'Tis true that some major e-mail players like yahoo, gmail, hotmail etc may have issues with greylisting because of thier server farms - but whatever you are using to greylist should be aware of this and be able to compensate.
... and Greylisting those providers is pointless anyway. They are a legit source of email. On Thu, Feb 21, 2008 at 10:24 AM, Jason Gurtz <[EMAIL PROTECTED]> wrote: > Sorry for the length, but greylisting is wide spread now and people should > really understand it. Long story short: If you implement greylisting > after DATA and whitelist a handful of very large email providers you won't > be disappointed > > > >> Greylisting only delays legitimate mail. It will stay in queue > >> and be sent again. The notion that Greylisting loses legitimate > >> email is a misnomer. > > > > Now that's funny. When you have 20 million messages coming to your > > door everyday ( And Jim over there at BB&T has even more than that) > > from all over the world, many from systems in countries that are still > > using older mail systems following RFC 821, I bet you wouldn't say > > that. > > Greylisting has known problems with very large mail providers such as > Yahoo and Gmail. But this is due to those systems retrying with a > different host than the one that initially tried delivery and triggered > greylisting which breaks the greylisting algorithm. Those domains that > need exemption from greylisting are well known and can be counted on two > hands. Blaming greylisting failure on RFC 821 is interesting and seems > like a reach though. > > From RFC 821 Appendix E: > > 4yz Transient Negative Completion reply > > The command was not accepted and the requested action did > not occur. However, the error condition is temporary and > the action may be requested again. The sender should > return to the beginning of the command sequence (if any). > > Granted it says SHOULD and doesn't say MUST but... RFC 821 was amended > some 19 years ago to make behaviors more explicit by RFC 1123. Can I get > a hand count of people that had dedicated Internet connectivity at that > time? ;) > > From section 5.3.1.1 Sending Strategy: > > [...] > In a typical system, the program that composes a message has some > method for requesting immediate attention for a new piece of > outgoing mail, while mail that cannot be transmitted immediately > MUST be queued and periodically retried by the sender. A mail > queue entry will include not only the message itself but also the > envelope information. 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 sender-SMTP can determine the reason for non- > delivery. > > Retries continue until the message is transmitted or the > sender gives up; the give-up time generally needs to be at > least 4-5 days. The parameters to the retry algorithm MUST > be configurable. > [...] > > > I'm not sure about 1980's era mail servers (almost certainly running a > protozoan era sendmail + maybe IDA patches) but 1993 era sendmail will > most certainly queue and retry outgoing mail. Are you saying you deal > with people running SMTP servers older than 15 years!? > > Now as far as the exchange bug... Well Lotus Notes had a similar failure > to retry bug but fixed several years ago now. Note that the exchange bug > is only triggered by greylisting that is applied before the DATA command. > Therefore, if your greylisting implementation returns a 4xx response code > to the DATA command (*after* the RCPT TO), you will not be affected by the > exchange bug. > > Someone else already posted links to the reg edit and hotfix but people > here may be interested in these posts at microsoft.public.exchange.admin: > <http://tinyurl.com/2sbtvm> I haven't heard about if Exchange 2k7 still > has this issue and would be very interested if someone could verify if > this bug is truly gone. :) > > As always, I highly recommend people run something else in between their > Exchange and the public Internet because of a long history of smtp bugs in > the exchange smtp engine. > > ~JasonG > > -- > > > > ~ Ninja Email Security with Cloudmark Spam Engine Gets Image Spam ~ > ~ http://www.sunbeltsoftware.com/Ninja ~ -- ME2 ~ Ninja Email Security with Cloudmark Spam Engine Gets Image Spam ~ ~ http://www.sunbeltsoftware.com/Ninja ~
