4. DKIM Function ... DKIM has a very constrained set of capabilities, primarily targeting email while it is in transit from an author to a set of recipients. It associates verifiable information with a message, especially a responsible identity. [When a message does not have a valid signature associated with the author, DKIM SP will permit the domain name of the author to be used for obtaining information about their signing practices.]
4.5. Sub-Domain Assessment ... To permit assessments that are independent, one method is for an organization to use different sub-domains in the "d=" parameter, such as "transaction.example.com" versus "newsletter.example.com", or "productA.example.com" versus "productB.example.com". [These can be entirely separate from the rfc2822.From header field domain.] RFC 4871: 3.5. The DKIM-Signature Header Field ... d= The domain of the signing entity (plain-text; REQUIRED). This is the domain that will be queried for the public key. This domain MUST be the same as or a parent domain of the "i=" tag (the signing identity, as described below), or it MUST meet the requirements for parent domain signing described in Section 3.8. When presented with a signature that does not meet these requirement, verifiers MUST consider the signature invalid. (Section 3.8 permits signatures by parent domains, but not child.) Add to section 4.5: Use of subdomain signatures may conflict with signing practices based upon the From header field email-address domains. ------ Whenever a subdomain contains the "_domainkey" and key selectors below a domain used by an email address (such as those within the From header field), the signature would not associate with the email- address. The domain holding the key selectors and "_domainkey" subdomains must be either at or above the domain of the email-address referenced by the signature before the signature would apply to that of the email-address. This appears to be in conflict with the statements made in Sections 4.0 and 4.5 of the overview draft. Is section 4.5 attempting to redefine the scope of identities that might associate with that of a signature? It seems there should there be a statement that signing practices will not be applicable in this situation to ensure clarity. (This is not the first time this issue has been mentioned, however it was never discussed.) -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
