On 1/18/11 4:58 PM, David F. Skoll wrote:
On Tue, 18 Jan 2011 16:55:42 +0100
Giles Coochey<gi...@coochey.net> wrote:
The legitimate mail that passes through my mail server comes from
hosts / networks I might not hear from again for months, by which
time I have to potentially wait 24 hours for the greylisting / mail
server to try again.
My point is I've never encountered a client that waits 24h to retry.
Most retry within minutes and the longest I've seen is maybe 4h.
RFC821/RFC2821/RFC5321 points out that a client has to wait a minimum of
30 minutes before a retry attempt should be made, unless the client is
able to determine what the reason is for the delay:
The sender MUST delay retrying a particular destination after one
attempt has failed. In general, the retry interval SHOULD be at
least 30 minutes; however, more sophisticated and variable strategies
will be beneficial when the SMTP client can determine the reason for
non-delivery.
As greylisting has never been standardized, there is no way for the
client to reliably determine after what interval a retry should be made.
Can you document that 'Most retry within minutes'? My experience is that
greylisting is causing real collateral damage due to the fact that many
MTA's use long retry intervals, at least longer than a few minutes*):
people get confused because their postings to mailing lists are delayed
while the discussion on the list goes on; people give up trying to
register themselves with sites, which send a confirmation message to the
customer: the customer is waiting for the confirmation mail and gives up
after a few minutes.
But I think you're right: I've yet to see the first MTA that waits for
24 hours before the first retry is done.
/rolf
*) The default retry interval for Postfix is 20 minutes, the default
retry interval for Sendmail is 1 hour, the default for Exchange is
(dependent on the role) 10 minutes or 30 minutes, default of Sun/Oracle
Messaging Server is 30 minutes or more, etc. etc.
