[Top] [All Lists]

Re: [ietf-dkim] Re: Role of Sender header as signing domain

2006-11-29 06:52:40
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

I utterly fail to see why what is displayed to the user is of the least

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 
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

<Prev in Thread] Current Thread [Next in Thread>