< draft-ietf-sieve-imap-sieve-04.txt		draft-ietf-sieve-imap-sieve-05.txt >
	Sieve Working Group B. Leiba		Sieve Working Group B. Leiba
	Internet-Draft Huawei Technologies		Internet-Draft Huawei Technologies
	Intended status: Standards Track May 30, 2012		Intended status: Standards Track June 15, 2012
	Expires: December 1, 2012		Expires: December 17, 2012
	Support for Internet Message Access Protocol (IMAP) Events in Sieve		Support for Internet Message Access Protocol (IMAP) Events in Sieve
	draft-ietf-sieve-imap-sieve-04		draft-ietf-sieve-imap-sieve-05
	Abstract		Abstract
	Sieve defines an email filtering language that can, in principle,		Sieve defines an email filtering language that can, in principle,
	plug into any point in the processing of an email message. As		plug into any point in the processing of an email message. As
	defined in the base specification, it plugs into mail delivery. This		defined in the base specification, it plugs into mail delivery. This
	document defines how Sieve can plug into points in the IMAP protocol		document defines how Sieve can plug into points in the IMAP protocol
	where messages are created or changed, adding the option of user-		where messages are created or changed, adding the option of user-
	defined or installation-defined filtering (or, with Sieve extensions,		defined or installation-defined filtering (or, with Sieve extensions,
	features such as notifications).		features such as notifications).
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 36 ¶
	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 1, 2012.		This Internet-Draft will expire on December 17, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 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 4, line 36 ¶		skipping to change at page 4, line 36 ¶
	invoked.		invoked.
	1.2. Differences Between IMAP Events and Mail Delivery		1.2. Differences Between IMAP Events and Mail Delivery
	Invoking Sieve scripts in a context other than initial mail delivery		Invoking Sieve scripts in a context other than initial mail delivery
	introduces new situations, which changes the applicability of Sieve		introduces new situations, which changes the applicability of Sieve
	features and creates implementation challenges and user interface		features and creates implementation challenges and user interface
	issues. This section discusses some of those differences,		issues. This section discusses some of those differences,
	challenges, and issues.		challenges, and issues.
	At times other than message delivery, delivery "envelope"		At times other than message delivery, delivery "envelope" information
	information, might not be available. With messages added through		might not be available. With messages added through IMAP APPEND,
	IMAP APPEND, there might be no way to even guess who the intended		there might be no way to even guess who the intended recipient is,
	recipient is, and no concept of who "sent" the message. Sieve		and no concept of who "sent" the message. Sieve actions that relate
	actions that relate to contacting the sender, for example, will not		to contacting the sender, for example, will not be applicable.
	be applicable.
	Because IMAP events will often be triggered by user actions, and		Because IMAP events will often be triggered by user actions, and
	because user interfaces allow bulk actions that differ from		because user interfaces allow bulk actions that differ from
	individual message arrival, it now becomes possible for a single user		individual message arrival, it now becomes possible for a single user
	action, such as drag-and-drop, to initiate Sieve script processing on		action, such as drag-and-drop, to initiate Sieve script processing on
	a large number of messages at once. Implementations will have to		a large number of messages at once. Implementations will have to
	deal with such situations as a "COPY" action or flag changes on		deal with such situations as a "COPY" action or flag changes on
	dozens, or even thousands of messages.		dozens, or even thousands of messages.
	Other issues might surface as this extension is deployed and		Other issues might surface as this extension is deployed and
	skipping to change at page 8, line 15 ¶		skipping to change at page 8, line 15 ¶
	2.3. New Functions Defined by IMAP events in Sieve		2.3. New Functions Defined by IMAP events in Sieve
	2.3.1. Interaction with Metadata		2.3.1. Interaction with Metadata
	Support for IMAP events in Sieve requires support for IMAP Metadata		Support for IMAP events in Sieve requires support for IMAP Metadata
	[RFC5464] as well, since the latter is used to associate scripts with		[RFC5464] as well, since the latter is used to associate scripts with
	IMAP mailboxes.		IMAP mailboxes.
	When an applicable event occurs on an IMAP mailbox, if there is an		When an applicable event occurs on an IMAP mailbox, if there is an
	IMAP metadata entry named "/IMAPSieve/Script" for the mailbox, that		IMAP metadata entry named "/shared/imapsieve/script" for the mailbox,
	entry is used. If there is not, but there is an IMAP metadata entry		that entry is used. If there is not, but there is an IMAP metadata
	named "/IMAPSieve/Script" for the server, that entry is used		entry named "/shared/imapsieve/script" for the server, that entry is
	(providing a way to define a global script for all mailboxes on a		used (providing a way to define a global script for all mailboxes on
	server). If neither entry exists, then no script will be invoked.		a server). If neither entry exists, then no script will be invoked.
	If an "/IMAPSieve/Script" metadata entry was selected above, the		If a "/shared/imapsieve/script" metadata entry was selected above,
	shared value of that metadata name (its "value.shared" attribute)		its value is used as the name of the Sieve script that will be
	MUST be the name of the Sieve script that will be invoked in response		invoked in response to the IMAP event. If the value is empty, then
	to the IMAP event. Note that only the value.shared attribute is		no script is run.
	used; any value.priv attributes are ignored.
	This specifies the mechanism for "activating" a script for a given		This specifies the mechanism for "activating" a script for a given
	mailbox (or for all mailboxes), but does not specify a mechanism for		mailbox (or for all mailboxes), but does not specify a mechanism for
	creating, storing, or validating the script. Implementations MUST		creating, storing, or validating the script. Implementations MUST
	support ManageSieve [RFC5804], and can use the PUTSCRIPT command to		support ManageSieve [RFC5804], and can use the PUTSCRIPT command to
	store the script without using the SETACTIVE command to activate it.		store the script without using the SETACTIVE command to activate it.
	Script names used in "/IMAPSieve/Script" metadata entries are the		Script names used in "/shared/imapsieve/script" metadata entries are
	script names used on the corresponding ManageSieve server. If an		the script names used on the corresponding ManageSieve server. If a
	"/IMAPSieve/Script" metadata entry contains a script name that		"/shared/imapsieve/script" metadata entry contains a script name that
	doesn't exist in the ManageSieve server, then no Sieve script will be		doesn't exist in the ManageSieve server, then no Sieve script will be
	invoked for IMAP Sieve events.		invoked for IMAP Sieve events.
	Only one Sieve script may currently be defined per mailbox,		Only one Sieve script may currently be defined per mailbox,
	eliminating the complexity and possible ambiguity involved with		eliminating the complexity and possible ambiguity involved with
	coordinating the results of multiple scripts. Any sub-filtering is		coordinating the results of multiple scripts. Any sub-filtering is
	done in the Sieve script. For example, if it's only necessary to		done in the Sieve script. For example, if it's only necessary to
	deal with flag changes, but not with new messages appended or copied,		deal with flag changes, but not with new messages appended or copied,
	the Sieve script will still be invoked for all events, and the script		the Sieve script will still be invoked for all events, and the script
	is responsible for checking the event type.		is responsible for checking the event type.
	skipping to change at page 11, line 27 ¶		skipping to change at page 11, line 27 ¶
	It's possible that a message processed in this way does not have the		It's possible that a message processed in this way does not have the
	information necessary to be redirected properly. It might lack		information necessary to be redirected properly. It might lack
	necessary header information, and there might not be appropriate		necessary header information, and there might not be appropriate
	information for the MAIL FROM command. In such cases, the "redirect"		information for the MAIL FROM command. In such cases, the "redirect"
	action uses Message Submission [RFC6409], and it is up to the Sieve		action uses Message Submission [RFC6409], and it is up to the Sieve
	engine to supply the missing information. The redirect address is,		engine to supply the missing information. The redirect address is,
	of course, used for the "RCPT TO", and the "MAIL FROM" SHOULD be set		of course, used for the "RCPT TO", and the "MAIL FROM" SHOULD be set
	to the address of the owner of the mailbox. The message submission		to the address of the owner of the mailbox. The message submission
	server is allowed, according to the Message Submission protocol, to		server is allowed, according to the Message Submission protocol, to
	perform necessary fix-up to the message (see section 8 of RFC 6409).		perform necessary fix-up to the message (see Section 8 of RFC 6409).
	It can also reject the submission attempt, if the message is too ill-		It can also reject the submission attempt, if the message is too ill-
	formed for submission.		formed for submission.
	For APPEND, MULTIAPPEND, and COPY, the message is stored into the		For APPEND, MULTIAPPEND, and COPY, the message is stored into the
	target mailbox in addition to being redirected. For flag changes,		target mailbox in addition to being redirected. For flag changes,
	the message remains in its original mailbox.		the message remains in its original mailbox.
	If a keep action is NOT also in effect, the original message is then		If a keep action is NOT also in effect, the original message is then
	marked with the \Deleted flag (and a flag-change Sieve script is NOT		marked with the \Deleted flag (and a flag-change Sieve script is NOT
	invoked). The implementation MAY then expunge the original message		invoked). The implementation MAY then expunge the original message
	skipping to change at page 17, line 16 ¶		skipping to change at page 17, line 16 ¶
	It is possible to introduce script processing loops by having a Sieve		It is possible to introduce script processing loops by having a Sieve
	script that is triggered by flag changes use the actions defined in		script that is triggered by flag changes use the actions defined in
	the IMAP4Flags extension [RFC5232]. Implementations MUST take steps		the IMAP4Flags extension [RFC5232]. Implementations MUST take steps
	to prevent such loops. One way to avoid this problem is that if a		to prevent such loops. One way to avoid this problem is that if a
	script is invoked by flag changes, and that script further changes		script is invoked by flag changes, and that script further changes
	the flags, those flag changes SHOULD NOT trigger a Sieve script		the flags, those flag changes SHOULD NOT trigger a Sieve script
	invocation.		invocation.
	It is also possible to introduce loops through the "redirect" or		It is also possible to introduce loops through the "redirect" or
	"notify" actions. See section 10 of Sieve [RFC5228], section 8 of		"notify" actions. See Section 10 of Sieve [RFC5228], Section 8 of
	Sieve Notify [RFC5435], and the Security Considerations sections of		Sieve Notify [RFC5435], and the Security Considerations sections of
	the applicable notification-method documents for loop-prevention		the applicable notification-method documents for loop-prevention
	information. This extension does not change any of that advice.		information. This extension does not change any of that advice.
	Other security considerations are discussed in IMAP [RFC3501], and		Other security considerations are discussed in IMAP [RFC3501], and
	Sieve [RFC5228], as well as in some of the other extension documents.		Sieve [RFC5228], as well as in some of the other extension documents.
	7. IANA Considerations		7. IANA Considerations
	7.1. Registration of "imapsieve" IMAP capability		7.1. Registration of "imapsieve" IMAP capability
	skipping to change at page 20, line 9 ¶		skipping to change at page 20, line 9 ¶
	7.4. Registration of IMAP METADATA Mailbox Entry Name		7.4. Registration of IMAP METADATA Mailbox Entry Name
	The following information should be added to the IMAP METADATA		The following information should be added to the IMAP METADATA
	Mailbox Entry Registry, according to the Metadata extension		Mailbox Entry Registry, according to the Metadata extension
	[RFC5464].		[RFC5464].
	(http://www.iana.org/assignments/imap-metadata/imap-metadata.xml)		(http://www.iana.org/assignments/imap-metadata/imap-metadata.xml)
	To: iana@iana.org		To: iana@iana.org
	Subject: IMAP METADATA Registration		Subject: IMAP METADATA Entry Registration
	Please register the following IMAP METADATA item:		Type: Mailbox
	[x] Entry [ ] Attribute		Name: /shared/imapsieve/script
	[x] Mailbox [ ] Server
	Name: /IMAPSieve/Script
	Description: This entry name is used to define mailbox metadata		Description: This entry name is used to define mailbox metadata
	associated with IMAP events in Sieve for the associated mailbox.		associated with IMAP events in Sieve for the associated mailbox.
	Specifically, this specifies the Sieve script that will be invoked		Specifically, this specifies the Sieve script that will be invoked
	when IMAP events occur on the specified mailbox.		when IMAP events occur on the specified mailbox.
	Content-type: text/plain; charset=utf-8		Content-type: text/plain; charset=utf-8
	RFC number: [[this RFC]]		RFC number: [[this RFC]]
	Contact address: Sieve mailing list <sieve@ietf.org>		Contact address: Sieve mailing list <sieve@ietf.org>
	7.5. Registration of IMAP METADATA Server Entry Name		7.5. Registration of IMAP METADATA Server Entry Name
	The following information should be added to the IMAP METADATA Server		The following information should be added to the IMAP METADATA Server
	Entry Registry, items according to the Metadata extension [RFC5464].		Entry Registry, items according to the Metadata extension [RFC5464].
	(http://www.iana.org/assignments/imap-metadata/imap-metadata.xml)		(http://www.iana.org/assignments/imap-metadata/imap-metadata.xml)
	To: iana@iana.org		To: iana@iana.org
	Subject: IMAP METADATA Registration		Subject: IMAP METADATA Entry Registration
	Please register the following IMAP METADATA item:		Type: Server
	[x] Entry [ ] Attribute		Name: /shared/imapsieve/script
	[ ] Mailbox [x] Server
	Name: /IMAPSieve/Script
	Description: This entry name is used to define metadata associated		Description: This entry name is used to define metadata associated
	globally with IMAP events in Sieve for the associated server.		globally with IMAP events in Sieve for the associated server.
	Specifically, this specifies the Sieve script that will be invoked		Specifically, this specifies the Sieve script that will be invoked
	when IMAP events occur on any mailbox in the server that does not		when IMAP events occur on any mailbox in the server that does not
	have its own mailbox-level /IMAPSieve/Script entry.		have its own mailbox-level /shared/imapsieve/script entry.
	Content-type: text/plain; charset=utf-8		Content-type: text/plain; charset=utf-8
	RFC number: [[this RFC]]		RFC number: [[this RFC]]
	Contact address: Sieve mailing list <sieve@ietf.org>		Contact address: Sieve mailing list <sieve@ietf.org>
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
End of changes. 12 change blocks.
	36 lines changed or deleted		30 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/