< draft-ietf-dkim-mailinglists-10.txt		draft-ietf-dkim-mailinglists-11.txt >
	DKIM Working Group M. Kucherawy		DKIM Working Group M. Kucherawy
	Internet-Draft Cloudmark		Internet-Draft Cloudmark
	Intended status: BCP May 10, 2011		Intended status: BCP June 3, 2011
	Expires: November 11, 2011		Expires: December 5, 2011
	DKIM And Mailing Lists		DKIM And Mailing Lists
	draft-ietf-dkim-mailinglists-10		draft-ietf-dkim-mailinglists-11
	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 document provides guidance for
	provides guidance for the use of DKIM with scenarios that include		the use of DKIM with scenarios that include Mailing List Managers
	Mailing List Managers (MLMs).		(MLMs).
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 11, 2011.		This Internet-Draft will expire on December 5, 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 7, line 49 ¶		skipping to change at page 7, line 49 ¶
	A "message stream" identifies a group of messages originating from		A "message stream" identifies a group of messages originating from
	within an ADMD that are distinct in intent, origin and/or use, and		within an ADMD that are distinct in intent, origin and/or use, and
	partitions them somehow (i.e., via changing the value in the "d=" tag		partitions them somehow (i.e., via changing the value in the "d=" tag
	value in the context of DKIM) so as to keep them associated to users		value in the context of DKIM) so as to keep them associated to users
	yet distinct in terms of their evaluation and handling by verifiers		yet distinct in terms of their evaluation and handling by verifiers
	or receivers.		or receivers.
	A good example might be user mail generated by a company's employees,		A good example might be user mail generated by a company's employees,
	versus operational or transactional mail that comes from automated		versus operational or transactional mail that comes from automated
	sources, versus marketing or sales campaigns. Each of these could		sources, versus marketing or sales campaigns. Each of these could
	have different security policies imposed against them, or there might		have different sending policies imposed against them, or there might
	be a desire to insulate one from the other (e.g., a marketing		be a desire to insulate one from the other (e.g., a marketing
	campaign that gets reported by many spam filters could cause the		campaign that gets reported by many spam filters could cause the
	marketing stream's reputation to degrade without automatically		marketing stream's reputation to degrade without automatically
	punishing the transactional or user streams).		punishing the transactional or user streams).
	3. Mailing Lists and DKIM		3. Mailing Lists and DKIM
	It is important to make some distinctions among different styles of		It is important to make some distinctions among different styles of
	intermediaries, their typical implementations, and the effects they		intermediaries, their typical implementations, and the effects they
	have in a DKIM-aware environment.		have in a DKIM-aware environment.
	skipping to change at page 9, line 21 ¶		skipping to change at page 9, line 21 ¶
	3.1. Roles and Realities		3.1. Roles and Realities
	Across DKIM activities, there are several key roles in the transit of		Across DKIM activities, there are several key roles in the transit of
	a message. Most of these are defined in [EMAIL-ARCH], but are		a message. Most of these are defined in [EMAIL-ARCH], but are
	reviewed here for quick reference.		reviewed here for quick reference.
	author: The agent that provided the content of the message being		author: The agent that provided the content of the message being
	sent through the system. The author delivers that content to the		sent through the system. The author delivers that content to the
	originator in order to begin a message's journey to its intended		originator in order to begin a message's journey to its intended
	final recipients. The author can be a human using an MUA (Mail		final recipients. The author can be a human using an MUA (Mail
	User Agent) or a common system utility such as "cron", etc.		User Agent) or an automated process that may send mail (for
			example, the "cron" Unix system utility).
	originator: The agent that accepts a message from the author,		originator: The agent that accepts a message from the author,
	ensures it conforms to the relevant standards such as [MAIL], and		ensures it conforms to the relevant standards such as [MAIL], and
	then sends it toward its destination(s). This is often referred		then sends it toward its destination(s). This is often referred
	to as the Mail Submission Agent (MSA).		to as the Mail Submission Agent (MSA).
	signer: Any agent that affixes one or more DKIM signature(s) to a		signer: Any agent that affixes one or more DKIM signature(s) to a
	message on its way toward its ultimate destination. There is		message on its way toward its ultimate destination. There is
	typically a signer running at the MTA that sits between the		typically a signer running at the MTA that sits between the
	author's ADMD and the general Internet. The originator and/or		author's ADMD and the general Internet. The originator and/or
	author might also be a signer.		author might also be a signer.
	verifier: Any agent that conducts DKIM signature analysis. One is		verifier: Any agent that conducts DKIM signature validation. One is
	typically running at the MTA that sits between the public Internet		typically running at the MTA that sits between the public Internet
	and the receiver's ADMD. Note that any agent that handles a		and the receiver's ADMD. Note that any agent that handles a
	signed message can conduct verification; this document only		signed message can conduct verification; this document only
	considers that action and its outcomes either at an MLM or at the		considers that action and its outcomes either at an MLM or at the
	receiver. Filtering decisions could be made by this agent based		receiver. Filtering decisions could be made by this agent based
	on verification results.		on verification results.
	receiver: The agent that is the final transit relay for the message		receiver: The agent that is the final transit relay for the message
	and performs final delivery to the recipient(s) of the message.		and performs final delivery to the recipient(s) of the message.
	Filtering decisions based on results made by the verifier could be		Filtering decisions based on results made by the verifier could be
	applied by the receiver. The verifier and the receiver could be		applied by the receiver. The verifier and the receiver could be
	the same agent.		the same agent. This is sometimes the same as or coupled with the
			Mail Delivery Agent (MDA).
	In the case of simple user-to-user mail, these roles are fairly		In the case of simple user-to-user mail, these roles are fairly
	straightforward. However, when one is sending mail to a list, which		straightforward. However, when one is sending mail to a list, which
	then gets relayed to all of that list's subscribers, the roles are		then gets relayed to all of that list's subscribers, the roles are
	often less clear to the general user as particular agents may hold		often less clear to the general user as particular agents may hold
	multiple important but separable roles. The above definitions are		multiple important but separable roles. The above definitions are
	intended to enable more precise discussion of the mechanisms		intended to enable more precise discussion of the mechanisms
	involved.		involved.
	3.2. Types Of Mailing Lists		3.2. Types Of Mailing Lists
	skipping to change at page 14, line 16 ¶		skipping to change at page 14, line 16 ¶
	This section contains a discussion of issues regarding sending DKIM-		This section contains a discussion of issues regarding sending DKIM-
	signed mail to or through an MLM that is not DKIM-aware.		signed mail to or through an MLM that is not DKIM-aware.
	Specifically, the header fields introduced by [DKIM] and		Specifically, the header fields introduced by [DKIM] and
	[AUTH-RESULTS] carry no special meaning to such an MLM.		[AUTH-RESULTS] carry no special meaning to such an MLM.
	4.1. Author-Related Signing		4.1. Author-Related Signing
	In an idealized world, if an author knows that the MLM to which a		In an idealized world, if an author knows that the MLM to which a
	message is being sent is a non-participating resending MLM, the		message is being sent is a non-participating resending MLM, the
	author SHOULD be cautious when deciding whether or not to send a		author needs to be cautious when deciding whether or not to send a
	signed message to the list. The MLM could make a change that would		signed message to the list. The MLM could make a change that would
	invalidate the author's signature but not remove it prior to re-		invalidate the author's signature but not remove it prior to re-
	distribution. Hence, list recipients would receive a message		distribution. Hence, list recipients would receive a message
	purportedly from the author but bearing a DKIM signature that would		purportedly from the author but bearing a DKIM signature that would
	not verify. Some mail filtering software incorrectly penalizes a		not verify. Some mail filtering software incorrectly penalizes a
	message containing a DKIM signature that fails verification. This		message containing a DKIM signature that fails verification. This
	may have detrimental effects outside of the author's control.		may have detrimental effects outside of the author's control.
	(Additional discussion of this is below.) This problem can be		(Additional discussion of this is below.) This problem can be
	compounded if there are receivers that apply signing policies (e.g.,		compounded if there are receivers that apply signing policies (e.g.,
	[ADSP]) and the author publishes any kind of strict policy, i.e., a		[ADSP]) and the author publishes any kind of strict policy, i.e., a
	skipping to change at page 18, line 29 ¶		skipping to change at page 18, line 29 ¶
	influence over the management of an MLM. Specifically, the behavior		influence over the management of an MLM. Specifically, the behavior
	of an intermediary (e.g., an MLM that is not careful about filtering		of an intermediary (e.g., an MLM that is not careful about filtering
	out junk mail or being diligent about unsubscription requests) can		out junk mail or being diligent about unsubscription requests) can
	trigger recipient complaints that reflect back on those agents that		trigger recipient complaints that reflect back on those agents that
	appear to be responsible for the message, in this case an author via		appear to be responsible for the message, in this case an author via
	the address found in the RFC5322.From field. In the future, as DKIM		the address found in the RFC5322.From field. In the future, as DKIM
	signature outputs (i.e., the signing domain) are used as inputs to		signature outputs (i.e., the signing domain) are used as inputs to
	reputation modules, there may be a desire to insulate one's		reputation modules, there may be a desire to insulate one's
	reputation from influence by the unknown results of sending mail		reputation from influence by the unknown results of sending mail
	through an MLM. In that case, authors SHOULD create a mail stream		through an MLM. In that case, authors SHOULD create a mail stream
	specifically used for generating signatures when sending traffic to		specifically used for generating DKIM signatures when sending traffic
	MLMs.		to MLMs.
	This suggestion can be made more general. Mail that is of a		This suggestion can be made more general. Mail that is of a
	transactional or generally end-to-end nature, and not likely to be		transactional or generally end-to-end nature, and not likely to be
	forwarded around either by MLMs or users, SHOULD be signed with a		forwarded around either by MLMs or users, SHOULD be signed with a
	different mail stream identifier from a stream that serves more		different mail stream identifier from a stream that serves more
	varied uses.		varied uses.
	5.6. Verification Outcomes at MLMs		5.6. Verification Outcomes at MLMs
	MLMs typically attempt to authenticate messages posted through them.		MLMs typically attempt to authenticate messages posted through them.
	skipping to change at page 21, line 51 ¶		skipping to change at page 21, line 51 ¶
	by the MLM. This is not required, however; it is believed the		by the MLM. This is not required, however; it is believed the
	reputation of the signer will be a more critical data point rather		reputation of the signer will be a more critical data point rather
	than this suggested binding. Furthermore, this is not a binding		than this suggested binding. Furthermore, this is not a binding
	recognized by any current specification document.		recognized by any current specification document.
	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 3.2). Any other configuration might generate signatures that		Section 3.2). Any other configuration might generate signatures that
	will not validate.		will not validate.
	DKIM-aware authoring MLMs MUST sign the mail they send according to		DKIM-aware authoring MLMs sign the mail they send according to the
	the regular signing guidelines given in [DKIM].		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]. It is nevertheless worth noting here.
	5.9. Verification Outcomes at Final Receiving Sites		5.9. Verification Outcomes at Final Receiving Sites
	skipping to change at page 23, line 37 ¶		skipping to change at page 23, line 37 ¶
	This includes possibly processing the message as per ADSP		This includes possibly processing the message as per ADSP
	requirements.		requirements.
	Receivers SHOULD ignore or remove all unsigned externally-applied		Receivers SHOULD ignore or remove all unsigned externally-applied
	Authentication-Results header fields, and those not signed by an ADMD		Authentication-Results header fields, and those not signed by an ADMD
	that can be trusted by the receiver. See Section 5 and Section 7 of		that can be trusted by the receiver. See Section 5 and Section 7 of
	[AUTH-RESULTS] for further discussion.		[AUTH-RESULTS] for further discussion.
	Upon DKIM and ADSP evaluation during an SMTP session (a common		Upon DKIM and ADSP evaluation during an SMTP session (a common
	implementation), an agent MAY decide to reject a message during an		implementation), an agent MAY decide to reject a message during an
	SMTP session. If this is done, use of an [SMTP] failure code not		SMTP session. If this is done, [SMTP] stipulates that 550 is the
	normally used for "user unknown" (550) is preferred; therefore, 554		correct response code. However, if the SMTP server supports
	SHOULD be used. If the rejecting SMTP server supports [ENHANCED]		[ENHANCED] status codes, a status code not normally used for "user
	status codes, it SHOULD make a distinction between messages rejected		unknown" (5.1.1) is preferred; therefore, a 5.7.0 code SHOULD be
	deliberately due to policy decisions rather than those rejected		used. If the rejecting SMTP server supports this, it thus makes a
	because of other delivery issues. In particular, a policy rejection		distinction between messages rejected deliberately due to policy
	SHOULD be relayed using a 5.7.1 enhanced status code and some		decisions rather than those rejected because of other delivery
	appropriate wording in the text part of the reply, in contrast to a		issues. In particular, a policy rejection SHOULD be relayed using
	code of 5.1.1 indicating the user does not exist. Those MLMs that		the above enhanced status code and some appropriate wording in the
	automatically attempt to remove users with prolonged delivery		text part of the reply. Those MLMs that automatically attempt to
	problems (such as account deletion) SHOULD thus detect the difference		remove users with prolonged delivery problems (such as account
	between policy rejection and other delivery failures, and act		deletion) SHOULD thus detect the difference between policy rejection
	accordingly. SMTP servers doing so SHOULD also use appropriate		and other delivery failures, and act accordingly. It would be
	wording in the text portion of the reply, perhaps explicitly using		beneficial for SMTP servers doing so to also use appropriate wording
	the string "ADSP" to facilitate searching of relevant data in logs.		in the text portion of the reply, perhaps explicitly using the string
			"ADSP" to facilitate searching for relevant data in logs.
	The preceding paragraph does not apply to an [ADSP] policy of		The preceding paragraph does not apply to an [ADSP] policy of
	"discardable". In such cases where the submission fails that test,		"discardable". In such cases where the submission fails that test,
	the receiver or verifier SHOULD discard the message but return an		the receiver or verifier SHOULD discard the message but return an
	SMTP success code, i.e. accept the message but drop it without		SMTP success code, i.e. accept the message but drop it without
	delivery. An SMTP rejection of such mail instead of the requested		delivery. An SMTP rejection of such mail instead of the requested
	discard action causes more harm than good.		discard action causes more harm than good.
	6. DKIM Reporting		6. DKIM Reporting
End of changes. 12 change blocks.
	31 lines changed or deleted		34 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/