The lesson one should get from all this is that the ultimate harm of spammers et al is that they are succeeding in corrupting the idea of a standards-based internet.
Sites invent policies to try to survive in a deluge of spam and implement those policies in software.
Usually they're loathe to even speak about how any of it works either for fear that disclosure will help spammers get around the software or fear that someone, maybe a customer maybe a litigious marketeer who feels unfairly excluded, will hold their feet to the fire.
So it's a vast sea of security by obscurity and standards be damned.
It's a real and serious failure of the IETF et al.
Has anyone ever figured out what percentage of a connection to the internet is now overhead i.e. spam, scan, viruses, etc? More than 5%? If we put everyone behind 4to6 gateways would the spam crush the gateways or would the gateways stop the spam? Would we add code to these transitional gateways to make them do more than act like protocol converters and then end up making them permanent because of "benefit"? Perhaps there's more to transitioning to a new technology after all? Maybe we could get rid of some of the cruft and right a few wrongs while we're at it?
We(*) can't even get BCP38 to work. Ha. Having nearly given up in disgust on trying to devise workable anti-spam solutions that would reliably deliver requested/desired mail to my own mailbox, I came to the realization that the real problem with the e-mail system is so fundamental that there's no trivial way to "save" it. Permission to mail is implied by simply knowing an e-mail address. If I provide "jgreco@ns.sol.net" to a vendor in order to receive updates to an online order, the vendor may retain that address and then mail it again at a later date. Worse, if the vendor shares the address list with someone else, we eventually have the Millions CD problem - and I have no idea who was responsible. Giving out tagged addresses gave a somewhat useful way to track back the "who was responsible," but didn't really offload the spam from the mail server. I've "solved" my spam problem (or, more accurately, am in the process of slowly solving my spam problem) by changing the paradigm. If the problem is that knowing an e-mail address acts as the key to the mail box, then giving the same key to everyone is stupid. For vendors, I now give them a crypto-signed e-mail address(*2). By making the key a part of the DNS name, I can turn off reception for a "bad" sender (anyone I don't want to hear from anymore!) or a sender who's shared "my" address with their "affiliates" (block two for the price of one!) All other validated mail makes it to my mailbox without further spam filtering of any kind. This has been excessively effective, though doing it for random consumers poses a lot of interesting problems. However, it proves to me that one of the problems is the permission model currently used. The spam problem is potentially solvable, but there's a failure to figure out (at a leadership level) paradigm changes that could actually make a difference. There's a lot of resistance to changing anything about the way e-mail works, and understandably so. However, these are the sorts of things that we have to contemplate and evaluate if we're really interested in making fundamental changes that reduce or eliminate abuse. (*) fsvo "we" that doesn't include AS14536. (*2) I've omitted a detailed description of the strategy in use because it's not necessarily relevant to NANOG. I'm happy to discuss it with anyone interested. It has technical merit going for it, but it represents a significant divergence from current practice. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.