postgrey

[Warren Togami]

William Reading wrote:
> On Mon, Apr 09, 2007 at 11:40:51AM -0400, Ethan Blanton wrote:
>> You cannot control the length of the delay imposed by the graylisting,
>> all you can do is define a *minimum*.  The actual delay is controlled
>> by the remote server, and is the amount of time it takes to decide to
>> retry.  As you are essentially telling the remote server "I am
>> overloaded, please try again later", any *good* mail server is going
>> to wait some nontrivial period of time before trying again, preferably
>> with some sort of exponential backoff.  Five minutes (300 seconds) is
>> not an unusual *initial* retry period.
> 
> I've found that setting a delay of 60 seconds with greylisting tends to
> work pretty effectively, but it still does tend to get delayed about an
> hour typically. (Most spambots seem to keep retrying every second rather
> than queue it and try again in a minute or ten like most MTA's.)
> 
> Granted, that's still outside the acceptable timeframe for a lot of
> people.
> 

A very effective alternative is a hybrid of greylisting + DNS RBL.  By 
default you would not delay any mail delivery.  But if the sending MTA 
is listed in a RBL (usually dynamic home IP) then use a 1 minute 
greylisting delay.  This means senders from legitimate MTA's who are not 
on any blacklists go cleanly through.  Others have the one-time 
greylisting delay, but thereafter they have no delay too.

Warren Togami
wtogami at redhat.com