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

[Matthew Seaman]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Jeremy Chadwick wrote:
| On Thu, Oct 16, 2008 at 09:01:02AM -0500, eculp at casasponti.net wrote:
|> In the last hour, I've received over 200 legitimate bounce messages from 
|> email services as a result of someone having used or worse is using my 
|> email address in spam from multiple windows machines and ip addresses.  
|> The end result is that I am getting the bounce messages.  I'm sure that 
|> others on this list have experienced the problem and maybe have a 
|> solution that I don't have.
|>
|> The messages are allowed through my obspamd/pf and pf smtp bruteforce  
|> blocking rules because they are completely legit.
|>
|> I guess the work around is to filter them on incoming together with our 
|> local bounce messaages util the spammers get tired of my address.
| 
| The term coined for this type of mail is "backscatter".
| 
| There is no easy solution for this.  The backscatter article on
| postfix.org, for example, caused our mail servers to start rejecting
| mail that was generated from PHP scripts and CGIs on our own systems,
| which makes no sense.  The article:
| 
| http://www.postfix.org/BACKSCATTER_README.html
| 
| If the backscatter is all directed to a single Email address (rather
| than a series of addresses, e.g. sdfkjhsfjkksjdf at yourdomain.com, and
| you have *@yourdomain.com accepted), then a solution is to reject
| mail with an RCPT TO of an account or virtual address that does not
| exist on your machine.
| 
| This, of course, has a wonderful side effect: spammers now have a way to
| detect what Email addresses on your box legitimately accept mail, thus
| once they find one which never gets a bounceback, will start pounding
| that address to kingdom come.
| 
| Let me know if you do find a reliable, decent solution that does not
| involve SPF or postfix header_checks or body_checks.
| 

Although not a solution to the immediate problems experienced by the OP
in the long term, the most effective way to counter back-scatter spam is
for every operator of a mail server to adopt the following behaviour:

~   * Reject e-mails *only* during the initial SMTP dialogue -- ie. respond
~     with a 5xx error code.  No exceptions. This includes internal mail
~     submission of messages between users on the same system.

~   * Once your mail server has accepted a message for delivery, never
~     bounce it back to the sender as a result of spam or virus filtering
~     or for unknown destination address.  Just drop it in the bit-bucket
~     in these cases.

This means that your edge SMTP servers and all your MXes have to have an
accurate list of all of the valid e-mail accounts on your system so that
they can respond with 'user unknown' where required.

The point of rejecting messages only during the initial SMTP dialogue is
that at that point they are still the responsibility of the sending system.
Chances are if it's a compromised machine attempting to inject spam, it's 
not even going to attempt resending failed messages, or send bounce-o-grammes
on it's own behalf.

Unfortunately, building anything beyond a single-server mail system with these
characteristics is quite a lot harder than the simple-minded approach of
accepting anything address to your domain at the edge, and only bouncing at
the point of delivery to the mailbox.  Especially if your backup MXes are a
long way away from your main servers.

Until the wonderful day that the entire internet abides by these rules[*], use
of technologies like SPF and DKIM can discourage but not entirely prevent the
spammers from joe-jobbing you.

	Cheers,

	Matthew

[*] Unlikely to ever happen as technically they contradict the current RFCs.


- -- 
Dr Matthew J Seaman MA, D.Phil.                       Flat 3
~                                                      7 Priory Courtyard
PGP: http://www.infracaninophile.co.uk/pgpkey         Ramsgate
~                                                      Kent, CT11 9PW, UK
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREDAAYFAkj3WogACgkQ3jDkPpsZ+VaqKwCeMPa4tGkwewH+l0EfgVwTvpmS
IKoAoJ1ec2WTSwBQRsYq6rNYWqQc6P2Y
=lFRk
-----END PGP SIGNATURE-----