doc: Add RFC documents

1 files changed, 1459 insertions, 0 deletions

diff --git a/doc/rfc/rfc6377.txt b/doc/rfc/rfc6377.txt
new file mode 100644
index 0000000..da91e17
--- /dev/null
+++ b/doc/rfc/rfc6377.txt
@@ -0,0 +1,1459 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                      M. Kucherawy
+Request for Comments: 6377                                     Cloudmark
+BCP: 167                                                  September 2011
+Category: Best Current Practice
+ISSN: 2070-1721
+
+
+          DomainKeys Identified Mail (DKIM) and Mailing Lists
+
+Abstract
+
+   DomainKeys Identified Mail (DKIM) allows an ADministrative Management
+   Domain (ADMD) to assume some responsibility for a message.  Based on
+   deployment experience with DKIM, this document provides guidance for
+   the use of DKIM with scenarios that include Mailing List Managers
+   (MLMs).
+
+Status of This Memo
+
+   This memo documents an Internet Best Current Practice.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   BCPs is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6377.
+
+Copyright Notice
+
+   Copyright (c) 2011 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+
+Kucherawy                 Best Current Practice                 [Page 1]
+
+RFC 6377                 DKIM and Mailing Lists           September 2011
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+     1.1.  Background . . . . . . . . . . . . . . . . . . . . . . . .  4
+     1.2.  MLMs in Infrastructure . . . . . . . . . . . . . . . . . .  4
+     1.3.  Feedback Loops and Other Bilateral Agreements  . . . . . .  5
+     1.4.  Document Scope and Goals . . . . . . . . . . . . . . . . .  6
+   2.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  6
+     2.1.  Key Words  . . . . . . . . . . . . . . . . . . . . . . . .  6
+     2.2.  Messaging Terms  . . . . . . . . . . . . . . . . . . . . .  6
+     2.3.  DKIM-Specific References . . . . . . . . . . . . . . . . .  6
+     2.4.  'DKIM-Friendly'  . . . . . . . . . . . . . . . . . . . . .  7
+     2.5.  Message Streams  . . . . . . . . . . . . . . . . . . . . .  7
+   3.  Mailing Lists and DKIM . . . . . . . . . . . . . . . . . . . .  7
+     3.1.  Roles and Realities  . . . . . . . . . . . . . . . . . . .  7
+     3.2.  Types of Mailing Lists . . . . . . . . . . . . . . . . . .  8
+     3.3.  Current MLM Effects on Signatures  . . . . . . . . . . . . 10
+   4.  Non-Participating MLMs . . . . . . . . . . . . . . . . . . . . 11
+     4.1.  Author-Related Signing . . . . . . . . . . . . . . . . . . 12
+     4.2.  Verification Outcomes at Receivers . . . . . . . . . . . . 12
+     4.3.  Handling Choices at Receivers  . . . . . . . . . . . . . . 13
+     4.4.  Wrapping a Non-Participating MLM . . . . . . . . . . . . . 13
+   5.  Participating MLMs . . . . . . . . . . . . . . . . . . . . . . 13
+     5.1.  General  . . . . . . . . . . . . . . . . . . . . . . . . . 13
+     5.2.  DKIM Author Domain Signing Practices . . . . . . . . . . . 14
+     5.3.  Subscriptions  . . . . . . . . . . . . . . . . . . . . . . 15
+     5.4.  Exceptions to ADSP Recommendations . . . . . . . . . . . . 15
+     5.5.  Author-Related Signing . . . . . . . . . . . . . . . . . . 16
+     5.6.  Verification Outcomes at MLMs  . . . . . . . . . . . . . . 16
+     5.7.  Signature Removal Issues . . . . . . . . . . . . . . . . . 17
+     5.8.  MLM Signatures . . . . . . . . . . . . . . . . . . . . . . 19
+     5.9.  Verification Outcomes at Final Receiving Sites . . . . . . 20
+     5.10. Use with FBLs  . . . . . . . . . . . . . . . . . . . . . . 20
+     5.11. Handling Choices at Receivers  . . . . . . . . . . . . . . 21
+   6.  DKIM Reporting . . . . . . . . . . . . . . . . . . . . . . . . 22
+   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 22
+     7.1.  Security Considerations from DKIM and ADSP . . . . . . . . 22
+     7.2.  Authentication Results When Relaying . . . . . . . . . . . 23
+   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
+     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 23
+     8.2.  Informative References . . . . . . . . . . . . . . . . . . 23
+   Appendix A.  Acknowledgements  . . . . . . . . . . . . . . . . . . 25
+   Appendix B.  Example Scenarios . . . . . . . . . . . . . . . . . . 25
+     B.1.  MLMs and ADSP  . . . . . . . . . . . . . . . . . . . . . . 25
+     B.2.  MLMs and FBLs  . . . . . . . . . . . . . . . . . . . . . . 25
+
+
+
+
+
+
+Kucherawy                 Best Current Practice                 [Page 2]
+
+RFC 6377                 DKIM and Mailing Lists           September 2011
+
+
+1.  Introduction
+
+   DomainKeys Identified Mail [DKIM] allows an ADministrative Management
+   Domain (ADMD) to take some responsibility for a [MAIL] message.  Such
+   responsibility can be taken by an Author's organization, an
+   operational relay (Mail Transfer Agent, or MTA), or one of their
+   agents.  Assertion of responsibility is made through a cryptographic
+   signature.  Message transit from Author to recipient is through
+   relays that typically make no substantive change to the message
+   content and thus preserve the validity of the DKIM signature.
+
+   In contrast to relays, there are intermediaries, such as Mailing List
+   Managers (MLMs), that actively take delivery of messages, reformat
+   them, and repost them, often invalidating DKIM signatures.  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.  Questions that will be discussed include:
+
+   o  Under what circumstances is it advisable for an Author, or its
+      organization, to apply DKIM to mail sent to mailing lists?
+
+   o  What are the trade-offs regarding having an MLM verify and use
+      DKIM identifiers?
+
+   o  What are the trade-offs regarding having an MLM remove existing
+      DKIM signatures prior to reposting the message?
+
+   o  What are the trade-offs regarding having an MLM add its own DKIM
+      signature?
+
+   These are open questions for which there may be no definitive
+   answers.  However, based on experience since the publication of the
+   original version of [DKIM] and its gradual deployment, there are some
+   views that are useful to consider and some recommended procedures.
+
+   In general, there are two categories of MLMs in relation to DKIM:
+   participating and non-participating.  As each type has its own issues
+   regarding DKIM-signed messages that are either handled or produced by
+   them (or both), the types are discussed in separate sections.
+
+   The best general recommendation for dealing with MLMs is that the MLM
+   or an MTA in the MLM's domain apply its own DKIM signature to each
+   message it forwards and that assessors on the receiving end consider
+   the MLM's domain signature in making their assessments.  (See
+   Section 5, especially Section 5.2.)
+
+
+
+
+
+
+Kucherawy                 Best Current Practice                 [Page 3]
+
+RFC 6377                 DKIM and Mailing Lists           September 2011
+
+
+   With the understanding that this is not always possible or practical
+   and the consideration that it might not always be sufficient, this
+   document provides additional guidance.
+
+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 relay.  Although not the only possibility, this is
+   most commonly done as a message passes through a boundary Mail
+   Transport Agent (MTA) as it departs an ADministrative Management
+   Domain (ADMD) across the open Internet.
+
+   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
+   behavior and often allow subscribers to select individual behaviors.
+   Further, the MTA might make changes that are independent of those
+   applied by the MLM.
+
+   The DKIM Signatures specification [DKIM] deliberately rejects the
+   notion of tying the signing domain (the "d=" tag in a DKIM signature)
+   to any other identifier within a message; any ADMD that handles a
+   message could 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 or less meaning
+   than a signature with any other "d=" value.
+
+1.2.  MLMs in Infrastructure
+
+   An MLM is an autonomous agent that takes delivery of a message and
+   can repost 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 reposted message.  This has
+   important implications for the use of DKIM.
+
+
+
+
+
+Kucherawy                 Best Current Practice                 [Page 4]
+
+RFC 6377                 DKIM and Mailing Lists           September 2011
+
+
+   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
+   behavior (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 need to be incremental and value-based.
+
+   Some MLM behaviors are well-established and their effects on DKIM
+   signature validity can be argued as frustrating wider DKIM adoption.
+   Still, those behaviors are not standards violations.  Hence, this
+   memo specifies practices for all parties involved, defining the
+   minimum changes possible to MLMs themselves.
+
+   A DKIM signature on a message is an expression of some responsibility
+   for the message taken by the signing domain.  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 not have been rendered invalid.  The
+   document also considers how invalidation might have happened.
+
+   Note that where in this document there is discussion of an MLM
+   conducting validation of DKIM signatures or Author Domain Signing
+   Practices ([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 favor any particular arrangement of these agents
+   over another; it merely talks about the MLM itself doing the work as
+   a matter of simplicity.
+
+1.3.  Feedback Loops and Other Bilateral Agreements
+
+   A Feedback Loop (FBL) is a bilateral 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 bilateral registration.  Some FBLs require DKIM
+   use by the registrant.
+
+   See Section 6 for additional discussion.
+
+   FBLs tend to use the [ARF] or the [IODEF] formats.
+
+
+
+
+
+
+Kucherawy                 Best Current Practice                 [Page 5]
+
+RFC 6377                 DKIM and Mailing Lists           September 2011
+
+
+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,
+   the preference is to impose changes to behavior at the Signer and
+   Verifier rather than at the MLM.
+
+   Wherever possible, the document's discussion of MLMs is conceptually
+   decoupled from MTAs 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
+   predictive in nature, taking into account the current email
+   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
+   their efficacy, performance, and security characteristics have not
+   yet been fully explored.
+
+2.  Definitions
+
+2.1.  Key Words
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   [KEYWORDS].
+
+2.2.  Messaging Terms
+
+   See [EMAIL-ARCH] for a general description of the current messaging
+   architecture and for definitions of various terms used in this
+   document.
+
+2.3.  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.
+
+
+
+
+
+
+
+
+
+Kucherawy                 Best Current Practice                 [Page 6]
+
+RFC 6377                 DKIM and Mailing Lists           September 2011
+
+
+2.4.  'DKIM-Friendly'
+
+   The term "DKIM-friendly" is used to describe an email intermediary
+   that, when handling a message, makes no changes to the message that
+   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.
+
+2.5.  Message Streams
+
+   A "message stream" identifies a group of messages originating from
+   within an ADMD that are distinct in intent, origin, and/or use and
+   partitions them somehow (e.g., 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 or marketing or sales campaigns.  Each of these could have
+   different sending 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 styles of
+   intermediaries, their typical implementations, and the effects they
+   have in a DKIM-aware environment.
+
+3.1.  Roles and Realities
+
+   Across DKIM activities, there are several key roles in the transit of
+   a message.  Most of these are defined in [EMAIL-ARCH] but are
+   reviewed here for quick reference.
+
+   Author:  The agent that provided the content of the message being
+      sent through the system.  The Author delivers that content to the
+      Originator in order to begin a message's journey to its intended
+      final recipients.  The Author can be a human using an MUA (Mail
+      User Agent) or an automated process that may send mail (for
+      example, the "cron" Unix system utility).
+
+
+
+
+Kucherawy                 Best Current Practice                 [Page 7]
+
+RFC 6377                 DKIM and Mailing Lists           September 2011
+
+
+   Originator:  The agent that accepts a message from the Author,
+      ensures it conforms to the relevant standards such as [MAIL], and
+      then sends it toward its destination(s).  This is often referred
+      to as the Mail Submission Agent (MSA).
+
+   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 validation.  One is
+      typically running at the MTA that sits between the public Internet
+      and the Receiver's ADMD.  Note that any agent that handles a
+      signed message can conduct verification; this document 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
+      and performs final delivery 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.  This is sometimes the same as or coupled with the
+      Mail Delivery Agent (MDA).
+
+   In the case of simple user-to-user mail, these roles are fairly
+   straightforward.  However, when one is sending mail to a list and the
+   mail 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:
+
+   aliasing:  An aliasing MLM (see Section 5.1 of [EMAIL-ARCH]) is one
+      that makes no changes to the message itself 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 header or body 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 transit.  An example of such an MLM is an address that
+
+
+
+
+
+Kucherawy                 Best Current Practice                 [Page 8]
+
+RFC 6377                 DKIM and Mailing Lists           September 2011
+
+
+      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
+      reposted message.  Such messages are often reformatted, 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 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.  Typically, replies are not
+      generated, or if they are, they go to a specific recipient and not
+      back to the list's full set of recipients.  Examples include
+      newsletters and bulk marketing mail.
+
+   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
+   phases 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
+
+
+
+Kucherawy                 Best Current Practice                 [Page 9]
+
+RFC 6377                 DKIM and Mailing Lists           September 2011
+
+
+   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; thus,
+   there is never an existing signature.  However, the changes a
+   resending MLM typically makes affect the RFC5322.Subject header
+   field, the addition of some list-specific header fields, and/or the
+   modification of the message body.  The effects of each of these on
+   DKIM verification are discussed below.
+
+   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 in the hash when
+      creating that signature.  Section 5.5 of [DKIM] lists
+      RFC5322.Subject as one that should be covered as it contains
+      important user-visible text, so this is expected to be an issue
+      for any list that 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 not seen as a
+      concern.
+
+   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
+      included in the signature hash, and those signatures will thus be
+      broken.
+
+
+
+
+
+Kucherawy                 Best Current Practice                [Page 10]
+
+RFC 6377                 DKIM and Mailing Lists           September 2011
+
+
+   Minor body changes:  Some lists prepend or append a few lines to each
+      message to remind subscribers of an administrative URL for
+      subscription issues, 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.  [DKIM] includes the capability to
+      limit the length of the body covered by its body hash so that
+      appended text will not interfere with signature validation, but
+      this has security implications.
+
+   Major body changes:  There are some MLMs that make more substantial
+      changes to message bodies when preparing them for redistribution,
+      such as adding, deleting, reordering, or reformatting [MIME]
+      parts, "flattening" HTML messages into plain text, or inserting
+      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 some cases
+      where a body length limit is applied in generation of the DKIM
+      signature, the signature will be broken.
+
+   There reportedly still exist some mailing lists in 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.
+
+
+
+
+
+
+Kucherawy                 Best Current Practice                [Page 11]
+
+RFC 6377                 DKIM and Mailing Lists           September 2011
+
+
+4.1.  Author-Related Signing
+
+   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 needs to be cautious when deciding whether or not to send a
+   signed message to the list.  The MLM could make a change that would
+   invalidate the Author's signature but not remove it prior to
+   redistribution.  Hence, list recipients would receive a message
+   purportedly from the Author but bearing a DKIM signature that would
+   not verify.  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.
+   (Additional discussion of this is below.)  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.
+
+   For domains that do publish strict ADSP policies, the originating
+   site SHOULD use a separate message stream (see Section 2.5), such as
+   a signing and Author subdomain, for the "personal" mail -- a
+   subdomain that is 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 stricter 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, 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.  (See also Section 5.7 below.)
+
+4.2.  Verification Outcomes at Receivers
+
+   There is no reliable way to determine that a piece of mail arrived
+   via a non-participating MLM.  Sites whose users subscribe to non-
+   participating MLMs SHOULD ensure that such user mail streams are not
+   subject to strict DKIM-related handling policies.
+
+
+
+Kucherawy                 Best Current Practice                [Page 12]
+
+RFC 6377                 DKIM and Mailing Lists           September 2011
+
+
+4.3.  Handling Choices at Receivers
+
+   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.
+
+   Any treatment of a verification failure as having special meaning is
+   a violation of the basic DKIM Signatures specification [DKIM].  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 honor the
+   policy and disallow the message.
+
+4.4.  Wrapping a Non-Participating MLM
+
+   One approach for adding DKIM support to an otherwise non-
+   participating MLM is to "wrap" the MLM or, in essence, place it
+   between other DKIM-aware components (such as MTAs) that provide some
+   DKIM services.  For example, the ADMD operating a non-participating
+   MLM could have its DKIM Verifier act on messages from list
+   subscribers, enforcing some of the features and 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.
+
+5.  Participating MLMs
+
+   This section contains a discussion of issues regarding DKIM-signed
+   mail that transits an MLM that is DKIM-aware.
+
+5.1.  General
+
+   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.  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]).
+
+
+
+
+Kucherawy                 Best Current Practice                [Page 13]
+
+RFC 6377                 DKIM and Mailing Lists           September 2011
+
+
+   However, the practice of applying headers and footers to message
+   bodies is common and not expected to fade regardless of what
+   documents 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]).  Therefore, its use is
+   discouraged.
+
+   Expressions of list-specific policy (e.g., rules for participation,
+   small advertisements, etc.) are often added to outgoing messages by
+   MLM operators.  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 commonly
+   included footer text appended to the body of the message or header
+   text prepended above the original body.  It is RECOMMENDED that
+   periodic, automatic mailings to the list are sent to remind
+   subscribers of list policy.  It is also RECOMMENDED that standard
+   header fields, rather than body changes, be used to express list
+   operation parameters.  These periodic mailings will be repetitive, of
+   course, but by being generally the same each time, they can be easily
+   filtered if desired.
+
+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.  A resending MLM SHOULD
+   reject outright any mail from an Author whose domain posts such a
+   policy, as those messages are likely to be discarded or rejected by
+   any ADSP-aware recipients.  See also the discussion in Section 5.3.
+
+   Where such rejection of "discardable" mail is not enforced, and such
+   mail arrives to a Verifier that applies ADSP checks that fail, the
+   message SHOULD be either discarded (i.e., accept the message at the
+   [SMTP] level but discard it without delivery) or rejected by
+   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.11.
+
+
+
+
+
+Kucherawy                 Best Current Practice                [Page 14]
+
+RFC 6377                 DKIM and Mailing Lists           September 2011
+
+
+   The reason for these recommendations is best illustrated by example.
+   Suppose the following:
+
+   o  users U1 and U2 are subscribers of list L;
+
+   o  U1 is within an ADMD that advertises a "discardable" policy using
+      ADSP;
+
+   o  L alters submissions prior to resending in a way that invalidates
+      the DKIM signature added by U1's ADMD;
+
+   o  U2's ADMD enforces ADSP at the border by issuing an SMTP error
+      code; and
+
+   o  L is configured to remove subscribers whose mail is bouncing.
+
+   It follows then that a submission to L from U1 will be received at
+   U2, but since the DKIM signature fails to verify, U2's ADMD will
+   reject it based on the ADSP protocol.  That rejection is received at
+   L, which proceeds to remove U2 from the list.
+
+   See also Appendix B.5 of [ADSP] for further discussion.
+
+5.3.  Subscriptions
+
+   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 published policy
+   of the subscriber's ADMD.
+
+   Of course, such a policy record could be created after subscription,
+   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.  Exceptions to ADSP Recommendations
+
+   Where an ADMD has established some out-of-band trust agreement with
+   another ADMD such that an Authentication-Results field applied by one
+   is trusted by the other, the above recommendations for MLM operation
+   with respect to ADSP do not apply because it is then possible to
+   establish whether or not a valid Author signature can be inferred
+   even if one is not present on receipt.
+
+
+
+
+
+
+Kucherawy                 Best Current Practice                [Page 15]
+
+RFC 6377                 DKIM and Mailing Lists           September 2011
+
+
+   For example, suppose domains example.com and example.net have an
+   explicit agreement to trust one another's authentication assertions.
+   Now, consider a message with an RFC5322.From domain of "example.org"
+   that is also bearing a valid DKIM signature by the same domain, which
+   arrives at a mailing list run by example.com.  Upon evaluation,
+   example.com validates the signature and adds an [AUTH-RESULTS] field
+   indicating this.  However, the MLM also makes changes to the message
+   body that invalidate the signature.  The MLM then re-signs the
+   modified message using DKIM and sends it on to the list's
+   subscribers, one of whom is at example.net.
+
+   On arrival at example.net, the DKIM signature for example.org is no
+   longer valid, so ADSP would generally fail.  However, example.net
+   trusts the assertion of example.com's Authentication-Results field
+   that indicated that there was a valid signature from example.org, so
+   the ADSP failure can be ignored.
+
+5.5.  Author-Related Signing
+
+   An important consideration is that Authors rarely have any direct
+   influence over the management of an MLM.  Specifically, the behavior
+   of an intermediary (e.g., an MLM that is not careful about filtering
+   out junk mail or being diligent about unsubscription requests) can
+   trigger recipient complaints that reflect back on those agents that
+   appear to be responsible for the message, in this case an Author via
+   the address found in the RFC5322.From field.  In the future, as DKIM
+   signature outputs (i.e., the signing domain) 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 DKIM signatures when sending traffic
+   to MLMs.
+
+   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 by either MLMs or users, SHOULD be signed with a
+   mail stream identifier different from that used for a stream that
+   serves more varied uses.
+
+5.6.  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 subscription registry.
+   DKIM enables a stronger form of authentication: the MLM can require
+   that messages using a given RFC5322.From address also have a DKIM
+
+
+
+
+Kucherawy                 Best Current Practice                [Page 16]
+
+RFC 6377                 DKIM and Mailing Lists           September 2011
+
+
+   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, however, that this goes beyond DKIM's documented semantics.
+   It is presented as a possible workable enhancement.)
+
+   As described, the MLM might conduct DKIM verification of a signed
+   message to attempt to confirm the identity of the Author.  Although
+   it is a common and intuitive conclusion, few signed messages will
+   include an Author signature (see [ADSP]).  MLM implementers adding
+   such support would have to accommodate this.  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.  This
+   enables a more reliable method of authentication at the expense of
+   having to store a mapping of authorized signing domains for
+   subscribers and trusting that it will be kept current.
+
+   A message that cannot be thus authenticated MAY be held for
+   moderation or rejected outright.
+
+   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 might or might not
+   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.7.  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 original assertion of responsibility for the
+   message so that the Receivers of the final message have an
+   opportunity to evaluate the message with that information available
+   to them.
+
+
+
+
+
+Kucherawy                 Best Current Practice                [Page 17]
+
+RFC 6377                 DKIM and Mailing Lists           September 2011
+
+
+   However, if the MLM is configured to make changes to the message
+   prior to reposting 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 includes in its hashes the entire
+       message on the output side, including the Authentication-Results
+       header field just added (see Section 5.8).
+
+   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 for list 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.
+
+   Per the discussion in [AUTH-RESULTS], a Receiver's choice to put any
+   faith in the veracity of the header field requires an a priori
+   assessment of the agent that created it.  Absent that assessment, a
+   Receiver cannot interpret the field as valid.  Thus, the final
+   recipients of the 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 only one on the message when the Verifier gets it,
+   and the Verifier explicitly trusts the Signer that included the
+
+
+
+Kucherawy                 Best Current Practice                [Page 18]
+
+RFC 6377                 DKIM and Mailing Lists           September 2011
+
+
+   Authentication-Results field in its header hash (in this case, the
+   MLM), the Verifier is 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 that 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 at least arrive to the next MTA unmodified.  It is
+   possible that future domain-based reputations would prefer a richer
+   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.8.  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 resending 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.
+
+   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, as any other MLM, is 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
+   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 could add a List-Post: header field (see [LIST-URLS])
+   using the DNS domain matching the one used in the "d=" tag of the
+   DKIM signature that is added by the MLM.  This can be used by
+   Verifiers or Receivers to identify the DKIM signature that was added
+   by the MLM.  This is not required, however; it is believed the
+
+
+
+
+
+Kucherawy                 Best Current Practice                [Page 19]
+
+RFC 6377                 DKIM and Mailing Lists           September 2011
+
+
+   reputation of the Signer will be a more critical data point than this
+   suggested binding.  Furthermore, this is not a binding recognized by
+   any current specification document.
+
+   A DKIM-aware resending MLM SHOULD sign the entire message after the
+   message is prepared for distribution (i.e., the MLM Output from
+   Section 3.2).  Any other configuration might generate signatures that
+   will not validate.
+
+   DKIM-aware authoring MLMs 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.
+
+5.9.  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 Sections 4.3 and 5.7, especially where an ADMD has
+   misused ADSP.
+
+5.10.  Use with FBLs
+
+   An FBL operator might wish to act on a complaint from a user about a
+   message sent to a list.  Some FBLs could choose to generate feedback
+   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.
+
+   MLM operators SHOULD register with FBLs from major service providers.
+   In the context of DKIM, there SHOULD be an exchange of information
+   with the FBL provider including what signing domain the MLM will use,
+   if any.
+
+
+
+
+Kucherawy                 Best Current Practice                [Page 20]
+
+RFC 6377                 DKIM and Mailing Lists           September 2011
+
+
+   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.
+
+   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
+   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 behavior,
+   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 is thus
+   undesirable.
+
+5.11.  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 Sections 5 and 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, [SMTP] stipulates that 550 is the
+   correct response code.  However, if the SMTP server supports
+   [ENHANCED] status codes, a status code not normally used for "user
+   unknown" (5.1.1) is preferred; therefore, a 5.7.0 code SHOULD be
+   used.  If the rejecting SMTP server supports this, it thus makes a
+   distinction between messages rejected deliberately due to policy
+
+
+
+Kucherawy                 Best Current Practice                [Page 21]
+
+RFC 6377                 DKIM and Mailing Lists           September 2011
+
+
+   decisions rather than those rejected because of other delivery
+   issues.  In particular, a policy rejection SHOULD be relayed using
+   the above enhanced status code and some appropriate wording in the
+   text part of the reply.  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.  It would also be
+   beneficial for SMTP servers doing so to use appropriate wording in
+   the text portion of the reply, perhaps explicitly using the string
+   "ADSP" to facilitate searching for 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.
+
+6.  DKIM Reporting
+
+   As mechanisms become available for reporting forensic details about
+   DKIM verification failures, MLMs will benefit from their use.
+
+   MLMs SHOULD apply 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.  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 practices described in this
+   document.
+
+7.1.  Security Considerations from DKIM and ADSP
+
+   Readers should be familiar with the material in the "Security
+   Considerations" sections in [DKIM], [ADSP], and [AUTH-RESULTS] as
+   appropriate.
+
+
+
+
+
+
+
+
+
+Kucherawy                 Best Current Practice                [Page 22]
+
+RFC 6377                 DKIM and Mailing Lists           September 2011
+
+
+7.2.  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.
+
+8.  References
+
+8.1.  Normative References
+
+   [ADSP]     Allman, E., Fenton, J., Delany, M., and J. Levine,
+              "DomainKeys Identified Mail (DKIM) Author Domain Signing
+              Practices (ADSP)", RFC 5617, August 2009.
+
+   [AUTH-RESULTS]
+              Kucherawy, M., "Message Header Field for Indicating
+              Message Authentication Status", RFC 5451, April 2009.
+
+   [DKIM]     Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
+              "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376,
+              September 2011.
+
+   [EMAIL-ARCH]
+              Crocker, D., "Internet Mail Architecture", RFC 5598,
+              July 2009.
+
+   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [MAIL]     Resnick, P., Ed., "Internet Message Format", RFC 5322,
+              October 2008.
+
+8.2.  Informative References
+
+   [ARF]      Shafranovich, Y., Levine, J., and M. Kucherawy, "An
+              Extensible Format for Email Feedback Reports", RFC 5965,
+              August 2010.
+
+   [DKIM-DEPLOYMENT]
+              Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker,
+              "DomainKeys Identified Mail (DKIM) Development,
+              Deployment, and Operations", RFC 5863, May 2010.
+
+
+
+Kucherawy                 Best Current Practice                [Page 23]
+
+RFC 6377                 DKIM and Mailing Lists           September 2011
+
+
+   [DKIM-OVERVIEW]
+              Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys
+              Identified Mail (DKIM) Service Overview", RFC 5585,
+              July 2009.
+
+   [ENHANCED] Vaudreuil, G., "Enhanced Mail System Status Codes",
+              RFC 3463, January 2003.
+
+   [IODEF]    Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident
+              Object Description Exchange Format", RFC 5070,
+              December 2007.
+
+   [LIST-ID]  Chandhok, R. and G. Wenger, "List-Id: A Structured Field
+              and Namespace for the Identification of Mailing Lists",
+              RFC 2919, March 2001.
+
+   [LIST-URLS]
+              Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax
+              for Core Mail List Commands and their Transport through
+              Message Header Fields", RFC 2369, July 1998.
+
+   [MIME]     Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+              Extensions (MIME) Part One: Format of Internet Message
+              Bodies", RFC 2045, November 1996.
+
+   [MIME-TYPES]
+              Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+              Extensions (MIME) Part Two: Media Types", RFC 2046,
+              November 1996.
+
+   [SMTP]     Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
+              October 2008.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kucherawy                 Best Current Practice                [Page 24]
+
+RFC 6377                 DKIM and Mailing Lists           September 2011
+
+
+Appendix A.  Acknowledgements
+
+   The author wishes to acknowledge the following individuals for their
+   review and constructive criticism of this document: Serge Aumont,
+   Daniel Black, Dave Crocker, J.D. Falk, Tony Hansen, Eliot Lear,
+   Charles Lindsey, John Levine, Jeff Macdonald, S. Moonesamy, Rolf E.
+   Sonneveld, and Alessandro Vesely.
+
+Appendix B.  Example Scenarios
+
+   This section describes a few MLM-related DKIM scenarios that were
+   part of the impetus for this work and the recommended resolutions for
+   each.
+
+B.1.  MLMs and ADSP
+
+   Problem:
+
+   o  Author ADMD advertises an ADSP policy of "dkim=discardable"
+
+   o  Author sends DKIM-signed mail to a non-participating MLM, which
+      invalidates the signature
+
+   o  Receiver MTA checks DKIM and ADSP at SMTP time and is configured
+      to reject ADSP failures, so rejects this message
+
+   o  process repeats a few times, after which the MLM unsubscribes the
+      Receiver
+
+   Solution: MLMs should refuse mail from domains advertising ADSP
+   policies of "discardable" unless the MLMs are certain they make no
+   changes that invalidate DKIM signatures.
+
+B.2.  MLMs and FBLs
+
+   Problem:
+
+   o  subscriber sends signed mail to a non-participating MLM that does
+      not invalidate the signature
+
+   o  a recipient reports the message as spam
+
+   o  FBL at recipient ADMD sends report to contributor rather than list
+      manager
+
+
+
+
+
+
+
+Kucherawy                 Best Current Practice                [Page 25]
+
+RFC 6377                 DKIM and Mailing Lists           September 2011
+
+
+   Solution: MLMs should sign mail they send and might also strip
+   existing signatures.  FBLs should report to list operators instead of
+   subscribers where such can be distinguished; otherwise, FBLs should
+   report to all parties with valid signatures.
+
+Author's Address
+
+   Murray S. Kucherawy
+   Cloudmark
+   128 King St., 2nd Floor
+   San Francisco, CA  94107
+   USA
+
+   Phone: +1 415 946 3800
+   EMail: msk@cloudmark.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kucherawy                 Best Current Practice                [Page 26]
+