This is the last feedback I need to massage into the draft before posting an
update, which I hope to do before the WG meeting on Wednesday. Thanks to all
those that provided input.
-----Original Message-----
From: Alessandro Vesely [mailto:vesely(_at_)tana(_dot_)it]
Sent: Tuesday, June 01, 2010 10:54 AM
To: Murray S. Kucherawy
Cc: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] dkim-lists draft
I have a few points, ordered by section number. Don't be scared by the
length, most text is quoted from the I-D, for readers convenience.
----- 1.1
The last paragraph in section 1.1 looks redundant to me.
The DKIM specification documents deliberately refrain from the notion
of tying the signing domain (the "d=" tag in a DKIM signature) to any
identifier within a message; any ADMD could sign any message
regardless of its origin or author domain. 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 From header
field match, nor is there any obvious degraded value to a signature
where they do not match. Since any DKIM signature is merely an
assertion of "some" responsibility by an ADMD, a DKIM signature added
by an MLM has no more, or less, meaning as a signature with any other
"d=" value.
It looks redundant because the semantic intentions of DKIM are already
discussed at length in the paragraphs about SDID, AUID and their
relationships, in RFC 5672. The latter is currently not a normative
reference; however, [DKIM] is: I'd be curious whether the "Updated by:
5672" in [DKIM] formally makes RFC 5672 normative, as if explicitly
referenced in the I-D.
I think the language of RFC5672 does not make it clear that there is no
relationship between "d=" and RFC5322.From in basic DKIM. It's important to be
explicit about that here when (a) some existing code, MLM or otherwise, is
already trying to make that distinction, and (b) we do hint at such a
connection being possibly useful when talking about authenticating mail from
subscribers.
Any comments from others?
----- 3.2
In section 3.2, "Types Of Mailing Lists Lists" there is a possible
typo in the title.
The first bullet reads:
aliasing: An aliasing MLM (see Section 5.1 of [EMAIL-ARCH]) is one
that makes no changes to a message as it redistributes; any
modifications are constrained to changes to the [SMTP] envelope
recipient list (RCPT commands) only. There are no changes to the
message body at all and only [MAIL] trace header fields are added.
The output of such an MLM is considered to be a continuation of
the author's original message. An example of such an MLM is a
address that expands directly in the MTA, such as a list of local
system administrators used for relaying operational or other
internal-only messages.
I would the phrase "at all", because the MTA may modify the MIME
layout of the message with no control by the MLM software. I'd mention
this possibility in the next section ("Major body changes" below.)
We're talking specifically about what the MLM does. This is stated in the
"Scope and Goals" section.
I will add a sentence elsewhere in the document, though, that mentions the MTA
might make changes independent of the MLM.
The second bullet reads:
resending: A resending MLM (see Sections 5.2 and 5.3 of
[EMAIL-ARCH]) is one that may make changes to a message. The
output of such an MLM is considered to be a new message; delivery
of the original has been completed prior to distribution of the
re-posted message. Such messages are often re-formatted, such as
with list-specific header fields or other properties, to
facilitate discussion among list subscribers.
Section 5.2 of [EMAIL-ARCH] is for ReSender. Do we need it? In
addition, I'd rename the bullet as something like "traditional" or
"lists proper", that conveys that this is the main character. Finally
for this bullet, section 3.9.2 of [SMTP] does not consider list
messages to be "new messages" (more on this below.)
I think any type of MLM could lay claim to terms like "traditional", so that's
perhaps not the nest choice here.
As I read 3.9.2 of SMTP, I think everything it discusses there is a change to
the envelope only. What we're defining here is one that does that but also
alters the message. 3.9.2 does apply to what we're calling an "aliasing" MLM,
so I'll add a reference to it there.
Now for the last paragraph in section 3.2:
The dissection of the overall MLM operation into these two distinct
steps allows the DKIM-specific issues with respect to MLMs to be
isolated and handled in a logical way. The main issue is that the
repackaging and reposting of a message by an MLM is actually the
construction of a completely new message, and as such the MLM is
introducing new content into the email ecosystem, consuming the
author's copy of the message and creating its own. When considered
in this way, the dual role of the MLM and its ADMD becomes clear.
I tend to associate "new message" to a new Message-ID. Only the last
two types actually do that. I think you mean that a MLM reinjects the
/same/ content into a different "message stream". The latter concept
is also used in RFC 5863, which omits a formal definition, though.
As I read 3.6.4 of RFC5322, and also 3.4.1 of RFC5598, any body change should
provoke the generation of a new Message-ID. I don't think we need to get into
that in this document, because it's not DKIM specific, other than perhaps
providing those two references.
----- 3.4
The last paragraph in section 3.4 reads:
A possible mitigation to this incompatibility is use of the "l=" tag
to bound the portion of the body covered by the body hash, but this
not workable for [MIME] messages and moreover has security
considerations (see Section 3.5 of [DKIM]). Its use is therefore
discouraged.
I would omit the last sentence. In facts, the warning in section 3.5
of [DKIM] says that "l=" has been designed exactly for this purpose.
Discouraging it, is a withdrawal of that statement.
I'm happy to go with consensus on this one, but I would also say an
informational document is free to provide advice based on experience acquired
since the base specification was published. Thus my vote is to leave it in.
----- 4.2
The last paragraph of section 4.2 reads:
Note that the underlying problem is the operational choice to use
ADSP in a message stream that does not maintain the signature.
The verb "use" is correct for subscribers, "allow" for MLMs. I'd
s/use/allow or use/, since the I-D is not specifically targeted to
subscribers. I'd also make explicit that _one_ subscriber using ADSP
results in _all_ subscribers having to whitelist the MLM sender.
The comment is specifically about subscriber use of it. ADSP is optional for
both ends, but it's the subscriber's misuse of it that causes the problem.
I think that section has been rewritten anyway.
----- 5.1
I agree with sending the ADSP-warning. Readers should be advised that
"dkim=discard" may be set at any time after subscription, though.
Added.
----- 5.4
Bullet 1, at the beginning of section 5.4, says
1. Attempt verification of all DKIM signatures present on the
message;
That is an operation that a MLM may want to do again after modifying
the message, in order to check whether any signature has been broken.
I'd add "MLM-input" to that bullet, to improve clarity.
True on both counts; updated.
It is the consensus of the working group
that a resending MLM is advised to reject outright any mail from an
author whose domain posts such a policy as it is likely to be
rejected by any ADSP-aware recipients, and might also be well advised
to present a warning to such subscribers when first signing up to the
list.
Mike didn't mention likelihoods. His text, quoted above, makes a more
precise point.
But is that an important distinction to make? Re-evaluating signatures can be
an expensive proposition, and it's not necessary if a list decides it's going
to change Subject: and most authors sign Subject: fields.
----- 5.5
The second paragragraph in section 5.5 reads:
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.
Partly agreed. Although it may not be available for "authoring" lists,
List-Post is less ambiguous than List-ID, since it makes explicit
which is the local part. But why not use the whole local part ("i=")?
What if an author has a mailbox within the same domain? Although
header.b allows to distinguish them, how does one know which one is
the MLM signature, or that there is a MLM signature at all?
We're talking about making a binding again, and this time to an unverifiable
field. We could suggest that since this is an informative document, but it's
dangerous territory.
Now for the paragraph after the bullets. It says
A DKIM-aware resending MLM is encouraged to sign the entire message
as it arrived, especially including the original signatures.
The "as it arrived" part is unclear to me, and I'd suggest using
MLM-input/MLM-output as appropriate.
Done.
----- 5.7
Section 5.7, Use With FBLs.
I like this a lot, bravo!! To clarify it even further, I'd add a note
mentioning that controlling FBL routes is one of the reasons to remove
author signatures. It may shred additional light to mention that it is
up the MLM's domain to define FBLs policies. As long as subscribers
are informed about what happens when they hit that button, anything is
cool. For example, one list may equate complaints to unsubscribe
requests, while another one may use them for reporting OT messages.
I don't think I see what you're trying to say here. Can you propose some
specific text?
I'm not sure getting into FBL definitions or policies, other than what's
already in Section 1.3, is necessarily a good thing to tackle in this document.
How about this? (pardon the XML):
<t> Use of FBLs in this way should be made explicit
to list subscribers. For example, if it is the
policy of the MLM's ADMD to handle an FBL item
by unsubscribing the user that was the apparent
sender of the offending message, advising
subscribers of this in advance would help to avoid
surprises later. </t>
----- 5.8
The second paragraph,
Receivers are advised to ignore all unsigned Authentication-Results
header fields.
is obviously formally wrong.
Why?
(Actually, requiring to validate a
signature in order to use the A-R field defeats its own purpose, but
this is OT here.)
We're talking about receivers here, and earlier in the document there's advice
to the MLM to add an A-R header field and then sign it. I don't see how this
is inconsistent.
I agree with John on this point, that determining
the prior validity of an author signature at this stage is only
relevant for forensic analysis and similar tasks. I'd omit that
paragraph tout-court, as it is hard to explain to someone who hasn't
read [AUTH-RESULTS], and useless otherwise.
But [AUTH-RESULTS] is a normative reference, so I think it's reasonable to
presume the reader is at least somewhat familiar with it.
There are some DKIM implementations that do want the ability to see what the
MLM saw as part of its evaluation, and are willing to settle for an expression
of authentication results from an MLM that it explicitly trusts.
The last paragraph I'm commenting is the next:
Upon DKIM and ADSP evaluation, a receiver may decide to reject a
message during an SMTP session. If this is done, use of [ENHANCED]
is advised to make a distinction between messages rejected
deliberately due to policy decisions rather than those rejected
because of other deliverability issues. In particular, a policy
rejection is advised to be relayed using a 5.7.1 enhanced status
code, in contrast to a code of 5.1.1 indicating the user does not
exist. Those MLMs that attempt to automatically remove users with
prolonged delivery problems (such as account deletion) will thus be
able to tell the difference between policy rejection and delivery
failures, and act accordingly. Where the receiver's MTA does not
support enhanced status codes, [SMTP] reply codes could also be
carefully selected (554 and 550, respectively, for example).
I've already written on its merit in
http://mipassoc.org/pipermail/ietf-dkim/2010q2/013561.html so I limit
this comment to the reply definition. First of all, it is yet another
reason for BCP/PS rather than informative: We are actually augmenting
ADSP here, and the I-D deserves an updates="5617" attribute for this.
I don't agree that this changes ADSP, but rather just gives (non-normative)
advice about how to handle it in this scenario.
The definitions of the meanings of SMTP reply codes should be given
independently of the advice on what MLMs can do with them, possibly in
their own subsection. I'd mention [SMTP] codes before [ENHANCED] ones.
Registering the enhanced status code will affect section 6.
There's no new code being added here; 5.7.1 (and actually 5.7.2, which is what
the updated version uses) are both already published in [ENHANCED].
Requiring
a substring match at the beginning of the human-readable part of the
reply, e.g. "ADSP failure", at least for servers advertising no
ENHANCEDSTATUSCODES, may increase robustness.
That sounds reasonable to me.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html