draft-ietf-dkim-ssp-03.txt | draft-ietf-dkim-ssp-04.txt | |||
---|---|---|---|---|
Network Working Group E. Allman | Network Working Group E. Allman | |||
Internet-Draft Sendmail, Inc. | Internet-Draft Sendmail, Inc. | |||
Intended status: Standards Track J. Fenton | Intended status: Standards Track J. Fenton | |||
Expires: August 26, 2008 Cisco Systems, Inc. | Expires: January 3, 2009 Cisco Systems, Inc. | |||
M. Delany | M. Delany | |||
Yahoo! Inc. | Yahoo! Inc. | |||
J. Levine | J. Levine | |||
Taughannock Networks | Taughannock Networks | |||
February 23, 2008 | July 2, 2008 | |||
DKIM Author Signing Practices (ASP) | DKIM Author Domain Signing Practices (ADSP) | |||
draft-ietf-dkim-ssp-03 | draft-ietf-dkim-ssp-04 | |||
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 39 | skipping to change at page 1, line 39 | |||
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 August 26, 2008. | This Internet-Draft will expire on January 3, 2009. | |||
Copyright Notice | ||||
Copyright (C) The IETF Trust (2008). | ||||
Abstract | Abstract | |||
DomainKeys Identified Mail (DKIM) defines a domain-level | DomainKeys Identified Mail (DKIM) defines a domain-level | |||
authentication framework for email using public-key cryptography and | authentication framework for email to permit verification of the | |||
key server technology to permit verification of the source and | source and contents of messages. This document specifies an adjunct | |||
contents of messages by either Mail Transport Agents (MTAs) or Mail | mechanism to aid in assessing messages that do not contain a DKIM | |||
User Agents (MUAs). The primary DKIM protocol is described in | signature for the domain used in the author's address. It defines a | |||
[RFC4871]. This document describes the records that authors' domains | record that can advertise whether they sign their outgoing mail, and | |||
can use to advertise their practices for signing their outgoing mail, | how other hosts can access those records. | |||
and how other hosts can access those records. | ||||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2. Language and Terminology . . . . . . . . . . . . . . . . . . . 4 | 2. Language and Terminology . . . . . . . . . . . . . . . . . . . 3 | |||
2.1. Terms Imported from DKIM Signatures Specification . . . . 4 | 2.1. Terms Imported from DKIM Signatures Specification . . . . 3 | |||
2.2. Valid Signature . . . . . . . . . . . . . . . . . . . . . 5 | 2.2. Valid Signature . . . . . . . . . . . . . . . . . . . . . 4 | |||
2.3. Author Address . . . . . . . . . . . . . . . . . . . . . . 5 | 2.3. Author Address . . . . . . . . . . . . . . . . . . . . . . 4 | |||
2.4. Author Domain . . . . . . . . . . . . . . . . . . . . . . 5 | 2.4. Author Domain . . . . . . . . . . . . . . . . . . . . . . 4 | |||
2.5. Alleged Author . . . . . . . . . . . . . . . . . . . . . . 5 | 2.5. Alleged Author . . . . . . . . . . . . . . . . . . . . . . 4 | |||
2.6. Author Signing Practices . . . . . . . . . . . . . . . . . 5 | 2.6. Author Domain Signing Practices . . . . . . . . . . . . . 4 | |||
2.7. Author Signature . . . . . . . . . . . . . . . . . . . . . 5 | 2.7. Author Signature . . . . . . . . . . . . . . . . . . . . . 4 | |||
3. Operation Overview . . . . . . . . . . . . . . . . . . . . . . 6 | 3. Operation Overview . . . . . . . . . . . . . . . . . . . . . . 5 | |||
3.1. ASP Usage . . . . . . . . . . . . . . . . . . . . . . . . 6 | 3.1. ADSP Applicability . . . . . . . . . . . . . . . . . . . . 5 | |||
3.2. ASP Results . . . . . . . . . . . . . . . . . . . . . . . 6 | 3.2. ADSP Usage . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
4. Detailed Description . . . . . . . . . . . . . . . . . . . . . 7 | 3.3. ADSP Results . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
4.1. DNS Representation . . . . . . . . . . . . . . . . . . . . 7 | 4. Detailed Description . . . . . . . . . . . . . . . . . . . . . 6 | |||
4.2. Publication of ASP Records . . . . . . . . . . . . . . . . 7 | 4.1. DNS Representation . . . . . . . . . . . . . . . . . . . . 6 | |||
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | 4.2. Publication of ADSP Records . . . . . . . . . . . . . . . 6 | |||
5.1. ASP Specification Tag Registry . . . . . . . . . . . . . . 10 | 4.3. ADSP Lookup Procedure . . . . . . . . . . . . . . . . . . 7 | |||
5.2. ASP Outbound Signing Practices Registry . . . . . . . . . 10 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 | |||
5.3. ASP Flags Registry . . . . . . . . . . . . . . . . . . . . 11 | 5.1. ADSP Specification Tag Registry . . . . . . . . . . . . . 8 | |||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 | 5.2. ADSP Outbound Signing Practices Registry . . . . . . . . . 9 | |||
6.1. ASP Threat Model . . . . . . . . . . . . . . . . . . . . . 11 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 | |||
6.2. DNS Attacks . . . . . . . . . . . . . . . . . . . . . . . 12 | 6.1. ADSP Threat Model . . . . . . . . . . . . . . . . . . . . 9 | |||
6.3. DNS Wildcards . . . . . . . . . . . . . . . . . . . . . . 12 | 6.2. DNS Attacks . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 | 6.3. DNS Wildcards . . . . . . . . . . . . . . . . . . . . . . 10 | |||
7.1. References - Normative . . . . . . . . . . . . . . . . . . 13 | 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
7.2. References - Informative . . . . . . . . . . . . . . . . . 13 | 7.1. References - Normative . . . . . . . . . . . . . . . . . . 11 | |||
Appendix A. Usage Examples . . . . . . . . . . . . . . . . . . . 13 | 7.2. References - Informative . . . . . . . . . . . . . . . . . 11 | |||
A.1. Single Location Domains . . . . . . . . . . . . . . . . . 14 | Appendix A. Usage Examples . . . . . . . . . . . . . . . . . . . 11 | |||
A.2. Bulk Mailing Domains . . . . . . . . . . . . . . . . . . . 14 | A.1. Single Location Domains . . . . . . . . . . . . . . . . . 12 | |||
A.3. Bulk Mailing Domains with Discardable Mail . . . . . . . . 14 | A.2. Bulk Mailing Domains . . . . . . . . . . . . . . . . . . . 12 | |||
A.4. Third Party Senders . . . . . . . . . . . . . . . . . . . 15 | A.3. Bulk Mailing Domains with Discardable Mail . . . . . . . . 13 | |||
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 15 | A.4. Third Party Senders . . . . . . . . . . . . . . . . . . . 13 | |||
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 15 | A.5. Non-email Domains . . . . . . . . . . . . . . . . . . . . 13 | |||
C.1. Changes since -ietf-dkim-02 . . . . . . . . . . . . . . . 15 | Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 13 | |||
C.2. Changes since -ietf-dkim-ssp-01 . . . . . . . . . . . . . 16 | Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 13 | |||
C.3. Changes since -ietf-dkim-ssp-00 . . . . . . . . . . . . . 17 | C.1. Changes since -ietf-dkim-03 . . . . . . . . . . . . . . . 14 | |||
C.4. Changes since -allman-ssp-02 . . . . . . . . . . . . . . . 17 | C.2. Changes since -ietf-dkim-02 . . . . . . . . . . . . . . . 14 | |||
C.5. Changes since -allman-ssp-01 . . . . . . . . . . . . . . . 18 | C.3. Changes since -ietf-dkim-ssp-01 . . . . . . . . . . . . . 15 | |||
C.6. Changes since -allman-ssp-00 . . . . . . . . . . . . . . . 18 | C.4. Changes since -ietf-dkim-ssp-00 . . . . . . . . . . . . . 16 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 | C.5. Changes since -allman-ssp-02 . . . . . . . . . . . . . . . 16 | |||
Intellectual Property and Copyright Statements . . . . . . . . . . 20 | C.6. Changes since -allman-ssp-01 . . . . . . . . . . . . . . . 17 | |||
C.7. Changes since -allman-ssp-00 . . . . . . . . . . . . . . . 17 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 | ||||
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 signing domain | messages can be cryptographically signed, permitting a signing domain | |||
to claim responsibility for the introduction of a message into the | to claim responsibility for the introduction of a message into the | |||
mail stream. Message recipients can verify the signature by querying | mail stream. Message recipients can verify the signature by querying | |||
the signer's domain directly to retrieve the appropriate public key, | the signer's domain directly to retrieve the appropriate public key, | |||
and thereby confirm that the message was attested to by a party in | and thereby confirm that the message was attested to by a party in | |||
possession of the private key for the signing domain. | possession of the private key for the signing 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, and the absence of a signature on a message is not an | |||
a priori indication of forgery. In fact, during early phases of | a priori indication of forgery. In fact, during early phases of | |||
deployment it is very likely that most messages will remain unsigned. | deployment it is very likely that most messages will remain unsigned. | |||
However, some domains might decide to sign all of their outgoing | However, some domains might decide to sign all of their outgoing | |||
mail, for example, to protect their brand name. It is desirable for | mail, for example, to protect their brand names. It is desirable for | |||
such domains to be able to advertise that fact to other hosts. This | such domains to be able to advertise that fact to other hosts. This | |||
is the topic of Author Signing Practices (ASP). | is the topic of Author Domain Signing Practices (ADSP). | |||
Hosts implementing this specification can inquire what Author Signing | Hosts implementing this specification can inquire what Author Signing | |||
Practices a domain advertises. This inquiry is called an Author | Practices a domain advertises. This inquiry is called an Author | |||
Signing Practices check. | Signing Practices check. | |||
The detailed requirements for Author Signing Practices are given in | The basic requirements for ADSP are given in [RFC5016]. This | |||
[RFC5016]. This document refers extensively to [RFC4871] and assumes | document refers extensively to [RFC4871] and assumes the reader is | |||
the reader is familiar with it. | familiar with it. | |||
Requirements Notation: The key words "MUST", "MUST NOT", "REQUIRED", | Requirements Notation: The key words "MUST", "MUST NOT", | |||
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", | "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", | |||
"MAY", and "OPTIONAL" in this document are to be interpreted as | "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be | |||
described in [RFC2119] | interpreted as described in [RFC2119] | |||
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 "Signer" is the agent that signs a message, as defined in | o A "Signer" is the agent that signs a message, as defined in | |||
section 2.1 of [RFC4871]. | section 2.1 of [RFC4871]. | |||
o A "Selector" specifies which of the keys published by a signing | o A "Local-part" is the part of an address preceding the @ | |||
domain is to be queried, as defined in section 3.1 of [RFC4871]. | character, as defined in [RFC2822] and used in [RFC4871]. | |||
o A "Local-part" is the part of an address preceding the @ sign, as | ||||
defined in [RFC2822] and used in [RFC4871]. | ||||
2.2. Valid Signature | 2.2. Valid Signature | |||
A "Valid Signature" is any signature on a message which correctly | A "Valid Signature" is any signature on a message which correctly | |||
verifies using the procedure described in section 6.1 of [RFC4871]. | verifies using the procedure described in section 6.1 of [RFC4871]. | |||
2.3. Author Address | 2.3. 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 | |||
skipping to change at page 5, line 29 | skipping to change at page 4, line 26 | |||
2.4. Author Domain | 2.4. Author Domain | |||
An "Author Domain" is everything to the right of the "@" in an Author | An "Author Domain" is everything to the right of the "@" in an Author | |||
Address (excluding the "@" itself). | Address (excluding the "@" itself). | |||
2.5. Alleged Author | 2.5. Alleged Author | |||
An "Alleged Author" is an Author Address of a message; it is | An "Alleged Author" is an Author Address of a message; it is | |||
"alleged" because it has not yet been verified. | "alleged" because it has not yet been verified. | |||
2.6. Author Signing Practices | 2.6. Author Domain Signing Practices | |||
"Author Signing Practices" (or just "practices") consist of a | "Author Domain Signing Practices" (or just "practices") consist of a | |||
machine-readable record published by the domain of an Alleged Author | machine-readable record published by the domain of an Alleged Author | |||
which includes statements about the domain's practices with respect | which includes statements about the domain's practices with respect | |||
to mail it sends with its domain in the From: line. | to mail it sends with its domain in the From: line. | |||
2.7. Author Signature | 2.7. Author Signature | |||
An "Author Signature" is any Valid Signature where the identity of | An "Author Signature" is any Valid Signature where the identity of | |||
the user or agent on behalf of which the message is signed (listed in | the user or agent on behalf of which the message is signed (listed in | |||
the ""i="" tag or its default value from the ""d="" tag) matches an | the "i=" tag or its default value from the "d=" tag) matches an | |||
Author Address in the message. When the identity of the user or | Author Address in the message. When the identity of the user or | |||
agent includes a Local-part, the identities match if the Local-parts | agent includes a Local-part, the identities match if the Local-parts | |||
match and the domains match. Otherwise, the identities match if the | are the same string, and the domains are the same string. Otherwise, | |||
domains match. | the identities match if the domains are the same string. Following | |||
[RFC2821], Local-part comparisons are case sensitive, domain | ||||
comparisons are case insensitive. | ||||
For example, if a message has a Valid Signature, with the DKIM- | For example, if a message has a Valid Signature, with the DKIM- | |||
Signature field containing "i=a@domain.example", then domain.example | Signature field containing "i=a@domain.example", then domain.example | |||
is asserting that it takes responsibility for the message. If the | is asserting that it takes responsibility for the message. If the | |||
message's From: field contains the address "b@domain.example" and an | message's From: field contains the address "b@domain.example" and an | |||
ASP query produces a "dkim=all" or "dkim=discardable" result, that | ADSP query produces a "dkim=all" or "dkim=discardable" result, that | |||
would mean that the message does not have a valid Author Signature. | would mean that the message does not have a valid Author Signature. | |||
Even though the message is signed by the same domain, its failure to | Even though the message is signed by the same domain, it fails to | |||
satisfy ASP could be problematic. | satisfy ADSP. | |||
3. Operation Overview | 3. Operation Overview | |||
Domain owners can publish Author Signing Practices via a query | Domain owners can publish ADSP information via a query mechanism such | |||
mechanism such as the Domain Name System; specific details are given | as the Domain Name System; specific details are given in Section 4.1. | |||
in Section 4.1. | ||||
Hosts can look up the Author Signing Practices of the domain(s) | Hosts can look up the ADSP information of the domain(s) specified by | |||
specified by the Author Address(es) as described in Section 4.2.2. | the Author Address(es) as described in Section 4.3. If a message has | |||
If a message has multiple Author Addresses the ASP lookups SHOULD be | multiple Author Addresses the ADSP lookups SHOULD be performed | |||
performed independently on each address. This standard does not | independently on each address. This standard does not address the | |||
address the process a host might use to combine the lookup results. | process a host might use to combine the lookup results. | |||
3.1. ASP Usage | 3.1. ADSP Applicability | |||
ADSP as defined in this document is bound to DNS. For this reason, | ||||
ADSP is applicable only to Author Domains with appropriate DNS | ||||
records (see Note below). The handling of other Author Domains is | ||||
outside the scope of this document. However, attackers may use such | ||||
domain names in a deliberate attempt to sidestep an organization's | ||||
ADSP policy statements. It is up to the ADSP verifier implementation | ||||
to return an appropriate error result for Author Domains outside the | ||||
scope of ADSP. | ||||
Note: The results from DNS queries that are intended to validate a | ||||
domain name unavoidably approximate the set of Author Domains that | ||||
can appear in legitimate email. For example, a DNS A record could | ||||
belong to a device that does not even have an email | ||||
implementation. It is up to the verifier to decide what degree of | ||||
approximation is acceptable. | ||||
3.2. ADSP Usage | ||||
Depending on the Author Domain(s) and the signatures in a message, a | Depending on the Author Domain(s) and the signatures in a message, a | |||
recipient gets varying amounts of useful information from each ASP | recipient gets varying amounts of useful information from each ADSP | |||
lookup. | lookup. | |||
o If a message has no Valid Signature, the ASP result is directly | o If a message has no Valid Signature, the ADSP result is directly | |||
relevant to the message. | relevant to the message. | |||
o If a message has a Valid Signature from an Author Domain, ASP | o If a message has a Valid Signature from an Author Domain, ADSP | |||
provides no benefit relative to that domain since the message is | provides no benefit relative to that domain since the message is | |||
already known to be compliant with any possible ASP for that | already known to be compliant with any possible ADSP for that | |||
domain. | domain. | |||
o If a message has a Valid Signature from a domain other than an | o If a message has a Valid Signature from a domain other than an | |||
Author Domain, the receiver can use both the Signature and the ASP | Author Domain, the receiver can use both the Signature and the | |||
result in its evaluation of the message. | ADSP result in its evaluation of the message. | |||
3.2. ASP Results | 3.3. ADSP Results | |||
An Author Signing Practices lookup for an Author Address produces one | An ADSP lookup for an Author Address produces one of four possible | |||
of four possible results: | results: | |||
o Messages from this domain might or might not have an author | o Messages from this domain might or might not have an author | |||
signature. This is the default if the domain exists in the DNS | signature. This is the default if the domain exists in the DNS | |||
but no record is found. | but no record is found. | |||
o All messages from this domain are signed. | o All messages from this domain are signed. | |||
o All messages from this domain are signed and discardable. | o All messages from this domain are signed and discardable. | |||
o The domain does not exist. | o The domain is not a valid mail 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 | ADSP records are published using the DNS TXT resource record type. | |||
resource record type. | ||||
NON-NORMATIVE DISCUSSION [to be removed before publication]: There | ||||
has been considerable discussion on the DKIM WG mailing list | ||||
regarding the relative advantages of TXT and a new resource record | ||||
(RR) type. Read the archive for details. | ||||
The RDATA for ASP resource records is textual in format, with | The RDATA for ADSP resource records is textual in format, with | |||
specific syntax and semantics relating to their role in describing | specific syntax and semantics relating to their role in describing | |||
Author Signing Practices. The "Tag=Value List" syntax described in | ADSP. The "Tag=Value List" syntax described in section 3.2 of | |||
section 3.2 of [RFC4871] is used. Records not in compliance with | [RFC4871] is used. Records not in compliance with that syntax or the | |||
that syntax or the syntax of individual tags described in Section 4.3 | syntax of individual tags described in Section 4.3 MUST be ignored | |||
MUST be ignored (considered equivalent to a NODATA result) for | (considered equivalent to a NODATA result) for purposes of ADSP, | |||
purposes of ASP, although they MAY cause the logging of warning | although they MAY cause the logging of warning messages via an | |||
messages via an appropriate system logging mechanism. If the RDATA | appropriate system logging mechanism. If the RDATA contains multiple | |||
contains multiple character strings, the strings are logically | character strings, the strings are logically concatenated with no | |||
concatenated with no delimiters between the strings. | delimiters between the strings. | |||
The ASP record for a domain is published at a location in the | The ADSP record for a domain is published at a location in the | |||
domain's DNS hierarchy prefixed by _asp._domainkey.; e.g., the ASP | domain's DNS hierarchy prefixed by _adsp._domainkey.; e.g., the ADSP | |||
record for example.com would be a TXT record that is published at | record for example.com would be a TXT record that is published at | |||
"_asp._domainkey.example.com". A domain MUST NOT publish more than | "_adsp._domainkey.example.com". A domain MUST NOT publish more than | |||
one ASP record; the semantics of an ASP lookup that returns multiple | one ADSP record; the semantics of an ADSP lookup that returns | |||
ASP records for a single domain are undefined. (Note that | multiple ADSP records for a single domain are undefined. (Note that | |||
example.com and mail.example.com are different domains.) | example.com and mail.example.com are different domains.) | |||
4.2. Publication of ASP Records | 4.2. Publication of ADSP Records | |||
Author Signing Practices are intended to apply to all mail sent from | ||||
the domain of an Alleged Author. In order to ensure that ASP applies | ||||
to any hosts within that domain (e.g., www.example.com, | ||||
ftp.example.com.) the ASP lookup algorithm looks up one level in the | ||||
domain tree. For example, mail signed by www.example.com could be | ||||
covered by the ASP record for example.com. This avoids the need to | ||||
include an ASP record for every name within a given domain. | ||||
Normally, a domain expressing Author Signing Practices will want to | ADSP is intended to apply to all mail sent using the domain name | |||
do so for both itself and all of its "descendants" (child domains at | string of an Alleged Author. | |||
all lower levels). Domains wishing to do so MUST publish ASP records | ||||
for the domain itself and any subdomains. | ||||
Wildcards within a domain publishing ASP records pose a particular | Wildcards within a domain publishing ADSP records pose a particular | |||
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 | |||
ASP 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]. | |||
Tags used in ASP records are described below. Unrecognized tags MUST | Tags used in ADSP records are described below. Unrecognized tags | |||
be ignored. In the ABNF below, the WSP token is imported from | MUST be ignored. In the ABNF below, the FWS token is imported from | |||
[RFC2822]. The ALPHA and DIGIT tokens are imported from [RFC5234]. | [RFC4871]. The ALPHA and DIGIT tokens are imported from [RFC5234]. | |||
dkim= Outbound signing practices for the domain (plain-text; | dkim= Outbound signing practices for the domain (plain-text; | |||
REQUIRED). Possible values are as follows: | REQUIRED). Possible values are as follows: | |||
unknown The domain might sign some or all email. | unknown The domain might sign some or all email. | |||
all All mail from the domain is signed with an Author Signature. | all All mail from the domain is signed with an Author | |||
Signature. | ||||
discardable All mail from the domain is signed with an Author | discardable All mail from the domain is signed with an Author | |||
Signature. Furthermore, if a message arrives without a valid | Signature. Furthermore, if a message arrives without a valid | |||
Author Signature due to modification in transit, submission via | Author Signature due to modification in transit, submission via | |||
a path without access to a signing key, or other reason, the | a path without access to a signing key, or other reason, the | |||
domain encourages the recipient(s) to discard it. | domain encourages the recipient(s) to discard it. | |||
ABNF: | ABNF: | |||
adsp-dkim-tag = %x64.6b.69.6d *FWS "=" *FWS | ||||
("unknown" / "all" / "discardable") | ||||
asp-dkim-tag = %x64.6b.69.6d *WSP "=" | 4.3. ADSP Lookup Procedure | |||
*WSP ("unknown" / "all" / "discardable") | ||||
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 signing practices apply only to the named domain, and not | ||||
to subdomains. | ||||
ABNF: | ||||
asp-t-tag = %x74 *WSP "=" *WSP { asp-t-tag-flag | ||||
0*( *WSP ":" *WSP asp-t-tag-flag ) | ||||
asp-t-tag-flag = "s" / hyphenated-word | ||||
; for future extension | ||||
hyphenated-word = ALPHA [ *(ALPHA / DIGIT / "-") | ||||
(ALPHA / DIGIT) ] | ||||
Unrecognized flags MUST be ignored. | ||||
4.2.2. Author Signing Practices Lookup Procedure | ||||
Hosts doing an ASP lookup MUST produce a result that is semantically | Hosts doing an ADSP lookup MUST produce a result that is semantically | |||
equivalent to applying the following steps in the order listed below. | equivalent to applying the following steps in the order listed below. | |||
In practice, several of these steps can be performed in parallel in | In practice, these steps can be performed in parallel in order to | |||
order to improve performance. However, implementations SHOULD avoid | improve performance. However, implementations SHOULD avoid doing | |||
doing unnecessary DNS lookups. For the purposes of this section a | unnecessary DNS lookups. | |||
"valid ASP record" is one that is both syntactically and semantically | ||||
correct; in particular, it matches the ABNF for a "tag-list" and | ||||
includes a defined "dkim=" tag. | ||||
1. _Fetch Named ASP Record._ The host MUST query DNS for a TXT | For the purposes of this section a "valid ADSP record" is one that is | |||
record corresponding to the Author Domain prefixed by | both syntactically and semantically correct; in particular, it | |||
"_asp._domainkey." (note the trailing dot). If the result of | matches the ABNF for a "tag-list" and includes a defined "dkim=" tag. | |||
this query is a "NOERROR" response with an answer which is a | ||||
valid ASP record, use that record; otherwise, continue to the | ||||
next step. | ||||
2. _Verify Domain Exists._ The host MUST perform a DNS query for a | Verify Domain Scope: An ADSP verifier implementation MUST determine | |||
record corresponding to the Author Domain (with no prefix). The | whether a given Author Domain is within scope for ADSP. Given the | |||
type of the query can be of any type, since this step is only to | background in Section 3.1 the verifier MUST decide which degree of | |||
determine if the domain itself exists in DNS. This query MAY be | over-approximation is acceptable. The verifier MUST return an | |||
done in parallel with the query made in step 2. If the result of | appropriate error result for Author Domains that are outside the | |||
this query is an "NXDOMAIN" error, the algorithm MUST terminate | scope of ADSP. | |||
with an appropriate error. | ||||
The host MUST perform a DNS query for a record corresponding to | ||||
the Author Domain (with no prefix). The type of the query can be | ||||
of any type, since this step is only to determine if the domain | ||||
itself exists in DNS. This query MAY be done in parallel with the | ||||
query to fetch the Named ADSP Record. If the result of this query | ||||
is that the Author domain does not exist in the DNS (often called | ||||
an "NXDOMAIN" error), the algorithm MUST terminate with an error | ||||
indicating that the domain is out of scope. | ||||
NON-NORMATIVE DISCUSSION: Any resource record type could be | NON-NORMATIVE DISCUSSION: Any resource record type could be | |||
used for this query since the existence of a resource record | used for this query since the existence of a resource record of | |||
of any type will prevent an "NXDOMAIN" error. MX is a | any type will prevent an "NXDOMAIN" error. MX is a reasonable | |||
reasonable choice for this purpose is because this record type | choice for this purpose because this record type is thought to | |||
is thought to be the most common for likely domains, and will | be the most common for domains used in e-mail, and will | |||
therefore result in a result which can be more readily cached | therefore produce a result which can be more readily cached | |||
than a negative result. | than a negative result. | |||
3. _Try Parent Domain._ The host MUST query DNS for a TXT record for | If the domain does exist, the verifier MAY make more extensive | |||
the immediate parent domain, prefixed with "_asp._domainkey." If | checks to verify the existence of the domain, such as the ones | |||
the result of this query is anything other than a "NOERROR" | described in Section 5 of [RFC2821]. If those checks indicate | |||
response with a valid ASP record, the algorithm terminates with a | that the Author domain does not exist for mail, e.g., the domain | |||
result indicating that no ASP record was present. If the ASP "t" | has no MX, A, or AAAA record, the verifier SHOULD terminate with | |||
tag exists in the response and any of the flags is "s" | an error indicating that the domain is out of scope. | |||
(indicating it does not apply to a subdomain), the algorithm also | ||||
terminates without finding an ASP record. Otherwise, use that | ||||
record. | ||||
If any of the queries involved in the Author Signing Practices Check | Fetch Named ADSP Record: The host MUST query DNS for a TXT record | |||
result in a "SERVFAIL" error response, the algorithm terminates | corresponding to the Author Domain prefixed by "_adsp._domainkey." | |||
without returning a result; possible actions include queuing the | (note the trailing dot). | |||
message or returning an SMTP error indicating a temporary failure. | ||||
5. IANA Considerations | If the result of this query is a "NOERROR" response with an answer | |||
which is a valid ADSP record, use that record, and the algorithm | ||||
terminates. | ||||
ASP introduces some new namespaces that have been registered with | If a query results in a "SERVFAIL" error response, the algorithm | |||
IANA. In all cases, new values are assigned only for values that | terminates without returning a result; possible actions include | |||
have been documented in a published RFC that has IETF Consensus | queuing the message or returning an SMTP error indicating a | |||
[RFC2434]. | temporary failure. | |||
INFORMATIVE NOTE [ to be removed before publication ]: RFC 4871 | 5. IANA Considerations | |||
defines a selector as a sub-domain, importing the term from RFC 2822. | ||||
A sub-domain starts with a letter or digit, hence names such as _asp | ||||
that start with an underscore cannot collide with valid selectors. | ||||
5.1. ASP Specification Tag Registry | ADSP adds the following namespaces to the IANA registry. In all | |||
cases, new values are assigned only for values that have been | ||||
documented in a published RFC that has IETF Consensus [RFC2434]. | ||||
An ASP record provides for a list of specification tags. IANA has | 5.1. ADSP Specification Tag Registry | |||
established the ASP Specification Tag Registry for specification tags | ||||
that can be used in ASP fields. | ||||
The initial entries in the registry comprise: | 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 entry in the registry is: | ||||
+------+-----------------+ | +------+-----------------+ | |||
| TYPE | REFERENCE | | | TYPE | REFERENCE | | |||
+------+-----------------+ | +------+-----------------+ | |||
| dkim | (this document) | | | dkim | (this document) | | |||
| t | (this document) | | ||||
+------+-----------------+ | +------+-----------------+ | |||
ADSP Specification Tag Registry Initial Values | ||||
ASP Specification Tag Registry Initial Values | 5.2. ADSP Outbound Signing Practices Registry | |||
5.2. ASP Outbound Signing Practices Registry | ||||
The "dkim=" tag spec, defined in Section 4.2.1, provides for a value | The "dkim=" tag spec, defined in Section 4.2.1, provides for a value | |||
specifying Outbound Signing Practices. IANA has established the ASP | specifying Outbound Signing Practices. IANA has established the ADSP | |||
Outbound Signing Practices Registry for Outbound Signing Practices. | Outbound Signing Practices Registry for Outbound Signing Practices. | |||
The initial entries in the registry comprise: | The initial entries in the registry comprise: | |||
+-------------+-----------------+ | +-------------+-----------------+ | |||
| TYPE | REFERENCE | | | TYPE | REFERENCE | | |||
+-------------+-----------------+ | +-------------+-----------------+ | |||
| unknown | (this document) | | | unknown | (this document) | | |||
| all | (this document) | | | all | (this document) | | |||
| discardable | (this document) | | | discardable | (this document) | | |||
+-------------+-----------------+ | +-------------+-----------------+ | |||
ADSP Outbound Signing Practices Registry Initial Values | ||||
ASP Outbound Signing Practices Registry Initial Values | ||||
5.3. ASP Flags Registry | ||||
The "t=" tag spec, defined in Section 4.2.1, provides for a value | ||||
specifying Flags. IANA has established the ASP Flags Registry for | ||||
ASP Flags. | ||||
The initial entries in the registry comprise: | ||||
+------+-----------------+ | ||||
| TYPE | REFERENCE | | ||||
+------+-----------------+ | ||||
| s | (this document) | | ||||
+------+-----------------+ | ||||
ASP Flags Registry Initial Values | ||||
6. Security Considerations | 6. Security Considerations | |||
Security considerations in the Author Signing Practices are mostly | Security considerations in the ADSP are mostly related to attempts on | |||
related to attempts on the part of malicious senders to represent | the part of malicious senders to represent themselves as authors for | |||
themselves as authors for whom they are not authorized to send mail, | whom they are not authorized to send mail, often in an attempt to | |||
often in an attempt to defraud either the recipient or an Alleged | defraud either the recipient or an Alleged Author. | |||
Author. | ||||
Additional security considerations regarding Author Signing Practices | Additional security considerations regarding Author Domain Signing | |||
are found in the DKIM threat analysis [RFC4686]. | Practices are found in the DKIM threat analysis [RFC4686]. | |||
6.1. ASP 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 authors that they | |||
already trust. Common examples include financial institutions with | already trust. Common examples include 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. | |||
Email abuse often seeks to exploit the name-recognition that | Email abuse often seeks to exploit a legitimate email author's name- | |||
recipients will have, for a legitimate email author, by using its | recognition among recipients, by using the author's domain name in | |||
domain name in the From: header field. Especially since many popular | the From: header field. Especially since many popular MUAs do not | |||
MUAs do not display the author's email address, there is no empirical | display the author's email address, there is no empirical evidence of | |||
evidence of the extent that this particular unauthorized use of a | the extent that this particular unauthorized use of a domain name | |||
domain name contributes to recipient deception or that eliminating it | contributes to recipient deception or that eliminating it will have | |||
will have significant effect. | significant effect. | |||
However, closing this exploit could facilitate some types of | However, closing this exploit could facilitate some types of | |||
optimized processing by receive-side message filtering engines, since | optimized processing by receive-side message filtering engines, since | |||
it could permit them to maintain higher-confidence assertions about | it could permit them to maintain higher-confidence assertions about | |||
From: header field uses of a domain, when the occurrence is | From: header field uses of a domain, when the occurrence is | |||
authorized. | authorized. | |||
Unauthorized uses of domain names occur elsewhere in messages, as do | Unauthorized uses of domain names occur elsewhere in messages, as do | |||
unauthorized uses of organizations' names. These attacks are outside | unauthorized uses of organizations' names. These attacks are outside | |||
the scope of this specification. | the scope of this specification. | |||
ASP does not provide any benefit--nor, indeed, have any effect at | ADSP does not provide any benefit--nor, indeed, have any effect at | |||
all--unless an external system acts upon the verdict, either by | all--unless an external system acts upon the verdict, either by | |||
treating the message differently during the delivery process or by | treating the message differently during the delivery process or by | |||
showing some indicator to the end recipient. Such a system is out of | showing some indicator to the end recipient. Such a system is out of | |||
scope for this specification. | scope for this specification. | |||
ASP Checkers perform up to three DNS lookups per Alleged Author | ADSP checkers may perform multiple DNS lookups per Alleged Author | |||
Domain. Since these lookups are driven by domain names in email | Domain. Since these lookups are driven by domain names in email | |||
message headers of possibly fraudulent email, legitimate ASP Checkers | message headers of possibly fraudulent email, legitimate ADSP | |||
can become participants in traffic multiplication attacks. | checkers can become participants in traffic multiplication attacks. | |||
6.2. DNS Attacks | 6.2. DNS Attacks | |||
An attacker might attack the DNS infrastructure in an attempt to | An attacker might attack the DNS infrastructure in an attempt to | |||
impersonate ASP records, in an attempt to influence a receiver's | impersonate ADSP records to influence a receiver's decision on how it | |||
decision on how it will handle mail. However, such an attacker is | will handle mail. However, such an attacker is more likely to attack | |||
more likely to attack at a higher level, e.g., redirecting A or MX | at a higher level, e.g., redirecting A or MX record lookups in order | |||
record lookups in order to capture traffic that was legitimately | to capture traffic that was legitimately intended for the target | |||
intended for the target domain. These DNS security issues are | domain. These DNS security issues are addressed by DNSSEC [RFC4033]. | |||
addressed by DNSSEC [RFC4033]. | ||||
Because ASP 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 ASP record is that | system, the default result in the absence of an ADSP record is that | |||
the domain does not sign all of its messages. It is therefore | the domain does not sign all of its messages. It is therefore | |||
important that the ASP 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. | |||
6.3. DNS Wildcards | 6.3. DNS Wildcards | |||
Wildcards within a domain publishing ASP records, including but not | If a domain contains wildcards, then any name that matches the | |||
limited to wildcard MX records, pose a particular problem. While | wildcard according to [RFC4592] is potentially a valid mail domain | |||
referencing the immediate parent domain allows the discovery of an | eligible for ADSP. It is possible to add a wildcard TXT record | |||
ASP record corresponding to an unintended immediate-child subdomain, | alongside a wildcard MX that will provide suitable ADSP records for | |||
wildcard records apply at multiple levels. For example, if there is | any domain chosen by an attacker, since if the wildcard synthesizes | |||
a wildcard MX record for "example.com", the domain | chosen-name.example.com IN MX, it will then also synthesize | |||
"foo.bar.example.com" can receive mail through the named mail | _adsp._domainkey.chosen-name.example.com IN TXT. However multiple | |||
exchanger. Conversely, the existence of the record makes it | wildcard TXT records produce an undefined ADSP result, which means | |||
impossible to tell whether "foo.bar.example.com" is a legitimate name | you cannot also publish both ADSP records and records for any other | |||
since a query for that name will not return an "NXDOMAIN" error. For | TXT-using protocol (such as SPF) for a wildcard domain. | |||
that reason, ASP coverage for subdomains of domains containing a | ||||
wildcard record is incomplete. | ||||
NON-NORMATIVE NOTE: Complete ASP coverage of domains containing (or | ||||
where any parent contains) wildcards generally cannot be provided by | ||||
standard DNS servers. | ||||
7. References | 7. References | |||
7.1. References - Normative | 7.1. References - Normative | |||
[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. | |||
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an | [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an | |||
IANA Considerations Section in RFCs", BCP 26, RFC 2434, | IANA Considerations Section in RFCs", BCP 26, RFC 2434, | |||
skipping to change at page 13, line 37 | skipping to change at page 11, line 40 | |||
[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 | |||
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, | ||||
April 2001. | ||||
[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 ASP. 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. | |||
Domain managers are advised to consider the ways that mail processing | Domain managers are advised to consider the ways that mail processing | |||
can modify messages in ways that will invalidate an existing DKIM | can modify messages in ways that will invalidate an existing DKIM | |||
signature, such as mailing lists, courtesy forwarders, and other | signature, 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 the modifications invalidate the DKIM signature, | In that case, if the modifications invalidate the DKIM signature, | |||
recipient hosts will consider the mail not to have an Author | recipient hosts will consider the mail not to have an Author | |||
Signature, even though the signature was present when the mail was | Signature, even though the signature was present when the mail was | |||
originally sent. | 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 Signature. | Author Signature. | |||
In this situation it might be appropriate to publish an ASP record | In this situation it might be appropriate to publish an ADSP record | |||
for the domain containing "all", depending on whether the users also | for the domain containing "all", depending on whether the users also | |||
send mail through other paths that do not apply an Author Signature. | send mail through other paths that do not apply an Author Signature. | |||
Such paths could include MTAs at hotels or hotspot networks used by | Such paths could include MTAs at hotels or hotspot networks used by | |||
travelling users, or web sites that provide "mail an article" | travelling users, or web sites that provide "mail an article" | |||
features. | features. | |||
A.2. Bulk Mailing Domains | A.2. Bulk Mailing Domains | |||
Another common configuration uses a domain solely for bulk or | Another common configuration uses a domain solely for bulk or | |||
broadcast mail, with no individual human users, again typically | broadcast mail, with no individual human users, again typically | |||
skipping to change at page 14, line 46 | skipping to change at page 13, line 5 | |||
bulk mail. In that case, the mailing provider needs access to a | bulk mail. In that case, the mailing provider needs access to a | |||
suitable signing key in order to apply an Author Signature. One | suitable signing key in order to apply an Author Signature. One | |||
possible route would be for the domain owner to generate the key and | possible route would be for the domain owner to generate the key and | |||
give it to the mailing provider. Another would be for the domain to | give it to the mailing provider. Another would be for the domain to | |||
delegate a subdomain to the mailing provider, for example, | delegate a subdomain to the mailing provider, for example, | |||
bigbank.example might delegate email.bigbank.example to such a | bigbank.example might delegate email.bigbank.example to such a | |||
provider. In that case, the provider can generate the keys and DKIM | provider. In that case, the provider can generate the keys and DKIM | |||
DNS records itself and use the subdomain in the Author address in the | DNS records itself and use the subdomain in the Author address in the | |||
mail. | mail. | |||
Regardless of the DNS and key management strategy chosen, whoever | ||||
maintains the DKIM records for the domain could also install an ADSP | ||||
record containing "all". | ||||
A.3. Bulk Mailing Domains with Discardable Mail | A.3. Bulk Mailing Domains with Discardable Mail | |||
In some cases, a domain might sign all its outgoing mail with an | In some cases, a domain might sign all of its outgoing mail with an | |||
Author Signature, but prefer that recipient systems discard mail | Author Signature, but prefer that recipient systems discard mail | |||
without a valid Author Signature to avoid confusion from mail sent | without a valid Author Signature to avoid confusion from mail sent | |||
from sources that do not apply an Author Signature. (This latter | from sources that do not apply an Author Signature. (This latter | |||
kind of mail is sometimes loosely called "forgeries".) In that case, | kind of mail is sometimes loosely called "forgeries".) In that case, | |||
it might be appropriate to publish an ASP record containing | it might be appropriate to publish an ADSP record containing | |||
"discardable". Note that a domain SHOULD NOT publish a "discardable" | "discardable". Note that a domain SHOULD NOT publish a "discardable" | |||
record if it wishes to maximize the likelihood that mail from the | record if it wishes to maximize the likelihood that mail from the | |||
domain is delivered, since it could cause some fraction of the mail | domain is delivered, since it could cause some fraction of the mail | |||
the domain sends to be discarded. | the domain sends to be discarded. | |||
As a special case, if a domain sends no mail at all, it can safely | ||||
publish a "discardable" ASP record, since any mail with an author | ||||
address in the domain is 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 or author domain, using that domain in | |||
RFC2822 From: or other headers. Due to the many and varied | the 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. | |||
A.5. Non-email Domains | ||||
If a domain sends no mail at all, it can safely publish a | ||||
"discardable" ADSP record, since any mail with an author address in | ||||
the domain is a forgery. | ||||
Appendix B. Acknowledgements | Appendix B. Acknowledgements | |||
This document greatly benefited from comments by Steve Atkins, Jon | This document greatly benefited from comments by Steve Atkins, Jon | |||
Callas, Dave Crocker, JD Falk, Arvel Hathcock, Ellen Siegel, Michael | Callas, Dave Crocker, JD Falk, Arvel Hathcock, Ellen Siegel, Michael | |||
Thomas, and Wietse Venema. | Thomas, and Wietse Venema. | |||
Appendix C. Change Log | Appendix C. Change Log | |||
*NOTE TO RFC EDITOR: This section may be removed upon publication of | *NOTE TO RFC EDITOR: This section may be removed upon publication of | |||
this document as an RFC.* | this document as an RFC.* | |||
C.1. Changes since -ietf-dkim-02 | C.1. Changes since -ietf-dkim-03 | |||
o Merge in more text from ASP draft. | o Name change for title and filename, to be ADSP | |||
o String changes throughout, to author Domain signing practices and | ||||
to aDsp. | ||||
o Added some keywords. | ||||
o Clarified comparison of local part and domain in Author Address. | ||||
o Streamlined the Abstract. | ||||
o Revised text of last bullet in Results list. | ||||
o Removed definitions not used in the document. | ||||
o Removed all specification details pertaining to sub-domains. | ||||
o Moved Lookup Procedure up one document level. | ||||
o Revised domain validity specification. Part in ADSP Usage in | ||||
Operations section, and part as it as first step in Lookup. | ||||
o Fixed xml for figures, including labeling ABNF with new xml2rfc | ||||
construct. | ||||
o Revised wildcard text. | ||||
o Removed 't' tag. | ||||
o Removed ADSP Flags Registry section. | ||||
o Changed ABNF use of whitespace from WSP back to FWS, for | ||||
consistency with dkim-base. | ||||
C.2. Changes since -ietf-dkim-02 | ||||
o Merge in more text from ADSP draft. | ||||
o Phrase actions as host's rather than checker. | o Phrase actions as host's rather than checker. | |||
o Explanatory description of i= matching. | o Explanatory description of i= matching. | |||
o Lookup procedure consistently refers to one ASP record per lookup. | o Lookup procedure consistently refers to one ADSP record per | |||
lookup. | ||||
o Update security section w/ language from W. Venema | o Update security section w/ language from W. Venema | |||
o Simplify imports of terms from other RFCs, add Local-part, 4234 -> | o Simplify imports of terms from other RFCs, add Local-part, 4234 -> | |||
5234. | 5234. | |||
o Add usage example appendix. | o Add usage example appendix. | |||
o Add IANA considerations. | o Add IANA considerations. | |||
o Update authors list | o Update authors list | |||
C.2. Changes since -ietf-dkim-ssp-01 | C.3. Changes since -ietf-dkim-ssp-01 | |||
o Reworded introduction for clarity. | o Reworded introduction for clarity. | |||
o Various definition clarifications. | o Various definition clarifications. | |||
o Changed names of practices to unknown, all, and discardable. | o Changed names of practices to unknown, all, and discardable. | |||
o Removed normative language mandating use of SSP in particular | o Removed normative language mandating use of SSP in particular | |||
situations (issue 1538). | situations (issue 1538). | |||
skipping to change at page 17, line 10 | skipping to change at page 16, line 15 | |||
o Introduced the concepts of "SSP Checker" and "Evaluator". | o Introduced the concepts of "SSP Checker" and "Evaluator". | |||
o Multiple author case now handled my separate invocations of SSP | o Multiple author case now handled my separate invocations of SSP | |||
checker by Evaluator (issue 1525). | checker by Evaluator (issue 1525). | |||
o Removed check to avoid querying top-level domains. | o Removed check to avoid querying top-level domains. | |||
o Changed ABNF use of whitespace from [FWS] to *WSP (partially | o Changed ABNF use of whitespace from [FWS] to *WSP (partially | |||
addresses issue 1543). | addresses issue 1543). | |||
C.3. Changes since -ietf-dkim-ssp-00 | C.4. Changes since -ietf-dkim-ssp-00 | |||
o Clarified Operation Overview and eliminated use of Legitimate as | o Clarified Operation Overview and eliminated use of Legitimate as | |||
the counterpart of Suspicious since the words have different | the counterpart of Suspicious since the words have different | |||
meanings. | meanings. | |||
o Improved discussion (courtesy of Arvel Hathcock) of the use of TXT | o Improved discussion (courtesy of Arvel Hathcock) of the use of TXT | |||
records in DNS vs. a new RR type. | records in DNS vs. a new RR type. | |||
o Clarified publication rules for multilevel names. | o Clarified publication rules for multilevel names. | |||
skipping to change at page 17, line 39 | skipping to change at page 16, line 44 | |||
o Added "handling" tag to express alleged sending domain's | o Added "handling" tag to express alleged sending domain's | |||
preference about handling of Suspicious messages. | preference about handling of Suspicious messages. | |||
o Clarified handling of SERVFAIL error in SSP check. | o Clarified handling of SERVFAIL error in SSP check. | |||
o Replaced "entity" with "domain", since with the removal of user- | o Replaced "entity" with "domain", since with the removal of user- | |||
granularity SSP, the only entities having sender signing policies | granularity SSP, the only entities having sender signing policies | |||
are domains. | are domains. | |||
C.4. Changes since -allman-ssp-02 | C.5. Changes since -allman-ssp-02 | |||
o Removed user-granularity SSP and u= tag. | o Removed user-granularity SSP and u= tag. | |||
o Replaced DKIMP resource record with a TXT record. | o Replaced DKIMP resource record with a TXT record. | |||
o Changed name of the primary tag from "p" to "dkim". | o Changed name of the primary tag from "p" to "dkim". | |||
o Replaced lookup algorithm with one which traverses upward at most | o Replaced lookup algorithm with one which traverses upward at most | |||
one level. | one level. | |||
o Added description of records to be published, and effect of | o Added description of records to be published, and effect of | |||
wildcard records within the domain, on SSP. | wildcard records within the domain, on SSP. | |||
C.5. Changes since -allman-ssp-01 | C.6. Changes since -allman-ssp-01 | |||
o Changed term "Sender Signing Policy" to "Sender Signing | o Changed term "Sender Signing Policy" to "Sender Signing | |||
Practices". | Practices". | |||
o Changed query methodology to use a separate DNS resource record | o Changed query methodology to use a separate DNS resource record | |||
type, DKIMP. | type, DKIMP. | |||
o Changed tag values from SPF-like symbols to words. | o Changed tag values from SPF-like symbols to words. | |||
o User level policies now default to that of the domain if not | o User level policies now default to that of the domain if not | |||
specified. | specified. | |||
o Removed the "Compliance" section since we're still not clear on | o Removed the "Compliance" section since we're still not clear on | |||
what goes here. | what goes here. | |||
o Changed the "parent domain" policy to only search up one level | o Changed the "parent domain" policy to only search up one level | |||
(assumes that subdomains will publish SSP records if appropriate). | (assumes that subdomains will publish SSP records if appropriate). | |||
o Added detailed description of SSP check procedure. | o Added detailed description of SSP check procedure. | |||
C.6. Changes since -allman-ssp-00 | C.7. Changes since -allman-ssp-00 | |||
From a "diff" perspective, the changes are extensive. Semantically, | From a "diff" perspective, the changes are extensive. Semantically, | |||
the changes are: | the changes are: | |||
o Added section on "Third-Party Signatures and Mailing Lists" | o Added section on "Third-Party Signatures and Mailing Lists" | |||
o Added "Compliance" (transferred from -base document). I'm not | o Added "Compliance" (transferred from -base document). I'm not | |||
clear on what needs to be done here. | clear on what needs to be done here. | |||
o Extensive restructuring. | o Extensive restructuring. | |||
skipping to change at page 20, line 44 | skipping to change at line 871 | |||
attempt made to obtain a general license or permission for the use of | attempt made to obtain a general license or permission for the use of | |||
such proprietary rights by implementers or users of this | such proprietary rights by implementers or users of this | |||
specification can be obtained from the IETF on-line IPR repository at | specification can be obtained from the IETF on-line IPR repository at | |||
http://www.ietf.org/ipr. | http://www.ietf.org/ipr. | |||
The IETF invites any interested party to bring to its attention any | The IETF invites any interested party to bring to its attention any | |||
copyrights, patents or patent applications, or other proprietary | copyrights, patents or patent applications, or other proprietary | |||
rights that may cover technology that may be required to implement | rights that may cover technology that may be required to implement | |||
this standard. Please address the information to the IETF at | this standard. Please address the information to the IETF at | |||
ietf-ipr@ietf.org. | ietf-ipr@ietf.org. | |||
Acknowledgment | ||||
Funding for the RFC Editor function is provided by the IETF | ||||
Administrative Support Activity (IASA). | ||||
End of changes. 90 change blocks. | ||||
297 lines changed or deleted | 296 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/ |