idnits 2.17.1 draft-ietf-jmap-mail-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 document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. -- The draft header indicates that this document updates RFC5788, 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 RFC5788, updated by this document, for RFC5378 checks: 2002-06-21) -- 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 (November 29, 2017) is 2340 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 1959 -- Looks like a reference, but probably isn't: '2' on line 1961 ** Obsolete normative reference: RFC 3798 (Obsoleted by RFC 8098) ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 JMAP N. Jenkins 3 Internet-Draft FastMail 4 Updates: 5788 (if approved) November 29, 2017 5 Intended status: Standards Track 6 Expires: June 2, 2018 8 JMAP for Mail 9 draft-ietf-jmap-mail-03 11 Abstract 13 This document specifies a data model for synchronising email data 14 with a server using JMAP. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on June 2, 2018. 33 Copyright Notice 35 Copyright (c) 2017 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 52 1.2. The Date datatypes . . . . . . . . . . . . . . . . . . . 4 53 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 54 1.4. Addition to the capabilities object . . . . . . . . . . . 4 55 2. Mailboxes . . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 2.1. getMailboxes . . . . . . . . . . . . . . . . . . . . . . 8 57 2.2. getMailboxUpdates . . . . . . . . . . . . . . . . . . . . 8 58 2.3. getMailboxList . . . . . . . . . . . . . . . . . . . . . 9 59 2.4. getMailboxListUpdates . . . . . . . . . . . . . . . . . . 9 60 2.5. setMailboxes . . . . . . . . . . . . . . . . . . . . . . 9 61 3. Threads . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 62 3.1. getThreads . . . . . . . . . . . . . . . . . . . . . . . 11 63 3.1.1. Example . . . . . . . . . . . . . . . . . . . . . . . 11 64 3.2. getThreadUpdates . . . . . . . . . . . . . . . . . . . . 11 65 4. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . 11 66 4.1. getMessages . . . . . . . . . . . . . . . . . . . . . . . 16 67 4.1.1. Example . . . . . . . . . . . . . . . . . . . . . . . 17 68 4.2. getMessageUpdates . . . . . . . . . . . . . . . . . . . . 17 69 4.3. getMessageList . . . . . . . . . . . . . . . . . . . . . 18 70 4.3.1. Filtering . . . . . . . . . . . . . . . . . . . . . . 18 71 4.3.2. Sorting . . . . . . . . . . . . . . . . . . . . . . . 21 72 4.3.3. Thread collapsing . . . . . . . . . . . . . . . . . . 22 73 4.3.4. Response . . . . . . . . . . . . . . . . . . . . . . 22 74 4.4. getMessageListUpdates . . . . . . . . . . . . . . . . . . 22 75 4.5. setMessages . . . . . . . . . . . . . . . . . . . . . . . 22 76 4.6. importMessages . . . . . . . . . . . . . . . . . . . . . 23 77 4.7. copyMessages . . . . . . . . . . . . . . . . . . . . . . 25 78 5. MessageSubmission . . . . . . . . . . . . . . . . . . . . . . 27 79 5.1. getMessageSubmissions . . . . . . . . . . . . . . . . . . 32 80 5.2. getMessageSubmissionUpdates . . . . . . . . . . . . . . . 32 81 5.3. getMessageSubmissionList . . . . . . . . . . . . . . . . 32 82 5.4. getMessageSubmissionListUpdates . . . . . . . . . . . . . 33 83 5.5. setMessageSubmissions . . . . . . . . . . . . . . . . . . 33 84 6. Identities . . . . . . . . . . . . . . . . . . . . . . . . . 35 85 6.1. getIdentities . . . . . . . . . . . . . . . . . . . . . . 36 86 6.2. getIdentityUpdates . . . . . . . . . . . . . . . . . . . 36 87 6.3. setIdentities . . . . . . . . . . . . . . . . . . . . . . 36 88 7. SearchSnippets . . . . . . . . . . . . . . . . . . . . . . . 36 89 7.1. getSearchSnippets . . . . . . . . . . . . . . . . . . . . 37 90 8. Vacation Response . . . . . . . . . . . . . . . . . . . . . . 38 91 8.1. getVacationResponse . . . . . . . . . . . . . . . . . . . 39 92 8.2. setVacationResponse . . . . . . . . . . . . . . . . . . . 39 93 9. Security considerations . . . . . . . . . . . . . . . . . . . 39 94 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 95 10.1. Normative References . . . . . . . . . . . . . . . . . . 39 96 10.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 42 97 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 42 99 1. Introduction 101 JMAP is a generic protocol for synchronising data, such as mail, 102 calendars or contacts, between a client and a server. It is 103 optimised for mobile and web environments, and aims to provide a 104 consistent interface to different data types. 106 This specification defines a data model for synchronising mail 107 between a client and a server using JMAP. 109 1.1. Notational Conventions 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119]. 115 The underlying format used for this specification is I-JSON 116 ([RFC7493]). Consequently, the terms "object" and "array" as well as 117 the four primitive types (strings, numbers, booleans, and null) are 118 to be interpreted as described in Section 1 of [RFC7159]. Unless 119 otherwise noted, all the property names and values are case 120 sensitive. 122 Some examples in this document contain "partial" JSON documents used 123 for illustrative purposes. In these examples, three periods "..." 124 are used to indicate a portion of the document that has been removed 125 for compactness. 127 Types signatures are given for all JSON objects in this document. 128 The following conventions are used: 130 o "Boolean|String" - The value is either a JSON "Boolean" value, or 131 a JSON "String" value. 133 o "Foo" - Any name that is not a native JSON type means an object 134 for which the properties (and their types) are defined elsewhere 135 within this document. 137 o "Foo[]" - An array of objects of type "Foo". 139 o "String[Foo]" - A JSON "Object" being used as a map (associative 140 array), where all the values are of type "Foo". 142 Object properties may also have a set of attributes defined along 143 with the type signature. These have the following meanings: 145 o *sever-set*: Only the server can set the value for this property. 146 The client MUST NOT send this property when creating a new object 147 of this type. 149 o *immutable*: The value MUST NOT change after the object is 150 created. 152 o *default*: (This is followed by a JSON value). The value that 153 will be used for this property if it is omitted when creating a 154 new object of this type. 156 1.2. The Date datatypes 158 Where "Date" is given as a type, it means a string in [RFC3339] 159 _date-time_ format. To ensure a normalised form, the _time-secfrac_ 160 MUST always be omitted and any letters in the string (e.g. "T" and 161 "Z") MUST be upper-case. For example, ""2014-10-30T14:12:00+08:00"". 163 Where "UTCDate" is given as a type, it means a "Date" where the 164 _time-offset_ component MUST be "Z" (i.e. it must be in UTC time). 165 For example, ""2014-10-30T06:12:00Z"". 167 1.3. Terminology 169 The same terminology is used in this document as in the core JMAP 170 specification. 172 1.4. Addition to the capabilities object 174 The capabilities object is returned as part of the standard JMAP 175 session object; see the JMAP spec. Servers supporting _this_ 176 specification MUST add a property called "ietf:jmapmail" to the 177 capabilities object. The value of this property is an object which 178 MUST contain the following information on server capabilities: 180 o *maxMailboxesPerMessage*: "Number|null" The maximum number of 181 mailboxes that can be can assigned to a single message. This MUST 182 be an integer >= 1, or "null" for no limit (or rather, the limit 183 is always the number of mailboxes in the account). 185 o *maxSizeAttachmentsPerMessage*: "Number" The maximum total size of 186 attachments, in bytes, allowed for a single message. A server MAY 187 still reject messages with a lower attachment size total (for 188 example, if the body includes several megabytes of text, causing 189 the size of the encoded MIME structure to be over some server- 190 defined limit). 192 o *maxDelayedSend*: "Number" The number in seconds of the maximum 193 delay the server supports in sending (see the MessageSubmission 194 object). This is "0" if the server does not support delayed send. 196 o *messageListSortOptions*: "String[]" A list of all the message 197 properties the server supports for sorting by. This MAY include 198 properties the client does not recognise (for example custom 199 properties specified in a vendor extension). Clients MUST ignore 200 any unknown properties in the list. 202 o *submissionExtensions*: "String[String[]]" A JMAP implementation 203 that talks to a Submission [RFC6409] server SHOULD have a 204 configuration setting that allows an administrator to expose a new 205 submission EHLO capability in this field. This allows a JMAP 206 server to gain access to a new submission extension without code 207 changes. By default, the JMAP server should show only known safe- 208 to-expose EHLO capabilities in this field, and hide EHLO 209 capabilities that are only relevant to the JMAP server. Each key 210 in the object is the _ehlo-name_, and the value is a list of 211 _ehlo-args_. Examples of safe-to-expose Submission extensions 212 include: 214 * FUTURERELEASE ([RFC4865]) 216 * SIZE ([RFC1870]) 218 * DSN ([RFC3461]) 220 * DELIVERYBY ([RFC2852]) 222 * MT-PRIORITY ([RFC6710]) 224 A JMAP server MAY advertise an extension and implement the 225 semantics of that extension locally on the JMAP server even if a 226 submission server used by JMAP doesn't implement it. The full 227 IANA registry of submission extensions can be found at 228 231 2. Mailboxes 233 A mailbox represents a named set of emails. This is the primary 234 mechanism for organising messages within an account. It is analogous 235 to a folder or a label in other systems. A mailbox may perform a 236 certain role in the system; see below for more details. 238 For compatibility with IMAP, a message MUST belong to one or more 239 mailboxes. The message id does not change if the message changes 240 mailboxes. 242 A *Mailbox* object has the following properties: 244 o *id*: "String" (immutable; server-set) The id of the mailbox. 246 o *name*: "String" User-visible name for the mailbox, e.g. "Inbox". 247 This may be any UTF-8 string ([RFC3629]) of at least 1 character 248 in length and maximum 256 bytes in size. Servers SHOULD forbid 249 sibling Mailboxes with the same name. 251 o *parentId*: "String|null" (default: "null") The mailbox id for the 252 parent of this mailbox, or "null" if this mailbox is at the top 253 level. Mailboxes form acyclic graphs (forests) directed by the 254 child-to-parent relationship. There MUST NOT be a loop. 256 o *role*: "String|null" (default: "null") Identifies system 257 mailboxes. This property can only be set on create. After the 258 record has been created, this property is immutable. The 259 following values MUST be used for the relevant mailboxes: 261 * "inbox" - the mailbox to which new mail is delivered by 262 default, unless diverted by a rule or spam filter etc. 264 * "archive" - messages the user does not need right now, but does 265 not wish to delete. 267 * "drafts" - messages the user is currently writing and are not 268 yet sent. 270 * "sent" - messages the user has sent. 272 * "trash" - messages the user has deleted. 274 * "spam" - messages considered spam by the server. 276 * "templates" - drafts which should be used as templates (i.e. 277 used as the basis for creating new drafts). 279 No two mailboxes may have the same role. Mailboxes without a 280 known purpose MUST have a role of "null". An account is not 281 required to have mailboxes with any of the above roles. A client 282 MAY create new mailboxes with a role property to help them keep 283 track of a use-case not covered by the above list. To avoid 284 potential conflict with any special behaviour a server might apply 285 to mailboxes with certain roles in the future, any roles not in 286 the above list created by the client must begin with ""x-"". The 287 client MAY attempt to create mailboxes with the standard roles if 288 not already present, but the server MAY reject these. 290 o *sortOrder*: "Number" (default: "0") Defines the sort order of 291 mailboxes when presented in the client's UI, so it is consistent 292 between devices. The number MUST be an integer in the range 0 <= 293 sortOrder < 2^31. A mailbox with a lower order should be 294 displayed before a mailbox with a higher order (that has the same 295 parent) in any mailbox listing in the client's UI. Mailboxes with 296 equal order SHOULD be sorted in alphabetical order by name. The 297 sorting SHOULD take into account locale-specific character order 298 convention. 300 o *mayReadItems*: "Boolean" (server-set) If true, may use this 301 mailbox as part of a filter in a _getMessageList_ call. If a sub- 302 mailbox is shared but not the parent mailbox, this may be "false". 304 o *mayAddItems*: "Boolean" (server-set) The user may add messages to 305 this mailbox (by either creating a new message or moving an 306 existing one). 308 o *mayRemoveItems*: "Boolean" (server-set) The user may remove 309 messages from this mailbox (by either changing the mailboxes of a 310 message or deleting it). 312 o *mayCreateChild*: "Boolean" (server-set) The user may create a 313 mailbox with this mailbox as its parent. 315 o *mayRename*: "Boolean" (server-set) The user may rename the 316 mailbox or make it a child of another mailbox. 318 o *mayDelete*: "Boolean" (server-set) The user may delete the 319 mailbox itself. 321 o *totalMessages*: "Number" (server-set) The number of messages in 322 this mailbox. 324 o *unreadMessages*: "Number" (server-set) The number of messages in 325 this mailbox that have neither the "$Seen" keyword nor the 326 "$Draft" keyword. 328 o *totalThreads*: "Number" (server-set) The number of threads where 329 at least one message in the thread is in this mailbox. 331 o *unreadThreads*: "Number" (server-set) The number of threads where 332 at least one message in the thread has neither the "$Seen" keyword 333 nor the "$Draft" keyword AND at least one message in the thread is 334 in this mailbox (but see below for special case handling of 335 Trash). Note, the unread message does not need to be the one in 336 this mailbox. 338 The Trash mailbox (that is a mailbox with "role == "trash"") MUST be 339 treated specially for the purpose of unread counts: 341 1. Messages that are *only* in the Trash (and no other mailbox) are 342 ignored when calculating the "unreadThreads" count of other 343 mailboxes. 345 2. Messages that are *not* in the Trash are ignored when calculating 346 the "unreadThreads" count for the Trash mailbox. 348 The result of this is that messages in the Trash are treated as 349 though they are in a separate thread for the purposes of unread 350 counts. It is expected that clients will hide messages in the Trash 351 when viewing a thread in another mailbox and vice versa. This allows 352 you to delete a single message to the Trash out of a thread. 354 So for example, suppose you have an account where the entire contents 355 is a single conversation with 2 messages: an unread message in the 356 Trash and a read message in the Inbox. The "unreadThreads" count 357 would be "1" for the Trash and "0" for the Inbox. 359 For IMAP compatibility, a message in both the Trash and another 360 mailbox SHOULD be treated by the client as existing in both places 361 (i.e. when emptying the trash, the client SHOULD just remove the 362 Trash mailbox and leave it in the other mailbox). 364 The following JMAP methods are supported: 366 2.1. getMailboxes 368 Standard _getFoos_ method. The _ids_ argument may be "null" to fetch 369 all at once. 371 2.2. getMailboxUpdates 373 Standard _getFooUpdates_ method, but with one extra argument to the 374 _mailboxUpdates_ response: 376 o *changedProperties*: "String[]|null" If only the mailbox counts 377 (unread/total messages/threads) have changed since the old state, 378 this will be the list of properties that may have changed, i.e. 379 "["totalMessages", "unreadMessages", "totalThreads", 380 "unreadThreads"]". If the server is unable to tell if only counts 381 have changed, it MUST just be "null". 383 Since counts frequently change but the rest of the mailboxes state 384 for most use cases changes rarely, the server can help the client 385 optimise data transfer by keeping track of changes to message counts 386 separately to other state changes. The _changedProperties_ array may 387 be used directly via a result reference in a subsequent getMailboxes 388 call in a single request. 390 2.3. getMailboxList 392 Standard _getFooList_ method. 394 The *FilterCondition* object (optionally passed as the _filter_ 395 argument) has the following properties, any of which may be omitted: 397 o *parentId*: "String|null" The Mailbox _parentId_ property must 398 match the given value exactly. 400 o *hasRole*: "Boolean" If this is "true", a Mailbox matches if it 401 has a non-"null" value for its _role_ property. 403 A Mailbox object matches the filter if and only if all of the given 404 conditions given match. If zero properties are specified, it is 405 automatically "true" for all objects. 407 The following properties MUST be supported for sorting: 409 o "sortOrder" 411 o "name" 413 2.4. getMailboxListUpdates 415 Standard _getFooListUpdates_ method. 417 2.5. setMailboxes 419 Standard _setFoos_ method. The following extra _SetError_ types are 420 defined: 422 For *create*: 424 o "maxQuotaReached": The user has reached a server-defined limit on 425 the number of mailboxes. 427 For *update*: 429 o "forbidden": The update would violate a mayXXX property. 431 For *destroy*: 433 o "forbidden": The update would violate a mayXXX property. 435 o "mailboxHasChild": The mailbox still has at least one child 436 mailbox. The client MUST remove these before it can delete the 437 parent mailbox. 439 o "mailboxHasMessage": The mailbox has at least one message assigned 440 to it. The client MUST remove these before it can delete the 441 mailbox. 443 3. Threads 445 Replies are grouped together with the original message to form a 446 thread. In JMAP, a thread is simply a flat list of messages, ordered 447 by date. Every message MUST belong to a thread, even if it is the 448 only message in the thread. 450 The JMAP spec does not require the server to use any particular 451 algorithm for determining whether two messages belong to the same 452 thread, however there is a recommended algorithm in the 453 implementation guide [1]. 455 If messages are delivered out of order for some reason, a user may 456 receive two messages in the same thread but without headers that 457 associate them with each other. The arrival of a third message in 458 the thread may provide the missing references to join them all 459 together into a single thread. Since the "threadId" of a message is 460 immutable, if the server wishes to merge the threads, it MUST handle 461 this by deleting and reinserting (with a new message id) the messages 462 that change threadId. 464 A *Thread* object has the following properties: 466 o *id*: "String" (immutable) The id of the thread. 468 o *messageIds*: "String[]" The ids of the messages in the thread, 469 sorted such that: 471 * Any message with the "$Draft" keyword that has an "In-Reply-To" 472 header is sorted after the _first_ non-draft message in the 473 thread with the corresponding "Message-Id" header, but before 474 any subsequent non-draft messages. 476 * Other than that, everything is sorted by the _receivedAt_ date 477 of the message, oldest first. 479 * If two messages are identical under the above two conditions, 480 the sort is server-dependent but MUST be stable (sorting by id 481 is recommended). 483 The following JMAP methods are supported: 485 3.1. getThreads 487 Standard _getFoos_ method. 489 3.1.1. Example 491 Request: 493 [ "getThreads", { 494 "ids": ["f123u4", "f41u44"], 495 }, "#1" ] 497 with response: 499 [ "threads", { 500 "accountId": "acme", 501 "state": "f6a7e214", 502 "list": [ 503 { 504 "id": "f123u4", 505 "messageIds": [ "eaa623", "f782cbb"] 506 }, 507 { 508 "id": "f41u44", 509 "messageIds": [ "82cf7bb" ] 510 } 511 ], 512 "notFound": null 513 }, "#1" ] 515 3.2. getThreadUpdates 517 Standard _getFooUpdates_ method. 519 4. Messages 521 A *Message* object is a JSON representation of an [RFC5322] message 522 that hides the complexities of MIME. All special encodings of either 523 headers or textual body parts, such as Base64 ([RFC4648]), or 524 [RFC2047] encoding of non-ASCII characters, MUST be fully decoded 525 into UTF-8. It has the following properties: 527 o *id*: "String" (immutable; server-set) The id of the message. 528 This is the JMAP id, NOT the [RFC5322] Message-Id header. 530 o *blobId*: "String" (immutable; server-set) The id representing the 531 raw [RFC5322] message. This may be used to download the original 532 message or to attach it directly to another message etc. 534 o *threadId*: "String" (immutable; server-set) The id of the thread 535 to which this message belongs. 537 o *mailboxIds*: "String[Boolean]" The set of mailbox ids this 538 message is in. A message MUST belong to one or more mailboxes at 539 all times (until it is deleted). The set is represented as an 540 object, with each key being a _Mailbox id_. The value for each key 541 in the object MUST be "true". 543 o *keywords*: "String[Boolean]" (default: "{}") A set of keywords 544 that apply to the message. The set is represented as an object, 545 with the keys being the _keywords_. The value for each key in the 546 object MUST be "true". Keywords are shared with IMAP. The six 547 system keywords from IMAP are treated specially. The following 548 four keywords have their first character changed from "\" in IMAP 549 to "$" in JMAP and have particular semantic meaning: 551 * "$Draft": The message is a draft the user is composing. 553 * "$Seen": The message has been read. 555 * "$Flagged": The message has been flagged for urgent/special 556 attention. 558 * "$Answered": The message has been replied to. 560 The IMAP "\Recent" keyword is not exposed via JMAP. The IMAP 561 "\Deleted" keyword is also not present: IMAP uses a delete+expunge 562 model, which JMAP does not. Any message with the "\Deleted" 563 keyword MUST NOT be visible via JMAP. Users may add arbitrary 564 keywords to a message. For compatibility with IMAP, a keyword is 565 a (case-sensitive) string of 1-255 characters in the ASCII subset 566 %x21-%x7e (excludes control chars and space), and MUST NOT include 567 any of these characters: "( ) { ] % * " \" The IANA Keyword 568 Registry [2] as established in [RFC5788] assigns semantic meaning 569 to some other keywords in common use. New keywords may be 570 established here in the future. In particular, note: 572 * "$Forwarded": The message has been forwarded. 574 * "$Phishing": The message is highly likely to be phishing. 575 Clients SHOULD warn users to take care when viewing this 576 message and disable links and attachments. 578 * "$Junk": The message is definitely spam. Clients SHOULD set 579 this flag when users report spam to help train automated spam- 580 detection systems. 582 * "$NotJunk": The message is definitely not spam. Clients SHOULD 583 set this flag when users indicate a message is legitimate, to 584 help train automated spam-detection systems. 586 o *hasAttachment*: "Boolean" (immutable; server-set) This is "true" 587 if and only if the _attachments_ property for the Message contains 588 at least one entry where _isInline_ is "false". 590 o *headers*: "String[String]" (immutable; default: "{}") A map of 591 lower-cased header name to (decoded) header value for all headers 592 in the message. For headers that occur multiple times (e.g. 593 "Received"), the values are concatenated with a single new line 594 ("\n") character in between each one. 596 o *sender*: "Emailer|null" (immutable; default: "null") An Emailer 597 object (see below) containing the name/email from the parsed 598 "Sender" header of the email. If the email doesn't have a 599 "Sender" header, this is "null". 601 o *from*: "Emailer[]|null" (immutable; default: "null") An array of 602 name/email objects (see below) representing the parsed "From" 603 header of the email, in the same order as they appear in the 604 header. If the email doesn't have a "From" header, this is 605 "null". If the header exists but does not have any content, the 606 response is an array of zero length. 608 o *to*: "Emailer[]|null" (immutable; default: "null") An array of 609 name/email objects (see below) representing the parsed "To" header 610 of the email, in the same order as they appear in the header. If 611 the email doesn't have a "To" header, this is "null". If the 612 header exists but does not have any content, the response is an 613 array of zero length. 615 o *cc*: "Emailer[]|null" (immutable; default: "null") An array of 616 name/email objects (see below) representing the parsed "Cc" header 617 of the email, in the same order as they appear in the header. If 618 the email doesn't have a "Cc" header, this is "null". If the 619 header exists but does not have any content, the response is an 620 array of zero length. 622 o *bcc*: "Emailer[]|null" (immutable; default: "null") An array of 623 name/email objects (see below) representing the parsed "Bcc" 624 header of the email. If the email doesn't have a "Bcc" header 625 (which will be true for most emails outside of the Sent mailbox), 626 this is "null". If the header exists but does not have any 627 content, the response is an array of zero length. 629 o *replyTo*: "Emailer[]|null" (immutable; default: "null") An array 630 of name/email objects (see below) representing the parsed "Reply- 631 To" header of the email, in the same order as they appear in the 632 header. If the email doesn't have a "Reply-To" header, this is 633 "null". If the header exists but does not have any content, the 634 response is an array of zero length. 636 o *subject*: "String" (immutable; default: """") The subject of the 637 message. If none, defaults to the empty string, not "null". 639 o *sentAt*: "Date" (immutable; default: time of creation on server) 640 The parsed date from the message's _Date_ header. 642 o *receivedAt*: "UTCDate" (immutable; default: time of creation on 643 server) The date the message was received by the message store. 644 This is the _internal date_ in IMAP. 646 o *size*: "Number" (immutable; server-set) The size in bytes of the 647 whole message as counted by the server towards the user's quota. 649 o *preview*: "String" (immutable; server-set) Up to 256 characters 650 of the beginning of a plain text version of the message body. 651 This is intended to be shown as a preview line on a mailbox 652 listing, and the server may choose to skip quoted sections or 653 salutations to return a more useful preview. 655 o *textBody*: "String" (immutable; default: """") The plain text 656 body part for the message. If there is only an HTML version of 657 the body, a plain text version MUST be generated from this; the 658 exact method of conversion in this case is not defined and is 659 server-specific. If there is neither a "text/plain" nor a "text/ 660 html" body part, this MUST be the empty string. 662 o *htmlBody*: "String|null" (immutable; default: "null") The HTML 663 body part for the message if present. 665 o *attachments*: "Attachment[]|null" (default: "null") An array of 666 attachment objects (see below) detailing all the attachments to 667 the message. 669 o *attachedMessages*: "String[Message]|null" (immutable; server-set) 670 An object mapping attachment id (as found in the "attachments" 671 property) to a *Message* object with the following properties, for 672 each [RFC5322] message attached to this one: 674 * headers 676 * from 678 * to 680 * cc 682 * bcc 684 * replyTo 686 * subject 688 * date 690 * textBody 692 * htmlBody 694 * attachments 696 * attachedMessages 698 This property is set by the server based on the _attachments_ 699 property. 701 An *Emailer* object has the following properties: 703 o *name*: "String" The name of the sender/recipient. If a name 704 cannot be extracted for an email, this property SHOULD be the 705 empty string. 707 o *email*: "String" The email address of the sender/recipient. This 708 MUST be of the form ""@"" If a "host" or even 709 "mailbox" cannot be extracted for an email, the empty string 710 SHOULD be used for this part (so the result MUST always still 711 contain an ""@"" character). 713 Group information and comments from the RFC 5322 header MUST be 714 discarded when converting into an Emailer object. 716 Example array of Emailer objects: 718 [ 719 {name:"Joe Bloggs", email:"joeb@example.com"}, 720 {name:"", email:"john@example.com"}, 721 {name:"John Smith", email: "john@"} 722 ] 724 An *Attachment* object has the following properties: 726 o *blobId*: "String" The id of the binary data. 728 o *type*: "String" The content-type of the attachment. 730 o *name*: "String|null" The full file name, e.g. 731 "myworddocument.doc", if available. 733 o *size*: "Number" The size, in bytes, of the attachment when fully 734 decoded (i.e. the number of bytes in the file the user would 735 download). 737 o *cid*: "String|null" The id used within the message body to 738 reference this attachment. This is only unique when paired with 739 the message id, and has no meaning without reference to that. 741 o *isInline*: "Boolean" True if the attachment is referenced by a 742 "cid:" link from within the HTML body of the message. 744 o *width*: "Number|null" (optional, server MAY omit if not 745 supported) The width (in px) of the image, if the attachment is an 746 image. 748 o *height*: "Number|null" (optional, server MAY omit if not 749 supported) The height (in px) of the image, if the attachment is 750 an image. 752 To add an attachment, the file must first be uploaded using the 753 standard upload mechanism; this will give the client a blobId that 754 may be used to identify the file. The "cid" property may be assigned 755 by the client, and is solely used for matching up with "cid:" 756 links inside the "htmlBody". 758 The following JMAP methods are supported: 760 4.1. getMessages 762 Standard _getFoos_ method, except the client may use the following 763 pseudo values in the _properties_ argument: 765 o *body*: If ""body"" is included in the list of requested 766 properties, it MUST be interpreted by the server as a request for 767 ""htmlBody"" if the message has an HTML part, or ""textBody"" 768 otherwise. 770 o *headers.property*: Instead of requesting all the headers (by 771 requesting the ""headers"" property, the client may specify the 772 particular headers it wants using the "headers.property-name" 773 syntax, e.g. ""headers.x-spam-score", "headers.x-spam-hits""). 774 The server MUST return a _headers_ property but with just the 775 requested headers in the object rather than all headers. If 776 ""headers"" is requested, the server MUST ignore the individual 777 header requests and just return all headers. If a requested 778 header is not present in the message, it MUST NOT be present in 779 the _headers_ object. Header names are case-insensitive. 781 4.1.1. Example 783 Request: 785 ["getMessages", { 786 "ids": [ "f123u456", "f123u457" ], 787 "properties": [ "threadId", "mailboxIds", "from", "subject", "date" ] 788 }, "#1"] 790 and response: 792 ["messages", { 793 "accountId": "abc", 794 "state": "41234123231", 795 "list": [ 796 { 797 id: "f123u457", 798 threadId: "ef1314a", 799 mailboxIds: { "f123": true }, 800 from: [{name: "Joe Bloggs", email: "joe@bloggs.com"}], 801 subject: "Dinner on Thursday?", 802 date: "2013-10-13T14:12:00Z" 803 } 804 ], 805 notFound: [ "f123u456" ] 806 }, "#1"] 808 4.2. getMessageUpdates 810 Standard _getFooUpdates_ method. 812 4.3. getMessageList 814 Standard _getFooList_ method, but with the following additional 815 arguments: 817 o *collapseThreads*: "Boolean" (default: "false") If "true", 818 messages in the same thread as a previous message in the list 819 (given the filter and sort order) will be removed from the list. 820 This means at most only one message will be included in the list 821 for any given thread. 823 4.3.1. Filtering 825 A *FilterOperator* object has the following properties: 827 o *operator*: "String" This MUST be one of the following strings: 828 "AND"/"OR"/"NOT": 830 * *AND*: all of the conditions must match for the filter to 831 match. 833 * *OR*: at least one of the conditions must match for the filter 834 to match. 836 * *NOT*: none of the conditions must match for the filter to 837 match. 839 o *conditions*: "(FilterCondition|FilterOperator)[]" The conditions 840 to evaluate against each message. 842 A *FilterCondition* object has the following properties, any of which 843 may be omitted: 845 o *inMailbox*: "String" A mailbox id. A message must be in this 846 mailbox to match the condition. 848 o *inMailboxOtherThan*: "String" A mailbox id. A message be in any 849 mailbox other than this one to match the condition. This is to 850 allow messages solely in trash/spam to be easily excluded from a 851 search. 853 o *before*: "UTCDate" The _receivedAt_ date of the message (as 854 returned on the Message object) must be before this date to match 855 the condition. 857 o *after*: "UTCDate" The _receivedAt_ date of the message (as 858 returned on the Message object) must be on or after this date to 859 match the condition. 861 o *minSize*: "Number" The size of the message in bytes (as returned 862 on the Message object) must be equal to or greater than this 863 number to match the condition. 865 o *maxSize*: "Number" The size of the message in bytes (as returned 866 on the Message object) must be less than this number to match the 867 condition. 869 o *allInThreadHaveKeyword*: "String" All messages (including this 870 one) in the same thread as this message must have the given 871 keyword to match the condition. 873 o *someInThreadHaveKeyword*: "String" At least one message (possibly 874 this one) in the same thread as this message must have the given 875 keyword to match the condition. 877 o *noneInThreadHaveKeyword*: "String" All messages (including this 878 one) in the same thread as this message must *not* have the given 879 keyword to match the condition. 881 o *hasKeyword*: "String" This message must have the given keyword to 882 match the condition. 884 o *notKeyword*: "String" This message must not have the given 885 keyword to match the condition. 887 o *hasAttachment*: "Boolean" The "hasAttachment" property of the 888 message must be identical to the value given to match the 889 condition. 891 o *text*: "String" Looks for the text in messages. The server 892 SHOULD look up text in the _from_, _to_, _cc_, _bcc_, _subject_, 893 _textBody_, _htmlBody_ or _attachments_ properties of the message. 894 The server MAY extend the search to any additional textual 895 property. 897 o *from*: "String" Looks for the text in the _from_ property of the 898 message. 900 o *to*: "String" Looks for the text in the _to_ property of the 901 message. 903 o *cc*: "String" Looks for the text in the _cc_ property of the 904 message. 906 o *bcc*: "String" Looks for the text in the _bcc_ property of the 907 message. 909 o *subject*: "String" Looks for the text in the _subject_ property 910 of the message. 912 o *body*: "String" Looks for the text in the _textBody_ or 913 _htmlBody_ property of the message. 915 o *attachments*: "String" Looks for the text in the attachments of 916 the message. Server MAY handle text extraction when possible for 917 the different kinds of media. 919 o *header*: "String[]" The array MUST contain either one or two 920 elements. The first element is the name of the header to match 921 against. The second (optional) element is the text to look for in 922 the header. If not supplied, the message matches simply if it 923 _has_ a header of the given name. 925 If zero properties are specified on the FilterCondition, the 926 condition MUST always evaluate to "true". If multiple properties are 927 specified, ALL must apply for the condition to be "true" (it is 928 equivalent to splitting the object into one-property conditions and 929 making them all the child of an AND filter operator). 931 The exact semantics for matching "String" fields is *deliberately not 932 defined* to allow for flexibility in indexing implementation, subject 933 to the following: 935 o Text SHOULD be matched in a case-insensitive manner. 937 o Text contained in either (but matched) single or double quotes 938 SHOULD be treated as a *phrase search*, that is a match is 939 required for that exact word or sequence of words, excluding the 940 surrounding quotation marks. Use "\"", "\'" and "\\" to match a 941 literal """, "'" and "\" respectively in a phrase. 943 o Outside of a phrase, white-space SHOULD be treated as dividing 944 separate tokens that may be searched for separately in the 945 message, but MUST all be present for the message to match the 946 filter. 948 o Tokens MAY be matched on a whole-word basis using stemming (so for 949 example a text search for "bus" would match "buses" but not 950 "business"). 952 o When searching inside the _htmlBody_ property, HTML tags and 953 attributes SHOULD be ignored. 955 4.3.2. Sorting 957 The following properties MUST be supported for sorting: 959 o *receivedAt* - The _receivedAt_ date as returned in the Message 960 object. 962 The following properties SHOULD be supported for sorting: 964 o *size* - The size as returned in the Message object. 966 o *from* - This is taken to be either the "name" part of the Emailer 967 object, or if none then the "email" part of the Emailer object 968 (see the definition of the from property in the Message object). 969 If still none, consider the value to be the empty string. 971 o *to* - This is taken to be either the "name" part of the *first* 972 Emailer object, or if none then the "email" part of the *first* 973 Emailer object (see the definition of the to property in the 974 Message object). If still none, consider the value to be the 975 empty string. 977 o *subject* - This is taken to be the subject of the Message with 978 any ignoring any leading "Fwd:"s or "Re:"s (case-insensitive 979 match). 981 o *sentAt* - The _sentAt_ property on the Message object. 983 o *hasKeyword:*"keyword" - This value MUST be considered "true" if 984 the message has the keyword, or "false" otherwise. 986 o *allInThreadHaveKeyword:*"keyword" - This value MUST be considered 987 "true" for the message if *all* of the messages in the same thread 988 (regardless of mailbox) have the keyword. 990 o *someInThreadHaveKeyword:*"keyword" - This value MUST be 991 considered "true" for the message if *any* of the messages in the 992 same thread (regardless of mailbox) have the keyword. 994 The server MAY support sorting based on other properties as well. A 995 client can discover which properties are supported by inspecting the 996 server's _capabilities_ object (see section 1). 998 Example sort: 1000 `[ "someInThreadHaveKeyword:$Flagged desc", "receivedAt desc" ] 1002 This would sort messages in flagged threads first (the thread is 1003 considered flagged if any message within it is flagged), and then in 1004 date order, newest first. If two messages have both identical 1005 flagged status and date, the order is server-dependent but must be 1006 stable. 1008 4.3.3. Thread collapsing 1010 When "collapseThreads == true", then after filtering and sorting the 1011 message list, the list is further winnowed by removing any messages 1012 for a thread id that has already been seen (when passing through the 1013 list sequentially). A thread will therefore only appear *once* in 1014 the "threadIds" list of the result, at the position of the first 1015 message in the list that belongs to the thread. 1017 4.3.4. Response 1019 The _messageList_ response has the following additional argument: 1021 o *collapseThreads*: "Boolean" The _collapseThreads_ value that was 1022 used when calculating the message list for this call. 1024 4.4. getMessageListUpdates 1026 Standard _getFooListUpdates_ method, with the following additional 1027 arguments: 1029 o *collapseThreads*: "Boolean" (default: "false") The 1030 _collapseThreads_ argument that was used with _getMessageList_. 1032 The _messageListUpdates_ response has the following additional 1033 arguments: 1035 o *collapseThreads*: "Boolean" The _collapseThreads_ value that was 1036 used when calculating the message list for this call. 1038 4.5. setMessages 1040 Standard _setFoos_ method. The _setMessages_ method encompasses: 1042 o Creating a draft message 1044 o Changing the flags of a message (unread/flagged status) 1046 o Adding/removing a message to/from mailboxes (moving a message) 1048 o Deleting messages 1049 When creating a message, the _headers_ property specifies extra 1050 headers to add in addition to any based off the parsed properties 1051 (like _from_/_to_/_subject_). The keys MUST only contain the 1052 characters a-z (lower-case only), 0-9 and hyphens. If a header is 1053 included that conflicts with one of the other properties on the 1054 Message object (e.g. _from_, _date_), the value in the _headers_ 1055 object MUST be ignored. 1057 The server MAY also choose to set additional headers. If not 1058 included, the server MUST generate and set a "Message-Id" header in 1059 conformance with [RFC5322] section 3.6.4. 1061 Other than making sure it conforms to the correct type, the server 1062 MUST NOT attempt to validate _from_/_to_/_cc_/_bcc_ (e.g. checking if 1063 an email address is valid) when creating a message. This is to 1064 ensure draft messages can be saved at any point. 1066 Destroying a message removes it from all mailboxes to which it 1067 belonged. To just delete a message to trash, simply change the 1068 "mailboxIds" property so it is now in the mailbox with "role == 1069 "trash"", and remove all other mailbox ids. 1071 When emptying the trash, clients SHOULD NOT destroy messages which 1072 are also in a mailbox other than trash. For those messages, they 1073 SHOULD just remove the Trash mailbox from the message. 1075 The following extra _SetError_ types are defined: 1077 For *create*: 1079 o "attachmentNotFound": At least one blob id given in an attachment 1080 doesn't exist. An extra _notFound_ property of type "String[]" 1081 MUST be included in the error object containing every _blobId_ 1082 referenced in _attachments_ that could not be found on the server. 1084 o "maxQuotaReached": The user has reached a server-defined limit on 1085 their message storage quota. 1087 For *update*: 1089 o "tooManyKeywords": The change to the message's keywords would 1090 exceed a server-defined maximum. 1092 4.6. importMessages 1094 The _importMessages_ method adds [RFC5322] messages to a user's set 1095 of messages. The messages must first be uploaded as a file using the 1096 standard upload mechanism. It takes the following arguments: 1098 o *accountId*: "String|null" The id of the account to use for this 1099 call. If "null", defaults to the primary account. 1101 o *messages*: "String[MessageImport]" A map of creation id (client 1102 specified) to MessageImport objects 1104 A *MessageImport* object has the following properties: 1106 o *blobId*: "String" The id representing the raw [RFC5322] message 1107 (see the file upload section). 1109 o *mailboxIds* "String[Boolean]" The ids of the mailbox(es) to 1110 assign this message to. At least one mailbox MUST be given. 1112 o *keywords*: "String[Boolean]" (default: "{}") The keywords to 1113 apply to the message. 1115 o *receivedAt*: "UTCDate" (default: time of import on server) The 1116 _receivedAt_ date to set on the message. 1118 Each message to import is considered an atomic unit which may succeed 1119 or fail individually. Importing successfully creates a new message 1120 object from the data reference by the blobId and applies the given 1121 mailboxes, keywords and receivedAt date. 1123 The server MAY forbid two messages with the same exact [RFC5322] 1124 content, or even just with the same [RFC5322] Message-Id, to coexist 1125 within an account. In this case, it should reject attempts to import 1126 a message considered a duplicate with an "alreadyExists" SetError. A 1127 _messageId_ property of type "String" MUST be included on the error 1128 object with the id of the existing message. 1130 If the _blobId_, _mailboxIds_, or _keywords_ properties are invalid 1131 (e.g. missing, wrong type, id not found), the server MUST reject the 1132 import with an "invalidProperties" SetError. 1134 If the message cannot be imported because it would take the account 1135 over quota, the import should be rejected with a "maxQuotaReached" 1136 SetError. 1138 If the blob referenced cannot be parsed as an [RFC5322] message, the 1139 server MUST reject the import with an "invalidMessage" SetError. 1141 The response to _importMessages_ is called _messagesImported_. It has 1142 the following arguments: 1144 o *accountId*: "String" The id of the account used for this call. 1146 o *created*: "String[Message]" A map of the creation id to an object 1147 containing the _id_, _blobId_, _threadId_ and _size_ properties 1148 for each successfully imported Message. 1150 o *notCreated*: "String[SetError]" A map of creation id to a 1151 SetError object for each Message that failed to be created. The 1152 possible errors are defined above. 1154 The following errors may be returned instead of the _messageImported_ 1155 response: 1157 "accountNotFound": Returned if an _accountId_ was explicitly included 1158 with the request, but it does not correspond to a valid account. 1160 "accountNotSupportedByMethod": Returned if the _accountId_ given 1161 corresponds to a valid account, but the account does not support this 1162 data type. 1164 "accountReadOnly": Returned if the account has "isReadOnly == true". 1166 "invalidArguments": Returned if one of the arguments is of the wrong 1167 type, or otherwise invalid. A "description" property MAY be present 1168 on the response object to help debug with an explanation of what the 1169 problem was. 1171 4.7. copyMessages 1173 The only way to move messages *between* two different accounts is to 1174 copy them using the _copyMessages_ method, then once the copy has 1175 succeeded, delete the original. It takes the following arguments: 1177 o *fromAccountId*: "String|null" The id of the account to copy 1178 messages from. If "null", defaults to the primary account. 1180 o *toAccountId*: "String|null" The id of the account to copy 1181 messages to. If "null", defaults to the primary account. 1183 o *messages*: "String[MessageCopy]" A map of _creation id_ to a 1184 MessageCopy object. 1186 A *MessageCopy* object has the following properties: 1188 o *messageId*: "String" The id of the message to be copied in the 1189 "from" account. 1191 o *mailboxIds*: "String[Boolean]" The ids of the mailboxes (in the 1192 "to" account) to add the copied message to. At least one mailbox 1193 MUST be given. 1195 o *keywords*: "String[Boolean]" (default: "{}") The _keywords_ 1196 property for the copy. 1198 o *receivedAt*: "UTCDate" (default: _receivedAt_ date of original) 1199 The _receivedAt_ date to set on the copy. 1201 The server MAY forbid two messages with the same exact [RFC5322] 1202 content, or even just with the same [RFC5322] Message-Id, to coexist 1203 within an account. If duplicates are allowed though, the "from" 1204 account may be the same as the "to" account to copy messages within 1205 an account. 1207 Each message copy is considered an atomic unit which may succeed or 1208 fail individually. Copying successfully MUST create a new message 1209 object, with separate ids and mutable properties (e.g. mailboxes and 1210 keywords) to the original message. 1212 The response to _copyMessages_ is called _messagesCopied_. It has the 1213 following arguments: 1215 o *fromAccountId*: "String" The id of the account messages were 1216 copied from. 1218 o *toAccountId*: "String" The id of the account messages were copied 1219 to. 1221 o *created*: "String[Message]|null" A map of the creation id to an 1222 object containing the _id_, _blobId_, _threadId_ and _size_ 1223 properties for each successfully copied Message. 1225 o *notCreated*: "String[SetError]|null" A map of creation id to a 1226 SetError object for each Message that failed to be copied, "null" 1227 if none. 1229 The *SetError* may be one of the following types: 1231 "alreadyExists": Returned if the server forbids duplicates and the 1232 message already exists in the target account. A _messageId_ property 1233 of type "String" MUST be included on the error object with the id of 1234 the existing message. 1236 "notFound": Returned if the _messageId_ given can't be found. 1238 "invalidProperties": Returned if the _mailboxIds_ or _keywords_ 1239 properties are invalid (e.g. missing, wrong type, id not found). 1241 "maxQuotaReached": Returned if the user has reached their mail quota 1242 so the message cannot be copied. 1244 The following errors may be returned instead of the _messagesCopied_ 1245 response: 1247 "fromAccountNotFound": Returned if a _fromAccountId_ was explicitly 1248 included with the request, but it does not correspond to a valid 1249 account. 1251 "toAccountNotFound": Returned if a _toAccountId_ was explicitly 1252 included with the request, but it does not correspond to a valid 1253 account. 1255 "fromAccountNoMail": Returned if the _fromAccountId_ given 1256 corresponds to a valid account, but does not contain any mail data. 1258 "toAccountNoMail": Returned if the _toAccountId_ given corresponds to 1259 a valid account, but does not contain any mail data. 1261 "accountReadOnly": Returned if the "to" account has "isReadOnly == 1262 true". 1264 "invalidArguments": Returned if one of the arguments is of the wrong 1265 type, or otherwise invalid. A "description" property MAY be present 1266 on the response object to help debug with an explanation of what the 1267 problem was. 1269 5. MessageSubmission 1271 The MessageSubmission object represents the submission of a message 1272 for delivery to one or more recipients. A *MessageSubmission* object 1273 has the following properties: 1275 o *id*: "String" (immutable; server-set) The id of the message 1276 submission. 1278 o *identityId*: "String" (immutable) The id of the identity to 1279 associate with this submission. 1281 o *messageId*: "String" (immutable) The id of the message to send. 1282 The message being sent does not have to be a draft, for example 1283 when "redirecting" an existing message to a different email 1284 address. 1286 o *threadId*: "String" (immutable; server-set) The thread id of the 1287 message to send. This is set by the server to the _threadId_ 1288 property of the message referenced by the _messageId_. 1290 o *envelope*: "Envelope|null" (immutable; default: "null") 1291 Information for use when sending via SMTP. An *Envelope* object 1292 has the following properties: 1294 * *mailFrom*: "Address" The email address to use as the return 1295 address in the SMTP submission, plus any parameters to pass 1296 with the MAIL FROM address. The JMAP server MAY allow the 1297 email to be the empty string. When a JMAP server performs a 1298 message submission, it MAY use the same id string for the 1299 [RFC3461] ENVID parameter and the MessageSubmission object id. 1300 Servers that do this MAY replace a client-provided value for 1301 ENVID with a server-provided value. 1303 * *rcptTo*: "Address[]" The email addresses to send the message 1304 to, and any RCPT TO parameters to pass with the recipient. 1306 An *Address* object has the following properties: 1308 * *email*: "String" The email address being represented by the 1309 object. This as a "Mailbox" as used in the Reverse-path or 1310 Foward-path of the MAIL FROM or RCPT TO command in [@!RFC5321 1312 * *parameters*: "Object|null" Any parameters to send with the 1313 email (either mail-parameter or rcpt-parameter as appropriate, 1314 as specified in [RFC5321]). If supplied, each key in the 1315 object is a parameter name, and the value either the parameter 1316 value (type "String") or if the parameter does not take a value 1317 then "null". For both name and value, any xtext or unitext 1318 encodings are removed ([RFC3461], [RFC6533]) and JSON string 1319 encoding applied. 1321 If the _envelope_ property is "null" or omitted on creation, the 1322 server MUST generate this from the referenced message as follows: 1324 * *mailFrom*: The email in the _Sender_ header, if present, 1325 otherwise the _From_ header, if present, and no parameters. If 1326 multiple addresses are present in one of these headers, or 1327 there is more than one _Sender_/_From_ header, the server 1328 SHOULD reject the message as invalid but otherwise MUST take 1329 the first email address in the last _Sender_/_From_ header in 1330 the [RFC5322] version of the message. If the address found 1331 from this is not allowed by the identity associated with this 1332 submission, the _email_ property from the identity MUST be used 1333 instead. 1335 * *rcptTo*: The deduplicated set of email addresses from the 1336 _To_, _Cc_ and _Bcc_ headers, if present, with no parameters 1337 for any of them. 1339 o *sendAt*: "UTCDate" (immutable; server-set) The date the message 1340 was/will be released for delivery. If the client successfully 1341 used [RFC4865] FUTURERELEASE with the message, this MUST be the 1342 time when the server will release the message; otherwise it MUST 1343 be the time the MessageSubmission was created. 1345 o *undoStatus*: "String" (server-set) This represents whether the 1346 submission may be canceled. This is server set and MUST be one of 1347 the following values: 1349 * "pending": It MAY be possible to cancel this submission. 1351 * "final": The message has been relayed to at least one recipient 1352 in a manner that cannot be recalled. It is no longer possible 1353 to cancel this submission. 1355 * "canceled": The message submission was canceled and will not be 1356 delivered to any recipient. 1358 On systems that do not support unsending, the value of this 1359 property will always be "final". On systems that do support 1360 canceling submission, it will start as "pending", and MAY 1361 transition to "final" when the server knows it definitely cannot 1362 recall the message, but MAY just remain "pending". If in pending 1363 state, a client can attempt to cancel the submission by setting 1364 this property to "canceled"; if the update succeeds, the 1365 submission was successfully canceled and the message has not been 1366 delivered to any of the original recipients. 1368 o *deliveryStatus*: "String[DeliveryStatus]|null" (server-set) This 1369 represents the delivery status for each of the message recipients, 1370 if known. This property MAY not be supported by all servers, in 1371 which case it will remain "null". Servers that support it SHOULD 1372 update the MessageSubmission object each time the status of any of 1373 the recipients changes, even if some recipients are still being 1374 retried. This value is a map from the email address of each 1375 recipient to a _DeliveryStatus_ object. A *DeliveryStatus* object 1376 has the following properties: 1378 * *smtpReply*: "String" The SMTP reply string returned for this 1379 recipient when the server last tried to relay the message, or 1380 in a later DSN response for the message. This SHOULD be the 1381 response to the RCPT TO stage, unless this was accepted and the 1382 message as a whole rejected at the end of the DATA stage, in 1383 which case the DATA stage reply SHOULD be used instead. Multi- 1384 line SMTP responses should be concatenated to a single string 1385 as follows: 1387 + The hyphen following the SMTP code on all but the last line 1388 is replaced with a space. 1390 + Any prefix in common with the first line is stripped from 1391 lines after the first. 1393 + CRLF is replaced by a space. 1395 For example: 1397 550-5.7.1 Our system has detected that this message is 1398 550 5.7.1 likely spam, sorry. 1400 would become: 1402 550 5.7.1 Our system has detected that this message is likely spam, sorry. 1404 For messages relayed via an alternative to SMTP, the server MAY 1405 generate a synthetic string representing the status instead. 1406 If it does this, the string MUST be of the following form: 1408 + A 3-digit SMTP reply code, as defined in [RFC5321], section 1409 4.2.3. 1411 + Then a single space character. 1413 + Then an SMTP Enhanced Mail System Status Code as defined in 1414 [RFC3463], with a registry defined in [RFC5248]. 1416 + Then a single space character. 1418 + Then an implementation-specific information string with a 1419 human readable explanation of the response. 1421 * *delivered*: "String" Represents whether the message has been 1422 successfully delivered to the recipient. This MUST be one of 1423 the following values: 1425 + "queued": The message is in a local mail queue and status 1426 will change once it exits the local mail queues. The 1427 _smtpReply_ property may still change. 1429 + "yes": The message was successfully delivered to the mailbox 1430 of the recipient. The _smtpReply_ property is final. 1432 + "no": Message delivery to the recipient permanently failed. 1433 The _smtpReply_ property is final. 1435 + "unknown": The final delivery status is unknown, (e.g. it 1436 was relayed to an external machine and no further 1437 information is available). The _smtpReply_ property may 1438 still change if a DSN arrives. 1440 Note, successful relaying to an external SMTP server SHOULD NOT 1441 be taken as an indication that the message has successfully 1442 reached the final mailbox. In this case though, the server MAY 1443 receive a DSN response, if requested. If a DSN is received for 1444 the recipient with Action equal to "delivered", as per 1445 [RFC3464] section 2.3.3, then the _delivered_ property SHOULD 1446 be set to "yes"; if the Action equals "failed", the property 1447 SHOULD be set to "no". Receipt of any other DSN SHOULD NOT 1448 affect this property. The server MAY also set this property 1449 based on other feedback channels. 1451 * *displayed*: "String" Represents whether the message has been 1452 displayed to the recipient. This MUST be one of the following 1453 values: 1455 + "unknown": The display status is unknown. This is the 1456 initial value. 1458 + "yes": The recipient's system claims the message content has 1459 been displayed to the recipient. Note, there is no 1460 guarantee that the recipient has noticed, read, or 1461 understood the content. 1463 If an MDN is received for this recipient with Disposition-Type 1464 (as per [RFC3798] section 3.2.6.2) equal to "displayed", this 1465 property SHOULD be set to "yes". The server MAY also set this 1466 property based on other feedback channels. 1468 o *dsnBlobIds*: "String[]" (server-set) A list of blob ids for DSNs 1469 received for this submission, in order of receipt, oldest first. 1471 o *mdnBlobIds*: "String[]" (server-set) A list of blob ids for MDNs 1472 received for this submission, in order of receipt, oldest first. 1474 JMAP servers MAY choose not to expose DSN and MDN responses as 1475 Message objects if they correlate to a MessageSubmission object. It 1476 SHOULD only do this if it exposes them in the _dsnBlobIds_ and 1477 _mdnblobIds_ fields instead, and expects the user to be using clients 1478 capable of fetching and displaying delivery status via the 1479 MessageSubmission object. 1481 For efficiency, a server MAY destroy MessageSubmission objects a 1482 certain amount of time after the message is successfully sent or it 1483 has finished retrying sending the message. For very basic SMTP 1484 proxies, this MAY be immediately after creation, as it has no way to 1485 assign a real id and return the information again if fetched later. 1487 The following JMAP methods are supported: 1489 5.1. getMessageSubmissions 1491 Standard _getFoos_ method. 1493 5.2. getMessageSubmissionUpdates 1495 Standard _getFooUpdates_ method. 1497 5.3. getMessageSubmissionList 1499 Standard _getFooList_ method. 1501 The *FilterCondition* object (optionally passed as the _filter_ 1502 argument) has the following properties, any of which may be omitted: 1504 o *messageIds*: "String[]" The MessageSubmission _messageId_ 1505 property must be in this list to match the condition. 1507 o *threadIds*: "String[]" The MessageSubmission _threadId_ property 1508 must be in this list to match the condition. 1510 o *undoStatus*: "String" The MessageSubmission _undoStatus_ property 1511 must be identical to the value given to match the condition. 1513 o *before*: "UTCDate" The _sendAt_ property of the MessageSubmission 1514 object must be before this date to match the condition. 1516 o *after*: "UTCDate" The _sendAt_ property of the MessageSubmission 1517 object must be after this date to match the condition. 1519 A MessageSubmission object matches the filter if and only if all of 1520 the given conditions given match. If zero properties are specified, 1521 it is automatically "true" for all objects. 1523 The following properties MUST be supported for sorting: 1525 o "messageId" 1527 o "threadId" 1529 o "sentAt" 1531 5.4. getMessageSubmissionListUpdates 1533 Standard _getFooListUpdates_ method. 1535 5.5. setMessageSubmissions 1537 Standard _setFoos_ method, with the following two extra arguments: 1539 o *onSuccessUpdateMessage*: "String[Message]|null" A map of 1540 _MessageSubmission id_ to an object containing properties to 1541 update on the Message object referenced by the MessageSubmission 1542 if the create/update/destroy succeeds. (For references to 1543 MessageSubmission creations, this is equivalent to a back 1544 reference so the id will be the creation id prefixed with a "#".) 1546 o *onSuccessDestroyMessage*: "String[]|null" A list of 1547 _MessageSubmission ids_ for which the message with the 1548 corresponding messageId should be destroyed if the create/update/ 1549 destroy succeeds. (For references to MessageSubmission creations, 1550 this is equivalent to a back reference so the id will be the 1551 creation id prefixed with a "#".) 1553 A single implicit _setMessages_ call MUST be made after all 1554 MessageSubmission create/update/destroy requests have been processed 1555 to perform any changes requested in these two arguments. The 1556 _messagesSet_ response MUST be returned after the 1557 _messageSubmissionsSet_ response. 1559 A message is sent by creating a MessageSubmission object. When 1560 processing each create, the server must check that the message is 1561 valid, and the user has sufficient authorization to send it. If the 1562 creation succeeds, the message will be sent to the recipients given 1563 in the envelope _rcptTo_ parameter. The server MUST remove any _Bcc_ 1564 header present on the message during delivery. The server MAY add or 1565 remove other headers from the submitted message, or make further 1566 alterations in accordance with the server's policy during delivery. 1568 If the referenced message is destroyed at any point after the 1569 MessageSubmission object is created, this MUST NOT change the 1570 behaviour of the message submission (i.e. it does not cancel a future 1571 send). 1573 Similarly, destroying a MessageSubmission object MUST NOT affect the 1574 deliveries it represents. It purely removes the record of the 1575 message submission. The server MAY automatically destroy 1576 MessageSubmission objects after a certain time or in response to 1577 other triggers, and MAY forbid the client from manually destroying 1578 MessageSubmission objects. 1580 The following extra _SetError_ types are defined: 1582 For *create*: 1584 o "tooLarge" - The message size is larger than the server supports. 1585 A _maxSize_ "Number" property MUST be present on the SetError 1586 specifying the maximum size of a message that may be sent, in 1587 bytes. 1589 o "tooManyRecipients" - The envelope (supplied or generated) has 1590 more recipients than the server allows. A _maxRecipients_ 1591 "Number" property MUST be present on the SetError specifying the 1592 maximum number of allowed recipients. 1594 o "noRecipients" - The envelope (supplied or generated) does not 1595 have any rcptTo emails. 1597 o "invalidRecipients" - The _rcptTo_ property of the envelope 1598 (supplied or generated) contains at least one rcptTo value which 1599 is not a valid email for sending to. An _invalidEmails_ 1600 "String[]" property MUST be present on the SetError, which is a 1601 list of the invalid emails. 1603 o "notPermittedFrom" - The server does not permit the user to send a 1604 message with the From header of the message to be sent. 1606 o "notPermittedToSend" - The user does not have permission to send 1607 at all right now for some reason. A _description_ "String" 1608 property MAY be present on the SetError object to display to the 1609 user why they are not permitted. 1611 o "messageNotFound" - The _messageId_ is not a valid id for a 1612 message in the account. 1614 o "invalidMessage" - The message to be sent is invalid in some way. 1615 The SetError SHOULD contain a property called _properties_ of type 1616 "String[]" that lists *all* the properties of the Message that 1617 were invalid. 1619 For *update*: 1621 o "cannotUnsend": The client attempted to update the _undoStatus_ of 1622 a valid MessageSubmission object from "pending" to "canceled", but 1623 the message cannot be unsent. 1625 For *destroy*: 1627 o "forbidden": The server does not allow clients to destroy 1628 MessageSubmission objects. 1630 6. Identities 1632 An *Identity* object stores information about an email address (or 1633 domain) the user may send from. It has the following properties: 1635 o *id*: "String" (immutable; server-set) The id of the identity. 1637 o *name*: "String" (default: """") The "From" _name_ the client 1638 SHOULD use when creating a new message from this identity. 1640 o *email*: "String" The "From" email address the client MUST use 1641 when creating a new message from this identity. This property is 1642 immutable. The "email" property MAY alternatively be of the form 1643 "*@example.com", in which case the client may use any valid email 1644 address ending in "@example.com". 1646 o *replyTo*: "Emailer[]|null" (default: "null") The Reply-To value 1647 the client SHOULD set when creating a new message from this 1648 identity. 1650 o *bcc*: "Emailer[]|null" (default: "null") The Bcc value the client 1651 SHOULD set when creating a new message from this identity. 1653 o *textSignature*: "String" (default: """") Signature the client 1654 SHOULD insert into new plain-text messages that will be sent from 1655 this identity. Clients MAY ignore this and/or combine this with a 1656 client-specific signature preference. 1658 o *htmlSignature*: "String" (default: """") Signature the client 1659 SHOULD insert into new HTML messages that will be sent from this 1660 identity. This text MUST be an HTML snippet to be inserted into 1661 the "" section of the new email. Clients MAY ignore 1662 this and/or combine this with a client-specific signature 1663 preference. 1665 o *mayDelete*: "Boolean" (server-set) Is the user allowed to delete 1666 this identity? Servers may wish to set this to "false" for the 1667 user's username or other default address. 1669 Multiple identities with the same email address MAY exist, to allow 1670 for different settings the user wants to pick between (for example 1671 with different names/signatures). 1673 The following JMAP methods are supported: 1675 6.1. getIdentities 1677 Standard _getFoos_ method. The _ids_ argument may be "null" to fetch 1678 all at once. 1680 6.2. getIdentityUpdates 1682 Standard _getFooUpdates_ method. 1684 6.3. setIdentities 1686 Standard _setFoos_ method. The following extra _SetError_ types are 1687 defined: 1689 For *create*: 1691 o "maxQuotaReached": The user has reached a server-defined limit on 1692 the number of identities. 1694 o "emailNotPermitted": The user is not allowed to send from the 1695 address given as the _email_ property of the identity. 1697 For *destroy*: 1699 o "forbidden": Returned if the identity's _mayDelete_ value is 1700 "false". 1702 7. SearchSnippets 1704 When doing a search on a "String" property, the client may wish to 1705 show the relevant section of the body that matches the search as a 1706 preview instead of the beginning of the message, and to highlight any 1707 matching terms in both this and the subject of the message. Search 1708 snippets represent this data. 1710 A *SearchSnippet* object has the following properties: 1712 o *messageId*: "String" The message id the snippet applies to. 1714 o *subject*: "String|null" If text from the filter matches the 1715 subject, this is the subject of the message HTML-escaped, with 1716 matching words/phrases wrapped in "" tags. If it 1717 does not match, this is "null". 1719 o *preview*: "String|null" If text from the filter matches the 1720 plain-text or HTML body, this is the relevant section of the body 1721 (converted to plain text if originally HTML), HTML-escaped, with 1722 matching words/phrases wrapped in "" tags, up to 256 1723 characters long. If it does not match, this is "null". 1725 o *attachments*: "String|null" If text from the filter matches the 1726 text extracted from an attachment, this is the relevant section of 1727 the attachment (converted to plain text), with matching words/ 1728 phrases wrapped in "" tags, up to 256 characters 1729 long. If it does not match, this is "null". 1731 It is server-defined what is a relevant section of the body for 1732 preview. If the server is unable to determine search snippets, it 1733 MUST return "null" for both the _subject_, _preview_ and 1734 _attachments_ properties. 1736 Note, unlike most data types, a SearchSnippet DOES NOT have a 1737 property called "id". 1739 The following JMAP method is supported: 1741 7.1. getSearchSnippets 1743 To fetch search snippets, make a call to "getSearchSnippets". It 1744 takes the following arguments: 1746 o *accountId*: "String|null" The id of the account to use for this 1747 call. If "null", defaults to the primary account. 1749 o *messageIds*: "String[]" The list of ids of messages to fetch the 1750 snippets for. 1752 o *filter*: "FilterCondition|FilterOperator|null" The same filter as 1753 passed to getMessageList; see the description of this method for 1754 details. 1756 The response to "getSearchSnippets" is called "searchSnippets". It 1757 has the following arguments: 1759 o *accountId*: "String" The id of the account used for the call. 1761 o *filter*: "FilterCondition|FilterOperator|null" Echoed back from 1762 the call. 1764 o *list*: "SearchSnippet[]" An array of SearchSnippet objects for 1765 the requested message ids. This may not be in the same order as 1766 the ids that were in the request. 1768 o *notFound*: "String[]|null" An array of message ids requested 1769 which could not be found, or "null" if all ids were found. 1771 Since snippets are only based on immutable properties, there is no 1772 state string or update mechanism needed. 1774 The following errors may be returned instead of the _searchSnippets_ 1775 response: 1777 "accountNotFound": Returned if an _accountId_ was explicitly included 1778 with the request, but it does not correspond to a valid account. 1780 "accountNotSupportedByMethod": Returned if the _accountId_ given 1781 corresponds to a valid account, but the account does not support this 1782 data type. 1784 "requestTooLarge": Returned if the number of _messageIds_ requested 1785 by the client exceeds the maximum number the server is willing to 1786 process in a single method call. 1788 "cannotDoFilter": Returned if the server is unable to process the 1789 given _filter_ for any reason. 1791 "invalidArguments": Returned if the request does not include one of 1792 the required arguments, or one of the arguments is of the wrong type, 1793 or otherwise invalid. A "description" property MAY be present on the 1794 response object to help debug with an explanation of what the problem 1795 was. 1797 8. Vacation Response 1799 The *VacationResponse* object represents the state of vacation- 1800 response related settings for an account. It has the following 1801 properties: 1803 o *id*: "String" (immutable) The id of the object. There is only 1804 ever one vacation response object, and its id is ""singleton"". 1806 o *isEnabled* "Boolean" Should a vacation response be sent if a 1807 message arrives between the _fromDate_ and _toDate_? 1809 o *fromDate*: "UTCDate|null" If _isEnabled_ is "true", the date/time 1810 after which messages that arrive should receive the user's 1811 vacation response, in UTC. If "null", the vacation response is 1812 effective immediately. 1814 o *toDate*: "UTCDate|null" If _isEnabled_ is "true", the date/time 1815 after which messages that arrive should no longer receive the 1816 user's vacation response, in UTC. If "null", the vacation 1817 response is effective indefinitely. 1819 o *subject*: "String|null" The subject that will be used by the mail 1820 sent in response to messages when the vacation response is 1821 enabled. If null, an appropriate subject SHOULD be set by the 1822 server. 1824 o *textBody*: "String|null" The plain text part of the message to 1825 send in response to messages when the vacation response is 1826 enabled. If this is "null", when the vacation message is sent a 1827 plain-text body part SHOULD be generated from the _htmlBody_ but 1828 the server MAY choose to send the response as HTML only. 1830 o *htmlBody*: "String|null" The HTML message to send in response to 1831 messages when the vacation response is enabled. If this is 1832 "null", when the vacation message is sent an HTML body part MAY be 1833 generated from the _textBody_, or the server MAY choose to send 1834 the response as plain-text only. 1836 The following JMAP methods are supported: 1838 8.1. getVacationResponse 1840 Standard _getFoos_ method. 1842 There MUST only be exactly one VacationResponse object in an account. 1843 It MUST have the id ""singleton"". 1845 8.2. setVacationResponse 1847 Standard _setFoos_ method. The following extra _SetError_ types are 1848 defined: 1850 For *create* or *destroy*: 1852 o "singleton": This is a singleton object, so you cannot create 1853 another one or destroy the existing one. 1855 9. Security considerations 1857 All security considerations of JMAP {TODO: insert RFC ref} apply to 1858 this specification. 1860 10. References 1862 10.1. Normative References 1864 [RFC1870] Klensin, J., Freed, N., and K. Moore, "SMTP Service 1865 Extension for Message Size Declaration", STD 10, RFC 1870, 1866 DOI 10.17487/RFC1870, November 1995, 1867 . 1869 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 1870 Part Three: Message Header Extensions for Non-ASCII Text", 1871 RFC 2047, DOI 10.17487/RFC2047, November 1996, 1872 . 1874 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1875 Requirement Levels", BCP 14, RFC 2119, 1876 DOI 10.17487/RFC2119, March 1997, 1877 . 1879 [RFC2852] Newman, D., "Deliver By SMTP Service Extension", RFC 2852, 1880 DOI 10.17487/RFC2852, June 2000, 1881 . 1883 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 1884 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 1885 . 1887 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 1888 Extension for Delivery Status Notifications (DSNs)", 1889 RFC 3461, DOI 10.17487/RFC3461, January 2003, 1890 . 1892 [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", 1893 RFC 3463, DOI 10.17487/RFC3463, January 2003, 1894 . 1896 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format 1897 for Delivery Status Notifications", RFC 3464, 1898 DOI 10.17487/RFC3464, January 2003, 1899 . 1901 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1902 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 1903 2003, . 1905 [RFC3798] Hansen, T., Ed. and G. Vaudreuil, Ed., "Message 1906 Disposition Notification", RFC 3798, DOI 10.17487/RFC3798, 1907 May 2004, . 1909 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1910 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 1911 . 1913 [RFC4865] White, G. and G. Vaudreuil, "SMTP Submission Service 1914 Extension for Future Message Release", RFC 4865, 1915 DOI 10.17487/RFC4865, May 2007, 1916 . 1918 [RFC5248] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced 1919 Mail System Status Codes", BCP 138, RFC 5248, 1920 DOI 10.17487/RFC5248, June 2008, 1921 . 1923 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 1924 DOI 10.17487/RFC5321, October 2008, 1925 . 1927 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 1928 DOI 10.17487/RFC5322, October 2008, 1929 . 1931 [RFC5788] Melnikov, A. and D. Cridland, "IMAP4 Keyword Registry", 1932 RFC 5788, DOI 10.17487/RFC5788, March 2010, 1933 . 1935 [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", 1936 STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011, 1937 . 1939 [RFC6533] Hansen, T., Ed., Newman, C., and A. Melnikov, 1940 "Internationalized Delivery Status and Disposition 1941 Notifications", RFC 6533, DOI 10.17487/RFC6533, February 1942 2012, . 1944 [RFC6710] Melnikov, A. and K. Carlberg, "Simple Mail Transfer 1945 Protocol Extension for Message Transfer Priorities", 1946 RFC 6710, DOI 10.17487/RFC6710, August 2012, 1947 . 1949 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1950 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 1951 2014, . 1953 [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, 1954 DOI 10.17487/RFC7493, March 2015, 1955 . 1957 10.2. URIs 1959 [1] server.html 1961 [2] https://www.iana.org/assignments/imap-keywords/imap- 1962 keywords.xhtml 1964 Author's Address 1966 Neil Jenkins 1967 FastMail 1968 Level 2, 114 William St 1969 Melbourne VIC 3000 1970 Australia 1972 Email: neilj@fastmailteam.com 1973 URI: https://www.fastmail.com