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 "prospects(_at_)companyA(_dot_)example" 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/i=(_at_)marketing(_dot_)domain(_dot_)example/.
* 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 bob(_at_)company(_dot_)example, 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 bob(_at_)subdomain(_dot_)company(_dot_)example, 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/i=(_at_)clienta(_dot_)espa(_dot_)example/.
* 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
joe(_at_)companya(_dot_)example(_dot_) Joe also has an ISP-1 account
joe(_at_)isp1(_dot_)example(_dot_)com, and he uses ISP-1's multiple address
feature to
attach his work email joe(_at_)companya(_dot_)example to his ISP-1 account.
When Joe sends email from his ISP-1 account and uses
joe(_at_)companya(_dot_)example 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