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