< draft-ietf-dkim-mailinglists-01.txt   draft-ietf-dkim-mailinglists-02.txt >
DKIM Working Group M. Kucherawy DKIM Working Group M. Kucherawy
Internet-Draft Cloudmark Internet-Draft Cloudmark
Intended status: Informational July 26, 2010 Intended status: Informational August 10, 2010
Expires: January 27, 2011 Expires: February 11, 2011
DKIM And Mailing Lists DKIM And Mailing Lists
draft-ietf-dkim-mailinglists-01 draft-ietf-dkim-mailinglists-02
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. As the
industry has now gained some deployment experience, the goal for this industry has now gained some deployment experience, the goal for this
document is to explore the use of DKIM for scenarios that include document is to explore the use of DKIM for scenarios that include
intermediaries, such as Mailing List Managers (MLMs). intermediaries, such as Mailing List Managers (MLMs).
Status of this Memo Status of this Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 January 27, 2011. This Internet-Draft will expire on February 11, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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
skipping to change at page 2, line 12 skipping to change at page 2, line 12
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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. MLMs In Infrastructure . . . . . . . . . . . . . . . . . . 4 1.2. MLMs In Infrastructure . . . . . . . . . . . . . . . . . . 4
1.3. Feedback Loops And Other Bi-Lateral Agreements . . . . . . 5 1.3. Feedback Loops And Other Bi-Lateral Agreements . . . . . . 5
1.4. Document Scope and Goals . . . . . . . . . . . . . . . . . 5 1.4. Document Scope and Goals . . . . . . . . . . . . . . . . . 5
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Other Terms . . . . . . . . . . . . . . . . . . . . . . . 7 2.1. Other Terms . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. DKIM-Specific References . . . . . . . . . . . . . . . . . 7 2.2. DKIM-Specific References . . . . . . . . . . . . . . . . . 6
2.3. Feedback Loop References . . . . . . . . . . . . . . . . . 7 2.3. 'DKIM-Friendly' . . . . . . . . . . . . . . . . . . . . . 6
2.4. Message Streams . . . . . . . . . . . . . . . . . . . . . 7 2.4. Feedback Loop References . . . . . . . . . . . . . . . . . 6
3. Mailing Lists and DKIM . . . . . . . . . . . . . . . . . . . . 8 2.5. Message Streams . . . . . . . . . . . . . . . . . . . . . 6
3.1. Roles and Realities . . . . . . . . . . . . . . . . . . . 8 3. Mailing Lists and DKIM . . . . . . . . . . . . . . . . . . . . 7
3.2. Types Of Mailing Lists . . . . . . . . . . . . . . . . . . 9 3.1. Roles and Realities . . . . . . . . . . . . . . . . . . . 7
3.3. Current MLM Effects On Signatures . . . . . . . . . . . . 10 3.2. Types Of Mailing Lists . . . . . . . . . . . . . . . . . . 8
3.4. Alternatives of Participation and Conformance . . . . . . 11 3.3. Current MLM Effects On Signatures . . . . . . . . . . . . 9
4. Non-Participating MLMs . . . . . . . . . . . . . . . . . . . . 13 4. Non-Participating MLMs . . . . . . . . . . . . . . . . . . . . 11
4.1. Author-Related Signing . . . . . . . . . . . . . . . . . . 13 4.1. Author-Related Signing . . . . . . . . . . . . . . . . . . 11
4.2. Verification Outcomes at Receivers . . . . . . . . . . . . 13 4.2. Verification Outcomes at Receivers . . . . . . . . . . . . 12
4.3. Handling Choices at Receivers . . . . . . . . . . . . . . 14 4.3. Handling Choices at Receivers . . . . . . . . . . . . . . 12
5. Participating MLMs . . . . . . . . . . . . . . . . . . . . . . 15 4.4. Wrapping A Non-Participating MLM . . . . . . . . . . . . . 12
5.1. Subscriptions . . . . . . . . . . . . . . . . . . . . . . 15 5. Participating MLMs . . . . . . . . . . . . . . . . . . . . . . 13
5.2. Author-Related Signing . . . . . . . . . . . . . . . . . . 15 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.3. Verification Outcomes at MLMs . . . . . . . . . . . . . . 16 5.2. DKIM Author Domain Signing Practices . . . . . . . . . . . 13
5.4. Pros and Cons of Signature Removal . . . . . . . . . . . . 16 5.3. Subscriptions . . . . . . . . . . . . . . . . . . . . . . 14
5.5. DKIM Author Domain Signing Practices . . . . . . . . . . . 17 5.4. Author-Related Signing . . . . . . . . . . . . . . . . . . 14
5.6. MLM Signatures . . . . . . . . . . . . . . . . . . . . . . 18 5.5. Verification Outcomes at MLMs . . . . . . . . . . . . . . 15
5.7. Verification Outcomes at Final Receiving Sites . . . . . . 19 5.6. Pros and Cons of Signature Removal . . . . . . . . . . . . 15
5.8. Use With FBLs . . . . . . . . . . . . . . . . . . . . . . 19 5.7. MLM Signatures . . . . . . . . . . . . . . . . . . . . . . 17
5.9. Handling Choices at Receivers . . . . . . . . . . . . . . 20 5.8. Verification Outcomes at Final Receiving Sites . . . . . . 18
6. DKIM Reporting . . . . . . . . . . . . . . . . . . . . . . . . 21 5.9. Use With FBLs . . . . . . . . . . . . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 5.10. Handling Choices at Receivers . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 6. DKIM Reporting . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Authentication Results When Relaying . . . . . . . . . . . 23 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . . . 24 8.1. Authentication Results When Relaying . . . . . . . . . . . 22
9.2. Informative References . . . . . . . . . . . . . . . . . . 24 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 26 9.1. Normative References . . . . . . . . . . . . . . . . . . . 23
Appendix B. Example Scenarios . . . . . . . . . . . . . . . . . . 27 9.2. Informative References . . . . . . . . . . . . . . . . . . 23
B.1. MLMs and ADSP . . . . . . . . . . . . . . . . . . . . . . 27 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 25
B.2. MLMs and FBLs . . . . . . . . . . . . . . . . . . . . . . 27 Appendix B. Example Scenarios . . . . . . . . . . . . . . . . . . 26
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 28 B.1. MLMs and ADSP . . . . . . . . . . . . . . . . . . . . . . 26
B.2. MLMs and FBLs . . . . . . . . . . . . . . . . . . . . . . 26
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
[DKIM] allows an Administrative Mail Domain to take some [DKIM] allows an Administrative Mail Domain to take some
responsibility for a [MAIL] message. This can be an author's responsibility for a [MAIL] message. This can be an author's
organization, an operational relay (Mail Transfer Agent, or MTA) or organization, an operational relay (Mail Transfer Agent, or MTA) or
one of their agents. Assertion of responsibility is made through a one of their agents. Assertion of responsibility is made through a
cryptographic signature. Message transit from author to recipient is cryptographic signature. Message transit from author to recipient is
through relays that typically make no substantive change to the through relays that typically make no substantive change to the
message content and thus preserve the DKIM signature. message content and thus preserve the DKIM signature.
skipping to change at page 3, line 42 skipping to change at page 3, line 42
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
useful views worth considering. useful views worth considering.
This document explores changes to common practice by the signers, the This document explores changes to common practice by the signers, the
verifiers and the MLMs. verifiers and the MLMs.
In general there are, in relation to DKIM, two categories of MLMs:
participating and non-participating. As both types have their own
issues regarding DKIM-signed messages that are either handled or
produced by them (or both), they are discussed in separate sections.
1.1. Background 1.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 domain-level digital signature to the message as it passes affixing a domain-level digital signature to the message as it passes
through a gateway. Although not the only possibility, this is most through a gateway. Although not the only possibility, this is most
commonly done as a message passes through a Mail Transport Agent commonly done as a message passes through a Mail Transport Agent
(MTA) as it departs an Administrative Mail Domain (ADMD) toward the (MTA) as it departs an Administrative Mail Domain (ADMD) toward the
general Internet. general Internet.
DKIM signatures will fail to verify if a portion of the message DKIM signatures will fail to verify if a portion of the message
covered by one of its hashes is altered. MLMs commonly alter covered by one of its hashes is altered. MLMs commonly alter
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 include: which it is providing service. Common modifications are enumerated
and described in Section 3.3. This does not consider consider
o Prefix the RFC5322.Subject field with a short string for easy changes the MTA might make independent of what changes the MLM
sorting by receivers' Mail User Agents (MUAs) or other filtering chooses to apply.
software;
o Prepend or append list management information to the message's
body, such as some text and/or a URL to which subscribers can go
to make administrative changes to their subscriptions;
o Add header fields such as Reply-To:, Sender:, Resent-Sender:
([MAIL]), List-Id: ([LIST-ID]), List-Post: or List-Unsubscribe:
([LIST-URLS]). In some cases, such header fields are replaced if
the original message already contained them.
The above list is not exhaustive, but instead only lists common
modifications. It also does not consider changes the MTA might make
independent of what changes the MLM chooses to apply.
The DKIM specification documents deliberately refrain from the notion The DKIM specification documents deliberately refrain from the notion
of tying the signing domain (the "d=" tag in a DKIM signature) to any of tying the signing domain (the "d=" tag in a DKIM signature) to any
identifier within a message; any ADMD could sign any message identifier within a message; any ADMD could sign any message
regardless of its origin or author domain. As such, there is no regardless of its origin or author domain. As such, there is no
specification of any additional value if the content of the "d=" tag specification of any additional value if the content of the "d=" tag
in the DKIM signature and the value of (for example) the RFC5322.From in the DKIM signature and the value of (for example) the RFC5322.From
field match, nor is there any obvious degraded value to a signature field match, nor is there any obvious degraded value to a signature
where they do not match. Since any DKIM signature is merely an where they do not match. Since any DKIM signature is merely an
assertion of "some" responsibility by an ADMD, a DKIM signature added assertion of "some" responsibility by an ADMD, a DKIM signature added
skipping to change at page 5, line 47 skipping to change at page 5, line 38
that site for mail coming from the sender. that site for mail coming from the sender.
An FBL reporting address is part of this bi-lateral registration. An FBL reporting address is part of this bi-lateral registration.
Some FBLs require DKIM use by the registrant. Messages signed and Some FBLs require DKIM use by the registrant. Messages signed and
sent by a registrant through an MLM can therefore result in having sent by a registrant through an MLM can therefore result in having
abuse reports sent to the original author when the actual problem abuse reports sent to the original author when the actual problem
pertains to the operation of the MLM. However, the original author pertains to the operation of the MLM. However, the original author
has no involvement in operation of the MLM, meaning the FBL report is has no involvement in operation of the MLM, meaning the FBL report is
not actionable and thus undesirable. not actionable and thus undesirable.
See Section 6 for additional discussion.
1.4. Document Scope and Goals 1.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. An attempt handling of possible interactions between DKIM and MLMs. An attempt
has been made to prefer imposing changes to behaviour at the signer has been made to prefer imposing changes to behaviour at the signer
and verifier rather than at the MLM. and verifier rather than at the MLM.
Wherever possible, MLMs will be conceptually decoupled from MTAs Wherever possible, MLMs will be conceptually decoupled from MTAs
despite the very tight integration that is sometimes observed in despite the very tight integration that is sometimes observed in
implementation. This is done to emphasize the functional implementation. This is done to emphasize the functional
skipping to change at page 7, line 20 skipping to change at page 6, line 20
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 2.2. 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 standards-track protocol documents as well as which are standards-track protocol documents as well as
[DKIM-OVERVIEW] and [DKIM-DEPLOYMENT] which are DKIM's primary [DKIM-OVERVIEW] and [DKIM-DEPLOYMENT] which are DKIM's primary
tutorial documents. tutorial documents.
2.3. Feedback Loop References 2.3. 'DKIM-Friendly'
The term "DKIM-Friendly" is used to describe an email intermediary
that, when handling a message, makes no changes to that message which
cause [DKIM] signatures present on the message on input to fail to
verify on output.
Various features of MTAs and MLMs seen as helpful to users often have
side-effects that do render DKIM signatures unverifiable. These
would not qualify for this label.
2.4. Feedback Loop References
FBLs tend to use the ARF ([I-D.DRAFT-IETF-MARF-BASE]) or the IODEF FBLs tend to use the ARF ([I-D.DRAFT-IETF-MARF-BASE]) or the IODEF
([IODEF]) format. ([IODEF]) format.
2.4. Message Streams 2.5. Message Streams
This document makes reference to the concept of "message streams". This document makes reference to the concept of "message streams".
The idea is to identify groups of messages originating from within an The idea is to identify groups of messages originating from within an
ADMD that are distinct in intent, origin and/or use, and partition ADMD that are distinct in intent, origin and/or use, and partition
them somehow (most commonly via DNS subdomains, and/or the "d=" tag them somehow (most commonly via DNS subdomains, and/or the "d=" tag
value in the context of DKIM) so as to keep them associated to users value in the context of DKIM) so as to keep them associated to users
yet operationally distinct. yet operationally distinct.
A good example might be user mail, generated by a company's A good example might be user mail, generated by a company's
employees, versus operational or transactional mail that comes from employees, versus operational or transactional mail that comes from
skipping to change at page 9, line 15 skipping to change at page 8, line 15
3.2. Types Of Mailing Lists 3.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 a message as it redistributes; any
modifications are constrained to changes to the [SMTP] envelope modifications are constrained to changes to the [SMTP] envelope
recipient list (RCPT commands) only. There are no changes to the recipient list (RCPT commands) only. There are no changes to the
message body at all and only [MAIL] trace header fields are added. message body at all and only [MAIL] trace header fields are added.
The output of such an MLM is considered to be a continuation of The output of such an MLM is considered to be a continuation of
the author's original message. An example of such an MLM is a the author's original message. An example of such an MLM is an
address that expands directly in the MTA, such as a list of local address that expands directly in the MTA, such as a list of local
system administrators used for relaying operational or other system administrators used for relaying operational or other
internal-only messages. See also Section 3.9.2 of [SMTP]. 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
skipping to change at page 10, line 10 skipping to change at page 9, line 10
corresponding to the following SMTP transactions: corresponding to the following SMTP transactions:
MLM Input: Originating user is author; originating ADMD is signer; MLM Input: Originating user is author; originating ADMD is signer;
MLM's ADMD is verifier; MLM's input function is receiver. MLM's ADMD is verifier; MLM's input function is receiver.
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 signer; the ADMD of each user's message) is author; MLM's ADMD is signer; the ADMD of each
subscriber of the list is a verifier; each subscriber is a subscriber of the list is a verifier; each subscriber is a
receiver. receiver.
Much of this document focuses on the resending MLM as it has the most Much of this document focuses on the resending MLM as it has the
direct conflict operationally with DKIM. widest range of possible interactions 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 steps allows the DKIM-specific issues with respect to MLMs to be
isolated and handled in a logical way. The main issue is that the isolated and handled in a logical way. The main issue is that the
repackaging and reposting of a message by an MLM is actually the 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 3.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 new content and thus there signature, and an authoring MLM is always new content and thus there
is never an existing signature. However, the changes a resending MLM is never an existing signature. However, the changes a resending MLM
can make typically affect the RFC5322.Subject header field, addition can make typically affect the RFC5322.Subject header field, addition
of some list-specific header fields, and/or the addition of some of some list-specific header fields, and/or modification of the
list-specific text to the top or bottom of the message body. The message body. The impacts of each of these on DKIM verification are
impacts of each of these on DKIM verification are discussed below. discussed below.
Subject tags: Altering the RFC5322.Subject field by adding a list- Subject tags: Altering the RFC5322.Subject field by adding a list-
specific prefix will invalidate the signer's signature if that specific prefix or suffix will invalidate the signer's signature
header field was covered by a hash of that signature. [DKIM] if that header field was covered by a hash of that signature.
lists RFC5322.Subject as one that should be covered, so this is [DKIM] lists RFC5322.Subject as one that should be covered, so
expected to be an issue for any list that makes such changes. this is expected to be an issue for any list that makes such
changes.
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 (though see notes about the addition of header fields in general (though see notes about the
"h=" tag in Section 3.5 of [DKIM]). Therefore this is seen as "h=" tag in Section 3.5 of [DKIM]). Therefore this is seen as
less of a concern. less of a concern.
skipping to change at page 11, line 18 skipping to change at page 10, line 18
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 this could cause a concern for MLMs that add or signed, and this could cause a concern for MLMs that add or
replace them. replace them.
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
pose an immediate problem. will render any exisitng signatures unverifiable.
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 deleting, reordering, or reformatting [MIME] parts, such as deleting, reordering, or reformatting [MIME] parts,
"flatten" HTML messages into plain text, or insert headers or "flatten" HTML messages into plain text, or insert headers or
footers within HTML messages. Most or all of these changes will footers within HTML messages. Most or all of these changes will
invalidate a DKIM signature with little or no hope of compensation invalidate a DKIM signature.
by either the signer or the verifier.
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. inadvertent automated malware delivery.
There reportedly still exist a few scattered mailing lists in There reportedly still exist a few scattered 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
In general, an MLM subscriber cannot be expected to be able to the above or even some other changes.
reconstruct the original message as it appeared at time of signing
and thus whether or not an author signature is actually valid after
MLM rewriting. Moreover, even if an MLM currently passes messages
unmodified such that author signatures validate, it is possible that
a configuration change or software upgrade to that MLM will cause
that no longer to be true.
3.4. Alternatives of Participation and Conformance
As DKIM becomes more entrenched, it is highly desirable that MLM
software adopt more DKIM-friendly processing.
Changes that merely add new header fields, such as those specified by
[LIST-ID], [LIST-URLS] and [MAIL] are generally the most friendly to
a DKIM-participating email infrastructure in that their addition by
an MLM will not affect any existing DKIM signatures unless those
fields were already present and covered by a signature's hash or a
signature was created specifically to disallow their addition (see
the note about "h=" in Section 3.5 of [DKIM]). The shortest path to
success for DKIM would be to mandate that all MLM software be re-
designed or re-configured with that goal in mind.
However, the practice of applying headers and footers to message
bodies is common and not expected to fade regardless of what
documents this or any standards body might produce. This sort of
change will invalidate the signature on a message where the body hash
covers the entire entire message. Thus, the following sections also
investigate and recommend other processing alternatives.
A possible mitigation to this incompatibility is use of the "l=" tag
to bound the portion of the body covered by the body hash, but this
not workable for [MIME] messages and moreover has security
considerations (see Section 3.5 of [DKIM]). Its use is therefore
discouraged.
There is currently no header field proposed for relaying general list In general, an MLM subscriber cannot expect signatures applied before
policy details, apart from what [LIST-URLS] already supports. This hte message was processed by the MLM to be valid. Moreover, even if
sort of information is what is commonly included in appended footer an MLM currently passes messages unmodified such that author
text or prepended header text. Rather than anticipating or proposing signatures validate, it is possible that a configuration change or
a new field here for that purpose, the working group recommends software upgrade to that MLM will cause that no longer to be true.
periodic, automatic mailings to the list to remind subscribers of
list policy. These will be repetitive, of course, but by being
generally the same each time they can be easily filtered if needed.
4. Non-Participating MLMs 4. 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 4.1. Author-Related Signing
If an author knows that the MLM to which a message is being sent is a If an author knows that the MLM to which a message is being sent is a
non-participating resending MLM, the author is advised to be cautious non-participating resending MLM, the author is advised to be cautious
when deciding whether or not to sign the message. The MLM could make when deciding whether or not to send to the list when that mail would
a change that would invalidate the author's signature but not remove be signed. The MLM could make a change that would invalidate the
it prior to re-distribution. Hence, list recipients would receive a author's signature but not remove it prior to re-distribution.
message purportedly from the author but bearing a DKIM signature that Hence, list recipients would receive a message purportedly from the
would not verifiy. This problem would be compounded further if there author but bearing a DKIM signature that would not verifiy. There
were receivers that applied signing policies ([ADSP]) and the author exist DKIM modules that incorrectly penalize messages with signatures
that do not validate, so this may have have detrimental effects
outside of the author's control. (Additional discussion of this is
below.) This problem could be compounded further if there were
receivers that applied signing policies (e.g., [ADSP]) and the author
published any kind of strict policy. published any kind of strict policy.
If this is cause for concern, the originating site can consider using For domains that do publish strict ADSP policies, the originating
a separate message stream, such as a sub-domain, for the "personal" site can consider using a separate message stream, such as a sub-
mail that is different from domain(s) used for other mail streams, so domain, for the "personal" mail that is different from domain(s) used
that they develop independent reputations, and more stringent for other mail streams, so that they develop independent reputations,
policies (including ADSP) can be applied to the mail stream(s) that and more stringent policies (including ADSP) can be applied to the
do not go through mailing lists. mail stream(s) that do not go through mailing lists or perhaps do not
get signed at all.
However, all of this presupposes a level of infrastructure 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. A common suggestion is to establish achieves wider adoption. A common suggestion is to establish
subdomains in the DNS that are used for separating different streams subdomains in the DNS that are used for separating different streams
of mail from within an ADMD, such as user-created "direct" mail from of mail from within an ADMD, such as user-created "direct" mail from
transactional or automated mail; some of these may be signed and some transactional or automated mail; some of these may be signed and some
not, some with published ADSP records, some not. In general, the not, some with published ADSP records, some not. In general, the
more strict practices and policies are likely to be successful only more strict practices and policies are likely to be successful only
for the mail streams subject to the most end-to-end control by the for the mail streams subject to the most end-to-end control by the
originating organization. That typically excludes mail going through originating organization. That typically excludes mail going through
MLMs. MLMs.
4.2. Verification Outcomes at Receivers 4.2. Verification Outcomes at Receivers
There does not appear to be a reliable way to determine that a piece There does not appear to be a reliable way to determine that a piece
of mail arrived via a non-participating MLM. Thus, it is not of mail arrived via a non-participating MLM. Sites whose users
reasonably possible to suggest any particular processing heuristics subscribe to non-participating MLMs should be prepared for legitimate
specific to this case with respect to DKIM and ADSP. mail to arrive with no valid signature, just as it always has in the
absence of DKIM.
4.3. Handling Choices at Receivers 4.3. Handling Choices at Receivers
A receiver's ADMD would have to have some way to register such non- A receiver's ADMD would have to have some way to register such non-
participating lists to exempt them from the filtering described in participating lists to exempt them from the signing decision
Section 4.1. This is, however, probably not a scalable solution as described in Section 4.1. This is, however, probably not a scalable
it imposes a burden on the receiver that is predicated on sender solution as it imposes a burden on the receiver that is predicated on
behaviour. sender behaviour.
Note that the [DKIM] specification explicitly directs verifiers to Note that the [DKIM] specification explicitly directs verifiers to
treat a verification failure as though the message were not signed in treat a verification failure as though the message was not signed in
the first place. In the absence of specific ADSP direction, any the first place. In the absence of specific ADSP direction, any
treatment of a verification failure as having special meaning is treatment of a verification failure as having special meaning is
either outside the scope of DKIM or is in violation of it. either outside the scope of DKIM or is in violation of it.
[ADSP] presents an additional challenge. Per that specification, Use of restrictive domain policies such as [ADSP] "discardable"
when a message is unsigned or the signature can no longer be presents an additional challenge. Per that specification, when a
verified, the verifier must discard the message. There is no message is unsigned or the signature can no longer be verified, the
exception in the policy for a message that may have been altered by verifier must discard the message. There is no exception in the
an MLM. Verifiers are thus advised to honor the policy and disallow policy for a message that may have been altered by an MLM. Verifiers
the message. Furthermore, authors whose ADSP is published as are thus advised to honor the policy and disallow the message.
"discardable" are advised not to send mail to MLMs as it is likely to Furthermore, authors whose ADSP is published as "discardable" are
be rejected by ADSP-aware recipients. (This is discussed further in advised not to send mail to MLMs as it is likely to be rejected by
Section 5.4 below.) ADSP-aware recipients. (This is discussed further in Section 5.6
below.)
4.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 provide DKIM signing services.
5. Participating MLMs 5. 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 DKIM-aware, and may also be signed mail to or through an MLM that is DKIM-aware, and may also be
ADSP-aware. ADSP-aware.
5.1. Subscriptions 5.1. General
As DKIM becomes more entrenched, it is highly desirable that MLM
software adopt more DKIM-friendly processing.
Changes that merely add new header fields, such as those specified by
[LIST-ID], [LIST-URLS] and [MAIL] are generally the most friendly to
a DKIM-participating email infrastructure in that their addition by
an MLM will not affect any existing DKIM signatures unless those
fields were already present and covered by a signature's hash or a
signature was created specifically to disallow their addition (see
the note about "h=" in Section 3.5 of [DKIM]).
However, the practice of applying headers and footers to message
bodies is common and not expected to fade regardless of what
documents this or any standards body might produce. This sort of
change will invalidate the signature on a message where the body hash
covers the entire message. Thus, the following sections also
investigate and recommend other processing alternatives.
A possible mitigation to this incompatibility is use of the "l=" tag
to bound the portion of the body covered by the DKIM body hash, but
this is not workable for [MIME] messages and moreover has security
considerations (see Section 3.5 of [DKIM]). Its use is therefore
discouraged.
There is currently no header field proposed for relaying general list
policy details, apart from what [LIST-URLS] already supports. This
sort of information is what is commonly included in appended footer
text or prepended header text. The working group recommends
periodic, automatic mailings to the list to remind subscribers of
list policy. These will be repetitive, of course, but by being
generally the same each time they can be easily filtered if needed.
5.2. DKIM Author Domain Signing Practices
[ADSP] presents a particular challenge. An author domain posting a
policy of "discardable" imposes a very tight restriction on the use
of mailing lists, essentially constraining that domain's users to
lists operated by aliasing MLMs only; any MLM that alters a message
from such a domain or removes its signature subjects the message to
severe action by receivers. It is the consensus of the working group
that a resending MLM is advised to reject outright any mail from an
author whose domain posts such a policy as it is likely to be
rejected by any ADSP-aware recipients, and might also be well advised
to discourage such subscribers when first signing up to the list.
Further discussion of this appears in Section 5.3.
Where the above practice is not observed and "discardable" mail
arrives via a list to a verifier that applies ADSP checks, the
verifier can either discard the message (i.e. accept the message at
the [SMTP] level but discard it without delivery) or conduct an SMTP
rejection by returning a 5xx error code. In the latter case, some
advice for how to conduct the rejection in a potentially meaningful
way can be found in Section 5.10.
See also Appendix B.5 of [ADSP] for further discussion.
5.3. Subscriptions
At subscription time, an ADSP-aware MLM could check for a published At subscription time, an ADSP-aware MLM could check for a published
ADSP record for the new subscriber, and present a warning for one ADSP record for the new subscriber, and disallow or present a warning
whose ADMD's published policy is "discardable" indicating that to one whose ADMD's published policy is "discardable" indicating that
submissions from that ADMD may not be deliverable because of submissions from that ADMD may not be deliverable because of
modifications that are likely to be made to the message. modifications that are likely to be made to the message.
Of course, such a policy could be applied after subscription, so this Of course, such a policy record could be applied after subscription,
is not a universal solution. An MLM implementation could do periodic so this is not a universal solution. An MLM implementation could do
checks of its subscribers and issue warnings where such a policy is periodic checks of its subscribers and issue warnings where such a
detected. policy is detected.
5.2. Author-Related Signing
MLMs typically attempt to authenticate messages posted through them. 5.4. Author-Related Signing
They usually do this through the trivial (and insecure) means of
verifying the RFC5322.From field email address (or, less frequently,
the RFC5321.MailFrom parameter) against a list registry. DKIM
enables a stronger form of authentication, although this is not yet
formally documented: It can require that messages using a given
RFC5322.From address also have a DKIM signature with a corresponding
"d=" domain. (Note, however, that it is entirely reasonable for an
MLM to permit registration of some other "d=" domain as valid
evidence of such authentication.) This feature would be somewhat
similar to using ADSP, except that the requirement for it would be
imposed by the MLM and not the author's organization.
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. As such, a signed message
from an author will in essence go to a set of unexpected places. from an author will in essence go to a set of unexpected places,
Authors may be well-advised to create a mail stream specifically used sometimes coupled with other messages from other sources. In the
for generating signatures when sending traffic to MLMs. This becomes future, as DKIM signature outputs (e.g. the SDID of [DKIM-UPDATE])
important as domain-based reputation systems begin to appear as are used as inputs to reputation modules, there may be a desire to
components of mail filtering modules. insulate one's reputation from influence by the unknown results of
sending mail through an MLM. In that case, authors may be well-
advised to create a mail stream specifically used for generating
signatures when sending traffic to MLMs.
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 come from a
different mail stream than a stream that serves a broader purpose. different mail stream than a stream that serves a broader purpose.
5.3. Verification Outcomes at MLMs 5.5. Verification Outcomes at MLMs
As described above, the MLM might conduct DKIM verification of a MLMs typically attempt to authenticate messages posted through them.
signed message to attempt to confirm the identity of the author. They usually do this through the trivial (and insecure) means of
Although it is a common and intuitive conclusion, however, not all verifying the RFC5322.From field email address (or, less frequently,
signed mail will include an author signature (see [ADSP]). MLM the RFC5321.MailFrom parameter) against a list registry. DKIM
implementors are advised to accomodate such in their configurations. enables a stronger form of authentication, although this is not yet
For example, an MLM might be designed to accomodate a list of formally documented: It can require that messages using a given
possible signing domains (the "d=" portion of a DKIM signature) for a RFC5322.From address also have a DKIM signature with a corresponding
given author, and determine at verification time if any of those are "d=" domain. This feature would be somewhat similar to using ADSP,
present. except that the requirement for it would be imposed by the MLM and
not the author's organization.
As described, the MLM might conduct DKIM verification of a signed
message to attempt to confirm the identity of the author. Although
it is a common and intuitive conclusion, however, not all signed mail
will include an author signature (see [ADSP]). MLM implementors are
advised to accomodate such in their configurations. For example, an
MLM might be designed to accomodate a list of possible signing
domains (the "d=" portion of a DKIM signature) for a given author,
and determine at verification time if any of those are present.
A message that cannot be thus authenticated could be held for A message that cannot be thus authenticated could 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 could apply submission. In particular, this improved authentication could apply
to subscription, unsubscription, and/or changes to subscriber options to 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 subscriptions, MLMs are In the case of verification of signatures on subscriptions, MLMs are
advised to add an [AUTH-RESULTS] header field to indicate the advised to add an [AUTH-RESULTS] header field to indicate the
signature(s) observed on the submission as it arrived at the MLM and signature(s) observed on the submission as it arrived at the MLM and
what the outcome of the evaluation was. Downstream agents may or may what the outcome of the evaluation was. Downstream agents may or may
not trust the content of that header field depending on their own a not trust the content of that header field depending on their own a
priori knowledge of the operation of the ADMD generating (and, 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.4. Pros and Cons of Signature Removal 5.6. Pros and Cons of Signature Removal
A message that arrives signed with DKIM means some domain prior to
MLM Input has made a claim of some responsibility for the message.
An obvious benefit to leaving the input-side signatures intact, then,
is to preserve that chain of responsibility of the message so that
the receivers of the final message have an opportunity to evaluate
the message with that information available to them.
However, if the MLM is configured to make changes to the message
prior to re-posting that would invalidate the original signature(s),
further action is recommended to prevent invalidated signatures from
arriving at final recipients, possibly triggering unwarranted filter
actions. (Note, however, that such filtering actions are plainly
wrong; [DKIM] stipulates that an invalid signature is to be treated
as no signature at all.)
If the MLM is configured to make changes to the message prior to re-
posting that would invalidate the original signature(s), further
action is recommended to prevent invalidated signatures from arriving
at final recipients, possibly triggering unwarranted filter actions.
A possible solution would be to: A possible solution would be to:
1. Attempt verification of all DKIM signatures present on the input 1. Attempt verification of all DKIM signatures present on the input
message; message;
2. Apply local policy to authenticate the identity of the author; 2. Apply local policy to authenticate the identity of the author;
3. Add an [AUTH-RESULTS] header field to the message to indicate the 3. Add an [AUTH-RESULTS] header field to the message to indicate the
results of the above; results of the above;
skipping to change at page 17, line 4 skipping to change at page 16, line 24
1. Attempt verification of all DKIM signatures present on the input 1. Attempt verification of all DKIM signatures present on the input
message; message;
2. Apply local policy to authenticate the identity of the author; 2. Apply local policy to authenticate the identity of the author;
3. Add an [AUTH-RESULTS] header field to the message to indicate the 3. Add an [AUTH-RESULTS] header field to the message to indicate the
results of the above; results of the above;
4. Remove all previously-evaluated DKIM signatures; 4. Remove all previously-evaluated DKIM signatures;
5. Affix a new signature that covers the Authentication-Results 5. Affix a new signature that covers the Authentication-Results
header field just added. header field just added (see Section 5.7).
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 to the contrary. implementations to the contrary.
The MLM could re-evaluate exisiting signatures after making its The MLM could re-evaluate exisiting signatures after making its
skipping to change at page 17, line 41 skipping to change at page 17, line 13
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.5. DKIM Author Domain Signing Practices 5.7. MLM Signatures
[ADSP] presents a particular challenge. An author domain posting a
policy of "discardable" imposes a very tight restriction on the use
of mailing lists, essentially constraining that domain's users to
lists operated by aliasing MLMs only; any MLM that alters a message
from such a domain or removes its signature subjects the message to
severe action by receivers. It is the consensus of the working group
that a resending MLM is advised to reject outright any mail from an
author whose domain posts such a policy as it is likely to be
rejected by any ADSP-aware recipients, and might also be well advised
to present a warning to such subscribers when first signing up to the
list.
Where the above practice is not observed and "discardable" mail
arrives via a list to a verifier that applies ADSP checks, the
verifier can either discard the message (i.e. accept the message at
the [SMTP] level but discard it without delivery) or conduct an SMTP
rejection by returning a 5xx error code. In the latter case, some
advice for how to conduct the rejection in a potentially meaningful
way can be found in Section 5.9.
5.6. MLM Signatures
DKIM-aware resending MLMs and authoring MLMs are encouraged to affix DKIM-aware resending MLMs and authoring MLMs are encouraged to affix
their own signatures when distributing messages. The MLM is their own signatures when distributing messages. The MLM is
responsible for the alterations it makes to the original messages it responsible for the alterations it makes to the original messages it
is re-sending, and should express this via a signature. This is also is re-sending, and should express this via a signature. This is also
helpful for getting feedback from any FBLs that might be set up so helpful for getting feedback from any FBLs that might be set up so
that undesired list mail can generate appropriate action. that undesired list mail can generate appropriate action.
The use of MLM signatures will likely be used by recipient systems to
recognize list mail and gives the MLM's ADMD an opportunity to
develop a good reputation for the list itself.
A signing MLM is, as any other MLM, free to omit redistribution of a A signing MLM is, as any other MLM, free to omit redistribution of a
message from an author if that message was not signed in accordance message from an author if that message was not signed in accordance
with its own local configuration or policy. However, selective with its own local configuration or policy. However, selective
signing is discouraged; essentially that would create two message signing is discouraged; essentially that would create two message
streams from the MLM, one signed and one not, which can confuse DKIM- streams from the MLM, one signed and one not, which can confuse DKIM-
aware verifiers and receivers. aware verifiers and receivers.
As is typical with DKIM signing, the MLM signature must be generated As is typical with DKIM signing, the MLM signature must be generated
only after all modifications the MLM wishes to apply have been only after all modifications the MLM wishes to apply have been
completed. Failing to do so generates a signature that can not be completed. Failing to do so generates a signature that can not be
skipping to change at page 18, line 48 skipping to change at page 18, line 4
"d=" tag of the DKIM signature it will add to the new message. This "d=" tag of the DKIM signature it will add to the new message. This
could be used by verifiers or receivers to identify the DKIM could be used by verifiers or receivers to identify the DKIM
signature that was added by the MLM. This is not required, however; signature that was added by the MLM. This is not required, however;
it is believed the reputation of the signer will be a more critical it is believed the reputation of the signer will be a more critical
data point rather than this suggested binding. data point rather than this suggested binding.
Such MLMs are advised to ensure the signature's header hash will Such MLMs are advised to ensure the signature's header hash will
cover: cover:
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 is encouraged to sign the entire message A DKIM-aware resending MLM is encouraged to sign the entire message
as it arrived (i.e. the "MLM Input" from Section 3.2), especially after being prepared for distribution (i.e. the "MLM Output" from
including the original signatures. Section 3.2), including any original signatures.
DKIM-aware authoring MLMs are advised to sign the mail they send DKIM-aware authoring MLMs are advised to sign the mail they send
according to the regular signing guidelines given in [DKIM]. according to the regular signing guidelines given in [DKIM].
Operators of non-DKIM-aware MLMs could arrange to submit MLM mail Operators of non-DKIM-aware MLMs could arrange to submit MLM mail
through an MSA that is DKIM-aware so that its mail will be signed. through an MSA that is DKIM-aware so that its mail will be signed.
Some concern has been expressed about an MLM applying its signature Some concern has been expressed about an MLM applying its signature
to unsigned mail, which some verifiers or receivers might interpret to unsigned mail, which some verifiers or receivers might interpret
as conferring more authority to the message content. The working as conferring more authority to the message content. The working
group feels this is no different than present-day lists relaying group feels this is no different than present-day lists relaying
traffic and affixing RFC5322.Subject tags or similar, and thus it traffic and affixing RFC5322.Subject tags or similar, and thus it
doesn't introduce any new concerns. doesn't introduce any new concerns.
5.7. Verification Outcomes at Final Receiving Sites 5.8. Verification Outcomes at Final Receiving Sites
In general, verifiers and receivers can treat a signed message from In general, verifiers and receivers can treat a signed message from
an MLM like any other signed message; indeed, it would be difficult an MLM like any other signed message; indeed, it would be difficult
to discern any difference. to discern any difference.
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.4. discussed in Section 4.3 and Section 5.6, especially where an ADMD
has misused ADSP.
5.8. Use With FBLs 5.9. Use With FBLs
An FBL operator wishing act on a complaint by making use of DKIM An FBL operator may wish to act on a complaint from a user about a
verifications is advised to send a report to any domain with a valid posting to a list. Some FBLs could choose to generate feedback
reports based on DKIM verifications in the subject message. Such
operators are advised to send a report to all domains with a valid
signature that has an FBL agreement established, as DKIM signatures signature that has an FBL agreement established, as DKIM signatures
are claims of some responsibility for that message. Because authors are claims of some responsibility for that message. Because authors
generally have limited control over the operation of a list, this generally have limited control over the operation of a list, this
point makes MLM signing all the more important. point makes MLM signing all the more important.
Where the FBL wishes to be more specific, it could act solely on a Where the FBL wishes to be more specific, it could act solely on a
DKIM signature where the signing domain matches the DNS domain found DKIM signature where the signing domain matches the DNS domain found
in a List-Post: header field (or similar). in a 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.9. Handling Choices at Receivers 5.10. Handling Choices at Receivers
A recipient that trusts signatures from an MLM may wish to extend A recipient that trusts signatures from an MLM may wish to extend
that trust to an [AUTH-RESULTS] header field signed by that MLM. The that trust to an [AUTH-RESULTS] header field signed by that MLM. The
recipient may then do additional processing of the message, using the recipient may then do additional processing of the message, using the
results recorded in the Authentication-Results header field instead results recorded in the Authentication-Results header field instead
of the original author's DKIM signature. This includes possibly of the original author's DKIM signature. This includes possibly
processing the message as per ADSP requirements. processing the message as per ADSP requirements.
Receivers are advised to ignore all unsigned Authentication-Results Receivers are advised to ignore or remove all unsigned externally-
header fields. applied Authentication-Results header fields, or those not signed by
an ADMD that can be trusted by the receiver. See Section 5 and
Section 7 of [AUTH-RESULTS] for further discussion.
Upon DKIM and ADSP evaluation, a receiver may decide to reject a Upon DKIM and ADSP evaluation, a receiver may decide to reject a
message during an SMTP session. If this is done, use of an [SMTP] message during an SMTP session. If this is done, use of an [SMTP]
failure code not normally used for "user unknown" (550) is suggested; failure code not normally used for "user unknown" (550) is suggested;
554 seems an appropriate candidate. If the rejecting SMTP server 554 seems an appropriate candidate. If the rejecting SMTP server
supports [ENHANCED] status codes, is advised to make a distinction supports [ENHANCED] status codes, is advised to make a distinction
between messages rejected deliberately due to policy decisions rather between messages rejected deliberately due to policy decisions rather
than those rejected because of other deliverability issues. In than those rejected because of other deliverability issues. In
particular, a policy rejection is advised to be relayed using a 5.7.2 particular, a policy rejection is advised to be relayed using a 5.7.2
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 attempt to automatically remove users not exist. Those MLMs that automatically attempt to remove users
with prolonged delivery problems (such as account deletion) will thus with prolonged delivery problems (such as account deletion) will thus
be able to tell the difference between policy rejection and delivery be able to tell the difference between policy rejection and other
failures, and act accordingly. SMTP servers doing so are also delivery failures, and act accordingly. SMTP servers doing so are
advised to use appropriate wording in the text portion of the reply. also advised to use appropriate wording in the text portion of the
reply, perhaps explicitly using the string "ADSP" to facilitate
searching of relevant data in logs.
The preceding paragraph does not apply to an [ADSP] policy of
"discardable". In such cases where the submission fails that test,
the receiver is strongly advised to discard the message but return an
SMTP success code, i.e. accept the message but drop it without
delivery. An SMTP rejection of such mail instead of the requested
discard action causes more harm than good.
6. DKIM Reporting 6. DKIM Reporting
The MARF working group is developing mechanisms for reporting The MARF working group is developing mechanisms for reporting
forensic details about DKIM verification failures. At the time of forensic details about DKIM verification failures. At the time of
writing, this is still a work in progress. writing, this is still a work in progress.
MLMs are encouraged to apply these or other DKIM failure reporting MLMs are encouraged to apply these or other DKIM failure reporting
mechanisms as a method for providing feedback about issues with DKIM mechanisms as a method for providing feedback about issues with DKIM
infrastructure back to signers. This is especially important for infrastructure back to signers. This is especially important for
skipping to change at page 23, line 14 skipping to change at page 22, line 14
8. Security Considerations 8. 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 8.1. Authentication Results When Relaying
some stuff about the fact that the MLM's auth-results can't be Section 5 advocates addition of an [AUTH-RESULTS] header field to
trusted by default indicate authentication status of a message received as MLM Input.
Per Section 7.2 of [AUTH-RESULTS], receivers generally should not
trust such data without a good reason to do so, such as an a priori
agreement with the MLM's ADMD to do so.
Such agreements are strongly advised to include a requirement that
those header fields be covered by a [DKIM] signature added by the
MLM's ADMD.
9. References 9. References
9.1. Normative References 9.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.
[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)
skipping to change at page 24, line 36 skipping to change at page 23, line 36
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.
[EMAIL-ARCH] [EMAIL-ARCH]
Crocker, D., "Internet Mail Architecture", RFC 5598, Crocker, D., "Internet Mail Architecture", RFC 5598,
July 2009. July 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.
[I-D.DRAFT-IETF-MARF-BASE] [I-D.DRAFT-IETF-MARF-BASE]
Shafranovich, Y., Levine, J., and M. Kucherawy, "An Shafranovich, Y., Levine, J., and M. Kucherawy, "An
skipping to change at page 26, line 10 skipping to change at page 25, line 10
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, John Levine, S. Dave Crocker, JD Falk, Tony Hansen, Eliot Lear, John Levine, S.
Moonesamy and Alessandro Vesely. Moonesamy, Rolf E. Sonneveld, and 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
Problem: Problem:
o author ADMD advertise an ADSP policy of "dkim=discardable" o author ADMD advertises an ADSP policy of "dkim=discardable"
o author sends DKIM-signed mail to a non-participating MLM, which o author sends DKIM-signed mail to a non-participating MLM, which
invalidates the signature invalidates the signature
o receiver MTA checks DKIM and ADSP at SMTP time, and is configured o receiver MTA checks DKIM and ADSP at SMTP time, and is configured
to reject ADSP failures, so rejects this message to reject ADSP failures, so rejects this message
o process repeats a few times, after which the MLM unsubscribes the o process repeats a few times, after which the MLM unsubscribes the
receiver receiver
Solution: MLMs should refuse mail from domains advertising ADSP Solution: MLMs should refuse mail from domains advertising ADSP
policies of "discardable" unless they are certain they make no policies of "discardable" unless they are certain they make no
changes that invalidate DKIM signatures. changes that invalidate DKIM signatures.
B.2. MLMs and FBLs B.2. MLMs and FBLs
Problem: Problem:
o subscriber sends sign mail to a non-participating MLM that does o subscriber sends signed mail to a non-participating MLM that does
not invalidate the signature not invalidate the signature
o a recipient reports the message as spam o a recipient reports the message as spam
o FBL at recipient ADMD sends report to contributor rather than list o FBL at recipient ADMD sends report to contributor rather than list
manager manager
Solution: MLMs should sign mail they send and might also strip Solution: MLMs should sign mail they send and might also strip
existing signatures; FBLs should report to list operators instead of existing signatures; FBLs should report to list operators instead of
to subscribers where such can be distinguished. subscribers where such can be distinguished, otherwise to all parties
with valid signatures.
Author's Address Author's Address
Murray S. Kucherawy Murray S. Kucherawy
Cloudmark Cloudmark
128 King St., 2nd Floor 128 King St., 2nd Floor
San Francisco, CA 94107 San Francisco, CA 94107
US US
Phone: +1 415 946 3800 Phone: +1 415 946 3800
 End of changes. 53 change blocks. 
233 lines changed or deleted 297 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/