The IESG wrote: > The IESG has received a request from the Domain Keys Identified Mail WG > (dkim) to consider the following document: > > - 'DomainKeys Identified Mail (DKIM) Development, Deployment and > Operations ' > <draft-ietf-dkim-deployment-09.txt> as an Informational RFC
I have some minor comments and nits, as follows: * In sect. 2.4, the last but one paragraph discusses the relation between the RFC5322.From domain part and the d= signature tag. Perhaps a forward reference to Section 7.3 may be helpful. * In sect. 2.3, a paragraph says The challenge in using additional layers of sub-domains is whether the extra granularity will be useful for the assessor. In fact, potentially excessive levels invite ambiguity: if the assessor does not take advantage of the added granularity, then what granularity will it use? That ambiguity would move the use of DKIM back to the realm of heuristics, rather than the deterministic processing that is its goal. The rhetorical question it puts is not clear until one reads the following sect. 4.3. I would suggest to replace it with a plainer explanation, such as "because assessors might unilaterally decide to only use some rightmost part of the identifier." * I'm unable to understand sect. 3.4 "Third Party Signer Key Management and Selector Administration". It probably means that messages are addressed to "[email protected]" so that the MSA skips signing them, and signatures will be added by the exploding MTA. However, it might also mean that messages are already signed on submission. * Sect 3.5, 1st par, s/a public key pair/an asymmetric key pair/. * In sect. 3.5.2, bullet 4.3, I'd s/empty "p=" field/empty public-key data ("p=") field/. * Sect. 4.2 says "The signing module uses the appropriate private key to create one or more signatures." Adding "(see Section 6.5)" may help; however, sect. 6.5 doesn't specify when signatures can be produced using the same key. Or did that mean a DomainKey-Signature? * Also in sect. 4.2, in "key information SHOULD NOT be hard-coded into software", I've been doltishly wondering whether a hard coded path name such as /etc/dkim.key would be considered "key information". "Key data" (the numeric value of a key) should be less ambiguous, or are those terms used interchangeably? * Sect. 5.4 references "external reputation or accreditation services" without giving any examples. Isn't it worth to mention RFC5518? * Sect. 6.2 s/i=marketing.domain.example/[email protected]/. * Also in sect. 6.2, perhaps it is worth to note that parent domain signatures are not considered author signatures, e.g. adding "See also Section 7.3.2". * In sect. 6.4, the last but one paragraph discusses third party signatures, but it misses an example. Mentioning that the signature would use "s=benefits; d=companyA.example" would make it more easily comparable with the paragraph that follows. * Sect. 6.5 doesn't mention changing algorithms, as described in A.2, A.3. * Sections 7.3.2 and 7.3.3 contain very similar text: For example, if the address in the RFC5322.From is [email protected], the SDID value of the author signature must be company.example. and For example, email with an RFC5322.From address of bob@ companyA.example MUST have an author signature where the SDID value is "companyA.example" or it will fail an ADSP validation. In addition, that example is not overly explicative. A variation might say, e.g. For example, if the address in the RFC5322.From is [email protected], the SDID value of the author signature must be subdomain.company.example, not the parent domain. * (In sect. 7.3.3 "Appendix A" and "Appendix B" in the last but one paragraph get the wrong HTML link, internal to the same document. Can that be avoided?) * Sect. 7.5 s/i=clienta.espa.example/[email protected]/. * In sect. 8.1, the paragraph quoted below mentions "multiple address" as a feature of both ISPs and mail clients. Probably it is enough to s/mail clients/ISPs/, since mail client features are not relevant here. However, an ISP may just allow any RFC5322.From address (omit checking) or sign messages according to the address they use (possibly featuring 3rd party signing), and the point that distinguishes ISP-1 from "some other ISPs" is not made. For example, assume Joe works for Company A and has an email address [email protected]. Joe also has an ISP-1 account [email protected], and he uses ISP-1's multiple address feature to attach his work email [email protected] to his ISP-1 account. When Joe sends email from his ISP-1 account and uses [email protected] as his designated RFC5322.From address, that email cannot have a signature with d=companya.example because the ISP-1 servers have no access to Company A's private key. In ISP-1's case it will have an ISP-1 signature, but for some other mail clients offering the same multiple address feature there may be no signature at all on the message. _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
