Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools

Problem, Formatting or Query -  Send Feedback

Was this page helpful?-10+1


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


 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

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

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
 ( 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
 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",
 "OPTIONAL" in this document are to be interpreted as described in

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

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

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

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
 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
 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
 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 and have an
 explicit agreement to trust one another's authentication assertions.
 Now, consider a message with an RFC5322.From domain of ""
 that is also bearing a valid DKIM signature by the same domain, which
 arrives at a mailing list run by  Upon evaluation, 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
 On arrival at, the DKIM signature for is no
 longer valid, so ADSP would generally fail.  However,
 trusts the assertion of's Authentication-Results field
 that indicated that there was a valid signature from, 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
 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
 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
 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

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

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

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

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

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

B.1. MLMs and ADSP

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

 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

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
 128 King St., 2nd Floor
 San Francisco, CA  94107
 Phone: +1 415 946 3800

Kucherawy Best Current Practice [Page 26]

/data/webs/external/dokuwiki/data/pages/rfc/bcp/bcp167.txt · Last modified: 2011/09/21 17:54 (external edit)