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
