> The web of trusted email servers would use a new and improved mail
> transfer protocol (NIMTP) that would only be used to exchange email
> between trusted servers. Users could continue to use authenticated SMTP to
> initiate the sending of email, but nobody would accept any unauthenticated
> SMTP servers any more.
Hmmm. I fail, personally, to see why ESMTP couldn't handle it. Sure, it
would require a new extension, but what's what the E is for, isn't it?
Specifically, view it as a form of public-key certificate exchange, whether
you trust a central authority or a web of trust to establish that identity
(and, really, nothing says you couldn't do both). A signature from each hop
along the way (though normally this wouldn't be more than 2-3, since most
mailservers these days directly connect).
And this would deploy how? In particular, consider the following questions:
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 very, very first to deploy? Very little, but also very little, if
any, cost - since nobody will invoke that extension, there's no crypto
verification overhead inbound or outbound. It costs a few bytes in your
EHLO block, I guess, and some code that will stay paged out once the
process has run for any length of time.
Almost the first to deploy, before wide adoption? Tie it into your other
spam filtering systems. Stuff from trusted sources (however that is
defined) can get tailored rules for each verified site (for most, that
probably means higher trust; for a few, lower).
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?)
Like many game situations, all deployers benefit, in a curve related to the
number of deployers, and the cost hits each deployer. Making the overhead
cost very low (an extra config line the next time you upgrade sendmail, to
turn it on, and adding certificates for sites you actually care about, if
and when you care about them) would remove most of the pain. A marginal
cost to deploy, weighed against a benefit based on the risk of others
deploying, can still be an acceptable business risk.
3) What percentage of sites have to deploy before it makes a real difference,
and what incremental benefit is there to deploying before that? (For any given
scheme that doesn't fly unless 90% or more of sites do it, explain how you
bootstrap it).
Two sites that speak to each other will potentially make a difference to
those two sites. Value as deployment increases is probably better than
linear, for most calculations of value return (I'm sure there are some
where it might not be; they don't have to deploy, if the cost is higher
than the value return, but that seems likely to be rare *if* it's done
properly).
4) Does the protocol still keep providing benefit if everybody deploys it?
(This is a common problem with SpamAssassin-like content filters - if most
sites filter phrase "xyz", spammers will learn to not use that phrase).
Yes. It provides more benefit the more sites deploy it, by building a
cohesive web of trusted servers within which one can believe, with some
reasonable expectation of being correct, that you know who is actually
talking to you - and make secondary decisions based on that, much as many
folks now do with RBLs.
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'.
The devil is, of course, in the details. The most crucial of them being
that it *must* be extremely easy to implement, likely to be implementable
in widespread software releases, and that the incremental overhead of use
must be small enough that the value provided is greater, in most cases.
In my opinion, at least, the value derived isn't from stopping spam;
spammers will still use throwaway accounts, folks will still try to
scam others, none of this will magically stop existing. The value is in
establishing a single, verifiable, consistant identity for any system with
which you might wish to talk, so that you can make decisions based on that
identity (or the lack thereof).
Much of this is based on my observations of the use and adopting of PGP and
SSL certificates. I don't sign all of my messages - most of them, yes, but
I occasionally don't do so if I expect the recipient might have problems
reading it, and if the recipient is valuble enough to make that choice.
Even though 90% of the mail coming to my inbox isn't PGP signed, it also
doesn't incur any extra cost; my client supports it automagically, and only
invokes it when I *do* get signed mail. I can then look at that signature,
and any other data I have either in the trust database or my own head, and
make decisions based on that data (Verified signature, a person I find
usually has reasonable ideas, probably worth reading; bad signature, read
with skeptecism; no signature, default handling).
It shouldn't be too difficult to imagine a set of rules for SpamAssassin
or similar setups that looks like:
MATCH (mailserver I trust to never relay spam) -1000
MATCH (mailserver which sends me lots of useful mail and rare throwaway
spam accounts that their abuse team will nail) -10
MATCH (signed mailserver, unknown certificate) -1
MATCH (unsigned mailserver) +0.5
MATCH (known spamhause mailserver) +10
Okay, sure, most spammers won't be nice enough to use well-identified
servers, and will fall into the unknown category; the value for this is
probably initially very low (since most mail would be there), and if
adoption increases, it can rise accordingly (look at how many folks are
willing to flat-out refuse connections from various RBLed servers, or from
all of APNIC space, or other broad, sweeping cutoffs).
Value also scales much faster if it's large ISP mailservers implementing
it, rather than Joe Blow's home server - and these mailservers are the ones
that are most likely to be able to generate a certificate and enable a
known feature line with very marginal overhead cost.
As a comparison: how many sites, today, don't support the 8BITMIME
extension? How much value do they lose from not supporting it? How many
sites have SpamAssassin rules (or the equivalent) that assign a trust value
to emails that have 8-bit headers?
How much benefit did early adopters of 8BITMIME get, how much did it
cost them, and how long did it take for value to rise above cost for a
significant percentage of sites?
I'm not going to assert that the answers are identical, but I do suspect
(based solely on personal observation) that they might not be all that
different, either.