Hector Santos:
[ Charset ISO-8859-1 unsupported, converting... ]
Wietse Venema wrote:
Perhaps an analogy from a different but familiar world will help.
Consider DKIM or SSP as broadcast radio transmissions (or TV if
you must). The point is that it is a UNIDIRECTIONAL thing. The
sender doesn't know if anyone is receiving the signal, and they
certainly can't force anyone to listen (or watch their TV program).
Likewise, the sender of DKIM-enabled email doesn't know if the
receiver implements DKIM or SSP, and they certainly can't force
them to implement unenforceable statements that say "deny".
DKIM and SSP have no more "enforcement" power than broadcast radio.
You don't know who "receives" the signal and you certainy can't
force them to do anything with it.
With the DKIM and SSP broadcast model, you can define the format
of the signal and its meaning. That's all. If you want to control
the receiver and "deny" mail, then you need a fundamentally different
model.
Yes Wietse.
Thank you for highlighting the simple broadcaster/receiver model. It was
very appropiate.
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.
Wietse
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html