draft-ietf-extra-sieve-special-use-03.txt		draft-ietf-extra-sieve-special-use-04.txt
	EXTRA S. Bosch		EXTRA S. Bosch
	Internet-Draft Dovecot Oy		Internet-Draft Dovecot Oy
	Intended status: Standards Track September 5, 2018		Intended status: Standards Track November 27, 2018
	Expires: March 9, 2019		Expires: May 31, 2019
	Sieve Email Filtering: Delivering to Special-Use Mailboxes		Sieve Email Filtering: Delivering to Special-Use Mailboxes
	draft-ietf-extra-sieve-special-use-03		draft-ietf-extra-sieve-special-use-04
	Abstract		Abstract
	The SPECIAL-USE capability of the IMAP protocol (RFC 6154) allows		The SPECIAL-USE capability of the IMAP protocol (RFC 6154) allows
	clients to identify special-use mailboxes; e.g., where draft or sent		clients to identify special-use mailboxes; e.g., where draft or sent
	messages should be put. This simplifies client configuration. In		messages should be put. This simplifies client configuration. In
	contrast, the Sieve mail filtering language (RFC 5228) currently has		contrast, the Sieve mail filtering language (RFC 5228) currently has
	no such capability. This memo defines a Sieve extension that fills		no such capability. This memo defines a Sieve extension that fills
	this gap: it adds a test for checking whether a special-use attribute		this gap: it adds a test for checking whether a special-use attribute
	is assigned for a particular mailbox or any mailbox, and it adds the		is assigned for a particular mailbox or any mailbox, and it adds the
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 38 ¶
	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 March 9, 2019.		This Internet-Draft will expire on May 31, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 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 14 ¶		skipping to change at page 2, line 14 ¶
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Conventions Used in This Document . . . . . . . . . . . . . . 3		2. Conventions Used in This Document . . . . . . . . . . . . . . 3
	3. Test "specialuse_exists" . . . . . . . . . . . . . . . . . . 3		3. Test "specialuse_exists" . . . . . . . . . . . . . . . . . . 3
	4. ":specialuse" Argument to "fileinto" Command . . . . . . . . 4		3.1. Equivalent IMAP Operations . . . . . . . . . . . . . . . 4
	4.1. Mailboxes Created Implicitly by the "fileinto" Command . 5		4. ":specialuse" Argument to "fileinto" Command . . . . . . . . 5
	5. Sieve Capability Strings . . . . . . . . . . . . . . . . . . 6		4.1. Mailboxes Created Implicitly by the "fileinto" Command . 6
	6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6		4.2. Equivalent IMAP Operations . . . . . . . . . . . . . . . 7
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 7		5. Sieve Capability Strings . . . . . . . . . . . . . . . . . . 8
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8		7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	10.1. Normative References . . . . . . . . . . . . . . . . . . 8		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
	10.2. Informative References . . . . . . . . . . . . . . . . . 9		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9		10.1. Normative References . . . . . . . . . . . . . . . . . . 10
			10.2. Informative References . . . . . . . . . . . . . . . . . 11
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
	1. Introduction		1. Introduction
	Commonly, several mailboxes in an IMAP message store [IMAP] have a		Commonly, several mailboxes in an IMAP message store [IMAP] have a
	special use; e.g. it is where the user's draft messages are stored,		special use; e.g. it is where the user's draft messages are stored,
	where a copy of sent messages are kept, or it is where spam messages		where a copy of sent messages are kept, or it is where spam messages
	are filed automatically at delivery. The SPECIAL-USE capability		are filed automatically at delivery. The SPECIAL-USE capability
	[SPECIAL-USE] of the IMAP protocol defines mailbox attributes that		[SPECIAL-USE] of the IMAP protocol defines mailbox attributes that
	identify these special mailboxes explicitly to the client. This way,		identify these special mailboxes explicitly to the client. This way,
	client configuration is simplified significantly. Using the CREATE-		client configuration is simplified significantly. Using the CREATE-
	skipping to change at page 3, line 24 ¶		skipping to change at page 3, line 26 ¶
	2. Conventions Used in This Document		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.
			In [IMAP] examples, "C:" and "S:" indicate lines sent by the client
			and server respectively. If such lines are wrapped without a new
			"C:" or "S:" label, then the wrapping is for editorial clarity and is
			not part of the command.
	3. Test "specialuse_exists"		3. Test "specialuse_exists"
	Usage: specialuse_exists [<mailbox: string>]		Usage: specialuse_exists [<mailbox: string>]
	<special-use-flags: string-list>		<special-use-flags: string-list>
	If the "mailbox" string argument is omitted, the "specialuse_exists"		If the "mailbox" string argument is omitted, the "specialuse_exists"
	test yields true if all of the following statements are true for each		test yields true if all of the following statements are true for each
	of the special-use flags listed in the "special-use-flags" argument:		of the special-use flags listed in the "special-use-flags" argument:
	a. at least one mailbox exists in the user's personal namespace		a. at least one mailbox exists in the user's personal namespace
	skipping to change at page 4, line 9 ¶		skipping to change at page 4, line 14 ¶
	b. that mailbox allows the user in whose context the Sieve script		b. that mailbox allows the user in whose context the Sieve script
	runs to "deliver" messages into it, and		runs to "deliver" messages into it, and
	c. that mailbox has all of the special-use flags listed in the		c. that mailbox has all of the special-use flags listed in the
	"special-use-flags" argument assigned to it.		"special-use-flags" argument assigned to it.
	Refer to the specification of the "mailboxexists" test in Section 3.1		Refer to the specification of the "mailboxexists" test in Section 3.1
	of RFC 5490 [SIEVE-MAILBOX] for a definition of when "delivery" of		of RFC 5490 [SIEVE-MAILBOX] for a definition of when "delivery" of
	messages into a mailbox is deemed possible.		messages into a mailbox is deemed possible.
			3.1. Equivalent IMAP Operations
			To clarify, a sequence of [IMAP] commands that a client could send to
			perform an assessment without Sieve that is equivalent to the
			"specialuse_exists" test is shown in the following IMAP protocol
			examples.
			First, the client queries which namespaces are available using the
			NAMESPACE command [NAMESPACE]:
			C: A01 NAMESPACE
			S: * NAMESPACE (("INBOX/" "/")("Archive/" "/")) NIL (("Public/" "/"))
			S: A01 OK NAMESPACE command completed
			Subsequently, when no particular mailbox is of interest (i.e., the
			"specialuse_exists" test has no mailbox argument), the client lists
			all mailboxes with special-use flags in the two returned personal
			namespaces (this extended LIST command requires the LIST-EXTENDED
			IMAP capability [LIST-EXTENDED]):
			C: A02 LIST (SPECIAL-USE) "" ("INBOX/*" "Archive/*")
			RETURN (SPECIAL-USE)
			S: * LIST (\Drafts) "/" INBOX/Drafts
			S: * LIST (\Trash) "/" INBOX/Trash
			S: * LIST (\Sent) "/" INBOX/Sent
			S: * LIST (\Archive) "/" Archive/Default
			S: A02 OK LIST command completed
			Finally, using the MYRIGHTS command [IMAP-ACL], the client determines
			the access rights it has for the mailbox or mailboxes that have all
			the requested flags assigned. This way, it can determine whether
			messages can be saved to any of those. In this example, an
			"\Archive" special-use mailbox is sought:
			C: A03 MYRIGHTS Archive/Default
			S: * MYRIGHTS Archive/Default lrwsip
			S: A03 OK Myrights completed
			The MYRIGHTS response indicates that the the user has "insert" rights
			[IMAP-ACL] for the "Archive/Default" mailbox, meaning that the client
			can deliver (APPEND) messages to that mailbox and that the Sieve
			"specialuse_exists" test would yield "true" in this case.
	4. ":specialuse" Argument to "fileinto" Command		4. ":specialuse" Argument to "fileinto" Command
	Usage: fileinto [:specialuse <special-use-flag: string>]		Usage: fileinto [:specialuse <special-use-flag: string>]
	<mailbox: string>		<mailbox: string>
	Normally, the "fileinto" command delivers the message in the mailbox		Normally, the "fileinto" command delivers the message in the mailbox
	specified using its positional mailbox argument. However, if the		specified using its positional mailbox argument. However, if the
	optional ":specialuse" argument is also specified, the "fileinto"		optional ":specialuse" argument is also specified, the "fileinto"
	command first checks whether a mailbox exists in the user's personal		command first checks whether a mailbox exists in the user's personal
	namespace [NAMESPACE] with the specified special-use flag assigned to		namespace [NAMESPACE] with the specified special-use flag assigned to
	skipping to change at page 6, line 5 ¶		skipping to change at page 7, line 5 ¶
	change: the Sieve interpreter will implicitly create the specified		change: the Sieve interpreter will implicitly create the specified
	default mailbox if needed. This need arises when both the special-		default mailbox if needed. This need arises when both the special-
	use mailbox and the default mailbox are not found.		use mailbox and the default mailbox are not found.
	If the server implementation supports the CREATE-SPECIAL-USE		If the server implementation supports the CREATE-SPECIAL-USE
	capability [SPECIAL-USE] for IMAP (i.e., it allows assigning special-		capability [SPECIAL-USE] for IMAP (i.e., it allows assigning special-
	use flags to new mailboxes) it SHOULD assign the special-use flag		use flags to new mailboxes) it SHOULD assign the special-use flag
	specified with the ":specialuse" argument to the newly created		specified with the ":specialuse" argument to the newly created
	mailbox.		mailbox.
			4.2. Equivalent IMAP Operations
			To clarify, a sequence of [IMAP] commands that a client could send to
			perform an action without Sieve that is equivalent to the "fileinto"
			action with the ":specialuse" argument is shown in the following IMAP
			protocol examples. The following Sieve script is assumed:
			require "fileinto";
			require "special-use";
			fileinto :specialuse "\\Archive" "INBOX/Archive";
			First, the client proceeds as in Section 3.1 to find out whether the
			indicated special-use flag is assigned to any mailbox in the user's
			personal namespace. If a matching special-use mailbox is found, the
			message is delivered there using the IMAP APPEND command. If no
			matching special-use mailbox is found, the client attempts to deliver
			the message to the indicated default mailbox:
			C: A04 APPEND INBOX/Archive {309}
			S: A04 NO [TRYCREATE] Mailbox does not exist: Archive/Personal
			In this example, the default mailbox does not exist either. In that
			case, the client MAY create the default mailbox and assign the
			indicated special-use flag to it:
			C: A05 CREATE INBOX/Archive (USE (\Archive))
			S: A05 OK Create completed
			Finally, the client completes the delivery:
			C: A06 APPEND INBOX/Archive {309}
			S: + OK
			C: Date: Wed, 18 Jul 2018 22:00:09 +0200
			C: From: mooch@owatagu.siam.edu
			C: To: Fred Foobar <foobar@Blurdybloop.com>
			C: Subject: afternoon meeting
			C: Message-Id: <Q234234-01012222@owatagu.siam.edu>
			C: MIME-Version: 1.0
			C: Content-Type: text/plain; charset=UTF-8
			C:
			C: Hi Fred, do you think we can meet again at 3:30 tomorrow?
			C:
			S: A06 OK [APPENDUID 1533375901 2312] Append completed.
	5. Sieve Capability Strings		5. Sieve Capability Strings
	A Sieve implementation that defines the "specialuse_exists" test and		A Sieve implementation that defines the "specialuse_exists" test and
	the ":specialuse" argument for the "fileinto" command will advertise		the ":specialuse" argument for the "fileinto" command will advertise
	the capability string "special-use".		the capability string "special-use".
	6. Examples		6. Examples
	The following example saves the message in the mailbox where messages		The following example saves the message in the mailbox where messages
	deemed to be junk mail are held. This mailbox is identified using		deemed to be junk mail are held. This mailbox is identified using
	skipping to change at page 9, line 25 ¶		skipping to change at page 11, line 25 ¶
	[VARIABLES]		[VARIABLES]
	Homme, K., "Sieve Email Filtering: Variables Extension",		Homme, K., "Sieve Email Filtering: Variables Extension",
	RFC 5229, January 2008.		RFC 5229, January 2008.
	10.2. Informative References		10.2. Informative References
	[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION		[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
	4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,		4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
	<http://www.rfc-editor.org/info/rfc3501>.		<http://www.rfc-editor.org/info/rfc3501>.
			[IMAP-ACL]
			Melnikov, A., "IMAP4 Access Control List (ACL) Extension",
			RFC 4314, DOI 10.17487/RFC4314, December 2005,
			<https://www.rfc-editor.org/info/rfc4314>.
	[IMAPSIEVE]		[IMAPSIEVE]
	Leiba, B., "Support for Internet Message Access Protocol		Leiba, B., "Support for Internet Message Access Protocol
	(IMAP) Events in Sieve", RFC 6785, DOI 10.17487/RFC6785,		(IMAP) Events in Sieve", RFC 6785, DOI 10.17487/RFC6785,
	November 2012, <http://www.rfc-editor.org/info/rfc6785>.		November 2012, <http://www.rfc-editor.org/info/rfc6785>.
			[LIST-EXTENDED]
			Leiba, B. and A. Melnikov, "Internet Message Access
			Protocol version 4 - LIST Command Extensions", RFC 5258,
			DOI 10.17487/RFC5258, June 2008, <https://www.rfc-
			editor.org/info/rfc5258>.
	Author's Address		Author's Address
	Stephan Bosch		Stephan Bosch
	Dovecot Oy		Dovecot Oy
	Lars Sonckin Kaari 12		Lars Sonckin Kaari 12
	Espoo 02600		Espoo 02600
	Finland		Finland
	Email: stephan.bosch@dovecot.fi		Email: stephan.bosch@dovecot.fi
End of changes. 9 change blocks.
	15 lines changed or deleted		120 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/