Spamhaus...

Sun Feb 21 14:10:44 UTC 2010

[ This discussion really needs to move to spam-l. ]

On Sat, Feb 20, 2010 at 03:53:55PM -0500, William Herrin wrote:
> I don't know what your spam intake looks like but in mine, 5% to 10%
> can't be ranked "high confidence" until checked by an eyeball mark 1.
> In my system, that fraction is a candidate for a bounce... unless your
> SPF records have told me that the message has a forged sender. I honor
> whatever instructions you've made the effort to give me via the sender
> policy framework.

So, "drink the SPF koolaid or I'll abuse your mail system"?  No thanks.

> That's the part that really galls me. Instructing my system not to
> bounce questionable messages related to yours is entirely within your
> control. You don't even have to know I exist; you just put a simple
> well-standardized line in your DNS. The instruction you choose to
> offer, I'll do all the processing necessary to honor it.

This is wrong.  Use of SPF, as I pointed out previously, *does not stop
backscatter spam*. [1]  This is very old news to everyone who's been
paying attention on spam-l for the past however-many-years.  I suggest
a thorough reading of the relevant traffic archived there, where any
number of nasty attack scenarios -- some of which are history,
not speculation -- have been discussed.

Hint: nothing stops the spammers from pointing the MX records for their
throwaway domains at somebody else's mail servers.  Among other things.
MANY other things, unfortunately.

The only thing that stops backscatter spam is not sending bounces. [2]
Period.  Full stop.  And sending rejects (that is: issuing 5xx responses
during the SMTP conversation) fully complies with the applicable RFCs,
so there's no issue there.  That's why it's a BCP.  And that's why
people who don't do it often get (correctly) blacklisted for the spam
they will inevitably emit.

The days of bounces are over.  Gone.  Buh-bye.  Thanks to 100M+ zombies
and all the other factors I previously listed, they are NOT coming back. [3]
We could lament it ad infinitum and argue about letter/spirit of the RFCs
twice as long, but the immediate operational goal is to reduce the amount
of abuse on the 'net, not sustain or amplify it.  Given that *at least*
95% of the mail traversing the 'net is junk/abusive (more like 98-99%, but
let's be a little conservative) the very last thing any operation
should be doing is passing it on or generating more of it.

Aside: this is part of a more general principle of SMTP abuse control:
do not allow attackers to cause *your* operation to generate outbound
traffic to arbitrary destinations of *their* choosing.  It's unlikely
that they will be kind enough to do so for your benefit or for that
of your victims.

---Rsk

[1] Neither does DKIM or SenderID or anything similar. 

[2] As before, "not sending bounces unless the sender is an
authenticated user".  And also as before, modulo the occasional
edge cases.

[3] I'm starting to think 200M may be a more realistic current
estimate, but the exact number really doesn't matter that much.
However large the number is, it's still increasing monotonically
and there is at present no reason on the table to think that this
trend will reverse.  And this is only one of several related problems
of large scale and scope that we face.  My crystal ball is murky,
but I see no reason whatsoever to think that ANY of these problems
will be fixed, let alone ALL of them.