I was just told by a guy trying o sell me www.sendio.com that it blocks 100% of all spam with zero false positives! Are you telling me he is a liar?
__________________________________________________ Stefan Jafs -----Original Message----- From: Andy David [mailto:[EMAIL PROTECTED] Sent: Thursday, February 21, 2008 15:04 To: MS-Exchange Admin Issues Subject: RE: GreyListing... I do understand it. But hey, greylist all you want. Nothing is stopping you. But anyone who says any SPAM solution has no false positives and never drops any legitimate mail is full of it. -----Original Message----- From: Jason Gurtz [mailto:[EMAIL PROTECTED] Sent: Thursday, February 21, 2008 10:24 AM To: MS-Exchange Admin Issues Subject: RE: GreyListing... 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 ~ ~ Ninja Email Security with Cloudmark Spam Engine Gets Image Spam ~ ~ http://www.sunbeltsoftware.com/Ninja ~ This email and any attached files are confidential and intended solely for the intended recipient(s). If you are not the named recipient you should not read, distribute, copy or alter this email. Any views or opinions expressed in this email are those of the author and do not represent those of the Amico Corpoartion company. Warning: Although precautions have been taken to make sure no viruses are present in this email, the company cannot accept responsibility for any loss or damage that arise from the use of this email or attachments. ~ Ninja Email Security with Cloudmark Spam Engine Gets Image Spam ~ ~ http://www.sunbeltsoftware.com/Ninja ~
