Per RFC 4871:
The signature's i= parameter is "expected" to contain on-behalf-of
information:
----
i= Identity of the user or agent (e.g., a mailing list manager) on
behalf of which this message is signed...
...
INFORMATIVE DISCUSSION: This document does not require the value of
the "i=" tag to match the identity in any message header fields.
This definition is fairly useful since it allows signing domains to
provide a reporting token within the i= parameter for verifiers to use
to identify the agent creating a problem. This token can be obscured
and be a transient hash of the account used to access their outbound
servers, for example.
SSP-02:
2.8. Author Signature
An "Author Signature" is any Valid Signature where the identity of
the user or agent on behalf of which the message is signed (listed in
the "i=" tag or its default value from the "d=" tag) matches an
Author Address (From header email-address) in the message.
3.3. SSP Record Syntax
"all" All mail from the domain is signed with an Author Signature.
Translation:
Only signatures on-behalf-of the From header email-address are
considered compliant with an "all" SSP policy. This is in conflict
with RFC 4871. Not all signatures are on-behalf-of the entity
represented by the From header, of course. Essentially, this
necessitates the i= parameter not be used when the identity might
conflict with the identity contained within the From header. The i=
parameter, as the only parameter defined as providing a higher
granularity of the message sources, will no longer be useful in these
cases. How does this help verifiers cope with abuse? It doesn't.
Per RFC 4871, a signature is valid when the signed on-behalf-of
identity, the i= parameter, does not relate to the From header email-
address. However, the SSP-02 definition prevents the i= parameters
from being useful in this role. As a result, in many cases, this
parameter is now unable to identify the actual agent or user who
introduced the message when using an obscured hash of the identity the
agent when it is related to the Resent-From or Sender header.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html