[ 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.