draft-otis-dkim-adsp-02.txt | draft-otis-dkim-adsp-03.txt | |||
---|---|---|---|---|
DKIM Working Group D. Otis | DKIM Working Group D. Otis | |||
Internet-Draft Trend Micro, NSSG | Internet-Draft Trend Micro, NSSG | |||
Intended status: Standards Track May 24, 2008 | Intended status: Standards Track June 23, 2008 | |||
Expires: November 25, 2008 | Expires: December 25, 2008 | |||
DKIM Author Domain Signing Practices (ADSP) | DKIM Author Domain Signing Practices (ADSP) | |||
draft-otis-dkim-adsp-02 | draft-otis-dkim-adsp-03 | |||
Status of this Memo | Status of this Memo | |||
By submitting this Internet-Draft, each author represents that any | By submitting this Internet-Draft, each author represents that any | |||
applicable patent or other IPR claims of which he or she is aware | applicable patent or other IPR claims of which he or she is aware | |||
have been or will be disclosed, and any of which he or she becomes | have been or will be disclosed, and any of which he or she becomes | |||
aware will be disclosed, in accordance with Section 6 of BCP 79. | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
skipping to change at page 1, line 34 | skipping to change at page 1, line 34 | |||
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." | |||
The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
This Internet-Draft will expire on November 25, 2008. | This Internet-Draft will expire on December 25, 2008. | |||
Copyright Notice | Copyright Notice | |||
Copyright (C) The IETF Trust (2008). | Copyright (C) The IETF Trust (2008). | |||
Abstract | Abstract | |||
Author Domain Signing Practices (ADSP) advertises the adoption level | DomainKeys Identified Mail (DKIM) as described in [RFC4871], defines | |||
of DomainKeys Identified Mail (DKIM), as described in [RFC4871], for | a domain-level authentication framework for email to permit | |||
outbound messages publicly exchanged using SMTP, as described in | verification of the source and contents of messages. This document | |||
[RFC2821]. Application of ADSP by Mail User Agents (MUAs) might need | specifies an adjunct mechanism to aid in assessing messages lacking | |||
to be offered as an option, to accommodate messages exchanged over | valid DKIM signatures for domains used in the author's address. It | |||
different public protocols. This document describes records that | defines a record that can advertise the extent that a domain signs | |||
authors' domains can publish to advertise their DKIM practices for | outgoing mail publicly exchanged on SMTP port 25, as described in | |||
outgoing messages containing the Author Domain. ADSP will not | [RFC2821], and how other hosts can access those records. | |||
dictate any specific use of DKIM identity parameters. Such identity | ||||
restrictions go beyond the charter and unnecessarily limit ADSP | Advertisements defined by this document may also increase DKIM | |||
applicability. Confirmation of an individual author's identity is | signature expectations for messages received by Mail User Agents | |||
orthogonal to and fully independent of ADSP. | (MUAs) or for messages which might have been exchanged over protocols | |||
other than SMTP. In some circumstances, author domains may wish to | ||||
have accommodations for protocol failures or for mixed public | ||||
protocol messaging not made. | ||||
In addition, DKIM's identity parameters related to the author address | ||||
are decisive only when a corresponding DKIM key local-part template | ||||
precludes an author address. DKIM in conjunction with ADSP is to | ||||
provide methods for detecting the spoofing of known domains, but not | ||||
for making assertions about the identity of the message author. | ||||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
2. Language and Terminology . . . . . . . . . . . . . . . . . . . 3 | 2. Language and Terminology . . . . . . . . . . . . . . . . . . . 4 | |||
2.1. Terms Imported from DKIM Signatures Specification . . . . 3 | 2.1. Terms Imported from DKIM Signatures Specification . . . . 4 | |||
2.2. Valid Signature . . . . . . . . . . . . . . . . . . . . . 4 | 2.2. Valid Signature . . . . . . . . . . . . . . . . . . . . . 5 | |||
2.3. Key Domain . . . . . . . . . . . . . . . . . . . . . . . . 4 | 2.3. Valid Author Signature . . . . . . . . . . . . . . . . . . 5 | |||
2.4. Author Key Domain . . . . . . . . . . . . . . . . . . . . 4 | 2.4. Key Domain . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
2.5. Author Address . . . . . . . . . . . . . . . . . . . . . . 4 | 2.5. Author Key Domain . . . . . . . . . . . . . . . . . . . . 5 | |||
2.6. Author Domain . . . . . . . . . . . . . . . . . . . . . . 4 | 2.6. Author Address . . . . . . . . . . . . . . . . . . . . . . 5 | |||
2.7. Author Domain Signing Practices . . . . . . . . . . . . . 4 | 2.7. Author Domain . . . . . . . . . . . . . . . . . . . . . . 5 | |||
3. Operation Overview . . . . . . . . . . . . . . . . . . . . . . 4 | 2.8. Author Domain Signing Practices . . . . . . . . . . . . . 5 | |||
3.1. ADSP Usage . . . . . . . . . . . . . . . . . . . . . . . . 5 | 3. Operation Overview . . . . . . . . . . . . . . . . . . . . . . 6 | |||
3.2. ADSP Results . . . . . . . . . . . . . . . . . . . . . . . 5 | 3.1. ADSP Discovery Results Usage . . . . . . . . . . . . . . . 6 | |||
4. Detailed Description . . . . . . . . . . . . . . . . . . . . . 5 | 3.2. ADSP Discovery Results . . . . . . . . . . . . . . . . . . 6 | |||
4.1. DNS Representation . . . . . . . . . . . . . . . . . . . . 5 | 4. Detailed Description . . . . . . . . . . . . . . . . . . . . . 7 | |||
4.2. Publication of ADSP Records . . . . . . . . . . . . . . . 6 | 4.1. DNS Representation . . . . . . . . . . . . . . . . . . . . 7 | |||
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 | 4.2. Publication of ADSP Records . . . . . . . . . . . . . . . 7 | |||
5.1. ADSP Specification Tag Registry . . . . . . . . . . . . . 9 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | |||
5.2. ADSP Outbound Signing Practices Registry . . . . . . . . . 9 | ||||
5.3. ADSP Flags Registry . . . . . . . . . . . . . . . . . . . 9 | ||||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 | |||
6.1. ADSP Threat Model . . . . . . . . . . . . . . . . . . . . 10 | 6.1. ADSP Threat Model . . . . . . . . . . . . . . . . . . . . 11 | |||
6.2. DNS Attacks . . . . . . . . . . . . . . . . . . . . . . . 11 | 6.2. DNS Attacks . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
6.3. DNS Wildcards . . . . . . . . . . . . . . . . . . . . . . 11 | 6.3. DNS Wildcards . . . . . . . . . . . . . . . . . . . . . . 13 | |||
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 | 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
7.1. References - Normative . . . . . . . . . . . . . . . . . . 12 | 7.1. References - Normative . . . . . . . . . . . . . . . . . . 13 | |||
7.2. References - Informative . . . . . . . . . . . . . . . . . 13 | 7.2. References - Informative . . . . . . . . . . . . . . . . . 14 | |||
Appendix A. Usage Examples . . . . . . . . . . . . . . . . . . . 13 | Appendix A. Usage Examples . . . . . . . . . . . . . . . . . . . 14 | |||
A.1. Single Location Domains . . . . . . . . . . . . . . . . . 13 | A.1. Single Location Domains . . . . . . . . . . . . . . . . . 14 | |||
A.2. Bulk Mailing Domains . . . . . . . . . . . . . . . . . . . 13 | A.2. Bulk Mailing Domains . . . . . . . . . . . . . . . . . . . 15 | |||
A.3. Commonly Forged Transactional Messages . . . . . . . . . . 14 | A.3. Commonly Forged Transactional Messages . . . . . . . . . . 15 | |||
A.4. Third Party Senders . . . . . . . . . . . . . . . . . . . 14 | A.4. Third Party Senders . . . . . . . . . . . . . . . . . . . 15 | |||
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 14 | Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 16 | |||
Appendix C. Changes in draft-otis-dkim-adsp-00 . . . . . . . . . 14 | Appendix C. Changes in draft-otis-dkim-adsp-00 . . . . . . . . . 16 | |||
Appendix D. Changes in draft-otis-dkim-adsp-01 . . . . . . . . . 15 | Appendix D. Changes in draft-otis-dkim-adsp-01 . . . . . . . . . 16 | |||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 | Appendix E. Changes in draft-otis-dkim-adsp-02 . . . . . . . . . 16 | |||
Intellectual Property and Copyright Statements . . . . . . . . . . 16 | Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
Intellectual Property and Copyright Statements . . . . . . . . . . 19 | ||||
1. Introduction | 1. Introduction | |||
DomainKeys Identified Mail (DKIM) defines a mechanism by which email | DomainKeys Identified Mail (DKIM) defines a mechanism by which email | |||
messages can be cryptographically signed, permitting a Key Domain to | messages can be cryptographically signed, permitting a Key Domain to | |||
claim responsibility for the introduction of a message into the mail | claim responsibility for the introduction of a message. Receiving | |||
stream. Receiving hosts can verify the signature by querying the Key | hosts can verify the signature by querying the Key Domain to retrieve | |||
Domain to retrieve the appropriate public key, and thereby confirm | the appropriate public key, and thereby confirm a message has been | |||
that the message was attested to by a party in possession of the | attested to by a party in possession of the private key and in | |||
private key and in control of a portion of the Key Domain. | control of a portion of the Key Domain. | |||
However, the legacy of the Internet is such that not all messages | However, the legacy of the Internet is such that not all messages | |||
will be signed, and the absence of a signature on a message is not an | will be signed or retain a valid signature, and that absence of a | |||
a priori indication of forgery. In fact, during early phases of | valid signature on a message is not an a priori indication of | |||
deployment it is likely that most messages will remain unsigned. | forgery. In fact, during early phases of deployment it is likely | |||
However, some domains might decide to sign all of their outgoing | that most messages will remain unsigned. However, some domains might | |||
mail, for example, to better protect their brand name. It is | decide to sign all of their outgoing mail, for example, to better | |||
desirable such domains be able to advertise that fact to other hosts. | protect their brand name. It is desirable such domains be able to | |||
This is the premise of Author Domain Signing Practices (ADSP). | advertise that fact to other hosts. This is the premise of Author | |||
Domain Signing Practices (ADSP). | ||||
Hosts implementing this specification can inquire what Author Domain | Receiving hosts implementing this specification ensure greater safety | |||
Signing Practices an Author Domain advertises. This inquiry is | by first inquiring into the validity of the SMTP domain before | |||
called an Author Domain Signing Practices discovery. | attempting a series of DKIM related validation transactions. The | |||
transactions pertaining to this document determine Author Domain | ||||
Signing Practices advertised by the Author Domains. This | ||||
determination is called ADSP Discovery. | ||||
The detailed requirements for Author Domain Signing Practices are | The detailed requirements for Author Domain Signing Practices are | |||
given in [RFC5016]. This document refers extensively to [RFC4871] | given in [RFC5016]. This document refers extensively to [RFC4871] | |||
and assumes the reader is familiar with it. | and assumes the reader is familiar with it. | |||
Requirements Notation: The key words "MUST", "MUST NOT", "REQUIRED", | Requirements Notation: The key words "MUST", "MUST NOT", "REQUIRED", | |||
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", | "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", | |||
"MAY", and "OPTIONAL" in this document are to be interpreted as | "MAY", and "OPTIONAL" in this document are to be interpreted as | |||
described in [RFC2119] | described in [RFC2119] | |||
skipping to change at page 3, line 46 | skipping to change at page 5, line 4 | |||
2. Language and Terminology | 2. Language and Terminology | |||
2.1. Terms Imported from DKIM Signatures Specification | 2.1. Terms Imported from DKIM Signatures Specification | |||
Some terminology used herein is derived directly from [RFC4871]. In | Some terminology used herein is derived directly from [RFC4871]. In | |||
several cases, references in that document to Sender have been | several cases, references in that document to Sender have been | |||
changed to Author here, to emphasize the relationship to the Author | changed to Author here, to emphasize the relationship to the Author | |||
address(es) in the From: header field described in [RFC2822]. | address(es) in the From: header field described in [RFC2822]. | |||
Briefly, | Briefly, | |||
o A "Local-part" is the part of an address preceding the @ sign, as | o A "Local-part" is the part of an address preceding the @ sign, as | |||
defined in [RFC2822] and used in [RFC4871]. | defined in [RFC2822] and used in [RFC4871]. | |||
2.2. Valid Signature | 2.2. Valid Signature | |||
A "Valid Signature" is any message signature which correctly verifies | A "Valid Signature" is any message signature which correctly verifies | |||
using procedures described in section 6.1 of [RFC4871]. | using procedures described in section 6.1 of [RFC4871]. | |||
2.3. Key Domain | 2.3. Valid Author Signature | |||
A "Valid Author Signature" is any message signature which correctly | ||||
verifies using procedures described in section 6.1 of [RFC4871], and | ||||
where the local-part template, the "g" parameter in the key and the | ||||
Key Domain, matches against the author address. | ||||
2.4. Key Domain | ||||
The "Key Domain" is the domain listed in the "d=" tag of a Valid | The "Key Domain" is the domain listed in the "d=" tag of a Valid | |||
Signature. | Signature. | |||
2.4. Author Key Domain | 2.5. Author Key Domain | |||
The "Author Key Domain" is the domain listed in the "d=" tag of a | The "Author Key Domain" is the domain listed in the "d=" tag of a | |||
Valid Signature that is at or above the Author Domain. The Author | Valid Author Signature that is at or above the Author Domain. The | |||
Key Domain must match all of its domain components with that of the | Author Key Domain must match all of its domain components with that | |||
Author Domain. When a referenced Key contains a "t=s" tag and value, | of the Author Domain. When a referenced Key contains a "t=s" tag and | |||
the Author Key Domain will match with the entire Author Domain. ADSP | value, the Author Key Domain will contain the entire Author Domain | |||
does not require the "i=" tag to match with any local-parts, and can | for the signature to be valid. | |||
include subdomains of the Author Domain. | ||||
2.5. Author Address | 2.6. Author Address | |||
An "Author Address" is an email address in the From header field of a | An "Author Address" is an email address in the From header field of a | |||
message [RFC2822]. If the From header field contains multiple | message [RFC2822]. If the From header field contains multiple | |||
addresses, the message has multiple Author Addresses. | addresses, the message has multiple Author Addresses. | |||
2.6. Author Domain | 2.7. Author Domain | |||
An "Author Domain" is determined by the entire right-hand-side of the | An "Author Domain" is determined by the entire right-hand-side of the | |||
Author Address (the portion that is to the right of the "@", | Author Address (the portion that is to the right of the "@", | |||
excluding the "@" itself). | excluding the "@" itself). | |||
2.7. Author Domain Signing Practices | 2.8. Author Domain Signing Practices | |||
"Author Domain Signing Practices" (or just "practices") consist of a | "Author Domain Signing Practices" (or just "practices") consist of a | |||
machine-readable record published at the "_adsp." subdomain of the | machine-readable record published at the "_adsp." subdomain of the | |||
Author Domain. The ADSP record includes statements about the | Author Domain. The ADSP record includes statements about outgoing | |||
outgoing mail practices for messages containing the Author Domain. | mail practices for messages containing the Author Domain. | |||
3. Operation Overview | 3. Operation Overview | |||
Domain owners can publish Author Domain Signing Practices via a | Domain owners can publish Author Domain Signing Practices via a | |||
distribution service, such as the Domain Name System; specific | distribution service, such as the Domain Name System; specific | |||
details are given in Section 4.1. | details related to the use of DNS are given in Section 4.1. | |||
Hosts can obtain Author Domain Signing Practices of the domain(s) | Hosts can obtain Author Domain Signing Practices of the domain(s) | |||
specified by the Author Domain as described in Section 4.2.2. If a | specified by the Author Domain as described in Section 4.2.2. If a | |||
message has multiple Author Addresses, ADSP discoveries SHOULD be | message has multiple Author Addresses, ADSP Discovery SHOULD be | |||
performed independently. This standard will not cover the | performed independently. This standard will not cover the | |||
consolidation of combined ADSP results. | consolidation of combined ADSP Discovery results. | |||
3.1. ADSP Usage | 3.1. ADSP Discovery Results Usage | |||
A receiving host might obtain varying amounts of useful information | A receiving host might obtain varying amounts of useful information | |||
through ADSP transactions. | through ADSP Discovery. Such as: | |||
o If a message has no Valid Signature, ADSP results at the Author | ||||
Domain are directly relevant to the message. | ||||
o If a message has a Valid Signature from an Author Key Domain, ADSP | o When a message has a Valid Author Signature, the ADSP Discovery | |||
provides no benefit since the message is compliant with any | result is of no benefit since the message is compliant with any | |||
possible ADSP assertion. | possible ADSP assertion. | |||
o If a message has a Valid Signature not at an Author Key Domain, | o When a message has a Valid Signature that is not also a Valid | |||
the receiver can use both the Key Domain and ADSP results in its | Author Signature, the ADSP Discovery result, in conjunction with | |||
evaluation of the message. | the Key Domain of the Valid Signature, is directly relevant to | |||
message assessment. | ||||
3.2. ADSP Results | o When a message is without a Valid Author Signature, the ADSP | |||
Discovery result at the Author Domain is directly relevant to | ||||
message assessment. | ||||
Author Domain Signing Practices discovery at an Author Domain | 3.2. ADSP Discovery Results | |||
provides four possible results: | ||||
o Messages containing the Author Domain may not have an Author Key | Author Domain Signing Practices Discovery at an Author Domain provide | |||
Domain signature. | three possible results: | |||
o All messages containing the Author Domain are initially signed by | o Messages containing the Author Domain advertise practices | |||
an Author Key Domain. | indicating they do not ensure messages are initially signed by an | |||
Author Key Domain. | ||||
o All messages containing the Author Domain not signed by an Author | o Messages containing the Author Domain advertise practices | |||
Key Domain are to be dismissed. | indicating they ensure messages are initially signed by an Author | |||
Key Domain. | ||||
o The Author Domain can not support SMTP. | o Messages containing the Author Domain advertise practices | |||
indicating they ensure messages are initially signed, and they | ||||
recommend dismissing messages not signed by an Author Key Domain. | ||||
4. Detailed Description | 4. Detailed Description | |||
4.1. DNS Representation | 4.1. DNS Representation | |||
Author Signing Practices records are published using the DNS TXT | Author Signing Practices records are published using the DNS TXT | |||
resource record type. | resource record type. | |||
NON-NORMATIVE DISCUSSION [to be removed before publication]: There | NON-NORMATIVE DISCUSSION [to be removed before publication]: There | |||
has been considerable discussion on the DKIM WG mailing list | has been considerable discussion on the DKIM WG mailing list | |||
skipping to change at page 6, line 27 | skipping to change at page 7, line 39 | |||
subdomain directly below the Author Domain; e.g., the ADSP record for | subdomain directly below the Author Domain; e.g., the ADSP record for | |||
"example.com" would be a TXT record that is published at | "example.com" would be a TXT record that is published at | |||
"_adsp.example.com". A domain MUST NOT publish more than one ADSP | "_adsp.example.com". A domain MUST NOT publish more than one ADSP | |||
record; the semantics of an ADSP transaction returning multiple ADSP | record; the semantics of an ADSP transaction returning multiple ADSP | |||
records for a single domain are undefined. (Note that "example.com" | records for a single domain are undefined. (Note that "example.com" | |||
and "mail.example.com" are different domains.) | and "mail.example.com" are different domains.) | |||
4.2. Publication of ADSP Records | 4.2. Publication of ADSP Records | |||
Author Domain Signing Practices are intended to apply to all mail | Author Domain Signing Practices are intended to apply to all mail | |||
containing the Author Domain. As an optional defensive strategy | containing the Author Domain. As a defensive strategy against | |||
against subdomain spoofing, ADSP records could also be placed at | subdomain spoofing, ADSP records can be placed at domains that might | |||
domains that might appear to support SMTP. | appear to support SMTP. | |||
Wildcards within a domain publishing ADSP records will not pose a | Wildcards within a domain publishing ADSP records will not pose a | |||
problem. This is discussed in more detail in Section 6.3. | problem. This is discussed in more detail in Section 6.3. | |||
4.2.1. Record Syntax | 4.2.1. Record Syntax | |||
ADSP records use the "tag=value" syntax described in section 3.2 of | ADSP records use the "tag=value" syntax described in section 3.2 of | |||
[RFC4871]. | [RFC4871]. Terms used to describe signing practices employ a | |||
metaphor of a door to avoid connotations that might differ from | ||||
definitions given this document. | ||||
Tags used in ADSP records are described below. Unrecognized tags | Tags used in ADSP records are described below. Unrecognized tags | |||
MUST be ignored. In the ABNF below, the WSP token is imported from | MUST be ignored. In the ABNF below, the WSP token is imported from | |||
[RFC2822]. The ALPHA and DIGIT tokens are imported from [RFC5234]. | [RFC2822]. The ALPHA and DIGIT tokens are imported from [RFC5234]. | |||
dkim= practices (plain-text; REQUIRED). Possible values are as | dkim= practices (plain-text; REQUIRED). Possible values are as | |||
follows: | follows: | |||
OPEN (Default) The Author Domain permits unsigned outbound mail. | OPEN (Default) The Author Domain practice permits unsigned | |||
outbound mail. | ||||
CLOSED All mail containing the Author Domain is initially signed | CLOSED The Author Domain practice always initially signs messages | |||
by an Author Key Domain. | containing the Author Domain by an Author Key Domain. | |||
LOCKED All mail containing the Author Domain is signed by an | LOCKED The Author Domain practice always initially signs messages | |||
Author Key Domain. Furthermore, if a message arrives without a | containing the Author Domain by an Author Key Domain. | |||
valid Author Key Domain signature, receiving hosts are | Furthermore, when a message is received without a valid Author | |||
encouraged to dismiss the message. | Key Domain signature, receiving hosts are requested to dismiss | |||
these messages. | ||||
ABNF: | ABNF: | |||
adsp-dkim-tag = %x64.6b.69.6d *WSP "=" | adsp-dkim-tag = %x64.6b.69.6d *WSP "=" | |||
*WSP ("OPEN" / "CLOSED" / "LOCKED") | *WSP ("OPEN" / "CLOSED" / "LOCKED") | |||
t= Flags, represented as a colon-separated list of names (plain-text; | ||||
OPTIONAL, default is that no flags are set). Flag values are: | ||||
s The practices are not to be applied to subdomains of the Author | ||||
Domain. This information might assist receiving hosts to | ||||
better classify subdomains lacking MX or ADSP, but that have A | ||||
records during an MX mandate transitional phase. | ||||
ABNF: | ||||
adsp-t-tag = %x74 *WSP "=" | ||||
*WSP adsp-t-tag-flag 0*( *WSP ":" *WSP adsp-t-tag-flag ) | ||||
adsp-t-tag-flag = "s" / hyphenated-word ; for future extension | ||||
hyphenated-word = ALPHA [ *(ALPHA / DIGIT / "-") (ALPHA / DIGIT) ] | ||||
Unrecognized flags MUST be ignored. | Unrecognized flags MUST be ignored. | |||
4.2.2. Author Signing Practices Discovery Procedure | 4.2.2. Author Signing Practices Discovery Procedure | |||
Hosts discovering an ADSP record SHOULD produce a result semantically | Hosts performing ADSP Discovery should exclude those being made for | |||
equivalent to applying the following steps in the order listed below. | SMTP clients that have demonstrated a history of abuse. The | |||
In practice, several of these steps can be performed in parallel to | transactions needed for ADSP Discovery or DKIM signature validation | |||
improve performance. However, implementations SHOULD avoid | should follow confirmations the Author Domain might support SMTP. In | |||
unnecessary DNS transactions. For the purposes of this section a | addition, hosts may consider some domains exempt, such as Top Level | |||
"valid ADSP record" is one that is both syntactically and | Domains (TLDs) listed in [RFC2606]. TLDs listed in [RFC2606] do not | |||
semantically correct; in particular, it matches the ABNF for a | represent a comprehensive list of TLDs that might be excluded from an | |||
"tag-list" and includes a defined "dkim=" tag. | SMTP domain validation process. Appending to a list of exempted | |||
domains may be required. | ||||
1. _Verify Domain Exists._ The host SHOULD perform a DNS query for | ||||
an MX record at the Author Domain (with no prefix). If a non- | ||||
existent domain error is returned, the discovery algorithm MUST | ||||
terminate with an error indicating SMTP is not supported by the | ||||
Author Domain. | ||||
NON-NORMATIVE DISCUSSION: To better protect domains not | For the purposes of this section, a "valid ADSP record" is one that | |||
supporting SMTP, an initial query for an MX record is a | is both syntactically and semantically correct; in particular, it | |||
reasonable choice since this record is predominately published | matches the ABNF for a "tag-list" and includes a defined "dkim=" tag. | |||
by domains supporting SMTP and is more readily cached than a | ||||
negative result. Whenever SMTP mandates MX records to support | ||||
public exchanges, then not obtaining an MX record will | ||||
terminate the discovery algorithm with an appropriate error. | ||||
2. _Fetch ADSP Record._ The host SHOULD query DNS for a TXT record | o _ADSP Discovery._ The host SHOULD query DNS for a TXT record | |||
corresponding to the Author Domain prefixed by "_adsp." (note the | corresponding to the Author Domain prefixed by "_adsp." (note the | |||
trailing dot). If a valid ADSP record is obtained, use that | trailing dot). The results returned by this operation would be | |||
record; otherwise, continue to the next step. | the value of the "dkim" tag or a value of "MISSING" when none | |||
exist. | ||||
3. _Verify Support of SMTP._ When an MX record has not been found at | ||||
the Author Domain, the host SHOULD query DNS for an A record at | ||||
the Author Domain. When no A records exist at this location, the | ||||
discovery algorithm terminates with a result indicating SMTP is | ||||
not supported by the Author Domain. | ||||
NON-NORMATIVE DISCUSSION: Whenever SMTP mandates MX records to | o NON-NORMATIVE DISCUSSION: Rather than placing ADSP records below | |||
support public exchanges, subsequent checks for A records | the "_domainkey." prefix used by DKIM, "_adsp." prefixed to the | |||
should not be made, since the discovery process would conclude | Author Domain reduces the number of DNS entities needed when ADSP | |||
at the first step. | records are desired at every address record. Delegation of a | |||
domain at or below "_domainkey." and at "_adsp." may be required | ||||
when consolidating control of DNS entries related to DKIM. | ||||
If any of the DNS transactions involved in Author Signing Practices | When any of the DNS transactions involved in ADSP Discovery result in | |||
discovery result in a temporary error condition, the algorithm | a temporary error condition, the algorithm terminates without | |||
terminates without returning a result; possible actions include | returning a result; possible actions include queuing the message or | |||
queuing the message or returning an SMTP error indicating a temporary | returning an SMTP error indicating a temporary failure. | |||
failure. | ||||
NOTE: Within a DNS transaction, as defined by [RFC1034] section | NOTE: Within a DNS transaction, as defined by [RFC1034] section | |||
5.2.2 and [RFC4034] section 3, when a CNAME is returned, the alias | 5.2.2 and [RFC4034] section 3, when a CNAME is returned, the alias | |||
name is to be processed as if it were the initial name. [RFC2181] | name is to be processed as if it were the initial name. [RFC2181] | |||
section 10.3 makes an exception for Exchange host names returned | section 10.3 makes an exception for Exchange host names returned | |||
by MX records. An Exchange host name must not return a CNAME. | by MX records. An Exchange host name must not return a CNAME. | |||
5. IANA Considerations | 5. IANA Considerations | |||
ADSP introduces some new namespaces that have been registered with | ADSP introduces the "_adsp" name into currently unregistered name | |||
IANA. In all cases, new values are assigned only for values that | space. Although domain names beginning with an underscore will not | |||
have been documented in a published RFC that has IETF Consensus | collide with host names, service names for [RFC2782] SRV records, and | |||
[RFC2434]. | labels for TXT records defined by other protocols reference | |||
underscore prefixed names to designate specific use. | ||||
INFORMATIVE NOTE [to be removed before publication]: Per the | ||||
[RFC2822] definition, a domain must start with a letter or digit. | ||||
Hence names such as "_adsp." that start with an underscore cannot | ||||
collide with host names and domains used by [RFC2821] and [RFC2822]. | ||||
5.1. ADSP Specification Tag Registry | ||||
An ADSP record provides for a list of specification tags. IANA has | ||||
established the ADSP Specification Tag Registry for specification | ||||
tags that can be used in ADSP fields. | ||||
The initial entries in the registry comprise: | ||||
+------+-----------------+ | ||||
| TYPE | REFERENCE | | ||||
+------+-----------------+ | ||||
| dkim | (this document) | | ||||
| t | (this document) | | ||||
+------+-----------------+ | ||||
ADSP Specification Tag Registry Initial Values | ||||
5.2. ADSP Outbound Signing Practices Registry | ||||
The "dkim=" tag spec, defined in Section 4.2.1, provides for a value | ||||
specifying Outbound Signing Practices. IANA has established the ADSP | ||||
Outbound Signing Practices Registry for Outbound Signing Practices. | ||||
The initial entries in the registry comprise: | ||||
+-----------+-----------------+ | ||||
| TYPE | REFERENCE | | ||||
+-----------+-----------------+ | ||||
| OPEN | (this document) | | ||||
| CLOSED | (this document) | | ||||
| LOCKED | (this document) | | ||||
+-----------+-----------------+ | ||||
ADSP Outbound Signing Practices Registry Initial Values | ||||
5.3. ADSP Flags Registry | ||||
The "t=" tag spec, defined in Section 4.2.1, provides for a value | ||||
specifying Flags. IANA has established the ADSP Flags Registry for | ||||
ADSP Flags. | ||||
The initial entries in the registry comprise: | ||||
+------+-----------------+ | ||||
| TYPE | REFERENCE | | ||||
+------+-----------------+ | ||||
| s | (this document) | | ||||
+------+-----------------+ | ||||
ADSP Flags Registry Initial Values | INFORMATIVE NOTE [to be removed before publication]: If at the time | |||
of publication no registry has been established or planned for | ||||
underscore prefixed names, this section may be removed. | ||||
6. Security Considerations | 6. Security Considerations | |||
Security considerations in the Author Domain Signing Practices are | Security considerations in the Author Domain Signing Practices mostly | |||
mostly related to attempts on the part of malicious senders to | relate to attempts on the part of malicious senders to represent | |||
represent themselves as authors for whom they are not authorized to | themselves as sending messages from the Author Domain for whom they | |||
send mail, often in an attempt to defraud recipients of the message. | are not authorized to use in their message, often in an attempt to | |||
defraud recipients of the message. | ||||
Messages signed by keys having a "g=" tag restricting the range of | Messages signed by keys having a local-part template in the "g=" tag | |||
valid local-parts are likely applied by systems that are beyond the | restricting the range of valid local-parts are likely employed by | |||
direct control of the Author Key Domain. As a result, additional | systems that are beyond the direct control of the Author Key Domain. | |||
care should be taken when the restricted local-part is not within an | As a result, additional care should be taken when the local-part | |||
Author Address. Acceptance of "g=" keys signing messages on behalf | template does not match against the Author Address. Signatures where | |||
of non-Author Addresses is discouraged. | the "g=" local-part template does not match against the Author | |||
Addresses should not be considered as offering a valid signature. | ||||
Additional security considerations regarding Author Domain Signing | Additional security considerations regarding Author Domain Signing | |||
Practices are found in the DKIM threat analysis [RFC4686]. | Practices are found in the DKIM threat analysis [RFC4686]. | |||
6.1. ADSP Threat Model | 6.1. ADSP Threat Model | |||
Email recipients often have a core set of content authors that they | Email recipients often have a core set of content Author Domains they | |||
already trust. Common examples include financial institutions with | trust. Common examples include those of financial institutions with | |||
which they have an existing relationship and Internet web transaction | which they have an existing relationship and Internet web transaction | |||
sites with which they conduct business. | sites with which they conduct business. DKIM validation and ADSP | |||
Discovery results will not provide any benefit unless receiving hosts | ||||
Email abuse often seeks to exploit the name-recognition that | act by either treating the message differently during delivery, or by | |||
recipients will have, for a legitimate email author, by using its | providing some indicator to the end recipient. Such an email | |||
domain name in the From: header field. Especially since many popular | annotation system is out of scope for this specification. | |||
MUAs do not display the author's email address, there is no empirical | ||||
evidence of the extent that this particular unauthorized use of a | ||||
domain name contributes to recipient deception or that eliminating it | ||||
will have significant effect. | ||||
However, closing this exploit could facilitate some types of | Bad actors often seek to exploit the name-recognition of a trusted | |||
optimized processing by receive-side message filtering engines, since | Author Domain. This might be done with just spoofed display-names or | |||
it could permit them to maintain higher-confidence assertions based | with user local-parts placed above subdomains or cousin domains in | |||
upon trusted Author Key Domains. | the From: header field. This problem is made worse by popular MUAs | |||
that do not display actual email addresses. As a result, there is no | ||||
empirical evidence as to what extent unauthorized use of a domain | ||||
name contributes to recipient deception, or that its elimination will | ||||
provide a significant effect. Being able to automate the accrual of | ||||
behavioural feedback that ignores invalid identifiers better ensures | ||||
systematic confidence is retained for trusted Author Key Domains. | ||||
Unauthorized uses of domain names occur elsewhere in messages, as do | Nevertheless, training recipients to use automated folder placement | |||
unauthorized uses of organizations' names. These attacks are outside | could help reduce deceptions that utilize domain look-alike and | |||
the scope of this specification. | subdomain based tactics. In addition, automated recognition | |||
facilitates optimized processing by receive-side message filtering | ||||
engines that attempt to curb unauthorized uses of domain names, | ||||
organizations' names and their logos elsewhere within the message. | ||||
These attacks and their mitigation are outside the scope of this | ||||
specification. | ||||
ADSP does not provide any benefit unless receiving host systems act | The ADSP Discovery algorithm performs one DNS transactions per Author | |||
upon ADSP results, either by treating the message differently during | Domain. Since this transaction, as well as those needed to validate | |||
the delivery process or by showing some indicator to the end | the DKIM signature, are driven by domain names in email message | |||
recipient. Such a system is out of scope for this specification. | headers of possibly fraudulent email, receiving hosts attempting ADSP | |||
Discovery and DKIM validation can become participants in traffic | ||||
multiplication attacks. | ||||
The ADSP discovery algorithm performs up to three DNS transactions | These attacks often target servers consolidating and distributing | |||
per Author Domain. Since these transactions are driven by domain | behavioral information aimed at curbing bad-actor activities. An | |||
names in email message headers of possibly fraudulent email, | attack may not lead to a denial of service, but may dramatically | |||
receiving hosts attempting to discover ADSP records can become | impact the cost of offering the service. A reduction in those | |||
participants in traffic multiplication attacks. | offering consolidated behavioral information places remaining | |||
providers in greater jeopardy of receiving a larger portion of the | ||||
abuse being generated. | ||||
6.2. DNS Attacks | 6.2. DNS Attacks | |||
An attack might be waged against DNS infrastructure in an attempt to | An attack might be waged against DNS infrastructure in an attempt to | |||
disable services dependent upon DNS. Such attacks could be made | disable services dependent upon DNS. Such attacks could be made | |||
worse by receiving hosts employing ADSP discovery. For this reason, | worse by receiving hosts employing ADSP Discovery and DKIM | |||
SMTP should consider making MX records mandatory for public | validations. For this reason, SMTP should eventually consider making | |||
exchanges. The ADSP discovery process is not expected to impact the | MX records mandatory for public exchanges. The ADSP Discovery | |||
likelihood of an attacker being successful at poisoning local DNS | process is not expected to impact the likelihood of an attacker being | |||
resolvers. In addition, such DNS security issues are addressed by | successful at poisoning local DNS resolvers. In addition, such DNS | |||
DNSSEC [RFC4033]. | security issues are addressed by DNSSEC [RFC4033]. | |||
A steady attack may not cause a denial of service, but can consume | ||||
significant resources related to "in the cloud" consolidation and | ||||
distribution of behavioral information. A typical strategy used by | ||||
bad actors employing bot-nets is to rapidly transition from an active | ||||
to dormant state. The duration of activity experienced by an SMTP | ||||
server is often brief, and is then followed by a fairly long dormant | ||||
period. This tactic proves challenging for defensive strategies | ||||
instantiated by individual hosts. There may be tens of millions of | ||||
bot-nets in the active state, while hundreds of millions appear | ||||
dormant to SMTP servers. | ||||
Consolidating and distributing behavioral information offers a | ||||
defensive tactic that can minimize the effectiveness of a blitzkrieg | ||||
or fast-flux tactic. Unfortunately, often part of a bad-actor's | ||||
tactic is to inundate behavioral repositories with virtual | ||||
identifiers. For DKIM, the signature's identity ("i=") parameter can | ||||
be synthesized since it permits use of wildcarded domains, unlike the | ||||
Key Domain ("d=") parameter or that of the ADSP record. | ||||
Because ADSP operates within the framework of the legacy e-mail | Because ADSP operates within the framework of the legacy e-mail | |||
system, the default result in the absence of an ADSP record is for | system, the default result in the absence of an ADSP record is for | |||
the Author Domain to be considered "OPEN" where not all messages are | the Author Domain to be considered "OPEN" where not all messages are | |||
expected to be signed by a Author Key Domain. It is therefore | expected to be signed by a Author Key Domain. It is therefore | |||
important that the ADSP clients distinguish a DNS failure such as | important that the ADSP clients distinguish a DNS failure such as | |||
"SERVFAIL" from other DNS errors so that appropriate actions can be | "SERVFAIL" from other DNS errors so that appropriate actions can be | |||
taken. | taken. | |||
To ensure message reception remains viable for crucial systems when | It is likely DKIM and ADSP combined roles will be in preventing | |||
DNS fails, IP addresses of crucial SMTP clients should be white | deception in conjunction with automated folder placements for those | |||
listed to allow ADSP and DKIM to be selectively bypassed during such | domains considered trustworthy. To ensure message reception remains | |||
events. | viable for crucial systems when DNS fails, IP addresses of crucial | |||
SMTP clients should be white listed to allow ADSP and DKIM to be | ||||
selectively bypassed during such events. | ||||
6.3. DNS Wildcards | 6.3. DNS Wildcards | |||
Wildcards within a domain, excluding wildcard MX records, that also | Wildcards within a domain, excluding wildcard MX records, that also | |||
publish ADSP records, do not pose a significant problem. While | publish ADSP records, do not pose a significant problem. While | |||
referencing SMTP related records will not provide "NXDOMAIN" results, | referencing SMTP related records will not provide "NXDOMAIN" results, | |||
either an MX or A record is still obtained as evidence of SMTP | SMTP discovery records such as MX or A records offer evidence of SMTP | |||
support. | support. Whether AAAA records absent MX or A records are to be | |||
considered evidence of SMTP support has not withstood widespread use | ||||
of AAAA only servers. | ||||
NON-NORMATIVE NOTE: Complete ADSP coverage for all subdomains of a | NON-NORMATIVE NOTE: Complete ADSP coverage for all subdomains of a | |||
domain remains possible. However, ADSP records must be published at | domain remains possible. However, ADSP records would need to be | |||
every subdomain containing A records, in addition to subdomains | published at every subdomain containing A records, in addition to | |||
containing MX records. When SMTP adopts an MX record mandate for | subdomains containing MX records. When SMTP adopts an MX record | |||
public exchanges, ADSP records would be required only at subdomains | mandate for public exchanges, ADSP records would then be required | |||
containing MX records. | only at subdomains containing MX records. This strategy shelters | |||
domains not publishing MX records from the transactions associated | ||||
with any number of Author Addresses and DKIM signatures per message. | ||||
7. References | 7. References | |||
7.1. References - Normative | 7.1. References - Normative | |||
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", | [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", | |||
STD 13, RFC 1034, November 1987. | STD 13, RFC 1034, November 1987. | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS | [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS | |||
Specification", RFC 2181, July 1997. | Specification", RFC 2181, July 1997. | |||
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an | [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS | |||
IANA Considerations Section in RFCs", BCP 26, RFC 2434, | Names", BCP 32, RFC 2606, June 1999. | |||
October 1998. | ||||
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, | [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, | |||
April 2001. | April 2001. | |||
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, | [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, | |||
April 2001. | April 2001. | |||
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. | [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. | |||
Rose, "DNS Security Introduction and Requirements", | Rose, "DNS Security Introduction and Requirements", | |||
RFC 4033, March 2005. | RFC 4033, March 2005. | |||
skipping to change at page 13, line 7 | skipping to change at page 14, line 18 | |||
[RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, | [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, | |||
J., and M. Thomas, "DomainKeys Identified Mail (DKIM) | J., and M. Thomas, "DomainKeys Identified Mail (DKIM) | |||
Signatures", RFC 4871, May 2007. | Signatures", RFC 4871, May 2007. | |||
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax | [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax | |||
Specifications: ABNF", STD 68, RFC 5234, January 2008. | Specifications: ABNF", STD 68, RFC 5234, January 2008. | |||
7.2. References - Informative | 7.2. References - Informative | |||
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for | ||||
specifying the location of services (DNS SRV)", RFC 2782, | ||||
February 2000. | ||||
[RFC5016] Thomas, M., "Requirements for a DomainKeys Identified Mail | [RFC5016] Thomas, M., "Requirements for a DomainKeys Identified Mail | |||
(DKIM) Signing Practices Protocol", RFC 5016, | (DKIM) Signing Practices Protocol", RFC 5016, | |||
October 2007. | October 2007. | |||
Appendix A. Usage Examples | Appendix A. Usage Examples | |||
These examples are intended to illustrate typical uses of ADSP. They | These examples are intended to illustrate typical uses of ADSP. They | |||
are not intended to be exhaustive, nor to apply to every domain's or | are not intended to be exhaustive, nor to apply to every domain's or | |||
mail system's individual situation. | mail system's individual situation. | |||
Administrators are advised to consider the ways that mail processing | Administrators are advised to consider the ways that mail processing | |||
can modify messages in a manner that will invalidate existing DKIM | can modify messages in a manner that will invalidate existing DKIM | |||
signatures, such as mailing lists, courtesy forwarders, and other | signatures, such as mailing lists, courtesy forwarders, and other | |||
paths that could add or modify headers, or modify the message body. | paths that could add or modify headers, or modify the message body. | |||
In that case, if these modifications invalidate DKIM signatures, | In that case, if these modifications invalidate DKIM signatures, | |||
receiving hosts will consider the mail not to have an Author Key | receiving hosts will consider the mail not to have an Author Key | |||
Domain signature, even though a Valid Signature was present when the | Domain signature, even though a Valid Author Signature was present | |||
mail was originally sent. | when the mail was originally sent. | |||
A.1. Single Location Domains | A.1. Single Location Domains | |||
A common mail system configuration handles all of a domain's users' | A common mail system configuration handles all of a domain's users' | |||
incoming and outgoing mail through a single MTA or group of MTAs. In | incoming and outgoing mail through a single MTA or group of MTAs. In | |||
that case, the MTA(s) can be configured to sign outgoing mail with an | that case, the MTA(s) can be configured to sign outgoing mail with an | |||
Author Key Domain signature. | Author Key Domain signature. | |||
In this situation it might be appropriate to publish a "CLOSED" ADSP | In this situation it might be appropriate to publish a "CLOSED" ADSP | |||
record for the Author Domain, depending on whether users also send | record for the Author Domain, depending on whether users also send | |||
skipping to change at page 14, line 8 | skipping to change at page 15, line 23 | |||
apply an Author Key Domain signature. In this case, before | apply an Author Key Domain signature. In this case, before | |||
publishing a "CLOSED" ADSP record, the domain's management should be | publishing a "CLOSED" ADSP record, the domain's management should be | |||
confident that all of its outgoing mail will be sent through signing | confident that all of its outgoing mail will be sent through signing | |||
MTAs. Lacking individual users, the domain is unlikely to | MTAs. Lacking individual users, the domain is unlikely to | |||
participate in mailing lists, but could still send mail through other | participate in mailing lists, but could still send mail through other | |||
paths that might invalidate signatures. | paths that might invalidate signatures. | |||
Domain owners also often use specialist mailing providers to send | Domain owners also often use specialist mailing providers to send | |||
their bulk mail. In that case, the mailing provider needs access to | their bulk mail. In that case, the mailing provider needs access to | |||
a suitable signing key in order to apply an Author Key Domain | a suitable signing key in order to apply an Author Key Domain | |||
signature. One possible route would be for the Author Key Domain | signature. One possible method would be for the Author Key Domain | |||
owner to generate the key and give it to the mailing provider. | owner exchange keys with the mailing provider. Another would be for | |||
Another would be for the Author Key Domain to delegate a subdomain | the Author Key Domain to delegate a subdomain below the "_domainkey." | |||
below the "_domainkey." label to the mailing provider. For example, | label to the mailing provider. For example, "bigbank.example" might | |||
"bigbank.example" might delegate "esp-00._domainkey.bigbank.example" | delegate "esp-00._domainkey.bigbank.example.com" to such a provider. | |||
to such a provider. In that case, the provider could generate keys | In that case, the provider could generate keys and DKIM DNS records | |||
and DKIM DNS records itself and provide Author Key Domain signatures. | itself and provide Author Key Domain signatures. | |||
A.3. Commonly Forged Transactional Messages | A.3. Commonly Forged Transactional Messages | |||
In some cases, a domain might sign all its outgoing mail with an | In some cases, a domain might sign all its outgoing mail with an | |||
Author Key Domain signature, but prefers that receiving host systems | Author Key Domain signature, but prefers that receiving host systems | |||
dismiss mail without a valid Author Key Domain signature to avoid | dismiss mail without a valid Author Key Domain signature to avoid | |||
confusion with mail sent from fraudulent sources unable to apply an | confusion with mail sent from fraudulent sources unable to apply an | |||
Author Key Domain signature. (This latter kind of mail is sometimes | Author Key Domain signature. (This latter kind of mail is sometimes | |||
loosely called "forgeries".) In that case, it might be appropriate | loosely called "forgeries".) In that case, it might be appropriate | |||
to publish a "LOCKED" ADSP record. Note that a domain SHOULD NOT | to publish a "LOCKED" ADSP record. Note that a domain SHOULD NOT | |||
publish a "LOCKED" ADSP record when it wishes to maximize the | publish a "LOCKED" ADSP record when it wishes to maximize the | |||
likelihood that its mail is delivered, since it could cause some | likelihood that its mail is delivered, since it could cause some | |||
fraction of the mail to be discarded. | fraction of the mail to become rejected or discarded. | |||
As a special case, if a domain sends no mail at all, it can safely | As a special case, if a domain sends no mail at all, it can safely | |||
publish a "LOCKED" ADSP record, since any mail with an Author Address | publish a "LOCKED" ADSP record, since any mail with this Author | |||
for this domain is a forgery. | Domain would be a forgery. | |||
A.4. Third Party Senders | A.4. Third Party Senders | |||
Another common use case is for a third party to enter into an | Another common use case is for a third party to enter into an | |||
agreement whereby that third party will send bulk or other mail on | agreement whereby that third party will send bulk or other mail on | |||
behalf of a designated Author Domain, using that domain in the | behalf of a designated Author Domain, using that domain in the | |||
RFC2822 From: or other headers. Due to the many and varied | RFC2822 From: or other headers. Due to the many and varied | |||
complexities of such agreements, third party signing is not addressed | complexities of such agreements, third party signing is not addressed | |||
in this specification. | in this specification. | |||
Appendix B. Acknowledgements | Appendix B. Acknowledgements | |||
This document was based upon the draft-ietf-dkim-ssp-003. | This document was based upon the draft-ietf-dkim-ssp-003. Dave | |||
Crocker, Frank Ellermann, and Charles Lindsey inputs were valuable, | ||||
however inclusion of their names should not be misconstrued as an | ||||
endorsement of this draft. This draft is an individual submission | ||||
intended to illustrate a comprehensive solution that might help | ||||
foreclose protracted debate when there is otherwise general | ||||
agreement. | ||||
Appendix C. Changes in draft-otis-dkim-adsp-00 | Appendix C. Changes in draft-otis-dkim-adsp-00 | |||
o Conditioned Author Signing Practices Discovery Procedure SMTP | o Conditioned Author Signing Practices Discovery Procedure SMTP | |||
verification step to be made only when an MX record had not been | verification step to be made only when an MX record had not been | |||
found. | found. | |||
Appendix D. Changes in draft-otis-dkim-adsp-01 | Appendix D. Changes in draft-otis-dkim-adsp-01 | |||
o Modified the Author Signing Practices Discovery Procedure to | o Modified the Author Signing Practices Discovery Procedure to | |||
better conform with terms in RFC2821. In addition, a note now | better conform with terms in RFC2821. In addition, a note now | |||
covers the issue of CNAMEs. | covers the issue of CNAMEs. | |||
Appendix E. Changes in draft-otis-dkim-adsp-02 | ||||
o Modified the abstract to include the language recommended by Dave | ||||
Crocker, clarified the relationship this document has with DKIM, | ||||
SMTP and other protocols, and clarified the extent of DKIM | ||||
identity parameter. The general language describing the intent | ||||
was taken from the WG charter. | ||||
o Included non retention of a valid signature and offered an | ||||
admonishment to first validate from domain in the introduction. | ||||
o Added a separate definition for Valid Author Signatures by | ||||
including the requirement the local-part template much match | ||||
against the author addresses. | ||||
o Made a few minor changes to the Author Key Domain definition. | ||||
o Included the phrase "related to the use of DNS" to the operation | ||||
Overview as well as expanding upon the term ADSP Discovery in | ||||
several places. | ||||
o Modified ADSP Usage to Discovery Results Usage. The information | ||||
provided was reorganized from least to most useful. | ||||
o Modified the terms in ADSP Discovery Results to be consistent with | ||||
advertised practices to align more closely with Dave Crocker's | ||||
Abstract. | ||||
o The Record syntax now mentions the terms used are a metaphor for a | ||||
door, and the terms modified to be in closer alignment with the | ||||
abstract. | ||||
o The ADSP Discovery procedure now warns about unlimited application | ||||
of this process, and suggests some domains may require exemption, | ||||
and introduces the term MISSING when no ADSP record is discovered. | ||||
o The IANA considerations where shortened based upon the assumption | ||||
a registry may not be established for underscore prefixed TXT | ||||
records. | ||||
o Change the beginning of the security section to clarify the domain | ||||
and not the author identity is assured by DKIM and ADSP. | ||||
o Changed the wording related to the key "g=" parameter to be more | ||||
consistent throughout the document. | ||||
o Mention in the threat model annotation is required by out of | ||||
scope. | ||||
o Modified the paragraph that describes exploitation of trust to be | ||||
about the domain and not the author identity. | ||||
o Mention that the target of an attack is often directed to | ||||
behavioral information services. | ||||
o Add paragraph describing the typical nature of bot-net behaviour, | ||||
and how the DKIM "i=" represents a significant venerability for | ||||
the accrual of behavioral information. | ||||
o Add a sentence to highlight benefits using automatic folder | ||||
placement. | ||||
o Expanded the DNS wildcard section to generally describe what might | ||||
be involved when validating the domains support of SMTP. | ||||
Author's Address | Author's Address | |||
Douglas Otis | Douglas Otis | |||
Trend Micro, NSSG | Trend Micro, NSSG | |||
10101 N. De Anza Blvd | 10101 N. De Anza Blvd | |||
Cupertino, CA 95014 | Cupertino, CA 95014 | |||
USA | USA | |||
Phone: +1.408.257-1500 | Phone: +1.408.257-1500 | |||
Email: doug_otis@trendmicro.com | Email: doug_otis@trendmicro.com | |||
End of changes. 64 change blocks. | ||||
299 lines changed or deleted | 354 lines changed or added | |||
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |