draft-ietf-dkim-ssp-01.txt		draft-ietf-dkim-ssp-02.txt
	DKIM Working Group E. Allman		DKIM Working Group E. Allman
	Internet-Draft Sendmail, Inc.		Internet-Draft Sendmail, Inc.
	Intended status: Standards Track M. Delany		Intended status: Standards Track M. Delany
	Expires: March 20, 2008 Yahoo! Inc.		Expires: August 4, 2008 Yahoo! Inc.
	J. Fenton		J. Fenton
	Cisco Systems, Inc.		Cisco Systems, Inc.
	September 17, 2007		February 1, 2008
	DKIM Sender Signing Practices		DKIM Sender Signing Practices
	draft-ietf-dkim-ssp-01		draft-ietf-dkim-ssp-02
	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 37		skipping to change at page 1, line 37
	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 March 20, 2008.		This Internet-Draft will expire on August 4, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		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 using public-key cryptography and
	key server technology to permit verification of the source and		key server technology to permit verification of the source and
	contents of messages by either Mail Transport Agents (MTAs) or Mail		contents of messages by either Mail Transport Agents (MTAs) or Mail
	User Agents (MUAs). The primary DKIM protocol is described in		User Agents (MUAs). The primary DKIM protocol is described in
	[RFC4871].		[RFC4871].
	This document describes the records that senders may use to advertise		This document describes the records that authors' domains can use to
	how they sign their outgoing mail, and how verifiers should access		advertise their practices regarding signing their outgoing mail, and
	and interpret those results.		how other hosts can access, parse and interpret those records.
	Requirements Language		Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	(Unresolved Issues/To Be Done)		(Unresolved Issues/To Be Done)
	Need to consider handling of multiple responses to a DNS query for		o Need to consider handling of multiple responses to a DNS query for
	the SSP record.		the SSP record.
			o Security Considerations needs a detailed examination.
			o IANA Considerations should be formalized (e.g., as in 4871).
			o Check over the references.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Language and Terminology . . . . . . . . . . . . . . . . . . . 5		2. Language and Terminology . . . . . . . . . . . . . . . . . . . 4
	2.1. Terms Imported from DKIM Signatures Specification . . . . 5		2.1. Terms Imported from DKIM Signatures Specification . . . . 5
	2.2. Valid Signature . . . . . . . . . . . . . . . . . . . . . 5		2.2. Evaluator . . . . . . . . . . . . . . . . . . . . . . . . 5
	2.3. Originator Address . . . . . . . . . . . . . . . . . . . . 5		2.3. SSP Checker . . . . . . . . . . . . . . . . . . . . . . . 5
	2.4. Originator Domain . . . . . . . . . . . . . . . . . . . . 6		2.4. Valid Signature . . . . . . . . . . . . . . . . . . . . . 5
	2.5. Alleged Signer . . . . . . . . . . . . . . . . . . . . . . 6		2.5. Alleged Author . . . . . . . . . . . . . . . . . . . . . . 5
	2.6. Alleged Originator . . . . . . . . . . . . . . . . . . . . 6		2.6. Author Address . . . . . . . . . . . . . . . . . . . . . . 6
	2.7. Sender Signing Practices . . . . . . . . . . . . . . . . . 6		2.7. Author Domain . . . . . . . . . . . . . . . . . . . . . . 6
	2.8. Originator Signature . . . . . . . . . . . . . . . . . . . 6		2.8. Author Signature . . . . . . . . . . . . . . . . . . . . . 6
	2.9. Suspicious . . . . . . . . . . . . . . . . . . . . . . . . 6		2.9. Sender Signing Practices Record . . . . . . . . . . . . . 6
	2.10. Third-Party Signature . . . . . . . . . . . . . . . . . . 7		3. Operational Description . . . . . . . . . . . . . . . . . . . 6
	2.11. Verifier Acceptable Third-Party Signature . . . . . . . . 7		3.1. Publication of SSP Records . . . . . . . . . . . . . . . . 6
	3. Operation Overview . . . . . . . . . . . . . . . . . . . . . . 7		3.2. Lookup of SSP Records . . . . . . . . . . . . . . . . . . 8
	4. Detailed Description . . . . . . . . . . . . . . . . . . . . . 8		3.3. SSP Record Syntax . . . . . . . . . . . . . . . . . . . . 9
	4.1. DNS Representation . . . . . . . . . . . . . . . . . . . . 8		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	4.2. Publication of SSP Records . . . . . . . . . . . . . . . . 9		5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	4.3. Record Syntax . . . . . . . . . . . . . . . . . . . . . . 10		5.1. DNS Attacks . . . . . . . . . . . . . . . . . . . . . . . 11
	4.4. Sender Signing Practices Check Procedure . . . . . . . . . 12		5.2. DNS Wildcards . . . . . . . . . . . . . . . . . . . . . . 11
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 13		6.1. Normative References . . . . . . . . . . . . . . . . . . . 12
	6.1. Fraudulent Sender Address . . . . . . . . . . . . . . . . 14		6.2. Informative References . . . . . . . . . . . . . . . . . . 12
	6.2. DNS Attacks . . . . . . . . . . . . . . . . . . . . . . . 14		Appendix A. Usage Examples (INFORMATIVE) . . . . . . . . . . . . 13
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14		A.1. Single Location Domains . . . . . . . . . . . . . . . . . 13
	7.1. Normative References . . . . . . . . . . . . . . . . . . . 14		A.2. Bulk Mailing Domains . . . . . . . . . . . . . . . . . . . 13
	7.2. Informative References . . . . . . . . . . . . . . . . . . 15		A.3. Bulk Mailing Domains with Discardable Mail . . . . . . . . 14
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15		A.4. Third Party Senders . . . . . . . . . . . . . . . . . . . 14
	Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 15		Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 14
	B.1. Changes since -ietf-dkim-ssp-00 . . . . . . . . . . . . . 15		Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 14
	B.2. Changes since -allman-ssp-02 . . . . . . . . . . . . . . . 16		C.1. Changes since -ietf-dkim-ssp-01 . . . . . . . . . . . . . 15
	B.3. Changes since -allman-ssp-01 . . . . . . . . . . . . . . . 16		C.2. Changes since -ietf-dkim-ssp-00 . . . . . . . . . . . . . 16
	B.4. Changes since -allman-ssp-00 . . . . . . . . . . . . . . . 16		C.3. Changes since -allman-ssp-02 . . . . . . . . . . . . . . . 16
			C.4. Changes since -allman-ssp-01 . . . . . . . . . . . . . . . 16
			C.5. Changes since -allman-ssp-00 . . . . . . . . . . . . . . . 17
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
	Intellectual Property and Copyright Statements . . . . . . . . . . 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 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. Therefore, the absence of a signature is not an a
	a priori indication of forgery. In fact, during early phases of		priori indication of forgery. In fact, during early phases of DKIM
	deployment it must be expected that most messages will remain		deployment it must be expected that most messages will remain
	unsigned. However, some domains may choose to sign all of their		unsigned. Nevertheless, some domains may find it highly desirable to
	outgoing mail, for example, to protect their brand name. It is		advertise that they sign all of their outgoing mail making the
	highly desirable for such domains to be able to advertise that fact		absence of a valid signature a potential indication of forgery.
	to verifiers, and that messages claiming to be from them that do not		Without a mechanism to do so, the benefits of DKIM are limited to
	have a valid signature are likely to be forgeries. This is the topic		cases in which a valid signature exists and cannot be extended to
	for sender signing practices.		cases in which signatures are missing or are invalid. Defining such
			a mechanism is the purpose of Sender Signing Practices (SSP).
	In the absence of a valid DKIM signature on behalf of the "From"		This specification focuses on information which is relevant in the
	address [RFC2822], message verifiers implementing this specification		absence of an acceptable signature. Expressions of signing practice
	MUST determine whether messages from that sender are expected to be		which require outside auditing are out of scope for this
	signed, and what signatures are acceptable. In particular, whether a		specification because they fall under the purview of reputation and
	domain signs all outbound email must be made available to the		accreditation. Sender Signing Practices can be extended in the
	verifier. Without such a mechanism, the benefit of message signing		future to include additional information that a receiver might use as
	techniques such as DKIM is limited since unsigned messages will		input to a processing decision.
	always need to be considered to be potentially legitimate. This
	determination is referred to as a Sender Signing Practices check.
	Conceivably, such expressions might be imagined to be extended in the		More specifically, this specification defines the SSP Checker, a
	future to include information about what hashing algorithms a domain		module that retrieves the SSP information for a given domain, and the
	uses, what kind of messages might be sent (e.g., bulk vs. personal		format of the data returned. An module called the Evaluator combines
	vs. transactional), etc. Such concerns are out of scope of this		information from DKIM signatures, SSP Checker results, and any other
	standard, because they can be expressed in the key record		data sources it cares to use in order to make a decision regarding
	("Selector") with which the signature is verified. In contrast, this		how the message should be processed. The Evaluator is explicitly out
	specification focuses on information which is relevant in the absence		of scope of this document, and is described herein in order to make
	of a valid signature. Expressions of signing practice which require		the limits of this specification clear.
	outside auditing are similarly out of scope for this specification
	because they fall under the purview of reputation and accreditation.
	The detailed requirements for Sender Signing Practices are given in		The detailed requirements for Sender Signing Practices are given in
	[I-D.ietf-dkim-ssp-requirements], which the protocol described in		[RFC5016], which the protocol described in this document attempts to
	this document attempts to satisfy. This document refers extensively		satisfy. This document refers extensively to [RFC4871], which should
	to [RFC4871], which should be read as a prerequisite to this		be read as a prerequisite to this document.
	document.
	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].		Some terminology used herein is derived directly from [RFC4871].
	Briefly,		Briefly,
	o A "Signer" is the agent that signs a message. In many cases it		o A "Signer" is the agent that signs a message. In many cases it
	will correspond closely with the original author of the message or		will correspond closely with the original author of the message or
	an agent working on the author's behalf.		an agent working on the author's behalf.
	o A "Verifier" is the agent that verifies a message by checking the		o "Selectors" describe the keys published by a signing domain.
	actual signature against the message itself and the public key		Signing domains may have multiple Selectors. Selectors subdivide
	published by the Alleged Signer. The Verifier also looks up the
	Sender Signing Practices published by the domain of the Originator
	Address if the message is not correctly signed by the Alleged
	Originator.
	o A "Selector" specifies which of the keys published by a signing
	domain should be queried. It is essentially a way of subdividing
	the address space to allow a single sending domain to publish		the address space to allow a single sending domain to publish
	multiple keys.		multiple keys.
	2.2. Valid Signature		o A "Verifier" is the agent that verifies a message by checking
			actual signature(s) in the message header against the message
	A "Valid Signature" is any signature on a message which correctly		itself using the public key published in the Selector referenced
	verifies using the procedure described in section 6.1 of [RFC4871].		by a given signature.
	2.3. Originator Address
	The "Originator Address" is the email address in the From header
	field of a message [RFC2822], or if and only if the From header field
	contains multiple addresses, the first address in the From header
	field.
	NON-NORMATIVE RATIONALE: The alternative option when there are
	multiple addresses in the From header field is to use the value of
	the Sender header field. This would be closer to the semantics
	indicated in [RFC2822] than using the first address in the From
	header field. However, the large number of deployed Mail User
	Agents that do not display the Sender header field value argues
	against that. Multiple addresses in the From header field are
	rare in real life.
	Even when there is only one address in the From header field, this
	address is chosen as the reference address for SSP lookups because
	it represents the author of the message and is more widely
	displayed by Mail User Agents as a result. The Sender header
	field frequently has other meanings.
	2.4. Originator Domain
	The "Originator Domain" is everything to the right of the "@" in the
	Originator Address (excluding the "@" itself).
	2.5. Alleged Signer
	An "Alleged Signer" is the identity of the signer claimed in a DKIM-
	Signature header field in a message received by a Verifier; it is
	"alleged" because it has not yet been verified.
	2.6. Alleged Originator
	An "Alleged Originator" is the Originator Address of a message
	received by a Verifier; it is "alleged" because it has not yet been
	verified.
	2.7. Sender Signing Practices		2.2. Evaluator
	"Sender Signing Practices" (or just "practices") consist of a		The "Evaluator" is the module that makes the ultimate decision on how
	machine-readable record published by the domain of the Alleged		an incoming message should be processed at a given site. In some
	Originator which includes information about whether or not that		cases it may be colocated with the Verifier. The Evaluator combines
	domain signs all of their email, and whether signatures from third		information from the DKIM signature(s) (if any), the output of the
	parties are sanctioned by the Alleged Originator.		SSP Checker, and any other information it cares to consult in order
			to make a processing decision about the message. The specification
			of the Evaluator is out of scope of this document.
	2.8. Originator Signature		2.3. SSP Checker
	An "Originator Signature" is any Valid Signature where the signing		The "SSP Checker" module performs the SSP queries on behalf of the
	address (listed in the "i=" tag if present, otherwise its default		Evaluator. It is the primary module defined by this document. The
	value, consisting of the null address, representing an unknown user,		input to the SSP Checker is an address extracted from the From header
	followed by "@", followed by the value of the "d=" tag) matches the		field of the message being evaluated; the output is either the Sender
	Originator Address. If the signing address does not include a local-		Signing Practices associated with that domain, or an error code.
	part, then only the domains must match; otherwise, the two addresses
	must be identical.
	2.9. Suspicious		2.4. Valid Signature
	Messages that do not contain a valid Originator Signature and which		A "Valid Signature" is any signature on a message which correctly
	are inconsistent with a Sender Signing Practices check (e.g., are		verifies using the procedure described in section 6.1 of [RFC4871].
	received without a Valid Signature and the sender's signing practices
	indicate all messages from the domain are signed) are referred to as
	"Suspicious". The handling of such messages is at the discretion of
	the Verifier or final recipient. "Suspicious" applies only to the
	DKIM evaluation of the message; a Verifier may decide the message
	should be accepted on the basis of other information beyond the scope
	of this document. Conversely, messages not deemed Suspicious may be
	rejected for other reasons.
	2.10. Third-Party Signature		2.5. Alleged Author
	A "Third-Party Signature" is a Valid Signature which is not an		An "Alleged Author" is the Author Address of a message received by an
	Originator Signature.		Evaluator; it is "alleged" because it has not yet been verified.
	2.11. Verifier Acceptable Third-Party Signature		2.6. Author Address
	A Verifier Acceptable Third-Party Signature is a Third-Party		The "Author Address" is an email address in the From header field of
	Signature that the Verifier is willing to accept as meaningful for		a message [RFC2822]. If the From header field contains multiple
	the message under consideration. The Verifier may use any criteria		addresses, the message has multiple Author Addresses, which may
	it deems appropriate for making this determination.		potentially cause the Evaluator to perform multiple SSP Checks for a
			given message.
	3. Operation Overview		2.7. Author Domain
	Sender Signing Practices checks MUST be based on the Originator		The "Author Domain" is everything to the right of the "@" in the
	Address. If the message contains a valid Originator Signature, no		Author Address (excluding the "@" itself).
	Sender Signing Practices check need be performed: the Verifier
	SHOULD NOT look up the Sender Signing Practices and the message MUST
	NOT be considered Suspicious.
	Verifiers checking messages that do not have at least one valid		2.8. Author Signature
	Originator Signature MUST perform a Sender Signing Practices check on
	the domain specified by the Originator Address as described in
	Section 4.4.
	A Sender Signing Practices check produces one of four possible		An "Author Signature" is any Valid Signature where the identity of
	results:		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
			Author Address in the message.
	1. Some messages from this domain are not signed; the message MUST		2.9. Sender Signing Practices Record
	NOT be considered Suspicious, even in the absence of a valid
	signature. This is the default.
	2. All messages from this domain are signed. Messages containing a		A "Sender Signing Practices Record" consists of a machine-readable
	Verifier Acceptable Third-Party Signature MUST NOT be considered		record published by the domain of an Alleged Author which includes
	Suspicious.		information on whether that domain signs all of their email, and
			related information. That record is defined in detail in section
			Section 3.3.
	NON-NORMATIVE RATIONALE: Third-party signatures, since they		3. Operational Description
	can potentially represent any domain, are considered more
	likely to be abused by attackers seeking to spoof a specific
	address. It may therefore be desirable for verifiers to apply
	other criteria outside the scope of this specification in
	deciding to accept a given third-party signature. For
	example, a list of known mailing list domains used by
	addresses served by the verifier might be specifically
	considered acceptable third-party signers.
	3. All valid messages from this domain are signed; the domain of the		The use of Sender Signing Practices consists of two parts:
	Alleged Originator requests that only messages with valid
	Originator Signatures be considered not Suspicious; Third-Party
	Signatures are irrelevant. This practice would typically be used
	by domains which send only transactional email (i.e., do not use
	mailing lists and such that are likely to break signatures) and
	which wish to emphasize security over deliverability of their
	messages. In the absence of a valid Originator Signature, the
	message MUST be considered Suspicious.
	4. The domain does not exist; the message MUST be considered		Publication of SSP records by author domains wishing to do so
	Suspicious.
	If the Sender Signing Practices record for the domain does not exist		Lookup of SSP records by an SSP Checker under the direction of an
	but the domain does exist, Verifier systems MUST assume that some		Evaluator.
	messages from this domain are not signed and the message MUST NOT be
	considered Suspicious.
	4. Detailed Description		3.1. Publication of SSP Records
	4.1. DNS Representation		3.1.1. DNS Representation
	Sender Signing Practices records are published using the DNS TXT		Sender Signing Practices Records are published using the DNS "TXT"
	resource record type.		resource record type.
	NON-NORMATIVE DISCUSSION: There has been considerable discussion		*[[DRAFT DISCUSSION, TO BE DELETED BEFORE PUBLICATION*: There has
	on the DKIM WG mailing list regarding the relative advantages of		been considerable discussion on the DKIM WG mailing list regarding
	TXT and a new resource record (RR) type. Many DNS server and		the relative advantages of TXT and a new resource record (RR)
	resolver implementations are incapable of quickly and easily		type. Many DNS server and resolver implementations are incapable
	supporting new resource record types. For this reason, support of		of quickly and easily supporting new resource record types. For
	TXT records is required whether a new RR type is defined or not.		this reason, support of TXT records is required whether a new RR
	However, without a "flag day" on which SSP TXT record support is		type is defined or not. However, without a "flag day" on which
	to be withdrawn, such support is likely to continue indefinitely.		SSP TXT record support is to be withdrawn, such support is likely
	As a result, this specification defines no new RR type for SSP.		to continue indefinitely. As a result, this specification defines
			no new RR type for SSP.
	Another alternative proposed by P. Hallam-Baker is the publication		Another alternative proposed by P. Hallam-Baker is the publication
	of both a TXT record and, when implementations permit, a new RR,		of both a TXT record and, when implementations permit, a new RR,
	referred to as XPTR, which gives the location from which SSP and		referred to as XPTR, which gives the location from which SSP and
	other policy information relating to a give domain can be		other policy information relating to a give domain can be
	retrieved. This has the advantage of supporting a variety of		retrieved. This has the advantage of supporting a variety of
	policies in a scalable manner, with better handling of wildcards		policies in a scalable manner, with better handling of wildcards
	and centralized publication of policy records, with caching		and centralized publication of policy records, with caching
	advantages. However, the above implementation issues also apply		advantages. However, the above implementation issues also apply
	to XPTR, and an additional lookup is required to retrieve SSP via		to XPTR, and an additional lookup is required to retrieve SSP via
	the XPTR method. At the time of publication of this draft,		the XPTR method. At the time of publication of this draft,
	consensus on this proposal was unclear.		consensus on this proposal was unclear.*]]*
	The RDATA for SSP resource records is textual in format, with		The RDATA for SSP 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
	sender signing practices. The "Tag=Value List" syntax described in		sender signing practices. SSP records follow the tag-list syntax
	section 3.2 of [RFC4871] is used. Records not in compliance with		described in section 3.2 of [RFC4871], including the restriction on
	that syntax or the syntax of individual tags described in Section 4.3		duplicate tags, the use of white space, and case sensitivity.
	MUST be ignored (considered equivalent to a NODATA result) for		Records not in overall compliance with that syntax MUST be ignored
	purposes of message disposition, although they MAY cause the logging		(considered equivalent to a "NODATA" result), although they MAY cause
	of warning messages via an appropriate system logging mechanism.		the logging of warning messages via an appropriate system logging
			mechanism. All syntactically valid tags MUST be made available to
			the Evaluator.
	SSP records for a domain are published at a location in the domain's		3.1.2. Location of SSP Records
	DNS hierarchy prefixed by _ssp._domainkey; e.g., the SSP record for
	example.com would be a TXT record that is published at
	_ssp._domainkey.example.com.
	4.2. Publication of SSP Records		SSP records for a domain are published at a location in the domain's
			DNS hierarchy prefixed by "_ssp._domainkey"; e.g., the SSP record for
			"example.com" would be a "TXT" record that is published at
			"_ssp._domainkey.example.com".
	Sender Signing Practices are intended to apply to all mail sent from		Sender Signing Practices are intended to apply to all mail sent from
	the domain of an Alleged Originator, and to the greatest extent		the domain of an Alleged Author. In order to ensure that SSP applies
	possible, to all subdomains of that domain. There are several cases		to any hosts within that domain (e.g., www.example.com,
	that need to be considered in that regard:		ftp.example.com, etc.) the SSP lookup algorithm looks up one level in
			the domain tree. For example, mail signed by www.example.com may
	o The domain itself		optionally be covered by the SSP record for example.com. This
			prevents administrators from having to include an SSP record for
	o Subdomains which may or may not be used for email		every name within a given domain.
	o Hostnames which may or may not be used for email		Normally, a domain expressing Sender Signing Practices will want to
			do so for both itself and all of its "descendents" (child domains at
			all lower levels). Domains wishing to do so MUST publish SSP records
			for the domain itself and any subdomains.
	o Other named resource records in the domain		Wildcards within a domain publishing SSP records pose a particular
			problem. This is discussed in more detail in Section 5.2.
	o Multi-level examples of the above, e.g., a.b.example.com		3.2. Lookup of SSP Records
	o Non-existent cases, i.e., a subdomain or hostname that does not		NON-NORMATIVE NOTE: While the operation of the Evaluator is outside
	actually exist within the domain		the scope of this specification, it is generally not worthwhile for
			an Evaluator to request an SSP check when the results of that check
			will not affect the disposition of the message. Since the
			information provided by SSP is only relevant in the absence of valid
			Author Signature(s), there is little to be gained by performing an
			SSP check on domains corresponding to valid Author Signatures. SSP
			checks may also be unnecessary when the Evaluator has some other
			basis for deciding to process the message "normally", including, but
			not limited to, the presence of a DKIM signature that the Evaluator
			has some basis to trust sufficiently for this purpose.
	Normally, a domain expressing Sender Signing Practices will want to		3.2.1. SSP Checker Results
	do so for both itself and all of its "descendents" (child domains and
	hosts, at all lower levels). Domains wishing to do so MUST publish
	SSP records as follows:
	Publish an SSP record for the domain itself		A Sender Signing Practices check produces one of four possible
			results for use by the Evaluator:
	Publish an SSP record for any existing subdomain		1. The domain does not exist in DNS.
	Note that since the lookup algorithm described below references the		2. The domain does exist, but no SSP Record is present.
	immediate parent of the alleged originating domain, it is not
	necessary to publish SSP records for every single-level label within
	the domain. This has been done to relieve domain administrators of
	the burden of publishing an SSP record for every other record in the
	domain, which would be otherwise required.
	Wildcards within a domain, including but not limited to wildcard MX		3. The SSP Record exists, and that value is also returned.
	records, pose a particular problem. While referencing the immediate
	parent domain allows the discovery of an SSP record corresponding to
	an unintended immediate-child subdomain, wildcard records apply at
	multiple levels. For example, if there is a wildcard MX record for
	example.com, the domain foo.bar.example.com can receive mail through
	the named mail exchanger. Conversely, the existence of the record
	makes it impossible to tell whether foo.bar.example.com is a
	legitimate name since a query for that name will not return an
	NXDOMAIN error. For that reason, SSP coverage for subdomains of
	domains containing a wildcard record is incomplete.
	NON-NORMATIVE NOTE: Complete SSP coverage of domains containing		4. The DNS information could not be determined due to a transient
	(or where any parent contains) wildcards generally cannot be		error such as "SERVFAIL".
	guaranteed.
	4.3. Record Syntax		3.2.2. SSP Lookup Algorithm
	SSP records follow the "tag=value" syntax described in section 3.2 of		SSP Checkers doing an SSP lookup MUST produce a result that is
	[RFC4871]. The SSP record syntax is a tag-list as defined in that		semantically equivalent to applying the following steps in the order
	section, including the restriction on duplicate tags, the use of		listed below. In practice, several of these steps can be performed
	white space, and case sensitivity.		in parallel in order to improve performance. However,
			implementations SHOULD avoid doing unnecessary DNS lookups. For the
			purposes of this section a "valid SSP record" is one that is both
			syntactically and semantically correct; in particular, it must match
			the ABNF for a "tag-list" and must include a defined "dkim=" tag.
	Tags used in SSP records are as follows. Unrecognized tags MUST be		1. _Fetch Named SSP Record._ The SSP Checker MUST query DNS for a
	ignored. In the ABNF below, the FWS token is inherited from		TXT record corresponding to the Author Domain prefixed by
	[RFC2822] with the exclusion of obs-FWS. The ALPHA and DIGIT tokens		""_ssp._domainkey."" (note the trailing dot). If the result of
	are imported from [RFC4234].		this query is a "NOERROR" response with one or more answers which
			are valid SSP records, return that record for interpretation by
			the Evaluator; otherwise, continue to the next step.
	dkim= Outbound signing practices for the domain (plain-text;		2. _Verify Domain Exists._ The SSP Checker MUST perform a DNS query
	REQUIRED). Possible values are as follows:		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 made in step 2. If the result
			of this query is an "NXDOMAIN" error, the SSP Checker MUST return
			an appropriate error to the Evaluator and terminate the
			algorithm.
	unknown The domain may sign some or all email.		NON-NORMATIVE DISCUSSION: Any resource record type could be
			used for this query since the existence of a resource record
			of any type will prevent an "NXDOMAIN" error. "MX" is a
			reasonable choice for this purpose is because this record type
			is thought to be the most common for likely domains, and will
			therefore result in a result which can be more readily cached
			than a negative result.
	all All mail from the domain is signed; unsigned email MUST be		3. _Try Parent Domain._ The SSP Checker MUST query DNS for a TXT
	considered Suspicious. The domain may send messages through		record for the immediate parent domain, prefixed with
	agents that may modify and re-sign messages, so email signed		""_ssp._domainkey."" If the result of this query is anything
	with a Verifier Acceptable Third-Party Signature SHOULD NOT be		other than a "NOERROR" response with a valid SSP record, the
	considered Suspicious.		algorithm terminates returning a result indicating that no SSP
			record was present. If the SSP "t" tag exists in the response
			and any of the flags is "s" (indicating it should not apply to a
			subdomain), the SSP Checker MUST also return a "No SSP Record"
			result. Otherwise, return that record for interpretation by the
			Evaluator.
	strict All mail from the domain is signed; messages lacking a		If any of the queries involved in the Sender Signing Practices Check
	valid Originator Signature MUST be considered Suspicious. The		result in a "SERVFAIL" error response, the SSP Checker MUST return
	domain does not expect to send messages through agents that may		that information to the Evaluator; possible actions include queuing
	modify and re-sign messages.		the message or returning an SMTP error indicating a temporary
			failure.
	NON-NORMATIVE RATIONALE: Strict practices may be used by		3.3. SSP Record Syntax
	entities which send only transactional email to individual
	addresses and which are willing to accept the consequence of
	having some mail which is re-signed appear suspicious in
	return for additional control over their addresses. Strict
	practices may also be used by entities which do not send
	(and therefore do not sign) any email.
	ABNF:		SSP Records MUST match the "tag-list" syntax defined in [RFC4871].
			The specific tags used in SSP records are described below.
			Unrecognized tags MUST be ignored.
	ssp-dkim-tag = "dkim" [FWS] "=" [FWS] ("unknown" /		dkim= Outbound signing practices for the domain (plain-text;
	"all" / "strict")		REQUIRED). Possible values are as follows:
	handling= Non-compliant message handling request for the domain		unknown The domain may sign none, some, or all email.
	(plain-text; OPTIONAL). Possible values are as follows:
	process Messages which are Suspicious from this domain SHOULD be		all All mail from the domain is signed with an Author Signature.
	processed by the verifier, although the SSP failure MAY be
	considered in subsequent evaluation of the message. This is
	the default value.
	deny Messages which are Suspicious from this domain MAY be		discardable All mail from the domain is signed with an Author
	rejected, bounced, or otherwise not delivered at the option of		Signature. Furthermore, if a message arrives without a valid
	the verifier.		Author Signature due to modification in transit, submission via
			a path without access to a signing key, or other reason, the
			domain encourages the recipient(s) to discard it.
	NON-NORMATIVE EXPLANATION: The "deny" practice is intended		NON-NORMATIVE DISCUSSION: Sender signing practices of
	for use by domains that value security over deliverability.		"discardable" would be usually inappropriate for domains of end
	For example, a domain used by a financial institution to		users, because of the potential for mailing lists and similar
	send transactional email, which signs all of its messages,		agents to modify messages in such a way as to render the
	might consider their concern about phishing messages		signature invalid. Domains sending mail that is expected to
	purporting to come from their domain to be higher than their		pass with no significant modification to the recipient, such as
	concern about some some legitimate messages not being		domains sending only transactional messages, are appropriate
	delivered. The "handling=deny" practice allows them to		places to consider the publication of a "discardable" practice.
	express that concern in a way that can be acted upon by		See [RFC5016] section 5.3 and Appendix A for further
	verifiers, if they so choose.		discussion.
	ABNF:		ABNF:
	ssp-handling-tag = "handling" [FWS] "=" [FWS] ("process" /		ssp-dkim-tag = "dkim" *WSP "=" *WSP ("unknown" /
	"deny")		"all" / "discardable")
	t= Flags, represented as a colon-separated list of names (plain-text;		t= Flags, represented as a colon-separated list of names (plain-text;
	OPTIONAL, default is that no flags are set). Flag values are:		OPTIONAL, default is that no flags are set). Flag values are:
	y The domain is testing signing practices, and the Verifier
	SHOULD NOT consider a message suspicious based on the record.
	s The signing practices apply only to the named domain, and not		s The signing practices apply only to the named domain, and not
	to subdomains.		to subdomains.
	ABNF:		ABNF:
	ssp-t-tag = %x75 [FWS] "=" [FWS] ssp-t-tag-flag		ssp-t-tag = %x75 *WSP "=" *WSP ssp-t-tag-flag
	0*( [FWS] ":" [FWS] ssp-t-tag-flag )		0*( *WSP ":" *WSP ssp-t-tag-flag )
	ssp-t-tag-flag = "y" / "s" / hyphenated-word		ssp-t-tag-flag = "s" / hyphenated-word
	; for future extension		; for future extension
	hyphenated-word = ALPHA [ *(ALPHA / DIGIT / "-")		hyphenated-word = ALPHA [ *(ALPHA / DIGIT / "-")
	(ALPHA / DIGIT) ]		(ALPHA / DIGIT) ]
			Unrecognized flags MUST be included in the result that is provided
			to the Evaluator.
	Unrecognized flags MUST be ignored.		4. IANA Considerations
	4.4. Sender Signing Practices Check Procedure
	Verifiers MUST produce a result that is semantically equivalent to
	applying the following steps in the order listed. In practice,
	several of these steps can be performed in parallel in order to
	improve performance.
	1. If a valid Originator Signature exists, the message is not
	Suspicious, and the algorithm terminates.
	2. The Verifier MUST query DNS for a TXT record corresponding to
	the Originator Domain prefixed by "_ssp._domainkey.". If the
	result of this query is a NOERROR response with one or more
	answers which are syntactically-valid SSP responses, proceed to
	step 7.
	3. The Verifier MUST query DNS for an MX record corresponding to
	the Originator Domain (with no prefix). This query is made only
	to check the existence of the domain name and MAY be done in
	parallel with the query made in step 2. If the result of this
	query is an NXDOMAIN error, the message is Suspicious and the
	algorithm terminates.
	NON-NORMATIVE DISCUSSION: Any resource record type could be
	used for this query since the existence of a resource record
	of any type will prevent an NXDOMAIN error. The choice of MX
	for this purpose is because this record type is thought to be
	the most common for likely domains, and will therefore result
	in a result which can be more readily cached than a negative
	result.
	4. If the immediate parent of the Originator Domain is a top-level
	domain (a domain consisting of a single element such as "com",
	"us", or "jp"), then the message is not Suspicious (because no
	SSP record was found) and the algorithm terminates. The
	verifier MAY also compare the parent domain against a locally-
	maintained list of known address suffixes (e.g., .co.uk) and
	terminate the algorithm with a not Suspicious result if the
	parent domain matches an entry on the list.
	5. The Verifier MUST query DNS for a TXT record for the immediate
	parent domain, prefixed with "_ssp._domainkey." If the result
	of this query is a NOERROR response with one or more answers
	which are syntactically-valid SSP responses, proceed to step 6.
	Otherwise, the message is not Suspicious and the algorithm
	terminates.
	6. If the SSP "t" tag exists in the response and any of the flags
	is "s" (indicating it should not apply to a subdomain), the
	message is not Suspicious and the algorithm terminates.
	7. If the SSP "t" tag exists in the response and any of the flags
	is "y" (indicating testing), the message is not Suspicious and
	the algorithm terminates.
	8. If the value of the SSP "dkim" tag is "unknown", the message is
	not Suspicious and the algorithm terminates.
	9. If the value of the SSP "dkim" tag is "all", and one or more
	Verifier Acceptable Third-Party Signatures are present on the
	message, the message is not Suspicious and the algorithm
	terminates.
	10. The message is Suspicious and the algorithm terminates.
	If any of the queries involved in the Sender Signing Practices Check
	result in a SERVFAIL error response, the verifier MAY either queue
	the message or return an SMTP error indicating a temporary failure.
	5. IANA Considerations
	IANA is requested to create a "DKIM selector name" registry and to		IANA is requested to create a "DKIM selector name" registry and to
	reserve the selector name "_ssp" to avoid confusion between DKIM key		reserve the selector name ""_ssp"" to avoid confusion between DKIM
	records and SSP records.		key records and SSP records.
	6. Security Considerations		*<<< Needs to be updated to be more complete; see 4871 for examples
			>>>*
			5. Security Considerations
	Security considerations in the Sender Signing Practices are mostly		Security considerations in the Sender Signing Practices are mostly
	related to attempts on the part of malicious senders to represent		related to attempts on the part of malicious senders to represent
	themselves as other senders, often in an attempt to defraud either		themselves as other authors, often in an attempt to defraud either
	the recipient or the Alleged Originator.		the recipient or an Alleged Author.
	Additional security considerations regarding Sender Signing Practices		Additional security considerations regarding Sender Signing Practices
	may be found in the DKIM threat analysis [RFC4686].		may be found in the DKIM threat analysis [RFC4686].
	6.1. Fraudulent Sender Address		*<<<THIS SECTION IS NOT COMPLETE.>>>*
	[[Assuming 3rd party signature is based on Sender header field]] If
	the Sender Signing Practices sanction third-party signing, an
	attacker can create a message with a From header field of an
	arbitrary sender and a legitimately signed Sender header field
	6.2. DNS Attacks		5.1. DNS Attacks
	An attacker might attack the DNS infrastructure in an attempt to		An attacker might attack the DNS infrastructure in an attempt to
	impersonate SSP records. However, such an attacker is more likely to		impersonate SSP records. However, such an attacker is more likely to
	attack at a higher level, e.g., redirecting A or MX record lookups in		attack at a higher level, e.g., redirecting "A" or "MX" record
	order to capture traffic that was legitimately intended for the		lookups in order to capture traffic that was legitimately intended
	target domain. Domains concerned about this should use DNSSEC		for the target domain. Domains concerned about this should use
	[RFC4033].		DNSSEC [RFC4033].
	Because SSP operates within the framework of the legacy e-mail		Because SSP operates within the framework of the legacy e-mail
	system, the default result in the absence of an SSP record is that		system, the default result in the absence of an SSP record is that
	the domain does not sign all of its messages. Therefore, a DNS		the domain does not sign all of its messages. It is therefore
	attack which is successful in suppressing the SSP response to the		important that the SSP Checker distinguish a DNS failure such as
	verifier is sufficient to cause the verifier to see unsigned messages		SERVFAIL from other DNS errors so that appropriate actions can be
	as non-suspicious, even when that is not intended by the alleged		taken.
	originating domain.
	7. References		5.2. DNS Wildcards
	7.1. Normative References		Wildcards within a domain publishing SSP records, including but not
			limited to wildcard "MX" records, pose a particular problem. While
			referencing the immediate parent domain allows the discovery of an
			SSP record corresponding to an unintended immediate-child subdomain,
			wildcard records apply at multiple levels. For example, if there is
			a wildcard "MX" record for "example.com", the domain
			"foo.bar.example.com" can receive mail through the named mail
			exchanger. Conversely, the existence of the record makes it
			impossible to tell whether "foo.bar.example.com" is a legitimate name
			since a query for that name will not return an "NXDOMAIN" error. For
			that reason, SSP coverage for subdomains of domains containing a
			wildcard record is incomplete.
			NON-NORMATIVE NOTE: Complete SSP coverage of domains containing
			(or where any parent contains) wildcards generally cannot be
			guaranteed.
			6. References
			6.1. Normative References
	[RFC1035] Mockapetris, P., "Domain names - implementation and		[RFC1035] Mockapetris, P., "Domain names - implementation and
	specification", STD 13, RFC 1035, November 1987.		specification", STD 13, RFC 1035, 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.
	[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,		[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
	April 2001.		April 2001.
	[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax		[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", RFC 4234, October 2005.		Specifications: ABNF", RFC 4234, October 2005.
	[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.
	7.2. Informative References		6.2. Informative References
	[I-D.ietf-dkim-ssp-requirements]
	Thomas, M., "Requirements for a DKIM Signing Practices
	Protocol", draft-ietf-dkim-ssp-requirements-05 (work in
	progress), April 2007.
	[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.
	[RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys		[RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys
	Identified Mail (DKIM)", RFC 4686, September 2006.		Identified Mail (DKIM)", RFC 4686, September 2006.
	Appendix A. Acknowledgements		[RFC5016] Thomas, M., "Requirements for a DomainKeys Identified Mail
			(DKIM) Signing Practices Protocol", RFC 5016,
			October 2007.
	The authors wish to thank many members of the ietf-dkim mailing list,		Appendix A. Usage Examples (INFORMATIVE)
	in particular Arvel Hathcock and Eliot Lear, for valuable suggestions
	and constructive criticism of earlier versions of this draft.
	Appendix B. Change Log		These examples are intended to illustrate typical uses of SSP. They
			are not intended to be exhaustive, nor to apply to every domain or
			mail system's individual situation.
	B.1. Changes since -ietf-dkim-ssp-00		A.1. Single Location Domains
			A common mail system configuration handles all of a domain's users'
			incoming and outgoing mail through a single MTA or cluster of MTAs.
			In that case, the MTA(s) can be configured to sign outgoing mail with
			an Author Signature.
			In this situation it might be appropriate to publish an SSP record
			for the domain containing "all", depending on whether the users also
			send mail through other MTAs that do not apply an Author Signature.
			Such MTAs could include MTAs at hotels or hotspot networks used by
			travelling users, or web sites that provide "mail an article"
			features.
			Domain managers are advised to consider the ways that mail processing
			can modify messages in ways that will invalidate an existing DKIM
			signature, such as mailing lists, courtesy forwarders, and other
			paths that could add or modify headers, or modify the message body.
			In that case, if the modifications invalidate the DKIM signature,
			recipient MTAs will consider the mail not to have an Author
			Signature, even though the signature was present when the mail was
			originally sent.
			A.2. Bulk Mailing Domains
			Another common configuration uses a domain solely for bulk or
			broadcast mail, with no individual human users, again typically
			sending all the mail through a single MTA or cluster of MTAs that can
			apply an Author Signature. In this case, the domain's management can
			be confident that all of its outgoing mail will be sent through the
			signing MTA. Lacking individual users, the domain is unlikely to
			participate in mailing lists, but could still send mail through other
			paths that might invalidate signatures.
			Domain owners often use specialist mailing providers to send their
			bulk mail. In that case, the mailing provider needs access to a
			suitable signing key in order to apply an Author Signature. One
			possible route would be for the domain owner to generate the key and
			give it to the mailing provider. Another would be for the domain to
			delegate a subdomain to the mailing provider, for example,
			bigbank.example might delegate email.bigbank.example to such a
			provider. In that case, the provider can generate the keys and DKIM
			DNS records itself and use the subdomain in the Author Address in the
			mail.
			A.3. Bulk Mailing Domains with Discardable Mail
			In some cases, a domain might sign all its outgoing mail with an
			Author Signature, but prefers that recipient systems discard mail
			without a valid Author Signature to avoid confusion from mail sent
			from sources that do not apply an Author Signature. (This latter
			kind of mail is sometimes loosely called "forgeries".) In that case,
			it may be appropriate to publish an SSP record containing
			"discardable". Note that a domain SHOULD NOT publish a "discardable"
			record if it wishes to maximize the likelihood that mail from the
			domain is delivered, since it could cause some fraction of the mail
			the domain sends to be discarded.
			As a special case, if a domain sends no mail at all, it can safely
			publish a "discardable" SSP record, since any mail with an author
			address in the domain is a forgery.
			A.4. Third Party Senders
			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
			behalf of a designated author domain, using that domain in the
			RFC2822 From: or other headers. Due to the many and varied
			complexities of such agreements, third party signing is not addressed
			in this specification. The authors anticipate that as mail systems
			gain experience with DKIM, it will become possible to codify best
			practices of this and other usages of DKIM.
			Appendix B. Acknowledgements
			The authors wish to thank many members of the ietf-dkim mailing list
			for valuable suggestions and constructive criticism of earlier
			versions of this draft.
			This draft incorporates content from a parallel "DKIM Author Signing
			Policies" document edited by John Levine. The authors appreciate
			this contribution.
			Appendix C. Change Log
			*NOTE TO RFC EDITOR: This section may be removed upon publication of
			this document as an RFC.*
			C.1. Changes since -ietf-dkim-ssp-01
			o Reworded introduction for clarity.
			o Various definition clarifications.
			o Changed names of practices to unknown, all, and discardable.
			o Removed normative language mandating use of SSP in particular
			situations (issue 1538).
			o Clarified possible confusion over handling of syntax errors.
			o Removed normative language from Introduction (issue 1538).
			o Changed "Originator" to "Author" throughout (issue 1529).
			o Removed all references to Third-Party Signatures (issues 1512,
			1521).
			o Removed all mention of "Suspicious" (issues 1528, 1530).
			o Removed "t=y" (testing) flag (issue 1540).
			o Removed "handling" tag (issue 1513).
			o Broke up the "Sender Signing Practices Check Procedure" into two
			algorithms: fetching the SSP record and interpretation thereof
			(issues 1531, 1535; partially addresses issue 1520).
			Interpretation is now the responsibility of the Evaluator.
			o Document restructuring for better flow and remove redundancies
			(some may address issue 1523, but I'm not sure I understand that
			issue completely; also issues 1532, 1537).
			o Removed all mention of how this interacts with users, even though
			it makes parts of the document harder to understand (issue 1526).
			o Introduced the concepts of "SSP Checker" and "Evaluator".
			o Multiple author case now handled my separate invocations of SSP
			checker by Evaluator (issue 1525).
			o Removed check to avoid querying top-level domains.
			o Changed ABNF use of whitespace from [FWS] to *WSP (partially
			addresses issue 1543).
			C.2. Changes since -ietf-dkim-ssp-00
	o Clarified Operation Overview and eliminated use of Legitimate as		o Clarified Operation Overview and eliminated use of Legitimate as
	the counterpart of Suspicious since the words have different		the counterpart of Suspicious since the words have different
	meanings.		meanings.
	o Improved discussion (courtesy of Arvel Hathcock) of the use of TXT		o Improved discussion (courtesy of Arvel Hathcock) of the use of TXT
	records in DNS vs. a new RR type.		records in DNS vs. a new RR type.
	o Clarified publication rules for multilevel names.		o Clarified publication rules for multilevel names.
	o Better description of overall record syntax, in particular that		o Better description of overall record syntax, in particular that
	records with unknown tags are considered syntactically correct.		records with unknown tags are considered syntactically correct.
	o Clarified Sender Signing Practices Check Procedure, primarily by		o Clarified Sender Signing Practices Check Procedure, primarily by
	use of new term Originator Domain.		use of new term Author Domain.
	o Eliminated section "Third-Party Signatures and Mailing Lists" that		o Eliminated section "Third-Party Signatures and Mailing Lists" that
	is better included in the DKIM overview document.		is better included in the DKIM overview document.
	o Added "handling" tag to express alleged sending domain's		o Added "handling" tag to express alleged sending domain's
	preference about handling of Suspicious messages.		preference about handling of Suspicious messages.
	o Clarified handling of SERVFAIL error in SSP check.		o Clarified handling of SERVFAIL error in SSP check.
	o Replaced "entity" with "domain", since with the removal of user-		o Replaced "entity" with "domain", since with the removal of user-
	granularity SSP, the only entities having sender signing policies		granularity SSP, the only entities having sender signing policies
	are domains.		are domains.
	B.2. Changes since -allman-ssp-02		C.3. Changes since -allman-ssp-02
	o Removed user-granularity SSP and u= tag.		o Removed user-granularity SSP and u= tag.
	o Replaced DKIMP resource record with a TXT record.		o Replaced DKIMP resource record with a TXT record.
	o Changed name of the primary tag from "p" to "dkim".		o Changed name of the primary tag from "p" to "dkim".
	o Replaced lookup algorithm with one which traverses upward at most		o Replaced lookup algorithm with one which traverses upward at most
	one level.		one level.
	o Added description of records which must be published, and effect		o Added description of records which must be published, and effect
	of wildcard records within the domain, on SSP.		of wildcard records within the domain, on SSP.
	B.3. Changes since -allman-ssp-01		C.4. Changes since -allman-ssp-01
	o Changed term "Sender Signing Policy" to "Sender Signing		o Changed term "Sender Signing Policy" to "Sender Signing
	Practices".		Practices".
	o Changed query methodology to use a separate DNS resource record		o Changed query methodology to use a separate DNS resource record
	type, DKIMP.		type, DKIMP.
	o Changed tag values from SPF-like symbols to words.		o Changed tag values from SPF-like symbols to words.
	o User level policies now default to that of the domain if not		o User level policies now default to that of the domain if not
	specified.		specified.
	o Removed the "Compliance" section since we're still not clear on		o Removed the "Compliance" section since we're still not clear on
	what goes here.		what goes here.
	o Changed the "parent domain" policy to only search up one level		o Changed the "parent domain" policy to only search up one level
	(assumes that subdomains will publish SSP records if appropriate).		(assumes that subdomains will publish SSP records if appropriate).
	o Added detailed description of SSP check procedure.		o Added detailed description of SSP check procedure.
	B.4. Changes since -allman-ssp-00		C.5. Changes since -allman-ssp-00
	From a "diff" perspective, the changes are extensive. Semantically,		From a "diff" perspective, the changes are extensive. Semantically,
	the changes are:		the changes are:
	o Added section on "Third-Party Signatures and Mailing Lists"		o Added section on "Third-Party Signatures and Mailing Lists"
	o Added "Compliance" (transferred from -base document). I'm not		o Added "Compliance" (transferred from -base document). I'm not
	clear on what needs to be done here.		clear on what needs to be done here.
	o Extensive restructuring.		o Extensive restructuring.
	Authors' Addresses		Authors' Addresses
	Eric Allman		Eric Allman
	Sendmail, Inc.		Sendmail, Inc.
	6475 Christie Ave, Suite 350		6475 Christie Ave, Suite 350
	skipping to change at page 18, line 7		skipping to change at page 19, line 7
	170 W. Tasman Drive		170 W. Tasman Drive
	San Jose, CA 95134-1706		San Jose, CA 95134-1706
	USA		USA
	Phone: +1 408 526 5914		Phone: +1 408 526 5914
	Email: fenton@cisco.com		Email: fenton@cisco.com
	URI:		URI:
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2008).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS		THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF		OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
End of changes. 96 change blocks.
	430 lines changed or deleted		452 lines changed or added
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/