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