Handling spam in DSNs from other sites?

[Steve Freegard]

Hi Trever,

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 
test box:

     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.

Cheers,
Steve.