< draft-ietf-dkim-mailinglists-09.txt		draft-ietf-dkim-mailinglists-10.txt >
	DKIM Working Group M. Kucherawy		DKIM Working Group M. Kucherawy
	Internet-Draft Cloudmark		Internet-Draft Cloudmark
	Intended status: BCP May 9, 2011		Intended status: BCP May 10, 2011
	Expires: November 10, 2011		Expires: November 11, 2011
	DKIM And Mailing Lists		DKIM And Mailing Lists
	draft-ietf-dkim-mailinglists-09		draft-ietf-dkim-mailinglists-10
	Abstract		Abstract
	DomainKeys Identified Mail (DKIM) allows an administrative mail		DomainKeys Identified Mail (DKIM) allows an administrative mail
	domain (ADMD) to assume some responsibility for a message. Based on		domain (ADMD) to assume some responsibility for a message. Based on
	deployment experience with DKIM, this Best Current Practices document		deployment experience with DKIM, this Best Current Practices document
	provides guidance for the use of DKIM with scenarios that include		provides guidance for the use of DKIM with scenarios that include
	Mailing List Managers (MLMs).		Mailing List Managers (MLMs).
	Status of this Memo		Status of this Memo
	skipping to change at page 1, line 34 ¶		skipping to change at page 1, line 34 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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."
	This Internet-Draft will expire on November 10, 2011.		This Internet-Draft will expire on November 11, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.2. MLMs In Infrastructure . . . . . . . . . . . . . . . . . . 4		1.2. MLMs In Infrastructure . . . . . . . . . . . . . . . . . . 4
	1.3. Feedback Loops And Other Bi-Lateral Agreements . . . . . . 5		1.3. Feedback Loops And Other Bi-Lateral Agreements . . . . . . 5
	1.4. Document Scope and Goals . . . . . . . . . . . . . . . . . 5		1.4. Document Scope and Goals . . . . . . . . . . . . . . . . . 5
	2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7		2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7
	2.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 7		2.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 7
	2.2. Messaging Terms . . . . . . . . . . . . . . . . . . . . . 7		2.2. Messaging Terms . . . . . . . . . . . . . . . . . . . . . 7
	2.3. DKIM-Specific References . . . . . . . . . . . . . . . . . 7		2.3. DKIM-Specific References . . . . . . . . . . . . . . . . . 7
	2.4. 'DKIM-Friendly' . . . . . . . . . . . . . . . . . . . . . 7		2.4. 'DKIM-Friendly' . . . . . . . . . . . . . . . . . . . . . 7
	2.5. Message Streams . . . . . . . . . . . . . . . . . . . . . 7		2.5. Message Streams . . . . . . . . . . . . . . . . . . . . . 7
	3. Mailing Lists and DKIM . . . . . . . . . . . . . . . . . . . . 8		3. Mailing Lists and DKIM . . . . . . . . . . . . . . . . . . . . 9
	3.1. Roles and Realities . . . . . . . . . . . . . . . . . . . 8		3.1. Roles and Realities . . . . . . . . . . . . . . . . . . . 9
	3.2. Types Of Mailing Lists . . . . . . . . . . . . . . . . . . 9		3.2. Types Of Mailing Lists . . . . . . . . . . . . . . . . . . 10
	3.3. Current MLM Effects On Signatures . . . . . . . . . . . . 10		3.3. Current MLM Effects On Signatures . . . . . . . . . . . . 11
	4. Non-Participating MLMs . . . . . . . . . . . . . . . . . . . . 13		4. Non-Participating MLMs . . . . . . . . . . . . . . . . . . . . 14
	4.1. Author-Related Signing . . . . . . . . . . . . . . . . . . 13		4.1. Author-Related Signing . . . . . . . . . . . . . . . . . . 14
	4.2. Verification Outcomes at Receivers . . . . . . . . . . . . 14		4.2. Verification Outcomes at Receivers . . . . . . . . . . . . 15
	4.3. Handling Choices at Receivers . . . . . . . . . . . . . . 14		4.3. Handling Choices at Receivers . . . . . . . . . . . . . . 15
	4.4. Wrapping A Non-Participating MLM . . . . . . . . . . . . . 14		4.4. Wrapping A Non-Participating MLM . . . . . . . . . . . . . 15
	5. Participating MLMs . . . . . . . . . . . . . . . . . . . . . . 15		5. Participating MLMs . . . . . . . . . . . . . . . . . . . . . . 16
	5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 15		5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 16
	5.2. DKIM Author Domain Signing Practices . . . . . . . . . . . 15		5.2. DKIM Author Domain Signing Practices . . . . . . . . . . . 16
	5.3. Subscriptions . . . . . . . . . . . . . . . . . . . . . . 16		5.3. Subscriptions . . . . . . . . . . . . . . . . . . . . . . 17
	5.4. Exceptions To ADSP Recommendations . . . . . . . . . . . . 16		5.4. Exceptions To ADSP Recommendations . . . . . . . . . . . . 18
	5.5. Author-Related Signing . . . . . . . . . . . . . . . . . . 16		5.5. Author-Related Signing . . . . . . . . . . . . . . . . . . 18
	5.6. Verification Outcomes at MLMs . . . . . . . . . . . . . . 17		5.6. Verification Outcomes at MLMs . . . . . . . . . . . . . . 18
	5.7. Signature Removal Issues . . . . . . . . . . . . . . . . . 18		5.7. Signature Removal Issues . . . . . . . . . . . . . . . . . 19
	5.8. MLM Signatures . . . . . . . . . . . . . . . . . . . . . . 19		5.8. MLM Signatures . . . . . . . . . . . . . . . . . . . . . . 21
	5.9. Verification Outcomes at Final Receiving Sites . . . . . . 20		5.9. Verification Outcomes at Final Receiving Sites . . . . . . 22
	5.10. Use With FBLs . . . . . . . . . . . . . . . . . . . . . . 21		5.10. Use With FBLs . . . . . . . . . . . . . . . . . . . . . . 22
	5.11. Handling Choices at Receivers . . . . . . . . . . . . . . 21		5.11. Handling Choices at Receivers . . . . . . . . . . . . . . 23
	6. DKIM Reporting . . . . . . . . . . . . . . . . . . . . . . . . 23		6. DKIM Reporting . . . . . . . . . . . . . . . . . . . . . . . . 25
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 25		8. Security Considerations . . . . . . . . . . . . . . . . . . . 27
	8.1. Security Considerations from DKIM and ADSP . . . . . . . . 25		8.1. Security Considerations from DKIM and ADSP . . . . . . . . 27
	8.2. Authentication Results When Relaying . . . . . . . . . . . 25		8.2. Authentication Results When Relaying . . . . . . . . . . . 27
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 26		9.1. Normative References . . . . . . . . . . . . . . . . . . . 28
	9.2. Informative References . . . . . . . . . . . . . . . . . . 26		9.2. Informative References . . . . . . . . . . . . . . . . . . 28
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 28		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 30
	Appendix B. Example Scenarios . . . . . . . . . . . . . . . . . . 29		Appendix B. Example Scenarios . . . . . . . . . . . . . . . . . . 31
	B.1. MLMs and ADSP . . . . . . . . . . . . . . . . . . . . . . 29		B.1. MLMs and ADSP . . . . . . . . . . . . . . . . . . . . . . 31
	B.2. MLMs and FBLs . . . . . . . . . . . . . . . . . . . . . . 29		B.2. MLMs and FBLs . . . . . . . . . . . . . . . . . . . . . . 31
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 30		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 32
	1. Introduction		1. Introduction
	DomainKeys Identified Mail ([DKIM]) allows an Administrative Mail		DomainKeys Identified Mail [DKIM] allows an Administrative Mail
	Domain to take some responsibility for a [MAIL] message. This can be		Domain to take some responsibility for a [MAIL] message. Such
	an author's organization, an operational relay (Mail Transfer Agent,		responsibility can be taken by an author's organization, an
	or MTA) or one of their agents. Assertion of responsibility is made		operational relay (Mail Transfer Agent, or MTA) or one of their
	through a cryptographic signature. Message transit from author to		agents. Assertion of responsibility is made through a cryptographic
	recipient is through relays that typically make no substantive change		signature. Message transit from author to recipient is through
	to the message content and thus preserve the validity of the DKIM		relays that typically make no substantive change to the message
	signature.		content and thus preserve the validity of the DKIM signature.
	In contrast to relays, there are intermediaries, such as mailing list		In contrast to relays, there are intermediaries, such as mailing list
	managers (MLMs), that actively take delivery of messages, re-format		managers (MLMs), that actively take delivery of messages, re-format
	them, and re-post them, often invalidating DKIM signatures. The goal		them, and re-post them, often invalidating DKIM signatures. The goal
	for this document is to explore the use of DKIM for scenarios that		for this document is to explore the use of DKIM for scenarios that
	include intermediaries, and recommend Best Current Practices based on		include intermediaries, and recommend Best Current Practices based on
	acquired experience. Questions that will be discussed include:		acquired experience. Questions that will be discussed include:
	o Under what circumstances is it advisable for an author, or its		o Under what circumstances is it advisable for an author, or its
	organization, to apply DKIM to mail sent to mailing lists?		organization, to apply DKIM to mail sent to mailing lists?
	skipping to change at page 3, line 37 ¶		skipping to change at page 3, line 37 ¶
	identifiers?		identifiers?
	o What are the tradeoffs regarding having an MLM remove existing		o What are the tradeoffs regarding having an MLM remove existing
	DKIM signatures prior to re-posting the message?		DKIM signatures prior to re-posting the message?
	o What are the tradeoffs regarding having an MLM add its own DKIM		o What are the tradeoffs regarding having an MLM add its own DKIM
	signature?		signature?
	These and others are open questions for which there may be no		These and others are open questions for which there may be no
	definitive answers. However, based on experience since the		definitive answers. However, based on experience since the
	publication of [DKIM] and its gradual deployment, there are some		publication of the original version of [DKIM] and its gradual
	views that are useful to consider and some recommended procedures.		deployment, there are some views that are useful to consider and some
			recommended procedures.
	In general there are, in relation to DKIM, two categories of MLMs:		In general there are, in relation to DKIM, two categories of MLMs:
	participating and non-participating. As each type has its own issues		participating and non-participating. As each type has its own issues
	regarding DKIM-signed messages that are either handled or produced by		regarding DKIM-signed messages that are either handled or produced by
	them (or both), the types are discussed in separate sections.		them (or both), the types are discussed in separate sections.
			The best general recommendation for dealing with MLMs is that the MLM
			or an MTA in the MLM's domain apply its own DKIM signature to each
			message it forwards, and for assessors on the receiving end to
			consider the MLM's domain signature in making their assessments.
			With the understanding that that is not always possible or practical,
			and the consideration that it might not always be sufficient, this
			document provides additional guidance.
	1.1. Background		1.1. Background
	DKIM signatures permit an agent of the email architecture (see		DKIM signatures permit an agent of the email architecture (see
	[EMAIL-ARCH]) to make a claim of responsibility for a message by		[EMAIL-ARCH]) to make a claim of responsibility for a message by
	affixing a validated domain-level identifier to the message as it		affixing a validated domain-level identifier to the message as it
	passes through a relay. Although not the only possibility, this is		passes through a relay. Although not the only possibility, this is
	most commonly done as a message passes through a boundary Mail		most commonly done as a message passes through a boundary Mail
	Transport Agent (MTA) as it departs an Administrative Mail Domain		Transport Agent (MTA) as it departs an Administrative Mail Domain
	(ADMD) across the open Internet.		(ADMD) across the open Internet.
	skipping to change at page 5, line 34 ¶		skipping to change at page 5, line 42 ¶
	to exchange reports of abuse. Typically, a sender registers with a		to exchange reports of abuse. Typically, a sender registers with a
	receiving site to receive abuse reports from that site for mail		receiving site to receive abuse reports from that site for mail
	coming from the sender.		coming from the sender.
	An FBL reporting address (i.e., an address to which FBL reports are		An FBL reporting address (i.e., an address to which FBL reports are
	sent) is part of this bi-lateral registration. Some FBLs require		sent) is part of this bi-lateral registration. Some FBLs require
	DKIM use by the registrant.		DKIM use by the registrant.
	See Section 6 for additional discussion.		See Section 6 for additional discussion.
	FBLs tend to use the ARF ([MARF]) or the IODEF ([IODEF]) formats.		FBLs tend to use the [ARF] or the [IODEF] formats.
	1.4. Document Scope and Goals		1.4. Document Scope and Goals
	This document provides discussion on the above issues, to improve the		This document provides discussion on the above issues, to improve the
	handling of possible interactions between DKIM and MLMs. In general,		handling of possible interactions between DKIM and MLMs. In general,
	the preference is to impose changes to behaviour at the signer and		the preference is to impose changes to behaviour at the signer and
	verifier rather than at the MLM.		verifier rather than at the MLM.
	Wherever possible, the document's discussion of MLMs is conceptually		Wherever possible, the document's discussion of MLMs is conceptually
	decoupled from MTAs despite the very tight integration that is		decoupled from MTAs despite the very tight integration that is
	skipping to change at page 7, line 10 ¶		skipping to change at page 7, line 10 ¶
	deployment, and working group consensus. There is no substantial		deployment, and working group consensus. There is no substantial
	implementation history upon which these suggestions are based, and		implementation history upon which these suggestions are based, and
	the efficacy, performance and security characteristics of them have		the efficacy, performance and security characteristics of them have
	not yet been fully explored.		not yet been fully explored.
	2. Definitions		2. Definitions
	2.1. Key Words		2.1. Key Words
	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", "NOT RECOMMENDED", "MAY", and
	document are to be interpreted as described in [KEYWORDS].		"OPTIONAL" in this document are to be interpreted as described in
			[KEYWORDS].
	2.2. Messaging Terms		2.2. Messaging Terms
	See [EMAIL-ARCH] for a general description of the current messaging		See [EMAIL-ARCH] for a general description of the current messaging
	architecture, and for definitions of various terms used in this		architecture, and for definitions of various terms used in this
	document.		document.
	2.3. DKIM-Specific References		2.3. DKIM-Specific References
	Readers are encouraged to become familiar with [DKIM] and [ADSP],		Readers are encouraged to become familiar with [DKIM] and [ADSP],
	skipping to change at page 15, line 40 ¶		skipping to change at page 16, line 40 ¶
	considerations (see Section 3.5 of [DKIM]). Its use is therefore		considerations (see Section 3.5 of [DKIM]). Its use is therefore
	discouraged.		discouraged.
	Expressions of list-specific policy (e.g., rules for participation,		Expressions of list-specific policy (e.g., rules for participation,
	small advertisements, etc.) are often added to outgoing messages by		small advertisements, etc.) are often added to outgoing messages by
	MLM operators. There is currently no header field proposed for		MLM operators. There is currently no header field proposed for
	relaying such general operational MLM details apart from what		relaying such general operational MLM details apart from what
	[LIST-URLS] already supports. This sort of information is commonly		[LIST-URLS] already supports. This sort of information is commonly
	included footer text appended to the body of the message, or header		included footer text appended to the body of the message, or header
	text prepended above the original body. It is RECOMMENDED that		text prepended above the original body. It is RECOMMENDED that
	periodic, automatic mailings to the list to remind subscribers of		periodic, automatic mailings to the list are sent to remind
	list policy, and it is otherwise RECOMMENDED that the use of standard		subscribers of list policy. It is also RECOMMENDED that the use of
	header fields to express list operation parameters be applied rather		standard header fields to express list operation parameters be
	than body changes. These periodic mailings will be repetitive, of		applied rather than body changes. These periodic mailings will be
	course, but by being generally the same each time they can be easily		repetitive, of course, but by being generally the same each time they
	filtered if desired.		can be easily filtered if desired.
	5.2. DKIM Author Domain Signing Practices		5.2. DKIM Author Domain Signing Practices
	ADSP presents a particular challenge. An author domain posting a		ADSP presents a particular challenge. An author domain posting a
	policy of "discardable" imposes a very tight restriction on the use		policy of "discardable" imposes a very tight restriction on the use
	of mailing lists, essentially constraining that domain's users to		of mailing lists, essentially constraining that domain's users to
	lists operated by aliasing MLMs only; any MLM that alters a message		lists operated by aliasing MLMs only; any MLM that alters a message
	from such a domain or removes its signature subjects the message to		from such a domain or removes its signature subjects the message to
	severe action by verifiers or receivers. A resending MLM SHOULD		severe action by verifiers or receivers. A resending MLM SHOULD
	reject outright any mail from an author whose domain posts such a		reject outright any mail from an author whose domain posts such a
	skipping to change at page 16, line 18 ¶		skipping to change at page 17, line 18 ¶
	ADSP-aware recipients. See also the discussion in Section 5.3.		ADSP-aware recipients. See also the discussion in Section 5.3.
	Where such rejection of "discardable" mail is not enforced, and such		Where such rejection of "discardable" mail is not enforced, and such
	mail arrives to a verifier that applies ADSP checks which fail, the		mail arrives to a verifier that applies ADSP checks which fail, the
	message SHOULD either be discarded (i.e. accept the message at the		message SHOULD either be discarded (i.e. accept the message at the
	[SMTP] level but discard it without delivery) or rejected by		[SMTP] level but discard it without delivery) or rejected by
	returning a 5xx error code. In the latter case, some advice for how		returning a 5xx error code. In the latter case, some advice for how
	to conduct the rejection in a potentially meaningful way can be found		to conduct the rejection in a potentially meaningful way can be found
	in Section 5.11.		in Section 5.11.
			The reason for these recommendations is best illustrated by example.
			Suppose the following:
			o users U1 and U2 are subscribers of list L;
			o U1 is within an ADMD that advertises a "discardable" policy using
			ADSP;
			o L alters submissions prior to re-sending in a way that invalidates
			the DKIM signature added by U1's ADMD;
			o U2's ADMD enforces ADSP at the border by issuing an SMTP error
			code; and
			o L is configured to remove subscribers whose mail is bouncing.
			It follows then that a submission to L from U1 will be received at
			U2, but since the DKIM signature fails to verify, U2's ADMD will
			reject it based on the ADSP protocol. That rejection is received at
			L, which proceeds to remove U2 from the list.
	See also Appendix B.5 of [ADSP] for further discussion.		See also Appendix B.5 of [ADSP] for further discussion.
	5.3. Subscriptions		5.3. Subscriptions
	At subscription time, an ADSP-aware MLM SHOULD check for a published		At subscription time, an ADSP-aware MLM SHOULD check for a published
	ADSP record for the new subscriber's domain. If the policy specifies		ADSP record for the new subscriber's domain. If the policy specifies
	"discardable", the MLM SHOULD disallow the subscription or present a		"discardable", the MLM SHOULD disallow the subscription or present a
	warning that the subscriber's submissions to the mailing list might		warning that the subscriber's submissions to the mailing list might
	not be deliverable to some recipients because of the subscriber's		not be deliverable to some recipients because of the subscriber's
	ADMD's published policy.		ADMD's published policy.
	skipping to change at page 24, line 7 ¶		skipping to change at page 26, line 7 ¶
	DKIM verification failures, MLMs will benefit from their use.		DKIM verification failures, MLMs will benefit from their use.
	MLMs SHOULD apply DKIM failure reporting mechanisms as a method for		MLMs SHOULD apply DKIM failure reporting mechanisms as a method for
	providing feedback to signers about issues with DKIM infrastructure.		providing feedback to signers about issues with DKIM infrastructure.
	This is especially important for MLMs that implement DKIM		This is especially important for MLMs that implement DKIM
	verification as a mechanism for authentication of list configuration		verification as a mechanism for authentication of list configuration
	commands and submissions from subscribers.		commands and submissions from subscribers.
	7. IANA Considerations		7. IANA Considerations
	This document includes no IANA actions.		This document includes no IANA actions. It should be removed prior
			to publication.
	8. Security Considerations		8. Security Considerations
	This document provides suggested or best current practices for use		This document provides suggested or best current practices for use
	with DKIM, and as such does not introduce any new technologies for		with DKIM, and as such does not introduce any new technologies for
	consideration. However, the following security issues should be		consideration. However, the following security issues should be
	considered when implementing the above practices.		considered when implementing the above practices.
	8.1. Security Considerations from DKIM and ADSP		8.1. Security Considerations from DKIM and ADSP
	skipping to change at page 26, line 33 ¶		skipping to change at page 28, line 33 ¶
	[KEYWORDS]		[KEYWORDS]
	Bradner, S., "Key words for use in RFCs to Indicate		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.
	[MAIL] Resnick, P., "Internet Message Format", RFC 5322,		[MAIL] Resnick, P., "Internet Message Format", RFC 5322,
	October 2008.		October 2008.
	9.2. Informative References		9.2. Informative References
			[ARF] Shafranovich, Y., Levine, J., and M. Kucherawy, "An
			Extensible Format for Email Feedback Reports", RFC 5965,
			August 2010.
	[DKIM-DEPLOYMENT]		[DKIM-DEPLOYMENT]
	Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker,		Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker,
	"DomainKeys Identified Mail (DKIM) Development, Deployment		"DomainKeys Identified Mail (DKIM) Development, Deployment
	and Operations", I-D DRAFT-IETF-DKIM-DEPLOYMENT,		and Operations", I-D DRAFT-IETF-DKIM-DEPLOYMENT,
	January 2010.		January 2010.
	[DKIM-OVERVIEW]		[DKIM-OVERVIEW]
	Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys		Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys
	Identified Mail (DKIM) Service Overview", RFC 5585,		Identified Mail (DKIM) Service Overview", RFC 5585,
	July 2009.		July 2009.
	skipping to change at page 27, line 12 ¶		skipping to change at page 29, line 16 ¶
	[LIST-ID] Chandhok, R. and G. Wenger, "List-Id: A Structured Field		[LIST-ID] Chandhok, R. and G. Wenger, "List-Id: A Structured Field
	and Namespace for the Identification of Mailing Lists",		and Namespace for the Identification of Mailing Lists",
	RFC 2919, March 2001.		RFC 2919, March 2001.
	[LIST-URLS]		[LIST-URLS]
	Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax		Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax
	for Core Mail List Commands and their Transport through		for Core Mail List Commands and their Transport through
	Message Header Fields", RFC 2369, July 1998.		Message Header Fields", RFC 2369, July 1998.
	[MARF] Shafranovich, Y., Levine, J., and M. Kucherawy, "An
	Extensible Format for Email Feedback Reports", RFC 5965,
	August 2010.
	[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail		[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
	Extensions (MIME) Part One: Format of Internet Message		Extensions (MIME) Part One: Format of Internet Message
	Bodies", RFC 2045, November 1996.		Bodies", RFC 2045, November 1996.
	[MIME-TYPES]		[MIME-TYPES]
	Freed, N. and N. Borenstein, "Multipurpose Internet Mail		Freed, N. and N. Borenstein, "Multipurpose Internet Mail
	Extensions (MIME) Part Two: Media Types", RFC 2046,		Extensions (MIME) Part Two: Media Types", RFC 2046,
	November 1996.		November 1996.
	[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,		[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
End of changes. 15 change blocks.
	63 lines changed or deleted		95 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/