idnits 2.17.1 draft-ietf-extra-sieve-special-use-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 5, 2018) is 2060 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 3501 (ref. 'IMAP') (Obsoleted by RFC 9051) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 EXTRA S. Bosch 3 Internet-Draft Dovecot Oy 4 Intended status: Standards Track September 5, 2018 5 Expires: March 9, 2019 7 Sieve Email Filtering: Delivering to Special-Use Mailboxes 8 draft-ietf-extra-sieve-special-use-03 10 Abstract 12 The SPECIAL-USE capability of the IMAP protocol (RFC 6154) allows 13 clients to identify special-use mailboxes; e.g., where draft or sent 14 messages should be put. This simplifies client configuration. In 15 contrast, the Sieve mail filtering language (RFC 5228) currently has 16 no such capability. This memo defines a Sieve extension that fills 17 this gap: it adds a test for checking whether a special-use attribute 18 is assigned for a particular mailbox or any mailbox, and it adds the 19 ability to file messages into an anonymous mailbox that has a 20 particular special-use attribute assigned. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on March 9, 2019. 39 Copyright Notice 41 Copyright (c) 2018 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 58 3. Test "specialuse_exists" . . . . . . . . . . . . . . . . . . 3 59 4. ":specialuse" Argument to "fileinto" Command . . . . . . . . 4 60 4.1. Mailboxes Created Implicitly by the "fileinto" Command . 5 61 5. Sieve Capability Strings . . . . . . . . . . . . . . . . . . 6 62 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 64 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 65 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 66 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 68 10.2. Informative References . . . . . . . . . . . . . . . . . 9 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 71 1. Introduction 73 Commonly, several mailboxes in an IMAP message store [IMAP] have a 74 special use; e.g. it is where the user's draft messages are stored, 75 where a copy of sent messages are kept, or it is where spam messages 76 are filed automatically at delivery. The SPECIAL-USE capability 77 [SPECIAL-USE] of the IMAP protocol defines mailbox attributes that 78 identify these special mailboxes explicitly to the client. This way, 79 client configuration is simplified significantly. Using the CREATE- 80 SPECIAL-USE capability [SPECIAL-USE], IMAP clients can also configure 81 these attributes dynamically based on user preference. 83 Unlike the IMAP protocol, the Sieve mail filtering language [SIEVE] 84 currently cannot freely access these special-use mailbox attributes. 85 Particularly, the Sieve interpreter cannot find an anonymous mailbox 86 that has a particular special-use attribute assigned. This would be 87 very useful for example to find the user's Spam mailbox at delivery. 89 In Sieve, limited access to the special-use attributes is provided 90 using the "mboxmetadata" extension [SIEVE-MAILBOX], which allows 91 testing for the presence of a special-use attribute in the "/private/ 92 specialuse" IMAP METADATA [IMAP-METADATA] entry of a mailbox. Still, 93 not all implementers will be willing to add the complexity of the 94 IMAP METADATA capability, just to provide access to special-use 95 attributes to the Sieve interpreter. 97 This document defines an extension to the Sieve mail filtering 98 language that adds the ability to freely access mailbox special-use 99 attributes. It adds a test called "specialuse_exists" that checks 100 whether a special-use attribute is assigned for a particular mailbox 101 or - if omitted - any of the user's personal mailboxes. It also adds 102 the ability to file messages into an anonymous personal mailbox that 103 has a particular special-use attribute assigned using a ":specialuse" 104 argument for the "fileinto" command [SIEVE]. 106 2. Conventions Used in This Document 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in [KEYWORDS]. 112 Conventions for notations are as in [SIEVE] Section 1.1, including 113 use of the "Usage:" label for the definition of action and tagged 114 arguments syntax. 116 3. Test "specialuse_exists" 118 Usage: specialuse_exists [] 119 121 If the "mailbox" string argument is omitted, the "specialuse_exists" 122 test yields true if all of the following statements are true for each 123 of the special-use flags listed in the "special-use-flags" argument: 125 a. at least one mailbox exists in the user's personal namespace 126 [NAMESPACE] that has that particular special-use flag assigned, 127 and 129 b. that mailbox allows the user in whose context the Sieve script 130 runs to "deliver" messages into it. 132 If the "mailbox" argument is specified, the "specialuse_exists" test 133 yields true if all of the following statements are true: 135 a. the indicated mailbox exists, 137 b. that mailbox allows the user in whose context the Sieve script 138 runs to "deliver" messages into it, and 140 c. that mailbox has all of the special-use flags listed in the 141 "special-use-flags" argument assigned to it. 143 Refer to the specification of the "mailboxexists" test in Section 3.1 144 of RFC 5490 [SIEVE-MAILBOX] for a definition of when "delivery" of 145 messages into a mailbox is deemed possible. 147 4. ":specialuse" Argument to "fileinto" Command 149 Usage: fileinto [:specialuse ] 150 152 Normally, the "fileinto" command delivers the message in the mailbox 153 specified using its positional mailbox argument. However, if the 154 optional ":specialuse" argument is also specified, the "fileinto" 155 command first checks whether a mailbox exists in the user's personal 156 namespace [NAMESPACE] with the specified special-use flag assigned to 157 it. If that is the case, that special-use mailbox is used for 158 delivery instead. If there is no such mailbox or if the specified 159 special-use flag is unknown to the implementation in general, the 160 "fileinto" action proceeds as it would without the ":specialuse" 161 argument. 163 Summarizing, if the ":specialuse" argument is specified, the fileinto 164 command deals with two mailboxes that may or may not exist: 166 o An anonymous special-use mailbox in the user's personal namespace, 167 which has at least the special-use flag specified with the 168 ":specialuse" argument assigned to it. 170 o The default mailbox named by the positional string argument of the 171 "fileinto" command, which is used when the special-use mailbox is 172 not found. 174 The special-use flag specified with the ":specialuse" argument MUST 175 conform to the "use-attr" syntax described in Section 6 of RFC6154 176 [SIEVE-MAILBOX]. Implementations SHOULD handle an invalid special- 177 use flag in the same way as an invalid mailbox name is handled. The 178 string parameter of the ":specialuse" argument is not a constant 179 string, which means that variable substitutions are allowed when the 180 "variables" extension [VARIABLES] is active. In that case, the 181 syntax of the special-use flag is only verified at runtime. 183 If neither the special-use mailbox nor the default mailbox exists, 184 the "fileinto" action MUST proceed exactly as it does in case the 185 ":specialuse" is argument is absent and the mailbox named by its 186 positional argument does not exist. The various options for handling 187 this situation are described in Section 4.1 of RFC5228 [SIEVE]. 189 More than one mailbox in the user's personal namespace can have a 190 particular special-use flag assigned. If one of those mailboxes is 191 in fact the default mailbox named by the positional string argument 192 of the "fileinto" command, that mailbox MUST be used for delivery. 193 If the default mailbox is not one of the options, the mailbox that is 194 chosen for delivery is implementation-defined. However, while the 195 set of mailboxes to which the involved special-use flags are assigned 196 remains unchanged, implementations SHOULD ensure that the mailbox 197 choice is made consistently, so that the same mailbox is used every 198 time. Conversely, the chosen mailbox MAY change once the special-use 199 flag assignments that are relevant for the mailbox choice are changed 200 (usually by user interaction). 202 If delivery to the special-use mailbox fails for reasons not relating 203 to its existence, the Sieve interpreter MUST NOT subsequently attempt 204 delivery in the indicated default mailbox as a fall-back. Instead, 205 it MUST proceed exactly as it does in case the ":specialuse" argument 206 is absent and delivery to the mailbox named by its positional 207 argument fails. This prevents the situation where messages are 208 unexpectedly spread over two mailboxes in case transient or 209 intermittent delivery failures occur. 211 4.1. Mailboxes Created Implicitly by the "fileinto" Command 213 Before attempting to deliver the message into the specified mailbox, 214 the "fileinto" command may implicitly create the mailbox if it does 215 not exist (see Section 4.1 of RFC5228 [SIEVE]). This optional 216 behavior can be requested explicitly using the "mailbox" extension 217 [SIEVE-MAILBOX], which adds the optional ":create" argument to the 218 "fileinto" command. If the ":create" argument is specified with 219 "fileinto", it instructs the Sieve interpreter to unconditionally 220 create the specified mailbox if needed. Note that the ":create" 221 argument has no effect when the implicit creation of mailboxes for 222 delivery is the default behavior. 224 When the ":specialuse" argument is present, this behavior does not 225 change: the Sieve interpreter will implicitly create the specified 226 default mailbox if needed. This need arises when both the special- 227 use mailbox and the default mailbox are not found. 229 If the server implementation supports the CREATE-SPECIAL-USE 230 capability [SPECIAL-USE] for IMAP (i.e., it allows assigning special- 231 use flags to new mailboxes) it SHOULD assign the special-use flag 232 specified with the ":specialuse" argument to the newly created 233 mailbox. 235 5. Sieve Capability Strings 237 A Sieve implementation that defines the "specialuse_exists" test and 238 the ":specialuse" argument for the "fileinto" command will advertise 239 the capability string "special-use". 241 6. Examples 243 The following example saves the message in the mailbox where messages 244 deemed to be junk mail are held. This mailbox is identified using 245 the "\Junk" special-use attribute. If no mailbox has this attribute 246 assigned, the message is filed into the mailbox named "Spam". If the 247 mailbox named "Spam" does not exist either, the result of this Sieve 248 script is implementation-dependent: e.g., it may trigger an error or 249 the mailbox may be created implicitly. 251 require "fileinto"; 252 require "special-use"; 254 fileinto :specialuse "\\Junk" "Spam"; 256 The following very similar example explicitly handles the case in 257 which neither a "\Junk" special-use mailbox nor the "Spam" mailbox 258 exist. In that case, a mailbox called "Spam" is created, and the 259 message is stored there. Additionally, the "\Junk" special-use 260 attribute may be assigned to it. 262 require "fileinto"; 263 require "special-use"; 264 require "mailbox"; 266 fileinto :specialuse "\\Junk" :create "Spam"; 268 The following example is used in a Sieve script that is triggered 269 from an IMAP event, rather than at message delivery [IMAPSIEVE]. 270 This Sieve script redirects messages to an automated recipient that 271 processes junk mail, if those messages are copied or moved into a 272 mailbox that has the "\Junk" special-use attribute assigned. 274 require "imapsieve"; 275 require "special-use"; 276 require "environment"; 277 require "variables"; 279 if environment :contains "imap.mailbox" "*" { 280 set "mailbox" "${1}"; 281 } 283 if allof( 284 environment "imap.cause" "COPY", 285 specialuse_exists "${mailbox}" "\\Junk") { 286 redirect "spam-report@example.org"; 287 } 289 7. Security Considerations 291 Security considerations are discussed in [SIEVE], [VARIABLES], and 292 [SPECIAL-USE]. It is believed that this extension does not introduce 293 any additional security concerns. 295 Note that this specification explicitly restricts the anonymous 296 special-use mailbox to the user's personal namespace. First, this 297 avoids the need to search the entire mail storage for mailboxes that 298 have a particular special-use flag assigned. This could put undue 299 load on the system, while shared special-use mailboxes are deemed of 300 limited use with the currently defined special-use flags. Secondly, 301 it prevents security concerns with shared mailboxes that have 302 special-use flags assigned that apply to all users. Searching the 303 entire mail storage for special-use mailboxes could lead to messages 304 unexpectedly or even maliciously being filed to shared mailboxes. 306 This restriction could be lifted for particular future special-use 307 flags, but such new flags should have a clear application for shared 308 mailboxes and the security concerns should be considered carefully. 310 8. IANA Considerations 312 The following template specifies the IANA registration of the Sieve 313 extension specified in this document: 315 To: iana@iana.org 316 Subject: Registration of new Sieve extension 318 Capability name: special-use 319 Description: adds a test for checking whether an IMAP 320 special-use attribute is assigned for a 321 particular mailbox or any mailbox, and it adds 322 the ability to file messages into an anonymous 323 mailbox that has a particular IMAP special-use 324 attribute assigned. 325 RFC number: this RFC 326 Contact address: Sieve mailing list 328 This information should be added to the list of sieve extensions 329 given on http://www.iana.org/assignments/sieve-extensions. 331 9. Acknowledgements 333 Thanks to Stan Kalisch, Barry Leiba, Alexey Melnikov, Ken Murchison, 334 and Ned Freed for reviews and suggestions. 336 Thanks to the authors of RFC5490 [SIEVE-MAILBOX] from which some 337 descriptive text is borrowed in this document. 339 10. References 341 10.1. Normative References 343 [IMAP-METADATA] 344 Daboo, C., "The IMAP METADATA Extension", RFC 5464, 345 DOI 10.17487/RFC5464, February 2009, 346 . 348 [KEYWORDS] 349 Bradner, S., "Key words for use in RFCs to Indicate 350 Requirement Levels", BCP 14, RFC 2119, March 1997. 352 [NAMESPACE] 353 Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342, 354 DOI 10.17487/RFC2342, May 1998, . 357 [SIEVE] Guenther, P. and T. Showalter, "Sieve: An Email Filtering 358 Language", RFC 5228, January 2008. 360 [SIEVE-MAILBOX] 361 Melnikov, A., "The Sieve Mail-Filtering Language -- 362 Extensions for Checking Mailbox Status and Accessing 363 Mailbox Metadata", RFC 5490, March 2009. 365 [SPECIAL-USE] 366 Leiba, B. and J. Nicolson, "IMAP LIST Extension for 367 Special-Use Mailboxes", RFC 6154, DOI 10.17487/RFC6154, 368 March 2011, . 370 [VARIABLES] 371 Homme, K., "Sieve Email Filtering: Variables Extension", 372 RFC 5229, January 2008. 374 10.2. Informative References 376 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 377 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 378 . 380 [IMAPSIEVE] 381 Leiba, B., "Support for Internet Message Access Protocol 382 (IMAP) Events in Sieve", RFC 6785, DOI 10.17487/RFC6785, 383 November 2012, . 385 Author's Address 387 Stephan Bosch 388 Dovecot Oy 389 Lars Sonckin Kaari 12 390 Espoo 02600 391 Finland 393 Email: stephan.bosch@dovecot.fi