New User? Register here - Existing Users: Username: Password: [Advanced Login]

 

 

Current Poll

Your preferred Interactive shell?









( 1334 votes ~ 14 comments )

 

Weblog entry #22 for lee

Exim retry control for greylist delivery
Posted by lee on Tue 12 Sep 2006 at 15:52

Greylisting is an anti-spam technique in which the receiving mailserver keeps track of information about the SMTP transaction, and unless it's been whitelisted, rejects the first attempt within a specified time period by fudging a "450" or "451" error. The theory being that legitimate mail servers will try again but spammers are less likely to.

I'm not a fan of greylisting. As someone who used to run a busy (legitimate!) listserver, they annoyed me immensely when deployed on primary MXes. (Having said that, I believe it may have its place on secondaries.)

One of the problems with the approach reared its head recently. For greylisting time windows to work they need to make reasonable assumptions about the retry windows the sender uses (and remember, greylisters don't advertise their time windows and there's no "Internet standard" to base assumptions on, just popular implementations). If the sender does not, or cannot, retry within the period before the original timestamp is purged, it goes back to square one.

Anything that relies on there not being some other problem either multiple machines and the internet between them isn't, as we say, "robust".

No problem, right? The mail originator gets the bounce and resends. Well, I suspect there may be a problem if the sender is using Exim. When the next mail is sent, Exim attempts a delivery, and chances are it will receive a temporary rejection. Exim will then check the address in its retry database and find that this is a long term failing address, and rather than retry it bounces immediately. (From the Exim docs Long-term failures: Reaching the retry cutoff is independent of how long any specific message has been failing; it is the length of continuous failure for the recipient address that counts.).

The quick fix at this point can be to haxxor the retry database with exim_fixdb, either by tweaking the date values, or just deleting it. (The example here is modified from a greylist address that hasn't yet expired).

# exim_dumpdb /var/spool/exim4 retry | grep "^  R:"| grep example.com
  R:bob@example.com -44 12877 SMTP error from remote mail server after RCPT TO:: host mx1.example.com [192.0.2.7]: 451 Greylisted

# exim_fixdb /var/spool/exim4 retry
> R:bob@example.com
12-Sep-2006 19:21:57
0 error number: -44 SMTP error from remote mail server after RCPT TO:: host mx1.example.com [192.0.2.7]: 451 Greylisted
1 extra data:   12877
2 first failed: 11-Sep-2006 12:01:36
3 last try:     12-Sep-2006 19:21:57
4 next try:     12-Sep-2006 19:36:57
5 expired:      no
> d

Then, in order to avoid doing this again for the specified address I put something into /etc/exim4/conf.d/retry/10_local_greylisters to customise the retry rules. The following rules, when met with a 451 code after RCPT, should retry every 30 minutes for the first 2 hours, every 20 minutes for the first 2 hours, and every hour until 7 days have transpired.

example.com   rcpt_451   F,2h,30m; F,4d,20m; F,7d,1h

 

 

 

Flattr