On August 19, 2005 at 23:23, Keith Moore wrote:
The point is that, for a variety of reasons, From really has no implied
relationship with who sent the message, and has only a tenuous
relationship with who wrote the message. People have stood on their
heads trying to reconcile this with the desire to make the IDs of
principals who sign the message agree with the legacy message headers,
but it just doesn't fit - there are too many different things that are
done with messages, for justifiable reasons, that invalidate this
assumption. Rather than try to change the way that existing fields are
used, it makes a lot more sense to just define new fields (or parameters
within a DKIM-Signature field) that have the semantics you want.
I think the core problem is that email cannot truely denote who
"authored" this message. RFC-2822 states that From indicates who was
involved in the authoring of the message. However, there is no way to
enforce this since a person can put anything in From, and no mechanism
exists to reliably associate a mailbox address to a real-life person.
The DKIM signing part of the specification actually avoids this
problem. From a signer's perspective, the i= tag denotes the
identity the signer is signing on behalf of. DKIM does not require
that the identity be a mailbox address, but whatever facilitates the
identification policies of the domain, so the identity has no real
value to the recipient. A DKIM signature makes no assertion on the
authorship of a message.
The SSP part does address this particular problem. SSP is an attempt
to deal with (domain-level) forgery in a way based upon the existing
behaviors of mail software, mainly the prominence rfc2822.From has
in the rendering of messages to people. Right or wrong, MUAs give
rfc2822.From a prominent role in message rendering. More work is
involed in modifying all the MUAs being used versus applying a
"good-enough" solution that does not need MUA modification initially
(but such changes will definitely be beneficial in the long term).
I'm all for having DKIM be as easily understood by "ordinary people" as
possible. But trying to add new functionality to an existing user
interface, without changing that interface, just doesn't work. If you
want DKIM to add value for recipients, MUAs need to display signed
messages differently than unsigned messages anyway. It might as well
display the identity of the signer instead of, or in addition to, the
From address.
Identity of signer has little value unless the role of the signer is
clearly understood (or displayed).
Just as a proof of concept, imagine that MUAs started displaying DKIM
signed messages differently than unsigned messages: unsigned messages
would display From:, while messages signed by their authors would
display something like Signed-From: e.g.:
a) From header a(_at_)b(_dot_)c; signed by a(_at_)b(_dot_)c would be
displayed:
Signed-From: a(_at_)b(_dot_)c
b) From header a(_at_)b(_dot_)c, b(_at_)b(_dot_)c; signed by a(_at_)b(_dot_)c
would be displayed:
Signed-From: a(_at_)b(_dot_)c [[claiming to represent a(_at_)b(_dot_)c,
b(_at_)b(_dot_)c ]]
(presuming that the From header were included in the signature)
c) From header a(_at_)b(_dot_)c; no signature would be displayed:
From: a(_at_)b(_dot_)c
You still have the problem of the signer forging the signed-from.
Therefore, the identifier placed in the signed-from will still need
to be checked by a verifier to determine if that identity allowed
the signer to use it. This is what SSP does.
So what have you really gained with "Signed-From"?
IMO, the benefit of Signed-From is that it protects the contents
from rfc2822.From munging (e.g. address rewriting). Therefore,
it is more for protecting the integrity of the signed content than
anything else. Since MUAs may not understand Sign-From initially,
(MTA-level) verifiers could replace the rfc2822.From with the Sign-From
so MUAs will see the rfc2822.From as it was signed.
--ewh
_______________________________________________
ietf-dkim mailing list
http://dkim.org