On 01/Jun/10 09:59, Murray S. Kucherawy wrote:
Finally, a question: So that an MLM can proudly exclaim "We are RFCxxxx
compliant!" and have it be meaningful, should this document seek the status
of a BCP, or is Informational sufficient?
IMHO, a BCP is appealing, but more challenging. The draft already
contains several explanation that are relevant independently of DKIM.
Some of these, in particular section 3.2 (see below), should be
improved so as to become generically acceptable. For a BCP, I would
change the title to "Mailing Lists And DKIM", "Mailing Lists Using
DKIM", or similar.
Perhaps, in case the I-D will provide a production rule for subject
tags, it may be worth considering it a proposed standard.
Now then:
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.
At any rate, unless someone finds them helpful, I think those
difficult considerations could be omitted, referencing RFC 5672
instead. One difficulty is indeed the apparent contradiction with
[ADSP], where it defines the binding with the exemplified "From"
header field.
----- 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.)
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.)
The third bullet reads:
authoring: An authoring MLM is one that creates the content being
sent as well as initiating its transport, rather than basing it on
one or more messages received earlier. This is a special case of
the MLM paradigm, one which generates its own content and does not
act as an intermediary. Typically replies are not generated, or
if they are, they go to a specific recipient and not back to the
list's full set of recipients. Examples include newsletters and
bulk marketing mail.
As it actually describes several types, it may be more meaningful to
make it the last one. Newsletters and such can also be implemented as
announce-only mailing lists --only subscription policies differ ;-)
For completeness, I also quote the fourth bullet:
digesting: A special case of the re-posting MLM is one that sends a
single message comprising an aggregation of recent MLM submissons,
which might be a message of [MIME] type "multipart/digest" (see
[MIME-TYPES]). This is obviously a new message but it may contain
a sequence of original messages that may themselves have been
DKIM-signed.
If going for BCP or PS, I'd put a subsection-break after these
definitions.
The following paragraph could be reworded, avoiding unnecessary
assumptions, from
The remainder of this document operates on the presumption that a
message going through a resending MLM actually comprises two message
transactions:
to
In the remainder of this document we distinguish two relevant steps,
corresponding to the following [SMTP] message transactions:
Furthermore, I'd name the message content of those two steps, e.g. by
tagging rather than numbering the relevant paragraphs, with names like
"MLM-input" and "MLM-output", so as to make references to them precise.
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.
----- 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.
----- 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.
----- 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.
----- 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.
[...]
2) One possible recommendation to list managers is that if a message to
the list is DKIM signed AND has an ADSP discardable policy AND the
signature cannot be maintained intact then the list should bounce the
message.
We seem to have rough consensus on this point, and it's in the draft.
Not quite: the last paragraph in section 5.4 says
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.
----- 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?
In case we care about the role of the signer, we need a precise
recipe. By comparison, in real life we often have it: e.g. "Treasurer
of the United States" on a dollar bill would not be exactly the same
as "X-Been-There", would it?
Would it make sense to define the subject tag in terms of the local
part in List-Post? (That is, subject-tag = "[" local-part "]".)
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.
----- 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.
----- 5.8
The second paragraph,
Receivers are advised to ignore all unsigned Authentication-Results
header fields.
is obviously formally wrong. (Actually, requiring to validate a
signature in order to use the A-R field defeats its own purpose, but
this is OT here.) 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.
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.
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. 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.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html