On 4/30/2011 9:10 PM, Hector Santos wrote:
So perhaps to help shut down this ambiguity we should add a DKIM
terminology to clearly separate it from AUID.
3.x Originating Domain Identity (ODID)
The ODID is the domain part of the From: address. This identity
MAY be considered as an output communicated to an advanced
Identity Assessor module.
Oh heck, let's just declare that the DKIM Signing module MAY output anything it
wants. That way we satisfy every possible output desire that has been
expressed
or might be expressed. After all, it's clear that implementers need the
permission.
Or we might notice that the purpose of a protocol specification is to define
conventions that are followed by both sides of an interaction and that specific
specifications are constrained to specific functions, in order to keep them
tractable. Telling implementers that they are free to follow any local
conventions they want violates both of these otherwise-normal requirements.
So rather than continue to fight old, settled issues that primarily have to do
with making DKIM try to be something it isn', a better idea would be to review:
Section 2.1:
INFORMATIVE RATIONALE: The signing identity specified by a DKIM
signature is not required to match an address in any particular
header field ...
Section 4.5, i=:
INFORMATIVE DISCUSSION: This specification does not require the
value of the "i=" tag to match the identity in any message
header fields.
Section 4.10:
INFORMATIVE DISCUSSION: This document does not require the value
of the SDID or AUID to match an identifier in any other message
header field.
In other words, DKIM has nothing to do with the rfc5321.From field, and
therefore it is entirely inappropriate -- that is, out of scope -- for the
specification to suggest dealing with it.
At least, please show working group rough consensus support for doing what you
suggest.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html