Murray, et al,
I think the Introduction's first paragraph is the best summary of DKIM that's
been written for any of our document's, so far.
Throughout the document, there is a tendency to offer advice without
justification. While I, of course, think the advice is good, the fact that it
is cast as advice means it needs to carry a statement of efficacy. Why do
things this way? Why not do them some other way? Advice requires a context of
tradeoffs.
SUBSTANTIVE
===========
When should an author, or its organization, use DKIM for mail sent
to mailing lists?
The word "should" implies an intent to make a normative statement. This
conflicts with the stated goal of Informational status. So does the distinction
between Normative and Informative references.
Either the goal should be BCP (or even Proposed) or perhaps the language for
this type of statement needs to be softened to something like "Under what
circumstances does..."
My own guess is that this document should target BCP. However on further
reading I came to the conclusion that this might be two documents, one BCP per
its original goal and one Proposed, defining value-added semantics. See below.
What are the tradeoffs regarding having an MLM verify and use DKIM
identifiers?
This might not need "fixing" but I found myself asking what it means for an MLM
to "use DKIM identifiers"? Perhaps in an Introduction it's ok to say this
without prior setup. Dunno.
Of the four bullets, aren't the latter three the details for the first one?
Terminology
This is a philosophical question: Given a document making normative statements,
aren't the definitions upon which it bases those statements themselves
normative? How can foundational language for normative statements not, itself,
be normative?
2.4. Message Streams
The concept of streams is discussed in the Deployment doc (RFC 5863):
<http://tools.ietf.org/html/rfc5863>
and the DKIM Wikipedia article:
<http://en.wikipedia.org/wiki/DomainKeys_Identified_Mail>
I suggest citing them. We should make sure this doc conforms to their
definition of explains its variation.
By my reading, your text does conform, but your definitional sentence probably
offers a more explicit and complete definition than the other docs.
However...
partition
them somehow (most commonly via DNS subdomains, and/or the "d=" tag
value in the context of DKIM)
If the reference to subdomains isn't for d=, then what does it refer to? If it
does mean the d= value, then the sentence wording is a bit confusing.
More conceptually, what way other than d= subdomains is within the scope of the
DKIM signing specification, for distinguishing among streams?
author: The agent that actually constructed the message
I've been finding myself distinguishing between responsibility for content
versus responsibility for initial handling, and using the term "author" for the
former. "Sender" or "originator" seem to refer to the latter. Your use of
Originator seems to match this.
I've gotten diligent about using the word "content" since that seems to be a
magic way to get people to focus on substance rather than matters of form. That
is, it's where "responsibility" gets much more serious.
There reportedly still exist a few scattered mailing lists in
operation that are actually run manually by a human list manager.
This sentence hangs there, without a label and without context. What is the
reader to do with it?
3.4. Alternatives of Participation and Conformance
While the content of this section seems useful, it doesn't really discuss either
of these as "alternatives". In fact, I initially thought the title meant them
as alternatives to each other! Only by reading later sections did it occur to
me that you meant each to have a "non-" form offered as the alternative.
As DKIM becomes more entrenched, it is highly desirable that MLM
software adopt more DKIM-friendly processing.
It occurs to me that the term "DKIM-friendly" would be far more useful if it
were first defined. I suggest that up in Terminology it be introduced. No
doubt, the details for the term will be subject to some debate. Best conduct
that debate during definition, rather than in the middle of its substantive use...
(It's only used other time, up in Section 1, but my sense is that as a group
we've been using the term more and that it might be worth making it a real
technical term of art.)
considerations (see Section 3.5 of [DKIM]). Its use is therefore
discouraged.
That sounds very much like a SHOULD NOT. Assuming the doc is really going to be
normative, then now's the time to start using the right language.
There is currently no header field proposed for relaying general list
policy details, apart from what [LIST-URLS] already supports. This
sort of information is what is commonly included in appended footer
text or prepended header text. Rather than anticipating or proposing
a new field here for that purpose, the working group recommends
List policy details? Huh?
1) I don't really know what that means
2) I'm not sure why this is being mentioned here
3) Any use of the word "policy" usually works against doing productive work
in these groups.
Seriously. Show me an IETF "policy" specification that's been successful. Show
me a second one.
And "for that purpose"? What purpose? Again, I've missed the context.
Has this morphed into a more general MLM BCP? (I assume this is what the
earlier discussion of such a BCP, sometime back, was about.)
If an author knows that the MLM to which a message is being sent is a
non-participating resending MLM, the author is advised to be cautious
when deciding whether or not to sign the message.
This is the sort of guidance that is comforting to the writer, but has no
practical benefit. Never mind whether an author is ever going to know the
required information. The guidance "be cautious" has no meaning or, at least,
no meaning in a technical specification seeking substance and precision. The
later text, two paragraphs down in the document, acknowledges this problem.
incumbent upon site administrators to consider how support of users
wishing to participate in mailing lists might be accomplished as DKIM
achieves wider adoption.
This text suffers the same problem. Site administrators can't be expected to
have enough knowledge or time "to consider" much about this topic. Rather, this
document should give simple and direct guidance for their choices. Language
like the following "A common suggestion" is exactly what they need an direct,
prescriptive form.
With respect to the guidance being given, there is a gaping hole that is implied
but not cited, although we've already seen it in the wild:
If an organization insists that all mail be signed under the same domain
name that is in the From: header field and it publishes a strict ADSP record,
then it is not possible for mail from that organization to go through a mailing
list. Ever.
Messing with d= is of course irrelevant to this problem.
In general, the
more strict practices and policies are likely to be successful only
for the mail streams subject to the most end-to-end control by the
originating organization. That typically excludes mail going through
MLMs.
And my point is that this language is too soft, modulo debating what "more
strict" means. The document should make a simple statement of the condition and
a simple statement of the result, since I think we understand both.
4.2. Verification Outcomes at Receivers
I think everything said in this section is probably correct, but I am not sure
what it is referring to, within the scope of DKIM. What technical actions do
"Verification Outcomes" refer to?
For example, an MLM might be designed to accomodate a list of
possible signing domains (the "d=" portion of a DKIM signature) for a
given author, and determine at verification time if any of those are
present.
This sounds reasonable, but I'm hard-pressed to believe it's practical.
I think the danger, here, is that listing impractical alternatives gives the
impression of having resolved something that actually remains unresolved.
Per the discussion in [AUTH-RESULTS], there is no a priori reason for
the final receivers to put any faith in the veracity of that header
field when added by the MLM. Thus, the final recipients of the
This is off-topic, but I keep wondering whether there isn't an opportunity for a
value-added function in the form of a header-field, which says something like
"the presence of this header field, when signed by DKIM, means that the contents
cited in this header field are asserted to be 'valid'...
So, for example:
DKIM-Valid: From, Date, Subject, Body
could mean that the signer claims all of that information is "correct", not just
carried correctly. Of course, the signer's DKIM h= also have to cite those
fields, as well as DKIM-Valid.
I think the hard part, here, is deciding whether the signer's d= has any
constraints, and what a receiver might or might not do, depending on who did the
signing.
but as I say, this is off-topic...
A signing MLM is, as any other MLM, free to omit redistribution of a
message from an author if that message was not signed in accordance
with its own local configuration or policy. However, selective
signing is discouraged; essentially that would create two message
streams from the MLM, one signed and one not, which can confuse DKIM-
aware verifiers and receivers.
I don't think I understand what this means. What is "selective signing" and
where is the basis for giving directions about it? This is being used as a term
of art, but I don't think it's been defined and I think that there isn't
community consensus about it. And I'm not sure that anything about it is
dependent upon MLMs.
A recipient that trusts signatures from an MLM may wish to extend
that trust to an [AUTH-RESULTS] header field signed by that MLM. The
"Trust"??? What does that mean, exactly, here? It needs to be defined. Seriously.
Receivers are advised to ignore all unsigned Authentication-Results
header fields.
Oh boy. No doubt this really is good advice, but ultimately it's based on a
value-added semantic that isn't written down anywhere, nevermind "approved"...
Again, I think this document really has two heads -- and possibly three -- and
probably needs to be split into two or three documents. One of them is a BCP
per the original goal. Another the other is a value-added technical
specification for Intermediaries that support DKIM. The third is that generic
MLM doc that folks have been mentioning.
The alternative is to go back and redefine the semantic of a DKIM signature. I
suspect that would cause some existing signers to stop using DKIM, since their
basis for using DKIM entails a much lower level of meaning that is being implied
here.
To be clear, I'm not saying that the value-added semantic is a bad idea. Merely
that it needs to be defined explicitly and, hopefully, in a generic fashion, so
that a receiver does not have to wander all over the header fields trying to
asses assorted interdependencies, before being able to determine what a
signature or a header field means.
Upon DKIM and ADSP evaluation, a receiver may decide to reject a
message during an SMTP session. If this is done, use of an [SMTP]
DKIM and ADSP evaluation are not performed during an SMTP session, unless the
session is delayed after the crlf.crlf, and that's not supposed to happen.
Upon DKIM and ADSP evaluation, a receiver may decide to reject a
message during an SMTP session. If this is done, use of an [SMTP]
Although this is useful text, it isn't in a form that's appropriate for a BCP.
I'm not sure what to suggest.
MLMs are encouraged to apply these or other DKIM failure reporting
mechanisms as a method for providing feedback about issues with DKIM
MLMs SHOULD apply a DKIM failure reporting mechanism, for providing feedback
about...
NITS OR UNCONTROVERSIAL
=======================
to make a claim of responsibility for a message by
affixing a domain-level digital signature to the message
...to make a claim of responsibility by affixing a validated domain-level
identifier to the message...
Although not the only possibility, this is most
commonly done as a message passes through a Mail Transport Agent
(MTA) as it departs an Administrative Mail Domain (ADMD) toward the
general Internet.
Given the short history of DKIM use and the fact that this document will live a
long time, making normative assertions is a bit risky. Perhaps:
One configuration of DKIM use attaches the DKIM signature as a message
passes through a...
Good list. I suggest adding two figures that show a before and after example of
a message, reflecting these modifications.
The above list is not exhaustive, but instead only lists common
modifications. It also does not consider changes the MTA might make
independent of what changes the MLM chooses to apply.
First sentence really is redundant. Perhaps instead:
However note that MLM's vary widely in their behavior, as well as often
allowing subscribers to specify individual treatment. The above list also does
not...
The DKIM specification documents deliberately refrain from the notion
I think the signature doc is the only "DKIM specification document". Singular.
Given how often people say DKIM when they mean ADSP, we'll do better to refer
to them separately. Especially for this statement, since ADSP does not refrain
from the notion...
of tying the signing domain (the "d=" tag in a DKIM signature) to any
This isn't a comment on this draft. It's a broader question: I think I'm
seeing "signing domain" used as the common reference for d=, rather than the
newly-minted SDID term. Does that match other folks' perception?
identifier within a message; any ADMD could sign any message
ADMD could sign any message -> ADMD handling a message can sign it
As such, there is no
specification of any additional value if the content of the "d=" tag
in the DKIM signature and the value of (for example) the RFC5322.From
field match, nor is there any obvious...
Awkward wording. Might not be understood if the reader does not already know
this point. Perhaps:
In particular, DKIM does not define any meaning to the occurrence of a
match between the content of the "d=" tag in the DKIM-Signature: header field
and the value of (for example) a domain name in the RFC5322.