draft-ietf-dkim-ssp-03.txt		draft-ietf-dkim-ssp-04.txt
	Network Working Group E. Allman		Network Working Group E. Allman
	Internet-Draft Sendmail, Inc.		Internet-Draft Sendmail, Inc.
	Intended status: Standards Track J. Fenton		Intended status: Standards Track J. Fenton
	Expires: August 26, 2008 Cisco Systems, Inc.		Expires: January 3, 2009 Cisco Systems, Inc.
	M. Delany		M. Delany
	Yahoo! Inc.		Yahoo! Inc.
	J. Levine		J. Levine
	Taughannock Networks		Taughannock Networks
	February 23, 2008		July 2, 2008
	DKIM Author Signing Practices (ASP)		DKIM Author Domain Signing Practices (ADSP)
	draft-ietf-dkim-ssp-03		draft-ietf-dkim-ssp-04
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 39		skipping to change at page 1, line 39
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on August 26, 2008.		This Internet-Draft will expire on January 3, 2009.
	Copyright Notice
	Copyright (C) The IETF Trust (2008).
	Abstract		Abstract
	DomainKeys Identified Mail (DKIM) defines a domain-level		DomainKeys Identified Mail (DKIM) defines a domain-level
	authentication framework for email using public-key cryptography and		authentication framework for email to permit verification of the
	key server technology to permit verification of the source and		source and contents of messages. This document specifies an adjunct
	contents of messages by either Mail Transport Agents (MTAs) or Mail		mechanism to aid in assessing messages that do not contain a DKIM
	User Agents (MUAs). The primary DKIM protocol is described in		signature for the domain used in the author's address. It defines a
	[RFC4871]. This document describes the records that authors' domains		record that can advertise whether they sign their outgoing mail, and
	can use to advertise their practices for signing their outgoing mail,		how other hosts can access those records.
	and how other hosts can access those records.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Language and Terminology . . . . . . . . . . . . . . . . . . . 4		2. Language and Terminology . . . . . . . . . . . . . . . . . . . 3
	2.1. Terms Imported from DKIM Signatures Specification . . . . 4		2.1. Terms Imported from DKIM Signatures Specification . . . . 3
	2.2. Valid Signature . . . . . . . . . . . . . . . . . . . . . 5		2.2. Valid Signature . . . . . . . . . . . . . . . . . . . . . 4
	2.3. Author Address . . . . . . . . . . . . . . . . . . . . . . 5		2.3. Author Address . . . . . . . . . . . . . . . . . . . . . . 4
	2.4. Author Domain . . . . . . . . . . . . . . . . . . . . . . 5		2.4. Author Domain . . . . . . . . . . . . . . . . . . . . . . 4
	2.5. Alleged Author . . . . . . . . . . . . . . . . . . . . . . 5		2.5. Alleged Author . . . . . . . . . . . . . . . . . . . . . . 4
	2.6. Author Signing Practices . . . . . . . . . . . . . . . . . 5		2.6. Author Domain Signing Practices . . . . . . . . . . . . . 4
	2.7. Author Signature . . . . . . . . . . . . . . . . . . . . . 5		2.7. Author Signature . . . . . . . . . . . . . . . . . . . . . 4
	3. Operation Overview . . . . . . . . . . . . . . . . . . . . . . 6		3. Operation Overview . . . . . . . . . . . . . . . . . . . . . . 5
	3.1. ASP Usage . . . . . . . . . . . . . . . . . . . . . . . . 6		3.1. ADSP Applicability . . . . . . . . . . . . . . . . . . . . 5
	3.2. ASP Results . . . . . . . . . . . . . . . . . . . . . . . 6		3.2. ADSP Usage . . . . . . . . . . . . . . . . . . . . . . . . 5
	4. Detailed Description . . . . . . . . . . . . . . . . . . . . . 7		3.3. ADSP Results . . . . . . . . . . . . . . . . . . . . . . . 6
	4.1. DNS Representation . . . . . . . . . . . . . . . . . . . . 7		4. Detailed Description . . . . . . . . . . . . . . . . . . . . . 6
	4.2. Publication of ASP Records . . . . . . . . . . . . . . . . 7		4.1. DNS Representation . . . . . . . . . . . . . . . . . . . . 6
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		4.2. Publication of ADSP Records . . . . . . . . . . . . . . . 6
	5.1. ASP Specification Tag Registry . . . . . . . . . . . . . . 10		4.3. ADSP Lookup Procedure . . . . . . . . . . . . . . . . . . 7
	5.2. ASP Outbound Signing Practices Registry . . . . . . . . . 10		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	5.3. ASP Flags Registry . . . . . . . . . . . . . . . . . . . . 11		5.1. ADSP Specification Tag Registry . . . . . . . . . . . . . 8
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 11		5.2. ADSP Outbound Signing Practices Registry . . . . . . . . . 9
	6.1. ASP Threat Model . . . . . . . . . . . . . . . . . . . . . 11		6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	6.2. DNS Attacks . . . . . . . . . . . . . . . . . . . . . . . 12		6.1. ADSP Threat Model . . . . . . . . . . . . . . . . . . . . 9
	6.3. DNS Wildcards . . . . . . . . . . . . . . . . . . . . . . 12		6.2. DNS Attacks . . . . . . . . . . . . . . . . . . . . . . . 10
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13		6.3. DNS Wildcards . . . . . . . . . . . . . . . . . . . . . . 10
	7.1. References - Normative . . . . . . . . . . . . . . . . . . 13		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	7.2. References - Informative . . . . . . . . . . . . . . . . . 13		7.1. References - Normative . . . . . . . . . . . . . . . . . . 11
	Appendix A. Usage Examples . . . . . . . . . . . . . . . . . . . 13		7.2. References - Informative . . . . . . . . . . . . . . . . . 11
	A.1. Single Location Domains . . . . . . . . . . . . . . . . . 14		Appendix A. Usage Examples . . . . . . . . . . . . . . . . . . . 11
	A.2. Bulk Mailing Domains . . . . . . . . . . . . . . . . . . . 14		A.1. Single Location Domains . . . . . . . . . . . . . . . . . 12
	A.3. Bulk Mailing Domains with Discardable Mail . . . . . . . . 14		A.2. Bulk Mailing Domains . . . . . . . . . . . . . . . . . . . 12
	A.4. Third Party Senders . . . . . . . . . . . . . . . . . . . 15		A.3. Bulk Mailing Domains with Discardable Mail . . . . . . . . 13
	Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 15		A.4. Third Party Senders . . . . . . . . . . . . . . . . . . . 13
	Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 15		A.5. Non-email Domains . . . . . . . . . . . . . . . . . . . . 13
	C.1. Changes since -ietf-dkim-02 . . . . . . . . . . . . . . . 15		Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 13
	C.2. Changes since -ietf-dkim-ssp-01 . . . . . . . . . . . . . 16		Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 13
	C.3. Changes since -ietf-dkim-ssp-00 . . . . . . . . . . . . . 17		C.1. Changes since -ietf-dkim-03 . . . . . . . . . . . . . . . 14
	C.4. Changes since -allman-ssp-02 . . . . . . . . . . . . . . . 17		C.2. Changes since -ietf-dkim-02 . . . . . . . . . . . . . . . 14
	C.5. Changes since -allman-ssp-01 . . . . . . . . . . . . . . . 18		C.3. Changes since -ietf-dkim-ssp-01 . . . . . . . . . . . . . 15
	C.6. Changes since -allman-ssp-00 . . . . . . . . . . . . . . . 18		C.4. Changes since -ietf-dkim-ssp-00 . . . . . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18		C.5. Changes since -allman-ssp-02 . . . . . . . . . . . . . . . 16
	Intellectual Property and Copyright Statements . . . . . . . . . . 20		C.6. Changes since -allman-ssp-01 . . . . . . . . . . . . . . . 17
			C.7. Changes since -allman-ssp-00 . . . . . . . . . . . . . . . 17
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
			Intellectual Property and Copyright Statements . . . . . . . . . . 19
	1. Introduction		1. Introduction
	DomainKeys Identified Mail (DKIM) defines a mechanism by which email		DomainKeys Identified Mail (DKIM) defines a mechanism by which email
	messages can be cryptographically signed, permitting a signing domain		messages can be cryptographically signed, permitting a signing domain
	to claim responsibility for the introduction of a message into the		to claim responsibility for the introduction of a message into the
	mail stream. Message recipients can verify the signature by querying		mail stream. Message recipients can verify the signature by querying
	the signer's domain directly to retrieve the appropriate public key,		the signer's domain directly to retrieve the appropriate public key,
	and thereby confirm that the message was attested to by a party in		and thereby confirm that the message was attested to by a party in
	possession of the private key for the signing domain.		possession of the private key for the signing domain.
	However, the legacy of the Internet is such that not all messages		However, the legacy of the Internet is such that not all messages
	will be signed, and the absence of a signature on a message is not an		will be signed, and the absence of a signature on a message is not an
	a priori indication of forgery. In fact, during early phases of		a priori indication of forgery. In fact, during early phases of
	deployment it is very likely that most messages will remain unsigned.		deployment it is very likely that most messages will remain unsigned.
	However, some domains might decide to sign all of their outgoing		However, some domains might decide to sign all of their outgoing
	mail, for example, to protect their brand name. It is desirable for		mail, for example, to protect their brand names. It is desirable for
	such domains to be able to advertise that fact to other hosts. This		such domains to be able to advertise that fact to other hosts. This
	is the topic of Author Signing Practices (ASP).		is the topic of Author Domain Signing Practices (ADSP).
	Hosts implementing this specification can inquire what Author Signing		Hosts implementing this specification can inquire what Author Signing
	Practices a domain advertises. This inquiry is called an Author		Practices a domain advertises. This inquiry is called an Author
	Signing Practices check.		Signing Practices check.
	The detailed requirements for Author Signing Practices are given in		The basic requirements for ADSP are given in [RFC5016]. This
	[RFC5016]. This document refers extensively to [RFC4871] and assumes		document refers extensively to [RFC4871] and assumes the reader is
	the reader is familiar with it.		familiar with it.
	Requirements Notation: The key words "MUST", "MUST NOT", "REQUIRED",		Requirements Notation: The key words "MUST", "MUST NOT",
	"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",		"REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
	"MAY", and "OPTIONAL" in this document are to be interpreted as		"RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
	described in [RFC2119]		interpreted as described in [RFC2119]
	2. Language and Terminology		2. Language and Terminology
	2.1. Terms Imported from DKIM Signatures Specification		2.1. Terms Imported from DKIM Signatures Specification
	Some terminology used herein is derived directly from [RFC4871]. In		Some terminology used herein is derived directly from [RFC4871]. In
	several cases, references in that document to Sender have been		several cases, references in that document to Sender have been
	changed to Author here, to emphasize the relationship to the Author		changed to Author here, to emphasize the relationship to the Author
	address(es) in the From: header field described in [RFC2822].		address(es) in the From: header field described in [RFC2822].
	Briefly,		Briefly,
	o A "Signer" is the agent that signs a message, as defined in		o A "Signer" is the agent that signs a message, as defined in
	section 2.1 of [RFC4871].		section 2.1 of [RFC4871].
	o A "Selector" specifies which of the keys published by a signing		o A "Local-part" is the part of an address preceding the @
	domain is to be queried, as defined in section 3.1 of [RFC4871].		character, as defined in [RFC2822] and used in [RFC4871].
	o A "Local-part" is the part of an address preceding the @ sign, as
	defined in [RFC2822] and used in [RFC4871].
	2.2. Valid Signature		2.2. Valid Signature
	A "Valid Signature" is any signature on a message which correctly		A "Valid Signature" is any signature on a message which correctly
	verifies using the procedure described in section 6.1 of [RFC4871].		verifies using the procedure described in section 6.1 of [RFC4871].
	2.3. Author Address		2.3. Author Address
	An "Author Address" is an email address in the From header field of a		An "Author Address" is an email address in the From header field of a
	message [RFC2822]. If the From header field contains multiple		message [RFC2822]. If the From header field contains multiple
	skipping to change at page 5, line 29		skipping to change at page 4, line 26
	2.4. Author Domain		2.4. Author Domain
	An "Author Domain" is everything to the right of the "@" in an Author		An "Author Domain" is everything to the right of the "@" in an Author
	Address (excluding the "@" itself).		Address (excluding the "@" itself).
	2.5. Alleged Author		2.5. Alleged Author
	An "Alleged Author" is an Author Address of a message; it is		An "Alleged Author" is an Author Address of a message; it is
	"alleged" because it has not yet been verified.		"alleged" because it has not yet been verified.
	2.6. Author Signing Practices		2.6. Author Domain Signing Practices
	"Author Signing Practices" (or just "practices") consist of a		"Author Domain Signing Practices" (or just "practices") consist of a
	machine-readable record published by the domain of an Alleged Author		machine-readable record published by the domain of an Alleged Author
	which includes statements about the domain's practices with respect		which includes statements about the domain's practices with respect
	to mail it sends with its domain in the From: line.		to mail it sends with its domain in the From: line.
	2.7. Author Signature		2.7. Author Signature
	An "Author Signature" is any Valid Signature where the identity of		An "Author Signature" is any Valid Signature where the identity of
	the user or agent on behalf of which the message is signed (listed in		the user or agent on behalf of which the message is signed (listed in
	the ""i="" tag or its default value from the ""d="" tag) matches an		the "i=" tag or its default value from the "d=" tag) matches an
	Author Address in the message. When the identity of the user or		Author Address in the message. When the identity of the user or
	agent includes a Local-part, the identities match if the Local-parts		agent includes a Local-part, the identities match if the Local-parts
	match and the domains match. Otherwise, the identities match if the		are the same string, and the domains are the same string. Otherwise,
	domains match.		the identities match if the domains are the same string. Following
			[RFC2821], Local-part comparisons are case sensitive, domain
			comparisons are case insensitive.
	For example, if a message has a Valid Signature, with the DKIM-		For example, if a message has a Valid Signature, with the DKIM-
	Signature field containing "i=a@domain.example", then domain.example		Signature field containing "i=a@domain.example", then domain.example
	is asserting that it takes responsibility for the message. If the		is asserting that it takes responsibility for the message. If the
	message's From: field contains the address "b@domain.example" and an		message's From: field contains the address "b@domain.example" and an
	ASP query produces a "dkim=all" or "dkim=discardable" result, that		ADSP query produces a "dkim=all" or "dkim=discardable" result, that
	would mean that the message does not have a valid Author Signature.		would mean that the message does not have a valid Author Signature.
	Even though the message is signed by the same domain, its failure to		Even though the message is signed by the same domain, it fails to
	satisfy ASP could be problematic.		satisfy ADSP.
	3. Operation Overview		3. Operation Overview
	Domain owners can publish Author Signing Practices via a query		Domain owners can publish ADSP information via a query mechanism such
	mechanism such as the Domain Name System; specific details are given		as the Domain Name System; specific details are given in Section 4.1.
	in Section 4.1.
	Hosts can look up the Author Signing Practices of the domain(s)		Hosts can look up the ADSP information of the domain(s) specified by
	specified by the Author Address(es) as described in Section 4.2.2.		the Author Address(es) as described in Section 4.3. If a message has
	If a message has multiple Author Addresses the ASP lookups SHOULD be		multiple Author Addresses the ADSP lookups SHOULD be performed
	performed independently on each address. This standard does not		independently on each address. This standard does not address the
	address the process a host might use to combine the lookup results.		process a host might use to combine the lookup results.
	3.1. ASP Usage		3.1. ADSP Applicability
			ADSP as defined in this document is bound to DNS. For this reason,
			ADSP is applicable only to Author Domains with appropriate DNS
			records (see Note below). The handling of other Author Domains is
			outside the scope of this document. However, attackers may use such
			domain names in a deliberate attempt to sidestep an organization's
			ADSP policy statements. It is up to the ADSP verifier implementation
			to return an appropriate error result for Author Domains outside the
			scope of ADSP.
			Note: The results from DNS queries that are intended to validate a
			domain name unavoidably approximate the set of Author Domains that
			can appear in legitimate email. For example, a DNS A record could
			belong to a device that does not even have an email
			implementation. It is up to the verifier to decide what degree of
			approximation is acceptable.
			3.2. ADSP Usage
	Depending on the Author Domain(s) and the signatures in a message, a		Depending on the Author Domain(s) and the signatures in a message, a
	recipient gets varying amounts of useful information from each ASP		recipient gets varying amounts of useful information from each ADSP
	lookup.		lookup.
	o If a message has no Valid Signature, the ASP result is directly		o If a message has no Valid Signature, the ADSP result is directly
	relevant to the message.		relevant to the message.
	o If a message has a Valid Signature from an Author Domain, ASP		o If a message has a Valid Signature from an Author Domain, ADSP
	provides no benefit relative to that domain since the message is		provides no benefit relative to that domain since the message is
	already known to be compliant with any possible ASP for that		already known to be compliant with any possible ADSP for that
	domain.		domain.
	o If a message has a Valid Signature from a domain other than an		o If a message has a Valid Signature from a domain other than an
	Author Domain, the receiver can use both the Signature and the ASP		Author Domain, the receiver can use both the Signature and the
	result in its evaluation of the message.		ADSP result in its evaluation of the message.
	3.2. ASP Results		3.3. ADSP Results
	An Author Signing Practices lookup for an Author Address produces one		An ADSP lookup for an Author Address produces one of four possible
	of four possible results:		results:
	o Messages from this domain might or might not have an author		o Messages from this domain might or might not have an author
	signature. This is the default if the domain exists in the DNS		signature. This is the default if the domain exists in the DNS
	but no record is found.		but no record is found.
	o All messages from this domain are signed.		o All messages from this domain are signed.
	o All messages from this domain are signed and discardable.		o All messages from this domain are signed and discardable.
	o The domain does not exist.		o The domain is not a valid mail domain.
	4. Detailed Description		4. Detailed Description
	4.1. DNS Representation		4.1. DNS Representation
	Author Signing Practices records are published using the DNS TXT		ADSP records are published using the DNS TXT resource record type.
	resource record type.
	NON-NORMATIVE DISCUSSION [to be removed before publication]: There
	has been considerable discussion on the DKIM WG mailing list
	regarding the relative advantages of TXT and a new resource record
	(RR) type. Read the archive for details.
	The RDATA for ASP resource records is textual in format, with		The RDATA for ADSP resource records is textual in format, with
	specific syntax and semantics relating to their role in describing		specific syntax and semantics relating to their role in describing
	Author Signing Practices. The "Tag=Value List" syntax described in		ADSP. The "Tag=Value List" syntax described in section 3.2 of
	section 3.2 of [RFC4871] is used. Records not in compliance with		[RFC4871] is used. Records not in compliance with that syntax or the
	that syntax or the syntax of individual tags described in Section 4.3		syntax of individual tags described in Section 4.3 MUST be ignored
	MUST be ignored (considered equivalent to a NODATA result) for		(considered equivalent to a NODATA result) for purposes of ADSP,
	purposes of ASP, although they MAY cause the logging of warning		although they MAY cause the logging of warning messages via an
	messages via an appropriate system logging mechanism. If the RDATA		appropriate system logging mechanism. If the RDATA contains multiple
	contains multiple character strings, the strings are logically		character strings, the strings are logically concatenated with no
	concatenated with no delimiters between the strings.		delimiters between the strings.
	The ASP record for a domain is published at a location in the		The ADSP record for a domain is published at a location in the
	domain's DNS hierarchy prefixed by _asp._domainkey.; e.g., the ASP		domain's DNS hierarchy prefixed by _adsp._domainkey.; e.g., the ADSP
	record for example.com would be a TXT record that is published at		record for example.com would be a TXT record that is published at
	"_asp._domainkey.example.com". A domain MUST NOT publish more than		"_adsp._domainkey.example.com". A domain MUST NOT publish more than
	one ASP record; the semantics of an ASP lookup that returns multiple		one ADSP record; the semantics of an ADSP lookup that returns
	ASP records for a single domain are undefined. (Note that		multiple ADSP records for a single domain are undefined. (Note that
	example.com and mail.example.com are different domains.)		example.com and mail.example.com are different domains.)
	4.2. Publication of ASP Records		4.2. Publication of ADSP Records
	Author Signing Practices are intended to apply to all mail sent from
	the domain of an Alleged Author. In order to ensure that ASP applies
	to any hosts within that domain (e.g., www.example.com,
	ftp.example.com.) the ASP lookup algorithm looks up one level in the
	domain tree. For example, mail signed by www.example.com could be
	covered by the ASP record for example.com. This avoids the need to
	include an ASP record for every name within a given domain.
	Normally, a domain expressing Author Signing Practices will want to		ADSP is intended to apply to all mail sent using the domain name
	do so for both itself and all of its "descendants" (child domains at		string of an Alleged Author.
	all lower levels). Domains wishing to do so MUST publish ASP records
	for the domain itself and any subdomains.
	Wildcards within a domain publishing ASP records pose a particular		Wildcards within a domain publishing ADSP records pose a particular
	problem. This is discussed in more detail in Section 6.3.		problem. This is discussed in more detail in Section 6.3.
	4.2.1. Record Syntax		4.2.1. Record Syntax
	ASP records use the "tag=value" syntax described in section 3.2 of		ADSP records use the "tag=value" syntax described in section 3.2 of
	[RFC4871].		[RFC4871].
	Tags used in ASP records are described below. Unrecognized tags MUST		Tags used in ADSP records are described below. Unrecognized tags
	be ignored. In the ABNF below, the WSP token is imported from		MUST be ignored. In the ABNF below, the FWS token is imported from
	[RFC2822]. The ALPHA and DIGIT tokens are imported from [RFC5234].		[RFC4871]. The ALPHA and DIGIT tokens are imported from [RFC5234].
	dkim= Outbound signing practices for the domain (plain-text;		dkim= Outbound signing practices for the domain (plain-text;
	REQUIRED). Possible values are as follows:		REQUIRED). Possible values are as follows:
	unknown The domain might sign some or all email.		unknown The domain might sign some or all email.
	all All mail from the domain is signed with an Author Signature.		all All mail from the domain is signed with an Author
			Signature.
	discardable All mail from the domain is signed with an Author		discardable All mail from the domain is signed with an Author
	Signature. Furthermore, if a message arrives without a valid		Signature. Furthermore, if a message arrives without a valid
	Author Signature due to modification in transit, submission via		Author Signature due to modification in transit, submission via
	a path without access to a signing key, or other reason, the		a path without access to a signing key, or other reason, the
	domain encourages the recipient(s) to discard it.		domain encourages the recipient(s) to discard it.
	ABNF:		ABNF:
			adsp-dkim-tag = %x64.6b.69.6d *FWS "=" *FWS
			("unknown" / "all" / "discardable")
	asp-dkim-tag = %x64.6b.69.6d *WSP "="		4.3. ADSP Lookup Procedure
	*WSP ("unknown" / "all" / "discardable")
	t= Flags, represented as a colon-separated list of names (plain-text;
	OPTIONAL, default is that no flags are set). Flag values are:
	s The signing practices apply only to the named domain, and not
	to subdomains.
	ABNF:
	asp-t-tag = %x74 *WSP "=" *WSP { asp-t-tag-flag
	0*( *WSP ":" *WSP asp-t-tag-flag )
	asp-t-tag-flag = "s" / hyphenated-word
	; for future extension
	hyphenated-word = ALPHA [ *(ALPHA / DIGIT / "-")
	(ALPHA / DIGIT) ]
	Unrecognized flags MUST be ignored.
	4.2.2. Author Signing Practices Lookup Procedure
	Hosts doing an ASP lookup MUST produce a result that is semantically		Hosts doing an ADSP lookup MUST produce a result that is semantically
	equivalent to applying the following steps in the order listed below.		equivalent to applying the following steps in the order listed below.
	In practice, several of these steps can be performed in parallel in		In practice, these steps can be performed in parallel in order to
	order to improve performance. However, implementations SHOULD avoid		improve performance. However, implementations SHOULD avoid doing
	doing unnecessary DNS lookups. For the purposes of this section a		unnecessary DNS lookups.
	"valid ASP record" is one that is both syntactically and semantically
	correct; in particular, it matches the ABNF for a "tag-list" and
	includes a defined "dkim=" tag.
	1. _Fetch Named ASP Record._ The host MUST query DNS for a TXT		For the purposes of this section a "valid ADSP record" is one that is
	record corresponding to the Author Domain prefixed by		both syntactically and semantically correct; in particular, it
	"_asp._domainkey." (note the trailing dot). If the result of		matches the ABNF for a "tag-list" and includes a defined "dkim=" tag.
	this query is a "NOERROR" response with an answer which is a
	valid ASP record, use that record; otherwise, continue to the
	next step.
	2. _Verify Domain Exists._ The host MUST perform a DNS query for a		Verify Domain Scope: An ADSP verifier implementation MUST determine
	record corresponding to the Author Domain (with no prefix). The		whether a given Author Domain is within scope for ADSP. Given the
	type of the query can be of any type, since this step is only to		background in Section 3.1 the verifier MUST decide which degree of
	determine if the domain itself exists in DNS. This query MAY be		over-approximation is acceptable. The verifier MUST return an
	done in parallel with the query made in step 2. If the result of		appropriate error result for Author Domains that are outside the
	this query is an "NXDOMAIN" error, the algorithm MUST terminate		scope of ADSP.
	with an appropriate error.
			The host MUST perform a DNS query for a record corresponding to
			the Author Domain (with no prefix). The type of the query can be
			of any type, since this step is only to determine if the domain
			itself exists in DNS. This query MAY be done in parallel with the
			query to fetch the Named ADSP Record. If the result of this query
			is that the Author domain does not exist in the DNS (often called
			an "NXDOMAIN" error), the algorithm MUST terminate with an error
			indicating that the domain is out of scope.
	NON-NORMATIVE DISCUSSION: Any resource record type could be		NON-NORMATIVE DISCUSSION: Any resource record type could be
	used for this query since the existence of a resource record		used for this query since the existence of a resource record of
	of any type will prevent an "NXDOMAIN" error. MX is a		any type will prevent an "NXDOMAIN" error. MX is a reasonable
	reasonable choice for this purpose is because this record type		choice for this purpose because this record type is thought to
	is thought to be the most common for likely domains, and will		be the most common for domains used in e-mail, and will
	therefore result in a result which can be more readily cached		therefore produce a result which can be more readily cached
	than a negative result.		than a negative result.
	3. _Try Parent Domain._ The host MUST query DNS for a TXT record for		If the domain does exist, the verifier MAY make more extensive
	the immediate parent domain, prefixed with "_asp._domainkey." If		checks to verify the existence of the domain, such as the ones
	the result of this query is anything other than a "NOERROR"		described in Section 5 of [RFC2821]. If those checks indicate
	response with a valid ASP record, the algorithm terminates with a		that the Author domain does not exist for mail, e.g., the domain
	result indicating that no ASP record was present. If the ASP "t"		has no MX, A, or AAAA record, the verifier SHOULD terminate with
	tag exists in the response and any of the flags is "s"		an error indicating that the domain is out of scope.
	(indicating it does not apply to a subdomain), the algorithm also
	terminates without finding an ASP record. Otherwise, use that
	record.
	If any of the queries involved in the Author Signing Practices Check		Fetch Named ADSP Record: The host MUST query DNS for a TXT record
	result in a "SERVFAIL" error response, the algorithm terminates		corresponding to the Author Domain prefixed by "_adsp._domainkey."
	without returning a result; possible actions include queuing the		(note the trailing dot).
	message or returning an SMTP error indicating a temporary failure.
	5. IANA Considerations		If the result of this query is a "NOERROR" response with an answer
			which is a valid ADSP record, use that record, and the algorithm
			terminates.
	ASP introduces some new namespaces that have been registered with		If a query results in a "SERVFAIL" error response, the algorithm
	IANA. In all cases, new values are assigned only for values that		terminates without returning a result; possible actions include
	have been documented in a published RFC that has IETF Consensus		queuing the message or returning an SMTP error indicating a
	[RFC2434].		temporary failure.
	INFORMATIVE NOTE [ to be removed before publication ]: RFC 4871		5. IANA Considerations
	defines a selector as a sub-domain, importing the term from RFC 2822.
	A sub-domain starts with a letter or digit, hence names such as _asp
	that start with an underscore cannot collide with valid selectors.
	5.1. ASP Specification Tag Registry		ADSP adds the following namespaces to the IANA registry. In all
			cases, new values are assigned only for values that have been
			documented in a published RFC that has IETF Consensus [RFC2434].
	An ASP record provides for a list of specification tags. IANA has		5.1. ADSP Specification Tag Registry
	established the ASP Specification Tag Registry for specification tags
	that can be used in ASP fields.
	The initial entries in the registry comprise:		An ADSP record provides for a list of specification tags. IANA has
			established the ADSP Specification Tag Registry for specification
			tags that can be used in ADSP fields.
			The initial entry in the registry is:
	+------+-----------------+		+------+-----------------+
	| TYPE | REFERENCE |		| TYPE | REFERENCE |
	+------+-----------------+		+------+-----------------+
	| dkim | (this document) |		| dkim | (this document) |
	| t | (this document) |
	+------+-----------------+		+------+-----------------+
			ADSP Specification Tag Registry Initial Values
	ASP Specification Tag Registry Initial Values		5.2. ADSP Outbound Signing Practices Registry
	5.2. ASP Outbound Signing Practices Registry
	The "dkim=" tag spec, defined in Section 4.2.1, provides for a value		The "dkim=" tag spec, defined in Section 4.2.1, provides for a value
	specifying Outbound Signing Practices. IANA has established the ASP		specifying Outbound Signing Practices. IANA has established the ADSP
	Outbound Signing Practices Registry for Outbound Signing Practices.		Outbound Signing Practices Registry for Outbound Signing Practices.
	The initial entries in the registry comprise:		The initial entries in the registry comprise:
	+-------------+-----------------+		+-------------+-----------------+
	| TYPE | REFERENCE |		| TYPE | REFERENCE |
	+-------------+-----------------+		+-------------+-----------------+
	| unknown | (this document) |		| unknown | (this document) |
	| all | (this document) |		| all | (this document) |
	| discardable | (this document) |		| discardable | (this document) |
	+-------------+-----------------+		+-------------+-----------------+
			ADSP Outbound Signing Practices Registry Initial Values
	ASP Outbound Signing Practices Registry Initial Values
	5.3. ASP Flags Registry
	The "t=" tag spec, defined in Section 4.2.1, provides for a value
	specifying Flags. IANA has established the ASP Flags Registry for
	ASP Flags.
	The initial entries in the registry comprise:
	+------+-----------------+
	| TYPE | REFERENCE |
	+------+-----------------+
	| s | (this document) |
	+------+-----------------+
	ASP Flags Registry Initial Values
	6. Security Considerations		6. Security Considerations
	Security considerations in the Author Signing Practices are mostly		Security considerations in the ADSP are mostly related to attempts on
	related to attempts on the part of malicious senders to represent		the part of malicious senders to represent themselves as authors for
	themselves as authors for whom they are not authorized to send mail,		whom they are not authorized to send mail, often in an attempt to
	often in an attempt to defraud either the recipient or an Alleged		defraud either the recipient or an Alleged Author.
	Author.
	Additional security considerations regarding Author Signing Practices		Additional security considerations regarding Author Domain Signing
	are found in the DKIM threat analysis [RFC4686].		Practices are found in the DKIM threat analysis [RFC4686].
	6.1. ASP Threat Model		6.1. ADSP Threat Model