draft-ietf-jmap-mail-12.txt   draft-ietf-jmap-mail-13.txt 
JMAP N. Jenkins JMAP N. Jenkins
Internet-Draft FastMail Internet-Draft FastMail
Updates: 5788 (if approved) C. Newman Updates: 5788 (if approved) C. Newman
Intended status: Standards Track Oracle Intended status: Standards Track Oracle
Expires: June 6, 2019 December 3, 2018 Expires: July 19, 2019 January 15, 2019
JMAP for Mail JMAP for Mail
draft-ietf-jmap-mail-12 draft-ietf-jmap-mail-13
Abstract Abstract
This document specifies a data model for synchronising email data This document specifies a data model for synchronising email data
with a server using JMAP. Clients can use this to efficiently with a server using JMAP. Clients can use this to efficiently
search, access, organise and send messages, and get pushed search, access, organise and send messages, and get pushed
notifications for fast resynchronisation when new messages are notifications for fast resynchronisation when new messages are
delivered or a change is made in another client. delivered or a change is made in another client.
Status of This Memo Status of This Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 6, 2019. This Internet-Draft will expire on July 19, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 17 skipping to change at page 2, line 17
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Notational conventions . . . . . . . . . . . . . . . . . 4 1.1. Notational conventions . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Additions to the capabilities object . . . . . . . . . . 4 1.3. Additions to the capabilities object . . . . . . . . . . 4
1.3.1. urn:ietf:params:jmap:mail . . . . . . . . . . . . . . 4 1.3.1. urn:ietf:params:jmap:mail . . . . . . . . . . . . . . 4
1.3.2. urn:ietf:params:jmap:submission . . . . . . . . . . . 5 1.3.2. urn:ietf:params:jmap:submission . . . . . . . . . . . 5
1.3.3. urn:ietf:params:jmap:vacationresponse . . . . . . . . 6 1.3.3. urn:ietf:params:jmap:vacationresponse . . . . . . . . 6
1.4. Data type support in different accounts . . . . . . . . . 6 1.4. Data type support in different accounts . . . . . . . . . 6
1.5. Push . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.5. Push . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5.1. Example . . . . . . . . . . . . . . . . . . . . . . . 7
1.6. Ids . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.6. Ids . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2. Mailboxes . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Mailboxes . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Mailbox/get . . . . . . . . . . . . . . . . . . . . . . . 10 2.1. Mailbox/get . . . . . . . . . . . . . . . . . . . . . . . 11
2.2. Mailbox/changes . . . . . . . . . . . . . . . . . . . . . 10 2.2. Mailbox/changes . . . . . . . . . . . . . . . . . . . . . 11
2.3. Mailbox/query . . . . . . . . . . . . . . . . . . . . . . 11 2.3. Mailbox/query . . . . . . . . . . . . . . . . . . . . . . 11
2.4. Mailbox/queryChanges . . . . . . . . . . . . . . . . . . 12 2.4. Mailbox/queryChanges . . . . . . . . . . . . . . . . . . 12
2.5. Mailbox/set . . . . . . . . . . . . . . . . . . . . . . . 12 2.5. Mailbox/set . . . . . . . . . . . . . . . . . . . . . . . 12
2.6. Example . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.6. Example . . . . . . . . . . . . . . . . . . . . . . . . . 13
3. Threads . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3. Threads . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1. Thread/get . . . . . . . . . . . . . . . . . . . . . . . 17 3.1. Thread/get . . . . . . . . . . . . . . . . . . . . . . . 18
3.1.1. Example . . . . . . . . . . . . . . . . . . . . . . . 17 3.1.1. Example . . . . . . . . . . . . . . . . . . . . . . . 18
3.2. Thread/changes . . . . . . . . . . . . . . . . . . . . . 17 3.2. Thread/changes . . . . . . . . . . . . . . . . . . . . . 18
4. Emails . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4. Emails . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1. Properties of the Email object . . . . . . . . . . . . . 18 4.1. Properties of the Email object . . . . . . . . . . . . . 19
4.1.1. Metadata . . . . . . . . . . . . . . . . . . . . . . 19 4.1.1. Metadata . . . . . . . . . . . . . . . . . . . . . . 20
4.1.2. Header fields parsed forms . . . . . . . . . . . . . 21 4.1.2. Header fields parsed forms . . . . . . . . . . . . . 22
4.1.3. Header fields properties . . . . . . . . . . . . . . 26 4.1.3. Header fields properties . . . . . . . . . . . . . . 27
4.1.4. Body parts . . . . . . . . . . . . . . . . . . . . . 28 4.1.4. Body parts . . . . . . . . . . . . . . . . . . . . . 29
4.2. Email/get . . . . . . . . . . . . . . . . . . . . . . . . 34 4.2. Email/get . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2.1. Example . . . . . . . . . . . . . . . . . . . . . . . 36 4.2.1. Example . . . . . . . . . . . . . . . . . . . . . . . 37
4.3. Email/changes . . . . . . . . . . . . . . . . . . . . . . 37 4.3. Email/changes . . . . . . . . . . . . . . . . . . . . . . 38
4.4. Email/query . . . . . . . . . . . . . . . . . . . . . . . 38 4.4. Email/query . . . . . . . . . . . . . . . . . . . . . . . 39
4.4.1. Filtering . . . . . . . . . . . . . . . . . . . . . . 38 4.4.1. Filtering . . . . . . . . . . . . . . . . . . . . . . 39
4.4.2. Sorting . . . . . . . . . . . . . . . . . . . . . . . 40 4.4.2. Sorting . . . . . . . . . . . . . . . . . . . . . . . 41
4.4.3. Thread collapsing . . . . . . . . . . . . . . . . . . 42 4.4.3. Thread collapsing . . . . . . . . . . . . . . . . . . 43
4.5. Email/queryChanges . . . . . . . . . . . . . . . . . . . 42 4.5. Email/queryChanges . . . . . . . . . . . . . . . . . . . 43
4.6. Email/set . . . . . . . . . . . . . . . . . . . . . . . . 42 4.6. Email/set . . . . . . . . . . . . . . . . . . . . . . . . 43
4.7. Email/copy . . . . . . . . . . . . . . . . . . . . . . . 45 4.7. Email/copy . . . . . . . . . . . . . . . . . . . . . . . 46
4.8. Email/import . . . . . . . . . . . . . . . . . . . . . . 45 4.8. Email/import . . . . . . . . . . . . . . . . . . . . . . 46
4.9. Email/parse . . . . . . . . . . . . . . . . . . . . . . . 47 4.9. Email/parse . . . . . . . . . . . . . . . . . . . . . . . 48
4.10. Examples . . . . . . . . . . . . . . . . . . . . . . . . 49 4.10. Examples . . . . . . . . . . . . . . . . . . . . . . . . 50
5. Search snippets . . . . . . . . . . . . . . . . . . . . . . . 56 5. Search snippets . . . . . . . . . . . . . . . . . . . . . . . 57
5.1. SearchSnippet/get . . . . . . . . . . . . . . . . . . . . 57 5.1. SearchSnippet/get . . . . . . . . . . . . . . . . . . . . 58
5.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 58 5.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 59
6. Identities . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.1. Identity/get . . . . . . . . . . . . . . . . . . . . . . 61
6.2. Identity/changes . . . . . . . . . . . . . . . . . . . . 61
6.3. Identity/set . . . . . . . . . . . . . . . . . . . . . . 61
6.4. Example . . . . . . . . . . . . . . . . . . . . . . . . . 62
7. Email submission . . . . . . . . . . . . . . . . . . . . . . 62
7.1. EmailSubmission/get . . . . . . . . . . . . . . . . . . . 67
7.2. EmailSubmission/changes . . . . . . . . . . . . . . . . . 67
7.3. EmailSubmission/query . . . . . . . . . . . . . . . . . . 67
7.4. EmailSubmission/queryChanges . . . . . . . . . . . . . . 68
7.5. EmailSubmission/set . . . . . . . . . . . . . . . . . . . 68
7.5.1. Example . . . . . . . . . . . . . . . . . . . . . . . 70
8. Vacation response . . . . . . . . . . . . . . . . . . . . . . 73
8.1. VacationResponse/get . . . . . . . . . . . . . . . . . . 74
8.2. VacationResponse/set . . . . . . . . . . . . . . . . . . 74
9. Security considerations . . . . . . . . . . . . . . . . . . . 74
9.1. EmailBodyPart value . . . . . . . . . . . . . . . . . . . 74
9.2. HTML email display . . . . . . . . . . . . . . . . . . . 74
9.3. Email submission . . . . . . . . . . . . . . . . . . . . 77
10. IANA considerations . . . . . . . . . . . . . . . . . . . . . 77
10.1. JMAP capability registration for "mail" . . . . . . . . 77
10.2. JMAP capability registration for "submission" . . . . . 78
10.3. JMAP capability registration for "vacationresponse" . . 78
10.4. IMAP and JMAP keywords registry . . . . . . . . . . . . 78
10.4.1. Registration of JMAP keyword '$draft' . . . . . . . 79
10.4.2. Registration of JMAP keyword '$seen' . . . . . . . . 80
10.4.3. Registration of JMAP keyword '$flagged' . . . . . . 81
10.4.4. Registration of JMAP keyword '$answered' . . . . . . 81
10.4.5. Registration of '$recent' keyword . . . . . . . . . 82
10.5. Registration of "inbox" role in . . . . . . . . . . . . 83
10.6. JMAP Error Codes registry . . . . . . . . . . . . . . . 83
10.6.1. mailboxHasChild . . . . . . . . . . . . . . . . . . 83
10.6.2. mailboxHasEmail . . . . . . . . . . . . . . . . . . 83
10.6.3. blobNotFound . . . . . . . . . . . . . . . . . . . . 84
10.6.4. tooManyKeywords . . . . . . . . . . . . . . . . . . 84
10.6.5. tooManyMailboxes . . . . . . . . . . . . . . . . . . 84
10.6.6. invalidEmail . . . . . . . . . . . . . . . . . . . . 84
10.6.7. tooManyRecipients . . . . . . . . . . . . . . . . . 84
10.6.8. noRecipients . . . . . . . . . . . . . . . . . . . . 85
10.6.9. invalidRecipients . . . . . . . . . . . . . . . . . 85
10.6.10. forbiddenMailFrom . . . . . . . . . . . . . . . . . 85
10.6.11. forbiddenFrom . . . . . . . . . . . . . . . . . . . 85
10.6.12. forbiddenToSend . . . . . . . . . . . . . . . . . . 85
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 86
11.1. Normative References . . . . . . . . . . . . . . . . . . 86
11.2. Informative References . . . . . . . . . . . . . . . . . 89
11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6. Identities . . . . . . . . . . . . . . . . . . . . . . . . . 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 90
6.1. Identity/get . . . . . . . . . . . . . . . . . . . . . . 60
6.2. Identity/changes . . . . . . . . . . . . . . . . . . . . 60
6.3. Identity/set . . . . . . . . . . . . . . . . . . . . . . 60
6.4. Example . . . . . . . . . . . . . . . . . . . . . . . . . 60
7. Email submission . . . . . . . . . . . . . . . . . . . . . . 61
7.1. EmailSubmission/get . . . . . . . . . . . . . . . . . . . 66
7.2. EmailSubmission/changes . . . . . . . . . . . . . . . . . 66
7.3. EmailSubmission/query . . . . . . . . . . . . . . . . . . 66
7.4. EmailSubmission/queryChanges . . . . . . . . . . . . . . 67
7.5. EmailSubmission/set . . . . . . . . . . . . . . . . . . . 67
7.5.1. Example . . . . . . . . . . . . . . . . . . . . . . . 69
8. Vacation response . . . . . . . . . . . . . . . . . . . . . . 70
8.1. VacationResponse/get . . . . . . . . . . . . . . . . . . 71
8.2. VacationResponse/set . . . . . . . . . . . . . . . . . . 71
9. Security considerations . . . . . . . . . . . . . . . . . . . 72
9.1. EmailBodyPart value . . . . . . . . . . . . . . . . . . . 72
9.2. HTML email display . . . . . . . . . . . . . . . . . . . 72
9.3. Email submission . . . . . . . . . . . . . . . . . . . . 74
10. IANA considerations . . . . . . . . . . . . . . . . . . . . . 75
10.1. JMAP capability registration for "mail" . . . . . . . . 75
10.2. JMAP capability registration for "submission" . . . . . 75
10.3. JMAP capability registration for "vacationresponse" . . 76
10.4. IMAP and JMAP keywords registry . . . . . . . . . . . . 76
10.4.1. Registration of JMAP keyword '$draft' . . . . . . . 77
10.4.2. Registration of JMAP keyword '$seen' . . . . . . . . 78
10.4.3. Registration of JMAP keyword '$flagged' . . . . . . 78
10.4.4. Registration of JMAP keyword '$answered' . . . . . . 79
10.4.5. Registration of '$recent' keyword . . . . . . . . . 80
10.5. Registration of "inbox" role in . . . . . . . . . . . . 81
10.6. JMAP Error Codes registry . . . . . . . . . . . . . . . 81
10.6.1. mailboxHasChild . . . . . . . . . . . . . . . . . . 81
10.6.2. mailboxHasEmail . . . . . . . . . . . . . . . . . . 81
10.6.3. blobNotFound . . . . . . . . . . . . . . . . . . . . 81
10.6.4. tooManyKeywords . . . . . . . . . . . . . . . . . . 82
10.6.5. tooManyMailboxes . . . . . . . . . . . . . . . . . . 82
10.6.6. invalidEmail . . . . . . . . . . . . . . . . . . . . 82
10.6.7. tooManyRecipients . . . . . . . . . . . . . . . . . 82
10.6.8. noRecipients . . . . . . . . . . . . . . . . . . . . 82
10.6.9. invalidRecipients . . . . . . . . . . . . . . . . . 83
10.6.10. forbiddenMailFrom . . . . . . . . . . . . . . . . . 83
10.6.11. forbiddenFrom . . . . . . . . . . . . . . . . . . . 83
10.6.12. forbiddenToSend . . . . . . . . . . . . . . . . . . 83
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 83
11.1. Normative References . . . . . . . . . . . . . . . . . . 84
11.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 87
1. Introduction 1. Introduction
JMAP (RFC XXXX) is a generic protocol for synchronising data, such as JMAP ([I-D.ietf-jmap-core]) is a generic protocol for synchronising
mail, calendars or contacts, between a client and a server. It is data, such as mail, calendars or contacts, between a client and a
optimised for mobile and web environments, and aims to provide a server. It is optimised for mobile and web environments, and aims to
consistent interface to different data types. provide a consistent interface to different data types.
This specification defines a data model for mail over JMAP. This specification defines a data model for mail over JMAP.
1.1. Notational conventions 1.1. Notational conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Type signatures, examples and property descriptions in this document Type signatures, examples and property descriptions in this document
follow the conventions established in Section 1.1 of RFC XXXX. Data follow the conventions established in section 1.1 of
types defined in the core specification are also used in this [I-D.ietf-jmap-core]. Data types defined in the core specification
document. are also used in this document.
1.2. Terminology 1.2. Terminology
The same terminology is used in this document as in the core JMAP The same terminology is used in this document as in the core JMAP
specification. specification.
1.3. Additions to the capabilities object 1.3. Additions to the capabilities object
The capabilities object is returned as part of the standard JMAP The capabilities object is returned as part of the standard JMAP
Session object; see RFC XXXX, section 2. Session object; see [I-D.ietf-jmap-core], section 2.
This document defines three additional capability URIs. This document defines three additional capability URIs.
1.3.1. urn:ietf:params:jmap:mail 1.3.1. urn:ietf:params:jmap:mail
This represents support for the Mailbox, Thread, Email, and This represents support for the Mailbox, Thread, Email, and
SearchSnippet data types and associated API methods. The value of SearchSnippet data types and associated API methods. The value of
this property is an object which MUST contain the following this property is an object which MUST contain the following
information on server capabilities: information on server capabilities:
skipping to change at page 7, line 5 skipping to change at page 7, line 11
Mailbox/Thread/Email data in the shared account but are not allowed Mailbox/Thread/Email data in the shared account but are not allowed
to send as that account (and so do not have access to Identity/ to send as that account (and so do not have access to Identity/
MessageSubmission objects) or view/set its vacation response. MessageSubmission objects) or view/set its vacation response.
1.5. Push 1.5. Push
Servers MUST support the standard JMAP push mechanisms to receive Servers MUST support the standard JMAP push mechanisms to receive
notifications when the state changes for any of the types defined in notifications when the state changes for any of the types defined in
this specification. this specification.
In addition, servers MUST support a psuedo-type called In addition, servers MUST support pushing state changes for a type
"EmailDelivery" in the push mechanisms. The state string for this called "EmailDelivery". There are no methods to act on this type; it
only exists as part of the push mechanism. The state string for this
MUST change whenever a new Email is added to the store, but SHOULD MUST change whenever a new Email is added to the store, but SHOULD
NOT change upon any other change to the Email objects. NOT change upon any other change to the Email objects, for example if
one is marked as read or deleted.
Clients in battery constrained environments may wish to delay Clients in battery constrained environments may wish to delay
fetching changes initiated by the user, but fetch new messages fetching changes initiated by the user, but fetch new messages
immediately so they can notify the user. immediately so they can notify the user. To do this, they can
register for pushes for the EmailDelivery type rather than the Email
type (defined in section 4).
1.5.1. Example
The client has registered for push notifications (see
[I-D.ietf-jmap-core]) just for the "EmailDelivery" type. The user
marks an email as read on another device, causing the state string
for the "Email" type to change, however as nothing new was added to
the store the "EmailDelivery" state does not change and nothing is
pushed to the client. A new message arrives in the user's inbox,
again causing the "Email" state to change. This time the
"EmailDelivery" state also changes, and a StateChange object is
pushed to the client with the new state string. The client may then
resync to fetch the new message immediately.
1.6. Ids 1.6. Ids
If a JMAP Mail server also provides an IMAP interface to the data and If a JMAP Mail server also provides an IMAP interface to the data and
supports [RFC8474] IMAP Extension for Object Identifiers, the ids supports [RFC8474] IMAP Extension for Object Identifiers, the ids
SHOULD be the same for mailbox, thread, and email objects in JMAP. SHOULD be the same for mailbox, thread, and email objects in JMAP.
2. Mailboxes 2. Mailboxes
A mailbox represents a named set of emails. This is the primary A mailbox represents a named set of emails. This is the primary
skipping to change at page 7, line 38 skipping to change at page 8, line 12
mailboxes. The email id does not change if the email changes mailboxes. The email id does not change if the email changes
mailboxes. mailboxes.
A *Mailbox* object has the following properties: A *Mailbox* object has the following properties:
o *id*: "Id" (immutable; server-set) The id of the mailbox. o *id*: "Id" (immutable; server-set) The id of the mailbox.
o *name*: "String" User-visible name for the mailbox, e.g. "Inbox". o *name*: "String" User-visible name for the mailbox, e.g. "Inbox".
This may be any Net-Unicode string ([RFC5198]) of at least 1 This may be any Net-Unicode string ([RFC5198]) of at least 1
character in length, subject to the maximum size given in the character in length, subject to the maximum size given in the
capability object. Servers MUST forbid sibling Mailboxes with the capability object. There MUST NOT be two sibling mailboxes with
same name. Servers MAY reject names that violate server policy both the same parent and the same name. Servers MAY reject names
(e.g., names containing slash (/) or control characters). that violate server policy (e.g., names containing slash (/) or
control characters).
o *parentId*: "Id|null" (default: null) The mailbox id for the o *parentId*: "Id|null" (default: null) The mailbox id for the
parent of this mailbox, or "null" if this mailbox is at the top parent of this mailbox, or "null" if this mailbox is at the top
level. Mailboxes form acyclic graphs (forests) directed by the level. Mailboxes form acyclic graphs (forests) directed by the
child-to-parent relationship. There MUST NOT be a loop. child-to-parent relationship. There MUST NOT be a loop.
o *role*: "String|null" (default: null) Identifies mailboxes that o *role*: "String|null" (default: null) Identifies mailboxes that
have a particular common purpose (e.g. the "inbox"), regardless of have a particular common purpose (e.g. the "inbox"), regardless of
the _name_ (which may be localised). This value is shared with the _name_ (which may be localised). This value is shared with
IMAP (exposed in IMAP via the [RFC6154] SPECIAL-USE extension). IMAP (exposed in IMAP via the [RFC6154] SPECIAL-USE extension).
skipping to change at page 9, line 19 skipping to change at page 9, line 42
though they are in a separate thread for the purposes of unread though they are in a separate thread for the purposes of unread
counts. It is expected that clients will hide emails in the Trash counts. It is expected that clients will hide emails in the Trash
when viewing a thread in another mailbox and vice versa. This when viewing a thread in another mailbox and vice versa. This
allows you to delete a single email to the Trash out of a thread. allows you to delete a single email to the Trash out of a thread.
So for example, suppose you have an account where the entire So for example, suppose you have an account where the entire
contents is a single thread with 2 emails: an unread email in the contents is a single thread with 2 emails: an unread email in the
Trash and a read email in the Inbox. The "unreadThreads" count Trash and a read email in the Inbox. The "unreadThreads" count
would be "1" for the Trash and "0" for the Inbox. would be "1" for the Trash and "0" for the Inbox.
o *myRights*: "MailboxRights" (server-set) The set of rights (ACLs) o *myRights*: "MailboxRights" (server-set) The set of rights (ACLs)
the user has in relation to this mailbox. A _MailboxRights_ the user has in relation to this mailbox. These are backwards
object has the following properties: compatible with IMAP ACLs, as defined in [RFC4314]. A
_MailboxRights_ object has the following properties:
* *mayReadItems*: "Boolean" If true, the user may use this * *mayReadItems*: "Boolean" If true, the user may use this
mailbox as part of a filter in a _Email/query_ call and the mailbox as part of a filter in a _Email/query_ call and the
mailbox may be included in the _mailboxIds_ set of _Email_ mailbox may be included in the _mailboxIds_ set of _Email_
objects. If a sub-mailbox is shared but not the parent objects. If a sub-mailbox is shared but not the parent
mailbox, this may be "false". Corresponds to IMAP ACLs "lr". mailbox, this may be "false". Corresponds to IMAP ACLs "lr".
* *mayAddItems*: "Boolean" The user may add mail to this mailbox * *mayAddItems*: "Boolean" The user may add mail to this mailbox
(by either creating a new email or moving an existing one). (by either creating a new email or moving an existing one).
Corresponds to IMAP ACL "i". Corresponds to IMAP ACL "i".
skipping to change at page 10, line 26 skipping to change at page 10, line 51
shared mailbox. A user may have permission to access a large shared mailbox. A user may have permission to access a large
number of shared accounts, or a shared account with a very large number of shared accounts, or a shared account with a very large
set of mailboxes, but only be interested in the contents of a few set of mailboxes, but only be interested in the contents of a few
of these. Clients may choose only to display mailboxes to the of these. Clients may choose only to display mailboxes to the
user that have the "isSubscribed" property set to "true", and user that have the "isSubscribed" property set to "true", and
offer a separate UI to allow the user to see and subscribe/ offer a separate UI to allow the user to see and subscribe/
unsubscribe from the full set of mailboxes. However, clients MAY unsubscribe from the full set of mailboxes. However, clients MAY
choose to ignore this property, either entirely for ease of choose to ignore this property, either entirely for ease of
implementation, or just for the primary account (which is normally implementation, or just for the primary account (which is normally
the user's own, rather than a shared account). This property the user's own, rather than a shared account). This property
corresponds to IMAP mailbox subscriptions. corresponds to IMAP ([RFC3501]) mailbox subscriptions.
For IMAP compatibility, an email in both the Trash and another For IMAP compatibility, an email in both the Trash and another
mailbox SHOULD be treated by the client as existing in both places mailbox SHOULD be treated by the client as existing in both places
(i.e. when emptying the trash, the client SHOULD just remove the (i.e. when emptying the trash, the client SHOULD just remove the
Trash mailbox and leave it in the other mailbox). Trash mailbox and leave it in the other mailbox).
The following JMAP methods are supported: The following JMAP methods are supported:
2.1. Mailbox/get 2.1. Mailbox/get
skipping to change at page 12, line 10 skipping to change at page 12, line 34
given value exactly. given value exactly.
o *hasAnyRole*: "Boolean" If "true", a Mailbox matches if it has any o *hasAnyRole*: "Boolean" If "true", a Mailbox matches if it has any
non-"null" value for its _role_ property. non-"null" value for its _role_ property.
o *isSubscribed*: "Boolean" The "isSubscribed" property of the o *isSubscribed*: "Boolean" The "isSubscribed" property of the
mailbox must be identical to the value given to match the mailbox must be identical to the value given to match the
condition. condition.
A Mailbox object matches the filter if and only if all of the given A Mailbox object matches the filter if and only if all of the given
conditions given match. If zero properties are specified, it is conditions match. If zero properties are specified, it is
automatically "true" for all objects. automatically "true" for all objects.
The following properties MUST be supported for sorting: The following properties MUST be supported for sorting:
o "sortOrder" o "sortOrder"
o "name" o "name"
2.4. Mailbox/queryChanges 2.4. Mailbox/queryChanges
skipping to change at page 18, line 8 skipping to change at page 19, line 8
"notFound": [] "notFound": []
}, "#1" ]] }, "#1" ]]
3.2. Thread/changes 3.2. Thread/changes
Standard "/changes" method. Standard "/changes" method.
4. Emails 4. Emails
The *Email* object is a representation of an [RFC5322] message, which The *Email* object is a representation of an [RFC5322] message, which
allows clients to avoid the complexities of MIME parsing, transport allows clients to avoid the complexities of MIME parsing, transfer
encoding and character encoding. encoding and character encoding.
4.1. Properties of the Email object 4.1. Properties of the Email object
Broadly, a message consists of two parts: a list of header fields, Broadly, a message consists of two parts: a list of header fields,
then a body. The JMAP Email object provides a way to access the full then a body. The JMAP Email object provides a way to access the full
structure, or to use simplified properties and avoid some complexity structure, or to use simplified properties and avoid some complexity
if this is sufficient for the client application. if this is sufficient for the client application.
While raw headers can be fetched and set, the vast majority of While raw headers can be fetched and set, the vast majority of
skipping to change at page 20, line 47 skipping to change at page 21, line 47
set this flag when users indicate an email is legitimate, to set this flag when users indicate an email is legitimate, to
help train automated spam-detection systems. help train automated spam-detection systems.
o *size*: "PositiveInt" (immutable; server-set) The size, in octets, o *size*: "PositiveInt" (immutable; server-set) The size, in octets,
of the raw data for the [RFC5322] message (as referenced by the of the raw data for the [RFC5322] message (as referenced by the
_blobId_, i.e. the number of octets in the file the user would _blobId_, i.e. the number of octets in the file the user would
download). download).
o *receivedAt*: "UTCDate" (immutable; default: time of creation on o *receivedAt*: "UTCDate" (immutable; default: time of creation on
server) The date the email was received by the message store. server) The date the email was received by the message store.
This is the _internal date_ in IMAP. This is the _internal date_ in IMAP ([RFC3501]).
4.1.2. Header fields parsed forms 4.1.2. Header fields parsed forms
Header field properties are derived from the [RFC5322] and [RFC6532] Header field properties are derived from the [RFC5322] and [RFC6532]
message header fields. All header fields may be fetched in a raw message header fields. All header fields may be fetched in a raw
form. Some headers may also be fetched in a parsed form. The form. Some headers may also be fetched in a parsed form. The
structured form that may be fetched depends on the header. The structured form that may be fetched depends on the header. The
following forms are defined: following forms are defined:
4.1.2.1. Raw 4.1.2.1. Raw
Type: "String" Type: "String"
The raw octets of the header field value from the first octet The raw octets of the header field value from the first octet
following the header field name terminating colon, up to but following the header field name terminating colon, up to but
excluding the header field terminating CRLF. Any standards-compliant excluding the header field terminating CRLF. Any standards-compliant
message MUST be either ASCII (RFC5322) or UTF-8 (RFC6532), however message MUST be either ASCII (RFC5322) or UTF-8 (RFC6532), however
other encodings exist in the wild. A server MAY use heuristics to other encodings exist in the wild. A server SHOULD replace any octet
determine a charset and decode the octets, or MAY replace any octet
or octet run with the high bit set that violates UTF-8 syntax with or octet run with the high bit set that violates UTF-8 syntax with
the unicode replacement character (U+FFFD). Any NUL octet MUST be the unicode replacement character (U+FFFD). Any NUL octet MUST be
dropped. dropped.
This form will typically have a leading space, as most generated
messages insert a space after the colon that terminates the header
field name.
4.1.2.2. Text 4.1.2.2. Text
Type: "String" Type: "String"
The header field value with: The header field value with:
1. White space unfolded (as defined in [RFC5322] section 2.2.3). 1. White space unfolded (as defined in [RFC5322] section 2.2.3).
2. The terminating CRLF at the end of the value removed. 2. The terminating CRLF at the end of the value removed.
3. Any SP characters at the beginning of the value removed. 3. Any SP characters at the beginning of the value removed.
4. Any syntactically correct [RFC2047] encoded sections with a known 4. Any syntactically correct [RFC2047] encoded sections with a known
character set decoded. Any [RFC2047] encoded NUL octets or character set decoded. Any [RFC2047] encoded NUL octets or
control characters are dropped from the decoded value. Any text control characters are dropped from the decoded value. Any text
that looks like [RFC2047] syntax but violates [RFC2047] placement that looks like [RFC2047] syntax but violates [RFC2047] placement
or whitespace rules MUST NOT be decoded. or whitespace rules MUST NOT be decoded.
5. Any [RFC6532] UTF-8 values decoded. 5. The resulting unicode converted to NFC form.
6. The resulting unicode converted to NFC form.
If any decodings fail, the parser SHOULD insert a unicode replacement If any decodings fail, the parser SHOULD insert a unicode replacement
character (U+FFFD) and attempt to continue as much as possible. character (U+FFFD) and attempt to continue as much as possible.
To prevent obviously nonsense behaviour, which can lead to To prevent obviously nonsense behaviour, which can lead to
interoperability issues, this form may only be fetched or set for the interoperability issues, this form may only be fetched or set for the
following header fields: following header fields:
o Subject o Subject
o Comment o Comments
o Keywords
o List-Id o List-Id
o Any header not defined in [RFC5322] or [RFC2369] o Any header not defined in [RFC5322] or [RFC2369]
4.1.2.3. Addresses 4.1.2.3. Addresses
Type: "EmailAddress[]" Type: "EmailAddress[]"
The header is parsed as an "address-list" value, as specified in The header is parsed as an "address-list" value, as specified in
skipping to change at page 22, line 42 skipping to change at page 23, line 44
2. Any _quoted-pair_ is decoded. 2. Any _quoted-pair_ is decoded.
3. White-space is unfolded, and then any leading and trailing 3. White-space is unfolded, and then any leading and trailing
white-space is removed. white-space is removed.
o *email*: "String" The _addr-spec_ of the [RFC5322] _mailbox_. o *email*: "String" The _addr-spec_ of the [RFC5322] _mailbox_.
Any syntactically correct [RFC2047] encoded sections with a known Any syntactically correct [RFC2047] encoded sections with a known
encoding MUST be decoded, following the same rules as for the _Text_ encoding MUST be decoded, following the same rules as for the _Text_
form. Any [RFC6532] UTF-8 values MUST be decoded. form.
Parsing SHOULD be best-effort in the face of invalid structure to Parsing SHOULD be best-effort in the face of invalid structure to
accommodate invalid messages and semi-complete drafts. EmailAddress accommodate invalid messages and semi-complete drafts. EmailAddress
objects MAY have an _email_ property that does not conform to the objects MAY have an _email_ property that does not conform to the
_addr-spec_ form (for example, may not contain an @ symbol). _addr-spec_ form (for example, may not contain an @ symbol).
For example, the following "address-list" string: For example, the following "address-list" string:
" James Smythe" <james@example.com>, Friends: " James Smythe" <james@example.com>, Friends:
jane@example.com, =?UTF-8?Q?John_Sm=C3=AEth?= jane@example.com, =?UTF-8?Q?John_Sm=C3=AEth?=
skipping to change at page 24, line 21 skipping to change at page 25, line 21
o *name*: "String|null" The _display-name_ of the [RFC5322] _group_, o *name*: "String|null" The _display-name_ of the [RFC5322] _group_,
or "null" if the addresses are not part of a group. If this is a or "null" if the addresses are not part of a group. If this is a
_quoted-string_ it is processed the same as the _name_ in the _quoted-string_ it is processed the same as the _name_ in the
_EmailAddress_ type. _EmailAddress_ type.
o *addresses*: "EmailAddress[]" The _mailbox_es that belong to this o *addresses*: "EmailAddress[]" The _mailbox_es that belong to this
group, represented as EmailAddress objects. group, represented as EmailAddress objects.
Any syntactically correct [RFC2047] encoded sections with a known Any syntactically correct [RFC2047] encoded sections with a known
encoding MUST be decoded, following the same rules as for the _Text_ encoding MUST be decoded, following the same rules as for the _Text_
form. Any [RFC6532] UTF-8 values MUST be decoded. form.
Parsing SHOULD be best-effort in the face of invalid structure to Parsing SHOULD be best-effort in the face of invalid structure to
accommodate invalid messages and semi-complete drafts. accommodate invalid messages and semi-complete drafts.
For example, the following "address-list" string: For example, the following "address-list" string:
" James Smythe" <james@example.com>, Friends: " James Smythe" <james@example.com>, Friends:
jane@example.com, =?UTF-8?Q?John_Sm=C3=AEth?= jane@example.com, =?UTF-8?Q?John_Sm=C3=AEth?=
<john@example.com>; <john@example.com>;
skipping to change at page 28, line 43 skipping to change at page 29, line 43
[RFC2045] MIME entities. [RFC2045] MIME entities.
A *EmailBodyPart* object has the following properties: A *EmailBodyPart* object has the following properties:
o *partId*: "String|null" Identifies this part uniquely within the o *partId*: "String|null" Identifies this part uniquely within the
Email. This is scoped to the _emailId_ and has no meaning outside Email. This is scoped to the _emailId_ and has no meaning outside
of the JMAP Email object representation. This is "null" if, and of the JMAP Email object representation. This is "null" if, and
only if, the part is of type "multipart/*". only if, the part is of type "multipart/*".
o *blobId*: "Id|null" The id representing the raw octets of the o *blobId*: "Id|null" The id representing the raw octets of the
contents of the part after decoding any _Content-Transfer- contents of the part, after decoding any known _Content-Transfer-
Encoding_ (as defined in [RFC2045]), or "null" if, and only if, Encoding_ (as defined in [RFC2045]), or "null" if, and only if,
the part is of type "multipart/*". Note, two parts may be the part is of type "multipart/*". Note, two parts may be
transfer-encoded differently but have the same blob id if their transfer-encoded differently but have the same blob id if their
decoded octets are identical and the server is using a secure hash decoded octets are identical and the server is using a secure hash
of the data for the blob id. of the data for the blob id. If the transfer encoding is unknown,
it is treated as though it had no transfer-encoding.
o *size*: "PositiveInt" The size, in octets, of the raw data after o *size*: "PositiveInt" The size, in octets, of the raw data after
content transfer decoding (as referenced by the _blobId_, i.e. the content transfer decoding (as referenced by the _blobId_, i.e. the
number of octets in the file the user would download). number of octets in the file the user would download).
o *headers*: "EmailHeader[]" This is a list of all header fields in o *headers*: "EmailHeader[]" This is a list of all header fields in
the part, in the order they appear in the message. The values are the part, in the order they appear in the message. The values are
in _Raw_ form. in _Raw_ form.
o *name*: "String|null" This is the [RFC2231] decoded _filename_ o *name*: "String|null" This is the [RFC2231] decoded _filename_
skipping to change at page 29, line 35 skipping to change at page 30, line 39
but has no charset parameter, this is the implicit charset as per but has no charset parameter, this is the implicit charset as per
the MIME standard: "us-ascii". the MIME standard: "us-ascii".
o *disposition*: "String|null" The value of the _Content- o *disposition*: "String|null" The value of the _Content-
Disposition_ header field of the part, if present, otherwise Disposition_ header field of the part, if present, otherwise
"null". CFWS is removed and any parameters are stripped. "null". CFWS is removed and any parameters are stripped.
o *cid*: "String|null" The value of the _Content-Id_ header field of o *cid*: "String|null" The value of the _Content-Id_ header field of
the part, if present, otherwise "null". CFWS and surrounding the part, if present, otherwise "null". CFWS and surrounding
angle brackets ("<>") are removed. This may be used to reference angle brackets ("<>") are removed. This may be used to reference
the content from within an html body part using the "cid:" the content from within an [HTML] body part using the "cid:"
protocol. protocol, as defined in [RFC2392].
o *language*: "String[]|null" The list of language tags, as defined o *language*: "String[]|null" The list of language tags, as defined
in [RFC3282], in the _Content-Language_ header field of the part, in [RFC3282], in the _Content-Language_ header field of the part,
if present. if present.
o *location*: "String|null" The URI, as defined in [RFC2557], in the o *location*: "String|null" The URI, as defined in [RFC2557], in the
_Content-Location_ header field of the part, if present. _Content-Location_ header field of the part, if present.
o *subParts*: "EmailBodyPart[]|null" If type is "multipart/*", this o *subParts*: "EmailBodyPart[]|null" If type is "multipart/*", this
contains the body parts of each child. contains the body parts of each child.
skipping to change at page 30, line 22 skipping to change at page 31, line 26
have subParts if they are of type "multipart/*". have subParts if they are of type "multipart/*".
o *bodyValues*: "String[EmailBodyValue]" (immutable) This is a map o *bodyValues*: "String[EmailBodyValue]" (immutable) This is a map
of _partId_ to an *EmailBodyValue* object for none, some or all of _partId_ to an *EmailBodyValue* object for none, some or all
"text/*" parts. Which parts are included and whether the value is "text/*" parts. Which parts are included and whether the value is
truncated is determined by various arguments to _Email/get_ and truncated is determined by various arguments to _Email/get_ and
_Email/parse_. An *EmailBodyValue* object has the following _Email/parse_. An *EmailBodyValue* object has the following
properties: properties:
* *value*: "String" The value of the body part after decoding * *value*: "String" The value of the body part after decoding
_Content-Transport-Encoding_ and decoding the _Content-Type_ _Content-Transfer-Encoding_ and decoding the _Content-Type_
charset, if known to the server, and with any CRLF replaced charset, if both known to the server, and with any CRLF
with a single LF. The server MAY use heuristics to determine replaced with a single LF. The server MAY use heuristics to
the charset to use for decoding if the charset is unknown, or determine the charset to use for decoding if the charset is
if no charset is given, or if it believes the charset given is unknown, or if no charset is given, or if it believes the
incorrect. Decoding is best-effort and SHOULD insert the charset given is incorrect. Decoding is best-effort and SHOULD
unicode replacement character (U+FFFD) and continue when a insert the unicode replacement character (U+FFFD) and continue
malformed section is encountered. Note that due to the charset when a malformed section is encountered. Note that due to the
decoding and line ending normalisation, the length of this charset decoding and line ending normalisation, the length of
string will probably not be exactly the same as the _size_ this string will probably not be exactly the same as the _size_
property on the corresponding EmailBodyPart. property on the corresponding EmailBodyPart.
* *isEncodingProblem*: "Boolean" (default: false) This is "true" * *isEncodingProblem*: "Boolean" (default: false) This is "true"
if malformed sections were found while decoding the charset, or if malformed sections were found while decoding the charset, or
the charset was unknown. the charset was unknown, or the content-trasfer-encoding was
unknown.
* *isTruncated*: "Boolean" (default: false) This is "true" if the * *isTruncated*: "Boolean" (default: false) This is "true" if the
_value_ has been truncated. _value_ has been truncated.
See the security considerations section for issues related to See the security considerations section for issues related to
truncation and heuristic determination of content-type and truncation and heuristic determination of content-type and
charset. charset.
o *textBody*: "EmailBodyPart[]" (immutable) A list of "text/plain", o *textBody*: "EmailBodyPart[]" (immutable) A list of "text/plain",
"text/html", "image/*", "audio/*" and/or "video/*" parts to "text/html", "image/*", "audio/*" and/or "video/*" parts to
skipping to change at page 31, line 19 skipping to change at page 32, line 24
of the following conditions: of the following conditions:
* not of type "multipart/*" and not included in _textBody_ or * not of type "multipart/*" and not included in _textBody_ or
_htmlBody_ _htmlBody_
* of type "image/*", "audio/*" or "video/*" and not in both * of type "image/*", "audio/*" or "video/*" and not in both
_textBody_ and _htmlBody_ _textBody_ and _htmlBody_
None of these parts include subParts, including "message/*" types. None of these parts include subParts, including "message/*" types.
Attached messages may be fetched using the Email/parse method and Attached messages may be fetched using the Email/parse method and
the blobId. Note, an HTML body part may reference image parts in the blobId. Note, an [HTML] body part may reference image parts
attachments using "cid:" links to reference the _Content-Id_ or by in attachments using "cid:" links to reference the _Content-Id_,
referencing the _Content-Location_. as defined in [RFC2392], or by referencing the _Content-Location_.
o *hasAttachment*: "Boolean" (immutable; server-set) This is "true" o *hasAttachment*: "Boolean" (immutable; server-set) This is "true"
if there are one or more parts in the message that a client UI if there are one or more parts in the message that a client UI
should offer as downloadable. A server SHOULD set hasAttachment should offer as downloadable. A server SHOULD set hasAttachment
to "true" if the _attachments_ list contains at least one item to "true" if the _attachments_ list contains at least one item
that does not have "Content-Disposition: inline". The server MAY that does not have "Content-Disposition: inline". The server MAY
ignore parts in this list that are processed automatically in some ignore parts in this list that are processed automatically in some
way, or are referenced as embedded images in one of the "text/ way, or are referenced as embedded images in one of the "text/
html" parts of the message. The server MAY set hasAttachment html" parts of the message. The server MAY set hasAttachment
based on implementation-defined or site configurable heuristics. based on implementation-defined or site configurable heuristics.
skipping to change at page 33, line 45 skipping to change at page 35, line 4
} }
// Found plain text part only // Found plain text part only
if ( htmlLength == htmlBody.length && if ( htmlLength == htmlBody.length &&
textLength != textBody.length ) { textLength != textBody.length ) {
for ( let i = textLength; i < textBody.length; i += 1 ) { for ( let i = textLength; i < textBody.length; i += 1 ) {
htmlBody.push( textBody[i] ); htmlBody.push( textBody[i] );
} }
} }
} }
} }
// Usage: // Usage:
let htmlBody = []; let htmlBody = [];
let textBody = []; let textBody = [];
let attachments = []; let attachments = [];
parseStructure( [ bodyStructure ], 'mixed', false, parseStructure( [ bodyStructure ], 'mixed', false,
htmlBody, textBody, attachments ); htmlBody, textBody, attachments );
For instance, consider a message with both text and html versions For instance, consider a message with both text and HTML versions
that's then gone through a list software manager that attaches a that's then gone through a list software manager that attaches a
header/footer. It might have a MIME structure something like: header/footer. It might have a MIME structure something like:
multipart/mixed multipart/mixed
text/plain, content-disposition=inline - A text/plain, content-disposition=inline - A
multipart/mixed multipart/mixed
multipart/alternative multipart/alternative
multipart/mixed multipart/mixed
text/plain, content-disposition=inline - B text/plain, content-disposition=inline - B
image/jpeg, content-disposition=inline - C image/jpeg, content-disposition=inline - C
skipping to change at page 43, line 7 skipping to change at page 44, line 7
o Creating a draft o Creating a draft
o Changing the keywords of an email (e.g. unread/flagged status) o Changing the keywords of an email (e.g. unread/flagged status)
o Adding/removing an email to/from mailboxes (moving a message) o Adding/removing an email to/from mailboxes (moving a message)
o Deleting emails o Deleting emails
The format of the keywords/mailboxIds properties means that when The format of the keywords/mailboxIds properties means that when
updating an email you can either replace the entire set of keywords/ updating an email you can either replace the entire set of keywords/
mailboxes (by setting the full value of the property) or add/remove mailboxes (by setting the full value of the property) or add/remove
individual ones using the JMAP patch syntax (see RFC XXXX, section individual ones using the JMAP patch syntax (see
5.3 for the specification and section 5.7 for an example). [I-D.ietf-jmap-core], section 5.3 for the specification and section
5.7 for an example).
Due to the format of the Email object, when creating an email there Due to the format of the Email object, when creating an email there
are a number of ways to specify the same information. To ensure that are a number of ways to specify the same information. To ensure that
the RFC5322 email to create is unambiguous, the following constraints the RFC5322 email to create is unambiguous, the following constraints
apply to Email objects submitted for creation: apply to Email objects submitted for creation:
o The _headers_ property MUST NOT be given, on either the top-level o The _headers_ property MUST NOT be given, on either the top-level
email or an EmailBodyPart - the client must set each header field email or an EmailBodyPart - the client must set each header field
as an individual property. as an individual property.
skipping to change at page 45, line 31 skipping to change at page 46, line 31
within an account; if the target account already has the email the within an account; if the target account already has the email the
copy will be rejected with a standard "alreadyExists" error. copy will be rejected with a standard "alreadyExists" error.
For successfully copied Email objects, the _created_ response For successfully copied Email objects, the _created_ response
contains the _id_, _blobId_, _threadId_ and _size_ properties of the contains the _id_, _blobId_, _threadId_ and _size_ properties of the
new object. new object.
4.8. Email/import 4.8. Email/import
The _Email/import_ method adds [RFC5322] messages to the set of The _Email/import_ method adds [RFC5322] messages to the set of
emails in an account. The messages must first be uploaded as blobs emails in an account. The server MUST support messages with
[RFC6532] EAI headers. The messages must first be uploaded as blobs
using the standard upload mechanism. It takes the following using the standard upload mechanism. It takes the following
arguments: arguments:
o *accountId*: "Id" The id of the account to use. o *accountId*: "Id" The id of the account to use.
o *ifInState*: "String|null" This is a state string as returned by o *ifInState*: "String|null" This is a state string as returned by
the _Email/get_ method. If supplied, the string must match the the _Email/get_ method. If supplied, the string must match the
current state of the account referenced by the accountId, current state of the account referenced by the accountId,
otherwise the method will be aborted and a "stateMismatch" error otherwise the method will be aborted and a "stateMismatch" error
returned. If "null", any changes will be applied to the current returned. If "null", any changes will be applied to the current
skipping to change at page 47, line 16 skipping to change at page 48, line 16
_Email/get_ on this account. _Email/get_ on this account.
o *created*: "Id[Email]|null" A map of the creation id to an object o *created*: "Id[Email]|null" A map of the creation id to an object
containing the _id_, _blobId_, _threadId_ and _size_ properties containing the _id_, _blobId_, _threadId_ and _size_ properties
for each successfully imported Email, or "null" if none. for each successfully imported Email, or "null" if none.
o *notCreated*: "Id[SetError]|null" A map of creation id to a o *notCreated*: "Id[SetError]|null" A map of creation id to a
SetError object for each Email that failed to be created, or SetError object for each Email that failed to be created, or
"null" if all successful. The possible errors are defined above. "null" if all successful. The possible errors are defined above.
The following additional errors may be returned instead of the _Foo/ The following additional errors may be returned instead of the
copy_ response: _Email/import_ response:
"stateMismatch": An "ifInState" argument was supplied and it does not "stateMismatch": An "ifInState" argument was supplied and it does not
match the current state. match the current state.
4.9. Email/parse 4.9. Email/parse
This method allows you to parse blobs as [RFC5322] messages to get This method allows you to parse blobs as [RFC5322] messages to get
Email objects. This can be used to parse and display attached emails Email objects. The server MUST support messages with [RFC6532] EAI
headers. This can be used to parse and display attached emails
without having to import them as top-level email objects in the mail without having to import them as top-level email objects in the mail
store in their own right. store in their own right.
The following metadata properties on the Email objects will be "null" The following metadata properties on the Email objects will be "null"
if requested: if requested:
o id o id
o mailboxIds o mailboxIds
skipping to change at page 56, line 28 skipping to change at page 57, line 28
"threadId": "T2f242ea424a4079a", "threadId": "T2f242ea424a4079a",
"size": 11721 "size": 11721
} }
}, },
"notCreated": null "notCreated": null
}, "0" ], }, "0" ],
[ "Email/set", { [ "Email/set", {
"accountId": "ue150411c", "accountId": "ue150411c",
"oldState": "780839", "oldState": "780839",
"newState": "780871", "newState": "780871",
"destroyed": [ "Ma783e5cdf5f2deffbc97930a" ], "destroyed": [ "Md45b47b4877521042cec0938" ],
... ...
}, "0" ]] }, "0" ]]
5. Search snippets 5. Search snippets
When doing a search on a "String" property, the client may wish to When doing a search on a "String" property, the client may wish to
show the relevant section of the body that matches the search as a show the relevant section of the body that matches the search as a
preview instead of the beginning of the message, and to highlight any preview instead of the beginning of the message, and to highlight any
matching terms in both this and the subject of the email. Search matching terms in both this and the subject of the email. Search
snippets represent this data. snippets represent this data.
A *SearchSnippet* object has the following properties: A *SearchSnippet* object has the following properties:
o *emailId*: "Id" The email id the snippet applies to. o *emailId*: "Id" The email id the snippet applies to.
o *subject*: "String|null" If text from the filter matches the o *subject*: "String|null" If text from the filter matches the
subject, this is the subject of the email HTML-escaped, with subject, this is the subject of the email with the following
matching words/phrases wrapped in "<mark></mark>" tags. If it transformations:
does not match, this is "null".
1. Any instance of the following three characters MUST be
replaced by an appropriate [HTML] entity: & (ampersand), <
(less-than sign), and > (greater-than sign). Other characters
MAY also be replaced with an HTML entity form.
2. The matching words/phrases from the filter are wrapped in HTML
"<mark></mark>" tags.
If the subject does not match text from the filter, this property
is "null".
o *preview*: "String|null" If text from the filter matches the o *preview*: "String|null" If text from the filter matches the
plain-text or HTML body, this is the relevant section of the body plain-text or HTML body, this is the relevant section of the body
(converted to plain text if originally HTML), HTML-escaped, with (converted to plain text if originally HTML), with the same
matching words/phrases wrapped in "<mark></mark>" tags. It MUST transformations as the _subject_ property. It MUST NOT be bigger
NOT be bigger than 255 octets in size. If it does not match, this than 255 octets in size. If the body does not contain a match for
is "null". the text from the filter, this property is "null".
It is server-defined what is a relevant section of the body for It is server-defined what is a relevant section of the body for
preview. If the server is unable to determine search snippets, it preview. If the server is unable to determine search snippets, it
MUST return "null" for both the _subject_ and _preview_ properties. MUST return "null" for both the _subject_ and _preview_ properties.
Note, unlike most data types, a SearchSnippet DOES NOT have a Note, unlike most data types, a SearchSnippet DOES NOT have a
property called "id". property called "id".
The following JMAP method is supported: The following JMAP method is supported:
skipping to change at page 58, line 25 skipping to change at page 59, line 35
"accountId": "ue150411c", "accountId": "ue150411c",
"filter": { "filter": {
"text": "foo" "text": "foo"
}, },
"emailIds": [ "emailIds": [
"M44200ec123de277c0c1ce69c", "M44200ec123de277c0c1ce69c",
"M7bcbcb0b58d7729686e83d99", "M7bcbcb0b58d7729686e83d99",
"M28d12783a0969584b6deaac0", "M28d12783a0969584b6deaac0",
... ...
] ]
}, "tag-0" ]] }, "0" ]]
Example response: Example response:
[[ "SearchSnippet/get", { [[ "SearchSnippet/get", {
"accountId": "ue150411c", "accountId": "ue150411c",
"list": [{ "list": [{
"emailId": "M44200ec123de277c0c1ce69c", "emailId": "M44200ec123de277c0c1ce69c",
"subject": null, "subject": null,
"preview": null "preview": null
}, { }, {
skipping to change at page 58, line 49 skipping to change at page 60, line 25
be held in the Stadium de ..." be held in the Stadium de ..."
}, { }, {
"emailId": "M28d12783a0969584b6deaac0", "emailId": "M28d12783a0969584b6deaac0",
"subject": null, "subject": null,
"preview": "...the <mark>Foo</mark>/bar method results often "preview": "...the <mark>Foo</mark>/bar method results often
returns &lt;1 widget rather than the complete..." returns &lt;1 widget rather than the complete..."
}, },
... ...
], ],
"notFound": null "notFound": null
}, "tag-0" ]] }, "0" ]]
6. Identities 6. Identities
An *Identity* object stores information about an email address (or An *Identity* object stores information about an email address (or
domain) the user may send from. It has the following properties: domain) the user may send from. It has the following properties:
o *id*: "Id" (immutable; server-set) The id of the identity. o *id*: "Id" (immutable; server-set) The id of the identity.
o *name*: "String" (default: "") The "From" _name_ the client SHOULD o *name*: "String" (default: "") The "From" _name_ the client SHOULD
use when creating a new message from this identity. use when creating a new message from this identity.
skipping to change at page 63, line 15 skipping to change at page 64, line 22
* *rcptTo*: The deduplicated set of email addresses from the * *rcptTo*: The deduplicated set of email addresses from the
_To_, _Cc_ and _Bcc_ headers, if present, with no parameters _To_, _Cc_ and _Bcc_ headers, if present, with no parameters
for any of them. for any of them.
o *sendAt*: "UTCDate" (immutable; server-set) The date the email o *sendAt*: "UTCDate" (immutable; server-set) The date the email
was/will be released for delivery. If the client successfully was/will be released for delivery. If the client successfully
used [RFC4865] FUTURERELEASE with the email, this MUST be the time used [RFC4865] FUTURERELEASE with the email, this MUST be the time
when the server will release the email; otherwise it MUST be the when the server will release the email; otherwise it MUST be the
time the EmailSubmission was created. time the EmailSubmission was created.
o *undoStatus*: "String" (server-set) This represents whether the o *undoStatus*: "String" This represents whether the submission may
submission may be canceled. This is server set and MUST be one of be canceled. This is server set and MUST be one of the following
the following values: values:
* "pending": It MAY be possible to cancel this submission. * "pending": It MAY be possible to cancel this submission.
* "final": The email has been relayed to at least one recipient * "final": The email has been relayed to at least one recipient
in a manner that cannot be recalled. It is no longer possible in a manner that cannot be recalled. It is no longer possible
to cancel this submission. to cancel this submission.
* "canceled": The email submission was canceled and will not be * "canceled": The email submission was canceled and will not be
delivered to any recipient. delivered to any recipient.
skipping to change at page 63, line 50 skipping to change at page 65, line 9
if known. This property MAY not be supported by all servers, in if known. This property MAY not be supported by all servers, in
which case it will remain "null". Servers that support it SHOULD which case it will remain "null". Servers that support it SHOULD
update the EmailSubmission object each time the status of any of update the EmailSubmission object each time the status of any of
the recipients changes, even if some recipients are still being the recipients changes, even if some recipients are still being
retried. This value is a map from the email address of each retried. This value is a map from the email address of each
recipient to a _DeliveryStatus_ object. A *DeliveryStatus* object recipient to a _DeliveryStatus_ object. A *DeliveryStatus* object
has the following properties: has the following properties:
* *smtpReply*: "String" The SMTP reply string returned for this * *smtpReply*: "String" The SMTP reply string returned for this
recipient when the server last tried to relay the email, or in recipient when the server last tried to relay the email, or in
a later DSN response for the email. This SHOULD be the a later DSN (Delivery Status Notification, as defined in
response to the RCPT TO stage, unless this was accepted and the [RFC3464]) response for the email. This SHOULD be the response
email as a whole rejected at the end of the DATA stage, in to the RCPT TO stage, unless this was accepted and the email as
which case the DATA stage reply SHOULD be used instead. Multi- a whole rejected at the end of the DATA stage, in which case
line SMTP responses should be concatenated to a single string the DATA stage reply SHOULD be used instead. Multi-line SMTP
as follows: responses should be concatenated to a single string as follows:
+ The hyphen following the SMTP code on all but the last line + The hyphen following the SMTP code on all but the last line
is replaced with a space. is replaced with a space.
+ Any prefix in common with the first line is stripped from + Any prefix in common with the first line is stripped from
lines after the first. lines after the first.
+ CRLF is replaced by a space. + CRLF is replaced by a space.
For example: For example:
skipping to change at page 65, line 15 skipping to change at page 66, line 26
+ "no": Delivery to the recipient permanently failed. The + "no": Delivery to the recipient permanently failed. The
_smtpReply_ property is final. _smtpReply_ property is final.
+ "unknown": The final delivery status is unknown, (e.g. it + "unknown": The final delivery status is unknown, (e.g. it
was relayed to an external machine and no further was relayed to an external machine and no further
information is available). The _smtpReply_ property may information is available). The _smtpReply_ property may
still change if a DSN arrives. still change if a DSN arrives.
Note, successful relaying to an external SMTP server SHOULD NOT Note, successful relaying to an external SMTP server SHOULD NOT
be taken as an indication that the email has successfully be taken as an indication that the email has successfully
reached the final mailbox. In this case though, the server MAY reached the final mailbox. In this case though, the server may
receive a DSN response, if requested. If a DSN is received for receive a DSN response, if requested. If a DSN is received for
the recipient with Action equal to "delivered", as per the recipient with Action equal to "delivered", as per
[RFC3464] section 2.3.3, then the _delivered_ property SHOULD [RFC3464] section 2.3.3, then the _delivered_ property SHOULD
be set to "yes"; if the Action equals "failed", the property be set to "yes"; if the Action equals "failed", the property
SHOULD be set to "no". Receipt of any other DSN SHOULD NOT SHOULD be set to "no". Receipt of any other DSN SHOULD NOT
affect this property. The server MAY also set this property affect this property. The server MAY also set this property
based on other feedback channels. based on other feedback channels.
* *displayed*: "String" Represents whether the email has been * *displayed*: "String" Represents whether the email has been
displayed to the recipient. This MUST be one of the following displayed to the recipient. This MUST be one of the following
skipping to change at page 65, line 41 skipping to change at page 67, line 5
+ "yes": The recipient's system claims the email content has + "yes": The recipient's system claims the email content has
been displayed to the recipient. Note, there is no been displayed to the recipient. Note, there is no
guarantee that the recipient has noticed, read, or guarantee that the recipient has noticed, read, or
understood the content. understood the content.
If an MDN is received for this recipient with Disposition-Type If an MDN is received for this recipient with Disposition-Type
(as per [RFC8098] section 3.2.6.2) equal to "displayed", this (as per [RFC8098] section 3.2.6.2) equal to "displayed", this
property SHOULD be set to "yes". The server MAY also set this property SHOULD be set to "yes". The server MAY also set this
property based on other feedback channels. property based on other feedback channels.
o *dsnBlobIds*: "Id[]" (server-set) A list of blob ids for DSNs o *dsnBlobIds*: "Id[]" (server-set) A list of blob ids for Delivery
received for this submission, in order of receipt, oldest first. Status Notifications ([RFC3464]) received for this submission, in
order of receipt, oldest first. The blob is the whole MIME
message (with a top-level content-type of multipart/report), as
received.
o *mdnBlobIds*: "Id[]" (server-set) A list of blob ids for MDNs o *mdnBlobIds*: "Id[]" (server-set) A list of blob ids for Message
received for this submission, in order of receipt, oldest first. Disposition Notifications ([RFC8098]) received for this
submission, in order of receipt, oldest first. The blob is the
whole MIME message (with a top-level content-type of multipart/
report), as received.
JMAP servers MAY choose not to expose DSN and MDN responses as Email JMAP servers MAY choose not to expose DSN and MDN responses as Email
objects if they correlate to a EmailSubmission object. It SHOULD objects if they correlate to an EmailSubmission object. It SHOULD
only do this if it exposes them in the _dsnBlobIds_ and _mdnblobIds_ only do this if it exposes them in the _dsnBlobIds_ and _mdnblobIds_
fields instead, and expects the user to be using clients capable of fields instead, and expects the user to be using clients capable of
fetching and displaying delivery status via the EmailSubmission fetching and displaying delivery status via the EmailSubmission
object. object.
For efficiency, a server MAY destroy EmailSubmission objects a For efficiency, a server MAY destroy EmailSubmission objects a
certain amount of time after the email is successfully sent or it has certain amount of time after the email is successfully sent or it has
finished retrying sending the email. For very basic SMTP proxies, finished retrying sending the email. For very basic SMTP proxies,
this MAY be immediately after creation, as it has no way to assign a this MAY be immediately after creation, as it has no way to assign a
real id and return the information again if fetched later. real id and return the information again if fetched later.
skipping to change at page 66, line 44 skipping to change at page 68, line 15
o *undoStatus*: "String" The EmailSubmission _undoStatus_ property o *undoStatus*: "String" The EmailSubmission _undoStatus_ property
must be identical to the value given to match the condition. must be identical to the value given to match the condition.
o *before*: "UTCDate" The _sendAt_ property of the EmailSubmission o *before*: "UTCDate" The _sendAt_ property of the EmailSubmission
object must be before this date-time to match the condition. object must be before this date-time to match the condition.
o *after*: "UTCDate" The _sendAt_ property of the EmailSubmission o *after*: "UTCDate" The _sendAt_ property of the EmailSubmission
object must be the same as or after this date-time to match the object must be the same as or after this date-time to match the
condition. condition.
A EmailSubmission object matches the filter if and only if all of the An EmailSubmission object matches the filter if and only if all of
given conditions given match. If zero properties are specified, it the given conditions match. If zero properties are specified, it is
is automatically "true" for all objects. automatically "true" for all objects.
The following properties MUST be supported for sorting: The following properties MUST be supported for sorting:
o "emailId" o "emailId"
o "threadId" o "threadId"
o "sentAt" o "sentAt"
7.4. EmailSubmission/queryChanges 7.4. EmailSubmission/queryChanges
Standard "/queryChanges" method. Standard "/queryChanges" method.
7.5. EmailSubmission/set 7.5. EmailSubmission/set
Standard "/set" method, with the following two extra arguments: Standard "/set" method, with the following two extra arguments:
skipping to change at page 67, line 45 skipping to change at page 69, line 18
creation succeeds, the email will be sent to the recipients given in creation succeeds, the email will be sent to the recipients given in
the envelope _rcptTo_ parameter. The server MUST remove any _Bcc_ the envelope _rcptTo_ parameter. The server MUST remove any _Bcc_
header present on the email during delivery. The server MAY add or header present on the email during delivery. The server MAY add or
remove other headers from the submitted email, or make further remove other headers from the submitted email, or make further
alterations in accordance with the server's policy during delivery. alterations in accordance with the server's policy during delivery.
If the referenced email is destroyed at any point after the If the referenced email is destroyed at any point after the
EmailSubmission object is created, this MUST NOT change the behaviour EmailSubmission object is created, this MUST NOT change the behaviour
of the email submission (i.e. it does not cancel a future send). of the email submission (i.e. it does not cancel a future send).
Similarly, destroying a EmailSubmission object MUST NOT affect the Similarly, destroying an EmailSubmission object MUST NOT affect the
deliveries it represents. It purely removes the record of the email deliveries it represents. It purely removes the record of the email
submission. The server MAY automatically destroy EmailSubmission submission. The server MAY automatically destroy EmailSubmission
objects after a certain time or in response to other triggers, and objects after a certain time or in response to other triggers, and
MAY forbid the client from manually destroying EmailSubmission MAY forbid the client from manually destroying EmailSubmission
objects. objects.
If the email to be sent is larger than the server supports sending, a If the email to be sent is larger than the server supports sending, a
standard "tooLarge" SetError MUST be returned. A _maxSize_ standard "tooLarge" SetError MUST be returned. A _maxSize_
"PositiveInt" property MUST be present on the SetError specifying the "PositiveInt" property MUST be present on the SetError specifying the
maximum size of an email that may be sent, in octets. maximum size of an email that may be sent, in octets.
skipping to change at page 68, line 45 skipping to change at page 70, line 16
o "forbiddenMailFrom" - The server does not permit the user to send o "forbiddenMailFrom" - The server does not permit the user to send
an email with the [RFC5321] envelope From. an email with the [RFC5321] envelope From.
o "forbiddenFrom" - The server does not permit the user to send an o "forbiddenFrom" - The server does not permit the user to send an
email with the [RFC5322] From header of the email to be sent. email with the [RFC5322] From header of the email to be sent.
o "forbiddenToSend" - The user does not have permission to send at o "forbiddenToSend" - The user does not have permission to send at
all right now for some reason. A _description_ "String" property all right now for some reason. A _description_ "String" property
MAY be present on the SetError object to display to the user why MAY be present on the SetError object to display to the user why
they are not permitted. The server MAY choose to localise this they are not permitted.
string into the user's preferred language, if known.
For *update*: For *update*:
o "cannotUnsend": The client attempted to update the _undoStatus_ of o "cannotUnsend": The client attempted to update the _undoStatus_ of
a valid EmailSubmission object from "pending" to "canceled", but a valid EmailSubmission object from "pending" to "canceled", but
the email cannot be unsent. the email cannot be unsent.
7.5.1. Example 7.5.1. Example
The following example presumes a draft of the message to be sent has The following example presumes a draft of the message to be sent has
skipping to change at page 69, line 45 skipping to change at page 71, line 36
"#k1490": { "#k1490": {
"mailboxIds/7cb4e8ee-df87-4757-b9c4-2ea1ca41b38e": null, "mailboxIds/7cb4e8ee-df87-4757-b9c4-2ea1ca41b38e": null,
"mailboxIds/73dbcb4b-bffc-48bd-8c2a-a2e91ca672f6": true, "mailboxIds/73dbcb4b-bffc-48bd-8c2a-a2e91ca672f6": true,
"keywords/$draft": null "keywords/$draft": null
} }
} }
}, "0" ]] }, "0" ]]
A successful response might look like this. Note there are two A successful response might look like this. Note there are two
responses due to the implicit Email/set call, but both have the same responses due to the implicit Email/set call, but both have the same
tag as they are due to the same call in the request: client id as they are due to the same call in the request:
[[ "EmailSubmission/set", { [[ "EmailSubmission/set", {
"accountId": "ue411d190", "accountId": "ue411d190",
"oldState": "012421s6-8nrq-4ps4-n0p4-9330r951ns21", "oldState": "012421s6-8nrq-4ps4-n0p4-9330r951ns21",
"newState": "355421f6-8aed-4cf4-a0c4-7377e951af36", "newState": "355421f6-8aed-4cf4-a0c4-7377e951af36",
"created": { "created": {
"k1490": { "k1490": {
"id": "3bab7f9a-623e-4acf-99a5-2e67facb02a0" "id": "3bab7f9a-623e-4acf-99a5-2e67facb02a0"
} }
} }
}, "0" ], }, "0" ],
[ "Email/set", { [ "Email/set", {
"accountId": "ue411d190", "accountId": "ue411d190",
"oldState": "778193", "oldState": "778193",
"newState": "778197", "newState": "778197",
"updated": { "updated": {
"M7f6ed5bcfd7e2604d1753f6c": null "M7f6ed5bcfd7e2604d1753f6c": null
} }
}, "0" ]] }, "0" ]]
If the email submission was not accepted on the other hand, the Suppose instead an admin has removed sending rights for the user, and
response may look like this: so the email submission is rejected with a "forbiddenToSend" error.
The description argument of the error is intended for display to the
user, so should be localised appropriately. Let's suppose the
request was sent with an Accept-Language header like this:
[[ "EmailSubmission/set", { Accept-Language: de;q=0.9,en;q=0.8
"accountId": "ue411d190",
"oldState": "012421s6-8nrq-4ps4-n0p4-9330r951ns21", The server should attempt to choose the best localisation from those
"newState": "012421s6-8nrq-4ps4-n0p4-9330r951ns21", it has available based on the Accept-Language header, as described in
"notCreated": { [I-D.ietf-jmap-core], section 3.7. If the server has English, French
"k1490": { and German translations it would choose German as the preferred
"type": "tooManyRecipients", language and return a response like this:
"maxRecipients": 10
}
}
}, "0" ]]
[[ "EmailSubmission/set", {
"accountId": "ue411d190",
"oldState": "012421s6-8nrq-4ps4-n0p4-9330r951ns21",
"newState": "012421s6-8nrq-4ps4-n0p4-9330r951ns21",
"notCreated": {
"k1490": {
"type": "forbiddenToSend",
"description": "Verzeihung, wegen verdaechtiger Aktivitaeten Ihres Benutzerkontos haben wir den Versand von Nachrichten gesperrt. Bitte wenden Sie sich fuer Hilfe an unser Support Team."
}
}
}, "0" ]]
8. Vacation response 8. Vacation response
A vacation response automatically sends a reply to messages sent to a A vacation response automatically sends a reply to messages sent to a
particular account, to inform the original sender that their message particular account, to inform the original sender that their message
may not be read for some time. Automated message sending can produce may not be read for some time. Automated message sending can produce
undesirable behaviour. To avoid this, implementors MUST follow the undesirable behaviour. To avoid this, implementors MUST follow the
recommendations set forth in [RFC3834]. recommendations set forth in [RFC3834].
The *VacationResponse* object represents the state of vacation- The *VacationResponse* object represents the state of vacation-
response related settings for an account. It has the following response related settings for an account. It has the following
skipping to change at page 71, line 24 skipping to change at page 73, line 35
vacation response. If "null", the vacation response is effective vacation response. If "null", the vacation response is effective
immediately. immediately.
o *toDate*: "UTCDate|null" If _isEnabled_ is "true", emails that o *toDate*: "UTCDate|null" If _isEnabled_ is "true", emails that
arrive before this date-time should receive the user's vacation arrive before this date-time should receive the user's vacation
response. If "null", the vacation response is effective response. If "null", the vacation response is effective
indefinitely. indefinitely.
o *subject*: "String|null" The subject that will be used by the o *subject*: "String|null" The subject that will be used by the
message sent in response to emails when the vacation response is message sent in response to emails when the vacation response is
enabled. If null, an appropriate subject SHOULD be set by the enabled. If "null", an appropriate subject SHOULD be set by the
server. server.
o *textBody*: "String|null" The plain text body to send in response o *textBody*: "String|null" The plain text body to send in response
to emails when the vacation response is enabled. If this is to emails when the vacation response is enabled. If this is
"null", when the vacation message is sent a plain-text body part "null", when the vacation message is sent a plain-text body part
SHOULD be generated from the _htmlBody_ but the server MAY choose SHOULD be generated from the _htmlBody_ but the server MAY choose
to send the response as HTML only. to send the response as HTML only. If both _textBody_ and
_htmlBody_ are "null", an appropriate default body SHOULD be
generated for responses by the server.
o *htmlBody*: "String|null" The HTML body to send in response to o *htmlBody*: "String|null" The HTML body to send in response to
emails when the vacation response is enabled. If this is "null", emails when the vacation response is enabled. If this is "null",
when the vacation message is sent an HTML body part MAY be when the vacation message is sent an HTML body part MAY be
generated from the _textBody_, or the server MAY choose to send generated from the _textBody_, or the server MAY choose to send
the response as plain-text only. the response as plain-text only.
The following JMAP methods are supported: The following JMAP methods are supported:
8.1. VacationResponse/get 8.1. VacationResponse/get
skipping to change at page 72, line 7 skipping to change at page 74, line 20
There MUST only be exactly one VacationResponse object in an account. There MUST only be exactly one VacationResponse object in an account.
It MUST have the id "singleton". It MUST have the id "singleton".
8.2. VacationResponse/set 8.2. VacationResponse/set
Standard "/set" method. Standard "/set" method.
9. Security considerations 9. Security considerations
All security considerations of JMAP (RFC XXXX) apply to this All security considerations of JMAP ([I-D.ietf-jmap-core]) apply to
specification. this specification.
9.1. EmailBodyPart value 9.1. EmailBodyPart value
Service providers typically perform security filtering on incoming Service providers typically perform security filtering on incoming
email and it's important the detection of content-type and charset email and it's important that the detection of content-type and
for the security filter aligns with the heuristics performed by JMAP charset for the security filter aligns with the heuristics performed
servers. Servers that apply heuristics to determine the content-type by JMAP servers. Servers that apply heuristics to determine the
or charset for _EmailBodyValue_ SHOULD document the heuristics and content-type or charset for _EmailBodyValue_ SHOULD document the
provide a mechanism to turn them off in the event they are misaligned heuristics and provide a mechanism to turn them off in the event they
with the security filter used at a particular mailbox host. are misaligned with the security filter used at a particular mailbox
host.
Automatic conversion of charsets that allow hidden channels for ASCII Automatic conversion of charsets that allow hidden channels for ASCII
text, such as UTF-7, have been problematic for security filters in text, such as UTF-7, have been problematic for security filters in
the past so server implementations can mitigate this risk by having the past so server implementations can mitigate this risk by having
such conversions off-by-default and/or separately configurable. such conversions off-by-default and/or separately configurable.
To allow the client to restrict the volume of data it can receive in To allow the client to restrict the volume of data it can receive in
response to a request, a maximum length may be requested for the data response to a request, a maximum length may be requested for the data
returned for a textual body part. However, truncating the data may returned for a textual body part. However, truncating the data may
change the semantic meaning, for example truncating a URL changes its change the semantic meaning, for example truncating a URL changes its
skipping to change at page 75, line 5 skipping to change at page 77, line 17
9.3. Email submission 9.3. Email submission
SMTP submission servers [RFC6409] use a number of mechanisms to SMTP submission servers [RFC6409] use a number of mechanisms to
mitigate damage caused by compromised user accounts and end-user mitigate damage caused by compromised user accounts and end-user
systems including rate limiting, anti-virus/anti-spam milters and systems including rate limiting, anti-virus/anti-spam milters and
other technologies. The technologies work better when they have more other technologies. The technologies work better when they have more
information about the client connection. If JMAP email submission is information about the client connection. If JMAP email submission is
implemented as a proxy to an SMTP Submission server, it is useful to implemented as a proxy to an SMTP Submission server, it is useful to
communicate this information from the JMAP proxy to the submission communicate this information from the JMAP proxy to the submission
server. The de-facto XCLIENT extension to SMTP server. The de-facto [XCLIENT] extension to SMTP can be used to do
<http://www.postfix.org/XCLIENT_README.html> can be used to do this, this, but use of an authenticated channel is recommended to limit use
but use of an authenticated channel is recommended to limit use of of that extension to explicitly authorized proxies.
that extension to explicitly authorized proxies.
JMAP servers that proxy to an SMTP Submission server SHOULD allow use JMAP servers that proxy to an SMTP Submission server SHOULD allow use
of the _submissions_ port [RFC8314] and SHOULD implement SASL PLAIN of the _submissions_ port [RFC8314] and SHOULD implement SASL PLAIN
over TLS [RFC4616] and/or TLS client certificate authentication with over TLS [RFC4616] and/or TLS client certificate authentication with
SASL EXTERNAL [RFC4422] appendix A. Implementation of a mechanism SASL EXTERNAL [RFC4422] appendix A. Implementation of a mechanism
similar to SMTP XCLIENT is strongly encouraged. similar to SMTP XCLIENT is strongly encouraged.
In the event the JMAP server directly relays mail to SMTP servers in In the event the JMAP server directly relays mail to SMTP servers in
other administrative domains, then implementation of the de-facto other administrative domains, then implementation of the de-facto
milter protocol is strongly encouraged to integrate with third-party milter protocol is strongly encouraged to integrate with third-party
skipping to change at page 80, line 21 skipping to change at page 82, line 28
this when submitting a reply or answer to the message. It may be set this when submitting a reply or answer to the message. It may be set
by the EmailSubmission/set operation with an onSuccessUpdateEmail by the EmailSubmission/set operation with an onSuccessUpdateEmail
attribute. In a mailstore shared by JMAP and IMAP, this is also set attribute. In a mailstore shared by JMAP and IMAP, this is also set
and cleared as necessary so it matches the IMAP \Answered flag. and cleared as necessary so it matches the IMAP \Answered flag.
Related keywords: None Related keywords: None
Related IMAP/JMAP Capabilities: None Related IMAP/JMAP Capabilities: None
Security Considerations: A server implementing this keyword as a Security Considerations: A server implementing this keyword as a
shared keyword may disclose that a user considers the message as shared keyword may disclose that a user has replied to a message.
flagged for urgent/special attention. This information would be This information would be exposed to other users with read permission
exposed to other users with read permission for the mailbox keywords. for the mailbox keywords.
Published specification (recommended): this document Published specification (recommended): this document
Person & email address to contact for further information: (editor- Person & email address to contact for further information: (editor-
contact-goes-here) contact-goes-here)
Intended usage: COMMON Intended usage: COMMON
Owner/Change controller: IESG Owner/Change controller: IESG
skipping to change at page 81, line 21 skipping to change at page 83, line 28
Description: New mail is delivered here by default. Description: New mail is delivered here by default.
Reference: This document, section 10.5. Reference: This document, section 10.5.
Usage Notes: JMAP only Usage Notes: JMAP only
10.6. JMAP Error Codes registry 10.6. JMAP Error Codes registry
The following sub-sections register several new error codes in the The following sub-sections register several new error codes in the
JMAP Error Codes registry, as defined in RFC XXXX. JMAP Error Codes registry, as defined in [I-D.ietf-jmap-core].
10.6.1. mailboxHasChild 10.6.1. mailboxHasChild
JMAP Error Code: mailboxHasChild JMAP Error Code: mailboxHasChild
Intended use: common Intended use: common
Change controller: IETF Change controller: IETF
Reference: This document, section 2.5 Reference: This document, section 2.5
skipping to change at page 83, line 41 skipping to change at page 86, line 4
Change controller: IETF Change controller: IETF
Reference: This document, sections 6.3 and 7.5 Reference: This document, sections 6.3 and 7.5
10.6.12. forbiddenToSend 10.6.12. forbiddenToSend
JMAP Error Code: forbiddenToSend JMAP Error Code: forbiddenToSend
Intended use: common Intended use: common
Change controller: IETF Change controller: IETF
Reference: This document, section 7.5 Reference: This document, section 7.5
11. References 11. References
11.1. Normative References 11.1. Normative References
[HTML] Berners-Lee et al., T., "HTML Standard", 2019,
<https://html.spec.whatwg.org/>.
[I-D.ietf-jmap-core]
Jenkins, N. and C. Newman, "JSON Meta Application
Protocol", draft-ietf-jmap-core-12 (work in progress),
December 2018.
[RFC1870] Klensin, J., Freed, N., and K. Moore, "SMTP Service [RFC1870] Klensin, J., Freed, N., and K. Moore, "SMTP Service
Extension for Message Size Declaration", STD 10, RFC 1870, Extension for Message Size Declaration", STD 10, RFC 1870,
DOI 10.17487/RFC1870, November 1995, DOI 10.17487/RFC1870, November 1995,
<https://www.rfc-editor.org/info/rfc1870>. <https://www.rfc-editor.org/info/rfc1870>.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
<https://www.rfc-editor.org/info/rfc2045>. <https://www.rfc-editor.org/info/rfc2045>.
skipping to change at page 84, line 36 skipping to change at page 87, line 5
[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded
Word Extensions: Character Sets, Languages, and Word Extensions: Character Sets, Languages, and
Continuations", RFC 2231, DOI 10.17487/RFC2231, November Continuations", RFC 2231, DOI 10.17487/RFC2231, November
1997, <https://www.rfc-editor.org/info/rfc2231>. 1997, <https://www.rfc-editor.org/info/rfc2231>.
[RFC2369] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax [RFC2369] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax
for Core Mail List Commands and their Transport through for Core Mail List Commands and their Transport through
Message Header Fields", RFC 2369, DOI 10.17487/RFC2369, Message Header Fields", RFC 2369, DOI 10.17487/RFC2369,
July 1998, <https://www.rfc-editor.org/info/rfc2369>. July 1998, <https://www.rfc-editor.org/info/rfc2369>.
[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource
Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998,
<https://www.rfc-editor.org/info/rfc2392>.
[RFC2557] Palme, J., Hopmann, A., and N. Shelness, "MIME [RFC2557] Palme, J., Hopmann, A., and N. Shelness, "MIME
Encapsulation of Aggregate Documents, such as HTML Encapsulation of Aggregate Documents, such as HTML
(MHTML)", RFC 2557, DOI 10.17487/RFC2557, March 1999, (MHTML)", RFC 2557, DOI 10.17487/RFC2557, March 1999,
<https://www.rfc-editor.org/info/rfc2557>. <https://www.rfc-editor.org/info/rfc2557>.
[RFC2852] Newman, D., "Deliver By SMTP Service Extension", RFC 2852, [RFC2852] Newman, D., "Deliver By SMTP Service Extension", RFC 2852,
DOI 10.17487/RFC2852, June 2000, DOI 10.17487/RFC2852, June 2000,
<https://www.rfc-editor.org/info/rfc2852>. <https://www.rfc-editor.org/info/rfc2852>.
[RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282, [RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282,
skipping to change at page 85, line 23 skipping to change at page 87, line 40
[RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format
for Delivery Status Notifications", RFC 3464, for Delivery Status Notifications", RFC 3464,
DOI 10.17487/RFC3464, January 2003, DOI 10.17487/RFC3464, January 2003,
<https://www.rfc-editor.org/info/rfc3464>. <https://www.rfc-editor.org/info/rfc3464>.
[RFC3834] Moore, K., "Recommendations for Automatic Responses to [RFC3834] Moore, K., "Recommendations for Automatic Responses to
Electronic Mail", RFC 3834, DOI 10.17487/RFC3834, August Electronic Mail", RFC 3834, DOI 10.17487/RFC3834, August
2004, <https://www.rfc-editor.org/info/rfc3834>. 2004, <https://www.rfc-editor.org/info/rfc3834>.
[RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension",
RFC 4314, DOI 10.17487/RFC4314, December 2005,
<https://www.rfc-editor.org/info/rfc4314>.
[RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
Authentication and Security Layer (SASL)", RFC 4422, Authentication and Security Layer (SASL)", RFC 4422,
DOI 10.17487/RFC4422, June 2006, DOI 10.17487/RFC4422, June 2006,
<https://www.rfc-editor.org/info/rfc4422>. <https://www.rfc-editor.org/info/rfc4422>.
[RFC4616] Zeilenga, K., Ed., "The PLAIN Simple Authentication and [RFC4616] Zeilenga, K., Ed., "The PLAIN Simple Authentication and
Security Layer (SASL) Mechanism", RFC 4616, Security Layer (SASL) Mechanism", RFC 4616,
DOI 10.17487/RFC4616, August 2006, DOI 10.17487/RFC4616, August 2006,
<https://www.rfc-editor.org/info/rfc4616>. <https://www.rfc-editor.org/info/rfc4616>.
skipping to change at page 87, line 9 skipping to change at page 89, line 28
[RFC8457] Leiba, B., Ed., "IMAP "$Important" Keyword and [RFC8457] Leiba, B., Ed., "IMAP "$Important" Keyword and
"\Important" Special-Use Attribute", RFC 8457, "\Important" Special-Use Attribute", RFC 8457,
DOI 10.17487/RFC8457, September 2018, DOI 10.17487/RFC8457, September 2018,
<https://www.rfc-editor.org/info/rfc8457>. <https://www.rfc-editor.org/info/rfc8457>.
[RFC8474] Gondwana, B., Ed., "IMAP Extension for Object [RFC8474] Gondwana, B., Ed., "IMAP Extension for Object
Identifiers", RFC 8474, DOI 10.17487/RFC8474, September Identifiers", RFC 8474, DOI 10.17487/RFC8474, September
2018, <https://www.rfc-editor.org/info/rfc8474>. 2018, <https://www.rfc-editor.org/info/rfc8474>.
11.2. URIs [XCLIENT] Postfix, "Postfix XCLIENT Howto", 2019,
<http://www.postfix.org/XCLIENT_README.html>.
11.2. Informative References
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
<https://www.rfc-editor.org/info/rfc3501>.
11.3. URIs
[1] https://www.iana.org/assignments/imap-mailbox-name-attributes/ [1] https://www.iana.org/assignments/imap-mailbox-name-attributes/
imap-mailbox-name-attributes.xhtml imap-mailbox-name-attributes.xhtml
[2] https://www.iana.org/assignments/imap-keywords/imap- [2] https://www.iana.org/assignments/imap-keywords/imap-
keywords.xhtml keywords.xhtml
[3] https://www.w3.org/TR/CSP3/ [3] https://www.w3.org/TR/CSP3/
[4] https://www.w3.org/TR/referrer-policy/ [4] https://www.w3.org/TR/referrer-policy/
 End of changes. 70 change blocks. 
201 lines changed or deleted 282 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/