[要約] RFC 8621は、メールのためのJSON Meta Application Protocol（JMAP）であり、メールクライアントとサーバー間の効率的な通信を提供します。目的は、メールの同期、送信、受信、検索などの操作を簡素化し、パフォーマンスを向上させることです。
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.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2019 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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
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と同様に、メッセージには0個以上のキーワード（短い任意の文字列）を割り当てることもできます。これらは主に、未読のステータスやメッセージに返信されたかどうかなどのクライアント表示を通知するためのメタデータを格納することを目的としています。 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.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、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]で説明されているインターネットメッセージ形式のドキュメントを指します。 Emailデータ型は、メールストアのメッセージと関連するメタデータを表します。
The capabilities object is returned as part of the JMAP Session object; see [RFC8620], Section 2.
機能オブジェクトは、JMAPセッションオブジェクトの一部として返されます。 [RFC8620]のセクション2をご覧ください。
This document defines three additional capability URIs.
このドキュメントでは、3つの追加機能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セッションの「機能」プロパティのこのプロパティの値は、空のオブジェクトです。
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 maxMailboxesPerEmail： "UnsignedInt | null"
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).
1つのメールオブジェクト（セクション4を参照）に割り当てることができるメールボックス（セクション2を参照）の最大数。これは1以上の整数であるか、制限がない場合はnullである必要があります（または、制限は常にアカウント内のメールボックスの数です）。
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.
メールボックス階層の最大の深さ（つまり、メールボックスが持つことのできる祖先の最大数より1つ多い）、または制限なしの場合はnull。
o maxSizeMailboxName: "UnsignedInt"
o maxSizeMailboxName： "UnsignedInt"
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： "UnsignedInt"
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).
1つのメールオブジェクトで許可される添付ファイルの最大合計サイズ（オクテット単位）。それでもサーバーは、添付ファイルサイズの合計が低いメールのインポートまたは作成を拒否する場合があります（たとえば、本文に数メガバイトのテキストが含まれ、エンコードされた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.
サーバーには、添付ファイル（多くの場合、base64エンコード）とメッセージヘッダーおよび本文を組み合わせることによって作成されたメッセージ[RFC5322]の合計サイズの制限がある場合があります。たとえば、サーバーが「maxSizeAttachmentsPerEmail：50000000」（50 MB）をアドバタイズするとします。強制されるサーバー制限は、70000000オクテットのメッセージサイズの場合があります。 base64エンコーディングと2 MBのHTML本文があっても、50 MBの添付ファイルはこの制限に適合します。
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.
サーバーがComparatorオブジェクトの「property」フィールドに対して「Email / query」ソートでサポートするすべての値のリスト（セクション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の場合、ユーザーはこのアカウントにnullの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.
これは、IdentityおよびEmailSubmissionデータ型と関連するAPIメソッドのサポートを表します。 JMAPセッションの「機能」プロパティのこのプロパティの値は、空のオブジェクトです。
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： "UnsignedInt"
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-name」であり、値は「ehlo-args」のリストです。
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).
送信サーバーと通信するJMAP実装[RFC6409]には、管理者がこのプロパティで公開する送信EHLO機能のセットを変更できる構成設定が必要です（SHOULD）。これにより、JMAPサーバーはコードを変更せずに、新しい送信拡張機能へのアクセスを簡単に追加できます。デフォルトでは、JMAPサーバーは、トランスポートメカニズムに関係するため、JMAPサーバーにのみ関連するEHLO機能（たとえば、PIPELINING、CHUNKING、STARTTLSなど）を非表示にする必要があります。
Examples of Submission extensions to include:
含める送信拡張の例：
* FUTURERELEASE [RFC4865]
* FUTURERELEASE [RFC4865]
* SIZE [RFC1870]
* サイズ[RFC1870]
* DSN [RFC3461]
* DSN [RFC3461]
* DELIVERYBY [RFC2852]
* DELIVERYBY [RFC2852]
* MT-PRIORITY [RFC6710]
* MT-PRIORITY [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.
サーバーは、ユーザーがそのURIで表されるデータ型を使用できるアカウントの「accountCapabilities」プロパティに、適切な機能文字列をキーとして含める必要があります。サポートされているデータ型は、ユーザーがアクセスできるアカウント間で異なる場合があります。たとえば、ユーザーの個人アカウントでは3つのデータセットすべてにアクセスできますが、共有アカウントでは「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).
バッテリーに制約のある環境のクライアントは、ユーザーが開始した変更のフェッチを遅らせたいが、ユーザーに通知できるように新しいメールをすぐにフェッチしたい場合があります。これを行うには、Eメールタイプ（セクション4で定義）ではなく、EmailDeliveryタイプのプッシュに登録できます。
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.
クライアントは、EmailDeliveryタイプのみのプッシュ通知（[RFC8620]を参照）に登録されています。ユーザーがメールを別のデバイスで既読としてマークすると、メールタイプの状態文字列が変更されます。ただし、ストアに新しいものが追加されなかったため、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は同じである必要があります（SHOULD）。
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との互換性のために、Eメールは1つ以上のメールボックスに属している必要があります。メールがメールボックスを変更しても、メールIDは変更されません。
A *Mailbox* object has the following properties:
* Mailbox *オブジェクトには次のプロパティがあります：
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).
メールボックスのユーザーに表示される名前（例： "Inbox"）。これは、機能オブジェクトで指定された最大サイズに従って、少なくとも1文字の長さのNet-Unicode文字列[RFC5198]でなければなりません。同じ親と同じ名前の2つの兄弟メールボックスがあってはなりません。サーバーは、サーバーポリシーに違反する名前（たとえば、スラッシュ（/）または制御文字を含む名前）を拒否する場合があります（MAY）。
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 ロール： "String | 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と共有されます（SPECIAL-USE拡張[RFC6154]を介してIMAPで公開されます）。ただし、IMAPとは異なり、メールボックスは単一の役割のみを持つ必要があり、同じ役割の同じアカウントに2つのメールボックスがあってはなりません。同じデータへのIMAPアクセスを提供するサーバーは、IMAPにもこれらの追加の制限を適用することをお勧めします。それ以外の場合、JMAPを介してデータを公開するときに準拠を確実にするためにIMAP属性を変更することは、実装に依存します。
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.
[RFC8457で確立されているように、値は、<https://www.iana.org/assignments/imap-mailbox-name-attributes/>のIANA "IMAP Mailbox Name Attributes"レジストリにリストされているメールボックス属性名の1つでなければなりません（MUST）。 ]、小文字に変換されます。ここで将来、新しい役割が確立されるかもしれません。
An account is not required to have Mailboxes with any particular roles.
アカウントは、特定の役割を持つメールボックスを持つ必要はありません。
o sortOrder: "UnsignedInt" (default: 0)
o sortOrder： "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のメールボックスリストで、高い順序（同じ親を持つ）のメールボックスの前に表示されます。等しい順序のメールボックスは、名前のアルファベット順にソートする必要があります（SHOULD）。並べ替えでは、ロケール固有の文字順序規則を考慮する必要があります。
o totalEmails: "UnsignedInt" (server-set)
o totalEmails： "UnsignedInt"（サーバーセット）
The number of Emails in this Mailbox.
このメールボックス内の電子メールの数。
o unreadEmails: "UnsignedInt" (server-set)
o unreadEmails： "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.
スレッド内の少なくとも1つの電子メールがこのメールボックスにあるスレッドの数。
o unreadThreads: "UnsignedInt" (server-set)
o unreadThreads： "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.
既存の実装との互換性のために、「未読スレッド」の決定方法はこのドキュメントでは必須ではありません。実装する最も簡単なソリューションは、スレッド内の少なくとも1つのメールがこのメールボックス内にあり、「$ 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」は、スレッド内の少なくとも1つのEメールに「$ seen」または「$ draft」キーワードがなく、スレッド内の少なくとも1つのEメールがこのメールボックスにあるスレッドの数である必要があります。未読のメールがこのメールボックスにある必要はないことに注意してください。さらに、ゴミ箱メールボックス（つまり、「役割」が「ゴミ箱」であるメールボックス）には特別な処理が必要です。
1. Emails that are *only* in the trash (and no other Mailbox) are ignored when calculating the "unreadThreads" count of other Mailboxes.
1. 他のメールボックスの「unreadThreads」数を計算するとき、ゴミ箱に*だけ*ある（他のメールボックスにはない）メールは無視されます。
2. Emails that are *not* in the trash are ignored when calculating the "unreadThreads" count for the trash Mailbox.
2. ゴミ箱メールボックスの「unreadThreads」数を計算するとき、ゴミ箱に*ない*メールは無視されます。
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.
たとえば、コンテンツ全体が2つの電子メール（ゴミ箱にある未読の電子メールと受信トレイにある開封済みの電子メール）を持つ単一のスレッドであるアカウントがあるとします。 「unreadThreads」の数は、ゴミ箱の場合は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の場合、ユーザーはこのメールボックスを「Email / query」呼び出しのフィルターの一部として使用でき、メールボックスはEmailオブジェクトの「mailboxIds」プロパティに含まれている可能性があります。メールオブジェクトは、この権限を持つ*少なくとも1つ*のメールボックスにある場合に取得できます。サブメールボックスが共有されているが、親メールボックスは共有されていない場合、これは誤りである可能性があります。 IMAP ACL「lr」に対応します（IMAPからのマッピングの場合、これがtrueになるためには両方が必要です）。
* 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"
* mayRemoveItems： "ブール"
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からのマッピングの場合、これがtrueになるためには両方が必要です）。
* maySetSeen: "Boolean"
* maySetSeen： "ブール値"
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"
* mayRename： "ブール"
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"
* mayDelete： "ブール値"
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"
* maySubmit： "ブール"
Messages may be submitted directly to this Mailbox. Corresponds to IMAP ACL "p".
メッセージはこのメールボックスに直接送信されます。 IMAP ACL "p"に対応します。
o isSubscribed: "Boolean"
o isSubscribe：「ブール」
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).
ユーザーは、多数の共有アカウント、または非常に大量のメールボックスのセットを持つ共有アカウントにアクセスする権限を持っている可能性がありますが、関心があるのはこれらのいくつかのコンテンツのみです。クライアントは、「isSubscribed」プロパティが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」メソッドですが、応答に対する引数が1つ追加されています。
o updatedProperties: "String[]|null"
o updatedProperties： "文字列[] | null"
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で説明されている標準の「/ query」メソッドですが、次の追加のリクエスト引数があります。
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が最初になります。同様に、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 filterAsTree： "ブール"（デフォルト：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.
メールボックスの「名前」プロパティには、指定された文字列が含まれています。
o role: "String|null"
o 役割： "文字列| null"
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 isSubscribe：「ブール」
The "isSubscribed" property of the Mailbox must be identical to the value given to match the condition.
メールボックスの「isSubscribe」プロパティは、条件に一致するために指定された値と同一である必要があります。
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.
Mailboxオブジェクトは、指定された条件がすべて一致する場合にのみ、FilterConditionと一致します。ゼロのプロパティを指定すると、すべてのオブジェクトに対して自動的にtrueになります。
The following Mailbox properties MUST be supported for sorting:
次のメールボックスプロパティは、並べ替えでサポートされている必要があります。
o "sortOrder"
o 「sortOrder」
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： "Boolean"（デフォルト：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」SetErrorで拒否されます。 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」：メールボックスには、まだ少なくとも1つの子メールボックスがあります。クライアントは、親メールボックスを削除する前にこれらを削除する必要があります。
o "mailboxHasEmail": The Mailbox has at least one Email assigned to it, and the "onDestroyRemoveEmails" argument was false.
o 「mailboxHasEmail」：メールボックスには少なくとも1つのメールが割り当てられており、「onDestroyRemoveEmails」引数はfalseでした。
Fetching all Mailboxes in an account:
アカウント内のすべてのメールボックスを取得する：
[[ "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" ]]
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" ]]
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" ]]
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" ]]
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" ]]
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:
2つのEメールが同じスレッドに属しているかどうかを判別するための正確なアルゴリズムは、この仕様では必須ではありません。異なる既存のシステムとの互換性を可能にするためです。新しい実装では、次の条件の両方が当てはまる場合、2つのメッセージが同じスレッドに属することが推奨されます。
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]が、両方のメッセージのMessage-Id、In-Reply-To、およびReferencesヘッダーフィールドのいずれかに表示されます。
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".
何らかの理由でメッセージが順序どおりに配信されない場合、ユーザーは同じスレッドに2つの電子メールを持っている可能性がありますが、それらを互いに関連付けるヘッダーはありません。 3番目の電子メールの到着は、それらをすべて1つのスレッドに結合するための欠落した参照を提供する場合があります。メールの「threadId」は不変であるため、サーバーがスレッドをマージしたい場合は、「threadId」を変更するメールを削除して（新しいメールIDで）再挿入することでこれを処理する必要があります。
A *Thread* object has the following properties:
* Thread *オブジェクトには次のプロパティがあります。
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」日付でソートされ、古いものが最初です。 2つのメールの日付が同じ場合、並べ替えはサーバーに依存しますが、安定している必要があります（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" ]]
with response:
応答あり：
[[ "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で説明されている標準の "/ changes"メソッドです。
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.
大まかに言えば、メッセージは2つの部分で構成されます。ヘッダーフィールドのリストと本文です。 Emailデータ型は、完全な構造にアクセスする方法、または簡略化されたプロパティを使用する方法を提供し、これがクライアントアプリケーションに十分である場合は複雑さを回避します。
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」プロパティに加えて、Emailオブジェクトにはボディパーツのフラットリストを持つ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"：これらは、メッセージの「本文」として順次レンダリングする必要があるパーツのリストを提供します。メッセージはヘッダーやフッターが送信時に個別のパーツとして追加/追加される可能性があり、一部のクライアントは本文にインラインで表示することを目的としたテキストや画像（またはビデオやサウンドさえも）を送信するため、これは単一のパーツではなくリストです参照された画像を含む単一の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表現を優先）があり、2つに対応します。最も一般的なクライアント要件。同じパーツが両方のリストに表示される場合がありますが、2つのリストの間に選択肢はありません。
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 "attachments"：これは、メッセージに "attachments"として提示されるべき部分のリストを提供します。一部の画像は、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に対して2番目のリクエストを実行する必要なく、テキストパーツの値を直接フェッチし、サーバーに文字セットをUnicodeにデコードさせることができます。クライアントがbodyStructure、textBody、htmlBodyの複数をフェッチする場合、同じ部分が2回含まれる可能性があるため、このデータは、EmailBodyPartオブジェクトではなく別のプロパティにあります。
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.
関連するプロパティの数が多いため、Eメールプロパティのセットは、次の4つのサブセクションで指定されています。これは純粋に読みやすくするためです。すべてのプロパティはトップレベルのピアです。
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].
EmailオブジェクトのID。これはJMAPオブジェクトIDであり、メッセージのMessage-IDヘッダーフィールド値ではないことに注意してください[RFC5322]。
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 mailboxIds： "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のセット。メールストア内のメールは、常に（破棄されるまで）1つ以上のメールボックスに属している必要があります。セットはオブジェクトとして表され、各キーはメールボックスIDです。オブジェクトの各キーの値はtrueでなければなりません。
o keywords: "String[Boolean]" (default: {})
o キーワード： "String [Boolean]"（デフォルト：{}）
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の6つのシステムキーワードは特別な扱いを受けます。次の4つのキーワードは、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.
* "$ answered"：メールは返信されました。
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は削除と消去モデルを使用しますが、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:
[RFC5788]で確立された<https://www.iana.org/assignments/imap-jmap-keywords/>のIANA「IMAPおよびJMAPキーワード」レジストリは、一般的に使用されている他のいくつかのキーワードに意味的な意味を割り当てます。新しいキーワードは将来ここに確立されるかもしれません。特に、次のことに注意してください。
* "$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.
* 「$フィッシング」：メールはフィッシングである可能性が高いです。クライアントは、この電子メールを表示するときは注意し、リンクと添付ファイルを無効にするようにユーザーに警告する必要があります。
* "$junk": The Email is definitely spam. Clients SHOULD set this flag when users report spam to help train automated spam-detection systems.
* "$ junk"：メールは間違いなくスパムです。クライアントは、ユーザーがスパムを報告するときにこのフラグを設定して、自動スパム検出システムのトレーニングを支援する必要があります（SHOULD）。
* "$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」：メールはスパムではありません。自動化されたスパム検出システムのトレーニングを支援するために、ユーザーが電子メールが正当であることをユーザーが示した場合、クライアントはこのフラグを設定する必要があります（SHOULD）。
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構文に違反する高ビットセットでオクテットまたはオクテット実行をユニコード置換文字（U + FFFD）に置き換える必要があります（SHOULD）。 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. 結果のユニコードは、正規化形式C（NFC）形式に変換されます。
If any decodings fail, the parser SHOULD insert a unicode replacement character (U+FFFD) and attempt to continue as much as possible.
デコードに失敗した場合、パーサーはユニコード置換文字（U + FFFD）を挿入し、可能な限り続行するようにすべきです（SHOULD）。
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[]"
タイプ：「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で指定されているように、ヘッダーフィールドは「address-list」値として解析され、「EmailAddress []」タイプに変換されます。 「アドレスリスト」から解析された「メールボックス」ごとにEmailAddress項目があります。グループとコメントの情報は破棄されます。
An *EmailAddress* object has the following properties:
* EmailAddress *オブジェクトには次のプロパティがあります。
o name: "String|null"
o 名前： "文字列| null"
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.
「display-name」はないが「addr-spec」の直後に「コメント」がある場合は、この値を代わりに使用してください。それ以外の場合、このプロパティはnullです。
o email: "String"
o メール：「文字列」
The "addr-spec" of the "mailbox" [RFC5322].
「メールボックス」の「addr-spec」[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).
既知のエンコーディングを持つ構文的に正しいエンコードセクション[RFC2047]は、テキストフォームの場合と同じルールに従ってデコードする必要があります（セクション4.1.2.2を参照）。
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オブジェクトには、「addr-spec」フォームに準拠しない「email」プロパティが含まれる場合があります（たとえば、@記号が含まれていない場合があります）。
For example, the following "address-list" string:
たとえば、次の "address-list"文字列：
" 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" }
]
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 Cc
o Bcc
o Bcc
o Resent-From
o 再送元
o Resent-Sender
o 再送信者
o Resent-Reply-To
o Resent-Reply-To
o Resent-To
o 再送先
o Resent-Cc
o Resent-Cc
o Resent-Bcc
o Resent-Bcc
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 名前： "文字列| null"
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.
「グループ」の[display-name] [RFC5322]、またはアドレスがグループの一部でない場合はnull。これが「引用文字列」の場合、EmailAddressタイプの「名前」と同じように処理されます。
o addresses: "EmailAddress[]"
o アドレス：「EmailAddress []」
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).
既知のエンコーディングを持つ構文的に正しいエンコードセクション[RFC2047]は、テキストフォームの場合と同じルールに従ってデコードする必要があります（セクション4.1.2.2を参照）。
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:
たとえば、次の "address-list"文字列：
" 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" }
]}
]
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"
タイプ：「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」値のリストとして解析され、「String []」タイプに変換されます。コメントおよび/または折りたたみ空白（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 Resent-Message-ID
o Any header field not defined in [RFC5322] or [RFC2369]
o [RFC5322]または[RFC2369]で定義されていないヘッダーフィールド
Type: "Date|null"
タイプ：「日付| 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"
タイプ：「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.
[RFC2369]で説明されているように、ヘッダーフィールドはURLのリストとして解析され、「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:
メッセージのヘッダーデータに完全にアクセスするために、次の低レベルのEmailプロパティが指定されています。
o headers: "EmailHeader[]" (immutable)
o headers： "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]で定義されているヘッダー「フィールド値」、Raw形式。
In addition, the client may request/send properties representing individual header fields of the form:
さらに、クライアントは、フォームの個々のヘッダーフィールドを表すプロパティを要求/送信できます。
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}」は、コロン（:)を除く、一連の1つ以上の印刷可能なASCII文字（33〜126の値を含む文字）を意味します。プロパティには、次のサフィックスが付いている場合もあります。
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}」は、上記で指定された解析済みフォーム名の1つです。指定しない場合、値はRaw形式です。
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.
つまり、値は配列であり、メッセージに表示される順序で、ヘッダーフィールドの各インスタンスに対応する項目が含まれます。このサフィックスが使用されない場合、結果はヘッダーフィールドの*最後*のインスタンスの値（つまり、：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 *ヘッダーフィールドを見つけ（大文字と小文字を区別せずに一致）、Raw形式で値を返すことを意味します。この名前のヘッダーフィールドが見つかりません。
For a more complex example, consider the client requesting a property called "header:Resent-To:asAddresses:all". This means:
より複雑な例として、「header：Resent-To：asAddresses：all」というプロパティを要求するクライアントを考えてみましょう。これの意味は：
1. Find *all* header fields named Resent-To (matched case insensitively).
1. Resent-Toという名前の*すべての*ヘッダーフィールドを検索します（大文字と小文字は区別されません）。
2. For each instance, parse the header field value in the Addresses form.
2. インスタンスごとに、アドレスフォームのヘッダーフィールド値を解析します。
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 [] []」です。配列の各項目は、Resent-Toヘッダーフィールドインスタンスの解析された値（それ自体が配列）に対応しています。
The following convenience properties are also specified for the Email object:
次の便利なプロパティもEmailオブジェクトに指定されています。
o messageId: "String[]|null" (immutable)
o messageId： "String [] | 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：asMessageIds」の値と同じです。 RFC 5322に準拠するメッセージの場合、これは単一のエントリを持つ配列になります。
o inReplyTo: "String[]|null" (immutable)
o inReplyTo： "String [] | 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 参照： "String [] | null"（不変）
The value is identical to the value of "header:References:asMessageIds".
この値は、「header：References：asMessageIds」の値と同じです。
o sender: "EmailAddress[]|null" (immutable)
o sender： "EmailAddress [] | null"（不変）
The value is identical to the value of "header:Sender:asAddresses".
この値は、「header：Sender：asAddresses」の値と同じです。
o from: "EmailAddress[]|null" (immutable)
o from： "EmailAddress [] | null"（不変）
The value is identical to the value of "header:From:asAddresses".
この値は、「header：From：asAddresses」の値と同じです。
o to: "EmailAddress[]|null" (immutable)
o to： "EmailAddress [] | null"（不変）
The value is identical to the value of "header:To:asAddresses".
この値は、「header：To：asAddresses」の値と同じです。
o cc: "EmailAddress[]|null" (immutable)
o cc： "EmailAddress [] | null"（不変）
The value is identical to the value of "header:Cc:asAddresses".
この値は、「header：Cc：asAddresses」の値と同じです。
o bcc: "EmailAddress[]|null" (immutable)
o bcc： "EmailAddress [] | null"（不変）
The value is identical to the value of "header:Bcc:asAddresses".
この値は、「header：Bcc：asAddresses」の値と同じです。
o replyTo: "EmailAddress[]|null" (immutable)
o replyTo： "EmailAddress [] | null"（不変）
The value is identical to the value of "header:Reply-To:asAddresses".
この値は、「header：Reply-To：asAddresses」の値と同じです。
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： "文字列| null"
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 / *」である場合にのみ、これはnullです。
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.
既知のContent-Transfer-Encoding（[RFC2045]で定義）をデコードした後の、パーツのコンテンツの未加工オクテットを表すID、またはパーツのタイプが「multipart / *」の場合はnull。 2つの部分は異なる方法で転送エンコードされる場合がありますが、デコードされたオクテットが同一であり、サーバーがBLOB IDのデータの安全なハッシュを使用している場合、BLOB IDは同じです。転送エンコーディングが不明な場合、転送エンコーディングがないかのように扱われます。
o size: "UnsignedInt"
o サイズ：「UnsignedInt」
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.
これは、パーツ内のすべてのヘッダーフィールドのリストで、メッセージに表示される順序です。値はRaw形式です。
o name: "String|null"
o 名前： "文字列| null"
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]によるContent-Dispositionヘッダーフィールドのデコードされた「ファイル名」パラメーター、または（既存のシステムとの互換性のため）存在しない場合は、[RFC2047によるContent-Typeヘッダーフィールドのデコードされた「名前」パラメーターです。 ]。
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.
パーツのContent-Typeヘッダーフィールドの値（存在する場合）。それ以外の場合、MIME標準（「text / plain」または「multipart / digest」内の場合は「message / rfc822」）に応じた暗黙のタイプ。 CFWSが削除され、すべてのパラメーターが削除されます。
o charset: "String|null"
o 文字セット： "String | 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".
Content-Typeヘッダーフィールドのcharsetパラメータの値（存在する場合）、またはヘッダーフィールドは存在するがタイプが "text / *"でない場合はnull。 Content-Typeヘッダーフィールドがない場合、または存在し、タイプが "text / *"であるがcharsetパラメータがない場合、これはMIME標準の暗黙の文字セット "us-ascii"です。
o disposition: "String|null"
o 配置： "文字列| null"
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.
パーツのContent-Dispositionヘッダーフィールドの値（存在する場合）。それ以外の場合はnullです。 CFWSが削除され、すべてのパラメーターが削除されます。
o cid: "String|null"
o cid： "文字列| null"
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].
パーツのContent-Idヘッダーフィールドの値（存在する場合）。それ以外の場合はnullです。 CFWSおよび周囲の山かっこ（ "<>"）が削除されます。これは、[RFC2392]で定義されているように、「cid：」プロトコルを使用して、「text / html」ボディパーツ[HTML]内からコンテンツを参照するために使用できます。
o language: "String[]|null"
o 言語：「String [] | null」
The list of language tags, as defined in [RFC3282], in the Content-Language header field of the part, if present.
[RFC3282]で定義されている、パーツのContent-Languageヘッダーフィールドにある言語タグのリスト（存在する場合）。
o location: "String|null"
o 場所： "文字列| null"
The URI, as defined in [RFC2557], in the Content-Location header field of the part, if present.
[RFC2557]で定義されている、パーツのContent-LocationヘッダーフィールドのURI（存在する場合）。
o subParts: "EmailBodyPart[]|null"
o subParts： "EmailBodyPart [] | null"
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".
さらに、クライアントは、「header：Content-Type」のように、Emailオブジェクトと同じ構文とセマンティクスに従って、個々のヘッダーフィールドを表す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/*".
これは、「message / rfc822」または「message / global」の部分に再帰しない、メッセージ本文の完全なMIME構造です。 EmailBodyPartsのタイプが「multipart / *」の場合、subPartsが含まれる場合があることに注意してください。
o bodyValues: "String[EmailBodyValue]" (immutable)
o bodyValues： "String [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」と、「text / *」部分がないか、一部またはすべてのEmailBodyValueオブジェクトへのマップです。どの部分が含まれるか、および値が切り捨てられるかどうかは、「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.
Content-Transfer-EncodingとContent-Type文字セットをデコードした後の本文部分の値（両方ともサーバーで認識されている場合）、およびCRLFが単一のLFに置き換えられている場合。サーバーはヒューリスティックを使用して、文字セットが不明、文字セットが指定されていない、または指定された文字セットが正しくないと考えている場合に、デコードに使用する文字セットを決定できます。デコードはベストエフォートです。サーバーは、Unicode置換文字（U + FFFD）を挿入して、不正なセクションに遭遇したときに続行する必要があります（SHOULD）。
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の「サイズ」プロパティと正確に同じになるとは限りません。
* 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 attachments: "EmailBodyPart[]" (immutable)
A list, traversing depth-first, of all parts in "bodyStructure" that satisfy either of the following conditions:
以下のいずれかの条件を満たす「bodyStructure」のすべてのパーツの、深さ優先のトラバースのリスト：
* 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".
これらのパーツには、「メッセージ/ *」タイプを含むサブパーツは含まれません。添付されたメッセージは、「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.
「text / html」ボディパーツ[HTML]は、[cid：]リンクを使用して[RFC2392]で定義されているContent-Idを参照するか、Content-Locationを参照することにより、添付ファイル内の画像パーツを参照する場合があります。
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がダウンロード可能として提供する必要があるメッセージに1つ以上の部分がある場合に当てはまります。 「添付ファイル」リストに「Content-Disposition：inline」を持たないアイテムが少なくとも1つ含まれている場合、サーバーはhasAttachmentをtrueに設定する必要があります（SHOULD）。サーバーは、何らかの方法で自動的に処理されるか、メッセージの「text / html」部分の1つに埋め込まれた画像として参照されるこのリストの部分を無視してもよい（MAY）。
The server MAY set hasAttachment based on implementation-defined or site-configurable heuristics.
サーバーは、実装定義またはサイト構成可能なヒューリスティックに基づいてhasAttachmentを設定できます（MAY）。
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.
これはサーバーによるメッセージの内容から導出され、そのためのアルゴリズムは時間の経過とともに変化する可能性があるため、これを電子メールに対して再度フェッチすると、異なる結果が返される場合があります。ただし、以前の値は正しくないとは見なされず、変更によって、Eメールオブジェクトがサーバーによって変更されたと見なされることはありません（SHOULD NOT）。
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、および添付ファイルのパーツリストに分解するための正確なアルゴリズムは必須ではありません。これはサービス品質の実装の問題であり、時間の経過とともに発見された不正な形式のコンテンツに対する回避策が必要になる可能性があるためです。ただし、次のアルゴリズム（ここではJavaScriptで表現）は、実際の経験に基づいた出発点として提案されています。
function isInlineMediaType ( type ) {
return type.startsWith( 'image/' ) ||
type.startsWith( 'audio/' ) ||
type.startsWith( 'video/' );
}
function parseStructure ( parts, multipartType, inAlternative, htmlBody, textBody, attachments ) {
function parseStructure（parts、multipartType、inAlternative、htmlBody、textBody、attachments）{
// 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 ) ) &&
// 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 ( 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 = [];
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
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 ]
This is a standard "/get" method as described in [RFC8620], Section 5.1 with the following additional request arguments:
これは、[RFC8620]のセクション5.1で説明されている標準の「/ get」メソッドで、次のリクエスト引数が追加されています。
o bodyProperties: "String[]"
o bodyProperties: "String[]"
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 fetchHTMLBodyValues： "ブール"（デフォルト：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： "Boolean"（デフォルト：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タグの内部、たとえば「<a href="https://example.com">」の途中で切り詰めるべきではありません（SHOULD NOT）。切り捨てられたフォームがバランスの取れたツリーまたは有効なHTMLである必要はありません（実際、元のソースがこれらのどちらでもない場合もあります）。
If the standard "properties" argument is omitted or null, the following default MUST be used instead of "all" properties:
標準の「プロパティ」引数が省略されているかnullの場合、「すべて」のプロパティの代わりに次のデフォルトを使用する必要があります。
[ "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"、 "mailboxIds"、 "keywords"、 "size"、 "receivedAt"、 "messageId"、 "inReplyTo"、 "references"、 "sender"、 "from"、 " to "、" cc "、" bcc "、" replyTo "、" subject "、" sentAt "、" hasAttachment "、" preview "、" bodyValues "、" textBody "、" htmlBody "、" attachments "]
The following properties are expected to be fast to fetch in a quality implementation:
次のプロパティは、高品質の実装でフェッチするのに高速であることが期待されています。
o id
o id
o blobId
o blobId
o threadId
o threadId
o mailboxIds
o mailboxIds
o keywords
o キーワード
o size
o サイズ
o receivedAt
o receivedAt
o messageId
o messageId
o inReplyTo
o inReplyTo
o sender
o 送る
o from
o から
o to
o と
o cc
o cc
o bcc
o bcc
o replyTo
o に返信
o subject
o 主題
o sentAt
o sentAt
o hasAttachment
o hasAttachment
o preview Clients SHOULD take care when fetching any other properties, as there may be significantly longer latency in fetching and returning the data.
oプレビュークライアントは、他のプロパティをフェッチするときに注意する必要があります。データのフェッチと返送にかなり長い待ち時間がかかる可能性があるためです。
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」エラーで拒否されなければならない（MUST）。
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:
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" ]]
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"
}, {
"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で説明されている標準の "/ changes"メソッドです。大きな変更セットの中間状態を生成する場合は、一般的にユーザーの関心が高いため、最初に新しい変更を返すことをお勧めします。
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: "Boolean" (default: 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の場合、リスト内の前のメールと同じスレッドにあるメール（フィルターおよびソート順を指定）はリストから削除されます。つまり、特定のスレッドのリストには、最大で1つのメールのみが含まれます。
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.
品質の実装では、クエリの「total」プロパティは、totalEmailsプロパティまたはtotalThreadsプロパティ（collapseThreadsがtrueかどうかに応じて異なる）と同じであるため、フィルタが単一の「inMailbox」プロパティのみで構成される場合、計算が高速になると予想されます。関連付けられたメールボックスオブジェクト。
A *FilterCondition* object has the following properties, any of which may be omitted:
* FilterCondition *オブジェクトには、次のプロパティがあります。これらのプロパティは省略できます。
o inMailbox: "Id"
o inMailbox: "Id"
A Mailbox id. An Email must be in this Mailbox to match the condition.
メールボックスID。条件に一致するには、このメールボックスに電子メールが含まれている必要があります。
o inMailboxOtherThan: "Id[]"
o inMailboxOtherThan： "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のリスト。条件に一致するには、このリストにないメールボックスにメールが1つ以上ある必要があります。これは、ゴミ箱/スパムのみのメッセージを検索から簡単に除外できるようにするためです。
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： "UnsignedInt"
The "size" property of the Email must be equal to or greater than this number to match the condition.
条件に一致するには、Eメールの「サイズ」プロパティがこの数値以上である必要があります。
o maxSize: "UnsignedInt"
o maxSize： "UnsignedInt"
The "size" property of the Email must be less than this number to match the condition.
条件に一致するには、電子メールの「サイズ」プロパティがこの数値よりも小さい必要があります。
o allInThreadHaveKeyword: "String"
o allInThreadHaveKeyword： "文字列"
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.
このメールと同じスレッド内の少なくとも1つのメール（おそらくこれ）には、条件に一致する特定のキーワードが必要です。
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 hasKeyword： "文字列"
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.
メールでテキストを探します。サーバーはメッセージのFrom、To、Cc、Bcc、およびSubjectヘッダーフィールドでテキストを検索する必要があり、サーバーによってテキストに変換される可能性のある「text / *」またはその他の本文部分の内部を確認する必要があります。サーバーは追加のテキストプロパティに検索を拡張できます。
o from: "String"
o from： "文字列"
Looks for the text in the From header field of the message.
メッセージのFromヘッダーフィールドでテキストを探します。
o to: "String"
o to： "文字列"
Looks for the text in the To header field of the message.
メッセージのToヘッダーフィールドでテキストを探します。
o cc: "String"
o cc： "文字列"
Looks for the text in the Cc header field of the message.
メッセージのCcヘッダーフィールドでテキストを検索します。
o bcc: "String"
o bcc： "文字列"
Looks for the text in the Bcc header field of the message.
メッセージのBccヘッダーフィールドでテキストを探します。
o subject: "String"
o subject: "String"
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.
メッセージの本文部分の1つでテキストを探します。サーバーは、 "text / *"および "message / *"以外のコンテンツメディアタイプのMIMEボディパーツを検索マッチングの対象から除外してもよい（MAY）。そのメディアタイプの視聴者が実際にエンドユーザーに提示したテキストコンテンツ、または検索インデックス作成に適切であると識別されたテキストコンテンツに基づいて一致するように注意する必要があります。興味のないドキュメントメタデータをエンドユーザーに一致させること（マークアップタグや属性名など）は望ましくありません。
o header: "String[]"
o ヘッダー：「String []」
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.
配列には、1つまたは2つの要素を含める必要があります。最初の要素は、照合するヘッダーフィールドの名前です。 2番目（オプション）の要素は、ヘッダーフィールド値で検索するテキストです。指定しない場合、指定された名前のヘッダーフィールドがある場合、メッセージは単純に一致します。
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と評価される必要があります。複数のプロパティが指定されている場合、条件が真になるにはALLを適用する必要があります（これは、オブジェクトを1つのプロパティ条件に分割し、それらすべてを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]は、テキストを照合する前にデコードする必要があります（SHOULD）。
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 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.
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 フレーズの外では、空白は、個別に検索できる別々のトークンを分割するものとして扱う必要があります（SHOULD）が、フィルターに一致する電子メールにはすべて存在する必要があります。
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 トークン（フレーズの一部ではない）は、ステミングを使用して単語全体で一致する場合があります（たとえば、「バス」のテキスト検索は「バス」に一致しますが、「ビジネス」には一致しません）。
The following value for the "property" field on the Comparator object MUST be supported for sorting:
並べ替えでは、Comparatorオブジェクトの「property」フィールドの次の値をサポートする必要があります。
o "receivedAt" - The "receivedAt" date as returned in the Email object.
o 「receivedAt」-Emailオブジェクトで返される「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.
Comparatorオブジェクトの「property」フィールドの次の値は、並べ替えをサポートする必要があります（SHOULD）。 「hasKeyword」、「allInThreadHaveKeyword」、または「someInThreadHaveKeyword」のソートを指定する場合、Comparatorオブジェクトには「keyword」プロパティも必要です。
o "size" - The "size" as returned in the Email object.
o 「サイズ」-Emailオブジェクトで返される「サイズ」。
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 /空の場合は、Eメールの "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 /空の場合は、Eメールの "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"-Emailオブジェクトの "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オブジェクトの追加の "keyword"プロパティとして指定されたキーワードを持っている場合、この値は電子メールに対してtrueと見なされる必要があります。
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" - 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.
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
}]
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.
これにより、最初にフラグの付いたスレッドの電子メールがソートされ（スレッド内の電子メールにフラグが付いている場合、スレッドはフラグの付いたと見なされます）、次に件名の順序で、次に同じ件名のメッセージの新しいものが最初にソートされます。 2つのメールの3つのプロパティすべてに同じ値がある場合、順序はサーバーに依存しますが、安定している必要があります。
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).
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).
This is a standard "/queryChanges" method as described in [RFC8620], Section 5.6 with the following additional request argument:
これは、[RFC8620]のセクション5.6で説明されている標準の「/ queryChanges」メソッドであり、次のリクエスト引数が追加されています。
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:
This is a standard "/set" method as described in [RFC8620], Section 5.3. The "Email/set" method encompasses:
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).
「keywords」/「mailboxIds」プロパティの形式は、メールを更新するときに、キーワード/メールボックスのセット全体を置き換える（プロパティの完全な値を設定する）か、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」プロパティは、トップレベルのEmailまたは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 Emailまたは特定のEmailBodyPart内に同じヘッダーフィールド（「header：from」と「from」など）を表す2つのプロパティがあってはなりません。
o Header fields MUST NOT be specified in parsed forms that are forbidden for that particular field.
o ヘッダーフィールドは、その特定のフィールドで禁止されている解析済みの形式で指定してはなりません（MUST NOT）。
o Header fields beginning with "Content-" MUST NOT be specified on the Email object, only on EmailBodyPart objects.
o 「Content-」で始まるヘッダーフィールドは、EmailBodyPartオブジェクトでのみ、Emailオブジェクトで指定してはなりません。
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にはボディパーツを1つだけ含める必要があり、「text / plain」タイプである必要があります。
o If given, htmlBody MUST contain exactly one body part and it MUST be of type "text/html".
o 指定する場合、htmlBodyにはボディパーツを1つだけ含める必要があり、「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」プロパティを省略しなければなりません（パーツのコンテンツはbodyValuesに含まれ、サーバーは適切なエンコーディングを選択できます）。
* 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.
* Content-Transfer-Encodingヘッダーフィールドを指定してはなりません（MUST NOT）。
o Within an EmailBodyValue object, isEncodingProblem and isTruncated MUST be either false or omitted.
o EmailBodyValueオブジェクト内では、isEncodingProblemとisTruncatedを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」エラーで拒否される必要があります。ただし、サーバーは、要件に準拠するように電子メールを変更する（たとえば、競合するヘッダーを選択する、別のコンテンツエンコーディングを使用するなど）ことを選択できます（MAY）。
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.
サーバーは、追加のヘッダーを設定することも選択できます（MAY）。含まれていない場合、サーバーは[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に基づいて無効になる可能性があります。たとえば、ドラフトが半完成の場合、Toヘッダーフィールドの値が、このヘッダーに必要な構文に準拠していない可能性があります。メッセージは、送信のために送信されるときに厳密な適合性がチェックされます（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.
メールを破棄すると、そのメールが属していたすべてのメールボックスから削除されます。メールをごみ箱に削除するには、「mailboxIds」プロパティを変更するだけで、「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.
For successfully created Email objects, the "created" response contains the "id", "blobId", "threadId", and "size" properties of the object.
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に指定された少なくとも1つのblob IDが存在しません。タイプ「Id []」の追加の「notFound」プロパティは、サーバー上で見つからなかったEmailBodyPartによって参照されるすべての「blobId」を含むSetErrorオブジェクトに含まれている必要があります。
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 "tooManyMailboxes"：このメールが含まれるメールボックスのセットに対する変更は、サーバーが定義した最大値を超えます。
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で説明されている標準の「/ copy」メソッドですが、「mailboxIds」、「keywords」、および「receivedAt」プロパティのみがコピー中に設定される場合があります。このメソッドは、Eメールで表されるメッセージを変更できません。
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]を持つ2つのEmailオブジェクトがアカウント内で共存することを禁止する場合があります。ターゲットアカウントに既にメールがある場合、コピーは標準の「alreadyExists」エラーで拒否されます。
For successfully copied Email objects, the "created" response contains the "id", "blobId", "threadId", and "size" properties of the new object.
正常にコピーされた電子メールオブジェクトの場合、「作成」応答には、新しいオブジェクトの「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:
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:
o accountId: "Id"
o accountId： "Id"
The id of the account to use.
使用するアカウントのID。
o ifInState: "String|null"
o ifInState： "文字列| null"
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によって参照されるアカウントの現在の状態と一致する必要があります。そうでない場合、メソッドは中止され、「stateMismatch」エラーが返されます。 nullの場合、変更は現在の状態に適用されます。
o emails: "Id[EmailImport]"
o メール：「Id [EmailImport]」
A map of creation id (client specified) to EmailImport objects.
EmailImportオブジェクトへの作成ID（クライアント指定）のマップ。
An *EmailImport* object has the following properties:
* EmailImport *オブジェクトには次のプロパティがあります。
o blobId: "Id"
o blobId： "Id"
The id of the blob containing the raw message [RFC5322].
生のメッセージを含むblobのID [RFC5322]。
o mailboxIds: "Id[Boolean]"
o mailboxIds： "Id [ブール]"
The ids of the Mailboxes to assign this Email to. At least one Mailbox MUST be given.
このメールを割り当てるメールボックスのID。少なくとも1つのメールボックスを指定する必要があります。
o keywords: "String[Boolean]" (default: {})
o キーワード： "String [Boolean]"（デフォルト：{}）
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"（デフォルト：最新のReceivedヘッダーの時刻、またはサーバーにインポートされなかった場合の時刻）
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によって参照されるデータから新しいメールオブジェクトが正常に作成され、指定されたメールボックス、キーワード、およびreceivedAt日付が適用されます。
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]の2つの電子メールオブジェクトがアカウント内で共存することを禁止する場合があります。この場合、 "alreadyExists" SetErrorを使用して重複と見なされる電子メールをインポートする試みを拒否する必要があります。タイプ「Id」の「existingId」プロパティは、既存の電子メールのIDを持つSetErrorオブジェクトに含める必要があります。重複が許可される場合、新しく作成されたEmailオブジェクトは、既存のオブジェクトに対して個別の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」、「mailboxIds」、または「keywords」プロパティが無効な場合（たとえば、欠落、間違ったタイプ、IDが見つからないなど）、サーバーは「invalidProperties」SetErrorでインポートを拒否する必要があります。
If the Email cannot be imported because it would take the account over quota, the import should be rejected with an "overQuota" SetError.
アカウントがクォータを超えるためにメールをインポートできない場合、インポートは「overQuota」SetErrorで拒否されます。
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" SetErrorでインポートを拒否してもよい（MAY）。
The response has the following arguments:
応答には次の引数があります。
o accountId: "Id"
o accountId： "Id"
The id of the account used for this call.
この呼び出しに使用されるアカウントのID。
o oldState: "String|null"
o oldState： "文字列| null"
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 newState： "文字列"
The state string that will now be returned by "Email/get" on this account.
このアカウントの「Email / get」によって返される状態文字列。
o created: "Id[Email]|null"
o 作成：「Id [Email] | null」
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」、「blobId」、「threadId」、および「size」プロパティを含むオブジェクトへの作成IDのマップ。存在しない場合は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.
作成に失敗した各メールのSetErrorオブジェクトへの作成IDのマップ、またはすべてが成功した場合は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.
"stateMismatch"： "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]、Eメールオブジェクトを取得できます。サーバーはEAIヘッダーを持つメッセージをサポートしなければなりません[RFC6532]。これを使用すると、添付されたメッセージを、それ自体をメールストアのトップレベルの電子メールオブジェクトとしてインポートする必要なく、解析して表示できます。
The following metadata properties on the Email objects will be null if requested:
要求された場合、Emailオブジェクトの以下のメタデータプロパティはnullになります。
o id
o id
o mailboxIds
o mailboxIds
o keywords
o キーワード
o receivedAt
o receivedAt
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」プロパティが存在する場合があります。それ以外の場合、フェッチされた場合、これもnullです。
The "Email/parse" method takes the following arguments:
「Email / parse」メソッドは次の引数を取ります。
o accountId: "Id"
o accountId： "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 プロパティ：「String []」
If supplied, only the properties listed in the array are returned for each Email object. If omitted, defaults to:
指定すると、配列にリストされているプロパティのみが各Emailオブジェクトに対して返されます。省略した場合、デフォルトは次のとおりです。
[ "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.
A list of properties to fetch for each EmailBodyPart returned. If omitted, defaults to the same value as the "Email/get" "bodyProperties" default argument.
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 fetchHTMLBodyValues: "Boolean" (default: 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： "Boolean"（デフォルト：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タグの内部、たとえば「<a href="https://example.com">」の途中で切り詰めるべきではありません（SHOULD NOT）。切り捨てられたフォームがバランスの取れたツリーまたは有効なHTMLである必要はありません（実際、元のソースがこれらのどちらでもない場合もあります）。
The response has the following arguments:
応答には次の引数があります。
o accountId: "Id"
o accountId： "Id"
The id of the account used for the call.
呼び出しに使用されたアカウントのID。
o parsed: "Id[Email]|null"
o 解析済み： "Id [Email] | null"
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 notParsable： "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 notFound： "Id [] | null"
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」エラーで拒否されなければならない（MUST）。
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,
"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」：後方参照を使用して、これらの各メール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" ]
}, {
"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" ]]
The server applies this and sends the success response:
サーバーはこれを適用し、成功応答を送信します。
[[ "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:
元のマシンに戻って、Eメールの状態文字列が「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" ]]
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" ]]
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" ]]
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" ]]
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
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"
}],
"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" ]]
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:
クライアントはこのドラフトを別のアカウントに移動します。これを行う唯一の方法は、「メール/コピー」方法を使用することです。現在の値は宛先アカウントの有効なメールボックスIDではないため、新しい「mailboxIds」プロパティを設定する必要があります。
[[ "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:
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/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 件名： "文字列| null"
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]の3つの文字のインスタンスは、適切な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 プレビュー：「文字列| null」
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.
プレビュー用の本文の関連セクションはサーバー定義です。サーバーが検索スニペットを判別できない場合は、「subject」プロパティと「preview」プロパティの両方に対して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 accountId： "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 emailIds： "Id []"
The ids of the Emails to fetch snippets for.
スニペットを取得するメールのID。
The response has the following arguments:
The response has the following arguments:
o accountId: "Id"
o accountId： "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 notFound： "Id [] | null"
An array of Email ids requested that could not be found, or null if all ids were found.
An array of Email ids requested that could not be found, or null if all ids were found.
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"：クライアントから要求された "emailIds"の数が、サーバーが単一のメソッド呼び出しで処理できる最大数を超えています。
"unsupportedFilter": The server is unable to process the given "filter" for any reason.
"unsupportedFilter": The server is unable to process the given "filter" for any reason.
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" ]]
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" ]]
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.
このIDから新しい電子メールを作成するときにクライアントが使用する「送信元」の名前。
o email: "String" (immutable)
o email： "String"（不変）
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").
このIDから新しい電子メールを作成するときにクライアントが使用する必要がある「送信元」の電子メールアドレス。アドレスの「メールボックス」部分（「@」の前のセクション）が単一文字「*」（たとえば、「* @ example.com」）である場合、クライアントはそのドメイン（たとえば、 、「foo@example.com」）。
o replyTo: "EmailAddress[]|null" (default: null)
o replyTo： "EmailAddress [] | null"（デフォルト：null）
The Reply-To value the client SHOULD set when creating a new Email from this Identity.
このIDから新しい電子メールを作成するときにクライアントが設定する必要があるReply-To値。
o bcc: "EmailAddress[]|null" (default: null)
o bcc： "EmailAddress [] | null"（デフォルト：null）
The Bcc value the client SHOULD set when creating a new Email from this Identity.
このIDから新しい電子メールを作成するときにクライアントが設定するBCC値。
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.
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.
o mayDelete: "Boolean" (server-set)
o mayDelete： "ブール値"（サーバーセット）
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.
ユーザーはこのIDを削除できますか？サーバーは、ユーザーのユーザー名またはその他のデフォルトアドレスに対して、これをfalseに設定したい場合があります。 「mayDelete：false」でIDを破棄しようとすると、標準の「禁止された」SetErrorで拒否されます。
See the "Addresses" header form description in the Email object (Section 4.1.2.3) for the definition of EmailAddress.
EmailAddressの定義については、Emailオブジェクト（セクション4.1.2.3）の「Addresses」ヘッダーフォームの説明を参照してください。
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).
同じ電子メールアドレスを持つ複数のIDが存在する場合があり、ユーザーが異なる設定（たとえば、異なる名前/署名）を選択できるようにすることができます。
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で説明されている標準の "/ changes"メソッドです。
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 "forbiddenFrom"：ユーザーは、IDの "email"プロパティとして指定されたアドレスからの送信を許可されていません。
Request:
リクエスト：
[ "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" ]
An *EmailSubmission* object represents the submission of an Email for delivery to one or more recipients. It has the following properties:
* EmailSubmission *オブジェクトは、1人以上の受信者に配信するための電子メールの送信を表します。次のプロパティがあります。
o id: "Id" (immutable; server-set)
o id： "Id"（不変、サーバーセット）
The id of the EmailSubmission.
EmailSubmissionのID。
o identityId: "Id" (immutable)
o identityId： "Id"（不変）
The id of the Identity to associate with this submission.
この送信に関連付けるIDのID。
o emailId: "Id" (immutable)
o メールID：「Is」（不変）
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 エンベロープ： "Envelope | null"（不変）
Information for use when sending via SMTP. An *Envelope* object has the following properties:
SMTP経由で送信するときに使用する情報。 * Envelope *オブジェクトには次のプロパティがあります。
* mailFrom: "Address"
* mailFrom： "アドレス"
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送信の返信アドレスとして使用する電子メールアドレスと、MAIL FROMアドレスで渡すパラメーター。 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の値をサーバー提供の値に置き換えてもよい（MAY）。
* 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]のMAIL FROMまたはRCPT TOコマンドのリバースパスまたはフォワードパスで使用される「メールボックス」です。
* parameters: "Object|null"
* 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]で指定されている、mail-parameterまたはrcpt-parameterのいずれか適切なもの）。指定されている場合、オブジェクトの各キーはパラメーター名であり、値はパラメーター値（タイプ
"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.
「文字列」）、またはパラメータが値を取らない場合は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:
"envelope"プロパティが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」：Senderヘッダーフィールドのメールアドレス（存在する場合）。それ以外の場合は、存在する場合はFromヘッダーフィールドのメールアドレスです。どちらの場合も、パラメーターは追加されません。
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.
これらのヘッダーフィールドの1つに複数のアドレスが存在する場合、または複数のSender / Fromヘッダーフィールドがある場合、サーバーはEmailSubmissionを無効として拒否する必要があります（SHOULD）。それ以外の場合は、最後のSender / Fromヘッダーフィールドの最初のアドレスを取得する必要があります。
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.
これから見つかったアドレスが、この送信に関連付けられたIDで許可されていない場合は、代わりにIDの「email」プロパティを使用する必要があります。
* "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"：To、Cc、およびBccヘッダーフィールドからの重複排除された電子メールアドレスのセット（存在する場合）。いずれのパラメーターもありません。
o sendAt: "UTCDate" (immutable; server-set)
o sendAt： "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]を正常に使用した場合、これはサーバーがメッセージを解放するときでなければなりません。それ以外の場合は、EmailSubmissionが作成された時刻でなければなりません。
o undoStatus: "String"
o undoStatus： "文字列"
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.
* 「最終」：メッセージは、取り消すことができない方法で少なくとも1人の受信者に中継されました。この送信をキャンセルすることはできません。
* "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： "String [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応答文字列。これが受け入れられ、メッセージ全体がDATAステージの最後で拒否された場合を除き、これはRCPT TOステージへの応答である必要があります（この場合、代わりにDATAステージ応答を使用する必要があります（SHOULD）。
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の代わりに中継されるメッセージの場合、サーバーは代わりにステータスを表す合成文字列を生成してもよい（MAY）。これを行う場合、文字列は次の形式でなければなりません：
+ 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.
+ 次に、1つのスペース文字。
+ Then an SMTP Enhanced Mail System Status Code as defined in [RFC3463], with a registry defined in [RFC5248].
+ 次に、[RFC5248]で定義されたレジストリを使用して、[RFC3463]で定義されたSMTP拡張メールシステムステータスコード。
+ Then a single space character.
+ 次に、1つのスペース文字。
+ 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.
+ "queued"：メッセージはローカルメールキューにあり、ローカルメールキューを出るとステータスが変わります。 「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.
+ "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.
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.
サーバーは他のフィードバックチャネルに基づいてこのプロパティを設定することもできます（MAY）。
* 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".
この受信者に対して、Disposition-Type（[RFC8098]、セクション3.2.6.2に従って）が「displayed」に等しいメッセージ処理通知（MDN）を受信した場合、このプロパティは「yes」に設定する必要があります。
The server MAY also set this property based on other feedback channels.
サーバーは他のフィードバックチャネルに基づいてこのプロパティを設定することもできます（MAY）。
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 /レポート」）です。
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 /レポート」）です。
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.
JMAPサーバーは、DSNおよびMDN応答がEmailSubmissionオブジェクトに関連付けられている場合、それらをEmailオブジェクトとして公開しないことを選択できます。代わりに「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.
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.
The following JMAP methods are supported.
次のJMAPメソッドがサポートされています。
This is a standard "/get" method as described in [RFC8620], Section 5.1.
This is a standard "/get" method as described in [RFC8620], Section 5.1.
This is a standard "/changes" method as described in [RFC8620], Section 5.2.
これは、[RFC8620]のセクション5.2で説明されている標準の "/ changes"メソッドです。
This is a standard "/query" method as described in [RFC8620], Section 5.5.
これは、[RFC8620]のセクション5.5で説明されている標準の「/ query」メソッドです。
A *FilterCondition* object has the following properties, any of which may be omitted:
* FilterCondition *オブジェクトには、次のプロパティがあります。これらのプロパティは省略できます。
o identityIds: "Id[]"
o identityIds： "Id []"
The EmailSubmission "identityId" property must be in this list to match the condition.
The EmailSubmission "identityId" property must be in this list to match the condition.
o emailIds: "Id[]"
o emailIds： "Id []"
The EmailSubmission "emailId" property must be in this list to match the condition.
条件に一致するには、EmailSubmission "emailId"プロパティがこのリストに含まれている必要があります。
o threadIds: "Id[]"
o threadIds: "Id[]"
The EmailSubmission "threadId" property must be in this list to match the condition.
条件に一致するには、EmailSubmission "threadId"プロパティがこのリストに含まれている必要があります。
o undoStatus: "String"
o undoStatus： "文字列"
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と一致します。ゼロのプロパティを指定すると、すべてのオブジェクトに対して自動的にtrueになります。
The following EmailSubmission properties MUST be supported for sorting:
次のEmailSubmissionプロパティは、並べ替えでサポートされている必要があります。
o "emailId"
o 「メリド」
o "threadId"
o 「threadId」
o "sentAt"
o 「sentAt」
This is a standard "/queryChanges" method as described in [RFC8620], Section 5.6.
This is a standard "/queryChanges" method as described in [RFC8620], Section 5.6.
This is a standard "/set" method as described in [RFC8620], Section 5.3 with the following two additional request arguments:
これは、[RFC8620]のセクション5.3で説明されている標準の「/ set」メソッドであり、次の2つのリクエスト引数が追加されています。
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によって参照されるEmailオブジェクトで更新するプロパティを含むオブジェクトへのEmailSubmission IDのマップ。 （同じ "/ set"呼び出しで作成されたEmailSubmissionsへの参照の場合、これはcreation-referenceと同じであるため、IDは "＃"が前に付いた作成IDになります。）
o onSuccessDestroyEmail: "Id[]|null"
o onSuccessDestroyEmail： "Id [] | null"
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 "#".)
作成/更新/破棄が成功した場合に、対応する「emailId」を持つメールを破棄する必要があるEmailSubmission IDのリスト。 （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」呼び出しのすべての作成/更新/破棄項目が処理された後、これらの2つの引数で要求された変更を実行するために、単一の暗黙の「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.
Emailは、EmailSubmissionオブジェクトを作成することによって送信されます。各作成を処理するとき、サーバーはメッセージが有効であること、およびユーザーがメッセージを送信するための十分な権限を持っていることを確認する必要があります。作成が成功した場合、メッセージはエンベロープの「rcptTo」パラメーターで指定された受信者に送信されます。サーバーは、配信中にメッセージに存在するBccヘッダーフィールドを削除する必要があります。サーバーは、送信されたメッセージに他のヘッダーフィールドを追加または削除するか、配信中にサーバーのポリシーに従ってさらに変更を加えることができます。
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オブジェクトが作成された後の任意の時点で参照されているEmailが破棄された場合、これは送信の動作を変更してはなりません（つまり、将来の送信をキャンセルしません）。 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を返さなければなりません（MUST）。 「maxSize」「UnsignedInt」プロパティは、オクテットで送信されるメッセージの最大サイズを指定するSetErrorに存在しなければなりません。
If the Email or Identity id given cannot be found, the submission creation is rejected with a standard "invalidProperties" SetError.
指定されたメールまたはIDが見つからない場合、送信の作成は標準の「invalidProperties」SetErrorで拒否されます。
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には、無効な電子メールの*すべて*のプロパティをリストする「String []」タイプの「properties」と呼ばれるプロパティを含める必要があります（SHOULD）。
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"-エンベロープ（提供または生成）には、サーバーで許可されている数よりも多くの受信者がいます。 "maxRecipients" "UnsignedInt"プロパティは、許可される受信者の最大数を指定するSetErrorにも存在する必要があります。
o "noRecipients" - The envelope (supplied or generated) does not have any rcptTo email addresses.
o "noRecipients"-エンベロープ（提供または生成）には、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"プロパティには、送信先として有効な電子メールアドレスではない少なくとも1つのrcptTo値が含まれています。 "invalidRecipients" "String []"プロパティは、無効なアドレスのリストであるSetErrorにも存在する必要があります。
o "forbiddenMailFrom" - The server does not permit the user to send a message with the envelope From address [RFC5321].
o "forbiddenMailFrom"-サーバーは、ユーザーがエンベロープFromアドレス[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 "forbiddenFrom"-サーバーは、ユーザーが送信するメッセージのFromヘッダーフィールド[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 "forbiddenToSend"-なんらかの理由により、ユーザーには現在送信権限がありません。 "説明" "文字列"プロパティがSetErrorオブジェクトに存在して、許可されていない理由をユーザーに表示する場合があります。
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"を "保留中"から "キャンセル"に更新しようとしましたが、メッセージの送信を取り消すことはできません。
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" ]]
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」呼び出しによる2つの応答がありますが、リクエスト内の同じ呼び出しによるものであるため、どちらも同じメソッド呼び出し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" ]]
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:
代わりに、管理者がユーザーの送信権限を削除したため、送信が「forbiddenToSend」エラーで拒否されたとします。エラーの説明引数はユーザーへの表示を目的としているため、適切にローカライズする必要があります。リクエストが次のようなAccept-Languageヘッダーで送信されたとしましょう：
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" ]]
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 *オブジェクトは、アカウントのVacation-Response関連の設定の状態を表します。次のプロパティがあります。
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オブジェクトは1つしかなく、その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 fromDate： "UTCDate | null"
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」より前）に到着するメッセージは、ユーザーの休暇応答を受信する必要があります。 nullの場合、休暇応答はすぐに有効になります。
o toDate: "UTCDate|null"
o toDate： "UTCDate | null"
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"以降）に到着するメッセージは、ユーザーの休暇応答を受信する必要があります。 nullの場合、休暇応答は無期限に有効になります。
o subject: "String|null"
o 件名： "文字列| null"
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の場合、サーバーによって適切なサブジェクトを設定する必要があります（SHOULD）。
o textBody: "String|null"
o textBody： "文字列| null"
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」からプレーンテキストの本文部分を生成する必要があります（SHOULD）が、応答をHTMLとしてのみ送信することを選択できます（MAY）。 「textBody」と「htmlBody」の両方がnullの場合、サーバーによる応答に対して適切なデフォルトの本文を生成する必要があります（SHOULD）。
o htmlBody: "String|null"
o htmlBody： "文字列| null"
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ボディパーツを生成することを選択するか、またはプレーンテキストのみとして応答を送信することを選択できます（MAY）。
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オブジェクトを1つだけ含める必要があります。 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.
UTF-7など、ASCIIテキストの非表示チャネルを許可する文字セットの自動変換は、これまでセキュリティフィルターにとって問題でした。そのため、サーバーの実装では、このような変換をデフォルトでオフにしたり、個別に構成したりすることで、このリスクを軽減できます。
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: 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).
HTMLメッセージ本文は、メッセージに対してより豊富なフォーマットを提供しますが、特にインターフェースHTMLと組み合わせてWebメールコンテキストに埋め込まれた場合、多くのセキュリティ上の課題を提示します。 HTMLメッセージをレンダリングするクライアントは、次のような潜在的なリスクを慎重に検討する必要があります。o埋め込みJavaScriptはメッセージを書き換えて、後で開くときにコンテンツを変更し、ユーザーを誤解させる可能性があります。ウェブメールシステムでは、インターフェースと同じオリジンで実行されると、ユーザーがアクセスできるすべてのプライベートデータ（他のすべてのメッセージや、場合によっては連絡先、カレンダーのイベント、設定、資格情報など）にアクセスして漏出できます。また、インターフェイスを検出できないフィッシングパスワードに書き換えることもできます。セッションの認証情報の漏えい、または後続のすべてのネットワークリクエストを傍受できるService Workerのインストールにより、ページのロード中だけでなく、妥協が持続する可能性があります（ただし、これは、BLOBのダウンロードも利用できる場合にのみ可能です）同じオリジンで、Service Workerスクリプトがメッセージに添付されます）。
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 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 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 ウェブメールシステムでは、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 別のフレーム内ではなくウェブメールコンテキスト内にある場合、セレクターが一致する場合、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 メッセージまたは埋め込まれた外部コンテンツから開かれたリンクは、ほとんどのシステムでデフォルトで送信されるリファラーヘッダーのプライベート情報をリークする可能性があります。
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 リファラーヘッダー内の情報の漏洩は、リファラーポリシーを使用して軽減できます（<https://www.w3.org/TR/referrer-policy/>を参照）。
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].
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].
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]は、レート制限、ウイルス対策/スパム対策milter（メールフィルター）、およびその他のテクノロジを含む、侵害されたユーザーアカウントおよびエンドユーザーシステムによって引き起こされる損害を軽減するために、いくつかのメカニズムを使用します。これらのテクノロジーは、クライアント接続に関する情報が多いほどうまく機能します。 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].
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].
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.
ユーザーは、アカウントに存在するデータのサブセットにアクセスする権限のみを持つことができます。許可されていない情報の漏洩を回避するために、このような状況では、サーバーは、ユーザーがアクセスする権限を持っていないデータを、存在していない場合と同様に扱わなければなりません（MUST）。
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が受信トレイと送信済みの2つのメールボックスを持つアカウントを持っているが、ユーザーBとのみ受信トレイを共有しているとします。この場合、ユーザーBがこのアカウントのメールボックスをフェッチすると、サーバーは送信済みメールボックスがそうでなかったかのように動作する必要があります。存在します。同様に、Emailオブジェクトをクエリまたはフェッチする場合、送信されたメールボックスに属しているメッセージは存在しないかのように処理する必要があります。スレッドオブジェクトのフェッチは、ユーザーがアクセスする権限を持つ電子メールオブジェクトのIDのみを返す必要があります。存在しない場合、スレッドは存在しない場合と同様に扱われなければなりません（MUST）。
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.
サーバーが1つのアカウントで2つの同一のメッセージ、または同じMessage-Idヘッダーフィールドを持つ2つのメッセージを持つことを禁止している場合、書き込みアクセス権を持つユーザーは、そのようなメッセージを作成またはインポートしようとして返されたエラーを使用して、すでに存在するかどうかを検出できますアカウントのアクセスできない部分。
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.
アカウントのIdentityオブジェクトのセット（セクション6を参照）により、クライアントは、ユーザーが送信する権限を持つ電子メールアドレスを知ることができます。各メール送信はIDに関連付けられており、サーバーは、メッセージのFromヘッダーフィールドが関連付けられたIDに対応していない送信を拒否する必要があります（SHOULD）。
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.
ユーザーが新しいIdentityオブジェクトを作成しようとする場合、ユーザーが送信元の電子メールアドレスを使用する権限を持っていなければ、サーバーは適切なエラーで拒否する必要があります。
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 MAIL FROMアドレス[RFC5321]は、Fromメッセージヘッダーフィールド[RFC5322]と混同されることがよくあります。通常、ユーザーにはメッセージヘッダーフィールドのアドレスのみが表示されます。これは、強制する主要なアドレスです。ただし、サーバーはMAIL FROMアドレス[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
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
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は「休暇応答」JMAP機能を次のように登録しました。
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キーワードレジストリに2つの変更を加えます。
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.
次に、キーワードが「IMAPのみ」、「JMAPのみ」、「両方」、または「予約済み」に適用されるかどうかを示すスコープ列がテンプレートとレジストリに追加されます。 IMAPキーワードレジストリに既にあるすべてのキーワードは、「両方」の範囲でマークされています。 「予約済み」ステータスを使用して、登録すると混乱する可能性がある名前の今後の登録を防止できます。 「予約済み」の範囲でキーワードを登録すると、登録テンプレートのほとんどのフィールドが省略されます（例については、以下の「$ 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.
これにより、「JMAPのみ」のキーワード「$ draft」が「IMAPおよびJMAPキーワード」レジストリに登録されます。
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.
それは助言的なキーワードですか、それとも自動アクションを引き起こす可能性がありますか：自動。アカウントに\ Drafts特殊用途属性[RFC6154]でマークされたIMAPメールボックスがある場合、このフラグを設定すると、メッセージがそのメールボックスに自動的に表示される場合があります。 「unreadEmails」などの特定のJMAP計算値は、このフラグを変更した結果として変更されます。さらに、メールクライアントは通常、下書きメッセージをビューアウィンドウではなくコンポーザウィンドウに表示します。
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クライアントによって設定されます。下書きメールの1つのモデルでは、「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>
Intended usage: COMMON
使用目的：COMMON
Owner/Change controller: IESG
所有者/変更コントローラ：IESG
This registers the "JMAP-only" keyword "$seen" in the "IMAP and JMAP Keywords" registry.
これにより、「JMAPのみ」のキーワード「$ seen」が「IMAPおよびJMAPキーワード」レジストリに登録されます。
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.
それは助言的なキーワードですか、それとも自動アクションを引き起こす可能性がありますか：助言。ただし、「unreadEmails」などの特定のJMAP計算値は、このフラグを変更した結果として変更されます。
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>
Intended usage: COMMON
使用目的：COMMON
Owner/Change controller: IESG
所有者/変更コントローラ：IESG
This registers the "JMAP-only" keyword "$flagged" in the "IMAP and JMAP Keywords" registry.
これにより、「JMAPのみ」のキーワード「$ flagged」が「IMAPおよびJMAPキーワード」レジストリに登録されます。
Keyword name: $flagged
キーワード名：$ 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.
それは助言的なキーワードですか、それとも自動アクションを引き起こす可能性がありますか：自動。アカウントに\ Flagged特殊用途属性[RFC6154]でマークされたIMAPメールボックスがある場合、このフラグを設定すると、メッセージがそのメールボックスに自動的に表示される場合があります。
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>
Intended usage: COMMON
使用目的：COMMON
Owner/Change controller: IESG
所有者/変更コントローラ：IESG
This registers the "JMAP-only" keyword "$answered" in the "IMAP and JMAP Keywords" registry.
これにより、「JMAPのみ」のキーワード「$ answered」が「IMAPおよびJMAPキーワード」レジストリに登録されます。
Keyword name: $answered
キーワード名：$ 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.
それは助言的なキーワードですか、それとも自動アクションを引き起こす可能性がありますか：助言。
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クライアントは通常、メッセージに返信または回答を送信するときにこれを設定します。 「onSuccessUpdateEmail」引数を使用した「EmailSubmission / set」操作で設定できます。 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>
Intended usage: COMMON
使用目的：COMMON
Owner/Change controller: IESG
所有者/変更コントローラ：IESG
This registers the keyword "$recent" in the "IMAP and JMAP Keywords" registry.
これにより、キーワード「$ recent」が「IMAPおよびJMAPキーワード」レジストリに登録されます。
Keyword name: $recent
キーワード名：$ recent
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>
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 Mailbox Name Attributes"レジストリに "JMAP-only" "inbox"属性を登録します。
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].
The following subsections register several new error codes in the "JMAP Error Codes" registry, as defined in [RFC8620].
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.
説明：メールボックスには、まだ少なくとも1つの子メールボックスがあります。クライアントは、親メールボックスを削除する前にこれらを削除する必要があります。
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.
説明：メールボックスには少なくとも1つのメッセージが割り当てられており、onDestroyRemoveEmails引数はfalseでした。
JMAP Error Code: blobNotFound
JMAPエラーコード：blobNotFound
Intended use: common
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.
説明：オブジェクトで参照されている少なくとも1つの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エラーコード：tooManyMailboxes
Intended use: common
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.
説明：エンベロープの[rcptTo]プロパティ[RFC5321]（提供または生成）には、送信先として有効な電子メールアドレスではない少なくとも1つのrcptTo値が含まれています。
JMAP Error Code: forbiddenMailFrom
JMAPエラーコード：forbiddenMailFrom
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].
説明：サーバーは、ユーザーがこのエンベロープFromアドレス[RFC5321]を使用してメッセージを送信することを許可しません。
JMAP Error Code: forbiddenFrom
JMAPエラーコード：forbiddenFrom
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.
説明：サーバーは、ユーザーが送信するメッセージのFromヘッダーフィールド[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」、World Wide Web Consortium Recommendation 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、「Multipurpose Internet Mail Extensions（MIME）Part One：Format of Internet Message Bodies」、RFC 2045、DOI 10.17487 / RFC2045、1996年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]ムーアK。、「MIME（多目的インターネットメール拡張）パート3：非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。、「Content-ID and Message-ID Uniform Resource Locators」、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、「HTML（MHTML）などの集約ドキュメントのMIMEカプセル化」、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]ニューマン、D。、「Deliver By SMTP Service Extension」、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。、「Simple Mail Transfer Protocol（SMTP）Service Extension for Delivery Status Notifications（DSNs）」、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。、「Enhanced Mail System Status Codes」、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、 "An Extensible Message Format for Delivery Status Notifications"、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。、「Recommendations for Automatic Responses to Electronic Mail」、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 Access Control List（ACL）Extension」、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]メルニコフ、A。、エド。 K. Zeilenga編、「Simple Authentication and Security Layer（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。、編、「PLAIN Simple Authentication and Security Layer（SASL）Mechanism」、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編、「認証用の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 Format for Network Interchange」、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、「A Registry for SMTP Enhanced Mail System Status Codes」、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、「インターネットメッセージアクセスプロトコル-SORTおよびTHREAD拡張機能」、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。、「Simple Mail Transfer Protocol」、RFC 5321、DOI 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。、編、「インターネットメッセージ形式」、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 Keyword Registry」、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 LIST Extension for Special-Use Mailboxes」、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、「Mail for Submission for Mail」、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、「Internationalized Email Headers」、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。、編、Newman、C。、およびA. Melnikov、「Internationalized Delivery Status and Disposition Notifications」、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]ハンセン、T。、エド。およびA. Melnikov編、「Message Disposition Notification」、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]ムーアK.およびC.ニューマン、「廃止予定のクリアテキスト：電子メールの送信とアクセスのためのトランスポート層セキュリティ（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。、編、「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] Gondwana、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、「The JSON Meta Application Protocol」、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：Breaking S / MIMEおよびOpenPGP Email Encryption With Exfiltration Channels」、2018年8月、<https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-poddebniak.pdf>。
[milter] Postfix, "Postfix before-queue Milter support", 2019, <http://www.postfix.org/MILTER_README.html>.
[milter] Postfix、「Postfix before-queue Milter support」、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、編、「ドメインベースのメッセージ認証、レポート、および準拠（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
Authors' Addresses
Neil Jenkins Fastmail PO Box 234, Collins St. West Melbourne, VIC 8007 Australia
Neil Jenkins Fastmail PO Box 234、Collins St. West Melbourne、VIC 8007 Australia
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
クリスニューマンオラクル440 E. Huntington Dr.、Suite 400 Arcadia、CA 91006アメリカ合衆国
Email: chris.newman@oracle.com