Why do you say RFC2822.From header field, specifically? Why
do you care what, specific field contains the identity?
Very, very good question. This is all tied up in the ambiguity
associated with trying to determine "who sent me this message". If one
must determine the signing policy of the "sending domain" one must make
the decision - who is the "sending domain"? To determine that, an
examination of the relevant sub-set of message headers is the only route
to take. Among those headers, there is one which carries a virtue that
none of the others possess - the RFC2822.From - alone amongst all other
identity headers, is prominantly displayed to naive users. Regardless
of the truth of the matter, end-users today have been trained by their
MUA's to view the RFC2822.From as the definitive "sending" entity. So,
I pick the RFC2822.From because (for right or wrong) it has this extra
property which the other identity headers do not possess. Therefore,
all else being equal, it seems the logical decision.
I strongly disagree. It is vitally important to distinguish between
"who wrote or authorized this content" and "who authorized the
transmission of this message to this recipient". RFC2822.From is a
close approximation to the first, but not the second. We currently
don't have an SMTP or 2822 field that approximates the second. (for
various reasons neither Sender nor Return-Path/MAIL FROM is close enough).
If end-users today are accustomed to thinking the message was sent by
RFC2822.From, they will need to be educated, and they may also need
better MUAs that make the distinction clear. But I don't think most
end-users are this naive or incapable of understanding the difference.
Mailing lists, for example, do not follow this convention. Nor do
forwarded messages. Neither one of these seems to result in a great
deal of user confusion.
Keith
_______________________________________________
ietf-dkim mailing list
ietf-dkim(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/ietf-dkim