On 1/18/11 11:02 PM, David F. Skoll wrote:
On Tue, 18 Jan 2011 22:18:33 +0100
"Rolf E. Sonneveld"<r.e.sonnev...@sonnection.nl> wrote:
RFC821/RFC2821/RFC5321 points out that a client has to wait a minimum
of 30 minutes before a retry attempt should be made,
That's fine. I don't care if an email from someone I've never heard
from before is delayed 30 minutes or even a couple of hours.
I agree with you, looking at my own personal situation. However, many
mail admins (and maybe you too) are responsible for the e-mail handling
of many (tens/hundreds/thousands) of users. Most users have unrealistic
expectations of e-mail delivery times, and become impatient when an
e-mail they send is not delivered after a few minutes. We can tell them
they should not have these expectations, but they just have them. User
education is a tough task. How many phone calls start with 'Hi <name>,
how are you, did you receive my mail?'.
Can you document that 'Most retry within minutes'?
I analyzed 1655 machines from my logs that successfully passed greylisting.
The mean retry time was about 13000 seconds, or about 3.6 hours.
The standard deviation was high at 45000 seconds (12.5 hours).
That being said, 1390 of the 1655 machines retried within 4 hours and
1586 of 1655 retried within a day. Every one of the machines that took
longer than a day was actually a spam box that only "accidentally" passed
greylisting when it tried sending a second spam using the same sender
address.
Thanks for sharing these figures, they're really useful even though the
standard deviation is high.
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.
Our system notices when a host retries and turns off greylisting for 40 days
for that host. That can greatly reduce the collateral damage. It also
won't greylist senders to whom I've sent mail within the last 6 months.
I wish everyone, using greylisting, would do what you did. That sure
would reduce collateral damage! I have a question about your setup: do
you automatically greylist senders to whom you sent mail the last 6
months? If so, do you differentiate between interpersonal messages
(legit mail from you to that sender) and out-of-office type messages
(which can be the result of spam messages and can carry your mail
address, depending on what type of mail system you use)?
For me, greylisting is so cheap and so effective I'm willing to live with
the small amount of colateral damage it introduces.
The right anti-spam defense is always a balance between catching as much
spam as possible and avoiding false positives (and other collateral
damage) as much as possible. IMHO too many mail admins focus on the
former, forgetting about the latter. The net result is that the
reliability of Internet e-mail system has degraded over the last 15 years.
/rolf
