...

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.

And this would deploy how? In particular, consider the following questions:

A few of the larger user sites such as AOL and MSN would deploy it between themselves. Once it is proven, they would analyse their logs and invite the large email sender sites to begin using the protocol. Once it is clear that NIMTP can be deployed easily and cheaply, they begin to impose rate limiting on email senders using SMTP which will cause queues to build at the email sender sites. Eventually running NIMTP will be recognized as the right thing to do and everyon will use it.

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).

2) Who bears the implementation cost when a site deploys, and who gets

You can replace complex and buggy spam filtering software with simple rules on your NIMTP servers. Since the spammer cannot spoof their identity, you simply rate limit them based on the volume of attempts. I.e. if a sender attempted to send 10 messages in one hour, you might limit him to 2 per hour but if he attempted to send 100 per hour you would limit him to 1 per hour. And if he attempted to send 1000 per hour you would limit him to 1 every 4 hours. the

benefit? (If it costs *me* to deploy, but *you* get the benefit, why do I want to do this?)

The site owners pay all the costs and reap all the benefits. Just like today with spam filtering.

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).

The incremental benefit is there if NIMTP deployment starts with large email sites.

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).

Of course it keeps providing benefits. The two key elements of NIMTP (New Improved Mail Transfer Protocol) are that the receiver will only receive email messages from a known sender site and the sender site will certify the identity of the message sender. In order to know the sender site, there needs to be an authentication handshake for a session and it needs to be based on some kind of prearranged agreement and key exchange. In order to certify the message sender, all messages will need to be relayed through an NIMTP relay site and the message sender will need to authenticate themself, i.e. using something like AuthSMTP. But AuthSMTP will only be used between mail clients and their email service provider. NIMTP is intended to be used between email service providers. Some of these NIMTP sites will be relaying email for smaller NIMTP sites that cannot afford the complexity of prearranging keys with all other NIMTP sites. To summarize, the NIMTP core will have NIMTP peering arrangements with every other member of the NIMTP core, but many NIMTP sites will only have NIMTP peering with one or two other sites. In order for anyone to send email within the NIMTP world they will need to hand the email to any NIMTP site who will relay it to its destination. But the NIMTP site will only accept email if it can certify the sender's identity.

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'.

I've just joined the ASRG list and if I can find the time I will try to write this up as a draft architecture and post it. But feel free to copy these emails to ASRG if you feel it would be worth discussing there. --Michael Dillon