Subject: [ietf-dkim] Nits with section 3 Operation Overview

From: Arvel Hathcock <[email-masked]>
Date: Tue, 30 Oct 2007 14:42:00 -0500

Just one suggestion.    I would rewrite the second sentence like this:

  "This practice would be used by those domains who wish to emphasize 
security over deliverability of their messages."

and leave out the bit about what we think the typical use case for this 
might be.  In fact, since none of the other practice options provide a 
rational behind why they would be used I don't see the need to do so 
here either in which case the entire sentence could be removed.  Or 
perhaps a NON-NORMATIVE DISCUSSION section could be added where the 
possible use cases and cautions could be given.

More coming
    
Arvel

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

---

From: Douglas Otis <[email-masked]>
Date: Tue, 30 Oct 2007 15:28:12 -0700

On Oct 30, 2007, at 12:42 PM, Arvel Hathcock wrote:

>  "This practice would be used by those domains who wish to  
> emphasize security over deliverability of their messages."

Unless the "From" field is specifically asserted as always signed,  
including other originating headers would allow spoofing of email- 
addresses within the particular domain by other domains.  However,  
this type of assertion interferes with deliverability of messages  
from various mailing lists.  If the assertion is intended to  
encompass both Sender and From fields as a type of escape mechanism,  
this would be expecting adoption of a strategy similar to that used  
by Microsoft where the MUA displays within the From field, "From:  
<sender-address> on behalf of <from-address>".  This synthetic field  
causes some confusion and angst as it is seen differently depending  
upon the MUA.  Of course the MUA could always display the Sender  
header, but then it could be confusing which field companies a valid  
signature.  Perhaps a green background placed behind any email  
addresses within a valid domain signature would be adequate.

The issue whether the i= identity has been validated in some fashion  
can not be answered without some specific additional assertion added  
to DKIM.  This assertion, if any are created, should be added to the  
Key if and when this becomes a requirement.  Don't expect this  
requirement to prove useful.  It would seem that the i= parameter  
within the signature field should become deprecated, as signers are  
likely to routinely add this to avoid deliverability or display  
issues.  If there is an inter-domain problem, this is something the  
signing domain needs to correct.  It would seem okay to simply say  
that highlighting any email-address be done whenever the domain is  
within a valid signing-domain, and ignore the issue of i=?.

For example, a message is signed-

  Sender: [email-masked]
  From: [email-masked]
  Dkim-signature: i=[email-masked]; d=example.com;...

Would the i= parameter invalidate the the [email-masked] address?
How should the synthetic "on behalf of" header be highlighted.

The i= parameter is a mess and should be deprecated at this point.

-Doug

---

From: Jeff Macdonald <[email-masked]>
Date: Tue, 30 Oct 2007 21:12:00 -0400

On Tue, Oct 30, 2007 at 03:28:12PM -0700, Douglas Otis wrote:
> The issue whether the i= identity has been validated in some fashion can 
> not be answered without some specific additional assertion added to DKIM.

I'm really having trouble understanding that since i= must be part or
equal to d=, why there needs to be further validation.

Why would a signing domain add an i= that would not be responsible? If
the answer is "because you can", why would one believe that d= would be
responsible?

-- 
:: Jeff Macdonald | Director of Messaging Technologies
:: e-Dialog | [email-masked]
:: 131 Hartwell Ave. | Lexington, MA 02421 
:: v: 781-372-1922 | f: 781-863-8118 
:: www.e-dialog.com