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

[Jeremy Chadwick]

On Mon, Oct 20, 2008 at 11:16:31AM -0500, Paul Schmehl wrote:
> --On Monday, October 20, 2008 10:24:28 -0500 "Michael K. Smith - Adhost"  
> <mksmith at adhost.com> wrote:
>
>>>
>>> Let me know if you do find a reliable, decent solution that does not
>>> involve SPF or postfix header_checks or body_checks.
>>>
>>
>> The following doesn't fix the problem but it does help mitigate the deluge.
>> We use a PERL script to tail our maillogs looking for any source IP that
>> tries to send mail to more than 4 invalid addresses.  When flagged, that IP
>> is then added to a PF table that blocks the address and issues RST's for 12
>> hours.  Of course, we also have a whitelist for "valid" SMTP servers.  Like I
>> said, it doesn't catch it all, but it catches *a lot* and generates almost no
>> complaints.  This does help obfuscate the valid/invalid addresses because all
>> mail is accepted as far as the sender is concerned until the IP is blocked at
>> the network layer.
>>
>> The usual complaint is from an remote office that has 12 real estate agents
>> behind a single IP, all with Outlook set to check mail "sooner than now."  :-)
>>
>
> 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.
>
> Here's one example of a rejected email:
>
> Oct 20 11:11:16 mail postfix/policyd-weight[77973]: weighted check:  
> IN_DYN_PBL_SPAMHAUS=3.25 NOT_IN_SBL_XBL_SPAMHAUS=-1.5 NOT_IN_SPAMCOP=-1.5 
> NOT_IN_BL_NJABL=-1.5 CL_IP_NE_HELO=4.75 REV_IP_EQ_HELO=-1.25  
> NOK_HELO_SEEMS_DIALUP=5 (check from: .hinet. - helo:  
> .dsl.dynamic8121373125.ttnet. - helo-domain: .ttnet.)  
> FROM/MX_MATCHES_NOT_UNVR_HELO(DOMAIN)=4.85 
> CLIENT_NOT_MX/A_FROM_DOMAIN=4.75 CLIENT/24_NOT_MX/A_FROM_DOMAIN=4.75; 
> <client=81.213.73.125> <helo=dsl.dynamic8121373125.ttnet.net.tr> 
> <from=alan0730 at ms35.hinet.net> <to=abeinlets at stovebolt.com>; rate: 21.6
> Oct 20 11:11:16 mail postfix/policyd-weight[77973]: decided action=550 
> Mail appeared to be SPAM or forged. Ask your Mail/DNS-Administrator to 
> correct HELO and DNS MX settings or to get removed from DNSBLs; please 
> relay via your ISP (ms35.hinet.net); Please use DynDNS; 
> <client=81.213.73.125> <helo=dsl.dynamic8121373125.ttnet.net.tr> 
> <from=alan0730 at ms35.hinet.net> <to=abeinlets at stovebolt.com>; delay: 8s
>
> Anything above 1 is rejected.  This email scored 21.6, which is off the charts.
>
> It even does greylisting.
>
> Oct 20 10:45:47 mail postfix/policyd-weight[28339]: decided action=550  
> temporarily blocked because of previous errors - retrying too fast. 
> penalty: 30 seconds x 0 retries.; <client=189.141.58.189>  
> <helo=dsl-189-141-58-189.prod-infinitum.com.mx> <from=ii7jam at hotmail.com> 
> <to=milliman at stovebolt.com>; delay: 0s
> Oct 20 10:46:51 mail postfix/policyd-weight[28339]: decided action=550  
> temporarily blocked because of previous errors - retrying too fast. 
> penalty: 30 seconds x 0 retries.; <client=65.110.50.188> 
> <helo=boomfm.dnsalias.com> <from=aw-confirm at ebay.com> 
> <to=tsp at stovebolt.com>; delay: 0s
>
> It does let some spam through, which spamassassin catches, but it rejects 
> all the bogus stuff (fake hostnames, bogus MTAs, forged from addresses, 
> etc., etc.)

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.

-- 
| Jeremy Chadwick                                jdc at parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                  Mountain View, CA, USA |
| Making life hard for others since 1977.              PGP: 4BD6C0CB |