Problems sending mail to yahoo?
jgreco at ns.sol.net
Fri Apr 11 22:11:09 UTC 2008
> > 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 at 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
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
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.
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.
More information about the NANOG