< draft-ietf-dkim-mailinglists-04.txt   draft-ietf-dkim-mailinglists-05.txt >
DKIM Working Group M. Kucherawy DKIM Working Group M. Kucherawy
Internet-Draft Cloudmark Internet-Draft Cloudmark
Intended status: Informational October 15, 2010 Intended status: Informational March 28, 2011
Expires: April 18, 2011 Expires: September 29, 2011
DKIM And Mailing Lists DKIM And Mailing Lists
draft-ietf-dkim-mailinglists-04 draft-ietf-dkim-mailinglists-05
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 April 18, 2011. This Internet-Draft will expire on September 29, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 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. 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 . . . . . . . . . . . . . . . . . 6
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Other Terms . . . . . . . . . . . . . . . . . . . . . . . 7 2.1. Other Terms . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. DKIM-Specific References . . . . . . . . . . . . . . . . . 7 2.2. DKIM-Specific References . . . . . . . . . . . . . . . . . 7
2.3. 'DKIM-Friendly' . . . . . . . . . . . . . . . . . . . . . 7 2.3. 'DKIM-Friendly' . . . . . . . . . . . . . . . . . . . . . 7
2.4. Message Streams . . . . . . . . . . . . . . . . . . . . . 7 2.4. Message Streams . . . . . . . . . . . . . . . . . . . . . 7
3. Mailing Lists and DKIM . . . . . . . . . . . . . . . . . . . . 8 3. Mailing Lists and DKIM . . . . . . . . . . . . . . . . . . . . 8
3.1. Roles and Realities . . . . . . . . . . . . . . . . . . . 8 3.1. Roles and Realities . . . . . . . . . . . . . . . . . . . 8
3.2. Types Of Mailing Lists . . . . . . . . . . . . . . . . . . 9 3.2. Types Of Mailing Lists . . . . . . . . . . . . . . . . . . 9
3.3. Current MLM Effects On Signatures . . . . . . . . . . . . 10 3.3. Current MLM Effects On Signatures . . . . . . . . . . . . 10
4. Non-Participating MLMs . . . . . . . . . . . . . . . . . . . . 12 4. Non-Participating MLMs . . . . . . . . . . . . . . . . . . . . 12
skipping to change at page 2, line 35 skipping to change at page 2, line 35
4.4. Wrapping A Non-Participating MLM . . . . . . . . . . . . . 13 4.4. Wrapping A Non-Participating MLM . . . . . . . . . . . . . 13
5. Participating MLMs . . . . . . . . . . . . . . . . . . . . . . 14 5. Participating MLMs . . . . . . . . . . . . . . . . . . . . . . 14
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.2. DKIM Author Domain Signing Practices . . . . . . . . . . . 14 5.2. DKIM Author Domain Signing Practices . . . . . . . . . . . 14
5.3. Subscriptions . . . . . . . . . . . . . . . . . . . . . . 15 5.3. Subscriptions . . . . . . . . . . . . . . . . . . . . . . 15
5.4. Author-Related Signing . . . . . . . . . . . . . . . . . . 15 5.4. Author-Related Signing . . . . . . . . . . . . . . . . . . 15
5.5. Verification Outcomes at MLMs . . . . . . . . . . . . . . 16 5.5. Verification Outcomes at MLMs . . . . . . . . . . . . . . 16
5.6. Signature Removal Issues . . . . . . . . . . . . . . . . . 16 5.6. Signature Removal Issues . . . . . . . . . . . . . . . . . 16
5.7. MLM Signatures . . . . . . . . . . . . . . . . . . . . . . 18 5.7. MLM Signatures . . . . . . . . . . . . . . . . . . . . . . 18
5.8. Verification Outcomes at Final Receiving Sites . . . . . . 19 5.8. Verification Outcomes at Final Receiving Sites . . . . . . 19
5.9. Use With FBLs . . . . . . . . . . . . . . . . . . . . . . 19 5.9. Use With FBLs . . . . . . . . . . . . . . . . . . . . . . 20
5.10. Handling Choices at Receivers . . . . . . . . . . . . . . 20 5.10. Handling Choices at Receivers . . . . . . . . . . . . . . 20
6. DKIM Reporting . . . . . . . . . . . . . . . . . . . . . . . . 22 6. DKIM Reporting . . . . . . . . . . . . . . . . . . . . . . . . 22
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24
8.1. Authentication Results When Relaying . . . . . . . . . . . 24 8.1. Authentication Results When Relaying . . . . . . . . . . . 24
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
9.1. Normative References . . . . . . . . . . . . . . . . . . . 25 9.1. Normative References . . . . . . . . . . . . . . . . . . . 25
9.2. Informative References . . . . . . . . . . . . . . . . . . 25 9.2. Informative References . . . . . . . . . . . . . . . . . . 25
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 27 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 27
Appendix B. Example Scenarios . . . . . . . . . . . . . . . . . . 28 Appendix B. Example Scenarios . . . . . . . . . . . . . . . . . . 28
skipping to change at page 4, line 29 skipping to change at page 4, line 29
DKIM does not define any meaning to the occurrence of a match between 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 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 name in the RFC5322.From field, nor is there any obvious degraded
value to a signature where they do not match. Since any DKIM value to a signature where they do not match. Since any DKIM
signature is merely an assertion of "some" responsibility by an ADMD, 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 DKIM signature added by an MLM has no more, nor less, meaning than
a signature with any other "d=" value. a signature with any other "d=" value.
1.2. MLMs In Infrastructure 1.2. MLMs In Infrastructure
The previous section describes some of the things MLMs commonly do Section 3.3 describes some of the things MLMs commonly do that
that produce broken signatures and thus reducing the perceived value produce broken signatures, thus reducing the perceived value of DKIM.
of DKIM.
Further, while the advent of standards that are specific to MLM Further, while there are published standards that are specific to MLM
behaviour (e.g. [MAIL], [LIST-ID] and [LIST-URLS]), their adoption behaviour (e.g. [MAIL], [LIST-ID] and [LIST-URLS]), their adoption
has been spotty at best. Hence, efforts to specify the use of DKIM 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. in the context of MLMs needs to be incremental and value-based.
MLM behaviors are well-established. Although it can be argued that Other MLM behaviours are well-established. Although it can be argued
they frustrate widespread DKIM adoption, it cannot be said that such that they frustrate widespread DKIM adoption, it cannot be said that
behaviours are not standards compliant. Thus, the best approach is such behaviours are not standards compliant. Thus, the best approach
to provide these best practices to all parties involved, imposing the is to provide these best practices to all parties involved, imposing
minimum requirements possible to MLMs themselves. 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 is typically the same as that of the original message and a message (in the non-digest case) is typically the same as that of
that recipients perceive the message as "from" the original author the original message, and that recipients perceive the message as
rather than the MLM creates confusion about responsibility and "from" the original author rather than the MLM, creates confusion
autonomy for the re-posted message. This has important implications about responsibility and autonomy for the re-posted message. This
for use of DKIM. has important implications for use of DKIM.
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, and one
this document intends to address, is some idea of how such a this document intends to address, is some idea of how such a
signature might be used by a recipient's evaluation module after the signature might be used by a recipient's evaluation module after the
message has gone through a mailing list and may or may not have been message has gone through a mailing list and may or may not have been
invalidated, and if it has, where the invalidation may have happened. invalidated, and if it has, where and how the invalidation may have
happened.
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 1.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. Messages signed and sent by a registrant DKIM use by the registrant.
through an MLM can therefore result in having abuse reports sent to
the original author when the actual problem pertains to the operation A DKIM-signed message sent to an MLM, and then distributed to all of
of the MLM. However, the original author has no involvement in a list's recipients, could result in a complaint from one of the
operation of the MLM, meaning the FBL report is not actionable and recipients for some reason. This could be an actual complaint from
thus is undesirable. 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. 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]) format.
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. In general, handling of possible interactions between DKIM and MLMs. In general,
consensus shows a preference toward imposing changes to behaviour at consensus shows a preference toward imposing changes to behaviour at
skipping to change at page 7, line 15 skipping to change at page 7, line 15
2. Definitions 2. Definitions
2.1. Other Terms 2.1. Other 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 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 core specification documents as well as [DKIM-OVERVIEW] and which are core specification documents, as well as [DKIM-OVERVIEW]
[DKIM-DEPLOYMENT] which are DKIM's primary tutorial documents. and [DKIM-DEPLOYMENT], which are DKIM's primary tutorial documents.
2.3. 'DKIM-Friendly' 2.3. '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
skipping to change at page 8, line 32 skipping to change at page 8, line 32
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 relays it toward its destination(s). This is often referred
to as the Mail Submission Agent (MSA). 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 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 general
Internet and the receiver's ADMD. Note that any agent that Internet and the receiver's ADMD. Note that any agent that
handles a signed message could conduct verification; this document handles a signed message could conduct verification; this document
only considers that action and its outcomes either at an MLM or at only considers that action and its outcomes either at an MLM or at
the receiver. Filtering decisions could be made by this agent the receiver. Filtering decisions could be made by this agent
based on verificaiton results. 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. prior to being delivered to the recipient(s) of the message.
Filtering decisions based on results made by the verifier could be Filtering decisions based on results made by the verifier could be
applied by the receiver. The verifier and the receiver could be applied by the receiver. The verifier and the receiver could be
the same agent. 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
skipping to change at page 9, line 38 skipping to change at page 9, line 38
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 a special case of
the MLM paradigm, one that generates its own content and does not the MLM paradigm, one that generates its own content and does not
act as an intermediary. Typically replies are not generated, or act as an intermediary. Typically replies are not generated, or
if they are, they go to a specific recipient and not back to the if they are, they go to a specific recipient and not back to the
list's full set of recipients. Examples include newsletters and list's full set of recipients. Examples include newsletters and
bulk marketing mail. 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 submissons, single message comprising an aggregation of recent MLM
which might be a message of [MIME] type "multipart/digest" (see submissions, which might be a message of [MIME] type "multipart/
[MIME-TYPES]). This is obviously a new message but it may contain digest" (see [MIME-TYPES]). This is obviously a new message but
a sequence of original messages that may themselves have been it may contain a sequence of original messages that may themselves
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:
MLM Input: Originating user is author; originating ADMD is MLM Input: Originating user is author; originating ADMD is
originator and signer; MLM's ADMD is verifier; MLM's input originator and signer; MLM's ADMD is verifier; MLM's input
function is receiver. 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 originator and signer; user's message) is author; MLM's ADMD is originator and signer;
skipping to change at page 11, line 17 skipping to change at page 11, line 17
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. signed, and those 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 unverifiable. will render any existing signatures that cover those portions of
the message body 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 adding, deleting, reordering, or reformatting [MIME] such as adding, deleting, reordering, or reformatting [MIME]
parts, "flatten" HTML messages into plain text, or insert headers parts, "flattening" HTML messages into plain text, or insert
or footers within HTML messages. Most or all of these changes headers or footers within HTML messages. Most or all of these
will invalidate a DKIM signature. 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 cases where a
body length limit is applied in generation of the DKIM signature, body length limit is applied in generation of the DKIM signature,
the signature will be broken. the signature will be broken.
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,
skipping to change at page 12, line 29 skipping to change at page 12, line 29
Hence, list recipients would receive a message purportedly from the Hence, list recipients would receive a message purportedly from the
author but bearing a DKIM signature that would not verify. There author but bearing a DKIM signature that would not verify. There
exist DKIM modules that incorrectly penalize messages with signatures exist DKIM modules that incorrectly penalize messages with signatures
that do not validate, so this may have detrimental effects outside of that do not validate, so this may have detrimental effects outside of
the author's control. (Additional discussion of this is below.) the author's control. (Additional discussion of this is below.)
This problem could be compounded if there were receivers that applied This problem could be compounded if there were receivers that applied
signing policies (e.g., [ADSP]) and the author published any kind of signing policies (e.g., [ADSP]) and the author published any kind of
strict policy. strict policy.
For domains that do publish strict ADSP policies, the originating For domains that do publish strict ADSP policies, the originating
site can consider using a separate message stream, such as a sub- site can consider using a separate message stream (see Section 2.4),
domain, for the "personal" mail -- a subdomain that is different from such as a sub-domain, for the "personal" mail -- a subdomain that is
domain(s) used for other mail streams. This allows each to develop different from domain(s) used for other mail streams. This allows
an independent reputation, and more stringent policies (including each to develop an independent reputation, and more stringent
ADSP) can be applied to the mail stream(s) that do not go through policies (including ADSP) can be applied to the mail stream(s) that
mailing lists or perhaps do not get signed at all. 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
skipping to change at page 14, line 17 skipping to change at page 14, line 17
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. General 5.1. General
As DKIM becomes more widely deployed, it is highly desirable that MLM As DKIM becomes more widely deployed, it is highly desirable that MLM
software adopt more DKIM-friendly processing. 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 in that their addition by
an MLM will not affect any existing DKIM signatures unless those an MLM 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 was created specifically to disallow their addition (see
the note about "h=" in Section 3.5 of [DKIM]). 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
skipping to change at page 15, line 14 skipping to change at page 15, line 14
lists operated by aliasing MLMs only; any MLM that alters a message lists operated by aliasing MLMs only; any MLM that alters a message
from such a domain or removes its signature subjects the message to from such a domain or removes its signature subjects the message to
severe action by verifiers or receivers. It is the consensus of the severe action by verifiers or receivers. It is the consensus of the
working group that a resending MLM is advised to reject outright any 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 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 to be rejected by any ADSP-aware recipients, and might also be well
advised to discourage such subscribers when they first sign up to the advised to discourage such subscribers when they first sign up to the
list. Further discussion of this appears in Section 5.3. list. Further discussion of this appears in Section 5.3.
Where the above practice is not observed and "discardable" mail Where the above practice is not observed and "discardable" mail
arrives via a list to a verifier that applies ADSP checks, the arrives via a list to a verifier that applies ADSP checks which fail,
message can either be discarded (i.e. accept the message at the the message can either be discarded (i.e. accept the message at the
[SMTP] level but discard it without delivery) or the message can be [SMTP] level but discard it without delivery) or the message can be
rejected by returning a 5xx error code. In the latter case, some rejected by returning a 5xx error code. In the latter case, some
advice for how to conduct the rejection in a potentially meaningful advice for how to conduct the rejection in a potentially meaningful
way can be found in Section 5.10. way can be found in Section 5.10.
See also Appendix B.5 of [ADSP] for further discussion. See also Appendix B.5 of [ADSP] for further discussion.
5.3. Subscriptions 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's domain. If the policy specifies ADSP record for the new subscriber's domain. If the policy specifies
"discardable", the MLM might disallow the subscription or present a "discardable", the MLM might 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 subscriber's ADMD's not be deliverable to some recipients because of the subscriber'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 applied after subscription,
so this is not a universal solution. An MLM implementation could do so this is not a universal solution. An MLM implementation could do
periodic checks of its subscribers and issue warnings where such a periodic checks of its subscribers and issue warnings where such a
policy is detected, or simply check upon each submission. policy is detected, or simply check upon each submission.
5.4. Author-Related Signing 5.4. 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. As such, a signed message
skipping to change at page 16, line 23 skipping to change at page 16, line 23
enables a stronger form of authentication, although this is not yet enables a stronger form of authentication, although this is not yet
formally documented: It can require that messages using a given formally documented: It can require that messages using a given
RFC5322.From address also have a DKIM signature with a corresponding RFC5322.From address also have a DKIM signature with a corresponding
"d=" domain. This feature would be somewhat similar to using ADSP, "d=" domain. This feature would be somewhat similar to using ADSP,
except that the requirement for it would be imposed by the MLM and except that the requirement for it would be imposed by the MLM and
not the author's organization. not the author's organization.
As described, the MLM might conduct DKIM verification of a signed 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, not all signed mail will
include an author signature (see [ADSP]). MLM implementors are include an author signature (see [ADSP]). MLM implementers are
advised to accomodate such in their configurations. For example, an advised to accommodate such in their configurations. For example, an
MLM might be designed to accomodate a list of possible signing MLM might be designed to accommodate a list of possible signing
domains (the "d=" portion of a DKIM signature) for a given author, domains (the "d=" portion of a DKIM signature) for a given author,
and determine at verification time if any of those are present. 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,
skipping to change at page 17, line 23 skipping to change at page 17, line 23
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:
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. Remove all existing [AUTH-RESULTS] fields (optional);
4. 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; 5. Remove all previously-evaluated DKIM signatures;
5. Affix a new signature that covers the Authentication-Results 6. Affix a new signature that covers the entire message on the
header field just added (see Section 5.7). output side, including the Authentication-Results 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 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
skipping to change at page 18, line 7 skipping to change at page 18, line 10
Per the discussion in [AUTH-RESULTS], there is no a priori reason for Per the discussion in [AUTH-RESULTS], there is no a priori reason for
the final receivers to put any faith in the veracity of that header the final receivers to put any faith in the veracity of that header
field when added by the MLM. Thus, the final recipients of the field when added by the MLM. Thus, the final recipients of the
message have no way to verify on their own the authenticity of the message have no way to verify on their own the authenticity of the
author's identity on that message. However, should that field be the author's identity on that message. However, should that field be the
only one on the message when the verifier gets it, and the verifier only one on the message when the verifier gets it, and the verifier
explicitly trusts the signer (in this case, the MLM), the verifier is explicitly trusts the signer (in this case, the MLM), the verifier is
in a position to believe that a valid author signature was present on in a position to believe that a valid author signature was present on
the message. the message.
This can be generalized as follows: A receiver is advised to consider
only [AUTH-RESULTS] fields bearing an authserv-id that appears in a
list of sites the receiver trusts that is also included in the header
hash of a [DKIM] signature added by a domain in the same trusted
list.
Since an aliasing MLM makes no substantive changes to a message, it 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.
skipping to change at page 18, line 38 skipping to change at page 18, line 47
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 discouraged; sign such mail. However, selective signing is discouraged;
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.
As is typical with DKIM signing, the MLM signature must be generated
immediately prior to sending, only after all other processing the MLM
wishes to apply has been completed. Failing to do so generates a
signature that can not be expected to validate.
A signing MLM could add a List-Post: header field (see [LIST-URLS]) A signing MLM could add a List-Post: header field (see [LIST-URLS])
using a DNS domain matching what will be used in the "d=" tag of the using a DNS domain matching what will be used in the "d=" tag of the
DKIM signature it will add to the new message. This could be used by DKIM signature it will add to the new message. This could be used by
verifiers or receivers to identify the DKIM signature that was added verifiers or receivers to identify the DKIM signature that was added
by the MLM. This is not required, however; it is believed the by the MLM. This is not required, however; it is believed the
reputation of the signer will be a more critical data point rather reputation of the signer will be a more critical data point rather
than this suggested binding. Furthermore, this is not a binding than this suggested binding. Furthermore, this is not a binding
recognized by any current specification document. recognized by any current specification document.
Such MLMs are advised to ensure the signature's header hash will Such MLMs are advised to ensure the signature's header hash will
skipping to change at page 19, line 17 skipping to change at page 19, line 20
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
after being prepared for distribution (i.e. the "MLM Output" from after being prepared for distribution (i.e. the "MLM Output" from
Section 3.2), including any original signatures. Section 3.2). Any other configuration might generate signatures that
cannot be expected to validate. The signature would deally include
any original signatures and any header fields that were covered by
those signatures, but not any that were not already signed.
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].
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. In the case of MLMs,
 End of changes. 29 change blocks. 
67 lines changed or deleted 85 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/