Handling spam in DSNs from other sites?
smf at f2s.com
Wed Jun 7 08:33:34 IST 2006
Furnish, Trever G wrote:
>> -----Original Message-----
>> From: mailscanner-bounces at lists.mailscanner.info
>> [mailto:mailscanner-bounces at lists.mailscanner.info] On Behalf
>> Of Glenn Steen
>> Sent: Tuesday, June 06, 2006 6:02 PM
>> To: MailScanner discussion
>> Subject: Re: Handling spam in DSNs from other sites?
>> On 06/06/06, Furnish, Trever G <TGFurnish at herffjones.com> wrote:
>>> I have a feeling I'm missing an obvious answer, but what
>> does everyone
>>> suggest for handling DSNs from other sites (not mine) that include
>>> spam in the message?
>> Glenn Steen wrote:
>> I'm sure others have other views, but ... why treat them any
>> different than any other mail? scan them, tag them, drop them....:-).
>> If they are legitimate, they will pass MS/SA/AVs anyway.
>> -- Glenn
>> email: glenn < dot > steen < at > gmail < dot > com
>> work: glenn < dot > steen < at > ap1 < dot > se
> Thanks. However, in many cases these are actually getting through.
> Since the ip address of the sending server isn't the spammer and isn't
> in the RBLs those checks aren't as helpful as they would've been for the
> original message.
> I tend to think these aren't being sent by a spammer who's identified a
> particular server with the specific intention of using the DSN for
> delivery, but rather just by a worm that's using my domain addresses as
> the faked sender address. If a specific server had been targeted, it'd
> probably end up in a DNSBL. SPF would help with the original message,
> but of course it does nothing to help with the bounce.
I've been experimenting with some stuff to address this. The problem
being that the DSN is being sent to you for a message that never
originated at your site.
After some investigation I found out that someone else had come up with
a clever solution to this: using SRS (part of SPF) to re-write all the
envelopes of messages sent from out from your domains (and re-writing
all inbound returns) with SRS (which contains a hashed-secret which
would be impossible for the spammer to guess). Then you use a milter
that rejects any DSNs that are not SRS signed or that are SRS signed and
do not have a valid signature.
Here's my results so far - this shows all MTA level rejections on my
date | greet_p | rbl | relay | uribl | 8bit | dsn_no_srs
2006-06-07 | 135 | 2168 | 263 | 467 | 101 | 82
2006-06-06 | 1389 | 25462 | 1061 | 4456 | 2214 | 1001
2006-06-05 | 1728 | 23948 | 93 | 5111 | 1591 | 1129
There are several down-sides, SRS is 'frowned' upon by some as it has
the potential to break the RFCs that state that the local-part field
size should be 64 bytes although it does state that an implementation
can pick a larger value (also VERP has been doing this for years without
issue). The other down-side is that to implement this I had to
re-compile Sendmail with -DSOCKETMAP and hack the .cf file as the
provided m4 HACK provided didn't work for me (it put the changes in the
wrong place). I've also never tried this on a production system.
See http://srs-socketmap.info/sendmailsrs.htm for the gory details...
Exim users have it slightly better than the Sendmail crowd - see
http://srs.mirtol.com/exim.php for details.
Before anyone asks -- I couldn't find an implementation for Postfix.
More information about the MailScanner