Milter-greylist

On Thu, 2006-11-23 at 10:01 +0000, Emmanuel Dreyfus wrote:
> On Thu, Nov 23, 2006 at 09:13:36AM +0100, manu@... wrote:
> > rcpturl "level 1" "http://www.foo.net/gr.php?rcpt=%r" "level1"
> > rcpturl "level 2" "http://www.foo.net/gr.php?rcpt=%r" "level2"
> > 
> > acl greylist rcpturl "level 1" greylist 15m
> > acl greylist rcpturl "level 2" greylist 1h 
> 
> While I think about it: delegating the decision to a web middleware
> does not have to be done only on the recipient address. We could immagine
> adding various information to the quesry such as sender IP, sender e-mail
> and so on. 
> 
> If we introduce racl (evaluated at RCPT stage) and dacl 
> (evaluated at DATA stage), we can even imagine sending the message body 
> using a POST request.
> 
> Such a feature seems to allow much more flexibility than just a recipient
> lookup in a LDAP directory, a SQL database, or whatever. 
> 
> The syntax would look like that:
> urlfilter "level 1" "http://www.foo.net/gr.php?rcpt=%r+ipaddr=%a" "level1"
> urlfilter "level 2" "http://www.foo.net/gr.php?rcpt=%r+ipaddr=%a" "level2"
> 
> acl greylist urlfilter "level 1" greylist 15m
> acl greylist urlfilter "level 2" greylist 1h
> 
> In the urlfilter statement, we could use:
> %r recipient e-mail
> %f sender e-mail
> %a sender IP
> %d sender DNS name
> %mfoo sendmail macro foo's value
> 
> Opinions?

I'm 100% with you on this, however I would do the config in a different
manner here.

First define a pair of URL references:
urlquery-rcpt <url>
urlquery-data <url>

i.e.:
urlquery-rcpt "http://www.foo.net/rq.php?rcpt=%r+ipaddr=%a+from=%f+ipdns=%s"
urlquery-data "http://www.foo.net/dq.php?rcpt=%r+ipaddr=%a+from=%f+ipdns=%s"

Define query timeouts:
urlquery-timeout <seconds>

And - define the possible responses as follows:
urlquery-response (<custom_response>|DEFAULT) <well_defined_action>

Where:
        <custom_response> - is a string value to be mapped to a well
        defined
        		action or the special case DEFAULT to be used in
        		case of the comm failure with the HTTP server or an
        		undecipherable response
        
        <well_defined_action> - is one of the following:
                greylist <time>	 -      final decision, cached in
                pending,
                			distributed via mxsync
                
                whitelist <time> -      final decision, cached in awl,
                			distributed via mxsync
                
                reject		 - 	final decision
                
                next		 -      allows milter to use other means like
                			SPF and DNSBL to make it's decision
                
                ...

I.e:
urlquery-response "grey1" greylist 15m
urlquery-response "grey2" greylist 30m
urlquery-response "white" whitelist 5d
urlquery-response "no opinion" next
urlquery-response DEFAULT next


The internal search order for the decision within the milter-greylist
would be:

     1. awl cache
     2. pending cache
     3. http query (if defined)
     4. the "old" behavior if the "next" is the action

What do you think?

R.