idnits 2.17.1 draft-ietf-extra-sieve-special-use-04.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 (November 27, 2018) is 1976 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 (==), 3 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 November 27, 2018 5 Expires: May 31, 2019 7 Sieve Email Filtering: Delivering to Special-Use Mailboxes 8 draft-ietf-extra-sieve-special-use-04 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 May 31, 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 3.1. Equivalent IMAP Operations . . . . . . . . . . . . . . . 4 60 4. ":specialuse" Argument to "fileinto" Command . . . . . . . . 5 61 4.1. Mailboxes Created Implicitly by the "fileinto" Command . 6 62 4.2. Equivalent IMAP Operations . . . . . . . . . . . . . . . 7 63 5. Sieve Capability Strings . . . . . . . . . . . . . . . . . . 8 64 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 66 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 67 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 68 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 70 10.2. Informative References . . . . . . . . . . . . . . . . . 11 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 73 1. Introduction 75 Commonly, several mailboxes in an IMAP message store [IMAP] have a 76 special use; e.g. it is where the user's draft messages are stored, 77 where a copy of sent messages are kept, or it is where spam messages 78 are filed automatically at delivery. The SPECIAL-USE capability 79 [SPECIAL-USE] of the IMAP protocol defines mailbox attributes that 80 identify these special mailboxes explicitly to the client. This way, 81 client configuration is simplified significantly. Using the CREATE- 82 SPECIAL-USE capability [SPECIAL-USE], IMAP clients can also configure 83 these attributes dynamically based on user preference. 85 Unlike the IMAP protocol, the Sieve mail filtering language [SIEVE] 86 currently cannot freely access these special-use mailbox attributes. 87 Particularly, the Sieve interpreter cannot find an anonymous mailbox 88 that has a particular special-use attribute assigned. This would be 89 very useful for example to find the user's Spam mailbox at delivery. 91 In Sieve, limited access to the special-use attributes is provided 92 using the "mboxmetadata" extension [SIEVE-MAILBOX], which allows 93 testing for the presence of a special-use attribute in the "/private/ 94 specialuse" IMAP METADATA [IMAP-METADATA] entry of a mailbox. Still, 95 not all implementers will be willing to add the complexity of the 96 IMAP METADATA capability, just to provide access to special-use 97 attributes to the Sieve interpreter. 99 This document defines an extension to the Sieve mail filtering 100 language that adds the ability to freely access mailbox special-use 101 attributes. It adds a test called "specialuse_exists" that checks 102 whether a special-use attribute is assigned for a particular mailbox 103 or - if omitted - any of the user's personal mailboxes. It also adds 104 the ability to file messages into an anonymous personal mailbox that 105 has a particular special-use attribute assigned using a ":specialuse" 106 argument for the "fileinto" command [SIEVE]. 108 2. Conventions Used in This Document 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in [KEYWORDS]. 114 Conventions for notations are as in [SIEVE] Section 1.1, including 115 use of the "Usage:" label for the definition of action and tagged 116 arguments syntax. 118 In [IMAP] examples, "C:" and "S:" indicate lines sent by the client 119 and server respectively. If such lines are wrapped without a new 120 "C:" or "S:" label, then the wrapping is for editorial clarity and is 121 not part of the command. 123 3. Test "specialuse_exists" 125 Usage: specialuse_exists [] 126 128 If the "mailbox" string argument is omitted, the "specialuse_exists" 129 test yields true if all of the following statements are true for each 130 of the special-use flags listed in the "special-use-flags" argument: 132 a. at least one mailbox exists in the user's personal namespace 133 [NAMESPACE] that has that particular special-use flag assigned, 134 and 136 b. that mailbox allows the user in whose context the Sieve script 137 runs to "deliver" messages into it. 139 If the "mailbox" argument is specified, the "specialuse_exists" test 140 yields true if all of the following statements are true: 142 a. the indicated mailbox exists, 143 b. that mailbox allows the user in whose context the Sieve script 144 runs to "deliver" messages into it, and 146 c. that mailbox has all of the special-use flags listed in the 147 "special-use-flags" argument assigned to it. 149 Refer to the specification of the "mailboxexists" test in Section 3.1 150 of RFC 5490 [SIEVE-MAILBOX] for a definition of when "delivery" of 151 messages into a mailbox is deemed possible. 153 3.1. Equivalent IMAP Operations 155 To clarify, a sequence of [IMAP] commands that a client could send to 156 perform an assessment without Sieve that is equivalent to the 157 "specialuse_exists" test is shown in the following IMAP protocol 158 examples. 160 First, the client queries which namespaces are available using the 161 NAMESPACE command [NAMESPACE]: 163 C: A01 NAMESPACE 164 S: * NAMESPACE (("INBOX/" "/")("Archive/" "/")) NIL (("Public/" "/")) 165 S: A01 OK NAMESPACE command completed 167 Subsequently, when no particular mailbox is of interest (i.e., the 168 "specialuse_exists" test has no mailbox argument), the client lists 169 all mailboxes with special-use flags in the two returned personal 170 namespaces (this extended LIST command requires the LIST-EXTENDED 171 IMAP capability [LIST-EXTENDED]): 173 C: A02 LIST (SPECIAL-USE) "" ("INBOX/*" "Archive/*") 174 RETURN (SPECIAL-USE) 175 S: * LIST (\Drafts) "/" INBOX/Drafts 176 S: * LIST (\Trash) "/" INBOX/Trash 177 S: * LIST (\Sent) "/" INBOX/Sent 178 S: * LIST (\Archive) "/" Archive/Default 179 S: A02 OK LIST command completed 181 Finally, using the MYRIGHTS command [IMAP-ACL], the client determines 182 the access rights it has for the mailbox or mailboxes that have all 183 the requested flags assigned. This way, it can determine whether 184 messages can be saved to any of those. In this example, an 185 "\Archive" special-use mailbox is sought: 187 C: A03 MYRIGHTS Archive/Default 188 S: * MYRIGHTS Archive/Default lrwsip 189 S: A03 OK Myrights completed 190 The MYRIGHTS response indicates that the the user has "insert" rights 191 [IMAP-ACL] for the "Archive/Default" mailbox, meaning that the client 192 can deliver (APPEND) messages to that mailbox and that the Sieve 193 "specialuse_exists" test would yield "true" in this case. 195 4. ":specialuse" Argument to "fileinto" Command 197 Usage: fileinto [:specialuse ] 198 200 Normally, the "fileinto" command delivers the message in the mailbox 201 specified using its positional mailbox argument. However, if the 202 optional ":specialuse" argument is also specified, the "fileinto" 203 command first checks whether a mailbox exists in the user's personal 204 namespace [NAMESPACE] with the specified special-use flag assigned to 205 it. If that is the case, that special-use mailbox is used for 206 delivery instead. If there is no such mailbox or if the specified 207 special-use flag is unknown to the implementation in general, the 208 "fileinto" action proceeds as it would without the ":specialuse" 209 argument. 211 Summarizing, if the ":specialuse" argument is specified, the fileinto 212 command deals with two mailboxes that may or may not exist: 214 o An anonymous special-use mailbox in the user's personal namespace, 215 which has at least the special-use flag specified with the 216 ":specialuse" argument assigned to it. 218 o The default mailbox named by the positional string argument of the 219 "fileinto" command, which is used when the special-use mailbox is 220 not found. 222 The special-use flag specified with the ":specialuse" argument MUST 223 conform to the "use-attr" syntax described in Section 6 of RFC6154 224 [SIEVE-MAILBOX]. Implementations SHOULD handle an invalid special- 225 use flag in the same way as an invalid mailbox name is handled. The 226 string parameter of the ":specialuse" argument is not a constant 227 string, which means that variable substitutions are allowed when the 228 "variables" extension [VARIABLES] is active. In that case, the 229 syntax of the special-use flag is only verified at runtime. 231 If neither the special-use mailbox nor the default mailbox exists, 232 the "fileinto" action MUST proceed exactly as it does in case the 233 ":specialuse" is argument is absent and the mailbox named by its 234 positional argument does not exist. The various options for handling 235 this situation are described in Section 4.1 of RFC5228 [SIEVE]. 237 More than one mailbox in the user's personal namespace can have a 238 particular special-use flag assigned. If one of those mailboxes is 239 in fact the default mailbox named by the positional string argument 240 of the "fileinto" command, that mailbox MUST be used for delivery. 241 If the default mailbox is not one of the options, the mailbox that is 242 chosen for delivery is implementation-defined. However, while the 243 set of mailboxes to which the involved special-use flags are assigned 244 remains unchanged, implementations SHOULD ensure that the mailbox 245 choice is made consistently, so that the same mailbox is used every 246 time. Conversely, the chosen mailbox MAY change once the special-use 247 flag assignments that are relevant for the mailbox choice are changed 248 (usually by user interaction). 250 If delivery to the special-use mailbox fails for reasons not relating 251 to its existence, the Sieve interpreter MUST NOT subsequently attempt 252 delivery in the indicated default mailbox as a fall-back. Instead, 253 it MUST proceed exactly as it does in case the ":specialuse" argument 254 is absent and delivery to the mailbox named by its positional 255 argument fails. This prevents the situation where messages are 256 unexpectedly spread over two mailboxes in case transient or 257 intermittent delivery failures occur. 259 4.1. Mailboxes Created Implicitly by the "fileinto" Command 261 Before attempting to deliver the message into the specified mailbox, 262 the "fileinto" command may implicitly create the mailbox if it does 263 not exist (see Section 4.1 of RFC5228 [SIEVE]). This optional 264 behavior can be requested explicitly using the "mailbox" extension 265 [SIEVE-MAILBOX], which adds the optional ":create" argument to the 266 "fileinto" command. If the ":create" argument is specified with 267 "fileinto", it instructs the Sieve interpreter to unconditionally 268 create the specified mailbox if needed. Note that the ":create" 269 argument has no effect when the implicit creation of mailboxes for 270 delivery is the default behavior. 272 When the ":specialuse" argument is present, this behavior does not 273 change: the Sieve interpreter will implicitly create the specified 274 default mailbox if needed. This need arises when both the special- 275 use mailbox and the default mailbox are not found. 277 If the server implementation supports the CREATE-SPECIAL-USE 278 capability [SPECIAL-USE] for IMAP (i.e., it allows assigning special- 279 use flags to new mailboxes) it SHOULD assign the special-use flag 280 specified with the ":specialuse" argument to the newly created 281 mailbox. 283 4.2. Equivalent IMAP Operations 285 To clarify, a sequence of [IMAP] commands that a client could send to 286 perform an action without Sieve that is equivalent to the "fileinto" 287 action with the ":specialuse" argument is shown in the following IMAP 288 protocol examples. The following Sieve script is assumed: 290 require "fileinto"; 291 require "special-use"; 293 fileinto :specialuse "\\Archive" "INBOX/Archive"; 295 First, the client proceeds as in Section 3.1 to find out whether the 296 indicated special-use flag is assigned to any mailbox in the user's 297 personal namespace. If a matching special-use mailbox is found, the 298 message is delivered there using the IMAP APPEND command. If no 299 matching special-use mailbox is found, the client attempts to deliver 300 the message to the indicated default mailbox: 302 C: A04 APPEND INBOX/Archive {309} 303 S: A04 NO [TRYCREATE] Mailbox does not exist: Archive/Personal 305 In this example, the default mailbox does not exist either. In that 306 case, the client MAY create the default mailbox and assign the 307 indicated special-use flag to it: 309 C: A05 CREATE INBOX/Archive (USE (\Archive)) 310 S: A05 OK Create completed 312 Finally, the client completes the delivery: 314 C: A06 APPEND INBOX/Archive {309} 315 S: + OK 316 C: Date: Wed, 18 Jul 2018 22:00:09 +0200 317 C: From: mooch@owatagu.siam.edu 318 C: To: Fred Foobar 319 C: Subject: afternoon meeting 320 C: Message-Id: 321 C: MIME-Version: 1.0 322 C: Content-Type: text/plain; charset=UTF-8 323 C: 324 C: Hi Fred, do you think we can meet again at 3:30 tomorrow? 325 C: 326 S: A06 OK [APPENDUID 1533375901 2312] Append completed. 328 5. Sieve Capability Strings 330 A Sieve implementation that defines the "specialuse_exists" test and 331 the ":specialuse" argument for the "fileinto" command will advertise 332 the capability string "special-use". 334 6. Examples 336 The following example saves the message in the mailbox where messages 337 deemed to be junk mail are held. This mailbox is identified using 338 the "\Junk" special-use attribute. If no mailbox has this attribute 339 assigned, the message is filed into the mailbox named "Spam". If the 340 mailbox named "Spam" does not exist either, the result of this Sieve 341 script is implementation-dependent: e.g., it may trigger an error or 342 the mailbox may be created implicitly. 344 require "fileinto"; 345 require "special-use"; 347 fileinto :specialuse "\\Junk" "Spam"; 349 The following very similar example explicitly handles the case in 350 which neither a "\Junk" special-use mailbox nor the "Spam" mailbox 351 exist. In that case, a mailbox called "Spam" is created, and the 352 message is stored there. Additionally, the "\Junk" special-use 353 attribute may be assigned to it. 355 require "fileinto"; 356 require "special-use"; 357 require "mailbox"; 359 fileinto :specialuse "\\Junk" :create "Spam"; 361 The following example is used in a Sieve script that is triggered 362 from an IMAP event, rather than at message delivery [IMAPSIEVE]. 363 This Sieve script redirects messages to an automated recipient that 364 processes junk mail, if those messages are copied or moved into a 365 mailbox that has the "\Junk" special-use attribute assigned. 367 require "imapsieve"; 368 require "special-use"; 369 require "environment"; 370 require "variables"; 372 if environment :contains "imap.mailbox" "*" { 373 set "mailbox" "${1}"; 374 } 376 if allof( 377 environment "imap.cause" "COPY", 378 specialuse_exists "${mailbox}" "\\Junk") { 379 redirect "spam-report@example.org"; 380 } 382 7. Security Considerations 384 Security considerations are discussed in [SIEVE], [VARIABLES], and 385 [SPECIAL-USE]. It is believed that this extension does not introduce 386 any additional security concerns. 388 Note that this specification explicitly restricts the anonymous 389 special-use mailbox to the user's personal namespace. First, this 390 avoids the need to search the entire mail storage for mailboxes that 391 have a particular special-use flag assigned. This could put undue 392 load on the system, while shared special-use mailboxes are deemed of 393 limited use with the currently defined special-use flags. Secondly, 394 it prevents security concerns with shared mailboxes that have 395 special-use flags assigned that apply to all users. Searching the 396 entire mail storage for special-use mailboxes could lead to messages 397 unexpectedly or even maliciously being filed to shared mailboxes. 399 This restriction could be lifted for particular future special-use 400 flags, but such new flags should have a clear application for shared 401 mailboxes and the security concerns should be considered carefully. 403 8. IANA Considerations 405 The following template specifies the IANA registration of the Sieve 406 extension specified in this document: 408 To: iana@iana.org 409 Subject: Registration of new Sieve extension 411 Capability name: special-use 412 Description: adds a test for checking whether an IMAP 413 special-use attribute is assigned for a 414 particular mailbox or any mailbox, and it adds 415 the ability to file messages into an anonymous 416 mailbox that has a particular IMAP special-use 417 attribute assigned. 418 RFC number: this RFC 419 Contact address: Sieve mailing list 421 This information should be added to the list of sieve extensions 422 given on http://www.iana.org/assignments/sieve-extensions. 424 9. Acknowledgements 426 Thanks to Stan Kalisch, Barry Leiba, Alexey Melnikov, Ken Murchison, 427 and Ned Freed for reviews and suggestions. 429 Thanks to the authors of RFC5490 [SIEVE-MAILBOX] from which some 430 descriptive text is borrowed in this document. 432 10. References 434 10.1. Normative References 436 [IMAP-METADATA] 437 Daboo, C., "The IMAP METADATA Extension", RFC 5464, 438 DOI 10.17487/RFC5464, February 2009, 439 . 441 [KEYWORDS] 442 Bradner, S., "Key words for use in RFCs to Indicate 443 Requirement Levels", BCP 14, RFC 2119, March 1997. 445 [NAMESPACE] 446 Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342, 447 DOI 10.17487/RFC2342, May 1998, . 450 [SIEVE] Guenther, P. and T. Showalter, "Sieve: An Email Filtering 451 Language", RFC 5228, January 2008. 453 [SIEVE-MAILBOX] 454 Melnikov, A., "The Sieve Mail-Filtering Language -- 455 Extensions for Checking Mailbox Status and Accessing 456 Mailbox Metadata", RFC 5490, March 2009. 458 [SPECIAL-USE] 459 Leiba, B. and J. Nicolson, "IMAP LIST Extension for 460 Special-Use Mailboxes", RFC 6154, DOI 10.17487/RFC6154, 461 March 2011, . 463 [VARIABLES] 464 Homme, K., "Sieve Email Filtering: Variables Extension", 465 RFC 5229, January 2008. 467 10.2. Informative References 469 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 470 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 471 . 473 [IMAP-ACL] 474 Melnikov, A., "IMAP4 Access Control List (ACL) Extension", 475 RFC 4314, DOI 10.17487/RFC4314, December 2005, 476 . 478 [IMAPSIEVE] 479 Leiba, B., "Support for Internet Message Access Protocol 480 (IMAP) Events in Sieve", RFC 6785, DOI 10.17487/RFC6785, 481 November 2012, . 483 [LIST-EXTENDED] 484 Leiba, B. and A. Melnikov, "Internet Message Access 485 Protocol version 4 - LIST Command Extensions", RFC 5258, 486 DOI 10.17487/RFC5258, June 2008, . 489 Author's Address 491 Stephan Bosch 492 Dovecot Oy 493 Lars Sonckin Kaari 12 494 Espoo 02600 495 Finland 497 Email: stephan.bosch@dovecot.fi