idnits 2.17.00 (12 Aug 2021) /tmp/idnits62340/draft-ietf-extra-sieve-snooze-00.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC5232, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5232, updated by this document, for RFC5378 checks: 2005-02-08) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 7, 2020) is 651 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) -- Looks like a reference, but probably isn't: '1' on line 493 -- Looks like a reference, but probably isn't: '2' on line 495 -- Possible downref: Normative reference to a draft: ref. 'I-D.gondwana-sieve-mailboxid' ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 EXTRA K. Murchison 3 Internet-Draft R. Signes 4 Updates: 5232 (if approved) N. Jenkins 5 Intended status: Standards Track Fastmail 6 Expires: February 8, 2021 August 7, 2020 8 Sieve Email Filtering: Snooze Extension 9 draft-ietf-extra-sieve-snooze-00 11 Abstract 13 This document describes the "snooze" extension to the Sieve email 14 filtering language. The "snooze" extension gives Sieve the ability 15 to postpone the filing of an incoming into a target mailbox until a 16 later point in time. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on February 8, 2021. 35 Copyright Notice 37 Copyright (c) 2020 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Conventions Used in This Document . . . . . . . . . . . . . . 2 54 3. Snooze Action . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3.1. Mailbox Argument . . . . . . . . . . . . . . . . . . . . 3 56 3.2. Weekdays Argument . . . . . . . . . . . . . . . . . . . . 4 57 3.3. Times and TZID Arguments . . . . . . . . . . . . . . . . 4 58 3.3.1. Awaken Times Examples . . . . . . . . . . . . . . . . 4 59 3.4. Interaction with Extensions to the Fileinto Action . . . 5 60 3.4.1. Imap4flags Extension . . . . . . . . . . . . . . . . 6 61 3.4.2. Mailbox Extension . . . . . . . . . . . . . . . . . . 6 62 3.4.3. Special-Use Extension . . . . . . . . . . . . . . . . 7 63 3.4.4. MailboxID Extension . . . . . . . . . . . . . . . . . 7 64 4. Mechanics of Snoozing Messages . . . . . . . . . . . . . . . 7 65 4.1. SMTP Future Message Release . . . . . . . . . . . . . . . 8 66 4.2. "Snoozed" Mailbox . . . . . . . . . . . . . . . . . . . . 8 67 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 8 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 69 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 71 8.1. Registration of Sieve Extension . . . . . . . . . . . . . 9 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 74 9.2. Informative References . . . . . . . . . . . . . . . . . 11 75 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 78 1. Introduction 80 Users are not always ready, willing, or able to read and respond to 81 email messages at the time of their arrival. Sometimes it is 82 desirable to have messages appear in a mailbox at a more convenient 83 time for the user to act upon them. 85 This document defines a new Sieve action command "snooze" that 86 postpones filing a message into a target mailbox until a later point 87 in time. The capability string associated with this extension is 88 "snooze". 90 2. Conventions Used in This Document 92 Conventions for notations are as in Section 1.1 of [RFC5228], 93 including use of the "Usage:" label for the definition of action and 94 tagged arguments syntax. 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 98 "OPTIONAL" in this document are to be interpreted as described in 99 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 100 capitals, as shown here. 102 3. Snooze Action 104 Usage: snooze *AWAKEN-OPTIONS 106 The AWAKEN-OPTIONS argument is defined here in ABNF [RFC4234] syntax 107 so that it can be modified by other extensions. 109 AWAKEN-OPTIONS = MAILBOX / WEEKDAYS / TZID 110 ; each option MUST NOT appear more than once 111 ; however, per Section 2.6.2 of RFC 5228, 112 ; the tagged arguments in AWAKEN-OPTIONS 113 ; may appear in any order 115 MAILBOX = ":mailbox" string 116 WEEKDAYS = ":weekdays" string-list 117 TZID = ":tzid" string 119 The snooze action is semantically equivalent to a delayed fileinto 120 action (see Section 4.1 of [RFC5228]). The arguments of the snooze 121 action specify when, where, and how the awakened message will be 122 filed. 124 The process of actually snoozing and awakening (delaying the filing 125 of) the message is implementation specific and outside the scope of 126 this document. However, Section 4 discusses possible methods for 127 implementing the snooze action. 129 3.1. Mailbox Argument 131 The optional :mailbox argument is used to specify the target mailbox 132 that the message will be filed into when it is awakened. It is 133 equivalent to the mailbox argument of the fileinto action (see 134 Section 4.1 of [RFC5228]). 136 If :mailbox is omitted, or if the specified mailbox doesn't exist at 137 the time of awakening, the message will be filed into the user's main 138 mailbox. For instance, in an implementation where the IMAP server is 139 running scripts on behalf of the user at time of delivery, the user's 140 "INBOX" would be the implicit target for awakening messages. 142 3.2. Weekdays Argument 144 The optional :weekdays argument specifies the set of days on which 145 the specified set of awakening times apply. Each day of the week is 146 expressed as an integer between "0" and "6". "0" is Sunday, "1" is 147 Monday, etc. This syntax matches that of the "weekday" date-part 148 argument to the date test extension (see Section 4.2 of [RFC5260]). 150 If :weekdays is omitted, the set of awakening times applies to every 151 day of the week. 153 3.3. Times and TZID Arguments 155 The required times argument, along with the optional :tzid argument, 156 are used to specify when a snoozed message will be awakened. Each 157 time is specified in "hh:mm:ss" format and is interpreted as the 158 local time in the time zone specified by the :tzid argument. 160 The value of the :tzid argument MUST be a time zone identifier from 161 the IANA Time Zone Database [tzdb]. If :tzid is omitted, the time 162 zone of the Sieve interpreter is used. 164 The combination of the weekdays and times form a chronological list 165 of awaken times. When a message is snoozed, it is assigned the next 166 future awaken time in the list. If a message is snoozed on a day 167 with no awaken times, or after the last awaken time on a given day, 168 the first awaken time on the next available day is used. 170 If the local time in the specified time zone occurs more than once 171 (daylight saving to standard time transition), the first occurrence 172 of the specified time value is used. If the local time in the 173 specified time zone does not occur (standard to daylight saving time 174 transition), the specified time value is interpreted using the UTC 175 offset prior to the transition. 177 3.3.1. Awaken Times Examples 179 The following examples show, given the specified snooze action and a 180 set of message arrival times, the corresponding times at which the 181 message would be awakened and filed. 183 The following example shows awaken times rolling into the next day or 184 week. Note that 2020-07-30 falls on a Thursday. 186 require "snooze"; 187 snooze :weekdays ["1", "3", "5", "2", "4"] 188 :tzid "Australia/Melbourne" ["12:00:00", 189 "08:00:00", "16:00:00"]; 191 +----------------------+---------------------+---------------------+ 192 | Arrival (UTC) | Arrival (Melbourne) | Awaken (Melbourne) | 193 +----------------------+---------------------+---------------------+ 194 | 2020-07-30T00:00:00Z | --07-30T10:00:00+10 | --07-30T12:00:00+10 | 195 | 2020-07-30T04:00:00Z | --07-30T14:00:00+10 | --07-30T16:00:00+10 | 196 | 2020-07-30T08:00:00Z | --07-30T18:00:00+10 | --07-31T08:00:00+10 | 197 | 2020-07-31T12:00:00Z | --07-31T22:00:00+10 | --08-03T08:00:00+10 | 198 | 2020-08-01T16:00:00Z | --08-02T02:00:00+10 | --08-03T08:00:00+10 | 199 +----------------------+---------------------+---------------------+ 201 The following example shows awaken times falling before, during, and 202 after a daylight saving to standard time transition. Note that the 203 transition occurs at 2020-11-01T02:00:00-04. 205 require "snooze"; 206 snooze :tzid "America/New_York" "01:30:00"; 208 +----------------------+---------------------+---------------------+ 209 | Arrival (UTC) | Arrival (New York) | Awaken (New York) | 210 +----------------------+---------------------+---------------------+ 211 | 2020-11-01T05:00:00Z | --11-01T01:00:00-04 | --11-01T01:30:00-04 | 212 | 2020-11-01T06:00:00Z | --11-01T01:00:00-05 | --11-02T01:30:00-05 | 213 | 2020-11-01T07:00:00Z | --11-01T02:00:00-05 | --11-02T01:30:00-05 | 214 +----------------------+---------------------+---------------------+ 216 The following example shows awaken times falling before, during, and 217 after a standard to daylight saving time transition. Note that the 218 transition occurs at 2021-03-14T02:00:00-05. 220 require "snooze"; 221 snooze :tzid "America/New_York" "02:30:00"; 223 +----------------------+---------------------+---------------------+ 224 | Arrival (UTC) | Arrival (New York) | Awaken (New York) | 225 +----------------------+---------------------+---------------------+ 226 | 2021-03-13T06:30:00Z | --03-13T01:30:00-05 | --03-13T02:30:00-05 | 227 | 2021-03-14T06:30:00Z | --03-14T01:30:00-05 | --03-14T03:30:00-04 | 228 | 2021-03-14T07:30:00Z | --03-14T03:30:00-04 | --03-15T02:30:00-04 | 229 +----------------------+---------------------+---------------------+ 231 3.4. Interaction with Extensions to the Fileinto Action 233 Some tagged arguments defined in extensions to the fileinto action 234 can be used together with the snooze action. The sections below 235 describe these interactions. Tagged arguments in future extensions 236 to the fileinto action need to describe their interaction with the 237 snooze extension, if any. 239 When any fileinto extension arguments are used with the snooze 240 extension, the corresponding extension MUST be enabled, and the 241 arguments are defined to have the same syntax, semantics, and 242 treatment as they do with the fileinto action. 244 3.4.1. Imap4flags Extension 246 When the "imap4flags" [RFC5232] extension is enabled in a script, two 247 additional tagged arguments are added to "snooze" that allow 248 manipulating the set of flags on a snoozed message. 250 AWAKEN-OPTIONS /= ADDFLAGS / REMOVEFLAGS 252 ADDFLAGS = ":addflags" string-list 253 REMOVEFLAGS = ":removeflags" string-list 255 The optional :addflags and :removeflags arguments are used to specify 256 which IMAP [RFC3501] flags should be added to and/or removed from the 257 set of IMAP flags present on the snoozed message at the time of 258 awakening. Note that depending on the method used to snooze a 259 message, the set of IMAP flags present at the time of awakening may 260 be the empty set. 262 This document doesn't dictate how the Sieve interpreter will set the 263 IMAP flags. In particular, the Sieve interpreter may work as an IMAP 264 client or may have direct access to the mailstore. 266 The general requirements for flag handling specified in Section 2 of 267 [RFC5232] MUST be followed. 269 3.4.2. Mailbox Extension 271 This document extends the definition of the ":create" [RFC5490] 272 tagged argument so that it can be used with the snooze action. 274 AWAKEN-OPTIONS /= CREATE 276 CREATE = ":create" 277 ; MUST NOT be appear unless MAILBOX also appears 279 If the optional ":create" argument is specified with snooze, it 280 instructs the Sieve interpreter to create the target mailbox, if 281 needed, before attempting to file the awakened message into the 282 target mailbox. 284 3.4.3. Special-Use Extension 286 This document extends the definition of the ":specialuse" [RFC8579] 287 tagged argument so that it can be used with the snooze action. 289 AWAKEN-OPTIONS /= SPECIAL-USE 291 SPECIAL-USE = ":specialuse" string 293 If the optional ":specialuse" argument is specified with snooze, it 294 instructs the Sieve interpreter to check whether a mailbox exists 295 with the specific special-use flag assigned to it. If such a mailbox 296 exists, the awakened message is filed into the special-use mailbox. 297 Otherwise, the awakened message is filed into the target mailbox. 299 If both the optional ":specialuse" and ":create" arguments are 300 specified with snooze, the Sieve interpreter is instructed to create 301 the target mailbox per Section 4.1 of [RFC8579], if needed. 303 3.4.4. MailboxID Extension 305 This document extends the definition of the ":mailboxid" 306 [I-D.gondwana-sieve-mailboxid] tagged argument so that it can be used 307 with the snooze action. 309 AWAKEN-OPTIONS /= MAILBOXID 311 MAILBOXID = ":mailboxid" string 313 If the optional ":mailboxid" argument is specified with snooze, it 314 instructs the Sieve interpreter to check whether a mailbox exists in 315 the user's personal namespace [RFC2342] with the specified MAILBOXID 316 [RFC8474]. If such a mailbox exists, the awakened message is filed 317 into that mailbox. Otherwise, the awakened message is filed into the 318 target mailbox. 320 If both the optional ":mailboxid" and ":specialuse" arguments are 321 specified with snooze, the Sieve interpreter is instructed to resolve 322 the mailboxid first. If a mailbox with the specified mailboxid does 323 not exist, then the process in Section 3.4.3 is followed. 325 4. Mechanics of Snoozing Messages 327 The process of snoozing is implementation specific and outside the 328 scope of this document. However, the sections below outline possible 329 methods of snoozing and awakening a message to be filed. 331 4.1. SMTP Future Message Release 333 A Sieve interpreter may implement the snooze action by leveraging the 334 SMTP Future Message Release [RFC4865] submission extension. The 335 message would be snoozed by queuing it for redelivery with a release 336 time that corresponds to the calculated awaken time. The target 337 mailbox for the awakened message would need to be encoded into the 338 recipient address or into a message header field. Care MUST be taken 339 to prevent the awakened message from being re-snoozed by the Sieve 340 script and causing a message loop. 342 4.2. "Snoozed" Mailbox 344 A Sieve interpreter may implement the snooze action by leveraging the 345 user's existing mail store. The message would be snoozed by storing 346 the message in a special "snoozed" mailbox and then moved into the 347 target mailbox at the calculated awaken time. 349 If a user's Sieve script enables the "imap4flags" [RFC5232] 350 extension, and if the "setflag" and/or "addflag" actions have been 351 used to store IMAP flags in the imap4flags internal variable, the 352 Sieve interpreter MAY use the current value of the internal variable 353 as the set of flags to associate with the message when storing it 354 into the "snoozed" mailbox. Note that in this case, the ":addflag" 355 and ":removeflag" tagged arguments to the snooze action operate on 356 this set of flags, but MUST NOT do so until the message is awakened. 358 5. Implementation Status 360 < RFC Editor: before publication please remove this section and the 361 reference to [RFC7942] > 363 This section records the status of known implementations of the 364 protocol defined by this specification at the time of posting of this 365 Internet-Draft, and is based on a proposal described in [RFC7942]. 366 The description of implementations in this section is intended to 367 assist the IETF in its decision processes in progressing drafts to 368 RFCs. Please note that the listing of any individual implementation 369 here does not imply endorsement by the IETF. Furthermore, no effort 370 has been spent to verify the information presented here that was 371 supplied by IETF contributors. This is not intended as, and must not 372 be construed to be, a catalog of available implementations or their 373 features. Readers are advised to note that other implementations may 374 exist. 376 According to [RFC7942], "this will allow reviewers and working groups 377 to assign due consideration to documents that have the benefit of 378 running code, which may serve as evidence of valuable experimentation 379 and feedback that have made the implemented protocols more mature. 380 It is up to the individual working groups to use this information as 381 they see fit". 383 5.1. Cyrus Server 385 The open source Cyrus Server [1] project is a highly scalable 386 enterprise mail system which supports Sieve email filtering at the 387 point of final delivery. This production level Sieve implementation 388 supports all of the requirements described in this document. This 389 implementation is freely distributable under a BSD style license from 390 Computing Services at Carnegie Mellon University [2]. 392 6. Security Considerations 394 Security considerations are discussed in [RFC5228], [RFC5232], 395 [RFC8579], and [I-D.gondwana-sieve-mailboxid]. 397 It is believed that this extension doesn't introduce any additional 398 security concerns. 400 7. Privacy Considerations 402 It is believed that this extension doesn't introduce any privacy 403 considerations beyond those in [RFC5228]. 405 8. IANA Considerations 407 8.1. Registration of Sieve Extension 409 To: iana@iana.org 411 Subject: Registration of new Sieve extension 413 Capability name: snooze 415 Description: Adds the "snooze" action command to postpone filing a 416 message into a target mailbox until a later point in time. 418 RFC number: RFC XXXX 420 Contact address: The Sieve discussion list 422 9. References 423 9.1. Normative References 425 [I-D.gondwana-sieve-mailboxid] 426 Gondwana, B., "Sieve Email Filtering: delivery by 427 mailboxid", draft-gondwana-sieve-mailboxid-02 (work in 428 progress), June 2020. 430 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 431 Requirement Levels", BCP 14, RFC 2119, 432 DOI 10.17487/RFC2119, March 1997, 433 . 435 [RFC2342] Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342, 436 DOI 10.17487/RFC2342, May 1998, 437 . 439 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 440 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 441 . 443 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 444 Specifications: ABNF", RFC 4234, DOI 10.17487/RFC4234, 445 October 2005, . 447 [RFC5228] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email 448 Filtering Language", RFC 5228, DOI 10.17487/RFC5228, 449 January 2008, . 451 [RFC5232] Melnikov, A., "Sieve Email Filtering: Imap4flags 452 Extension", RFC 5232, DOI 10.17487/RFC5232, January 2008, 453 . 455 [RFC5490] Melnikov, A., "The Sieve Mail-Filtering Language -- 456 Extensions for Checking Mailbox Status and Accessing 457 Mailbox Metadata", RFC 5490, DOI 10.17487/RFC5490, March 458 2009, . 460 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 461 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 462 May 2017, . 464 [RFC8474] Gondwana, B., Ed., "IMAP Extension for Object 465 Identifiers", RFC 8474, DOI 10.17487/RFC8474, September 466 2018, . 468 [RFC8579] Bosch, S., "Sieve Email Filtering: Delivering to Special- 469 Use Mailboxes", RFC 8579, DOI 10.17487/RFC8579, May 2019, 470 . 472 [tzdb] Internet Assigned Numbers Authority, "Time Zone Database", 473 . 475 9.2. Informative References 477 [RFC4865] White, G. and G. Vaudreuil, "SMTP Submission Service 478 Extension for Future Message Release", RFC 4865, 479 DOI 10.17487/RFC4865, May 2007, 480 . 482 [RFC5260] Freed, N., "Sieve Email Filtering: Date and Index 483 Extensions", RFC 5260, DOI 10.17487/RFC5260, July 2008, 484 . 486 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 487 Code: The Implementation Status Section", BCP 205, 488 RFC 7942, DOI 10.17487/RFC7942, July 2016, 489 . 491 9.3. URIs 493 [1] http://www.cyrusimap.org/ 495 [2] http://www.cmu.edu/computing/ 497 Authors' Addresses 499 Kenneth Murchison 500 Fastmail US LLC 501 1429 Walnut Street - Suite 1201 502 Philadelphia, PA 19102 503 USA 505 Email: murch@fastmailteam.com 507 Ricardo Signes 508 Fastmail US LLC 509 1429 Walnut Street - Suite 1201 510 Philadelphia, PA 19102 511 USA 513 Email: rjbs@fastmailteam.com 514 Neil Jenkins 515 Fastmail Pty Ltd 516 Level 2, 114 William Street 517 Melbourne, VIC 3000 518 Australia 520 Email: neilj@fastmailteam.com