idnits 2.17.1 draft-ietf-extra-sieve-special-use-05.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (January 25, 2019) is 1918 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 (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 EXTRA S. Bosch 3 Internet-Draft Open Xchange Oy 4 Intended status: Standards Track January 25, 2019 5 Expires: July 29, 2019 7 Sieve Email Filtering: Delivering to Special-Use Mailboxes 8 draft-ietf-extra-sieve-special-use-05 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 a mailbox identified solely by a 20 special-use attribute. 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 July 29, 2019. 39 Copyright Notice 41 Copyright (c) 2019 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. For example, there can be a special-use mailbox for 77 storing the user's draft messages, for keeping copies of sent 78 messages, and for collecting spam messages that were classified as 79 such at delivery. The SPECIAL-USE capability [SPECIAL-USE] of the 80 IMAP protocol defines mailbox attributes that identify these special 81 mailboxes explicitly to the client. This way, client configuration 82 is simplified significantly. Using the CREATE-SPECIAL-USE capability 83 [SPECIAL-USE], IMAP clients can also configure these attributes 84 dynamically based on user preference. 86 Unlike the IMAP protocol, the Sieve mail filtering language [SIEVE] 87 currently cannot freely access these special-use mailbox attributes. 88 Particularly, the Sieve interpreter has no means to identify a 89 mailbox with a particular special-use attribute. This would be very 90 useful for example to find the user's Spam mailbox at delivery. 92 In Sieve, limited access to the special-use attributes is provided 93 using the "mboxmetadata" extension [SIEVE-MAILBOX], which allows 94 testing for the presence of a special-use attribute in the "/private/ 95 specialuse" IMAP METADATA [IMAP-METADATA] entry of a mailbox. Still, 96 not all implementers will be willing to add the complexity of the 97 IMAP METADATA capability, just to provide access to special-use 98 attributes to the Sieve interpreter. 100 This document defines an extension to the Sieve mail filtering 101 language that adds the ability to freely access mailbox special-use 102 attributes. It adds a test called "specialuse_exists" that checks 103 whether a special-use attribute is assigned for a particular mailbox 104 or - if omitted - any of the user's personal mailboxes. It also adds 105 the ability to file messages into a personal mailbox identified by a 106 particular special-use attribute rather than the mailbox's name. 107 This is achieved using the new ":specialuse" argument for the 108 "fileinto" command [SIEVE]. 110 2. Conventions Used in This Document 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 114 "OPTIONAL" in this document are to be interpreted as described in 115 BCP 14 [KEYWORDS] [KEYWORDS-UPD] when, and only when, they appear in 116 all capitals, as shown here. 118 Conventions for notations are as in [SIEVE] Section 1.1, including 119 use of the "Usage:" label for the definition of action and tagged 120 arguments syntax. 122 In [IMAP] examples, "C:" and "S:" indicate lines sent by the client 123 and server respectively. If such lines are wrapped without a new 124 "C:" or "S:" label, then the wrapping is for editorial clarity and is 125 not part of the command. 127 3. Test "specialuse_exists" 129 Usage: specialuse_exists [] 130 132 If the "mailbox" string argument is omitted, the "specialuse_exists" 133 test yields true if all of the following statements are true for each 134 of the special-use attributes listed in the "special-use-attrs" 135 argument: 137 a. at least one mailbox exists in the user's personal namespace 138 [NAMESPACE] that has that particular special-use attribute 139 assigned, and 141 b. that mailbox allows the user in whose context the Sieve script 142 runs to "deliver" messages into it. 144 If the "mailbox" argument is specified, the "specialuse_exists" test 145 yields true if all of the following statements are true: 147 a. the indicated mailbox exists, 149 b. that mailbox allows the user in whose context the Sieve script 150 runs to "deliver" messages into it, and 152 c. that mailbox has all of the special-use attributes listed in the 153 "special-use-attrs" argument assigned to it. 155 Refer to the specification of the "mailboxexists" test in Section 3.1 156 of RFC 5490 [SIEVE-MAILBOX] for a definition of when "delivery" of 157 messages into a mailbox is deemed possible. 159 3.1. Equivalent IMAP Operations 161 To clarify, a sequence of [IMAP] commands that a client could send to 162 perform an assessment without Sieve that is equivalent to the 163 "specialuse_exists" test is shown in the following IMAP protocol 164 examples. 166 First, the client queries which namespaces are available using the 167 NAMESPACE command [NAMESPACE]: 169 C: A01 NAMESPACE 170 S: * NAMESPACE (("INBOX/" "/")("Archive/" "/")) NIL (("Public/" "/")) 171 S: A01 OK NAMESPACE command completed 173 Subsequently, when no particular mailbox is of interest (i.e., the 174 "specialuse_exists" test has no mailbox argument), the client lists 175 all mailboxes with special-use attributes in the two returned 176 personal namespaces (this extended LIST command requires the LIST- 177 EXTENDED IMAP capability [LIST-EXTENDED]): 179 C: A02 LIST (SPECIAL-USE) "" ("INBOX/*" "Archive/*") 180 RETURN (SPECIAL-USE) 181 S: * LIST (\Drafts) "/" INBOX/Drafts 182 S: * LIST (\Trash) "/" INBOX/Trash 183 S: * LIST (\Sent) "/" INBOX/Sent 184 S: * LIST (\Archive) "/" Archive/Default 185 S: A02 OK LIST command completed 187 Finally, using the MYRIGHTS command [IMAP-ACL], the client determines 188 the access rights it has for the mailbox or mailboxes that have all 189 the requested attributes assigned. This way, it can determine 190 whether messages can be saved to any of those. In this example, an 191 "\Archive" special-use mailbox is sought: 193 C: A03 MYRIGHTS Archive/Default 194 S: * MYRIGHTS Archive/Default lrwsip 195 S: A03 OK Myrights completed 197 The MYRIGHTS response indicates that the the user has "insert" rights 198 [IMAP-ACL] for the "Archive/Default" mailbox, meaning that the client 199 can deliver (APPEND) messages to that mailbox and that the Sieve 200 "specialuse_exists" test would yield "true" in this case. 202 4. ":specialuse" Argument to "fileinto" Command 204 Usage: fileinto [:specialuse ] 205 207 Normally, the "fileinto" command delivers the message in the mailbox 208 specified using its positional mailbox argument, which is the name of 209 the mailbox. However, if the optional ":specialuse" argument is also 210 specified, the "fileinto" command first checks whether a mailbox 211 exists in the user's personal namespace [NAMESPACE] with the 212 specified special-use attribute assigned to it. If that is the case, 213 that special-use mailbox is used for delivery instead. If there is 214 no such mailbox or if the specified special-use attribute is unknown 215 to the implementation in general, the "fileinto" action proceeds as 216 it would without the ":specialuse" argument. 218 Summarizing, if the ":specialuse" argument is specified, the fileinto 219 command deals with two mailboxes that may or may not exist and may in 220 fact be equal: 222 o A special-use mailbox in the user's personal namespace, which has 223 at least the special-use attribute specified with the 224 ":specialuse" argument assigned to it. The name for this mailbox 225 is not relevant here: it is only identified by the assigned 226 special-use attribute. 228 o The default mailbox named by the positional string argument of the 229 "fileinto" command, which is used when the special-use mailbox is 230 not found. 232 The special-use attribute specified with the ':specialuse' argument 233 conforms to the 'use-attr' syntax described in Section 6 of RFC6154 234 [SIEVE-MAILBOX]. Implementations SHOULD handle an invalid special- 235 use attribute in the same way as an invalid mailbox name is handled. 236 The string parameter of the ":specialuse" argument is not a constant 237 string, which means that variable substitutions are allowed when the 238 "variables" extension [VARIABLES] is active. In that case, the 239 syntax of the special-use attribute is only verified at runtime. 241 If neither the special-use mailbox nor the default mailbox exists, 242 the "fileinto" action MUST proceed exactly as it does in case the 243 ":specialuse" is argument is absent and the mailbox named by its 244 positional argument does not exist. The various options for handling 245 this situation are described in Section 4.1 of RFC5228 [SIEVE]. 247 More than one mailbox in the user's personal namespace can have a 248 particular special-use attribute assigned. If one of those mailboxes 249 is in fact the default mailbox named by the positional string 250 argument of the "fileinto" command, that mailbox MUST be used for 251 delivery. If the default mailbox is not one of the options, the 252 mailbox that is chosen for delivery is implementation-defined. 253 However, while the set of mailboxes to which the involved special-use 254 attribute are assigned remains unchanged, implementations SHOULD 255 ensure that the mailbox choice is made consistently, so that the same 256 mailbox is used every time. Conversely, the chosen mailbox MAY 257 change once the special-use attribute assignments that are relevant 258 for the mailbox choice are changed (usually by user interaction). 260 If delivery to the special-use mailbox fails for reasons not relating 261 to its existence, the Sieve interpreter MUST NOT subsequently attempt 262 delivery in the indicated default mailbox as a fall-back. Instead, 263 it MUST proceed exactly as it does in case the ":specialuse" argument 264 is absent and delivery to the mailbox named by its positional 265 argument fails. This prevents the situation where messages are 266 unexpectedly spread over two mailboxes in case transient or 267 intermittent delivery failures occur. 269 4.1. Mailboxes Created Implicitly by the "fileinto" Command 271 Before attempting to deliver the message into the specified mailbox, 272 the "fileinto" command may implicitly create the mailbox if it does 273 not exist (see Section 4.1 of RFC5228 [SIEVE]). This optional 274 behavior can be requested explicitly using the "mailbox" extension 275 [SIEVE-MAILBOX], which adds the optional ":create" argument to the 276 "fileinto" command. If the ":create" argument is specified with 277 "fileinto", it instructs the Sieve interpreter to unconditionally 278 create the specified mailbox if needed. Note that the ":create" 279 argument has no effect when the implicit creation of mailboxes for 280 delivery is the default behavior. 282 When the ":specialuse" argument is present, this behavior does not 283 change: the Sieve interpreter will implicitly create the specified 284 default mailbox if needed. This need arises when both the special- 285 use mailbox and the default mailbox are not found. 287 If the server implementation supports the CREATE-SPECIAL-USE 288 capability [SPECIAL-USE] for IMAP (i.e., it allows assigning special- 289 use attributes to new mailboxes) it SHOULD assign the special-use 290 attribute specified with the ":specialuse" argument to the newly 291 created mailbox. 293 4.2. Equivalent IMAP Operations 295 To clarify, a sequence of [IMAP] commands that a client could send to 296 perform an action without Sieve that is equivalent to the "fileinto" 297 action with the ":specialuse" argument is shown in the following IMAP 298 protocol examples. The following Sieve script is assumed: 300 require "fileinto"; 301 require "special-use"; 303 fileinto :specialuse "\\Archive" "INBOX/Archive"; 305 First, the client proceeds as in Section 3.1 to find out whether the 306 indicated special-use attribute is assigned to any mailbox in the 307 user's personal namespace. If a matching special-use mailbox is 308 found, the message is delivered there using the IMAP APPEND command. 309 If no matching special-use mailbox is found, the client attempts to 310 deliver the message to the indicated default mailbox: 312 C: A04 APPEND INBOX/Archive {309} 313 S: A04 NO [TRYCREATE] Mailbox does not exist: INBOX/Archive 315 In this example, the default mailbox does not exist either. In that 316 case, the client MAY create the default mailbox and assign the 317 indicated special-use attribute to it: 319 C: A05 CREATE INBOX/Archive (USE (\Archive)) 320 S: A05 OK Create completed 322 Finally, the client completes the delivery: 324 C: A06 APPEND INBOX/Archive {309} 325 S: + OK 326 C: Date: Wed, 18 Jul 2018 22:00:09 +0200 327 C: From: mooch@owatagu.siam.example 328 C: To: Fred Foobar 329 C: Subject: afternoon meeting 330 C: Message-Id: 331 C: MIME-Version: 1.0 332 C: Content-Type: text/plain; charset=UTF-8 333 C: 334 C: Hi Fred, do you think we can meet again at 3:30 tomorrow? 335 C: 336 S: A06 OK [APPENDUID 1533375901 2312] Append completed. 338 5. Sieve Capability Strings 340 A Sieve implementation that defines the "specialuse_exists" test and 341 the ":specialuse" argument for the "fileinto" command will advertise 342 the capability string "special-use". 344 6. Examples 346 The following example saves the message in the mailbox where messages 347 deemed to be junk mail are held. This mailbox is identified using 348 the "\Junk" special-use attribute. If no mailbox has this attribute 349 assigned, the message is filed into the mailbox named "Spam". If the 350 mailbox named "Spam" does not exist either, the result of this Sieve 351 script is implementation-dependent: e.g., it may trigger an error or 352 the mailbox may be created implicitly. 354 require "fileinto"; 355 require "special-use"; 357 fileinto :specialuse "\\Junk" "Spam"; 359 The following very similar example explicitly handles the case in 360 which neither a "\Junk" special-use mailbox nor the "Spam" mailbox 361 exist. In that case, a mailbox called "Spam" is created, and the 362 message is stored there. Additionally, the "\Junk" special-use 363 attribute may be assigned to it. 365 require "fileinto"; 366 require "special-use"; 367 require "mailbox"; 369 fileinto :specialuse "\\Junk" :create "Spam"; 371 The following example is used in a Sieve script that is triggered 372 from an IMAP event, rather than at message delivery [IMAPSIEVE]. 373 This Sieve script redirects messages to an automated recipient that 374 processes junk mail, if those messages are copied or moved into a 375 mailbox that has the "\Junk" special-use attribute assigned. 377 require "imapsieve"; 378 require "special-use"; 379 require "environment"; 380 require "variables"; 382 if environment :contains "imap.mailbox" "*" { 383 set "mailbox" "${1}"; 384 } 386 if allof( 387 environment "imap.cause" "COPY", 388 specialuse_exists "${mailbox}" "\\Junk") { 389 redirect "spam-report@example.org"; 390 } 392 7. Security Considerations 394 Security considerations are discussed in [SIEVE], [VARIABLES], and 395 [SPECIAL-USE]. It is believed that this extension does not introduce 396 any additional security concerns. 398 Note that this specification explicitly restricts the special-use 399 mailbox to the user's personal namespace. First, this avoids the 400 need to search the entire mail storage for mailboxes that have a 401 particular special-use attribute assigned. This could put undue load 402 on the system, while shared special-use mailboxes are deemed of 403 limited use with the currently defined special-use attributes. 404 Secondly, it prevents security concerns with shared mailboxes that 405 have special-use attributes assigned that apply to all users. 406 Searching the entire mail storage for special-use mailboxes could 407 lead to messages unexpectedly or even maliciously being filed to 408 shared mailboxes. 410 This restriction could be lifted for particular future special-use 411 attributes, but such new attributes should have a clear application 412 for shared mailboxes and the security concerns should be considered 413 carefully. 415 8. IANA Considerations 417 The following template specifies the IANA registration of the Sieve 418 extension specified in this document: 420 To: iana@iana.org 421 Subject: Registration of new Sieve extension 423 Capability name: special-use 424 Description: adds a test for checking whether an IMAP 425 special-use attribute is assigned for a 426 particular mailbox or any mailbox, and it adds 427 the ability to file messages into a mailbox 428 identified solely by a special-use attribute. 429 RFC number: this RFC 430 Contact address: Sieve mailing list 432 This information should be added to the list of sieve extensions 433 given on http://www.iana.org/assignments/sieve-extensions. 435 9. Acknowledgements 437 Thanks to Stan Kalisch, Barry Leiba, Alexey Melnikov, Ken Murchison, 438 and Ned Freed for reviews and suggestions. 440 Thanks to the authors of RFC5490 [SIEVE-MAILBOX] from which some 441 descriptive text is borrowed in this document. 443 10. References 445 10.1. Normative References 447 [IMAP-METADATA] 448 Daboo, C., "The IMAP METADATA Extension", RFC 5464, 449 DOI 10.17487/RFC5464, February 2009, 450 . 452 [KEYWORDS] 453 Bradner, S., "Key words for use in RFCs to Indicate 454 Requirement Levels", BCP 14, RFC 2119, March 1997. 456 [KEYWORDS-UPD] 457 Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 458 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 459 May 2017, . 461 [NAMESPACE] 462 Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342, 463 DOI 10.17487/RFC2342, May 1998, . 466 [SIEVE] Guenther, P. and T. Showalter, "Sieve: An Email Filtering 467 Language", RFC 5228, January 2008. 469 [SIEVE-MAILBOX] 470 Melnikov, A., "The Sieve Mail-Filtering Language -- 471 Extensions for Checking Mailbox Status and Accessing 472 Mailbox Metadata", RFC 5490, March 2009. 474 [SPECIAL-USE] 475 Leiba, B. and J. Nicolson, "IMAP LIST Extension for 476 Special-Use Mailboxes", RFC 6154, DOI 10.17487/RFC6154, 477 March 2011, . 479 [VARIABLES] 480 Homme, K., "Sieve Email Filtering: Variables Extension", 481 RFC 5229, January 2008. 483 10.2. Informative References 485 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 486 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 487 . 489 [IMAP-ACL] 490 Melnikov, A., "IMAP4 Access Control List (ACL) Extension", 491 RFC 4314, DOI 10.17487/RFC4314, December 2005, 492 . 494 [IMAPSIEVE] 495 Leiba, B., "Support for Internet Message Access Protocol 496 (IMAP) Events in Sieve", RFC 6785, DOI 10.17487/RFC6785, 497 November 2012, . 499 [LIST-EXTENDED] 500 Leiba, B. and A. Melnikov, "Internet Message Access 501 Protocol version 4 - LIST Command Extensions", RFC 5258, 502 DOI 10.17487/RFC5258, June 2008, . 505 Author's Address 507 Stephan Bosch 508 Open Xchange Oy 509 Lars Sonckin kaari 12 510 Espoo 02600 511 Finland 513 Email: stephan.bosch@open-xchange.com