1) What *immediate* benefits do you get if you are among the first to
deploy? (For instance, note that you can't stop accepting "plain old
SMTP" till everybody else deploys).
The immediate benefit (as sender) is that you reduce the (now ever-increasing)
risk of your mail being rejected by filtration processes and will be trusted
on arrival; the benefit for the recipient is of course less junk!
However you CAN stop accepting "plain old SMTP" right away, because you can
delegate that to a filtration service that hosts your old-style MX, applies
ever-increasingly stringent filtration rules, and then forwards to you using
the new protocol. Several such filtrations services may well appear when the
time is right.
2) Who bears the implementation cost when a site deploys, and who gets
the benefit? (If it costs *me* to deploy, but *you* get the benefit,
why do I want to do this?)
Both parties get benefits which seriously outweigh the costs!
3) What percentage of sites have to deploy before it makes a real
difference, and what incremental benefit is there to deploying before that?
To some extent the concept is already here, and deployed, whether using
in-house filters or remote-MX, to subject the unauthenticated mail - which
of course is currently ALL the mail - to appropriate filtering.
(For any given scheme that doesn't fly unless 90% or more of sites do it,
explain how you bootstrap it).
That is a very valid point that most people don't address. I define any
new scheme as unworkable unless someone can describe the present, albeit
unsatisfactory, arrangements that it offers to replace as a "special case"
of the new scheme for which there is clearly-defined correct handling.
4) Does the protocol still keep providing benefit if everybody deploys it?
That depends entirely on the contactual relationships that may exist between
mail-exchanging sites. Just implementing an authenticating protocol on its
own will NOT help. There will be a prima-facie need for a selection of
"trust-authorities" who specify what is acceptable for their trusted-senders
to send. Recipients then get to choose which criteria are closest to their
requirements (including whitelisting if needed on a per-site basis).
(This is a common problem with SpamAssassin-like content filters - if most
sites filter phrase "xyz", spammers will learn to not use that phrase).
That goes for any precautions taken - not just content filters. That is WHY
the contractual relationships are absolutely essential for any new scheme.
And there, too, lies the bulk of the work needed - the technical issues do
not place any great demands on the networking community.
If you have a *serious* proposal that actually passes all 4 questions
(in other words, it provides immediate benefit to early adopters, and
still works when everybody does it), bring it on over to 'asrg@ietf.org'.
Heh. The noise-to-signal level *there* is far worse than in NANOG - by at
least 12dB last time I looked 
