< draft-ietf-dkim-mailinglists-07.txt		draft-ietf-dkim-mailinglists-08.txt >
	DKIM Working Group M. Kucherawy		DKIM Working Group M. Kucherawy
	Internet-Draft Cloudmark		Internet-Draft Cloudmark
	Intended status: BCP April 25, 2011		Intended status: BCP April 27, 2011
	Expires: October 27, 2011		Expires: October 29, 2011
	DKIM And Mailing Lists		DKIM And Mailing Lists
	draft-ietf-dkim-mailinglists-07		draft-ietf-dkim-mailinglists-08
	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). {DKIM 12}		Mailing List Managers (MLMs). {DKIM 12}
	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 October 27, 2011.		This Internet-Draft will expire on October 29, 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
	skipping to change at page 2, line 37 ¶		skipping to change at page 2, line 37 ¶
	5.4. Wrapping A Non-Participating MLM . . . . . . . . . . . . . 15		5.4. Wrapping A Non-Participating MLM . . . . . . . . . . . . . 15
	6. Participating MLMs . . . . . . . . . . . . . . . . . . . . . . 16		6. Participating MLMs . . . . . . . . . . . . . . . . . . . . . . 16
	6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 16		6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 16
	6.2. DKIM Author Domain Signing Practices . . . . . . . . . . . 16		6.2. DKIM Author Domain Signing Practices . . . . . . . . . . . 16
	6.3. Subscriptions . . . . . . . . . . . . . . . . . . . . . . 17		6.3. Subscriptions . . . . . . . . . . . . . . . . . . . . . . 17
	6.4. Exceptions To ADSP Recommendations . . . . . . . . . . . . 17		6.4. Exceptions To ADSP Recommendations . . . . . . . . . . . . 17
	6.5. Author-Related Signing . . . . . . . . . . . . . . . . . . 17		6.5. Author-Related Signing . . . . . . . . . . . . . . . . . . 17
	6.6. Verification Outcomes at MLMs . . . . . . . . . . . . . . 18		6.6. Verification Outcomes at MLMs . . . . . . . . . . . . . . 18
	6.7. Signature Removal Issues . . . . . . . . . . . . . . . . . 19		6.7. Signature Removal Issues . . . . . . . . . . . . . . . . . 19
	6.8. MLM Signatures . . . . . . . . . . . . . . . . . . . . . . 20		6.8. MLM Signatures . . . . . . . . . . . . . . . . . . . . . . 20
	6.9. Verification Outcomes at Final Receiving Sites . . . . . . 22		6.9. Verification Outcomes at Final Receiving Sites . . . . . . 21
	6.10. Use With FBLs . . . . . . . . . . . . . . . . . . . . . . 22		6.10. Use With FBLs . . . . . . . . . . . . . . . . . . . . . . 22
	6.11. Handling Choices at Receivers . . . . . . . . . . . . . . 23		6.11. Handling Choices at Receivers . . . . . . . . . . . . . . 23
	7. DKIM Reporting . . . . . . . . . . . . . . . . . . . . . . . . 25		7. DKIM Reporting . . . . . . . . . . . . . . . . . . . . . . . . 24
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 27		9. Security Considerations . . . . . . . . . . . . . . . . . . . 26
	9.1. Security Considerations from DKIM and ADSP . . . . . . . . 27		9.1. Security Considerations from DKIM and ADSP . . . . . . . . 26
	9.2. Authentication Results When Relaying . . . . . . . . . . . 27		9.2. Authentication Results When Relaying . . . . . . . . . . . 26
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 28		10.1. Normative References . . . . . . . . . . . . . . . . . . . 27
	10.2. Informative References . . . . . . . . . . . . . . . . . . 28		10.2. Informative References . . . . . . . . . . . . . . . . . . 27
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 30		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 29
	Appendix B. Example Scenarios . . . . . . . . . . . . . . . . . . 31		Appendix B. Example Scenarios . . . . . . . . . . . . . . . . . . 30
	B.1. MLMs and ADSP . . . . . . . . . . . . . . . . . . . . . . 31		B.1. MLMs and ADSP . . . . . . . . . . . . . . . . . . . . . . 30
	B.2. MLMs and FBLs . . . . . . . . . . . . . . . . . . . . . . 31		B.2. MLMs and FBLs . . . . . . . . . . . . . . . . . . . . . . 30
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 32		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 31
	1. Notes to Editor and Reviewers		1. Notes to Editor and Reviewers
	This version of the memo contains notations such as "{DKIM 2}".		This version of the memo contains notations such as "{DKIM 2}".
	These correspond to DKIM working group issue tracker items. They		These correspond to DKIM working group issue tracker items. They
	should be deleted prior to publication.		should be deleted prior to publication.
	2. Introduction		2. Introduction
	DomainKeys Identified Mail ([DKIM]) allows an Administrative Mail		DomainKeys Identified Mail ([DKIM]) allows an Administrative Mail
	skipping to change at page 19, line 49 ¶		skipping to change at page 19, line 49 ¶
	2. Apply local policy to authenticate the identity of the author;		2. Apply local policy to authenticate the identity of the author;
	3. Remove all existing [AUTH-RESULTS] fields (optional);		3. Remove all existing [AUTH-RESULTS] fields (optional);
	4. Add an [AUTH-RESULTS] header field to the message to indicate the		4. Add an [AUTH-RESULTS] header field to the message to indicate the
	results of the above;		results of the above;
	5. Remove all previously-evaluated DKIM signatures;		5. Remove all previously-evaluated DKIM signatures;
	6. Affix a new signature that covers the entire message on the		6. Affix a new signature that includes in in its hashes the entire
	output side, including the Authentication-Results header field		message on the output side, including the Authentication-Results
	just added (see Section 6.8).		header field just added (see Section 6.8).
	Removing the original signature(s) seems particularly appropriate		Removing the original signature(s) seems particularly appropriate
	when the MLM knows it is likely to invalidate any or all of them due		when the MLM knows it is likely to invalidate any or all of them due
	to the nature of the reformatting it will do. This avoids false		to the nature of the reformatting it will do. This avoids false
	negatives at the list's subscribers in their roles as receivers of		negatives at the list's subscribers in their roles as receivers of
	the message; although [DKIM] stipulates that an invalid signature is		the message; although [DKIM] stipulates that an invalid signature is
	the same as no signature, it is anticipated that there will be some		the same as no signature, it is anticipated that there will be some
	implementations that ignore this advice.		implementations that ignore this advice.
	The MLM could re-evaluate existing signatures after making its		The MLM could re-evaluate existing signatures after making its
	skipping to change at page 21, line 28 ¶		skipping to change at page 21, line 28 ¶
	A signing MLM could add a List-Post: {DKIM 12} header field (see		A signing MLM could add a List-Post: {DKIM 12} header field (see
	[LIST-URLS]) using that DNS domain matching the one used in the "d="		[LIST-URLS]) using that DNS domain matching the one used in the "d="
	tag of the DKIM signature that is added by the MLM. This can be used		tag of the DKIM signature that is added by the MLM. This can be used
	by {DKIM 12} verifiers or receivers to identify the DKIM signature		by {DKIM 12} verifiers or receivers to identify the DKIM signature
	that was added by the MLM. This is not required, however; it is		that was added by the MLM. This is not required, however; it is
	believed the reputation of the signer will be a more critical data		believed the reputation of the signer will be a more critical data
	point rather than this suggested binding. Furthermore, this is not a		point rather than this suggested binding. Furthermore, this is not a
	binding recognized by any current specification document.		binding recognized by any current specification document.
	Section 5.5 of [DKIM] includes a list of header fields that a
	signature SHOULD include in its header hash and discusses reasons for
	doing so. MLMs that sign MUST adhere to those guidelines, extended
	as follows: {DKIM 12}
	o Any [AUTH-RESULTS] fields added by the MLM;
	o Any [LIST-ID] or [LIST-URLS] fields added by the MLM;
	o Any [MAIL] fields, especially Sender and Reply-To, added or
	replaced by the MLM.
	A DKIM-aware resending MLM SHOULD sign the entire message after the		A DKIM-aware resending MLM SHOULD sign the entire message after the
	message is prepared for distribution (i.e. the "MLM Output" from		message is prepared for distribution (i.e. the "MLM Output" from
	Section 4.2). Any other configuration might generate signatures that		Section 4.2). Any other configuration might generate signatures that
	will not validate. {DKIM 12} As with any other DKIM signing		will not validate. {DKIM 12}
	operation, the choice of what portions of the header and body of the
	output message should include those parts of the header and body for
	which the MLM wishes to assert responsibility.
	DKIM-aware authoring MLMs MUST sign the mail they send according to		DKIM-aware authoring MLMs MUST sign the mail they send according to
	the regular signing guidelines given in [DKIM].		the regular signing guidelines given in [DKIM].
	One concern is that having an MLM apply its signature to unsigned		One concern is that having an MLM apply its signature to unsigned
	mail might cause some verifiers or receivers to interpret the		mail might cause some verifiers or receivers to interpret the
	signature as conferring more authority or authenticity to the message		signature as conferring more authority or authenticity to the message
	content than is defined by [DKIM]. This is an issue beyond MLMs and		content than is defined by [DKIM]. This is an issue beyond MLMs and
	primarily entails receive-side processing outside of the scope of		primarily entails receive-side processing outside of the scope of
	[DKIM]. It is nevertheless worth noting here. {DKIM 12}		[DKIM]. It is nevertheless worth noting here. {DKIM 12}
	skipping to change at page 28, line 16 ¶		skipping to change at page 27, line 16 ¶
	10.1. Normative References		10.1. Normative References
	[ADSP] Allman, E., Delany, M., Fenton, J., and J. Levine, "DKIM		[ADSP] Allman, E., Delany, M., Fenton, J., and J. Levine, "DKIM
	Sender Signing Practises", RFC 5617, August 2009.		Sender Signing Practises", RFC 5617, August 2009.
	[AUTH-RESULTS]		[AUTH-RESULTS]
	Kucherawy, M., "Message Header Field for Indicating		Kucherawy, M., "Message Header Field for Indicating
	Message Authentication Status", RFC 5451, April 2009.		Message Authentication Status", RFC 5451, April 2009.
	[DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,		[DKIM] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys
	J., and M. Thomas, "DomainKeys Identified Mail (DKIM)		Identified Mail (DKIM) Signatures",
	Signatures", RFC 4871, May 2007.		I-D draft-ietf-dkim-rfc4871bis, April 2011.
	[EMAIL-ARCH]		[EMAIL-ARCH]
	Crocker, D., "Internet Mail Architecture", RFC 5598,		Crocker, D., "Internet Mail Architecture", RFC 5598,
	July 2009.		July 2009.
	[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,
End of changes. 9 change blocks.
	40 lines changed or deleted		25 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/