< draft-ietf-dkim-mailinglists-06.txt   draft-ietf-dkim-mailinglists-07.txt >
DKIM Working Group M. Kucherawy DKIM Working Group M. Kucherawy
Internet-Draft Cloudmark Internet-Draft Cloudmark
Intended status: BCP March 28, 2011 Intended status: BCP April 25, 2011
Expires: September 29, 2011 Expires: October 27, 2011
DKIM And Mailing Lists DKIM And Mailing Lists
draft-ietf-dkim-mailinglists-06 draft-ietf-dkim-mailinglists-07
Abstract Abstract
DomainKeys Identified Mail (DKIM) allows an administrative mail DomainKeys Identified Mail (DKIM) allows an administrative mail
domain (ADMD) to assume some responsibility for a message. As the domain (ADMD) to assume some responsibility for a message. Based on
industry has now gained some deployment experience, the goal for this deployment experience with DKIM, this Best Current Practices document
document is to explore the use of DKIM for scenarios that include provides guidance for the use of DKIM with scenarios that include
intermediaries, such as Mailing List Managers (MLMs) and describe the Mailing List Managers (MLMs). {DKIM 12}
Best Current Practices.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 29, 2011. This Internet-Draft will expire on October 27, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Notes to Editor and Reviewers . . . . . . . . . . . . . . . . 3
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. MLMs In Infrastructure . . . . . . . . . . . . . . . . . . 4 2.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Feedback Loops And Other Bi-Lateral Agreements . . . . . . 5 2.2. MLMs In Infrastructure . . . . . . . . . . . . . . . . . . 5
1.4. Document Scope and Goals . . . . . . . . . . . . . . . . . 6 2.3. Feedback Loops And Other Bi-Lateral Agreements . . . . . . 6
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.4. Document Scope and Goals . . . . . . . . . . . . . . . . . 6
2.1. Other Terms . . . . . . . . . . . . . . . . . . . . . . . 7 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2. DKIM-Specific References . . . . . . . . . . . . . . . . . 7 3.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3. 'DKIM-Friendly' . . . . . . . . . . . . . . . . . . . . . 7 3.2. Messaging Terms . . . . . . . . . . . . . . . . . . . . . 8
2.4. Message Streams . . . . . . . . . . . . . . . . . . . . . 7 3.3. DKIM-Specific References . . . . . . . . . . . . . . . . . 8
3. Mailing Lists and DKIM . . . . . . . . . . . . . . . . . . . . 8 3.4. 'DKIM-Friendly' . . . . . . . . . . . . . . . . . . . . . 8
3.1. Roles and Realities . . . . . . . . . . . . . . . . . . . 8 3.5. Message Streams . . . . . . . . . . . . . . . . . . . . . 8
3.2. Types Of Mailing Lists . . . . . . . . . . . . . . . . . . 9 4. Mailing Lists and DKIM . . . . . . . . . . . . . . . . . . . . 9
3.3. Current MLM Effects On Signatures . . . . . . . . . . . . 10 4.1. Roles and Realities . . . . . . . . . . . . . . . . . . . 9
4. Non-Participating MLMs . . . . . . . . . . . . . . . . . . . . 12 4.2. Types Of Mailing Lists . . . . . . . . . . . . . . . . . . 10
4.1. Author-Related Signing . . . . . . . . . . . . . . . . . . 12 4.3. Current MLM Effects On Signatures . . . . . . . . . . . . 11
4.2. Verification Outcomes at Receivers . . . . . . . . . . . . 13 5. Non-Participating MLMs . . . . . . . . . . . . . . . . . . . . 14
4.3. Handling Choices at Receivers . . . . . . . . . . . . . . 13 5.1. Author-Related Signing . . . . . . . . . . . . . . . . . . 14
4.4. Wrapping A Non-Participating MLM . . . . . . . . . . . . . 13 5.2. Verification Outcomes at Receivers . . . . . . . . . . . . 15
5. Participating MLMs . . . . . . . . . . . . . . . . . . . . . . 14 5.3. Handling Choices at Receivers . . . . . . . . . . . . . . 15
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.4. Wrapping A Non-Participating MLM . . . . . . . . . . . . . 15
5.2. DKIM Author Domain Signing Practices . . . . . . . . . . . 15 6. Participating MLMs . . . . . . . . . . . . . . . . . . . . . . 16
5.3. Subscriptions . . . . . . . . . . . . . . . . . . . . . . 15 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.4. Author-Related Signing . . . . . . . . . . . . . . . . . . 15 6.2. DKIM Author Domain Signing Practices . . . . . . . . . . . 16
5.5. Verification Outcomes at MLMs . . . . . . . . . . . . . . 16 6.3. Subscriptions . . . . . . . . . . . . . . . . . . . . . . 17
5.6. Signature Removal Issues . . . . . . . . . . . . . . . . . 17 6.4. Exceptions To ADSP Recommendations . . . . . . . . . . . . 17
5.7. MLM Signatures . . . . . . . . . . . . . . . . . . . . . . 18 6.5. Author-Related Signing . . . . . . . . . . . . . . . . . . 17
5.8. Verification Outcomes at Final Receiving Sites . . . . . . 19 6.6. Verification Outcomes at MLMs . . . . . . . . . . . . . . 18
5.9. Use With FBLs . . . . . . . . . . . . . . . . . . . . . . 20 6.7. Signature Removal Issues . . . . . . . . . . . . . . . . . 19
5.10. Handling Choices at Receivers . . . . . . . . . . . . . . 20 6.8. MLM Signatures . . . . . . . . . . . . . . . . . . . . . . 20
6. DKIM Reporting . . . . . . . . . . . . . . . . . . . . . . . . 22 6.9. Verification Outcomes at Final Receiving Sites . . . . . . 22
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 6.10. Use With FBLs . . . . . . . . . . . . . . . . . . . . . . 22
8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 6.11. Handling Choices at Receivers . . . . . . . . . . . . . . 23
8.1. Authentication Results When Relaying . . . . . . . . . . . 24 7. DKIM Reporting . . . . . . . . . . . . . . . . . . . . . . . . 25
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
9.1. Normative References . . . . . . . . . . . . . . . . . . . 25 9. Security Considerations . . . . . . . . . . . . . . . . . . . 27
9.2. Informative References . . . . . . . . . . . . . . . . . . 25 9.1. Security Considerations from DKIM and ADSP . . . . . . . . 27
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 27 9.2. Authentication Results When Relaying . . . . . . . . . . . 27
Appendix B. Example Scenarios . . . . . . . . . . . . . . . . . . 28 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
B.1. MLMs and ADSP . . . . . . . . . . . . . . . . . . . . . . 28 10.1. Normative References . . . . . . . . . . . . . . . . . . . 28
B.2. MLMs and FBLs . . . . . . . . . . . . . . . . . . . . . . 28 10.2. Informative References . . . . . . . . . . . . . . . . . . 28
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 29 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 30
Appendix B. Example Scenarios . . . . . . . . . . . . . . . . . . 31
B.1. MLMs and ADSP . . . . . . . . . . . . . . . . . . . . . . 31
B.2. MLMs and FBLs . . . . . . . . . . . . . . . . . . . . . . 31
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Notes to Editor and Reviewers
This version of the memo contains notations such as "{DKIM 2}".
These correspond to DKIM working group issue tracker items. They
should be deleted prior to publication.
2. Introduction
DomainKeys Identified Mail ([DKIM]) allows an Administrative Mail DomainKeys Identified Mail ([DKIM]) allows an Administrative Mail
Domain to take some responsibility for a [MAIL] message. This can be Domain to take some responsibility for a [MAIL] message. This can be
an author's organization, an operational relay (Mail Transfer Agent, an author's organization, an operational relay (Mail Transfer Agent,
or MTA) or one of their agents. Assertion of responsibility is made or MTA) or one of their agents. Assertion of responsibility is made
through a cryptographic signature. Message transit from author to through a cryptographic signature. Message transit from author to
recipient is through relays that typically make no substantive change recipient is through relays that typically make no substantive change
to the message content and thus preserve the validity of the DKIM to the message content and thus preserve the validity of the DKIM
signature. signature.
skipping to change at page 3, line 41 skipping to change at page 4, line 41
o What are the tradeoffs regarding having an MLM add its own DKIM o What are the tradeoffs regarding having an MLM add its own DKIM
signature? signature?
These and others are open questions for which there may be no These and others are open questions for which there may be no
definitive answers. However, based on experience since the definitive answers. However, based on experience since the
publication of [DKIM] and its gradual deployment, there are some publication of [DKIM] and its gradual deployment, there are some
views that are useful to consider and some recommended procedures. views that are useful to consider and some recommended procedures.
In general there are, in relation to DKIM, two categories of MLMs: In general there are, in relation to DKIM, two categories of MLMs:
participating and non-participating. As each types has its own participating and non-participating. As each type has its own issues
issues regarding DKIM-signed messages that are either handled or regarding DKIM-signed messages that are either handled or produced by
produced by them (or both), the types are discussed in separate them (or both), the types are discussed in separate sections.
sections.
1.1. Background 2.1. Background
DKIM signatures permit an agent of the email architecture (see DKIM signatures permit an agent of the email architecture (see
[EMAIL-ARCH]) to make a claim of responsibility for a message by [EMAIL-ARCH]) to make a claim of responsibility for a message by
affixing a validated domain-level identifier to the message as it affixing a validated domain-level identifier to the message as it
passes through a gateway. Although not the only possibility, this is passes through a relay. {DKIM 12} Although not the only possibility,
most commonly done as a message passes through a Mail Transport Agent this is most commonly done as a message passes through a boundary
(MTA) as it departs an Administrative Mail Domain (ADMD) toward the Mail Transport Agent (MTA) as it departs an Administrative Mail
general Internet. Domain (ADMD) across the open Internet. {DKIM 12}
A DKIM signature will fail to verify if a portion of the message 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 covered by one of its hashes is altered. An MLM commonly alters
messages to provide information specific to the mailing list for messages to provide information specific to the mailing list for
which it is providing service. Common modifications are enumerated which it is providing service. Common modifications are enumerated
and described in Section 3.3. However, note that MLMs vary widely in and described in Section 4.3. However, note that MLMs vary widely in
behaviour as well as often allowing subscribers to select individual behaviour as well as often allowing subscribers to select individual
behaviours. Further, this does not consider changes the MTA might behaviours. Further, the MTA might make changes that are independent
make independent of what changes the MLM chooses to apply. of those applied by the MLM. {DKIM 12}
The DKIM specification document deliberately refrains from the notion
of tying the signing domain (the "d=" tag in a DKIM signature) to any
identifier within a message; any ADMD that handles a message could
sign it, regardless of its origin or author domain. In particular,
DKIM does not define any meaning to the occurrence of a match between
the content of a "d=" tag and the value of, for example, a domain
name in the RFC5322.From field, nor is there any obvious degraded
value to a signature where they do not match. Since any DKIM
signature is merely an assertion of "some" responsibility by an ADMD,
a DKIM signature added by an MLM has no more, nor less, meaning than
a signature with any other "d=" value.
1.2. MLMs In Infrastructure
Section 3.3 describes some of the things MLMs commonly do that
produce broken signatures, thus reducing the perceived value of DKIM.
Further, while there are published standards that are specific to MLM The DKIM signing specification deliberately rejects the notion of
behaviour (e.g. [MAIL], [LIST-ID] and [LIST-URLS]), their adoption tying the signing {DKIM 12} domain (the "d=" tag in a DKIM signature)
has been spotty at best. Hence, efforts to specify the use of DKIM to any other identifier {DKIM 12} within a message; any ADMD that
in the context of MLMs needs to be incremental and value-based. 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, nor less, meaning than a signature with any other "d=" value.
Other MLM behaviours are well-established. Although it can be argued 2.2. MLMs In Infrastructure
that they frustrate widespread DKIM adoption, it cannot be said that
such behaviours are not standards compliant. Thus, the best approach
is to provide these best practices to all parties involved, imposing
the minimum requirements possible to MLMs themselves.
An MLM is an autonomous agent that takes delivery of a message and An MLM is an autonomous agent that takes delivery of a message and
can re-post it as a new message, or construct a digest of it along can re-post it as a new message, or construct a digest of it along
with other messages to the members of the list (see [EMAIL-ARCH], 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 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 a message (in the non-digest case) is typically the same as that of
the original message, and that recipients perceive the message as the original message, and that recipients perceive the message as
"from" the original author rather than the MLM, creates confusion "from" the original author rather than the MLM, creates confusion
about responsibility and autonomy for the re-posted message. This about responsibility and autonomy for the re-posted message. This
has important implications for use of DKIM. has important implications for use of DKIM. {DKIM 12}
Section 4.3 describes some of the things MLMs commonly do that
produce broken signatures, thus reducing the perceived value of DKIM.
Further, while there are published standards that are specific to MLM
behaviour (e.g. [MAIL], [LIST-ID] and [LIST-URLS]), their adoption
has been spotty at best. Hence, efforts to specify the use of DKIM
in the context of MLMs needs to be incremental and value-based.
Some MLM behaviours are well-established and their effects on DKIM
signature validity can be argued as frustrating wider DKIM adoption.
Still, those behaviors are not standards violations. Hence, the best
approach for a BCP effort is to specify practices for all parties
involved, defining the minimum changes possible to MLMs themselves.
{DKIM 12}
A DKIM signature on a message is an expression of some responsibility A DKIM signature on a message is an expression of some responsibility
for the message taken by the signing domain. An open issue, and one for the message taken by the signing domain. An open issue that is
this document intends to address, is some idea of how such a addressed by this document is the ways a signature might be used by a
signature might be used by a recipient's evaluation module after the recipient's evaluation module, after the message has gone through a
message has gone through a mailing list and may or may not have been mailing list and might or might not have been rendered invalid. The
invalidated, and if it has, where and how the invalidation may have document also considers how invalidation might have happened. {DKIM
happened. 12}
Note that where in this document there is discussion of an MLM Note that where in this document there is discussion of an MLM
conducting validation of DKIM signatures or ADSP policies, the actual conducting validation of DKIM signatures or ADSP policies, the actual
implementation could be one where the validation is done by the MTA 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 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 by a trusted channel not specified here. See [AUTH-RESULTS] for a
discussion of this. This document does not favour any particular discussion of this. This document does not favour any particular
arrangement of these agents over another, but merely talks about the arrangement of these agents over another, but merely talks about the
MLM itself doing the work as a matter of simplicity. MLM itself doing the work as a matter of simplicity.
1.3. Feedback Loops And Other Bi-Lateral Agreements 2.3. Feedback Loops And Other Bi-Lateral Agreements
A Feedback Loop (FBL) is a bi-lateral agreement between two parties A Feedback Loop (FBL) is a bi-lateral agreement between two parties
to exchange reports of abuse. Typically, a sender registers with a to exchange reports of abuse. Typically, a sender registers with a
receiving site to receive abuse reports from that site for mail receiving site to receive abuse reports from that site for mail
coming from the sender. coming from the sender.
An FBL reporting address (i.e., an address to which FBL reports are An FBL reporting address (i.e., an address to which FBL reports are
sent) is part of this bi-lateral registration. Some FBLs require sent) is part of this bi-lateral registration. Some FBLs require
DKIM use by the registrant. DKIM use by the registrant.
A DKIM-signed message sent to an MLM, and then distributed to all of See Section 7 for additional discussion.
a list's recipients, could result in a complaint from one of the
recipients for some reason. This could be an actual complaint from
some subscriber that finds the message abusive or otherwise
undesirable, or it could be an automated complaint such as receiver
detection of an invalidated DKIM signature or some other condition.
It could also be a complaint that results from antagonistic
behaviour, such as is common when a subscriber to a list is having
trouble unsubscribing, and then begins issuing complaints about all
submissions to the list. This would result in a complaint being
generated in the context of an FBL report back to the message author.
However, the original author has no involvement in operation of the
MLM itself, meaning the FBL report is not actionable and thus
undesirable.
See Section 6 for additional discussion.
FBLs tend to use the ARF ([MARF]) or the IODEF ([IODEF]) format. FBLs tend to use the ARF ([MARF]) or the IODEF ([IODEF]) formats.
{DKIM 12}
1.4. Document Scope and Goals 2.4. Document Scope and Goals
This document provides discussion on the above issues, to improve the This document provides discussion on the above issues, to improve the
handling of possible interactions between DKIM and MLMs. In general, handling of possible interactions between DKIM and MLMs. In general,
consensus shows a preference toward imposing changes to behaviour at the preference is to impose changes to behaviour at the signer and
the signer and verifier rather than at the MLM. verifier rather than at the MLM. {DKIM 12}
Wherever possible, MLMs will be 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.
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. {DKIM 12}
Parts of this document explore possible changes to common practice by Parts of this document explore possible changes to common practice by
signers, verifiers and MLMs. The suggested enhancements are largely signers, verifiers and MLMs. The suggested enhancements are largely
theoretical in nature, taking into account the current email predictive {DKIM 12} in nature, taking into account the current email
infrastructure, the facilities DKIM can provide as it gains wider infrastructure, the facilities DKIM can provide as it gains wider
deployment, and working group consensus. There is no substantial deployment, and working group consensus. There is no substantial
implementation history upon which these suggestions are based, and implementation history upon which these suggestions are based, and
the efficacy, performance and security characteristics of them have the efficacy, performance and security characteristics of them have
not yet been fully explored. not yet been fully explored.
2. Definitions 3. Definitions
2.1. Other Terms 3.1. Key Words
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [KEYWORDS]. {DKIM 15}
3.2. Messaging Terms
See [EMAIL-ARCH] for a general description of the current messaging See [EMAIL-ARCH] for a general description of the current messaging
architecture, and for definitions of various terms used in this architecture, and for definitions of various terms used in this
document. document.
2.2. DKIM-Specific References 3.3. DKIM-Specific References
Readers are encouraged to become familiar with [DKIM] and [ADSP], Readers are encouraged to become familiar with [DKIM] and [ADSP],
which are core specification documents, as well as [DKIM-OVERVIEW] which are core specification documents, as well as [DKIM-OVERVIEW]
and [DKIM-DEPLOYMENT], which are DKIM's primary tutorial documents. and [DKIM-DEPLOYMENT], which are DKIM's primary tutorial documents.
2.3. 'DKIM-Friendly' 3.4. 'DKIM-Friendly'
The term "DKIM-Friendly" is used to describe an email intermediary The term "DKIM-Friendly" is used to describe an email intermediary
that, when handling a message, makes no changes to that message which that, when handling a message, makes no changes to that message which
cause valid [DKIM] signatures present on the message on input to fail cause valid [DKIM] signatures present on the message on input to fail
to verify on output. to verify on output.
Various features of MTAs and MLMs seen as helpful to users often have Various features of MTAs and MLMs seen as helpful to users often have
side effects that do render DKIM signatures unverifiable. These side effects that do render DKIM signatures unverifiable. These
would not qualify for this label. would not qualify for this label.
2.4. Message Streams 3.5. Message Streams
This document makes reference to the concept of "message streams". A "message stream" identifies a group of messages originating from
The idea is to identify groups of messages originating from within an within an {DKIM 12} ADMD that are distinct in intent, origin and/or
ADMD that are distinct in intent, origin and/or use, and partition use, and partitions them somehow (i.e., via {DKIM 12} changing the
them somehow (i.e., via changing the value in the "d=" tag value in value in the "d=" tag value in the context of DKIM) so as to keep
the context of DKIM) so as to keep them associated to users yet them associated to users yet distinct in terms of their evaluation
distinct in terms of their evaluation and handling by verifiers or and handling by verifiers or receivers.
receivers.
A good example might be user mail generated by a company's employees, A good example might be user mail generated by a company's employees,
versus operational or transactional mail that comes from automated versus operational or transactional mail that comes from automated
sources, versus marketing or sales campaigns. Each of these could sources, versus marketing or sales campaigns. Each of these could
have different security policies imposed against them, or there might have different security policies imposed against them, or there might
be a desire to insulate one from the other (e.g., a marketing be a desire to insulate one from the other (e.g., a marketing
campaign that gets reported by many spam filters could cause the campaign that gets reported by many spam filters could cause the
marketing stream's reputation to degrade without automatically marketing stream's reputation to degrade without automatically
punishing the transactional or user streams). punishing the transactional or user streams).
3. Mailing Lists and DKIM 4. Mailing Lists and DKIM
It is important to make some distinctions among different MLM-like It is important to make some distinctions among different styles of
agents, their typical implementations, and the impacts they have in a intermediaries, their typical implementations, and the effects they
DKIM-aware environment. have in a DKIM-aware environment. {DKIM 12}
3.1. Roles and Realities 4.1. Roles and Realities
In DKIM parlance, there are several key roles in the transit of a Across DKIM activities, there are several key roles {DKIM 12} in the
message. Most of these are defined in [EMAIL-ARCH]. transit of a message. Most of these are defined in [EMAIL-ARCH], but
are reviewed here for quick reference. {DKIM 12}
author: The agent that provided the content of the message being author: The agent that provided the content of the message being
sent through the system, and performed the initial submission. sent through the system. The author delivers that content to the
This can be a human using an MUA or a common system utility such originator in order to begin a message's journey to its intended
as "cron", etc. final recipients. The author can be a human using an MUA (Mail
User Agent) or a common system utility such as "cron", etc. {DKIM
12}
originator: The agent that accepts a message from the author, originator: The agent that accepts a message from the author,
ensures it conforms to the relevant standards such as [MAIL], and ensures it conforms to the relevant standards such as [MAIL], and
then relays it toward its destination(s). This is often referred then sends {DKIM 12} it toward its destination(s). This is often
to as the Mail Submission Agent (MSA). referred to as the Mail Submission Agent (MSA).
signer: Any agent that affixes one or more DKIM signature(s) to a signer: Any agent that affixes one or more DKIM signature(s) to a
message on its way toward its ultimate destination. There is message on its way toward its ultimate destination. There is
typically a signer running at the MTA that sits between the typically a signer running at the MTA that sits between the
author's ADMD and the general Internet. The originator and/or author's ADMD and the general Internet. The originator and/or
author might also be a signer. author might also be a signer.
verifier: Any agent that conducts DKIM signature analysis. One is verifier: Any agent that conducts DKIM signature analysis. One is
typically running at the MTA that sits between the general typically running at the MTA that sits between the public Internet
Internet and the receiver's ADMD. Note that any agent that {DKIM 12} and the receiver's ADMD. Note that any agent that
handles a signed message could conduct verification; this document handles a signed message can conduct verification; {DKIM 12} this
only considers that action and its outcomes either at an MLM or at document only considers that action and its outcomes either at an
the receiver. Filtering decisions could be made by this agent MLM or at the receiver. Filtering decisions could be made by this
based on verification results. agent based on verification results.
receiver: The agent that is the final transit relay for the message receiver: The agent that is the final transit relay for the message
prior to being delivered to the recipient(s) of the message. and performs final delivery to {DKIM 12} the recipient(s) of the
Filtering decisions based on results made by the verifier could be message. Filtering decisions based on results made by the
applied by the receiver. The verifier and the receiver could be verifier could be applied by the receiver. The verifier and the
the same agent. receiver could be the same agent.
In the case of simple user-to-user mail, these roles are fairly In the case of simple user-to-user mail, these roles are fairly
straightforward. However, when one is sending mail to a list, which straightforward. However, when one is sending mail to a list, which
then gets relayed to all of that list's subscribers, the roles are 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 often less clear to the general user as particular agents may hold
multiple important but separable roles. The above definitions are multiple important but separable roles. The above definitions are
intended to enable more precise discussion of the mechanisms intended to enable more precise discussion of the mechanisms
involved. involved.
3.2. Types Of Mailing Lists 4.2. Types Of Mailing Lists
There are four common MLM implementation modes: There are four common MLM implementation modes:
aliasing: An aliasing MLM (see Section 5.1 of [EMAIL-ARCH]) is one aliasing: An aliasing MLM (see Section 5.1 of [EMAIL-ARCH]) is one
that makes no changes to a message as it redistributes; any that makes no changes to the message itself as it redistributes;
modifications are constrained to changes to the [SMTP] envelope any modifications are constrained to changes to the [SMTP] {DKIM
recipient list (RCPT commands) only. There are no changes to the 12} envelope recipient list (RCPT commands) only. There are no
message body at all and only [MAIL] trace header fields are added. changes to the message header or body at all, except for the
The output of such an MLM is considered to be a continuation of addition of [MAIL] trace header fields. {DKIM 12} The output of
the author's original message. An example of such an MLM is an such an MLM is considered to be a continuation of the author's
address that expands directly in the MTA, such as a list of local original message transit. {DKIM 12} An example of such an MLM is
system administrators used for relaying operational or other an address that expands directly in the {DKIM 12} MTA, such as a
internal-only messages. See also Section 3.9.2 of [SMTP]. 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 resending: A resending MLM (see Sections 5.2 and 5.3 of
[EMAIL-ARCH]) is one that may make changes to a message. The [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 output of such an MLM is considered to be a new message; delivery
of the original has been completed prior to distribution of the of the original has been completed prior to distribution of the
re-posted message. Such messages are often re-formatted, such as re-posted message. Such messages are often re-formatted, such as
with list-specific header fields or other properties, to with list-specific header fields or other properties, to
facilitate discussion among list subscribers. facilitate discussion among list subscribers.
authoring: An authoring MLM is one that creates the content being authoring: An authoring MLM is one that creates the content being
sent as well as initiating its transport, rather than basing it on sent as well as initiating its transport, rather than basing it on
one or more messages received earlier. This is a special case of one or more messages received earlier. This is not a "mediator"
the MLM paradigm, one that generates its own content and does not in terms of [EMAIL-ARCH] since it originates the message, but
act as an intermediary. Typically replies are not generated, or after creation, its message processing and posting behavior
if they are, they go to a specific recipient and not back to the otherwise do match the MLM paradigm. Typically {DKIM 12} replies
list's full set of recipients. Examples include newsletters and are not generated, or if they are, they go to a specific recipient
bulk marketing mail. 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 digesting: A special case of the resending MLM is one that sends a
single message comprising an aggregation of recent MLM single message comprising an aggregation of recent MLM
submissions, which might be a message of [MIME] type "multipart/ submissions, which might be a message of [MIME] type "multipart/
digest" (see [MIME-TYPES]). This is obviously a new message but digest" (see [MIME-TYPES]). This is obviously a new message but
it may contain a sequence of original messages that may themselves it may contain a sequence of original messages that may themselves
have been DKIM-signed. have been DKIM-signed.
In the remainder of this document we distinguish two relevant steps, In the remainder of this document we distinguish two relevant steps,
corresponding to the following SMTP transactions: corresponding to the following SMTP transactions:
skipping to change at page 10, line 14 skipping to change at page 11, line 18
MLM Output: MLM (sending its reconstructed copy of the originating MLM Output: MLM (sending its reconstructed copy of the originating
user's message) is author; MLM's ADMD is originator and signer; user's message) is author; MLM's ADMD is originator and signer;
the ADMD of each subscriber of the list is a verifier; each the ADMD of each subscriber of the list is a verifier; each
subscriber is a receiver. subscriber is a receiver.
Much of this document focuses on the resending class of MLM as it has Much of this document focuses on the resending class of MLM as it has
the most direct conflict operationally with DKIM. the most direct conflict operationally with DKIM.
The dissection of the overall MLM operation into these two distinct The dissection of the overall MLM operation into these two distinct
steps allows the DKIM-specific issues with respect to MLMs to be phases allows the DKIM-specific {DKIM 12} issues with respect to MLMs
isolated and handled in a logical way. The main issue is that the to be isolated and handled in a logical way. The main issue is that
repackaging and reposting of a message by an MLM is actually the the repackaging and reposting of a message by an MLM is actually the
construction of a completely new message, and as such the MLM is construction of a completely new message, and as such the MLM is
introducing new content into the email ecosystem, consuming the introducing new content into the email ecosystem, consuming the
author's copy of the message and creating its own. When considered 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. 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 Some issues about these activities are discussed in Section 3.6.4 of
[MAIL] and in Section 3.4.1 of [EMAIL-ARCH]. [MAIL] and in Section 3.4.1 of [EMAIL-ARCH].
3.3. Current MLM Effects On Signatures 4.3. Current MLM Effects On Signatures
As described above, an aliasing MLM does not affect any existing As described above, an aliasing MLM does not affect any existing
signature, and an authoring MLM is always creating new content and signature, and an authoring MLM is always creating new content and
thus there is never an existing signature. However, the changes a thus there is never an existing signature. However, the changes a
resending MLM can make typically affect the RFC5322.Subject header resending MLM typically make affect {DKIM 12} the RFC5322.Subject
field, addition of some list-specific header fields, and/or header field, addition of some list-specific header fields, and/or
modification of the message body. The impacts of each of these on modification of the message body. The effects of each of these {DKIM
DKIM verification are discussed below. 12} on DKIM verification are discussed below.
Subject tags: A popular feature of MLMs is the "tagging" of an Subject tags: A popular feature of MLMs is the "tagging" of an
RFC5322.Subject field by prefixing the field's contents with the RFC5322.Subject field by prefixing the field's contents with the
name of the list, such as "[example]" for a list called "example". name of the list, such as "[example]" for a list called "example".
Altering the RFC5322.Subject field on new submissions by adding a Altering the RFC5322.Subject field on new submissions by adding a
list-specific prefix or suffix will invalidate the signer's list-specific prefix or suffix will invalidate the signer's
signature if that header field was included when creating that signature if that header field was included in the hash when
signature. [DKIM] lists RFC5322.Subject as one that should be creating that signature. Section 5.5 of [DKIM] lists
covered, so this is expected to be an issue for any list that RFC5322.Subject as one that should be covered as it contains
makes such changes. important user-visible text, so this is expected to be an issue
for any list that makes such changes. {DKIM 12}
List-specific header fields: Some lists will add header fields List-specific header fields: Some lists will add header fields
specific to list administrative functions such as those defined in specific to list administrative functions such as those defined in
[LIST-ID] and [LIST-URLS], or the "Resent-" fields defined in [LIST-ID] and [LIST-URLS], or the "Resent-" fields defined in
[MAIL]. It is unlikely that a typical MUA would include such [MAIL]. It is unlikely that a typical MUA would include such
fields in an original message, and DKIM is resilient to the fields in an original message, and DKIM is resilient to the
addition of header fields in general (see notes about the "h=" tag addition of header fields in general (see notes about the "h=" tag
in Section 3.5 of [DKIM]). Therefore this is seen as less of a in Section 3.5 of [DKIM]). Therefore not seen as a concern. {DKIM
concern. 12}
Other header fields: Some lists will add or replace header fields Other header fields: Some lists will add or replace header fields
such as "Reply-To" or "Sender" in order to establish that the 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 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 the list is identified ("Sender") and any user replies go to the
list ("Reply-To"). If these fields were included in the original list ("Reply-To"). If these fields were included in the original
message, it is possible that one or more of them may have been message, it is possible that one or more of them may have been
signed, and those signatures will thus be broken. included in the signature hash, and those {DKIM 12} signatures
will thus be broken.
Minor body changes: Some lists prepend or append a few lines to each Minor body changes: Some lists prepend or append a few lines to each
message to remind subscribers of an administrative URL for message to remind subscribers of an administrative URL for
subscription issues, or of list policy, etc. Changes to the body subscription issues, or of list policy, etc. Changes to the body
will alter the body hash computed at the DKIM verifier, so these will alter the body hash computed at the DKIM verifier, so these
will render any existing signatures that cover those portions of will render any existing signatures that cover those portions of
the message body unverifiable. 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. {DKIM 12}
Major body changes: There are some MLMs that make more substantial Major body changes: There are some MLMs that make more substantial
changes to message bodies when preparing them for re-distribution, changes to message bodies when preparing them for re-distribution,
such as adding, deleting, reordering, or reformatting [MIME] such as adding, deleting, reordering, or reformatting [MIME]
parts, "flattening" HTML messages into plain text, or insert parts, "flattening" HTML messages into plain text, or inserting
headers or footers within HTML messages. Most or all of these {DKIM 9} headers or footers within HTML messages. Most or all of
changes will invalidate a DKIM signature. these changes will invalidate a DKIM signature.
MIME part removal: Some MLMs that are MIME-aware will remove large MIME part removal: Some MLMs that are MIME-aware will remove large
MIME parts from submissions and replace them with URLs to reduce MIME parts from submissions and replace them with URLs to reduce
the size of the distributed form of the message and to prevent the size of the distributed form of the message and to prevent
inadvertent automated malware delivery. Except in cases where a inadvertent automated malware delivery. Except in some cases
body length limit is applied in generation of the DKIM signature, where {DKIM 12} a body length limit is applied in generation of
the signature will be broken. the DKIM signature, the signature will be broken.
There reportedly still exist a few scattered mailing lists in There reportedly still exist some {DKIM 12} mailing lists in
operation that are actually run manually by a human list manager, operation that are actually run manually by a human list manager,
whose workings in preparing a message for distribution could include whose workings in preparing a message for distribution could include
the above or even some other changes. the above or even some other changes.
In general, absent a general movement by MLM developers and operators In general, absent a general movement by MLM developers and operators
toward more DKIM-friendly practices, an MLM subscriber cannot expect toward more DKIM-friendly practices, an MLM subscriber cannot expect
signatures applied before the message was processed by the MLM to be signatures applied before the message was processed by the MLM to be
valid on delivery to a receiver. Such an evolution is not expected valid on delivery to a receiver. Such an evolution is not expected
in the short term due to general development and deployment inertia. in the short term due to general development and deployment inertia.
Moreover, even if an MLM currently passes messages unmodified such Moreover, even if an MLM currently passes messages unmodified such
that author signatures validate, it is possible that a configuration that author signatures validate, it is possible that a configuration
change or software upgrade to that MLM will cause that no longer to change or software upgrade to that MLM will cause that no longer to
be true. be true.
4. Non-Participating MLMs 5. Non-Participating MLMs
This section contains a discussion of issues regarding sending DKIM- This section contains a discussion of issues regarding sending DKIM-
signed mail to or through an MLM that is not DKIM-aware. signed mail to or through an MLM that is not DKIM-aware.
Specifically, the header fields introduced by [DKIM] and Specifically, the header fields introduced by [DKIM] and
[AUTH-RESULTS] carry no special meaning to such an MLM. [AUTH-RESULTS] carry no special meaning to such an MLM.
4.1. Author-Related Signing 5.1. Author-Related Signing
If an author knows that the MLM to which a message is being sent is a In an idealized world, if an author knows that the MLM to which a
non-participating resending MLM, the author SHOULD be cautious when message {DKIM 12} is being sent is a non-participating resending MLM,
deciding whether or not to send to the list when that mail would be the author SHOULD be cautious when deciding whether or not to send a
signed. The MLM could make a change that would invalidate the signed message to the list {DKIM 9}. The MLM could make a change
author's signature but not remove it prior to re-distribution. that would invalidate the author's signature but not remove it prior
Hence, list recipients would receive a message purportedly from the to re-distribution. Hence, list recipients would receive a message
author but bearing a DKIM signature that would not verify. There purportedly from the author but bearing a DKIM signature that would
exist DKIM modules that incorrectly penalize messages with signatures not verify. Some mail filtering software incorrectly penalizes a
that do not validate, so this may have detrimental effects outside of message containing a DKIM signature that fails verification. This
the author's control. (Additional discussion of this is below.) may have {DKIM 12} detrimental effects outside of the author's
This problem could be compounded if there were receivers that applied control. (Additional discussion of this is below.) This problem can
signing policies (e.g., [ADSP]) and the author published any kind of be compounded if there are receivers that apply signing {DKIM 12}
strict policy. 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. {DKIM 12}
For domains that do publish strict ADSP policies, the originating For domains that do publish strict ADSP policies, the originating
site SHOULD use a separate message stream (see Section 2.4), such as site SHOULD use a separate message stream (see Section 3.5), such as
a sub-domain, for the "personal" mail -- a subdomain that is a signing and author subdomain {DKIM 12}, for the "personal" mail --
different from domain(s) used for other mail streams. This allows a subdomain that is different from domain(s) used for other mail
each to develop an independent reputation, and more stringent streams. This allows each to develop an independent reputation, and
policies (including ADSP) can be applied to the mail stream(s) that more stringent policies (including ADSP) can be applied to the mail
do not go through mailing lists or perhaps do not get signed at all. 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 However, all of this presupposes a level of infrastructure
understanding that is not expected to be common. Thus, it will be understanding that is not expected to be common. Thus, it will be
incumbent upon site administrators to consider how support of users incumbent upon site administrators to consider how support of users
wishing to participate in mailing lists might be accomplished as DKIM wishing to participate in mailing lists might be accomplished as DKIM
achieves wider adoption. achieves wider adoption.
In general, the more strict practices and policies are likely to be In general, the more strict practices and policies are likely to be
successful only for the mail streams subject to the most end-to-end successful only for the mail streams subject to the most end-to-end
control by the originating organization. That typically excludes control by the originating organization. That typically excludes
mail going through MLMs. Therefore, authors whose ADSP is published mail going through MLMs. Therefore, site administrators wishing to
as "discardable" SHOULD NOT send mail to MLMs, as it is likely to be employ ADSP with a "discardable" setting SHOULD separate the
rejected by ADSP-aware verifiers or recipients. (This is discussed controlled mail stream warranting this handling from other mail
further in Section 5.6 below.) streams that are less controlled, such as personal mail that transits
MLMs. (See also in Section 6.7 below.) {DKIM 12}
4.2. Verification Outcomes at Receivers 5.2. Verification Outcomes at Receivers
There does not appear to be a reliable way to determine that a piece There is no reliable way to {DKIM 12} determine that a piece of mail
of mail arrived via a non-participating MLM. Sites whose users arrived via a non-participating MLM. Sites whose users subscribe to
subscribe to non-participating MLMs SHOULD be prepared for legitimate non-participating MLMs SHOULD ensure that such user mail streams are
mail to arrive with no valid signature, just as it always has in the not subject to strict DKIM-related handling policies. {DKIM 12}
absence of DKIM.
4.3. Handling Choices at Receivers 5.3. Handling Choices at Receivers
A receiver's ADMD would have to have some way to register such non- In order to exempt some mail from the expectation of signature
participating lists to exempt them from the expectation of signed verification, as discussed in Section 5.1, receiving ADMDs would need
mail as discussed in Section 4.1. This is, however, probably not a to register non-participating lists and confirm that mail transited
scalable solution as it imposes a burden on the receiver that is them. However, such an approach requires excessive effort and even
predicated on sender behaviour. then is likely to be unreliable. Hence, it is not a scalable
solution. {DKIM 12}
Note that the [DKIM] specification explicitly directs verifiers and Any treatment of a verification failure as having special meaning is
receivers to treat a verification failure as though the message was a violation of the basic DKIM signing specification. The only valid,
not signed in the first place. In the absence of specific ADSP standardized basis for going beyond that specification is with
direction, any treatment of a verification failure as having special specific ADSP direction. {DKIM 12}
meaning is either outside the scope of DKIM or is in violation of it.
Use of restrictive domain policies such as [ADSP] "discardable" Use of restrictive domain policies such as [ADSP] "discardable"
presents an additional challenge. In that case, when a message is presents an additional challenge. In that case, when a message is
unsigned or the signature can no longer be verified, discarding of unsigned or the signature can no longer be verified, discarding of
the message is requested. There is no exception in the policy for a 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 message that may have been altered by an MLM, nor is there a reliable
way to identify such mail. Therefore, participants SHOULD honour the way to identify such mail. Therefore, participants SHOULD honour the
policy and disallow the message. policy and disallow the message.
4.4. Wrapping A Non-Participating MLM 5.4. Wrapping A Non-Participating MLM
One approach to adding DKIM support to an otherwise non-participating
MLM is to "wrap" it, 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 a DKIM
verifier act on submissions, 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 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 6 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. {DKIM
12}
This section contains a discussion of issues regarding sending DKIM- 6. Participating MLMs
signed mail to or through an MLM that is DKIM-aware, and may also be
ADSP-aware.
5.1. General This section contains a discussion of issues regarding DKIM-signed
mail that transits an MLM which is DKIM-aware.
As DKIM becomes more widely deployed, it is highly desirable that MLM 6.1. General
software adopt more DKIM-friendly processing.
Changes that merely add new header fields, such as those specified by Changes that merely add new header fields, such as those specified by
[LIST-ID], [LIST-URLS] and [MAIL], are generally the most friendly to [LIST-ID], [LIST-URLS] and [MAIL], are generally the most friendly to
a DKIM-participating email infrastructure in that their addition by a DKIM-participating email infrastructure. Their addition by an MLM
an MLM will not affect any existing DKIM signatures unless those {DKIM 12} will not affect any existing DKIM signatures unless those
fields were already present and covered by a signature's hash or a fields were already present and covered by a signature's hash, or a
signature was created specifically to disallow their addition (see signature {DKIM 12} was created specifically to disallow their
the note about "h=" in Section 3.5 of [DKIM]). addition (see the note about "h=" in Section 3.5 of [DKIM]).
However, the practice of applying headers and footers to message However, the practice of applying headers and footers to message
bodies is common and not expected to fade regardless of what bodies is common and not expected to fade regardless of what
documents this or any standards body might produce. This sort of documents this or any standards body might produce. This sort of
change will invalidate the signature on a message where the body hash change will invalidate the signature on a message where the body hash
covers the entire message. Thus, the following sections also discuss covers the entire message. Thus, the following sections also discuss
and suggest other processing alternatives. and suggest other processing alternatives.
A possible mitigation to this incompatibility is use of the "l=" tag 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 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 this is not workable for [MIME] messages; moreover, it has security
considerations (see Section 3.5 of [DKIM]). Its use is therefore considerations (see Section 3.5 of [DKIM]). Its use is therefore
discouraged. discouraged.
MLM operators often arrange to affix to outgoing messages expressions Expressions of list-specific policy (e.g., rules for participation,
of list-specific policy and related information (e.g., rules for small advertisements, etc.) are often added to outgoing messages by
participation, small advertisements, etc.). There is currently no MLM operators. There is currently no header field proposed for
header field proposed for relaying such general operational MLM relaying such general operational MLM details apart from what
details apart from what [LIST-URLS] already supports. This sort of [LIST-URLS] already supports. This sort of information is commonly
information is what is commonly included in appended footer text or included footer text appended to the body of the message, or header
prepended header text. The working group RECOMMENDS periodic, text prepended above the original body {DKIM 9}. It is RECOMMENDED
automatic mailings to the list to remind subscribers of list policy, that periodic, automatic mailings to the list to remind subscribers
and otherwise RECOMMENDS use of standard header fields to express of list policy, and it is otherwise RECOMMENDED that the use of
list operation parameters rather than body changes. These periodic standard header fields to express list operation parameters be
mailings will be repetitive, of course, but by being generally the applied rather than body changes. {DKIM 12} These periodic mailings
same each time they can be easily filtered if desired. 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 6.2. DKIM Author Domain Signing Practices
[ADSP] presents a particular challenge. An author domain posting a ADSP {DKIM 9} presents a particular challenge. An author domain
policy of "discardable" imposes a very tight restriction on the use posting a policy of "discardable" imposes a very tight restriction on
of mailing lists, essentially constraining that domain's users to the use of mailing lists, essentially constraining that domain's
lists operated by aliasing MLMs only; any MLM that alters a message users to lists operated by aliasing MLMs only; any MLM that alters a
from such a domain or removes its signature subjects the message to message from such a domain or removes its signature subjects the
severe action by verifiers or receivers. It is the consensus of the message to severe action by verifiers or receivers. A resending
working group that a resending MLM SHOULD reject outright any mail {DKIM 12} MLM SHOULD reject outright any mail from an author whose
from an author whose domain posts such a policy as it is likely to be domain posts such a policy, as those messages likely to be discarded
rejected by any ADSP-aware recipients, and SHOULD also discourage or rejected by any ADSP-aware recipients. See also the discussion in
such subscribers when they first sign up to the list. Further Section 6.3. {DKIM 9}
discussion of this appears in Section 5.3.
Where the above practice is not observed and "discardable" mail Where such rejection of "discardable" mail is not enforced, and such
arrives via a list to a verifier that applies ADSP checks which fail, mail arrives to a {DKIM 12} verifier that applies ADSP checks which
the message SHOULD either be discarded (i.e. accept the message at fail, the message SHOULD either be discarded (i.e. accept the message
the [SMTP] level but discard it without delivery) or rejected by 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 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 to conduct the rejection in a potentially meaningful way can be found
in Section 5.10. in Section 6.11.
See also Appendix B.5 of [ADSP] for further discussion. See also Appendix B.5 of [ADSP] for further discussion.
5.3. Subscriptions 6.3. Subscriptions
At subscription time, an ADSP-aware MLM SHOULD check for a published At subscription time, an ADSP-aware MLM SHOULD check for a published
ADSP record for the new subscriber's domain. If the policy specifies ADSP record for the new subscriber's domain. If the policy specifies
"discardable", the MLM SHOULD disallow the subscription or present a "discardable", the MLM SHOULD disallow the subscription or present a
warning that the subscriber's submissions to the mailing list might warning that the subscriber's submissions to the mailing list might
not be deliverable to some recipients because of the subscriber's not be deliverable to some recipients because of the subscriber's
ADMD's published policy. ADMD's published policy.
Of course, such a policy record could be applied after subscription, Of course, such a policy record could be created {DKIM 12} after
so this is not a universal solution. An MLM implementation MAY do subscription, so this is not a universal solution. An MLM
periodic checks of its subscribers and issue warnings where such a implementation MAY do periodic checks of its subscribers and issue
policy is detected, or simply check upon each submission. warnings where such a policy is detected, or simply check upon each
submission.
5.4. Author-Related Signing 6.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.
6.5. Author-Related Signing
An important consideration is that authors rarely have any direct An important consideration is that authors rarely have any direct
influence over the management of an MLM. As such, a signed message influence over the management of an MLM. Specifically, the behavior
from an author will in essence go to a set of unexpected places, of an intermediary (e.g., an MLM that is not careful about filtering
sometimes coupled with other messages from other sources. In the out junk mail or being diligent about unsubscription requests) can
future, as DKIM signature outputs (e.g. the AUID or SDID of trigger recipient complaints that reflect back on those agents that
[DKIM-UPDATE]) are used as inputs to reputation modules, there may be appear to be responsible for the message, in this case an author via
a desire to insulate one's reputation from influence by the unknown the address found in the RFC5322.From field. In the future, as DKIM
results of sending mail through an MLM. In that case, authors SHOULD signature outputs (i.e., the signing domain) are used as inputs to
create a mail stream specifically used for generating signatures when reputation modules, there may be a desire to insulate one's
sending traffic to MLMs. reputation from influence by the unknown results of sending mail
through an MLM. In that case, authors SHOULD create a mail stream
specifically used for generating signatures when sending traffic to
MLMs. {DKIM 12}
This suggestion can be made more general. Mail that is of a This suggestion can be made more general. Mail that is of a
transactional or generally end-to-end nature, and not likely to be transactional or generally end-to-end nature, and not likely to be
forwarded around either by MLMs or users, SHOULD come from a forwarded around either by MLMs or users, SHOULD be signed with a
different mail stream than a stream that serves more varied uses. different mail stream identifier from a stream that serves more
varied uses. {DKIM 12}
5.5. Verification Outcomes at MLMs 6.6. Verification Outcomes at MLMs
MLMs typically attempt to authenticate messages posted through them. MLMs typically attempt to authenticate messages posted through them.
They usually do this through the trivial (and insecure) means of They usually do this through the trivial (and insecure) means of
verifying the RFC5322.From field email address (or, less frequently, verifying the RFC5322.From field email address (or, less frequently,
the RFC5321.MailFrom parameter) against a list registry. DKIM the RFC5321.MailFrom parameter) against a list subscription registry.
enables a stronger form of authentication, although this is not yet {DKIM 12} DKIM enables a stronger form of authentication: {DKIM 9}
formally documented: It can require that messages using a given The MLM can require that messages using a given RFC5322.From address
RFC5322.From address also have a DKIM signature with a corresponding also have a DKIM signature with a corresponding "d=" domain. This
"d=" domain. This feature would be somewhat similar to using ADSP, feature would be somewhat similar to using ADSP, except that the
except that the requirement for it would be imposed by the MLM and requirement for it would be imposed by the MLM and not the author's
not the author's organization. organization.
As described, the MLM MAY conduct DKIM verification of a signed (Note, however, that this goes beyond DKIM's documented semantics.
It is presented as a possible workable enhancement.) {DKIM 12}
As described, the MLM might conduct DKIM verification of a signed
message to attempt to confirm the identity of the author. Although message to attempt to confirm the identity of the author. Although
it is a common and intuitive conclusion, not all signed mail will it is a common and intuitive conclusion, few signed messages will
include an author signature (see [ADSP]). MLM implementers SHOULD include an author {DKIM 12} signature (see [ADSP]). MLM implementers
accommodate such in their configurations. For example, an MLM might adding such support would have accommodate this. For example, an MLM
be designed to accommodate a list of possible signing domains (the might be designed to accommodate a list of possible signing domains
"d=" portion of a DKIM signature) for a given author, and determine (the "d=" portion of a DKIM signature) for a given author, and
at verification time if any of those are present. 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. {DKIM 12}
A message that cannot be thus authenticated MAY be held for A message that cannot be thus authenticated MAY be held for
moderation or rejected outright. moderation or rejected outright.
This logic could apply to any list operation, not just list This logic could apply to any list operation, not just list
submission. In particular, this improved authentication MAY apply to submission. In particular, this improved authentication MAY apply to
subscription, unsubscription, and/or changes to subscriber options subscription, unsubscription, and/or changes to subscriber options
that are sent via email rather than through an authenticated, that are sent via email rather than through an authenticated,
interactive channel such as the web. interactive channel such as the web.
In the case of verification of signatures on submissions, MLMs SHOULD In the case of verification of signatures on submissions, MLMs SHOULD
add an [AUTH-RESULTS] header field to indicate the signature(s) add an [AUTH-RESULTS] header field to indicate the signature(s)
observed on the submission as it arrived at the MLM and what the observed on the submission as it arrived at the MLM and what the
outcome of the evaluation was. Downstream agents may or may not outcome of the evaluation was. Downstream agents might or might not
trust the content of that header field depending on their own a trust the content of that header {DKIM 12} field depending on their
priori knowledge of the operation of the ADMD generating (and, own a priori knowledge of the operation of the ADMD generating (and,
preferably, signing) that header field. See [AUTH-RESULTS] for preferably, signing) that header field. See [AUTH-RESULTS] for
further discussion. further discussion.
5.6. Signature Removal Issues 6.7. Signature Removal Issues
A message that arrives signed with DKIM means some domain prior to A message that arrives signed with DKIM means some domain prior to
MLM Input has made a claim of some responsibility for the message. MLM Input has made a claim of some responsibility for the message.
An obvious benefit to leaving the input-side signatures intact, then, An obvious benefit to leaving the input-side signatures intact, then,
is to preserve that chain of responsibility of the message so that is to preserve that original assertion of responsibility for the
the receivers of the final message have an opportunity to evaluate message so that the receivers of the final message have an
the message with that information available to them. opportunity to evaluate the message with that information available
to them. {DKIM 12}
However, if the MLM is configured to make changes to the message However, if the MLM is configured to make changes to the message
prior to re-posting that would invalidate the original signature(s), prior to re-posting that would invalidate the original signature(s),
further action is RECOMMENDED to prevent invalidated signatures from further action is RECOMMENDED to prevent invalidated signatures from
arriving at final recipients, possibly triggering unwarranted filter arriving at final recipients, possibly triggering unwarranted filter
actions. (Note, however, that such filtering actions are plainly actions. (Note, however, that such filtering actions are plainly
wrong; [DKIM] stipulates that an invalid signature is to be treated wrong; [DKIM] stipulates that an invalid signature is to be treated
as no signature at all.) as no signature at all.)
A possible solution would be to: A possible solution would be to:
skipping to change at page 17, line 38 skipping to change at page 19, line 51
3. Remove all existing [AUTH-RESULTS] fields (optional); 3. Remove all existing [AUTH-RESULTS] fields (optional);
4. Add an [AUTH-RESULTS] header field to the message to indicate the 4. Add an [AUTH-RESULTS] header field to the message to indicate the
results of the above; results of the above;
5. Remove all previously-evaluated DKIM signatures; 5. Remove all previously-evaluated DKIM signatures;
6. Affix a new signature that covers the entire message on the 6. Affix a new signature that covers the entire message on the
output side, including the Authentication-Results header field output side, including the Authentication-Results header field
just added (see Section 5.7). just added (see Section 6.8).
Removing the original signature(s) seems particularly appropriate Removing the original signature(s) seems particularly appropriate
when the MLM knows it is likely to invalidate any or all of them due 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 to the nature of the reformatting it will do. This avoids false
negatives at the list's subscribers in their roles as receivers of negatives at the list's subscribers in their roles as receivers of
the message; although [DKIM] stipulates that an invalid signature is the message; although [DKIM] stipulates that an invalid signature is
the same as no signature, it is anticipated that there will be some the same as no signature, it is anticipated that there will be some
implementations that ignore this advice. implementations that ignore this advice.
The MLM could re-evaluate existing signatures after making its The MLM could re-evaluate existing signatures after making its
message changes to determine whether or not any of them have been message changes to determine whether or not any of them have been
invalidated. The cost of this is reduced by the fact that, invalidated. The cost of this is reduced by the fact that,
presumably, the necessary public keys have already been downloaded presumably, the necessary public keys have already been downloaded
and one or both of the message hashes could be reused. and one or both of the message hashes could be reused.
Per the discussion in [AUTH-RESULTS], there is no a priori reason for Per the discussion in [AUTH-RESULTS], a receiver's choice to put any
the final receivers to put any faith in the veracity of that header faith in the veracity of that header field requires an a priori
field when added by the MLM. Thus, the final recipients of the assessment of the agent that created it. Absent that assessment, a
message have no way to verify on their own the authenticity of the receiver cannot interpret the field as valid. Thus, the final
author's identity on that message. However, if that field is the recipients of the {DKIM 12} message have no way to verify on their
only one on the message when the verifier gets it, and the verifier own the authenticity of the author's identity on that message.
explicitly trusts the signer (in this case, the MLM), the verifier is However, if that field is the only one on the message when the
in a position to believe that a valid author signature was present on verifier gets it, and the verifier explicitly trusts the signer that
the message. included the 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. {DKIM 12}
This can be generalized as follows: A receiver SHOULD consider only This can be generalized as follows: A receiver SHOULD consider only
[AUTH-RESULTS] fields bearing an authserv-id that appears in a list [AUTH-RESULTS] fields bearing an authserv-id that appears in a list
of sites the receiver trusts and which is also included in the header of sites the receiver trusts and which is also included in the header
hash of a [DKIM] signature added by a domain in the same trusted hash of a [DKIM] signature added by a domain in the same trusted
list. list.
Since an aliasing MLM makes no substantive changes to a message, it Since an aliasing MLM makes no substantive changes to a message, it
need not consider the issue of signature removal as the original need not consider the issue of signature removal as the original
signatures should arrive at least to the next MTA unmodified. It is signatures should arrive at least to the next MTA unmodified. It is
possible that future domain-based reputations would prefer a more possible that future domain-based reputations would prefer a more
rich data set on receipt of a message, and in that case signature rich data set on receipt of a message, and in that case signature
removal would be undesirable. removal would be undesirable.
An authoring MLM is closed to outside submitters, thus much of this An authoring MLM is closed to outside submitters, thus much of this
discussion does not apply in that case. discussion does not apply in that case.
5.7. MLM Signatures 6.8. MLM Signatures
DKIM-aware resending MLMs and authoring MLMs SHOULD affix their own DKIM-aware resending MLMs and authoring MLMs SHOULD affix their own
signatures when distributing messages. The MLM is responsible for signatures when distributing messages. The MLM is responsible for
the alterations it makes to the original messages it is re-sending, the alterations it makes to the original messages it is re-sending,
and should express this via a signature. This is also helpful for 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 getting feedback from any FBLs that might be set up so that undesired
list mail can generate appropriate action. list mail can generate appropriate action.
MLM signatures will likely be used by recipient systems to recognize 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 list mail, and they give the MLM's ADMD an opportunity to develop a
good reputation for the list itself. good reputation for the list itself.
A signing MLM is, as any other MLM, free to omit redistribution of a A signing MLM is, as any other MLM, free to omit redistribution of a
message if that message was not signed in accordance with its own message if that message was not signed in accordance with its own
local configuration or policy. It could also redistribute but not local configuration or policy. It could also redistribute but not
sign such mail. However, selective signing is NOT RECOMMENDED; sign such mail. However, selective signing is NOT RECOMMENDED;
essentially that would create two message streams from the MLM, one essentially that would create two message streams from the MLM, one
signed and one not, which can confuse DKIM-aware verifiers and signed and one not, which can confuse DKIM-aware verifiers and
receivers. receivers.
A signing MLM SHOULD add a List-Post: header field (see [LIST-URLS]) A signing MLM could add a List-Post: {DKIM 12} header field (see
using a DNS domain matching what will be used in the "d=" tag of the [LIST-URLS]) using that DNS domain matching the one used in the "d="
DKIM signature it will add to the new message. This could be used by tag of the DKIM signature that is added by the MLM. This can be used
verifiers or receivers to identify the DKIM signature that was added by {DKIM 12} verifiers or receivers to identify the DKIM signature
by the MLM. This is not required, however; it is believed the that was added by the MLM. This is not required, however; it is
reputation of the signer will be a more critical data point rather believed the reputation of the signer will be a more critical data
than this suggested binding. Furthermore, this is not a binding point rather than this suggested binding. Furthermore, this is not a
recognized by any current specification document. binding recognized by any current specification document.
Such MLMs SHOULD ensure the signature's header hash will cover at Section 5.5 of [DKIM] includes a list of header fields that a
least: signature SHOULD include in its header hash and discusses reasons for
doing so. MLMs that sign MUST adhere to those guidelines, extended
as follows: {DKIM 12}
o Any [AUTH-RESULTS] fields added by the MLM; o Any [AUTH-RESULTS] fields added by the MLM;
o Any [LIST-ID] or [LIST-URLS] fields added by the MLM; o Any [LIST-ID] or [LIST-URLS] fields added by the MLM;
o Any [MAIL] fields, especially Sender and Reply-To, added or o Any [MAIL] fields, especially Sender and Reply-To, added or
replaced by the MLM. replaced by the MLM.
A DKIM-aware resending MLM SHOULD sign the entire message after being A DKIM-aware resending MLM SHOULD sign the entire message after the
prepared for distribution (i.e. the "MLM Output" from Section 3.2). message is prepared for distribution (i.e. the "MLM Output" from
Any other configuration might generate signatures that cannot be Section 4.2). Any other configuration might generate signatures that
expected to validate. As with any other DKIM signing operation, the will not validate. {DKIM 12} As with any other DKIM signing
choice of what portions of the header and body of the output message operation, the choice of what portions of the header and body of the
should include those parts of the header and body for which the MLM output message should include those parts of the header and body for
wishes to assert responsibility. which the MLM wishes to assert responsibility.
DKIM-aware authoring MLMs MUST sign the mail they send according to DKIM-aware authoring MLMs MUST sign the mail they send according to
the regular signing guidelines given in [DKIM]. the regular signing guidelines given in [DKIM].
One concern is that having an MLM apply its signature to unsigned One concern is that having an MLM apply its signature to unsigned
mail might cause some verifiers or receivers to interpret the mail might cause some verifiers or receivers to interpret the
signature as conferring more authority or authenticity to the message signature as conferring more authority or authenticity to the message
content than is defined by [DKIM]. This is an issue beyond MLMs and content than is defined by [DKIM]. This is an issue beyond MLMs and
primarily entails receive-side processing outside of the scope of primarily entails receive-side processing outside of the scope of
[DKIM]. It is nevertheless worth noting here. In the case of MLMs, [DKIM]. It is nevertheless worth noting here. {DKIM 12}
the presence of an MLM signature is best treated as similar to MLM
handling that affixes an RFC5322.Subject tag or similar information.
It therefore does not introduce any new concerns.
5.8. Verification Outcomes at Final Receiving Sites 6.9. Verification Outcomes at Final Receiving Sites
In general, verifiers and receivers SHOULD treat a signed message In general, verifiers and receivers SHOULD treat a signed message
from an MLM like any other signed message; indeed, it would be from an MLM like any other signed message; indeed, it would be
difficult to discern any difference since specifications such as difficult to discern any difference since specifications such as
[LIST-URLS] and [LIST-ID] are not universally deployed and can be [LIST-URLS] and [LIST-ID] are not universally deployed and can be
trivially spoofed. trivially spoofed.
However, because the author domain will commonly be different from However, because the author domain will commonly be different from
the MLM's signing domain, there may be a conflict with [ADSP] as the MLM's signing domain, there may be a conflict with [ADSP] as
discussed in Section 4.3 and Section 5.6, especially where an ADMD discussed in Section 5.3 and Section 6.7, especially where an ADMD
has misused ADSP. has misused ADSP.
5.9. Use With FBLs 6.10. Use With FBLs
An FBL operator might wish to act on a complaint from a user about a An FBL operator might wish to act on a complaint from a user about a
posting to a list. Some FBLs could choose to generate feedback message sent to a list. Some {DKIM 12} FBLs could choose to generate
reports based on DKIM verifications in the subject message. Such feedback reports based on DKIM verifications in the subject message.
operators SHOULD send a report to each domain with a valid signature Such operators SHOULD send a report to each domain with a valid
that has an FBL agreement established, as DKIM signatures are claims signature that has an FBL agreement established, as DKIM signatures
of some responsibility for that message. Because authors generally are claims of some responsibility for that message. Because authors
have limited control over the operation of a list, this point makes generally have limited control over the operation of a list, this
MLM signing all the more important. 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. {DKIM 12}
Where the FBL wishes to be more specific, it MAY act solely on a DKIM 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 signature where the signing domain matches the DNS domain found in a
List-Post: header field (or similar). List-Post: header field (or similar).
Use of FBLs in this way SHOULD be made explicit to list subscribers. 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 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 item by unsubscribing the user that was the apparent sender of the
offending message, advising subscribers of this in advance would help offending message, advising subscribers of this in advance would help
to avoid surprises later. to avoid surprises later.
5.10. Handling Choices at Receivers 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 {DKIM 12} could be an automated complaint such as
receiver detection of an invalidated DKIM signature or some other
condition. It could also be a complaint that results from
antagonistic behaviour, such as is common when a subscriber to a list
is having trouble unsubscribing, and then begins issuing complaints
about all submissions to the list. This would result in a complaint
being generated in the context of an FBL report back to the message
author. However, the original author has no involvement in operation
of the MLM itself, meaning the FBL report is not actionable, and is
thus undesirable. {DKIM 9, DKIM 12}
6.11. Handling Choices at Receivers
A recipient that explicitly trusts signatures from a particular MLM A recipient that explicitly trusts signatures from a particular MLM
MAY wish to extend that trust to an [AUTH-RESULTS] header field MAY wish to extend that trust to an [AUTH-RESULTS] header field
signed by that MLM. The recipient MAY then do additional processing signed by that MLM. The recipient MAY then do additional processing
of the message, using the results recorded in the Authentication- of the message, using the results recorded in the Authentication-
Results header field instead of the original author's DKIM signature. Results header field instead of the original author's DKIM signature.
This includes possibly processing the message as per ADSP This includes possibly processing the message as per ADSP
requirements. requirements.
Receivers SHOULD ignore or remove all unsigned externally-applied Receivers SHOULD ignore or remove all unsigned externally-applied
Authentication-Results header fields, and those not signed by an ADMD Authentication-Results header fields, and those not signed by an ADMD
that can be trusted by the receiver. See Section 5 and Section 7 of that can be trusted by the receiver. See Section 5 and Section 7 of
[AUTH-RESULTS] for further discussion. [AUTH-RESULTS] for further discussion.
Upon DKIM and ADSP evaluation during an SMTP session (a common Upon DKIM and ADSP evaluation during an SMTP session (a common
implementation), an agent MAY decide to reject a message during an implementation), an agent MAY decide to reject a message during an
SMTP session. If this is done, use of an [SMTP] failure code not SMTP session. If this is done, use of an [SMTP] failure code not
normally used for "user unknown" (550) is suggested; 554 seems an normally used for "user unknown" (550) is preferred; therefore, 554
appropriate candidate and thus SHOULD be used. If the rejecting SMTP SHOULD be used. {DKIM 12} If the rejecting SMTP server supports
server supports [ENHANCED] status codes, it SHOULD make a distinction [ENHANCED] status codes, it SHOULD make a distinction between
between messages rejected deliberately due to policy decisions rather messages rejected deliberately due to policy decisions rather than
than those rejected because of other deliverability issues. In those rejected because of other delivery issues {DKIM 9}. In
particular, a policy rejection SHOULD be relayed using a 5.7.1 particular, a policy rejection SHOULD be relayed using a 5.7.1
enhanced status code and some appropriate wording in the text part of enhanced status code and some appropriate wording in the text part of
the reply, in contrast to a code of 5.1.1 indicating the user does the reply, in contrast to a code of 5.1.1 indicating the user does
not exist. Those MLMs that automatically attempt to remove users not exist. Those MLMs that automatically attempt to remove users
with prolonged delivery problems (such as account deletion) SHOULD with prolonged delivery problems (such as account deletion) SHOULD
thus detect the difference between policy rejection and other thus detect the difference between policy rejection and other
delivery failures, and act accordingly. SMTP servers doing so SHOULD delivery failures, and act accordingly. SMTP servers doing so SHOULD
also use appropriate wording in the text portion of the reply, also use appropriate wording in the text portion of the reply,
perhaps explicitly using the string "ADSP" to facilitate searching of perhaps explicitly using the string "ADSP" to facilitate searching of
relevant data in logs. relevant data in logs.
The preceding paragraph does not apply to an [ADSP] policy of The preceding paragraph does not apply to an [ADSP] policy of
"discardable". In such cases where the submission fails that test, "discardable". In such cases where the submission fails that test,
the receiver or verifier SHOULD discard the message but return an the receiver or verifier SHOULD discard the message but return an
SMTP success code, i.e. accept the message but drop it without SMTP success code, i.e. accept the message but drop it without
delivery. An SMTP rejection of such mail instead of the requested delivery. An SMTP rejection of such mail instead of the requested
discard action causes more harm than good. discard action causes more harm than good.
6. DKIM Reporting 7. DKIM Reporting
The MARF working group is developing mechanisms for reporting As mechanisms become available for reporting forensic details about
forensic details about DKIM verification failures. At the time of DKIM verification failures, MLMs will benefit from their use. {DKIM
this writing, this is still a work in progress. 12}
MLMs SHOULD apply these or other DKIM failure reporting mechanisms as MLMs SHOULD apply DKIM failure reporting mechanisms as a method for
a method for providing feedback to signers about issues with DKIM providing feedback to signers about issues with DKIM infrastructure.
infrastructure. This is especially important for MLMs that implement This is especially important for MLMs that implement DKIM
DKIM verification as a mechanism for authentication of list verification as a mechanism for authentication of list configuration
configuration commands and submissions from subscribers. commands and submissions from subscribers.
7. IANA Considerations 8. IANA Considerations
This document includes no IANA actions. This document includes no IANA actions.
8. Security Considerations 9. Security Considerations
This document provides suggested or best current practices for use This document provides suggested or best current practices for use
with DKIM, and as such does not introduce any new technologies for with DKIM, and as such does not introduce any new technologies for
consideration. However, the following security issues should be consideration. However, the following security issues should be
considered when implementing the above practices. considered when implementing the above practices.
8.1. Authentication Results When Relaying 9.1. Security Considerations from DKIM and ADSP
Section 5 advocates addition of an [AUTH-RESULTS] header field to Readers should be familiar with the material in the Security
Considerations in [DKIM], [ADSP] and [AUTH-RESULTS] as appropriate.
{DKIM 9}
9.2. Authentication Results When Relaying
Section 6 advocates addition of an [AUTH-RESULTS] header field to
indicate authentication status of a message received as MLM Input. indicate authentication status of a message received as MLM Input.
Per Section 7.2 of [AUTH-RESULTS], receivers generally should not 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 trust such data without a good reason to do so, such as an a priori
agreement with the MLM's ADMD. agreement with the MLM's ADMD.
Such agreements are strongly advised to include a requirement that Such agreements are strongly advised to include a requirement that
those header fields be covered by a [DKIM] signature added by the those header fields be covered by a [DKIM] signature added by the
MLM's ADMD. MLM's ADMD.
9. References 10. References
9.1. Normative References 10.1. Normative References
[ADSP] Allman, E., Delany, M., Fenton, J., and J. Levine, "DKIM [ADSP] Allman, E., Delany, M., Fenton, J., and J. Levine, "DKIM
Sender Signing Practises", RFC 5617, August 2009. Sender Signing Practises", RFC 5617, August 2009.
[AUTH-RESULTS] [AUTH-RESULTS]
Kucherawy, M., "Message Header Field for Indicating Kucherawy, M., "Message Header Field for Indicating
Message Authentication Status", RFC 5451, April 2009. Message Authentication Status", RFC 5451, April 2009.
[DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, [DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
J., and M. Thomas, "DomainKeys Identified Mail (DKIM) J., and M. Thomas, "DomainKeys Identified Mail (DKIM)
Signatures", RFC 4871, May 2007. Signatures", RFC 4871, May 2007.
[EMAIL-ARCH] [EMAIL-ARCH]
Crocker, D., "Internet Mail Architecture", RFC 5598, Crocker, D., "Internet Mail Architecture", RFC 5598,
July 2009. July 2009.
[KEYWORDS]
Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[MAIL] Resnick, P., "Internet Message Format", RFC 5322, [MAIL] Resnick, P., "Internet Message Format", RFC 5322,
October 2008. October 2008.
9.2. Informative References 10.2. Informative References
[DKIM-DEPLOYMENT] [DKIM-DEPLOYMENT]
Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker, Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker,
"DomainKeys Identified Mail (DKIM) Development, Deployment "DomainKeys Identified Mail (DKIM) Development, Deployment
and Operations", I-D DRAFT-IETF-DKIM-DEPLOYMENT, and Operations", I-D DRAFT-IETF-DKIM-DEPLOYMENT,
January 2010. January 2010.
[DKIM-OVERVIEW] [DKIM-OVERVIEW]
Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys
Identified Mail (DKIM) Service Overview", RFC 5585, Identified Mail (DKIM) Service Overview", RFC 5585,
July 2009. July 2009.
[DKIM-UPDATE]
Crocker, D., "RFC 4871 DomainKeys Identified Mail (DKIM)
Signatures -- Update", RFC 5672, August 2009.
[ENHANCED] [ENHANCED]
Vaudreuil, G., "Enhanced Mail System Status Codes", Vaudreuil, G., "Enhanced Mail System Status Codes",
RFC 3463, January 2003. RFC 3463, January 2003.
[IODEF] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident [IODEF] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident
Object Description Exchange Format", RFC 5070, Object Description Exchange Format", RFC 5070,
December 2007. December 2007.
[LIST-ID] Chandhok, R. and G. Wenger, "List-Id: A Structured Field [LIST-ID] Chandhok, R. and G. Wenger, "List-Id: A Structured Field
and Namespace for the Identification of Mailing Lists", and Namespace for the Identification of Mailing Lists",
skipping to change at page 27, line 9 skipping to change at page 30, line 9
Extensions (MIME) Part Two: Media Types", RFC 2046, Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996. November 1996.
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008. October 2008.
Appendix A. Acknowledgements Appendix A. Acknowledgements
The author wishes to acknowledge the following for their review and The author wishes to acknowledge the following for their review and
constructive criticism of this document: Serge Aumont, Daniel Black, constructive criticism of this document: Serge Aumont, Daniel Black,
Dave Crocker, JD Falk, Tony Hansen, Eliot Lear, Charles Lindsey, John Dave Crocker, J.D. Falk, Tony Hansen, Eliot Lear, Charles Lindsey,
Levine, Jeff Macdonald, S. Moonesamy, Rolf E. Sonneveld, and John Levine, Jeff Macdonald, S. Moonesamy, Rolf E. Sonneveld, and
Alessandro Vesely. Alessandro Vesely.
Appendix B. Example Scenarios Appendix B. Example Scenarios
This section describes a few MLM-related DKIM scenarios that were This section describes a few MLM-related DKIM scenarios that were
part of the impetus for this work, and the recommended resolutions part of the impetus for this work, and the recommended resolutions
for each. for each.
B.1. MLMs and ADSP B.1. MLMs and ADSP
 End of changes. 108 change blocks. 
400 lines changed or deleted 459 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/