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. > 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. > 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. For me, greylisting is so cheap and so effective I'm willing to live with the small amount of colateral damage it introduces. Regards, David.
