On Mon, Oct 20, 2008 at 11:16:31AM -0500, Paul Schmehl wrote:
The best solution *by far* that I have found for spam (using Postfix) is
mail/postfix-policyd-weight. It routinely rejects 50 to 70% of incoming
mail with no false positives. It took *very* little tweaking to get it
to this point, and it rejects the mail before postfix even deals with
it.
I use spamassassin as well, but policyd-weight does the heavy lifting.
We used to use numerous features in postfix to block mail during
different phases of the SMTP handshake, requiring strings meet RFC
standards, comply with being FQDNs, resolve, blah blah... It
worked great... until...
One day, one of my users mailed me stating they were in a lot of
trouble: they hadn't been receiving any mails from eBay, specifically
contact from buyers/sellers (to negotiate payment means, etc.), and
outbid notifications.
I went digging through logs, and sure enough found the cause: eBay's
HELO strings were what pedants would call "absolutely preposterous".
They violated 3 or 4 different checks postfix had. At first I tuned
postfix to allow certain IP blocks through that check, only to find
that it's nearly impossible to determine all of the IP blocks eBay
has -- in fact, some of their mail gets siphoned through a third-party
mailer, and it looks like that mailer uses IPs all over the place.
Meaning: administrative nightmare.
There is nothing worse than telling your users "Okay, I've fixed it",
only to get mail from them 24 hours later stating "Umm, no you didn't,
and this is really starting to piss me off".
I went through the same ordeal with other users and their LiveJournal
mail notifications being blocked.
The point I'm trying to make is that all this overly-aggressive
filtering might work great if you're one guy maintaining your own box
only used by you -- and I have a feeling a lot of people who post on
this list are exactly that. It's a **completely** different game when
you've got other people reliant upon your mail filtering decisions.
The problem with blocking mail "early on" (meaning before it's queued,
e.g. SMTP 5xx or 4xx rejections) is that the end-user has no knowledge
of this. They simply do not get the mail. They're left in the dark,
wondering "Did <person> send the mail? Are they lying to me? What's
going on???". It's a very sensitive thing when you're a hosting
provider.
In the case of my users, they would much rather get the mail and have it
incorrectly flagged as spam, than not get it at all. I personally
believe this directly reflects on the state of anti-spam affairs: we've
gotten so aggressive that *who KNOWS* what kind of legitimate mail we're
blocking.