Here're my editorial comments on the rest of -09.
Again, almost all of these are ok to take or leave, as the
authors see fit.
Stephen.
#1 Section 2.1, 2nd sentence: "One point of..., or to..." reads like two points
so maybe change to "Attackers can leverage..." In the same sentence maybe
s/"cousin" name/"cousin" domain name/
#2 Section 2.1, s/As such, DKIM performs/As such, a DKIM signature performs/
#3 Section 2.1, s/becomes a later step of assesment/is a question for later
stages of assessment/
#4 Section 2.2, 1st para, s/formulates this quality assesssment/makes this
assessment/
#5 Section 2.2, 2nd para, suggest changing 1st sentence to: "DKIM provides
additional information for this process by associating a verified "responsible"
identity with the message, that the engine can use as part of its quality
assessment."
#6 Section 3, Suggest changing intro to: "This section describes the functional
and operations goals that motivated the design of the DKIM authentication
service." (Current text reads oddly, esp. 2nd sentence.)
#7 Section 3.1.1, s/seeks/is designed to provide/ and s/Internet service
construct/construct/ and s/the signing key record/a signing key record (defined
by DKIM)/ and s/potential privacy issues/fewer privacy issues/
#8 Section 3.1.1 suggest changing 2nd para to "In contrast, OpenPGP and S/MIME
associate signatures with specific email addresses."
#9 Section 3.1.2 suggest chaning to "Any party, anywhere along the transit path
can implement DKIM signing, and any subsequent party on the transit path can
verify DKIM signatures. DKIM's use is not confined to end systems nor boundary
MTAs."
#10, Secction 3.1.4: this is a critical point to make but the current text
seems very unclear to me. Suggest something like "A DKIM signature only means
that the signer is asserting (some) responsibility for the message -
essentially the signer is declaring (via the signature) that they are
associated with the message, and nothing more. While other services can build
on thie assertion, DKIM by itself says nothing about e.g. whether the From:
header field's domain is associated with the signer, though of course that will
frequently be the case."
#11, Section 3.1.3 s/who authored it/that authored the message/
#12, Section 3.2.1, 1st sentence refers to a requirement for transparency but
that's (now) in 3.2.2. Suggest deleting that clause. Suggest rewording this
paragraph to "A DKIM verifier must treat a message with a signature that fails
verification exactly as if the message had been unsigned. It is important to
note this difference between DKIM and most other digital signatures based
authentication mechanisms." Suggest changing second paragraph to "In contrast,
for OpenPGP and S/MIME a signature verification failure is treated as an error
in message processing, and generally triggers some error handler, for example,
altering the display of the message in an MUA."
#13 Section 3.2.3 is very "sales" oriented text, and feels a bit out of place.
I think the main valid point to make here is that DKIM is useful even if not
ubiquitously deployed. So mabe change the entire section to one paragraph
like: "DKIM can provide significant value even with highly restricted
deployment. For example, in a situation where a domain has a lot of "bogus"
mail that purports to be from that doain but is not, then DKIM signing the
messages that actually are sourced by the domain can allow receivers (that
implement DKIM verification) to improve their processing of messages that
purport to come from the domain in question. One commonly suggested improvement
is to "dial-down" the level of resource devoted to assessment of messages with
valid signatures, perhaps by skipping some anti-abuse processing steps (which
can be CPU intensive)."
#14 Section 3.2.4: I think the first 3 sentences could be deleted, which'd mean
starting from "In order to allow..."
#15 Section 3.2.5: Title: s/Permit wide/Permit a wide/ Also I don't really get
the last sentence, maybe a couple of examples might help (or reference such if
they're elsewhere in the document).
#16 Section 4.1, 1st para: s/records/inserts/ and maybe s/queries/queries (if
necessary)/
#17 Section 4.1, 3rd para: maybe delete the "(by using s=)" - most of the text
doesn't go to that level of detail and its probably not needed here.
#18 Section 4.3, as in #17 this might be better if specific mention of the DKIM
fields (d= & i=) was omitted. (I guess if the reader of this isn't likely to
read rfc4871 then they may get confused by this level of detail.)
#19 Section 4.4: this is the only time the term "attest" is used, maybe it'd be
better not to do that, if so, perhaps s/attested to/signed/ (though that'd
maybe read a bit oddly)
#20 Section 5, intro: s/The DKIM service is divided into components that are
performed using/The DKIM service can be split into components that use/
#21 Section 5, "The MDA" s/If the signature passes/If the signature verifies/
#22 Section 5, "Note" Is the term non-author right here? Maybe 3rd-party is
easier to understand?
#23 Section 5.1, s/public\/private (asymmetric) key/public\/private key
(asymmetric)/ i.e. move the word "key" to before the brackets.
#24 Section 5.1, if its not too big a change I think it might be worth
splitting the "Key Store" into private and public. The logic being that we do
specify a standard for the public key store, but not for the private key store.
I can offer text if you want it.
#25 Section 5.1, "Key Store" I'm not clear about what's meant by a policy for
public key distribution, does it mean where in the DNS to put keys or what
selectors to use? As written it could be read to imply that there's some kind
of need to control access to the public keys.
#26 Section 5.1, "Signing Practices" s/there is an the/there is the/ In the
same sentence is "any organizational practices" right? Maybe "mail
organisational practices" would be better?
#27 Section 5.1, "Signing Practices" is "to be discarded" too strong? Maybe "or
whether the domain are happy for such mail to be discarded..."
#28 Section 5.2, worth noting that while an MUA can sign, that that's uncommon?
#29 Secction 5.4, suggest deleting the 1st sentence.
#30 Section 5.5 - I like "soup of rules" :-)
#31 Section 5.6 s/Mediator/mediator/ Actually I see its defined in App A,
so maybe add a fwd ref.
#32 Appendix A - do all Mediators leave the From: header field intact?
If not, maybe add "typically" before retaining.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html