On Wednesday 29 November 2006 05:51, Charles Lindsey wrote:
On Tue, 28 Nov 2006 15:42:11 -0000, Scott Kitterman
<ietf-dkim(_at_)kitterman(_dot_)com> wrote:
2822.From is the only identity that is reliably displayed to the end
user.
I utterly fail to see why what is displayed to the user is of the least
relevance.
For DKIM-base I agree. There is no tie at all between the signing domain and
any of the 2822 identities. This is, as I think it was John Levine that
said, a feature, not a bug.
Verification is going to be done mostly by MDAs, who will either drop the
message, or else warn the user that it is suspicious (warnings may range
from a simple Good/Bad to a long essay on exactly what is wrong). It is
only when the user suspects he has a false positive that he might be
interested in examining the headers himself. More usually, if he is sure
it is a false positive, he will just accept it and get on with life.
The occasional sophisticated user who elects to do the verification
himself will naturally provide himself with tools which display all
headers of interest.
For DKIM-SSP it is a different matter. We've been through this before, but...
SSP needs an identity to key off of to lookup a policy. The agreed identity
for that is 2822.From for several reasons:
1. It the only 2822 identity that is mandatory.
2. It is one of the headers that is signed.
3. It is displayed to the end user (senders that have an interest in
protecting their domains from spoofing are deeply interested in what is
displayed).
4. Allowing any other header to trump the policy of 2822.From allows
2822.From to be trivially spoofed and eliminates whatever anti-phishing
potential there is in DKIM (how much that is has been argued to death and I
don't propose we do it again - it is what it is).
Scott K
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html