Milter-greylist

Hello,
Using milter-greylist 4.2+

from greylist.conf manual page

#       Here is an example that will use various DNSRBL depending on a 
#per-recipient setting stored in the dnsrbl attribute of a LDAP directory.
#
# dnsrbl "RBL2" "rbl.example.net" "127.0.0.2" 
# dnsrbl "RBL3" "rbl.example.net" "127.0.0.3" 
# dnsrbl "RBL4" "rbl.example.net" "127.0.0.4" 

# urlcheck "userconf" "ldap://localhost/dc=org?milterGreylistStatus,dnsrbl?one?mail=%r" 5 getprop clear

#  racl blacklist urlcheck "userconf" $dnsrbl "RBL2" dnsrbl "RBL2"
#  racl blacklist $dnsrbl "RBL3" dnsrbl "RBL3"
#  racl blacklist $dnsrbl "RBL4" dnsrbl "RBL4"

#Note that when matching gathered properties, format strings and regex can 
#be used.

Could I ask for additional explanation what exactly it means?
After four (including urlcheck) dnsrbl definitions 
and then three racl matching. Message to john@... is evaluated in 
the following way:

Assume I have ldap entry with

dn: cn=john,ou=foobar.net,dc=org
cn: john
mail: john@...
dnsrbl: MYRBL5 rbl5.example.net 127.0.0.5
dnsrbl: rbl6.example.net 127.0.0.6
dnsrbl: rblx7.example.net 
milterGreylistStatus: TRUE

1) ldap query (mail=john@...), requesting attributes
milterGreylistStatus and dnsrbl attributes, so the example matching 
response would be:

dnsrbl: MYRBL5 rbl5.example.net 127.0.0.5
dnsrbl: rbl6.example.net 127.0.0.6
dnsrbl: rblx7.example.net 
milterGreylistStatus: TRUE

so, what actually will be substituted as $dnsrbl keyword with racl using 
"userconf" ? Should I make sure, there'll be only one variable of dnsrbl 
retrieved? AFAIK return-only-matching-values ldapserver extension is not 
supported by classic ldapurl scheme, so the only way is to force
dnsrbl attribute with SINGLE-VALUE keyword in ldap directory schema.
But which one will be valid ? 

Assuming $dnsrbl in racl is just substituted "as-is", the following 
combination would be valid, depending on actual dnsrbl value

#1: dnsrbl: RBLX rblx.example.net 127.0.0.1
racl blacklist urlcheck "userconf" $dnsrbl 

OR

#2: dnsrbl: rblx.example.net 127.0.0.1
racl blacklist urlcheck "userconf" RBLX $dnsrbl

OR

#3: dnsrbl: 127.0.0.1
racl blacklist urlcheck "userconf" RBLX rblx.example.net $dnsrbl 

OR

#4: dnsrbl: rblx.example.net
racl blacklist urlcheck "userconf" RBLX $dnsrbl 127.0.0.1

#5. dnsrbl: rblx.example.net
#no 127.0.0.1, any response cosidered positive match
racl blacklist urlcheck "userconf" RBLX $dnsrbl 

I guess response is used as value, without attributeName, (string 
"attributeName: attributeValue" trimmed to "attributeValue"), so what 
about the following trick:

#filter: (&((mail=john@...)(customAttrName=*)), 
#custom attribute storing preference
#ldap://localhost/dc=org?milterGreylistStatus,customAttrName?one?mail=%r"

#4: customAttrName: RBLX rblx.example.net 127.0.0.1
racl blacklist urlcheck "userconf" $customAttrName

customAttrName must be SINGLE-VALUE anyway, multi-value will confuse 
urlcheck/ldapcheck ? 

Regards,

PW

On Thu, May 14, 2009 at 10:24:15AM +0200, Piotr Wadas wrote:
> Could I ask for additional explanation what exactly it means?
> After four (including urlcheck) dnsrbl definitions 

You don't need to duplicate the urlcheck clause: once it is
evaluated, you have the fetched variables available for the
remaining ACLs.

> so, what actually will be substituted as $dnsrbl keyword with racl using 
> "userconf" ? Should I make sure, there'll be only one variable of dnsrbl 
> retrieved?

urlcheck fetched values can be multivalued. If there are multiple dnrbl
attributes in your LDAP directory, $dnsrbl will contain all of them. 
An ACL will match if any of the $dnsrbl value match.

I made a presentation at SolutionsLinux 2009 about milter-greylist.
The slides are in french, but that will not prevent you for grabbing
the smple config files:
http://ftp.espci.fr/shadow/manu/SL2009.pdf

Once you will have the thing working, feel free to contribute documentation
to the milter-greylist wiki.

-- 
Emmanuel Dreyfus
manu@...

I'm still fighting with prop usage.

When incoming message is on its way, I got the following in verbose log:

Querying "ldap://127.0.0.1"
got prop $dnsrbl = "xxxx"
ldapcheck lookup performed in 0.001245s

and the following config:

###
ldapconf "ldap://127.0.0.1B"                                                                                                                                                                                                                                                                                                 
ldapcheck "lck" "ldap://nohost/dc=net?dnsrbl?sub?(mail=%r))" clear

dnsrbl "RBL2" rbl2.example.net 127.0.0.2
dnsrbl "RBL3" rbl3.example.net 127.0.0.2

racl blacklist ldapcheck "lck" $dnsrbl "xxxx" dnsrbl "RBL2"
####

So, in short, a property dnsrbl IS retrieved from ldap directory,
but racl still doesn't match. Expected behaviour is 
to use RBL2 or RBL3, depending on what "dnsrbl" attribute contains.
I tried to put "xxx" in dnsrbl ldap attribute, I tried
to put "RBL2" with/without quotes, still no effect. 
I tried to put the whole line 'dnsrbl "RBL2" x.y.z 127.0.0.2' 
in ldap attribute, and also 'x.y.z' (rbl server FQDN), and 
the answer rbl server is returnig. I tried to put 'TRUE' or 'OK'

WHAT the hell is the expected variable, to be returned as property value
from directory, to have racl match, and - as matched - use "RBL2"
dnsrbl entry (defined above) with "%r" user ? 

The following works as expected:

###
dnsrbl "RBL2" rbl2.example.net 127.0.0.2                                                                                                 
dnsrbl "RBL3" rbl3.example.net 127.0.0.2                                                                                                  
                                                                                                                                             
racl blacklist dnsrbl "RBL2"       
####

please :) what is the expected variable to be returned
as property right from directory, to match racl line?
In above example, I expect attribute value must match
sixth word in racl line, to use dnsrbl entry specified by
name as eighth word of racl line. I wonder to lookup in
source coude, but racl syntax definition is probably
complicated a little bit :)
regards,
Piotr 

On Thu, 14 May 2009, Emmanuel Dreyfus wrote:

> On Thu, May 14, 2009 at 10:24:15AM +0200, Piotr Wadas wrote:
> > Could I ask for additional explanation what exactly it means?
> > After four (including urlcheck) dnsrbl definitions 
> 
> You don't need to duplicate the urlcheck clause: once it is
> evaluated, you have the fetched variables available for the
> remaining ACLs.
> 
> > so, what actually will be substituted as $dnsrbl keyword with racl using 
> > "userconf" ? Should I make sure, there'll be only one variable of dnsrbl 
> > retrieved?
> 
> urlcheck fetched values can be multivalued. If there are multiple dnrbl
> attributes in your LDAP directory, $dnsrbl will contain all of them. 
> An ACL will match if any of the $dnsrbl value match.
> 
> I made a presentation at SolutionsLinux 2009 about milter-greylist.
> The slides are in french, but that will not prevent you for grabbing
> the smple config files:
> http://ftp.espci.fr/shadow/manu/SL2009.pdf
> 
> Once you will have the thing working, feel free to contribute documentation
> to the milter-greylist wiki.
> 
>

From the presentation,

> http://ftp.espci.fr/shadow/manu/SL2009.pdf

I expect a defined rbl 

dnsrbl "RBL2" my.server.com 127.0.0.2

should work with ldapcheck property of particular
attribute containing a word "RBL2" (without quotes),
and both (first found) of these racls: 

racl blacklist $dnsrbl "RBL2" dnsrbl "RBL2" msg "blabla"

OR

racl blacklist ldapcheck "lck" $dnsrbl "RBL2" dnsrbl "RBL2" msg "blabla"

The first one uses $dnsrbl (a stored query result), the second one
does lookup itself. Anyway, although

---

Querying "ldap://127.0.0.1"
got prop $dnsrbl = "RBL2"
ldapcheck lookup performed in 0.001574s

----

a message stil got some last default racl, instead of getting blacklisted.

Regards,
Piotr

Tested with ldapcheck and urlcheck - both cases property returned from 
ldap is exactly the same as the word in racl configuration line, anyway 
ACL does not proceed to rbl lookup - it does only with simple, direct racl 
dnsrbl config. I set up rbldns response on my dns server, and the
answer (127.0.0.2 in this case) is returned properly, if asked.
Regards,
Piotr

On Sun, May 17, 2009 at 09:57:30PM +0200, Piotr Wadas wrote:
> Tested with ldapcheck and urlcheck - both cases property returned from 
> ldap is exactly the same as the word in racl configuration line, anyway 
> ACL does not proceed to rbl lookup - it does only with simple, direct racl 
> dnsrbl config. I set up rbldns response on my dns server, and the
> answer (127.0.0.2 in this case) is returned properly, if asked.

I am almost AFK until next sunday. I will get back on this problem then.

-- 
Emmanuel Dreyfus
manu@...

There's something wrong with function ldapcheck_validate (ldapcheck.c),
returned props are not strcmp'ed at all (retval is always 0).

Additionally, when testing against urlcheck, a positive match
is acquired and dnsrbl lookup is done if, and only if, a 
milterGreylistAction property is returned ('blacklist' in this case).

(milterGreylistStatus returned or not doesn't matter as expected).

More, if defined urlcheck and ldapcheck with the same property name,
e.g. 'milterGreylistDnsRbl' (or simply 'dnsrbl'), used later with dollar 
prefix ($dnsrbl/$milterGreylistDnsRbl), property variable, as already
present, is probably overwritten. 

I'll post a patch, if I'll figure out what's missing.
Regards,
Piotr Wadas

Attaching simple schema I use with ldap tests.
Note, that it's related to standard sendmail.schema,
available from sendmail site, replace "sendmailMTAKey" with
standard "mail" attribute, if needed.

Regards
DT

-----------------

###################

attributetype ( 3.1.1.1.1.6.1
	NAME 'milterGreylistStatus'
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 
	EQUALITY booleanMatch 
	SINGLE-VALUE 
	DESC 'boolean. The ACL will match if any of below keys are returned: milterGreylistStatus is not mandatory.' )

attributetype ( 3.1.1.1.1.6.2
	NAME 'milterGreylistDelay'
	SUP sn
	SINGLE-VALUE
	DESC 'The greylisting delay to use (time unit suffix allowed)'	)

attributetype ( 3.1.1.1.1.6.3
	NAME 'milterGreylistAutowhite'
	SUP sn
	DESC 'The autowhite delay to use (time unit suffix allowed)'
	SINGLE-VALUE )

attributetype ( 3.1.1.1.1.6.4
	NAME 'milterGreylistFlushAddr'
	SINGLE-VALUE
	DESC 'The  value  is  ignored.  If  this  key  is  present,  then the IP address for the sender machine will be flushed from greylist and autowhite databases.'
	SUP sn )

attributetype ( 3.1.1.1.1.6.5
	NAME 'milterGreylistCode'
	DESC 'The SMTP code to return (e.g.: 551).'
	SUP sn )

attributetype ( 3.1.1.1.1.6.6
	NAME 'milterGreylistECode'
	DESC 'The SMTP extended code to return (e.g.: 5.7.1)'
	SUP sn )

attributetype ( 3.1.1.1.1.6.7
	NAME 'milterGreylistMsg'
	DESC 'The string to return with SMTP codes.'
	SUP sn )

attributetype ( 3.1.1.1.1.6.8
	NAME 'milterGreylistReport'
	DESC 'The string to display in the X-Greylist header.'
	SUP sn )

attributetype ( 3.1.1.1.1.6.9
	NAME 'milterGreylistIgnore'
	DESC 'This line will be ignored, without warnings in the logs.'
	SUP sn )

attributetype ( 3.1.1.1.1.6.10
	NAME 'milterGreylistAction'
	SINGLE-VALUE
	DESC 'By specifying the  values  greylist, whitelist, or blacklist, it is possible to overload the ACL action itself.'
	SUP sn )

attributetype ( 3.1.1.1.1.6.11
	NAME 'milterGreylistDnsRbl'
	DESC 'milter greylist preference dns rbl server name'
	SUP sn )

attributetype ( 3.1.1.1.1.6.12
	NAME 'milterGreylistNoLog'
	DESC 'milter greylist preference no log property'
	SUP sn )

objectclass ( 4.1.1.1.1.1.24 
	NAME 'milterGreylistSettingsBase'
	DESC 'This object represents milter-greylist settings ( structural )'
	MUST ( sendmailMTAKey )
	MAY ( 
		milterGreylistStatus $ 
		milterGreylistDelay $ 
		milterGreylistAutoWhite $ 
		milterGreylistFlushAddr $ 
		milterGreylistCode $ 
		milterGreylistECode $ 
		milterGreylistMsg $ 
		milterGreylistReport $ 
		milterGreylistIgnore $ 
		milterGreylistAction $ 
		milterGreylistDnsRbl $
		milterGreylistNoLog
	)
	STRUCTURAL
  )

###################

objectclass ( 4.1.1.1.1.1.25
	NAME 'milterGreylistSettingsAux'
	DESC 'This object represents milter-greylist settings (auxiliary)'
	MUST ( sendmailMTAKey )
	MAY ( 
		milterGreylistStatus $ 
		milterGreylistDelay $ 
		milterGreylistAutoWhite $ 
		milterGreylistFlushAddr $ 
		milterGreylistCode $ 
		milterGreylistECode $ 
		milterGreylistMsg $ 
		milterGreylistReport $ 
		milterGreylistIgnore $ 
		milterGreylistAction $ 
		milterGreylistDnsRbl $
		milterGreylistNoLog 
	)
	AUXILIARY
 )

------------------

On Mon, 18 May 2009, Emmanuel Dreyfus wrote:

> On Sun, May 17, 2009 at 09:57:30PM +0200, Piotr Wadas wrote:
> > Tested with ldapcheck and urlcheck - both cases property returned from 
> > ldap is exactly the same as the word in racl configuration line, anyway 
> > ACL does not proceed to rbl lookup - it does only with simple, direct racl 
> > dnsrbl config. I set up rbldns response on my dns server, and the
> > answer (127.0.0.2 in this case) is returned properly, if asked.
> 
> I am almost AFK until next sunday. I will get back on this problem then.
> 
>