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