< draft-ietf-sieve-imap-sieve-07.txt		draft-ietf-sieve-imap-sieve-08.txt >
	Sieve Working Group B. Leiba		Sieve Working Group B. Leiba
	Internet-Draft Huawei Technologies		Internet-Draft Huawei Technologies
	Updates: 5228 (if approved) September 10, 2012		Updates: 5228 (if approved) September 10, 2012
	Intended status: Standards Track		Intended status: Standards Track
	Expires: March 14, 2013		Expires: March 14, 2013
	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-07		draft-ietf-sieve-imap-sieve-08
	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). Because this requires future Sieve		features such as notifications). Because this requires future Sieve
	skipping to change at page 2, line 33 ¶		skipping to change at page 2, line 33 ¶
	2.2.3. The IMAP COPY Command . . . . . . . . . . . . . . . . . . 7		2.2.3. The IMAP COPY Command . . . . . . . . . . . . . . . . . . 7
	2.2.4. Changes to IMAP Message Flags . . . . . . . . . . . . . . 7		2.2.4. Changes to IMAP Message Flags . . . . . . . . . . . . . . 7
	2.3. New Functions Defined by IMAP events in Sieve . . . . . . 8		2.3. New Functions Defined by IMAP events in Sieve . . . . . . 8
	2.3.1. Interaction with Metadata . . . . . . . . . . . . . . . . 8		2.3.1. Interaction with Metadata . . . . . . . . . . . . . . . . 8
	3. Applicable Sieve Actions and Interactions . . . . . . . . 10		3. Applicable Sieve Actions and Interactions . . . . . . . . 10
	3.1. The Implicit Keep . . . . . . . . . . . . . . . . . . . . 10		3.1. The Implicit Keep . . . . . . . . . . . . . . . . . . . . 10
	3.2. The Keep Action . . . . . . . . . . . . . . . . . . . . . 10		3.2. The Keep Action . . . . . . . . . . . . . . . . . . . . . 10
	3.3. The Fileinto Action . . . . . . . . . . . . . . . . . . . 10		3.3. The Fileinto Action . . . . . . . . . . . . . . . . . . . 10
	3.4. The Redirect Action . . . . . . . . . . . . . . . . . . . 11		3.4. The Redirect Action . . . . . . . . . . . . . . . . . . . 11
	3.5. The Discard Action . . . . . . . . . . . . . . . . . . . . 12		3.5. The Discard Action . . . . . . . . . . . . . . . . . . . . 11
	3.6. The Notify Action . . . . . . . . . . . . . . . . . . . . 13		3.6. The Notify Action . . . . . . . . . . . . . . . . . . . . 12
	3.7. The Addheader and Deleteheader Actions . . . . . . . . . . 13		3.7. The Addheader and Deleteheader Actions . . . . . . . . . . 12
	3.8. The Setflag, Deleteflag, and Removeflag Actions . . . . . 13		3.8. The Setflag, Deleteflag, and Removeflag Actions . . . . . 12
	3.9. MIME Part Tests and Replacement . . . . . . . . . . . . . 13		3.9. MIME Part Tests and Replacement . . . . . . . . . . . . . 12
	3.10. Spamtest and Virustest . . . . . . . . . . . . . . . . . . 14		3.10. Spamtest and Virustest . . . . . . . . . . . . . . . . . . 13
	3.11. Inapplicable Actions . . . . . . . . . . . . . . . . . . . 14		3.11. Inapplicable Actions . . . . . . . . . . . . . . . . . . . 13
	3.12. Future Sieve Actions . . . . . . . . . . . . . . . . . . . 14		3.12. Future Sieve Actions . . . . . . . . . . . . . . . . . . . 13
	4. Interaction With Sieve Environment . . . . . . . . . . . . 15		4. Interaction With Sieve Environment . . . . . . . . . . . . 14
	4.1. Base Sieve Environment Items: location and phase . . . . . 15		4.1. Base Sieve Environment Items: location and phase . . . . . 14
	4.2. New Sieve Environment Items: imapuser and imapemail . . . 15		4.2. New Sieve Environment Items: imapuser and imapemail . . . 14
	4.3. New Sieve Environment Item: cause . . . . . . . . . . . . 15		4.3. New Sieve Environment Item: cause . . . . . . . . . . . . 14
	4.4. New Sieve Environment Item: mailbox . . . . . . . . . . . 16		4.4. New Sieve Environment Item: mailbox . . . . . . . . . . . 15
	4.5. New Sieve Environment Item: changedflags . . . . . . . . . 16		4.5. New Sieve Environment Item: changedflags . . . . . . . . . 15
	4.6. Interaction With Sieve Tests (Comparisons) . . . . . . . . 16		4.6. Interaction With Sieve Tests (Comparisons) . . . . . . . . 15
	5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 17		5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 16
	6. Security Considerations . . . . . . . . . . . . . . . . . 18		6. Security Considerations . . . . . . . . . . . . . . . . . 17
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . 19		7. IANA Considerations . . . . . . . . . . . . . . . . . . . 18
	7.1. Registration of "imapsieve" IMAP capability . . . . . . . 19		7.1. Registration of "imapsieve" IMAP capability . . . . . . . 18
	7.2. Registration of "imapsieve" Sieve extension . . . . . . . 19		7.2. Registration of "imapsieve" Sieve extension . . . . . . . 18
	7.3. Registration of Sieve Environment Items . . . . . . . . . 19		7.3. Registration of Sieve Environment Items . . . . . . . . . 18
	7.3.1. Registration of Sieve Environment Item: cause . . . . . . 19		7.3.1. Registration of Sieve Environment Item: cause . . . . . . 18
	7.3.2. Registration of Sieve Environment Item: mailbox . . . . . 20		7.3.2. Registration of Sieve Environment Item: mailbox . . . . . 19
	7.3.3. Registration of Sieve Environment Item: changedflags . . . 20		7.3.3. Registration of Sieve Environment Item: changedflags . . . 19
	7.3.4. Registration of Sieve Environment Item: imapuser . . . . . 20		7.3.4. Registration of Sieve Environment Item: imapuser . . . . . 19
	7.3.5. Registration of Sieve Environment Item: imapemail . . . . 20		7.3.5. Registration of Sieve Environment Item: imapemail . . . . 19
	7.4. Registration of IMAP METADATA Mailbox Entry Name . . . . . 20		7.4. Registration of IMAP METADATA Mailbox Entry Name . . . . . 19
	7.5. Registration of IMAP METADATA Server Entry Name . . . . . 21		7.5. Registration of IMAP METADATA Server Entry Name . . . . . 20
	8. References . . . . . . . . . . . . . . . . . . . . . . . . 22		8. References . . . . . . . . . . . . . . . . . . . . . . . . 21
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 22		8.1. Normative References . . . . . . . . . . . . . . . . . . . 21
	8.2. Informative References . . . . . . . . . . . . . . . . . . 22		8.2. Informative References . . . . . . . . . . . . . . . . . . 21
	Author's Address . . . . . . . . . . . . . . . . . . . . . 24		Author's Address . . . . . . . . . . . . . . . . . . . . . 23
	1. Introduction		1. Introduction
	1.1. Overview		1.1. Overview
	Some applications have a need to apply Sieve filters [RFC5228] in		Some applications have a need to apply Sieve filters [RFC5228] in
	contexts other than initial mail delivery. This is especially true		contexts other than initial mail delivery. This is especially true
	in diverse service environments, such as when the client is		in diverse service environments, such as when the client is
	sporadically connected, is connected through a high-latency or high-		sporadically connected, is connected through a high-latency or high-
	cost channel, or is on a limited-function device. For such clients,		cost channel, or is on a limited-function device. For such clients,
	skipping to change at page 11, line 33 ¶		skipping to change at page 11, line 33 ¶
	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.
	Any site policies related to the origination of email have to be
	enforced in the submission service, which will apply the same
	policies to messages generated by the redirect action as it does to
	messages submitted directly by user agents.
	It is important to use the redirect action with great caution and
	only with the understanding and consent of the user, as it causes a
	message to be sent as a side effect of a user action (the storing or
	copying of a message, the changing of a flag). The following
	examples might represent appropriate use of redirect, if the user
	specifically chooses them:
	o The user wants messages she marks as "important" (through the
	setting of the \Flagged flag) to be redirected to her alternate
	email address.
	o The user wants messages she files (copies) into her "Funny things
	to share" mailbox to be redirected to a few friends she shares
	these with.
	o The user chooses a feature that takes messages the user copies to
	his "Junk" mailbox and redirects them to a spam analysis service.
	When the user chooses the feature, the mechanism and privacy
	consequences are clearly explained.
	But it is unlikely for examples such as these to ever be appropriate,
	and the use of redirect in these sorts of scenarios is not advisable.
	o Messages being redirected as a result of setting the \Seen flag.
	The \Seen flag is set as a result of fetching the message, and
	using redirect here is almost certainly too broad.
	o Messages being redirected in a server-wide script to a spam
	analysis service as a result of a user copying the message to his
	"Junk" mailbox.
	It would be dangerous and inappropriate for a server script to
	redirect messages on behalf of all users, likely without their
	understanding or consent. Therefore, the redirect action SHOULD NOT
	be used in server-wide scripts.
	It is also important to understand that the redirect action will not
	have access to user-agent context, such as a setting to digitally
	sign or encrypt all outgoing messages, or a setting to include a
	particular Reply-To address. Users should be cautioned, when using
	this action in their scripts, that this is the case.
	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
	(WITHOUT expunging other messages in the mailbox); alternatively, it		(WITHOUT expunging other messages in the mailbox); alternatively, it
	might choose to have expunges batched or done by a user. If the		might choose to have expunges batched or done by a user. If the
	server does the expunge, the effect is as though a client had flagged		server does the expunge, the effect is as though a client had flagged
End of changes. 8 change blocks.
	80 lines changed or deleted		33 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/