Milter-greylist

On 03/11/2008 09:45 AM the voices made Matt Kettler write:

> 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.
> 

My experience has been that 15 minutes greylisting is needlessly too
long. Many high volume mailers were resending in as little as 30
seconds. If the mail was again tempfailed by greylisting the sending MTA
moved the mail to a slow queue and it might be 2-4 hours before it was
retried again.

I have my greylisting set for 10 seconds and autowhitelisting for 30
days. The spammers who never try - well, they never retry. It doesn't
matter what the greylisting time is set for. Why needlessly delay the
MTAs that _are_ going to retry?