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

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

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 PROTECTED]
 From: [EMAIL PROTECTED]
 Dkim-signature: [EMAIL PROTECTED]; d=example.com;...

Would the i= parameter invalidate the the [EMAIL PROTECTED] 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

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

Reply via email to