draft-ietf-dkim-ssp-03.txt   draft-otis-dkim-adsp-04.txt 
Network Working Group E. Allman DKIM Working Group D. Otis
Internet-Draft Sendmail, Inc. Internet-Draft Trend Micro, NSSG
Intended status: Standards Track J. Fenton Intended status: Standards Track June 25, 2008
Expires: August 26, 2008 Cisco Systems, Inc. Expires: December 27, 2008
M. Delany
Yahoo! Inc.
J. Levine
Taughannock Networks
February 23, 2008
DKIM Author Signing Practices (ASP) DKIM Author Domain Signing Practices (ADSP)
draft-ietf-dkim-ssp-03 draft-otis-dkim-adsp-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 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 August 26, 2008. This Internet-Draft will expire on December 27, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
DomainKeys Identified Mail (DKIM) defines a domain-level DomainKeys Identified Mail (DKIM) as described in [RFC4871], defines
authentication framework for email using public-key cryptography and a domain-level authentication framework for email to permit
key server technology to permit verification of the source and verification of the source and contents of messages. This document
contents of messages by either Mail Transport Agents (MTAs) or Mail specifies an adjunct mechanism to aid in assessing messages that lack
User Agents (MUAs). The primary DKIM protocol is described in valid DKIM signatures for domains used in the author's address. It
[RFC4871]. This document describes the records that authors' domains defines a record that can advertise the extent to which a domain
can use to advertise their practices for signing their outgoing mail, signs outgoing mail that is publicly exchanged on SMTP port 25, as
and how other hosts can access those records. described in [RFC2821]. Also, how other hosts can access those
records.
Advertisements, defined by this document, may also increase DKIM
signature expectations for messages received by Mail User Agents
(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 to be 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 strong assertions about the identity of the message
author.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Language and Terminology . . . . . . . . . . . . . . . . . . . 4 2. Language and Terminology . . . . . . . . . . . . . . . . . . . 4
2.1. Terms Imported from DKIM Signatures Specification . . . . 4 2.1. Terms Imported from DKIM Signatures Specification . . . . 4
2.2. Valid Signature . . . . . . . . . . . . . . . . . . . . . 5 2.2. Valid Signature . . . . . . . . . . . . . . . . . . . . . 5
2.3. Author Address . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Valid Author Signature . . . . . . . . . . . . . . . . . . 5
2.4. Author Domain . . . . . . . . . . . . . . . . . . . . . . 5 2.4. Key Domain . . . . . . . . . . . . . . . . . . . . . . . . 5
2.5. Alleged Author . . . . . . . . . . . . . . . . . . . . . . 5 2.5. Author Key Domain . . . . . . . . . . . . . . . . . . . . 5
2.6. Author Signing Practices . . . . . . . . . . . . . . . . . 5 2.6. Author Address . . . . . . . . . . . . . . . . . . . . . . 5
2.7. Author Signature . . . . . . . . . . . . . . . . . . . . . 5 2.7. Author Domain . . . . . . . . . . . . . . . . . . . . . . 5
2.8. Author Domain Signing Practices . . . . . . . . . . . . . 6
3. Operation Overview . . . . . . . . . . . . . . . . . . . . . . 6 3. Operation Overview . . . . . . . . . . . . . . . . . . . . . . 6
3.1. ASP Usage . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. ADSP Discovery Results Usage . . . . . . . . . . . . . . . 6
3.2. ASP Results . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. ADSP Discovery Results . . . . . . . . . . . . . . . . . . 6
4. Detailed Description . . . . . . . . . . . . . . . . . . . . . 7 4. Detailed Description . . . . . . . . . . . . . . . . . . . . . 7
4.1. DNS Representation . . . . . . . . . . . . . . . . . . . . 7 4.1. DNS Representation . . . . . . . . . . . . . . . . . . . . 7
4.2. Publication of ASP Records . . . . . . . . . . . . . . . . 7 4.2. Publication of ADSP Records . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5.1. ASP Specification Tag Registry . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
5.2. ASP Outbound Signing Practices Registry . . . . . . . . . 10 6.1. ADSP Threat Model . . . . . . . . . . . . . . . . . . . . 11
5.3. ASP Flags Registry . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6.1. ASP Threat Model . . . . . . . . . . . . . . . . . . . . . 11
6.2. DNS Attacks . . . . . . . . . . . . . . . . . . . . . . . 12 6.2. DNS Attacks . . . . . . . . . . . . . . . . . . . . . . . 12
6.3. DNS Wildcards . . . . . . . . . . . . . . . . . . . . . . 12 6.3. DNS Wildcards . . . . . . . . . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. References - Normative . . . . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . . . . 14 A.1. Single Location Domains . . . . . . . . . . . . . . . . . 14
A.2. Bulk Mailing Domains . . . . . . . . . . . . . . . . . . . 14 A.2. Bulk Mailing Domains . . . . . . . . . . . . . . . . . . . 15
A.3. Bulk Mailing Domains with Discardable Mail . . . . . . . . 14 A.3. Commonly Forged Transactional Messages . . . . . . . . . . 15
A.4. Third Party Senders . . . . . . . . . . . . . . . . . . . 15 A.4. Third Party Senders . . . . . . . . . . . . . . . . . . . 16
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 15 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 16
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 15 Appendix C. Update History . . . . . . . . . . . . . . . . . . . 16
C.1. Changes since -ietf-dkim-02 . . . . . . . . . . . . . . . 15 C.1. Changes to draft-otis-dkim-adsp-00 . . . . . . . . . . . . 16
C.2. Changes since -ietf-dkim-ssp-01 . . . . . . . . . . . . . 16 C.2. Changes to draft-otis-dkim-adsp-01 . . . . . . . . . . . . 16
C.3. Changes since -ietf-dkim-ssp-00 . . . . . . . . . . . . . 17 C.3. Changes to draft-otis-dkim-adsp-02 . . . . . . . . . . . . 16
C.4. Changes since -allman-ssp-02 . . . . . . . . . . . . . . . 17 C.4. Changes to draft-otis-dkim-adsp-03 . . . . . . . . . . . . 18
C.5. Changes since -allman-ssp-01 . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18
C.6. Changes since -allman-ssp-00 . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 20
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 Key Domain to
to claim responsibility for the introduction of a message into the claim responsibility for the introduction of a message. Receiving
mail stream. Message recipients can verify the signature by querying hosts can verify the signature by querying the Key Domain to retrieve
the signer's domain directly to retrieve the appropriate public key, the appropriate public key, and thereby confirming that a message has
and thereby confirm that the message was attested to by a party in been attested to by a party in possession of the private key and in
possession of the private key for the signing 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 will retain a valid signature, and that absence of
a priori indication of forgery. In fact, during early phases of a valid signature on a message is not an "a priori" indication of
deployment it is very 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 protect their brand name. It is desirable for decide to sign all of their outgoing mail, for example, to better
such domains to be able to advertise that fact to other hosts. This protect their brand name. It is desirable for such domains to be
is the topic of Author Signing Practices (ASP). able to advertise that fact to other hosts. This is the premise of
Author Domain Signing Practices (ADSP).
Hosts implementing this specification can inquire what Author Signing Receiving hosts implementing this specification ensure greater safety
Practices a domain advertises. This inquiry is called an Author by first inquiring into the validity of the SMTP domain before
Signing Practices check. attempting a series of transactions related to DKIM validations. 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 Signing Practices are given in The detailed requirements for Author Domain Signing Practices are
[RFC5016]. This document refers extensively to [RFC4871] and assumes given in [RFC5016]. This document refers extensively to [RFC4871]
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]
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,
o A "Signer" is the agent that signs a message, as defined in
section 2.1 of [RFC4871].
o A "Selector" specifies which of the keys published by a signing In addition, [RFC4871] requires that a valid signature having a
domain is to be queried, as defined in section 3.1 of [RFC4871]. restrictive local-part template, the key's "g=" tag and value, must
match against an undefined "signing address". The "signing address"
could be understood to be the email address associated with the
signature's "on behalf of" identity which would be the "i=" tag and
value or its default, but the benefit of this check is limited since
DKIM signatures are not normally displayed. This document seeks to
clearly define the "signing address" used in conjunction with a
restrictive key's local-part template as being the "Author Address".
Briefly,
o A "Local-part" is the part of an address preceding the @ sign, as o The "local-part" is the part of an address preceding the "@" sign,
defined in [RFC2822] and used in [RFC4871]. 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 message signature which correctly verifies
verifies using the procedure described in section 6.1 of [RFC4871]. using procedures described in section 6.1 of [RFC4871].
2.3. Author Address 2.3. Valid Author Signature
An "Author Address" is an email address in the From header field of a A "Valid Author Signature" is any message signature which correctly
message [RFC2822]. If the From header field contains multiple verifies using procedures described in section 6.1 of [RFC4871], and
addresses, the message has multiple Author Addresses. where the local-part template, the key "g=" tag and value, and the
Key Domain, match against the Author Address.
2.4. Author Domain 2.4. Key Domain
An "Author Domain" is everything to the right of the "@" in an Author The "Key Domain" is the domain listed in the "d=" tag of a Valid
Address (excluding the "@" itself). Signature.
2.5. Alleged Author 2.5. Author Key Domain
An "Alleged Author" is an Author Address of a message; it is The "Author Key Domain" is the domain listed in the "d=" tag of a
"alleged" because it has not yet been verified. Valid Author Signature that is at or above the Author Domain. The
Author Key Domain must match all of its domain components with that
of the Author Domain. When a referenced Key contains a "t=s" tag and
value, the Author Key Domain will contain the entire Author Domain
for the signature to be valid.
2.6. Author Signing Practices 2.6. Author Address
"Author Signing Practices" (or just "practices") consist of a An "Author Address" is an email address in the From header field of a
machine-readable record published by the domain of an Alleged Author message [RFC2822]. If the From header field contains multiple
which includes statements about the domain's practices with respect addresses, the message has multiple Author Addresses.
to mail it sends with its domain in the From: line.
2.7. Author Signature 2.7. Author Domain
An "Author Signature" is any Valid Signature where the identity of An "Author Domain" is determined by the entire right-hand-side of the
the user or agent on behalf of which the message is signed (listed in Author Address (the portion that is to the right of the "@",
the ""i="" tag or its default value from the ""d="" tag) matches an excluding the "@" itself).
Author Address in the message. When the identity of the user or
agent includes a Local-part, the identities match if the Local-parts
match and the domains match. Otherwise, the identities match if the
domains match.
For example, if a message has a Valid Signature, with the DKIM- 2.8. Author Domain Signing Practices
Signature field containing "i=a@domain.example", then domain.example
is asserting that it takes responsibility for the message. If the "Author Domain Signing Practices" (or just "practices") consist of a
message's From: field contains the address "b@domain.example" and an machine-readable record published at the "_adsp." subdomain of the
ASP query produces a "dkim=all" or "dkim=discardable" result, that Author Domain. The ADSP record includes statements about outgoing
would mean that the message does not have a valid Author Signature. mail practices for messages containing the Author Domain.
Even though the message is signed by the same domain, its failure to
satisfy ASP could be problematic.
3. Operation Overview 3. Operation Overview
Domain owners can publish Author Signing Practices via a query Domain owners can publish Author Domain Signing Practices via a
mechanism such as the Domain Name System; specific details are given distribution service, such as the Domain Name System; specific
in Section 4.1. details related to the use of DNS are given in Section 4.1.
Hosts can look up the Author Signing Practices of the domain(s) Hosts can obtain Author Domain Signing Practices of the domain(s)
specified by the Author Address(es) as described in Section 4.2.2. specified by the Author Domain as described in Section 4.2.2. If a
If a message has multiple Author Addresses the ASP lookups SHOULD be message has multiple Author Addresses, ADSP Discovery SHOULD be
performed independently on each address. This standard does not performed independently. This standard will not cover the
address the process a host might use to combine the lookup results. consolidation of combined ADSP Discovery results.
3.1. ASP Usage 3.1. ADSP Discovery Results Usage
Depending on the Author Domain(s) and the signatures in a message, a A receiving host might obtain varying amounts of useful information
recipient gets varying amounts of useful information from each ASP through ADSP Discovery. Such as:
lookup.
o If a message has no Valid Signature, the ASP result is directly o When a message has a Valid Author Signature, the ADSP Discovery
relevant to the message. result is of no benefit since the message is compliant with any
possible ADSP assertion.
o If a message has a Valid Signature from an Author Domain, ASP o When a message has a Valid Signature that is not also a Valid
provides no benefit relative to that domain since the message is Author Signature, the ADSP Discovery result, in conjunction with
already known to be compliant with any possible ASP for that the Key Domain of the Valid Signature, is directly relevant to
domain. message assessment.
o If a message has a Valid Signature from a domain other than an o When a message is without a Valid Signature, the ADSP Discovery
Author Domain, the receiver can use both the Signature and the ASP result at the Author Domain is directly relevant to message
result in its evaluation of the message. assessment.
3.2. ASP Results 3.2. ADSP Discovery Results
An Author Signing Practices lookup for an Author Address produces one Author Domain Signing Practices Discovery at an Author Domain provide
of four possible results: four possible results:
o Messages from this domain might or might not have an author o Message contains an Author Domain that does not advertise
signature. This is the default if the domain exists in the DNS practices.
but no record is found.
o All messages from this domain are signed. o Message contains an Author Domain that advertises practices
indicating they do not ensure messages are initially signed by an
Author Key Domain.
o All messages from this domain are signed and discardable. o Message contains an Author Domain that advertises practices
indicating they ensure messages are initially signed by an Author
Key Domain.
o The domain does not exist. o Message contains an Author Domain that advertises 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
regarding the relative advantages of TXT and a new resource record regarding the relative advantages of TXT and a new resource record
(RR) type. Read the archive for details. (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 Author Domain Signing Practices. The "Tag=Value List" syntax
section 3.2 of [RFC4871] is used. Records not in compliance with described in section 3.2 of [RFC4871] is to be used. Records not in
that syntax or the syntax of individual tags described in Section 4.3 compliance with that syntax or with the syntax of individual tags
MUST be ignored (considered equivalent to a NODATA result) for described in Section 4.3 MUST be ignored, although they MAY cause the
purposes of ASP, although they MAY cause the logging of warning logging of warning messages via an appropriate system logging
messages via an appropriate system logging mechanism. If the RDATA mechanism. If the RDATA contains multiple character strings, the
contains multiple character strings, the strings are logically strings are to be logically concatenated with no delimiters placed
concatenated with no delimiters between the strings. between the strings.
The ASP record for a domain is published at a location in the
domain's DNS hierarchy prefixed by _asp._domainkey.; e.g., the ASP
record for example.com would be a TXT record that is published at
"_asp._domainkey.example.com". A domain MUST NOT publish more than
one ASP record; the semantics of an ASP lookup that returns multiple
ASP records for a single domain are undefined. (Note that
example.com and mail.example.com are different domains.)
4.2. Publication of ASP Records The ADSP record for an Author Domain is published at a "_adsp."
subdomain directly below the Author Domain; e.g., the ADSP record for
"example.com" would be a TXT record that is published at
"_adsp.example.com". A domain MUST NOT publish more than one ADSP
record; the semantics of an ADSP transaction returning multiple ADSP
records for a single domain are undefined. (Note that "example.com"
and "mail.example.com" are different domains.)
Author Signing Practices are intended to apply to all mail sent from 4.2. Publication of ADSP Records
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 Author Domain Signing Practices are intended to apply to all mail
do so for both itself and all of its "descendants" (child domains at containing the Author Domain. As a defensive strategy against
all lower levels). Domains wishing to do so MUST publish ASP records subdomain spoofing, ADSP records can be placed at domains that might
for the domain itself and any subdomains. appear to support SMTP.
Wildcards within a domain publishing ASP records pose a particular Wildcards within a domain that is also publishing ADSP records will
problem. This is discussed in more detail in Section 6.3. not pose a 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]. Terms used to describe signing practices employ a
metaphor of a door to avoid connotations that might differ from
definitions given in this document.
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 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= Outbound signing practices for the domain (plain-text; dkim= practices (plain-text; REQUIRED). Possible values are as
REQUIRED). Possible values are as follows: follows:
unknown The domain might sign some or all email.
all All mail from the domain is signed with an Author Signature.
discardable All mail from the domain is signed with an Author
Signature. Furthermore, if a message arrives without a valid
Author Signature due to modification in transit, submission via
a path without access to a signing key, or other reason, the
domain encourages the recipient(s) to discard it.
ABNF:
asp-dkim-tag = %x64.6b.69.6d *WSP "=" OPEN (Default) The Author Domain practice permits unsigned
*WSP ("unknown" / "all" / "discardable") outbound mail.
t= Flags, represented as a colon-separated list of names (plain-text; CLOSED The Author Domain practice always initially signs mail
OPTIONAL, default is that no flags are set). Flag values are: containing the Author Domain by an Author Key Domain.
s The signing practices apply only to the named domain, and not LOCKED The Author Domain practice always initially signs mail
to subdomains. containing the Author Domain by an Author Key Domain.
Furthermore, when a message is received without a Valid Author
Signature, receiving hosts are requested to dismiss such
messages.
ABNF: ABNF:
asp-t-tag = %x74 *WSP "=" *WSP { asp-t-tag-flag adsp-dkim-tag = %x64.6b.69.6d *WSP "="
0*( *WSP ":" *WSP asp-t-tag-flag ) *WSP ("OPEN" / "CLOSED" / "LOCKED")
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 4.2.2. Author Signing Practices Discovery Procedure
Hosts doing an ASP lookup MUST produce a result that is semantically Hosts performing ADSP Discovery should first exclude SMTP clients
equivalent to applying the following steps in the order listed below. with a demonstrated history of abuse. Also, the transactions needed
In practice, several of these steps can be performed in parallel in for ADSP Discovery or DKIM signature validation should be subsequent
order to improve performance. However, implementations SHOULD avoid to some confirmation that the Author Domain might support SMTP. In
doing unnecessary DNS lookups. For the purposes of this section a addition, hosts may consider some domains to be exempt, such as Top
"valid ASP record" is one that is both syntactically and semantically Level Domains (TLDs) listed in [RFC2606], for example ".invalid".
correct; in particular, it matches the ABNF for a "tag-list" and [RFC2606] does not represent a comprehensive list of all possible
includes a defined "dkim=" tag. exempted domains which might also include ".local", therefore,
appending to a list of exempted domains may be required.
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
record corresponding to the Author Domain prefixed by is 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 _ADSP Discovery._ The host SHOULD query DNS for a TXT record
record corresponding to the Author Domain (with no prefix). The corresponding to the Author Domain prefixed by "_adsp." (note the
type of the query can be of any type, since this step is only to trailing dot). The results returned by this operation would be
determine if the domain itself exists in DNS. This query MAY be the value of the "dkim" tag or the value of "MISSING" when none
done in parallel with the query made in step 2. If the result of exist.
this query is an "NXDOMAIN" error, the algorithm MUST terminate
with an appropriate error.
NON-NORMATIVE DISCUSSION: Any resource record type could be NON-NORMATIVE DISCUSSION: Rather than placing ADSP records below the
used for this query since the existence of a resource record "_domainkey." prefix used by DKIM, "_adsp." prefixed to the Author
of any type will prevent an "NXDOMAIN" error. MX is a Domain reduces the number of DNS entities needed when ADSP records
reasonable choice for this purpose is because this record type are desired at every address record. Delegation of a domain at or
is thought to be the most common for likely domains, and will below "_domainkey." and at "_adsp." may be required when
therefore result in a result which can be more readily cached consolidating control of DNS entries related to DKIM.
than a negative result.
3. _Try Parent Domain._ The host MUST query DNS for a TXT record for When any of the DNS transactions involved in ADSP Discovery result in
the immediate parent domain, prefixed with "_asp._domainkey." If a temporary error condition, the algorithm terminates without
the result of this query is anything other than a "NOERROR" returning a result; possible actions include queuing the message or
response with a valid ASP record, the algorithm terminates with a returning an SMTP error indicating a temporary failure.
result indicating that no ASP record was present. If the ASP "t"
tag exists in the response and any of the flags is "s"
(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 NON-NORMATIVE NOTE: Within a DNS transaction, as defined by
result in a "SERVFAIL" error response, the algorithm terminates [RFC1034] section 5.2.2 and [RFC4034] section 3, when a CNAME is
without returning a result; possible actions include queuing the returned, the alias name is to be processed as if it were the
message or returning an SMTP error indicating a temporary failure. initial name. [RFC2181] section 10.3 makes an exception for
Exchange host names returned by MX records. An Exchange host name
must not return a CNAME.
5. IANA Considerations 5. IANA Considerations
ASP 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 ]: RFC 4871
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
An ASP record provides for a list of specification tags. IANA has
established the ASP Specification Tag Registry for specification tags
that can be used in ASP fields.
The initial entries in the registry comprise:
+------+-----------------+
| TYPE | REFERENCE |
+------+-----------------+
| dkim | (this document) |
| t | (this document) |
+------+-----------------+
ASP Specification Tag Registry Initial Values
5.2. ASP 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 ASP
Outbound Signing Practices Registry for Outbound Signing Practices.
The initial entries in the registry comprise:
+-------------+-----------------+ INFORMATIVE NOTE [to be removed before publication]: If at the time
| TYPE | REFERENCE | of publication no registry has been established or is planned for
+-------------+-----------------+ underscore prefixed names, this section may be removed.
| unknown | (this document) |
| all | (this document) |
| discardable | (this document) |
+-------------+-----------------+
ASP Outbound Signing Practices Registry Initial Values 6. Security Considerations
5.3. ASP Flags Registry Security considerations in the Author Domain Signing Practices mostly
relate to attempts on the part of malicious senders to represent
themselves as sending messages from the Author Domain for whom they
are not authorized to use in their message. This is often done in an
attempt to defraud recipients of the message.
The "t=" tag spec, defined in Section 4.2.1, provides for a value DKIM keys with a restrictive local-part template in the "g=" tag and
specifying Flags. IANA has established the ASP Flags Registry for value are likely to be employed for untrusted systems that are beyond
ASP Flags. the direct control of the Author Key Domain. As a result, additional
care should be taken when a restrictive local-part template does not
match against the Author Address. Signatures, where a restrictive
local-part key "g=" tag and value and the Key Domain do not match
against the Author Addresses, should be considered invalid.
The initial entries in the registry comprise: Signatures with restrictive local-part keys where the signing address
is not that of the Author Address will be deceptive when marked as
valid. Recipients are often unaware of the signature's "on behalf
of" identity that is not normally displayed. In addition, these keys
are prone to theft since they are also likely to be used by less
secure mobile users, for example.
+------+-----------------+ Signatures with DKIM keys lacking a restrictive local-part template
| TYPE | REFERENCE | are only safely added when the Author Key Domain is able to directly
+------+-----------------+ evaluate signed header fields and content. Recognition of directly
| s | (this document) | controlled signing improves security in several ways:
+------+-----------------+
ASP Flags Registry Initial Values Discerns potentially deceptive signatures independent of ADSP
Discovery.
6. Security Considerations Permits the accurate indication of on whose behalf the signature
was added, even when not on behalf of the Author Address.
Security considerations in the Author Signing Practices are mostly Permits the "on behalf of" identity to be derived from an account
related to attempts on the part of malicious senders to represent instead of being omitted when the Author Key Domain is unable or
themselves as authors for whom they are not authorized to send mail, unwilling to affirm the identity of the Author Address.
often in an attempt to defraud either the recipient or an Alleged
Author.
Additional security considerations regarding Author Signing Practices Permits the identity to track either the author or the account
are found in the DKIM threat analysis [RFC4686]. used. This ability can be useful to third-parties who are
attempting to isolate bot-net 0wned systems. In response to a
growing portion of the IP address space being blocked, bot-nets
increasingly send their mail through a provider's outbound server
after obtaining access to valid accounts.
6.1. ASP Threat Model Additional security considerations regarding Author Domain Signing
Practices are found in the DKIM threat analysis [RFC4686].
Email recipients often have a core set of content authors that they 6.1. ADSP Threat Model
already trust. Common examples include financial institutions with
which they have an existing relationship and Internet web transaction
sites with which they conduct business.
Email abuse often seeks to exploit the name-recognition that Email recipients often have a core set of Author Domains that they
recipients will have, for a legitimate email author, by using its trust. Common examples include those of financial institutions with
domain name in the From: header field. Especially since many popular which they have an existing relationship and Internet web commerce
MUAs do not display the author's email address, there is no empirical sites with which they conduct business. DKIM validation and ADSP
evidence of the extent that this particular unauthorized use of a Discovery results will not provide any benefit unless receiving hosts
domain name contributes to recipient deception or that eliminating it either treat the messages differently during delivery, or provide
will have significant effect. some indicator to the end recipient. Such email annotation is out of
scope for this document.
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 by just spoofing display-names, or
it could permit them to maintain higher-confidence assertions about by placing user local-parts above subdomains or cousin domains in the
From: header field uses of a domain, when the occurrence is From: header field. This problem is made worse by popular MUAs that
authorized. do not display actual email addresses. As a result, there is no
empirical evidence showing to what extent unauthorized use of a
domain name contributes to recipient deception, nor that its
elimination will provide a significant effect. Nevertheless, the
automated accrual of behavioural feedback that ignores invalid
identifiers better ensures that systematic confidence is retained for
trusted Author Key Domains.
Unauthorized uses of domain names occur elsewhere in messages, as do Training recipients to use automated folder placement could also help
unauthorized uses of organizations' names. These attacks are outside reduce deceptions that utilize domain look-alike and subdomain based
the scope of this specification. tactics. In addition, automated recognition facilitates optimized
processing by receiver-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 also outside the scope of this document.
ASP does not provide any benefit--nor, indeed, have any effect at The ADSP Discovery algorithm performs one DNS transaction per Author
all--unless an external system acts upon the verdict, either by Domain. Since this transaction, as well as the ones needed to
treating the message differently during the delivery process or by validate the DKIM signature, are driven by domain names in email
showing some indicator to the end recipient. Such a system is out of message headers of possibly fraudulent email, receiving hosts
scope for this specification. attempting ADSP Discovery and DKIM validation can become participants
in traffic multiplication attacks.
ASP Checkers perform up to three DNS lookups per Alleged Author These attacks often target servers consolidating and distributing
Domain. Since these lookups are driven by domain names in email behavioral information about bad-actor activities. Such attacks may
message headers of possibly fraudulent email, legitimate ASP Checkers dramatically impact the cost of offering the protective service. As
can become participants in traffic multiplication attacks. a result, a reduction in number of those offering consolidated
behavioral information places the remaining providers in greater
jeopardy of receiving a larger portion of the abuse.
6.2. DNS Attacks 6.2. DNS Attacks
An attacker might attack the DNS infrastructure in an attempt to An attack might be waged against DNS infrastructure in an attempt to
impersonate ASP records, in an attempt to influence a receiver's disable services dependent upon DNS. Such attacks could be made
decision on how it will handle mail. However, such an attacker is worse when receiving hosts employ ADSP Discovery and DKIM validation.
more likely to attack at a higher level, e.g., redirecting A or MX A goal to "First, do no harm" is increasingly difficult to achieve
record lookups in order to capture traffic that was legitimately when confronting massive bot-nets. For this reason, SMTP should
intended for the target domain. These DNS security issues are consider eventually making MX records mandatory for the acceptance of
public exchanges. The ADSP Discovery process is not expected to
impact the likelihood of an attacker being successful at poisoning
local DNS resolvers. In addition, such DNS security issues are
addressed by DNSSEC [RFC4033]. addressed by DNSSEC [RFC4033].
Because ASP operates within the framework of the legacy e-mail Although a steady attack may not cause a denial of service, it can
system, the default result in the absence of an ASP record is that consume significant resources related to "in the cloud" consolidation
the domain does not sign all of its messages. It is therefore and distribution of behavioral information. A typical strategy used
important that the ASP clients distinguish a DNS failure such as by bad actors employing bot-nets is to rapidly transition from an
"SERVFAIL" from other DNS errors so that appropriate actions can be active to a 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 attempted by individual hosts. There is some evidence
that there may be tens of millions of bot-net controlled systems in
the active state, while hundreds of millions appear dormant to
individual SMTP servers.
Consolidating and distributing behavioral information offers
receiving hosts a defensive tactic that can minimize the
effectiveness of the blitzkrieg or fast-flux tactic. Unfortunately,
often part of a bad-actor's strategy is to inundate behavioral
repositories with virtual identifiers. For DKIM, the signature's
identity, "i=" tag and value, and key selector, "s=" tag and value,
can be synthesized since wildcard domain support is possible, unlike
for the Key Domain "d=" tag and value, or the location of the ADSP
record.
Because ADSP operates within the framework of the legacy e-mail
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
expected to be signed by a Author Key Domain. It is therefore
important that the ADSP clients distinguish a DNS failure such as
"SERVFAIL" from other DNS errors, so that appropriate actions can be
taken. taken.
It is likely that DKIM's and ADSP's combined roles will be to prevent
deception when used in conjunction with automated folder placement of
domains considered trustworthy. To ensure message reception remains
viable for crucial systems when DNS fails, the IP addresses of
crucial SMTP clients should be white-listed. This will allow ADSP
and DKIM to be selectively bypassed during such events.
6.3. DNS Wildcards 6.3. DNS Wildcards
Wildcards within a domain publishing ASP records, including but not With the exception of wildcard MX records, wildcards within a domain
limited to wildcard MX records, pose a particular problem. While that also publish ADSP records do not pose a significant problem.
referencing the immediate parent domain allows the discovery of an Although referencing SMTP related records will not provide "NXDOMAIN"
ASP record corresponding to an unintended immediate-child subdomain, results when a domain contains a wildcard, SMTP discovery records,
wildcard records apply at multiple levels. For example, if there is such as MX or A records, still offer evidence of SMTP support.
a wildcard MX record for "example.com", the domain Whether AAAA records, absent MX or A records, can be considered
"foo.bar.example.com" can receive mail through the named mail evidence of SMTP support has not withstood widespread use of AAAA
exchanger. Conversely, the existence of the record makes it only servers.
impossible to tell whether "foo.bar.example.com" is a legitimate name
since a query for that name will not return an "NXDOMAIN" error. For
that reason, ASP coverage for subdomains of domains containing a
wildcard record is incomplete.
NON-NORMATIVE NOTE: Complete ASP coverage of domains containing (or NON-NORMATIVE NOTE: Complete ADSP coverage for all subdomains of a
where any parent contains) wildcards generally cannot be provided by domain remains possible. However, ADSP records would need to be
standard DNS servers. published at every subdomain containing A records, in addition to
subdomains containing MX records. When SMTP adopts an MX record
mandate for the acceptance of public exchanges, only then could
ADSP records be limited to subdomains containing the MX records.
This strategy would also shelter domains not publishing MX records
from the additional transactions associated with any number of
Author Addresses and DKIM signatures that might be generated per
message.
7. References 7. References
7.1. References - Normative 7.1. References - Normative
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
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.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
IANA Considerations Section in RFCs", BCP 26, RFC 2434, Specification", RFC 2181, July 1997.
October 1998.
[RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS
Names", BCP 32, RFC 2606, June 1999.
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
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.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005.
[RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys [RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys
Identified Mail (DKIM)", RFC 4686, September 2006. Identified Mail (DKIM)", RFC 4686, September 2006.
[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 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 Administrators are advised to consider the ways that mail processing
can modify messages in ways that will invalidate an existing DKIM can modify messages in a manner that will invalidate existing DKIM
signature, 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 the modifications invalidate the DKIM signature, In that case, if these modifications invalidate DKIM signatures,
recipient hosts will consider the mail not to have an Author receiving hosts will consider the mail not to have a Valid Author
Signature, even though the signature was present when the mail was Signature, even though one was present when the mail was originally
originally sent. 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 a "CLOSED" ADSP
for the domain containing "all", depending on whether the users also record for the Author Domain, depending on whether users also send
send mail through other paths that do not apply an Author Signature. mail through other paths that do not apply an Author Key Domain
Such paths could include MTAs at hotels or hotspot networks used by signature. Such paths could include MTAs at hotels or hotspot
travelling users, or web sites that provide "mail an article" networks used by travelling users, or web sites that provide "mail an
features. article" 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
sending all the mail through a single MTA or group of MTAs that can sending all the mail through a single MTA or group of MTAs that can
apply an Author Signature. In this case, the domain's management can apply an Author Key Domain signature. In this case, before
be confident that all of its outgoing mail will be sent through the publishing a "CLOSED" ADSP record, the domain's management should be
signing MTA. Lacking individual users, the domain is unlikely to confident that all of its outgoing mail will be sent through signing
MTAs. Because it lacks 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 often use specialist mailing providers to send their Domain owners often use specialist mailing providers to send their
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 Key Domain
possible route would be for the domain owner to generate the key and signature. One possible method would be for the Author Key Domain
give it to the mailing provider. Another would be for the domain to owner to exchange keys with the mailing provider. Another would be
delegate a subdomain to the mailing provider, for example, for the Author Key Domain to delegate a subdomain below the
bigbank.example might delegate email.bigbank.example to such a "_domainkey." label to the mailing provider. For example,
provider. In that case, the provider can generate the keys and DKIM "bigbank.example.com" might delegate
DNS records itself and use the subdomain in the Author address in the "esp-00._domainkey.bigbank.example.com" to such a provider. As a
mail. result, the provider could generate keys and DKIM DNS records itself
and thereby provide Author Key Domain signatures.
A.3. Bulk Mailing Domains with Discardable Mail 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 Signature, but prefer that recipient systems discard mail Author Key Domain signature, but prefer that receiving host systems
without a valid Author Signature to avoid confusion from mail sent dismiss mail without a valid Author Key Domain signature to avoid
from sources that do not apply an Author Signature. (This latter confusion with mail sent from fraudulent sources that are unable to
kind of mail is sometimes loosely called "forgeries".) In that case, apply an Author Key Domain signature. (This latter kind of mail is
it might be appropriate to publish an ASP record containing sometimes loosely called "forgeries".) In that case, it might be
"discardable". Note that a domain SHOULD NOT publish a "discardable" appropriate to publish a "LOCKED" ADSP record. Note that a domain
record if it wishes to maximize the likelihood that mail from the SHOULD NOT publish a "LOCKED" ADSP record when it wishes to maximize
domain is delivered, since it could cause some fraction of the mail the likelihood that its mail is delivered, since it could cause some
the domain sends 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 "discardable" ASP record, since any mail with an author publish a "LOCKED" ADSP record, since any mail with this Author
address in the 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 greatly benefited from comments by Steve Atkins, Jon This document was based upon the draft-ietf-dkim-ssp-003. Dave
Callas, Dave Crocker, JD Falk, Arvel Hathcock, Ellen Siegel, Michael Crocker, Frank Ellermann, and Charles Lindsey inputs were valuable.
Thomas, and Wietse Venema. However, inclusion of their names should not be misconstrued as an
endorsement of this draft. This draft is an individual submission
Appendix C. Change Log intended to illustrate a comprehensive solution that might help
foreclose protracted debate when there is otherwise general
*NOTE TO RFC EDITOR: This section may be removed upon publication of agreement.
this document as an RFC.*
C.1. Changes since -ietf-dkim-02
o Merge in more text from ASP draft.
o Phrase actions as host's rather than checker.
o Explanatory description of i= matching.
o Lookup procedure consistently refers to one ASP record per lookup.
o Update security section w/ language from W. Venema
o Simplify imports of terms from other RFCs, add Local-part, 4234 ->
5234.
o Add usage example appendix.
o Add IANA considerations.
o Update authors list
C.2. Changes since -ietf-dkim-ssp-01
o Reworded introduction for clarity.
o Various definition clarifications.
o Changed names of practices to unknown, all, and discardable.
o Removed normative language mandating use of SSP in particular
situations (issue 1538).
o Clarified possible confusion over handling of syntax errors.
o Removed normative language from Introduction (issue 1538).
o Changed "Originator" to "Author" throughout (issue 1529).
o Removed all references to Third-Party Signatures (issues 1512,
1521).
o Removed all mention of "Suspicious" (issues 1528, 1530).
o Removed "t=y" (testing) flag (issue 1540).
o Removed "handling" tag (issue 1513).
o Broke up the "Sender Signing Practices Check Procedure" into two
algorithms: fetching the SSP record and interpretation thereof
(issues 1531, 1535; partially addresses issue 1520).
Interpretation is now the responsibility of the Evaluator.
o Document restructuring for better flow and remove redundancies
(some may address issue 1523, but I'm not sure I understand that
issue completely; also issues 1532, 1537).
o Removed all mention of how this interacts with users, even though
it makes parts of the document harder to understand (issue 1526).
o Introduced the concepts of "SSP Checker" and "Evaluator".
o Multiple author case now handled my separate invocations of SSP
checker by Evaluator (issue 1525).
o Removed check to avoid querying top-level domains.
o Changed ABNF use of whitespace from [FWS] to *WSP (partially
addresses issue 1543).
C.3. Changes since -ietf-dkim-ssp-00
o Clarified Operation Overview and eliminated use of Legitimate as
the counterpart of Suspicious since the words have different
meanings.
o Improved discussion (courtesy of Arvel Hathcock) of the use of TXT
records in DNS vs. a new RR type.
o Clarified publication rules for multilevel names.
o Better description of overall record syntax, in particular that Appendix C. Update History
records with unknown tags are considered syntactically correct.
o Clarified Sender Signing Practices Check Procedure, primarily by C.1. Changes to draft-otis-dkim-adsp-00
use of new term Author Domain.
o Eliminated section "Third-Party Signatures and Mailing Lists" that o Conditioned Author Signing Practices Discovery Procedure SMTP
is better included in the DKIM overview document. verification step to be made only when an MX record had not been
found.
o Added "handling" tag to express alleged sending domain's C.2. Changes to draft-otis-dkim-adsp-01
preference about handling of Suspicious messages.
o Clarified handling of SERVFAIL error in SSP check. o Modified the Author Signing Practices Discovery Procedure to
better conform with terms in RFC2821. In addition, a note now
covers the issue of CNAMEs.
o Replaced "entity" with "domain", since with the removal of user- C.3. Changes to draft-otis-dkim-adsp-02
granularity SSP, the only entities having sender signing policies
are domains.
C.4. Changes since -allman-ssp-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 Removed user-granularity SSP and u= tag. o Included non retention of a valid signature and offered an
admonishment to first validate from domain in the introduction.
o Replaced DKIMP resource record with a TXT record. o Added a separate definition for Valid Author Signatures by
including the requirement the local-part template must match
against the author addresses.
o Changed name of the primary tag from "p" to "dkim". o Made a few minor changes to the Author Key Domain definition.
o Replaced lookup algorithm with one which traverses upward at most o Included the phrase "related to the use of DNS" to the operation
one level. Overview as well as expanding upon the term ADSP Discovery in
several places.
o Added description of records to be published, and effect of o Modified ADSP Usage to Discovery Results Usage. The information
wildcard records within the domain, on SSP. provided was reorganized from least to most useful.
C.5. Changes since -allman-ssp-01 o Modified the terms in ADSP Discovery Results to be consistent with
advertised practices to align more closely with Dave Crocker's
Abstract.
o Changed term "Sender Signing Policy" to "Sender Signing o The Record syntax now mentions the terms used are a metaphor for a
Practices". door, and the terms modified to be in closer alignment with the
abstract.
o Changed query methodology to use a separate DNS resource record o The ADSP Discovery procedure now warns about unlimited application
type, DKIMP. of this process, and suggests some domains may require exemption,
and introduces the term MISSING when no ADSP record is discovered.
o Changed tag values from SPF-like symbols to words. o The IANA considerations where shortened based upon the assumption
a registry may not be established for underscore prefixed TXT
records.
o User level policies now default to that of the domain if not o Change the beginning of the security section to clarify the domain
specified. and not the author identity is assured by DKIM and ADSP.
o Removed the "Compliance" section since we're still not clear on o Changed the wording related to the key "g=" parameter to be more
what goes here. consistent throughout the document.
o Changed the "parent domain" policy to only search up one level o Mention in the threat model annotation is required, but is out of
(assumes that subdomains will publish SSP records if appropriate). scope.
o Added detailed description of SSP check procedure. o Modified the paragraph that describes exploitation of trust to be
about the domain and not the author identity.
C.6. Changes since -allman-ssp-00 o Mention that the target of an attack is often directed to
behavioral information services.
From a "diff" perspective, the changes are extensive. Semantically, o Add paragraph describing the typical nature of bot-net behaviour,
the changes are: and how the DKIM "i=" represents a significant vulnerability for
the accrual of behavioral information.
o Added section on "Third-Party Signatures and Mailing Lists" o Add a sentence to highlight benefits using automatic folder
placement.
o Added "Compliance" (transferred from -base document). I'm not o Expanded the DNS wildcard section to generally describe what might
clear on what needs to be done here. be involved when validating the domain's support of SMTP.
o Extensive restructuring. C.4. Changes to draft-otis-dkim-adsp-03
Authors' Addresses o Clarify the definition of signing address when used in conjunction
with restrictive local-part templates by adding a paragraph to
Section 2.1.
Eric Allman o Modified the list in Section 3.2 to include the case where the
Sendmail, Inc. Author Domain has no ADSP record.
6475 Christie Ave, Suite 350
Emeryville, CA 94608
Phone: +1 510 594 5501 o Give examples in Section 4.2.2 regarding possibly exempt TLDs.
Email: eric+dkim@sendmail.org
Jim Fenton
Cisco Systems, Inc.
MS SJ-9/2
170 W. Tasman Drive
San Jose, CA 95134-1706
Phone: +1 408 526 5914 o Expand upon the recognition of direct versus indirect control of
Email: fenton@cisco.com the DKIM signing process, and how this relates to the use of the
"on behalf of" identity by adding two paragraphs to Section 6.
Mark Delany o Made several minor grammatical changes.
Yahoo! Inc.
701 First Avenue
Sunnyvale, CA 94089
Phone: +1 408 349 6831 Author's Address
Email: markd+dkim@yahoo-inc.com
John Levine Douglas Otis
Taughannock Networks Trend Micro, NSSG
PO Box 727 10101 N. De Anza Blvd
Trumansburg, NY 14886 Cupertino, CA 95014
USA
Phone: +1 831 480 2300 Phone: +1.408.257-1500
Email: standards@taugh.com Email: doug_otis@trendmicro.com
URI: http://www.taugh.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
 End of changes. 134 change blocks. 
558 lines changed or deleted 521 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/