Milter-greylist

Hi,

On Fri, Nov 12, 2004 at 02:58:52PM +0100, manu@... wrote:
> After some discussions behind the scene with Remy Card, I repost my last
> proposal about an ACL mecanism for milter-greylist, so that he can reply
> on this topic and move forward to another proposal. 

	Thanks, Manu!

> I insist on the point that I don't push the syntax presented in this
> document rather than another one, but IMO another proposal with another
> syntax should propose the equivalent functionnality.

	Well, on my side, I must admit that I really hate the squid-like
syntax.  I think that it introduces an extra complexity that is not needed,
IMHO.  I find squid acl complex to write and to read aand I think that it
would be a pain to handle them internaly in milter-greylist.

	That's why I want to propose a simpler syntax that addresses the
same issues.

> ===== My last unanswered proposal about ACL in milter-greylist =====
> 
> We would have a first match list of greylist/whitelist keywords, each
> using an ACL using a last match basis. Here is a complete proposal, I'd
> appreciate if people could comment:

        I'd like to propose a simpler scheme.  There would be a single
access-list that would be evaluated in sequence.  The evaluation would stop
when encountering the first entry that matches.
   
        Each entry would have this syntax:

acl greylist|whitelist [addr IP/CIDR] [from address|regex]
        [rcpt address|regex] [domain domain|regex]

> First, a few examples...
> 
> # first config, Dan's setup:
> acl grandma {
>         rcpt grandma@...
>         not from friend@...
>         not from another.friend@...
> }
> greylist grandma
> whitelist default

        This could be written:
 
acl whitelist from friend@... rcpt grandma@...
acl whitelist from another.friend@... rcpt grandma@...
acl greylist rcpt grandma@...
acl whitelist rcpt /.*/

> # Second config, Remy's setup:
> acl foo {
>         rcpt .*@...
>         not rcpt postmaster@...
> }
> greylist foo 
> whitelist default

        This could be written:

acl whitelist rcpt postmaster@...
acl greylist rcpt /.*@.../
acl whitelist rcpt /.*/

> # And finaly, Manu's setup:
> acl user1 {
>         rcpt user1@...
> }
> acl user2 (
>         rcpt user2@...
> }
> acl user3 {
>         rcpt user3@...
> }
> acl mywhitelist {
>         addr 193.54.0.0/16
>         domain friendly.com
> }
> whitelist mywhitelist
> greylist user1
> greylist user2
> greylist user3
> whitelist default

        This could be written:

acl whitelist addr 193.54.0.0/16 domain friendly.com
acl greylist rcpt user1@...
acl greylist rcpt user2@...
acl greylist rcpt user3@...
acl whitelist rcpt /.*/

> default is an internally defined ACL that match anything.
> 
> It seems to me that it matches all the needs that have been described
> here so far. Now, let's try to be more formal:
> 
> For each {greylist|whitelist} keyword {
>         for each entry in its ACL {
>                 if it's addr and the IP doesn't match
>                         break out of the ACL loop
>                 if it's domain and the domain doesn't match
>                         break out of  the ACL loop
>                 if it's from and the sender doesn't match
>                         break out of  the ACL loop
>                 if it's rcpt and the recipient doesn't match
>                         break out of  the ACL loop
>         }
>         if all entries in the ACL matched or if it was void {
>                 retain the {greylist|whitelist} decision 
>                 exit the keyword loop
>         }
> }

        With my proposition, I think that the evaluation would be:

match=0
Foreach (entry in the ACL) while (match == 0) {
        match=1
        if the entry contains an IP/CIDR couple and the IP desn't match {
                match=0
                continue
        }
        if the entry contains a domain and the domain doesn't match {
                match=0
                continue
        }
        if the entry contains a from and the sender doesn't match {
                match=0
                continue
        }
        if the entry contains a rcpt and the recipient doesn't match {
                match=0
                continue
        }
}
If (match == 1)
        return the type of the entry (greylist or whitelist)
else
        return the default type

> The last problem is to convert the older keyword to the new framework so
> that we can retain backward compatibility in the config file.
> 
> "rcpt X" in test mode will be interpreted as
> acl X {
>         rcpt X
> }
> greylist X
> 
> 
> "rcpt X" in "normal" mode will be interpreted as
> acl X {
>         rcpt X
> }
> whitelist X
>  
> 
> "{addr|from|domain} X" turns into
> acl X {
>         {addr|from|domain} X
> }
> whitelist X

        With my proposal, conversion is much easier : just add "acl " before
each {addr|domain|from|rcpt} keyword.  A simple sed script could do the work.

> Test mode turns into adding "whitelist default" at the end of the config
> Normal mode turns into adding "greylist default" at the end of the
> config.
> 
> We would tag as obsolete all the old syntax, but we will keep it working
> for the sake of backward compatibility (did I ever explained I hated
> software that broke my config files? :-) 

        I think that it's easy to handle the old syntax, by modifying
conf_yacc.y: just add an ACL entry when parsing the old {addr|domain|from|rcpt}
keywords instead of an exception entry.

	I'm interested in comments on this proposal.  I think that it addresses
the needs that I have been expressed on this list (if I am wrong, please point
out the needs that my proposal does not address).

	Cheers

		R\ufffdmy