draft-ietf-extra-sieve-special-use-05.txt		rfc8579.txt
	EXTRA S. Bosch		Internet Engineering Task Force (IETF) S. Bosch
	Internet-Draft Open Xchange Oy		Request for Comments: 8579 Open Xchange Oy
	Intended status: Standards Track January 25, 2019		Category: Standards Track May 2019
	Expires: July 29, 2019		ISSN: 2070-1721
	Sieve Email Filtering: Delivering to Special-Use Mailboxes		Sieve Email Filtering: Delivering to Special-Use Mailboxes
	draft-ietf-extra-sieve-special-use-05
	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
	ability to file messages into a mailbox identified solely by a		ability to file messages into a mailbox identified solely by a
	special-use attribute.		special-use attribute.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This is an Internet Standards Track document.
	provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any		(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference		received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."		Internet Engineering Steering Group (IESG). Further information on
			Internet Standards is available in Section 2 of RFC 7841.
	This Internet-Draft will expire on July 29, 2019.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			https://www.rfc-editor.org/info/rfc8579.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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		(https://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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	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
	3.1. Equivalent IMAP Operations . . . . . . . . . . . . . . . 4		3.1. Equivalent IMAP Operations . . . . . . . . . . . . . . . 4
	4. ":specialuse" Argument to "fileinto" Command . . . . . . . . 5		4. ":specialuse" Argument to "fileinto" Command . . . . . . . . 5
	4.1. Mailboxes Created Implicitly by the "fileinto" Command . 6		4.1. Mailboxes Created Implicitly by the "fileinto" Command . 6
	4.2. Equivalent IMAP Operations . . . . . . . . . . . . . . . 7		4.2. Equivalent IMAP Operations . . . . . . . . . . . . . . . 7
	5. Sieve Capability Strings . . . . . . . . . . . . . . . . . . 8		5. Sieve Capability Strings . . . . . . . . . . . . . . . . . . 8
	6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8		6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 9		7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10		9.1. Normative References . . . . . . . . . . . . . . . . . . 10
	10.1. Normative References . . . . . . . . . . . . . . . . . . 10		9.2. Informative References . . . . . . . . . . . . . . . . . 11
	10.2. Informative References . . . . . . . . . . . . . . . . . 11		Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
	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. For example, there can be a special-use mailbox for		special use. For example, there can be a special-use mailbox for
	storing the user's draft messages, for keeping copies of sent		storing the user's draft messages, for keeping copies of sent
	messages, and for collecting spam messages that were classified as		messages, and for collecting spam messages that were classified as
	such at delivery. The SPECIAL-USE capability [SPECIAL-USE] of the		such at delivery. The SPECIAL-USE capability [SPECIAL-USE] of the
	IMAP protocol defines mailbox attributes that identify these special		IMAP protocol defines mailbox attributes that identify these special
	mailboxes explicitly to the client. This way, client configuration		mailboxes explicitly to the client. This way, client configuration
	is simplified significantly. Using the CREATE-SPECIAL-USE capability		is simplified significantly. Using the CREATE-SPECIAL-USE capability
	[SPECIAL-USE], IMAP clients can also configure these attributes		[SPECIAL-USE], IMAP clients can also configure these attributes
	dynamically based on user preference.		dynamically based on user preference.
	Unlike the IMAP protocol, the Sieve mail filtering language [SIEVE]		Unlike the IMAP protocol, the Sieve mail filtering language [SIEVE]
	currently cannot freely access these special-use mailbox attributes.		currently cannot freely access these special-use mailbox attributes.
	Particularly, the Sieve interpreter has no means to identify a		Particularly, the Sieve interpreter has no means to identify a
	mailbox with a particular special-use attribute. This would be very		mailbox with a particular special-use attribute. This would be very
	useful for example to find the user's Spam mailbox at delivery.		useful, for example, to find the user's "Spam" mailbox at delivery.
	In Sieve, limited access to the special-use attributes is provided		In Sieve, limited access to the special-use attributes is provided
	using the "mboxmetadata" extension [SIEVE-MAILBOX], which allows		using the "mboxmetadata" extension [SIEVE-MAILBOX], which allows
	testing for the presence of a special-use attribute in the "/private/		testing for the presence of a special-use attribute in the "/private/
	specialuse" IMAP METADATA [IMAP-METADATA] entry of a mailbox. Still,		specialuse" IMAP METADATA [IMAP-METADATA] entry of a mailbox. Still,
	not all implementers will be willing to add the complexity of the		not all implementers will be willing to add the complexity of the
	IMAP METADATA capability, just to provide access to special-use		IMAP METADATA capability just to provide access to special-use
	attributes to the Sieve interpreter.		attributes to the Sieve interpreter.
	This document defines an extension to the Sieve mail filtering		This document defines an extension to the Sieve mail filtering
	language that adds the ability to freely access mailbox special-use		language that adds the ability to freely access mailbox special-use
	attributes. It adds a test called "specialuse_exists" that checks		attributes. It adds a test called "specialuse_exists" that checks 1)
	whether a special-use attribute is assigned for a particular mailbox		whether a special-use attribute is assigned for a particular mailbox
	or - if omitted - any of the user's personal mailboxes. It also adds		or 2) whether any of the user's personal mailboxes have a special-use
	the ability to file messages into a personal mailbox identified by a		attribute assigned. It also adds the ability to file messages into a
	particular special-use attribute rather than the mailbox's name.		personal mailbox identified by a particular special-use attribute
	This is achieved using the new ":specialuse" argument for the		rather than the mailbox's name. This is achieved using the new
	"fileinto" command [SIEVE].		":specialuse" argument for the "fileinto" command [SIEVE].
	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", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	BCP 14 [KEYWORDS] [KEYWORDS-UPD] when, and only when, they appear in		BCP 14 [KEYWORDS] [KEYWORDS-UPD] when, and only when, they appear in
	all capitals, as shown here.		all capitals, as shown here.
	Conventions for notations are as in [SIEVE] Section 1.1, including		Conventions for notations are as described in Section 1.1 of [SIEVE],
	use of the "Usage:" label for the definition of action and tagged		including use of the "Usage:" label for the definition of the action
	arguments syntax.		and the syntax of tagged arguments.
	In [IMAP] examples, "C:" and "S:" indicate lines sent by the client		In [IMAP] examples, "C:" and "S:" indicate lines sent by the client
	and server respectively. If such lines are wrapped without a new		and server, respectively. If such lines are wrapped without a new
	"C:" or "S:" label, then the wrapping is for editorial clarity and is		"C:" or "S:" label, then the wrapping is for editorial clarity and is
	not part of the command.		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-attrs: string-list>		<special-use-attrs: 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
	of the special-use attributes listed in the "special-use-attrs"		each of the special-use attributes listed in the special-use-attrs
	argument:		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
	[NAMESPACE] that has that particular special-use attribute		[NAMESPACE] that has that particular special-use attribute
	assigned, and		assigned.
	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.		runs to "deliver" messages into it.
	If the "mailbox" argument is specified, the "specialuse_exists" test		If the mailbox argument is specified, the "specialuse_exists" test
	yields true if all of the following statements are true:		yields "true" if all of the following statements are true:
	a. the indicated mailbox exists,		a. The indicated mailbox exists.
	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.
	c. that mailbox has all of the special-use attributes listed in the		c. That mailbox has all of the special-use attributes listed in the
	"special-use-attrs" argument assigned to it.		special-use-attrs 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		3.1. Equivalent IMAP Operations
	To clarify, a sequence of [IMAP] commands that a client could send to		To clarify, the following IMAP protocol examples show a sequence of
	perform an assessment without Sieve that is equivalent to the		[IMAP] commands that a client could send to perform an assessment
	"specialuse_exists" test is shown in the following IMAP protocol		without Sieve that is equivalent to the "specialuse_exists" test.
	examples.
	First, the client queries which namespaces are available using the		First, the client queries which namespaces are available using the
	NAMESPACE command [NAMESPACE]:		NAMESPACE command [NAMESPACE]:
	C: A01 NAMESPACE		C: A01 NAMESPACE
	S: * NAMESPACE (("INBOX/" "/")("Archive/" "/")) NIL (("Public/" "/"))		S: * NAMESPACE (("INBOX/" "/")("Archive/" "/")) NIL (("Public/" "/"))
	S: A01 OK NAMESPACE command completed		S: A01 OK NAMESPACE command completed
	Subsequently, when no particular mailbox is of interest (i.e., the		Subsequently, when no particular mailbox is of interest (i.e., the
	"specialuse_exists" test has no mailbox argument), the client lists		"specialuse_exists" test has no mailbox argument), the client lists
	skipping to change at page 5, line 9 ¶		skipping to change at page 5, line 9 ¶
	Finally, using the MYRIGHTS command [IMAP-ACL], the client determines		Finally, using the MYRIGHTS command [IMAP-ACL], the client determines
	the access rights it has for the mailbox or mailboxes that have all		the access rights it has for the mailbox or mailboxes that have all
	the requested attributes assigned. This way, it can determine		the requested attributes assigned. This way, it can determine
	whether messages can be saved to any of those. In this example, an		whether messages can be saved to any of those. In this example, an
	"\Archive" special-use mailbox is sought:		"\Archive" special-use mailbox is sought:
	C: A03 MYRIGHTS Archive/Default		C: A03 MYRIGHTS Archive/Default
	S: * MYRIGHTS Archive/Default lrwsip		S: * MYRIGHTS Archive/Default lrwsip
	S: A03 OK Myrights completed		S: A03 OK Myrights completed
	The MYRIGHTS response indicates that the the user has "insert" rights		The MYRIGHTS response indicates that the user has "insert" rights
	[IMAP-ACL] for the "Archive/Default" mailbox, meaning that the client		[IMAP-ACL] for the "Archive/Default" mailbox, meaning that the client
	can deliver (APPEND) messages to that mailbox and that the Sieve		can deliver (APPEND) messages to that mailbox and that the Sieve
	"specialuse_exists" test would yield "true" in this case.		"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-attr: string>]		Usage: fileinto [:specialuse <special-use-attr: 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, which is the name of		specified using its positional mailbox argument, which is the name of
	the mailbox. However, if the optional ":specialuse" argument is also		the mailbox. However, if the optional ":specialuse" argument is also
	specified, the "fileinto" command first checks whether a mailbox		specified, the "fileinto" command first checks whether a mailbox
	exists in the user's personal namespace [NAMESPACE] with the		exists in the user's personal namespace [NAMESPACE] with the
	specified special-use attribute assigned to it. If that is the case,		specified special-use attribute assigned to it. If that is the case,
	that special-use mailbox is used for delivery instead. If there is		that special-use mailbox is used for delivery instead. If there is
	no such mailbox or if the specified special-use attribute is unknown		no such mailbox or if the specified special-use attribute is unknown
	to the implementation in general, the "fileinto" action proceeds as		to the implementation in general, the "fileinto" action proceeds as
	it would without the ":specialuse" argument.		it would without the ":specialuse" argument.
	Summarizing, if the ":specialuse" argument is specified, the fileinto		Summarizing, if the ":specialuse" argument is specified, the
	command deals with two mailboxes that may or may not exist and may in		"fileinto" command deals with two mailboxes that may or may not exist
	fact be equal:		and may, in fact, be equal:
	o A special-use mailbox in the user's personal namespace, which has		o A special-use mailbox in the user's personal namespace, which has
	at least the special-use attribute specified with the		at least the special-use attribute specified with the
	":specialuse" argument assigned to it. The name for this mailbox		":specialuse" argument assigned to it. The name for this mailbox
	is not relevant here: it is only identified by the assigned		is not relevant here; it is only identified by the assigned
	special-use attribute.		special-use attribute.
	o The default mailbox named by the positional string argument of the		o The default mailbox named by the positional string argument of the
	"fileinto" command, which is used when the special-use mailbox is		"fileinto" command, which is used when the special-use mailbox is
	not found.		not found.
	The special-use attribute specified with the ':specialuse' argument		The special-use attribute specified with the ":specialuse" argument
	conforms to the 'use-attr' syntax described in Section 6 of RFC6154		conforms to the "use-attr" syntax described in Section 6 of RFC 6154
	[SIEVE-MAILBOX]. Implementations SHOULD handle an invalid special-		[SPECIAL-USE]. Implementations SHOULD handle an invalid special-use
	use attribute in the same way as an invalid mailbox name is handled.		attribute in the same way as an invalid mailbox name is handled. The
	The string parameter of the ":specialuse" argument is not a constant		string parameter of the ":specialuse" argument is not a constant
	string, which means that variable substitutions are allowed when the		string, which means that variable substitutions are allowed when the
	"variables" extension [VARIABLES] is active. In that case, the		"variables" extension [VARIABLES] is active. In that case, the
	syntax of the special-use attribute is only verified at runtime.		syntax of the special-use attribute is only verified at runtime.
	If neither the special-use mailbox nor the default mailbox exists,		If neither the special-use mailbox nor the default mailbox exists,
	the "fileinto" action MUST proceed exactly as it does in case the		the "fileinto" action MUST proceed exactly as it does in case the
	":specialuse" is argument is absent and the mailbox named by its		":specialuse" argument is absent and the mailbox named by its
	positional argument does not exist. The various options for handling		positional argument does not exist. The various options for handling
	this situation are described in Section 4.1 of RFC5228 [SIEVE].		this situation are described in Section 4.1 of RFC 5228 [SIEVE].
	More than one mailbox in the user's personal namespace can have a		More than one mailbox in the user's personal namespace can have a
	particular special-use attribute assigned. If one of those mailboxes		particular special-use attribute assigned. If one of those mailboxes
	is in fact the default mailbox named by the positional string		is, in fact, the default mailbox named by the positional string
	argument of the "fileinto" command, that mailbox MUST be used for		argument of the "fileinto" command, that mailbox MUST be used for
	delivery. If the default mailbox is not one of the options, the		delivery. If the default mailbox is not one of the options, the
	mailbox that is chosen for delivery is implementation-defined.		mailbox that is chosen for delivery is implementation defined.
	However, while the set of mailboxes to which the involved special-use		However, while the set of mailboxes to which the involved special-use
	attribute are assigned remains unchanged, implementations SHOULD		attribute are assigned remains unchanged, implementations SHOULD
	ensure that the mailbox choice is made consistently, so that the same		ensure that the mailbox choice is made consistently, so that the same
	mailbox is used every time. Conversely, the chosen mailbox MAY		mailbox is used every time. Conversely, the chosen mailbox MAY
	change once the special-use attribute assignments that are relevant		change once the assignments of the special-use attribute that are
	for the mailbox choice are changed (usually by user interaction).		relevant for the mailbox choice are changed (usually by user
			interaction).
	If delivery to the special-use mailbox fails for reasons not relating		If delivery to the special-use mailbox fails for reasons not relating
	to its existence, the Sieve interpreter MUST NOT subsequently attempt		to its existence, the Sieve interpreter MUST NOT subsequently attempt
	delivery in the indicated default mailbox as a fall-back. Instead,		delivery in the indicated default mailbox as a fallback. Instead, it
	it MUST proceed exactly as it does in case the ":specialuse" argument		MUST proceed exactly as it does in case the ":specialuse" argument is
	is absent and delivery to the mailbox named by its positional		absent and delivery to the mailbox named by its positional argument
	argument fails. This prevents the situation where messages are		fails. This prevents the situation where messages are unexpectedly
	unexpectedly spread over two mailboxes in case transient or		spread over two mailboxes in case transient or intermittent delivery
	intermittent delivery failures occur.		failures occur.
	4.1. Mailboxes Created Implicitly by the "fileinto" Command		4.1. Mailboxes Created Implicitly by the "fileinto" Command
	Before attempting to deliver the message into the specified mailbox,		Before attempting to deliver the message into the specified mailbox,
	the "fileinto" command may implicitly create the mailbox if it does		the "fileinto" command may implicitly create the mailbox if it does
	not exist (see Section 4.1 of RFC5228 [SIEVE]). This optional		not exist (see Section 4.1 of RFC 5228 [SIEVE]). This optional
	behavior can be requested explicitly using the "mailbox" extension		behavior can be requested explicitly using the "mailbox" extension
	[SIEVE-MAILBOX], which adds the optional ":create" argument to the		[SIEVE-MAILBOX], which adds the optional ":create" argument to the
	"fileinto" command. If the ":create" argument is specified with		"fileinto" command. If the ":create" argument is specified with
	"fileinto", it instructs the Sieve interpreter to unconditionally		"fileinto", it instructs the Sieve interpreter to unconditionally
	create the specified mailbox if needed. Note that the ":create"		create the specified mailbox if needed. Note that the ":create"
	argument has no effect when the implicit creation of mailboxes for		argument has no effect when the implicit creation of mailboxes for
	delivery is the default behavior.		delivery is the default behavior.
	When the ":specialuse" argument is present, this behavior does not		When the ":specialuse" argument is present, this behavior does not
	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 attributes to new mailboxes) it SHOULD assign the special-use		use attributes to new mailboxes), it SHOULD assign the special-use
	attribute specified with the ":specialuse" argument to the newly		attribute specified with the ":specialuse" argument to the newly
	created mailbox.		created mailbox.
	4.2. Equivalent IMAP Operations		4.2. Equivalent IMAP Operations
	To clarify, a sequence of [IMAP] commands that a client could send to		To clarify, the following IMAP protocol examples show a sequence of
	perform an action without Sieve that is equivalent to the "fileinto"		[IMAP] commands that a client could send to perform an action without
	action with the ":specialuse" argument is shown in the following IMAP		Sieve that is equivalent to the "fileinto" action with the
	protocol examples. The following Sieve script is assumed:		":specialuse" argument. The following Sieve script is assumed:
	require "fileinto";		require "fileinto";
	require "special-use";		require "special-use";
	fileinto :specialuse "\\Archive" "INBOX/Archive";		fileinto :specialuse "\\Archive" "INBOX/Archive";
	First, the client proceeds as in Section 3.1 to find out whether the		First, the client proceeds as in Section 3.1 to find out whether the
	indicated special-use attribute is assigned to any mailbox in the		indicated special-use attribute is assigned to any mailbox in the
	user's personal namespace. If a matching special-use mailbox is		user's personal namespace. If a matching special-use mailbox is
	found, the message is delivered there using the IMAP APPEND command.		found, the message is delivered there using the IMAP APPEND command.
	skipping to change at page 8, line 18 ¶		skipping to change at page 8, line 33 ¶
	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
	the "\Junk" special-use attribute. If no mailbox has this attribute		the "\Junk" special-use attribute. If no mailbox has this attribute
	assigned, the message is filed into the mailbox named "Spam". If the		assigned, the message is filed into the mailbox named "Spam". If the
	mailbox named "Spam" does not exist either, the result of this Sieve		mailbox named "Spam" does not exist either, the result of this Sieve
	script is implementation-dependent: e.g., it may trigger an error or		script is implementation dependent, e.g., it may trigger an error or
	the mailbox may be created implicitly.		the mailbox may be created implicitly.
	require "fileinto";		require "fileinto";
	require "special-use";		require "special-use";
	fileinto :specialuse "\\Junk" "Spam";		fileinto :specialuse "\\Junk" "Spam";
	The following very similar example explicitly handles the case in		The following very similar example explicitly handles the case in
	which neither a "\Junk" special-use mailbox nor the "Spam" mailbox		which neither a "\Junk" special-use mailbox nor the "Spam" mailbox
	exist. In that case, a mailbox called "Spam" is created, and the		exists. In that case, a mailbox called "Spam" is created, and the
	message is stored there. Additionally, the "\Junk" special-use		message is stored there. Additionally, the "\Junk" special-use
	attribute may be assigned to it.		attribute may be assigned to it.
	require "fileinto";		require "fileinto";
	require "special-use";		require "special-use";
	require "mailbox";		require "mailbox";
	fileinto :specialuse "\\Junk" :create "Spam";		fileinto :specialuse "\\Junk" :create "Spam";
	The following example is used in a Sieve script that is triggered		The following example is used in a Sieve script that is triggered
	from an IMAP event, rather than at message delivery [IMAPSIEVE].		from an IMAP event rather than at message delivery [IMAPSIEVE]. This
	This Sieve script redirects messages to an automated recipient that		Sieve script redirects messages to an automated recipient that
	processes junk mail, if those messages are copied or moved into a		processes junk mail if those messages are copied or moved into a
	mailbox that has the "\Junk" special-use attribute assigned.		mailbox that has the "\Junk" special-use attribute assigned.
	require "imapsieve";		require "imapsieve";
	require "special-use";		require "special-use";
	require "environment";		require "environment";
	require "variables";		require "variables";
	if environment :contains "imap.mailbox" "*" {		if environment :contains "imap.mailbox" "*" {
	set "mailbox" "${1}";		set "mailbox" "${1}";
	}		}
	skipping to change at page 9, line 40 ¶		skipping to change at page 9, line 45 ¶
	on the system, while shared special-use mailboxes are deemed of		on the system, while shared special-use mailboxes are deemed of
	limited use with the currently defined special-use attributes.		limited use with the currently defined special-use attributes.
	Secondly, it prevents security concerns with shared mailboxes that		Secondly, it prevents security concerns with shared mailboxes that
	have special-use attributes assigned that apply to all users.		have special-use attributes assigned that apply to all users.
	Searching the entire mail storage for special-use mailboxes could		Searching the entire mail storage for special-use mailboxes could
	lead to messages unexpectedly or even maliciously being filed to		lead to messages unexpectedly or even maliciously being filed to
	shared mailboxes.		shared mailboxes.
	This restriction could be lifted for particular future special-use		This restriction could be lifted for particular future special-use
	attributes, but such new attributes should have a clear application		attributes, but such new attributes should have a clear application
	for shared mailboxes and the security concerns should be considered		for shared mailboxes, and the security concerns should be considered
	carefully.		carefully.
	8. IANA Considerations		8. IANA Considerations
	The following template specifies the IANA registration of the Sieve		IANA has registered the Sieve extension specified in this document in
	extension specified in this document:		the "Sieve Extensions" registry at <https://www.iana.org/assignments/
			sieve-extensions>:
	To: iana@iana.org
	Subject: Registration of new Sieve extension
	Capability name: special-use		Capability name: special-use
	Description: adds a test for checking whether an IMAP		Description: adds a test for checking whether an IMAP
	special-use attribute is assigned for a		special-use attribute is assigned for a
	particular mailbox or any mailbox, and it adds		particular mailbox or any mailbox; also adds
	the ability to file messages into a mailbox		the ability to file messages into a mailbox
	identified solely by a special-use attribute.		identified solely by a special-use attribute.
	RFC number: this RFC		RFC number: RFC 8579
	Contact address: Sieve mailing list <sieve@ietf.org>		Contact address: Sieve discussion list <sieve@ietf.org>
	This information should be added to the list of sieve extensions
	given on http://www.iana.org/assignments/sieve-extensions.
	9. Acknowledgements
	Thanks to Stan Kalisch, Barry Leiba, Alexey Melnikov, Ken Murchison,
	and Ned Freed for reviews and suggestions.
	Thanks to the authors of RFC5490 [SIEVE-MAILBOX] from which some
	descriptive text is borrowed in this document.
	10. References		9. References
	10.1. Normative References		9.1. Normative References
	[IMAP-METADATA]		[IMAP-METADATA]
	Daboo, C., "The IMAP METADATA Extension", RFC 5464,		Daboo, C., "The IMAP METADATA Extension", RFC 5464,
	DOI 10.17487/RFC5464, February 2009,		DOI 10.17487/RFC5464, February 2009,
	<http://www.rfc-editor.org/info/rfc5464>.		<https://www.rfc-editor.org/info/rfc5464>.
	[KEYWORDS]		[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
	Bradner, S., "Key words for use in RFCs to Indicate		Requirement Levels", BCP 14, RFC 2119,
	Requirement Levels", BCP 14, RFC 2119, March 1997.		DOI 10.17487/RFC2119, March 1997,
			<https://www.rfc-editor.org/info/rfc2119>.
	[KEYWORDS-UPD]		[KEYWORDS-UPD]
	Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[NAMESPACE]		[NAMESPACE]
	Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342,		Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342,
	DOI 10.17487/RFC2342, May 1998, <https://www.rfc-		DOI 10.17487/RFC2342, May 1998,
	editor.org/info/rfc2342>.		<https://www.rfc-editor.org/info/rfc2342>.
	[SIEVE] Guenther, P. and T. Showalter, "Sieve: An Email Filtering		[SIEVE] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email
	Language", RFC 5228, January 2008.		Filtering Language", RFC 5228, DOI 10.17487/RFC5228,
			January 2008, <https://www.rfc-editor.org/info/rfc5228>.
	[SIEVE-MAILBOX]		[SIEVE-MAILBOX]
	Melnikov, A., "The Sieve Mail-Filtering Language --		Melnikov, A., "The Sieve Mail-Filtering Language --
	Extensions for Checking Mailbox Status and Accessing		Extensions for Checking Mailbox Status and Accessing
	Mailbox Metadata", RFC 5490, March 2009.		Mailbox Metadata", RFC 5490, DOI 10.17487/RFC5490, March
			2009, <https://www.rfc-editor.org/info/rfc5490>.
	[SPECIAL-USE]		[SPECIAL-USE]
	Leiba, B. and J. Nicolson, "IMAP LIST Extension for		Leiba, B. and J. Nicolson, "IMAP LIST Extension for
	Special-Use Mailboxes", RFC 6154, DOI 10.17487/RFC6154,		Special-Use Mailboxes", RFC 6154, DOI 10.17487/RFC6154,
	March 2011, <http://www.rfc-editor.org/info/rfc6154>.		March 2011, <https://www.rfc-editor.org/info/rfc6154>.
	[VARIABLES]		[VARIABLES]
	Homme, K., "Sieve Email Filtering: Variables Extension",		Homme, K., "Sieve Email Filtering: Variables Extension",
	RFC 5229, January 2008.		RFC 5229, DOI 10.17487/RFC5229, January 2008,
			<https://www.rfc-editor.org/info/rfc5229>.
	10.2. Informative References		9.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>.		<https://www.rfc-editor.org/info/rfc3501>.
	[IMAP-ACL]		[IMAP-ACL] Melnikov, A., "IMAP4 Access Control List (ACL) Extension",
	Melnikov, A., "IMAP4 Access Control List (ACL) Extension",
	RFC 4314, DOI 10.17487/RFC4314, December 2005,		RFC 4314, DOI 10.17487/RFC4314, December 2005,
	<https://www.rfc-editor.org/info/rfc4314>.		<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, <https://www.rfc-editor.org/info/rfc6785>.
	[LIST-EXTENDED]		[LIST-EXTENDED]
	Leiba, B. and A. Melnikov, "Internet Message Access		Leiba, B. and A. Melnikov, "Internet Message Access
	Protocol version 4 - LIST Command Extensions", RFC 5258,		Protocol version 4 - LIST Command Extensions", RFC 5258,
	DOI 10.17487/RFC5258, June 2008, <https://www.rfc-		DOI 10.17487/RFC5258, June 2008,
	editor.org/info/rfc5258>.		<https://www.rfc-editor.org/info/rfc5258>.
			Acknowledgements
			Thanks to Stan Kalisch, Barry Leiba, Alexey Melnikov, Ken Murchison,
			and Ned Freed for reviews and suggestions.
			Thanks to the authors of RFC 5490 [SIEVE-MAILBOX], from which some
			descriptive text in this document is borrowed.
	Author's Address		Author's Address
	Stephan Bosch		Stephan Bosch
	Open Xchange Oy		Open Xchange Oy
	Lars Sonckin kaari 12		Lars Sonckin kaari 12
	Espoo 02600		Espoo 02600
	Finland		Finland
	Email: stephan.bosch@open-xchange.com		Email: stephan.bosch@open-xchange.com
End of changes. 59 change blocks.
	128 lines changed or deleted		121 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/