Re: [ietf-dkim] Re: ISSUE 1525 -- Restriction to posting by first Author

On Jan 31, 2008, at 6:15 AM, Charles Lindsey wrote:

> On Wed, 30 Jan 2008 14:46:56 -0000, Jeff Macdonald <jmacdonald(_at_)e-dialog(_dot_)com 
> > wrote:
> > On Wed, Jan 30, 2008 at 11:18:08AM -0000, Charles Lindsey wrote:
> > > On Tue, 29 Jan 2008 17:52:57 -0000, Jeff Macdonald <jmacdonald(_at_)e-dialog(_dot_)com 
> > > > wrote:
> > > > On Wed, Jan 16, 2008 at 09:46:26AM -0800, Dave Crocker wrote:
> > > > <snip>
> > > >
> > > > > In any event, "on behalf of" is key wording that permits more  
> > > > > flexibility than you seem to be acknowledging.  Note, for  
> > > > > example, that the agent specified in the Sender field is acting  
> > > > > "on behalf of" the author.
> > > > Is that agent authorized to work "on behalf of" the author?
> > > That is what the person who actually sent it is claiming.
> > >
> > > A well-organized 1st party signer will not sign anything that did  
> > > not originate within is domain, and containing a From/Sender  
> > > within bis domain.
> > Ah, I thought were were talking about the case where there isn't a
> > signature for the domain that is present in the From: header, but  
> > just
> > the Sender: header. Additionally the domains for those two headers
> > would be different.
> Agreed. If the Sender domain was already one of the From domains,  
> there is no need to consider it further.
Agreed.

> But suppose that there were 4 From addresses, from domains which  
> published no SSP. But for some reason the 4 authors had engaged  
> someone from domain E to Send it for them. Suppose E publishes a  
> strict SSP. Then they are going to sign it on the way out, and so it  
> is a 1st party signature.
Disagree.  The concept of 1st Party signature would be with respect to  
the From email-address.  In other words, SSP assurance is limited to  
policy statements regarding email-addresses found within the From  
domain.  When a signature is signed on-behalf-of the Sender header  
(i=) using a key that could encompass that of the From email-address  
(g= t=) in question, the signature alone verifies the signing domain's  
policy.  When the From email-addresses do not reference SSP records,  
and the signature on-behalf-of the Sender does not encompass the From  
address, this signature represents that of a Third-Party.
> The verifier sees the valid signature and is puzzled because it does  
> not relate to any of the Froms; he looks for SSP, and there is none  
> for those Froms. Is it a 1st or 3rd party signature (for some reason  
> he likes to know which it is)? Then he looks closer and discovers  
> that it was indeed Sent from the domain that signed it, which has a  
> strict SSP (plus a good reputation). So maybe that makes him  
> happier, especially if we provide a mechanism in SSP for E to say  
> "we sign Sender headers where appropriate".
While this check can be made, checking email-addresses found in  
different headers will likely have little benefit, but that might  
depend upon the MUA/OS being used.  Outlook will show the From as the  
"on behalf of" following the Sender's address.  The virtual From  
header is to support the PRA validations.  This might open the door  
for Sender header spoofing, but this will also increase the overhead  
involved with checking SSP.  Consider that most email is not signed.
> So for sure we could build that into SSP if we wanted to.
No need when "all" or "strict" is complaint where just the signature's  
domain and key qualify a valid signature.
> I agree that I can't think of anything the Bad Guys might that do  
> would be spotted due to an unsigned Sender header, but you never  
> know what Bad Guys are going to dream up next :-( .
Perhaps.

> And note that this thread started with Dave asking what a Sender  
> header actually "meant", presumably with the intent of enquiring  
> what mechanisms we were providing that might increase confidence in  
> that meaning.
Ignoring the i= parameter found within the signature represents the  
simplest way to address this concern.  This then allows verifiers, at  
their discretion, to check the policy of any email-address.
-Doug


_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html