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

2006-11-30 Thread Charles Lindsey
On Wed, 29 Nov 2006 16:50:24 -, william(at)elan.net [EMAIL PROTECTED] wrote: On Wed, 29 Nov 2006, Charles Lindsey wrote: On Tue, 28 Nov 2006 15:42:11 -, Scott Kitterman [EMAIL PROTECTED] wrote: 2822.From is the only identity that is reliably displayed to the end user. I

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

2006-11-30 Thread Charles Lindsey
On Wed, 29 Nov 2006 11:42:25 -, Eliot Lear [EMAIL PROTECTED] wrote: Charles Lindsey wrote: I utterly fail to see why what is displayed to the user is of the least relevance. Because it's very possible UAs will indicate whether a message is signed or not. This is already done with

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

2006-11-30 Thread Charles Lindsey
On Wed, 29 Nov 2006 13:44:30 -, Scott Kitterman [EMAIL PROTECTED] wrote: SSP needs an identity to key off of to lookup a policy. The agreed identity for that is 2822.From for several reasons: But that is wholly back to front. The SSP policy to look up initially should be that of

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

2006-11-30 Thread Scott Kitterman
On Thursday 30 November 2006 05:55, Charles Lindsey wrote: Ah! I think I see now what Scott and Eliot are getting at. Suppose we have: From: [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] with good signature by bar.com The verifier informs the recipient that the message was signed by

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

2006-11-30 Thread Bill.Oxley
I fail to see any relevance here? Go out to your user pool show them the headers and ask them what they signify. Chances are not much. From: [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Good DKIM sig from bar.com Means that bar.com signed on behalf of (purportedly) [EMAIL PROTECTED] and when

[ietf-dkim] Re: new issue: clarify i= vs. SSP

2006-11-30 Thread Frank Ellermann
Michael Thomas wrote: we need to have clarity in SSP on what, exactly, qualifies as a valid signature for I sign everything. This guidance is not in dkim-base (purposefully), but I believe that we had intended i= to provide that clarity. In any case, we do need to provide the exact semantics

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

2006-11-30 Thread Michael Thomas
Charles Lindsey wrote: On Wed, 29 Nov 2006 13:44:30 -, Scott Kitterman [EMAIL PROTECTED] wrote: SSP needs an identity to key off of to lookup a policy. The agreed identity for that is 2822.From for several reasons: But that is wholly back to front. The SSP policy to look up initially

Re: [ietf-dkim] new issue: clarify i= vs. SSP

2006-11-30 Thread Dave Crocker
Michael Thomas wrote: Hi, One of the things I noticed from recent discussions is that we need to have clarity in SSP on what, exactly, qualifies as a valid signature for I sign everything. Michael, To carry your point farther than I suspect you intend: From the virtually all of the SSP

[ietf-dkim] new issue: requirement to enumerate receiver side benefits of SSP?

2006-11-30 Thread Michael Thomas
Dave Crocker wrote: Michael Thomas wrote: Hi, One of the things I noticed from recent discussions is that we need to have clarity in SSP on what, exactly, qualifies as a valid signature for I sign everything. Michael, To carry your point farther than I suspect you intend: From the

Re: [ietf-dkim] new issue: requirement to enumerate receiver side benefits of SSP?

2006-11-30 Thread Steve Atkins
On Nov 30, 2006, at 9:11 AM, Michael Thomas wrote: Dave Crocker wrote: Michael Thomas wrote: Hi, One of the things I noticed from recent discussions is that we need to have clarity in SSP on what, exactly, qualifies as a valid signature for I sign everything. Michael, To carry

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

2006-11-30 Thread Douglas Otis
On Nov 29, 2006, at 10:52 AM, Eliot Lear wrote: The same plug-ins can also verify an associative policy regarding other headers as well. Being signed might be for entities found in the 2822.From, the 2822.Sender, or for the 2821.MailFrom (to help ensure DSNs). First of all, we are now

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

2006-11-30 Thread Douglas Otis
On Nov 30, 2006, at 2:55 AM, Charles Lindsey wrote: There are two cases: 1. The MUA has been specially adapted to work with DKIM 2. The MUA has not been specially adapted We are supposed to be designing a system which will work with existing MUAs (i.e. case 2), so in that case the