Subject: Re: [ietf-dkim] dkim-lists draft

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 26 Jul 2010 05:02:50 -0700

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:[email-masked]]
> Sent: Tuesday, June 01, 2010 10:54 AM
> To: Murray S. Kucherawy
> Cc: [email-masked]
> 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