[Asrg] 6. Email Path Verification

Hi, I'm new to ASRG so feel free to point out any obvious flaws (or 
redundancy) in my post.
After reading an article on The Register, which quoted Dr. Solomon as 
suggesting that a "penny post" scheme would be the best anti-junk 
system around (but conceding that present takeup and attitudes to the 
idea were not encouraging), I got to thinking about schemes which might 
work.
Starting from the "penny post" principle, I figured out a high-level 
method of attaching a cryptographic signature to an e-mail, via a 
third-party "payment agent".  The recipient would then have the option 
of checking the signature both against the e-mail and against the 
agent.  The agent, moreover, could be looked up in a directory of 
agents, chosen by the recipient.
At this point, I realised that the agent not only need not actually 
charge for it's services, and also need not be attached to the sender's 
smarthost or ISP.  This makes deployment and acceptance much easier in 
the early stages, certainly easier than IPv6.  The agent does have to 
check whether a user is apparently trying to sign a large batch of 
mails, but this is not technically difficult.
The actual volume and pricing policy would be set by the agent, which 
would be under market pressure from both ends - allowing sufficient 
volume and low prices to please senders, while still keeping the 
quantity and quality of mail sent through it in line with recipients' 
(really the directory maintainers') expectations.  I can suggest a 
number of models which might be considered by different agents.
At this point I started looking through the RFC and I-D databases to 
see what other people were doing in this line, and eventually came 
across the ASRG's work.
The end result of my idea's evolution (over several days) looks less 
like the SHRED system presented by AT&T Labs, and more like the last 
entry in the Email Path Verification paper.  My system, however, adds 
an extra trust layer in the form of the agent directory, which would 
operate in a similar manner to the present RBLs, but generally as a 
whitelist rather than a blacklist.
The system operates entirely independently of the mail transport 
system.  Signatures are added as headers in the RFC2822 scope, so they 
survive through SMTP, POP3, IMAP and all similar protocols with no 
modifications to existing MTAs.  Signing and verification are both 
optional, and initiated by the MUA at the appropriate end.
I've also considered scalability problems introduced by large mailing 
lists, some problems associated with the limited resources on some 
e-mail clients, the usability and security problems introduced by 
storing cryptographic keys on inexperienced users' machines, and can 
suggest a solution to each of these.  I believe the idea is 
implementable using existing infrastructure and technologies, with 
minimal impact on most users' experience of e-mail.
If you'd like me to go into more detail, please ask.

--------------------------------------------------------------
from:     Jonathan "Chromatix" Morton
mail:     chromi(_at_)chromatix(_dot_)demon(_dot_)co(_dot_)uk
website:  http://www.chromatix.uklinux.net/
tagline:  The key to knowledge is not to rely on people to teach you it.


_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg