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...
Common modifications include:
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.From field. Nor is
there any obviously...
a DKIM signature added
by an MLM has no more, or less, meaning as a signature with any other
"d=" value.
with -> than
The previous section describes some of the things MLMs commonly do
that are not DKIM-friendly, producing broken signatures and thus
reducing the perceived value of DKIM.
The previous section describes some of the things MLMs commonly do
that produce broken signatures and thus
reduce the perceived value of DKIM.
MLM behaviors are well-established and standards compliant.
The preceding paragraph appears to (correctly) contradict this assertion. I
suggest deleting this sentence and merging the next sentence to the end of the
preceding paragraph (possibly with slight massaging.)
An MLM is an autonomous agent that takes delivery of a message
delivered to it and can re-post it as a new message (or construct a
digest of it along with other messages)
delivered to it -> [delete]
drop the parens; the surrounded text is integral.
is some idea of how such a
signature might be applied by an recipient's evaluation
is some idea of -> [delete]
an -> a
and if so,
if so??? i got lost in this reference and suspect the sentence need a bit
of
simplification.
Note that where in this document there is discussion of an MLM
conducting validation of DKIM signatures or ADSP policies, the actual
implementation could be one where the validation is done by the MTA
or an agent attached to it, and the results of that work are relayed
by a trusted channel not specified here.
ditto.
An FBL reporting address
-> An address to which FBL reports are sent
{ This isn't just quibbling; a reader might not know what the current
reference means. They might think it means an address that a sender reports
to...}
not actionable and thus undesirable.
and thus is undesirable
An attempt
has been made to prefer imposing changes to behaviour at the signer
and verifier rather than at the MLM.
{ I suspect that attempt is to satisfy the preference rather than to have
the preference... }
An attempt... changes to
->
In general the document shows a preference for imposing changes to...
Readers are encouraged to become familiar with [DKIM] and [ADSP]
which are standards-track protocol documents as well as
which are standards-track protocol documents
->
which are core specification documents,
In the remainder of this document we distinguish Two relevant steps,
corresponding to the following SMTP transactions:
MLM Input:
...
MLM Output:
This begs for a diagram.
Much of this document focuses on the resending MLM
the resending class of MLM
3.3. Current MLM Effects On Signatures
Nice section.
Other header fields:
...
If these fields were included in the original
message, it is possible that one or more of them may have been
signed, and this could cause a concern for MLMs that add or
replace them.
I think your politeness gets in the way of clarity: If they were part of a
signature calculation and they are changed, the signature is simply and utterly
broken. No?
I think the issue is distinguishing "problem" from "broken" in the document.
The latter is a binary condition. I'm not sure what qualifies for the former,
other than breakage, but I suggest calling breakage breakage, so the reader has
no room for misunderstanding.
MIME part removal:
For diligence, the text should note that this breaks a sig.
reconstruct the original message as it appeared at time of signing
at the time of
and thus whether or not an author signature is actually valid after
seems to be missing a word. maybe the verb. can't tell what the context for
the 'whether or not' is.
MLM rewriting. Moreover, even if an MLM currently passes messages
unmodified such that author signatures validate, it is possible that
a configuration change or software upgrade to that MLM will cause
that no longer to be true.
Perhaps I'm not reading this properly, but I can't seem to connect the Moreover
sentence to the preceding sentence. I suspect this, too, needs some more
context.
the note about "h=" in Section 3.5 of [DKIM]). The shortest path to
success for DKIM would be to mandate that all MLM software be re-
designed or re-configured with that goal in mind.
Perhaps the text should demure a bit, by adding "Were it likely to to be widely
adopted, the shortest path..."
to bound the portion of the body covered by the body hash, but this
not workable for [MIME] messages and moreover has security
but this is not
messages; moreover it has
A receiver's ADMD would have to have some way to register such non-
participating lists to exempt them from the filtering described in
The 'such' has no referrent. Just delete the word.
[ADSP] presents an additional challenge. Per that specification,
when a message is unsigned or the signature can no longer be
verified, the verifier must discard the message. There is no
There is no "must discard" in ADSP. In any event, I thought the 'request' to
discard applies only to the more strict setting of discard.
the message. Furthermore, authors whose ADSP is published as
"discardable" are advised not to send mail to MLMs as it is likely to
be rejected by ADSP-aware recipients. (This is discussed further in
Section 5.4 below.)
Since this is advice to signers, it should be in the earlier sub-section.
Of course, such a policy could be applied after subscription, so this
is not a universal solution. An MLM implementation could do periodic
checks of its subscribers and issue warnings where such a policy is
detected.
Concerning ADSP enforcement, the simple form of this is to check for every
submission and possibly even reject at submission time if the later receipt
will
be rejected.
It can require that messages using a given
RFC5322.From address also have a DKIM signature with a corresponding
"d=" domain. (Note, however, that it is entirely reasonable for an
It occurs to me that this model is a variant of the FBL registration model...
However as implied by the reference to ADSP, an implication is not being able
to
submit mail that is posted through alternative ADMD MTAs. This should be noted.
This suggestion can be made more general. Mail that is of a
transactional or generally end-to-end nature, and not likely to be
This sounds interesting, but I don't really know what "end-to-end" means, here.
different mail stream than a stream that serves a broader purpose.
broader purpose? perhaps "more varied uses"?
Although it is a common and intuitive conclusion, however, not all
however -> [deleted]
As is typical with DKIM signing, the MLM signature must be generated
only after all modifications the MLM wishes to apply have been
completed. Failing to do so generates a signature that can not be
"Typical" DKIM signing doesn't involve an MLM. I think the meaning here is
something like:
As is typical with DKIM signing, the MLM signature MUST be generated
immediately prior to sending, and after all other processing has been completed.
A signing MLM is advised to add a List-Post: header field (see
[LIST-URLS]) using a DNS domain matching what will be used in the
"d=" tag of the DKIM signature it will add to the new message. This
could be used by verifiers or receivers to identify the DKIM
signature that was added by the MLM. This is not required, however;
This advice is predictable, understandable, and wrong. It declares a linkage
that DKIM explicitly does not assert -- and in fact this draft earlier notes
that it does not.
There are some different directions that changes to this text might reasonably
go. I'm not sure what I'd recommend.
This section also appears to suggest hashing on a series of header-fields based
on a belief that the DKIM header hash is "protecting" or "validating" those
header fields. It doesn't do that.
At its core, I believe this line of specification is attempting to creates a
value-added meaning of a DKIM signature for an MLM. That seems an entirely
worthy goal, but it's a new goal and requires new specification, including some
flag that declares the additional semantic.
A DKIM-aware resending MLM is encouraged to sign the entire message
as it arrived (i.e. the "MLM Input" from Section 3.2), especially
including the original signatures.
This appears to run contrary to the earlier advice to sign just before
re-posting the message.
Some concern has been expressed about an MLM applying its signature
to unsigned mail, which some verifiers or receivers might interpret
as conferring more authority to the message content. The working
group feels this is no different than present-day lists relaying
traffic and affixing RFC5322.Subject tags or similar, and thus it
doesn't introduce any new concerns.
This isn't written in a final form appropriate to an RFC. I suggest:
One concern is that having an MLM apply its signature to unsigned mail
might
cause some verifiers or receivers to interpret the signature as confirming more
authority to the message content than is defined by DKIM. This is an issue
beyond MLMs and primarily entails receive-side processing outside the scope of
the DKIM specification. However it is worth nothing here. In the case of
MLMs,
the presence of an MLM signature SHOULD be treated as similar to MLM handling
that affixes an RFC5322.Subject tag or similar information. Thus it does not
introduce any new concerns.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html