< draft-ietf-dkim-mailinglists-00.txt		draft-ietf-dkim-mailinglists-01.txt >
	DKIM Working Group M. Kucherawy		DKIM Working Group M. Kucherawy
	Internet-Draft Cloudmark		Internet-Draft Cloudmark
	Intended status: Informational June 3, 2010		Intended status: Informational July 26, 2010
	Expires: December 5, 2010		Expires: January 27, 2011
	DKIM And Mailing Lists		DKIM And Mailing Lists
	draft-ietf-dkim-mailinglists-00		draft-ietf-dkim-mailinglists-01
	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. As the		domain (ADMD) to assume some responsibility for a message. As the
	industry has now gained some deployment experience, the goal for this		industry has now gained some deployment experience, the goal for this
	document is to explore the use of DKIM for scenarios that include		document is to explore the use of DKIM for scenarios that include
	intermediaries, such as Mailing List Managers (MLMs).		intermediaries, such as 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 December 5, 2010.		This Internet-Draft will expire on January 27, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2010 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 19 ¶		skipping to change at page 2, line 19 ¶
	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. Other Terms . . . . . . . . . . . . . . . . . . . . . . . 7		2.1. Other Terms . . . . . . . . . . . . . . . . . . . . . . . 7
	2.2. DKIM-Specific References . . . . . . . . . . . . . . . . . 7		2.2. DKIM-Specific References . . . . . . . . . . . . . . . . . 7
	2.3. Feedback Loop References . . . . . . . . . . . . . . . . . 7		2.3. Feedback Loop References . . . . . . . . . . . . . . . . . 7
	2.4. Message Streams . . . . . . . . . . . . . . . . . . . . . 7		2.4. Message Streams . . . . . . . . . . . . . . . . . . . . . 7
	3. Mailing Lists and DKIM . . . . . . . . . . . . . . . . . . . . 8		3. Mailing Lists and DKIM . . . . . . . . . . . . . . . . . . . . 8
	3.1. Roles and Realities . . . . . . . . . . . . . . . . . . . 8		3.1. Roles and Realities . . . . . . . . . . . . . . . . . . . 8
	3.2. Types Of Mailing Lists Lists . . . . . . . . . . . . . . . 9		3.2. Types Of Mailing Lists . . . . . . . . . . . . . . . . . . 9
	3.3. Current MLM Effects On Signatures . . . . . . . . . . . . 10		3.3. Current MLM Effects On Signatures . . . . . . . . . . . . 10
	3.4. Alternatives of Participation and Conformance . . . . . . 11		3.4. Alternatives of Participation and Conformance . . . . . . 11
	4. Non-Participating MLMs . . . . . . . . . . . . . . . . . . . . 13		4. Non-Participating MLMs . . . . . . . . . . . . . . . . . . . . 13
	4.1. Author-Related Signing . . . . . . . . . . . . . . . . . . 13		4.1. Author-Related Signing . . . . . . . . . . . . . . . . . . 13
	4.2. Verification Outcomes at Receivers . . . . . . . . . . . . 13		4.2. Verification Outcomes at Receivers . . . . . . . . . . . . 13
	4.3. Handling Choices at Receivers . . . . . . . . . . . . . . 14		4.3. Handling Choices at Receivers . . . . . . . . . . . . . . 14
	5. Participating MLMs . . . . . . . . . . . . . . . . . . . . . . 15		5. Participating MLMs . . . . . . . . . . . . . . . . . . . . . . 15
	5.1. Subscriptions . . . . . . . . . . . . . . . . . . . . . . 15		5.1. Subscriptions . . . . . . . . . . . . . . . . . . . . . . 15
	5.2. Author-Related Signing . . . . . . . . . . . . . . . . . . 15		5.2. Author-Related Signing . . . . . . . . . . . . . . . . . . 15
	5.3. Verification Outcomes at MLMs . . . . . . . . . . . . . . 15		5.3. Verification Outcomes at MLMs . . . . . . . . . . . . . . 16
	5.4. Pros and Cons of Signature Removal . . . . . . . . . . . . 16		5.4. Pros and Cons of Signature Removal . . . . . . . . . . . . 16
	5.5. MLM Signatures . . . . . . . . . . . . . . . . . . . . . . 17		5.5. DKIM Author Domain Signing Practices . . . . . . . . . . . 17
	5.6. Verification Outcomes at Final Receiving Sites . . . . . . 18		5.6. MLM Signatures . . . . . . . . . . . . . . . . . . . . . . 18
	5.7. Use With FBLs . . . . . . . . . . . . . . . . . . . . . . 18		5.7. Verification Outcomes at Final Receiving Sites . . . . . . 19
	5.8. Handling Choices at Receivers . . . . . . . . . . . . . . 19		5.8. Use With FBLs . . . . . . . . . . . . . . . . . . . . . . 19
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20		5.9. Handling Choices at Receivers . . . . . . . . . . . . . . 20
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 21		6. DKIM Reporting . . . . . . . . . . . . . . . . . . . . . . . . 21
	7.1. Authentication Results When Relaying . . . . . . . . . . . 21		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22		8. Security Considerations . . . . . . . . . . . . . . . . . . . 23
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 22		8.1. Authentication Results When Relaying . . . . . . . . . . . 23
	8.2. Informative References . . . . . . . . . . . . . . . . . . 22		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 24		9.1. Normative References . . . . . . . . . . . . . . . . . . . 24
	Appendix B. Example Scenarios . . . . . . . . . . . . . . . . . . 25		9.2. Informative References . . . . . . . . . . . . . . . . . . 24
	B.1. MLMs and ADSP . . . . . . . . . . . . . . . . . . . . . . 25		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 26
	B.2. MLMs and FBLs . . . . . . . . . . . . . . . . . . . . . . 25		Appendix B. Example Scenarios . . . . . . . . . . . . . . . . . . 27
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26		B.1. MLMs and ADSP . . . . . . . . . . . . . . . . . . . . . . 27
			B.2. MLMs and FBLs . . . . . . . . . . . . . . . . . . . . . . 27
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 28
	1. Introduction		1. Introduction
	[DKIM] allows an Administrative Mail Domain to take some		[DKIM] allows an Administrative Mail Domain to take some
	responsibility for a [MAIL] message. This can be an author's		responsibility for a [MAIL] message. This can be an author's
	organization, an operational relay (Mail Transfer Agent, or MTA) or		organization, an operational relay (Mail Transfer Agent, or MTA) or
	one of their agents. Assertion of responsibility is made through a		one of their agents. Assertion of responsibility is made through a
	cryptographic signature. Message transit from author to recipient is		cryptographic signature. Message transit from author to recipient is
	through relays that typically make no substantive change to the		through relays that typically make no substantive change to the
	message content and thus preserve the DKIM signature.		message content and thus preserve the DKIM signature.
	skipping to change at page 4, line 8 ¶		skipping to change at page 4, line 8 ¶
	through a gateway. Although not the only possibility, this is most		through a gateway. Although not the only possibility, this is most
	commonly done as a message passes through a Mail Transport Agent		commonly done as a message passes through a Mail Transport Agent
	(MTA) as it departs an Administrative Mail Domain (ADMD) toward the		(MTA) as it departs an Administrative Mail Domain (ADMD) toward the
	general Internet.		general Internet.
	DKIM signatures will fail to verify if a portion of the message		DKIM signatures will fail to verify if a portion of the message
	covered by one of its hashes is altered. MLMs commonly alter		covered by one of its hashes is altered. MLMs commonly alter
	messages to provide information specific to the mailing list for		messages to provide information specific to the mailing list for
	which it is providing service. Common modifications include:		which it is providing service. Common modifications include:
	o Prefix the Subject: header field with a short string for easy		o Prefix the RFC5322.Subject field with a short string for easy
	sorting by receivers' Mail User Agents (MUAs) or other filtering		sorting by receivers' Mail User Agents (MUAs) or other filtering
	software;		software;
	o Prepend or append list management information to the message's		o Prepend or append list management information to the message's
	body, such as some text and/or a URL to which subscribers can go		body, such as some text and/or a URL to which subscribers can go
	to make administrative changes to their subscriptions;		to make administrative changes to their subscriptions;
	o Add header fields such as Reply-To:, Sender:, Resent-Sender:		o Add header fields such as Reply-To:, Sender:, Resent-Sender:
	([MAIL]), List-Id: ([LIST-ID]), List-Post: or List-Unsubscribe:		([MAIL]), List-Id: ([LIST-ID]), List-Post: or List-Unsubscribe:
	([LIST-URLS]). In some cases, such header fields are replaced if		([LIST-URLS]). In some cases, such header fields are replaced if
	the original message already contained them.		the original message already contained them.
			The above list is not exhaustive, but instead only lists common
			modifications. It also does not consider changes the MTA might make
			independent of what changes the MLM chooses to apply.
	The DKIM specification documents deliberately refrain from the notion		The DKIM specification documents deliberately refrain from the notion
	of tying the signing domain (the "d=" tag in a DKIM signature) to any		of tying the signing domain (the "d=" tag in a DKIM signature) to any
	identifier within a message; any ADMD could sign any message		identifier within a message; any ADMD could sign any message
	regardless of its origin or author domain. As such, there is no		regardless of its origin or author domain. As such, there is no
	specification of any additional value if the content of the "d=" tag		specification of any additional value if the content of the "d=" tag
	in the DKIM signature and the value of (for example) the From header		in the DKIM signature and the value of (for example) the RFC5322.From
	field match, nor is there any obvious degraded value to a signature		field match, nor is there any obvious degraded value to a signature
	where they do not match. Since any DKIM signature is merely an		where they do not match. Since any DKIM signature is merely an
	assertion of "some" responsibility by an ADMD, a DKIM signature added		assertion of "some" responsibility by an ADMD, a DKIM signature added
	by an MLM has no more, or less, meaning as a signature with any other		by an MLM has no more, or less, meaning as a signature with any other
	"d=" value.		"d=" value.
	1.2. MLMs In Infrastructure		1.2. MLMs In Infrastructure
	The previous section describes some of the things MLMs commonly do		The previous section describes some of the things MLMs commonly do
	that are not DKIM-friendly, producing broken signatures and thus		that are not DKIM-friendly, producing broken signatures and thus
	skipping to change at page 5, line 4 ¶		skipping to change at page 5, line 8 ¶
	in the context of MLMs needs to be incremental and value-based.		in the context of MLMs needs to be incremental and value-based.
	MLM behaviors are well-established and standards compliant. Thus,		MLM behaviors are well-established and standards compliant. Thus,
	the best approach is to provide these best practices to all parties		the best approach is to provide these best practices to all parties
	involved, imposing the minimum requirements possible to MLMs		involved, imposing the minimum requirements possible to MLMs
	themselves.		themselves.
	An MLM is an autonomous agent that takes delivery of a message		An MLM is an autonomous agent that takes delivery of a message
	delivered to it and can re-post it as a new message (or construct a		delivered to it and can re-post it as a new message (or construct a
	digest of it along with other messages) to the members of the list		digest of it along with other messages) to the members of the list
	(see [EMAIL-ARCH], Section 5.3). However, the fact that the From		(see [EMAIL-ARCH], Section 5.3). However, the fact that the
	field of such a message is typically the same as for the original		RFC5322.From field of such a message is typically the same as for the
	message and that recipients perceive the message as "from" the		original message and that recipients perceive the message as "from"
	original author rather than the MLM creates confusion about		the original author rather than the MLM creates confusion about
	responsibility and autonomy for the re-posted message. This has		responsibility and autonomy for the re-posted message. This has
	important implications for use of DKIM.		important implications for use of DKIM.
	A DKIM signature on a message is an expression of some responsibility		A DKIM signature on a message is an expression of some responsibility
	for the message taken by the signing domain. An open question, one		for the message taken by the signing domain. An open question, one
	this document intends to address, is some idea of how such a		this document intends to address, is some idea of how such a
	signature might be applied by an recipient's evaluation module after		signature might be applied by an recipient's evaluation module after
	the message has gone through a mailing list, and may or may not have		the message has gone through a mailing list, and may or may not have
	been invalidated, and if so, where the invalidation may have		been invalidated, and if so, where the invalidation may have
	happened.		happened.
	skipping to change at page 9, line 5 ¶		skipping to change at page 9, line 5 ¶
	prior to being delivered to the recipient(s) of the message.		prior to being delivered to the recipient(s) of the message.
	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 Lists		3.2. Types Of Mailing Lists
	There are four common MLM implementation modes:		There are four common MLM implementation modes:
	aliasing: An aliasing MLM (see Section 5.1 of [EMAIL-ARCH]) is one		aliasing: An aliasing MLM (see Section 5.1 of [EMAIL-ARCH]) is one
	that makes no changes to a message as it redistributes; any		that makes no changes to a message as it redistributes; any
	modifications are constrained to changes to the [SMTP] envelope		modifications are constrained to changes to the [SMTP] envelope
	recipient list (RCPT commands) only. There are no changes to the		recipient list (RCPT commands) only. There are no changes to the
	message body at all and only [MAIL] trace header fields are added.		message body at all and only [MAIL] trace header fields are added.
	The output of such an MLM is considered to be a continuation of		The output of such an MLM is considered to be a continuation of
	the author's original message. An example of such an MLM is a		the author's original message. An example of such an MLM is a
	address that expands directly in the MTA, such as a list of local		address that expands directly in the MTA, such as a list of local
	system administrators used for relaying operational or other		system administrators used for relaying operational or other
	internal-only messages.		internal-only messages. See also Section 3.9.2 of [SMTP].
	resending: A resending MLM (see Sections 5.2 and 5.3 of		resending: A resending MLM (see Sections 5.2 and 5.3 of
	[EMAIL-ARCH]) is one that may make changes to a message. The		[EMAIL-ARCH]) is one that may make changes to a message. The
	output of such an MLM is considered to be a new message; delivery		output of such an MLM is considered to be a new message; delivery
	of the original has been completed prior to distribution of the		of the original has been completed prior to distribution of the
	re-posted message. Such messages are often re-formatted, such as		re-posted message. Such messages are often re-formatted, such as
	with list-specific header fields or other properties, to		with list-specific header fields or other properties, to
	facilitate discussion among list subscribers.		facilitate discussion among list subscribers.
	authoring: An authoring MLM is one that creates the content being		authoring: An authoring MLM is one that creates the content being
	skipping to change at page 9, line 44 ¶		skipping to change at page 9, line 44 ¶
	list's full set of recipients. Examples include newsletters and		list's full set of recipients. Examples include newsletters and
	bulk marketing mail.		bulk marketing mail.
	digesting: A special case of the re-posting MLM is one that sends a		digesting: A special case of the re-posting MLM is one that sends a
	single message comprising an aggregation of recent MLM submissons,		single message comprising an aggregation of recent MLM submissons,
	which might be a message of [MIME] type "multipart/digest" (see		which might be a message of [MIME] type "multipart/digest" (see
	[MIME-TYPES]). This is obviously a new message but it may contain		[MIME-TYPES]). This is obviously a new message but it may contain
	a sequence of original messages that may themselves have been		a sequence of original messages that may themselves have been
	DKIM-signed.		DKIM-signed.
	The remainder of this document operates on the presumption that a		In the remainder of this document we distinguish Two relevant steps,
	message going through a resending MLM actually comprises two message		corresponding to the following SMTP transactions:
	transactions:
	1. Originating user to MLM: Originating user is author; originating		MLM Input: Originating user is author; originating ADMD is signer;
	ADMD is signer; MLM's ADMD is verifier; MLM's input function is		MLM's ADMD is verifier; MLM's input function is receiver.
	receiver.
	2. MLM to receivers: MLM (sending its reconstructed copy of the		MLM Output: MLM (sending its reconstructed copy of the originating
	originating user's message) is author; MLM's ADMD is signer; the		user's message) is author; MLM's ADMD is signer; the ADMD of each
	ADMD of each subscriber of the list is a verifier; each		subscriber of the list is a verifier; each subscriber is a
	subscriber is a receiver.		receiver.
	Much of this document focuses on the resending MLM as it has the most		Much of this document focuses on the resending MLM as it has the most
	direct conflict operationally with DKIM.		direct conflict operationally with DKIM.
	The dissection of the overall MLM operation into these two distinct		The dissection of the overall MLM operation into these two distinct
	steps allows the DKIM-specific issues with respect to MLMs to be		steps allows the DKIM-specific issues with respect to MLMs to be
	isolated and handled in a logical way. The main issue is that the		isolated and handled in a logical way. The main issue is that the
	repackaging and reposting of a message by an MLM is actually the		repackaging and reposting of a message by an MLM is actually the
	construction of a completely new message, and as such the MLM is		construction of a completely new message, and as such the MLM is
	introducing new content into the email ecosystem, consuming the		introducing new content into the email ecosystem, consuming the
	author's copy of the message and creating its own. When considered		author's copy of the message and creating its own. When considered
	in this way, the dual role of the MLM and its ADMD becomes clear.		in this way, the dual role of the MLM and its ADMD becomes clear.
			Some issues about these activities are discussed in Section 3.6.4 of
			[MAIL] and in Section 3.4.1 of [EMAIL-ARCH].
	3.3. Current MLM Effects On Signatures		3.3. Current MLM Effects On Signatures
	As described above, an aliasing MLM does not affect any existing		As described above, an aliasing MLM does not affect any existing
	signature, and an authoring MLM is always new content and thus there		signature, and an authoring MLM is always new content and thus there
	is never an existing signature. However, the changes a resending MLM		is never an existing signature. However, the changes a resending MLM
	can make typically affect the Subject: header field, addition of some		can make typically affect the RFC5322.Subject header field, addition
	list-specific header fields, and/or the addition of some list-		of some list-specific header fields, and/or the addition of some
	specific text to the top or bottom of the message body. The impacts		list-specific text to the top or bottom of the message body. The
	of each of these on DKIM verification are discussed below.		impacts of each of these on DKIM verification are discussed below.
	Subject tags: Altering the Subject: header field will invalidate the		Subject tags: Altering the RFC5322.Subject field by adding a list-
	signer's signature if that header field was covered by a hash of		specific prefix will invalidate the signer's signature if that
	that signature. [DKIM] lists Subject as one that should be		header field was covered by a hash of that signature. [DKIM]
	covered, so this is expected to be an issue for any list that		lists RFC5322.Subject as one that should be covered, so this is
	makes such changes.		expected to be an issue for any list that makes such changes.
	List-specific header fields: Some lists will add header fields		List-specific header fields: Some lists will add header fields
	specific to list administrative functions such as those defined in		specific to list administrative functions such as those defined in
	[LIST-ID] and [LIST-URLS], or the "Resent-" fields defined in		[LIST-ID] and [LIST-URLS], or the "Resent-" fields defined in
	[MAIL]. It is unlikely that a typical MUA would include such		[MAIL]. It is unlikely that a typical MUA would include such
	fields in an original message, and DKIM is resilient to the		fields in an original message, and DKIM is resilient to the
	addition of header fields in general (though see notes about the		addition of header fields in general (though see notes about the
	"h=" tag in Section 3.5 of [DKIM]). Therefore this is seen as		"h=" tag in Section 3.5 of [DKIM]). Therefore this is seen as
	less of a concern.		less of a concern.
	skipping to change at page 11, line 21 ¶		skipping to change at page 11, line 28 ¶
	pose an immediate problem.		pose an immediate problem.
	Major body changes: There are some MLMs that make more substantial		Major body changes: There are some MLMs that make more substantial
	changes to message bodies when preparing them for re-distribution,		changes to message bodies when preparing them for re-distribution,
	such as deleting, reordering, or reformatting [MIME] parts,		such as deleting, reordering, or reformatting [MIME] parts,
	"flatten" HTML messages into plain text, or insert headers or		"flatten" HTML messages into plain text, or insert headers or
	footers within HTML messages. Most or all of these changes will		footers within HTML messages. Most or all of these changes will
	invalidate a DKIM signature with little or no hope of compensation		invalidate a DKIM signature with little or no hope of compensation
	by either the signer or the verifier.		by either the signer or the verifier.
			MIME part removal: Some MLMs that are MIME-aware will remove large
			MIME parts from submissions and replace them with URLs to reduce
			the size of the distributed form of the message and to prevent
			inadvertent automated malware delivery.
	There reportedly still exist a few scattered mailing lists in		There reportedly still exist a few scattered mailing lists in
	operation that are actually run manually by a human list manager.		operation that are actually run manually by a human list manager.
	In general, an MLM subscriber cannot be expected to be able to		In general, an MLM subscriber cannot be expected to be able to
	reconstruct the original message as it appeared at time of signing		reconstruct the original message as it appeared at time of signing
	and thus whether or not an author signature is actually valid after		and thus whether or not an author signature is actually valid after
	MLM rewriting. Moreover, even if an MLM currently passes messages		MLM rewriting. Moreover, even if an MLM currently passes messages
	unmodified such that author signatures validate, it is possible that		unmodified such that author signatures validate, it is possible that
	a configuration change or software upgrade to that MLM will cause		a configuration change or software upgrade to that MLM will cause
	that no longer to be true.		that no longer to be true.
	skipping to change at page 13, line 5 ¶		skipping to change at page 12, line 23 ¶
	change will invalidate the signature on a message where the body hash		change will invalidate the signature on a message where the body hash
	covers the entire entire message. Thus, the following sections also		covers the entire entire message. Thus, the following sections also
	investigate and recommend other processing alternatives.		investigate and recommend other processing alternatives.
	A possible mitigation to this incompatibility is use of the "l=" tag		A possible mitigation to this incompatibility is use of the "l=" tag
	to bound the portion of the body covered by the body hash, but this		to bound the portion of the body covered by the body hash, but this
	not workable for [MIME] messages and moreover has security		not workable for [MIME] messages and moreover has security
	considerations (see Section 3.5 of [DKIM]). Its use is therefore		considerations (see Section 3.5 of [DKIM]). Its use is therefore
	discouraged.		discouraged.
			There is currently no header field proposed for relaying general list
			policy details, apart from what [LIST-URLS] already supports. This
			sort of information is what is commonly included in appended footer
			text or prepended header text. Rather than anticipating or proposing
			a new field here for that purpose, the working group recommends
			periodic, automatic mailings to the list to remind subscribers of
			list policy. These will be repetitive, of course, but by being
			generally the same each time they can be easily filtered if needed.
	4. Non-Participating MLMs		4. Non-Participating MLMs
	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
	If an author knows that the MLM to which a message is being sent is a		If an author knows that the MLM to which a message is being sent is a
	skipping to change at page 13, line 47 ¶		skipping to change at page 13, line 47 ¶
	of mail from within an ADMD, such as user-created "direct" mail from		of mail from within an ADMD, such as user-created "direct" mail from
	transactional or automated mail; some of these may be signed and some		transactional or automated mail; some of these may be signed and some
	not, some with published ADSP records, some not. In general, the		not, some with published ADSP records, some not. In general, the
	more strict practices and policies are likely to be successful only		more strict practices and policies are likely to be successful only
	for the mail streams subject to the most end-to-end control by the		for the mail streams subject to the most end-to-end control by the
	originating organization. That typically excludes mail going through		originating organization. That typically excludes mail going through
	MLMs.		MLMs.
	4.2. Verification Outcomes at Receivers		4.2. Verification Outcomes at Receivers
	Verifiers that receive mail bearing DKIM signatures that fail to		There does not appear to be a reliable way to determine that a piece
	verify might benefit from attempting to detect that such mail passed		of mail arrived via a non-participating MLM. Thus, it is not
	through a non-participating MLM and then decide not to apply [ADSP]		reasonably possible to suggest any particular processing heuristics
	in order to avoid aggressive filtering of mail that should otherwise		specific to this case with respect to DKIM and ADSP.
	have been delivered.
	Unfortunately, there may not be a reliable way of making such
	determinations, as there is no uniform MLM behaviour, and any tagging
	mechanism meant to relay such information could easily be abused.
	Note that the underlying problem is the operational choice to use
	ADSP in a message stream that does not maintain the signature.
	4.3. Handling Choices at Receivers		4.3. Handling Choices at Receivers
	A receiver's ADMD would have to have some way to register such non-		A receiver's ADMD would have to have some way to register such non-
	participating lists to exempt them from the filtering described in		participating lists to exempt them from the filtering described in
	Section 4.1. This is, however, probably not a scalable solution as		Section 4.1. This is, however, probably not a scalable solution as
	it imposes a burden on the receiver that is predicated on sender		it imposes a burden on the receiver that is predicated on sender
	behaviour.		behaviour.
	Note that the [DKIM] specification explicitly directs verifiers to		Note that the [DKIM] specification explicitly directs verifiers to
	skipping to change at page 15, line 19 ¶		skipping to change at page 15, line 19 ¶
	ADSP-aware.		ADSP-aware.
	5.1. Subscriptions		5.1. Subscriptions
	At subscription time, an ADSP-aware MLM could check for a published		At subscription time, an ADSP-aware MLM could check for a published
	ADSP record for the new subscriber, and present a warning for one		ADSP record for the new subscriber, and present a warning for one
	whose ADMD's published policy is "discardable" indicating that		whose ADMD's published policy is "discardable" indicating that
	submissions from that ADMD may not be deliverable because of		submissions from that ADMD may not be deliverable because of
	modifications that are likely to be made to the message.		modifications that are likely to be made to the message.
			Of course, such a policy could be applied after subscription, so this
			is not a universal solution. An MLM implementation could do periodic
			checks of its subscribers and issue warnings where such a policy is
			detected.
	5.2. Author-Related Signing		5.2. Author-Related Signing
	MLMs typically attempt to authenticate messages posted through them.		MLMs typically attempt to authenticate messages posted through them.
	They usually do this through the trivial (and insecure) means of		They usually do this through the trivial (and insecure) means of
	verifying the From field email address against a list registry. DKIM		verifying the RFC5322.From field email address (or, less frequently,
			the RFC5321.MailFrom parameter) against a list registry. DKIM
	enables a stronger form of authentication, although this is not yet		enables a stronger form of authentication, although this is not yet
	formally documented: It can require that messages using a given From		formally documented: It can require that messages using a given
	address also have a DKIM signature with a corresponding "d=" domain.		RFC5322.From address also have a DKIM signature with a corresponding
	(Note, however, that it is entirely reasonable for an MLM to permit		"d=" domain. (Note, however, that it is entirely reasonable for an
	registration of some other "d=" domain as valid evidence of such		MLM to permit registration of some other "d=" domain as valid
	authentication.) This feature would be somewhat similar to using		evidence of such authentication.) This feature would be somewhat
	ADSP, except that the requirement for it would be imposed by the MLM		similar to using ADSP, except that the requirement for it would be
	and not the author's organization.		imposed by the MLM and not the author's organization.
	An important consideration is that authors rarely have any direct		An important consideration is that authors rarely have any direct
	influence over the management of an MLM. As such, a signed message		influence over the management of an MLM. As such, a signed message
	from an author will in essence go to a set of unexpected places.		from an author will in essence go to a set of unexpected places.
	Authors may be well-advised to create a mail stream specifically used		Authors may be well-advised to create a mail stream specifically used
	for generating signatures when sending traffic to MLMs. This becomes		for generating signatures when sending traffic to MLMs. This becomes
	important as domain-based reputation systems begin to appear as		important as domain-based reputation systems begin to appear as
	components of mail filtering modules.		components of mail filtering modules.
	This suggestion can be made more general. Mail that is of a		This suggestion can be made more general. Mail that is of a
	skipping to change at page 16, line 36 ¶		skipping to change at page 16, line 43 ¶
	further discussion.		further discussion.
	5.4. Pros and Cons of Signature Removal		5.4. Pros and Cons of Signature Removal
	If the MLM is configured to make changes to the message prior to re-		If the MLM is configured to make changes to the message prior to re-
	posting that would invalidate the original signature(s), further		posting that would invalidate the original signature(s), further
	action is recommended to prevent invalidated signatures from arriving		action is recommended to prevent invalidated signatures from arriving
	at final recipients, possibly triggering unwarranted filter actions.		at final recipients, possibly triggering unwarranted filter actions.
	A possible solution would be to:		A possible solution would be to:
	1. Attempt verification of all DKIM signatures present on the		1. Attempt verification of all DKIM signatures present on the input
	message;		message;
	2. Apply local policy to authenticate the identity of the author;		2. Apply local policy to authenticate the identity of the author;
	3. Add an [AUTH-RESULTS] header field to the message to indicate the		3. Add an [AUTH-RESULTS] header field to the message to indicate the
	results of the above;		results of the above;
	4. Remove all previously-evaluated DKIM signatures;		4. Remove all previously-evaluated DKIM signatures;
	5. Affix a new signature that covers the Authentication-Results		5. Affix a new signature that covers the Authentication-Results
	header field just added.		header field just added.
	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.		the message; although [DKIM] stipulates that an invalid signature is
			the same as no signature, it is anticipated that there will be some
			implementations to the contrary.
	However, per the discussion in [AUTH-RESULTS], there is no a priori		The MLM could re-evaluate exisiting signatures after making its
	reason for the final receivers to put any faith in the veracity of		message changes to determine whether or not any of them have been
	that header field when added by the MLM. Thus, the final recipients		invalidated. The cost of this is reduced by the fact that,
	of the message have no way to verify on their own the authenticity of		presumably, the necessary public keys have already been downloaded
	the author's identity on that message.		and one or both of the message hashes could be reused.
			Per the discussion in [AUTH-RESULTS], there is no a priori reason for
			the final receivers to put any faith in the veracity of that header
			field when added by the MLM. Thus, the final recipients of the
			message have no way to verify on their own the authenticity of the
			author's identity on that message. However, should that field be the
			only one on the message when the verifier gets it, and the verifier
			explicitly trusts the signer (in this case, the MLM), the verifier is
			in a position to believe that a valid author signature was present on
			the message.
	Since an aliasing MLM makes no substantive changes to a message, it		Since an aliasing MLM makes no substantive changes to a message, it
	need not consider the issue of signature removal as the original		need not consider the issue of signature removal as the original
	signatures should arrive at least to the next MTA unmodified. It is		signatures should arrive at least to the next MTA unmodified. It is
	possible that future domain-based reputations would prefer a more		possible that future domain-based reputations would prefer a more
	rich data set on receipt of a message, and in that case signature		rich data set on receipt of a message, and in that case signature
	removal would be undesirable.		removal would be undesirable.
	An authoring MLM is closed to outside submitters, thus much of this		An authoring MLM is closed to outside submitters, thus much of this
	discussion does not apply in that case.		discussion does not apply in that case.
			5.5. 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 receivers. It is the consensus of the working group		severe action by receivers. It is the consensus of the working group
	that a resending MLM is advised to reject outright any mail from an		that a resending MLM is advised to reject outright any mail from an
	author whose domain posts such a policy as it is likely to be		author whose domain posts such a policy as it is likely to be
	rejected by any ADSP-aware recipients, and might also be well advised		rejected by any ADSP-aware recipients, and might also be well advised
	to present a warning to such subscribers when first signing up to the		to present a warning to such subscribers when first signing up to the
	list.		list.
	5.5. MLM Signatures		Where the above practice is not observed and "discardable" mail
			arrives via a list to a verifier that applies ADSP checks, the
			verifier can either discard the message (i.e. accept the message at
			the [SMTP] level but discard it without delivery) or conduct an SMTP
			rejection by 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 in Section 5.9.
			5.6. MLM Signatures
	DKIM-aware resending MLMs and authoring MLMs are encouraged to affix		DKIM-aware resending MLMs and authoring MLMs are encouraged to affix
	their own signatures when distributing messages. The MLM is		their own signatures when distributing messages. The MLM is
	responsible for the alterations it makes to the original messages it		responsible for the alterations it makes to the original messages it
	is re-sending, and should express this via a signature. This is also		is re-sending, and should express this via a signature. This is also
	helpful for getting feedback from any FBLs that might be set up so		helpful for getting feedback from any FBLs that might be set up so
	that undesired list mail can generate appropriate action.		that undesired list mail can generate appropriate action.
	A signing MLM is, as any other MLM, free to omit redistribution of a		A signing MLM is, as any other MLM, free to omit redistribution of a
	message from an author if that message was not signed in accordance		message from an author if that message was not signed in accordance
	with its own local configuration or policy. However, selective		with its own local configuration or policy. However, selective
	signing is discouraged; essentially that would create two message		signing is discouraged; essentially that would create two message
	streams from the MLM, which can confuse verifiers and receivers.		streams from the MLM, one signed and one not, which can confuse DKIM-
			aware verifiers and receivers.
			As is typical with DKIM signing, the MLM signature must be generated
			only after all modifications the MLM wishes to apply have been
			completed. Failing to do so generates a signature that can not be
			expected to validate.
	A signing MLM is advised to add a List-Post: header field (see		A signing MLM is advised to add a List-Post: header field (see
	[LIST-URLS]) using a DNS domain matching what will be used in the		[LIST-URLS]) using a DNS domain matching what will be used in the
	"d=" tag of the DKIM signature it will add to the new message. This		"d=" tag of the DKIM signature it will add to the new message. This
	could be used by verifiers or receivers to identify the DKIM		could be used by verifiers or receivers to identify the DKIM
	signature that was added by the MLM.		signature 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 point rather than this suggested binding.
	Such MLMs are advised to ensure the signature's header hash will		Such MLMs are advised to ensure the signature's header hash will
	cover:		cover:
	o Any [AUTH-RESULTS] fields added by the MLM;		o Any [AUTH-RESULTS] fields added by the MLM;
	o Any [LIST-ID] or [LIST-URLS] 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		o Any [MAIL] fields, especially Sender and Reply-To, added or
	replaced by the MLM.		replaced by the MLM.
	A DKIM-aware resending MLM is encouraged to sign the entire message		A DKIM-aware resending MLM is encouraged to sign the entire message
	as it arrived, especially including the original signatures.		as it arrived (i.e. the "MLM Input" from Section 3.2), especially
			including the original signatures.
	DKIM-aware authoring MLMs are advised to sign the mail they send		DKIM-aware authoring MLMs are advised to sign the mail they send
	according to the regular signing guidelines given in [DKIM].		according to the regular signing guidelines given in [DKIM].
	Operators of non-DKIM-aware MLMs could arrange to submit MLM mail		Operators of non-DKIM-aware MLMs could arrange to submit MLM mail
	through an MSA that is DKIM-aware so that its mail will be signed.		through an MSA that is DKIM-aware so that its mail will be signed.
	5.6. Verification Outcomes at Final Receiving Sites		Some concern has been expressed about an MLM applying its signature
			to unsigned mail, which some verifiers or receivers might interpret
			as conferring more authority to the message content. The working
			group feels this is no different than present-day lists relaying
			traffic and affixing RFC5322.Subject tags or similar, and thus it
			doesn't introduce any new concerns.
			5.7. Verification Outcomes at Final Receiving Sites
	In general, verifiers and receivers can treat a signed message from		In general, verifiers and receivers can treat a signed message from
	an MLM like any other signed message; indeed, it would be difficult		an MLM like any other signed message; indeed, it would be difficult
	to discern any difference.		to discern any difference.
	However, because the author domain will commonly be different from		However, because the author domain will commonly be different from
	the MLM's signing domain, there may be a conflict with [ADSP] as		the MLM's signing domain, there may be a conflict with [ADSP] as
	discussed in Section 4.3 and Section 5.4.		discussed in Section 4.3 and Section 5.4.
	5.7. Use With FBLs		5.8. Use With FBLs
	An FBL operator wishing act on a complaint by making use of DKIM		An FBL operator wishing act on a complaint by making use of DKIM
	verifications is advised to send a report to any domain with a valid		verifications is advised to send a report to any domain with a valid
	signature that has an FBL agreement established, as DKIM signatures		signature that has an FBL agreement established, as DKIM signatures
	are claims of some responsibility for that message. Because authors		are claims of some responsibility for that message. Because authors
	generally have limited control over the operation of a list, this		generally have limited control over the operation of a list, this
	point makes MLM signing all the more important.		point makes MLM signing all the more important.
	Where the FBL wishes to be more specific, it could act solely on a		Where the FBL wishes to be more specific, it could act solely on a
	DKIM signature where the signing domain matches the DNS domain found		DKIM signature where the signing domain matches the DNS domain found
	in a List-Post: header field (or similar).		in a List-Post: header field (or similar).
	5.8. Handling Choices at Receivers		Use of FBLs in this way should be made explicit to list subscribers.
			For example, if it is the policy of the MLM's ADMD to handle an FBL
			item by unsubscribing the user that was the apparent sender of the
			offending message, advising subscribers of this in advance would help
			to avoid surprises later.
			5.9. Handling Choices at Receivers
	A recipient that trusts signatures from an MLM may wish to extend		A recipient that trusts signatures from an MLM may wish to extend
	that trust to an [AUTH-RESULTS] header field signed by that MLM. The		that trust to an [AUTH-RESULTS] header field signed by that MLM. The
	recipient may then do additional processing of the message, using the		recipient may then do additional processing of the message, using the
	results recorded in the Authentication-Results header field instead		results recorded in the Authentication-Results header field instead
	of the original author's DKIM signature. This includes possibly		of the original author's DKIM signature. This includes possibly
	processing the message as per ADSP requirements.		processing the message as per ADSP requirements.
	Receivers are advised to ignore all unsigned Authentication-Results		Receivers are advised to ignore all unsigned Authentication-Results
	header fields.		header fields.
	Upon DKIM and ADSP evaluation, a receiver may decide to reject a		Upon DKIM and ADSP evaluation, a receiver may decide to reject a
	message during an SMTP session. If this is done, use of [ENHANCED]		message during an SMTP session. If this is done, use of an [SMTP]
	is advised to make a distinction between messages rejected		failure code not normally used for "user unknown" (550) is suggested;
	deliberately due to policy decisions rather than those rejected		554 seems an appropriate candidate. If the rejecting SMTP server
	because of other deliverability issues. In particular, a policy		supports [ENHANCED] status codes, is advised to make a distinction
	rejection is advised to be relayed using a 5.7.1 enhanced status		between messages rejected deliberately due to policy decisions rather
	code, in contrast to a code of 5.1.1 indicating the user does not		than those rejected because of other deliverability issues. In
	exist. Those MLMs that attempt to automatically remove users with		particular, a policy rejection is advised to be relayed using a 5.7.2
	prolonged delivery problems (such as account deletion) will thus be		enhanced status code and some appropriate wording in the text part of
	able to tell the difference between policy rejection and delivery		the reply, in contrast to a code of 5.1.1 indicating the user does
	failures, and act accordingly. Where the receiver's MTA does not		not exist. Those MLMs that attempt to automatically remove users
	support enhanced status codes, [SMTP] reply codes could also be		with prolonged delivery problems (such as account deletion) will thus
	carefully selected (554 and 550, respectively, for example).		be able to tell the difference between policy rejection and delivery
			failures, and act accordingly. SMTP servers doing so are also
			advised to use appropriate wording in the text portion of the reply.
	6. IANA Considerations		6. DKIM Reporting
			The MARF working group is developing mechanisms for reporting
			forensic details about DKIM verification failures. At the time of
			writing, this is still a work in progress.
			MLMs are encouraged to apply these or other DKIM failure reporting
			mechanisms as a method for providing feedback about issues with DKIM
			infrastructure back to signers. This is especially important for
			MLMs that implement DKIM verification as a mechanism for
			authentication of list configuration commands and submissions from
			subscribers.
			7. IANA Considerations
	This document includes no IANA actions.		This document includes no IANA actions.
	7. 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.
	7.1. Authentication Results When Relaying		8.1. Authentication Results When Relaying
	some stuff about the fact that the MLM's auth-results can't be		some stuff about the fact that the MLM's auth-results can't be
	trusted by default		trusted by default
	8. References		9. References
	8.1. Normative References		9.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.
	[DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,		[DKIM] 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.
	[MAIL] Resnick, P., "Internet Message Format", RFC 5322,		[MAIL] Resnick, P., "Internet Message Format", RFC 5322,
	October 2008.		October 2008.
	8.2. Informative References		9.2. Informative References
	[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-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.
	skipping to change at page 24, line 8 ¶		skipping to change at page 26, line 8 ¶
	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,
	October 2008.		October 2008.
	Appendix A. Acknowledgements		Appendix A. Acknowledgements
	The author wishes to acknowledge the following for their review and		The author wishes to acknowledge the following for their review and
	constructive criticism of this document: Dave Crocker, JD Falk, Tony		constructive criticism of this document: Serge Aumont, Daniel Black,
	Hansen, Eliot Lear, John Levine and S. Moonesamy.		Dave Crocker, JD Falk, Tony Hansen, Eliot Lear, John Levine, S.
			Moonesamy and Alessandro Vesely.
	Appendix B. Example Scenarios		Appendix B. Example Scenarios
	This section describes a few MLM-related DKIM scenarios that were		This section describes a few MLM-related DKIM scenarios that were
	part of the impetus for this work, and the recommended resolutions		part of the impetus for this work, and the recommended resolutions
	for each.		for each.
	B.1. MLMs and ADSP		B.1. MLMs and ADSP
	Problem:		Problem:
	skipping to change at page 25, line 42 ¶		skipping to change at page 27, line 42 ¶
	Problem:		Problem:
	o subscriber sends sign mail to a non-participating MLM that does		o subscriber sends sign mail to a non-participating MLM that does
	not invalidate the signature		not invalidate the signature
	o a recipient reports the message as spam		o a recipient reports the message as spam
	o FBL at recipient ADMD sends report to contributor rather than list		o FBL at recipient ADMD sends report to contributor rather than list
	manager		manager
	Solution: MLMs should sign mail they send and should probably strip		Solution: MLMs should sign mail they send and might also strip
	signatures; FBLs should report to list operators instead of to		existing signatures; FBLs should report to list operators instead of
	subscribers where such can be distinguished.		to subscribers where such can be distinguished.
	Author's Address		Author's Address
	Murray S. Kucherawy		Murray S. Kucherawy
	Cloudmark		Cloudmark
	128 King St., 2nd Floor		128 King St., 2nd Floor
	San Francisco, CA 94107		San Francisco, CA 94107
	US		US
	Phone: +1 415 946 3800		Phone: +1 415 946 3800
End of changes. 46 change blocks.
	107 lines changed or deleted		184 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/