Eliot Lear wrote:
Further to my earlier message about clarifying the interoperability
problem, if the above statement is really the case, why not remove i=
entirely? We are already rather strongly warned about its use in RFC
4871. So, what is its remaining value?
Its utility is outside of DKIM. The DKIM base spec says the value is
opaque. Other specs can expose its structure.
If the signer knows the identity of the user/agent, it can put it in. If
may choose to do so using a variety of schemes, one of which is to use
the user/agent's email address; other mechanisms can also be used. If
there is a way for the signer to communicate to the recipient's system
that it is using a particular mechanism, say through an ADSP record or
other means, the recipient and/or the recipient's system can do further
processing of the message for whitelisting or enhanced display. As an
end user, I'd like to know if the signing system says it's signing the
message on behalf of Aunt Tillie or Uncle George.
Also, in your new version, you write:
8. RFC4871 Section 2.11 Identity Assessor
Original Text:
(None. Additional text.)
Corrected Text:
The name of the module that consumes DKIM's primary payload, the
responsible Signing Domain Identifier (SDID). It can optionally
consume the User Agent Identifier (UAID) value, if provided to the
module. The conventions and semantics used by a signer to create and
use a specific SDID or UAID are outside the scope of the DKIM Signing
specification, as is any use of those conventions and semantics.
I don't understand what the last third sentence has to do with the other
two. This looks like a cut and paste error.
I agree that SDID should not be listed in that last sentence.
For the UAID, it reinforces the notion that the semantics of the UAID is
opaque per the base spec, and that you need to use knowledge from
outside of the base spec in order to do anything meaningful with the UAID.
Tony Hansen
tony(_at_)att(_dot_)com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html