I've just found a new and interesting spam source - legitimatebounce messages

[Paul Schmehl]

--On Monday, October 20, 2008 10:11:36 -0700 Jeremy Chadwick 
<koitsu at FreeBSD.org> wrote:

> 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.

That's why it's critically important that whatever tools you use be highly 
configurable.  In the case of policyd-weight, you can configure it so that it 
passes *everything* through but marks it in such a way that you can filter it 
appropriately.

In my case, I run a small hobby website with a minimal number of email 
addresses.  When I first installed policyd-weight, I watched it closely and 
discovered it was blocking legitimate mail from sbcglobal because they didn't 
have their mail servers' dns properly configured.  The result was a score just 
slightly higher than the threshold for rejection (a tenth of a point or two.) 
I decided to make that particular check worth less overall, and that solved the 
problem.

I have yet to receive a single complaint about mail not getting through, and, 
although there's only a handful of accounts on the server, we get mail from our 
website users constantly.

I fully understand where you're coming from, Jeremy.  We have the same issues 
at UTD.  But for many smaller sites, policyd-weight would be a godsend.

-- 
Paul Schmehl, Senior Infosec Analyst
As if it wasn't already obvious, my opinions
are my own and not those of my employer.
*******************************************
Check the headers before clicking on Reply.