Subject: [ietf-dkim] Review of: draft-ietf-dkim-mailinglists-06

From: Dave CROCKER <[email-masked]>
Date: Sun, 17 Apr 2011 10:51:08 -0700

Comments inline.

A mass of small, localized suggestions.  Most are merely wording improvements, 
to tighten things up or clarify things a bit better.

A few substantive points, with suggested revision text, where possible.

There are more such points than I expected, later in the document, as things 
seek to get more normative.

d/

 > DKIM Working Group                                          M. Kucherawy
 > Internet-Draft                                                 Cloudmark
 > Intended status: BCP                                      March 28, 2011
 > Expires: September 29, 2011
 >
 >
 >                          DKIM And Mailing Lists
 >                     draft-ietf-dkim-mailinglists-06
 >
 > Abstract
 >
 >    DomainKeys Identified Mail (DKIM) allows an administrative mail
 >    domain (ADMD) to assume some responsibility for a message.  As the
 >    industry has now gained some deployment experience, the goal for this
 >    document is to explore the use of DKIM for scenarios that include
 >    intermediaries, such as Mailing List Managers (MLMs) and describe the
 >    Best Current Practices.

As the... Practices
->
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).

 > 1.1.  Background
 >
 >    DKIM signatures permit an agent of the email architecture (see
 >    [EMAIL-ARCH]) to make a claim of responsibility for a message by
 >    affixing a validated domain-level identifier to the message as it
 >    passes through a gateway.  Although not the only possibility, this is

gateway???  I don't think so, given the email-arch reference.

perhaps:

     as it is processed by an email actor

 >    most commonly done as a message passes through a Mail Transport Agent

through a boundary mail Transport Agent

 >    (MTA) as it departs an Administrative Mail Domain (ADMD) toward the
 >    general Internet.

as it departs an Administrative Mail Domain (ADMD) across the open Internet.

{{ when departing, the act of departing puts it into the public Internet, not 
'towards' it. }}

 >    A DKIM signature will fail to verify if a portion of the message
 >    covered by one of its hashes is altered.  An MLM commonly alters
 >    messages to provide information specific to the mailing list for
 >    which it is providing service.  Common modifications are enumerated
 >    and described in Section 3.3.  However, note that MLMs vary widely in
 >    behaviour as well as often allowing subscribers to select individual
 >    behaviours.  Further, this does not consider changes the MTA might
 >    make independent of what changes the MLM chooses to apply.

Further, the MTA might make changes that are independent of those the MLM applies.

 >    The DKIM specification document deliberately refrains from the notion

specification document -> signing specification

refrains -> rejects

{{ "This document does not require the value of the SDID or AUID to match an 
identifier in any other message header field."  That's an overt dis-sociation, 
not a passive ignoring. }}

 >    of tying the signing domain (the "d=" tag in a DKIM signature) to any
 >    identifier within a message; any ADMD that handles a message could

any identifier -> any other identifier

 >    sign it, regardless of its origin or author domain.  In particular,
 >    DKIM does not define any meaning to the occurrence of a match between
 >    the content of a "d=" tag and the value of, for example, a domain
 >    name in the RFC5322.From field, 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, nor less, meaning than
 >    a signature with any other "d=" value.
 >
 > 1.2.  MLMs In Infrastructure
 >
 >    Section 3.3 describes some of the things MLMs commonly do that
 >    produce broken signatures, thus reducing the perceived value of DKIM.
 >
 >    Further, while there are published standards that are specific to MLM
 >    behaviour (e.g.  [MAIL], [LIST-ID] and [LIST-URLS]), their adoption
 >    has been spotty at best.  Hence, efforts to specify the use of DKIM
 >    in the context of MLMs needs to be incremental and value-based.
 >
 >    Other MLM behaviours are well-established.  Although it can be argued
 >    that they frustrate widespread DKIM adoption, it cannot be said that
 >    such behaviours are not standards compliant.  Thus, the best approach
 >    is to provide these best practices to all parties involved, imposing
 >    the minimum requirements possible to MLMs themselves.

Some MLM behaviours are well-established and their effects on DKIM signature 
validity can be argued as frustrating wider DKIM adoption.  Still, those 
behaviors are not standards violation.  Hence the best approach for a BCP effort 
is to specify practices for all parties involved, defining the minimum changes 
possible to MLMs themselves.

 >    An MLM is an autonomous agent that takes delivery of a message and
 >    can re-post it as a new message, or construct a digest of it along
 >    with other messages to the members of the list (see [EMAIL-ARCH],
 >    Section 5.3).  However, the fact that the RFC5322.From field of such
 >    a message (in the non-digest case) is typically the same as that of
 >    the original message, and that recipients perceive the message as
 >    "from" the original author rather than the MLM, creates confusion
 >    about responsibility and autonomy for the re-posted message.  This
 >
 >    has important implications for use of DKIM.

{{ The above paragraph strikes me as the strongest and clearest description of 
the underlying tension for this topic.  I suggest moving it sooner in the 
document and somehow highlighting it. Then again, it's still Section 1, so maybe 
its current location is fine. }}

 >    A DKIM signature on a message is an expression of some responsibility
 >    for the message taken by the signing domain.  An open issue, and one
 >    this document intends to address, is some idea of how such a
 >    signature might be used by a recipient's evaluation module after the
 >    message has gone through a mailing list and may or may not have been
 >    invalidated, and if it has, where and how the invalidation may have
 >    happened.

An open issue that is addressed by this document is the ways a signature might 
be used by a recipient's evaluation module, after the message has gone through a 
mailing list and might or might have been rendered invalid. The document also 
considers how invalidation might have happened.

{{ also note switch to non-normative vocabulary. }}

 >    Note that where in this document there is discussion of an MLM
 >    conducting validation of DKIM signatures or ADSP policies, the actual
 >    implementation could be one where the validation is done by the MTA
 >    or an agent attached to it, and the results of that work are relayed
 >    by a trusted channel not specified here.  See [AUTH-RESULTS] for a
 >    discussion of this.  This document does not favour any particular
 >    arrangement of these agents over another, but merely talks about the
 >    MLM itself doing the work as a matter of simplicity.
 >
 > 1.3.  Feedback Loops And Other Bi-Lateral Agreements
 >
 >    A Feedback Loop (FBL) is a bi-lateral agreement between two parties
 >    to exchange reports of abuse.  Typically, a sender registers with a
 >    receiving site to receive abuse reports from that site for mail
 >    coming from the sender.
 >
 >    An FBL reporting address (i.e., an address to which FBL reports are
 >    sent) is part of this bi-lateral registration.  Some FBLs require
 >    DKIM use by the registrant.
 >
 >    A DKIM-signed message sent to an MLM, and then distributed to all of
 >    a list's recipients, could result in a complaint from one of the

one of the final

 >    recipients for some reason.  This could be an actual complaint from
 >    some subscriber that finds the message abusive or otherwise
 >    undesirable, or it could be an automated complaint such as receiver
 >    detection of an invalidated DKIM signature or some other condition.
 >    It could also be a complaint that results from antagonistic
 >    behaviour, such as is common when a subscriber to a list is having
 >    trouble unsubscribing, and then begins issuing complaints about all
 >    submissions to the list.  This would result in a complaint being
 >    generated in the context of an FBL report back to the message author.
 >    However, the original author has no involvement in operation of the
 >    MLM itself, meaning the FBL report is not actionable and thus
 >    undesirable.

meaning... ->  meaning that for them the FBL report is not actionable, might be 
confusing and is thus undesirable.

 >    See Section 6 for additional discussion.
 >
 >    FBLs tend to use the ARF ([MARF]) or the IODEF ([IODEF]) format.

format -> formats

 >
 > 1.4.  Document Scope and Goals
 >
 >    This document provides discussion on the above issues, to improve the
 >    handling of possible interactions between DKIM and MLMs.  In general,
 >    consensus shows a preference toward imposing changes to behaviour at
 >    the signer and verifier rather than at the MLM.

consensus shows a preference toward imposing -> the preference is to impose

{{ referring to consensus invites the reader to declare their disagreement; the 
alternative language is more generic... }}

 >    Wherever possible, MLMs will be conceptually decoupled from MTAs

MLMs will be -> the document's discussion of MLMs is

 >    despite the very tight integration that is sometimes observed in
 >    implementation.  This is done to emphasize the functional
 >    independence of MLM services and responsibilities from those of an
 >    MTA.
 >
 >    Parts of this document explore possible changes to common practice by
 >    signers, verifiers and MLMs.  The suggested enhancements are largely
 >    theoretical in nature, taking into account the current email

theoretical -> predictive

{{ perhaps slightly less inviting of being dismissed by the skeptical reader? }}

 >    infrastructure, the facilities DKIM can provide as it gains wider
 >    deployment, and working group consensus.  There is no substantial
 >    implementation history upon which these suggestions are based, and
 >    the efficacy, performance and security characteristics of them have
 >    not yet been fully explored.
 >
 >
 > 2.  Definitions
 >
 > 2.1.  Other Terms
 >
 >    See [EMAIL-ARCH] for a general description of the current messaging
 >    architecture, and for definitions of various terms used in this
 >    document.
 >
 > 2.2.  DKIM-Specific References
 >
 >    Readers are encouraged to become familiar with [DKIM] and [ADSP],
 >    which are core specification documents, as well as [DKIM-OVERVIEW]
 >    and [DKIM-DEPLOYMENT], which are DKIM's primary tutorial documents.
 >
 > 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. }}

 > 2.4.  Message Streams
 >
 >    This document makes reference to the concept of "message streams".
 >    The idea is to identify groups of messages originating from within an

This document...identify groups
->
A "message stream" identifies a group

 >    ADMD that are distinct in intent, origin and/or use, and partition

and it partitions

 >    them somehow (i.e., via changing the value in the "d=" tag value in
 >    the context of DKIM) so as to keep them associated to users yet
 >    distinct in terms of their evaluation and handling by verifiers or
 >    receivers.
 >
 >    A good example might be user mail generated by a company's employees,
 >    versus operational or transactional mail that comes from automated
 >    sources, versus marketing or sales campaigns.  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).
 >
 >
 > 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? }}

impacts -> effects

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

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

 >    signer:  Any agent that affixes one or more DKIM signature(s) to a
 >       message on its way toward its ultimate destination.  There is
 >       typically a signer running at the MTA that sits between the
 >       author's ADMD and the general Internet.  The originator and/or
 >       author might also be a signer.
 >
 >    verifier:  Any agent that conducts DKIM signature analysis.  One is
 >       typically running at the MTA that sits between the general

MTA -> boundary MTA

general -> public

 >       Internet and the receiver's ADMD.  Note that any agent that
 >       handles a signed message could conduct verification; this document

could -> can

 >       only considers that action and its outcomes either at an MLM or at
 >       the receiver.  Filtering decisions could be made by this agent
 >       based on verification results.
 >
 >    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" }}

 >    In the case of simple user-to-user mail, these roles are fairly
 >    straightforward.  However, when one is sending mail to a list, which
 >    then gets relayed to all of that list's subscribers, the roles are
 >    often less clear to the general user as particular agents may hold
 >    multiple important but separable roles.  The above definitions are
 >    intended to enable more precise discussion of the mechanisms
 >    involved.
 >
 >
 > 3.2.  Types Of Mailing Lists
 >
 >    There are four common MLM implementation modes:

{{ mumble.  given the focus of this document, i'm guessing this is one set of 
terms that really /does/ warrant discussion directly in the document... }}

 >    aliasing:  An aliasing MLM (see Section 5.1 of [EMAIL-ARCH]) is one
 >       that makes no changes to a message as it redistributes; any

to a message as -> to the message itself, as

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

body at all and only [MAIL] trace header fields are added.
->
body or header at all, except for the addition of [MAIL] trace header fields.

 >       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 an

message. -> message transit.

 >       address that expands directly in the MTA, such as a list of local
 >       system administrators used for relaying operational or other
 >       internal-only messages.  See also Section 3.9.2 of [SMTP].
 >
 >    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.
 >
 >    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 that generates its own content and does not
 >       act as an intermediary.  Typically replies are not generated, or

This is a special case of... act as an intermediary.
->
This is not a "mediator" in terms of [EMAIL-ARCH], since it originates the 
message, but after creation, its message processing and posting behavior 
otherwise do match the MLM paradigm.

 >       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.
 >
 >    digesting:  A special case of the resending MLM is one that sends a
 >       single message comprising an aggregation of recent MLM
 >       submissions, 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.
 >
 >    In the remainder of this document we distinguish two relevant steps,
 >    corresponding to the following SMTP transactions:
 >
 >    MLM Input:  Originating user is author; originating ADMD is
 >       originator and signer; MLM's ADMD is verifier; MLM's input
 >       function is receiver.
 >
 >
 >    MLM Output:  MLM (sending its reconstructed copy of the originating
 >       user's message) is author; MLM's ADMD is originator and signer;
 >       the ADMD of each subscriber of the list is a verifier; each
 >       subscriber is a receiver.
 >
 >    Much of this document focuses on the resending class of MLM as it has
 >    the most direct conflict operationally with DKIM.
 >
 >    The dissection of the overall MLM operation into these two distinct
 >    steps allows the DKIM-specific issues with respect to MLMs to be

steps -> phases

{{ methinks there are lots of 'steps' here, inside each phase... }}

 >    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.
 >
 >    Some issues about these activities are discussed in Section 3.6.4 of
 >    [MAIL] and in Section 3.4.1 of [EMAIL-ARCH].
 >
 > 3.3.  Current MLM Effects On Signatures
 >
 >    As described above, an aliasing MLM does not affect any existing
 >    signature, and an authoring MLM is always creating new content and
 >    thus there is never an existing signature.  However, the changes a
 >    resending MLM can make typically affect the RFC5322.Subject header

can make typically -> typically make

 >    field, addition of some list-specific header fields, and/or
 >    modification of the message body.  The impacts of each of these on
 >    DKIM verification are discussed below.

impacts of each -> effects of

 >
 >    Subject tags:  A popular feature of MLMs is the "tagging" of an
 >       RFC5322.Subject field by prefixing the field's contents with the
 >       name of the list, such as "[example]" for a list called "example".
 >       Altering the RFC5322.Subject field on new submissions by adding a
 >       list-specific prefix or suffix will invalidate the signer's
 >       signature if that header field was included when creating that

included -> included in the hash

 >       signature.  [DKIM] lists RFC5322.Subject as one that should be
 >       covered, so this is expected to be an issue for any list that

covered, -> covered and it contains important user-visible text,

 >       makes such changes.
 >
 >    List-specific header fields:  Some lists will add header fields
 >       specific to list administrative functions such as those defined in
 >       [LIST-ID] and [LIST-URLS], or the "Resent-" fields defined in
 >       [MAIL].  It is unlikely that a typical MUA would include such
 >       fields in an original message, and DKIM is resilient to the
 >       addition of header fields in general (see notes about the "h=" tag
 >       in Section 3.5 of [DKIM]).  Therefore this is seen as less of a
 >       concern.

{{ "less"?  seems like it means it is not a concern at all.  }}

 >
 >    Other header fields:  Some lists will add or replace header fields
 >       such as "Reply-To" or "Sender" in order to establish that the
 >       message is being sent in the context of the mailing list, so that
 >       the list is identified ("Sender") and any user replies go to the
 >       list ("Reply-To").  If these fields were included in the original
 >       message, it is possible that one or more of them may have been
 >       signed, and those signatures will thus be broken.

have been signed -> have been included in the signature hash

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

 >
 >    Major body changes:  There are some MLMs that make more substantial
 >       changes to message bodies when preparing them for re-distribution,
 >       such as adding, deleting, reordering, or reformatting [MIME]
 >       parts, "flattening" HTML messages into plain text, or insert
 >       headers or footers within HTML messages.  Most or all of these
 >       changes will invalidate a DKIM signature.
 >
 >    MIME part removal:  Some MLMs that are MIME-aware will remove large
 >       MIME parts from submissions and replace them with URLs to reduce
 >       the size of the distributed form of the message and to prevent
 >       inadvertent automated malware delivery.  Except in cases where a

in cases -> in some cases

 >       body length limit is applied in generation of the DKIM signature,
 >       the signature will be broken.
 >
 >    There reportedly still exist a few scattered mailing lists in

a few scattered -> some

 >    operation that are actually run manually by a human list manager,
 >    whose workings in preparing a message for distribution could include
 >    the above or even some other changes.
 >
 >    In general, absent a general movement by MLM developers and operators
 >    toward more DKIM-friendly practices, an MLM subscriber cannot expect
 >    signatures applied before the message was processed by the MLM to be
 >    valid on delivery to a receiver.  Such an evolution is not expected
 >    in the short term due to general development and deployment inertia.
 >    Moreover, even if an MLM currently passes messages unmodified such
 >    that author signatures validate, it is possible that a configuration
 >    change or software upgrade to that MLM will cause that no longer to
 >    be true.
 >
 >
 > 4.  Non-Participating MLMs
 >
 >    This section contains a discussion of issues regarding sending DKIM-
 >    signed mail to or through an MLM that is not DKIM-aware.
 >    Specifically, the header fields introduced by [DKIM] and
 >    [AUTH-RESULTS] carry no special meaning to such an MLM.
 >
 > 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. }}

 >    signed.  The MLM could make a change that would invalidate the
 >    author's signature but not remove it prior to re-distribution.
 >    Hence, list recipients would receive a message purportedly from the
 >    author but bearing a DKIM signature that would not verify.  There
 >    exist DKIM modules that incorrectly penalize messages with signatures
 >    that do not validate, so this may have detrimental effects outside of

{{ I'm going to quibble and say that the problematic modules are not really part 
of DKIM.  If there's misbehaving software, let's not blame any part of DKIM... 
So, perhaps: }}

There exists...control
->
Some mail filtering software incorrectly penalizes a message containing a DKIM 
signature that fails verification.  This may have detrimental effects outside of 
the author's control.

 >    the author's control.  (Additional discussion of this is below.)
 >    This problem could be compounded if there were receivers that applied
 >    signing policies (e.g., [ADSP]) and the author published any kind of
 >    strict policy.

could -> can / were -> are / applied -> apply / published -> publishes

{{ we live in an active world... }}

{{ by the way, does a term like "strict ADSP policy" have an obvious and precise 
meaning?  I suspect not, so that more fully explaining what is meant might be 
safer. }}

 >    For domains that do publish strict ADSP policies, the originating
 >    site SHOULD use a separate message stream (see Section 2.4), such as
 >    a sub-domain, for the "personal" mail -- a subdomain that is

a sub-domain -> a signing and author sub-domain

{{ Since ADSP is being cited, the issue is more than what is earlier defined as 
a message stream, since it requires consonance with the From: field. }}

 >    different from domain(s) used for other mail streams.  This allows
 >    each to develop an independent reputation, and more stringent
 >    policies (including ADSP) can be applied to the mail stream(s) that
 >    do not go through mailing lists or perhaps do not get signed at all.

 >    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.
 >
 >    In general, the more strict practices and policies are likely to be
 >    successful only for the mail streams subject to the most end-to-end
 >    control by the originating organization.  That typically excludes
 >    mail going through MLMs.  Therefore, authors whose ADSP is published
 >    as "discardable" SHOULD NOT send mail to MLMs, as it is likely to be
 >    rejected by ADSP-aware verifiers or recipients.  (This is discussed
 >    further in Section 5.6 below.)

{{ Hmmm.  Seems like the normative language needs to be directed at the site 
administrators and not the authors.  So... }}

Therefore, site administrators wishing to employ ADSP with a "discardable" 
setting, SHOULD separate the controlled mail stream warranting this handling 
from other mail streams that are less controlled, such as personal mail that 
transits MLMs.

 >
 >
 > 4.2.  Verification Outcomes at Receivers
 >
 >    There does not appear to be a reliable way to determine that a piece

does not appear to be a -> is no

{{ we know 'truth' here, so let's not be iffy about it... }}

 >    of mail arrived via a non-participating MLM.  Sites whose users
 >    subscribe to non-participating MLMs SHOULD be prepared for legitimate
 >    mail to arrive with no valid signature, just as it always has in the
 >    absence of DKIM.

{{ what does it mean to "be prepared", here? Perhaps this is similar to above 
and the directive that is needed is along the lines of: }}

Sites whose users subscribe to non-participating MLMs SHOULD ensure that such 
user mail streams are not subject to strict DKIM-related handling policies.

 > 4.3.  Handling Choices at Receivers
 >
 >    A receiver's ADMD would have to have some way to register such non-
 >    participating lists to exempt them from the expectation of signed
 >    mail as discussed in Section 4.1.  This is, however, probably not a
 >    scalable solution as it imposes a burden on the receiver that is
 >    predicated on sender behaviour.

In order to exempt some mail from the expectation of signature verification, as 
discussed in Section 4.1, receiving ADMDs would need to register 
non-participating lists and confirm that mail transited them. However such an 
approach requires excessive effort and even then is likely to be unreliable. 
Hence it is not a scalable solution.

 >    Note that the [DKIM] specification explicitly directs verifiers and
 >    receivers to treat a verification failure as though the message was
 >    not signed in the first place.  In the absence of specific ADSP
 >    direction, any treatment of a verification failure as having special
 >    meaning is either outside the scope of DKIM or is in violation of it.

{{ Even with an ADSP directive, it's outside of the scope of DKIM. So... }}

Any treatment of a verification failure as having special meaning is a violation 
of the basic DKIM signing specification.  The only valid, standardized basis for 
going beyond that specification is with specific ADSP direction.

 >    Use of restrictive domain policies such as [ADSP] "discardable"
 >    presents an additional challenge.  In that case, when a message is
 >    unsigned or the signature can no longer be verified, discarding of
 >    the message is requested.  There is no exception in the policy for a
 >    message that may have been altered by an MLM, nor is there a reliable
 >    way to identify such mail.  Therefore, participants SHOULD honour the
 >    policy and disallow the message.
 >
 > 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? }}

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

 >    recommendations of Section 5 on behalf of the MLM, and the MTA or MSA
 >    receiving the MLM Output could also add a DKIM signature for the
 >    MLM's domain.
 >

{{ overall, I think I understand the intent of this sub-section but find the 
text confusing and the guidance more limited than is likely to be helpful.  I 
think all that's needed is a bit more beef, rather than any change in intent. }}

 >
 > 5.  Participating MLMs
 >
 >    This section contains a discussion of issues regarding sending DKIM-
 >    signed mail to or through an MLM that is DKIM-aware, and may also be
 >    ADSP-aware.

regarding DKIM-signed mail that transits an MLM that is DKIM-aware

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

 >    Changes that merely add new header fields, such as those specified by
 >    [LIST-ID], [LIST-URLS] and [MAIL], are generally the most friendly to
 >    a DKIM-participating email infrastructure in that their addition by
 >    an MLM will not affect any existing DKIM signatures unless those
 >    fields were already present and covered by a signature's hash or a
 >    signature was created specifically to disallow their addition (see
 >    the note about "h=" in Section 3.5 of [DKIM]).

{{ Suggest breaking the above into two or more sentences. I nearly ran out of 
breath reading it... }}

 >    However, the practice of applying headers and footers to message
 >    bodies is common and not expected to fade regardless of what
 >    documents this or any standards body might produce.  This sort of
 >    change will invalidate the signature on a message where the body hash
 >    covers the entire message.  Thus, the following sections also discuss
 >    and suggest other processing alternatives.
 >
 >    A possible mitigation to this incompatibility is use of the "l=" tag
 >    to bound the portion of the body covered by the DKIM body hash, but
 >    this is not workable for [MIME] messages; moreover, it has security
 >    considerations (see Section 3.5 of [DKIM]).  Its use is therefore
 >    discouraged.
 >
 >    MLM operators often arrange to affix to outgoing messages expressions

arrange to affix to outgoing messages expressions -> affix expressions

 >    of list-specific policy and related information (e.g., rules for
 >    participation, small advertisements, etc.).  There is currently no
 >    header field proposed for relaying such general operational MLM
 >    details apart from what [LIST-URLS] already supports.  This sort of
 >    information is what is commonly included in appended footer text or
 >    prepended header text.  The working group RECOMMENDS periodic,

It is RECOMMENDED that periodic...

 >    automatic mailings to the list to remind subscribers of list policy,
 >    and otherwise RECOMMENDS use of standard header fields to express
 >    list operation parameters rather than body changes.  These periodic
 >    mailings will be repetitive, of course, but by being generally the
 >    same each time they can be easily filtered if desired.

{{ Mumble. The logic leading to this recommendation is reasonable, but there is 
no way it will have any meaningful effect and I've no idea what else to suggest.  }}

 >
 > 5.2.  DKIM Author Domain Signing Practices
 >
 >    [ADSP] presents a particular challenge.  An author domain posting a
 >    policy of "discardable" imposes a very tight restriction on the use
 >    of mailing lists, essentially constraining that domain's users to
 >    lists operated by aliasing MLMs only; any MLM that alters a message
 >    from such a domain or removes its signature subjects the message to
 >    severe action by verifiers or receivers.  It is the consensus of the
 >    working group that a resending MLM SHOULD 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 SHOULD also discourage
 >    such subscribers when they first sign up to the list.  Further
 >    discussion of this appears in Section 5.3.

{{ Specs and BCPs do not make statements about wg consensus.  Rather they simply 
document normative directives. All references to consensus should be changed to 
simple normative declarations. }}

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

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

 >    returning a 5xx error code.  In the latter case, some advice for how
 >    to conduct the rejection in a potentially meaningful way can be found
 >    in Section 5.10.
 >
 >    See also Appendix B.5 of [ADSP] for further discussion.
 >
 > 5.3.  Subscriptions

{{ this strikes me as one of the more useful sub-sections in the document... }}

 >    At subscription time, an ADSP-aware MLM SHOULD check for a published
 >    ADSP record for the new subscriber's domain.  If the policy specifies
 >    "discardable", the MLM SHOULD disallow the subscription or present a
 >    warning that the subscriber's submissions to the mailing list might
 >    not be deliverable to some recipients because of the subscriber's
 >    ADMD's published policy.
 >
 >    Of course, such a policy record could be applied after subscription,

applied -> created

 >    so this is not a universal solution.  An MLM implementation MAY do
 >    periodic checks of its subscribers and issue warnings where such a
 >    policy is detected, or simply check upon each submission.
 >
 > 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 suggestion can be made more general.  Mail that is of a
 >    transactional or generally end-to-end nature, and not likely to be
 >    forwarded around either by MLMs or users, SHOULD come from a
 >    different mail stream than a stream that serves more varied uses.

come from a different mail stream
->
signed with a different mail stream identifier

 > 5.5.  Verification Outcomes at MLMs
 >
 >    MLMs typically attempt to authenticate messages posted through them.
 >    They usually do this through the trivial (and insecure) means of
 >    verifying the RFC5322.From field email address (or, less frequently,
 >    the RFC5321.MailFrom parameter) against a list registry.  DKIM

list registry -> list subscription registry

 >    enables a stronger form of authentication, although this is not yet
 >    formally documented: It can require that messages using a given
 >    RFC5322.From address also have a DKIM signature with a corresponding
 >    "d=" domain.  This feature would be somewhat similar to using ADSP,
 >    except that the requirement for it would be imposed by the MLM and
 >    not the author's organization.

Note that this also uses a DKIM signature beyond its formal semantics, since a 
signature does not validate the RFC5322.From address.

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

 >    it is a common and intuitive conclusion, not all signed mail will
 >    include an author signature (see [ADSP]).  MLM implementers SHOULD

not all... will include
->
few signed messages will include

{{ state the affirmative and the likely long-term reality. }}

 >    accommodate such in their configurations.  For example, an MLM might
 >    be designed to accommodate a list of possible signing domains (the
 >    "d=" portion of a DKIM signature) for a given author, and determine
 >    at verification time if any of those are present.

{{ As soon as a document like this puts forward a hypothetical, exploratory 
design choice, it should document likely tradeoffs.  For example, here the 
assumption is that the author will know what the list should be and that the 
list is stable.  Neither is likely to be true. }}

 >    A message that cannot be thus authenticated MAY be held for
 >    moderation or rejected outright.

{{ The follow-on problem with this line of specification is that providing 
normative language lends more claim of certitude and benefit than is justified. 
  I strongly suggest removing normative language from this type of discussion. 
The discussion is an exploration and should cast things in those terms. Hence, 
MAY -> might.}}

 >    This logic could apply to any list operation, not just list
 >    submission.  In particular, this improved authentication MAY apply to
 >    subscription, unsubscription, and/or changes to subscriber options
 >    that are sent via email rather than through an authenticated,
 >    interactive channel such as the web.
 >
 >    In the case of verification of signatures on submissions, MLMs SHOULD
 >    add an [AUTH-RESULTS] header field to indicate the signature(s)
 >    observed on the submission as it arrived at the MLM and what the
 >    outcome of the evaluation was.  Downstream agents may or may not

may or may -> might or might

 >    trust the content of that header field depending on their own a
 >    priori knowledge of the operation of the ADMD generating (and,
 >    preferably, signing) that header field.  See [AUTH-RESULTS] for
 >    further discussion.
 >
 >
 > 5.6.  Signature Removal Issues
 >
 >    A message that arrives signed with DKIM means some domain prior to
 >    MLM Input has made a claim of some responsibility for the message.
 >    An obvious benefit to leaving the input-side signatures intact, then,
 >    is to preserve that chain of responsibility of the message so that

{{ hmmm.  it's not really a chain.  this is not a model of transitive trust but 
of "packaged" trust that is preserved.  So, perhaps:  }}

to preserve that chain of responsibility
->
to preserve that original assertion of responsibility

 >    the receivers of the final message have an opportunity to evaluate
 >    the message with that information available to them.
 >
 >    However, if the MLM is configured to make changes to the message
 >    prior to re-posting that would invalidate the original signature(s),
 >    further action is RECOMMENDED to prevent invalidated signatures from
 >    arriving at final recipients, possibly triggering unwarranted filter
 >    actions.  (Note, however, that such filtering actions are plainly
 >    wrong; [DKIM] stipulates that an invalid signature is to be treated
 >    as no signature at all.)
 >
 >    A possible solution would be to:
 >
 >    1.  Attempt verification of all DKIM signatures present on the input
 >        message;
 >
 >    2.  Apply local policy to authenticate the identity of the author;
 >
 >    3.  Remove all existing [AUTH-RESULTS] fields (optional);
 >
 >    4.  Add an [AUTH-RESULTS] header field to the message to indicate the
 >        results of the above;
 >
 >    5.  Remove all previously-evaluated DKIM signatures;
 >
 >    6.  Affix a new signature that covers the entire message on the
 >        output side, including the Authentication-Results header field
 >        just added (see Section 5.7).
 >
 >    Removing the original signature(s) seems particularly appropriate
 >    when the MLM knows it is likely to invalidate any or all of them due
 >    to the nature of the reformatting it will do.  This avoids false
 >    negatives at the list's subscribers in their roles as receivers of
 >    the message; although [DKIM] stipulates that an invalid signature is
 >    the same as no signature, it is anticipated that there will be some
 >    implementations that ignore this advice.
 >
 >    The MLM could re-evaluate existing signatures after making its
 >    message changes to determine whether or not any of them have been
 >    invalidated.  The cost of this is reduced by the fact that,
 >    presumably, the necessary public keys have already been downloaded
 >    and one or both of the message hashes could be reused.

{{ in fact, the actual work is only in comparing the hashes, not in performing 
any additional public key computations. }}

 >    Per the discussion in [AUTH-RESULTS], there is no a priori reason for
 >    the final receivers to put any faith in the veracity of that header
 >    field when added by the MLM.  Thus, the final recipients of the

Per the...MLM
->
Per the discussion in [AUTH-RESULTS], a receiver's putting any faith in the 
veracity of that header field requires a priori assessment of the agent that 
created it.  Absent that assessment, a receiver cannot interpret the field as valid.

 >    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? }}

 >    only one on the message when the verifier gets it, and the verifier
 >    explicitly trusts the signer (in this case, the MLM), the verifier is

signer -> signer that is covering the Auth-Results field

 >    in a position to believe that a valid author signature was present on
 >    the message.
 >
 >    This can be generalized as follows: A receiver SHOULD consider only
 >    [AUTH-RESULTS] fields bearing an authserv-id that appears in a list
 >    of sites the receiver trusts and which is also included in the header
 >    hash of a [DKIM] signature added by a domain in the same trusted
 >    list.
 >
 >    Since an aliasing MLM makes no substantive changes to a message, it
 >    need not consider the issue of signature removal as the original
 >    signatures should arrive at least to the next MTA unmodified.  It is
 >    possible that future domain-based reputations would prefer a more
 >    rich data set on receipt of a message, and in that case signature
 >    removal would be undesirable.
 >
 >    An authoring MLM is closed to outside submitters, thus much of this
 >    discussion does not apply in that case.
 >
 > 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. }}

 >    MLM signatures will likely be used by recipient systems to recognize
 >    list mail, and they give the MLM's ADMD an opportunity to develop a
 >    good reputation for the list itself.
 >
 >    A signing MLM is, as any other MLM, free to omit redistribution of a
 >    message if that message was not signed in accordance with its own
 >    local configuration or policy.  It could also redistribute but not

{{ seems like this "policy" applies to any receiving MLM and not just ones that 
do signing.  That is, it's about incoming messages and not outgoing ones. }}

 >    sign such mail.  However, selective signing is NOT RECOMMENDED;
 >    essentially that would create two message streams from the MLM, one
 >    signed and one not, which can confuse DKIM-aware verifiers and
 >    receivers.
 >
 >    A signing MLM SHOULD 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

using a DNS domain matching what will be used in the "d=" tag of the
DKIM signature it will add to the new message
->
using that DNS domain matching the one used in the "d=" tag of the
DKIM signature that is added by the MLM

This could -> This can

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

 >    reputation of the signer will be a more critical data point rather
 >    than this suggested binding.  Furthermore, this is not a binding
 >    recognized by any current specification document.
 >
 >    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. }}

 >    A DKIM-aware resending MLM SHOULD sign the entire message after being

after being -> after the message is

 >    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? }}

 >    choice of what portions of the header and body of the output message
 >    should include those parts of the header and body for which the MLM
 >    wishes to assert responsibility.
 >
 >    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.  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. }}

 >
 > 5.8.  Verification Outcomes at Final Receiving Sites
 >
 >    In general, verifiers and receivers SHOULD treat a signed message
 >    from an MLM like any other signed message; indeed, it would be
 >    difficult to discern any difference since specifications such as
 >    [LIST-URLS] and [LIST-ID] are not universally deployed and can be
 >    trivially spoofed.
 >
 >    However, because the author domain will commonly be different from
 >    the MLM's signing domain, there may be a conflict with [ADSP] as
 >    discussed in Section 4.3 and Section 5.6, especially where an ADMD
 >    has misused ADSP.
 >
 > 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"? }}

 >    reports based on DKIM verifications in the subject message.  Such
 >    operators SHOULD send a report to each domain with a valid signature
 >    that has an FBL agreement established, as DKIM signatures are claims
 >    of some responsibility for that message.  Because authors generally
 >    have limited control over the operation of a list, this point makes
 >    MLM signing all the more important.

{{ this implies a rather important point that should be made explicitly and 
perhaps strongly:  MLMs should register with FBLs.  }}

 >    Where the FBL wishes to be more specific, it MAY act solely on a DKIM
 >    signature where the signing domain matches the DNS domain found in a
 >    List-Post: header field (or similar).
 >
 >    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.
 >
 > 5.10.  Handling Choices at Receivers
 >
 >    A recipient that explicitly trusts signatures from a particular MLM
 >    MAY wish to extend that trust to an [AUTH-RESULTS] header field
 >    signed by that MLM.  The recipient MAY then do additional processing
 >    of the message, using the results recorded in the Authentication-
 >    Results header field instead of the original author's DKIM signature.
 >    This includes possibly processing the message as per ADSP
 >    requirements.
 >
 >    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.  See Section 5 and Section 7 of
 >    [AUTH-RESULTS] for further discussion.
 >
 >    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. }}

 >    server supports [ENHANCED] status codes, it SHOULD make a distinction
 >    between messages rejected deliberately due to policy decisions rather
 >    than those rejected because of other deliverability issues.  In
 >
 >
 >
 > Kucherawy              Expires September 29, 2011              [Page 20]
 > 
 > Internet-Draft           DKIM and Mailing Lists               March 2011
 >
 >
 >    particular, a policy rejection SHOULD be relayed using a 5.7.1
 >    enhanced status code and some appropriate wording in the text part of
 >    the reply, in contrast to a code of 5.1.1 indicating the user does
 >    not exist.  Those MLMs that automatically attempt to remove users
 >    with prolonged delivery problems (such as account deletion) SHOULD
 >    thus detect the difference between policy rejection and other
 >    delivery failures, and act accordingly.  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.
 >
 >    The preceding paragraph does not apply to an [ADSP] policy of
 >    "discardable".  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.
 >
 >
 >
 >
 >
 >
 >
 >
 >
 >
 >
 >
 >
 >
 >
 >
 >
 >
 >
 >
 >
 >
 >
 >
 >
 >
 >
 >
 >
 >
 >
 >
 >
 >
 > Kucherawy              Expires September 29, 2011              [Page 21]
 > 
 > Internet-Draft           DKIM and Mailing Lists               March 2011
 >
 >
 > 6.  DKIM Reporting
 >
 >    The MARF working group is developing mechanisms for reporting
 >    forensic details about DKIM verification failures.  At the time of
 >    this writing, this is still a work in progress.

{{ I tend to discourage directly discussing work that is underway. The text is 
quickly overtaken by event. Perhaps:

As mechanisms are available for reporting forensive details about DKIM 
verification failures, MLMs will benefit from their use.

 >
 >    MLMs SHOULD apply these or other DKIM failure reporting mechanisms as
 >    a method for providing feedback to signers about issues with DKIM
 >    infrastructure.  This is especially important for MLMs that implement
 >    DKIM verification as a mechanism for authentication of list
 >    configuration commands and submissions from subscribers.
 >
 > 7.  IANA Considerations
 >
 >    This document includes no IANA actions.
 >
 >
 >
 > 8.  Security Considerations
 >
 >    This document provides suggested or best current practices for use
 >    with DKIM, and as such does not introduce any new technologies for
 >    consideration.  However, the following security issues should be
 >    considered when implementing the above practices.
 >
 > 8.1.  Authentication Results When Relaying
 >
 >    Section 5 advocates addition of an [AUTH-RESULTS] header field to
 >    indicate authentication status of a message received as MLM Input.
 >    Per Section 7.2 of [AUTH-RESULTS], receivers generally should not
 >    trust such data without a good reason to do so, such as an a priori
 >    agreement with the MLM's ADMD.
 >
 >    Such agreements are strongly advised to include a requirement that
 >    those header fields be covered by a [DKIM] signature added by the
 >    MLM's ADMD.
 >

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 19 Apr 2011 00:09:33 -0700

Thanks for the thorough review.  I've only replied below to stuff that warrants more than an "OK" or other indication of agreement.

> focus on DKIM-Hostile, rather than DKIM-Friendly?  Friendly largely

How about "DKIM-Cooperative"?

(Largely because flipping the logic throughout the work might be a lot of work...)

>  >    It is important to make some distinctions among different MLM- like

Specifically, intermediaries that mess with the envelope, typically changing one recipient to many, and possibly altering the content.

> 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)"?

> {{ "relays it towards its destinations" is more like the definition of a...

So change "relays" to "sends" or "routes"?

> {{ email-arch: "2.2.4. Receiver  The Receiver performs final delivery" }}

Those read the same to me.  Are you proposing a change here?

> {{ I'd have thought that citing the l= capability here would be appropriate, for

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.

> author is aware of any of these issues, nevermind know what it means to be

Later on in Section 4.1, there's this:

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

The non-participating MLM.  So s/it/the MLM/

> 'submission' is an email term of art, this reference is confusing. }}

So instead of "submissions", say "messages from list subscribers"?

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

> {{ "above practice is not observed"?  Sorry but I don't know what that's

The paragraph preceding proposes MLM interference with subscription actions from addresses that use an ADSP "discardable".

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

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

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

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

>  >    the alterations it makes to the original messages it is re- sending,

Usually, but not always, especially with the FBL discovery work MARF is doing.

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

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

> will verify or it won't.  how can this be statistical, other than later, in

"will not validate" would work for me too, since "might" is also in there.

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

> this means. "a posting"? }}

Bleed-over from Usenet terminology, I suppose.  "message" would be fine there.

> what is done, recommended or what. }}

How about "preferred" or "appropriate"?

-MSK

---

From: "John R. Levine" <[email-masked]>
Date: 19 Apr 2011 12:40:08 -0400

> How about "DKIM-Cooperative"?

I'd suggest DKIM aware, unless you think there are list operators who are 
actively DKIM hostile.

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

Please leave it out -- the cases it covers are such a small fraction of 
the ways that a list will break a signature that it just confuses the 
issue.

>> >    deciding whether or not to send to the list when that mail would be

I'd prefer taking entire section out, unless we want to make a deep dive 
into the swamp of offering advice to work around the ways we think that 
other people's software is broken.  Just sign your fripping mail.

>> but in fact it isn't.  It's just an ADSP failure. }}

The alternative suggestion is that if it has a sufficiently credible 
signature, accept it and forget about ADSP.  See above-mentioned swamp.

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

I definitely get FBL reports from Yahoo for mail I've sent to lists.  It's 
really not an author issue as much as an original ADMD vs. list's ADMD 
issue.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Ian Eiloart <[email-masked]>
Date: Wed, 20 Apr 2011 08:46:15 +0000

> signature, accept it and forget about ADSP.  See above-mentioned swamp.

I guess you'd want to see evidence (signed by the credible MLM) that the message had arrived at the list with a good signature.

So, if the list gets a message from an ADSP protected author, the list should add a header with information to that affect, and then sign that header. If the recipient trusts the list, then it should examine that header to check that the original message was compliant. If not, then it should discard the message.

-- 
Ian Eiloart
Postmaster, University of Sussex
+44 (0) 1273 87-3148

---

From: "John R. Levine" <[email-masked]>
Date: 20 Apr 2011 08:49:05 -0400

> I guess you'd want to see evidence (signed by the credible MLM) that the
> message had arrived at the list with a good signature.

As I said in the sentence you quoted, no, I don't.

Why is it so important to second guess the list software? I've been using 
mailing lists for over thirty years, and I've never had any interest in
trying to mechanically determine whether I agree with the list manager's 
selection of messages.  In cases where it's wrong, the fix is to fix the 
list manager, not to add an extra layer of sorting just about list mail.

I've been asking for at least a year why people think it's important to 
see the incoming signatures on list mail, and the answer has always boiled 
down to, well on some lists we can, then going off into the woods with 
implausible changes to MLM software.  If this were important, why don't we 
demand that they preserve S/MIME signatures, too?

Regards,

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 20 Apr 2011 08:54:39 -0700

On 4/19/2011 12:09 AM, Murray S. Kucherawy wrote:b
>> {{ 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. }}
>

Semantically pretty good.  Stylistically sounds terrible.  But no, i don't have 
a better suggestion.

> Specifically, intermediaries that mess with the envelope, typically changing
> one recipient to many, and possibly altering the content.

Well, my main point behind a question like that is that the doc is using an 
undefined term and that should be fixed, either with an explanation or a 
different term that is already in common use.

>> {{ And indeed, here's an example of divergence.  In email-arch, the author
>> does not (necessarily) perform submission.  Submission is performed by the

The architecture doc just shows a line connecting them and no protocol spec to 
cover the transition.  Since, yes, it's usually the author, they are the same 
entity in typical practice, but architecturally they are distinct with distinct 
roles name.

> begin its travel to its destination(s)"?

wfm.

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

'sends' is (almost) always safe...

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

Interesting.  Yes I originally read it as different.  But yes, I see that they 
probably mean the same.  mumble.

>>> 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. }}
>
> document.  It also only handles appended text, but not prepended text, for
> example.

Hmmm.  Since it is not a deprecated feature, and since it's highly relevant to 
this bit of discussion, I suggest saying /something/ about it, even if it's to 
recommend against.  Not sure what to suggest.

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

For the earlier text, how about some waffling, along the lines of:

    In an idealized world, if an author knows...

Just to acknowledge up front that it's an easily-challenged scenario.

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

belts and suspenders:

    a non-participating MLM could have its DKIM verifier act on messages from 
list subscribers

>>> on

Yeah, but I'll repeat that that text does not say anything useful but sounds as 
if it thinks it is.  (that's all sounds harsher than I'd prefer, but it's what 
my fingers produced.)

> The paragraph preceding proposes MLM interference with subscription actions
> from addresses that use an ADSP "discardable".

Again, my point is that i think the current text, here, is likely to be 
challenging for a reader.

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

Well, I think my point is that this failure is merely an exemplar of an entire 
class of handling/routing failures and the text ought to make that clear.

>>> 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.
>>
>> {{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.
>> }}
>
> 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.

1. We know it's not realistic to tell authors to create different streams.  It's 
pretty much not realistic to tell authors to do anything in this space.

2. Does John's scenario care about the nature of the signature?  Author domain 
or any?  I think it doesn't, but am not sure.

3. On reflection, I suggest tossing the reference to AUID.

4.  The scenario that you cite as motivating this isn't obvious to me from the 
existing text.  Generically, the point is that behavior of an intermediary can 
trigger recipient complaints that wind up reflecting back on the author, but the 
author has no control over any of it.  This is certainly a fair point.

5. I'm not sure differing mail stream signature identifiers will help for John's 
scenario, because the bad rep is likely to accrue to the From: field domain...

>>> As described, the MLM MAY conduct DKIM verification of a signed message
>>> to attempt to confirm the identity of the author. Although
>>
>> 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. }}
>
> 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.

Right.  And that's a good start.  But on reading the doc, I think there needs to 
be an explicit distinction between the two.

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

hmmm.  Back to theory, rather than actual practice...

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

Right.  I'd be happy to have the doc merely note that this is entirely beyond 
basic DKIM semantics and requires additional conventions, such as private agreement.

>>> Such MLMs SHOULD ensure the signature's header hash will cover at least:
>>>
>>> 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. }}
>

Well, that's a respectable effort, if only DKIM semantics meant that hashed 
fields specified what the signer is taking responsibility for.

But since the semantics are merely that the signer is taking (some) 
responsibility for the (entire) message, and not only the signed parts of the 
message, your language asserts a degree of precision that is greater than DKIM 
semantics provide.

(Given that you and I are having this exchange, I'm pretty sure the general 
community stands no chance of being clear about this.  At the least this means 
that our docs need to bend over backwards to emphasize the limitations.)

>>> 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? }}
>

ack.

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

The text seems to be saying "receivers sometimes go far beyond the actual 
semantics".  That's an inherent problem, of course, for any occurrence of 
multiple signatures.

I guess what's distinctive is that an MLM is likely to be the common source of 
an additional signature, other than one provided in the author' organization or 
the outbound border MTA's organization.  (Think small enterprise connected via 
large ISP.)  In the long run, however, I'm suspecting that multiple signatures 
will be different, particularly when the author domain is different from the 
outbound border MTA.  (My own example of dcrocker.net and songbird.com fits this.)

I guess the only thing I'd suggest is, again, distinguishing theory from 
practice.  That is, the concern here is certainly valid theory -- the potential 
for the problem is real -- but I believe there is no established pattern of 
problem in practice.

d/

-- 

   Dave Crocker