< draft-ietf-sieve-editheader-10.txt		draft-ietf-sieve-editheader-11.txt >
	Network Working Group Jutta Degener		Network Working Group Jutta Degener
	Internet Draft Philip Guenther		Internet Draft Philip Guenther
	Intended status: Standards Track Sendmail, Inc.		Intended status: Standards Track Sendmail, Inc.
	Expires: August 2008 February 2008		Expires: September 2008 March 2008
	Sieve Email Filtering: Editheader Extension		Sieve Email Filtering: Editheader Extension
	draft-ietf-sieve-editheader-10.txt		draft-ietf-sieve-editheader-11.txt
	Status of this memo		Status of this memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 2, line 5 ¶		skipping to change at page 2, line 5 ¶
	filtering language that add and delete email header fields.		filtering language that add and delete email header fields.
	1. Introduction		1. Introduction
	Email header fields are a flexible and easy to understand means		Email header fields are a flexible and easy to understand means
	of communication between email processors.		of communication between email processors.
	This extension enables sieve scripts to interact with other		This extension enables sieve scripts to interact with other
	components that consume or produce header fields by allowing		components that consume or produce header fields by allowing
	the script to delete and add header fields.		the script to delete and add header fields.
	2. Conventions used.		2. Conventions Used in This Document
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [KEYWORDS].		document are to be interpreted as described in [KEYWORDS].
	Conventions for notations are as in [SIEVE] section 1.1, including		Conventions for notations are as in [SIEVE] section 1.1, including
	use of the "Usage:" label for the definition of action and tagged		use of the "Usage:" label for the definition of action and tagged
	arguments syntax.		arguments syntax.
	The term "header field" is used here as in [IMAIL] to mean a		The term "header field" is used here as in [IMAIL] to mean a
	logical line of an email message header.		logical line of an email message header.
			3. Capability Identifier
	The capability string associated with the extension defined in		The capability string associated with the extension defined in
	this document is "editheader".		this document is "editheader".
	3. Action addheader		4. Action addheader
	Usage: "addheader" [":last"] <field-name: string> <value: string>		Usage: "addheader" [":last"] <field-name: string> <value: string>
	The addheader action adds a header field to the existing message		The addheader action adds a header field to the existing message
	header. If the field-name is not a valid 7-bit US-ASCII header		header. If the field-name is not a valid 7-bit US-ASCII header
	field name as described by the [IMAIL] "field-name" nonterminal		field name as described by the [IMAIL] "field-name" nonterminal
	syntax element, the implementation MUST flag an error. The		syntax element, the implementation MUST flag an error. The
	addheader action does not affect Sieve's implicit keep.		addheader action does not affect Sieve's implicit keep.
	If the specified field value does not match the RFC 2822		If the specified field value does not match the RFC 2822
	skipping to change at page 3, line 5 ¶		skipping to change at page 3, line 14 ¶
	Example:		Example:
	/* Don't redirect if we already redirected */		/* Don't redirect if we already redirected */
	if not header :contains "X-Sieve-Filtered"		if not header :contains "X-Sieve-Filtered"
	["<kim@job.example.com>", "<kim@home.example.com>"]		["<kim@job.example.com>", "<kim@home.example.com>"]
	{		{
	addheader "X-Sieve-Filtered" "<kim@job.example.com>";		addheader "X-Sieve-Filtered" "<kim@job.example.com>";
	redirect "kim@home.example.com";		redirect "kim@home.example.com";
	}		}
	4. Action deleteheader		5. Action deleteheader
	Usage: "deleteheader" [":index" <fieldno: number> [":last"]]		Usage: "deleteheader" [":index" <fieldno: number> [":last"]]
	[COMPARATOR] [MATCH-TYPE]		[COMPARATOR] [MATCH-TYPE]
	<field-name: string>		<field-name: string>
	[<value-patterns: string-list>]		[<value-patterns: string-list>]
	By default, the deleteheader action deletes all occurrences of		By default, the deleteheader action deletes all occurrences of
	the named header field. The deleteheader action does not affect		the named header field. The deleteheader action does not affect
	Sieve's implicit keep.		Sieve's implicit keep.
	skipping to change at page 3, line 36 ¶		skipping to change at page 3, line 45 ¶
	field values is ignored. If no value-patterns are specified		field values is ignored. If no value-patterns are specified
	then the comparator and match-type options are silently ignored.		then the comparator and match-type options are silently ignored.
	If :index <fieldno> is specified, the attempts to match a value		If :index <fieldno> is specified, the attempts to match a value
	are limited to the <fieldno> occurrence of the named header		are limited to the <fieldno> occurrence of the named header
	field, beginning at 1, the first named header field. If :last		field, beginning at 1, the first named header field. If :last
	is specified, the count is backwards; 1 denotes the last named		is specified, the count is backwards; 1 denotes the last named
	header field, 2 the second to last, and so on. The counting		header field, 2 the second to last, and so on. The counting
	happens before the <value-patterns> match, if any. For example:		happens before the <value-patterns> match, if any. For example:
	deleteheader :index 2 :contains "Received" "via carrier-pigeon"		deleteheader :index 1 :contains "Delivered-To"
			"bob@example.com";
	deletes the second "Received" header field if it contains		deletes the first "Delivered-To" header field if it contains the
	the string "via carrier-pigeon" (not the second "Received" field		string "bob@example.com" (not the first "Delivered-To" field
	that contains "via carrier-pigeon").		that contains "bob@example.com").
	It is not an error if no header fields match the conditions in		It is not an error if no header fields match the conditions in
	the deleteheader action or if the :index argument is greater		the deleteheader action or if the :index argument is greater
	than the number of named header fields.		than the number of named header fields.
	The implementation MUST flag an error if :last is specified		The implementation MUST flag an error if :last is specified
	without also specifying :index.		without also specifying :index.
	5. Implementation Limitations on Changes		6. Implementation Limitations on Changes
	As a matter of local policy, implementations MAY limit which		As a matter of local policy, implementations MAY limit which
	header fields may be deleted and which header fields may be		header fields may be deleted and which header fields may be
	added. However, implementations MUST NOT permit attempts to		added. However, implementations MUST NOT permit attempts to
	delete "Received" header fields and MUST permit both addition		delete "Received" header fields and MUST permit both addition
	and deletion of the "Subject" header field.		and deletion of the "Subject" header field.
	If a script tries to make a change that isn't permitted, the		If a script tries to make a change that isn't permitted, the
	attempt MUST be silently ignored.		attempt MUST be silently ignored.
	6. Interaction with Other Sieve Extensions		7. Interaction with Other Sieve Extensions
	Actions that generate [MDN], [DSN], or similar disposition		Actions that generate [MDN], [DSN], or similar disposition
	messages MUST do so using the original, unmodified message header.		messages MUST do so using the original, unmodified message header.
	Similarly, if an error terminates processing of the script, the		Similarly, if an error terminates processing of the script, the
	original message header MUST be used when doing the implicit		original message header MUST be used when doing the implicit
	keep required by [SIEVE] section 2.10.6.		keep required by [SIEVE] section 2.10.6.
	With the exception of the special handling of redirect and		With the exception of the special handling of redirect and
	"Received" header fields described above, all other actions that		"Received" header fields described above, all other actions that
	store, send, or alter the message MUST do so with the current set		store, send, or alter the message MUST do so with the current set
	skipping to change at page 5, line 35 ¶		skipping to change at page 6, line 5 ¶
	keep;		keep;
	MUST only file one message. It is up to the implementation		MUST only file one message. It is up to the implementation
	to pick which of the redundant "fileinto" or "keep" actions is		to pick which of the redundant "fileinto" or "keep" actions is
	executed, and which ones are ignored.		executed, and which ones are ignored.
	The "implicit keep" is thought to be executed at the end of		The "implicit keep" is thought to be executed at the end of
	the script, after the headers have been modified. (However,		the script, after the headers have been modified. (However,
	a canceled "implicit keep" remains canceled.)		a canceled "implicit keep" remains canceled.)
	7. IANA Considerations		8. IANA Considerations
	The following template specifies the IANA registration of the Sieve		The following template specifies the IANA registration of the Sieve
	extension specified in this document:		extension specified in this document:
	To: iana@iana.org		To: iana@iana.org
	Subject: Registration of new Sieve extension		Subject: Registration of new Sieve extension
	Capability name: editheader		Capability name: editheader
	Description: adds actions 'addheader' and 'deleteheader'		Description: Adds actions 'addheader' and 'deleteheader'
	that modify the header of the message being		that modify the header of the message being
	processed		processed
	RFC number: this RFC		RFC number: this RFC
	Contact Address: Jutta Degener <jutta@pobox.com>		Contact Address: Jutta Degener <jutta@pobox.com>
	This information should be added to the list of sieve extensions		This information should be added to the list of sieve extensions
	given on http://www.iana.org/assignments/sieve-extensions.		given on http://www.iana.org/assignments/sieve-extensions.
	8. Security Considerations		9. Security Considerations
	Someone with write access to a user's script storage may use this		Someone with write access to a user's script storage may use this
	extension to generate headers that a user would otherwise be		extension to generate headers that a user would otherwise be
	shielded from (e.g., by a gateway MTA that removes them).		shielded from (e.g., by a gateway MTA that removes them).
	A sieve filter that removes header fields may unwisely destroy		A sieve filter that removes header fields may unwisely destroy
	evidence about the path a message has taken.		evidence about the path a message has taken.
	While this specification overrides the requirement that redirected
	messages have more "Received" header fields than the message as
	received, doing so removes an important mechanisms for detecting
	loops and MUST NOT be permitted by implementations without due
	consideration, such as requiring administrative action to enable
	it.
	Any change in a message content may interfere with digital		Any change in a message content may interfere with digital
	signature mechanisms that include the header in the signed		signature mechanisms that include the header in the signed
	material. Since normal message delivery adds "Received"		material. Since normal message delivery adds "Received"
	header fields and other trace fields to the beginning of a		header fields and other trace fields to the beginning of a
	message, many such schemas are impervious to headers prefixed		message, many such schemas are impervious to headers prefixed
	to a message, and will work with "addheader" unless :last is		to a message, and will work with "addheader" unless :last is
	used.		used.
	Any decision mechanism in a user's filter that is based		Any decision mechanism in a user's filter that is based
	on headers is vulnerable to header spoofing. For example,		on headers is vulnerable to header spoofing. For example,
	if the user adds an APPROVED header or tag, a malicious sender		if the user adds an APPROVED header or tag, a malicious sender
	may add that tag or header themselves. One way to guard against		may add that tag or header themselves. One way to guard against
	this is to delete or rename any such headers or stamps prior		this is to delete or rename any such headers or stamps prior
	to processing the message.		to processing the message.
	9. Acknowledgments		10. Acknowledgments
	Thanks to Eric Allman, Cyrus Daboo, Matthew Elvey, Ned Freed,		Thanks to Eric Allman, Cyrus Daboo, Matthew Elvey, Ned Freed,
	Arnt Gulbrandsen, Kjetil Torgrim Homme, Simon Josefsson,		Arnt Gulbrandsen, Kjetil Torgrim Homme, Simon Josefsson,
	Will Lee, William Leibzon, Mark E. Mallett, Chris Markle,		Will Lee, William Leibzon, Mark E. Mallett, Chris Markle,
	Alexey Melnikov, Randall Schwartz, Aaron Stone, Nigel Swinson,		Alexey Melnikov, Randall Schwartz, Aaron Stone, Nigel Swinson,
	and Rand Wacker for extensive corrections and suggestions.		and Rand Wacker for extensive corrections and suggestions.
	10. Authors' Addresses		11. Authors' Addresses
	Jutta Degener		Jutta Degener
	5245 College Ave, Suite #127		5245 College Ave, Suite #127
	Oakland, CA 94618		Oakland, CA 94618
	Email: jutta@pobox.com		Email: jutta@pobox.com
	Philip Guenther		Philip Guenther
	Sendmail, Inc.		Sendmail, Inc.
	6475 Christie Ave., Ste 350		6475 Christie Ave., Ste 350
	Emeryville, CA 94608		Emeryville, CA 94608
	Email: guenther@sendmail.com		Email: guenther@sendmail.com
	11. Discussion		12. Discussion
	This section will be removed when this document leaves the		This section will be removed when this document leaves the
	Internet-Draft stage.		Internet-Draft stage.
	This draft is intended as an extension to the Sieve mail filtering		This draft is intended as an extension to the Sieve mail filtering
	language. Sieve extensions are discussed on the MTA Filters mailing		language. Sieve extensions are discussed on the MTA Filters mailing
	list at <ietf-mta-filters@imc.org>. Subscription requests can		list at <ietf-mta-filters@imc.org>. Subscription requests can
	be sent to <ietf-mta-filters-request@imc.org> (send an email		be sent to <ietf-mta-filters-request@imc.org> (send an email
	message with the word "subscribe" in the body).		message with the word "subscribe" in the body).
	More information on the mailing list along with a WWW archive of		More information on the mailing list along with a WWW archive of
	back messages is available at <http://www.imc.org/ietf-mta-filters/>.		back messages is available at <http://www.imc.org/ietf-mta-filters/>.
	11.2 Changes from draft-ietf-sieve-editheader-09.txt		12.1 Changes from draft-ietf-sieve-editheader-10.txt
			Update the deleteheader example to not violate the spec.
			Remove the security consideration about deleting "Received" headers.
			Add a "Capability Identifier" section to match existing RFCs.
			Make the normative and information references subsections of a
			"References" section to match existing RFCs.
			12.2 Changes from draft-ietf-sieve-editheader-09.txt
	Add section 5, completely banning <<deleteheader "Received">>		Add section 5, completely banning <<deleteheader "Received">>
	but requiring that "Subject" changes be permitted.		but requiring that "Subject" changes be permitted.
	Since deletion of "Received" headers is now banned, this spec		Since deletion of "Received" headers is now banned, this spec
	no longer updates the base-spec.		no longer updates the base-spec.
	Updated references to Sieves specs that have been published.		Updated references to Sieves specs that have been published.
	11.3 Changes from draft-ietf-sieve-editheader-08.txt		12.3 Changes from draft-ietf-sieve-editheader-08.txt
	Tighten up the permissible behaviors involving redirect and		Tighten up the permissible behaviors involving redirect and
	deleteheader "Recieved".		deleteheader "Recieved".
	Consistently quote the names of header fields, but not actions.		Consistently quote the names of header fields, but not actions.
	For deleteheader, :last without :index is an error. On the other		For deleteheader, :last without :index is an error. On the other
	hand, the match-type and comparator are ignored if there are no		hand, the match-type and comparator are ignored if there are no
	value-patterns.		value-patterns.
	Clarify that addheader and deleteheader operate on the 'current'		Clarify that addheader and deleteheader operate on the 'current'
	set of header fields and give examples demonstrating this.		set of header fields and give examples demonstrating this.
	11.4 Changes from draft-ietf-sieve-editheader-07.txt		12.4 Changes from draft-ietf-sieve-editheader-07.txt
	Let implementations permit redirected messages to have fewer		Let implementations permit redirected messages to have fewer
	"Received" header fields, but warn about the consequences.		"Received" header fields, but warn about the consequences.
	Updated boilerplate to match RFC 4748.		Updated boilerplate to match RFC 4748.
	Added "Intended-Status: Standards Track" and		Added "Intended-Status: Standards Track" and
	"Updates: draft-ietf-sieve-3028bis-12"		"Updates: draft-ietf-sieve-3028bis-12"
	Change the references from appendices to sections.		Change the references from appendices to sections.
	Update [SIEVE], [BODY], [DSN], and [MDN] references.		Update [SIEVE], [BODY], [DSN], and [MDN] references.
	11.5 Changes from draft-ietf-sieve-editheader-06.txt		12.5 Changes from draft-ietf-sieve-editheader-06.txt
	Make deleteheader match addheader on the description of invalid		Make deleteheader match addheader on the description of invalid
	field-names.		field-names.
	Update copyright boilerplate		Update copyright boilerplate
	Update references		Update references
	11.6 Changes from draft-ietf-sieve-editheader-05.txt		12.6 Changes from draft-ietf-sieve-editheader-05.txt
	MDN and DSN references are merely informative		MDN and DSN references are merely informative
	11.7 Changes from draft-ietf-sieve-editheader-04.txt		12.7 Changes from draft-ietf-sieve-editheader-04.txt
	Ignore leading and trailing whitespace when matching header field		Ignore leading and trailing whitespace when matching header field
	values.		values.
	Header modifications are ignored when continuing after an error		Header modifications are ignored when continuing after an error
	or generating MDNs or DSNs		or generating MDNs or DSNs
	Added references for MDN and DSN		Added references for MDN and DSN
	Update IANA registration to match 3028bis		Update IANA registration to match 3028bis
	skipping to change at page 9, line 4 ¶		skipping to change at page 9, line 26 ¶
	values.		values.
	Header modifications are ignored when continuing after an error		Header modifications are ignored when continuing after an error
	or generating MDNs or DSNs		or generating MDNs or DSNs
	Added references for MDN and DSN		Added references for MDN and DSN
	Update IANA registration to match 3028bis		Update IANA registration to match 3028bis
	Added [KEYWORDS] boilerplate text		Added [KEYWORDS] boilerplate text
	Describe an invalid field-name to addheader as an error (might		Describe an invalid field-name to addheader as an error (might
	be detected at runtime)		be detected at runtime)
	11.8 Changes from draft-ietf-sieve-editheader-03.txt		12.8 Changes from draft-ietf-sieve-editheader-03.txt
	Change "Syntax:" to "Usage:".		Change "Syntax:" to "Usage:".
	Updated references.		Updated references.
	11.9 Changes from draft-ietf-sieve-editheader-02.txt		12.9 Changes from draft-ietf-sieve-editheader-02.txt
	Clarify that value-patterns restrict which occurrences are deleted.		Clarify that value-patterns restrict which occurrences are deleted.
	Add informative reference to [BODY].		Add informative reference to [BODY].
	11.10 Changes from draft-ietf-sieve-editheader-01.txt		12.10 Changes from draft-ietf-sieve-editheader-01.txt
	Whitespace and line length tweaks noted by ID-nits.		Whitespace and line length tweaks noted by ID-nits.
	Clarified what is being counted by :index.		Clarified what is being counted by :index.
	Update the [SIEVE] reference to the I-D of the revision.		Update the [SIEVE] reference to the I-D of the revision.
	11.11 Changes from draft-ietf-sieve-editheader-00.txt		12.11 Changes from draft-ietf-sieve-editheader-00.txt
	Updated IPR boilerplate to RFC 3978/3979.		Updated IPR boilerplate to RFC 3978/3979.
	Many corrections in response to WGLC comments. Of particular note:		Many corrections in response to WGLC comments. Of particular note:
	- correct a number of spelling and grammar errors		- correct a number of spelling and grammar errors
	- document that neither addheader nor deleteheader affects the		- document that neither addheader nor deleteheader affects the
	implicit keep		implicit keep
	- add normative references to RFC 2047 and RFC 2231		- add normative references to RFC 2047 and RFC 2231
	- it is not an error for deleteheader to affect nothing		- it is not an error for deleteheader to affect nothing
	- change "foo.tld" to "foo.example.com"		- change "foo.tld" to "foo.example.com"
	- add an informative reference to [VACATION], citing it as an		- add an informative reference to [VACATION], citing it as an
	example of an action that examines header fields		example of an action that examines header fields
	- add weasel words about changes to fields that have secondary		- add weasel words about changes to fields that have secondary
	effects		effects
	- add security consideration for combination of header changes		- add security consideration for combination of header changes
	and "reject"		and "reject"
	11.12 Changes from draft-degener-sieve-editheader-03.txt		12.12 Changes from draft-degener-sieve-editheader-03.txt
	Renamed to draft-ietf-sieve-editheader-00.txt;		Renamed to draft-ietf-sieve-editheader-00.txt;
	tweaked the title and abstract.		tweaked the title and abstract.
	Added Philip Guenther as co-author.		Added Philip Guenther as co-author.
	Updated IPR boilerplate.		Updated IPR boilerplate.
	11.13 Changes from draft-degener-sieve-editheader-02.txt		12.13 Changes from draft-degener-sieve-editheader-02.txt
	Changed the duplicate restrictions from "messages with different		Changed the duplicate restrictions from "messages with different
	headers MUST be considered different" to their direct opposite,		headers MUST be considered different" to their direct opposite,
	"messages with different headers MUST be considered the same,"		"messages with different headers MUST be considered the same,"
	as requested by workgroup members on the mailing list.		as requested by workgroup members on the mailing list.
	Expanded mention of header signature schemes to Security		Expanded mention of header signature schemes to Security
	Considerations.		Considerations.
	Added IANA Considerations section.		Added IANA Considerations section.
	12. Normative References		13. References
			13.1 Normative References
	[IMAIL] Resnick, P., "Internet Message Format", RFC 2822, April		[IMAIL] Resnick, P., "Internet Message Format", RFC 2822, April
	2001.		2001.
	[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate		[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", RFC 2119, March 1997.		Requirement Levels", RFC 2119, March 1997.
	[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail		[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail
	Extensions) Part Three: Message Header Extensions for		Extensions) Part Three: Message Header Extensions for
	Non-ASCII Text", RFC 2047, November 1996.		Non-ASCII Text", RFC 2047, November 1996.
	[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and		[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and
	Encoded Word Extensions: Character Sets, Languages, and		Encoded Word Extensions: Character Sets, Languages, and
	Continuations", RFC 2231, November 1997.		Continuations", RFC 2231, November 1997.
	[SIEVE] Guenther, P. and T. Showalter, "Sieve: An Email Filtering		[SIEVE] Guenther, P. and T. Showalter, "Sieve: An Email Filtering
	Language", RFC 5228, January 2008.		Language", RFC 5228, January 2008.
	13. Informative References		13.2. Informative References
	[BODY] Degener, J. and P. Guenther, "Sieve Email Filtering:		[BODY] Degener, J. and P. Guenther, "Sieve Email Filtering:
	Body Extension", draft-ietf-sieve-body-07, June 2008.		Body Extension", draft-ietf-sieve-body-09, March 2008.
	[DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format		[DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format
	for Delivery Status Notifications", RFC 3464, January		for Delivery Status Notifications", RFC 3464, January
	2003.		2003.
	[MDN] T. Hansen, Ed., G. Vaudreuil, Ed., "Message Disposition		[MDN] T. Hansen, Ed., G. Vaudreuil, Ed., "Message Disposition
	Notification", RFC 3798, May 2004.		Notification", RFC 3798, May 2004.
	[VACATION] Showalter, T. and N. Freed, "Sieve Email Filtering:		[VACATION] Showalter, T. and N. Freed, "Sieve Email Filtering:
	Vacation Extension", RFC 5230, January 2008.		Vacation Extension", RFC 5230, January 2008.
End of changes. 35 change blocks.
	39 lines changed or deleted		51 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/