Ed Greshko wrote: > 1. The time to delay is configurable in a good greylist milter. Mine is > set to 15 minutes since this is pretty much the default retry interval of > most MTAs. then: > So, "SHOULD" is a guideline and having set my greylist interval to 15 > minutes is perfectly fine. OK -- I think you missed my point there, but I will agree that your point is also good. My point -- the standard recommends a retry interval of 30 minutes. That doesn't mean that a shorter interval doesn't follow the standard, merely that a longer retry period should be considered normal, according to the standard. Your point -- in practice, few MTAs follow the recommendation in their default configuration. I wrote: > But you are missing a detail here, and confusing "sending system", > "computer", and "IP address". For major providers, the sending system > may involve lots of computers, with lots of IP addresses. Retries may > come from any of those computers -- this is perfectly legitimate under > SMTP. So it may take a while (especially if they use an "exponential > back-off") before the same server retries the same e-mail. With enough > sending IP addresses, it's possible that the e-mail might never be > retried from the same IP address. Ed replied: > You said, "Retries may come from any of those computers" and this is an > incorrect statement. While a major provider has many systems sending out > emails when an individual email is placed in the queue of a sending system > it stays in that system's queue. You pointed out "SHOULD", I'll point out "MAY" in my statement. For many major senders, what you right is absolutely true. I maintain that it is not universally true, and there are some major exceptions. I understand that a number of major senders (who have their own, custom-written SMTP engines) do resend from different servers. There is a fair amount of evidence to support this: http://www.merakmailserver.com/forum/Greylisting_Bypass_Info/m_1441/tm.htm http://en.wikipedia.org/wiki/Greylisting makes this point. http://www.dataenter.co.at/doc/xwall_greylisting_exclusions.htm I wrote: > But you're missing another point -- the more people use greylisting, the > less reliable it becomes (because spammers start retrying on any error). > If Tony and I choose not to use greylisting, that makes it more usable > for you! Ed replied: > There is a word/phrase for that type of "argument", I think it is a "Red > Herring" but not sure.... > > Of course spammers will react to *any* defensive measures put in place and a > given defense will reduce in value in time. Why do you think we are seeing > more and more spam with single image attachments that are designed to fool > OCR programs? > > Yet, I don't see the effectiveness of greylisting going down. The > greylist's main role is to combat spambots. I'm sure you know what they > are, so there is no reason to explain. If creators of spambots would start > to build in complexity of retries into their process the return on > investment would be small and the users of the infected systems would more > likely detect things have slowed down. I think we're pretty nearly saying the same thing -- the more greylisting is used, the greater the return on investment would be. If everyone used greylisting, then spambots would be worthless unless they learned to retry. It looks as though most e-mail providers who are likely to use greylisting already have it in place, and that most spammers either aren't collecting or analysing reject rates, or they reckon the extra complexity of retrying isn't worth the hassle. But I am seeing some evidence that a few spammers are retrying even on 5xx permanent rejects (for example, identical e-mails, down to To: From: and Message-ID: fields, from the same IP address). James. -- E-mail: james@ | The "Power Switch" on ATX supplies, like traffic lights aprilcottage.co.uk | in Paris, really is just a polite suggestion. | -- Mike Andrews
