idnits 2.17.1 draft-ietf-extra-sieve-snooze-01.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 (February 22, 2021) is 1149 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 531 -- Looks like a reference, but probably isn't: '2' on line 533 == Outdated reference: A later version (-09) exists of draft-ietf-extra-sieve-mailboxid-06 ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 5 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: August 26, 2021 February 22, 2021 8 Sieve Email Filtering: Snooze Extension 9 draft-ietf-extra-sieve-snooze-01 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 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 August 26, 2021. 35 Copyright Notice 37 Copyright (c) 2021 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. Capability Identifier . . . . . . . . . . . . . . . . . . . . 3 55 4. Snooze Action . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4.1. Mailbox Argument . . . . . . . . . . . . . . . . . . . . 3 57 4.2. Weekdays Argument . . . . . . . . . . . . . . . . . . . . 4 58 4.3. Times and TZID Arguments . . . . . . . . . . . . . . . . 4 59 4.3.1. Awaken Times Examples . . . . . . . . . . . . . . . . 5 60 4.4. Interaction with Extensions to the Fileinto Action . . . 6 61 4.4.1. Imap4flags Extension . . . . . . . . . . . . . . . . 6 62 4.4.2. Mailbox Extension . . . . . . . . . . . . . . . . . . 7 63 4.4.3. Special-Use Extension . . . . . . . . . . . . . . . . 7 64 4.4.4. MailboxID Extension . . . . . . . . . . . . . . . . . 8 65 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 8 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 67 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 69 8.1. Registration of Sieve Extension . . . . . . . . . . . . . 9 70 8.2. Registration of IMAP Mailbox Name Attribute . . . . . . . 10 71 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 72 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 74 10.2. Informative References . . . . . . . . . . . . . . . . . 12 75 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 12 76 Appendix A. Change History (To be removed by RFC Editor before 77 publication) . . . . . . . . . . . . . . . . . . . . 12 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 80 1. Introduction 82 Users are not always ready, willing, or able to read and respond to 83 email messages at the time of their arrival. Sometimes it is 84 desirable to have messages appear in a mailbox at a more convenient 85 time for the user to act upon them. 87 This document defines an extension to the Sieve language [RFC5228] 88 that enables scripts to postpone the delivery of a message into a 89 target mailbox until a later point in time. 91 2. Conventions Used in This Document 93 Conventions for notations are as in Section 1.1 of [RFC5228], 94 including use of the "Usage:" label for the definition of action and 95 tagged arguments syntax. 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 99 "OPTIONAL" in this document are to be interpreted as described in 100 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 101 capitals, as shown here. 103 3. Capability Identifier 105 Sieve implementations that implement this extension have an 106 identifier of "snooze" for use with the capability mechanism. 108 4. Snooze Action 110 Usage: snooze *AWAKEN-OPTIONS 112 The AWAKEN-OPTIONS argument is defined here in ABNF [RFC4234] syntax 113 so that it can be modified by other extensions. 115 AWAKEN-OPTIONS = MAILBOX / WEEKDAYS / TZID 116 ; each option MUST NOT appear more than once 117 ; however, per Section 2.6.2 of RFC 5228, 118 ; the tagged arguments in AWAKEN-OPTIONS 119 ; may appear in any order 121 MAILBOX = ":mailbox" string 122 WEEKDAYS = ":weekdays" string-list 123 TZID = ":tzid" string 125 The "snooze" action cancels the implicit keep and postpones delivery 126 of the message into the specified mailbox at a later point in time. 128 The snooze action is semantically equivalent to a delayed fileinto 129 action (see Section 4.1 of [RFC5228]). The arguments of the snooze 130 action specify when, where, and how the awakened message will be 131 filed. 133 A Sieve interpreter MUST implement the snooze action by delivering 134 the message to a special "snoozed" mailbox within its mailstore. 135 IMAP and JMAP servers MUST apply the "Snoozed" (Section 8.2) 136 attribute to this mailbox. The message will reside in this special 137 mailbox until the prescribed awaken time at which it will be moved 138 into the specified target mailbox. 140 4.1. Mailbox Argument 142 The optional :mailbox argument is used to specify the target mailbox 143 that the message will be filed into when it is awakened. It is 144 equivalent to the mailbox argument of the fileinto action (see 145 Section 4.1 of [RFC5228]). 147 If :mailbox is omitted, or if the specified mailbox doesn't exist at 148 the time of awakening, the message will be filed into the user's main 149 mailbox. For instance, in an implementation where the IMAP server is 150 running scripts on behalf of the user at time of delivery, the user's 151 "INBOX" would be the implicit target for awakening messages. 153 4.2. Weekdays Argument 155 The optional :weekdays argument specifies the set of days on which 156 the specified set of awakening times apply. Each day of the week is 157 expressed as an integer between "0" and "6". "0" is Sunday, "1" is 158 Monday, etc. This syntax matches that of the "weekday" date-part 159 argument to the date test extension (see Section 4.2 of [RFC5260]). 161 If :weekdays is omitted, the set of awakening times applies to every 162 day of the week. 164 4.3. Times and TZID Arguments 166 The required times argument, along with the optional :tzid argument, 167 are used to specify when a snoozed message will be awakened. Each 168 time is specified in "hh:mm:ss" format and is interpreted as the 169 local time in the time zone specified by the :tzid argument. 171 The value of the :tzid argument MUST be a time zone identifier from 172 the IANA Time Zone Database [tzdb]. If :tzid is omitted, the time 173 zone of the Sieve interpreter is used. 175 The combination of the weekdays and times form a chronological list 176 of awaken times. When a message is snoozed, it is assigned the next 177 future awaken time in the list. If a message is snoozed on a day 178 with no awaken times, or after the last awaken time on a given day, 179 the first awaken time on the next available day is used. 181 If the local time in the specified time zone occurs more than once 182 (daylight saving to standard time transition), the first occurrence 183 of the specified time value is used. If the local time in the 184 specified time zone does not occur (standard to daylight saving time 185 transition), the specified time value is interpreted using the UTC 186 offset prior to the transition. 188 4.3.1. Awaken Times Examples 190 The following examples show, given the specified snooze action and a 191 set of message arrival times, the corresponding times at which the 192 message would be awakened and filed. 194 The following example shows awaken times rolling into the next day or 195 week. Note that 2020-07-30 falls on a Thursday. 197 require "snooze"; 198 snooze :weekdays ["1", "3", "5", "2", "4"] 199 :tzid "Australia/Melbourne" ["12:00:00", 200 "08:00:00", "16:00:00"]; 202 +----------------------+---------------------+---------------------+ 203 | Arrival (UTC) | Arrival (Melbourne) | Awaken (Melbourne) | 204 +----------------------+---------------------+---------------------+ 205 | 2020-07-30T00:00:00Z | --07-30T10:00:00+10 | --07-30T12:00:00+10 | 206 | 2020-07-30T04:00:00Z | --07-30T14:00:00+10 | --07-30T16:00:00+10 | 207 | 2020-07-30T08:00:00Z | --07-30T18:00:00+10 | --07-31T08:00:00+10 | 208 | 2020-07-31T12:00:00Z | --07-31T22:00:00+10 | --08-03T08:00:00+10 | 209 | 2020-08-01T16:00:00Z | --08-02T02:00:00+10 | --08-03T08:00:00+10 | 210 +----------------------+---------------------+---------------------+ 212 The following example shows awaken times falling before, during, and 213 after a daylight saving to standard time transition. Note that the 214 transition occurs at 2020-11-01T02:00:00-04. 216 require "snooze"; 217 snooze :tzid "America/New_York" "01:30:00"; 219 +----------------------+---------------------+---------------------+ 220 | Arrival (UTC) | Arrival (New York) | Awaken (New York) | 221 +----------------------+---------------------+---------------------+ 222 | 2020-11-01T05:00:00Z | --11-01T01:00:00-04 | --11-01T01:30:00-04 | 223 | 2020-11-01T06:00:00Z | --11-01T01:00:00-05 | --11-02T01:30:00-05 | 224 | 2020-11-01T07:00:00Z | --11-01T02:00:00-05 | --11-02T01:30:00-05 | 225 +----------------------+---------------------+---------------------+ 227 The following example shows awaken times falling before, during, and 228 after a standard to daylight saving time transition. Note that the 229 transition occurs at 2021-03-14T02:00:00-05. 231 require "snooze"; 232 snooze :tzid "America/New_York" "02:30:00"; 233 +----------------------+---------------------+---------------------+ 234 | Arrival (UTC) | Arrival (New York) | Awaken (New York) | 235 +----------------------+---------------------+---------------------+ 236 | 2021-03-13T06:30:00Z | --03-13T01:30:00-05 | --03-13T02:30:00-05 | 237 | 2021-03-14T06:30:00Z | --03-14T01:30:00-05 | --03-14T03:30:00-04 | 238 | 2021-03-14T07:30:00Z | --03-14T03:30:00-04 | --03-15T02:30:00-04 | 239 +----------------------+---------------------+---------------------+ 241 4.4. Interaction with Extensions to the Fileinto Action 243 Some tagged arguments defined in extensions to the fileinto action 244 can be used together with the snooze action. The sections below 245 describe these interactions. Tagged arguments in future extensions 246 to the fileinto action need to describe their interaction with the 247 snooze extension, if any. 249 When any fileinto extension arguments are used with the snooze 250 extension, the corresponding extension MUST be enabled, and the 251 arguments are defined to have the same syntax, semantics, and 252 treatment as they do with the fileinto action. 254 4.4.1. Imap4flags Extension 256 When the "imap4flags" [RFC5232] extension is enabled in a script, two 257 additional tagged arguments are added to "snooze" that allow 258 manipulating the set of flags on a snoozed message. 260 AWAKEN-OPTIONS /= ADDFLAGS / REMOVEFLAGS 262 ADDFLAGS = ":addflags" string-list 263 REMOVEFLAGS = ":removeflags" string-list 265 If the "setflag" and/or "addflag" actions have been used to store 266 IMAP flags in the imap4flags internal variable, the Sieve interpreter 267 MUST use the current value of the internal variable as the set of 268 flags to associate with the message when storing it into the 269 "snoozed" mailbox. 271 The optional :addflags and :removeflags arguments are used to specify 272 which IMAP [RFC3501] flags should be added to and/or removed from the 273 set of IMAP flags present on the snoozed message at the time of 274 awakening. Note the set of IMAP flags present at the time of 275 awakening may be the empty set. 277 This document doesn't dictate how the Sieve interpreter will set the 278 IMAP flags. In particular, the Sieve interpreter may work as an IMAP 279 client or may have direct access to the mailstore. 281 The general requirements for flag handling specified in Section 2 of 282 [RFC5232] MUST be followed. 284 4.4.1.1. Example 286 The following example leverage the Date [RFC5260], Relational 287 [RFC5231], and Imap4flags [RFC5232] extensions to snooze messages 288 received after business hours until the following work day. Note 289 that the message is marked as important when it is snoozed, and will 290 be marked as unread when it is awakened. 292 require ["snooze", "imap4flags", "date", "relational"]; 294 if anyof(header :is "from" "boss@example.com", 295 currentdate :is "weekday" "0", 296 currentdate :is "weekday" "6", 297 currentdate :value "ge" "hour" "17") { 298 setflag "\\Important"; 299 snooze :removeflags "\\Seen" 300 :weekdays ["1". "2", "3", "4", "5"] 301 :tzid "American/New_York", "09:00"; 302 } 304 4.4.2. Mailbox Extension 306 This document extends the definition of the ":create" [RFC5490] 307 tagged argument so that it can be used with the snooze action. 309 AWAKEN-OPTIONS /= CREATE 311 CREATE = ":create" 312 ; MUST NOT be appear unless MAILBOX also appears 314 If the optional ":create" argument is specified with snooze, it 315 instructs the Sieve interpreter to create the target mailbox, if 316 needed, before attempting to file the awakened message into the 317 target mailbox. 319 4.4.3. Special-Use Extension 321 This document extends the definition of the ":specialuse" [RFC8579] 322 tagged argument so that it can be used with the snooze action. 324 AWAKEN-OPTIONS /= SPECIAL-USE 326 SPECIAL-USE = ":specialuse" string 327 If the optional ":specialuse" argument is specified with snooze, it 328 instructs the Sieve interpreter to check whether a mailbox exists 329 with the specific special-use flag assigned to it. If such a mailbox 330 exists, the awakened message is filed into the special-use mailbox. 331 Otherwise, the awakened message is filed into the target mailbox. 333 If both the optional ":specialuse" and ":create" arguments are 334 specified with snooze, the Sieve interpreter is instructed to create 335 the target mailbox per Section 4.1 of [RFC8579], if needed. 337 4.4.4. MailboxID Extension 339 This document extends the definition of the ":mailboxid" 340 [I-D.ietf-extra-sieve-mailboxid] tagged argument so that it can be 341 used with the snooze action. 343 AWAKEN-OPTIONS /= MAILBOXID 345 MAILBOXID = ":mailboxid" string 347 If the optional ":mailboxid" argument is specified with snooze, it 348 instructs the Sieve interpreter to check whether a mailbox exists in 349 the user's personal namespace [RFC2342] with the specified MAILBOXID 350 [RFC8474]. If such a mailbox exists, the awakened message is filed 351 into that mailbox. Otherwise, the awakened message is filed into the 352 target mailbox. 354 It is an error to specify both ":mailboxid" and ":specialuse" in the 355 same snooze action. 357 5. Implementation Status 359 < RFC Editor: before publication please remove this section and the 360 reference to [RFC7942] > 362 This section records the status of known implementations of the 363 protocol defined by this specification at the time of posting of this 364 Internet-Draft, and is based on a proposal described in [RFC7942]. 365 The description of implementations in this section is intended to 366 assist the IETF in its decision processes in progressing drafts to 367 RFCs. Please note that the listing of any individual implementation 368 here does not imply endorsement by the IETF. Furthermore, no effort 369 has been spent to verify the information presented here that was 370 supplied by IETF contributors. This is not intended as, and must not 371 be construed to be, a catalog of available implementations or their 372 features. Readers are advised to note that other implementations may 373 exist. 375 According to [RFC7942], "this will allow reviewers and working groups 376 to assign due consideration to documents that have the benefit of 377 running code, which may serve as evidence of valuable experimentation 378 and feedback that have made the implemented protocols more mature. 379 It is up to the individual working groups to use this information as 380 they see fit". 382 5.1. Cyrus Server 384 The open source Cyrus Server [1] project is a highly scalable 385 enterprise mail system which supports Sieve email filtering at the 386 point of final delivery. This production level Sieve implementation 387 supports all of the requirements described in this document. This 388 implementation is freely distributable under a BSD style license from 389 Computing Services at Carnegie Mellon University [2]. 391 6. Security Considerations 393 Security considerations are discussed in [RFC5228], [RFC5232], 394 [RFC8579], and [I-D.ietf-extra-sieve-mailboxid]. 396 It is believed that this extension doesn't introduce any additional 397 security concerns. 399 7. Privacy Considerations 401 It is believed that this extension doesn't introduce any privacy 402 considerations beyond those in [RFC5228]. 404 8. IANA Considerations 406 8.1. Registration of Sieve Extension 408 This document defines the following new Sieve extension to be added 409 to the registry defined in Section 6.2 of [RFC5228] and located here: 410 413 IANA are requested to add a capability to the Sieve Extensions 414 registry: 416 To: iana@iana.org 418 Subject: Registration of new Sieve extension 420 Capability name: snooze 421 Description: Adds the "snooze" action command to postpone delivery 422 of a message into a target mailbox until a later point in time. 424 RFC number: RFC XXXX 426 Contact address: The Sieve discussion list 428 8.2. Registration of IMAP Mailbox Name Attribute 430 This document defines the following new IMAP mailbox name attribute 431 to be added to the registry defined in Section 6.2 of [RFC8457] and 432 located here: 436 IANA are requested to add an attribute to the IMAP Mailbox Name 437 Attribute registry: 439 To: iana@iana.org 441 Subject: Registration of new IMAP Mailbox Name Attribute 443 Attribute name: Snoozed 445 Description: Messages that have been snoozed. 447 Reference: RFC XXXX 449 9. Acknowledgments 451 The authors would like to thank the following individuals for 452 contributing their ideas and support for writing this specification: 453 Ned Freed, Barry Leiba, and Alexey Melnikov. 455 10. References 457 10.1. Normative References 459 [I-D.ietf-extra-sieve-mailboxid] 460 Gondwana, B., "Sieve Email Filtering: delivery by 461 mailboxid", draft-ietf-extra-sieve-mailboxid-06 (work in 462 progress), December 2020. 464 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 465 Requirement Levels", BCP 14, RFC 2119, 466 DOI 10.17487/RFC2119, March 1997, 467 . 469 [RFC2342] Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342, 470 DOI 10.17487/RFC2342, May 1998, 471 . 473 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 474 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 475 . 477 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 478 Specifications: ABNF", RFC 4234, DOI 10.17487/RFC4234, 479 October 2005, . 481 [RFC5228] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email 482 Filtering Language", RFC 5228, DOI 10.17487/RFC5228, 483 January 2008, . 485 [RFC5232] Melnikov, A., "Sieve Email Filtering: Imap4flags 486 Extension", RFC 5232, DOI 10.17487/RFC5232, January 2008, 487 . 489 [RFC5490] Melnikov, A., "The Sieve Mail-Filtering Language -- 490 Extensions for Checking Mailbox Status and Accessing 491 Mailbox Metadata", RFC 5490, DOI 10.17487/RFC5490, March 492 2009, . 494 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 495 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 496 May 2017, . 498 [RFC8457] Leiba, B., Ed., "IMAP "$Important" Keyword and 499 "\Important" Special-Use Attribute", RFC 8457, 500 DOI 10.17487/RFC8457, September 2018, 501 . 503 [RFC8474] Gondwana, B., Ed., "IMAP Extension for Object 504 Identifiers", RFC 8474, DOI 10.17487/RFC8474, September 505 2018, . 507 [RFC8579] Bosch, S., "Sieve Email Filtering: Delivering to Special- 508 Use Mailboxes", RFC 8579, DOI 10.17487/RFC8579, May 2019, 509 . 511 [tzdb] Internet Assigned Numbers Authority, "Time Zone Database", 512 . 514 10.2. Informative References 516 [RFC5231] Segmuller, W. and B. Leiba, "Sieve Email Filtering: 517 Relational Extension", RFC 5231, DOI 10.17487/RFC5231, 518 January 2008, . 520 [RFC5260] Freed, N., "Sieve Email Filtering: Date and Index 521 Extensions", RFC 5260, DOI 10.17487/RFC5260, July 2008, 522 . 524 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 525 Code: The Implementation Status Section", BCP 205, 526 RFC 7942, DOI 10.17487/RFC7942, July 2016, 527 . 529 10.3. URIs 531 [1] http://www.cyrusimap.org/ 533 [2] http://www.cmu.edu/computing/ 535 Appendix A. Change History (To be removed by RFC Editor before 536 publication) 538 Changes since draft-ietf-extra-sieve-snooze-00: 540 o Disallow both :mailboxid and :specialuse in the same snooze 541 action. 543 o Updated :mailboxid reference to draft-ietf-extra-sieve-mailboxid 545 o Specified that snooze cancels implicit keep. 547 o Specified that implementations MUST use a "snoozed" mailbox. 549 o Added registration of \Snoozed Special-Use Attribute. 551 o Added example of manipulating IMAP flags at both snooze time and 552 awaken time. 554 o Miscellaneous editorial changes. 556 Authors' Addresses 557 Kenneth Murchison 558 Fastmail US LLC 559 1429 Walnut Street - Suite 1201 560 Philadelphia, PA 19102 561 USA 563 Email: murch@fastmailteam.com 565 Ricardo Signes 566 Fastmail US LLC 567 1429 Walnut Street - Suite 1201 568 Philadelphia, PA 19102 569 USA 571 Email: rjbs@fastmailteam.com 573 Neil Jenkins 574 Fastmail Pty Ltd 575 Level 2, 114 William Street 576 Melbourne, VIC 3000 577 Australia 579 Email: neilj@fastmailteam.com