< draft-ietf-dkim-mailinglists-03.txt   draft-ietf-dkim-mailinglists-04.txt >
DKIM Working Group M. Kucherawy DKIM Working Group M. Kucherawy
Internet-Draft Cloudmark Internet-Draft Cloudmark
Intended status: Informational October 4, 2010 Intended status: Informational October 15, 2010
Expires: April 7, 2011 Expires: April 18, 2011
DKIM And Mailing Lists DKIM And Mailing Lists
draft-ietf-dkim-mailinglists-03 draft-ietf-dkim-mailinglists-04
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 7, 2011. This Internet-Draft will expire on April 18, 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 32 skipping to change at page 2, line 32
4.1. Author-Related Signing . . . . . . . . . . . . . . . . . . 12 4.1. Author-Related Signing . . . . . . . . . . . . . . . . . . 12
4.2. Verification Outcomes at Receivers . . . . . . . . . . . . 13 4.2. Verification Outcomes at Receivers . . . . . . . . . . . . 13
4.3. Handling Choices at Receivers . . . . . . . . . . . . . . 13 4.3. Handling Choices at Receivers . . . . . . . . . . . . . . 13
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. Pros and Cons of Signature Removal . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . 19
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
skipping to change at page 3, line 28 skipping to change at page 3, line 28
them, and re-post them, often invalidating DKIM signatures. The goal them, and re-post them, often invalidating DKIM signatures. The goal
for this document is to explore the use of DKIM for scenarios that for this document is to explore the use of DKIM for scenarios that
include intermediaries. Questions that will be discussed include: include intermediaries. Questions that will be discussed include:
o Under what circumstances is it advisable for an author, or its o Under what circumstances is it advisable for an author, or its
organization, to apply DKIM to mail sent to mailing lists? organization, to apply DKIM to mail sent to mailing lists?
o What are the tradeoffs regarding having an MLM verify and use DKIM o What are the tradeoffs regarding having an MLM verify and use DKIM
identifiers? identifiers?
o What are the tradeoffs regarding having an MLM remove exisiting o What are the tradeoffs regarding having an MLM remove existing
DKIM signatures prior to re-posting the message? DKIM signatures prior to re-posting the message?
o What are the tradeoffs regarding having an MLM add its own DKIM o What are the tradeoffs regarding having an MLM add its own DKIM
signature? signature?
These and others are open questions for which there may be no These and others are open questions for which there may be no
definitive answers. However, based on experience since the definitive answers. However, based on experience since the
publication of [DKIM] and its gradual deployment, there are some publication of [DKIM] and its gradual deployment, there are some
views that are useful to consider. views that are useful to consider.
This document explores changes to common practice by the signers, the
verifiers and the MLMs.
In general there are, in relation to DKIM, two categories of MLMs: In general there are, in relation to DKIM, two categories of MLMs:
participating and non-participating. As each types has its own participating and non-participating. As each types has its own
issues regarding DKIM-signed messages that are either handled or issues regarding DKIM-signed messages that are either handled or
produced by them (or both), the types are discussed in separate produced by them (or both), the types are discussed in separate
sections. 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
skipping to change at page 7, line 5 skipping to change at page 6, line 7
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
the signer and verifier rather than at the MLM. the signer 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
independence of MLM services and responsibilities from those of an independence of MLM services and responsibilities from those of an
MTA. MTA.
Parts of this document explore possible changes to common practice by
signers, verifiers and MLMs. The suggested enhancements are largely
theoretical in nature, taking into account the current email
infrastructure, the facilities DKIM can provide as it gains wider
deployment, and working group consensus. There is no substantial
implementation history upon which these suggestions are based, and
the efficacy, performance and security characteristics of them have
not yet been fully explored.
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
skipping to change at page 8, line 26 skipping to change at page 8, line 26
author: The agent that provided the content of the message being author: The agent that provided the content of the message being
sent through the system, and performed the initial submission. sent through the system, and performed the initial submission.
This can be a human using an MUA or a common system utility such This can be a human using an MUA or a common system utility such
as "cron", etc. as "cron", etc.
originator: The agent that accepts a message from the author, originator: The agent that accepts a message from the author,
ensures it conforms to the relevant standards such as [MAIL], and ensures it conforms to the relevant standards such as [MAIL], and
then relays it toward its destination(s). This is often referred then 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: The 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. It is message on its way toward its ultimate destination. There is
typically running at the MTA that sits between the author's ADMD typically a signer running at the MTA that sits between the
and the general Internet. The signer may also be the same agent author's ADMD and the general Internet. The originator and/or
as the originator and/or author. author might also be a signer.
verifier: The agent that conducts DKIM signature analysis. It is verifier: Any agent that conducts DKIM signature analysis. One
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 verificaiton 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
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 exisitng signatures unverifiable. will render any existing 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 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, "flatten" HTML messages into plain text, or insert headers
or footers within HTML messages. Most or all of these changes or footers within HTML messages. Most or all of these changes
will invalidate a DKIM signature. 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
skipping to change at page 11, line 41 skipping to change at page 11, line 41
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,
whose workings in preparing a message for distribution could include whose workings in preparing a message for distribution could include
the above or even some other changes. the above or even some other changes.
In general, absent a general movement by MLM developers and operators In general, absent a general movement by MLM developers and operators
toward more DKIM-friendly practices, an MLM subscriber cannot expect toward more DKIM-friendly practices, an MLM subscriber cannot expect
signatures applied before the message was processed by the MLM to be signatures applied before the message was processed by the MLM to be
valid. Such an evolution is not expected in the short term due to valid on delivery to a receiver. Such an evolution is not expected
general development and deployment inertia. Moreover, even if an MLM in the short term due to general development and deployment inertia.
currently passes messages unmodified such that author signatures Moreover, even if an MLM currently passes messages unmodified such
validate, it is possible that a configuration change or software that author signatures validate, it is possible that a configuration
upgrade to that MLM will cause that no longer to be true. change or software upgrade to that MLM will cause that no longer to
be true.
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 send to the list when that mail would when deciding whether or not to send to the list when that mail would
be signed. The MLM could make a change that would invalidate the be signed. The MLM could make a change that would invalidate the
author's signature but not remove it prior to re-distribution. author's signature but not remove it prior to re-distribution.
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 verifiy. 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 have detrimental effects that do not validate, so this may have detrimental effects outside of
outside of the author's control. (Additional discussion of this is the author's control. (Additional discussion of this is below.)
below.) This problem could be compounded if there were receivers This problem could be compounded if there were receivers that applied
that applied signing policies (e.g., [ADSP]) and the author published signing policies (e.g., [ADSP]) and the author published any kind of
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, such as a sub-
domain, for the "personal" mail -- a subdomain that is different from domain, for the "personal" mail -- a subdomain that is different from
domain(s) used for other mail streams. This allows each to develop domain(s) used for other mail streams. This allows each to develop
an independent reputation, and more stringent policies (including an independent reputation, and more stringent policies (including
ADSP) can be applied to the mail stream(s) that do not go through ADSP) can be applied to the mail stream(s) that do not go through
mailing lists or perhaps do not get signed at all. mailing lists or perhaps do not get signed at all.
However, all of this presupposes a level of infrastructure However, all of this presupposes a level of infrastructure
understanding that is not expected to be common. Thus, it will be understanding that is not expected to be common. Thus, it will be
incumbent upon site administrators to consider how support of users incumbent upon site administrators to consider how support of users
wishing to participate in mailing lists might be accomplished as DKIM wishing to participate in mailing lists might be accomplished as DKIM
achieves wider adoption. achieves wider adoption.
In general, the more strict practices and policies are likely to be In general, the more strict practices and policies are likely to be
successful only for the mail streams subject to the most end-to-end successful only for the mail streams subject to the most end-to-end
control by the originating organization. That typically excludes control by the originating organization. That typically excludes
mail going through MLMs. Therefore, authors whose ADSP is published mail going through MLMs. Therefore, authors whose ADSP is published
as "discardable" are advised not to send mail to MLMs, as it is as "discardable" are advised not to send mail to MLMs, as it is
likely to be rejected by ADSP-aware recipients. (This is discussed likely to be rejected by ADSP-aware verifiers or recipients. (This
further in Section 5.6 below.) is discussed further in Section 5.6 below.)
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. Sites whose users of mail arrived via a non-participating MLM. Sites whose users
subscribe to non-participating MLMs should be prepared for legitimate subscribe to non-participating MLMs should be prepared for legitimate
mail to arrive with no valid signature, just as it always has in the mail to arrive with no valid signature, just as it always has in the
absence of DKIM. 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 expectation of signed participating lists to exempt them from the expectation of signed
mail as discussed in Section 4.1. This is, however, probably not a mail as discussed in Section 4.1. This is, however, probably not a
scalable solution as it imposes a burden on the receiver that is scalable solution as it imposes a burden on the receiver that is
predicated on sender behaviour. predicated on sender behaviour.
Note that the [DKIM] specification explicitly directs verifiers to Note that the [DKIM] specification explicitly directs verifiers and
treat a verification failure as though the message was not signed in receivers to treat a verification failure as though the message was
the first place. In the absence of specific ADSP direction, any not signed in the first place. In the absence of specific ADSP
treatment of a verification failure as having special meaning is direction, any treatment of a verification failure as having special
either outside the scope of DKIM or is in violation of it. meaning is either outside the scope of DKIM or is in violation of it.
Use of restrictive domain policies such as [ADSP] "discardable" Use of restrictive domain policies such as [ADSP] "discardable"
presents an additional challenge. In that case, when a message is presents an additional challenge. In that case, when a message is
unsigned or the signature can no longer be verified, the verifier is unsigned or the signature can no longer be verified, discarding of
requested to discard the message. There is no exception in the the message is requested. There is no exception in the policy for a
policy for a message that may have been altered by an MLM, nor is message that may have been altered by an MLM, nor is there a reliable
there a reliable way to identify such mail. Receivers are thus way to identify such mail. Participants are thus advised to honor
advised to honor the policy and disallow the message. the policy and disallow the message.
4.4. Wrapping A Non-Participating MLM 4.4. Wrapping A Non-Participating MLM
One approach to adding DKIM support to an otherwise non-participating 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 MLM is to "wrap" it, or in essence place it between other DKIM-aware
components (such as MTAs) that provide some DKIM services. For components (such as MTAs) that provide some DKIM services. For
example, the ADMD operating a non-participating MLM could have a DKIM example, the ADMD operating a non-participating MLM could have a DKIM
verifier act on submissions, enforcing some of the features and verifier act on submissions, enforcing some of the features and
recommendations of Section 5 on behalf of the MLM, and the MTA or MSA recommendations of Section 5 on behalf of the MLM, and the MTA or MSA
receiving the MLM Output could also add a DKIM signature for hte receiving the MLM Output could also add a DKIM signature for the
MLM's domain. MLM's domain.
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. General 5.1. General
skipping to change at page 14, line 28 skipping to change at page 14, line 28
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 covers the entire message. Thus, the following sections also discuss
investigate and recommend other processing alternatives. and suggest other processing alternatives.
A possible mitigation to this incompatibility is use of the "l=" tag A possible mitigation to this incompatibility is use of the "l=" tag
to bound the portion of the body covered by the DKIM body hash, but to bound the portion of the body covered by the DKIM body hash, but
this is not workable for [MIME] messages; moreover, it has security this is not workable for [MIME] messages; moreover, it has security
considerations (see Section 3.5 of [DKIM]). Its use is therefore considerations (see Section 3.5 of [DKIM]). Its use is therefore
discouraged. discouraged.
MLM operators often arrange to affix to outgoing messages expressions MLM operators often arrange to affix to outgoing messages expressions
of list-specific policy and related information (e.g., rules for of list-specific policy and related information (e.g., rules for
participation, small advertisements, etc.). There is currently no participation, small advertisements, etc.). There is currently no
skipping to change at page 15, line 6 skipping to change at page 15, line 6
These will be repetitive, of course, but by being generally the same These will be repetitive, of course, but by being generally the same
each time they can be easily filtered if desired. each time they can be easily filtered if desired.
5.2. DKIM Author Domain Signing Practices 5.2. DKIM Author Domain Signing Practices
[ADSP] presents a particular challenge. An author domain posting a [ADSP] presents a particular challenge. An author domain posting a
policy of "discardable" imposes a very tight restriction on the use policy of "discardable" imposes a very tight restriction on the use
of mailing lists, essentially constraining that domain's users to of mailing lists, essentially constraining that domain's users to
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 receivers. It is the consensus of the working group severe action by verifiers or receivers. It is the consensus of the
that a resending MLM is advised to reject outright any mail from an working group that a resending MLM is advised to reject outright any
author whose domain posts such a policy as it is likely to be mail from an author whose domain posts such a policy as it is likely
rejected by any ADSP-aware recipients, and might also be well advised to be rejected by any ADSP-aware recipients, and might also be well
to discourage such subscribers when they first sign up to the list. advised to discourage such subscribers when they first sign up to the
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, the
receiver can either discard the message (i.e. accept the message at message can either be discarded (i.e. accept the message at the
the [SMTP] level but discard it without delivery) or conduct an SMTP [SMTP] level but discard it without delivery) or the message can be
rejection 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 subscriber's ADMD's
published policy. 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 for 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
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,
sometimes coupled with other messages from other sources. In the sometimes coupled with other messages from other sources. In the
future, as DKIM signature outputs (e.g. the SDID of [DKIM-UPDATE]) future, as DKIM signature outputs (e.g. the AUID or SDID of
are used as inputs to reputation modules, there may be a desire to [DKIM-UPDATE]) are used as inputs to reputation modules, there may be
insulate one's reputation from influence by the unknown results of a desire to insulate one's reputation from influence by the unknown
sending mail through an MLM. In that case, authors may be well- results of sending mail through an MLM. In that case, authors may be
advised to create a mail stream specifically used for generating well-advised to create a mail stream specifically used for generating
signatures when sending traffic to MLMs. 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 more varied uses. different mail stream than a stream that serves more varied uses.
5.5. Verification Outcomes at MLMs 5.5. Verification Outcomes at MLMs
MLMs typically attempt to authenticate messages posted through them. MLMs typically attempt to authenticate messages posted through them.
skipping to change at page 16, line 47 skipping to change at page 16, line 47
In the case of verification of signatures on submissions, MLMs are In the case of verification of signatures on submissions, 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.6. Pros and Cons of Signature Removal 5.6. Signature Removal Issues
A message that arrives signed with DKIM means some domain prior to A message that arrives signed with DKIM means some domain prior to
MLM Input has made a claim of some responsibility for the message. MLM Input has made a claim of some responsibility for the message.
An obvious benefit to leaving the input-side signatures intact, then, An obvious benefit to leaving the input-side signatures intact, then,
is to preserve that chain of responsibility of the message so that is to preserve that chain of responsibility of the message so that
the receivers of the final message have an opportunity to evaluate the receivers of the final message have an opportunity to evaluate
the message with that information available to them. the message with that information available to them.
However, if the MLM is configured to make changes to the message However, if the MLM is configured to make changes to the message
prior to re-posting that would invalidate the original signature(s), prior to re-posting that would invalidate the original signature(s),
skipping to change at page 17, line 39 skipping to change at page 17, line 39
header field just added (see Section 5.7). 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 exisiting signatures after making its The MLM could re-evaluate existing signatures after making its
message changes to determine whether or not any of them have been message changes to determine whether or not any of them have been
invalidated. The cost of this is reduced by the fact that, invalidated. The cost of this is reduced by the fact that,
presumably, the necessary public keys have already been downloaded presumably, the necessary public keys have already been downloaded
and one or both of the message hashes could be reused. and one or both of the message hashes could be reused.
Per the discussion in [AUTH-RESULTS], there is no a priori reason for Per the discussion in [AUTH-RESULTS], 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
skipping to change at page 20, line 33 skipping to change at page 20, line 33
Results header field instead of the original author's DKIM signature. Results header field instead of the original author's DKIM signature.
This includes possibly processing the message as per ADSP This includes possibly processing the message as per ADSP
requirements. requirements.
Receivers are advised to ignore or remove all unsigned externally- Receivers are advised to ignore or remove all unsigned externally-
applied Authentication-Results header fields, and those not signed by applied Authentication-Results header fields, and those not signed by
an ADMD that can be trusted by the receiver. See Section 5 and an ADMD that can be trusted by the receiver. See Section 5 and
Section 7 of [AUTH-RESULTS] for further discussion. Section 7 of [AUTH-RESULTS] for further discussion.
Upon DKIM and ADSP evaluation during an SMTP session (a common Upon DKIM and ADSP evaluation during an SMTP session (a common
implementation), a receiver may decide to reject a message during an implementation), an agent might decide to reject a message during an
SMTP session. If this is done, use of an [SMTP] failure code not SMTP session. If this is done, use of an [SMTP] failure code not
normally used for "user unknown" (550) is suggested; 554 seems an normally used for "user unknown" (550) is suggested; 554 seems an
appropriate candidate. If the rejecting SMTP server supports appropriate candidate. If the rejecting SMTP server supports
[ENHANCED] status codes, is advised to make a distinction between [ENHANCED] status codes, is advised to make a distinction between
messages rejected deliberately due to policy decisions rather than messages rejected deliberately due to policy decisions rather than
those rejected because of other deliverability issues. In those rejected because of other deliverability issues. In
particular, a policy rejection is advised to be relayed using a 5.7.1 particular, a policy rejection is advised to be relayed using a 5.7.1
enhanced status code and some appropriate wording in the text part of enhanced status code and some appropriate wording in the text part of
the reply, in contrast to a code of 5.1.1 indicating the user does the reply, in contrast to a code of 5.1.1 indicating the user does
not exist. Those MLMs that automatically attempt to remove users not exist. Those MLMs that automatically attempt to remove users
with prolonged delivery problems (such as account deletion) will thus with prolonged delivery problems (such as account deletion) will thus
be able to tell the difference between policy rejection and other be able to tell the difference between policy rejection and other
delivery failures, and act accordingly. SMTP servers doing so are delivery failures, and act accordingly. SMTP servers doing so are
also advised to use appropriate wording in the text portion of the also advised to use appropriate wording in the text portion of the
reply, perhaps explicitly using the string "ADSP" to facilitate reply, perhaps explicitly using the string "ADSP" to facilitate
searching of relevant data in logs. searching of relevant data in logs.
The preceding paragraph does not apply to an [ADSP] policy of The preceding paragraph does not apply to an [ADSP] policy of
"discardable". In such cases where the submission fails that test, "discardable". In such cases where the submission fails that test,
the receiver is strongly advised to discard the message but return an the receiver or verifier is strongly advised to discard the message
SMTP success code, i.e. accept the message but drop it without but return an SMTP success code, i.e. accept the message but drop it
delivery. An SMTP rejection of such mail instead of the requested without delivery. An SMTP rejection of such mail instead of the
discard action causes more harm than good. 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
this writing, this is still a work in progress. this 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 to signers about issues mechanisms as a method for providing feedback to signers about issues
with DKIM infrastructure. This is especially important for MLMs that with DKIM infrastructure. This is especially important for MLMs that
skipping to change at page 24, line 18 skipping to change at page 24, line 18
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
Section 5 advocates addition of an [AUTH-RESULTS] header field to Section 5 advocates addition of an [AUTH-RESULTS] header field to
indicate authentication status of a message received as MLM Input. indicate authentication status of a message received as MLM Input.
Per Section 7.2 of [AUTH-RESULTS], receivers generally should not Per Section 7.2 of [AUTH-RESULTS], receivers generally should not
trust such data without a good reason to do so, such as an a priori trust such data without a good reason to do so, such as an a priori
agreement with the MLM's ADMD to do so. agreement with the MLM's ADMD.
Such agreements are strongly advised to include a requirement that Such agreements are strongly advised to include a requirement that
those header fields be covered by a [DKIM] signature added by the those header fields be covered by a [DKIM] signature added by the
MLM's ADMD. MLM's ADMD.
9. References 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
 End of changes. 27 change blocks. 
65 lines changed or deleted 72 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/