< draft-ietf-dkim-mailinglists-11.txt   draft-ietf-dkim-mailinglists-12.txt >
DKIM Working Group M. Kucherawy DKIM Working Group M. Kucherawy
Internet-Draft Cloudmark Internet-Draft Cloudmark
Intended status: BCP June 3, 2011 Intended status: BCP June 23, 2011
Expires: December 5, 2011 Expires: December 25, 2011
DKIM And Mailing Lists DKIM And Mailing Lists
draft-ietf-dkim-mailinglists-11 draft-ietf-dkim-mailinglists-12
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. Based on domain (ADMD) to assume some responsibility for a message. Based on
deployment experience with DKIM, this document provides guidance for deployment experience with DKIM, this document provides guidance for
the use of DKIM with scenarios that include Mailing List Managers the use of DKIM with scenarios that include Mailing List Managers
(MLMs). (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 December 5, 2011. This Internet-Draft will expire on December 25, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 33 skipping to change at page 2, line 33
4.1. Author-Related Signing . . . . . . . . . . . . . . . . . . 14 4.1. Author-Related Signing . . . . . . . . . . . . . . . . . . 14
4.2. Verification Outcomes at Receivers . . . . . . . . . . . . 15 4.2. Verification Outcomes at Receivers . . . . . . . . . . . . 15
4.3. Handling Choices at Receivers . . . . . . . . . . . . . . 15 4.3. Handling Choices at Receivers . . . . . . . . . . . . . . 15
4.4. Wrapping A Non-Participating MLM . . . . . . . . . . . . . 15 4.4. Wrapping A Non-Participating MLM . . . . . . . . . . . . . 15
5. Participating MLMs . . . . . . . . . . . . . . . . . . . . . . 16 5. Participating MLMs . . . . . . . . . . . . . . . . . . . . . . 16
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.2. DKIM Author Domain Signing Practices . . . . . . . . . . . 16 5.2. DKIM Author Domain Signing Practices . . . . . . . . . . . 16
5.3. Subscriptions . . . . . . . . . . . . . . . . . . . . . . 17 5.3. Subscriptions . . . . . . . . . . . . . . . . . . . . . . 17
5.4. Exceptions To ADSP Recommendations . . . . . . . . . . . . 18 5.4. Exceptions To ADSP Recommendations . . . . . . . . . . . . 18
5.5. Author-Related Signing . . . . . . . . . . . . . . . . . . 18 5.5. Author-Related Signing . . . . . . . . . . . . . . . . . . 18
5.6. Verification Outcomes at MLMs . . . . . . . . . . . . . . 18 5.6. Verification Outcomes at MLMs . . . . . . . . . . . . . . 19
5.7. Signature Removal Issues . . . . . . . . . . . . . . . . . 19 5.7. Signature Removal Issues . . . . . . . . . . . . . . . . . 20
5.8. MLM Signatures . . . . . . . . . . . . . . . . . . . . . . 21 5.8. MLM Signatures . . . . . . . . . . . . . . . . . . . . . . 21
5.9. Verification Outcomes at Final Receiving Sites . . . . . . 22 5.9. Verification Outcomes at Final Receiving Sites . . . . . . 22
5.10. Use With FBLs . . . . . . . . . . . . . . . . . . . . . . 22 5.10. Use With FBLs . . . . . . . . . . . . . . . . . . . . . . 22
5.11. Handling Choices at Receivers . . . . . . . . . . . . . . 23 5.11. Handling Choices at Receivers . . . . . . . . . . . . . . 23
6. DKIM Reporting . . . . . . . . . . . . . . . . . . . . . . . . 25 6. DKIM Reporting . . . . . . . . . . . . . . . . . . . . . . . . 25
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
8. Security Considerations . . . . . . . . . . . . . . . . . . . 27 8. Security Considerations . . . . . . . . . . . . . . . . . . . 27
8.1. Security Considerations from DKIM and ADSP . . . . . . . . 27 8.1. Security Considerations from DKIM and ADSP . . . . . . . . 27
8.2. Authentication Results When Relaying . . . . . . . . . . . 27 8.2. Authentication Results When Relaying . . . . . . . . . . . 27
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
skipping to change at page 3, line 50 skipping to change at page 3, line 50
In general there are, in relation to DKIM, two categories of MLMs: In general there are, in relation to DKIM, two categories of MLMs:
participating and non-participating. As each type has its own issues participating and non-participating. As each type has its own issues
regarding DKIM-signed messages that are either handled or produced by regarding DKIM-signed messages that are either handled or produced by
them (or both), the types are discussed in separate sections. them (or both), the types are discussed in separate sections.
The best general recommendation for dealing with MLMs is that the MLM The best general recommendation for dealing with MLMs is that the MLM
or an MTA in the MLM's domain apply its own DKIM signature to each or an MTA in the MLM's domain apply its own DKIM signature to each
message it forwards, and for assessors on the receiving end to message it forwards, and for assessors on the receiving end to
consider the MLM's domain signature in making their assessments. consider the MLM's domain signature in making their assessments.
(See Section 5 and especially Section 5.2.)
With the understanding that that is not always possible or practical, With the understanding that that is not always possible or practical,
and the consideration that it might not always be sufficient, this and the consideration that it might not always be sufficient, this
document provides additional guidance. document provides additional guidance.
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 validated domain-level identifier to the message as it affixing a validated domain-level identifier to the message as it
passes through a relay. Although not the only possibility, this is passes through a relay. Although not the only possibility, this is
skipping to change at page 5, line 9 skipping to change at page 5, line 12
Section 3.3 describes some of the things MLMs commonly do that Section 3.3 describes some of the things MLMs commonly do that
produce broken signatures, thus reducing the perceived value of DKIM. produce broken signatures, thus reducing the perceived value of DKIM.
Further, while there are published 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.
Some MLM behaviours are well-established and their effects on DKIM Some MLM behaviours are well-established and their effects on DKIM
signature validity can be argued as frustrating wider DKIM adoption. signature validity can be argued as frustrating wider DKIM adoption.
Still, those behaviors are not standards violations. Hence, the best Still, those behaviors are not standards violations. Hence, this
approach for a BCP effort is to specify practices for all parties memo specifies practices for all parties involved, defining the
involved, defining the minimum changes possible to MLMs themselves. minimum changes possible to MLMs themselves.
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 that is for the message taken by the signing domain. An open issue that is
addressed by this document is the ways a signature might be used by a addressed by this document is the ways a signature might be used by a
recipient's evaluation module, after the message has gone through a recipient's evaluation module, after the message has gone through a
mailing list and might or might not have been rendered invalid. The mailing list and might or might not have been rendered invalid. The
document also considers how invalidation might have happened. document also considers how invalidation might 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 Author Domain Signing
implementation could be one where the validation is done by the MTA Practices ([ADSP]) policies, the actual implementation could be one
or an agent attached to it, and the results of that work are relayed where the validation is done by the MTA or an agent attached to it,
by a trusted channel not specified here. See [AUTH-RESULTS] for a and the results of that work are relayed by a trusted channel not
discussion of this. This document does not favour any particular specified here. See [AUTH-RESULTS] for a discussion of this. This
arrangement of these agents over another, but merely talks about the document does not favour any particular arrangement of these agents
MLM itself doing the work as a matter of simplicity. over another, but merely talks about the 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
skipping to change at page 7, line 41 skipping to change at page 7, line 41
to verify on output. to verify on output.
Various features of MTAs and MLMs seen as helpful to users often have Various features of MTAs and MLMs seen as helpful to users often have
side effects that do render DKIM signatures unverifiable. These side effects that do render DKIM signatures unverifiable. These
would not qualify for this label. would not qualify for this label.
2.5. Message Streams 2.5. Message Streams
A "message stream" identifies a group of messages originating from A "message stream" identifies a group of messages originating from
within an ADMD that are distinct in intent, origin and/or use, and within an ADMD that are distinct in intent, origin and/or use, and
partitions them somehow (i.e., via changing the value in the "d=" tag partitions them somehow (e.g., via changing the value in the "d=" tag
value in the context of DKIM) so as to keep them associated to users value in the context of DKIM) so as to keep them associated to users
yet distinct in terms of their evaluation and handling by verifiers yet distinct in terms of their evaluation and handling by verifiers
or receivers. or receivers.
A good example might be user mail generated by a company's employees, A good example might be user mail generated by a company's employees,
versus operational or transactional mail that comes from automated versus operational or transactional mail that comes from automated
sources, versus marketing or sales campaigns. Each of these could sources, versus marketing or sales campaigns. Each of these could
have different sending policies imposed against them, or there might have different sending policies imposed against them, or there might
be a desire to insulate one from the other (e.g., a marketing be a desire to insulate one from the other (e.g., a marketing
campaign that gets reported by many spam filters could cause the campaign that gets reported by many spam filters could cause the
skipping to change at page 11, line 34 skipping to change at page 11, line 34
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 creating new content and signature, and an authoring MLM is always creating new content and
thus there is never an existing signature. However, the changes a thus there is never an existing signature. However, the changes a
resending MLM typically make affect the RFC5322.Subject header field, resending MLM typically makes affect the RFC5322.Subject header
addition of some list-specific header fields, and/or modification of field, addition of some list-specific header fields, and/or
the message body. The effects of each of these on DKIM verification modification of the message body. The effects of each of these on
are discussed below. DKIM verification are discussed below.
Subject tags: A popular feature of MLMs is the "tagging" of an Subject tags: A popular feature of MLMs is the "tagging" of an
RFC5322.Subject field by prefixing the field's contents with the RFC5322.Subject field by prefixing the field's contents with the
name of the list, such as "[example]" for a list called "example". name of the list, such as "[example]" for a list called "example".
Altering the RFC5322.Subject field on new submissions by adding a Altering the RFC5322.Subject field on new submissions by adding a
list-specific prefix or suffix will invalidate the signer's list-specific prefix or suffix will invalidate the signer's
signature if that header field was included in the hash when signature if that header field was included in the hash when
creating that signature. Section 5.5 of [DKIM] lists creating that signature. Section 5.5 of [DKIM] lists
RFC5322.Subject as one that should be covered as it contains RFC5322.Subject as one that should be covered as it contains
important user-visible text, so this is expected to be an issue important user-visible text, so this is expected to be an issue
for any list that makes such changes. 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 (see notes about the "h=" tag addition of header fields in general (see notes about the "h=" tag
in Section 3.5 of [DKIM]). Therefore not seen as a concern. in Section 3.5 of [DKIM]). Therefore this is not seen as a
concern.
Other header fields: Some lists will add or replace header fields Other header fields: Some lists will add or replace header fields
such as "Reply-To" or "Sender" in order to establish that the such as "Reply-To" or "Sender" in order to establish that the
message is being sent in the context of the mailing list, so that message is being sent in the context of the mailing list, so that
the list is identified ("Sender") and any user replies go to the the list is identified ("Sender") and any user replies go to the
list ("Reply-To"). If these fields were included in the original list ("Reply-To"). If these fields were included in the original
message, it is possible that one or more of them may have been message, it is possible that one or more of them may have been
included in the signature hash, and those signatures will thus be included in the signature hash, and those signatures will thus be
broken. broken.
skipping to change at page 18, line 16 skipping to change at page 18, line 16
5.4. Exceptions To ADSP Recommendations 5.4. Exceptions To ADSP Recommendations
Where an ADMD has established some out-of-band trust agreement with Where an ADMD has established some out-of-band trust agreement with
another ADMD such that an Authentication-Results field applied by one another ADMD such that an Authentication-Results field applied by one
is trusted by the other, the above recommendations for MLM operation is trusted by the other, the above recommendations for MLM operation
with respect to ADSP do not apply because it is then possible to with respect to ADSP do not apply because it is then possible to
establish whether or not a valid author signature can be inferred establish whether or not a valid author signature can be inferred
even if one is not present on receipt. even if one is not present on receipt.
For example, suppose domains example.com and example.net have an
explicit agreement to trust one another's authentication assertions.
Now, consider a message with an RFC5322.From domain of "example.org"
that is also bearing a valid DKIM signature by the same domain which
arrives at a mailing list run by example.com. Upon evaluation,
example.com validates the signature, and adds an [AUTH-RESULTS] field
indicating this. However, the MLM also makes changes to the message
body that invalidate the signature. The MLM then re-signs the
modified message using DKIM and sends it on to the list's
subscribers, one of whom is at example.net.
On arrival at example.net, the DKIM signature for example.org is no
longer valid, so ADSP would generally fail. However, example.net
trusts the assertion of example.com's Authentication-Results field
that indicated that there was a valid signature from example.org, so
the ADSP failure can be ignored.
5.5. Author-Related Signing 5.5. Author-Related Signing
An important consideration is that authors rarely have any direct An important consideration is that authors rarely have any direct
influence over the management of an MLM. Specifically, the behavior influence over the management of an MLM. Specifically, the behavior
of an intermediary (e.g., an MLM that is not careful about filtering of an intermediary (e.g., an MLM that is not careful about filtering
out junk mail or being diligent about unsubscription requests) can out junk mail or being diligent about unsubscription requests) can
trigger recipient complaints that reflect back on those agents that trigger recipient complaints that reflect back on those agents that
appear to be responsible for the message, in this case an author via appear to be responsible for the message, in this case an author via
the address found in the RFC5322.From field. In the future, as DKIM the address found in the RFC5322.From field. In the future, as DKIM
signature outputs (i.e., the signing domain) are used as inputs to signature outputs (i.e., the signing domain) are used as inputs to
skipping to change at page 19, line 4 skipping to change at page 19, line 21
verifying the RFC5322.From field email address (or, less frequently, verifying the RFC5322.From field email address (or, less frequently,
the RFC5321.MailFrom parameter) against a list subscription registry. the RFC5321.MailFrom parameter) against a list subscription registry.
DKIM enables a stronger form of authentication: The MLM can require DKIM enables a stronger form of authentication: The MLM can require
that messages using a given RFC5322.From address also have a DKIM that messages using a given RFC5322.From address also have a DKIM
signature with a corresponding "d=" domain. This feature would be signature with a corresponding "d=" domain. This feature would be
somewhat similar to using ADSP, except that the requirement for it somewhat similar to using ADSP, except that the requirement for it
would be imposed by the MLM and not the author's organization. would be imposed by the MLM and not the author's organization.
(Note, however, that this goes beyond DKIM's documented semantics. (Note, however, that this goes beyond DKIM's documented semantics.
It is presented as a possible workable enhancement.) It is presented as a possible workable enhancement.)
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, few signed messages will it is a common and intuitive conclusion, few signed messages will
include an author signature (see [ADSP]). MLM implementers adding include an author signature (see [ADSP]). MLM implementers adding
such support would have accommodate this. For example, an MLM might such support would have to accommodate this. For example, an MLM
be designed to accommodate a list of possible signing domains (the might be designed to accommodate a list of possible signing domains
"d=" portion of a DKIM signature) for a given author, and determine (the "d=" portion of a DKIM signature) for a given author, and
at verification time if any of those are present. This enables a determine at verification time if any of those are present. This
more reliable method of authentication at the expense of having to enables a more reliable method of authentication at the expense of
store a mapping of authorized signing domains for subscribers and having to store a mapping of authorized signing domains for
trusting that it will be kept current. subscribers and trusting that it will be kept current.
A message that cannot be thus authenticated MAY be held for A message that cannot be thus authenticated MAY be held for
moderation or rejected outright. moderation or rejected outright.
This logic could apply to any list operation, not just list This logic could apply to any list operation, not just list
submission. In particular, this improved authentication MAY apply to submission. In particular, this improved authentication MAY apply to
subscription, unsubscription, and/or changes to subscriber options subscription, unsubscription, and/or changes to subscriber options
that are sent via email rather than through an authenticated, that are sent via email rather than through an authenticated,
interactive channel such as the web. interactive channel such as the web.
 End of changes. 13 change blocks. 
29 lines changed or deleted 51 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/