Jonathan,
Welcome to the group. It seems that you have put a fair amount of thought
into the problem and a possible solution. Yes, more details would be
interesting. The most efficient way to communicate those to the group would
be to create a document that details your approach. It seems that you've
already begin to think about it relative to other proposals. Additionally,
as you create your document, please take into account the considerations
presented in
http://www.ietf.org/internet-drafts/draft-crocker-spam-techconsider-02.txt .
We look forward to seeing your ideas.
Paul
-----Original Message-----
From: Jonathan Morton
[mailto:chromi(_at_)chromatix(_dot_)demon(_dot_)co(_dot_)uk]
Sent: Monday, September 08, 2003 1:10 PM
To: asrg(_at_)ietf(_dot_)org
Subject: [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
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg