On Dec 4, 2007, at 10:30 AM, Wietse Venema wrote:
By the way, I neglected to clarify my remark about fundamentally
different model, so I will take the opportunity to correct that.
Current email is primarily push technology. The problem therefore
is authenticating the pusher.
A fundamentally different model would be pull-based. For example,
to receive mail from my bank, I would pull it from their website.
I wouldn't have to worry if the mail is spoofed (it came from the
bank's website, I have their DNS name and SSL cert), and the bank
could easily claim that all other mail in their name is a forgery.
Note that pull-based email technology is immune to the problems of
forwarding, mailing list munging and third-party signatures.
One implementation is for the bank to send a tiny email message
with just a token, plus a plain old URL for legacy mail clients.
As in early MIME days, legacy clients show ugly stuff to the user.
Smart MTAs (or MUAs) would handle the download step transparently.
There's nothing revolutionary in this. It's just basic application
of a different email distribution model. In fact, that model can
be built on top of the existing one.
Agreed.
Here is a draft aimed at doing just that. IPR issues might require
this to model BURL's IMAP rather than HTTP.
http://www.ietf.org/internet-drafts/draft-otis-smtp-tbr-ext-00.txt
This could help deal with possible replay abuse where obligations for
delivery can be postponed. DKIM signed messages still offer recipients
somewhat transitory evidence to a third-party who originated the
message. (Within the realm often needed to report an immediate
problem) S/MIME would be less transitory of course.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html