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