Problems sending mail to yahoo?

> 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 "" 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

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