Internet Engineering Task Force (IETF) N. Jenkins
Request for Comments: 8621 Fastmail
Updates: 5788 C. Newman
Category: Standards Track Oracle
ISSN: 2070-1721 August 2019
Internet Engineering Task Force (IETF) N. Jenkins
Request for Comments: 8621 Fastmail
Updates: 5788 C. Newman
Category: Standards Track Oracle
ISSN: 2070-1721 August 2019
The JSON Meta Application Protocol (JMAP) for Mail
邮件的JSON元应用程序协议（JMAP）
Abstract
摘要
This document specifies a data model for synchronising email data with a server using the JSON Meta Application Protocol (JMAP). Clients can use this to efficiently search, access, organise, and send messages, and to get push notifications for fast resynchronisation when new messages are delivered or a change is made in another client.
本文档指定了使用JSON元应用程序协议（JMAP）与服务器同步电子邮件数据的数据模型。客户端可以使用此功能高效地搜索、访问、组织和发送消息，并在传递新消息或在另一个客户端中进行更改时获取推送通知以实现快速重新同步。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8621.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8621.
Copyright Notice
版权公告
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
版权（c）2019 IETF信托基金和被确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Additions to the Capabilities Object . . . . . . . . . . 5
1.3.1. urn:ietf:params:jmap:mail . . . . . . . . . . . . . . 5
1.3.2. urn:ietf:params:jmap:submission . . . . . . . . . . . 7
1.3.3. urn:ietf:params:jmap:vacationresponse . . . . . . . . 8
1.4. Data Type Support in Different Accounts . . . . . . . . . 8
1.5. Push . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.5.1. Example . . . . . . . . . . . . . . . . . . . . . . . 9
1.6. Ids . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2. Mailboxes . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1. Mailbox/get . . . . . . . . . . . . . . . . . . . . . . . 14
2.2. Mailbox/changes . . . . . . . . . . . . . . . . . . . . . 14
2.3. Mailbox/query . . . . . . . . . . . . . . . . . . . . . . 14
2.4. Mailbox/queryChanges . . . . . . . . . . . . . . . . . . 15
2.5. Mailbox/set . . . . . . . . . . . . . . . . . . . . . . . 16
2.6. Example . . . . . . . . . . . . . . . . . . . . . . . . . 17
3. Threads . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.1. Thread/get . . . . . . . . . . . . . . . . . . . . . . . 22
3.1.1. Example . . . . . . . . . . . . . . . . . . . . . . . 22
3.2. Thread/changes . . . . . . . . . . . . . . . . . . . . . 22
4. Emails . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1. Properties of the Email Object . . . . . . . . . . . . . 23
4.1.1. Metadata . . . . . . . . . . . . . . . . . . . . . . 24
4.1.2. Header Fields Parsed Forms . . . . . . . . . . . . . 26
4.1.3. Header Fields Properties . . . . . . . . . . . . . . 32
4.1.4. Body Parts . . . . . . . . . . . . . . . . . . . . . 35
4.2. Email/get . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2.1. Example . . . . . . . . . . . . . . . . . . . . . . . 44
4.3. Email/changes . . . . . . . . . . . . . . . . . . . . . . 45
4.4. Email/query . . . . . . . . . . . . . . . . . . . . . . . 45
4.4.1. Filtering . . . . . . . . . . . . . . . . . . . . . . 46
4.4.2. Sorting . . . . . . . . . . . . . . . . . . . . . . . 49
4.4.3. Thread Collapsing . . . . . . . . . . . . . . . . . . 50
4.5. Email/queryChanges . . . . . . . . . . . . . . . . . . . 51
4.6. Email/set . . . . . . . . . . . . . . . . . . . . . . . . 51
4.7. Email/copy . . . . . . . . . . . . . . . . . . . . . . . 53
4.8. Email/import . . . . . . . . . . . . . . . . . . . . . . 54
4.9. Email/parse . . . . . . . . . . . . . . . . . . . . . . . 56
4.10. Examples . . . . . . . . . . . . . . . . . . . . . . . . 58
5. Search Snippets . . . . . . . . . . . . . . . . . . . . . . . 68
5.1. SearchSnippet/get . . . . . . . . . . . . . . . . . . . . 69
5.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 71
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Additions to the Capabilities Object . . . . . . . . . . 5
1.3.1. urn:ietf:params:jmap:mail . . . . . . . . . . . . . . 5
1.3.2. urn:ietf:params:jmap:submission . . . . . . . . . . . 7
1.3.3. urn:ietf:params:jmap:vacationresponse . . . . . . . . 8
1.4. Data Type Support in Different Accounts . . . . . . . . . 8
1.5. Push . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.5.1. Example . . . . . . . . . . . . . . . . . . . . . . . 9
1.6. Ids . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2. Mailboxes . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1. Mailbox/get . . . . . . . . . . . . . . . . . . . . . . . 14
2.2. Mailbox/changes . . . . . . . . . . . . . . . . . . . . . 14
2.3. Mailbox/query . . . . . . . . . . . . . . . . . . . . . . 14
2.4. Mailbox/queryChanges . . . . . . . . . . . . . . . . . . 15
2.5. Mailbox/set . . . . . . . . . . . . . . . . . . . . . . . 16
2.6. Example . . . . . . . . . . . . . . . . . . . . . . . . . 17
3. Threads . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.1. Thread/get . . . . . . . . . . . . . . . . . . . . . . . 22
3.1.1. Example . . . . . . . . . . . . . . . . . . . . . . . 22
3.2. Thread/changes . . . . . . . . . . . . . . . . . . . . . 22
4. Emails . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1. Properties of the Email Object . . . . . . . . . . . . . 23
4.1.1. Metadata . . . . . . . . . . . . . . . . . . . . . . 24
4.1.2. Header Fields Parsed Forms . . . . . . . . . . . . . 26
4.1.3. Header Fields Properties . . . . . . . . . . . . . . 32
4.1.4. Body Parts . . . . . . . . . . . . . . . . . . . . . 35
4.2. Email/get . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2.1. Example . . . . . . . . . . . . . . . . . . . . . . . 44
4.3. Email/changes . . . . . . . . . . . . . . . . . . . . . . 45
4.4. Email/query . . . . . . . . . . . . . . . . . . . . . . . 45
4.4.1. Filtering . . . . . . . . . . . . . . . . . . . . . . 46
4.4.2. Sorting . . . . . . . . . . . . . . . . . . . . . . . 49
4.4.3. Thread Collapsing . . . . . . . . . . . . . . . . . . 50
4.5. Email/queryChanges . . . . . . . . . . . . . . . . . . . 51
4.6. Email/set . . . . . . . . . . . . . . . . . . . . . . . . 51
4.7. Email/copy . . . . . . . . . . . . . . . . . . . . . . . 53
4.8. Email/import . . . . . . . . . . . . . . . . . . . . . . 54
4.9. Email/parse . . . . . . . . . . . . . . . . . . . . . . . 56
4.10. Examples . . . . . . . . . . . . . . . . . . . . . . . . 58
5. Search Snippets . . . . . . . . . . . . . . . . . . . . . . . 68
5.1. SearchSnippet/get . . . . . . . . . . . . . . . . . . . . 69
5.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 71
6. Identities . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.1. Identity/get . . . . . . . . . . . . . . . . . . . . . . 73
6.2. Identity/changes . . . . . . . . . . . . . . . . . . . . 73
6.3. Identity/set . . . . . . . . . . . . . . . . . . . . . . 73
6.4. Example . . . . . . . . . . . . . . . . . . . . . . . . . 73
7. Email Submission . . . . . . . . . . . . . . . . . . . . . . 74
7.1. EmailSubmission/get . . . . . . . . . . . . . . . . . . . 80
7.2. EmailSubmission/changes . . . . . . . . . . . . . . . . . 80
7.3. EmailSubmission/query . . . . . . . . . . . . . . . . . . 80
7.4. EmailSubmission/queryChanges . . . . . . . . . . . . . . 81
7.5. EmailSubmission/set . . . . . . . . . . . . . . . . . . . 81
7.5.1. Example . . . . . . . . . . . . . . . . . . . . . . . 84
8. Vacation Response . . . . . . . . . . . . . . . . . . . . . . 86
8.1. VacationResponse/get . . . . . . . . . . . . . . . . . . 87
8.2. VacationResponse/set . . . . . . . . . . . . . . . . . . 88
9. Security Considerations . . . . . . . . . . . . . . . . . . . 88
9.1. EmailBodyPart Value . . . . . . . . . . . . . . . . . . . 88
9.2. HTML Email Display . . . . . . . . . . . . . . . . . . . 88
9.3. Multiple Part Display . . . . . . . . . . . . . . . . . . 91
9.4. Email Submission . . . . . . . . . . . . . . . . . . . . 91
9.5. Partial Account Access . . . . . . . . . . . . . . . . . 92
9.6. Permission to Send from an Address . . . . . . . . . . . 92
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 93
10.1. JMAP Capability Registration for "mail" . . . . . . . . 93
10.2. JMAP Capability Registration for "submission" . . . . . 93
10.3. JMAP Capability Registration for "vacationresponse" . . 94
10.4. IMAP and JMAP Keywords Registry . . . . . . . . . . . . 94
10.4.1. Registration of JMAP Keyword "$draft" . . . . . . . 95
10.4.2. Registration of JMAP Keyword "$seen" . . . . . . . . 96
10.4.3. Registration of JMAP Keyword "$flagged" . . . . . . 97
10.4.4. Registration of JMAP Keyword "$answered" . . . . . . 98
10.4.5. Registration of "$recent" Keyword . . . . . . . . . 99
10.5. IMAP Mailbox Name Attributes Registry . . . . . . . . . 99
10.5.1. Registration of "inbox" Role . . . . . . . . . . . . 99
10.6. JMAP Error Codes Registry . . . . . . . . . . . . . . . 100
10.6.1. mailboxHasChild . . . . . . . . . . . . . . . . . . 100
10.6.2. mailboxHasEmail . . . . . . . . . . . . . . . . . . 100
10.6.3. blobNotFound . . . . . . . . . . . . . . . . . . . . 100
10.6.4. tooManyKeywords . . . . . . . . . . . . . . . . . . 101
10.6.5. tooManyMailboxes . . . . . . . . . . . . . . . . . . 101
10.6.6. invalidEmail . . . . . . . . . . . . . . . . . . . . 101
10.6.7. tooManyRecipients . . . . . . . . . . . . . . . . . 102
10.6.8. noRecipients . . . . . . . . . . . . . . . . . . . . 102
10.6.9. invalidRecipients . . . . . . . . . . . . . . . . . 102
10.6.10. forbiddenMailFrom . . . . . . . . . . . . . . . . . 103
10.6.11. forbiddenFrom . . . . . . . . . . . . . . . . . . . 103
10.6.12. forbiddenToSend . . . . . . . . . . . . . . . . . . 103
6. Identities . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.1. Identity/get . . . . . . . . . . . . . . . . . . . . . . 73
6.2. Identity/changes . . . . . . . . . . . . . . . . . . . . 73
6.3. Identity/set . . . . . . . . . . . . . . . . . . . . . . 73
6.4. Example . . . . . . . . . . . . . . . . . . . . . . . . . 73
7. Email Submission . . . . . . . . . . . . . . . . . . . . . . 74
7.1. EmailSubmission/get . . . . . . . . . . . . . . . . . . . 80
7.2. EmailSubmission/changes . . . . . . . . . . . . . . . . . 80
7.3. EmailSubmission/query . . . . . . . . . . . . . . . . . . 80
7.4. EmailSubmission/queryChanges . . . . . . . . . . . . . . 81
7.5. EmailSubmission/set . . . . . . . . . . . . . . . . . . . 81
7.5.1. Example . . . . . . . . . . . . . . . . . . . . . . . 84
8. Vacation Response . . . . . . . . . . . . . . . . . . . . . . 86
8.1. VacationResponse/get . . . . . . . . . . . . . . . . . . 87
8.2. VacationResponse/set . . . . . . . . . . . . . . . . . . 88
9. Security Considerations . . . . . . . . . . . . . . . . . . . 88
9.1. EmailBodyPart Value . . . . . . . . . . . . . . . . . . . 88
9.2. HTML Email Display . . . . . . . . . . . . . . . . . . . 88
9.3. Multiple Part Display . . . . . . . . . . . . . . . . . . 91
9.4. Email Submission . . . . . . . . . . . . . . . . . . . . 91
9.5. Partial Account Access . . . . . . . . . . . . . . . . . 92
9.6. Permission to Send from an Address . . . . . . . . . . . 92
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 93
10.1. JMAP Capability Registration for "mail" . . . . . . . . 93
10.2. JMAP Capability Registration for "submission" . . . . . 93
10.3. JMAP Capability Registration for "vacationresponse" . . 94
10.4. IMAP and JMAP Keywords Registry . . . . . . . . . . . . 94
10.4.1. Registration of JMAP Keyword "$draft" . . . . . . . 95
10.4.2. Registration of JMAP Keyword "$seen" . . . . . . . . 96
10.4.3. Registration of JMAP Keyword "$flagged" . . . . . . 97
10.4.4. Registration of JMAP Keyword "$answered" . . . . . . 98
10.4.5. Registration of "$recent" Keyword . . . . . . . . . 99
10.5. IMAP Mailbox Name Attributes Registry . . . . . . . . . 99
10.5.1. Registration of "inbox" Role . . . . . . . . . . . . 99
10.6. JMAP Error Codes Registry . . . . . . . . . . . . . . . 100
10.6.1. mailboxHasChild . . . . . . . . . . . . . . . . . . 100
10.6.2. mailboxHasEmail . . . . . . . . . . . . . . . . . . 100
10.6.3. blobNotFound . . . . . . . . . . . . . . . . . . . . 100
10.6.4. tooManyKeywords . . . . . . . . . . . . . . . . . . 101
10.6.5. tooManyMailboxes . . . . . . . . . . . . . . . . . . 101
10.6.6. invalidEmail . . . . . . . . . . . . . . . . . . . . 101
10.6.7. tooManyRecipients . . . . . . . . . . . . . . . . . 102
10.6.8. noRecipients . . . . . . . . . . . . . . . . . . . . 102
10.6.9. invalidRecipients . . . . . . . . . . . . . . . . . 102
10.6.10. forbiddenMailFrom . . . . . . . . . . . . . . . . . 103
10.6.11. forbiddenFrom . . . . . . . . . . . . . . . . . . . 103
10.6.12. forbiddenToSend . . . . . . . . . . . . . . . . . . 103
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 104
11.1. Normative References . . . . . . . . . . . . . . . . . . 104
11.2. Informative References . . . . . . . . . . . . . . . . . 107
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 108
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 104
11.1. Normative References . . . . . . . . . . . . . . . . . . 104
11.2. Informative References . . . . . . . . . . . . . . . . . 107
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 108
The JSON Meta Application Protocol (JMAP) [RFC8620] is a generic protocol for synchronising data, such as mail, calendars, or contacts between a client and a server. It is optimised for mobile and web environments and aims to provide a consistent interface to different data types.
JSON元应用程序协议（JMAP）[RFC8620]是一种通用协议，用于在客户端和服务器之间同步数据，如邮件、日历或联系人。它针对移动和web环境进行了优化，旨在为不同的数据类型提供一致的接口。
This specification defines a data model for accessing a mail store over JMAP, allowing you to query, read, organise, and submit mail for sending.
此规范定义了通过JMAP访问邮件存储的数据模型，允许您查询、读取、组织和提交要发送的邮件。
The data model is designed to allow a server to provide consistent access to the same data via IMAP [RFC3501] as well as JMAP. As in IMAP, a message must belong to a mailbox; however, in JMAP, its id does not change if you move it between mailboxes, and the server may allow it to belong to multiple mailboxes simultaneously (often exposed in a user agent as labels rather than folders).
数据模型旨在允许服务器通过IMAP[RFC3501]和JMAP提供对相同数据的一致访问。在IMAP中，邮件必须属于邮箱；但是，在JMAP中，如果在邮箱之间移动它，它的id不会改变，服务器可能会允许它同时属于多个邮箱（通常在用户代理中作为标签而不是文件夹公开）。
As in IMAP, messages may also be assigned zero or more keywords: short arbitrary strings. These are primarily intended to store metadata to inform client display, such as unread status or whether a message has been replied to. An IANA registry allows common semantics to be shared between clients and extended easily in the future.
与IMAP一样，消息也可能被分配零个或多个关键字：短的任意字符串。它们主要用于存储元数据以通知客户端显示，例如未读状态或消息是否已回复。IANA注册中心允许在客户端之间共享通用语义，并在将来方便地进行扩展。
A message and its replies are linked on the server by a common Thread id. Clients may fetch the list of messages with a particular Thread id to more easily present a threaded or conversational interface.
消息及其回复在服务器上通过公共线程id链接。客户端可以获取具有特定线程id的消息列表，以便更轻松地呈现线程或对话接口。
Permissions for message access happen on a per-mailbox basis. Servers may give the user restricted permissions for certain mailboxes, for example, if another user's inbox has been shared as read-only with them.
邮件访问权限基于每个邮箱。服务器可能会向用户授予某些邮箱的受限权限，例如，如果另一个用户的收件箱已以只读方式与他们共享。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
Type signatures, examples, and property descriptions in this document follow the conventions established in Section 1.1 of [RFC8620]. Data types defined in the core specification are also used in this document.
本文件中的类型签名、示例和属性描述遵循[RFC8620]第1.1节中规定的约定。本文档中还使用了核心规范中定义的数据类型。
Servers MUST support all properties specified for the new data types defined in this document.
服务器必须支持为此文档中定义的新数据类型指定的所有属性。
This document uses the same terminology as in the core JMAP specification.
本文档使用与核心JMAP规范中相同的术语。
The terms Mailbox, Thread, Email, SearchSnippet, EmailSubmission and VacationResponse (with that specific capitalisation) are used to refer to the data types defined in this document and instances of those data types.
术语Mailbox、Thread、Email、SearchSnippet、EmailSubmission和VacationResponse（具有特定的大写字母）用于指代本文档中定义的数据类型以及这些数据类型的实例。
The term message refers to a document in Internet Message Format, as described in [RFC5322]. The Email data type represents messages in the mail store and associated metadata.
术语消息是指互联网消息格式的文档，如[RFC5322]所述。电子邮件数据类型表示邮件存储和关联元数据中的邮件。
The capabilities object is returned as part of the JMAP Session object; see [RFC8620], Section 2.
capabilities对象作为JMAP会话对象的一部分返回；见[RFC8620]，第2节。
This document defines three additional capability URIs.
本文档定义了三个附加功能URI。
This represents support for the Mailbox, Thread, Email, and SearchSnippet data types and associated API methods. The value of this property in the JMAP session "capabilities" property is an empty object.
这表示对邮箱、线程、电子邮件和SearchSnippet数据类型以及相关API方法的支持。JMAP会话“capabilities”属性中此属性的值为空对象。
The value of this property in an account's "accountCapabilities" property is an object that MUST contain the following information on server capabilities and permissions for that account:
帐户“accountCapabilities”属性中此属性的值是一个对象，该对象必须包含有关该帐户的服务器功能和权限的以下信息：
o maxMailboxesPerEmail: "UnsignedInt|null"
o MaxMailboxesPerMail:“未签名|空”
The maximum number of Mailboxes (see Section 2) that can be can assigned to a single Email object (see Section 4). This MUST be an integer >= 1, or null for no limit (or rather, the limit is always the number of Mailboxes in the account).
可分配给单个电子邮件对象的最大邮箱数（请参见第2节）（请参见第4节）。这必须是一个大于等于1的整数，或者为空表示没有限制（或者说，限制始终是帐户中的邮箱数）。
o maxMailboxDepth: "UnsignedInt|null"
o maxMailboxDepth:“UnsignedInt | null”
The maximum depth of the Mailbox hierarchy (i.e., one more than the maximum number of ancestors a Mailbox may have), or null for no limit.
邮箱层次结构的最大深度（即，比邮箱的最大祖先数多一个），或null表示无限制。
o maxSizeMailboxName: "UnsignedInt"
o MaxSizeEmailBoxName:“未签名”
The maximum length, in (UTF-8) octets, allowed for the name of a Mailbox. This MUST be at least 100, although it is recommended servers allow more.
邮箱名称允许的最大长度（UTF-8）八位字节。这必须至少为100，尽管建议服务器允许更多。
o maxSizeAttachmentsPerEmail: "UnsignedInt"
o maxSizeAttachmentsPerEmail：“未签名”
The maximum total size of attachments, in octets, allowed for a single Email object. A server MAY still reject the import or creation of an Email with a lower attachment size total (for example, if the body includes several megabytes of text, causing the size of the encoded MIME structure to be over some server-defined limit).
单个电子邮件对象允许的最大附件总大小（以八位字节为单位）。服务器仍可能拒绝导入或创建附件总大小较低的电子邮件（例如，如果正文包含数兆字节的文本，则会导致已编码MIME结构的大小超过某些服务器定义的限制）。
Note that this limit is for the sum of unencoded attachment sizes. Users are generally not knowledgeable about encoding overhead, etc., nor should they need to be, so marketing and help materials normally tell them the "max size attachments". This is the unencoded size they see on their hard drive, so this capability matches that and allows the client to consistently enforce what the user understands as the limit.
请注意，此限制适用于未编码附件尺寸的总和。用户通常不了解编码开销等，也不需要了解，因此营销和帮助材料通常会告诉他们“最大附件大小”。这是他们在硬盘上看到的未编码大小，因此此功能与之匹配，并允许客户端一致地强制执行用户理解为限制的内容。
The server may separately have a limit for the total size of the message [RFC5322], created by combining the attachments (often base64 encoded) with the message headers and bodies. For example, suppose the server advertises "maxSizeAttachmentsPerEmail: 50000000" (50 MB). The enforced server limit may be for a message size of 70000000 octets. Even with base64 encoding and a 2 MB HTML body, 50 MB attachments would fit under this limit.
服务器可能单独限制消息[RFC5322]的总大小，该消息是通过将附件（通常是base64编码的）与消息头和消息体组合而创建的。例如，假设服务器播发“MaxSizeAttachmentsPreMail:50000000”（50MB）。强制服务器限制可能适用于7000000个八位字节的消息大小。即使使用base64编码和2MB HTML正文，50MB的附件也可以满足此限制。
o emailQuerySortOptions: "String[]"
o emailQuerySortOptions:“字符串[]”
A list of all the values the server supports for the "property" field of the Comparator object in an "Email/query" sort (see Section 4.4.2). This MAY include properties the client does not recognise (for example, custom properties specified in a vendor extension). Clients MUST ignore any unknown properties in the list.
服务器对“电子邮件/查询”排序中比较器对象的“属性”字段支持的所有值的列表（参见第4.4.2节）。这可能包括客户无法识别的属性（例如，在供应商扩展中指定的自定义属性）。客户端必须忽略列表中的任何未知属性。
o mayCreateTopLevelMailbox: "Boolean"
o mayCreateTopLevelMailbox：“布尔”
If true, the user may create a Mailbox (see Section 2) in this account with a null parentId. (Permission for creating a child of an existing Mailbox is given by the "myRights" property on that Mailbox.)
如果为true，则用户可以在此帐户中创建一个parentId为空的邮箱（请参阅第2节）。（创建现有邮箱子级的权限由该邮箱上的“myRights”属性授予。）
This represents support for the Identity and EmailSubmission data types and associated API methods. The value of this property in the JMAP session "capabilities" property is an empty object.
这表示对标识和EmailSubmission数据类型以及相关API方法的支持。JMAP会话“capabilities”属性中此属性的值为空对象。
The value of this property in an account's "accountCapabilities" property is an object that MUST contain the following information on server capabilities and permissions for that account:
帐户“accountCapabilities”属性中此属性的值是一个对象，该对象必须包含有关该帐户的服务器功能和权限的以下信息：
o maxDelayedSend: "UnsignedInt"
o maxDelayedSend：“未签名”
The number in seconds of the maximum delay the server supports in sending (see the EmailSubmission object description). This is 0 if the server does not support delayed send.
服务器在发送时支持的最大延迟数（以秒为单位）（请参阅EmailSubmission对象描述）。如果服务器不支持延迟发送，则为0。
o submissionExtensions: "String[String[]]"
o submissionExtensions:“字符串[字符串[]”
The set of SMTP submission extensions supported by the server, which the client may use when creating an EmailSubmission object (see Section 7). Each key in the object is the "ehlo-name", and the value is a list of "ehlo-args".
服务器支持的SMTP提交扩展集，客户端在创建EmailSubmission对象时可以使用该扩展集（请参阅第7节）。对象中的每个键都是“ehlo名称”，值是“ehlo参数”列表。
A JMAP implementation that talks to a submission server [RFC6409] SHOULD have a configuration setting that allows an administrator to modify the set of submission EHLO capabilities it may expose on this property. This allows a JMAP server to easily add access to a new submission extension without code changes. By default, the JMAP server should hide EHLO capabilities that have to do with the transport mechanism and thus are only relevant to the JMAP server (for example, PIPELINING, CHUNKING, or STARTTLS).
与提交服务器[RFC6409]对话的JMAP实现应该有一个配置设置，允许管理员修改可能在此属性上公开的提交EHLO功能集。这允许JMAP服务器轻松添加对新提交扩展的访问，而无需更改代码。默认情况下，JMAP服务器应该隐藏与传输机制有关的EHLO功能，因此只与JMAP服务器相关（例如，管道、分块或STARTTLS）。
Examples of Submission extensions to include:
提交扩展的示例包括：
* FUTURERELEASE [RFC4865]
* 未来发布[RFC4865]
* SIZE [RFC1870]
* 尺寸[RFC1870]
* DSN [RFC3461]
* DSN[RFC3461]
* DELIVERYBY [RFC2852]
* 交付人[RFC2852]
* MT-PRIORITY [RFC6710]
* MT-优先级[RFC6710]
A JMAP server MAY advertise an extension and implement the semantics of that extension locally on the JMAP server even if a submission server used by JMAP doesn't implement it.
JMAP服务器可能会公布一个扩展，并在JMAP服务器上本地实现该扩展的语义，即使JMAP使用的提交服务器没有实现它。
The full IANA registry of submission extensions can be found at <https://www.iana.org/assignments/mail-parameters>.
完整的IANA提交扩展注册可以在<https://www.iana.org/assignments/mail-parameters>.
This represents support for the VacationResponse data type and associated API methods. The value of this property is an empty object in both the JMAP session "capabilities" property and an account's "accountCapabilities" property.
这表示对VacationResponse数据类型和相关API方法的支持。此属性的值在JMAP会话“capabilities”属性和帐户的“accountCapabilities”属性中都是空对象。
The server MUST include the appropriate capability strings as keys in the "accountCapabilities" property of any account with which the user may use the data types represented by that URI. Supported data types may differ between accounts the user has access to. For example, in the user's personal account, they may have access to all three sets of data, but in a shared account, they may only have data for "urn:ietf:params:jmap:mail". This means they can access 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/ EmailSubmission objects) or view/set its VacationResponse.
服务器必须在任何帐户的“accountCapabilities”属性中包含适当的功能字符串作为键，用户可以使用该URI表示的数据类型。用户有权访问的帐户之间支持的数据类型可能不同。例如，在用户的个人帐户中，他们可以访问所有三组数据，但在共享帐户中，他们可能只有“urn:ietf:params:jmap:mail”的数据。这意味着他们可以访问共享帐户中的邮箱/线程/电子邮件数据，但不允许作为该帐户发送（因此无法访问Identity/EmailSubmission对象）或查看/设置其VacationResponse。
Servers MUST support the JMAP push mechanisms, as specified in [RFC8620], Section 7, to receive notifications when the state changes for any of the types defined in this specification.
服务器必须支持[RFC8620]第7节中规定的JMAP推送机制，以便在本规范中定义的任何类型的状态更改时接收通知。
In addition, servers that implement the "urn:ietf:params:jmap:mail" capability MUST support pushing state changes for a type 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 it SHOULD NOT change upon any other change to the Email objects, for example, if one is marked as read or deleted.
此外，实现“urn:ietf:params:jmap:mail”功能的服务器必须支持对称为“EmailDelivery”的类型进行状态更改。没有对该类型执行操作的方法；它仅作为推动机构的一部分存在。每当将新电子邮件添加到存储时，此项的状态字符串都必须更改，但在电子邮件对象发生任何其他更改时（例如，如果其中一个对象被标记为已读或已删除），该状态字符串不应更改。
Clients in battery-constrained environments may wish to delay fetching changes initiated by the user but fetch new Emails immediately so they can notify the user. To do this, they can register for pushes for the EmailDelivery type rather than the Email type (as defined in Section 4).
电池受限环境中的客户端可能希望延迟获取用户发起的更改，但会立即获取新电子邮件，以便通知用户。为此，他们可以注册EmailDelivery类型而不是Email类型（定义见第4节）的推送。
The client has registered for push notifications (see [RFC8620]) 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 Email immediately.
客户机已注册推送通知（请参阅[RFC8620]），仅用于EmailDelivery类型。用户将电子邮件标记为已在另一台设备上读取，从而导致电子邮件类型的状态字符串更改；但是，由于未向存储添加任何新内容，EmailDelivery状态不会更改，也不会将任何内容推送到客户端。新邮件到达用户的收件箱，再次导致电子邮件状态更改。这一次，EmailDelivery状态也会发生变化，一个StateChange对象会用新的状态字符串推送到客户端。然后，客户端可以重新同步以立即获取新电子邮件。
If a JMAP Mail server also provides an IMAP interface to the data and supports IMAP Extension for Object Identifiers [RFC8474], the ids SHOULD be the same for Mailbox, Thread, and Email objects in JMAP.
如果JMAP邮件服务器还提供数据的IMAP接口并支持对象标识符的IMAP扩展[RFC8474]，则JMAP中邮箱、线程和电子邮件对象的ID应相同。
A Mailbox represents a named set of Email objects. This is the primary mechanism for organising messages within an account. It is analogous to a folder or a label in other systems. A Mailbox may perform a certain role in the system; see below for more details.
邮箱表示一组已命名的电子邮件对象。这是在帐户中组织消息的主要机制。它类似于其他系统中的文件夹或标签。邮箱可能在系统中扮演某种角色；有关更多详细信息，请参见下文。
For compatibility with IMAP, an Email MUST belong to one or more Mailboxes. The Email id does not change if the Email changes Mailboxes.
为了与IMAP兼容，电子邮件必须属于一个或多个邮箱。如果电子邮件更改邮箱，则电子邮件id不会更改。
A *Mailbox* object has the following properties:
*邮箱*对象具有以下属性：
o id: "Id" (immutable; server-set)
o id：“id”（不可变；服务器集）
The id of the Mailbox.
邮箱的id。
o name: "String"
o 名称：“字符串”
User-visible name for the Mailbox, e.g., "Inbox". This MUST be a Net-Unicode string [RFC5198] of at least 1 character in length, subject to the maximum size given in the capability object. There MUST NOT be two sibling Mailboxes with both the same parent and the same name. Servers MAY reject names that violate server policy (e.g., names containing a slash (/) or control characters).
邮箱的用户可见名称，例如“收件箱”。这必须是长度至少为1个字符的净Unicode字符串[RFC5198]，以capability对象中给定的最大大小为准。不能有两个具有相同父级和相同名称的同级邮箱。服务器可能拒绝违反服务器策略的名称（例如，包含斜杠（/）或控制字符的名称）。
o parentId: "Id|null" (default: null)
o parentId:“Id | null”（默认值：null）
The Mailbox id for the parent of this Mailbox, or null if this Mailbox is at the top level. Mailboxes form acyclic graphs (forests) directed by the child-to-parent relationship. There MUST NOT be a loop.
此邮箱的父级的邮箱id，如果此邮箱处于顶级，则为null。邮箱形成由子到父关系定向的非循环图（林）。不应该有循环。
o role: "String|null" (default: null)
o 角色：“字符串| null”（默认值：null）
Identifies Mailboxes that have a particular common purpose (e.g., the "inbox"), regardless of the "name" property (which may be localised).
标识具有特定公共用途的邮箱（例如“收件箱”），而不考虑“名称”属性（可能是本地化的）。
This value is shared with IMAP (exposed in IMAP via the SPECIAL-USE extension [RFC6154]). However, unlike in IMAP, a Mailbox MUST only have a single role, and there MUST NOT be two Mailboxes in the same account with the same role. Servers providing IMAP access to the same data are encouraged to enforce these extra restrictions in IMAP as well. Otherwise, modifying the IMAP attributes to ensure compliance when exposing the data over JMAP is implementation dependent.
此值与IMAP共享（通过专用扩展[RFC6154]在IMAP中公开）。但是，与IMAP不同，邮箱只能有一个角色，同一帐户中不能有两个具有相同角色的邮箱。鼓励提供IMAP访问相同数据的服务器也在IMAP中实施这些额外限制。否则，修改IMAP属性以确保通过JMAP公开数据时的遵从性取决于实现。
The value MUST be one of the Mailbox attribute names listed in the IANA "IMAP Mailbox Name Attributes" registry at <https://www.iana.org/assignments/imap-mailbox-name-attributes/>, as established in [RFC8457], converted to lowercase. New roles may be established here in the future.
该值必须是以下位置的IANA“IMAP邮箱名称属性”注册表中列出的邮箱属性名称之一：<https://www.iana.org/assignments/imap-mailbox-name-attributes/>，如[RFC8457]中所述，转换为小写。未来可能会在这里建立新的角色。
An account is not required to have Mailboxes with any particular roles.
帐户不需要具有具有任何特定角色的邮箱。
o sortOrder: "UnsignedInt" (default: 0)
o 排序器：“UnsignedInt”（默认值：0）
Defines the sort order of Mailboxes when presented in the client's UI, so it is consistent between devices. The number MUST be an integer in the range 0 <= sortOrder < 2^31.
定义邮箱在客户端UI中显示时的排序顺序，以便在设备之间保持一致。该数字必须是范围0<=sortOrder<2^31的整数。
A Mailbox with a lower order should be displayed before a Mailbox with a higher order (that has the same parent) in any Mailbox listing in the client's UI. Mailboxes with equal order SHOULD be sorted in alphabetical order by name. The sorting should take into account locale-specific character order convention.
在客户端UI的任何邮箱列表中，具有较低顺序的邮箱应显示在具有较高顺序（具有相同父级）的邮箱之前。顺序相同的邮箱应按名称按字母顺序排序。排序应考虑特定于区域设置的字符顺序约定。
o totalEmails: "UnsignedInt" (server-set)
o totalEmails：“UnsignedInt”（服务器集）
The number of Emails in this Mailbox.
此邮箱中的电子邮件数。
o unreadEmails: "UnsignedInt" (server-set)
o 未解析：“UnsignedInt”（服务器集）
The number of Emails in this Mailbox that have neither the "$seen" keyword nor the "$draft" keyword.
此邮箱中既没有“$seen”关键字也没有“$draft”关键字的电子邮件数。
o totalThreads: "UnsignedInt" (server-set)
o totalThreads：“UnsignedInt”（服务器集）
The number of Threads where at least one Email in the Thread is in this Mailbox.
线程中至少有一封电子邮件在此邮箱中的线程数。
o unreadThreads: "UnsignedInt" (server-set)
o 未读线程：“UnsignedInt”（服务器集）
An indication of the number of "unread" Threads in the Mailbox.
邮箱中“未读”线程数的指示。
For compatibility with existing implementations, the way "unread Threads" is determined is not mandated in this document. The simplest solution to implement is simply the number of Threads where at least one Email in the Thread is both in this Mailbox and has neither the "$seen" nor "$draft" keywords.
为了与现有实现兼容，本文档不强制要求确定“未读线程”的方式。要实现的最简单的解决方案就是线程数，其中线程中至少有一封电子邮件同时位于此邮箱中，并且没有“$seen”或“$draft”关键字。
However, a quality implementation will return the number of unread items the user would see if they opened that Mailbox. A Thread is shown as unread if it contains any unread Emails that will be displayed when the Thread is opened. Therefore, "unreadThreads" should be the number of Threads where at least one Email in the Thread has neither the "$seen" nor the "$draft" keyword AND at least one Email in the Thread is in this Mailbox. Note that the unread Email does not need to be the one in this Mailbox. In addition, the trash Mailbox (that is, a Mailbox whose "role" is "trash") requires special treatment:
但是，质量实现将返回用户在打开该邮箱时看到的未读项目数。如果某个线程包含任何未读电子邮件，则该线程将显示为未读，该电子邮件将在该线程打开时显示。因此，“unreadThreads”应该是线程中至少有一封电子邮件既没有“$seen”也没有“$draft”关键字并且线程中至少有一封电子邮件在此邮箱中的线程数。请注意，未读电子邮件不必是此邮箱中的电子邮件。此外，垃圾箱邮箱（即“角色”为“垃圾箱”的邮箱）需要特殊处理：
1. Emails that are *only* in the trash (and no other Mailbox) are ignored when calculating the "unreadThreads" count of other Mailboxes.
1. 在计算其他邮箱的“未读线程”计数时，将忽略垃圾箱中*仅*的电子邮件（没有其他邮箱）。
2. Emails that are *not* in the trash are ignored when calculating the "unreadThreads" count for the trash Mailbox.
2. 在计算垃圾箱邮箱的“未读线程”计数时，垃圾箱中*不*的电子邮件将被忽略。
The result of this is that Emails in the trash are treated as though they are in a separate Thread for the purposes of unread counts. It is expected that clients will hide Emails in the trash 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.
这样做的结果是，出于未读计数的目的，垃圾箱中的电子邮件被视为在单独的线程中。当查看另一个邮箱中的线程时，客户端会将电子邮件隐藏在垃圾箱中，反之亦然。这允许您从一个线程中删除一封发送到垃圾箱的电子邮件。
For example, suppose you have an account where the entire contents is a single Thread with 2 Emails: an unread Email in the trash and a read Email in the inbox. The "unreadThreads" count would be 1 for the trash and 0 for the inbox.
例如，假设您有一个帐户，其中整个内容是一个线程，包含两封电子邮件：垃圾箱中的一封未读电子邮件和收件箱中的一封已读电子邮件。垃圾箱的“未读线程”计数为1，收件箱的“未读线程”计数为0。
o myRights: "MailboxRights" (server-set)
o myRights:“MailboxRights”（服务器集）
The set of rights (Access Control Lists (ACLs)) the user has in relation to this Mailbox. These are backwards compatible with IMAP ACLs, as defined in [RFC4314]. A *MailboxRights* object has the following properties:
用户对此邮箱拥有的一组权限（访问控制列表（ACL））。如[RFC4314]中所定义，它们与IMAP ACL向后兼容。*MailboxRights*对象具有以下属性：
* mayReadItems: "Boolean"
* mayReadItems：“布尔”
If true, the user may use this Mailbox as part of a filter in an "Email/query" call, and the Mailbox may be included in the "mailboxIds" property of Email objects. Email objects may be fetched if they are in *at least one* Mailbox with this permission. If a sub-Mailbox is shared but not the parent Mailbox, this may be false. Corresponds to IMAP ACLs "lr" (if mapping from IMAP, both are required for this to be true).
如果为true，则用户可以在“电子邮件/查询”调用中将此邮箱用作筛选器的一部分，并且该邮箱可能包含在电子邮件对象的“MailboxID”属性中。如果电子邮件对象位于*至少一个*具有此权限的邮箱中，则可以提取它们。如果子邮箱是共享的，而不是父邮箱，则这可能是错误的。对应于IMAP ACL“lr”（如果从IMAP映射，则这两个都是必需的）。
* mayAddItems: "Boolean"
* mayAddItems：“布尔”
The user may add mail to this Mailbox (by either creating a new Email or moving an existing one). Corresponds to IMAP ACL "i".
用户可以将邮件添加到此邮箱（通过创建新邮件或移动现有邮件）。对应于IMAP ACL“i”。
* mayRemoveItems: "Boolean"
* Mayremovietems：“布尔”
The user may remove mail from this Mailbox (by either changing the Mailboxes of an Email or destroying the Email). Corresponds to IMAP ACLs "te" (if mapping from IMAP, both are required for this to be true).
用户可以从此邮箱中删除邮件（通过更改电子邮件邮箱或销毁电子邮件）。对应于IMAP ACL“te”（如果从IMAP映射，则这两个都是必需的）。
* maySetSeen: "Boolean"
* 梅塞森：“布尔”
The user may add or remove the "$seen" keyword to/from an Email. If an Email belongs to multiple Mailboxes, the user may only modify "$seen" if they have this permission for *all* of the Mailboxes. Corresponds to IMAP ACL "s".
用户可以在电子邮件中添加或删除“$seen”关键字。如果一封电子邮件属于多个邮箱，用户只有在对*所有*邮箱拥有此权限时才能修改“$seen”。对应于IMAP ACL“s”。
* maySetKeywords: "Boolean"
* maySetKeywords：“布尔”
The user may add or remove any keyword other than "$seen" to/ from an Email. If an Email belongs to multiple Mailboxes, the user may only modify keywords if they have this permission for *all* of the Mailboxes. Corresponds to IMAP ACL "w".
用户可以在电子邮件中添加或删除除“$seen”以外的任何关键字。如果一封电子邮件属于多个邮箱，用户只有在对*所有*邮箱拥有此权限时才能修改关键字。对应于IMAP ACL“w”。
* mayCreateChild: "Boolean"
* mayCreateChild：“布尔”
The user may create a Mailbox with this Mailbox as its parent. Corresponds to IMAP ACL "k".
用户可以使用此邮箱作为其父邮箱创建邮箱。对应于IMAP ACL“k”。
* mayRename: "Boolean"
* 可以重命名为：“布尔”
The user may rename the Mailbox or make it a child of another Mailbox. Corresponds to IMAP ACL "x" (although this covers both rename and delete permissions).
用户可以重命名邮箱或使其成为另一邮箱的子邮箱。对应于IMAP ACL“x”（尽管这包括重命名和删除权限）。
* mayDelete: "Boolean"
* 可删除：“布尔值”
The user may delete the Mailbox itself. Corresponds to IMAP ACL "x" (although this covers both rename and delete permissions).
用户可以删除邮箱本身。对应于IMAP ACL“x”（尽管这包括重命名和删除权限）。
* maySubmit: "Boolean"
* 可能提交：“布尔”
Messages may be submitted directly to this Mailbox. Corresponds to IMAP ACL "p".
邮件可以直接提交到此邮箱。对应于IMAP ACL“p”。
o isSubscribed: "Boolean"
o 已订阅：“布尔值”
Has the user indicated they wish to see this Mailbox in their client? This SHOULD default to false for Mailboxes in shared accounts the user has access to and true for any new Mailboxes created by the user themself. This MUST be stored separately per user where multiple users have access to a shared Mailbox.
用户是否表示希望在其客户端中看到此邮箱？对于用户有权访问的共享帐户中的邮箱，此选项默认为false；对于用户自己创建的任何新邮箱，此选项默认为true。如果多个用户可以访问共享邮箱，则必须为每个用户单独存储此信息。
A user may have permission to access a 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 of these. Clients may choose to only display Mailboxes where the "isSubscribed" property is set to true, and offer a separate UI to allow the user to see and subscribe/unsubscribe from the full set of Mailboxes. However, clients MAY choose to ignore this property, either entirely for ease of implementation or just for an account where "isPersonal" is true (indicating it is the user's own rather than a shared account).
用户可能拥有访问大量共享帐户的权限，或者拥有一组非常大邮箱的共享帐户的权限，但只对其中一些内容感兴趣。客户端可以选择仅显示“IssuSubscribed”属性设置为true的邮箱，并提供一个单独的UI，允许用户查看和订阅/取消订阅全套邮箱。但是，客户机可能会选择忽略此属性，或者完全是为了易于实现，或者只是针对“isPersonal”为true的帐户（表示它是用户自己的帐户，而不是共享帐户）。
This property corresponds to IMAP [RFC3501] mailbox subscriptions.
此属性对应于IMAP[RFC3501]邮箱订阅。
For IMAP compatibility, an Email in both the trash and another Mailbox SHOULD be treated by the client as existing in both places (i.e., when emptying the trash, the client should just remove it from the trash Mailbox and leave it in the other Mailbox).
为了与IMAP兼容，客户机应将垃圾箱和另一个邮箱中的电子邮件视为在两个位置都存在（即，清空垃圾箱时，客户机应将其从垃圾箱邮箱中删除，并将其保留在另一个邮箱中）。
The following JMAP methods are supported.
支持以下JMAP方法。
This is a standard "/get" method as described in [RFC8620], Section 5.1. The "ids" argument may be "null" to fetch all at once.
这是[RFC8620]第5.1节所述的标准“/get”方法。“ids”参数可以是“null”，以便一次获取所有数据。
This is a standard "/changes" method as described in [RFC8620], Section 5.2 but with one extra argument to the response:
这是[RFC8620]第5.2节所述的标准“/changes”方法，但响应中有一个额外参数：
o updatedProperties: "String[]|null"
o updatedProperties:“字符串[]空”
If only the "totalEmails", "unreadEmails", "totalThreads", and/or "unreadThreads" Mailbox properties have changed since the old state, this will be the list of properties that may have changed. If the server is unable to tell if only counts have changed, it MUST just be null.
如果自旧状态以来只有“totalEmails”、“unreadEmails”、“totalThreads”和/或“unreadThreads”邮箱属性已更改，则这将是可能已更改的属性列表。如果服务器无法判断是否只有计数发生了更改，则它必须为null。
Since counts frequently change but other properties are generally only changed rarely, the server can help the client optimise data transfer by keeping track of changes to Email/Thread counts separate from other state changes. The "updatedProperties" array may be used directly via a back-reference in a subsequent "Mailbox/get" call in the same request, so only these properties are returned if nothing else has changed.
由于计数经常更改，但其他属性通常很少更改，因此服务器可以通过将电子邮件/线程计数的更改与其他状态更改分开来跟踪，从而帮助客户端优化数据传输。“updatedProperties”数组可以在同一请求中的后续“Mailbox/get”调用中通过反向引用直接使用，因此如果没有其他更改，则只返回这些属性。
This is a standard "/query" method as described in [RFC8620], Section 5.5 but with the following additional request argument:
这是[RFC8620]第5.5节所述的标准“/查询”方法，但具有以下附加请求参数：
o sortAsTree: "Boolean" (default: false)
o sortAsTree：“布尔”（默认值：false）
If true, when sorting the query results and comparing Mailboxes A and B:
如果为true，则在对查询结果进行排序并比较邮箱A和B时：
* If A is an ancestor of B, it always comes first regardless of the sort comparators. Similarly, if A is descendant of B, then B always comes first.
* 如果A是B的祖先，则无论排序比较器是什么，它总是排在第一位。同样，如果A是B的后代，那么B总是排在第一位。
* Otherwise, if A and B do not share a "parentId", find the nearest ancestors of each that do have the same "parentId" and compare the sort properties on those Mailboxes instead.
* 否则，如果A和B不共享“parentId”，请查找每个具有相同“parentId”的最近祖先，然后比较这些邮箱上的排序属性。
The result of this is that the Mailboxes are sorted as a tree according to the parentId properties, with each set of children with a common parent sorted according to the standard sort comparators.
这样做的结果是，邮箱按照parentId属性作为树进行排序，每组具有公共父级的子级按照标准排序比较器进行排序。
o filterAsTree: "Boolean" (default: false)
o FiltersTree：“布尔”（默认值：false）
If true, a Mailbox is only included in the query if all its ancestors are also included in the query according to the filter.
如果为true，则仅当邮箱的所有祖先都根据筛选器包含在查询中时，才会将其包含在查询中。
A *FilterCondition* object has the following properties, any of which may be omitted:
*FilterCondition*对象具有以下属性，其中任何属性都可以省略：
o parentId: "Id|null"
o parentId:“Id | null”
The Mailbox "parentId" property must match the given value exactly.
邮箱“parentId”属性必须与给定值完全匹配。
o name: "String"
o 名称：“字符串”
The Mailbox "name" property contains the given string.
邮箱“name”属性包含给定字符串。
o role: "String|null"
o 角色：“字符串|空”
The Mailbox "role" property must match the given value exactly.
邮箱“角色”属性必须与给定值完全匹配。
o hasAnyRole: "Boolean"
o hasAnyRole：“布尔”
If true, a Mailbox matches if it has any non-null value for its "role" property.
如果为true，则邮箱匹配其“角色”属性是否具有任何非null值。
o isSubscribed: "Boolean"
o 已订阅：“布尔值”
The "isSubscribed" property of the Mailbox must be identical to the value given to match the condition.
邮箱的“IssuSubscribed”属性必须与给定的值相同，以匹配条件。
A Mailbox object matches the FilterCondition if and only if all of the given conditions match. If zero properties are specified, it is automatically true for all objects.
当且仅当所有给定条件都匹配时，邮箱对象才匹配FilterCondition。如果指定零属性，则所有对象的属性都自动为真。
The following Mailbox properties MUST be supported for sorting:
排序必须支持以下邮箱属性：
o "sortOrder"
o “巫师”
o "name"
o “姓名”
This is a standard "/queryChanges" method as described in [RFC8620], Section 5.6.
这是[RFC8620]第5.6节所述的标准“/queryChanges”方法。
This is a standard "/set" method as described in [RFC8620], Section 5.3 but with the following additional request argument:
这是[RFC8620]第5.3节所述的标准“/set”方法，但具有以下附加请求参数：
o onDestroyRemoveEmails: "Boolean" (default: false)
o onDestroyRemoveEmails：“布尔”（默认值：false）
If false, any attempt to destroy a Mailbox that still has Emails in it will be rejected with a "mailboxHasEmail" SetError. If true, any Emails that were in the Mailbox will be removed from it, and if in no other Mailboxes, they will be destroyed when the Mailbox is destroyed.
如果为false，则任何破坏仍包含电子邮件的邮箱的尝试都将被拒绝，并显示“mailboxHasEmail”设置错误。如果为true，则邮箱中的所有电子邮件都将从中删除，如果没有其他邮箱中的电子邮件，则在邮箱销毁时将销毁这些电子邮件。
The following extra SetError types are defined:
定义了以下额外的SetError类型：
For "destroy":
对于“销毁”：
o "mailboxHasChild": The Mailbox still has at least one child Mailbox. The client MUST remove these before it can delete the parent Mailbox.
o “mailboxHasChild”：邮箱仍至少有一个子邮箱。客户端必须先删除这些，然后才能删除父邮箱。
o "mailboxHasEmail": The Mailbox has at least one Email assigned to it, and the "onDestroyRemoveEmails" argument was false.
o “mailboxHasEmail”：邮箱至少分配了一封电子邮件，“onDestroyRemoveEmails”参数为false。
Fetching all Mailboxes in an account:
正在获取帐户中的所有邮箱：
[[ "Mailbox/get", {
"accountId": "u33084183",
"ids": null
}, "0" ]]
[[ "Mailbox/get", {
"accountId": "u33084183",
"ids": null
}, "0" ]]
And the response:
答复如下：
[[ "Mailbox/get", {
"accountId": "u33084183",
"state": "78540",
"list": [{
"id": "MB23cfa8094c0f41e6",
"name": "Inbox",
"parentId": null,
"role": "inbox",
"sortOrder": 10,
"totalEmails": 16307,
"unreadEmails": 13905,
"totalThreads": 5833,
"unreadThreads": 5128,
"myRights": {
"mayAddItems": true,
"mayRename": false,
"maySubmit": true,
"mayDelete": false,
"maySetKeywords": true,
"mayRemoveItems": true,
"mayCreateChild": true,
"maySetSeen": true,
"mayReadItems": true
},
"isSubscribed": true
}, {
"id": "MB674cc24095db49ce",
"name": "Important mail",
...
}, ... ],
"notFound": []
}, "0" ]]
[[ "Mailbox/get", {
"accountId": "u33084183",
"state": "78540",
"list": [{
"id": "MB23cfa8094c0f41e6",
"name": "Inbox",
"parentId": null,
"role": "inbox",
"sortOrder": 10,
"totalEmails": 16307,
"unreadEmails": 13905,
"totalThreads": 5833,
"unreadThreads": 5128,
"myRights": {
"mayAddItems": true,
"mayRename": false,
"maySubmit": true,
"mayDelete": false,
"maySetKeywords": true,
"mayRemoveItems": true,
"mayCreateChild": true,
"maySetSeen": true,
"mayReadItems": true
},
"isSubscribed": true
}, {
"id": "MB674cc24095db49ce",
"name": "Important mail",
...
}, ... ],
"notFound": []
}, "0" ]]
Now suppose an Email is marked read, and we get a push update that the Mailbox state has changed. You might fetch the updates like this:
现在假设一封电子邮件被标记为已读，我们得到一个邮箱状态已更改的推送更新。您可以按如下方式获取更新：
[[ "Mailbox/changes", {
"accountId": "u33084183",
"sinceState": "78540"
}, "0" ],
[ "Mailbox/get", {
"accountId": "u33084183",
"#ids": {
"resultOf": "0",
"name": "Mailbox/changes",
"path": "/created"
}
}, "1" ],
[ "Mailbox/get", {
"accountId": "u33084183",
"#ids": {
"resultOf": "0",
"name": "Mailbox/changes",
"path": "/updated"
},
"#properties": {
"resultOf": "0",
"name": "Mailbox/changes",
"path": "/updatedProperties"
}
}, "2" ]]
[[ "Mailbox/changes", {
"accountId": "u33084183",
"sinceState": "78540"
}, "0" ],
[ "Mailbox/get", {
"accountId": "u33084183",
"#ids": {
"resultOf": "0",
"name": "Mailbox/changes",
"path": "/created"
}
}, "1" ],
[ "Mailbox/get", {
"accountId": "u33084183",
"#ids": {
"resultOf": "0",
"name": "Mailbox/changes",
"path": "/updated"
},
"#properties": {
"resultOf": "0",
"name": "Mailbox/changes",
"path": "/updatedProperties"
}
}, "2" ]]
This fetches the list of ids for created/updated/destroyed Mailboxes, then using back-references, it fetches the data for just the created/ updated Mailboxes in the same request. The response may look something like this:
这将获取已创建/更新/销毁邮箱的ID列表，然后使用反向引用，仅获取同一请求中已创建/更新邮箱的数据。响应可能如下所示：
[[ "Mailbox/changes", {
"accountId": "u33084183",
"oldState": "78541",
"newState": "78542",
"hasMoreChanges": false,
"updatedProperties": [
"totalEmails", "unreadEmails",
"totalThreads", "unreadThreads"
],
"created": [],
"updated": ["MB23cfa8094c0f41e6"],
"destroyed": []
}, "0" ],
[ "Mailbox/get", {
"accountId": "u33084183",
"state": "78542",
"list": [],
"notFound": []
}, "1" ],
[ "Mailbox/get", {
"accountId": "u33084183",
"state": "78542",
"list": [{
"id": "MB23cfa8094c0f41e6",
"totalEmails": 16307,
"unreadEmails": 13903,
"totalThreads": 5833,
"unreadThreads": 5127
}],
"notFound": []
}, "2" ]]
[[ "Mailbox/changes", {
"accountId": "u33084183",
"oldState": "78541",
"newState": "78542",
"hasMoreChanges": false,
"updatedProperties": [
"totalEmails", "unreadEmails",
"totalThreads", "unreadThreads"
],
"created": [],
"updated": ["MB23cfa8094c0f41e6"],
"destroyed": []
}, "0" ],
[ "Mailbox/get", {
"accountId": "u33084183",
"state": "78542",
"list": [],
"notFound": []
}, "1" ],
[ "Mailbox/get", {
"accountId": "u33084183",
"state": "78542",
"list": [{
"id": "MB23cfa8094c0f41e6",
"totalEmails": 16307,
"unreadEmails": 13903,
"totalThreads": 5833,
"unreadThreads": 5127
}],
"notFound": []
}, "2" ]]
Here's an example where we try to rename one Mailbox and destroy another:
以下是我们尝试重命名一个邮箱并销毁另一个邮箱的示例：
[[ "Mailbox/set", {
"accountId": "u33084183",
"ifInState": "78542",
"update": {
"MB674cc24095db49ce": {
"name": "Maybe important mail"
}
},
"destroy": [ "MB23cfa8094c0f41e6" ]
}, "0" ]]
[[ "Mailbox/set", {
"accountId": "u33084183",
"ifInState": "78542",
"update": {
"MB674cc24095db49ce": {
"name": "Maybe important mail"
}
},
"destroy": [ "MB23cfa8094c0f41e6" ]
}, "0" ]]
Suppose the rename succeeds, but we don't have permission to destroy the Mailbox we tried to destroy; we might get back:
假设重命名成功，但我们没有销毁试图销毁的邮箱的权限；我们可能会回来：
[[ "Mailbox/set", {
"accountId": "u33084183",
"oldState": "78542",
"newState": "78549",
"updated": {
"MB674cc24095db49ce": null
},
"notDestroyed": {
"MB23cfa8094c0f41e6": {
"type": "forbidden"
}
}
}, "0" ]]
[[ "Mailbox/set", {
"accountId": "u33084183",
"oldState": "78542",
"newState": "78549",
"updated": {
"MB674cc24095db49ce": null
},
"notDestroyed": {
"MB23cfa8094c0f41e6": {
"type": "forbidden"
}
}
}, "0" ]]
Replies are grouped together with the original message to form a Thread. In JMAP, a Thread is simply a flat list of Emails, ordered by date. Every Email MUST belong to a Thread, even if it is the only Email in the Thread.
回复与原始邮件一起分组，形成一个线程。在JMAP中，线程只是一个按日期排序的电子邮件平面列表。每个电子邮件必须属于一个线程，即使它是线程中唯一的电子邮件。
The exact algorithm for determining whether two Emails belong to the same Thread is not mandated in this spec to allow for compatibility with different existing systems. For new implementations, it is suggested that two messages belong in the same Thread if both of the following conditions apply:
为了与不同的现有系统兼容，本规范中没有规定确定两封电子邮件是否属于同一线程的精确算法。对于新的实现，如果以下两个条件都适用，建议两条消息属于同一个线程：
1. An identical message id [RFC5322] appears in both messages in any of the Message-Id, In-Reply-To, and References header fields.
1. 相同的消息id[RFC5322]出现在任何消息id、回复和引用标头字段的两条消息中。
2. After stripping automatically added prefixes such as "Fwd:", "Re:", "[List-Tag]", etc., and ignoring white space, the subjects are the same. This avoids the situation where a person replies to an old message as a convenient way of finding the right recipient to send to but changes the subject and starts a new conversation.
2. 删除自动添加的前缀（如“Fwd:”、“Re:”、“[List Tag]”等）并忽略空白后，主题是相同的。这避免了这样一种情况：一个人回复一封旧邮件，这是一种方便的方式，可以找到合适的收件人进行发送，但会改变主题并开始新的对话。
If messages are delivered out of order for some reason, a user may have two Emails in the same Thread but without headers that associate them with each other. The arrival of a third Email may provide the missing references to join them all together into a single Thread. Since the "threadId" of an Email is immutable, if the server wishes to merge the Threads, it MUST handle this by deleting and reinserting (with a new Email id) the Emails that change "threadId".
如果由于某种原因邮件发送顺序不正确，用户可能在同一线程中有两封电子邮件，但没有将它们相互关联的标题。第三封电子邮件的到来可能会提供缺失的引用，将它们连接到一个线程中。由于电子邮件的“threadId”是不可变的，如果服务器希望合并线程，则必须通过删除并重新插入（使用新的电子邮件id）更改“threadId”的电子邮件来处理此问题。
A *Thread* object has the following properties:
*线程*对象具有以下属性：
o id: "Id" (immutable; server-set)
o id：“id”（不可变；服务器集）
The id of the Thread.
线程的id。
o emailIds: "Id[]" (server-set)
o emailIds:“Id[]”（服务器集）
The ids of the Emails in the Thread, sorted by the "receivedAt" date of the Email, oldest first. If two Emails have an identical date, the sort is server dependent but MUST be stable (sorting by id is recommended).
线程中电子邮件的ID，按电子邮件的“receivedAt”日期排序，最早的优先。如果两封电子邮件的日期相同，则排序取决于服务器，但必须稳定（建议按id排序）。
The following JMAP methods are supported.
支持以下JMAP方法。
This is a standard "/get" method as described in [RFC8620], Section 5.1.
这是[RFC8620]第5.1节所述的标准“/get”方法。
Request:
请求：
[[ "Thread/get", {
"accountId": "acme",
"ids": ["f123u4", "f41u44"]
}, "#1" ]]
[[ "Thread/get", {
"accountId": "acme",
"ids": ["f123u4", "f41u44"]
}, "#1" ]]
with response:
答复如下：
[[ "Thread/get", {
"accountId": "acme",
"state": "f6a7e214",
"list": [
{
"id": "f123u4",
"emailIds": [ "eaa623", "f782cbb"]
},
{
"id": "f41u44",
"emailIds": [ "82cf7bb" ]
}
],
"notFound": []
}, "#1" ]]
[[ "Thread/get", {
"accountId": "acme",
"state": "f6a7e214",
"list": [
{
"id": "f123u4",
"emailIds": [ "eaa623", "f782cbb"]
},
{
"id": "f41u44",
"emailIds": [ "82cf7bb" ]
}
],
"notFound": []
}, "#1" ]]
This is a standard "/changes" method as described in [RFC8620], Section 5.2.
这是[RFC8620]第5.2节所述的标准“/变更”方法。
An *Email* object is a representation of a message [RFC5322], which allows clients to avoid the complexities of MIME parsing, transfer encoding, and character encoding.
*Email*对象是消息[RFC5322]的表示形式，它允许客户端避免MIME解析、传输编码和字符编码的复杂性。
Broadly, a message consists of two parts: a list of header fields and then a body. The Email data type provides a way to access the full structure or to use simplified properties and avoid some complexity if this is sufficient for the client application.
一般来说，消息由两部分组成：头字段列表和正文。电子邮件数据类型提供了一种访问完整结构或使用简化属性的方法，如果这对于客户端应用程序来说足够的话，还可以避免一些复杂性。
While raw headers can be fetched and set, the vast majority of clients should use an appropriate parsed form for each of the header fields it wants to process, as this allows it to avoid the complexities of various encodings that are required in a valid message per RFC 5322.
虽然可以获取和设置原始头，但绝大多数客户机都应该为要处理的每个头字段使用适当的解析形式，因为这样可以避免RFC 5322有效消息中所需的各种编码的复杂性。
The body of a message is normally a MIME-encoded set of documents in a tree structure. This may be arbitrarily nested, but the majority of email clients present a flat model of a message body (normally plaintext or HTML) with a set of attachments. Flattening the MIME structure to form this model can be difficult and causes inconsistency between clients. Therefore, in addition to the "bodyStructure" property, which gives the full tree, the Email object contains 3 alternate properties with flat lists of body parts:
消息体通常是树结构中的MIME编码文档集。这可能是任意嵌套的，但大多数电子邮件客户端都提供了带有一组附件的邮件正文（通常是纯文本或HTML）的平面模型。扁平化MIME结构以形成此模型可能很困难，并且会导致客户端之间的不一致。因此，除了提供完整树的“bodyStructure”属性外，电子邮件对象还包含3个具有身体部位平面列表的备用属性：
o "textBody"/"htmlBody": These provide a list of parts that should be rendered sequentially as the "body" of the message. This is a list rather than a single part as messages may have headers and/or footers appended/prepended as separate parts when they are transmitted, and some clients send text and images intended to be displayed inline in the body (or even videos and sound clips) as multiple parts rather than a single HTML part with referenced images.
o “textBody”/“htmlBody”：它们提供了应按顺序呈现为消息“body”的部分列表。这是一个列表，而不是一个单独的部分，因为消息在传输时可能会附加/预先添加页眉和/或页脚作为单独的部分，一些客户端会将文本和图像作为多个部分（甚至视频和声音剪辑）发送，而不是包含引用图像的单个HTML部分。
Because MIME allows for multiple representations of the same data (using "multipart/alternative"), there is a "textBody" property (which prefers a plaintext representation) and an "htmlBody" property (which prefers an HTML representation) to accommodate the two most common client requirements. The same part may appear in both lists where there is no alternative between the two.
由于MIME允许对同一数据进行多个表示（使用“multipart/alternative”），因此有一个“textBody”属性（首选纯文本表示）和一个“htmlBody”属性（首选HTML表示）来满足两个最常见的客户机需求。同一部分可能出现在两个列表中，在这两个列表之间没有替代品。
o "attachments": This provides a list of parts that should be presented as "attachments" to the message. Some images may be solely there for embedding within an HTML body part; clients may wish to not present these as attachments in the user interface if they are displaying the HTML with the embedded images directly. Some parts may also be in htmlBody/textBody; again, clients may wish to not present these as attachments in the user interface if rendered as part of the body.
o “附件”：这提供了应作为邮件“附件”显示的部件列表。有些图像可能只用于嵌入HTML主体部分；如果客户端直接显示带有嵌入图像的HTML，则可能不希望在用户界面中将其作为附件显示。某些部分也可能在htmlBody/textBody中；同样，如果作为主体的一部分呈现，客户端可能不希望在用户界面中将这些作为附件呈现。
The "bodyValues" property allows for clients to fetch the value of text parts directly without having to do a second request for the blob and to have the server handle decoding the charset into unicode. This data is in a separate property rather than on the EmailBodyPart object to avoid duplication of large amounts of data, as the same part may be included twice if the client fetches more than one of bodyStructure, textBody, and htmlBody.
“bodyValues”属性允许客户端直接获取文本部分的值，而无需对blob执行第二次请求，并允许服务器将字符集解码为unicode。此数据位于单独的属性中，而不是位于EmailBodyPart对象上，以避免大量数据的重复，因为如果客户端获取bodyStructure、textBody和htmlBody中的多个，则同一部分可能包含两次。
In the following subsections, the common notational convention for wildcards has been adopted for content types, so "foo/*" means any content type that starts with "foo/".
在以下小节中，内容类型采用了通配符的通用符号约定，因此“foo/*”表示以“foo/”开头的任何内容类型。
Due to the number of properties involved, the set of Email properties is specified over the following four subsections. This is purely for readability; all properties are top-level peers.
由于涉及的属性数量较多，在以下四个小节中指定了电子邮件属性集。这纯粹是为了可读性；所有属性都是顶级对等项。
These properties represent metadata about the message in the mail store and are not derived from parsing the message itself.
这些属性表示邮件存储中有关邮件的元数据，不是从解析邮件本身派生的。
o id: "Id" (immutable; server-set)
o id：“id”（不可变；服务器集）
The id of the Email object. Note that this is the JMAP object id, NOT the Message-ID header field value of the message [RFC5322].
电子邮件对象的id。注意，这是JMAP对象id，而不是消息[RFC5322]的消息id头字段值。
o blobId: "Id" (immutable; server-set)
o blobId：“Id”（不可变；服务器集）
The id representing the raw octets of the message [RFC5322] for this Email. This may be used to download the raw original message or to attach it directly to another Email, etc.
表示此电子邮件的消息[RFC5322]的原始八位字节的id。这可用于下载原始原始邮件或将其直接附加到其他电子邮件等。
o threadId: "Id" (immutable; server-set)
o threadId:“Id”（不可变；服务器集）
The id of the Thread to which this Email belongs.
此电子邮件所属线程的id。
o mailboxIds: "Id[Boolean]"
o MailboxID:“Id[布尔值]”
The set of Mailbox ids this Email belongs to. An Email in the mail store MUST belong to one or more Mailboxes at all times (until it is destroyed). The set is represented as an object, with each key being a Mailbox id. The value for each key in the object MUST be true.
此电子邮件所属的邮箱ID集。邮件存储中的电子邮件必须始终属于一个或多个邮箱（直到被销毁）。集合表示为一个对象，每个键都是邮箱id。对象中每个键的值都必须为true。
o keywords: "String[Boolean]" (default: {})
o 关键词：“字符串[布尔]”（默认值：{}）
A set of keywords that apply to the Email. The set is represented as an object, with the keys being the keywords. The value for each key in the object MUST be true.
应用于电子邮件的一组关键字。集合被表示为一个对象，键是关键字。对象中每个键的值必须为true。
Keywords are shared with IMAP. The six system keywords from IMAP get special treatment. The following four keywords have their first character changed from "\" in IMAP to "$" in JMAP and have particular semantic meaning:
关键字与IMAP共享。IMAP中的六个系统关键字得到特殊处理。以下四个关键字的第一个字符已从IMAP中的“\”更改为JMAP中的“$”，并具有特定的语义含义：
* "$draft": The Email is a draft the user is composing.
* “$draft”：电子邮件是用户正在撰写的草稿。
* "$seen": The Email has been read.
* “$seen”：电子邮件已被阅读。
* "$flagged": The Email has been flagged for urgent/special attention.
* “$flagged”：电子邮件已标记为紧急/特别注意。
* "$answered": The Email has been replied to.
* “$已回复”：电子邮件已回复。
The IMAP "\Recent" keyword is not exposed via JMAP. The IMAP "\Deleted" keyword is also not present: IMAP uses a delete+expunge model, which JMAP does not. Any message with the "\Deleted" keyword MUST NOT be visible via JMAP (and so are not counted in the "totalEmails", "unreadEmails", "totalThreads", and "unreadThreads" Mailbox properties).
IMAP“\Recent”关键字未通过JMAP公开。IMAP“\Deleted”关键字也不存在：IMAP使用delete+expunge模型，JMAP不使用。任何带有“\Deleted”关键字的邮件不得通过JMAP可见（因此不计入“totalEmails”、“unreadEmails”、“totalThreads”和“unreadThreads”邮箱属性）。
Users may add arbitrary keywords to an Email. For compatibility with IMAP, a keyword is a case-insensitive string of 1-255 characters in the ASCII subset %x21-%x7e (excludes control chars and space), and it MUST NOT include any of these characters:
用户可以在电子邮件中添加任意关键字。为了与IMAP兼容，关键字是ASCII子集%x21-%x7e中1-255个字符的不区分大小写的字符串（不包括控制字符和空格），它不能包含以下任何字符：
( ) { ] % * " \
( ) { ] % * " \
Because JSON is case sensitive, servers MUST return keywords in lowercase.
由于JSON区分大小写，服务器必须以小写形式返回关键字。
The IANA "IMAP and JMAP Keywords" registry at <https://www.iana.org/assignments/imap-jmap-keywords/> as established in [RFC5788] assigns semantic meaning to some other keywords in common use. New keywords may be established here in the future. In particular, note:
IANA“IMAP和JMAP关键字”注册表位于<https://www.iana.org/assignments/imap-jmap-keywords/>如[RFC5788]中所述，将语义赋予其他常用关键字。将来可能会在这里建立新的关键字。请特别注意：
* "$forwarded": The Email has been forwarded.
* “$forwarded”：电子邮件已转发。
* "$phishing": The Email is highly likely to be phishing. Clients SHOULD warn users to take care when viewing this Email and disable links and attachments.
* “$phishing”：电子邮件很可能是网络钓鱼。客户端应警告用户在查看此电子邮件时要小心，并禁用链接和附件。
* "$junk": The Email is definitely spam. Clients SHOULD set this flag when users report spam to help train automated spam-detection systems.
* “$垃圾邮件”：这封邮件绝对是垃圾邮件。当用户报告垃圾邮件时，客户端应设置此标志，以帮助培训自动垃圾邮件检测系统。
* "$notjunk": The Email is definitely not spam. Clients SHOULD set this flag when users indicate an Email is legitimate, to help train automated spam-detection systems.
* “$notjunk”：电子邮件绝对不是垃圾邮件。当用户指示电子邮件合法时，客户端应设置此标志，以帮助培训自动垃圾邮件检测系统。
o size: "UnsignedInt" (immutable; server-set)
o 大小：“UnsignedInt”（不可变；服务器集）
The size, in octets, of the raw data for the message [RFC5322] (as referenced by the "blobId", i.e., the number of octets in the file the user would download).
消息[RFC5322]的原始数据的大小（以八位字节为单位）（由“blobId”引用，即用户将下载的文件中的八位字节数）。
o receivedAt: "UTCDate" (immutable; default: time of creation on server)
o receivedAt：“UTCDate”（不可变；默认值：服务器上的创建时间）
The date the Email was received by the message store. This is the "internal date" in IMAP [RFC3501].
邮件存储收到电子邮件的日期。这是IMAP[RFC3501]中的“内部日期”。
Header field properties are derived from the message header fields [RFC5322] [RFC6532]. All header fields may be fetched in a raw form. Some header fields may also be fetched in a parsed form. The structured form that may be fetched depends on the header. The forms are defined in the subsections that follow.
标头字段属性源自消息标头字段[RFC5322][RFC6532]。所有标题字段都可以原始形式获取。某些标题字段也可以以解析形式获取。可提取的结构化表单取决于标头。表格在下面的小节中定义。
Type: "String"
类型：“字符串”
The raw octets of the header field value from the first octet following the header field name terminating colon, up to but excluding the header field terminating CRLF. Any standards-compliant message MUST be either ASCII (RFC 5322) or UTF-8 (RFC 6532); however, other encodings exist in the wild. A server SHOULD replace any octet 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 dropped.
标题字段值的原始八位字节，从标题字段名称终止冒号后的第一个八位字节开始，直到但不包括终止CRLF的标题字段。任何符合标准的消息必须是ASCII（RFC 5322）或UTF-8（RFC 6532）；然而，其他编码在野外也存在。服务器应使用违反UTF-8语法的高位集替换任何八位字节或八位字节运行，并使用unicode替换字符（U+FFFD）。必须删除任何NUL八位字节。
This form will typically have a leading space, as most generated messages insert a space after the colon that terminates the header field name.
此表单通常会有一个前导空格，因为大多数生成的消息都会在冒号后面插入一个空格，以终止标题字段名。
Type: "String"
类型：“字符串”
The header field value with:
标题字段值包含：
1. White space unfolded (as defined in [RFC5322], Section 2.2.3).
1. 展开的空白（如[RFC5322]第2.2.3节所定义）。
2. The terminating CRLF at the end of the value removed.
2. 在删除的值末尾终止CRLF。
3. Any SP characters at the beginning of the value removed.
3. 删除值开头的所有SP字符。
4. Any syntactically correct encoded sections [RFC2047] with a known character set decoded. Any NUL octets or control characters encoded per [RFC2047] are dropped from the decoded value. Any text that looks like syntax per [RFC2047] but violates placement or white space rules per [RFC2047] MUST NOT be decoded.
4. 已解码已知字符集的任何语法正确的编码段[RFC2047]。从解码值中删除按照[RFC2047]编码的任何NUL八位字节或控制字符。任何看似符合[RFC2047]语法但违反[RFC2047]放置或空白规则的文本都不得解码。
5. The resulting unicode converted to Normalization Form C (NFC) form.
5. 生成的unicode转换为规范化形式C（NFC）形式。
If any decodings fail, the parser SHOULD insert a unicode replacement character (U+FFFD) and attempt to continue as much as possible.
如果任何解码失败，解析器应该插入一个unicode替换字符（U+FFFD）并尽可能继续。
To prevent obviously nonsense behaviour, which can lead to interoperability issues, this form may only be fetched or set for the following header fields:
为了防止明显的无意义行为，这可能导致互操作性问题，只能为以下标题字段获取或设置此表单：
o Subject
o 主题
o Comments
o 评论
o Keywords
o 关键词
o List-Id
o 列表Id
o Any header field not defined in [RFC5322] or [RFC2369]
o [RFC5322]或[RFC2369]中未定义的任何标题字段
Type: "EmailAddress[]"
键入：“电子邮件地址[]”
The header field is parsed as an "address-list" value, as specified in [RFC5322], Section 3.4, into the "EmailAddress[]" type. There is an EmailAddress item for each "mailbox" parsed from the "address-list". Group and comment information is discarded.
根据[RFC5322]第3.4节的规定，标题字段被解析为“地址列表”值，并转换为“EmailAddress[]”类型。从“地址列表”解析的每个“邮箱”都有一个EmailAddress项。组和注释信息将被丢弃。
An *EmailAddress* object has the following properties:
*EmailAddress*对象具有以下属性：
o name: "String|null"
o 名称：“字符串|空”
The "display-name" of the "mailbox" [RFC5322]. If this is a "quoted-string":
“邮箱”[RFC5322]的“显示名称”。如果这是一个“带引号的字符串”：
1. The surrounding DQUOTE characters are removed.
1. 周围的DQUOTE字符将被删除。
2. Any "quoted-pair" is decoded.
2. 任何“引用对”都被解码。
3. White space is unfolded, and then any leading and trailing white space is removed.
3. 展开空白，然后删除任何前导和尾随空白。
If there is no "display-name" but there is a "comment" immediately following the "addr-spec", the value of this SHOULD be used instead. Otherwise, this property is null.
如果没有“显示名称”，但“addr spec”后面紧跟着“comment”，则应使用该值。否则，此属性为null。
o email: "String"
o 电子邮件：“字符串”
The "addr-spec" of the "mailbox" [RFC5322].
“邮箱”[RFC5322]的“地址规范”。
Any syntactically correct encoded sections [RFC2047] with a known encoding MUST be decoded, following the same rules as for the Text form (see Section 4.1.2.2).
必须按照与文本形式相同的规则（见第4.1.2.2节），对任何语法正确且编码已知的编码节[RFC2047]进行解码。
Parsing SHOULD be best effort in the face of invalid structure to accommodate invalid messages and semi-complete drafts. EmailAddress objects MAY have an "email" property that does not conform to the "addr-spec" form (for example, may not contain an @ symbol).
在遇到无效结构时，应尽最大努力进行解析，以容纳无效消息和半完整草稿。EmailAddress对象的“email”属性可能不符合“addr spec”表单（例如，可能不包含@符号）。
For example, the following "address-list" string:
例如，以下“地址列表”字符串：
" James Smythe" <james@example.com>, Friends:
jane@example.com, =?UTF-8?Q?John_Sm=C3=AEth?=
<john@example.com>;
" James Smythe" <james@example.com>, Friends:
jane@example.com, =?UTF-8?Q?John_Sm=C3=AEth?=
<john@example.com>;
would be parsed as:
将被解析为：
[
{ "name": "James Smythe", "email": "james@example.com" },
{ "name": null, "email": "jane@example.com" },
{ "name": "John Smith", "email": "john@example.com" }
]
[
{ "name": "James Smythe", "email": "james@example.com" },
{ "name": null, "email": "jane@example.com" },
{ "name": "John Smith", "email": "john@example.com" }
]
To prevent obviously nonsense behaviour, which can lead to interoperability issues, this form may only be fetched or set for the following header fields:
为了防止明显的无意义行为，这可能导致互操作性问题，只能为以下标题字段获取或设置此表单：
o From
o 从…起
o Sender
o 发件人
o Reply-To
o 答复
o To
o 到
o Cc
o 复写的副本
o Bcc
o 密件抄送
o Resent-From
o 怨恨
o Resent-Sender
o 怨恨发送者
o Resent-Reply-To
o 回信
o Resent-To
o 怨恨
o Resent-Cc
o 重发抄送
o Resent-Bcc
o 憎恨密件抄送
o Any header field not defined in [RFC5322] or [RFC2369]
o [RFC5322]或[RFC2369]中未定义的任何标题字段
Type: "EmailAddressGroup[]"
类型：“EmailAddressGroup[]”
This is similar to the Addresses form but preserves group information. The header field is parsed as an "address-list" value, as specified in [RFC5322], Section 3.4, into the "GroupedAddresses[]" type. Consecutive "mailbox" values that are not part of a group are still collected under an EmailAddressGroup object to provide a uniform type.
这与地址表单类似，但保留组信息。根据[RFC5322]第3.4节的规定，将标题字段解析为“地址列表”值，并转换为“GroupedAddresses[]”类型。不属于组的连续“邮箱”值仍在EmailAddressGroup对象下收集，以提供统一类型。
An *EmailAddressGroup* object has the following properties:
*EmailAddressGroup*对象具有以下属性：
o name: "String|null"
o 名称：“字符串|空”
The "display-name" of the "group" [RFC5322], 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 EmailAddress type.
“组”[RFC5322]的“显示名称”，如果地址不是组的一部分，则为null。如果这是一个“带引号的字符串”，则其处理方式与EmailAddress类型中的“名称”相同。
o addresses: "EmailAddress[]"
o 地址：“电子邮件地址[]”
The "mailbox" values that belong to this group, represented as EmailAddress objects.
属于此组的“邮箱”值，表示为EmailAddress对象。
Any syntactically correct encoded sections [RFC2047] with a known encoding MUST be decoded, following the same rules as for the Text form (see Section 4.1.2.2).
必须按照与文本形式相同的规则（见第4.1.2.2节），对任何语法正确且编码已知的编码节[RFC2047]进行解码。
Parsing SHOULD be best effort in the face of invalid structure to accommodate invalid messages and semi-complete drafts.
在遇到无效结构时，应尽最大努力进行解析，以容纳无效消息和半完整草稿。
For example, the following "address-list" string:
例如，以下“地址列表”字符串：
" James Smythe" <james@example.com>, Friends:
jane@example.com, =?UTF-8?Q?John_Sm=C3=AEth?=
<john@example.com>;
" James Smythe" <james@example.com>, Friends:
jane@example.com, =?UTF-8?Q?John_Sm=C3=AEth?=
<john@example.com>;
would be parsed as:
将被解析为：
[
{ "name": null, "addresses": [
{ "name": "James Smythe", "email": "james@example.com" }
]},
{ "name": "Friends", "addresses": [
{ "name": null, "email": "jane@example.com" },
{ "name": "John Smith", "email": "john@example.com" }
]}
]
[
{ "name": null, "addresses": [
{ "name": "James Smythe", "email": "james@example.com" }
]},
{ "name": "Friends", "addresses": [
{ "name": null, "email": "jane@example.com" },
{ "name": "John Smith", "email": "john@example.com" }
]}
]
To prevent obviously nonsense behaviour, which can lead to interoperability issues, this form may only be fetched or set for the same header fields as the Addresses form (see Section 4.1.2.3).
为了防止明显的无意义行为，这可能导致互操作性问题，此表单只能为与地址表单相同的标题字段获取或设置（见第4.1.2.3节）。
Type: "String[]|null"
类型：“字符串[]空”
The header field is parsed as a list of "msg-id" values, as specified in [RFC5322], Section 3.6.4, into the "String[]" type. Comments and/ or folding white space (CFWS) and surrounding angle brackets ("<>") are removed. If parsing fails, the value is null.
根据[RFC5322]第3.6.4节的规定，标题字段被解析为“msg id”值列表，并转换为“字符串[]”类型。删除注释和/或折叠空白（CFWS）和周围的尖括号（<>）。如果解析失败，则该值为null。
To prevent obviously nonsense behaviour, which can lead to interoperability issues, this form may only be fetched or set for the following header fields:
为了防止明显的无意义行为，这可能导致互操作性问题，只能为以下标题字段获取或设置此表单：
o Message-ID
o 消息ID
o In-Reply-To
o 答复
o References
o 工具书类
o Resent-Message-ID
o 重新发送消息ID
o Any header field not defined in [RFC5322] or [RFC2369]
o [RFC5322]或[RFC2369]中未定义的任何标题字段
Type: "Date|null"
类型：“日期|空”
The header field is parsed as a "date-time" value, as specified in [RFC5322], Section 3.3, into the "Date" type. If parsing fails, the value is null.
根据[RFC5322]第3.3节的规定，标题字段被解析为“日期-时间”值，并转换为“日期”类型。如果解析失败，则该值为null。
To prevent obviously nonsense behaviour, which can lead to interoperability issues, this form may only be fetched or set for the following header fields:
为了防止明显的无意义行为，这可能导致互操作性问题，只能为以下标题字段获取或设置此表单：
o Date
o 日期
o Resent-Date
o 重发日期
o Any header field not defined in [RFC5322] or [RFC2369]
o [RFC5322]或[RFC2369]中未定义的任何标题字段
Type: "String[]|null"
类型：“字符串[]空”
The header field is parsed as a list of URLs, as described in [RFC2369], into the "String[]" type. Values do not include the surrounding angle brackets or any comments in the header field with the URLs. If parsing fails, the value is null.
标题字段被解析为URL列表，如[RFC2369]中所述，解析为“String[]”类型。值不包括周围的尖括号或URL标题字段中的任何注释。如果解析失败，则该值为null。
To prevent obviously nonsense behaviour, which can lead to interoperability issues, this form may only be fetched or set for the following header fields:
为了防止明显的无意义行为，这可能导致互操作性问题，只能为以下标题字段获取或设置此表单：
o List-Help
o 列出帮助
o List-Unsubscribe
o 列表取消订阅
o List-Subscribe
o 列表订阅
o List-Post
o 名单栏
o List-Owner
o 名单所有者
o List-Archive
o 列表存档
o Any header field not defined in [RFC5322] or [RFC2369]
o [RFC5322]或[RFC2369]中未定义的任何标题字段
The following low-level Email property is specified for complete access to the header data of the message:
为完全访问邮件的标题数据，指定了以下低级电子邮件属性：
o headers: "EmailHeader[]" (immutable)
o 标题：“EmailHeader[]”（不可变）
This is a list of all header fields [RFC5322], in the same order they appear in the message. An *EmailHeader* object has the following properties:
这是所有标题字段[RFC5322]的列表，它们在消息中的显示顺序相同。*EmailHeader*对象具有以下属性：
* name: "String"
* 名称：“字符串”
The header "field name" as defined in [RFC5322], with the same capitalization that it has in the message.
[RFC5322]中定义的标题“字段名”，其大小写与其在消息中的大小写相同。
* value: "String"
* 值：“字符串”
The header "field value" as defined in [RFC5322], in Raw form.
[RFC5322]中定义的原始形式的标题“字段值”。
In addition, the client may request/send properties representing individual header fields of the form:
此外，客户机可以请求/发送表示表单的各个标题字段的属性：
header:{header-field-name}
header:{header-field-name}
Where "{header-field-name}" means any series of one or more printable ASCII characters (i.e., characters that have values between 33 and 126, inclusive), except for colon (:). The property may also have the following suffixes:
其中，{header field name}表示一个或多个可打印ASCII字符的任何系列（即值介于33和126之间的字符，包括33和126），冒号（：）除外。该属性还可能具有以下后缀：
o :as{header-form}
o :as{header-form}
This means the value is in a parsed form, where "{header-form}" is one of the parsed-form names specified above. If not given, the value is in Raw form.
这意味着该值采用解析形式，其中“{header form}”是上面指定的解析形式名称之一。如果未给出，则该值为原始形式。
o :all
o ：全部
This means the value is an array, with the items corresponding to each instance of the header field, in the order they appear in the message. If this suffix is not used, the result is the value of the *last* instance of the header field (i.e., identical to the last item in the array if :all is used), or null if none.
这意味着该值是一个数组，其中的项目按照它们在消息中出现的顺序对应于标题字段的每个实例。如果未使用此后缀，则结果为标题字段的*last*实例的值（即，如果使用了：all，则与数组中的最后一项相同），如果没有，则为null。
If both suffixes are used, they MUST be specified in the order above. Header field names are matched case insensitively. The value is typed according to the requested form or to an array of that type if :all is used. If no header fields exist in the message with the requested name, the value is null if fetching a single instance or an empty array if requesting :all.
如果两个后缀都使用，则必须按上述顺序指定它们。标题字段名称不区分大小写匹配。根据请求的表单或该类型的数组键入值（如果使用：all）。如果消息中不存在具有请求名称的头字段，则如果获取单个实例，则该值为null；如果请求：all，则该值为空数组。
As a simple example, if the client requests a property called "header:subject", this means find the *last* header field in the message named "subject" (matched case insensitively) and return the value in Raw form, or null if no header field of this name is found.
作为一个简单的例子，如果客户端请求一个名为“header:subject”的属性，这意味着在名为“subject”的消息中查找*last*头字段（不区分大小写匹配），并以原始形式返回值，如果找不到此名称的头字段，则返回null。
For a more complex example, consider the client requesting a property called "header:Resent-To:asAddresses:all". This means:
对于一个更复杂的示例，考虑客户端请求一个称为“头：Reent to：AsAd:ALL”的属性。这意味着：
1. Find *all* header fields named Resent-To (matched case insensitively).
1. 查找名为Resent To的*all*头字段（不区分大小写匹配）。
2. For each instance, parse the header field value in the Addresses form.
2. 对于每个实例，解析Addresses表单中的header字段值。
3. The result is of type "EmailAddress[][]" -- each item in the array corresponds to the parsed value (which is itself an array) of the Resent-To header field instance.
3. 结果的类型为“EmailAddress[][]”——数组中的每个项都对应于重新发送到标头字段实例的解析值（它本身就是一个数组）。
The following convenience properties are also specified for the Email object:
还为电子邮件对象指定了以下便利属性：
o messageId: "String[]|null" (immutable)
o messageId:“字符串[]| null”（不可变）
The value is identical to the value of "header:Message-ID:asMessageIds". For messages conforming to RFC 5322, this will be an array with a single entry.
该值与“header:Message ID:asMessageID”的值相同。对于符合RFC 5322的消息，这将是一个带有单个条目的数组。
o inReplyTo: "String[]|null" (immutable)
o inReplyTo：“字符串[]| null”（不可变）
The value is identical to the value of "header:In-Reply-To:asMessageIds".
该值与“header:In Reply to:asMessageIds”的值相同。
o references: "String[]|null" (immutable)
o 参考：“字符串[]| null”（不可变）
The value is identical to the value of "header:References:asMessageIds".
该值与“header:References:asMessageId”的值相同。
o sender: "EmailAddress[]|null" (immutable)
o 发件人：“电子邮件地址[]|空”（不可变）
The value is identical to the value of "header:Sender:asAddresses".
该值与“header:Sender:asaddress”的值相同。
o from: "EmailAddress[]|null" (immutable)
o 发件人：“EmailAddress[]| null”（不可变）
The value is identical to the value of "header:From:asAddresses".
该值与“header:From:asaddress”的值相同。
o to: "EmailAddress[]|null" (immutable)
o 收件人：“EmailAddress[]| null”（不可变）
The value is identical to the value of "header:To:asAddresses".
该值与“header:to:asaddress”的值相同。
o cc: "EmailAddress[]|null" (immutable)
o 抄送：“电子邮件地址[]|空”（不可变）
The value is identical to the value of "header:Cc:asAddresses".
该值与“header:Cc:asaddress”的值相同。
o bcc: "EmailAddress[]|null" (immutable)
o 密件抄送：“电子邮件地址[]|空”（不可变）
The value is identical to the value of "header:Bcc:asAddresses".
该值与“header:Bcc:asaddress”的值相同。
o replyTo: "EmailAddress[]|null" (immutable)
o 回复：“电子邮件地址[]|空”（不可变）
The value is identical to the value of "header:Reply-To:asAddresses".
该值与“header:Reply to:asaddress”的值相同。
o subject: "String|null" (immutable)
o 主题：“字符串| null”（不可变）
The value is identical to the value of "header:Subject:asText".
该值与“header:Subject:asText”的值相同。
o sentAt: "Date|null" (immutable; default on creation: current server time)
o sentAt:“Date | null”（不可变；创建时的默认值：当前服务器时间）
The value is identical to the value of "header:Date:asDate".
该值与“header:Date:asDate”的值相同。
These properties are derived from the message body [RFC5322] and its MIME entities [RFC2045].
这些属性派生自消息体[RFC5322]及其MIME实体[RFC2045]。
An *EmailBodyPart* object has the following properties:
*EmailBodyPart*对象具有以下属性：
o partId: "String|null"
o partId:“字符串|空”
Identifies this part uniquely within the Email. This is scoped to the "emailId" and has no meaning outside of the JMAP Email object representation. This is null if, and only if, the part is of type "multipart/*".
在电子邮件中唯一标识此部分。这是“emailId”的范围，在JMAP电子邮件对象表示之外没有任何意义。当且仅当零件类型为“multipart/*”时，此值为空。
o blobId: "Id|null"
o blobId：“Id | null”
The id representing the raw octets of the contents of the part, after decoding any known Content-Transfer-Encoding (as defined in [RFC2045]), or null if, and only if, the part is of type "multipart/*". Note that two parts may be transfer-encoded differently but have the same blob id if their decoded octets are identical and the server is using a secure hash of the data for the blob id. If the transfer encoding is unknown, it is treated as though it had no transfer encoding.
在解码任何已知的内容传输编码（如[RFC2045]中所定义）后，表示该部分内容原始八位字节的id，或者当且仅当该部分为“multipart/*”类型时为空。请注意，如果两个部分的解码八位字节相同，并且服务器正在使用blob id数据的安全散列，则这两个部分的传输编码可能不同，但具有相同的blob id。如果传输编码未知，则将其视为没有传输编码。
o size: "UnsignedInt"
o 大小：“未签名”
The size, in octets, of the raw data after content transfer decoding (as referenced by the "blobId", i.e., the number of octets in the file the user would download).
内容传输解码后原始数据的大小（以八位字节为单位）（由“blobId”引用，即用户将下载的文件中的八位字节数）。
o headers: "EmailHeader[]"
o 标题：“EmailHeader[]”
This is a list of all header fields in the part, in the order they appear in the message. The values are in Raw form.
这是部件中所有标题字段的列表，按它们在消息中的显示顺序排列。这些值是原始形式的。
o name: "String|null"
o 名称：“字符串|空”
This is the decoded "filename" parameter of the Content-Disposition header field per [RFC2231], or (for compatibility with existing systems) if not present, then it's the decoded "name" parameter of the Content-Type header field per [RFC2047].
这是根据[RFC2231]的内容处置头字段的解码“文件名”参数，或者（为了与现有系统兼容），如果不存在，则是根据[RFC2047]的内容类型头字段的解码“名称”参数。
o type: "String"
o 类型：“字符串”
The value of the Content-Type header field of the part, if present; otherwise, the implicit type as per the MIME standard ("text/plain" or "message/rfc822" if inside a "multipart/digest"). CFWS is removed and any parameters are stripped.
零件的内容类型标题字段的值（如果存在）；否则，根据MIME标准的隐式类型（“text/plain”或“message/rfc822”，如果在“multipart/digest”中）。删除CFWS并剥离所有参数。
o charset: "String|null"
o 字符集：“字符串| null”
The value of the charset parameter of the Content-Type header field, if present, or null if the header field is present but not of type "text/*". If there is no Content-Type header field, or it exists and is of type "text/*" but has no charset parameter, this is the implicit charset as per the MIME standard: "us-ascii".
内容类型标头字段的字符集参数值（如果存在），如果标头字段存在但不是“text/*”类型，则为null。如果没有内容类型标头字段，或者该字段存在且类型为“text/*”但没有字符集参数，则这是符合MIME标准的隐式字符集：“us ascii”。
o disposition: "String|null"
o 处置：“字符串|空”
The value of the Content-Disposition header field of the part, if present; otherwise, it's null. CFWS is removed and any parameters are stripped.
零件的内容处置标题字段的值（如果存在）；否则，它是空的。删除CFWS并剥离所有参数。
o cid: "String|null"
o cid：“字符串|空”
The value of the Content-Id header field of the part, if present; otherwise, it's null. CFWS and surrounding angle brackets ("<>") are removed. This may be used to reference the content from within a "text/html" body part [HTML] using the "cid:" protocol, as defined in [RFC2392].
零件的内容Id标题字段的值（如果存在）；否则，它是空的。CFW和周围的角括号（“<>”）被移除。这可用于使用[RFC2392]中定义的“cid:”协议从“文本/html”主体部分[html]中引用内容。
o language: "String[]|null"
o 语言：“字符串[]空”
The list of language tags, as defined in [RFC3282], in the Content-Language header field of the part, if present.
[RFC3282]中定义的零件内容语言标题字段中的语言标记列表（如果存在）。
o location: "String|null"
o 位置：“字符串|空”
The URI, as defined in [RFC2557], in the Content-Location header field of the part, if present.
[RFC2557]中定义的部件内容位置头字段中的URI（如果存在）。
o subParts: "EmailBodyPart[]|null"
o 子部分：“EmailBodyPart[]|空”
If the type is "multipart/*", this contains the body parts of each child.
如果类型为“multipart/*”，则包含每个子级的主体部分。
In addition, the client may request/send EmailBodyPart properties representing individual header fields, following the same syntax and semantics as for the Email object, e.g., "header:Content-Type".
此外，客户机可以请求/发送代表各个标题字段的EmailBodyPart属性，遵循与电子邮件对象相同的语法和语义，例如，“标题：内容类型”。
The following Email properties are specified for access to the body data of the message:
指定以下电子邮件属性以访问邮件的正文数据：
o bodyStructure: "EmailBodyPart" (immutable)
o bodyStructure:“EmailBodyPart”（不可变）
This is the full MIME structure of the message body, without recursing into "message/rfc822" or "message/global" parts. Note that EmailBodyParts may have subParts if they are of type "multipart/*".
这是消息体的完整MIME结构，没有递归到“message/rfc822”或“message/global”部分。请注意，如果EmailBodyPart的类型为“multipart/*”，则它们可能具有子部件。
o bodyValues: "String[EmailBodyValue]" (immutable)
o BodyValue:“字符串[EmailBodyValue]”（不可变）
This is a map of "partId" to an EmailBodyValue object for none, some, or all "text/*" parts. Which parts are included and whether the value is truncated is determined by various arguments to "Email/get" and "Email/parse". An *EmailBodyValue* object has the following properties:
这是一个“partId”到EmailBodyValue对象的映射，用于无、部分或全部“text/*”部分。包含哪些部分以及值是否被截断取决于“Email/get”和“Email/parse”的各种参数。*EmailBodyValue*对象具有以下属性：
* value: "String"
* 值：“字符串”
The value of the body part after decoding Content-Transfer-Encoding and the Content-Type charset, if both known to the server, and with any CRLF replaced with a single LF. The server MAY use heuristics to determine the charset to use for decoding if the charset is unknown, no charset is given, or it believes the charset given is incorrect. Decoding is best effort; the server SHOULD insert the unicode replacement character (U+FFFD) and continue when a malformed section is encountered.
对内容传输编码和内容类型字符集进行解码后的正文部分的值（如果服务器知道这两个字符集，并且任何CRLF都替换为单个LF）。如果字符集未知，没有给出字符集，或者服务器认为给出的字符集不正确，则服务器可以使用启发式算法来确定用于解码的字符集。解码是最好的努力；服务器应插入unicode替换字符（U+FFFD），并在遇到格式错误的节时继续。
Note that due to the charset decoding and line ending normalisation, the length of this string will probably not be exactly the same as the "size" property on the corresponding EmailBodyPart.
请注意，由于字符集解码和行尾归一化，此字符串的长度可能与相应EmailBodyPart上的“size”属性不完全相同。
* isEncodingProblem: "Boolean" (default: false)
* isEncodingProblem:“布尔”（默认值：false）
This is true if malformed sections were found while decoding the charset, the charset was unknown, or the content-transfer-encoding was unknown.
如果在解码字符集时发现格式错误的部分，字符集未知，或内容传输编码未知，则为真。
* isTruncated: "Boolean" (default: false)
* isTruncated：“布尔”（默认值：false）
This is true if the "value" has been truncated.
如果“值”被截断，则为真。
See the Security Considerations section for issues related to truncation and heuristic determination of the content-type and charset.
有关内容类型和字符集的截断和启发式确定的问题，请参见安全注意事项部分。
o textBody: "EmailBodyPart[]" (immutable)
o textBody:“EmailBodyPart[]”（不可变）
A list of "text/plain", "text/html", "image/*", "audio/*", and/or "video/*" parts to display (sequentially) as the message body, with a preference for "text/plain" when alternative versions are available.
“text/plain”、“text/html”、“image/*”、“audio/*”和/或“video/*”部分的列表，以（顺序）显示为消息正文，当有替代版本时，首选“text/plain”。
o htmlBody: "EmailBodyPart[]" (immutable)
o htmlBody:“EmailBodyPart[]”（不可变）
A list of "text/plain", "text/html", "image/*", "audio/*", and/or "video/*" parts to display (sequentially) as the message body, with a preference for "text/html" when alternative versions are available.
“text/plain”、“text/html”、“image/*”、“audio/*”和/或“video/*”部分的列表，以（顺序）显示为消息正文，当有替代版本时，首选“text/html”。
o attachments: "EmailBodyPart[]" (immutable)
o 附件：“EmailBodyPart[]”（不可变）
A list, traversing depth-first, of all parts in "bodyStructure" that satisfy either of the following conditions:
“车身结构”中满足以下任一条件的所有零件的列表，遍历深度优先：
* not of type "multipart/*" and not included in "textBody" or "htmlBody"
* 不属于“multipart/*”类型且不包含在“textBody”或“htmlBody”中
* of type "image/*", "audio/*", or "video/*" and not in both "textBody" and "htmlBody"
* 类型为“image/*”、“audio/*”或“video/*”，且不在“textBody”和“htmlBody”中
None of these parts include subParts, including "message/*" types. Attached messages may be fetched using the "Email/parse" method and the "blobId".
这些部分都不包括子部分，包括“message/*”类型。可以使用“Email/parse”方法和“blobId”获取附加的消息。
Note that a "text/html" body part [HTML] may reference image parts in attachments by using "cid:" links to reference the Content-Id, as defined in [RFC2392], or by referencing the Content-Location.
注意，“文本/html”正文部分[html]可以通过使用“cid:”链接引用[RFC2392]中定义的内容Id，或者通过引用内容位置来引用附件中的图像部分。
o hasAttachment: "Boolean" (immutable; server-set)
o hasAttachment:“布尔”（不可变；服务器集）
This is true if there are one or more parts in the message that a client UI should offer as downloadable. A server SHOULD set hasAttachment to true if the "attachments" list contains at least one item that does not have "Content-Disposition: inline". The server MAY ignore parts in this list that are processed automatically in some way or are referenced as embedded images in one of the "text/html" parts of the message.
如果消息中有一个或多个部分是客户端UI应提供的可下载部分，则为真。如果“附件”列表至少包含一个没有“内容处置：内联”的项，则服务器应将hasAttachment设置为true。服务器可能会忽略此列表中以某种方式自动处理的部分，或者在消息的“text/html”部分中作为嵌入图像引用的部分。
The server MAY set hasAttachment based on implementation-defined or site-configurable heuristics.
服务器可以基于实现定义的或站点可配置的启发式设置hasAttachment。
o preview: "String" (immutable; server-set)
o 预览：“字符串”（不可变；服务器集）
A plaintext fragment of the message body. This is intended to be shown as a preview line when listing messages in the mail store and may be truncated when shown. The server may choose which part of the message to include in the preview; skipping quoted sections and salutations and collapsing white space can result in a more useful preview.
消息正文的纯文本片段。当在邮件存储中列出邮件时，这将显示为预览行，显示时可能会被截断。服务器可以选择预览中包含的消息部分；跳过引用的部分和问候语以及折叠空白可以生成更有用的预览。
This MUST NOT be more than 256 characters in length.
长度不得超过256个字符。
As this is derived from the message content by the server, and the algorithm for doing so could change over time, fetching this for an Email a second time MAY return a different result. However, the previous value is not considered incorrect, and the change SHOULD NOT cause the Email object to be considered as changed by the server.
由于这是由服务器从邮件内容中派生出来的，并且执行此操作的算法可能会随着时间的推移而改变，因此第二次获取此邮件可能会返回不同的结果。但是，之前的值不被认为是不正确的，并且该更改不应导致服务器将电子邮件对象视为已更改。
The exact algorithm for decomposing bodyStructure into textBody, htmlBody, and attachments part lists is not mandated, as this is a quality-of-service implementation issue and likely to require workarounds for malformed content discovered over time. However, the following algorithm (expressed here in JavaScript) is suggested as a starting point, based on real-world experience:
将bodyStructure分解为textBody、htmlBody和attachments部件列表的精确算法没有强制要求，因为这是一个服务质量实现问题，可能需要解决随着时间的推移发现的格式错误的内容。但是，根据实际经验，以下算法（此处用JavaScript表示）建议作为起点：
function isInlineMediaType ( type ) {
return type.startsWith( 'image/' ) ||
type.startsWith( 'audio/' ) ||
type.startsWith( 'video/' );
}
function isInlineMediaType ( type ) {
return type.startsWith( 'image/' ) ||
type.startsWith( 'audio/' ) ||
type.startsWith( 'video/' );
}
function parseStructure ( parts, multipartType, inAlternative, htmlBody, textBody, attachments ) {
函数结构（部件、多部件类型、非可选、htmlBody、textBody、附件）{
// For multipartType == alternative
let textLength = textBody ? textBody.length : -1;
let htmlLength = htmlBody ? htmlBody.length : -1;
// For multipartType == alternative
let textLength = textBody ? textBody.length : -1;
let htmlLength = htmlBody ? htmlBody.length : -1;
for ( let i = 0; i < parts.length; i += 1 ) {
let part = parts[i];
let isMultipart = part.type.startsWith( 'multipart/' );
// Is this a body part rather than an attachment
let isInline = part.disposition != "attachment" &&
// Must be one of the allowed body types
( part.type == "text/plain" ||
part.type == "text/html" ||
isInlineMediaType( part.type ) ) &&
for ( let i = 0; i < parts.length; i += 1 ) {
let part = parts[i];
let isMultipart = part.type.startsWith( 'multipart/' );
// Is this a body part rather than an attachment
let isInline = part.disposition != "attachment" &&
// Must be one of the allowed body types
( part.type == "text/plain" ||
part.type == "text/html" ||
isInlineMediaType( part.type ) ) &&
// If multipart/related, only the first part can be inline
// If a text part with a filename, and not the first item
// in the multipart, assume it is an attachment
( i === 0 ||
( multipartType != "related" &&
( isInlineMediaType( part.type ) || !part.name ) ) );
// If multipart/related, only the first part can be inline
// If a text part with a filename, and not the first item
// in the multipart, assume it is an attachment
( i === 0 ||
( multipartType != "related" &&
( isInlineMediaType( part.type ) || !part.name ) ) );
if ( isMultipart ) {
let subMultiType = part.type.split( '/' )[1];
parseStructure( part.subParts, subMultiType,
inAlternative || ( subMultiType == 'alternative' ),
htmlBody, textBody, attachments );
} else if ( isInline ) {
if ( multipartType == 'alternative' ) {
switch ( part.type ) {
case 'text/plain':
textBody.push( part );
break;
case 'text/html':
htmlBody.push( part );
break;
default:
attachments.push( part );
break;
}
continue;
} else if ( inAlternative ) {
if ( part.type == 'text/plain' ) {
htmlBody = null;
}
if ( part.type == 'text/html' ) {
textBody = null;
}
}
if ( textBody ) {
textBody.push( part );
}
if ( htmlBody ) {
htmlBody.push( part );
}
if ( ( !textBody || !htmlBody ) &&
isInlineMediaType( part.type ) ) {
attachments.push( part );
}
} else {
attachments.push( part );
}
}
if ( isMultipart ) {
let subMultiType = part.type.split( '/' )[1];
parseStructure( part.subParts, subMultiType,
inAlternative || ( subMultiType == 'alternative' ),
htmlBody, textBody, attachments );
} else if ( isInline ) {
if ( multipartType == 'alternative' ) {
switch ( part.type ) {
case 'text/plain':
textBody.push( part );
break;
case 'text/html':
htmlBody.push( part );
break;
default:
attachments.push( part );
break;
}
continue;
} else if ( inAlternative ) {
if ( part.type == 'text/plain' ) {
htmlBody = null;
}
if ( part.type == 'text/html' ) {
textBody = null;
}
}
if ( textBody ) {
textBody.push( part );
}
if ( htmlBody ) {
htmlBody.push( part );
}
if ( ( !textBody || !htmlBody ) &&
isInlineMediaType( part.type ) ) {
attachments.push( part );
}
} else {
attachments.push( part );
}
}
if ( multipartType == 'alternative' && textBody && htmlBody ) {
// Found HTML part only
if ( textLength == textBody.length &&
htmlLength != htmlBody.length ) {
for ( let i = htmlLength; i < htmlBody.length; i += 1 ) {
textBody.push( htmlBody[i] );
}
}
// Found plaintext part only
if ( htmlLength == htmlBody.length &&
textLength != textBody.length ) {
for ( let i = textLength; i < textBody.length; i += 1 ) {
htmlBody.push( textBody[i] );
}
}
}
}
if ( multipartType == 'alternative' && textBody && htmlBody ) {
// Found HTML part only
if ( textLength == textBody.length &&
htmlLength != htmlBody.length ) {
for ( let i = htmlLength; i < htmlBody.length; i += 1 ) {
textBody.push( htmlBody[i] );
}
}
// Found plaintext part only
if ( htmlLength == htmlBody.length &&
textLength != textBody.length ) {
for ( let i = textLength; i < textBody.length; i += 1 ) {
htmlBody.push( textBody[i] );
}
}
}
}
// Usage:
let htmlBody = [];
let textBody = [];
let attachments = [];
// Usage:
let htmlBody = [];
let textBody = [];
let attachments = [];
parseStructure( [ bodyStructure ], 'mixed', false, htmlBody, textBody, attachments );
parseStructure（[bodyStructure]，'mixed'，false，htmlBody，textBody，attachments）；
For instance, consider a message with both text and HTML versions that has gone through a list software manager that attaches a header and footer. It might have a MIME structure something like:
例如，考虑一个带有文本和HTML版本的消息，它已经通过列表软件管理器附加了页眉和页脚。它可能具有类似于以下内容的MIME结构：
multipart/mixed
text/plain, content-disposition=inline - A
multipart/mixed
multipart/alternative
multipart/mixed
text/plain, content-disposition=inline - B
image/jpeg, content-disposition=inline - C
text/plain, content-disposition=inline - D
multipart/related
text/html - E
image/jpeg - F
image/jpeg, content-disposition=attachment - G
application/x-excel - H
message/rfc822 - J
text/plain, content-disposition=inline - K
multipart/mixed
text/plain, content-disposition=inline - A
multipart/mixed
multipart/alternative
multipart/mixed
text/plain, content-disposition=inline - B
image/jpeg, content-disposition=inline - C
text/plain, content-disposition=inline - D
multipart/related
text/html - E
image/jpeg - F
image/jpeg, content-disposition=attachment - G
application/x-excel - H
message/rfc822 - J
text/plain, content-disposition=inline - K
In this case, the above algorithm would decompose this to:
在这种情况下，上述算法会将其分解为：
textBody => [ A, B, C, D, K ]
htmlBody => [ A, E, K ]
attachments => [ C, F, G, H, J ]
textBody => [ A, B, C, D, K ]
htmlBody => [ A, E, K ]
attachments => [ C, F, G, H, J ]
This is a standard "/get" method as described in [RFC8620], Section 5.1 with the following additional request arguments:
这是一个标准的“/get”方法，如[RFC8620]第5.1节所述，具有以下附加请求参数：
o bodyProperties: "String[]"
o bodyProperties:“字符串[]”
A list of properties to fetch for each EmailBodyPart returned. If omitted, this defaults to:
要为返回的每个EmailBodyPart获取的属性列表。如果省略，则默认为：
[ "partId", "blobId", "size", "name", "type", "charset", "disposition", "cid", "language", "location" ]
[“partId”、“blobId”、“size”、“name”、“type”、“charset”、“disposition”、“cid”、“language”、“location”]
o fetchTextBodyValues: "Boolean" (default: false)
o fetchTextBodyValues：“布尔”（默认值：false）
If true, the "bodyValues" property includes any "text/*" part in the "textBody" property.
如果为true，“bodyValues”属性包括“textBody”属性中的任何“text/*”部分。
o fetchHTMLBodyValues: "Boolean" (default: false)
o FetchHtmlBodyValue：“布尔”（默认值：false）
If true, the "bodyValues" property includes any "text/*" part in the "htmlBody" property.
如果为true，“bodyValues”属性包括“htmlBody”属性中的任何“text/*”部分。
o fetchAllBodyValues: "Boolean" (default: false)
o fetchAllBodyValues：“布尔”（默认值：false）
If true, the "bodyValues" property includes any "text/*" part in the "bodyStructure" property.
如果为true，“bodyValues”属性包括“bodyStructure”属性中的任何“text/*”部分。
o maxBodyValueBytes: "UnsignedInt" (default: 0)
o maxBodyValueBytes：“UnsignedInt”（默认值：0）
If greater than zero, the "value" property of any EmailBodyValue object returned in "bodyValues" MUST be truncated if necessary so it does not exceed this number of octets in size. If 0 (the default), no truncation occurs.
如果大于零，则在“bodyValues”中返回的任何EmailBodyValue对象的“value”属性必须在必要时截断，以使其大小不超过此八位字节数。如果为0（默认值），则不会发生截断。
The server MUST ensure the truncation results in valid UTF-8 and does not occur mid-codepoint. If the part is of type "text/html", the server SHOULD NOT truncate inside an HTML tag, e.g., in the middle of "<a href="https://example.com">". There is no requirement for the truncated form to be a balanced tree or valid HTML (indeed, the original source may well be neither of these things).
服务器必须确保截断产生有效的UTF-8，并且不会发生在代码点中间。如果该部分是“text /html”类型，则服务器不应该在HTML标记中截断，例如，在“<aHeRF=”的中间。https://example.com">". 被截断的表单不需要是平衡树或有效的HTML（事实上，原始源代码很可能不是这两种东西）。
If the standard "properties" argument is omitted or null, the following default MUST be used instead of "all" properties:
如果省略了标准“properties”参数或为null，则必须使用以下默认值，而不是“all”属性：
[ "id", "blobId", "threadId", "mailboxIds", "keywords", "size", "receivedAt", "messageId", "inReplyTo", "references", "sender", "from", "to", "cc", "bcc", "replyTo", "subject", "sentAt", "hasAttachment", "preview", "bodyValues", "textBody", "htmlBody", "attachments" ]
[“id”、“blobId”、“threadId”、“MailboxID”、“关键字”、“大小”、“receivedAt”、“messageId”、“inReplyTo”、“引用”、“发件人”、“发件人”、“收件人”、“抄送”、“密件抄送”、“回复收件人”、“主题”、“发送”、“附件”、“预览”、“正文值”、“正文”、“正文”、“正文”、“附件”]
The following properties are expected to be fast to fetch in a quality implementation:
以下属性有望快速获取高质量的实现：
o id
o 身份证件
o blobId
o 臃肿
o threadId
o 线状
o mailboxIds
o 邮箱ID
o keywords
o 关键词
o size
o 大小
o receivedAt
o 收到
o messageId
o 消息ID
o inReplyTo
o 替代
o sender
o 发件人
o from
o 从…起
o to
o 到
o cc
o 复写的副本
o bcc
o 密件抄送
o replyTo
o 答复
o subject
o 主题
o sentAt
o 森塔特
o hasAttachment
o 附件
o preview
o 预览
Clients SHOULD take care when fetching any other properties, as there may be significantly longer latency in fetching and returning the data.
客户端在获取任何其他属性时都应该小心，因为获取和返回数据时可能会有更长的延迟。
As specified above, parsed forms of headers may only be used on appropriate header fields. Attempting to fetch a form that is forbidden (e.g., "header:From:asDate") MUST result in the method call being rejected with an "invalidArguments" error.
如上所述，解析形式的头只能在适当的头字段上使用。试图获取被禁止的表单（例如，“header:From:asDate”）必须导致方法调用被拒绝，并出现“invalidArguments”错误。
Where a specific header field is requested as a property, the capitalization of the property name in the response MUST be identical to that used in the request.
如果请求将特定头字段作为属性，则响应中属性名称的大小写必须与请求中使用的相同。
Request:
请求：
[[ "Email/get", {
"ids": [ "f123u456", "f123u457" ],
"properties": [ "threadId", "mailboxIds", "from", "subject",
"receivedAt", "header:List-POST:asURLs",
"htmlBody", "bodyValues" ],
"bodyProperties": [ "partId", "blobId", "size", "type" ],
"fetchHTMLBodyValues": true,
"maxBodyValueBytes": 256
}, "#1" ]]
[[ "Email/get", {
"ids": [ "f123u456", "f123u457" ],
"properties": [ "threadId", "mailboxIds", "from", "subject",
"receivedAt", "header:List-POST:asURLs",
"htmlBody", "bodyValues" ],
"bodyProperties": [ "partId", "blobId", "size", "type" ],
"fetchHTMLBodyValues": true,
"maxBodyValueBytes": 256
}, "#1" ]]
and response:
答复:
[[ "Email/get", {
"accountId": "abc",
"state": "41234123231",
"list": [
{
"id": "f123u457",
"threadId": "ef1314a",
"mailboxIds": { "f123": true },
"from": [{ "name": "Joe Bloggs", "email": "joe@example.com" }],
"subject": "Dinner on Thursday?",
"receivedAt": "2013-10-13T14:12:00Z",
"header:List-POST:asURLs": [
"mailto:partytime@lists.example.com"
],
"htmlBody": [{
"partId": "1",
"blobId": "B841623871",
"size": 283331,
"type": "text/html"
[[ "Email/get", {
"accountId": "abc",
"state": "41234123231",
"list": [
{
"id": "f123u457",
"threadId": "ef1314a",
"mailboxIds": { "f123": true },
"from": [{ "name": "Joe Bloggs", "email": "joe@example.com" }],
"subject": "Dinner on Thursday?",
"receivedAt": "2013-10-13T14:12:00Z",
"header:List-POST:asURLs": [
"mailto:partytime@lists.example.com"
],
"htmlBody": [{
"partId": "1",
"blobId": "B841623871",
"size": 283331,
"type": "text/html"
}, {
"partId": "2",
"blobId": "B319437193",
"size": 10343,
"type": "text/plain"
}],
"bodyValues": {
"1": {
"isEncodingProblem": false,
"isTruncated": true,
"value": "<html><body><p>Hello ..."
},
"2": {
"isEncodingProblem": false,
"isTruncated": false,
"value": "-- Sent by your friendly mailing list ..."
}
}
}
],
"notFound": [ "f123u456" ]
}, "#1" ]]
}, {
"partId": "2",
"blobId": "B319437193",
"size": 10343,
"type": "text/plain"
}],
"bodyValues": {
"1": {
"isEncodingProblem": false,
"isTruncated": true,
"value": "<html><body><p>Hello ..."
},
"2": {
"isEncodingProblem": false,
"isTruncated": false,
"value": "-- Sent by your friendly mailing list ..."
}
}
}
],
"notFound": [ "f123u456" ]
}, "#1" ]]
This is a standard "/changes" method as described in [RFC8620], Section 5.2. If generating intermediate states for a large set of changes, it is recommended that newer changes be returned first, as these are generally of more interest to users.
这是[RFC8620]第5.2节所述的标准“/变更”方法。如果为一大组更改生成中间状态，建议首先返回较新的更改，因为用户通常更感兴趣这些更改。
This is a standard "/query" method as described in [RFC8620], Section 5.5 but with the following additional request arguments:
这是[RFC8620]第5.5节所述的标准“/query”方法，但具有以下附加请求参数：
o collapseThreads: "Boolean" (default: false)
o collapseThreads：“布尔”（默认值：false）
If true, Emails in the same Thread as a previous Email in the list (given the filter and sort order) will be removed from the list. This means only one Email at most will be included in the list for any given Thread.
如果为true，则与列表中的前一封电子邮件相同的线程中的电子邮件（给定筛选和排序顺序）将从列表中删除。这意味着对于任何给定的线程，列表中最多只包含一封电子邮件。
In quality implementations, the query "total" property is expected to be fast to calculate when the filter consists solely of a single "inMailbox" property, as it is the same as the totalEmails or totalThreads properties (depending on whether collapseThreads is true) of the associated Mailbox object.
在高质量实现中，当筛选器仅由单个“inMailbox”属性组成时，查询“total”属性的计算速度预计会很快，因为它与关联邮箱对象的totalEmails或totalThreads属性（取决于collapseThreads是否为true）相同。
A *FilterCondition* object has the following properties, any of which may be omitted:
*FilterCondition*对象具有以下属性，其中任何属性都可以省略：
o inMailbox: "Id"
o 邮箱：“Id”
A Mailbox id. An Email must be in this Mailbox to match the condition.
邮箱id。此邮箱中必须有电子邮件才能符合条件。
o inMailboxOtherThan: "Id[]"
o InMailboxOthern:“Id[]”
A list of Mailbox ids. An Email must be in at least one Mailbox not in this list to match the condition. This is to allow messages solely in trash/spam to be easily excluded from a search.
邮箱ID的列表。电子邮件必须至少位于一个不在此列表中的邮箱中，才能符合条件。这是为了让垃圾/垃圾邮件中的邮件可以轻松地从搜索中排除。
o before: "UTCDate"
o 在“UTCDate”之前
The "receivedAt" date-time of the Email must be before this date-time to match the condition.
电子邮件的“receivedAt”日期时间必须早于此日期时间以符合条件。
o after: "UTCDate"
o “UTCDate”之后
The "receivedAt" date-time of the Email must be the same or after this date-time to match the condition.
电子邮件的“receivedAt”日期时间必须与此日期时间相同或晚于此日期时间，以符合条件。
o minSize: "UnsignedInt"
o minSize：“未签名”
The "size" property of the Email must be equal to or greater than this number to match the condition.
电子邮件的“大小”属性必须等于或大于此数字才能与条件匹配。
o maxSize: "UnsignedInt"
o maxSize:“未签名”
The "size" property of the Email must be less than this number to match the condition.
电子邮件的“大小”属性必须小于此数字才能与条件匹配。
o allInThreadHaveKeyword: "String"
o Allinthreadhave关键字：“字符串”
All Emails (including this one) in the same Thread as this Email must have the given keyword to match the condition.
与此电子邮件位于同一线程中的所有电子邮件（包括此电子邮件）必须具有给定的关键字以匹配条件。
o someInThreadHaveKeyword: "String"
o someInThreadHaveKeyword：“字符串”
At least one Email (possibly this one) in the same Thread as this Email must have the given keyword to match the condition.
与此电子邮件位于同一线程中的至少一封电子邮件（可能是这封）必须具有给定的关键字才能与条件匹配。
o noneInThreadHaveKeyword: "String"
o noneInThreadHaveKeyword:“字符串”
All Emails (including this one) in the same Thread as this Email must *not* have the given keyword to match the condition.
与此电子邮件位于同一线程中的所有电子邮件（包括此邮件）必须*不*具有给定的关键字以匹配条件。
o hasKeyword: "String"
o 关键词：“字符串”
This Email must have the given keyword to match the condition.
此电子邮件必须具有与条件匹配的给定关键字。
o notKeyword: "String"
o notKeyword:“字符串”
This Email must not have the given keyword to match the condition.
此电子邮件不得具有与条件匹配的给定关键字。
o hasAttachment: "Boolean"
o hasAttachment:“布尔”
The "hasAttachment" property of the Email must be identical to the value given to match the condition.
电子邮件的“hasAttachment”属性必须与给定的值相同，以匹配条件。
o text: "String"
o 文本：“字符串”
Looks for the text in Emails. The server MUST look up text in the From, To, Cc, Bcc, and Subject header fields of the message and SHOULD look inside any "text/*" or other body parts that may be converted to text by the server. The server MAY extend the search to any additional textual property.
在电子邮件中查找文本。服务器必须在邮件的“发件人”、“收件人”、“抄送”、“密件抄送”和“主题”标题字段中查找文本，并应查找任何“文本/*”或服务器可能转换为文本的其他正文部分。服务器可以将搜索扩展到任何其他文本属性。
o from: "String"
o 来自：“字符串”
Looks for the text in the From header field of the message.
在邮件的“发件人标头”字段中查找文本。
o to: "String"
o 致：“字符串”
Looks for the text in the To header field of the message.
在邮件的“收件人”标题字段中查找文本。
o cc: "String"
o 抄送：“字符串”
Looks for the text in the Cc header field of the message.
在邮件的“抄送头”字段中查找文本。
o bcc: "String"
o 密件抄送：“字符串”
Looks for the text in the Bcc header field of the message.
在邮件的密件抄送标头字段中查找文本。
o subject: "String"
o 主题：“字符串”
Looks for the text in the Subject header field of the message.
在邮件的主题标题字段中查找文本。
o body: "String"
o 正文：“字符串”
Looks for the text in one of the body parts of the message. The server MAY exclude MIME body parts with content media types other than "text/*" and "message/*" from consideration in search matching. Care should be taken to match based on the text content actually presented to an end user by viewers for that media type or otherwise identified as appropriate for search indexing. Matching document metadata uninteresting to an end user (e.g., markup tag and attribute names) is undesirable.
在邮件的一个正文部分中查找文本。在搜索匹配中，服务器可能会将内容媒体类型不是“text/*”和“message/*”的MIME正文部分排除在考虑范围之外。应注意根据观众针对该媒体类型实际呈现给最终用户的文本内容进行匹配，或根据搜索索引的需要进行识别。匹配最终用户不感兴趣的文档元数据（例如标记标记和属性名称）是不可取的。
o header: "String[]"
o 标题：“字符串[]”
The array MUST contain either one or two elements. The first element is the name of the header field to match against. The second (optional) element is the text to look for in the header field value. If not supplied, the message matches simply if it has a header field of the given name.
数组必须包含一个或两个元素。第一个元素是要匹配的标题字段的名称。第二个（可选）元素是要在标题字段值中查找的文本。如果未提供，则消息仅在具有给定名称的头字段时匹配。
If zero properties are specified on the FilterCondition, the condition MUST always evaluate to true. If multiple properties are specified, ALL must apply for the condition to be true (it is equivalent to splitting the object into one-property conditions and making them all the child of an AND filter operator).
如果在FilterCondition上指定了零属性，则该条件的计算结果必须始终为true。如果指定了多个属性，则所有属性都必须应用该条件才能为真（这相当于将对象拆分为一个属性条件，并使它们都成为and筛选器运算符的子对象）。
The exact semantics for matching "String" fields is *deliberately not defined* to allow for flexibility in indexing implementation, subject to the following:
匹配“字符串”字段的确切语义*故意未定义*以允许索引实现的灵活性，但需遵守以下规定：
o Any syntactically correct encoded sections [RFC2047] of header fields with a known encoding SHOULD be decoded before attempting to match text.
o 在尝试匹配文本之前，应解码具有已知编码的标题字段的任何语法正确的编码部分[RFC2047]。
o When searching inside a "text/html" body part, any text considered markup rather than content SHOULD be ignored, including HTML tags and most attributes, anything inside the "<head>" tag, Cascading Style Sheets (CSS), and JavaScript. Attribute content intended for presentation to the user such as "alt" and "title" SHOULD be considered in the search.
o 在“text/html”主体部分内搜索时，应忽略任何被视为标记而非内容的文本，包括html标记和大多数属性、“<head>”标记内的任何内容、级联样式表（CSS）和JavaScript。搜索时应考虑用于向用户演示的属性内容，如“alt”和“title”。
o Text SHOULD be matched in a case-insensitive manner.
o 文本应以不区分大小写的方式匹配。
o Text contained in either (but matched) single (') or double (") quotes SHOULD be treated as a *phrase search*; that is, a match is required for that exact word or sequence of words, excluding the surrounding quotation marks.
o 包含在（但匹配的）单（'）或双（“）引号中的文本应视为*短语搜索*；也就是说，除了周围的引号外，该词或词序列需要匹配。
Within a phrase, to match one of the following characters you MUST escape it by prefixing it with a backslash (\):
在短语中，要匹配以下字符之一，必须在其前面加反斜杠（\）以转义：
' " \
' " \
o Outside of a phrase, white space SHOULD be treated as dividing separate tokens that may be searched for separately but MUST all be present for the Email to match the filter.
o 在短语之外，空白应被视为分隔单独的标记，可以单独搜索这些标记，但必须全部存在才能使电子邮件与筛选器匹配。
o Tokens (not part of a phrase) MAY be matched on a whole-word basis using stemming (for example, a text search for "bus" would match "buses" but not "business").
o 标记（不是短语的一部分）可以使用词干匹配整个单词（例如，对“bus”的文本搜索将匹配“bus”而不是“business”）。
The following value for the "property" field on the Comparator object MUST be supported for sorting:
排序时必须支持比较器对象上“property”字段的以下值：
o "receivedAt" - The "receivedAt" date as returned in the Email object.
o “receivedAt”-电子邮件对象中返回的“receivedAt”日期。
The following values for the "property" field on the Comparator object SHOULD be supported for sorting. When specifying a "hasKeyword", "allInThreadHaveKeyword", or "someInThreadHaveKeyword" sort, the Comparator object MUST also have a "keyword" property.
排序时应支持比较器对象上“property”字段的以下值。指定“hasKeyword”、“AllintReadHaveKeyword”或“someInThreadHaveKeyword”排序时，Comparator对象还必须具有“keyword”属性。
o "size" - The "size" as returned in the Email object.
o “大小”-电子邮件对象中返回的“大小”。
o "from" - This is taken to be either the "name" property or if null/empty, the "email" property of the *first* EmailAddress object in the Email's "from" property. If still none, consider the value to be the empty string.
o “from”-这被视为“name”属性，如果为null/空，则为电子邮件“from”属性中*first*EmailAddress对象的“email”属性。如果仍然没有，则将该值视为空字符串。
o "to" - This is taken to be either the "name" property or if null/ empty, the "email" property of the *first* EmailAddress object in the Email's "to" property. If still none, consider the value to be the empty string.
o “to”-这被视为“name”属性，如果为null/空，则为电子邮件的“to”属性中*first*EmailAddress对象的“email”属性。如果仍然没有，则将该值视为空字符串。
o "subject" - This is taken to be the base subject of the message, as defined in Section 2.1 of [RFC5256].
o “主题”-根据[RFC5256]第2.1节的定义，这被视为消息的基本主题。
o "sentAt" - The "sentAt" property on the Email object.
o “sentAt”-电子邮件对象上的“sentAt”属性。
o "hasKeyword" - This value MUST be considered true if the Email has the keyword given as an additional "keyword" property on the Comparator object, or false otherwise.
o “hasKeyword”-如果电子邮件将关键字作为Comparator对象的附加“keyword”属性给出，则此值必须视为true，否则为false。
o "allInThreadHaveKeyword" - This value MUST be considered true for the Email if *all* of the Emails in the same Thread have the keyword given as an additional "keyword" property on the Comparator object.
o “allInThreadHaveKeyword”-如果同一线程中的*所有*电子邮件的关键字作为Comparator对象上的附加“关键字”属性给定，则该值必须被视为电子邮件的真值。
o "someInThreadHaveKeyword" - This value MUST be considered true for the Email if *any* of the Emails in the same Thread have the keyword given as an additional "keyword" property on the Comparator object.
o “someInThreadHaveKeyword”-如果同一线程中的*任何*电子邮件的关键字作为Comparator对象上的附加“keyword”属性给定，则该值对于电子邮件必须被视为true。
The server MAY support sorting based on other properties as well. A client can discover which properties are supported by inspecting the account's "capabilities" object (see Section 1.3).
服务器也可以支持基于其他属性的排序。客户端可以通过检查帐户的“功能”对象来发现支持哪些属性（请参见第1.3节）。
Example sort:
示例排序：
[{
"property": "someInThreadHaveKeyword",
"keyword": "$flagged",
"isAscending": false
}, {
"property": "subject",
"collation": "i;ascii-casemap"
}, {
"property": "receivedAt",
"isAscending": false
}]
[{
"property": "someInThreadHaveKeyword",
"keyword": "$flagged",
"isAscending": false
}, {
"property": "subject",
"collation": "i;ascii-casemap"
}, {
"property": "receivedAt",
"isAscending": false
}]
This would sort Emails in flagged Threads first (the Thread is considered flagged if any Email within it is flagged), in subject order second, and then from newest first for messages with the same subject. If two Emails have identical values for all three properties, then the order is server dependent but must be stable.
这将首先按照标记的线程对电子邮件进行排序（如果其中有任何电子邮件被标记，则该线程将被视为已标记），然后按照主题顺序对电子邮件进行排序，然后从最新的第一个线程对具有相同主题的邮件进行排序。如果两封电子邮件的所有三个属性的值相同，则顺序取决于服务器，但必须稳定。
When "collapseThreads" is true, then after filtering and sorting the Email list, the list is further winnowed by removing any Emails for a Thread id that has already been seen (when passing through the list sequentially). A Thread will therefore only appear *once* in the result, at the position of the first Email in the list that belongs to the Thread (given the current sort/filter).
当“collapseThreads”为true时，在对电子邮件列表进行过滤和排序后，通过删除已看到的线程id的任何电子邮件（当按顺序通过列表时），进一步筛选该列表。因此，一个线程将只在结果中出现*一次*，位于属于该线程的列表中第一封电子邮件的位置（给定当前排序/筛选器）。
This is a standard "/queryChanges" method as described in [RFC8620], Section 5.6 with the following additional request argument:
这是一种标准的“/queryChanges”方法，如[RFC8620]第5.6节所述，带有以下附加请求参数：
o collapseThreads: "Boolean" (default: false)
o collapseThreads：“布尔”（默认值：false）
The "collapseThreads" argument that was used with "Email/query".
与“Email/query”一起使用的“collapseThreads”参数。
This is a standard "/set" method as described in [RFC8620], Section 5.3. The "Email/set" method encompasses:
这是[RFC8620]第5.3节所述的标准“/set”方法。“电子邮件/设置”方法包括：
o Creating a draft
o 创建草稿
o Changing the keywords of an Email (e.g., unread/flagged status)
o 更改电子邮件的关键字（例如，未读/标记状态）
o Adding/removing an Email to/from Mailboxes (moving a message)
o 在邮箱中添加/删除电子邮件（移动邮件）
o Deleting Emails
o 删除电子邮件
The format of the "keywords"/"mailboxIds" properties means that when updating an Email, you can either replace the entire set of keywords/ Mailboxes (by setting the full value of the property) or add/remove individual ones using the JMAP patch syntax (see [RFC8620], Section 5.3 for the specification and Section 5.7 for an example).
“关键字”/“MailboxID”属性的格式意味着在更新电子邮件时，您可以替换整个关键字/邮箱集（通过设置属性的完整值），或者使用JMAP修补程序语法添加/删除单个关键字/邮箱（参见[RFC8620]，第5.3节了解规范，第5.7节了解示例）。
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 the message [RFC5322] to create is unambiguous, the following constraints apply to Email objects submitted for creation:
由于电子邮件对象的格式不同，在创建电子邮件时，有多种方法可以指定相同的信息。为确保要创建的消息[RFC5322]明确无误，以下约束适用于提交创建的电子邮件对象：
o The "headers" property MUST NOT be given on either the top-level Email or an EmailBodyPart -- the client must set each header field as an individual property.
o “headers”属性不能在顶级电子邮件或EmailBodyPart上提供——客户端必须将每个标题字段设置为单个属性。
o There MUST NOT be two properties that represent the same header field (e.g., "header:from" and "from") within the Email or particular EmailBodyPart.
o 在电子邮件或特定的EmailBodyPart中，不能有两个属性表示相同的标题字段（例如，“标题：发件人”和“发件人”）。
o Header fields MUST NOT be specified in parsed forms that are forbidden for that particular field.
o 不得在特定字段禁止的已解析表单中指定标题字段。
o Header fields beginning with "Content-" MUST NOT be specified on the Email object, only on EmailBodyPart objects.
o 不能在电子邮件对象上指定以“Content-”开头的标题字段，只能在EmailBodyPart对象上指定。
o If a "bodyStructure" property is given, there MUST NOT be "textBody", "htmlBody", or "attachments" properties.
o 如果给定了“bodyStructure”属性，则不能有“textBody”、“htmlBody”或“attachments”属性。
o If given, the "bodyStructure" EmailBodyPart MUST NOT contain a property representing a header field that is already defined on the top-level Email object.
o 如果给定，“bodyStructure”EmailBodyPart不能包含表示顶级电子邮件对象上已定义的标题字段的属性。
o If given, textBody MUST contain exactly one body part and it MUST be of type "text/plain".
o 如果给定，textBody必须仅包含一个正文部分，并且必须为“text/plain”类型。
o If given, htmlBody MUST contain exactly one body part and it MUST be of type "text/html".
o 如果给定，htmlBody必须只包含一个主体部分，并且必须是“text/html”类型。
o Within an EmailBodyPart:
o 在EmailBodyPart中：
* The client may specify a partId OR a blobId, but not both. If a partId is given, this partId MUST be present in the "bodyValues" property.
* 客户机可以指定partId或blobId，但不能同时指定两者。如果给定partId，则该partId必须出现在“bodyValues”属性中。
* The "charset" property MUST be omitted if a partId is given (the part's content is included in bodyValues, and the server may choose any appropriate encoding).
* 如果给定partId，则必须省略“charset”属性（partId的内容包含在BodyValue中，服务器可以选择任何适当的编码）。
* The "size" property MUST be omitted if a partId is given. If a blobId is given, it may be included but is ignored by the server (the size is actually calculated from the blob content itself).
* 如果给定partId，则必须省略“size”属性。如果给出了blobId，它可能会被包括在内，但会被服务器忽略（大小实际上是根据blob内容本身计算出来的）。
* A Content-Transfer-Encoding header field MUST NOT be given.
* 不得提供内容传输编码标头字段。
o Within an EmailBodyValue object, isEncodingProblem and isTruncated MUST be either false or omitted.
o 在EmailBodyValue对象中，isEncodingProblem和IsRuncated必须为false或省略。
Creation attempts that violate any of this SHOULD be rejected with an "invalidProperties" error; however, a server MAY choose to modify the Email (e.g., choose between conflicting headers, use a different content-encoding, etc.) to comply with its requirements instead.
违反上述任何一项的创建尝试均应以“invalidProperties”错误予以拒绝；但是，服务器可以选择修改电子邮件（例如，在冲突的标题之间进行选择，使用不同的内容编码等），以符合其要求。
The server MAY also choose to set additional headers. If not included, the server MUST generate and set a Message-ID header field in conformance with [RFC5322], Section 3.6.4 and a Date header field in conformance with Section 3.6.1.
服务器还可以选择设置其他头。如果未包括，服务器必须生成并设置符合[RFC5322]第3.6.4节的消息ID头字段和符合第3.6.1节的日期头字段。
The final message generated may be invalid per RFC 5322. For example, if it is a half-finished draft, the To header field may have a value that does not conform to the required syntax for this header. The message will be checked for strict conformance when submitted for sending (see the EmailSubmission object description).
根据RFC 5322，生成的最终消息可能无效。例如，如果是半成品草稿，“收件人”标题字段的值可能不符合此标题所需的语法。提交发送时，将检查邮件是否严格符合要求（请参阅EmailSubmission对象描述）。
Destroying an Email removes it from all Mailboxes to which it belonged. To just delete an Email to trash, simply change the "mailboxIds" property, so it is now in the Mailbox with a "role" property equal to "trash", and remove all other Mailbox ids.
销毁电子邮件会将其从其所属的所有邮箱中删除。若要仅删除要丢弃的电子邮件，只需更改“MailboxID”属性，使其现在位于邮箱中，且“role”属性等于“trash”，然后删除所有其他邮箱ID。
When emptying the trash, clients SHOULD NOT destroy Emails that are also in a Mailbox other than trash. For those Emails, they SHOULD just remove the trash Mailbox from the Email.
清空垃圾箱时，客户端不应销毁除垃圾箱以外邮箱中的电子邮件。对于那些电子邮件，他们应该从电子邮件中删除垃圾邮箱。
For successfully created Email objects, the "created" response contains the "id", "blobId", "threadId", and "size" properties of the object.
对于成功创建的电子邮件对象，“created”响应包含对象的“id”、“blobId”、“threadId”和“size”属性。
The following extra SetError types are defined:
定义了以下额外的SetError类型：
For "create":
对于“创建”：
o "blobNotFound": At least one blob id given for an EmailBodyPart doesn't exist. An extra "notFound" property of type "Id[]" MUST be included in the SetError object containing every "blobId" referenced by an EmailBodyPart that could not be found on the server.
o “blobNotFound”：为EmailBodyPart提供的至少一个blob id不存在。SetError对象中必须包含类型为“Id[]”的额外“notFound”属性，该属性包含服务器上找不到的EmailBodyPart引用的每个“blobId”。
For "create" and "update":
对于“创建”和“更新”：
o "tooManyKeywords": The change to the Email's keywords would exceed a server-defined maximum.
o “tooManyKeywords”：对电子邮件关键字的更改将超过服务器定义的最大值。
o "tooManyMailboxes": The change to the set of Mailboxes that this Email is in would exceed a server-defined maximum.
o “ToomanyMailbox”：对此电子邮件所在邮箱集的更改将超过服务器定义的最大值。
This is a standard "/copy" method as described in [RFC8620], Section 5.4, except only the "mailboxIds", "keywords", and "receivedAt" properties may be set during the copy. This method cannot modify the message represented by the Email.
这是[RFC8620]第5.4节所述的标准“/复制”方法，但在复制过程中只能设置“MailboxID”、“关键字”和“receivedAt”属性。此方法无法修改电子邮件所代表的邮件。
The server MAY forbid two Email objects with identical message content [RFC5322], or even just with the same Message-ID [RFC5322], to coexist within an account; if the target account already has the Email, the copy will be rejected with a standard "alreadyExists" error.
服务器可能会禁止具有相同邮件内容[RFC5322]，甚至具有相同邮件ID[RFC5322]的两个电子邮件对象在一个帐户内共存；如果目标帐户已经有电子邮件，则该副本将被拒绝，并出现标准的“alreadyExists”错误。
For successfully copied Email objects, the "created" response contains the "id", "blobId", "threadId", and "size" properties of the new object.
对于成功复制的电子邮件对象，“created”响应包含新对象的“id”、“blobId”、“threadId”和“size”属性。
The "Email/import" method adds messages [RFC5322] to the set of Emails in an account. The server MUST support messages with Email Address Internationalization (EAI) headers [RFC6532]. The messages must first be uploaded as blobs using the standard upload mechanism. The method takes the following arguments:
“电子邮件/导入”方法将消息[RFC5322]添加到帐户中的电子邮件集。服务器必须支持电子邮件地址国际化（EAI）标题为[RFC6532]的邮件。必须首先使用标准上载机制将消息作为blob上载。该方法采用以下参数：
o accountId: "Id"
o 帐户Id:“Id”
The id of the account to use.
要使用的帐户的id。
o ifInState: "String|null"
o i说明：“字符串|空”
This is a state string as returned by the "Email/get" method. If supplied, the string must match the current state of the account referenced by the accountId; otherwise, the method will be aborted and a "stateMismatch" error returned. If null, any changes will be applied to the current state.
这是“Email/get”方法返回的状态字符串。如果提供，字符串必须与accountId引用的帐户的当前状态匹配；否则，该方法将被中止，并返回“StateMatch”错误。如果为null，则任何更改都将应用于当前状态。
o emails: "Id[EmailImport]"
o 电子邮件：“Id[电子邮件导入]”
A map of creation id (client specified) to EmailImport objects.
创建id（客户端指定）到EmailImport对象的映射。
An *EmailImport* object has the following properties:
*EmailImport*对象具有以下属性：
o blobId: "Id"
o blobId：“Id”
The id of the blob containing the raw message [RFC5322].
包含原始消息[RFC5322]的blob的id。
o mailboxIds: "Id[Boolean]"
o MailboxID:“Id[布尔值]”
The ids of the Mailboxes to assign this Email to. At least one Mailbox MUST be given.
要将此电子邮件分配给的邮箱的ID。必须至少提供一个邮箱。
o keywords: "String[Boolean]" (default: {})
o 关键词：“字符串[布尔]”（默认值：{}）
The keywords to apply to the Email.
要应用于电子邮件的关键字。
o receivedAt: "UTCDate" (default: time of most recent Received header, or time of import on server if none)
o receivedAt：“UTCDate”（默认值：最近接收到的头的时间，或在服务器上导入的时间（如果没有）
The "receivedAt" date to set on the Email.
要在电子邮件上设置的“receivedAt”日期。
Each Email to import is considered an atomic unit that may succeed or fail individually. Importing successfully creates a new Email object from the data referenced by the blobId and applies the given Mailboxes, keywords, and receivedAt date.
要导入的每封电子邮件都被视为一个原子单元，可能成功，也可能失败。导入成功地从blobId引用的数据创建新的电子邮件对象，并应用给定的邮箱、关键字和接收日期。
The server MAY forbid two Email objects with the same exact content [RFC5322], or even just with the same Message-ID [RFC5322], to coexist within an account. In this case, it MUST reject attempts to import an Email considered to be a duplicate with an "alreadyExists" SetError. An "existingId" property of type "Id" MUST be included on the SetError object with the id of the existing Email. If duplicates are allowed, the newly created Email object MUST have a separate id and independent mutable properties to the existing object.
服务器可能会禁止具有相同确切内容[RFC5322]，甚至仅具有相同邮件ID[RFC5322]的两个电子邮件对象在一个帐户内共存。在这种情况下，它必须拒绝导入被视为具有“alreadyExists”设置错误的重复电子邮件的尝试。SetError对象上必须包含“Id”类型的“existingId”属性，该属性的Id为现有电子邮件的Id。如果允许重复，新创建的电子邮件对象必须具有单独的id，并且与现有对象具有独立的可变属性。
If the "blobId", "mailboxIds", or "keywords" properties are invalid (e.g., missing, wrong type, id not found), the server MUST reject the import with an "invalidProperties" SetError.
如果“blobId”、“MailboxID”或“keywords”属性无效（例如，缺少、类型错误、找不到id），服务器必须拒绝导入，并显示“invalidProperties”设置错误。
If the Email cannot be imported because it would take the account over quota, the import should be rejected with an "overQuota" SetError.
如果由于帐户超过配额而无法导入电子邮件，则应拒绝导入，并显示“overQuota”设置错误。
If the blob referenced is not a valid message [RFC5322], the server MAY modify the message to fix errors (such as removing NUL octets or fixing invalid headers). If it does this, the "blobId" on the response MUST represent the new representation and therefore be different to the "blobId" on the EmailImport object. Alternatively, the server MAY reject the import with an "invalidEmail" SetError.
如果引用的blob不是有效消息[RFC5322]，服务器可能会修改该消息以修复错误（例如删除NUL八位字节或修复无效头）。如果这样做，响应上的“blobId”必须表示新的表示，因此与EmailImport对象上的“blobId”不同。或者，服务器可能会以“invalidEmail”设置错误拒绝导入。
The response has the following arguments:
响应具有以下参数：
o accountId: "Id"
o 帐户Id:“Id”
The id of the account used for this call.
用于此呼叫的帐户的id。
o oldState: "String|null"
o oldState:“字符串|空”
The state string that would have been returned by "Email/get" on this account before making the requested changes, or null if the server doesn't know what the previous state string was.
在进行请求的更改之前，此帐户上的“Email/get”将返回的状态字符串，如果服务器不知道以前的状态字符串是什么，则返回null。
o newState: "String"
o 新闻状态：“字符串”
The state string that will now be returned by "Email/get" on this account.
现在将通过此帐户上的“Email/get”返回的状态字符串。
o created: "Id[Email]|null"
o 已创建：“Id[电子邮件]|空”
A map of the creation id to an object containing the "id", "blobId", "threadId", and "size" properties for each successfully imported Email, or null if none.
创建id到对象的映射，该对象包含每个成功导入电子邮件的“id”、“blobId”、“threadId”和“size”属性，如果没有，则为null。
o notCreated: "Id[SetError]|null"
o notCreated:“Id[SetError]| null”
A map of the creation id to a SetError object for each Email that failed to be created, or null if all successful. The possible errors are defined above.
创建失败的每封电子邮件的创建id到SetError对象的映射，如果全部成功，则为null。上面定义了可能的错误。
The following additional errors may be returned instead of the "Email/import" response:
可能会返回以下附加错误，而不是“电子邮件/导入”响应：
"stateMismatch": An "ifInState" argument was supplied, and it does not match the current state.
“StateMatch”：提供了一个“ifInState”参数，但该参数与当前状态不匹配。
This method allows you to parse blobs as messages [RFC5322] to get Email objects. The server MUST support messages with EAI headers [RFC6532]. This can be used to parse and display attached messages without having to import them as top-level Email objects in the mail store in their own right.
此方法允许您将blob解析为消息[RFC5322]，以获取电子邮件对象。服务器必须支持带有EAI头[RFC6532]的消息。这可用于解析和显示附加邮件，而无需将其作为顶级电子邮件对象以其自身的权限导入邮件存储中。
The following metadata properties on the Email objects will be null if requested:
如果请求，电子邮件对象上的以下元数据属性将为空：
o id
o 身份证件
o mailboxIds
o 邮箱ID
o keywords
o 关键词
o receivedAt
o 收到
The "threadId" property of the Email MAY be present if the server can calculate which Thread the Email would be assigned to were it to be imported. Otherwise, this too is null if fetched.
如果服务器可以计算电子邮件导入时将分配给哪个线程，则电子邮件的“threadId”属性可能存在。否则，如果获取，这也是空的。
The "Email/parse" method takes the following arguments:
“Email/parse”方法采用以下参数：
o accountId: "Id"
o 帐户Id:“Id”
The id of the account to use.
要使用的帐户的id。
o blobIds: "Id[]"
o blobIds:“Id[]”
The ids of the blobs to parse.
要分析的Blob的ID。
o properties: "String[]"
o 属性：“字符串[]”
If supplied, only the properties listed in the array are returned for each Email object. If omitted, defaults to:
如果提供，则仅为每个电子邮件对象返回数组中列出的属性。如果省略，则默认为：
[ "messageId", "inReplyTo", "references", "sender", "from", "to", "cc", "bcc", "replyTo", "subject", "sentAt", "hasAttachment", "preview", "bodyValues", "textBody", "htmlBody", "attachments" ]
[“messageId”、“inReplyTo”、“references”、“sender”、“from”、“to”、“cc”、“bcc”、“replyTo”、“subject”、“sentAt”、“hasAttachment”、“preview”、“bodyValues”、“textBody”、“htmlBody”、“attachments”]
o bodyProperties: "String[]"
o bodyProperties:“字符串[]”
A list of properties to fetch for each EmailBodyPart returned. If omitted, defaults to the same value as the "Email/get" "bodyProperties" default argument.
要为返回的每个EmailBodyPart获取的属性列表。如果省略，则默认值与“Email/get”“bodyProperties”默认参数的值相同。
o fetchTextBodyValues: "Boolean" (default: false)
o fetchTextBodyValues：“布尔”（默认值：false）
If true, the "bodyValues" property includes any "text/*" part in the "textBody" property.
如果为true，“bodyValues”属性包括“textBody”属性中的任何“text/*”部分。
o fetchHTMLBodyValues: "Boolean" (default: false)
o FetchHtmlBodyValue：“布尔”（默认值：false）
If true, the "bodyValues" property includes any "text/*" part in the "htmlBody" property.
如果为true，“bodyValues”属性包括“htmlBody”属性中的任何“text/*”部分。
o fetchAllBodyValues: "Boolean" (default: false)
o fetchAllBodyValues：“布尔”（默认值：false）
If true, the "bodyValues" property includes any "text/*" part in the "bodyStructure" property.
如果为true，“bodyValues”属性包括“bodyStructure”属性中的任何“text/*”部分。
o maxBodyValueBytes: "UnsignedInt" (default: 0)
o maxBodyValueBytes：“UnsignedInt”（默认值：0）
If greater than zero, the "value" property of any EmailBodyValue object returned in "bodyValues" MUST be truncated if necessary so it does not exceed this number of octets in size. If 0 (the default), no truncation occurs.
如果大于零，则在“bodyValues”中返回的任何EmailBodyValue对象的“value”属性必须在必要时截断，以使其大小不超过此八位字节数。如果为0（默认值），则不会发生截断。
The server MUST ensure the truncation results in valid UTF-8 and does not occur mid-codepoint. If the part is of type "text/html", the server SHOULD NOT truncate inside an HTML tag, e.g., in the middle of "<a href="https://example.com">". There is no requirement for the truncated form to be a balanced tree or valid HTML (indeed, the original source may well be neither of these things).
服务器必须确保截断产生有效的UTF-8，并且不会发生在代码点中间。如果该部分是“text /html”类型，则服务器不应该在HTML标记中截断，例如，在“<aHeRF=”的中间。https://example.com">". 被截断的表单不需要是平衡树或有效的HTML（事实上，原始源代码很可能不是这两种东西）。
The response has the following arguments:
响应具有以下参数：
o accountId: "Id"
o 帐户Id:“Id”
The id of the account used for the call.
用于呼叫的帐户的id。
o parsed: "Id[Email]|null"
o 解析：“Id[电子邮件]|空”
A map of blob id to parsed Email representation for each successfully parsed blob, or null if none.
对于每个成功解析的blob，blob id到解析的电子邮件表示的映射，如果没有，则为null。
o notParsable: "Id[]|null"
o 不可解析：“Id[]| null”
A list of ids given that corresponded to blobs that could not be parsed as Emails, or null if none.
与无法解析为电子邮件的blob对应的给定ID列表，如果没有，则为null。
o notFound: "Id[]|null"
o 未找到：“Id[]|空”
A list of blob ids given that could not be found, or null if none.
给定的无法找到的blob ID列表，如果没有，则为null。
As specified above, parsed forms of headers may only be used on appropriate header fields. Attempting to fetch a form that is forbidden (e.g., "header:From:asDate") MUST result in the method call being rejected with an "invalidArguments" error.
如上所述，解析形式的头只能在适当的头字段上使用。试图获取被禁止的表单（例如，“header:From:asDate”）必须导致方法调用被拒绝，并出现“invalidArguments”错误。
Where a specific header field is requested as a property, the capitalization of the property name in the response MUST be identical to that used in the request.
如果请求将特定头字段作为属性，则响应中属性名称的大小写必须与请求中使用的相同。
A client logs in for the first time. It first fetches the set of Mailboxes. Now it will display the inbox to the user, which we will presume has Mailbox id "fb666a55". The inbox may be (very!) large, but the user's screen is only so big, so the client can just load the Threads it needs to fill the screen and then load in more only when the user scrolls. The client sends this request:
客户端第一次登录。它首先获取邮箱集。现在，它将向用户显示收件箱，我们假定其邮箱id为“fb666a55”。收件箱可能（非常！）大，但用户的屏幕只有这么大，因此客户端可以只加载填充屏幕所需的线程，然后仅在用户滚动时加载更多线程。客户端发送此请求：
[[ "Email/query",{
"accountId": "ue150411c",
"filter": {
"inMailbox": "fb666a55"
},
"sort": [{
"isAscending": false,
"property": "receivedAt"
}],
"collapseThreads": true,
[[ "Email/query",{
"accountId": "ue150411c",
"filter": {
"inMailbox": "fb666a55"
},
"sort": [{
"isAscending": false,
"property": "receivedAt"
}],
"collapseThreads": true,
"position": 0,
"limit": 30,
"calculateTotal": true
}, "0" ],
[ "Email/get", {
"accountId": "ue150411c",
"#ids": {
"resultOf": "0",
"name": "Email/query",
"path": "/ids"
},
"properties": [
"threadId"
]
}, "1" ],
[ "Thread/get", {
"accountId": "ue150411c",
"#ids": {
"resultOf": "1",
"name": "Email/get",
"path": "/list/*/threadId"
}
}, "2" ],
[ "Email/get", {
"accountId": "ue150411c",
"#ids": {
"resultOf": "2",
"name": "Thread/get",
"path": "/list/*/emailIds"
},
"properties": [
"threadId",
"mailboxIds",
"keywords",
"hasAttachment",
"from",
"subject",
"receivedAt",
"size",
"preview"
]
}, "3" ]]
"position": 0,
"limit": 30,
"calculateTotal": true
}, "0" ],
[ "Email/get", {
"accountId": "ue150411c",
"#ids": {
"resultOf": "0",
"name": "Email/query",
"path": "/ids"
},
"properties": [
"threadId"
]
}, "1" ],
[ "Thread/get", {
"accountId": "ue150411c",
"#ids": {
"resultOf": "1",
"name": "Email/get",
"path": "/list/*/threadId"
}
}, "2" ],
[ "Email/get", {
"accountId": "ue150411c",
"#ids": {
"resultOf": "2",
"name": "Thread/get",
"path": "/list/*/emailIds"
},
"properties": [
"threadId",
"mailboxIds",
"keywords",
"hasAttachment",
"from",
"subject",
"receivedAt",
"size",
"preview"
]
}, "3" ]]
Let's break down the 4 method calls to see what they're doing:
让我们分解4个方法调用，看看它们在做什么：
"0": This asks the server for the ids of the first 30 Email objects in the inbox, sorted newest first, ignoring Emails from the same Thread as a newer Email in the Mailbox (i.e., it is the first 30 unique Threads).
“0”：这会要求服务器提供收件箱中前30个电子邮件对象的ID，首先排序为最新，忽略来自与邮箱中较新电子邮件相同线程的电子邮件（即，它是前30个唯一线程）。
"1": Now we use a back-reference to fetch the Thread ids for each of these Email ids.
“1”：现在我们使用back引用获取每个电子邮件ID的线程ID。
"2": Another back-reference fetches the Thread object for each of these Thread ids.
“2”：另一个反向引用获取每个线程ID的线程对象。
"3": Finally, we fetch the information we need to display the Mailbox listing (but no more!) for every Email in each of these 30 Threads. The client may aggregate this data for display, for example, by showing the Thread as "flagged" if any of the Emails in it has the "$flagged" keyword.
“3”：最后，我们为这30个线程中的每封电子邮件获取显示邮箱列表所需的信息。例如，如果其中的任何电子邮件具有“$flagged”关键字，则客户端可以通过将线程显示为“已标记”来聚合该数据以供显示。
The response from the server may look something like this:
来自服务器的响应可能如下所示：
[[ "Email/query", {
"accountId": "ue150411c",
"queryState": "09aa9a075588-780599:0",
"canCalculateChanges": true,
"position": 0,
"total": 115,
"ids": [ "Ma783e5cdf5f2deffbc97930a",
"M9bd17497e2a99cb345fc1d0a", ... ]
}, "0" ],
[ "Email/get", {
"accountId": "ue150411c",
"state": "780599",
"list": [{
"id": "Ma783e5cdf5f2deffbc97930a",
"threadId": "T36703c2cfe9bd5ed"
}, {
"id": "M9bd17497e2a99cb345fc1d0a",
"threadId": "T0a22ad76e9c097a1"
}, ... ],
"notFound": []
}, "1" ],
[ "Thread/get", {
"accountId": "ue150411c",
"state": "22a8728b",
"list": [{
"id": "T36703c2cfe9bd5ed",
"emailIds": [ "Ma783e5cdf5f2deffbc97930a" ]
[[ "Email/query", {
"accountId": "ue150411c",
"queryState": "09aa9a075588-780599:0",
"canCalculateChanges": true,
"position": 0,
"total": 115,
"ids": [ "Ma783e5cdf5f2deffbc97930a",
"M9bd17497e2a99cb345fc1d0a", ... ]
}, "0" ],
[ "Email/get", {
"accountId": "ue150411c",
"state": "780599",
"list": [{
"id": "Ma783e5cdf5f2deffbc97930a",
"threadId": "T36703c2cfe9bd5ed"
}, {
"id": "M9bd17497e2a99cb345fc1d0a",
"threadId": "T0a22ad76e9c097a1"
}, ... ],
"notFound": []
}, "1" ],
[ "Thread/get", {
"accountId": "ue150411c",
"state": "22a8728b",
"list": [{
"id": "T36703c2cfe9bd5ed",
"emailIds": [ "Ma783e5cdf5f2deffbc97930a" ]
}, {
"id": "T0a22ad76e9c097a1",
"emailIds": [ "M3b568670a63e5d100f518fa5",
"M9bd17497e2a99cb345fc1d0a" ]
}, ... ],
"notFound": []
}, "2" ],
[ "Email/get", {
"accountId": "ue150411c",
"state": "780599",
"list": [{
"id": "Ma783e5cdf5f2deffbc97930a",
"threadId": "T36703c2cfe9bd5ed",
"mailboxIds": {
"fb666a55": true
},
"keywords": {
"$seen": true,
"$flagged": true
},
"hasAttachment": true,
"from": [{
"email": "jdoe@example.com",
"name": "Jane Doe"
}],
"subject": "The Big Reveal",
"receivedAt": "2018-06-27T00:20:35Z",
"size": 175047,
"preview": "As you may be aware, we are required to prepare a
presentation where we wow a panel of 5 random members of the
public, on or before 30 June each year. We have drafted..."
},
...
],
"notFound": []
}, "3" ]]
}, {
"id": "T0a22ad76e9c097a1",
"emailIds": [ "M3b568670a63e5d100f518fa5",
"M9bd17497e2a99cb345fc1d0a" ]
}, ... ],
"notFound": []
}, "2" ],
[ "Email/get", {
"accountId": "ue150411c",
"state": "780599",
"list": [{
"id": "Ma783e5cdf5f2deffbc97930a",
"threadId": "T36703c2cfe9bd5ed",
"mailboxIds": {
"fb666a55": true
},
"keywords": {
"$seen": true,
"$flagged": true
},
"hasAttachment": true,
"from": [{
"email": "jdoe@example.com",
"name": "Jane Doe"
}],
"subject": "The Big Reveal",
"receivedAt": "2018-06-27T00:20:35Z",
"size": 175047,
"preview": "As you may be aware, we are required to prepare a
presentation where we wow a panel of 5 random members of the
public, on or before 30 June each year. We have drafted..."
},
...
],
"notFound": []
}, "3" ]]
Now, on another device, the user marks the first Email as unread, sending this API request:
现在，在另一台设备上，用户将第一封电子邮件标记为未读，并发送此API请求：
[[ "Email/set", {
"accountId": "ue150411c",
"update": {
"Ma783e5cdf5f2deffbc97930a": {
"keywords/$seen": null
}
}
}, "0" ]]
[[ "Email/set", {
"accountId": "ue150411c",
"update": {
"Ma783e5cdf5f2deffbc97930a": {
"keywords/$seen": null
}
}
}, "0" ]]
The server applies this and sends the success response:
服务器应用此选项并发送成功响应：
[[ "Email/set", {
"accountId": "ue150411c",
"oldState": "780605",
"newState": "780606",
"updated": {
"Ma783e5cdf5f2deffbc97930a": null
},
...
}, "0" ]]
[[ "Email/set", {
"accountId": "ue150411c",
"oldState": "780605",
"newState": "780606",
"updated": {
"Ma783e5cdf5f2deffbc97930a": null
},
...
}, "0" ]]
The user also deletes a few Emails, and then a new message arrives.
用户还删除了一些电子邮件，然后一条新消息到达。
Back on our original machine, we receive a push update that the state string for Email is now "780800". As this does not match the client's current state, it issues a request for the changes:
回到我们原来的机器上，我们收到一个推送更新，电子邮件的状态字符串现在是“780800”。由于这与客户端的当前状态不匹配，因此会发出更改请求：
[[ "Email/changes", {
"accountId": "ue150411c",
"sinceState": "780605",
"maxChanges": 50
}, "3" ],
[ "Email/queryChanges", {
"accountId": "ue150411c",
"filter": {
"inMailbox": "fb666a55"
},
"sort": [{
"property": "receivedAt",
"isAscending": false
}],
"collapseThreads": true,
"sinceQueryState": "09aa9a075588-780599:0",
"upToId": "Mc2781d5e856a908d8a35a564",
"maxChanges": 25,
"calculateTotal": true
}, "11" ]]
[[ "Email/changes", {
"accountId": "ue150411c",
"sinceState": "780605",
"maxChanges": 50
}, "3" ],
[ "Email/queryChanges", {
"accountId": "ue150411c",
"filter": {
"inMailbox": "fb666a55"
},
"sort": [{
"property": "receivedAt",
"isAscending": false
}],
"collapseThreads": true,
"sinceQueryState": "09aa9a075588-780599:0",
"upToId": "Mc2781d5e856a908d8a35a564",
"maxChanges": 25,
"calculateTotal": true
}, "11" ]]
The response:
答复如下：
[[ "Email/changes", {
"accountId": "ue150411c",
"oldState": "780605",
"newState": "780800",
"hasMoreChanges": false,
"created": [ "Me8de6c9f6de198239b982ea2" ],
"updated": [ "Ma783e5cdf5f2deffbc97930a" ],
"destroyed": [ "M9bd17497e2a99cb345fc1d0a", ... ]
}, "3" ],
[ "Email/queryChanges", {
"accountId": "ue150411c",
"oldQueryState": "09aa9a075588-780599:0",
"newQueryState": "e35e9facf117-780615:0",
"added": [{
"id": "Me8de6c9f6de198239b982ea2",
"index": 0
}],
"removed": [ "M9bd17497e2a99cb345fc1d0a" ],
"total": 115
}, "11" ]]
[[ "Email/changes", {
"accountId": "ue150411c",
"oldState": "780605",
"newState": "780800",
"hasMoreChanges": false,
"created": [ "Me8de6c9f6de198239b982ea2" ],
"updated": [ "Ma783e5cdf5f2deffbc97930a" ],
"destroyed": [ "M9bd17497e2a99cb345fc1d0a", ... ]
}, "3" ],
[ "Email/queryChanges", {
"accountId": "ue150411c",
"oldQueryState": "09aa9a075588-780599:0",
"newQueryState": "e35e9facf117-780615:0",
"added": [{
"id": "Me8de6c9f6de198239b982ea2",
"index": 0
}],
"removed": [ "M9bd17497e2a99cb345fc1d0a" ],
"total": 115
}, "11" ]]
The client can update its local cache of the query results by removing "M9bd17497e2a99cb345fc1d0a" and then splicing in "Me8de6c9f6de198239b982ea2" at position 0. As it does not have the data for this new Email, it will then fetch it (it also could have done this in the same request using back-references).
客户端可以通过删除“M9bd17497e2a99cb345fc1d0a”，然后在位置0处拼接“Me8de6c9f6de198239b982ea2”，来更新查询结果的本地缓存。由于它没有这封新电子邮件的数据，因此它将获取它（它也可以使用反向引用在同一请求中完成此操作）。
It knows something has changed about "Ma783e5cdf5f2deffbc97930a", so it will refetch the Mailbox ids and keywords (the only mutable properties) for this Email too.
它知道“Ma783e5cdf5f2deffbc97930a”发生了一些变化，因此它也将重新蚀刻此电子邮件的邮箱ID和关键字（唯一可变属性）。
The user starts composing a new Email. The email is plaintext and the client knows the email in English so adds this metadata to the body part. The user saves a draft while the composition is still in progress. The client sends:
用户开始撰写新电子邮件。电子邮件是纯文本的，客户知道电子邮件是英文的，因此将此元数据添加到正文部分。用户在撰写过程中保存草稿。客户端发送：
[[ "Email/set", {
"accountId": "ue150411c",
"create": {
"k192": {
"mailboxIds": {
"2ea1ca41b38e": true
},
"keywords": {
"$seen": true,
"$draft": true
},
"from": [{
"name": "Joe Bloggs",
"email": "joe@example.com"
}],
"subject": "World domination",
"receivedAt": "2018-07-10T01:03:11Z",
"sentAt": "2018-07-10T11:03:11+10:00",
"bodyStructure": {
"type": "text/plain",
"partId": "bd48",
"header:Content-Language": "en"
},
"bodyValues": {
"bd48": {
"value": "I have the most brilliant plan. Let me tell
you all about it. What we do is, we",
"isTruncated": false
}
}
}
}
}, "0" ]]
[[ "Email/set", {
"accountId": "ue150411c",
"create": {
"k192": {
"mailboxIds": {
"2ea1ca41b38e": true
},
"keywords": {
"$seen": true,
"$draft": true
},
"from": [{
"name": "Joe Bloggs",
"email": "joe@example.com"
}],
"subject": "World domination",
"receivedAt": "2018-07-10T01:03:11Z",
"sentAt": "2018-07-10T11:03:11+10:00",
"bodyStructure": {
"type": "text/plain",
"partId": "bd48",
"header:Content-Language": "en"
},
"bodyValues": {
"bd48": {
"value": "I have the most brilliant plan. Let me tell
you all about it. What we do is, we",
"isTruncated": false
}
}
}
}
}, "0" ]]
The server creates the message and sends the success response:
服务器创建消息并发送成功响应：
[[ "Email/set", {
"accountId": "ue150411c",
"oldState": "780823",
"newState": "780839",
"created": {
"k192": {
"id": "Mf40b5f831efa7233b9eb1c7f",
"blobId": "Gf40b5f831efa7233b9eb1c7f8f97d84eeeee64f7",
"threadId": "Td957e72e89f516dc",
"size": 359
}
},
...
}, "0" ]]
[[ "Email/set", {
"accountId": "ue150411c",
"oldState": "780823",
"newState": "780839",
"created": {
"k192": {
"id": "Mf40b5f831efa7233b9eb1c7f",
"blobId": "Gf40b5f831efa7233b9eb1c7f8f97d84eeeee64f7",
"threadId": "Td957e72e89f516dc",
"size": 359
}
},
...
}, "0" ]]
The message created on the server looks something like this:
在服务器上创建的消息如下所示：
Message-Id: <bbce0ae9-58be-4b24-ac82-deb840d58016@sloti7d1t02>
User-Agent: Cyrus-JMAP/3.1.6-736-gdfb8e44
Mime-Version: 1.0
Date: Tue, 10 Jul 2018 11:03:11 +1000
From: "Joe Bloggs" <joe@example.com>
Subject: World domination
Content-Language: en
Content-Type: text/plain
Message-Id: <bbce0ae9-58be-4b24-ac82-deb840d58016@sloti7d1t02>
User-Agent: Cyrus-JMAP/3.1.6-736-gdfb8e44
Mime-Version: 1.0
Date: Tue, 10 Jul 2018 11:03:11 +1000
From: "Joe Bloggs" <joe@example.com>
Subject: World domination
Content-Language: en
Content-Type: text/plain
I have the most brilliant plan. Let me tell you all about it. What we do is, we
我有一个最聪明的计划。让我告诉你一切。我们所做的是
The user adds a recipient and converts the message to HTML so they can add formatting, then saves an updated draft:
用户添加收件人并将邮件转换为HTML，以便添加格式，然后保存更新的草稿：
[[ "Email/set", {
"accountId": "ue150411c",
"create": {
"k1546": {
"mailboxIds": {
"2ea1ca41b38e": true
},
"keywords": {
"$seen": true,
"$draft": true
},
"from": [{
"name": "Joe Bloggs",
"email": "joe@example.com"
[[ "Email/set", {
"accountId": "ue150411c",
"create": {
"k1546": {
"mailboxIds": {
"2ea1ca41b38e": true
},
"keywords": {
"$seen": true,
"$draft": true
},
"from": [{
"name": "Joe Bloggs",
"email": "joe@example.com"
}],
"to": [{
"name": "John",
"email": "john@example.com"
}],
"subject": "World domination",
"receivedAt": "2018-07-10T01:05:08Z",
"sentAt": "2018-07-10T11:05:08+10:00",
"bodyStructure": {
"type": "multipart/alternative",
"subParts": [{
"partId": "a49d",
"type": "text/html",
"header:Content-Language": "en"
}, {
"partId": "bd48",
"type": "text/plain",
"header:Content-Language": "en"
}]
},
"bodyValues": {
"bd48": {
"value": "I have the most brilliant plan. Let me tell
you all about it. What we do is, we",
"isTruncated": false
},
"a49d": {
"value": "<!DOCTYPE html><html><head><title></title>
<style type=\"text/css\">div{font-size:16px}</style></head>
<body><div>I have the most <b>brilliant</b> plan. Let me
tell you all about it. What we do is, we</div></body>
</html>",
"isTruncated": false
}
}
}
},
"destroy": [ "Mf40b5f831efa7233b9eb1c7f" ]
}, "0" ]]
}],
"to": [{
"name": "John",
"email": "john@example.com"
}],
"subject": "World domination",
"receivedAt": "2018-07-10T01:05:08Z",
"sentAt": "2018-07-10T11:05:08+10:00",
"bodyStructure": {
"type": "multipart/alternative",
"subParts": [{
"partId": "a49d",
"type": "text/html",
"header:Content-Language": "en"
}, {
"partId": "bd48",
"type": "text/plain",
"header:Content-Language": "en"
}]
},
"bodyValues": {
"bd48": {
"value": "I have the most brilliant plan. Let me tell
you all about it. What we do is, we",
"isTruncated": false
},
"a49d": {
"value": "<!DOCTYPE html><html><head><title></title>
<style type=\"text/css\">div{font-size:16px}</style></head>
<body><div>I have the most <b>brilliant</b> plan. Let me
tell you all about it. What we do is, we</div></body>
</html>",
"isTruncated": false
}
}
}
},
"destroy": [ "Mf40b5f831efa7233b9eb1c7f" ]
}, "0" ]]
The server creates the new draft, deletes the old one, and sends the success response:
服务器创建新草稿，删除旧草稿，并发送成功响应：
[[ "Email/set", {
"accountId": "ue150411c",
"oldState": "780839",
"newState": "780842",
"created": {
"k1546": {
"id": "Md45b47b4877521042cec0938",
"blobId": "Ge8de6c9f6de198239b982ea214e0f3a704e4af74",
"threadId": "Td957e72e89f516dc",
"size": 11721
}
},
"destroyed": [ "Mf40b5f831efa7233b9eb1c7f" ],
...
}, "0" ]]
[[ "Email/set", {
"accountId": "ue150411c",
"oldState": "780839",
"newState": "780842",
"created": {
"k1546": {
"id": "Md45b47b4877521042cec0938",
"blobId": "Ge8de6c9f6de198239b982ea214e0f3a704e4af74",
"threadId": "Td957e72e89f516dc",
"size": 11721
}
},
"destroyed": [ "Mf40b5f831efa7233b9eb1c7f" ],
...
}, "0" ]]
The client moves this draft to a different account. The only way to do this is via the "Email/copy" method. It MUST set a new "mailboxIds" property, since the current value will not be valid Mailbox ids in the destination account:
客户将此汇票移至其他帐户。做到这一点的唯一方法是通过“电子邮件/副本”方法。它必须设置新的“MailboxID”属性，因为当前值将不是目标帐户中的有效邮箱ID：
[[ "Email/copy", {
"fromAccountId": "ue150411c",
"accountId": "u6c6c41ac",
"create": {
"k45": {
"id": "Md45b47b4877521042cec0938",
"mailboxIds": {
"75a4c956": true
}
}
},
"onSuccessDestroyOriginal": true
}, "0" ]]
[[ "Email/copy", {
"fromAccountId": "ue150411c",
"accountId": "u6c6c41ac",
"create": {
"k45": {
"id": "Md45b47b4877521042cec0938",
"mailboxIds": {
"75a4c956": true
}
}
},
"onSuccessDestroyOriginal": true
}, "0" ]]
The server successfully copies the Email and deletes the original. Due to the implicit call to "Email/set", there are two responses to the single method call, both with the same method call id:
服务器成功复制电子邮件并删除原始邮件。由于对“Email/set”的隐式调用，对单个方法调用有两个响应，都具有相同的方法调用id：
[[ "Email/copy", {
"fromAccountId": "ue150411c",
"accountId": "u6c6c41ac",
"oldState": "7ee7e9263a6d",
"newState": "5a0d2447ed26",
"created": {
"k45": {
"id": "M138f9954a5cd2423daeafa55",
"blobId": "G6b9fb047cba722c48c611e79233d057c6b0b74e8",
"threadId": "T2f242ea424a4079a",
"size": 11721
}
},
"notCreated": null
}, "0" ],
[ "Email/set", {
"accountId": "ue150411c",
"oldState": "780842",
"newState": "780871",
"destroyed": [ "Md45b47b4877521042cec0938" ],
...
}, "0" ]]
[[ "Email/copy", {
"fromAccountId": "ue150411c",
"accountId": "u6c6c41ac",
"oldState": "7ee7e9263a6d",
"newState": "5a0d2447ed26",
"created": {
"k45": {
"id": "M138f9954a5cd2423daeafa55",
"blobId": "G6b9fb047cba722c48c611e79233d057c6b0b74e8",
"threadId": "T2f242ea424a4079a",
"size": 11721
}
},
"notCreated": null
}, "0" ],
[ "Email/set", {
"accountId": "ue150411c",
"oldState": "780842",
"newState": "780871",
"destroyed": [ "Md45b47b4877521042cec0938" ],
...
}, "0" ]]
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 preview and to highlight any matching terms in both this and the subject of the Email. Search snippets represent this data.
在搜索“字符串”属性时，客户可能希望显示正文中与搜索匹配的相关部分作为预览，并突出显示此内容和电子邮件主题中的任何匹配项。搜索片段表示此数据。
A *SearchSnippet* object has the following properties:
*SearchSnippet*对象具有以下属性：
o emailId: "Id"
o emailId:“Id”
The Email id the snippet applies to.
代码段应用于的电子邮件id。
o subject: "String|null"
o 主题：“字符串|空”
If text from the filter matches the subject, this is the subject of the Email with the following transformations:
如果筛选器中的文本与主题匹配，则这是电子邮件的主题，并进行以下转换：
1. Any instance of the following three characters MUST be replaced by an appropriate HTML entity: & (ampersand), < (less-than sign), and > (greater-than sign) [HTML]. Other characters MAY also be replaced with an HTML entity form.
1. 以下三个字符的任何实例都必须替换为适当的HTML实体：&（与号）、<（小于号）和>（大于号）[HTML]。其他字符也可以替换为HTML实体表单。
2. The matching words/phrases from the filter are wrapped in HTML "<mark></mark>" tags.
2. 过滤器中匹配的单词/短语包装在HTML“<mark></mark>”标记中。
If the subject does not match text from the filter, this property is null.
如果主题与筛选器中的文本不匹配，则此属性为null。
o preview: "String|null"
o 预览：“字符串|空”
If text from the filter matches the plaintext or HTML body, this is the relevant section of the body (converted to plaintext if originally HTML), with the same transformations as the "subject" property. It MUST NOT be bigger than 255 octets in size. If the body does not contain a match for the text from the filter, this property is null.
如果筛选器中的文本与纯文本或HTML正文匹配，则这是正文的相关部分（如果最初是HTML，则转换为纯文本），其转换与“subject”属性相同。它的大小不得超过255个八位字节。如果正文不包含与筛选器中的文本匹配的内容，则此属性为null。
What is a relevant section of the body for preview is server defined. If the server is unable to determine search snippets, it MUST return null for both the "subject" and "preview" properties.
用于预览的正文的相关部分由服务器定义。如果服务器无法确定搜索片段，则必须为“主题”和“预览”属性返回null。
Note that unlike most data types, a SearchSnippet DOES NOT have a property called "id".
请注意，与大多数数据类型不同，SearchSnippet没有名为“id”的属性。
The following JMAP method is supported.
支持以下JMAP方法。
To fetch search snippets, make a call to "SearchSnippet/get". It takes the following arguments:
要获取搜索片段，请调用“SearchSnippet/get”。它采用以下参数：
o accountId: "Id"
o 帐户Id:“Id”
The id of the account to use.
要使用的帐户的id。
o filter: "FilterOperator|FilterCondition|null"
o 筛选器：“FilterOperator | FilterCondition | null”
The same filter as passed to "Email/query"; see the description of this method in Section 4.4 for details.
传递给“电子邮件/查询”的过滤器相同；有关详细信息，请参见第4.4节中对该方法的描述。
o emailIds: "Id[]"
o EmailID:“Id[]”
The ids of the Emails to fetch snippets for.
要获取代码片段的电子邮件的ID。
The response has the following arguments:
响应具有以下参数：
o accountId: "Id"
o 帐户Id:“Id”
The id of the account used for the call.
用于呼叫的帐户的id。
o list: "SearchSnippet[]"
o 列表：“SearchSnippet[]”
An array of SearchSnippet objects for the requested Email ids. This may not be in the same order as the ids that were in the request.
请求的电子邮件ID的SearchSnippet对象数组。这可能与请求中的ID顺序不同。
o notFound: "Id[]|null"
o 未找到：“Id[]|空”
An array of Email ids requested that could not be found, or null if all ids were found.
无法找到请求的电子邮件ID数组，如果找到所有ID，则为null。
As the search snippets are derived from the message content and the algorithm for doing so could change over time, fetching the same snippets a second time MAY return a different result. However, the previous value is not considered incorrect, so there is no state string or update mechanism needed.
由于搜索片段是从消息内容中派生出来的，并且这样做的算法可能会随着时间的推移而改变，因此第二次获取相同的片段可能会返回不同的结果。但是，前面的值并不被认为是不正确的，因此不需要状态字符串或更新机制。
The following additional errors may be returned instead of the "SearchSnippet/get" response:
可能会返回以下附加错误，而不是“SearchSnippet/get”响应：
"requestTooLarge": The number of "emailIds" requested by the client exceeds the maximum number the server is willing to process in a single method call.
“requestTooLarge”：客户端请求的“EmailID”数量超过了服务器在单个方法调用中愿意处理的最大数量。
"unsupportedFilter": The server is unable to process the given "filter" for any reason.
“unsupportedFilter”：服务器由于任何原因无法处理给定的“筛选器”。
Here, we did an "Email/query" to search for any Email in the account containing the word "foo"; now, we are fetching the search snippets for some of the ids that were returned in the results:
在这里，我们做了一个“电子邮件/查询”来搜索帐户中包含“foo”一词的任何电子邮件；现在，我们正在获取搜索结果中返回的某些ID的搜索片段：
[[ "SearchSnippet/get", {
"accountId": "ue150411c",
"filter": {
"text": "foo"
},
"emailIds": [
"M44200ec123de277c0c1ce69c",
"M7bcbcb0b58d7729686e83d99",
"M28d12783a0969584b6deaac0",
...
]
}, "0" ]]
[[ "SearchSnippet/get", {
"accountId": "ue150411c",
"filter": {
"text": "foo"
},
"emailIds": [
"M44200ec123de277c0c1ce69c",
"M7bcbcb0b58d7729686e83d99",
"M28d12783a0969584b6deaac0",
...
]
}, "0" ]]
Example response:
答复示例：
[[ "SearchSnippet/get", {
"accountId": "ue150411c",
"list": [{
"emailId": "M44200ec123de277c0c1ce69c",
"subject": null,
"preview": null
}, {
"emailId": "M7bcbcb0b58d7729686e83d99",
"subject": "The <mark>Foo</mark>sball competition",
"preview": "...year the <mark>foo</mark>sball competition will
be held in the Stadium de ..."
}, {
"emailId": "M28d12783a0969584b6deaac0",
"subject": null,
"preview": "...the <mark>Foo</mark>/bar method results often
returns <1 widget rather than the complete..."
},
...
],
"notFound": null
}, "0" ]]
[[ "SearchSnippet/get", {
"accountId": "ue150411c",
"list": [{
"emailId": "M44200ec123de277c0c1ce69c",
"subject": null,
"preview": null
}, {
"emailId": "M7bcbcb0b58d7729686e83d99",
"subject": "The <mark>Foo</mark>sball competition",
"preview": "...year the <mark>foo</mark>sball competition will
be held in the Stadium de ..."
}, {
"emailId": "M28d12783a0969584b6deaac0",
"subject": null,
"preview": "...the <mark>Foo</mark>/bar method results often
returns <1 widget rather than the complete..."
},
...
],
"notFound": null
}, "0" ]]
An *Identity* object stores information about an email address or domain the user may send from. It has the following properties:
*Identity*对象存储有关用户可以发送的电子邮件地址或域的信息。它具有以下属性：
o id: "Id" (immutable; server-set)
o id：“id”（不可变；服务器集）
The id of the Identity.
标识的id。
o name: "String" (default: "")
o 名称：“字符串”（默认值：“”）
The "From" name the client SHOULD use when creating a new Email from this Identity.
客户端使用此身份创建新电子邮件时应使用的“发件人”名称。
o email: "String" (immutable)
o 电子邮件：“字符串”（不可变）
The "From" email address the client MUST use when creating a new Email from this Identity. If the "mailbox" part of the address (the section before the "@") is the single character "*" (e.g., "*@example.com"), the client may use any valid address ending in that domain (e.g., "foo@example.com").
使用此身份创建新电子邮件时，客户端必须使用的“发件人”电子邮件地址。如果地址的“邮箱”部分（在“@”之前的部分）是单个字符“*”（例如“*@example.com”），则客户端可以使用以该域结尾的任何有效地址（例如“*@example.com”）foo@example.com").
o replyTo: "EmailAddress[]|null" (default: null)
o 回复至：“电子邮件地址[]|空”（默认值：空）
The Reply-To value the client SHOULD set when creating a new Email from this Identity.
使用此标识创建新电子邮件时客户端应设置的回复值。
o bcc: "EmailAddress[]|null" (default: null)
o 密件抄送：“电子邮件地址[]|空”（默认值：空）
The Bcc value the client SHOULD set when creating a new Email from this Identity.
使用此标识创建新电子邮件时客户端应设置的密件抄送值。
o textSignature: "String" (default: "")
o textSignature:“字符串”（默认值：）
A signature the client SHOULD insert into new plaintext messages that will be sent from this Identity. Clients MAY ignore this and/or combine this with a client-specific signature preference.
客户端应将签名插入将从此身份发送的新明文消息中。客户可能会忽略这一点和/或将其与客户特定的签名首选项相结合。
o htmlSignature: "String" (default: "")
o htmlSignature:“字符串”（默认值：）
A signature the client SHOULD insert into new HTML messages that will be sent from this Identity. This text MUST be an HTML snippet to be inserted into the "<body></body>" section of the HTML. Clients MAY ignore this and/or combine this with a client-specific signature preference.
客户端应将签名插入将从此身份发送的新HTML消息中。此文本必须是要插入HTML的“<body></body>”部分的HTML片段。客户可能会忽略这一点和/或将其与客户特定的签名首选项相结合。
o mayDelete: "Boolean" (server-set)
o 可能删除：“布尔”（服务器集）
Is the user allowed to delete this Identity? Servers may wish to set this to false for the user's username or other default address. Attempts to destroy an Identity with "mayDelete: false" will be rejected with a standard "forbidden" SetError.
是否允许用户删除此标识？服务器可能希望将用户的用户名或其他默认地址设置为false。使用“mayDelete:false”销毁标识的尝试将被标准的“禁止”设置错误拒绝。
See the "Addresses" header form description in the Email object (Section 4.1.2.3) for the definition of EmailAddress.
有关电子邮件地址的定义，请参见电子邮件对象（第4.1.2.3节）中的“地址”标题表单说明。
Multiple identities with the same email address MAY exist, to allow for different settings the user wants to pick between (for example, with different names/signatures).
可能存在具有相同电子邮件地址的多个身份，以允许用户选择不同的设置（例如，使用不同的名称/签名）。
The following JMAP methods are supported.
支持以下JMAP方法。
This is a standard "/get" method as described in [RFC8620], Section 5.1. The "ids" argument may be null to fetch all at once.
这是[RFC8620]第5.1节所述的标准“/get”方法。“ids”参数可以为null，以便一次获取所有内容。
This is a standard "/changes" method as described in [RFC8620], Section 5.2.
这是[RFC8620]第5.2节所述的标准“/变更”方法。
This is a standard "/set" method as described in [RFC8620], Section 5.3. The following extra SetError types are defined:
这是[RFC8620]第5.3节所述的标准“/set”方法。定义了以下额外的SetError类型：
For "create":
对于“创建”：
o "forbiddenFrom": The user is not allowed to send from the address given as the "email" property of the Identity.
o “禁止发件人”：不允许用户从作为身份的“电子邮件”属性指定的地址发送。
Request:
请求：
[ "Identity/get", {
"accountId": "acme"
}, "0" ]
[ "Identity/get", {
"accountId": "acme"
}, "0" ]
with response:
答复如下：
[ "Identity/get", {
"accountId": "acme",
"state": "99401312ae-11-333",
"list": [
{
"id": "XD-3301-222-11_22AAz",
"name": "Joe Bloggs",
"email": "joe@example.com",
"replyTo": null,
"bcc": [{
"name": null,
"email": "joe+archive@example.com"
}],
"textSignature": "-- \nJoe Bloggs\nMaster of Email",
"htmlSignature": "<div><b>Joe Bloggs</b></div>
<div>Master of Email</div>",
"mayDelete": false
},
{
"id": "XD-9911312-11_22AAz",
"name": "Joe B",
"email": "*@example.com",
"replyTo": null,
"bcc": null,
"textSignature": "",
"htmlSignature": "",
"mayDelete": true
}
],
"notFound": []
}, "0" ]
[ "Identity/get", {
"accountId": "acme",
"state": "99401312ae-11-333",
"list": [
{
"id": "XD-3301-222-11_22AAz",
"name": "Joe Bloggs",
"email": "joe@example.com",
"replyTo": null,
"bcc": [{
"name": null,
"email": "joe+archive@example.com"
}],
"textSignature": "-- \nJoe Bloggs\nMaster of Email",
"htmlSignature": "<div><b>Joe Bloggs</b></div>
<div>Master of Email</div>",
"mayDelete": false
},
{
"id": "XD-9911312-11_22AAz",
"name": "Joe B",
"email": "*@example.com",
"replyTo": null,
"bcc": null,
"textSignature": "",
"htmlSignature": "",
"mayDelete": true
}
],
"notFound": []
}, "0" ]
An *EmailSubmission* object represents the submission of an Email for delivery to one or more recipients. It has the following properties:
*EmailSubmission*对象表示将电子邮件提交给一个或多个收件人。它具有以下属性：
o id: "Id" (immutable; server-set)
o id：“id”（不可变；服务器集）
The id of the EmailSubmission.
电子邮件提交的id。
o identityId: "Id" (immutable)
o 标识Id：“Id”（不可变）
The id of the Identity to associate with this submission.
要与此提交关联的标识的id。
o emailId: "Id" (immutable)
o emailId:“Id”（不可变）
The id of the Email to send. The Email being sent does not have to be a draft, for example, when "redirecting" an existing Email to a different address.
要发送的电子邮件的id。发送的电子邮件不必是草稿，例如，将现有电子邮件“重定向”到其他地址时。
o threadId: "Id" (immutable; server-set)
o threadId:“Id”（不可变；服务器集）
The Thread id of the Email to send. This is set by the server to the "threadId" property of the Email referenced by the "emailId".
要发送的电子邮件的线程id。这由服务器设置为“emailId”引用的电子邮件的“threadId”属性。
o envelope: "Envelope|null" (immutable)
o 信封：“信封|空”（不可变）
Information for use when sending via SMTP. An *Envelope* object has the following properties:
通过SMTP发送时使用的信息。*Envelope*对象具有以下属性：
* mailFrom: "Address"
* 邮寄地址：“地址”
The email address to use as the return address in the SMTP submission, plus any parameters to pass with the MAIL FROM address. The JMAP server MAY allow the address to be the empty string.
要用作SMTP提交中的返回地址的电子邮件地址，以及要与邮件发件人地址一起传递的任何参数。JMAP服务器可能允许地址为空字符串。
When a JMAP server performs an SMTP message submission, it MAY use the same id string for the ENVID parameter [RFC3461] and the EmailSubmission object id. Servers that do this MAY replace a client-provided value for ENVID with a server-provided value.
当JMAP服务器执行SMTP邮件提交时，它可能会对ENVID参数[RFC3461]和EmailSubmission对象id使用相同的id字符串。执行此操作的服务器可能会将客户端为ENVID提供的值替换为服务器提供的值。
* rcptTo: "Address[]"
* rcptTo:“地址[]”
The email addresses to send the message to, and any RCPT TO parameters to pass with the recipient.
要发送消息的电子邮件地址，以及要与收件人传递的任何RCPT to参数。
An *Address* object has the following properties:
*Address*对象具有以下属性：
* email: "String"
* 电子邮件：“字符串”
The email address being represented by the object. This is a "Mailbox" as used in the Reverse-path or Forward-path of the MAIL FROM or RCPT TO command in [RFC5321].
由对象表示的电子邮件地址。这是一个“邮箱”，用于[RFC5321]中“邮件发件人”或“RCPT收件人”命令的反向路径或正向路径。
* parameters: "Object|null"
* 参数：“对象|空”
Any parameters to send with the email address (either mail-parameter or rcpt-parameter as appropriate, as specified in [RFC5321]). If supplied, each key in the object is a parameter name, and the value is either the parameter value (type
与电子邮件地址一起发送的任何参数（根据[RFC5321]中的规定，邮件参数或rcpt参数，视情况而定）。如果提供，对象中的每个键都是一个参数名，该值为参数值（类型
"String") or null if the parameter does not take a value. For both name and value, any xtext or unitext encodings are removed (see [RFC3461] and [RFC6533]) and JSON string encoding is applied.
“String”）或null（如果参数没有取值）。对于名称和值，将删除任何xtext或unitext编码（请参见[RFC3461]和[RFC6533]），并应用JSON字符串编码。
If the "envelope" property is null or omitted on creation, the server MUST generate this from the referenced Email as follows:
如果“信封”属性在创建时为null或省略，则服务器必须根据引用的电子邮件生成该属性，如下所示：
* "mailFrom": The email address in the Sender header field, if present; otherwise, it's the email address in the From header field, if present. In either case, no parameters are added.
* “mailFrom”：发件人标题字段中的电子邮件地址（如果存在）；否则，它是发件人标题字段中的电子邮件地址（如果存在）。在这两种情况下，都不会添加任何参数。
If multiple addresses are present in one of these header fields, or there is more than one Sender/From header field, the server SHOULD reject the EmailSubmission as invalid; otherwise, it MUST take the first address in the last Sender/From header field.
如果其中一个标题字段中存在多个地址，或者有多个发件人/发件人标题字段，则服务器应拒绝电子邮件提交，认为其无效；否则，它必须采用最后一个发件人/发件人标头字段中的第一个地址。
If the address found from this is not allowed by the Identity associated with this submission, the "email" property from the Identity MUST be used instead.
如果与此提交相关联的标识不允许从中找到地址，则必须使用标识中的“电子邮件”属性。
* "rcptTo": The deduplicated set of email addresses from the To, Cc, and Bcc header fields, if present, with no parameters for any of them.
* “rcptTo”：从收件人、抄送和密件抄送标头字段（如果存在）中删除重复的电子邮件地址集，其中没有任何参数。
o sendAt: "UTCDate" (immutable; server-set)
o 发送地址：“UTCDate”（不可变；服务器集）
The date the submission was/will be released for delivery. If the client successfully used FUTURERELEASE [RFC4865] with the submission, this MUST be the time when the server will release the message; otherwise, it MUST be the time the EmailSubmission was created.
提交文件发布交付的日期。如果客户机在提交时成功使用FUTURERELEASE[RFC4865]，则这必须是服务器发布消息的时间；否则，它必须是创建电子邮件提交的时间。
o undoStatus: "String"
o 撤消状态：“字符串”
This represents whether the submission may be canceled. This is server set on create and MUST be one of the following values:
这表示是否可以取消提交。这是在创建时设置的服务器，必须是以下值之一：
* "pending": It may be possible to cancel this submission.
* “待定”：可能会取消此提交。
* "final": The message has been relayed to at least one recipient in a manner that cannot be recalled. It is no longer possible to cancel this submission.
* “最终”：消息已以无法收回的方式转发给至少一个收件人。无法再取消此提交。
* "canceled": The submission was canceled and will not be delivered to any recipient.
* “已取消”：提交内容已取消，不会发送给任何收件人。
On systems that do not support unsending, the value of this property will always be "final". On systems that do support canceling submission, it will start as "pending" and MAY transition to "final" when the server knows it definitely cannot recall the message, but it MAY just remain "pending". If in pending state, a client can attempt to cancel the submission by setting this property to "canceled"; if the update succeeds, the submission was successfully canceled, and the message has not been delivered to any of the original recipients.
在不支持取消发送的系统上，此属性的值始终为“最终”。在支持取消提交的系统上，它将以“挂起”开始，当服务器知道它肯定无法调用消息时，它可能会转换为“最终”，但它可能仍然处于“挂起”状态。如果处于挂起状态，客户端可以通过将此属性设置为“已取消”来尝试取消提交；如果更新成功，则提交已成功取消，并且邮件尚未送达任何原始收件人。
o deliveryStatus: "String[DeliveryStatus]|null" (server-set)
o deliveryStatus:“字符串[deliveryStatus]| null”（服务器集）
This represents the delivery status for each of the submission's recipients, if known. This property MAY not be supported by all servers, in which case it will remain null. Servers that support it SHOULD update the EmailSubmission object each time the status of any of the recipients changes, even if some recipients are still being retried.
这表示每个提交收件人的传递状态（如果已知）。并非所有服务器都支持此属性，在这种情况下，它将保持为null。支持它的服务器应该在每次更改任何收件人的状态时更新EmailSubmission对象，即使某些收件人仍在重试。
This value is a map from the email address of each recipient to a DeliveryStatus object.
此值是从每个收件人的电子邮件地址到DeliveryStatus对象的映射。
A *DeliveryStatus* object has the following properties:
*DeliveryStatus*对象具有以下属性：
* smtpReply: "String"
* smtpReply：“字符串”
The SMTP reply string returned for this recipient when the server last tried to relay the message, or in a later Delivery Status Notification (DSN, as defined in [RFC3464]) response for the message. This SHOULD be the response to the RCPT TO stage, unless this was accepted and the message as a whole was rejected at the end of the DATA stage, in which case the DATA stage reply SHOULD be used instead.
当服务器上次尝试中继邮件时，或在稍后的邮件传递状态通知（DSN，如[RFC3464]中定义）响应中，为此收件人返回的SMTP回复字符串。这应该是对RCPT to stage的响应，除非这被接受，并且在数据阶段结束时整个消息被拒绝，在这种情况下，应使用数据阶段回复。
Multi-line SMTP responses should be concatenated to a single string as follows:
多行SMTP响应应连接到单个字符串，如下所示：
+ The hyphen following the SMTP code on all but the last line is replaced with a space.
+ 除了最后一行之外，所有SMTP代码后面的连字符都将替换为空格。
+ Any prefix in common with the first line is stripped from lines after the first.
+ 任何与第一行相同的前缀都将从第一行之后的行中删除。
+ CRLF is replaced by a space.
+ CRLF被一个空格代替。
For example:
例如：
550-5.7.1 Our system has detected that this message is 550 5.7.1 likely spam.
550-5.7.1我们的系统检测到此邮件可能是550 5.7.1垃圾邮件。
would become:
将成为：
550 5.7.1 Our system has detected that this message is likely spam.
550 5.7.1我们的系统检测到此邮件可能是垃圾邮件。
For messages relayed via an alternative to SMTP, the server MAY generate a synthetic string representing the status instead. If it does this, the string MUST be of the following form:
对于通过SMTP替代方案中继的邮件，服务器可能会生成表示状态的合成字符串。如果执行此操作，则字符串必须为以下形式：
+ A 3-digit SMTP reply code, as defined in [RFC5321], Section 4.2.3.
+ [RFC5321]第4.2.3节中定义的3位SMTP回复代码。
+ Then a single space character.
+ 然后是单个空格字符。
+ Then an SMTP Enhanced Mail System Status Code as defined in [RFC3463], with a registry defined in [RFC5248].
+ 然后是[RFC3463]中定义的SMTP增强邮件系统状态代码，以及[RFC5248]中定义的注册表。
+ Then a single space character.
+ 然后是单个空格字符。
+ Then an implementation-specific information string with a human-readable explanation of the response.
+ 然后是一个特定于实现的信息字符串，其中包含对响应的可读解释。
* delivered: "String"
* 交付：“字符串”
Represents whether the message has been successfully delivered to the recipient. This MUST be one of the following values:
表示邮件是否已成功传递给收件人。这必须是以下值之一：
+ "queued": The message is in a local mail queue and the status will change once it exits the local mail queues. The "smtpReply" property may still change.
+ “排队”：邮件位于本地邮件队列中，一旦退出本地邮件队列，状态将更改。“smtpReply”属性仍可能更改。
+ "yes": The message was successfully delivered to the mail store of the recipient. The "smtpReply" property is final.
+ “是”：邮件已成功传递到收件人的邮件存储区。“smtpReply”属性是最终属性。
+ "no": Delivery to the recipient permanently failed. The "smtpReply" property is final.
+ “否”：向收件人的传递永久失败。“smtpReply”属性是最终属性。
+ "unknown": The final delivery status is unknown, (e.g., it was relayed to an external machine and no further information is available). The "smtpReply" property may still change if a DSN arrives.
+ “未知”：最终交付状态未知（例如，它被中继到外部机器，没有进一步的信息可用）。如果DSN到达，“smtpReply”属性仍可能更改。
Note that successful relaying to an external SMTP server SHOULD NOT be taken as an indication that the message has successfully reached the final mail store. In this case though, the server may receive a DSN response, if requested.
请注意，成功中继到外部SMTP服务器不应视为邮件已成功到达最终邮件存储。但在这种情况下，如果请求，服务器可能会收到DSN响应。
If a DSN is received for the recipient with Action equal to "delivered", as per [RFC3464], Section 2.3.3, then the "delivered" property SHOULD be set to "yes"; if the Action equals "failed", the property SHOULD be set to "no". Receipt of any other DSN SHOULD NOT affect this property.
根据[RFC3464]第2.3.3节，如果收件人收到的DSN的动作等于“已交付”，则“已交付”属性应设置为“是”；如果操作等于“失败”，则属性应设置为“否”。收到任何其他DSN不应影响此属性。
The server MAY also set this property based on other feedback channels.
服务器还可以根据其他反馈通道设置此属性。
* displayed: "String"
* 显示：“字符串”
Represents whether the message has been displayed to the recipient. This MUST be one of the following values:
表示邮件是否已显示给收件人。这必须是以下值之一：
+ "unknown": The display status is unknown. This is the initial value.
+ “未知”：显示状态未知。这是初始值。
+ "yes": The recipient's system claims the message content has been displayed to the recipient. Note that there is no guarantee that the recipient has noticed, read, or understood the content.
+ “是”：收件人的系统声称邮件内容已显示给收件人。请注意，不能保证收件人已经注意、阅读或理解了内容。
If a Message Disposition Notification (MDN) is received for this recipient with Disposition-Type (as per [RFC8098], Section 3.2.6.2) equal to "displayed", this property SHOULD be set to "yes".
如果接收到此收件人的消息处置通知（MDN），且处置类型（根据[RFC8098]，第3.2.6.2节）等于“已显示”，则此属性应设置为“是”。
The server MAY also set this property based on other feedback channels.
服务器还可以根据其他反馈通道设置此属性。
o dsnBlobIds: "Id[]" (server-set)
o dsnBlobIds:“Id[]”（服务器集）
A list of blob ids for DSNs [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.
本次提交收到的DSN[RFC3464]的blob ID列表，按接收顺序排列，最早的优先。blob是接收到的整个MIME消息（顶级内容类型为“multipart/report”）。
o mdnBlobIds: "Id[]" (server-set)
o mdnBlobIds:“Id[]”（服务器集）
A list of blob ids for MDNs [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.
本次提交收到的MDN[RFC8098]的blob ID列表，按接收顺序排列，最早的优先。blob是接收到的整个MIME消息（顶级内容类型为“multipart/report”）。
JMAP servers MAY choose not to expose DSN and MDN responses as Email objects if they correlate to an EmailSubmission object. It SHOULD only do this if it exposes them in the "dsnBlobIds" and "mdnblobIds" fields instead, and it expects the user to be using clients capable of fetching and displaying delivery status via the EmailSubmission object.
如果DSN和MDN响应与EmailSubmission对象相关，JMAP服务器可能会选择不将其作为电子邮件对象公开。只有当它在“dsnBlobIds”和“mdnblobIds”字段中公开它们时，它才应该这样做，并且它希望用户使用能够通过EmailSubmission对象获取和显示传递状态的客户端。
For efficiency, a server MAY destroy EmailSubmission objects at any time after the message is successfully sent or after it has finished retrying to send the message. For very basic SMTP proxies, this MAY be immediately after creation, as it has no way to assign a real id and return the information again if fetched later.
为了提高效率，服务器可以在成功发送邮件或完成重试发送邮件后的任何时间销毁EmailSubmission对象。对于非常基本的SMTP代理，这可能是在创建后立即执行的，因为它无法分配真实的id，如果稍后获取，则无法再次返回信息。
The following JMAP methods are supported.
支持以下JMAP方法。
This is a standard "/get" method as described in [RFC8620], Section 5.1.
这是[RFC8620]第5.1节所述的标准“/get”方法。
This is a standard "/changes" method as described in [RFC8620], Section 5.2.
这是[RFC8620]第5.2节所述的标准“/变更”方法。
This is a standard "/query" method as described in [RFC8620], Section 5.5.
这是[RFC8620]第5.5节所述的标准“/查询”方法。
A *FilterCondition* object has the following properties, any of which may be omitted:
*FilterCondition*对象具有以下属性，其中任何属性都可以省略：
o identityIds: "Id[]"
o 标识Id:“Id[]”
The EmailSubmission "identityId" property must be in this list to match the condition.
EmailSubmission“identityId”属性必须在此列表中才能与条件匹配。
o emailIds: "Id[]"
o EmailID:“Id[]”
The EmailSubmission "emailId" property must be in this list to match the condition.
EmailSubmission“emailId”属性必须在此列表中才能与条件匹配。
o threadIds: "Id[]"
o threadId:“Id[]”
The EmailSubmission "threadId" property must be in this list to match the condition.
EmailSubmission“threadId”属性必须在此列表中才能与条件匹配。
o undoStatus: "String"
o 撤消状态：“字符串”
The EmailSubmission "undoStatus" property must be identical to the value given to match the condition.
EmailSubmission“undoStatus”属性必须与给定的值相同，以匹配条件。
o before: "UTCDate"
o 在“UTCDate”之前
The "sendAt" property of the EmailSubmission object must be before this date-time to match the condition.
EmailSubmission对象的“sendAt”属性必须早于此日期时间才能与条件匹配。
o after: "UTCDate"
o “UTCDate”之后
The "sendAt" property of the EmailSubmission object must be the same as or after this date-time to match the condition.
EmailSubmission对象的“sendAt”属性必须与此日期时间相同或在该日期时间之后，才能与条件匹配。
An EmailSubmission object matches the FilterCondition if and only if all of the given conditions match. If zero properties are specified, it is automatically true for all objects.
当且仅当所有给定条件都匹配时，EmailSubmission对象才匹配FilterCondition。如果指定零属性，则所有对象的属性都自动为真。
The following EmailSubmission properties MUST be supported for sorting:
排序必须支持以下EmailSubmission属性：
o "emailId"
o “电子邮件ID”
o "threadId"
o “线程ID”
o "sentAt"
o “sentAt”
This is a standard "/queryChanges" method as described in [RFC8620], Section 5.6.
这是[RFC8620]第5.6节所述的标准“/queryChanges”方法。
This is a standard "/set" method as described in [RFC8620], Section 5.3 with the following two additional request arguments:
这是一个标准的“/set”方法，如[RFC8620]第5.3节所述，具有以下两个额外的请求参数：
o onSuccessUpdateEmail: "Id[PatchObject]|null"
o onSuccessUpdateEmail:“Id[PatchObject]| null”
A map of EmailSubmission id to an object containing properties to update on the Email object referenced by the EmailSubmission if the create/update/destroy succeeds. (For references to EmailSubmissions created in the same "/set" invocation, this is equivalent to a creation-reference, so the id will be the creation id prefixed with a "#".)
EmailSubmission id到对象的映射，该对象包含在创建/更新/销毁成功时EmailSubmission引用的电子邮件对象上要更新的属性。（对于在同一“/set”调用中创建的EmailSubmissions引用，这相当于创建引用，因此id将是以“#”为前缀的创建id）
o onSuccessDestroyEmail: "Id[]|null"
o OnSuccessDestroy电子邮件：“Id[]|空”
A list of EmailSubmission ids for which the Email with the corresponding "emailId" should be destroyed if the create/update/ destroy succeeds. (For references to EmailSubmission creations, this is equivalent to a creation-reference, so the id will be the creation id prefixed with a "#".)
电子邮件提交ID列表，如果创建/更新/销毁成功，则应销毁具有相应“emailId”的电子邮件。（对于EmailSubmission创建的引用，这相当于创建引用，因此id将是以“#”为前缀的创建id）
After all create/update/destroy items in the "EmailSubmission/set" invocation have been processed, a single implicit "Email/set" call MUST be made to perform any changes requested in these two arguments. The response to this MUST be returned after the "EmailSubmission/set" response.
在处理了“EmailSubmission/set”调用中的所有创建/更新/销毁项之后，必须进行一个隐式的“Email/set”调用，以执行这两个参数中请求的任何更改。对此的响应必须在“EmailSubmission/set”响应之后返回。
An Email is sent by creating an EmailSubmission object. When processing each create, the server must check that the message is valid, and the user has sufficient authorisation to send it. If the creation succeeds, the message will be sent to the recipients given in the envelope "rcptTo" parameter. The server MUST remove any Bcc header field present on the message during delivery. The server MAY add or remove other header fields from the submitted message or make further alterations in accordance with the server's policy during delivery.
通过创建EmailSubmission对象发送电子邮件。在处理每个创建时，服务器必须检查消息是否有效，以及用户是否有足够的权限发送消息。如果创建成功，消息将发送给信封“rcptTo”参数中给定的收件人。在传递期间，服务器必须删除邮件上存在的任何密件抄送头字段。服务器可以从提交的邮件中添加或删除其他标题字段，或者在传递期间根据服务器的策略进行进一步更改。
If the referenced Email is destroyed at any point after the EmailSubmission object is created, this MUST NOT change the behaviour of the submission (i.e., it does not cancel a future send). The "emailId" and "threadId" properties of the EmailSubmission object remain, but trying to fetch them (with a standard "Email/get" call) will return a "notFound" error if the corresponding objects have been destroyed.
如果在创建EmailSubmission对象后的任何时候销毁了引用的电子邮件，则不得更改提交的行为（即，它不会取消未来的发送）。EmailSubmission对象的“emailId”和“threadId”属性仍然存在，但如果相应的对象已被销毁，尝试获取它们（使用标准的“Email/get”调用）将返回“notFound”错误。
Similarly, destroying an EmailSubmission object MUST NOT affect the deliveries it represents. It purely removes the record of the submission. The server MAY automatically destroy EmailSubmission objects after some time or in response to other triggers, and MAY forbid the client from manually destroying EmailSubmission objects.
类似地，销毁EmailSubmission对象不得影响它所代表的传递。它纯粹是删除提交的记录。服务器可能会在一段时间后或响应其他触发器自动销毁EmailSubmission对象，并且可能会禁止客户端手动销毁EmailSubmission对象。
If the message to be sent is larger than the server supports sending, a standard "tooLarge" SetError MUST be returned. A "maxSize" "UnsignedInt" property MUST be present on the SetError specifying the maximum size of a message that may be sent, in octets.
如果要发送的消息大于服务器支持发送的消息，则必须返回标准的“tooLarge”SetError。SetError上必须存在“maxSize”“UnsignedInt”属性，指定可以发送的消息的最大大小（以八位字节为单位）。
If the Email or Identity id given cannot be found, the submission creation is rejected with a standard "invalidProperties" SetError.
如果找不到给定的电子邮件或标识id，则提交创建将被拒绝，并出现标准的“invalidProperties”设置错误。
The following extra SetError types are defined:
定义了以下额外的SetError类型：
For "create":
对于“创建”：
o "invalidEmail" - The Email to be sent is invalid in some way. The SetError SHOULD contain a property called "properties" of type "String[]" that lists *all* the properties of the Email that were invalid.
o “invalidEmail”-要发送的电子邮件在某些方面是无效的。SetError应该包含一个名为“properties”的属性，类型为“String[]”，它列出了*电子邮件中所有*无效的属性。
o "tooManyRecipients" - The envelope (supplied or generated) has more recipients than the server allows. A "maxRecipients" "UnsignedInt" property MUST also be present on the SetError specifying the maximum number of allowed recipients.
o “tooManyRecipients”-信封（提供或生成）的收件人数量超过服务器允许的数量。SetError上还必须存在“maxRecipients”“UnsignedInt”属性，指定允许的最大收件人数。
o "noRecipients" - The envelope (supplied or generated) does not have any rcptTo email addresses.
o “无收件人”-信封（提供或生成）没有任何rcptTo电子邮件地址。
o "invalidRecipients" - The "rcptTo" property of the envelope (supplied or generated) contains at least one rcptTo value, which is not a valid email address for sending to. An "invalidRecipients" "String[]" property MUST also be present on the SetError, which is a list of the invalid addresses.
o “invalidRecipients”-信封（提供或生成）的“rcptTo”属性至少包含一个rcptTo值，该值不是发送到的有效电子邮件地址。SetError上还必须存在“invalidRecipients”“String[]”属性，该属性是无效地址的列表。
o "forbiddenMailFrom" - The server does not permit the user to send a message with the envelope From address [RFC5321].
o “禁止邮件发件人”-服务器不允许用户使用信封发件人地址[RFC5321]发送邮件。
o "forbiddenFrom" - The server does not permit the user to send a message with the From header field [RFC5322] of the message to be sent.
o “禁止发件人”-服务器不允许用户发送带有待发送消息的发件人标头字段[RFC5322]的消息。
o "forbiddenToSend" - The user does not have permission to send at all right now for some reason. A "description" "String" property MAY be present on the SetError object to display to the user why they are not permitted.
o “禁止发送”-由于某些原因，用户现在根本没有发送的权限。SetError对象上可能存在“description”“String”属性，以向用户显示不允许使用这些属性的原因。
For "update":
对于“更新”：
o "cannotUnsend" - The client attempted to update the "undoStatus" of a valid EmailSubmission object from "pending" to "canceled", but the message cannot be unsent.
o “cannotUnsend”-客户端试图将有效EmailSubmission对象的“undoStatus”从“pending”更新为“cannotUnsend”，但无法取消发送消息。
The following example presumes a draft of the Email to be sent has already been saved, and its Email id is "M7f6ed5bcfd7e2604d1753f6c". This call then sends the Email immediately, and if successful, removes the "$draft" flag and moves it from the drafts folder (which has Mailbox id "7cb4e8ee-df87-4757-b9c4-2ea1ca41b38e") to the sent folder (which we presume has Mailbox id "73dbcb4b-bffc-48bd-8c2a-a2e91ca672f6").
以下示例假定要发送的电子邮件草稿已保存，其电子邮件id为“M7f6ed5bcfd7e2604d1753f6c”。然后，此呼叫立即发送电子邮件，如果成功，则删除“$draft”标志并将其从草稿文件夹（邮箱id为“7cb4e8ee-df87-4757-b9c4-2ea1ca41b38e”）移动到已发送文件夹（我们假定邮箱id为“73dbcb4b-bffc-48bd-8c2a-a2e91ca672f6”）。
[[ "EmailSubmission/set", {
"accountId": "ue411d190",
"create": {
"k1490": {
"identityId": "I64588216",
"emailId": "M7f6ed5bcfd7e2604d1753f6c",
"envelope": {
"mailFrom": {
"email": "john@example.com",
"parameters": null
},
"rcptTo": [{
"email": "jane@example.com",
"parameters": null
},
...
]
}
}
},
"onSuccessUpdateEmail": {
"#k1490": {
"mailboxIds/7cb4e8ee-df87-4757-b9c4-2ea1ca41b38e": null,
"mailboxIds/73dbcb4b-bffc-48bd-8c2a-a2e91ca672f6": true,
"keywords/$draft": null
}
}
}, "0" ]]
[[ "EmailSubmission/set", {
"accountId": "ue411d190",
"create": {
"k1490": {
"identityId": "I64588216",
"emailId": "M7f6ed5bcfd7e2604d1753f6c",
"envelope": {
"mailFrom": {
"email": "john@example.com",
"parameters": null
},
"rcptTo": [{
"email": "jane@example.com",
"parameters": null
},
...
]
}
}
},
"onSuccessUpdateEmail": {
"#k1490": {
"mailboxIds/7cb4e8ee-df87-4757-b9c4-2ea1ca41b38e": null,
"mailboxIds/73dbcb4b-bffc-48bd-8c2a-a2e91ca672f6": true,
"keywords/$draft": null
}
}
}, "0" ]]
A successful response might look like this. Note that there are two responses due to the implicit "Email/set" call, but both have the same method call id as they are due to the same call in the request:
成功的响应可能是这样的。请注意，由于隐式的“Email/set”调用，有两个响应，但它们都具有相同的方法调用id，因为它们是由于请求中的相同调用引起的：
[[ "EmailSubmission/set", {
"accountId": "ue411d190",
"oldState": "012421s6-8nrq-4ps4-n0p4-9330r951ns21",
"newState": "355421f6-8aed-4cf4-a0c4-7377e951af36",
"created": {
"k1490": {
"id": "ES-3bab7f9a-623e-4acf-99a5-2e67facb02a0"
}
}
}, "0" ],
[ "Email/set", {
"accountId": "ue411d190",
"oldState": "778193",
"newState": "778197",
"updated": {
"M7f6ed5bcfd7e2604d1753f6c": null
}
}, "0" ]]
[[ "EmailSubmission/set", {
"accountId": "ue411d190",
"oldState": "012421s6-8nrq-4ps4-n0p4-9330r951ns21",
"newState": "355421f6-8aed-4cf4-a0c4-7377e951af36",
"created": {
"k1490": {
"id": "ES-3bab7f9a-623e-4acf-99a5-2e67facb02a0"
}
}
}, "0" ],
[ "Email/set", {
"accountId": "ue411d190",
"oldState": "778193",
"newState": "778197",
"updated": {
"M7f6ed5bcfd7e2604d1753f6c": null
}
}, "0" ]]
Suppose instead an admin has removed sending rights for the user, so the submission is rejected with a "forbiddenToSend" error. The description argument of the error is intended for display to the user, so it should be localised appropriately. Let's suppose the request was sent with an Accept-Language header like this:
相反，假设管理员删除了用户的发送权限，因此提交被拒绝，并出现“禁止发送”错误。错误的description参数旨在向用户显示，因此应该适当地对其进行本地化。让我们假设请求是使用如下所示的Accept Language标头发送的：
Accept-Language: de;q=0.9,en;q=0.8
Accept-Language: de;q=0.9,en;q=0.8
The server should attempt to choose the best localisation from those it has available based on the Accept-Language header, as described in [RFC8620], Section 3.8. If the server has English, French, and German translations, it would choose German as the preferred language and return a response like this:
如[RFC8620]第3.8节所述，服务器应尝试根据Accept Language标头从可用本地化中选择最佳本地化。如果服务器有英语、法语和德语翻译，它会选择德语作为首选语言，并返回如下响应：
[[ "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" ]]
[[ "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" ]]
A vacation response sends an automatic reply when a message is delivered to the mail store, informing the original sender that their message may not be read for some time.
当邮件被发送到邮件存储时，假期响应会自动发送回复，通知原始发件人他们的邮件可能在一段时间内无法阅读。
Automated message sending can produce undesirable behaviour. To avoid this, implementors MUST follow the recommendations set forth in [RFC3834].
自动消息发送可能会产生不良行为。为了避免这种情况，实施者必须遵循[RFC3834]中提出的建议。
The *VacationResponse* object represents the state of vacation-response-related settings for an account. It has the following properties:
*VacationResponse*对象表示帐户的假期响应相关设置的状态。它具有以下属性：
o id: "Id" (immutable; server-set)
o id：“id”（不可变；服务器集）
The id of the object. There is only ever one VacationResponse object, and its id is "singleton".
对象的id。只有一个VacationResponse对象，其id为“singleton”。
o isEnabled: "Boolean"
o isEnabled：“布尔”
Should a vacation response be sent if a message arrives between the "fromDate" and "toDate"?
如果消息在“fromDate”和“toDate”之间到达，是否应发送假期响应？
o fromDate: "UTCDate|null"
o 起始日期：“UTCDate |空”
If "isEnabled" is true, messages that arrive on or after this date-time (but before the "toDate" if defined) should receive the user's vacation response. If null, the vacation response is effective immediately.
如果“isEnabled”为true，则在此日期或时间之后到达的消息（如果定义了“toDate”，则在“toDate”之前）应接收用户的假期响应。如果为空，假期响应将立即生效。
o toDate: "UTCDate|null"
o toDate:“UTCDate |空”
If "isEnabled" is true, messages that arrive before this date-time (but on or after the "fromDate" if defined) should receive the user's vacation response. If null, the vacation response is effective indefinitely.
如果“isEnabled”为true，则在此日期时间之前到达的消息（如果定义了“fromDate”，则在“fromDate”或之后到达）应接收用户的假期响应。如果为null，则假期响应将无限期有效。
o subject: "String|null"
o 主题：“字符串|空”
The subject that will be used by the message sent in response to messages when the vacation response is enabled. If null, an appropriate subject SHOULD be set by the server.
启用假期响应时，为响应消息而发送的消息将使用的主题。如果为null，则服务器应设置适当的主题。
o textBody: "String|null"
o textBody:“字符串|空”
The plaintext body to send in response to messages when the vacation response is enabled. If this is null, the server SHOULD generate a plaintext body part from the "htmlBody" when sending vacation responses but MAY choose 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.
启用假期响应时，为响应消息而发送的明文正文。如果该值为null，则在发送假期响应时，服务器应该从“htmlBody”生成一个纯文本正文部分，但可以选择仅以HTML形式发送响应。如果“textBody”和“htmlBody”都为空，则服务器应为响应生成适当的默认正文。
o htmlBody: "String|null"
o htmlBody:“字符串|空”
The HTML body to send in response to messages when the vacation response is enabled. If this is null, the server MAY choose to generate an HTML body part from the "textBody" when sending vacation responses or MAY choose to send the response as plaintext only.
启用假期响应时，为响应消息而发送的HTML正文。如果该值为null，则服务器可以选择在发送假期响应时从“textBody”生成HTML正文部分，或者选择仅以明文形式发送响应。
The following JMAP methods are supported.
支持以下JMAP方法。
This is a standard "/get" method as described in [RFC8620], Section 5.1.
这是[RFC8620]第5.1节所述的标准“/get”方法。
There MUST only be exactly one VacationResponse object in an account. It MUST have the id "singleton".
一个帐户中只能有一个VacationResponse对象。它必须具有id“singleton”。
This is a standard "/set" method as described in [RFC8620], Section 5.3.
这是[RFC8620]第5.3节所述的标准“/set”方法。
All security considerations of JMAP [RFC8620] apply to this specification. Additional considerations specific to the data types and functionality introduced by this document are described in the following subsections.
JMAP[RFC8620]的所有安全注意事项均适用于本规范。以下小节介绍了本文档介绍的数据类型和功能的其他注意事项。
Service providers typically perform security filtering on incoming messages, and it's important that the detection of content-type and charset for the security filter aligns with the heuristics performed by JMAP servers. Servers that apply heuristics to determine the content-type or charset for an EmailBodyValue SHOULD document the heuristics and provide a mechanism to turn them off in the event they are misaligned with the security filter used at a particular mail host.
服务提供者通常对传入消息执行安全过滤，安全过滤器的内容类型和字符集的检测与JMAP服务器执行的启发式方法保持一致，这一点很重要。应用试探法来确定EmailBodyValue的内容类型或字符集的服务器应记录试探法，并提供一种机制，以便在它们与特定邮件主机上使用的安全筛选器不一致时将其关闭。
Automatic conversion of charsets that allow hidden channels for ASCII text, such as UTF-7, have been problematic for security filters in the past, so server implementations can mitigate this risk by having such conversions off-by-default and/or separately configurable.
自动转换允许ASCII文本的隐藏通道的字符集（如UTF-7）在过去对于安全过滤器来说一直是个问题，因此服务器实现可以通过在默认情况下关闭这种转换和/或单独配置来减轻这种风险。
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 returned for a textual body part. However, truncating the data may change the semantic meaning, for example, truncating a URL changes its location. Servers that scan for links to malicious sites should take care to either ensure truncation is not at a semantically significant point or rescan the truncated value for malicious content before returning it.
为了允许客户端限制其在响应请求时可以接收的数据量，可以为文本主体部分返回的数据请求最大长度。但是，截断数据可能会更改语义，例如，截断URL会更改其位置。扫描指向恶意站点的链接的服务器应注意确保截断不在语义重要点，或在返回恶意内容之前重新扫描截断值。
HTML message bodies provide richer formatting for messages but present a number of security challenges, especially when embedded in a webmail context in combination with interface HTML. Clients that render HTML messages should carefully consider the potential risks, including:
HTML消息体为消息提供了更丰富的格式，但也带来了许多安全挑战，特别是当嵌入到webmail上下文中并与HTML接口结合使用时。呈现HTML消息的客户端应该仔细考虑潜在的风险，包括：
o Embedded JavaScript can rewrite the message to change its content on subsequent opening, allowing users to be mislead. In webmail systems, if run in the same origin as the interface, it can access and exfiltrate all private data accessible to the user, including all other messages and potentially contacts, calendar events, settings, and credentials. It can also rewrite the interface to undetectably phish passwords. A compromise is likely to be persistent, not just for the duration of page load, due to exfiltration of session credentials or installation of a service worker that can intercept all subsequent network requests (however, this would only be possible if blob downloads are also available on the same origin, and the service worker script is attached to the message).
o 嵌入式JavaScript可以重写消息，在后续打开时更改其内容，从而允许用户受到误导。在webmail系统中，如果与界面在同一来源中运行，它可以访问和过滤用户可访问的所有私人数据，包括所有其他消息和潜在联系人、日历事件、设置和凭据。它还可以将接口重写为无法检测到的钓鱼密码。由于会话凭证的过滤或安装可以拦截所有后续网络请求的服务工作程序，妥协可能是持久的，而不仅仅是在页面加载期间（但是，只有当blob下载在同一来源上也可用，并且服务工作者脚本附加到消息时，这才可能实现）。
o HTML documents may load content directly from the Internet rather than just referencing attached resources. For example, you may have an "<img>" tag with an external "src" attribute. This may leak to the sender when a message is opened, as well as the IP address of the recipient. Cookies may also be sent and set by the server, allowing tracking between different messages and even website visits and advertising profiles.
o HTML文档可以直接从Internet加载内容，而不仅仅是引用附加的资源。例如，您可能有一个带有外部“src”属性的“<img>”标记。这可能会在打开邮件时泄露给发件人，以及收件人的IP地址。Cookie也可以由服务器发送和设置，允许跟踪不同的消息，甚至网站访问和广告配置文件。
o In webmail systems, CSS can break the layout or create phishing vulnerabilities. For example, the use of "position:fixed" can allow a message to draw content outside of its normal bounds, potentially clickjacking a real interface element.
o 在webmail系统中，CSS可以破坏布局或创建网络钓鱼漏洞。例如，使用“position:fixed”可以允许消息在其正常边界之外绘制内容，可能会点击一个真实的界面元素。
o If in a webmail context and not inside a separate frame, any styles defined in CSS rules will apply to interface elements as well if the selector matches, allowing the interface to be modified. Similarly, any interface styles that match elements in the message will alter their appearance, potentially breaking the layout of the message.
o 如果在webmail上下文中而不是在单独的框架中，则如果选择器匹配，CSS规则中定义的任何样式也将应用于接口元素，从而允许修改接口。类似地，与消息中的元素匹配的任何接口样式都将改变其外观，从而可能破坏消息的布局。
o The link text in HTML has no necessary correlation with the actual target of the link, which can be used to make phishing attacks more convincing.
o HTML中的链接文本与链接的实际目标没有必要的相关性，这可以用来使钓鱼攻击更具说服力。
o Links opened from a message or embedded external content may leak private info in the Referer header sent by default in most systems.
o 在大多数系统中，从消息或嵌入的外部内容打开的链接可能会在默认情况下发送的Referer标头中泄漏私人信息。
o Forms can be used to mimic login boxes, providing a potent phishing vector if allowed to submit directly from the message display.
o 表单可用于模拟登录框，如果允许直接从消息显示提交，则可提供强大的网络钓鱼载体。
There are a number of ways clients can mitigate these issues, and a defence-in-depth approach that uses a combination of techniques will provide the strongest security.
客户端可以通过多种方式缓解这些问题，而使用多种技术组合的纵深防御方法将提供最强的安全性。
o HTML can be filtered before rendering, stripping potentially malicious content. Sanitising HTML correctly is tricky, and implementors are strongly recommended to use a well-tested library with a carefully vetted whitelist-only approach. New features with unexpected security characteristics may be added to HTML rendering engines in the future; a blacklist approach is likely to result in security issues.
o 可以在呈现之前过滤HTML，剥离潜在的恶意内容。正确清理HTML是一件棘手的事情，强烈建议实现者使用经过良好测试的库，并采用经过仔细审查的纯白名单方法。将来可能会在HTML呈现引擎中添加具有意外安全特性的新功能；黑名单方法可能会导致安全问题。
Subtle differences in parsing of HTML can introduce security flaws: to filter with 100% accuracy, you need to use the same parser that the HTML rendering engine will use.
HTML解析中的细微差异可能会引入安全缺陷：要100%准确地进行过滤，需要使用HTML呈现引擎将使用的相同解析器。
o Encapsulating the message in an "<iframe sandbox>", as defined in [HTML], Section 4.7.6, can help mitigate a number of risks. This will:
o 按照[HTML]第4.7.6节中的定义，将消息封装在“<iframe sandbox>”中有助于降低许多风险。这将：
* Disable JavaScript.
* 禁用JavaScript。
* Disable form submission.
* 禁用表单提交。
* Prevent drawing outside of its bounds or conflicts between message CSS and interface CSS.
* 防止在消息CSS和接口CSS之间的边界之外绘制或冲突。
* Establish a unique anonymous origin, separate to the containing origin.
* 建立一个独立于包含源的唯一匿名源。
o A strong Content Security Policy (see <https://www.w3.org/TR/ CSP3/>) can, among other things, block JavaScript and the loading of external content should it manage to evade the filter.
o 强大的内容安全策略（请参阅<https://www.w3.org/TR/ CSP3/>）可以阻止JavaScript和加载外部内容（如果它设法避开过滤器）。
o The leakage of information in the Referer header can be mitigated with the use of a referrer policy (see <https://www.w3.org/TR/ referrer-policy/>).
o 可以通过使用Referer策略来缓解Referer标头中的信息泄漏（请参阅<https://www.w3.org/TR/ 推荐人策略/>）。
o A "crossorigin=anonymous" attribute on tags that load remote content can prevent cookies from being sent.
o 加载远程内容的标记上的“crossorigin=anonymous”属性可以阻止发送cookie。
o If adding "target=_blank" to open links in new tabs, also add "rel=noopener" to ensure the page that opens cannot change the URL in the original tab to redirect the user to a phishing site.
o 如果添加“target=_blank”以在新选项卡中打开链接，还应添加“rel=noopener”以确保打开的页面无法更改原始选项卡中的URL以将用户重定向到钓鱼网站。
As highly complex software components, HTML rendering engines increase the attack surface of a client considerably, especially when being used to process untrusted, potentially malicious content.
作为高度复杂的软件组件，HTML呈现引擎极大地增加了客户端的攻击面，尤其是在用于处理不受信任的潜在恶意内容时。
Serious bugs have been found in image decoders, JavaScript engines, and HTML parsers in the past, which could lead to full system compromise. Clients using an engine should ensure they get the latest version and continue to incorporate any security patches released by the vendor.
过去在图像解码器、JavaScript引擎和HTML解析器中发现了严重的错误，这可能导致整个系统受损。使用引擎的客户端应确保获得最新版本，并继续使用供应商发布的任何安全修补程序。
Messages may consist of multiple parts to be displayed sequentially as a body. Clients MUST render each part in isolation and MUST NOT concatenate the raw text values to render. Doing so may change the overall semantics of the message. If the client or server is decrypting a Pretty Good Privacy (PGP) or S/MIME encrypted part, concatenating with other parts may leak the decrypted text to an attacker, as described in [EFAIL].
消息可能由多个部分组成，以正文的形式顺序显示。客户端必须单独呈现每个部分，并且不能连接原始文本值进行呈现。这样做可能会改变消息的整体语义。如果客户端或服务器正在解密相当好的隐私（PGP）或S/MIME加密部分，则与其他部分连接可能会将解密文本泄漏给攻击者，如[EFAIL]中所述。
SMTP submission servers [RFC6409] use a number of mechanisms to mitigate damage caused by compromised user accounts and end-user systems including rate limiting, anti-virus/anti-spam milters (mail filters), and other technologies. The technologies work better when they have more information about the client connection. If JMAP email submission is implemented as a proxy to an SMTP submission server, it is useful to communicate this information from the JMAP proxy to the submission server. The de facto XCLIENT extension to SMTP [XCLIENT] can be used to do this, but use of an authenticated channel is recommended to limit use of that extension to explicitly authorised proxies.
SMTP提交服务器[RFC6409]使用多种机制来减轻受损用户帐户和最终用户系统造成的损害，包括速率限制、反病毒/反垃圾邮件过滤器（邮件过滤器）和其他技术。当这些技术有更多关于客户端连接的信息时，它们工作得更好。如果JMAP电子邮件提交是作为SMTP提交服务器的代理实现的，那么将此信息从JMAP代理传递到提交服务器是非常有用的。可以使用SMTP[XCLIENT]的事实上的XCLIENT扩展来完成此操作，但建议使用经过身份验证的通道，以将该扩展的使用限制为明确授权的代理。
JMAP servers that proxy to an SMTP submission server SHOULD allow use of the submissions port [RFC8314]. Implementation of a mechanism similar to SMTP XCLIENT is strongly encouraged. While Simple Authentication and Security Layer (SASL) PLAIN over TLS [RFC4616] is presently the mandatory-to-implement mechanism for interoperability with SMTP submission servers [RFC4954], a JMAP submission proxy SHOULD implement and prefer a stronger mechanism for this use case such as TLS client certificate authentication with SASL EXTERNAL ([RFC4422], Appendix A) or Salted Challenge Response Authentication Mechanism (SCRAM) [RFC7677].
代理SMTP提交服务器的JMAP服务器应允许使用提交端口[RFC8314]。强烈鼓励实施类似于SMTP XCLIENT的机制。虽然TLS上的简单身份验证和安全层（SASL）平原[RFC4616]目前是实现与SMTP提交服务器[RFC4954]互操作性的强制机制，但JMAP提交代理应该实现并更喜欢此用例的更强大机制，例如使用SASL外部的TLS客户端证书身份验证([RFC4422]，附录A）或SALT质询响应认证机制（紧急停堆）[RFC7677]。
In the event the JMAP server directly relays mail to SMTP servers in other administrative domains, implementation of the de facto [milter] protocol is strongly encouraged to integrate with third-party products that address security issues including anti-virus/anti-spam, reputation protection, compliance archiving, and data loss prevention. Proxying to a local SMTP submission server may be a simpler way to provide such security services.
如果JMAP服务器直接将邮件转发给其他管理域中的SMTP服务器，强烈建议实施事实上的[milter]协议，以与解决安全问题的第三方产品集成，包括防病毒/反垃圾邮件、声誉保护、法规遵从性归档和数据丢失预防。代理到本地SMTP提交服务器可能是提供此类安全服务的更简单方法。
A user may only have permission to access a subset of the data that exists in an account. To avoid leaking unauthorised information, in such a situation, the server MUST treat any data the user does not have permission to access the same as if it did not exist.
用户可能只有访问帐户中存在的数据子集的权限。为避免泄露未经授权的信息，在这种情况下，服务器必须将用户无权访问的任何数据视为不存在。
For example, suppose user A has an account with two Mailboxes, inbox and sent, but only shares the inbox with user B. In this case, when user B fetches Mailboxes for this account, the server MUST behave as though the sent Mailbox did not exist. Similarly, when querying or fetching Email objects, it MUST treat any messages that just belong to the sent Mailbox as though they did not exist. Fetching Thread objects MUST only return ids for Email objects the user has permission to access; if none, the Thread again MUST be treated the same as if it did not exist.
例如，假设用户A有一个具有两个邮箱（收件箱和已发送邮箱）的帐户，但仅与用户B共享收件箱。在这种情况下，当用户B获取此帐户的邮箱时，服务器的行为必须与已发送邮箱不存在一样。类似地，在查询或获取电子邮件对象时，它必须将属于已发送邮箱的任何邮件视为不存在。获取线程对象必须只返回用户有权访问的电子邮件对象的ID；如果没有，则必须再次将线程视为不存在的线程。
If the server forbids a single account from having two identical messages, or two messages with the same Message-Id header field, a user with write access can use the error returned by trying to create/import such a message to detect whether it already exists in an inaccessible portion of the account.
如果服务器禁止单个帐户具有两条相同的消息，或两条消息具有相同的消息Id标头字段，则具有写访问权限的用户可以使用尝试创建/导入此类消息时返回的错误来检测该消息是否已存在于帐户的不可访问部分中。
In recent years, the email ecosystem has moved towards associating trust with the From address in the message [RFC5322], particularly with schemes such as Domain-based Message Authentication, Reporting, and Conformance (DMARC) [RFC7489].
近年来，电子邮件生态系统已转向将信任与邮件中的发件人地址[RFC5322]相关联，特别是与基于域的邮件身份验证、报告和一致性（DMARC）[RFC7489]等方案相关联。
The set of Identity objects (see Section 6) in an account lets the client know which email addresses the user has permission to send from. Each email submission is associated with an Identity, and servers SHOULD reject submissions where the From header field of the message does not correspond to the associated Identity.
帐户中的一组标识对象（见第6节）让客户端知道用户有权从哪些电子邮件地址发送。每个电子邮件提交都与一个标识关联，如果邮件的“发件人”标题字段与关联标识不对应，则服务器应拒绝提交。
The server MAY allow an exception to send an exact copy of an existing message received into the mail store to another address (otherwise known as "redirecting" or "bouncing"), although it is RECOMMENDED the server limit this to destinations the user has verified they also control.
服务器可能允许异常将接收到邮件存储的现有邮件的准确副本发送到另一个地址（也称为“重定向”或“跳转”），但建议服务器将此限制到用户已验证其也控制的目的地。
If the user attempts to create a new Identity object, the server MUST reject it with the appropriate error if the user does not have permission to use that email address to send from.
如果用户试图创建新的标识对象，如果用户没有使用该电子邮件地址进行发送的权限，则服务器必须拒绝该对象，并出现相应的错误。
The SMTP MAIL FROM address [RFC5321] is often confused with the From message header field [RFC5322]. The user generally only ever sees the address in the message header field, and this is the primary one to enforce. However, the server MUST also enforce appropriate restrictions on the MAIL FROM address [RFC5321] to stop the user from flooding a third-party address with bounces and non-delivery notices.
SMTP邮件发件人地址[RFC5321]经常与发件人邮件头字段[RFC5322]混淆。用户通常只在消息头字段中看到地址，这是要强制执行的主要地址。但是，服务器还必须对邮件发件人地址[RFC5321]实施适当的限制，以防止用户向第三方地址发送跳转和未送达通知。
The JMAP submission model provides separate errors for impermissible addresses in either context.
JMAP提交模型为两种上下文中不允许的地址提供了单独的错误。
IANA has registered the "mail" JMAP Capability as follows:
IANA已注册“邮件”JMAP功能，如下所示：
Capability Name: urn:ietf:params:jmap:mail
Capability Name: urn:ietf:params:jmap:mail
Specification document: this document
规范文件：本文件
Intended use: common
预期用途：普通
Change Controller: IETF
更改控制器：IETF
Security and privacy considerations: this document, Section 9
安全和隐私注意事项：本文件第9节
IANA has registered the "submission" JMAP Capability as follows:
IANA已注册“提交”JMAP功能，如下所示：
Capability Name: urn:ietf:params:jmap:submission
Capability Name: urn:ietf:params:jmap:submission
Specification document: this document
规范文件：本文件
Intended use: common
预期用途：普通
Change Controller: IETF
更改控制器：IETF
Security and privacy considerations: this document, Section 9
安全和隐私注意事项：本文件第9节
IANA has registered the "vacationresponse" JMAP Capability as follows:
IANA已注册“vacationresponse”JMAP功能，如下所示：
Capability Name: urn:ietf:params:jmap:vacationresponse
Capability Name: urn:ietf:params:jmap:vacationresponse
Specification document: this document
规范文件：本文件
Intended use: common
预期用途：普通
Change Controller: IETF
更改控制器：IETF
Security and privacy considerations: this document, Section 9
安全和隐私注意事项：本文件第9节
This document makes two changes to the IMAP keywords registry as defined in [RFC5788].
本文档对[RFC5788]中定义的IMAP关键字注册表进行了两次更改。
First, the name of the registry is changed to the "IMAP and JMAP Keywords" registry.
首先，注册表的名称更改为“IMAP和JMAP关键字”注册表。
Second, a scope column is added to the template and registry indicating whether a keyword applies to "IMAP-only", "JMAP-only", "both", or "reserved". All keywords already in the IMAP keyword registry have been marked with a scope of "both". The "reserved" status can be used to prevent future registration of a name that would be confusing if registered. Registration of keywords with scope "reserved" omit most fields in the registration template (see registration of "$recent" below for an example); such registrations are intended to be infrequent.
其次，在模板和注册表中添加一个scope列，指示关键字是应用于“仅IMAP”、“仅JMAP”、“两者”还是“保留”。IMAP关键字注册表中已经存在的所有关键字都已标记为范围为“两者”。“保留”状态可用于防止将来注册一个名称，该名称在注册后会引起混淆。范围为“reserved”的关键字注册会忽略注册模板中的大多数字段（请参见下面的“$recent”注册示例）；这类注册并不常见。
IMAP clients MAY silently ignore any keywords marked "JMAP-only" or "reserved" in the event they appear in protocol. JMAP clients MAY silently ignore any keywords marked "IMAP-only" or "reserved" in the event they appear in protocol.
IMAP客户端可能会在协议中出现标记为“仅JMAP”或“保留”的任何关键字时忽略它们。JMAP客户端在协议中出现任何标记为“仅IMAP”或“保留”的关键字时，可能会自动忽略这些关键字。
New "JMAP-only" keywords are registered in the following subsections. These keywords correspond to IMAP system keywords and are thus not appropriate for use in IMAP. These keywords cannot be subsequently registered for use in IMAP except via standards action.
在以下小节中注册了新的“仅限JMAP”关键字。这些关键字对应于IMAP系统关键字，因此不适合在IMAP中使用。除非通过标准操作，否则这些关键字随后无法注册以在IMAP中使用。
This registers the "JMAP-only" keyword "$draft" in the "IMAP and JMAP Keywords" registry.
这将在“IMAP和JMAP关键字”注册表中注册“仅JMAP”关键字“$draft”。
Keyword name: $draft
关键字名称：$draft
Scope: JMAP-only
范围：仅限JMAP
Purpose (description): This is set when the user wants to treat the message as a draft the user is composing. This is the JMAP equivalent of the IMAP \Draft flag.
目的（描述）：当用户希望将消息视为用户正在撰写的草稿时，设置此项。这是等同于IMAP\Draft标志的JMAP。
Private or Shared on a server: BOTH
服务器上的私有或共享：两者
Is it an advisory keyword or may it cause an automatic action: Automatic. If the account has an IMAP mailbox marked with the \Drafts special use attribute [RFC6154], setting this flag MAY cause the message to appear in that mailbox automatically. Certain JMAP computed values such as "unreadEmails" will change as a result of changing this flag. In addition, mail clients will typically present draft messages in a composer window rather than a viewer window.
它是一个建议关键字还是可能导致自动操作：自动。如果帐户的IMAP邮箱标记有\Drafts special use属性[RFC6154]，设置此标志可能会导致邮件自动显示在该邮箱中。某些JMAP计算值（如“unreadEmails”）将因更改此标志而更改。此外，邮件客户端通常会在编写器窗口而不是查看器窗口中显示草稿消息。
When/by whom the keyword is set/cleared: This is typically set by a JMAP client when referring to a draft message. One model for draft Emails would result in clearing this flag in an "EmailSubmission/set" operation with an "onSuccessUpdateEmail" argument. In a mail store shared by JMAP and IMAP, this is also set and cleared as necessary so it matches the IMAP \Draft flag.
何时/由谁设置/清除关键字：这通常由JMAP客户端在引用草稿消息时设置。草稿电子邮件的一个模型将导致在带有“onSuccessUpdateEmail”参数的“EmailSubmission/set”操作中清除此标志。在JMAP和IMAP共享的邮件存储中，也会根据需要进行设置和清除，以便与IMAP\Draft标志匹配。
Related keywords: None
相关关键词：无
Related IMAP/JMAP Capabilities: SPECIAL-USE [RFC6154]
相关IMAP/JMAP功能：专用[RFC6154]
Security Considerations: A server implementing this keyword as a shared keyword may disclose that a user considers the message a draft message. This information would be exposed to other users with read permission for the Mailbox keywords.
安全注意事项：将此关键字作为共享关键字实现的服务器可能会披露用户将该消息视为草稿消息。此信息将向具有邮箱关键字读取权限的其他用户公开。
Published specification: this document
已发布规范：本文件
Person & email address to contact for further information:
JMAP mailing list <jmap@ietf.org>
Person & email address to contact for further information:
JMAP mailing list <jmap@ietf.org>
Intended usage: COMMON
预期用途：普通
Owner/Change controller: IESG
所有者/变更控制员：IESG
This registers the "JMAP-only" keyword "$seen" in the "IMAP and JMAP Keywords" registry.
这将在“IMAP和JMAP关键字”注册表中注册“仅JMAP”关键字“$seen”。
Keyword name: $seen
关键字名称：$seen
Scope: JMAP-only
范围：仅限JMAP
Purpose (description): This is set when the user wants to treat the message as read. This is the JMAP equivalent of the IMAP \Seen flag.
目的（说明）：当用户希望将消息视为已读时设置。这是与IMAP\Seen标志等效的JMAP。
Private or Shared on a server: BOTH
服务器上的私有或共享：两者
Is it an advisory keyword or may it cause an automatic action: Advisory. However, certain JMAP computed values such as "unreadEmails" will change as a result of changing this flag.
它是一个advisory关键字还是可能导致自动操作：advisory。但是，某些JMAP计算值（如“unreadEmails”）将因更改此标志而更改。
When/by whom the keyword is set/cleared: This is set by a JMAP client when it presents the message content to the user; clients often offer an option to clear this flag. In a mail store shared by JMAP and IMAP, this is also set and cleared as necessary so it matches the IMAP \Seen flag.
何时/由谁设置/清除关键字：这是由JMAP客户端在向用户显示消息内容时设置的；客户端通常提供清除此标志的选项。在JMAP和IMAP共享的邮件存储中，也会根据需要进行设置和清除，以便与IMAP\Seen标志匹配。
Related keywords: None
相关关键词：无
Related IMAP/JMAP Capabilities: None
相关IMAP/JMAP功能：无
Security Considerations: A server implementing this keyword as a shared keyword may disclose that a user considers the message to have been read. This information would be exposed to other users with read permission for the Mailbox keywords.
安全注意事项：将此关键字作为共享关键字实现的服务器可能会披露用户认为邮件已被读取。此信息将向具有邮箱关键字读取权限的其他用户公开。
Published specification: this document
已发布规范：本文件
Person & email address to contact for further information:
JMAP mailing list <jmap@ietf.org>
Person & email address to contact for further information:
JMAP mailing list <jmap@ietf.org>
Intended usage: COMMON
预期用途：普通
Owner/Change controller: IESG
所有者/变更控制员：IESG
This registers the "JMAP-only" keyword "$flagged" in the "IMAP and JMAP Keywords" registry.
这将在“IMAP和JMAP关键字”注册表中注册“仅JMAP”关键字“$flagged”。
Keyword name: $flagged
关键字名称：$已标记
Scope: JMAP-only
范围：仅限JMAP
Purpose (description): This is set when the user wants to treat the message as flagged for urgent/special attention. This is the JMAP equivalent of the IMAP \Flagged flag.
目的（说明）：当用户希望将消息视为标记为紧急/特别注意时设置。这是与IMAP\Flagged标志等效的JMAP。
Private or Shared on a server: BOTH
服务器上的私有或共享：两者
Is it an advisory keyword or may it cause an automatic action: Automatic. If the account has an IMAP mailbox marked with the \Flagged special use attribute [RFC6154], setting this flag MAY cause the message to appear in that mailbox automatically.
它是一个建议关键字还是可能导致自动操作：自动。如果帐户的IMAP邮箱标记有\Flagged special use属性[RFC6154]，设置此标志可能会导致邮件自动显示在该邮箱中。
When/by whom the keyword is set/cleared: JMAP clients typically allow a user to set/clear this flag as desired. In a mail store shared by JMAP and IMAP, this is also set and cleared as necessary so it matches the IMAP \Flagged flag.
设置/清除关键字的时间/人：JMAP客户端通常允许用户根据需要设置/清除此标志。在JMAP和IMAP共享的邮件存储中，也会根据需要进行设置和清除，以便与IMAP\Flagged标志匹配。
Related keywords: None
相关关键词：无
Related IMAP/JMAP Capabilities: SPECIAL-USE [RFC6154]
相关IMAP/JMAP功能：专用[RFC6154]
Security Considerations: A server implementing this keyword as a shared keyword may disclose that a user considers the message as flagged for urgent/special attention. This information would be exposed to other users with read permission for the Mailbox keywords.
安全注意事项：将此关键字作为共享关键字实现的服务器可能会披露用户认为该消息已标记为紧急/特别注意。此信息将向具有邮箱关键字读取权限的其他用户公开。
Published specification: this document
已发布规范：本文件
Person & email address to contact for further information:
JMAP mailing list <jmap@ietf.org>
Person & email address to contact for further information:
JMAP mailing list <jmap@ietf.org>
Intended usage: COMMON
预期用途：普通
Owner/Change controller: IESG
所有者/变更控制员：IESG
This registers the "JMAP-only" keyword "$answered" in the "IMAP and JMAP Keywords" registry.
这将在“IMAP和JMAP关键字”注册表中注册“仅JMAP”关键字“$answered”。
Keyword name: $answered
关键字名称：$已回答
Scope: JMAP-only
范围：仅限JMAP
Purpose (description): This is set when the message has been answered.
目的（描述）：当消息已应答时设置。
Private or Shared on a server: BOTH
服务器上的私有或共享：两者
Is it an advisory keyword or may it cause an automatic action: Advisory.
它是一个advisory关键字还是可能导致自动操作：advisory。
When/by whom the keyword is set/cleared: JMAP clients typically set this when submitting a reply or answer to the message. It may be set by the "EmailSubmission/set" operation with an "onSuccessUpdateEmail" argument. In a mail store shared by JMAP and IMAP, this is also set and cleared as necessary so it matches the IMAP \Answered flag.
何时/由谁设置/清除关键字：JMAP客户端通常在提交对消息的回复或答复时设置此选项。它可以通过“EmailSubmission/set”操作和“onSuccessUpdateEmail”参数进行设置。在JMAP和IMAP共享的邮件存储中，也会根据需要设置和清除此选项，以便与IMAP\Answered标志匹配。
Related keywords: None
相关关键词：无
Related IMAP/JMAP Capabilities: None
相关IMAP/JMAP功能：无
Security Considerations: A server implementing this keyword as a shared keyword may disclose that a user has replied to a message. This information would be exposed to other users with read permission for the Mailbox keywords.
安全注意事项：将此关键字作为共享关键字实现的服务器可能会披露用户已回复消息。此信息将向具有邮箱关键字读取权限的其他用户公开。
Published specification: this document
已发布规范：本文件
Person & email address to contact for further information:
JMAP mailing list <jmap@ietf.org>
Person & email address to contact for further information:
JMAP mailing list <jmap@ietf.org>
Intended usage: COMMON
预期用途：普通
Owner/Change controller: IESG
所有者/变更控制员：IESG
This registers the keyword "$recent" in the "IMAP and JMAP Keywords" registry.
这将在“IMAP和JMAP关键字”注册表中注册关键字“$recent”。
Keyword name: $recent
关键字名称：$recented
Scope: reserved
范围：保留
Purpose (description): This keyword is not used to avoid confusion with the IMAP \Recent system flag.
用途（说明）：此关键字不用于避免与IMAP\Recent系统标志混淆。
Published specification: this document
已发布规范：本文件
Person & email address to contact for further information:
JMAP mailing list <jmap@ietf.org>
Person & email address to contact for further information:
JMAP mailing list <jmap@ietf.org>
Owner/Change controller: IESG
所有者/变更控制员：IESG
This registers the "JMAP-only" "inbox" attribute in the "IMAP Mailbox Name Attributes" registry, as established in [RFC8457].
这将在[RFC8457]中建立的“IMAP邮箱名称属性”注册表中注册“仅JMAP”“收件箱”属性。
Attribute Name: Inbox
属性名称：收件箱
Description: New mail is delivered here by default.
描述：默认情况下，新邮件在此传递。
Reference: This document, Section 10.5.1
参考：本文件第10.5.1节
Usage Notes: JMAP only
用法说明：仅限JMAP
The following subsections register several new error codes in the "JMAP Error Codes" registry, as defined in [RFC8620].
以下小节在[RFC8620]中定义的“JMAP错误代码”注册表中注册了几个新的错误代码。
JMAP Error Code: mailboxHasChild
JMAP错误代码：mailboxHasChild
Intended use: common
预期用途：普通
Change controller: IETF
更改控制器：IETF
Reference: This document, Section 2.5
参考：本文件第2.5节
Description: The Mailbox still has at least one child Mailbox. The client MUST remove these before it can delete the parent Mailbox.
描述：邮箱仍至少有一个子邮箱。客户端必须先删除这些，然后才能删除父邮箱。
JMAP Error Code: mailboxHasEmail
JMAP错误代码：mailboxHasEmail
Intended use: common
预期用途：普通
Change controller: IETF
更改控制器：IETF
Reference: This document, Section 2.5
参考：本文件第2.5节
Description: The Mailbox has at least one message assigned to it, and the onDestroyRemoveEmails argument was false.
描述：邮箱至少分配了一封邮件，onDestroyRemoveEmails参数为false。
JMAP Error Code: blobNotFound
JMAP错误代码：blobNotFound
Intended use: common
预期用途：普通
Change controller: IETF
更改控制器：IETF
Reference: This document, Section 4.6
参考：本文件第4.6节
Description: At least one blob id referenced in the object doesn't exist.
描述：对象中至少引用了一个blob id不存在。
JMAP Error Code: tooManyKeywords
JMAP错误代码：tooManyKeywords
Intended use: common
预期用途：普通
Change controller: IETF
更改控制器：IETF
Reference: This document, Section 4.6
参考：本文件第4.6节
Description: The change to the Email's keywords would exceed a server-defined maximum.
描述：对电子邮件关键字的更改将超过服务器定义的最大值。
JMAP Error Code: tooManyMailboxes
JMAP错误代码：ToomanyMailbox
Intended use: common
预期用途：普通
Change controller: IETF
更改控制器：IETF
Reference: This document, Section 4.6
参考：本文件第4.6节
Description: The change to the set of Mailboxes that this Email is in would exceed a server-defined maximum.
描述：对此电子邮件所在邮箱集的更改将超过服务器定义的最大值。
JMAP Error Code: invalidEmail
JMAP错误代码：invalidEmail
Intended use: common
预期用途：普通
Change controller: IETF
更改控制器：IETF
Reference: This document, Section 7.5
参考：本文件第7.5节
Description: The Email to be sent is invalid in some way.
说明：要发送的电子邮件在某些方面无效。
JMAP Error Code: tooManyRecipients
JMAP错误代码：tooManyRecipients
Intended use: common
预期用途：普通
Change controller: IETF
更改控制器：IETF
Reference: This document, Section 7.5
参考：本文件第7.5节
Description: The envelope [RFC5321] (supplied or generated) has more recipients than the server allows.
描述：信封[RFC5321]（提供或生成）的收件人数超过服务器允许的数量。
JMAP Error Code: noRecipients
JMAP错误代码：noRecipients
Intended use: common
预期用途：普通
Change controller: IETF
更改控制器：IETF
Reference: This document, Section 7.5
参考：本文件第7.5节
Description: The envelope [RFC5321] (supplied or generated) does not have any rcptTo email addresses.
说明：信封[RFC5321]（提供或生成）没有任何rcptTo电子邮件地址。
JMAP Error Code: invalidRecipients
JMAP错误代码：invalidRecipients
Intended use: common
预期用途：普通
Change controller: IETF
更改控制器：IETF
Reference: This document, Section 7.5
参考：本文件第7.5节
Description: The rcptTo property of the envelope [RFC5321] (supplied or generated) contains at least one rcptTo value that is not a valid email address for sending to.
说明：信封[RFC5321]（提供或生成）的rcptTo属性至少包含一个rcptTo值，该值不是发送到的有效电子邮件地址。
JMAP Error Code: forbiddenMailFrom
JMAP错误代码：禁止Mailfrom
Intended use: common
预期用途：普通
Change controller: IETF
更改控制器：IETF
Reference: This document, Section 7.5
参考：本文件第7.5节
Description: The server does not permit the user to send a message with this envelope From address [RFC5321].
描述：服务器不允许用户从地址[RFC5321]发送带有此信封的邮件。
JMAP Error Code: forbiddenFrom
JMAP错误代码：禁止从
Intended use: common
预期用途：普通
Change controller: IETF
更改控制器：IETF
Reference: This document, Sections 6.3 and 7.5
参考：本文件第6.3节和第7.5节
Description: The server does not permit the user to send a message with the From header field [RFC5322] of the message to be sent.
描述：服务器不允许用户使用要发送的消息的发件人标头字段[RFC5322]发送消息。
JMAP Error Code: forbiddenToSend
JMAP错误代码：forbiddenToSend
Intended use: common
预期用途：普通
Change controller: IETF
更改控制器：IETF
Reference: This document, Section 7.5
参考：本文件第7.5节
Description: The user does not have permission to send at all right now.
描述：用户现在根本没有发送的权限。
[HTML] Faulkner, S., Eicholz, A., Leithead, T., Danilo, A., and S. Moon, "HTML 5.2", World Wide Web Consortium Recommendation REC-html52-20171214, December 2017, <https://www.w3.org/TR/html52/>.
[HTML]Faulkner，S.，Eicholz，A.，Leithead，T.，Danilo，A.，和S.Moon，“HTML 5.2”，万维网联盟建议REC-html52-20171214，2017年12月<https://www.w3.org/TR/html52/>.
[RFC1870] Klensin, J., Freed, N., and K. Moore, "SMTP Service Extension for Message Size Declaration", STD 10, RFC 1870, DOI 10.17487/RFC1870, November 1995, <https://www.rfc-editor.org/info/rfc1870>.
[RFC1870]Klensin，J.，Freed，N.，和K.Moore，“邮件大小声明的SMTP服务扩展”，STD 10，RFC 1870，DOI 10.17487/RFC1870，1995年11月<https://www.rfc-editor.org/info/rfc1870>.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, <https://www.rfc-editor.org/info/rfc2045>.
[RFC2045]Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第一部分：互联网邮件正文格式”，RFC 2045，DOI 10.17487/RFC20451996年11月<https://www.rfc-editor.org/info/rfc2045>.
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, DOI 10.17487/RFC2047, November 1996, <https://www.rfc-editor.org/info/rfc2047>.
[RFC2047]Moore，K.，“MIME（多用途互联网邮件扩展）第三部分：非ASCII文本的消息头扩展”，RFC 2047，DOI 10.17487/RFC2047，1996年11月<https://www.rfc-editor.org/info/rfc2047>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, DOI 10.17487/RFC2231, November 1997, <https://www.rfc-editor.org/info/rfc2231>.
[RFC2231]Freed，N.和K.Moore，“MIME参数值和编码字扩展：字符集、语言和连续体”，RFC 2231，DOI 10.17487/RFC2231，1997年11月<https://www.rfc-editor.org/info/rfc2231>.
[RFC2369] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields", RFC 2369, DOI 10.17487/RFC2369, July 1998, <https://www.rfc-editor.org/info/rfc2369>.
[RFC2369]Neufeld，G.和J.Baer，“使用URL作为核心邮件列表命令的元语法及其通过消息头字段的传输”，RFC 2369，DOI 10.17487/RFC2369，1998年7月<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>.
[RFC2392]Levinson，E.，“内容ID和消息ID统一资源定位器”，RFC 2392，DOI 10.17487/RFC2392，1998年8月<https://www.rfc-editor.org/info/rfc2392>.
[RFC2557] Palme, J., Hopmann, A., and N. Shelness, "MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)", RFC 2557, DOI 10.17487/RFC2557, March 1999, <https://www.rfc-editor.org/info/rfc2557>.
[RFC2557]Palme，J.，Hopmann，A.，和N.Shelness，“聚合文档的MIME封装，如HTML（MHTML）”，RFC 2557，DOI 10.17487/RFC2557，1999年3月<https://www.rfc-editor.org/info/rfc2557>.
[RFC2852] Newman, D., "Deliver By SMTP Service Extension", RFC 2852, DOI 10.17487/RFC2852, June 2000, <https://www.rfc-editor.org/info/rfc2852>.
[RFC2852]Newman，D.，“通过SMTP服务扩展交付”，RFC 2852，DOI 10.17487/RFC2852，2000年6月<https://www.rfc-editor.org/info/rfc2852>.
[RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282, DOI 10.17487/RFC3282, May 2002, <https://www.rfc-editor.org/info/rfc3282>.
[RFC3282]Alvestrand，H.，“内容语言标题”，RFC 3282，DOI 10.17487/RFC3282，2002年5月<https://www.rfc-editor.org/info/rfc3282>.
[RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, DOI 10.17487/RFC3461, January 2003, <https://www.rfc-editor.org/info/rfc3461>.
[RFC3461]Moore，K.，“用于传递状态通知（DSN）的简单邮件传输协议（SMTP）服务扩展”，RFC 3461，DOI 10.17487/RFC3461，2003年1月<https://www.rfc-editor.org/info/rfc3461>.
[RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, DOI 10.17487/RFC3463, January 2003, <https://www.rfc-editor.org/info/rfc3463>.
[RFC3463]Vaudreuil，G.，“增强邮件系统状态代码”，RFC 3463，DOI 10.17487/RFC3463，2003年1月<https://www.rfc-editor.org/info/rfc3463>.
[RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, DOI 10.17487/RFC3464, January 2003, <https://www.rfc-editor.org/info/rfc3464>.
[RFC3464]Moore，K.和G.Vaudreuil，“交付状态通知的可扩展消息格式”，RFC 3464，DOI 10.17487/RFC3464，2003年1月<https://www.rfc-editor.org/info/rfc3464>.
[RFC3834] Moore, K., "Recommendations for Automatic Responses to Electronic Mail", RFC 3834, DOI 10.17487/RFC3834, August 2004, <https://www.rfc-editor.org/info/rfc3834>.
[RFC3834]Moore，K.，“自动回复电子邮件的建议”，RFC 3834，DOI 10.17487/RFC3834，2004年8月<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>.
[RFC4314]Melnikov，A.，“IMAP4访问控制列表（ACL）扩展”，RFC 4314，DOI 10.17487/RFC4314，2005年12月<https://www.rfc-editor.org/info/rfc4314>.
[RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, DOI 10.17487/RFC4422, June 2006, <https://www.rfc-editor.org/info/rfc4422>.
[RFC4422]Melnikov，A.，Ed.和K.Zeilenga，Ed.，“简单身份验证和安全层（SASL）”，RFC 4422，DOI 10.17487/RFC4422，2006年6月<https://www.rfc-editor.org/info/rfc4422>.
[RFC4616] Zeilenga, K., Ed., "The PLAIN Simple Authentication and Security Layer (SASL) Mechanism", RFC 4616, DOI 10.17487/RFC4616, August 2006, <https://www.rfc-editor.org/info/rfc4616>.
[RFC4616]Zeilenga，K.，Ed.“简单认证和安全层（SASL）机制”，RFC 4616，DOI 10.17487/RFC4616，2006年8月<https://www.rfc-editor.org/info/rfc4616>.
[RFC4865] White, G. and G. Vaudreuil, "SMTP Submission Service Extension for Future Message Release", RFC 4865, DOI 10.17487/RFC4865, May 2007, <https://www.rfc-editor.org/info/rfc4865>.
[RFC4865]White，G.和G.Vaudreuil，“未来邮件发布的SMTP提交服务扩展”，RFC 4865，DOI 10.17487/RFC4865，2007年5月<https://www.rfc-editor.org/info/rfc4865>.
[RFC4954] Siemborski, R., Ed. and A. Melnikov, Ed., "SMTP Service Extension for Authentication", RFC 4954, DOI 10.17487/RFC4954, July 2007, <https://www.rfc-editor.org/info/rfc4954>.
[RFC4954]Siemborski，R.，Ed.和A.Melnikov，Ed.，“用于身份验证的SMTP服务扩展”，RFC 4954，DOI 10.17487/RFC4954，2007年7月<https://www.rfc-editor.org/info/rfc4954>.
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, <https://www.rfc-editor.org/info/rfc5198>.
[RFC5198]Klensin，J.和M.Padlipsky，“网络交换的Unicode格式”，RFC 5198，DOI 10.17487/RFC5198，2008年3月<https://www.rfc-editor.org/info/rfc5198>.
[RFC5248] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced Mail System Status Codes", BCP 138, RFC 5248, DOI 10.17487/RFC5248, June 2008, <https://www.rfc-editor.org/info/rfc5248>.
[RFC5248]Hansen，T.和J.Klensin，“SMTP增强邮件系统状态代码的注册表”，BCP 138，RFC 5248，DOI 10.17487/RFC5248，2008年6月<https://www.rfc-editor.org/info/rfc5248>.
[RFC5256] Crispin, M. and K. Murchison, "Internet Message Access Protocol - SORT and THREAD Extensions", RFC 5256, DOI 10.17487/RFC5256, June 2008, <https://www.rfc-editor.org/info/rfc5256>.
[RFC5256]Crispin，M.和K.Murchison，“互联网消息访问协议-排序和线程扩展”，RFC 5256，DOI 10.17487/RFC5256，2008年6月<https://www.rfc-editor.org/info/rfc5256>.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, <https://www.rfc-editor.org/info/rfc5321>.
[RFC5321]Klensin，J.，“简单邮件传输协议”，RFC 5321DOI 10.17487/RFC5321，2008年10月<https://www.rfc-editor.org/info/rfc5321>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, <https://www.rfc-editor.org/info/rfc5322>.
[RFC5322]Resnick，P.，Ed.，“互联网信息格式”，RFC 5322，DOI 10.17487/RFC5322，2008年10月<https://www.rfc-editor.org/info/rfc5322>.
[RFC5788] Melnikov, A. and D. Cridland, "IMAP4 Keyword Registry", RFC 5788, DOI 10.17487/RFC5788, March 2010, <https://www.rfc-editor.org/info/rfc5788>.
[RFC5788]Melnikov，A.和D.Cridland，“IMAP4关键字注册表”，RFC 5788，DOI 10.17487/RFC5788，2010年3月<https://www.rfc-editor.org/info/rfc5788>.
[RFC6154] Leiba, B. and J. Nicolson, "IMAP LIST Extension for Special-Use Mailboxes", RFC 6154, DOI 10.17487/RFC6154, March 2011, <https://www.rfc-editor.org/info/rfc6154>.
[RFC6154]Leiba，B.和J.Nicolson，“特殊用途邮箱的IMAP列表扩展”，RFC 6154，DOI 10.17487/RFC6154，2011年3月<https://www.rfc-editor.org/info/rfc6154>.
[RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011, <https://www.rfc-editor.org/info/rfc6409>.
[RFC6409]Gellens，R.和J.Klensin，“邮件的邮件提交”，STD 72，RFC 6409，DOI 10.17487/RFC6409，2011年11月<https://www.rfc-editor.org/info/rfc6409>.
[RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized Email Headers", RFC 6532, DOI 10.17487/RFC6532, February 2012, <https://www.rfc-editor.org/info/rfc6532>.
[RFC6532]Yang，A.，Steele，S.，和N.Freed，“国际化电子邮件头”，RFC 6532，DOI 10.17487/RFC6532，2012年2月<https://www.rfc-editor.org/info/rfc6532>.
[RFC6533] Hansen, T., Ed., Newman, C., and A. Melnikov, "Internationalized Delivery Status and Disposition Notifications", RFC 6533, DOI 10.17487/RFC6533, February 2012, <https://www.rfc-editor.org/info/rfc6533>.
[RFC6533]Hansen，T.，Ed.，Newman，C.，和A.Melnikov，“国际化交付状态和处置通知”，RFC 6533，DOI 10.17487/RFC6533，2012年2月<https://www.rfc-editor.org/info/rfc6533>.
[RFC6710] Melnikov, A. and K. Carlberg, "Simple Mail Transfer Protocol Extension for Message Transfer Priorities", RFC 6710, DOI 10.17487/RFC6710, August 2012, <https://www.rfc-editor.org/info/rfc6710>.
[RFC6710]Melnikov，A.和K.Carlberg，“消息传输优先级的简单邮件传输协议扩展”，RFC 6710，DOI 10.17487/RFC6710，2012年8月<https://www.rfc-editor.org/info/rfc6710>.
[RFC7677] Hansen, T., "SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple Authentication and Security Layer (SASL) Mechanisms", RFC 7677, DOI 10.17487/RFC7677, November 2015, <https://www.rfc-editor.org/info/rfc7677>.
[RFC7677]Hansen，T.，“SCRAM-SHA-256和SCRAM-SHA-256-PLUS简单认证和安全层（SASL）机制”，RFC 7677，DOI 10.17487/RFC7677，2015年11月<https://www.rfc-editor.org/info/rfc7677>.
[RFC8098] Hansen, T., Ed. and A. Melnikov, Ed., "Message Disposition Notification", STD 85, RFC 8098, DOI 10.17487/RFC8098, February 2017, <https://www.rfc-editor.org/info/rfc8098>.
[RFC8098]Hansen，T.，Ed.和A.Melnikov，Ed.，“消息处置通知”，STD 85，RFC 8098，DOI 10.17487/RFC8098，2017年2月<https://www.rfc-editor.org/info/rfc8098>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC8314] Moore, K. and C. Newman, "Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access", RFC 8314, DOI 10.17487/RFC8314, January 2018, <https://www.rfc-editor.org/info/rfc8314>.
[RFC8314]Moore，K.和C.Newman，“被认为过时的明文：使用传输层安全（TLS）提交和访问电子邮件”，RFC 8314，DOI 10.17487/RFC8314，2018年1月<https://www.rfc-editor.org/info/rfc8314>.
[RFC8457] Leiba, B., Ed., "IMAP "$Important" Keyword and "\Important" Special-Use Attribute", RFC 8457, DOI 10.17487/RFC8457, September 2018, <https://www.rfc-editor.org/info/rfc8457>.
[RFC8457]Leiba，B.，Ed.，“IMAP”$Important”关键字和“\Important”特殊用途属性，RFC 8457，DOI 10.17487/RFC8457，2018年9月<https://www.rfc-editor.org/info/rfc8457>.
[RFC8474] Gondwana, B., Ed., "IMAP Extension for Object Identifiers", RFC 8474, DOI 10.17487/RFC8474, September 2018, <https://www.rfc-editor.org/info/rfc8474>.
[RFC8474]冈瓦纳，B.，编辑，“对象标识符的IMAP扩展”，RFC 8474，DOI 10.17487/RFC8474，2018年9月<https://www.rfc-editor.org/info/rfc8474>.
[RFC8620] Jenkins, N. and C. Newman, "The JSON Meta Application Protocol", RFC 8620, DOI 10.17487/RFC8620, June 2019, <https://www.rfc-editor.org/info/rfc8620>.
[RFC8620]Jenkins，N.和C.Newman，“JSON元应用程序协议”，RFC 8620，DOI 10.17487/RFC8620，2019年6月<https://www.rfc-editor.org/info/rfc8620>.
[EFAIL] Poddebniak, D., Dresen, C., Mueller, J., Ising, F., Schinzel, S., Friedberger, S., Somorovsky, J., and J. Schwenk, "Efail: Breaking S/MIME and OpenPGP Email Encryption using Exfiltration Channels", August 2018, <https://www.usenix.org/system/files/conference/ usenixsecurity18/sec18-poddebniak.pdf>.
[EFAIL]Poddebniak，D.，Dresen，C.，Mueller，J.，Ising，F.，Schinzel，S.，Friedberger，S.，Somorovsky，J.，和J.Schwenk，“EFAIL:使用Exfilter通道破坏S/MIME和OpenPGP电子邮件加密”，2018年8月<https://www.usenix.org/system/files/conference/ 请使用nixsecurity18/sec18 poddebniak.pdf>。
[milter] Postfix, "Postfix before-queue Milter support", 2019, <http://www.postfix.org/MILTER_README.html>.
[milter]后缀，“队列milter支持之前的后缀”，2019年<http://www.postfix.org/MILTER_README.html>.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, <https://www.rfc-editor.org/info/rfc3501>.
[RFC3501]Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 3501，DOI 10.17487/RFC3501，2003年3月<https://www.rfc-editor.org/info/rfc3501>.
[RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, <https://www.rfc-editor.org/info/rfc7489>.
[RFC7489]Kucherawy，M.，Ed.和E.Zwicky，Ed.，“基于域的消息验证、报告和一致性（DMARC）”，RFC 7489，DOI 10.17487/RFC7489，2015年3月<https://www.rfc-editor.org/info/rfc7489>.
[XCLIENT] Postfix, "Postfix XCLIENT Howto", 2019, <http://www.postfix.org/XCLIENT_README.html>.
[XCLIENT]Postfix，“Postfix XCLIENT Howto”，2019年<http://www.postfix.org/XCLIENT_README.html>.
Authors' Addresses
作者地址
Neil Jenkins Fastmail PO Box 234, Collins St. West Melbourne, VIC 8007 Australia
澳大利亚维多利亚州墨尔本西柯林斯街234号尼尔·詹金斯快件邮政信箱8007
Email: neilj@fastmailteam.com
URI: https://www.fastmail.com
Email: neilj@fastmailteam.com
URI: https://www.fastmail.com
Chris Newman Oracle 440 E. Huntington Dr., Suite 400 Arcadia, CA 91006 United States of America
Chris Newman Oracle 440 E.Huntington博士，美国加利福尼亚州阿卡迪亚400室，91006
Email: chris.newman@oracle.com
Email: chris.newman@oracle.com