Milter-greylist

Adam Katz wrote:
> I've heard users describe instances where mail is delayed for about a
> day.  This time, I had the time to dig up (and scrub) the logs.
> 
> I'm running milter-greylist 3.0 and sendmail 8.13.8 on Debian.
> 
> The important part of the log to note is:
> 
> Mar 6 16:17:37 milter-greylist from sender to userb delays 00:17:12
> Mar 6 16:17:37 sm-mta from sender via relay 123.45.67.89
> Mar 7 20:42:18 milter-greylist addr 123.45.67.89 from sender to userb
>                autowhitelisted for 504:00:00
> 
> sender uses only one mail relay in all transactions.
> sender has no problems sending the same message to usera.
> userb got sender's message 27 hours after usera got it.
> ... why?
> 

If you're greylisted, Milter-Greylist will accept the email on the next retry 
after the greylist expires, but exactly how long that takes depends on how long 
it takes for the sending server to retry. Milter-greylist can't control how 
often a sending server retries delivering mail.

The RFCs suggest retrying every 15 minutes, but an overloaded server with a lot 
of mail in its queue can take a very long time to retry. Also, most MTAs allow 
you to adjust the retry interval, and some admins reduce the retry frequency in 
order to limit the load and log output from retries..

Check your logs to see if the message delivery was retried between 16:17 and 
20:42.. If it wasn't retried, there's nothing MG can do about it. It can't call 
up and say "deliver your message now", it has to wait for the sending to present 
the message again.

This is actually a fundamental drawback of greylisting. Greylisting deals poorly 
with broken servers that don't retry, which is desirable and why it works. 
However it also excessively delays mail from servers that don't retry promptly 
like they should, which is desirable in some cases, and undesirable in others.