idnits 2.17.1 draft-ietf-extra-sieve-snooze-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 : ---------------------------------------------------------------------------- -- 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 (17 February 2022) is 792 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 normative reference: RFC 3501 (Obsoleted by RFC 9051) ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 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: 21 August 2022 17 February 2022 8 Sieve Email Filtering: Snooze Extension 9 draft-ietf-extra-sieve-snooze-03 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 delivery of an incoming email message into a target 16 mailbox until a 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 21 August 2022. 35 Copyright Notice 37 Copyright (c) 2022 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 (https://trustee.ietf.org/ 42 license-info) in effect on the date of publication of this document. 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. Code Components 45 extracted from this document must include Revised BSD License text as 46 described in Section 4.e of the Trust Legal Provisions and are 47 provided without warranty as described in the Revised BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Conventions Used in This Document . . . . . . . . . . . . . . 2 53 3. Capability Identifier . . . . . . . . . . . . . . . . . . . . 3 54 4. Snooze Action . . . . . . . . . . . . . . . . . . . . . . . . 3 55 4.1. Mailbox Argument . . . . . . . . . . . . . . . . . . . . 4 56 4.2. Weekdays Argument . . . . . . . . . . . . . . . . . . . . 4 57 4.3. Times and TZID Arguments . . . . . . . . . . . . . . . . 4 58 4.3.1. Awaken Times Examples . . . . . . . . . . . . . . . . 5 59 4.4. Interaction with Extensions to the Fileinto Action . . . 6 60 4.4.1. Imap4flags Extension . . . . . . . . . . . . . . . . 6 61 4.4.2. Mailbox Extension . . . . . . . . . . . . . . . . . . 7 62 4.4.3. Special-Use Extension . . . . . . . . . . . . . . . . 8 63 4.4.4. MailboxID Extension . . . . . . . . . . . . . . . . . 8 64 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 8 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 66 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 68 8.1. Registration of Sieve Extension . . . . . . . . . . . . . 9 69 8.2. Registration of IMAP Mailbox Name Attribute . . . . . . . 10 70 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 71 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 73 10.2. Informative References . . . . . . . . . . . . . . . . . 12 74 Appendix A. Change History (To be removed by RFC Editor before 75 publication) . . . . . . . . . . . . . . . . . . . . . . 12 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 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 an extension to the Sieve language [RFC5228] 86 that enables scripts to postpone the delivery of a message into a 87 target mailbox until a later point in time. 89 2. Conventions Used in This Document 91 Conventions for notations are as in Section 1.1 of [RFC5228], 92 including use of the "Usage:" label for the definition of action and 93 tagged arguments syntax. 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 97 "OPTIONAL" in this document are to be interpreted as described in 98 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 99 capitals, as shown here. 101 3. Capability Identifier 103 Sieve implementations that implement this extension have an 104 identifier of "snooze" for use with the capability mechanism. 106 4. Snooze Action 108 Usage: snooze *AWAKEN-OPTIONS 110 The AWAKEN-OPTIONS argument is defined here in ABNF [RFC4234] syntax 111 so that it can be modified by other extensions. 113 AWAKEN-OPTIONS = MAILBOX / WEEKDAYS / TZID 114 ; each option MUST NOT appear more than once 115 ; however, per Section 2.6.2 of RFC 5228, 116 ; the tagged arguments in AWAKEN-OPTIONS 117 ; may appear in any order 119 MAILBOX = ":mailbox" string 120 WEEKDAYS = ":weekdays" string-list 121 TZID = ":tzid" string 123 The "snooze" action cancels the implicit keep and postpones delivery 124 of the message into the specified mailbox at a later point in time. 126 The snooze action is semantically equivalent to a delayed fileinto 127 action (see Section 4.1 of [RFC5228]). The arguments of the snooze 128 action specify when, where, and how the awakened message will be 129 filed. 131 A Sieve interpreter MUST implement the snooze action by delivering 132 the message to a special "snoozed" mailbox within its mailstore. 133 IMAP [RFC3501] and JMAP [RFC8621] servers MUST apply the "Snoozed" 134 (Section 8.2) attribute to this mailbox. The message will reside in 135 this special mailbox until the prescribed awaken time at which it 136 will be moved into the specified target mailbox. 138 4.1. Mailbox Argument 140 The optional :mailbox argument is used to specify the target mailbox 141 that the message will be filed into when it is awakened. It is 142 equivalent to the mailbox argument of the fileinto action (see 143 Section 4.1 of [RFC5228]). 145 If :mailbox is omitted, or if the specified mailbox doesn't exist at 146 the time of awakening, the message will be filed into the user's main 147 mailbox. For instance, in an implementation where an IMAP server is 148 running scripts on behalf of the user at time of delivery, the user's 149 "INBOX" would be the implicit target for awakening messages. 151 4.2. Weekdays Argument 153 The optional :weekdays argument specifies the set of days on which 154 the specified set of awakening times apply. Each day of the week is 155 expressed as an integer between "0" and "6". "0" is Sunday, "1" is 156 Monday, etc. This syntax matches that of the "weekday" date-part 157 argument to the date test extension (see Section 4.2 of [RFC5260]). 159 If :weekdays is omitted, the set of awakening times applies to every 160 day of the week. 162 4.3. Times and TZID Arguments 164 The required times argument, along with the optional :tzid argument, 165 are used to specify when a snoozed message will be awakened. Each 166 time is specified in "hh:mm:ss" format and is interpreted as the 167 local time in the time zone specified by the :tzid argument. 169 The value of the :tzid argument MUST be a time zone identifier from 170 the IANA Time Zone Database [tzdb]. If :tzid is omitted, the time 171 zone of the Sieve interpreter is used. 173 The combination of the weekdays and times form a chronological list 174 of awaken times. When a message is snoozed, it is assigned the next 175 future awaken time in the list. If a message is snoozed on a day 176 with no awaken times, or after the last awaken time on a given day, 177 the first awaken time on the next available day is used. 179 If the local time in the specified time zone occurs more than once 180 (daylight saving to standard time transition), the first occurrence 181 of the specified time value is used. If the local time in the 182 specified time zone does not occur (standard to daylight saving time 183 transition), the specified time value is interpreted using the UTC 184 offset prior to the transition. 186 4.3.1. Awaken Times Examples 188 The following examples show, given the specified snooze action and a 189 set of message arrival times, the corresponding times at which the 190 message would be awakened and filed. 192 The following example shows awaken times rolling into the next day or 193 week. Note that 2020-07-30 falls on a Thursday. 195 require "snooze"; 196 snooze :weekdays ["1", "3", "5", "2", "4"] 197 :tzid "Australia/Melbourne" ["12:00:00", 198 "08:00:00", "16:00:00"]; 200 +======================+=====================+=====================+ 201 | Arrival (UTC) | Arrival (Melbourne) | Awaken (Melbourne) | 202 +======================+=====================+=====================+ 203 | 2020-07-30T00:00:00Z | --07-30T10:00:00+10 | --07-30T12:00:00+10 | 204 +----------------------+---------------------+---------------------+ 205 | 2020-07-30T04:00:00Z | --07-30T14:00:00+10 | --07-30T16:00:00+10 | 206 +----------------------+---------------------+---------------------+ 207 | 2020-07-30T08:00:00Z | --07-30T18:00:00+10 | --07-31T08:00:00+10 | 208 +----------------------+---------------------+---------------------+ 209 | 2020-07-31T12:00:00Z | --07-31T22:00:00+10 | --08-03T08:00:00+10 | 210 +----------------------+---------------------+---------------------+ 211 | 2020-08-01T16:00:00Z | --08-02T02:00:00+10 | --08-03T08:00:00+10 | 212 +----------------------+---------------------+---------------------+ 214 Table 1 216 The following example shows awaken times falling before, during, and 217 after a daylight saving to standard time transition. Note that the 218 transition occurs at 2020-11-01T02:00:00-04. 220 require "snooze"; 221 snooze :tzid "America/New_York" "01:30:00"; 223 +======================+=====================+=====================+ 224 | Arrival (UTC) | Arrival (New York) | Awaken (New York) | 225 +======================+=====================+=====================+ 226 | 2020-11-01T05:00:00Z | --11-01T01:00:00-04 | --11-01T01:30:00-04 | 227 +----------------------+---------------------+---------------------+ 228 | 2020-11-01T06:00:00Z | --11-01T01:00:00-05 | --11-02T01:30:00-05 | 229 +----------------------+---------------------+---------------------+ 230 | 2020-11-01T07:00:00Z | --11-01T02:00:00-05 | --11-02T01:30:00-05 | 231 +----------------------+---------------------+---------------------+ 233 Table 2 235 The following example shows awaken times falling before, during, and 236 after a standard to daylight saving time transition. Note that the 237 transition occurs at 2021-03-14T02:00:00-05. 239 require "snooze"; 240 snooze :tzid "America/New_York" "02:30:00"; 242 +======================+=====================+=====================+ 243 | Arrival (UTC) | Arrival (New York) | Awaken (New York) | 244 +======================+=====================+=====================+ 245 | 2021-03-13T06:30:00Z | --03-13T01:30:00-05 | --03-13T02:30:00-05 | 246 +----------------------+---------------------+---------------------+ 247 | 2021-03-14T06:30:00Z | --03-14T01:30:00-05 | --03-14T03:30:00-04 | 248 +----------------------+---------------------+---------------------+ 249 | 2021-03-14T07:30:00Z | --03-14T03:30:00-04 | --03-15T02:30:00-04 | 250 +----------------------+---------------------+---------------------+ 252 Table 3 254 4.4. Interaction with Extensions to the Fileinto Action 256 Some tagged arguments defined in extensions to the fileinto action 257 can be used together with the snooze action. The sections below 258 describe these interactions. Tagged arguments in future extensions 259 to the fileinto action need to describe their interaction with the 260 snooze extension, if any. 262 When any fileinto extension arguments are used with the snooze 263 extension, the corresponding extension MUST be enabled, and the 264 arguments are defined to have the same syntax, semantics, and 265 treatment as they do with the fileinto action. 267 4.4.1. Imap4flags Extension 269 When the "imap4flags" [RFC5232] extension is enabled in a script, two 270 additional tagged arguments are added to "snooze" that allow 271 manipulating the set of flags on a snoozed message. 273 AWAKEN-OPTIONS /= ADDFLAGS / REMOVEFLAGS 275 ADDFLAGS = ":addflags" string-list 276 REMOVEFLAGS = ":removeflags" string-list 278 The optional :addflags and :removeflags arguments are used to specify 279 which IMAP [RFC3501] flags should be added to and/or removed from the 280 set of IMAP flags present on the snoozed message at the time of 281 awakening. Note the set of IMAP flags present at the time of 282 awakening may be the empty set. 284 If the "setflag" and/or "addflag" actions have been used to store 285 IMAP flags in the imap4flags internal variable, the Sieve interpreter 286 MUST use the current value of the internal variable as the set of 287 flags to associate with the message when storing it into the 288 "snoozed" mailbox. 290 This document doesn't dictate how the Sieve interpreter will set the 291 IMAP flags. In particular, the Sieve interpreter may work as an IMAP 292 client or may have direct access to the mailstore. 294 The general requirements for flag handling specified in Section 2 of 295 [RFC5232] MUST be followed. 297 4.4.1.1. Example 299 The following example leverages the Date [RFC5260], Relational 300 [RFC5231], and Imap4flags [RFC5232] extensions to snooze messages 301 received after business hours until the following work day. Note 302 that the message is marked as important when it is snoozed, and will 303 be marked as unread when it is awakened. 305 require ["snooze", "imap4flags", "date", "relational"]; 307 if anyof(header :is "from" "boss@example.com", 308 currentdate :is "weekday" "0", 309 currentdate :is "weekday" "6", 310 currentdate :value "ge" "hour" "17") { 311 setflag "\\Important"; 312 snooze :removeflags "\\Seen" 313 :weekdays ["1". "2", "3", "4", "5"] 314 :tzid "American/New_York", "09:00"; 315 } 317 4.4.2. Mailbox Extension 319 This document extends the definition of the ":create" [RFC5490] 320 tagged argument so that it can be used with the snooze action. 322 AWAKEN-OPTIONS /= CREATE 324 CREATE = ":create" 325 ; MUST NOT be appear unless MAILBOX also appears 327 If the optional ":create" argument is specified with snooze, it 328 instructs the Sieve interpreter to create the target mailbox, if 329 needed, before attempting to file the awakened message into the 330 target mailbox. 332 4.4.3. Special-Use Extension 334 This document extends the definition of the ":specialuse" [RFC8579] 335 tagged argument so that it can be used with the snooze action. 337 AWAKEN-OPTIONS /= SPECIAL-USE 339 SPECIAL-USE = ":specialuse" string 341 If the optional ":specialuse" argument is specified with snooze, it 342 instructs the Sieve interpreter to check whether a mailbox exists 343 with the specific special-use flag assigned to it. If such a mailbox 344 exists, the awakened message is filed into the special-use mailbox. 345 Otherwise, the awakened message is filed into the target mailbox. 347 If both the optional ":specialuse" and ":create" arguments are 348 specified with snooze, the Sieve interpreter is instructed to create 349 the target mailbox per Section 4.1 of [RFC8579], if needed. 351 4.4.4. MailboxID Extension 353 This document extends the definition of the ":mailboxid" [RFC9042] 354 tagged argument so that it can be used with the snooze action. 356 AWAKEN-OPTIONS /= MAILBOXID 358 MAILBOXID = ":mailboxid" string 360 If the optional ":mailboxid" argument is specified with snooze, it 361 instructs the Sieve interpreter to check whether a mailbox exists in 362 the user's personal namespace [RFC2342] with the specified MAILBOXID 363 [RFC8474]. If such a mailbox exists, the awakened message is filed 364 into that mailbox. Otherwise, the awakened message is filed into the 365 target mailbox. 367 It is an error to specify both ":mailboxid" and ":specialuse" in the 368 same snooze action. 370 5. Implementation Status 372 < RFC Editor: before publication please remove this section and the 373 reference to [RFC7942] > 375 This section records the status of known implementations of the 376 protocol defined by this specification at the time of posting of this 377 Internet-Draft, and is based on a proposal described in [RFC7942]. 378 The description of implementations in this section is intended to 379 assist the IETF in its decision processes in progressing drafts to 380 RFCs. Please note that the listing of any individual implementation 381 here does not imply endorsement by the IETF. Furthermore, no effort 382 has been spent to verify the information presented here that was 383 supplied by IETF contributors. This is not intended as, and must not 384 be construed to be, a catalog of available implementations or their 385 features. Readers are advised to note that other implementations may 386 exist. 388 According to [RFC7942], "this will allow reviewers and working groups 389 to assign due consideration to documents that have the benefit of 390 running code, which may serve as evidence of valuable experimentation 391 and feedback that have made the implemented protocols more mature. 392 It is up to the individual working groups to use this information as 393 they see fit". 395 5.1. Cyrus Server 397 The open source Cyrus Server (http://www.cyrusimap.org/) project is a 398 highly scalable enterprise mail system which supports Sieve email 399 filtering at the point of final delivery. This production level 400 Sieve implementation supports all of the requirements described in 401 this document. This implementation is freely distributable under a 402 BSD style license from Computing Services at Carnegie Mellon 403 University (http://www.cmu.edu/computing/). 405 6. Security Considerations 407 Security considerations are discussed in [RFC5228], [RFC5232], 408 [RFC8579], and [RFC9042]. 410 It is believed that this extension doesn't introduce any additional 411 security concerns. 413 7. Privacy Considerations 415 It is believed that this extension doesn't introduce any privacy 416 considerations beyond those in [RFC5228]. 418 8. IANA Considerations 420 8.1. Registration of Sieve Extension 422 This document defines the following new Sieve extension to be added 423 to the registry defined in Section 6.2 of [RFC5228] and located here: 424 https://www.iana.org/assignments/sieve-extensions/sieve- 425 extensions.xhtml#sieve-extensions 426 IANA are requested to add a capability to the Sieve Extensions 427 registry: 429 To: iana@iana.org 431 Subject: Registration of new Sieve extension 433 Capability name: snooze 435 Description: Adds the "snooze" action command to postpone delivery 436 of a message into a target mailbox until a later point in time. 438 RFC number: RFC XXXX 440 Contact address: The Sieve discussion list 442 8.2. Registration of IMAP Mailbox Name Attribute 444 This document defines the following new IMAP mailbox name attribute 445 to be added to the registry defined in Section 6.2 of [RFC8457] and 446 located here: https://www.iana.org/assignments/imap-mailbox-name- 447 attributes/imap-mailbox-name-attributes.xhtml#imap-mailbox-name- 448 attributes 450 IANA are requested to add an attribute to the IMAP Mailbox Name 451 Attribute registry: 453 To: iana@iana.org 455 Subject: Registration of new IMAP Mailbox Name Attribute 457 Attribute name: Snoozed 459 Description: Messages that have been snoozed. 461 Reference: RFC XXXX 463 9. Acknowledgments 465 The authors would like to thank the following individuals for 466 contributing their ideas and support for writing this specification: 467 Ned Freed, Barry Leiba, and Alexey Melnikov. 469 10. References 471 10.1. Normative References 473 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 474 Requirement Levels", BCP 14, RFC 2119, 475 DOI 10.17487/RFC2119, March 1997, 476 . 478 [RFC2342] Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342, 479 DOI 10.17487/RFC2342, May 1998, 480 . 482 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 483 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 484 . 486 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 487 Specifications: ABNF", RFC 4234, DOI 10.17487/RFC4234, 488 October 2005, . 490 [RFC5228] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email 491 Filtering Language", RFC 5228, DOI 10.17487/RFC5228, 492 January 2008, . 494 [RFC5232] Melnikov, A., "Sieve Email Filtering: Imap4flags 495 Extension", RFC 5232, DOI 10.17487/RFC5232, January 2008, 496 . 498 [RFC5490] Melnikov, A., "The Sieve Mail-Filtering Language -- 499 Extensions for Checking Mailbox Status and Accessing 500 Mailbox Metadata", RFC 5490, DOI 10.17487/RFC5490, March 501 2009, . 503 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 504 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 505 May 2017, . 507 [RFC8457] Leiba, B., Ed., "IMAP "$Important" Keyword and 508 "\Important" Special-Use Attribute", RFC 8457, 509 DOI 10.17487/RFC8457, September 2018, 510 . 512 [RFC8474] Gondwana, B., Ed., "IMAP Extension for Object 513 Identifiers", RFC 8474, DOI 10.17487/RFC8474, September 514 2018, . 516 [RFC8579] Bosch, S., "Sieve Email Filtering: Delivering to Special- 517 Use Mailboxes", RFC 8579, DOI 10.17487/RFC8579, May 2019, 518 . 520 [RFC9042] Gondwana, B., Ed., "Sieve Email Filtering: Delivery by 521 MAILBOXID", RFC 9042, DOI 10.17487/RFC9042, June 2021, 522 . 524 [tzdb] Internet Assigned Numbers Authority, "Time Zone Database", 525 . 527 10.2. Informative References 529 [RFC5231] Segmuller, W. and B. Leiba, "Sieve Email Filtering: 530 Relational Extension", RFC 5231, DOI 10.17487/RFC5231, 531 January 2008, . 533 [RFC5260] Freed, N., "Sieve Email Filtering: Date and Index 534 Extensions", RFC 5260, DOI 10.17487/RFC5260, July 2008, 535 . 537 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 538 Code: The Implementation Status Section", BCP 205, 539 RFC 7942, DOI 10.17487/RFC7942, July 2016, 540 . 542 [RFC8621] Jenkins, N. and C. Newman, "The JSON Meta Application 543 Protocol (JMAP) for Mail", RFC 8621, DOI 10.17487/RFC8621, 544 August 2019, . 546 Appendix A. Change History (To be removed by RFC Editor before 547 publication) 549 Changes since draft-ietf-extra-sieve-snooze-02: 551 * Updated :mailboxid reference to RFC9042. 553 * Added an informative reference to RFC8621. 555 * Miscellaneous editorial changes. 557 Changes since draft-ietf-extra-sieve-snooze-01: 559 * Miscellaneous editorial changes. 561 Changes since draft-ietf-extra-sieve-snooze-00: 563 * Disallow both :mailboxid and :specialuse in the same snooze 564 action. 566 * Updated :mailboxid reference to draft-ietf-extra-sieve-mailboxid 567 * Specified that snooze cancels implicit keep. 569 * Specified that implementations MUST use a "snoozed" mailbox. 571 * Added registration of \Snoozed Special-Use Attribute. 573 * Added example of manipulating IMAP flags at both snooze time and 574 awaken time. 576 * Miscellaneous editorial changes. 578 Authors' Addresses 580 Kenneth Murchison 581 Fastmail US LLC 582 1429 Walnut Street - Suite 1201 583 Philadelphia, PA 19102 584 United States of America 585 Email: murch@fastmailteam.com 587 Ricardo Signes 588 Fastmail US LLC 589 1429 Walnut Street - Suite 1201 590 Philadelphia, PA 19102 591 United States of America 592 Email: rjbs@fastmailteam.com 594 Neil Jenkins 595 Fastmail Pty Ltd 596 Level 2, 114 William Street 597 Melbourne VIC 3000 598 Australia 599 Email: neilj@fastmailteam.com