Re: Last Call: <draft-ietf-dkim-mailinglists-10.txt> (DKIM And Mailing Lists) to BCP

[SM <[e-mail]>]

At 08:02 12-05-2011, The IESG wrote:
>The IESG has received a request from the Domain Keys Identified Mail WG
>(dkim) to consider the following document:
>- 'DKIM And Mailing Lists'
>   <draft-ietf-dkim-mailinglists-10.txt> as a BCP
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action. Please send substantive comments to the
>[e-mail] mailing lists by 2011-05-26. Exceptionally, comments may be

 From Abstract Section:

   "Based on deployment experience with DKIM, this Best Current
    Practices document provides guidance for the use of DKIM
    with scenarios that include Mailing List Managers (MLMs)."

Although one can extrapolate from experience and provide some 
guidance, I would not call it "Best Current Practices".  I suggest a 
change to that sentence:

    Based on deployment experience with DKIM, this document provides
    guidance for the use of DKIM with scenarios that include Mailing
    List Managers (MLMs).

Quoting the Introduction Section:

   "The goal for this document is to explore the use of DKIM for
    scenarios that include intermediaries, and recommend Best
    Current Practices based on acquired experience."

The Intended Status of this document is BCP.  I cannot support a 
recommendation for "Best Current Practices" that is not based on 
existing practices.  If the IETF wants a stick to tell the outside 
world what to do, it can publish this document as a BCP.  If the IETF 
would like to provide guidance, leave it to the outside world to 
adopt that and then document the current practice, it should not 
publish this document as a BCP.

 From Section 2.5:

   "Each of these could have different security policies imposed
    against them, or there might be a desire to insulate one from
    the other (e.g., a marketing campaign that gets reported by
    many spam filters could cause the marketing stream's reputation
    to degrade without automatically punishing the transactional or
    user streams)."

Shouldn't that be sending policies instead of "security 
policies"?  If we go a stretch further, a marketing campaign might 
end up be labelled as a terrorist act and that falls under the Security Area.

I'll translate that paragraph for a wider audience.  Some companies 
send out spam; it keeps businesses happy if it is called a marketing 
campaign.  These companies also send out messages that the receiver 
actually wants to read.  On the receiving side, there is a lot of 
zealotry that goes on.  One way to mitigate the effects of that 
zealotry is to provide the receiver a means to separate the spam from 
other mail.

In Section 3.3:

   "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."

It's funny to see how some MUAs adapted to that by hiding these lines 
thereby rolling back that "fix".

In Section 4.1:

   "In an idealized world, 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 a
    signed message to the list."

The author generally does not have any control over that decision as 
DKIM signing is not done at the MUA level.  The usage of a key word 
is somewhat excessive here as the ideal world is out of scope for RFC 2119.

   "This problem can be compounded if there are receivers that apply
    signing policies (e.g., [ADSP]) and the author publishes any kind
    of strict policy, i.e., a policy that requests that receivers reject
    or otherwise deal severely with non-compliant messages."

The "definition of insanity is doing the same thing over and over and 
expecting different results".   There are parallels between ADSP and SPF.

In Section 5.1:

   "It is RECOMMENDED that periodic, automatic mailings to the list are
    sent to remind subscribers of list policy."

This is currently being done by the IETF under the guise of mailman day.

In Section 5.5:

   "In that case, authors SHOULD create a mail stream
    specifically used for generating signatures when sending traffic to
    MLMs."

I suggest using "DKIM signatures".

   "This suggestion can be made more general."

Shouldn't that be recommendation?

In Section 5.8:

  "DKIM-aware authoring MLMs MUST sign the mail they send according to
   the regular signing guidelines given in [DKIM].

   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."

Removing the MUST and saying:

   DKIM-aware authoring MLMs signs the messages they send according to
   the regular signing guidelines given in [DKIM]

gives more weight to the last two paragraphs, especially with the 
note about the concern.

In Section 5.10:

   "An FBL operator might wish to act on a complaint from a user about a
    message sent to a list."

Shouldn't that be FBI? :-)

In Section 5.11:

   "Receivers SHOULD ignore or remove all unsigned externally-applied
    Authentication-Results header fields, and those not signed by an ADMD
    that can be trusted by the receiver."

Quoting Section 5 of RFC 5451:

   "For security reasons, any MTA conforming to this specification MUST
    delete any discovered instance of this header field that claims to
    have been added within its trust boundary and that did not come from
    another trusted MTA."

   "For simplicity and maximum security, a border MTA MAY remove all
    instances of this header field on mail crossing into its trust
    boundary."

The MUST and the MAY are aggregated into a SHOULD.  Is that intentional?

 From Section 5.11:

   "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 preferred; therefore, 554
    SHOULD be used."

This falls under policy decision.  The usage of a 554 code is 
inappropriate.  From Section 3.6.2 of RFC 5321:

   "If it [SMTP server] declines to relay mail to a particular address
    for policy reasons, a 550 response SHOULD be returned."

 From the same section of this document:

   "SMTP servers doing so SHOULD also use appropriate wording in
    the text portion of the reply, perhaps explicitly using
    the string "ADSP" to facilitate searching of relevant data
    in logs."

I wouldn't put a SHOULD in there.  The working group made the 
argument.  Leave it at that.

Quoting two sentences from the same section to provide better context:

   "In such cases where the submission fails that test, the receiver or
    verifier SHOULD discard the message but return an SMTP success code,
    i.e. accept the message but drop it without delivery.  An SMTP
    rejection of such mail instead of the requested discard action
    causes more harm than good."

I would remove the SHOULD as the argument (second sentence) is 
clear.  The usage of the SHOULD raises the question about whether 
this is a SMTP receiver action and whether it is appropriate to 
create a black hole (silent drop of message).

I found the document well-written.  In places where the document 
advocates a particular approach, it provides an explanation for 
that.  This document can be published as Experimental or 
Informational.  Please note that such an intended status is not a 
dilution of the value of the document.

As there has been some discussion about an Applicability Statement 
experiment, I'll quote some text from RFC 2026:

   "An Applicability Statement specifies how, and under what circumstances,
    one or more TSs [Technical Specifications] may be applied to support a
    particular Internet capability."

This document covers RFC 4871 (4871bis actually), RFC 5451 and RFC 
5617.  The document specifies the circumstances under which the 
capabilities discussed here are applicable.  If the DKIM working 
group decides on taking that path, it could ask for publication of 
the document as Proposed Standard.

Regards,
-sm