Thanks for the thorough review. I've only replied below to stuff that warrants
more than an "OK" or other indication of agreement.
> 2.3. 'DKIM-Friendly'
>
> The term "DKIM-Friendly" is used to describe an email
intermediary
> that, when handling a message, makes no changes to that message
which
> cause valid [DKIM] signatures present on the message on input to
fail
> to verify on output.
>
> Various features of MTAs and MLMs seen as helpful to users often
have
> side effects that do render DKIM signatures unverifiable. These
> would not qualify for this label.
{{ stray thought: since the real concern is breakage, wouldn't it make
sense to
focus on DKIM-Hostile, rather than DKIM-Friendly? Friendly largely
means being
passive. }}
How about "DKIM-Cooperative"?
(Largely because flipping the logic throughout the work might be a lot of
work...)
> 3. Mailing Lists and DKIM
>
> It is important to make some distinctions among different MLM- like
> agents, their typical implementations, and the impacts they have in a
MLM-like agents -> intermediaries.
{{ what does 'MLM-like' mean? }}
Specifically, intermediaries that mess with the envelope, typically changing
one recipient to many, and possibly altering the content.
> DKIM-aware environment.
>
> 3.1. Roles and Realities
>
> In DKIM parlance, there are several key roles in the transit of a
In DKIM parlance, -> Across DKIM activities,
{{ generic flag is raised: having this document repeat definitions from other
documents invites divergence. }}
> message. Most of these are defined in [EMAIL-ARCH].
>
> author: The agent that provided the content of the message being
> sent through the system, and performed the initial submission.
{{ And indeed, here's an example of divergence. In email-arch, the author
does
not (necessarily) perform submission. Submission is performed by the
Originator, in email-arch... }}
How does content get from an author to an originator? Or are they typically
the same agent?
Is it sufficient to change "performed" to "handed it to the originator to begin
its travel to its destination(s)"?
> This can be a human using an MUA or a common system utility such
> as "cron", etc.
>
> originator: The agent that accepts a message from the author,
> ensures it conforms to the relevant standards such as [MAIL], and
> then relays it toward its destination(s). This is often referred
> to as the Mail Submission Agent (MSA).
{{ "relays it towards its destinations" is more like the definition of a...
relay. }}
So change "relays" to "sends" or "routes"?
> receiver: The agent that is the final transit relay for the message
> prior to being delivered to the recipient(s) of the message.
> Filtering decisions based on results made by the verifier could be
> applied by the receiver. The verifier and the receiver could be
> the same agent.
{{ email-arch: "2.2.4. Receiver The Receiver performs final delivery" }}
Those read the same to me. Are you proposing a change here?
> Minor body changes: Some lists prepend or append a few lines to each
> message to remind subscribers of an administrative URL for
> subscription issues, or of list policy, etc. Changes to the body
> will alter the body hash computed at the DKIM verifier, so these
> will render any existing signatures that cover those portions of
> the message body unverifiable.
{{ I'd have thought that citing the l= capability here would be appropriate,
for
completeness. }}
I think it was there in earlier versions but was removed because the WG
generally dislikes use of "l=" for the reasons specified in the base document.
It also only handles appended text, but not prepended text, for example.
> 4.1. Author-Related Signing
>
> If an author knows that the MLM to which a message is being sent is a
> non-participating resending MLM, the author SHOULD be cautious when
> deciding whether or not to send to the list when that mail would be
{{ I don't know what to suggest, but this section presumes that we can
reasonably expect authors to know about DKIM issues and in particular to know
that some MLMs screw up signatures. But we already know that virtually no
author is aware of any of these issues, nevermind know what it means to be
'cautious'. Mumble. }}
Later on in Section 4.1, there's this:
However, all of this presupposes a level of infrastructure
understanding that is not expected to be common. Thus, it will be
incumbent upon site administrators to consider how support of users
wishing to participate in mailing lists might be accomplished as DKIM
achieves wider adoption.
> 4.4. Wrapping A Non-Participating MLM
>
> One approach to adding DKIM support to an otherwise non- participating
to adding -> for adding
> MLM is to "wrap" it, or in essence place it between other DKIM- aware
{{ it?? what is the referrent? }}
The non-participating MLM. So s/it/the MLM/
> components (such as MTAs) that provide some DKIM services. For
> example, the ADMD operating a non-participating MLM could have a DKIM
> verifier act on submissions, enforcing some of the features and
{{ submissions? isn't this meant to refer to the receive-side of the MLM?
since
'submission' is an email term of art, this reference is confusing. }}
So instead of "submissions", say "messages from list subscribers"?
> 5.1. General
>
> As DKIM becomes more widely deployed, it is highly desirable that MLM
> software adopt more DKIM-friendly processing.
{{ I suggested deleting the above. It doesn't add anything. }}
I think it makes a statement that we (the WG) don't think the onus is on us to
make all the accommodations here.
> Where the above practice is not observed and "discardable" mail
{{ "above practice is not observed"? Sorry but I don't know what that's
referring to. }}
The paragraph preceding proposes MLM interference with subscription actions
from addresses that use an ADSP "discardable".
> arrives via a list to a verifier that applies ADSP checks which fail,
> the message SHOULD either be discarded (i.e. accept the message at
> the [SMTP] level but discard it without delivery) or rejected by
{{ Is this describing anything different than would/should take place for mail
that did NOT go througha list? The text seems to be describing a special case
but in fact it isn't. It's just an ADSP failure. }}
The issue is the one we observed with discardable mail that goes through an
MLM, where the implementation of "discardable" is a 5xx reply. So A and C
subscribe to list B, A posts discardable, A sends to B, B rewrites and relays
while keeping but breaking the signature, C gets it, DKIM fails, ADSP causes
rejection, C gets unsubscribed from B.
So yes, it's just an ADSP failure at verification time, but it has more serious
side-effects when there's an MLM intermediary.
> 5.4. Author-Related Signing
>
> An important consideration is that authors rarely have any direct
> influence over the management of an MLM. As such, a signed message
> from an author will in essence go to a set of unexpected places,
> sometimes coupled with other messages from other sources. In the
> future, as DKIM signature outputs (e.g. the AUID or SDID of
> [DKIM-UPDATE]) are used as inputs to reputation modules, there may be
> a desire to insulate one's reputation from influence by the unknown
> results of sending mail through an MLM. In that case, authors SHOULD
> create a mail stream specifically used for generating signatures when
> sending traffic to MLMs.
"signed message from an author".
{{all messages are from the author. what distinctive condition is this trying
to describe? messages signed with the author domain? I don't understand the
point of the "As such" sentence. The rest of the paragraph is also confusing
to
me. I'm not sure what to suggest to make it clearer. }}
This came from a use case John submitted.
A and C are subscribed to B. A sends to B, which goes to C. But C doesn't
want to be on the list anymore and can't seem to unsubscribe. In frustration,
C begins reporting B traffic as spam, which begins to negatively affect the
reputation of A's signed mail.
> As described, the MLM MAY conduct DKIM verification of a signed
> message to attempt to confirm the identity of the author. Although
{{ Hmmm. This really does go entirely beyond DKIM semantics. Is the text
meaning to imply that any signature validates any From: field? Generally, the
document ought to distinguish between what can/should be done today within
existing specifications, versus what would be enhancements beyond them.
}}
I had thought this was clear, but I can add text to make it so.
There is text early on that says some of the things the document suggests are
just ideas and have no basis in reality yet, but merely illustrate possible
applications based on our experience to date.
> message have no way to verify on their own the authenticity of the
> author's identity on that message. However, if that field is the
{{ huh? "verify their own authenticity"? what exactly does this mean and how
does the DKIM signing spec support it? }}
Not quite what it says. Perhaps some commas would help:
"...message have no way to verify, on their own, the authenticity of the..."
> 5.7. MLM Signatures
>
> DKIM-aware resending MLMs and authoring MLMs SHOULD affix their own
> signatures when distributing messages. The MLM is responsible for
> the alterations it makes to the original messages it is re- sending,
> and should express this via a signature. This is also helpful for
> getting feedback from any FBLs that might be set up so that undesired
> list mail can generate appropriate action.
{{ I thought FBL behavior required prior registration. }}
Usually, but not always, especially with the FBL discovery work MARF is doing.
> DKIM signature it will add to the new message
> verifiers or receivers to identify the DKIM signature that was added
> by the MLM. This is not required, however; it is believed the
{{ this is describing a policy that is otherwise undocumented and undeclared.
If there is an explicit relationship between a d= name and a list-post name,
it
should be declared explicitly, such as with a special header-field defined to
assert the relationship. }}
...or some out of band understanding that that's how this list operates?
This document probably shouldn't also register a new header field just for this
purpose.
> Such MLMs SHOULD ensure the signature's header hash will cover at
> least:
>
> o Any [AUTH-RESULTS] fields added by the MLM;
>
> o Any [LIST-ID] or [LIST-URLS] fields added by the MLM;
>
> o Any [MAIL] fields, especially Sender and Reply-To, added or
> replaced by the MLM.
{{ This implies that there is semantics or security 'protection' in the choice
of header-fields that are hashed. None of this is valid in terms of the
current
DKIM Signing specification. In order to make it valid, there needs to be an
additional specification defining it and specifying how a recipient can know
that the added semantics apply. }}
I think a slight shift in wording might make you happy without changing what
it's saying:
"Such MLMs should generate a signature that takes responsibility for at least
..."
> prepared for distribution (i.e. the "MLM Output" from Section 3.2).
> Any other configuration might generate signatures that cannot be
> expected to validate. As with any other DKIM signing operation, the
{{ "cannot be expected" is odd language to use about verification. either is
will verify or it won't. how can this be statistical, other than later, in
transit vagaries? }}
"will not validate" would work for me too, since "might" is also in there.
> One concern is that having an MLM apply its signature to unsigned
> mail might cause some verifiers or receivers to interpret the
> signature as conferring more authority or authenticity to the message
> content than is defined by [DKIM]. This is an issue beyond MLMs and
> primarily entails receive-side processing outside of the scope of
> [DKIM]. It is nevertheless worth noting here. In the case of MLMs,
> the presence of an MLM signature is best treated as similar to MLM
> handling that affixes an RFC5322.Subject tag or similar information.
> It therefore does not introduce any new concerns.
{{ after re-reading this paragraph a few times, I find I don't know what it is
adding and also the next-to-last sentence confuses me. }}
It acknowledges that there are applications out there that think a DKIM
signature is a good thing regardless of any other piece of information
available. That creates a concern that all mail through a list is potentially,
apparently, endorsed by the list operator. Such interpretations might not be
wise if the verifier doesn't know how the list is actually configured or
filtered.
You're right about the last sentence though.
> 5.9. Use With FBLs
>
> An FBL operator might wish to act on a complaint from a user about a
> posting to a list. Some FBLs could choose to generate feedback
{{ "a complaint from a user about a posting to a list" I think I don't
know what
this means. "a posting"? }}
Bleed-over from Usenet terminology, I suppose. "message" would be fine there.
> Upon DKIM and ADSP evaluation during an SMTP session (a common
> implementation), an agent MAY decide to reject a message during an
> SMTP session. If this is done, use of an [SMTP] failure code not
> normally used for "user unknown" (550) is suggested; 554 seems an
> appropriate candidate and thus SHOULD be used. If the rejecting SMTP
{{ The passive tense of this sentence winds up confusing me. "is
suggested"? by
whom and where? Given that the second part negates it, I now don't
really know
what is done, recommended or what. }}
How about "preferred" or "appropriate"?
-MSK
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html