< draft-ietf-dkim-mailinglists-05.txt   draft-ietf-dkim-mailinglists-06.txt >
DKIM Working Group M. Kucherawy DKIM Working Group M. Kucherawy
Internet-Draft Cloudmark Internet-Draft Cloudmark
Intended status: Informational March 28, 2011 Intended status: BCP March 28, 2011
Expires: September 29, 2011 Expires: September 29, 2011
DKIM And Mailing Lists DKIM And Mailing Lists
draft-ietf-dkim-mailinglists-05 draft-ietf-dkim-mailinglists-06
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) and describe the
Best Current Practices.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
skipping to change at page 2, line 28 skipping to change at page 2, line 29
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
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 . . . . . . . . . . . 15
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 . . . . . . . . . . . . . . . . . 17
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 . . . . . . . . . . . . . . . . . . . . . . 20 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
skipping to change at page 3, line 20 skipping to change at page 3, line 20
or MTA) or one of their agents. Assertion of responsibility is made or MTA) or one of their agents. Assertion of responsibility is made
through a cryptographic signature. Message transit from author to through a cryptographic signature. Message transit from author to
recipient is through relays that typically make no substantive change recipient is through relays that typically make no substantive change
to the message content and thus preserve the validity of the DKIM to the message content and thus preserve the validity of the DKIM
signature. signature.
In contrast to relays, there are intermediaries, such as mailing list In contrast to relays, there are intermediaries, such as mailing list
managers (MLMs), that actively take delivery of messages, re-format managers (MLMs), that actively take delivery of messages, re-format
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, and recommend Best Current Practices based on
acquired experience. 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 existing 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 and some recommended procedures.
In general there are, in relation to DKIM, two categories of MLMs: In general there are, in relation to DKIM, two categories of MLMs:
participating and non-participating. As each types has its own participating and non-participating. As each 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
skipping to change at page 12, line 15 skipping to change at page 12, line 15
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 SHOULD be cautious when
when deciding whether or not to send to the list when that mail would deciding whether or not to send to the list when that mail would be
be signed. The MLM could make a change that would invalidate the 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 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 (see Section 2.4), site SHOULD use a separate message stream (see Section 2.4), such as
such as a sub-domain, for the "personal" mail -- a subdomain that is a sub-domain, for the "personal" mail -- a subdomain that is
different from domain(s) used for other mail streams. This allows different from domain(s) used for other mail streams. This allows
each to develop an independent reputation, and more stringent each to develop an independent reputation, and more stringent
policies (including ADSP) can be applied to the mail stream(s) that policies (including ADSP) can be applied to the mail stream(s) that
do not go through 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
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" SHOULD NOT send mail to MLMs, as it is likely to be
likely to be rejected by ADSP-aware verifiers or recipients. (This rejected by ADSP-aware verifiers or recipients. (This is discussed
is discussed further in Section 5.6 below.) 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.
skipping to change at page 13, line 32 skipping to change at page 13, line 32
receivers to treat a verification failure as though the message was receivers to treat a verification failure as though the message was
not signed in the first place. In the absence of specific ADSP not signed in the first place. In the absence of specific ADSP
direction, any treatment of a verification failure as having special direction, any treatment of a verification failure as having special
meaning is 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, discarding of unsigned or the signature can no longer be verified, discarding of
the message is requested. There is no exception in the policy for a the message is requested. There is no exception in the policy for a
message that may have been altered by an MLM, nor is there a reliable message that may have been altered by an MLM, nor is there a reliable
way to identify such mail. Participants are thus advised to honor way to identify such mail. Therefore, participants SHOULD honour the
the policy and disallow the message. 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 the receiving the MLM Output could also add a DKIM signature for the
skipping to change at page 14, line 43 skipping to change at page 14, line 43
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
header field proposed for relaying such general operational MLM header field proposed for relaying such general operational MLM
details apart from what [LIST-URLS] already supports. This sort of details apart from what [LIST-URLS] already supports. This sort of
information is what is commonly included in appended footer text or information is what is commonly included in appended footer text or
prepended header text. The working group recommends periodic, prepended header text. The working group RECOMMENDS periodic,
automatic mailings to the list to remind subscribers of list policy. automatic mailings to the list to remind subscribers of list policy,
These will be repetitive, of course, but by being generally the same and otherwise RECOMMENDS use of standard header fields to express
each time they can be easily filtered if desired. list operation parameters rather than body changes. These periodic
mailings will be repetitive, of course, but by being generally the
same each time they can be easily filtered if desired.
5.2. DKIM Author Domain Signing Practices 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 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 SHOULD reject outright any mail
mail from an author whose domain posts such a policy as it is likely from an author whose domain posts such a policy as it is likely to be
to be rejected by any ADSP-aware recipients, and might also be well rejected by any ADSP-aware recipients, and SHOULD also discourage
advised to discourage such subscribers when they first sign up to the such subscribers when they first sign up to the list. Further
list. Further discussion of this appears in Section 5.3. 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 which fail, arrives via a list to a verifier that applies ADSP checks which fail,
the message can either be discarded (i.e. accept the message at the the message SHOULD either be discarded (i.e. accept the message at
[SMTP] level but discard it without delivery) or the message can be the [SMTP] level but discard it without delivery) or rejected by
rejected by returning a 5xx error code. In the latter case, some returning a 5xx error code. In the latter case, some advice for how
advice for how to conduct the rejection in a potentially meaningful to conduct the rejection in a potentially meaningful way can be found
way can be found in Section 5.10. 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 SHOULD check for a published
ADSP record for the new subscriber's domain. If the policy specifies ADSP record for the new subscriber's domain. If the policy specifies
"discardable", the MLM might disallow the subscription or present a "discardable", the MLM SHOULD disallow the subscription or present a
warning that the subscriber's submissions to the mailing list might warning that the subscriber's submissions to the mailing list might
not be deliverable to some recipients because of the subscriber's not be deliverable to some recipients because of the subscriber's
ADMD's published policy. ADMD's published policy.
Of course, such a policy record could be applied after subscription, Of course, such a policy record could be 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 MAY 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
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 AUID or SDID of future, as DKIM signature outputs (e.g. the AUID or SDID of
[DKIM-UPDATE]) are used as inputs to reputation modules, there may be [DKIM-UPDATE]) are used as inputs to reputation modules, there may be
a desire to insulate one's reputation from influence by the unknown a desire to insulate one's reputation from influence by the unknown
results of sending mail through an MLM. In that case, authors may be results of sending mail through an MLM. In that case, authors SHOULD
well-advised to create a mail stream specifically used for generating create a mail stream specifically used for generating signatures when
signatures when sending traffic to MLMs. 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.
They usually do this through the trivial (and insecure) means of They usually do this through the trivial (and insecure) means of
verifying the RFC5322.From field email address (or, less frequently, verifying the RFC5322.From field email address (or, less frequently,
the RFC5321.MailFrom parameter) against a list registry. DKIM the RFC5321.MailFrom parameter) against a list registry. DKIM
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 MAY 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 implementers are include an author signature (see [ADSP]). MLM implementers SHOULD
advised to accommodate such in their configurations. For example, an accommodate such in their configurations. For example, an MLM might
MLM might be designed to accommodate a list of possible signing be designed to accommodate a list of possible signing domains (the
domains (the "d=" portion of a DKIM signature) for a given author, "d=" portion of a DKIM signature) for a given author, and determine
and determine at verification time if any of those are present. 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 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 could apply submission. In particular, this improved authentication MAY apply to
to subscription, unsubscription, and/or changes to subscriber options subscription, unsubscription, and/or changes to subscriber options
that are sent via email rather than through an authenticated, that are sent via email rather than through an authenticated,
interactive channel such as the web. interactive channel such as the web.
In the case of verification of signatures on submissions, MLMs are In the case of verification of signatures on submissions, MLMs SHOULD
advised to add an [AUTH-RESULTS] header field to indicate the add an [AUTH-RESULTS] header field to indicate the signature(s)
signature(s) observed on the submission as it arrived at the MLM and observed on the submission as it arrived at the MLM and what the
what the outcome of the evaluation was. Downstream agents may or may outcome of the evaluation was. Downstream agents may or may not
not trust the content of that header field depending on their own a 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. Signature Removal Issues 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),
further action is recommended to prevent invalidated signatures from further action is RECOMMENDED to prevent invalidated signatures from
arriving at final recipients, possibly triggering unwarranted filter arriving at final recipients, possibly triggering unwarranted filter
actions. (Note, however, that such filtering actions are plainly actions. (Note, however, that such filtering actions are plainly
wrong; [DKIM] stipulates that an invalid signature is to be treated wrong; [DKIM] stipulates that an invalid signature is to be treated
as no signature at all.) as no signature at all.)
A possible solution would be to: A possible solution would be to:
1. Attempt verification of all DKIM signatures present on the input 1. Attempt verification of all DKIM signatures present on the input
message; message;
skipping to change at page 18, line 4 skipping to change at page 18, line 9
The MLM could re-evaluate existing signatures after making its The MLM could re-evaluate existing signatures after making its
message changes to determine whether or not any of them have been message changes to determine whether or not any of them have been
invalidated. The cost of this is reduced by the fact that, invalidated. The cost of this is reduced by the fact that,
presumably, the necessary public keys have already been downloaded presumably, the necessary public keys have already been downloaded
and one or both of the message hashes could be reused. and one or both of the message hashes could be reused.
Per the discussion in [AUTH-RESULTS], there is no a priori reason for Per the discussion in [AUTH-RESULTS], 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, if that field is 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 This can be generalized as follows: A receiver SHOULD consider only
only [AUTH-RESULTS] fields bearing an authserv-id that appears in a [AUTH-RESULTS] fields bearing an authserv-id that appears in a list
list of sites the receiver trusts that is also included in the header of sites the receiver trusts and which is also included in the header
hash of a [DKIM] signature added by a domain in the same trusted hash of a [DKIM] signature added by a domain in the same trusted
list. list.
Since an aliasing MLM makes no substantive changes to a message, it Since an aliasing MLM makes no substantive changes to a message, it
need not consider the issue of signature removal as the original need not consider the issue of signature removal as the original
signatures should arrive at least to the next MTA unmodified. It is signatures should arrive at least to the next MTA unmodified. It is
possible that future domain-based reputations would prefer a more possible that future domain-based reputations would prefer a more
rich data set on receipt of a message, and in that case signature rich data set on receipt of a message, and in that case signature
removal would be undesirable. removal would be undesirable.
An authoring MLM is closed to outside submitters, thus much of this An authoring MLM is closed to outside submitters, thus much of this
discussion does not apply in that case. discussion does not apply in that case.
5.7. MLM Signatures 5.7. MLM Signatures
DKIM-aware resending MLMs and authoring MLMs are encouraged to affix DKIM-aware resending MLMs and authoring MLMs SHOULD affix their own
their own signatures when distributing messages. The MLM is signatures when distributing messages. The MLM is responsible for
responsible for the alterations it makes to the original messages it the alterations it makes to the original messages it is re-sending,
is re-sending, and should express this via a signature. This is also and should express this via a signature. This is also helpful for
helpful for getting feedback from any FBLs that might be set up so getting feedback from any FBLs that might be set up so that undesired
that undesired list mail can generate appropriate action. list mail can generate appropriate action.
MLM signatures will likely be used by recipient systems to recognize MLM signatures will likely be used by recipient systems to recognize
list mail, and they give the MLM's ADMD an opportunity to develop a list mail, and they give the MLM's ADMD an opportunity to develop a
good reputation for the list itself. good reputation for the list itself.
A signing MLM is, as any other MLM, free to omit redistribution of a A signing MLM is, as any other MLM, free to omit redistribution of a
message if that message was not signed in accordance with its own message if that message was not signed in accordance with its own
local configuration or policy. It could also redistribute but not local configuration or policy. It could also redistribute but not
sign such mail. However, selective signing is discouraged; sign such mail. However, selective signing is NOT RECOMMENDED;
essentially that would create two message streams from the MLM, one essentially that would create two message streams from the MLM, one
signed and one not, which can confuse DKIM-aware verifiers and signed and one not, which can confuse DKIM-aware verifiers and
receivers. receivers.
A signing MLM could add a List-Post: header field (see [LIST-URLS]) A signing MLM SHOULD 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 SHOULD ensure the signature's header hash will cover at
cover: least:
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 SHOULD sign the entire message after being
after being prepared for distribution (i.e. the "MLM Output" from prepared for distribution (i.e. the "MLM Output" from Section 3.2).
Section 3.2). Any other configuration might generate signatures that Any other configuration might generate signatures that cannot be
cannot be expected to validate. The signature would deally include expected to validate. As with any other DKIM signing operation, the
any original signatures and any header fields that were covered by choice of what portions of the header and body of the output message
those signatures, but not any that were not already signed. should include those parts of the header and body for which the MLM
wishes to assert responsibility.
DKIM-aware authoring MLMs are advised to sign the mail they send DKIM-aware authoring MLMs MUST sign the mail they send according to
according to the regular signing guidelines given in [DKIM]. the regular signing guidelines given in [DKIM].
One concern is that having an MLM apply its signature to unsigned One concern is that having an MLM apply its signature to unsigned
mail might cause some verifiers or receivers to interpret the mail might cause some verifiers or receivers to interpret the
signature as conferring more authority or authenticity to the message signature as conferring more authority or authenticity to the message
content than is defined by [DKIM]. This is an issue beyond MLMs and content than is defined by [DKIM]. This is an issue beyond MLMs and
primarily entails receive-side processing outside of the scope of primarily entails receive-side processing outside of the scope of
[DKIM]. It is nevertheless worth noting here. In the case of MLMs, [DKIM]. It is nevertheless worth noting here. In the case of MLMs,
the presence of an MLM signature is best treated as similar to MLM the presence of an MLM signature is best treated as similar to MLM
handling that affixes an RFC5322.Subject tag or similar information. handling that affixes an RFC5322.Subject tag or similar information.
It therefore does not introduce any new concerns. It therefore does not introduce any new concerns.
5.8. Verification Outcomes at Final Receiving Sites 5.8. Verification Outcomes at Final Receiving Sites
In general, verifiers and receivers can treat a signed message from In general, verifiers and receivers SHOULD treat a signed message
an MLM like any other signed message; indeed, it would be difficult from an MLM like any other signed message; indeed, it would be
to discern any difference since specifications such as [LIST-URLS] difficult to discern any difference since specifications such as
and [LIST-ID] are not universally deployed and can be trivially [LIST-URLS] and [LIST-ID] are not universally deployed and can be
spoofed. trivially spoofed.
However, because the author domain will commonly be different from However, because the author domain will commonly be different from
the MLM's signing domain, there may be a conflict with [ADSP] as the MLM's signing domain, there may be a conflict with [ADSP] as
discussed in Section 4.3 and Section 5.6, especially where an ADMD discussed in Section 4.3 and Section 5.6, especially where an ADMD
has misused ADSP. has misused ADSP.
5.9. Use With FBLs 5.9. Use With FBLs
An FBL operator may wish to act on a complaint from a user about a An FBL operator might wish to act on a complaint from a user about a
posting to a list. Some FBLs could choose to generate feedback posting to a list. Some FBLs could choose to generate feedback
reports based on DKIM verifications in the subject message. Such reports based on DKIM verifications in the subject message. Such
operators are advised to send a report to each domain with a valid operators SHOULD send a report to each domain with a valid signature
signature that has an FBL agreement established, as DKIM signatures that has an FBL agreement established, as DKIM signatures are claims
are claims of some responsibility for that message. Because authors of some responsibility for that message. Because authors generally
generally have limited control over the operation of a list, this have limited control over the operation of a list, this point makes
point makes MLM signing all the more important. MLM signing all the more important.
Where the FBL wishes to be more specific, it could act solely on a Where the FBL wishes to be more specific, it MAY act solely on a DKIM
DKIM signature where the signing domain matches the DNS domain found signature where the signing domain matches the DNS domain found in a
in a List-Post: header field (or similar). List-Post: header field (or similar).
Use of FBLs in this way should be made explicit to list subscribers. Use of FBLs in this way SHOULD be made explicit to list subscribers.
For example, if it is the policy of the MLM's ADMD to handle an FBL For example, if it is the policy of the MLM's ADMD to handle an FBL
item by unsubscribing the user that was the apparent sender of the item by unsubscribing the user that was the apparent sender of the
offending message, advising subscribers of this in advance would help offending message, advising subscribers of this in advance would help
to avoid surprises later. to avoid surprises later.
5.10. Handling Choices at Receivers 5.10. Handling Choices at Receivers
A recipient that explicitly trusts signatures from a particular MLM A recipient that explicitly trusts signatures from a particular MLM
may wish to extend that trust to an [AUTH-RESULTS] header field MAY wish to extend that trust to an [AUTH-RESULTS] header field
signed by that MLM. The recipient may then do additional processing signed by that MLM. The recipient MAY then do additional processing
of the message, using the results recorded in the Authentication- of the message, using the results recorded in the Authentication-
Results header field instead of the original author's DKIM signature. Results header field instead of the original author's DKIM signature.
This includes possibly processing the message as per ADSP This includes possibly processing the message as per ADSP
requirements. requirements.
Receivers are advised to ignore or remove all unsigned externally- Receivers SHOULD ignore or remove all unsigned externally-applied
applied Authentication-Results header fields, and those not signed by Authentication-Results header fields, and those not signed by an ADMD
an ADMD that can be trusted by the receiver. See Section 5 and that can be trusted by the receiver. See Section 5 and Section 7 of
Section 7 of [AUTH-RESULTS] for further discussion. [AUTH-RESULTS] for further discussion.
Upon DKIM and ADSP evaluation during an SMTP session (a common Upon DKIM and ADSP evaluation during an SMTP session (a common
implementation), an agent might decide to reject a message during an implementation), an agent MAY decide to reject a message during an
SMTP session. If this is done, use of an [SMTP] failure code not SMTP session. If this is done, use of an [SMTP] failure code not
normally used for "user unknown" (550) is suggested; 554 seems an normally used for "user unknown" (550) is suggested; 554 seems an
appropriate candidate. If the rejecting SMTP server supports appropriate candidate and thus SHOULD be used. If the rejecting SMTP
[ENHANCED] status codes, is advised to make a distinction between server supports [ENHANCED] status codes, it SHOULD make a distinction
messages rejected deliberately due to policy decisions rather than between messages rejected deliberately due to policy decisions rather
those rejected because of other deliverability issues. In than those rejected because of other deliverability issues. In
particular, a policy rejection is advised to be relayed using a 5.7.1 particular, a policy rejection SHOULD be relayed using a 5.7.1
enhanced status code and some appropriate wording in the text part of enhanced status code and some appropriate wording in the text part of
the reply, in contrast to a code of 5.1.1 indicating the user does the reply, in contrast to a code of 5.1.1 indicating the user does
not exist. Those MLMs that automatically attempt to remove users not exist. Those MLMs that automatically attempt to remove users
with prolonged delivery problems (such as account deletion) will thus with prolonged delivery problems (such as account deletion) SHOULD
be able to tell the difference between policy rejection and other thus detect the difference between policy rejection and other
delivery failures, and act accordingly. SMTP servers doing so are delivery failures, and act accordingly. SMTP servers doing so SHOULD
also advised to use appropriate wording in the text portion of the also use appropriate wording in the text portion of the reply,
reply, perhaps explicitly using the string "ADSP" to facilitate perhaps explicitly using the string "ADSP" to facilitate searching of
searching of relevant data in logs. relevant data in logs.
The preceding paragraph does not apply to an [ADSP] policy of The preceding paragraph does not apply to an [ADSP] policy of
"discardable". In such cases where the submission fails that test, "discardable". In such cases where the submission fails that test,
the receiver or verifier is strongly advised to discard the message the receiver or verifier SHOULD discard the message but return an
but return an SMTP success code, i.e. accept the message but drop it SMTP success code, i.e. accept the message but drop it without
without delivery. An SMTP rejection of such mail instead of the delivery. An SMTP rejection of such mail instead of the requested
requested discard action causes more harm than good. 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 SHOULD apply these or other DKIM failure reporting mechanisms as
mechanisms as a method for providing feedback to signers about issues a method for providing feedback to signers about issues with DKIM
with DKIM infrastructure. This is especially important for MLMs that infrastructure. This is especially important for MLMs that implement
implement DKIM verification as a mechanism for authentication of list DKIM verification as a mechanism for authentication of list
configuration commands and submissions from subscribers. configuration commands and submissions from subscribers.
7. IANA Considerations 7. IANA Considerations
This document includes no IANA actions. This document includes no IANA actions.
8. Security Considerations 8. Security Considerations
This document provides suggested or best current practices for use This document provides suggested or best current practices for use
with DKIM, and as such does not introduce any new technologies for with DKIM, and as such does not introduce any new technologies for
 End of changes. 46 change blocks. 
117 lines changed or deleted 122 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/