Milter-greylist

> On Nov 27, 2015, at 11:26 PM, manu@... [milter-greylist] <milter-greylist@yahoogroups.com> wrote:
> 
> DATA-stage ACL are evaluated after RCPT-stage ACL. therefore line 301
> here can never see the variable set afterwards in line 294.
> 
> Generally speaking it is a good idea to have dacl after racl in the
> file: it prevents such confusion.
> 

Thanks—in hindsight that should have been obvious.

Now that I’m doing DATA-phase checks in dacls (or trying to), I’ve run into a different problem: how does one structure the greylist.conf file so that dacls actually have a chance to affect the disposition of the message?

This comes directly from the greylist.conf man page:

spamdsock inet "127.0.0.1:783"
racl whitelist default
dacl blacklist spamd > 15 msg "Your message is considered spam."
dacl greylist  spamd > 10 delay 2h
dacl greylist  spamd > 5  delay 1h

In my testing the greylisting decision is always made based on the last (matching) racl (or if there is none, on the default greylist and autowhitelist settings).  Even using a “continue” action as the last racl results in the default action taking place.

Here are the results of some focused testing on this problem.  In each case the message is coming in from a non-trusted relay and contains a string that causes SpamAssassin to give the message a very high score.  My MIMEDefang filter triggers to add an X-Spam-Level header, which I’m trying to use in my greylist.conf to do something different with such messages.  The mimedefang milter is called before milter-greylist.

All of the configuration other than racl and dacl is boilerplate or unused lists (for this configuration anyway), so I’m just providing the racl and dacl statements.

Case #1 - default racl action is to whitelist (dacl is never consulted)

# cleared database
racl “DEF” whitelist default
dacl “XSL” greylist header /^X-Spam-Level:[ ]*(.*)$/ delay 30m autowhite 90m

Nov 29 13:14:00 xxx milter-greylist[30633]: tATIDxm8030639: skipping greylist because this is the default action, (from=<rm55@xxx>, rcpt=<rm55@xxx>, addr=xxx) ACL DEF

Case #2 - default racl action is to greylist (dacl is never consulted)

# cleared database 
racl "DEF" greylist default delay 1m autowhite 5m
dacl "XSL" greylist header /^X-Spam-Level:[ ]*(.*)$/ delay 30m autowhite 90m

Nov 29 13:18:06 xxx milter-greylist[30711]: qid: addr xxx from <rm55@xxx> to <rm55@xxx> delayed for 00:01:00 (ACL DEF)

# retry
Nov 29 13:19:15 xxx sendmail[30735]: qid: Milter add: header: X-Greylist: Delayed for 00:01:09 by milter-greylist-4.5.12 (xxx); Sun, 29 Nov 2015 13:19:15 -0500 (EST)

# subsequent delivery
Nov 29 13:21:47 xxx sendmail[30760]: qid: Milter add: header: X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.5.12 (xxx); Sun, 29 Nov 2015 13:21:47 -0500 (EST)

Case #3 - no default racl (dacl is never consulted)

# cleared database 

#racl "DEF" greylist default delay 1m autowhite 5m                                                                                  
dacl "XSL" greylist header /^X-Spam-Level:[ ]*(.*)$/ delay 30m autowhite 90m

Nov 29 13:24:52 xxx milter-greylist[30814]: qid: addr xxx from <rm55@xxx> to <rm55@xxx> delayed for 00:05:00 (ACL )

# retry
Nov 29 13:29:56 xxx sendmail[30873]: qid: Milter add: header: X-Greylist: Delayed for 00:05:03 by milter-greylist-4.5.12 (xxx); Sun, 29 Nov 2015 13:29:56 -0500 (EST)

Case #4 - only racl action is continue (dacl is never consulted)

# cleared database 

#racl "DEF" greylist default delay 1m autowhite 5m                                                                                  
racl "CON" continue from /./
dacl "XSL" greylist header /^X-Spam-Level:[ ]*(.*)$/ delay 30m autowhite 90m

Nov 29 13:33:07 xxx milter-greylist[30934]: qid: addr xxx from <rm55@xxx> to <rm55@xxx> delayed for 00:05:00 (ACL CON)

# retry
(no point, this is just like the previous case)

Thanks,
Rudy