[要約] RFC 3501は、IMAPのバージョン4rev1に関する仕様書であり、電子メールの取得と管理を可能にするプロトコルです。このRFCの目的は、クライアントとサーバー間の通信を規定し、メールの効率的な操作とアクセスを提供することです。
Network Working Group M. Crispin
Request for Comments: 3501 University of Washington
Obsoletes: 2060 March 2003
Category: Standards Track
INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1
インターネットメッセージアクセスプロトコル-バージョン4rev1
Status of this Memo
本文書の状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（C）The Internet Society（2003）。全著作権所有。
Abstract
概要
The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev1 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. IMAP4rev1 also provides the capability for an offline client to resynchronize with the server.
インターネットメッセージアクセスプロトコル、バージョン4rev1（IMAP4rev1）を使用すると、クライアントはサーバー上の電子メールメッセージにアクセスして操作できます。 IMAP4rev1では、ローカルフォルダーと機能的に同等の方法でメールボックス（リモートメッセージフォルダー）を操作できます。 IMAP4rev1は、オフラインクライアントがサーバーと再同期する機能も提供します。
IMAP4rev1 includes operations for creating, deleting, and renaming mailboxes, checking for new messages, permanently removing messages, setting and clearing flags, RFC 2822 and RFC 2045 parsing, searching, and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev1 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers.
IMAP4rev1には、メールボックスの作成、削除、名前変更、新しいメッセージの確認、メッセージの完全な削除、フラグの設定とクリア、RFC 2822およびRFC 2045の解析、検索、メッセージ属性、テキスト、およびそれらの一部の選択的フェッチの操作が含まれます。 IMAP4rev1のメッセージには、番号を使用してアクセスします。これらの番号は、メッセージシーケンス番号または一意の識別子のいずれかです。
IMAP4rev1 supports a single server. A mechanism for accessing configuration information to support multiple IMAP4rev1 servers is discussed in RFC 2244.
IMAP4rev1は単一のサーバーをサポートします。複数のIMAP4rev1サーバーをサポートするために構成情報にアクセスするメカニズムは、RFC 2244で説明されています。
IMAP4rev1 does not specify a means of posting mail; this function is handled by a mail transfer protocol such as RFC 2821.
IMAP4rev1はメールの投稿方法を指定していません。この機能は、RFC 2821などのメール転送プロトコルによって処理されます。
Table of Contents
目次
IMAP4rev1 Protocol Specification ................................ 4
1. How to Read This Document ............................... 4
1.1. Organization of This Document ........................... 4
1.2. Conventions Used in This Document ....................... 4
1.3. Special Notes to Implementors ........................... 5
2. Protocol Overview ....................................... 6
2.1. Link Level .............................................. 6
2.2. Commands and Responses .................................. 6
2.2.1. Client Protocol Sender and Server Protocol Receiver ..... 6
2.2.2. Server Protocol Sender and Client Protocol Receiver ..... 7
2.3. Message Attributes ...................................... 8
2.3.1. Message Numbers ......................................... 8
2.3.1.1. Unique Identifier (UID) Message Attribute ....... 8
2.3.1.2. Message Sequence Number Message Attribute ....... 10
2.3.2. Flags Message Attribute ................................. 11
2.3.3. Internal Date Message Attribute ......................... 12
2.3.4. [RFC-2822] Size Message Attribute ....................... 12
2.3.5. Envelope Structure Message Attribute .................... 12
2.3.6. Body Structure Message Attribute ........................ 12
2.4. Message Texts ........................................... 13
3. State and Flow Diagram .................................. 13
3.1. Not Authenticated State ................................. 13
3.2. Authenticated State ..................................... 13
3.3. Selected State .......................................... 13
3.4. Logout State ............................................ 14
4. Data Formats ............................................ 16
4.1. Atom .................................................... 16
4.2. Number .................................................. 16
4.3. String .................................................. 16
4.3.1. 8-bit and Binary Strings ................................ 17
4.4. Parenthesized List ...................................... 17
4.5. NIL ..................................................... 17
5. Operational Considerations .............................. 18
5.1. Mailbox Naming .......................................... 18
5.1.1. Mailbox Hierarchy Naming ................................ 19
5.1.2. Mailbox Namespace Naming Convention ..................... 19
5.1.3. Mailbox International Naming Convention ................. 19
5.2. Mailbox Size and Message Status Updates ................. 21
5.3. Response when no Command in Progress .................... 21
5.4. Autologout Timer ........................................ 22
5.5. Multiple Commands in Progress ........................... 22
6. Client Commands ........................................ 23
6.1. Client Commands - Any State ............................ 24
6.1.1. CAPABILITY Command ..................................... 24
6.1.2. NOOP Command ........................................... 25
6.1.3. LOGOUT Command ......................................... 26
6.2. Client Commands - Not Authenticated State .............. 26
6.2.1. STARTTLS Command ....................................... 27
6.2.2. AUTHENTICATE Command ................................... 28
6.2.3. LOGIN Command .......................................... 30
6.3. Client Commands - Authenticated State .................. 31
6.3.1. SELECT Command ......................................... 32
6.3.2. EXAMINE Command ........................................ 34
6.3.3. CREATE Command ......................................... 34
6.3.4. DELETE Command ......................................... 35
6.3.5. RENAME Command ......................................... 37
6.3.6. SUBSCRIBE Command ...................................... 39
6.3.7. UNSUBSCRIBE Command .................................... 39
6.3.8. LIST Command ........................................... 40
6.3.9. LSUB Command ........................................... 43
6.3.10. STATUS Command ......................................... 44
6.3.11. APPEND Command ......................................... 46
6.4. Client Commands - Selected State ....................... 47
6.4.1. CHECK Command .......................................... 47
6.4.2. CLOSE Command .......................................... 48
6.4.3. EXPUNGE Command ........................................ 49
6.4.4. SEARCH Command ......................................... 49
6.4.5. FETCH Command .......................................... 54
6.4.6. STORE Command .......................................... 58
6.4.7. COPY Command ........................................... 59
6.4.8. UID Command ............................................ 60
6.5. Client Commands - Experimental/Expansion ............... 62
6.5.1. X<atom> Command ........................................ 62
7. Server Responses ....................................... 62
7.1. Server Responses - Status Responses .................... 63
7.1.1. OK Response ............................................ 65
7.1.2. NO Response ............................................ 66
7.1.3. BAD Response ........................................... 66
7.1.4. PREAUTH Response ....................................... 67
7.1.5. BYE Response ........................................... 67
7.2. Server Responses - Server and Mailbox Status ........... 68
7.2.1. CAPABILITY Response .................................... 68
7.2.2. LIST Response .......................................... 69
7.2.3. LSUB Response .......................................... 70
7.2.4 STATUS Response ........................................ 70
7.2.5. SEARCH Response ........................................ 71
7.2.6. FLAGS Response ......................................... 71
7.3. Server Responses - Mailbox Size ........................ 71
7.3.1. EXISTS Response ........................................ 71
7.3.2. RECENT Response ........................................ 72
7.4. Server Responses - Message Status ...................... 72
7.4.1. EXPUNGE Response ....................................... 72
7.4.2. FETCH Response ......................................... 73
7.5. Server Responses - Command Continuation Request ........ 79
8. Sample IMAP4rev1 connection ............................ 80
9. Formal Syntax .......................................... 81
10. Author's Note .......................................... 92
11. Security Considerations ................................ 92
11.1. STARTTLS Security Considerations ....................... 92
11.2. Other Security Considerations .......................... 93
12. IANA Considerations .................................... 94
Appendices ..................................................... 95
A. References ............................................. 95
B. Changes from RFC 2060 .................................. 97
C. Key Word Index ......................................... 103
Author's Address ............................................... 107
Full Copyright Statement ....................................... 108
IMAP4rev1 Protocol Specification
IMAP4rev1プロトコル仕様
This document is written from the point of view of the implementor of an IMAP4rev1 client or server. Beyond the protocol overview in section 2, it is not optimized for someone trying to understand the operation of the protocol. The material in sections 3 through 5 provides the general context and definitions with which IMAP4rev1 operates.
このドキュメントは、IMAP4rev1クライアントまたはサーバーの実装者の観点から書かれています。セクション2のプロトコルの概要を超えて、プロトコルの操作を理解しようとしている人のために最適化されていません。セクション3から5の資料は、IMAP4rev1が動作する一般的なコンテキストと定義を提供します。
Sections 6, 7, and 9 describe the IMAP commands, responses, and syntax, respectively. The relationships among these are such that it is almost impossible to understand any of them separately. In particular, do not attempt to deduce command syntax from the command section alone; instead refer to the Formal Syntax section.
セクション6、7、9では、それぞれIMAPコマンド、応答、および構文について説明します。これらの関係は、それらを個別に理解することはほとんど不可能であるようなものです。特に、コマンドセクションだけからコマンド構文を推測しようとしないでください。代わりに、正式な構文のセクションを参照してください。
"Conventions" are basic principles or procedures. Document conventions are noted in this section.
「規約」は基本的な原則または手順です。このセクションでは、表記規則について説明します。
In examples, "C:" and "S:" indicate lines sent by the client and server respectively.
例では、「C：」と「S：」は、それぞれクライアントとサーバーによって送信された行を示します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「MAY」、および「OPTIONAL」は、次のように解釈されます[キーワード]で説明されています。
The word "can" (not "may") is used to refer to a possible circumstance or situation, as opposed to an optional facility of the protocol.
プロトコルのオプション機能とは対照的に、「できる」という言葉は、「可能性がある」ではなく、可能な状況または状況を指すために使用されます。
"User" is used to refer to a human user, whereas "client" refers to the software being run by the user.
「ユーザー」は人間のユーザーを指し、「クライアント」はユーザーが実行しているソフトウェアを指します。
"Connection" refers to the entire sequence of client/server interaction from the initial establishment of the network connection until its termination.
「接続」とは、ネットワーク接続の最初の確立から終了までのクライアント/サーバー対話のシーケンス全体を指します。
"Session" refers to the sequence of client/server interaction from the time that a mailbox is selected (SELECT or EXAMINE command) until the time that selection ends (SELECT or EXAMINE of another mailbox, CLOSE command, or connection termination).
「セッション」とは、メールボックスが選択されたとき（SELECTまたはEXAMINEコマンド）から選択が終了するとき（別のメールボックスのSELECTまたはEXAMINE、CLOSEコマンド、または接続の終了）までのクライアント/サーバーの対話のシーケンスを指します。
Characters are 7-bit US-ASCII unless otherwise specified. Other character sets are indicated using a "CHARSET", as described in [MIME-IMT] and defined in [CHARSET]. CHARSETs have important additional semantics in addition to defining character set; refer to these documents for more detail.
特に指定のない限り、文字は7ビットUS-ASCIIです。他の文字セットは、[MIME-IMT]で説明され、[CHARSET]で定義されているように、「CHARSET」を使用して示されます。 CHARSETには、文字セットの定義に加えて、重要な追加のセマンティクスがあります。詳細については、これらのドキュメントを参照してください。
There are several protocol conventions in IMAP. These refer to aspects of the specification which are not strictly part of the IMAP protocol, but reflect generally-accepted practice. Implementations need to be aware of these conventions, and avoid conflicts whether or not they implement the convention. For example, "&" may not be used as a hierarchy delimiter since it conflicts with the Mailbox International Naming Convention, and other uses of "&" in mailbox names are impacted as well.
IMAPにはいくつかのプロトコル規約があります。これらは、厳密にはIMAPプロトコルの一部ではないが、一般に認められている慣行を反映している仕様の側面を指します。実装はこれらの規則を認識し、それらが規則を実装するかどうかに関係なく競合を回避する必要があります。たとえば、「＆」はメールボックス国際命名規則と競合するため、階層区切り文字として使用できません。また、メールボックス名での「＆」の他の使用にも影響があります。
Implementors of the IMAP protocol are strongly encouraged to read the IMAP implementation recommendations document [IMAP-IMPLEMENTATION] in conjunction with this document, to help understand the intricacies of this protocol and how best to build an interoperable product.
IMAPプロトコルの実装者は、このドキュメントと併せてIMAP実装推奨ドキュメント[IMAP-IMPLEMENTATION]を読んで、このプロトコルの複雑さと、相互運用可能な製品を構築するための最善の方法を理解することを強くお勧めします。
IMAP4rev1 is designed to be upwards compatible from the [IMAP2] and unpublished IMAP2bis protocols. IMAP4rev1 is largely compatible with the IMAP4 protocol described in RFC 1730; the exception being in certain facilities added in RFC 1730 that proved problematic and were subsequently removed. In the course of the evolution of IMAP4rev1, some aspects in the earlier protocols have become obsolete. Obsolete commands, responses, and data formats which an IMAP4rev1 implementation can encounter when used with an earlier implementation are described in [IMAP-OBSOLETE].
IMAP4rev1は、[IMAP2]および非公開のIMAP2bisプロトコルとの上位互換性を持つように設計されています。 IMAP4rev1は、RFC 1730で説明されているIMAP4プロトコルとほぼ互換性があります。例外は、RFC 1730で追加された特定のファシリティにあり、問題があることが判明したため削除されました。 IMAP4rev1の進化の過程で、以前のプロトコルの一部の側面は廃止されました。以前の実装でIMAP4rev1実装を使用したときに発生する可能性がある廃止されたコマンド、応答、およびデータ形式については、[IMAP-OBSOLETE]で説明されています。
Other compatibility issues with IMAP2bis, the most common variant of the earlier protocol, are discussed in [IMAP-COMPAT]. A full discussion of compatibility issues with rare (and presumed extinct) variants of [IMAP2] is in [IMAP-HISTORICAL]; this document is primarily of historical interest.
以前のプロトコルの最も一般的なバリアントであるIMAP2bisとの他の互換性の問題は、[IMAP-COMPAT]で説明されています。 [IMAP2]のまれな（そして絶滅したと思われる）バリアントとの互換性の問題に関する完全な議論は[IMAP-HISTORICAL]にあります。このドキュメントは、主に歴史的な関心事です。
IMAP was originally developed for the older [RFC-822] standard, and as a consequence several fetch items in IMAP incorporate "RFC822" in their name. With the exception of RFC822.SIZE, there are more modern replacements; for example, the modern version of RFC822.HEADER is BODY.PEEK[HEADER]. In all cases, "RFC822" should be interpreted as a reference to the updated [RFC-2822] standard.
IMAPは、もともとは古い[RFC-822]標準用に開発されたものであり、その結果、IMAPのいくつかのフェッチアイテムの名前には「RFC822」が組み込まれています。 RFC822.SIZEを除いて、より最近の置き換えがあります。たとえば、RFC822.HEADERの最新バージョンはBODY.PEEK [HEADER]です。すべての場合において、「RFC822」は更新された[RFC-2822]標準への参照として解釈されるべきです。
The IMAP4rev1 protocol assumes a reliable data stream such as that provided by TCP. When TCP is used, an IMAP4rev1 server listens on port 143.
IMAP4rev1プロトコルは、TCPによって提供されるような信頼できるデータストリームを想定しています。 TCPを使用する場合、IMAP4rev1サーバーはポート143で待機します。
An IMAP4rev1 connection consists of the establishment of a client/server network connection, an initial greeting from the server, and client/server interactions. These client/server interactions consist of a client command, server data, and a server completion result response.
IMAP4rev1接続は、クライアント/サーバーネットワーク接続の確立、サーバーからの最初の挨拶、およびクライアント/サーバーの相互作用で構成されます。これらのクライアント/サーバー相互作用は、クライアントコマンド、サーバーデータ、およびサーバー完了結果の応答で構成されます。
All interactions transmitted by client and server are in the form of lines, that is, strings that end with a CRLF. The protocol receiver of an IMAP4rev1 client or server is either reading a line, or is reading a sequence of octets with a known count followed by a line.
クライアントとサーバーによって送信されるすべての対話は、行の形式、つまりCRLFで終わる文字列です。 IMAP4rev1クライアントまたはサーバーのプロトコルレシーバーは、行を読み取っているか、既知のカウントとそれに続く行を含むオクテットのシーケンスを読み取っています。
The client command begins an operation. Each client command is prefixed with an identifier (typically a short alphanumeric string, e.g., A0001, A0002, etc.) called a "tag". A different tag is generated by the client for each command.
クライアントコマンドが操作を開始します。各クライアントコマンドの先頭には、「タグ」と呼ばれる識別子（通常は、A0001、A0002などの短い英数字の文字列）が付いています。コマンドごとに異なるタグがクライアントによって生成されます。
Clients MUST follow the syntax outlined in this specification strictly. It is a syntax error to send a command with missing or extraneous spaces or arguments.
クライアントは、この仕様で厳密に説明されている構文に従う必要があります。不足している、または無関係なスペースまたは引数を指定してコマンドを送信すると、構文エラーになります。
There are two cases in which a line from the client does not represent a complete command. In one case, a command argument is quoted with an octet count (see the description of literal in String under Data Formats); in the other case, the command arguments require server feedback (see the AUTHENTICATE command). In either case, the server sends a command continuation request response if it is ready for the octets (if appropriate) and the remainder of the command. This response is prefixed with the token "+".
クライアントからの行が完全なコマンドを表していない場合が2つあります。 1つのケースでは、コマンド引数はオクテットカウントで引用されます（データ形式の文字列のリテラルの説明を参照）。それ以外の場合、コマンド引数にはサーバーフィードバックが必要です（AUTHENTICATEコマンドを参照）。どちらの場合も、オクテット（該当する場合）と残りのコマンドの準備ができている場合、サーバーはコマンド継続要求応答を送信します。この応答には、トークン「+」が前に付けられます。
Note: If instead, the server detected an error in the command, it sends a BAD completion response with a tag matching the command (as described below) to reject the command and prevent the client from sending any more of the command.
注：代わりに、サーバーがコマンドでエラーを検出した場合、サーバーはコマンドに一致するタグを付けてBAD完了応答を送信し（以下で説明）、コマンドを拒否し、クライアントがこれ以上コマンドを送信できないようにします。
It is also possible for the server to send a completion response for some other command (if multiple commands are in progress), or untagged data. In either case, the command continuation request is still pending; the client takes the appropriate action for the response, and reads another response from the server. In all cases, the client MUST send a complete command (including receiving all command continuation request responses and command continuations for the command) before initiating a new command.
サーバーが他のコマンドの完了応答（複数のコマンドが進行中の場合）またはタグなしデータを送信することも可能です。どちらの場合も、コマンド継続要求はまだ保留中です。クライアントは応答に対して適切なアクションを実行し、サーバーから別の応答を読み取ります。すべての場合において、クライアントは新しいコマンドを開始する前に、完全なコマンドを送信する必要があります（すべてのコマンド継続要求応答とコマンドのコマンド継続の受信を含む）。
The protocol receiver of an IMAP4rev1 server reads a command line from the client, parses the command and its arguments, and transmits server data and a server command completion result response.
IMAP4rev1サーバーのプロトコルレシーバーは、クライアントからコマンドラインを読み取り、コマンドとその引数を解析し、サーバーデータとサーバーコマンド完了結果の応答を送信します。
Data transmitted by the server to the client and status responses that do not indicate command completion are prefixed with the token "*", and are called untagged responses.
サーバーからクライアントに送信されるデータと、コマンドの完了を示さないステータス応答には、トークン「*」が前に付けられ、タグなし応答と呼ばれます。
Server data MAY be sent as a result of a client command, or MAY be sent unilaterally by the server. There is no syntactic difference between server data that resulted from a specific command and server data that were sent unilaterally.
サーバーデータは、クライアントコマンドの結果として送信される場合と、サーバーから一方的に送信される場合があります。特定のコマンドからのサーバーデータと一方的に送信されたサーバーデータの間に構文上の違いはありません。
The server completion result response indicates the success or failure of the operation. It is tagged with the same tag as the client command which began the operation. Thus, if more than one command is in progress, the tag in a server completion response identifies the command to which the response applies. There are three possible server completion responses: OK (indicating success), NO (indicating failure), or BAD (indicating a protocol error such as unrecognized command or command syntax error).
サーバーの完了結果の応答は、操作の成功または失敗を示します。操作を開始したクライアントコマンドと同じタグが付けられます。したがって、複数のコマンドが進行中の場合、サーバー完了応答のタグは、応答が適用されるコマンドを識別します。サーバー完了応答には、OK（成功を示す）、NO（失敗を示す）、またはBAD（認識できないコマンドやコマンド構文エラーなどのプロトコルエラーを示す）の3つが考えられます。
Servers SHOULD enforce the syntax outlined in this specification strictly. Any client command with a protocol syntax error, including (but not limited to) missing or extraneous spaces or arguments, SHOULD be rejected, and the client given a BAD server completion response.
サーバーは、この仕様で概説されている構文を厳密に適用する必要があります（SHOULD）。欠落している、または無関係なスペースや引数を含む（ただしこれらに限定されない）プロトコル構文エラーのあるクライアントコマンドはすべて拒否され、クライアントはBADサーバー完了応答を返します。
The protocol receiver of an IMAP4rev1 client reads a response line from the server. It then takes action on the response based upon the first token of the response, which can be a tag, a "*", or a "+".
IMAP4rev1クライアントのプロトコルレシーバーは、サーバーから応答ラインを読み取ります。次に、タグ、「*」、「+」などの応答の最初のトークンに基づいて、応答に対してアクションを実行します。
A client MUST be prepared to accept any server response at all times. This includes server data that was not requested. Server data SHOULD be recorded, so that the client can reference its recorded copy rather than sending a command to the server to request the data. In the case of certain server data, the data MUST be recorded.
クライアントは、常にサーバー応答を受け入れる準備ができていなければなりません。これには、要求されなかったサーバーデータが含まれます。クライアントがサーバーにデータを要求するコマンドを送信するのではなく、記録されたコピーを参照できるように、サーバーデータを記録する必要があります。特定のサーバーデータの場合、データを記録する必要があります。
This topic is discussed in greater detail in the Server Responses section.
このトピックについては、サーバーの応答セクションで詳しく説明します。
In addition to message text, each message has several attributes associated with it. These attributes can be retrieved individually or in conjunction with other attributes or message texts.
メッセージテキストに加えて、各メッセージにはいくつかの属性が関連付けられています。これらの属性は、個別に、または他の属性やメッセージテキストと組み合わせて取得できます。
Messages in IMAP4rev1 are accessed by one of two numbers; the unique identifier or the message sequence number.
IMAP4rev1のメッセージには、2つの番号のいずれかでアクセスします。一意の識別子またはメッセージシーケンス番号。
A 32-bit value assigned to each message, which when used with the unique identifier validity value (see below) forms a 64-bit value that MUST NOT refer to any other message in the mailbox or any subsequent mailbox with the same name forever. Unique identifiers are assigned in a strictly ascending fashion in the mailbox; as each message is added to the mailbox it is assigned a higher UID than the message(s) which were added previously. Unlike message sequence numbers, unique identifiers are not necessarily contiguous.
各メッセージに割り当てられた32ビット値。一意の識別子の有効性値（下記参照）と共に使用すると、64ビット値を形成し、メールボックス内の他のメッセージまたは同じ名前の後続のメールボックスを永久に参照してはなりません。一意の識別子は、メールボックスで厳密に昇順で割り当てられます。各メッセージがメールボックスに追加されると、以前に追加されたメッセージよりも高いUIDが割り当てられます。メッセージシーケンス番号とは異なり、一意の識別子は必ずしも連続していません。
The unique identifier of a message MUST NOT change during the session, and SHOULD NOT change between sessions. Any change of unique identifiers between sessions MUST be detectable using the UIDVALIDITY mechanism discussed below. Persistent unique identifiers are required for a client to resynchronize its state from a previous session with the server (e.g., disconnected or offline access clients); this is discussed further in [IMAP-DISC].
メッセージの一意の識別子はセッション中に変更してはならず（MUST NOT）、セッション間で変更してはなりません（SHOULD NOT）。セッション間の一意の識別子の変更は、以下で説明するUIDVALIDITYメカニズムを使用して検出できる必要があります。クライアントが前のセッションからの状態をサーバーと再同期するには、永続的な一意の識別子が必要です（切断されたクライアントやオフラインアクセスクライアントなど）。これについては、[IMAP-DISC]でさらに説明されています。
Associated with every mailbox are two values which aid in unique identifier handling: the next unique identifier value and the unique identifier validity value.
すべてのメールボックスには、一意の識別子の処理に役立つ2つの値、次の一意の識別子の値と一意の識別子の有効性の値が関連付けられています。
The next unique identifier value is the predicted value that will be assigned to a new message in the mailbox. Unless the unique identifier validity also changes (see below), the next unique identifier value MUST have the following two characteristics. First, the next unique identifier value MUST NOT change unless new messages are added to the mailbox; and second, the next unique identifier value MUST change whenever new messages are added to the mailbox, even if those new messages are subsequently expunged.
次の一意の識別子の値は、メールボックスの新しいメッセージに割り当てられる予測値です。一意の識別子の有効性も変更されない限り（以下を参照）、次の一意の識別子の値は次の2つの特性を持つ必要があります。まず、新しいメッセージがメールボックスに追加されない限り、次の一意の識別子の値は変更してはなりません（MUST NOT）。次に、新しいメッセージが後で消去された場合でも、新しいメッセージがメールボックスに追加されるたびに、次の一意の識別子の値を変更する必要があります。
Note: The next unique identifier value is intended to provide a means for a client to determine whether any messages have been delivered to the mailbox since the previous time it checked this value. It is not intended to provide any guarantee that any message will have this unique identifier. A client can only assume, at the time that it obtains the next unique identifier value, that messages arriving after that time will have a UID greater than or equal to that value.
注：次の一意の識別子の値は、前回この値をチェックしてからメッセージがメールボックスに配信されたかどうかをクライアントが判断する手段を提供することを目的としています。メッセージがこの一意の識別子を持つことを保証するものではありません。クライアントは、次の一意の識別子の値を取得するときに、その時間以降に到着するメッセージのUIDがその値以上であると想定することができます。
The unique identifier validity value is sent in a UIDVALIDITY response code in an OK untagged response at mailbox selection time. If unique identifiers from an earlier session fail to persist in this session, the unique identifier validity value MUST be greater than the one used in the earlier session.
一意の識別子の有効性の値は、メールボックスの選択時に、タグなしのOK応答のUIDVALIDITY応答コードで送信されます。以前のセッションの一意の識別子がこのセッションで保持されない場合、一意の識別子の有効性の値は、以前のセッションで使用されたものよりも大きくなければなりません。
Note: Ideally, unique identifiers SHOULD persist at all times. Although this specification recognizes that failure to persist can be unavoidable in certain server environments, it STRONGLY ENCOURAGES message store implementation techniques that avoid this problem. For example:
注：理想的には、一意の識別子を常に保持する必要があります。この仕様では、特定のサーバー環境では永続化の失敗が避けられない可能性があることを認識していますが、この問題を回避するメッセージストア実装手法を強く推奨しています。例えば：
1) Unique identifiers MUST be strictly ascending in the mailbox at all times. If the physical message store is re-ordered by a non-IMAP agent, this requires that the unique identifiers in the mailbox be regenerated, since the former unique identifiers are no longer strictly ascending as a result of the re-ordering.
1）一意の識別子は、常にメールボックス内で厳密に昇順である必要があります。物理メッセージストアがIMAP以外のエージェントによって並べ替えられる場合、並べ替えの結果として以前の一意の識別子は厳密に昇順ではなくなったため、メールボックス内の一意の識別子を再生成する必要があります。
2) If the message store has no mechanism to store unique identifiers, it must regenerate unique identifiers at each session, and each session must have a unique UIDVALIDITY value.
2）メッセージストアに一意の識別子を格納するメカニズムがない場合、メッセージストアは各セッションで一意の識別子を再生成する必要があり、各セッションには一意のUIDVALIDITY値が必要です。
3) If the mailbox is deleted and a new mailbox with the same name is created at a later date, the server must either keep track of unique identifiers from the previous instance of the mailbox, or it must assign a new UIDVALIDITY value to the new instance of the mailbox. A good UIDVALIDITY value to use in this case is a 32-bit representation of the creation date/time of the mailbox. It is alright to use a constant such as 1, but only if it guaranteed that unique identifiers will never be reused, even in the case of a mailbox being deleted (or renamed) and a new mailbox by the same name created at some future time.
3）メールボックスが削除され、同じ名前の新しいメールボックスが後日作成される場合、サーバーはメールボックスの前のインスタンスからの一意の識別子を追跡するか、新しいUIDVALIDITY値を新しいメールボックスのインスタンス。この場合に使用するのに適したUIDVALIDITY値は、メールボックスの作成日時の32ビット表現です。 1などの定数を使用しても問題ありませんが、メールボックスが削除（または名前変更）され、同じ名前で新しいメールボックスが将来作成される場合でも、一意の識別子が再利用されないことが保証されている場合に限ります。 。
4) The combination of mailbox name, UIDVALIDITY, and UID must refer to a single immutable message on that server forever. In particular, the internal date, [RFC-2822] size, envelope, body structure, and message texts (RFC822, RFC822.HEADER, RFC822.TEXT, and all BODY[...] fetch data items) must never change. This does not include message numbers, nor does it include attributes that can be set by a STORE command (e.g., FLAGS).
4）メールボックス名、UIDVALIDITY、およびUIDの組み合わせは、そのサーバー上の単一の不変メッセージを永久に参照する必要があります。特に、内部日付、[RFC-2822]サイズ、エンベロープ、本文の構造、メッセージテキスト（RFC822、RFC822.HEADER、RFC822.TEXT、およびすべてのBODY [...]フェッチデータアイテム）は決して変更してはなりません。これにはメッセージ番号は含まれません。また、STOREコマンドで設定できる属性（FLAGSなど）も含まれません。
A relative position from 1 to the number of messages in the mailbox. This position MUST be ordered by ascending unique identifier. As each new message is added, it is assigned a message sequence number that is 1 higher than the number of messages in the mailbox before that new message was added.
1からメールボックス内のメッセージ数までの相対位置。この位置は、一意の識別子を昇順に並べる必要があります。新しいメッセージが追加されるたびに、新しいメッセージが追加される前のメールボックス内のメッセージ数よりも1大きいメッセージシーケンス番号が割り当てられます。
Message sequence numbers can be reassigned during the session. For example, when a message is permanently removed (expunged) from the mailbox, the message sequence number for all subsequent messages is decremented. The number of messages in the mailbox is also decremented. Similarly, a new message can be assigned a message sequence number that was once held by some other message prior to an expunge.
メッセージのシーケンス番号は、セッション中に再割り当てできます。たとえば、メッセージがメールボックスから完全に削除（消去）されると、後続のすべてのメッセージのメッセージシーケンス番号が減少します。メールボックス内のメッセージの数も減少します。同様に、新しいメッセージには、消去前に他のメッセージによって保持されていたメッセージシーケンス番号を割り当てることができます。
In addition to accessing messages by relative position in the mailbox, message sequence numbers can be used in mathematical calculations. For example, if an untagged "11 EXISTS" is received, and previously an untagged "8 EXISTS" was received, three new messages have arrived with message sequence numbers of 9, 10, and 11. Another example, if message 287 in a 523 message mailbox has UID 12345, there are exactly 286 messages which have lesser UIDs and 236 messages which have greater UIDs.
メールボックス内の相対位置でメッセージにアクセスすることに加えて、メッセージのシーケンス番号を数学的な計算で使用できます。たとえば、タグなしの「11 EXISTS」を受信し、以前にタグなしの「8 EXISTS」を受信した場合、メッセージシーケンス番号が9、10、および11の3つの新しいメッセージが到着しました。メッセージメールボックスのUIDは12345です。UIDが少ない286のメッセージと、UIDが大きい236のメッセージがあります。
A list of zero or more named tokens associated with the message. A flag is set by its addition to this list, and is cleared by its removal. There are two types of flags in IMAP4rev1. A flag of either type can be permanent or session-only.
メッセージに関連付けられた0個以上の名前付きトークンのリスト。フラグは、このリストへの追加によって設定され、削除によってクリアされます。 IMAP4rev1には2種類のフラグがあります。どちらのタイプのフラグも、永続的またはセッションのみにすることができます。
A system flag is a flag name that is pre-defined in this specification. All system flags begin with "\". Certain system flags (\Deleted and \Seen) have special semantics described elsewhere. The currently-defined system flags are:
システムフラグは、この仕様で事前定義されているフラグ名です。すべてのシステムフラグは「\」で始まります。特定のシステムフラグ（\ Deletedおよび\ Seen）には、他の場所で説明されている特別なセマンティクスがあります。現在定義されているシステムフラグは次のとおりです。
\Seen Message has been read
\メッセージを読みました
\Answered Message has been answered
\回答済みのメッセージに回答しました
\Flagged Message is "flagged" for urgent/special attention
\フラグ付きメッセージは緊急/特別な注意のために「フラグが立てられています」
\Deleted Message is "deleted" for removal by later EXPUNGE
\削除されたメッセージは、後のEXPUNGEによる削除のために「削除」されます
\Draft Message has not completed composition (marked as a draft).
\ドラフトメッセージは作成が完了していません（ドラフトとしてマークされています）。
\Recent Message is "recently" arrived in this mailbox. This session is the first session to have been notified about this message; if the session is read-write, subsequent sessions will not see \Recent set for this message. This flag can not be altered by the client.
\最近のメッセージはこのメールボックスに「最近」到着しました。このセッションは、このメッセージについて通知された最初のセッションです。セッションが読み取り/書き込みの場合、以降のセッションでは、このメッセージに設定された\ Recentは表示されません。このフラグはクライアントが変更することはできません。
If it is not possible to determine whether or not this session is the first session to be notified about a message, then that message SHOULD be considered recent.
このセッションがメッセージについて通知される最初のセッションであるかどうかを判断することができない場合、そのメッセージは最近のものと見なされるべきです。
If multiple connections have the same mailbox selected simultaneously, it is undefined which of these connections will see newly-arrived messages with \Recent set and which will see it without \Recent set.
複数の接続で同じメールボックスが同時に選択されている場合、これらの接続のうち、\ Recentが設定された状態で新しく到着したメッセージを表示する接続と、\ Recentを設定せずに表示する接続は未定義です。
A keyword is defined by the server implementation. Keywords do not begin with "\". Servers MAY permit the client to define new keywords in the mailbox (see the description of the PERMANENTFLAGS response code for more information).
キーワードはサーバーの実装によって定義されます。キーワードの先頭が「\」ではありません。サーバーはクライアントがメールボックスに新しいキーワードを定義することを許可してもよい（詳細についてはPERMANENTFLAGS応答コードの説明を参照）。
A flag can be permanent or session-only on a per-flag basis. Permanent flags are those which the client can add or remove from the message flags permanently; that is, concurrent and subsequent sessions will see any change in permanent flags. Changes to session flags are valid only in that session.
フラグは、フラグごとに永続的またはセッションのみにすることができます。永続的なフラグは、クライアントがメッセージフラグに対して永続的に追加または削除できるフラグです。つまり、同時および後続のセッションでは、永続的なフラグが変更されます。セッションフラグの変更は、そのセッションでのみ有効です。
Note: The \Recent system flag is a special case of a session flag. \Recent can not be used as an argument in a STORE or APPEND command, and thus can not be changed at all.
注：\ Recentシステムフラグは、セッションフラグの特殊なケースです。 \ Recentは、STOREまたはAPPENDコマンドの引数として使用できないため、まったく変更できません。
The internal date and time of the message on the server. This is not the date and time in the [RFC-2822] header, but rather a date and time which reflects when the message was received. In the case of messages delivered via [SMTP], this SHOULD be the date and time of final delivery of the message as defined by [SMTP]. In the case of messages delivered by the IMAP4rev1 COPY command, this SHOULD be the internal date and time of the source message. In the case of messages delivered by the IMAP4rev1 APPEND command, this SHOULD be the date and time as specified in the APPEND command description. All other cases are implementation defined.
サーバー上のメッセージの内部日時。これは[RFC-2822]ヘッダーの日時ではなく、メッセージが受信された日時を反映する日時です。 [SMTP]を介して配信されたメッセージの場合、これは[SMTP]で定義されているメッセージの最終配信の日付と時刻である必要があります（SHOULD）。 IMAP4rev1 COPYコマンドによって配信されたメッセージの場合、これはソースメッセージの内部の日付と時刻である必要があります（SHOULD）。 IMAP4rev1 APPENDコマンドによって配信されたメッセージの場合、これはAPPENDコマンドの説明で指定されている日付と時刻にする必要があります（SHOULD）。他のすべてのケースは実装で定義されます。
The number of octets in the message, as expressed in [RFC-2822] format.
[RFC-2822]形式で表される、メッセージ内のオクテットの数。
A parsed representation of the [RFC-2822] header of the message. Note that the IMAP Envelope structure is not the same as an [SMTP] envelope.
メッセージの[RFC-2822]ヘッダーの解析された表現。 IMAPエンベロープ構造は[SMTP]エンベロープと同じではないことに注意してください。
A parsed representation of the [MIME-IMB] body structure information of the message.
メッセージの[MIME-IMB]ボディ構造情報の解析された表現。
In addition to being able to fetch the full [RFC-2822] text of a message, IMAP4rev1 permits the fetching of portions of the full message text. Specifically, it is possible to fetch the [RFC-2822] message header, [RFC-2822] message body, a [MIME-IMB] body part, or a [MIME-IMB] header.
メッセージの[RFC-2822]テキスト全体をフェッチできることに加えて、IMAP4rev1ではメッセージテキスト全体の一部をフェッチできます。具体的には、[RFC-2822]メッセージヘッダー、[RFC-2822]メッセージボディ、[MIME-IMB]ボディパーツ、または[MIME-IMB]ヘッダーをフェッチできます。
Once the connection between client and server is established, an IMAP4rev1 connection is in one of four states. The initial state is identified in the server greeting. Most commands are only valid in certain states. It is a protocol error for the client to attempt a command while the connection is in an inappropriate state, and the server will respond with a BAD or NO (depending upon server implementation) command completion result.
クライアントとサーバー間の接続が確立されると、IMAP4rev1接続は4つの状態のいずれかになります。初期状態は、サーバーグリーティングで識別されます。ほとんどのコマンドは、特定の状態でのみ有効です。接続が不適切な状態のときにクライアントがコマンドを試行するのはプロトコルエラーであり、サーバーはBADまたはNO（サーバーの実装に応じて）コマンドの完了結果を返します。
In the not authenticated state, the client MUST supply authentication credentials before most commands will be permitted. This state is entered when a connection starts unless the connection has been pre-authenticated.
認証されていない状態では、ほとんどのコマンドが許可される前に、クライアントは認証資格情報を提供する必要があります。接続が事前認証されていない限り、接続が開始すると、この状態になります。
In the authenticated state, the client is authenticated and MUST select a mailbox to access before commands that affect messages will be permitted. This state is entered when a pre-authenticated connection starts, when acceptable authentication credentials have been provided, after an error in selecting a mailbox, or after a successful CLOSE command.
認証された状態では、クライアントは認証されており、メッセージに影響を与えるコマンドが許可される前に、アクセスするメールボックスを選択する必要があります。この状態に入るのは、事前認証済みの接続が開始されたとき、受け入れ可能な認証資格情報が提供されたとき、メールボックスの選択エラー、またはCLOSEコマンドが成功した後です。
In a selected state, a mailbox has been selected to access. This state is entered when a mailbox has been successfully selected.
選択状態では、アクセスするメールボックスが選択されています。メールボックスが正常に選択されると、この状態になります。
In the logout state, the connection is being terminated. This state can be entered as a result of a client request (via the LOGOUT command) or by unilateral action on the part of either the client or server.
ログアウト状態では、接続が終了しています。この状態は、（LOGOUTコマンドを介した）クライアント要求の結果として、またはクライアントまたはサーバー側の一方的なアクションによって開始できます。
If the client requests the logout state, the server MUST send an untagged BYE response and a tagged OK response to the LOGOUT command before the server closes the connection; and the client MUST read the tagged OK response to the LOGOUT command before the client closes the connection.
クライアントがログアウト状態を要求する場合、サーバーは接続を閉じる前に、タグなしのBYE応答とタグ付きのOK応答をLOGOUTコマンドに送信する必要があります。クライアントは、クライアントが接続を閉じる前に、LOGOUTコマンドに対するタグ付きのOK応答を読み取る必要があります。
A server MUST NOT unilaterally close the connection without sending an untagged BYE response that contains the reason for having done so. A client SHOULD NOT unilaterally close the connection, and instead SHOULD issue a LOGOUT command. If the server detects that the client has unilaterally closed the connection, the server MAY omit the untagged BYE response and simply close its connection.
サーバーは、そうした理由を含むタグなしBYE応答を送信せずに、一方的に接続を閉じてはなりません（MUST NOT）。クライアントは一方的に接続を閉じるべきではなく（SHOULD NOT）、代わりにLOGOUTコマンドを発行する必要があります（SHOULD）。クライアントが一方的に接続を閉じたことをサーバーが検出した場合、サーバーはタグなしBYE応答を省略して、単にその接続を閉じてもよい（MAY）。
+----------------------+
|connection established|
+----------------------+
||
\/
+--------------------------------------+
| server greeting |
+--------------------------------------+
|| (1) || (2) || (3)
\/ || ||
+-----------------+ || ||
|Not Authenticated| || ||
+-----------------+ || ||
|| (7) || (4) || ||
|| \/ \/ ||
|| +----------------+ ||
|| | Authenticated |<=++ ||
|| +----------------+ || ||
|| || (7) || (5) || (6) ||
|| || \/ || ||
|| || +--------+ || ||
|| || |Selected|==++ ||
|| || +--------+ ||
|| || || (7) ||
\/ \/ \/ \/
+--------------------------------------+
| Logout |
+--------------------------------------+
||
\/
+-------------------------------+
|both sides close the connection|
+-------------------------------+
(1) connection without pre-authentication (OK greeting) (2) pre-authenticated connection (PREAUTH greeting) (3) rejected connection (BYE greeting) (4) successful LOGIN or AUTHENTICATE command (5) successful SELECT or EXAMINE command (6) CLOSE command, or failed SELECT or EXAMINE command (7) LOGOUT command, server shutdown, or connection closed
（1）事前認証なしの接続（OKグリーティング）（2）事前認証済み接続（PREAUTHグリーティング）（3）接続拒否（BYEグリーティング）（4）LOGINまたはAUTHENTICATEコマンドの成功（5）SELECTまたはEXAMINEコマンドの成功（6） ）CLOSEコマンド、または失敗したSELECTまたはEXAMINEコマンド（7）LOGOUTコマンド、サーバーのシャットダウン、または接続のクローズ
IMAP4rev1 uses textual commands and responses. Data in IMAP4rev1 can be in one of several forms: atom, number, string, parenthesized list, or NIL. Note that a particular data item may take more than one form; for example, a data item defined as using "astring" syntax may be either an atom or a string.
IMAP4rev1は、テキストコマンドと応答を使用します。 IMAP4rev1のデータは、アトム、数値、文字列、括弧付きリスト、またはNILのいずれかの形式になります。特定のデータ項目は複数の形式をとることがあることに注意してください。たとえば、「astring」構文を使用するように定義されたデータ項目は、アトムまたは文字列のいずれかです。
An atom consists of one or more non-special characters.
アトムは、1つ以上の非特殊文字で構成されています。
A number consists of one or more digit characters, and represents a numeric value.
数値は1つ以上の数字で構成され、数値を表します。
A string is in one of two forms: either literal or quoted string. The literal form is the general form of string. The quoted string form is an alternative that avoids the overhead of processing a literal at the cost of limitations of characters which may be used.
文字列は、リテラル文字列または引用符付き文字列の2つの形式のいずれかです。リテラル形式は、文字列の一般的な形式です。引用符付きの文字列形式は、使用できる文字の制限を犠牲にしてリテラルを処理するオーバーヘッドを回避する代替手段です。
A literal is a sequence of zero or more octets (including CR and LF), prefix-quoted with an octet count in the form of an open brace ("{"), the number of octets, close brace ("}"), and CRLF. In the case of literals transmitted from server to client, the CRLF is immediately followed by the octet data. In the case of literals transmitted from client to server, the client MUST wait to receive a command continuation request (described later in this document) before sending the octet data (and the remainder of the command).
リテラルは、0個以上のオクテット（CRとLFを含む）のシーケンスであり、左中括弧（ "{"）、オクテットの数、右中括弧（ "}"）の形式のオクテットカウントでプレフィックス引用されます。およびCRLF。サーバーからクライアントに送信されるリテラルの場合、CRLFの直後にオクテットデータが続きます。リテラルがクライアントからサーバーに送信される場合、クライアントはオクテットデータ（およびコマンドの残りの部分）を送信する前に、コマンド継続要求（このドキュメントで後述）の受信を待機する必要があります。
A quoted string is a sequence of zero or more 7-bit characters, excluding CR and LF, with double quote (<">) characters at each end.
引用符で囲まれた文字列は、CRおよびLFを除く0個以上の7ビット文字のシーケンスであり、両端に二重引用符（<">）文字が付いています。
The empty string is represented as either "" (a quoted string with zero characters between double quotes) or as {0} followed by CRLF (a literal with an octet count of 0).
空の文字列は、 ""（二重引用符の間にゼロ文字を含む引用符付き文字列）または{0}の後にCRLF（オクテットカウントが0のリテラル）として表されます。
Note: Even if the octet count is 0, a client transmitting a literal MUST wait to receive a command continuation request.
注：オクテットカウントが0の場合でも、リテラルを送信するクライアントは、コマンド継続要求の受信を待機する必要があります。
8-bit textual and binary mail is supported through the use of a [MIME-IMB] content transfer encoding. IMAP4rev1 implementations MAY transmit 8-bit or multi-octet characters in literals, but SHOULD do so only when the [CHARSET] is identified.
[MIME-IMB]コンテンツ転送エンコーディングの使用により、8ビットのテキストおよびバイナリメールがサポートされます。 IMAP4rev1実装は、リテラルで8ビットまたはマルチオクテット文字を送信できますが、[CHARSET]が識別されている場合にのみ送信する必要があります。
Although a BINARY body encoding is defined, unencoded binary strings are not permitted. A "binary string" is any string with NUL characters. Implementations MUST encode binary data into a textual form, such as BASE64, before transmitting the data. A string with an excessive amount of CTL characters MAY also be considered to be binary.
BINARYボディエンコーディングが定義されていますが、エンコードされていないバイナリ文字列は許可されていません。 「バイナリ文字列」とは、NUL文字を含む任意の文字列です。実装では、データを送信する前に、バイナリデータをBASE64などのテキスト形式にエンコードする必要があります。 CTL文字が多すぎる文字列もバイナリと見なされる場合があります。
Data structures are represented as a "parenthesized list"; a sequence of data items, delimited by space, and bounded at each end by parentheses. A parenthesized list can contain other parenthesized lists, using multiple levels of parentheses to indicate nesting.
データ構造は「括弧で囲まれたリスト」として表されます。スペースで区切られ、括弧で両端が区切られた一連のデータ項目。括弧で囲まれたリストには、複数のレベルの括弧を使用してネストを示す他の括弧で囲まれたリストを含めることができます。
The empty list is represented as () -- a parenthesized list with no members.
空のリストは()として表されます-メンバーのない括弧付きリスト。
The special form "NIL" represents the non-existence of a particular data item that is represented as a string or parenthesized list, as distinct from the empty string "" or the empty parenthesized list ().
特別な形式「NIL」は、空の文字列「」または空の括弧付きリスト()とは異なり、文字列または括弧付きリストとして表される特定のデータ項目の非存在を表します。
Note: NIL is never used for any data item which takes the form of an atom. For example, a mailbox name of "NIL" is a mailbox named NIL as opposed to a non-existent mailbox name. This is because mailbox uses "astring" syntax which is an atom or a string. Conversely, an addr-name of NIL is a non-existent personal name, because addr-name uses "nstring" syntax which is NIL or a string, but never an atom.
注：NILは、アトムの形をとるデータ項目には決して使用されません。たとえば、「NIL」というメールボックス名は、存在しないメールボックス名ではなく、NILという名前のメールボックスです。これは、メールボックスがアトムまたは文字列である「astring」構文を使用するためです。逆に、addr-nameはNILまたは文字列であるがアトムではない「nstring」構文を使用するため、NILのaddr-nameは存在しない個人名です。
The following rules are listed here to ensure that all IMAP4rev1 implementations interoperate properly.
次のルールは、すべてのIMAP4rev1実装が適切に相互運用できるようにするためにここにリストされています。
Mailbox names are 7-bit. Client implementations MUST NOT attempt to create 8-bit mailbox names, and SHOULD interpret any 8-bit mailbox names returned by LIST or LSUB as UTF-8. Server implementations SHOULD prohibit the creation of 8-bit mailbox names, and SHOULD NOT return 8-bit mailbox names in LIST or LSUB. See section 5.1.3 for more information on how to represent non-ASCII mailbox names.
メールボックス名は7ビットです。クライアントの実装は、8ビットのメールボックス名の作成を試みてはならず（MUST NOT）、LISTまたはLSUBから返された8ビットのメールボックス名をUTF-8として解釈する必要があります（SHOULD）。サーバーの実装では、8ビットのメールボックス名の作成を禁止する必要があり（SHOULD）、LISTまたはLSUBで8ビットのメールボックス名を返さないでください（SHOULD NOT）。非ASCIIメールボックス名を表す方法の詳細については、セクション5.1.3を参照してください。
Note: 8-bit mailbox names were undefined in earlier versions of this protocol. Some sites used a local 8-bit character set to represent non-ASCII mailbox names. Such usage is not interoperable, and is now formally deprecated.
注：このプロトコルの以前のバージョンでは、8ビットのメールボックス名は定義されていませんでした。一部のサイトでは、ASCII以外のメールボックス名を表すためにローカルの8ビット文字セットを使用していました。このような使用法は相互運用性がなく、正式に廃止されました。
The case-insensitive mailbox name INBOX is a special name reserved to mean "the primary mailbox for this user on this server". The interpretation of all other names is implementation-dependent.
大文字と小文字を区別しないメールボックス名INBOXは、「このサーバー上のこのユーザーのプライマリメールボックス」を意味するように予約されている特別な名前です。他のすべての名前の解釈は実装に依存します。
In particular, this specification takes no position on case sensitivity in non-INBOX mailbox names. Some server implementations are fully case-sensitive; others preserve case of a newly-created name but otherwise are case-insensitive; and yet others coerce names to a particular case. Client implementations MUST interact with any of these. If a server implementation interprets non-INBOX mailbox names as case-insensitive, it MUST treat names using the international naming convention specially as described in section 5.1.3.
特に、この仕様では、INBOX以外のメールボックス名の大文字と小文字の区別については考慮されていません。一部のサーバー実装では、大文字と小文字が完全に区別されます。新しく作成された名前の大文字と小文字を保持するものもありますが、それ以外は大文字と小文字を区別しません。さらに、特定のケースに名前を強制する人もいます。クライアント実装は、これらのいずれかと対話する必要があります。サーバーの実装がINBOX以外のメールボックス名を大文字と小文字を区別しないものとして解釈する場合、セクション5.1.3で説明されているように、特別に国際命名規則を使用して名前を処理する必要があります。
There are certain client considerations when creating a new mailbox name:
新しいメールボックス名を作成する場合、クライアントに関する特定の考慮事項があります。
1) Any character which is one of the atom-specials (see the Formal Syntax) will require that the mailbox name be represented as a quoted string or literal.
1）アトム特殊文字（正式な構文を参照）のいずれかである文字には、メールボックス名を引用符付きの文字列またはリテラルとして表す必要があります。
2) CTL and other non-graphic characters are difficult to represent in a user interface and are best avoided.
2）CTLおよびその他の非グラフィック文字は、ユーザーインターフェイスで表現するのが難しく、回避するのが最善です。
3) Although the list-wildcard characters ("%" and "*") are valid in a mailbox name, it is difficult to use such mailbox names with the LIST and LSUB commands due to the conflict with wildcard interpretation.
3）リストワイルドカード文字（ "％"および "*"）はメールボックス名で有効ですが、ワイルドカードの解釈との競合により、LISTおよびLSUBコマンドでそのようなメールボックス名を使用することは困難です。
4) Usually, a character (determined by the server implementation) is reserved to delimit levels of hierarchy.
4）通常、（サーバーの実装によって決定される）文字は、階層のレベルを区切るために予約されています。
5) Two characters, "#" and "&", have meanings by convention, and should be avoided except when used in that convention.
5） "＃"と "＆"の2つの文字は、慣例により意味があり、その慣例で使用されている場合を除き、避ける必要があります。
If it is desired to export hierarchical mailbox names, mailbox names MUST be left-to-right hierarchical using a single character to separate levels of hierarchy. The same hierarchy separator character is used for all levels of hierarchy within a single name.
階層型メールボックス名をエクスポートする必要がある場合、メールボックス名は、階層のレベルを区切るために単一の文字を使用して、左から右の階層でなければなりません。単一の名前内の階層のすべてのレベルに同じ階層区切り文字が使用されています。
By convention, the first hierarchical element of any mailbox name which begins with "#" identifies the "namespace" of the remainder of the name. This makes it possible to disambiguate between different types of mailbox stores, each of which have their own namespaces.
慣例により、「＃」で始まるメールボックス名の最初の階層要素は、残りの名前の「名前空間」を識別します。これにより、それぞれが独自の名前空間を持つ異なるタイプのメールボックスストアを明確にすることができます。
For example, implementations which offer access to USENET newsgroups MAY use the "#news" namespace to partition the USENET newsgroup namespace from that of other mailboxes. Thus, the comp.mail.misc newsgroup would have a mailbox name of "#news.comp.mail.misc", and the name "comp.mail.misc" can refer to a different object (e.g., a user's private mailbox).
たとえば、USENETニュースグループへのアクセスを提供する実装は、「＃news」名前空間を使用して、他のメールボックスの名前空間からUSENETニュースグループの名前空間を分割できます。したがって、comp.mail.miscニュースグループのメールボックス名は "＃news.comp.mail.misc"となり、 "comp.mail.misc"という名前は別のオブジェクト（ユーザーのプライベートメールボックスなど）を参照できます。 。
By convention, international mailbox names in IMAP4rev1 are specified using a modified version of the UTF-7 encoding described in [UTF-7]. Modified UTF-7 may also be usable in servers that implement an earlier version of this protocol.
慣例により、IMAP4rev1の国際メールボックス名は、[UTF-7]で説明されているUTF-7エンコーディングの修正バージョンを使用して指定されます。変更されたUTF-7は、このプロトコルの以前のバージョンを実装するサーバーでも使用できる場合があります。
In modified UTF-7, printable US-ASCII characters, except for "&", represent themselves; that is, characters with octet values 0x20-0x25 and 0x27-0x7e. The character "&" (0x26) is represented by the two-octet sequence "&-".
変更されたUTF-7では、「＆」を除く印刷可能なUS-ASCII文字はそれ自体を表します。つまり、オクテット値が0x20-0x25および0x27-0x7eの文字です。文字「＆」（0x26）は、2オクテットのシーケンス「＆-」で表されます。
All other characters (octet values 0x00-0x1f and 0x7f-0xff) are represented in modified BASE64, with a further modification from [UTF-7] that "," is used instead of "/". Modified BASE64 MUST NOT be used to represent any printing US-ASCII character which can represent itself.
他のすべての文字（オクテット値0x00-0x1fおよび0x7f-0xff）は変更されたBASE64で表され、[/]の代わりに[、]が使用されるように[UTF-7]からさらに変更されています。変更されたBASE64は、それ自体を表すことができる印刷US-ASCII文字を表すために使用してはなりません（MUST NOT）。
"&" is used to shift to modified BASE64 and "-" to shift back to US-ASCII. There is no implicit shift from BASE64 to US-ASCII, and null shifts ("-&" while in BASE64; note that "&-" while in US-ASCII means "&") are not permitted. However, all names start in US-ASCII, and MUST end in US-ASCII; that is, a name that ends with a non-ASCII ISO-10646 character MUST end with a "-").
「＆」は変更されたBASE64に移行するために使用され、「-」はUS-ASCIIに移行するために使用されます。 BASE64からUS-ASCIIへの暗黙のシフトはありません。ヌルシフト（BASE64での「-＆」、US-ASCIIでの「＆-」は「＆」を意味することに注意）は許可されていません。ただし、すべての名前はUS-ASCIIで始まり、US-ASCIIで終わる必要があります。つまり、ASCII以外のISO-10646文字で終わる名前は、「-」で終わる必要があります）。
The purpose of these modifications is to correct the following problems with UTF-7:
これらの変更の目的は、UTF-7に関する以下の問題を修正することです。
1) UTF-7 uses the "+" character for shifting; this conflicts with the common use of "+" in mailbox names, in particular USENET newsgroup names.
1）UTF-7はシフトに「+」文字を使用します。これは、メールボックス名、特にUSENETニュースグループ名での「+」の一般的な使用と競合します。
2) UTF-7's encoding is BASE64 which uses the "/" character; this conflicts with the use of "/" as a popular hierarchy delimiter.
2）UTF-7のエンコーディングは「/」文字を使用するBASE64です。これは、一般的な階層区切り文字としての「/」の使用と競合します。
3) UTF-7 prohibits the unencoded usage of "\"; this conflicts with the use of "\" as a popular hierarchy delimiter.
3）UTF-7は、「\」のエンコードされていない使用を禁止します。これは、一般的な階層区切り文字としての「\」の使用と競合します。
4) UTF-7 prohibits the unencoded usage of "~"; this conflicts with the use of "~" in some servers as a home directory indicator.
4）UTF-7は、エンコードされていない「〜」の使用を禁止します。これは、一部のサーバーでのホームディレクトリインジケータとしての「〜」の使用と競合します。
5) UTF-7 permits multiple alternate forms to represent the same string; in particular, printable US-ASCII characters can be represented in encoded form.
5）UTF-7では、複数の代替形式で同じ文字列を表すことができます。特に、印刷可能なUS-ASCII文字は、エンコードされた形式で表すことができます。
Although modified UTF-7 is a convention, it establishes certain requirements on server handling of any mailbox name with an embedded "&" character. In particular, server implementations MUST preserve the exact form of the modified BASE64 portion of a modified UTF-7 name and treat that text as case-sensitive, even if names are otherwise case-insensitive or case-folded.
変更されたUTF-7は慣例ですが、 "＆"文字が埋め込まれたメールボックス名のサーバー処理に関する特定の要件を確立します。特に、サーバーの実装は、変更されたUTF-7名の変更されたBASE64部分の正確な形式を保持し、名前が大文字と小文字を区別しない、または折りたたまれている場合でも、そのテキストを大文字と小文字を区別するものとして扱う必要があります。
Server implementations SHOULD verify that any mailbox name with an embedded "&" character, used as an argument to CREATE, is: in the correctly modified UTF-7 syntax, has no superfluous shifts, and has no encoding in modified BASE64 of any printing US-ASCII character which can represent itself. However, client implementations MUST NOT depend upon the server doing this, and SHOULD NOT attempt to create a mailbox name with an embedded "&" character unless it complies with the modified UTF-7 syntax.
サーバーの実装は、「＆」文字が埋め込まれたメールボックス名がCREATEへの引数として使用されていることを確認する必要があります。正しく変更されたUTF-7構文では、余分なシフトはなく、印刷されたUSの変更されたBASE64にはエンコードがありません。 -自分自身を表すことができるASCII文字。ただし、クライアントの実装はこれを行うサーバーに依存してはならず（MUST NOT）、変更されたUTF-7構文に準拠していない限り、「＆」文字が埋め込まれたメールボックス名の作成を試みるべきではありません（SHOULD NOT）。
Server implementations which export a mail store that does not follow the modified UTF-7 convention MUST convert to modified UTF-7 any mailbox name that contains either non-ASCII characters or the "&" character.
変更されたUTF-7規則に従わないメールストアをエクスポートするサーバー実装は、非ASCII文字または「＆」文字のいずれかを含むメールボックス名を変更されたUTF-7に変換する必要があります。
For example, here is a mailbox name which mixes English,
Chinese, and Japanese text:
~peter/mail/&U,BTFw-/&ZeVnLIqe-
For example, the string "&Jjo!" is not a valid mailbox name because it does not contain a shift to US-ASCII before the "!". The correct form is "&Jjo-!". The string "&U,BTFw-&ZeVnLIqe-" is not permitted because it contains a superfluous shift. The correct form is "&U,BTF2XlZyyKng-".
たとえば、文字列「＆Jjo！」 「！」の前にUS-ASCIIへのシフトが含まれていないため、は有効なメールボックス名ではありません。正しい形式は「＆Jjo-！」です。文字列 "＆U、BTFw-＆ZeVnLIqe-"は、余分なシフトが含まれているため許可されません。正しい形式は「＆U、BTF2XlZyyKng-」です。
At any time, a server can send data that the client did not request. Sometimes, such behavior is REQUIRED. For example, agents other than the server MAY add messages to the mailbox (e.g., new message delivery), change the flags of the messages in the mailbox (e.g., simultaneous access to the same mailbox by multiple agents), or even remove messages from the mailbox. A server MUST send mailbox size updates automatically if a mailbox size change is observed during the processing of a command. A server SHOULD send message flag updates automatically, without requiring the client to request such updates explicitly.
サーバーはいつでも、クライアントが要求していないデータを送信できます。場合によっては、そのような動作が必要になります。たとえば、サーバー以外のエージェントは、メールボックスにメッセージを追加したり（たとえば、新しいメッセージ配信）、メールボックス内のメッセージのフラグを変更したり（たとえば、複数のエージェントによる同じメールボックスへの同時アクセス）、またはメールボックス。コマンドの処理中にメールボックスサイズの変更が観察された場合、サーバーはメールボックスサイズの更新を自動的に送信する必要があります。サーバーは、クライアントが明示的にそのような更新を要求する必要なく、メッセージフラグの更新を自動的に送信する必要があります。
Special rules exist for server notification of a client about the removal of messages to prevent synchronization errors; see the description of the EXPUNGE response for more detail. In particular, it is NOT permitted to send an EXISTS response that would reduce the number of messages in the mailbox; only the EXPUNGE response can do this.
同期エラーを防ぐために、メッセージの削除に関するクライアントへのサーバー通知には特別なルールがあります。詳細については、EXPUNGE応答の説明を参照してください。特に、メールボックス内のメッセージ数を減らすEXISTS応答の送信は許可されていません。 EXPUNGE応答のみがこれを行うことができます。
Regardless of what implementation decisions a client makes on remembering data from the server, a client implementation MUST record mailbox size updates. It MUST NOT assume that any command after the initial mailbox selection will return the size of the mailbox.
クライアントがサーバーからのデータを記憶する際にどのような実装決定を行うかに関係なく、クライアント実装はメールボックスサイズの更新を記録する必要があります。最初のメールボックス選択後のコマンドがメールボックスのサイズを返すと想定してはいけません。
Server implementations are permitted to send an untagged response (except for EXPUNGE) while there is no command in progress. Server implementations that send such responses MUST deal with flow control considerations. Specifically, they MUST either (1) verify that the size of the data does not exceed the underlying transport's available window size, or (2) use non-blocking writes.
サーバーの実装は、進行中のコマンドがない間は、タグ付けされていない応答（EXPUNGEを除く）を送信できます。このような応答を送信するサーバー実装は、フロー制御の考慮事項に対処する必要があります。具体的には、（1）データのサイズが基になるトランスポートの使用可能なウィンドウサイズを超えていないことを確認するか、（2）非ブロッキング書き込みを使用する必要があります。
If a server has an inactivity autologout timer, the duration of that timer MUST be at least 30 minutes. The receipt of ANY command from the client during that interval SHOULD suffice to reset the autologout timer.
サーバーに非アクティブな自動ログアウトタイマーがある場合、そのタイマーの持続時間は少なくとも30分である必要があります。自動ログアウトタイマーをリセットするには、その間隔中にクライアントからANYコマンドを受信するだけで十分です（SHOULD）。
The client MAY send another command without waiting for the completion result response of a command, subject to ambiguity rules (see below) and flow control constraints on the underlying data stream. Similarly, a server MAY begin processing another command before processing the current command to completion, subject to ambiguity rules. However, any command continuation request responses and command continuations MUST be negotiated before any subsequent command is initiated.
クライアントは、あいまいさルール（以下を参照）と基になるデータストリームのフロー制御制約に従って、コマンドの完了結果応答を待たずに別のコマンドを送信できます（MAY）。同様に、サーバーは、あいまいさのルールに従って、現在のコマンドを最後まで処理する前に別のコマンドの処理を開始する場合があります。ただし、コマンド継続要求の応答とコマンド継続は、後続のコマンドが開始される前にネゴシエートする必要があります。
The exception is if an ambiguity would result because of a command that would affect the results of other commands. Clients MUST NOT send multiple commands without waiting if an ambiguity would result. If the server detects a possible ambiguity, it MUST execute commands to completion in the order given by the client.
例外は、他のコマンドの結果に影響を与えるコマンドのためにあいまいさが生じる場合です。あいまいさが生じる場合、クライアントは待機せずに複数のコマンドを送信してはなりません（MUST NOT）。サーバーは、あいまいさの可能性を検出した場合、クライアントが指定した順序でコマンドを実行して完了する必要があります。
The most obvious example of ambiguity is when a command would affect the results of another command, e.g., a FETCH of a message's flags and a STORE of that same message's flags.
あいまいさの最も明白な例は、コマンドが別のコマンドの結果に影響を与える場合です。たとえば、メッセージのフラグのFETCHと同じメッセージのフラグのSTOREなどです。
A non-obvious ambiguity occurs with commands that permit an untagged EXPUNGE response (commands other than FETCH, STORE, and SEARCH), since an untagged EXPUNGE response can invalidate sequence numbers in a subsequent command. This is not a problem for FETCH, STORE, or SEARCH commands because servers are prohibited from sending EXPUNGE responses while any of those commands are in progress. Therefore, if the client sends any command other than FETCH, STORE, or SEARCH, it MUST wait for the completion result response before sending a command with message sequence numbers.
タグ付けされていないEXPUNGE応答は後続のコマンドのシーケンス番号を無効にする可能性があるため、タグ付けされていないEXPUNGE応答を許可するコマンド（FETCH、STORE、およびSEARCH以外のコマンド）では、明白でないあいまいさが発生します。これは、FETCH、STORE、またはSEARCHコマンドの問題ではありません。これらのコマンドの実行中は、サーバーがEXPUNGE応答を送信することが禁止されているためです。したがって、クライアントがFETCH、STORE、またはSEARCH以外のコマンドを送信する場合、メッセージシーケンス番号を含むコマンドを送信する前に、完了結果の応答を待機する必要があります。
Note: UID FETCH, UID STORE, and UID SEARCH are different commands from FETCH, STORE, and SEARCH. If the client sends a UID command, it must wait for a completion result response before sending a command with message sequence numbers.
注：UID FETCH、UID STORE、およびUID SEARCHは、FETCH、STORE、およびSEARCHとは異なるコマンドです。クライアントがUIDコマンドを送信する場合、メッセージシーケンス番号を含むコマンドを送信する前に、完了結果の応答を待つ必要があります。
For example, the following non-waiting command sequences are invalid:
たとえば、次の待機していないコマンドシーケンスは無効です。
FETCH + NOOP + STORE
STORE + COPY + FETCH
COPY + COPY
CHECK + FETCH
The following are examples of valid non-waiting command sequences:
以下は、有効な非待機コマンドシーケンスの例です。
FETCH + STORE + SEARCH + CHECK
STORE + COPY + EXPUNGE
UID SEARCH + UID SEARCH may be valid or invalid as a non-waiting command sequence, depending upon whether or not the second UID SEARCH contains message sequence numbers.
UID SEARCH + UID SEARCHは、2番目のUID SEARCHにメッセージシーケンス番号が含まれているかどうかによって、非待機コマンドシーケンスとして有効または無効になる場合があります。
IMAP4rev1 commands are described in this section. Commands are organized by the state in which the command is permitted. Commands which are permitted in multiple states are listed in the minimum permitted state (for example, commands valid in authenticated and selected state are listed in the authenticated state commands).
このセクションでは、IMAP4rev1コマンドについて説明します。コマンドは、コマンドが許可されている状態によって編成されます。複数の状態で許可されるコマンドは、最小許可状態にリストされます（例えば、認証済みおよび選択済み状態で有効なコマンドは、認証済み状態コマンドにリストされます）。
Command arguments, identified by "Arguments:" in the command descriptions below, are described by function, not by syntax. The precise syntax of command arguments is described in the Formal Syntax section.
以下のコマンドの説明で「Arguments：」によって識別されるコマンド引数は、構文ではなく関数によって記述されます。コマンド引数の正確な構文は、「正式な構文」セクションで説明されています。
Some commands cause specific server responses to be returned; these are identified by "Responses:" in the command descriptions below. See the response descriptions in the Responses section for information on these responses, and the Formal Syntax section for the precise syntax of these responses. It is possible for server data to be transmitted as a result of any command. Thus, commands that do not specifically require server data specify "no specific responses for this command" instead of "none".
一部のコマンドは、特定のサーバー応答を返します。これらは、以下のコマンドの説明の「応答：」で識別されます。これらの応答の詳細については、応答セクションの応答の説明を参照してください。これらの応答の正確な構文については、正式な構文セクションを参照してください。コマンドの結果としてサーバーデータが送信される可能性があります。したがって、サーバーデータを特に必要としないコマンドは、「なし」ではなく「このコマンドに対する特定の応答なし」を指定します。
The "Result:" in the command description refers to the possible tagged status responses to a command, and any special interpretation of these status responses.
コマンドの説明の「結果：」は、コマンドに対する可能なタグ付きステータス応答と、これらのステータス応答の特別な解釈を示しています。
The state of a connection is only changed by successful commands which are documented as changing state. A rejected command (BAD response) never changes the state of the connection or of the selected mailbox. A failed command (NO response) generally does not change the state of the connection or of the selected mailbox; the exception being the SELECT and EXAMINE commands.
接続の状態は、状態の変化として文書化されている成功したコマンドによってのみ変更されます。拒否されたコマンド（BAD応答）は、接続または選択されたメールボックスの状態を変更することはありません。失敗したコマンド（NO応答）は、通常、接続または選択されたメールボックスの状態を変更しません。 SELECTコマンドとEXAMINEコマンドは例外です。
The following commands are valid in any state: CAPABILITY, NOOP, and LOGOUT.
コマンドCAPABILITY、NOOP、およびLOGOUTは、どの状態でも有効です。
Arguments: none
引数：なし
Responses: REQUIRED untagged response: CAPABILITY
応答：タグなしの応答が必要です：能力
Result: OK - capability completed BAD - command unknown or arguments invalid
結果：OK-機能完了BAD-コマンドが不明または引数が無効
The CAPABILITY command requests a listing of capabilities that the server supports. The server MUST send a single untagged CAPABILITY response with "IMAP4rev1" as one of the listed capabilities before the (tagged) OK response.
CAPABILITYコマンドは、サーバーがサポートする機能のリストを要求します。サーバーは、（タグ付き）OK応答の前に、リストされた機能の1つとして「IMAP4rev1」を含む単一のタグなしCAPABILITY応答を送信する必要があります。
A capability name which begins with "AUTH=" indicates that the server supports that particular authentication mechanism. All such names are, by definition, part of this specification. For example, the authorization capability for an experimental "blurdybloop" authenticator would be "AUTH=XBLURDYBLOOP" and not "XAUTH=BLURDYBLOOP" or "XAUTH=XBLURDYBLOOP".
「AUTH =」で始まる機能名は、サーバーがその特定の認証メカニズムをサポートしていることを示します。そのような名前はすべて、定義により、この仕様の一部です。たとえば、実験的な「blurdybloop」認証システムの認証機能は「AUTH = XBLURDYBLOOP」であり、「XAUTH = BLURDYBLOOP」または「XAUTH = XBLURDYBLOOP」ではありません。
Other capability names refer to extensions, revisions, or amendments to this specification. See the documentation of the CAPABILITY response for additional information. No capabilities, beyond the base IMAP4rev1 set defined in this specification, are enabled without explicit client action to invoke the capability.
他の機能名は、この仕様の拡張、改訂、または修正を指します。詳細については、CAPABILITY応答のドキュメントを参照してください。この仕様で定義されている基本のIMAP4rev1セット以外の機能は、その機能を呼び出す明示的なクライアントアクションがないと有効になりません。
Client and server implementations MUST implement the STARTTLS, LOGINDISABLED, and AUTH=PLAIN (described in [IMAP-TLS]) capabilities. See the Security Considerations section for important information.
クライアントとサーバーの実装は、STARTTLS、LOGINDISABLED、およびAUTH = PLAIN（[IMAP-TLS]で説明）機能を実装する必要があります。重要な情報については、セキュリティに関する考慮事項のセクションを参照してください。
See the section entitled "Client Commands - Experimental/Expansion" for information about the form of site or implementation-specific capabilities.
サイトの形式や実装固有の機能については、「クライアントコマンド-実験的/拡張」というタイトルのセクションを参照してください。
Example: C: abcd CAPABILITY
S: * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI
LOGINDISABLED
S: abcd OK CAPABILITY completed
C: efgh STARTTLS
S: efgh OK STARTLS completed
<TLS negotiation, further commands are under [TLS] layer>
C: ijkl CAPABILITY
S: * CAPABILITY IMAP4rev1 AUTH=GSSAPI AUTH=PLAIN
S: ijkl OK CAPABILITY completed
Arguments: none
引数：なし
Responses: no specific responses for this command (but see below)
応答：このコマンドに対する特定の応答はありません（ただし、以下を参照）
Result: OK - noop completed BAD - command unknown or arguments invalid
結果：OK-noop完了BAD-コマンドが不明、または引数が無効
The NOOP command always succeeds. It does nothing.
NOOPコマンドは常に成功します。それは何もしません。
Since any command can return a status update as untagged data, the NOOP command can be used as a periodic poll for new messages or message status updates during a period of inactivity (this is the preferred method to do this). The NOOP command can also be used to reset any inactivity autologout timer on the server.
どのコマンドでもステータス更新をタグなしデータとして返すことができるので、NOOPコマンドは、非アクティブ期間中の新しいメッセージまたはメッセージステータス更新の定期的なポーリングとして使用できます（これは、これを行うのに推奨される方法です）。 NOOPコマンドを使用して、サーバー上の非アクティブな自動ログアウトタイマーをリセットすることもできます。
Example: C: a002 NOOP
S: a002 OK NOOP completed
. . .
C: a047 NOOP
S: * 22 EXPUNGE
S: * 23 EXISTS
S: * 3 RECENT
S: * 14 FETCH (FLAGS (\Seen \Deleted))
S: a047 OK NOOP completed
Arguments: none
引数：なし
Responses: REQUIRED untagged response: BYE
応答：必須タグなし応答：BYE
Result: OK - logout completed BAD - command unknown or arguments invalid
結果：OK-ログアウト完了BAD-コマンドが不明または引数が無効
The LOGOUT command informs the server that the client is done with the connection. The server MUST send a BYE untagged response before the (tagged) OK response, and then close the network connection.
LOGOUTコマンドは、クライアントが接続を完了したことをサーバーに通知します。サーバーは、（タグ付き）OK応答の前にBYEタグなし応答を送信してから、ネットワーク接続を閉じる必要があります。
Example: C: A023 LOGOUT S: * BYE IMAP4rev1 Server logging out S: A023 OK LOGOUT completed (Server and client then close the connection)
例：C：A023ログアウトS：* BYE IMAP4rev1サーバーログアウトS：A023 OKログアウト完了（サーバーとクライアントが接続を閉じる）
In the not authenticated state, the AUTHENTICATE or LOGIN command establishes authentication and enters the authenticated state. The AUTHENTICATE command provides a general mechanism for a variety of authentication techniques, privacy protection, and integrity checking; whereas the LOGIN command uses a traditional user name and plaintext password pair and has no means of establishing privacy protection or integrity checking.
認証されていない状態では、AUTHENTICATEまたはLOGINコマンドが認証を確立し、認証された状態に入ります。 AUTHENTICATEコマンドは、さまざまな認証技術、プライバシー保護、および整合性チェックのための一般的なメカニズムを提供します。一方、LOGINコマンドは従来のユーザー名とプレーンテキストのパスワードのペアを使用し、プライバシー保護や整合性チェックを確立する手段はありません。
The STARTTLS command is an alternate form of establishing session privacy protection and integrity checking, but does not establish authentication or enter the authenticated state.
STARTTLSコマンドは、セッションのプライバシー保護と整合性チェックを確立する代替形式ですが、認証を確立したり、認証済みの状態にしたりしません。
Server implementations MAY allow access to certain mailboxes without establishing authentication. This can be done by means of the ANONYMOUS [SASL] authenticator described in [ANONYMOUS]. An older convention is a LOGIN command using the userid "anonymous"; in this case, a password is required although the server may choose to accept any password. The restrictions placed on anonymous users are implementation-dependent.
サーバーの実装は、認証を確立せずに特定のメールボックスへのアクセスを許可してもよい（MAY）。これは、[ANONYMOUS]で説明されているANONYMOUS [SASL]オーセンティケーターを使用して実行できます。古い規則は、ユーザーID「anonymous」を使用するLOGINコマンドです。この場合、サーバーは任意のパスワードを受け入れることを選択できますが、パスワードが必要です。匿名ユーザーに課せられる制限は、実装によって異なります。
Once authenticated (including as anonymous), it is not possible to re-enter not authenticated state.
認証後（匿名としても含む）、認証されていない状態に再度入ることはできません。
In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT), the following commands are valid in the not authenticated state: STARTTLS, AUTHENTICATE and LOGIN. See the Security Considerations section for important information about these commands.
ユニバーサルコマンド（CAPABILITY、NOOP、およびLOGOUT）に加えて、次のコマンドは、認証されていない状態でも有効です：STARTTLS、AUTHENTICATE、およびLOGIN。これらのコマンドに関する重要な情報については、セキュリティに関する考慮事項のセクションを参照してください。
Arguments: none
引数：なし
Responses: no specific response for this command
応答：このコマンドに対する特定の応答はありません
Result: OK - starttls completed, begin TLS negotiation BAD - command unknown or arguments invalid
結果：OK-starttlsが完了し、TLSネゴシエーションを開始しますBAD-コマンドが不明または引数が無効です
A [TLS] negotiation begins immediately after the CRLF at the end of the tagged OK response from the server. Once a client issues a STARTTLS command, it MUST NOT issue further commands until a server response is seen and the [TLS] negotiation is complete.
[TLS]ネゴシエーションは、サーバーからのタグ付きOK応答の終わりのCRLFの直後に始まります。クライアントがSTARTTLSコマンドを発行すると、サーバーの応答が確認されて[TLS]ネゴシエーションが完了するまで、クライアントはそれ以上コマンドを発行してはなりません（MUST NOT）。
The server remains in the non-authenticated state, even if client credentials are supplied during the [TLS] negotiation. This does not preclude an authentication mechanism such as EXTERNAL (defined in [SASL]) from using client identity determined by the [TLS] negotiation.
[TLS]ネゴシエーション中にクライアントの資格情報が提供されても、サーバーは非認証状態のままです。これはEXTERNAL（[SASL]で定義）などの認証メカニズムが[TLS]ネゴシエーションによって決定されたクライアントIDを使用することを妨げません。
Once [TLS] has been started, the client MUST discard cached information about server capabilities and SHOULD re-issue the CAPABILITY command. This is necessary to protect against man-in-the-middle attacks which alter the capabilities list prior to STARTTLS. The server MAY advertise different capabilities after STARTTLS.
[TLS]が開始されると、クライアントはサーバー機能に関するキャッシュされた情報を破棄し、CAPABILITYコマンドを再発行する必要があります（SHOULD）。これは、STARTTLSの前に機能リストを変更する中間者攻撃から保護するために必要です。サーバーは、STARTTLSの後にさまざまな機能を通知する場合があります。
Example: C: a001 CAPABILITY
S: * CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED
S: a001 OK CAPABILITY completed
C: a002 STARTTLS
S: a002 OK Begin TLS negotiation now
<TLS negotiation, further commands are under [TLS] layer>
C: a003 CAPABILITY
S: * CAPABILITY IMAP4rev1 AUTH=PLAIN
S: a003 OK CAPABILITY completed
C: a004 LOGIN joe password
S: a004 OK LOGIN completed
Arguments: authentication mechanism name
引数：認証メカニズム名
Responses: continuation data can be requested
応答：継続データを要求できます
Result: OK - authenticate completed, now in authenticated state NO - authenticate failure: unsupported authentication mechanism, credentials rejected BAD - command unknown or arguments invalid, authentication exchange cancelled
結果：OK-認証が完了し、認証済みの状態になりましたNO-認証の失敗：サポートされていない認証メカニズム、資格情報が拒否されましたBAD-不明なコマンドまたは引数が無効です、認証交換がキャンセルされました
The AUTHENTICATE command indicates a [SASL] authentication mechanism to the server. If the server supports the requested authentication mechanism, it performs an authentication protocol exchange to authenticate and identify the client. It MAY also negotiate an OPTIONAL security layer for subsequent protocol interactions. If the requested authentication mechanism is not supported, the server SHOULD reject the AUTHENTICATE command by sending a tagged NO response.
AUTHENTICATEコマンドは、サーバーに[SASL]認証メカニズムを示します。サーバーが要求された認証メカニズムをサポートしている場合、認証プロトコル交換を実行してクライアントを認証および識別します。また、後続のプロトコル対話のために、オプションのセキュリティ層をネゴシエートする場合があります。要求された認証メカニズムがサポートされていない場合、サーバーはタグ付きのNO応答を送信してAUTHENTICATEコマンドを拒否する必要があります（SHOULD）。
The AUTHENTICATE command does not support the optional "initial response" feature of [SASL]. Section 5.1 of [SASL] specifies how to handle an authentication mechanism which uses an initial response.
AUTHENTICATEコマンドは、[SASL]のオプションの「初期応答」機能をサポートしていません。 [SASL]のセクション5.1は、初期応答を使用する認証メカニズムの処理方法を指定しています。
The service name specified by this protocol's profile of [SASL] is "imap".
このプロトコルの[SASL]のプロファイルで指定されているサービス名は「imap」です。
The authentication protocol exchange consists of a series of server challenges and client responses that are specific to the authentication mechanism. A server challenge consists of a command continuation request response with the "+" token followed by a BASE64 encoded string. The client response consists of a single line consisting of a BASE64 encoded string. If the client wishes to cancel an authentication exchange, it issues a line consisting of a single "*". If the server receives such a response, it MUST reject the AUTHENTICATE command by sending a tagged BAD response.
認証プロトコル交換は、認証メカニズムに固有の一連のサーバーチャレンジとクライアント応答で構成されます。サーバーチャレンジは、「+」トークン付きのコマンド継続要求応答と、その後に続くBASE64エンコードされた文字列で構成されます。クライアントの応答は、BASE64エンコードされた文字列で構成される1行で構成されます。クライアントが認証交換をキャンセルしたい場合は、単一の「*」で構成される行を発行します。サーバーがそのような応答を受信した場合、タグ付きのBAD応答を送信してAUTHENTICATEコマンドを拒否する必要があります。
If a security layer is negotiated through the [SASL] authentication exchange, it takes effect immediately following the CRLF that concludes the authentication exchange for the client, and the CRLF of the tagged OK response for the server.
セキュリティ層が[SASL]認証交換を介してネゴシエートされる場合、それはクライアントの認証交換を終了するCRLFとサーバーのタグ付けされたOK応答のCRLFの直後に有効になります。
While client and server implementations MUST implement the AUTHENTICATE command itself, it is not required to implement any authentication mechanisms other than the PLAIN mechanism described in [IMAP-TLS]. Also, an authentication mechanism is not required to support any security layers.
クライアントとサーバーの実装はAUTHENTICATEコマンド自体を実装する必要がありますが、[IMAP-TLS]で説明されているPLAINメカニズム以外の認証メカニズムを実装する必要はありません。また、セキュリティレイヤをサポートするために認証メカニズムは必要ありません。
Note: a server implementation MUST implement a configuration in which it does NOT permit any plaintext password mechanisms, unless either the STARTTLS command has been negotiated or some other mechanism that protects the session from password snooping has been provided. Server sites SHOULD NOT use any configuration which permits a plaintext password mechanism without such a protection mechanism against password snooping. Client and server implementations SHOULD implement additional [SASL] mechanisms that do not use plaintext passwords, such the GSSAPI mechanism described in [SASL] and/or the [DIGEST-MD5] mechanism.
注：サーバーの実装では、STARTTLSコマンドがネゴシエートされているか、セッションをパスワードスヌーピングから保護する他のメカニズムが提供されていない限り、プレーンテキストのパスワードメカニズムを許可しない構成を実装する必要があります。サーバーサイトは、パスワードのスヌーピングに対するそのような保護メカニズムなしでプレーンテキストのパスワードメカニズムを許可する構成を使用してはなりません。クライアントとサーバーの実装は、[SASL]や[DIGEST-MD5]メカニズムで説明されているGSSAPIメカニズムなど、プレーンテキストのパスワードを使用しない追加の[SASL]メカニズムを実装する必要があります（SHOULD）。
Servers and clients can support multiple authentication mechanisms. The server SHOULD list its supported authentication mechanisms in the response to the CAPABILITY command so that the client knows which authentication mechanisms to use.
サーバーとクライアントは、複数の認証メカニズムをサポートできます。サーバーは、CAPABILITYコマンドへの応答に、サポートされている認証メカニズムをリストする必要があります（SHOULD）。これにより、クライアントは使用する認証メカニズムを認識できます。
A server MAY include a CAPABILITY response code in the tagged OK response of a successful AUTHENTICATE command in order to send capabilities automatically. It is unnecessary for a client to send a separate CAPABILITY command if it recognizes these automatic capabilities. This should only be done if a security layer was not negotiated by the AUTHENTICATE command, because the tagged OK response as part of an AUTHENTICATE command is not protected by encryption/integrity checking. [SASL] requires the client to re-issue a CAPABILITY command in this case.
サーバーは、機能を自動的に送信するために、成功したAUTHENTICATEコマンドのタグ付きOK応答にCAPABILITY応答コードを含めることができます。クライアントがこれらの自動機能を認識する場合、クライアントが個別のCAPABILITYコマンドを送信する必要はありません。 AUTHENTICATEコマンドの一部としてタグ付けされたOK応答は暗号化/整合性チェックによって保護されていないため、セキュリティ層がAUTHENTICATEコマンドによってネゴシエートされなかった場合にのみ、これを行う必要があります。この場合、[SASL]はクライアントにCAPABILITYコマンドを再発行することを要求します。
If an AUTHENTICATE command fails with a NO response, the client MAY try another authentication mechanism by issuing another AUTHENTICATE command. It MAY also attempt to authenticate by using the LOGIN command (see section 6.2.3 for more detail). In other words, the client MAY request authentication types in decreasing order of preference, with the LOGIN command as a last resort.
AUTHENTICATEコマンドがNO応答で失敗した場合、クライアントは別のAUTHENTICATEコマンドを発行して別の認証メカニズムを試行できます（MAY）。また、LOGINコマンドを使用して認証を試みてもよい（詳細については、セクション6.2.3を参照）。言い換えれば、クライアントはLOGINコマンドを最後の手段として、優先度の降順で認証タイプを要求してもよい（MAY）。
The authorization identity passed from the client to the server during the authentication exchange is interpreted by the server as the user name whose privileges the client is requesting.
認証交換中にクライアントからサーバーに渡される許可IDは、サーバーによって、クライアントが要求している特権を持つユーザー名として解釈されます。
Example: S: * OK IMAP4rev1 Server
C: A001 AUTHENTICATE GSSAPI
S: +
C: YIIB+wYJKoZIhvcSAQICAQBuggHqMIIB5qADAgEFoQMCAQ6iBw
MFACAAAACjggEmYYIBIjCCAR6gAwIBBaESGxB1Lndhc2hpbmd0
b24uZWR1oi0wK6ADAgEDoSQwIhsEaW1hcBsac2hpdmFtcy5jYW
Mud2FzaGluZ3Rvbi5lZHWjgdMwgdCgAwIBAaEDAgEDooHDBIHA
cS1GSa5b+fXnPZNmXB9SjL8Ollj2SKyb+3S0iXMljen/jNkpJX
AleKTz6BQPzj8duz8EtoOuNfKgweViyn/9B9bccy1uuAE2HI0y
C/PHXNNU9ZrBziJ8Lm0tTNc98kUpjXnHZhsMcz5Mx2GR6dGknb
I0iaGcRerMUsWOuBmKKKRmVMMdR9T3EZdpqsBd7jZCNMWotjhi
vd5zovQlFqQ2Wjc2+y46vKP/iXxWIuQJuDiisyXF0Y8+5GTpAL
pHDc1/pIGmMIGjoAMCAQGigZsEgZg2on5mSuxoDHEA1w9bcW9n
FdFxDKpdrQhVGVRDIzcCMCTzvUboqb5KjY1NJKJsfjRQiBYBdE
NKfzK+g5DlV8nrw81uOcP8NOQCLR5XkoMHC0Dr/80ziQzbNqhx
O6652Npft0LQwJvenwDI13YxpwOdMXzkWZN/XrEqOWp6GCgXTB
vCyLWLlWnbaUkZdEYbKHBPjd8t/1x5Yg==
S: + YGgGCSqGSIb3EgECAgIAb1kwV6ADAgEFoQMCAQ+iSzBJoAMC
AQGiQgRAtHTEuOP2BXb9sBYFR4SJlDZxmg39IxmRBOhXRKdDA0
uHTCOT9Bq3OsUTXUlk0CsFLoa8j+gvGDlgHuqzWHPSQg==
C:
S: + YDMGCSqGSIb3EgECAgIBAAD/////6jcyG4GE3KkTzBeBiVHe
ceP2CWY0SR0fAQAgAAQEBAQ=
C: YDMGCSqGSIb3EgECAgIBAAD/////3LQBHXTpFfZgrejpLlLImP
wkhbfa2QteAQAgAG1yYwE=
S: A001 OK GSSAPI authentication successful
Note: The line breaks within server challenges and client responses are for editorial clarity and are not in real authenticators.
注：サーバーのチャレンジとクライアントの応答内の改行は、編集を明確にするためのものであり、実際の認証システムにはありません。
Arguments: user name password
引数：ユーザー名とパスワード
Responses: no specific responses for this command
応答：このコマンドに対する特定の応答はありません
Result: OK - login completed, now in authenticated state
NO - login failure: user name or password rejected
BAD - command unknown or arguments invalid
The LOGIN command identifies the client to the server and carries the plaintext password authenticating this user.
LOGINコマンドは、サーバーに対してクライアントを識別し、このユーザーを認証するプレーンテキストのパスワードを伝達します。
A server MAY include a CAPABILITY response code in the tagged OK response to a successful LOGIN command in order to send capabilities automatically. It is unnecessary for a client to send a separate CAPABILITY command if it recognizes these automatic capabilities.
サーバーは、機能を自動的に送信するために、成功したLOGINコマンドに対するタグ付きのOK応答にCAPABILITY応答コードを含めることができます。クライアントがこれらの自動機能を認識する場合、クライアントが個別のCAPABILITYコマンドを送信する必要はありません。
Example: C: a001 LOGIN SMITH SESAME S: a001 OK LOGIN completed
例：C：a001 LOGIN SMITH SESAME S：a001 OK LOGIN completed
Note: Use of the LOGIN command over an insecure network (such as the Internet) is a security risk, because anyone monitoring network traffic can obtain plaintext passwords. The LOGIN command SHOULD NOT be used except as a last resort, and it is recommended that client implementations have a means to disable any automatic use of the LOGIN command.
注：安全でないネットワーク（インターネットなど）でのLOGINコマンドの使用は、ネットワークトラフィックを監視している誰もがプレーンテキストのパスワードを取得できるため、セキュリティ上のリスクがあります。 LOGINコマンドは、最後の手段として以外は使用しないでください。クライアントの実装に、LOGINコマンドの自動使用を無効にする手段を設けることをお勧めします。
Unless either the STARTTLS command has been negotiated or some other mechanism that protects the session from password snooping has been provided, a server implementation MUST implement a configuration in which it advertises the LOGINDISABLED capability and does NOT permit the LOGIN command. Server sites SHOULD NOT use any configuration which permits the LOGIN command without such a protection mechanism against password snooping. A client implementation MUST NOT send a LOGIN command if the LOGINDISABLED capability is advertised.
STARTTLSコマンドがネゴシエートされているか、セッションをパスワードスヌーピングから保護する他のメカニズムが提供されていない限り、サーバー実装は、LOGINDISABLED機能を通知し、LOGINコマンドを許可しない構成を実装する必要があります。サーバーサイトは、パスワードスヌーピングに対するそのような保護メカニズムなしでLOGINコマンドを許可する構成を使用してはなりません（SHOULD NOT）。 LOGINDISABLED機能がアドバタイズされている場合、クライアント実装はLOGINコマンドを送信してはなりません（MUST NOT）。
In the authenticated state, commands that manipulate mailboxes as atomic entities are permitted. Of these commands, the SELECT and EXAMINE commands will select a mailbox for access and enter the selected state.
認証された状態では、メールボックスをアトミックエンティティとして操作するコマンドが許可されます。これらのコマンドのうち、SELECTコマンドとEXAMINEコマンドは、アクセスするメールボックスを選択し、選択された状態に入ります。
In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT), the following commands are valid in the authenticated state: SELECT, EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, STATUS, and APPEND.
ユニバーサルコマンド（CAPABILITY、NOOP、およびLOGOUT）に加えて、次のコマンドは認証された状態で有効です：SELECT、EXAMINE、CREATE、DELETE、RENAME、SUBSCRIBE、UNSUBSCRIBE、LIST、LSUB、STATUS、およびAPPEND。
Arguments: mailbox name
引数：メールボックス名
Responses: REQUIRED untagged responses: FLAGS, EXISTS, RECENT REQUIRED OK untagged responses: UNSEEN, PERMANENTFLAGS, UIDNEXT, UIDVALIDITY
応答：必須のタグなし応答：FLAGS、EXISTS、RECENT REQUIRED OKのタグなし応答：UNSEEN、PERMANENTFLAGS、UIDNEXT、UIDVALIDITY
Result: OK - select completed, now in selected state NO - select failure, now in authenticated state: no such mailbox, can't access mailbox BAD - command unknown or arguments invalid
結果：OK-選択完了、選択状態になりましたNO-選択失敗、認証状態になりました：そのようなメールボックスはありません、メールボックスにアクセスできませんBAD-不明なコマンドまたは引数が無効です
The SELECT command selects a mailbox so that messages in the mailbox can be accessed. Before returning an OK to the client, the server MUST send the following untagged data to the client. Note that earlier versions of this protocol only required the FLAGS, EXISTS, and RECENT untagged data; consequently, client implementations SHOULD implement default behavior for missing data as discussed with the individual item.
SELECTコマンドは、メールボックスを選択して、メールボックス内のメッセージにアクセスできるようにします。 OKをクライアントに返す前に、サーバーは次のタグなしデータをクライアントに送信する必要があります。このプロトコルの以前のバージョンでは、FLAGS、EXISTS、およびRECENTのタグなしデータのみが必要であったことに注意してください。結果として、クライアント実装は、個々の項目で説明したように、欠落データのデフォルト動作を実装する必要があります（SHOULD）。
FLAGS Defined flags in the mailbox. See the description of the FLAGS response for more detail.
FLAGSメールボックスの定義済みフラグ。詳細については、FLAGS応答の説明を参照してください。
<n> EXISTS The number of messages in the mailbox. See the description of the EXISTS response for more detail.
<n> EXISTSメールボックス内のメッセージの数。詳細については、EXISTS応答の説明を参照してください。
<n> RECENT The number of messages with the \Recent flag set. See the description of the RECENT response for more detail.
<n> RECENT \ Recentフラグが設定されているメッセージの数。詳細については、最近の応答の説明を参照してください。
OK [UNSEEN <n>] The message sequence number of the first unseen message in the mailbox. If this is missing, the client can not make any assumptions about the first unseen message in the mailbox, and needs to issue a SEARCH command if it wants to find it.
OK [UNSEEN <n>]メールボックス内の最初に表示されないメッセージのメッセージシーケンス番号。これが欠落している場合、クライアントはメールボックス内の最初に表示されないメッセージについて何も想定できず、それを見つけたい場合はSEARCHコマンドを発行する必要があります。
OK [PERMANENTFLAGS (<list of flags>)] A list of message flags that the client can change permanently. If this is missing, the client should assume that all flags can be changed permanently.
OK [PERMANENTFLAGS（<list of flags>）]クライアントが永続的に変更できるメッセージフラグのリスト。これがない場合、クライアントはすべてのフラグを永久に変更できると想定する必要があります。
OK [UIDNEXT <n>] The next unique identifier value. Refer to section 2.3.1.1 for more information. If this is missing, the client can not make any assumptions about the next unique identifier value.
OK [UIDNEXT <n>]次の一意の識別子の値。詳細については、セクション2.3.1.1を参照してください。これが欠落している場合、クライアントは次の一意の識別子の値について何も想定できません。
OK [UIDVALIDITY <n>] The unique identifier validity value. Refer to section 2.3.1.1 for more information. If this is missing, the server does not support unique identifiers.
OK [UIDVALIDITY <n>]一意の識別子の有効性の値。詳細については、セクション2.3.1.1を参照してください。これがない場合、サーバーは一意の識別子をサポートしません。
Only one mailbox can be selected at a time in a connection; simultaneous access to multiple mailboxes requires multiple connections. The SELECT command automatically deselects any currently selected mailbox before attempting the new selection. Consequently, if a mailbox is selected and a SELECT command that fails is attempted, no mailbox is selected.
接続で一度に選択できるメールボックスは1つだけです。複数のメールボックスに同時にアクセスするには、複数の接続が必要です。 SELECTコマンドは、新しい選択を試みる前に、現在選択されているメールボックスの選択を自動的に解除します。その結果、メールボックスが選択され、失敗したSELECTコマンドが試行された場合、メールボックスは選択されません。
If the client is permitted to modify the mailbox, the server SHOULD prefix the text of the tagged OK response with the "[READ-WRITE]" response code.
クライアントがメールボックスの変更を許可されている場合、サーバーはタグ付きOK応答のテキストの前に「[READ-WRITE]」応答コードを付ける必要があります（SHOULD）。
If the client is not permitted to modify the mailbox but is permitted read access, the mailbox is selected as read-only, and the server MUST prefix the text of the tagged OK response to SELECT with the "[READ-ONLY]" response code. Read-only access through SELECT differs from the EXAMINE command in that certain read-only mailboxes MAY permit the change of permanent state on a per-user (as opposed to global) basis. Netnews messages marked in a server-based .newsrc file are an example of such per-user permanent state that can be modified with read-only mailboxes.
クライアントがメールボックスの変更は許可されていないが読み取りアクセスは許可されている場合、メールボックスは読み取り専用として選択され、サーバーはタグ付きOK応答のテキストの先頭に「[読み取り専用]」応答コードを付けてSELECTする必要があります。 。 SELECTによる読み取り専用アクセスは、特定の読み取り専用メールボックスが（グローバルではなく）ユーザーごとに永続的な状態の変更を許可する場合があるという点で、EXAMINEコマンドとは異なります。サーバーベースの.newsrcファイルでマークされたNetnewsメッセージは、読み取り専用メールボックスで変更できるユーザーごとの永続的な状態の例です。
Example: C: A142 SELECT INBOX
S: * 172 EXISTS
S: * 1 RECENT
S: * OK [UNSEEN 12] Message 12 is first unseen
S: * OK [UIDVALIDITY 3857529045] UIDs valid
S: * OK [UIDNEXT 4392] Predicted next UID
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
S: A142 OK [READ-WRITE] SELECT completed
Arguments: mailbox name
引数：メールボックス名
Responses: REQUIRED untagged responses: FLAGS, EXISTS, RECENT REQUIRED OK untagged responses: UNSEEN, PERMANENTFLAGS, UIDNEXT, UIDVALIDITY
応答：必須のタグなし応答：FLAGS、EXISTS、RECENT REQUIRED OKのタグなし応答：UNSEEN、PERMANENTFLAGS、UIDNEXT、UIDVALIDITY
Result: OK - examine completed, now in selected state NO - examine failure, now in authenticated state: no such mailbox, can't access mailbox BAD - command unknown or arguments invalid
結果：OK-検査完了、選択状態になりましたNO-検査失敗、認証状態になりました：そのようなメールボックスはありません、メールボックスにアクセスできませんBAD-不明なコマンドまたは引数が無効です
The EXAMINE command is identical to SELECT and returns the same output; however, the selected mailbox is identified as read-only. No changes to the permanent state of the mailbox, including per-user state, are permitted; in particular, EXAMINE MUST NOT cause messages to lose the \Recent flag.
EXAMINEコマンドはSELECTと同じで、同じ出力を返します。ただし、選択したメールボックスは読み取り専用として識別されます。ユーザーごとの状態を含む、メールボックスの永続的な状態の変更は許可されていません。特に、EXAMINEはメッセージに\ Recentフラグを失わせてはなりません。
The text of the tagged OK response to the EXAMINE command MUST begin with the "[READ-ONLY]" response code.
EXAMINEコマンドに対するタグ付きOK応答のテキストは、「[READ-ONLY]」応答コードで始まる必要があります。
Example: C: A932 EXAMINE blurdybloop
S: * 17 EXISTS
S: * 2 RECENT
S: * OK [UNSEEN 8] Message 8 is first unseen
S: * OK [UIDVALIDITY 3857529045] UIDs valid
S: * OK [UIDNEXT 4392] Predicted next UID
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * OK [PERMANENTFLAGS ()] No permanent flags permitted
S: A932 OK [READ-ONLY] EXAMINE completed
Arguments: mailbox name
引数：メールボックス名
Responses: no specific responses for this command
応答：このコマンドに対する特定の応答はありません
Result: OK - create completed
NO - create failure: can't create mailbox with that name
BAD - command unknown or arguments invalid
The CREATE command creates a mailbox with the given name. An OK response is returned only if a new mailbox with that name has been created. It is an error to attempt to create INBOX or a mailbox with a name that refers to an extant mailbox. Any error in creation will return a tagged NO response.
CREATEコマンドは、指定された名前のメールボックスを作成します。その名前の新しいメールボックスが作成されている場合にのみ、OK応答が返されます。 INBOXまたは既存のメールボックスを参照する名前のメールボックスを作成しようとすると、エラーになります。作成中にエラーが発生すると、タグ付きのNO応答が返されます。
If the mailbox name is suffixed with the server's hierarchy separator character (as returned from the server by a LIST command), this is a declaration that the client intends to create mailbox names under this name in the hierarchy. Server implementations that do not require this declaration MUST ignore the declaration. In any case, the name created is without the trailing hierarchy delimiter.
メールボックス名の末尾にサーバーの階層区切り文字（LISTコマンドによってサーバーから返される）が付いている場合、これは、クライアントが階層内でこの名前の下にメールボックス名を作成することを意図している宣言です。この宣言を必要としないサーバー実装では、宣言を無視する必要があります。いずれの場合も、作成される名前には、末尾の階層区切り文字がありません。
If the server's hierarchy separator character appears elsewhere in the name, the server SHOULD create any superior hierarchical names that are needed for the CREATE command to be successfully completed. In other words, an attempt to create "foo/bar/zap" on a server in which "/" is the hierarchy separator character SHOULD create foo/ and foo/bar/ if they do not already exist.
サーバーの階層区切り文字が名前の別の場所にある場合、サーバーは、CREATEコマンドを正常に完了するために必要な上位の階層名を作成する必要があります（SHOULD）。言い換えると、「/」が階層区切り文字であるサーバー上で「foo / bar / zap」を作成しようとすると、foo /とfoo / bar /がまだ存在していない場合は作成する必要があります（SHOULD）。
If a new mailbox is created with the same name as a mailbox which was deleted, its unique identifiers MUST be greater than any unique identifiers used in the previous incarnation of the mailbox UNLESS the new incarnation has a different unique identifier validity value. See the description of the UID command for more detail.
削除されたメールボックスと同じ名前で新しいメールボックスが作成される場合、その一意の識別子は、新しいインカネーションが異なる一意の識別子の有効性値を持たない限り、メールボックスの以前のインカネーションで使用されたどの一意の識別子よりも大きい必要があります。詳細については、UIDコマンドの説明を参照してください。
Example: C: A003 CREATE owatagusiam/
S: A003 OK CREATE completed
C: A004 CREATE owatagusiam/blurdybloop
S: A004 OK CREATE completed
Note: The interpretation of this example depends on whether "/" was returned as the hierarchy separator from LIST. If "/" is the hierarchy separator, a new level of hierarchy named "owatagusiam" with a member called "blurdybloop" is created. Otherwise, two mailboxes at the same hierarchy level are created.
注：この例の解釈は、 "/"がLISTから階層セパレーターとして返されたかどうかによって異なります。 「/」が階層セパレーターである場合、「blurdybloop」というメンバーを持つ「owatagusiam」という名前の新しいレベルの階層が作成されます。それ以外の場合は、同じ階層レベルの2つのメールボックスが作成されます。
Arguments: mailbox name
引数：メールボックス名
Responses: no specific responses for this command
応答：このコマンドに対する特定の応答はありません
Result: OK - delete completed
NO - delete failure: can't delete mailbox with that name
BAD - command unknown or arguments invalid
The DELETE command permanently removes the mailbox with the given name. A tagged OK response is returned only if the mailbox has been deleted. It is an error to attempt to delete INBOX or a mailbox name that does not exist.
DELETEコマンドは、指定された名前のメールボックスを完全に削除します。タグ付きOK応答は、メールボックスが削除されている場合にのみ返されます。 INBOXまたは存在しないメールボックス名を削除しようとするとエラーになります。
The DELETE command MUST NOT remove inferior hierarchical names. For example, if a mailbox "foo" has an inferior "foo.bar" (assuming "." is the hierarchy delimiter character), removing "foo" MUST NOT remove "foo.bar". It is an error to attempt to delete a name that has inferior hierarchical names and also has the \Noselect mailbox name attribute (see the description of the LIST response for more details).
DELETEコマンドは、下位の階層名を削除してはなりません（MUST NOT）。たとえば、メールボックス「foo」に下位の「foo.bar」がある場合（「。」が階層区切り文字であると想定）、「foo」を削除しても「foo.bar」を削除してはなりません。階層名が低く、\ Noselectメールボックス名属性もある名前を削除しようとすると、エラーになります（詳細については、LIST応答の説明を参照してください）。
It is permitted to delete a name that has inferior hierarchical names and does not have the \Noselect mailbox name attribute. In this case, all messages in that mailbox are removed, and the name will acquire the \Noselect mailbox name attribute.
階層名が低く、\ Noselectメールボックス名属性のない名前を削除することができます。この場合、そのメールボックス内のすべてのメッセージが削除され、名前は\ Noselectメールボックス名属性を取得します。
The value of the highest-used unique identifier of the deleted mailbox MUST be preserved so that a new mailbox created with the same name will not reuse the identifiers of the former incarnation, UNLESS the new incarnation has a different unique identifier validity value. See the description of the UID command for more detail.
同じ名前で作成された新しいメールボックスが以前のインカネーションの識別子を再利用しないように、削除されたメールボックスの最も使用頻度の高い一意の識別子の値を保持する必要があります。ただし、新しいインカネーションが異なる一意の識別子の有効性値を持たない限り。詳細については、UIDコマンドの説明を参照してください。
Examples: C: A682 LIST "" *
S: * LIST () "/" blurdybloop
S: * LIST (\Noselect) "/" foo
S: * LIST () "/" foo/bar
S: A682 OK LIST completed
C: A683 DELETE blurdybloop
S: A683 OK DELETE completed
C: A684 DELETE foo
S: A684 NO Name "foo" has inferior hierarchical names
C: A685 DELETE foo/bar
S: A685 OK DELETE Completed
C: A686 LIST "" *
S: * LIST (\Noselect) "/" foo
S: A686 OK LIST completed
C: A687 DELETE foo
S: A687 OK DELETE Completed C: A82 LIST "" *
S: * LIST () "." blurdybloop
S: * LIST () "." foo
S: * LIST () "." foo.bar
S: A82 OK LIST completed
C: A83 DELETE blurdybloop
S: A83 OK DELETE completed
C: A84 DELETE foo
S: A84 OK DELETE Completed
C: A85 LIST "" *
S: * LIST () "." foo.bar
S: A85 OK LIST completed
C: A86 LIST "" %
S: * LIST (\Noselect) "." foo
S: A86 OK LIST completed
Arguments: existing mailbox name new mailbox name
引数：既存のメールボックス名新しいメールボックス名
Responses: no specific responses for this command
応答：このコマンドに対する特定の応答はありません
Result: OK - rename completed NO - rename failure: can't rename mailbox with that name, can't rename to mailbox with that name BAD - command unknown or arguments invalid
結果：OK-名前の変更が完了したNO-名前の変更に失敗：その名前のメールボックスの名前を変更できない、その名前のメールボックスの名前を変更できないBAD-コマンドが不明であるか、引数が無効
The RENAME command changes the name of a mailbox. A tagged OK response is returned only if the mailbox has been renamed. It is an error to attempt to rename from a mailbox name that does not exist or to a mailbox name that already exists. Any error in renaming will return a tagged NO response.
RENAMEコマンドは、メールボックスの名前を変更します。タグ付きOK応答は、メールボックスの名前が変更されている場合にのみ返されます。存在しないメールボックス名から、またはすでに存在するメールボックス名に名前を変更しようとすると、エラーになります。名前の変更でエラーが発生すると、タグ付きのNO応答が返されます。
If the name has inferior hierarchical names, then the inferior hierarchical names MUST also be renamed. For example, a rename of "foo" to "zap" will rename "foo/bar" (assuming "/" is the hierarchy delimiter character) to "zap/bar".
名前に下位の階層名がある場合は、下位の階層名も名前変更する必要があります。たとえば、 "foo"を "zap"に名前変更すると、 "foo / bar"（ "/"が階層区切り文字であると仮定）は "zap / bar"に名前変更されます。
If the server's hierarchy separator character appears in the name, the server SHOULD create any superior hierarchical names that are needed for the RENAME command to complete successfully. In other words, an attempt to rename "foo/bar/zap" to baz/rag/zowie on a server in which "/" is the hierarchy separator character SHOULD create baz/ and baz/rag/ if they do not already exist.
サーバーの階層区切り文字が名前に含まれている場合、サーバーはRENAMEコマンドが正常に完了するために必要な上位の階層名を作成する必要があります（SHOULD）。言い換えると、「/」が階層区切り文字であるサーバーで「foo / bar / zap」の名前をbaz / rag / zowieに変更しようとすると、baz /とbaz / rag /がまだ存在していない場合は作成する必要があります。
The value of the highest-used unique identifier of the old mailbox name MUST be preserved so that a new mailbox created with the same name will not reuse the identifiers of the former incarnation, UNLESS the new incarnation has a different unique identifier validity value. See the description of the UID command for more detail.
同じ名前で作成された新しいメールボックスが前のインカネーションの識別子を再利用しないように、古いメールボックス名の最も使用頻度の高い一意の識別子の値を保持する必要があります。ただし、新しいインカネーションが異なる一意の識別子の有効性値を持たない限り。詳細については、UIDコマンドの説明を参照してください。
Renaming INBOX is permitted, and has special behavior. It moves all messages in INBOX to a new mailbox with the given name, leaving INBOX empty. If the server implementation supports inferior hierarchical names of INBOX, these are unaffected by a rename of INBOX.
INBOXの名前変更は許可されており、特別な動作があります。 INBOX内のすべてのメッセージを、指定された名前の新しいメールボックスに移動し、INBOXは空のままにします。サーバーの実装がINBOXの下位階層名をサポートしている場合、これらはINBOXの名前変更による影響を受けません。
Examples: C: A682 LIST "" *
S: * LIST () "/" blurdybloop
S: * LIST (\Noselect) "/" foo
S: * LIST () "/" foo/bar
S: A682 OK LIST completed
C: A683 RENAME blurdybloop sarasoop
S: A683 OK RENAME completed
C: A684 RENAME foo zowie
S: A684 OK RENAME Completed
C: A685 LIST "" *
S: * LIST () "/" sarasoop
S: * LIST (\Noselect) "/" zowie
S: * LIST () "/" zowie/bar
S: A685 OK LIST completed
C: Z432 LIST "" *
S: * LIST () "." INBOX
S: * LIST () "." INBOX.bar
S: Z432 OK LIST completed
C: Z433 RENAME INBOX old-mail
S: Z433 OK RENAME completed
C: Z434 LIST "" *
S: * LIST () "." INBOX
S: * LIST () "." INBOX.bar
S: * LIST () "." old-mail
S: Z434 OK LIST completed
Arguments: mailbox
引数：メールボックス
Responses: no specific responses for this command
応答：このコマンドに対する特定の応答はありません
Result: OK - subscribe completed
NO - subscribe failure: can't subscribe to that name
BAD - command unknown or arguments invalid
The SUBSCRIBE command adds the specified mailbox name to the server's set of "active" or "subscribed" mailboxes as returned by the LSUB command. This command returns a tagged OK response only if the subscription is successful.
SUBSCRIBEコマンドは、指定されたメールボックス名を、LSUBコマンドによって返されるサーバーの "アクティブ"または "サブスクライブ"メールボックスのセットに追加します。このコマンドは、サブスクリプションが成功した場合にのみ、タグ付きのOK応答を返します。
A server MAY validate the mailbox argument to SUBSCRIBE to verify that it exists. However, it MUST NOT unilaterally remove an existing mailbox name from the subscription list even if a mailbox by that name no longer exists.
サーバーは、SUBSCRIBEへのメールボックス引数を検証して、それが存在することを確認できます。ただし、既存のメールボックス名が存在しない場合でも、サブスクリプションリストから一方的に削除することはできません。
Note: This requirement is because a server site can choose to routinely remove a mailbox with a well-known name (e.g., "system-alerts") after its contents expire, with the intention of recreating it when new contents are appropriate.
注：この要件は、既知の名前（「system-alerts」など）のメールボックスのコンテンツが期限切れになった後、新しいコンテンツが適切な場合に再作成することを目的として、サーバーサイトが定期的に削除することを選択できるためです。
Example: C: A002 SUBSCRIBE #news.comp.mail.mime
S: A002 OK SUBSCRIBE completed
Arguments: mailbox name
引数：メールボックス名
Responses: no specific responses for this command
応答：このコマンドに対する特定の応答はありません
Result: OK - unsubscribe completed
NO - unsubscribe failure: can't unsubscribe that name
BAD - command unknown or arguments invalid
The UNSUBSCRIBE command removes the specified mailbox name from the server's set of "active" or "subscribed" mailboxes as returned by the LSUB command. This command returns a tagged OK response only if the unsubscription is successful.
UNSUBSCRIBEコマンドは、LSUBコマンドによって返されたサーバーの "アクティブ"または "サブスクライブ"メールボックスのセットから指定されたメールボックス名を削除します。このコマンドは、サブスクリプション解除が成功した場合にのみ、タグ付きのOK応答を返します。
Example: C: A002 UNSUBSCRIBE #news.comp.mail.mime
S: A002 OK UNSUBSCRIBE completed
Arguments: reference name mailbox name with possible wildcards
引数：ワイルドカードを使用できる参照名メールボックス名
Responses: untagged responses: LIST
応答：タグなしの応答：LIST
Result: OK - list completed
NO - list failure: can't list that reference or name
BAD - command unknown or arguments invalid
The LIST command returns a subset of names from the complete set of all names available to the client. Zero or more untagged LIST replies are returned, containing the name attributes, hierarchy delimiter, and name; see the description of the LIST reply for more detail.
LISTコマンドは、クライアントが使用できるすべての名前の完全なセットから名前のサブセットを返します。名前属性、階層区切り文字、および名前を含む、0個以上のタグなしのLIST応答が返されます。詳細については、LIST応答の説明を参照してください。
The LIST command SHOULD return its data quickly, without undue delay. For example, it SHOULD NOT go to excess trouble to calculate the \Marked or \Unmarked status or perform other processing; if each name requires 1 second of processing, then a list of 1200 names would take 20 minutes!
LISTコマンドは、過度の遅延なしに、データを迅速に返す必要があります（SHOULD）。たとえば、\ Markedまたは\ Unmarkedステータスを計算したり、他の処理を実行したりするために、過度のトラブルに出してはなりません。各名前に1秒の処理が必要な場合、1200の名前のリストには20分かかります。
An empty ("" string) reference name argument indicates that the mailbox name is interpreted as by SELECT. The returned mailbox names MUST match the supplied mailbox name pattern. A non-empty reference name argument is the name of a mailbox or a level of mailbox hierarchy, and indicates the context in which the mailbox name is interpreted.
空の（ ""文字列）参照名引数は、メールボックス名がSELECTによって解釈されることを示します。返されるメールボックス名は、指定されたメールボックス名パターンと一致する必要があります。空でない参照名引数は、メールボックスの名前またはメールボックス階層のレベルであり、メールボックス名が解釈されるコンテキストを示します。
An empty ("" string) mailbox name argument is a special request to return the hierarchy delimiter and the root name of the name given in the reference. The value returned as the root MAY be the empty string if the reference is non-rooted or is an empty string. In all cases, a hierarchy delimiter (or NIL if there is no hierarchy) is returned. This permits a client to get the hierarchy delimiter (or find out that the mailbox names are flat) even when no mailboxes by that name currently exist.
空（ ""文字列）のメールボックス名引数は、参照で指定された名前の階層区切り文字とルート名を返す特別な要求です。参照がルート化されていないか空の文字列の場合、ルートとして返される値は空の文字列になる場合があります。すべての場合で、階層区切り文字（または階層がない場合はNIL）が返されます。これにより、その名前のメールボックスが現在存在しない場合でも、クライアントは階層区切り文字を取得できます（またはメールボックス名がフラットであることを確認できます）。
The reference and mailbox name arguments are interpreted into a canonical form that represents an unambiguous left-to-right hierarchy. The returned mailbox names will be in the interpreted form.
参照とメールボックス名の引数は、明確な左から右の階層を表す正規形式に解釈されます。返されるメールボックス名は解釈された形式になります。
Note: The interpretation of the reference argument is implementation-defined. It depends upon whether the server implementation has a concept of the "current working directory" and leading "break out characters", which override the current working directory.
注：参照引数の解釈は実装定義です。それは、サーバーの実装に、「現在の作業ディレクトリ」と先行する「ブレークアウト文字」の概念があり、現在の作業ディレクトリをオーバーライドするかどうかによって異なります。
For example, on a server which exports a UNIX or NT filesystem, the reference argument contains the current working directory, and the mailbox name argument would contain the name as interpreted in the current working directory.
たとえば、UNIXまたはNTファイルシステムをエクスポートするサーバーでは、参照引数には現在の作業ディレクトリが含まれ、メールボックス名の引数には現在の作業ディレクトリで解釈される名前が含まれます。
If a server implementation has no concept of break out characters, the canonical form is normally the reference name appended with the mailbox name. Note that if the server implements the namespace convention (section 5.1.2), "#" is a break out character and must be treated as such.
サーバーの実装にブレークアウト文字の概念がない場合、通常の形式は、メールボックス名が付加された参照名です。サーバーが名前空間規則（セクション5.1.2）を実装している場合、「＃」はブレークアウト文字であり、そのように扱う必要があることに注意してください。
If the reference argument is not a level of mailbox hierarchy (that is, it is a \NoInferiors name), and/or the reference argument does not end with the hierarchy delimiter, it is implementation-dependent how this is interpreted. For example, a reference of "foo/bar" and mailbox name of "rag/baz" could be interpreted as "foo/bar/rag/baz", "foo/barrag/baz", or "foo/rag/baz". A client SHOULD NOT use such a reference argument except at the explicit request of the user. A hierarchical browser MUST NOT make any assumptions about server interpretation of the reference unless the reference is a level of mailbox hierarchy AND ends with the hierarchy delimiter.
参照引数がメールボックス階層のレベルではない（つまり、\ NoInferiors名である）場合、および/または参照引数が階層区切り文字で終わっていない場合、これはどのように解釈されるかは実装に依存します。たとえば、「foo / bar」の参照と「rag / baz」のメールボックス名は、「foo / bar / rag / baz」、「foo / barrag / baz」、または「foo / rag / baz」と解釈できます。 。クライアントは、ユーザーの明示的な要求がない限り、このような参照引数を使用してはなりません（SHOULD NOT）。参照がメールボックス階層のレベルであり、階層デリミタで終わっていない限り、階層ブラウザは参照のサーバー解釈についていかなる仮定も行わないでください。
Any part of the reference argument that is included in the interpreted form SHOULD prefix the interpreted form. It SHOULD also be in the same form as the reference name argument. This rule permits the client to determine if the returned mailbox name is in the context of the reference argument, or if something about the mailbox argument overrode the reference argument. Without this rule, the client would have to have knowledge of the server's naming semantics including what characters are "breakouts" that override a naming context.
解釈された形式に含まれる参照引数の任意の部分は、解釈された形式の前に付ける必要があります（SHOULD）。また、参照名の引数と同じ形式にする必要があります。このルールにより、クライアントは、返されたメールボックス名が参照引数のコンテキスト内にあるかどうか、またはメールボックス引数に関する何かが参照引数を上書きしたかどうかを判断できます。このルールがない場合、クライアントは、ネーミングコンテキストをオーバーライドする「ブレイクアウト」となる文字など、サーバーのネーミングセマンティクスを知っている必要があります。
For example, here are some examples of how references and mailbox names might be interpreted on a UNIX-based server:
たとえば、UNIXベースのサーバーで参照とメールボックス名がどのように解釈されるかの例を次に示します。
Reference Mailbox Name Interpretation
------------ ------------ --------------
~smith/Mail/ foo.* ~smith/Mail/foo.*
archive/ % archive/%
#news. comp.mail.* #news.comp.mail.*
~smith/Mail/ /usr/doc/foo /usr/doc/foo
archive/ ~fred/Mail/* ~fred/Mail/*
The first three examples demonstrate interpretations in the context of the reference argument. Note that "~smith/Mail" SHOULD NOT be transformed into something like "/u2/users/smith/Mail", or it would be impossible for the client to determine that the interpretation was in the context of the reference.
最初の3つの例は、参照引数のコンテキストでの解釈を示しています。 「〜smith / Mail」は「/ u2 / users / smith / Mail」のようなものに変換すべきではないことに注意してください。そうしないと、クライアントが解釈が参照のコンテキスト内であったと判断することが不可能になります。
The character "*" is a wildcard, and matches zero or more characters at this position. The character "%" is similar to "*", but it does not match a hierarchy delimiter. If the "%" wildcard is the last character of a mailbox name argument, matching levels of hierarchy are also returned. If these levels of hierarchy are not also selectable mailboxes, they are returned with the \Noselect mailbox name attribute (see the description of the LIST response for more details).
文字「*」はワイルドカードであり、この位置にあるゼロ個以上の文字と一致します。文字「％」は「*」に似ていますが、階層区切り文字とは一致しません。 「％」ワイルドカードがメールボックス名引数の最後の文字である場合は、一致する階層レベルも返されます。これらの階層レベルが選択可能なメールボックスでもない場合は、\ Noselectメールボックス名属性で返されます（詳細については、LIST応答の説明を参照してください）。
Server implementations are permitted to "hide" otherwise accessible mailboxes from the wildcard characters, by preventing certain characters or names from matching a wildcard in certain situations. For example, a UNIX-based server might restrict the interpretation of "*" so that an initial "/" character does not match.
サーバーの実装では、特定の状況で特定の文字または名前がワイルドカードと一致しないようにすることで、他の方法でアクセス可能なメールボックスをワイルドカード文字から「隠す」ことができます。たとえば、UNIXベースのサーバーは、最初の「/」文字が一致しないように「*」の解釈を制限する場合があります。
The special name INBOX is included in the output from LIST, if INBOX is supported by this server for this user and if the uppercase string "INBOX" matches the interpreted reference and mailbox name arguments with wildcards as described above. The criteria for omitting INBOX is whether SELECT INBOX will return failure; it is not relevant whether the user's real INBOX resides on this or some other server.
INBOXがこのユーザーのこのサーバーでサポートされており、大文字のストリング「INBOX」が上記のように解釈された参照とメールボックス名の引数をワイルドカードで一致する場合、特別な名前INBOXがLISTの出力に含まれます。 INBOXを省略するための基準は、SELECT INBOXが失敗を返すかどうかです。ユーザーの実際のINBOXがこのサーバーにあるか、他のサーバーにあるかは関係ありません。
Example: C: A101 LIST "" ""
S: * LIST (\Noselect) "/" ""
S: A101 OK LIST Completed
C: A102 LIST #news.comp.mail.misc ""
S: * LIST (\Noselect) "." #news.
S: A102 OK LIST Completed
C: A103 LIST /usr/staff/jones ""
S: * LIST (\Noselect) "/" /
S: A103 OK LIST Completed
C: A202 LIST ~/Mail/ %
S: * LIST (\Noselect) "/" ~/Mail/foo
S: * LIST () "/" ~/Mail/meetings
S: A202 OK LIST completed
Arguments: reference name mailbox name with possible wildcards
引数：ワイルドカードを使用できる参照名メールボックス名
Responses: untagged responses: LSUB
応答：タグなし応答：LSUB
Result: OK - lsub completed
NO - lsub failure: can't list that reference or name
BAD - command unknown or arguments invalid
The LSUB command returns a subset of names from the set of names that the user has declared as being "active" or "subscribed". Zero or more untagged LSUB replies are returned. The arguments to LSUB are in the same form as those for LIST.
LSUBコマンドは、ユーザーが「アクティブ」または「サブスクライブ」であると宣言した名前のセットから名前のサブセットを返します。タグなしのゼロ以上のLSUB応答が返されます。 LSUBの引数は、LISTの引数と同じ形式です。
The returned untagged LSUB response MAY contain different mailbox flags from a LIST untagged response. If this should happen, the flags in the untagged LIST are considered more authoritative.
返されたタグなしLSUB応答には、リストのタグなし応答とは異なるメールボックスフラグが含まれる場合があります。これが発生した場合、タグなしリストのフラグがより信頼できると見なされます。
A special situation occurs when using LSUB with the % wildcard. Consider what happens if "foo/bar" (with a hierarchy delimiter of "/") is subscribed but "foo" is not. A "%" wildcard to LSUB must return foo, not foo/bar, in the LSUB response, and it MUST be flagged with the \Noselect attribute.
％ワイルドカードでLSUBを使用すると、特別な状況が発生します。 「foo / bar」（「/」の階層区切り文字を使用）がサブスクライブされているが、「foo」がサブスクライブされていない場合にどうなるかを考えます。 LSUBへの「％」ワイルドカードは、LSUB応答でfoo / barではなくfooを返す必要があり、\ Noselect属性でフラグを立てる必要があります。
The server MUST NOT unilaterally remove an existing mailbox name from the subscription list even if a mailbox by that name no longer exists.
その名前のメールボックスが存在しなくなった場合でも、サーバーは既存のメールボックス名を一方的にサブスクリプションリストから削除してはなりません（MUST NOT）。
Example: C: A002 LSUB "#news." "comp.mail.*"
S: * LSUB () "." #news.comp.mail.mime
S: * LSUB () "." #news.comp.mail.misc
S: A002 OK LSUB completed
C: A003 LSUB "#news." "comp.%"
S: * LSUB (\NoSelect) "." #news.comp.mail
S: A003 OK LSUB completed
Arguments: mailbox name status data item names
引数：メールボックス名ステータスデータアイテム名
Responses: untagged responses: STATUS
応答：タグなし応答：ステータス
Result: OK - status completed
NO - status failure: no status for that name
BAD - command unknown or arguments invalid
The STATUS command requests the status of the indicated mailbox. It does not change the currently selected mailbox, nor does it affect the state of any messages in the queried mailbox (in particular, STATUS MUST NOT cause messages to lose the \Recent flag).
STATUSコマンドは、指定されたメールボックスのステータスを要求します。現在選択されているメールボックスは変更されません。また、照会されたメールボックス内のメッセージの状態にも影響しません（特に、ステータスが原因でメッセージが\ Recentフラグを失うことはありません）。
The STATUS command provides an alternative to opening a second IMAP4rev1 connection and doing an EXAMINE command on a mailbox to query that mailbox's status without deselecting the current mailbox in the first IMAP4rev1 connection.
STATUSコマンドは、2番目のIMAP4rev1接続を開き、最初のIMAP4rev1接続で現在のメールボックスを選択解除せずにメールボックスのステータスを照会するためにメールボックスでEXAMINEコマンドを実行する代替手段を提供します。
Unlike the LIST command, the STATUS command is not guaranteed to be fast in its response. Under certain circumstances, it can be quite slow. In some implementations, the server is obliged to open the mailbox read-only internally to obtain certain status information. Also unlike the LIST command, the STATUS command does not accept wildcards.
LISTコマンドとは異なり、STATUSコマンドの応答が速いことは保証されていません。特定の状況下では、かなり遅くなる可能性があります。一部の実装では、サーバーは特定のステータス情報を取得するために、内部で読み取り専用でメールボックスを開く必要があります。また、LISTコマンドとは異なり、STATUSコマンドはワイルドカードを受け入れません。
Note: The STATUS command is intended to access the status of mailboxes other than the currently selected mailbox. Because the STATUS command can cause the mailbox to be opened internally, and because this information is available by other means on the selected mailbox, the STATUS command SHOULD NOT be used on the currently selected mailbox.
注：STATUSコマンドは、現在選択されているメールボックス以外のメールボックスのステータスにアクセスすることを目的としています。 STATUSコマンドによってメールボックスが内部で開かれる可能性があり、この情報は選択されたメールボックスで他の方法で利用できるため、現在選択されているメールボックスではSTATUSコマンドを使用しないでください（SHOULD NOT）。
The STATUS command MUST NOT be used as a "check for new messages in the selected mailbox" operation (refer to sections 7, 7.3.1, and 7.3.2 for more information about the proper method for new message checking).
STATUSコマンドは、「選択されたメールボックス内の新しいメッセージのチェック」操作として使用してはなりません（新しいメッセージチェックの適切な方法の詳細については、セクション7、7.3.1、および7.3.2を参照してください）。
Because the STATUS command is not guaranteed to be fast in its results, clients SHOULD NOT expect to be able to issue many consecutive STATUS commands and obtain reasonable performance.
結果でSTATUSコマンドが高速であることが保証されていないので、クライアントは多くの連続したSTATUSコマンドを発行して妥当なパフォーマンスを得ることができると期待すべきではありません。
The currently defined status data items that can be requested are:
リクエストできる現在定義されているステータスデータ項目は次のとおりです。
MESSAGES The number of messages in the mailbox.
MESSAGESメールボックス内のメッセージの数。
RECENT The number of messages with the \Recent flag set.
RECENT \ Recentフラグが設定されているメッセージの数。
UIDNEXT The next unique identifier value of the mailbox. Refer to section 2.3.1.1 for more information.
UIDNEXTメールボックスの次の一意の識別子の値。詳細については、セクション2.3.1.1を参照してください。
UIDVALIDITY The unique identifier validity value of the mailbox. Refer to section 2.3.1.1 for more information.
UIDVALIDITYメールボックスの一意の識別子の有効性の値。詳細については、セクション2.3.1.1を参照してください。
UNSEEN The number of messages which do not have the \Seen flag set.
UNSEEN \ Seenフラグが設定されていないメッセージの数。
Example: C: A042 STATUS blurdybloop (UIDNEXT MESSAGES)
S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292)
S: A042 OK STATUS completed
Arguments: mailbox name OPTIONAL flag parenthesized list OPTIONAL date/time string message literal
引数：メールボックス名オプションのフラグ括弧で囲まれたリストオプションの日付/時刻文字列メッセージリテラル
Responses: no specific responses for this command
応答：このコマンドに対する特定の応答はありません
Result: OK - append completed
NO - append error: can't append to that mailbox, error
in flags or date/time or message text
BAD - command unknown or arguments invalid
The APPEND command appends the literal argument as a new message to the end of the specified destination mailbox. This argument SHOULD be in the format of an [RFC-2822] message. 8-bit characters are permitted in the message. A server implementation that is unable to preserve 8-bit data properly MUST be able to reversibly convert 8-bit APPEND data to 7-bit using a [MIME-IMB] content transfer encoding.
APPENDコマンドは、指定された宛先メールボックスの末尾に、新しいメッセージとしてリテラル引数を追加します。この引数は、[RFC-2822]メッセージの形式にする必要があります（SHOULD）。メッセージでは8ビット文字を使用できます。 8ビットデータを適切に保存できないサーバー実装は、[MIME-IMB]コンテンツ転送エンコーディングを使用して、8ビットAPPENDデータを7ビットに可逆的に変換できなければなりません（MUST）。
Note: There MAY be exceptions, e.g., draft messages, in which required [RFC-2822] header lines are omitted in the message literal argument to APPEND. The full implications of doing so MUST be understood and carefully weighed.
注：APPENDへのメッセージリテラル引数で、必要な[RFC-2822]ヘッダー行が省略されている、ドラフトメッセージなどの例外がある場合があります。そうすることの完全な影響を理解し、慎重に検討する必要があります。
If a flag parenthesized list is specified, the flags SHOULD be set in the resulting message; otherwise, the flag list of the resulting message is set to empty by default. In either case, the Recent flag is also set.
フラグの括弧で囲まれたリストが指定されている場合、結果のメッセージにフラグを設定する必要があります（SHOULD）。それ以外の場合、結果のメッセージのフラグリストはデフォルトで空に設定されます。どちらの場合も、Recentフラグも設定されます。
If a date-time is specified, the internal date SHOULD be set in the resulting message; otherwise, the internal date of the resulting message is set to the current date and time by default.
日時が指定されている場合、結果のメッセージに内部日付を設定する必要があります（SHOULD）。それ以外の場合、結果のメッセージの内部日付は、デフォルトで現在の日付と時刻に設定されます。
If the append is unsuccessful for any reason, the mailbox MUST be restored to its state before the APPEND attempt; no partial appending is permitted.
何らかの理由で追加が失敗した場合は、メールボックスをAPPENDの試行前の状態に復元する必要があります。部分的な追加は許可されていません。
If the destination mailbox does not exist, a server MUST return an error, and MUST NOT automatically create the mailbox. Unless it is certain that the destination mailbox can not be created, the server MUST send the response code "[TRYCREATE]" as the prefix of the text of the tagged NO response. This gives a hint to the client that it can attempt a CREATE command and retry the APPEND if the CREATE is successful.
宛先メールボックスが存在しない場合、サーバーはエラーを返さなければならず（MUST）、メールボックスを自動的に作成してはいけません（MUST NOT）。宛先メールボックスが作成できないことが確実でない限り、サーバーはタグ付きNO応答のテキストの接頭辞として応答コード「[TRYCREATE]」を送信する必要があります。これにより、クライアントがCREATEコマンドを試行し、CREATEが成功した場合にAPPENDを再試行できるというヒントがクライアントに与えられます。
If the mailbox is currently selected, the normal new message actions SHOULD occur. Specifically, the server SHOULD notify the client immediately via an untagged EXISTS response. If the server does not do so, the client MAY issue a NOOP command (or failing that, a CHECK command) after one or more APPEND commands.
メールボックスが現在選択されている場合、通常の新しいメッセージアクションが発生する必要があります（SHOULD）。具体的には、サーバーはタグなしのEXISTS応答を介してクライアントにすぐに通知する必要があります（SHOULD）。サーバーがこれを行わない場合、クライアントは1つ以上のAPPENDコマンドの後にNOOPコマンドを発行（または失敗）する可能性があります（CHECKコマンド）。
Example: C: A003 APPEND saved-messages (\Seen) {310}
S: + Ready for literal data
C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
C: From: Fred Foobar <foobar@Blurdybloop.COM>
C: Subject: afternoon meeting
C: To: mooch@owatagu.siam.edu
C: Message-Id: <B27397-0100000@Blurdybloop.COM>
C: MIME-Version: 1.0
C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
C:
C: Hello Joe, do you think we can meet at 3:30 tomorrow?
C:
S: A003 OK APPEND completed
Note: The APPEND command is not used for message delivery, because it does not provide a mechanism to transfer [SMTP] envelope information.
注：APPENDコマンドは、[SMTP]エンベロープ情報を転送するメカニズムを提供しないため、メッセージ配信には使用されません。
In the selected state, commands that manipulate messages in a mailbox are permitted.
選択状態では、メールボックス内のメッセージを操作するコマンドが許可されます。
In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT), and the authenticated state commands (SELECT, EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, STATUS, and APPEND), the following commands are valid in the selected state: CHECK, CLOSE, EXPUNGE, SEARCH, FETCH, STORE, COPY, and UID.
ユニバーサルコマンド（CAPABILITY、NOOP、およびLOGOUT）、および認証済み状態コマンド（SELECT、EXAMINE、CREATE、DELETE、RENAME、SUBSCRIBE、UNSUBSCRIBE、LIST、LSUB、STATUS、およびAPPEND）に加えて、以下のコマンドが有効です。選択された状態：CHECK、CLOSE、EXPUNGE、SEARCH、FETCH、STORE、COPY、およびUID。
Arguments: none
引数：なし
Responses: no specific responses for this command
応答：このコマンドに対する特定の応答はありません
Result: OK - check completed BAD - command unknown or arguments invalid
結果：OK-完了したBADを確認-コマンドが不明または引数が無効
The CHECK command requests a checkpoint of the currently selected mailbox. A checkpoint refers to any implementation-dependent housekeeping associated with the mailbox (e.g., resolving the server's in-memory state of the mailbox with the state on its disk) that is not normally executed as part of each command. A checkpoint MAY take a non-instantaneous amount of real time to complete. If a server implementation has no such housekeeping considerations, CHECK is equivalent to NOOP.
CHECKコマンドは、現在選択されているメールボックスのチェックポイントを要求します。チェックポイントとは、メールボックスに関連付けられている実装依存のハウスキーピング（たとえば、メールボックスのサーバーのメモリ内の状態をディスク上の状態で解決する）を指します。通常、各コマンドの一部として実行されません。チェックポイントは、完了までにリアルタイムではない時間がかかる場合があります。サーバー実装にそのようなハウスキーピングの考慮事項がない場合、CHECKはNOOPと同等です。
There is no guarantee that an EXISTS untagged response will happen as a result of CHECK. NOOP, not CHECK, SHOULD be used for new message polling.
CHECKの結果として、EXISTSタグなし応答が発生する保証はありません。新しいメッセージのポーリングには、CHECKではなくNOOPを使用してください。
Example: C: FXXZ CHECK S: FXXZ OK CHECK Completed
例：C：FXXZ CHECK S：FXXZ OK CHECK Completed
Arguments: none
引数：なし
Responses: no specific responses for this command
応答：このコマンドに対する特定の応答はありません
Result: OK - close completed, now in authenticated state BAD - command unknown or arguments invalid
結果：OK-完了、認証済みの状態になりましたBAD-コマンドが不明または引数が無効です
The CLOSE command permanently removes all messages that have the \Deleted flag set from the currently selected mailbox, and returns to the authenticated state from the selected state. No untagged EXPUNGE responses are sent.
CLOSEコマンドは、現在選択されているメールボックスから\ Deletedフラグが設定されているすべてのメッセージを完全に削除し、選択された状態から認証された状態に戻ります。タグなしのEXPUNGE応答は送信されません。
No messages are removed, and no error is given, if the mailbox is selected by an EXAMINE command or is otherwise selected read-only.
メールボックスがEXAMINEコマンドで選択されているか、そうでなければ読み取り専用で選択されている場合、メッセージは削除されず、エラーも発生しません。
Even if a mailbox is selected, a SELECT, EXAMINE, or LOGOUT command MAY be issued without previously issuing a CLOSE command. The SELECT, EXAMINE, and LOGOUT commands implicitly close the currently selected mailbox without doing an expunge. However, when many messages are deleted, a CLOSE-LOGOUT or CLOSE-SELECT sequence is considerably faster than an EXPUNGE-LOGOUT or EXPUNGE-SELECT because no untagged EXPUNGE responses (which the client would probably ignore) are sent.
メールボックスが選択されている場合でも、以前にCLOSEコマンドを発行せずに、SELECT、EXAMINE、またはLOGOUTコマンドを発行できます。 SELECT、EXAMINE、およびLOGOUTコマンドは、消去を行わずに、現在選択されているメールボックスを暗黙的に閉じます。ただし、多くのメッセージが削除されると、タグなしのEXPUNGE応答（おそらくクライアントが無視する）が送信されないため、CLOSE-LOGOUTまたはCLOSE-SELECTシーケンスはEXPUNGE-LOGOUTまたはEXPUNGE-SELECTよりもかなり高速になります。
Example: C: A341 CLOSE S: A341 OK CLOSE completed
例：C：A341 CLOSE S：A341 OK CLOSE完了
Arguments: none
引数：なし
Responses: untagged responses: EXPUNGE
応答：タグなしの応答：EXPUNGE
Result: OK - expunge completed NO - expunge failure: can't expunge (e.g., permission denied) BAD - command unknown or arguments invalid
結果：OK-消去完了NO-消去失敗：消去できません（許可が拒否されたなど）BAD-不明なコマンドまたは引数が無効です
The EXPUNGE command permanently removes all messages that have the \Deleted flag set from the currently selected mailbox. Before returning an OK to the client, an untagged EXPUNGE response is sent for each message that is removed.
EXPUNGEコマンドは、現在選択されているメールボックスから、\ Deletedフラグが設定されているすべてのメッセージを完全に削除します。 OKをクライアントに返す前に、削除されるメッセージごとにタグなしEXPUNGE応答が送信されます。
Example: C: A202 EXPUNGE
S: * 3 EXPUNGE
S: * 3 EXPUNGE
S: * 5 EXPUNGE
S: * 8 EXPUNGE
S: A202 OK EXPUNGE completed
Note: In this example, messages 3, 4, 7, and 11 had the \Deleted flag set. See the description of the EXPUNGE response for further explanation.
注：この例では、メッセージ3、4、7、および11に\ Deletedフラグが設定されています。詳細については、EXPUNGE応答の説明を参照してください。
Arguments: OPTIONAL [CHARSET] specification searching criteria (one or more)
引数：OPTIONAL [CHARSET]指定検索基準（1つ以上）
Responses: REQUIRED untagged response: SEARCH
応答：タグなしの応答が必要です：検索
Result: OK - search completed NO - search error: can't search that [CHARSET] or criteria BAD - command unknown or arguments invalid
結果：OK-検索が完了したNO-検索エラー：その[CHARSET]または基準が検索できないBAD-不明なコマンドまたは引数が無効
The SEARCH command searches the mailbox for messages that match the given searching criteria. Searching criteria consist of one or more search keys. The untagged SEARCH response from the server contains a listing of message sequence numbers corresponding to those messages that match the searching criteria.
SEARCHコマンドは、指定された検索条件に一致するメッセージをメールボックスで検索します。検索基準は、1つ以上の検索キーで構成されます。サーバーからのタグなしのSEARCH応答には、検索条件に一致するメッセージに対応するメッセージシーケンス番号のリストが含まれています。
When multiple keys are specified, the result is the intersection (AND function) of all the messages that match those keys. For example, the criteria DELETED FROM "SMITH" SINCE 1-Feb-1994 refers to all deleted messages from Smith that were placed in the mailbox since February 1, 1994. A search key can also be a parenthesized list of one or more search keys (e.g., for use with the OR and NOT keys).
複数のキーが指定されている場合、結果はそれらのキーに一致するすべてのメッセージの共通部分（AND関数）です。たとえば、条件DELETED FROM "SMITH" SINCE 1-Feb-1994は、1994年2月1日以降にメールボックスに配置されたSmithからのすべての削除済みメッセージを指します。検索キーは、1つ以上の検索キーの括弧付きリストにすることもできます。 （例えば、ORおよびNOTキーで使用するため）。
Server implementations MAY exclude [MIME-IMB] body parts with terminal content media types other than TEXT and MESSAGE from consideration in SEARCH matching.
サーバーの実装は、TEXTおよびMESSAGE以外の端末コンテンツメディアタイプを含む[MIME-IMB]ボディパーツを、検索マッチングの考慮から除外してもよい（MAY）。
The OPTIONAL [CHARSET] specification consists of the word
"CHARSET" followed by a registered [CHARSET]. It indicates the
[CHARSET] of the strings that appear in the search criteria.
[MIME-IMB] content transfer encodings, and [MIME-HDRS] strings in
[RFC-2822]/[MIME-IMB] headers, MUST be decoded before comparing
text in a [CHARSET] other than US-ASCII. US-ASCII MUST be
supported; other [CHARSET]s MAY be supported.
If the server does not support the specified [CHARSET], it MUST return a tagged NO response (not a BAD). This response SHOULD contain the BADCHARSET response code, which MAY list the [CHARSET]s supported by the server.
サーバーが指定された[CHARSET]をサポートしない場合は、タグ付きのNO応答（BADではない）を返さなければなりません（MUST）。この応答には、サーバーがサポートする[CHARSET]をリストする可能性があるBADCHARSET応答コードを含める必要があります（SHOULD）。
In all search keys that use strings, a message matches the key if the string is a substring of the field. The matching is case-insensitive.
文字列を使用するすべての検索キーで、文字列がフィールドの部分文字列である場合、メッセージはキーと一致します。照合では大文字と小文字が区別されません。
The defined search keys are as follows. Refer to the Formal Syntax section for the precise syntactic definitions of the arguments.
定義されている検索キーは以下の通りです。引数の正確な構文定義については、正式な構文のセクションを参照してください。
<sequence set> Messages with message sequence numbers corresponding to the specified message sequence number set.
<シーケンスセット>指定されたメッセージシーケンス番号セットに対応するメッセージシーケンス番号を持つメッセージ。
ALL All messages in the mailbox; the default initial key for ANDing.
ALLメールボックス内のすべてのメッセージ。 AND演算のデフォルトの初期キー。
ANSWERED Messages with the \Answered flag set.
\ Answeredフラグが設定されたANSWEREDメッセージ。
BCC <string> Messages that contain the specified string in the envelope structure's BCC field.
BCC <string>エンベロープ構造のBCCフィールドに指定された文字列を含むメッセージ。
BEFORE <date> Messages whose internal date (disregarding time and timezone) is earlier than the specified date.
BEFORE <date>内部日付（時刻とタイムゾーンに関係なく）が指定された日付より前のメッセージ。
BODY <string> Messages that contain the specified string in the body of the message.
BODY <string>メッセージの本文に指定された文字列を含むメッセージ。
CC <string> Messages that contain the specified string in the envelope structure's CC field.
CC <string>エンベロープ構造のCCフィールドに指定された文字列を含むメッセージ。
DELETED Messages with the \Deleted flag set.
\ Deletedフラグが設定されたDELETEDメッセージ。
DRAFT Messages with the \Draft flag set.
\ Draftフラグが設定されたドラフトメッセージ。
FLAGGED Messages with the \Flagged flag set.
\ Flaggedフラグが設定されたFLAGGEDメッセージ。
FROM <string> Messages that contain the specified string in the envelope structure's FROM field.
FROM <string>エンベロープ構造のFROMフィールドに指定された文字列を含むメッセージ。
HEADER <field-name> <string> Messages that have a header with the specified field-name (as defined in [RFC-2822]) and that contains the specified string in the text of the header (what comes after the colon). If the string to search is zero-length, this matches all messages that have a header line with the specified field-name regardless of the contents.
HEADER <field-name> <string>指定されたフィールド名（[RFC-2822]で定義）のヘッダーがあり、ヘッダーのテキストに指定された文字列（コロンの後に続くもの）を含むメッセージ。検索する文字列の長さがゼロの場合、これは内容に関係なく、指定されたフィールド名を持つヘッダー行を持つすべてのメッセージに一致します。
KEYWORD <flag> Messages with the specified keyword flag set.
KEYWORD <フラグ>指定されたキーワードフラグが設定されたメッセージ。
LARGER <n> Messages with an [RFC-2822] size larger than the specified number of octets.
[RFC-2822]サイズが指定されたオクテット数より大きいLARGER <n>メッセージ。
NEW Messages that have the \Recent flag set but not the \Seen flag. This is functionally equivalent to "(RECENT UNSEEN)".
\ Recentフラグが設定されているが\ Seenフラグは設定されていないメッセージ。これは、機能的には「（RECENT UNSEEN）」と同等です。
NOT <search-key> Messages that do not match the specified search key.
NOT <search-key>指定された検索キーと一致しないメッセージ。
OLD Messages that do not have the \Recent flag set. This is functionally equivalent to "NOT RECENT" (as opposed to "NOT NEW").
\ Recentフラグが設定されていない古いメッセージ。これは、「最新ではない」とは機能的に同等です（「新しい」ではありません）。
ON <date> Messages whose internal date (disregarding time and timezone) is within the specified date.
ON <date>内部日付（時刻とタイムゾーンを除く）が指定された日付内にあるメッセージ。
OR <search-key1> <search-key2> Messages that match either search key.
または<search-key1> <search-key2>いずれかの検索キーに一致するメッセージ。
RECENT Messages that have the \Recent flag set.
\ Recentフラグが設定されている最近のメッセージ。
SEEN Messages that have the \Seen flag set.
\ Seenフラグが設定されているメッセージ。
SENTBEFORE <date> Messages whose [RFC-2822] Date: header (disregarding time and timezone) is earlier than the specified date.
SENTBEFORE <date> [RFC-2822] Date：ヘッダー（時刻とタイムゾーンを無視）が指定した日付より前のメッセージ。
SENTON <date> Messages whose [RFC-2822] Date: header (disregarding time and timezone) is within the specified date.
SENTON <date> [RFC-2822] Date：ヘッダー（時刻とタイムゾーンは無視）が指定された日付内にあるメッセージ。
SENTSINCE <date> Messages whose [RFC-2822] Date: header (disregarding time and timezone) is within or later than the specified date.
SENTSINCE <日付> [RFC-2822]日付：ヘッダー（時刻とタイムゾーンは無視）が指定された日付以内であるメッセージ。
SINCE <date> Messages whose internal date (disregarding time and timezone) is within or later than the specified date.
SINCE <date>内部日付（時刻とタイムゾーンを除く）が指定された日付内またはそれより後のメッセージ。
SMALLER <n> Messages with an [RFC-2822] size smaller than the specified number of octets.
[RFC-2822]サイズが指定されたオクテット数より小さいSMALLER <n>メッセージ。
SUBJECT <string> Messages that contain the specified string in the envelope structure's SUBJECT field.
SUBJECT <string>エンベロープ構造のSUBJECTフィールドに指定された文字列を含むメッセージ。
TEXT <string> Messages that contain the specified string in the header or body of the message.
TEXT <string>メッセージのヘッダーまたは本文に指定された文字列を含むメッセージ。
TO <string> Messages that contain the specified string in the envelope structure's TO field.
TO <string>エンベロープ構造のTOフィールドに指定された文字列を含むメッセージ。
UID <sequence set> Messages with unique identifiers corresponding to the specified unique identifier set. Sequence set ranges are permitted.
UID <シーケンスセット>指定された一意の識別子セットに対応する一意の識別子を持つメッセージ。シーケンスセットの範囲は許可されます。
UNANSWERED Messages that do not have the \Answered flag set.
UNANSWERED \ Answeredフラグが設定されていないメッセージ。
UNDELETED Messages that do not have the \Deleted flag set.
UNDELETED \ Deletedフラグが設定されていないメッセージ。
UNDRAFT Messages that do not have the \Draft flag set.
ドラフト\ Draftフラグが設定されていないメッセージ。
UNFLAGGED Messages that do not have the \Flagged flag set.
UNFLAGGED \ Flaggedフラグが設定されていないメッセージ。
UNKEYWORD <flag> Messages that do not have the specified keyword flag set.
UNKEYWORD <フラグ>指定されたキーワードフラグが設定されていないメッセージ。
UNSEEN Messages that do not have the \Seen flag set.
UNSEEN \ Seenフラグが設定されていないメッセージ。
Example: C: A282 SEARCH FLAGGED SINCE 1-Feb-1994 NOT FROM "Smith"
S: * SEARCH 2 84 882
S: A282 OK SEARCH completed
C: A283 SEARCH TEXT "string not in mailbox"
S: * SEARCH
S: A283 OK SEARCH completed
C: A284 SEARCH CHARSET UTF-8 TEXT {6}
C: XXXXXX
S: * SEARCH 43
S: A284 OK SEARCH completed
Note: Since this document is restricted to 7-bit ASCII text, it is not possible to show actual UTF-8 data. The "XXXXXX" is a placeholder for what would be 6 octets of 8-bit data in an actual transaction.
注：このドキュメントは7ビットASCIIテキストに制限されているため、実際のUTF-8データを表示することはできません。 「XXXXXX」は、実際のトランザクションで8オクテットの6オクテットのプレースホルダーです。
Arguments: sequence set message data item names or macro
引数：シーケンスセットメッセージデータ項目名またはマクロ
Responses: untagged responses: FETCH
応答：タグなし応答：FETCH
Result: OK - fetch completed
NO - fetch error: can't fetch that data
BAD - command unknown or arguments invalid
The FETCH command retrieves data associated with a message in the mailbox. The data items to be fetched can be either a single atom or a parenthesized list.
FETCHコマンドは、メールボックス内のメッセージに関連付けられたデータを取得します。フェッチされるデータ項目は、単一のアトムまたは括弧で囲まれたリストのいずれかです。
Most data items, identified in the formal syntax under the msg-att-static rule, are static and MUST NOT change for any particular message. Other data items, identified in the formal syntax under the msg-att-dynamic rule, MAY change, either as a result of a STORE command or due to external events.
msg-att-staticルールの正式な構文で識別されるほとんどのデータ項目は静的であり、特定のメッセージに対して変更してはなりません。 msg-att-dynamicルールの下の正式な構文で識別される他のデータ項目は、STOREコマンドの結果として、または外部イベントのために変更される場合があります。
For example, if a client receives an ENVELOPE for a message when it already knows the envelope, it can safely ignore the newly transmitted envelope.
たとえば、クライアントがエンベロープをすでに知っているときにメッセージのENVELOPEを受信した場合、新しく送信されたエンベロープを無視しても安全です。
There are three macros which specify commonly-used sets of data items, and can be used instead of data items. A macro must be used by itself, and not in conjunction with other macros or data items.
一般的に使用されるデータ項目のセットを指定する3つのマクロがあり、データ項目の代わりに使用できます。マクロは単独で使用する必要があり、他のマクロやデータアイテムと組み合わせて使用することはできません。
ALL Macro equivalent to: (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE)
ALL同等のマクロ：（FLAGS INTERNALDATE RFC822.SIZE ENVELOPE）
FAST Macro equivalent to: (FLAGS INTERNALDATE RFC822.SIZE)
同等のFASTマクロ：（FLAGS INTERNALDATE RFC822.SIZE）
FULL Macro equivalent to: (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE BODY)
次と同等のFULLマクロ：（FLAGS INTERNALDATE RFC822.SIZE ENVELOPE BODY）
The currently defined data items that can be fetched are:
フェッチできる現在定義されているデータ項目は次のとおりです。
BODY Non-extensible form of BODYSTRUCTURE.
BODY BODYSTRUCTUREの非拡張形式。
BODY[<section>]<<partial>> The text of a particular body section. The section specification is a set of zero or more part specifiers delimited by periods. A part specifier is either a part number or one of the following: HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, MIME, and TEXT. An empty section specification refers to the entire message, including the header.
BODY [<section>] << partial >>特定の本文セクションのテキスト。セクション指定は、ピリオドで区切られた0個以上のパーツ指定子のセットです。パーツ指定子は、パーツ番号または次のいずれかです：HEADER、HEADER.FIELDS、HEADER.FIELDS.NOT、MIME、およびTEXT。空のセクション指定は、ヘッダーを含むメッセージ全体を指します。
Every message has at least one part number. Non-[MIME-IMB] messages, and non-multipart [MIME-IMB] messages with no encapsulated message, only have a part 1.
すべてのメッセージには、少なくとも1つの部品番号があります。非[MIME-IMB]メッセージ、およびカプセル化されたメッセージのない非マルチパート[MIME-IMB]メッセージには、パート1のみがあります。
Multipart messages are assigned consecutive part numbers, as they occur in the message. If a particular part is of type message or multipart, its parts MUST be indicated by a period followed by the part number within that nested multipart part.
マルチパートメッセージには、メッセージ内で発生する連続したパーツ番号が割り当てられます。特定のパートがメッセージタイプまたはマルチパートタイプの場合、そのパートは、ネストされたマルチパートパート内のパート番号が後に続くピリオドで示す必要があります。
A part of type MESSAGE/RFC822 also has nested part numbers, referring to parts of the MESSAGE part's body.
タイプMESSAGE / RFC822のパーツにも、MESSAGEパーツの本体のパーツを参照するネストされたパーツ番号があります。
The HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, and TEXT part specifiers can be the sole part specifier or can be prefixed by one or more numeric part specifiers, provided that the numeric part specifier refers to a part of type MESSAGE/RFC822. The MIME part specifier MUST be prefixed by one or more numeric part specifiers.
数値部分指定子がタイプMESSAGE / RFC822の部分を参照する場合、HEADER、HEADER.FIELDS、HEADER.FIELDS.NOT、およびTEXT部分指定子は、単一の部分指定子にするか、1つ以上の数値部分指定子を前に付けることができます。 。 MIMEパート指定子には、1つ以上の数値パート指定子をプレフィックスとして付ける必要があります。
The HEADER, HEADER.FIELDS, and HEADER.FIELDS.NOT part specifiers refer to the [RFC-2822] header of the message or of an encapsulated [MIME-IMT] MESSAGE/RFC822 message. HEADER.FIELDS and HEADER.FIELDS.NOT are followed by a list of field-name (as defined in [RFC-2822]) names, and return a
HEADER、HEADER.FIELDS、およびHEADER.FIELDS.NOTの部分指定子は、メッセージまたはカプセル化された[MIME-IMT] MESSAGE / RFC822メッセージの[RFC-2822]ヘッダーを参照します。 HEADER.FIELDSおよびHEADER.FIELDS.NOTの後には（[RFC-2822]で定義されている）フィールド名のリストが続き、
subset of the header. The subset returned by HEADER.FIELDS contains only those header fields with a field-name that matches one of the names in the list; similarly, the subset returned by HEADER.FIELDS.NOT contains only the header fields with a non-matching field-name. The field-matching is case-insensitive but otherwise exact. Subsetting does not exclude the [RFC-2822] delimiting blank line between the header and the body; the blank line is included in all header fetches, except in the case of a message which has no body and no blank line.
ヘッダーのサブセット。 HEADER.FIELDSによって返されるサブセットには、リスト内の名前のいずれかに一致するフィールド名を持つヘッダーフィールドのみが含まれます。同様に、HEADER.FIELDS.NOTによって返されるサブセットには、フィールド名が一致しないヘッダーフィールドのみが含まれます。フィールド照合は大文字と小文字を区別しませんが、それ以外は正確です。サブセット化は、ヘッダーと本文の間の[RFC-2822]区切りの空白行を除外しません。空白行は、本文も空白行もないメッセージの場合を除いて、すべてのヘッダーフェッチに含まれます。
The MIME part specifier refers to the [MIME-IMB] header for this part.
MIMEパート指定子は、このパートの[MIME-IMB]ヘッダーを参照します。
The TEXT part specifier refers to the text body of the message, omitting the [RFC-2822] header.
TEXTパート指定子は、メッセージのテキスト本文を参照し、[RFC-2822]ヘッダーを省略します。
Here is an example of a complex message with some of its part specifiers:
次に、一部の指定子を含む複雑なメッセージの例を示します。
HEADER ([RFC-2822] header of the message) TEXT ([RFC-2822] text body of the message) MULTIPART/MIXED 1 TEXT/PLAIN 2 APPLICATION/OCTET-STREAM 3 MESSAGE/RFC822 3.HEADER ([RFC-2822] header of the message) 3.TEXT ([RFC-2822] text body of the message) MULTIPART/MIXED 3.1 TEXT/PLAIN 3.2 APPLICATION/OCTET-STREAM 4 MULTIPART/MIXED 4.1 IMAGE/GIF 4.1.MIME ([MIME-IMB] header for the IMAGE/GIF) 4.2 MESSAGE/RFC822 4.2.HEADER ([RFC-2822] header of the message) 4.2.TEXT ([RFC-2822] text body of the message) MULTIPART/MIXED 4.2.1 TEXT/PLAIN 4.2.2 MULTIPART/ALTERNATIVE 4.2.2.1 TEXT/PLAIN 4.2.2.2 TEXT/RICHTEXT
HEADER（[RFC-2822]メッセージのヘッダー）TEXT（[RFC-2822]メッセージの本文）MULTIPART / MIXED 1 TEXT / PLAIN 2 APPLICATION / OCTET-STREAM 3 MESSAGE / RFC822 3.HEADER（[RFC-2822 ]メッセージのヘッダー）3.TEXT（[RFC-2822]メッセージ本文）MULTIPART / MIXED 3.1 TEXT / PLAIN 3.2 APPLICATION / OCTET-STREAM 4 MULTIPART / MIXED 4.1 IMAGE / GIF 4.1.MIME（[MIME-IMB ] IMAGE / GIFのヘッダー）4.2 MESSAGE / RFC822 4.2.HEADER（メッセージの[RFC-2822]ヘッダー）4.2.TEXT（[RFC-2822]メッセージのテキスト本文）MULTIPART / MIXED 4.2.1 TEXT / PLAIN 4.2.2 MULTIPART / ALTERNATIVE 4.2.2.1 TEXT / PLAIN 4.2.2.2 TEXT / RICHTEXT
It is possible to fetch a substring of the designated text. This is done by appending an open angle bracket ("<"), the octet position of the first desired octet, a period, the maximum number of octets desired, and a close angle bracket (">") to the part specifier. If the starting octet is beyond the end of the text, an empty string is returned.
指定されたテキストの部分文字列を取得することが可能です。これは、開き山かっこ（ "<"）、最初に必要なオクテットのオクテット位置、ピリオド、必要な最大オクテット数、および終わり山かっこ（ ">"）をパーツ指定子に追加することによって行われます。開始オクテットがテキストの終わりを超えている場合、空の文字列が返されます。
Any partial fetch that attempts to read beyond the end of the text is truncated as appropriate. A partial fetch that starts at octet 0 is returned as a partial fetch, even if this truncation happened.
テキストの終わりを超えて読み取ろうとする部分フェッチは、必要に応じて切り捨てられます。この切り捨てが発生した場合でも、オクテット0で始まる部分フェッチは部分フェッチとして返されます。
Note: This means that BODY[]<0.2048> of a 1500-octet message will return BODY[]<0> with a literal of size 1500, not BODY[].
注：これは、1500オクテットメッセージのBODY [] <0.2048>が、BODY []ではなく、サイズ1500のリテラルを含むBODY [] <0>を返すことを意味します。
Note: A substring fetch of a HEADER.FIELDS or HEADER.FIELDS.NOT part specifier is calculated after subsetting the header.
注：HEADER.FIELDSまたはHEADER.FIELDS.NOTパーツ指定子の部分文字列フェッチは、ヘッダーをサブセット化した後に計算されます。
The \Seen flag is implicitly set; if this causes the flags to change, they SHOULD be included as part of the FETCH responses.
\ Seenフラグは暗黙的に設定されます。これによりフラグが変更される場合は、それらをFETCH応答の一部として含める必要があります（SHOULD）。
BODY.PEEK[<section>]<<partial>> An alternate form of BODY[<section>] that does not implicitly set the \Seen flag.
BODY.PEEK [<セクション>] <<部分>>暗黙的に\ Seenフラグを設定しないBODY [<セクション>]の代替形式。
BODYSTRUCTURE The [MIME-IMB] body structure of the message. This is computed by the server by parsing the [MIME-IMB] header fields in the [RFC-2822] header and [MIME-IMB] headers.
BODYSTRUCTUREメッセージの[MIME-IMB]本文構造。これは、[RFC-2822]ヘッダーと[MIME-IMB]ヘッダーの[MIME-IMB]ヘッダーフィールドを解析することにより、サーバーによって計算されます。
ENVELOPE The envelope structure of the message. This is computed by the server by parsing the [RFC-2822] header into the component parts, defaulting various fields as necessary.
ENVELOPEメッセージのエンベロープ構造。これは、[RFC-2822]ヘッダーをコンポーネント部分に解析し、必要に応じてさまざまなフィールドをデフォルト設定することにより、サーバーによって計算されます。
FLAGS The flags that are set for this message.
FLAGSこのメッセージに設定されるフラグ。
INTERNALDATE The internal date of the message.
INTERNALDATEメッセージの内部日付。
RFC822 Functionally equivalent to BODY[], differing in the syntax of the resulting untagged FETCH data (RFC822 is returned).
RFC822機能的にはBODY []と同等であり、タグ付けされていないFETCHデータの構文が異なります（RFC822が返されます）。
RFC822.HEADER Functionally equivalent to BODY.PEEK[HEADER], differing in the syntax of the resulting untagged FETCH data (RFC822.HEADER is returned).
RFC822.HEADER BODY.PEEK [HEADER]と機能的に同等であり、タグなしFETCHデータの構文が異なります（RFC822.HEADERが返されます）。
RFC822.SIZE The [RFC-2822] size of the message.
RFC822.SIZEメッセージの[RFC-2822]サイズ。
RFC822.TEXT Functionally equivalent to BODY[TEXT], differing in the syntax of the resulting untagged FETCH data (RFC822.TEXT is returned).
RFC822.TEXT機能的にはBODY [TEXT]と同等であり、タグ付けされていないFETCHデータの構文が異なります（RFC822.TEXTが返されます）。
UID The unique identifier for the message.
UIDメッセージの一意の識別子。
Example: C: A654 FETCH 2:4 (FLAGS BODY[HEADER.FIELDS (DATE FROM)])
S: * 2 FETCH ....
S: * 3 FETCH ....
S: * 4 FETCH ....
S: A654 OK FETCH completed
Arguments: sequence set message data item name value for message data item
引数：メッセージデータアイテムのシーケンスセットメッセージデータアイテム名の値
Responses: untagged responses: FETCH
応答：タグなし応答：FETCH
Result: OK - store completed
NO - store error: can't store that data
BAD - command unknown or arguments invalid
The STORE command alters data associated with a message in the mailbox. Normally, STORE will return the updated value of the data with an untagged FETCH response. A suffix of ".SILENT" in the data item name prevents the untagged FETCH, and the server SHOULD assume that the client has determined the updated value itself or does not care about the updated value.
STOREコマンドは、メールボックス内のメッセージに関連付けられたデータを変更します。通常、STOREはタグの付いていないFETCH応答でデータの更新された値を返します。データ項目名に「.SILENT」という接尾辞を付けると、タグなしのFETCHが防止され、サーバーは、クライアントが更新された値自体を決定したか、更新された値を気にしないと想定する必要があります。
Note: Regardless of whether or not the ".SILENT" suffix was used, the server SHOULD send an untagged FETCH response if a change to a message's flags from an external source is observed. The intent is that the status of the flags is determinate without a race condition.
注：「.SILENT」サフィックスが使用されたかどうかに関係なく、外部ソースからのメッセージのフラグへの変更が観察された場合、サーバーはタグなしFETCH応答を送信する必要があります（SHOULD）。その意図は、フラグのステータスが競合状態なしで確定していることです。
The currently defined data items that can be stored are:
保存できる現在定義されているデータ項目は次のとおりです。
FLAGS <flag list> Replace the flags for the message (other than \Recent) with the argument. The new value of the flags is returned as if a FETCH of those flags was done.
FLAGS <フラグリスト>メッセージのフラグ（\ Recent以外）を引数で置き換えます。フラグの新しい値は、それらのフラグのFETCHが行われたかのように返されます。
FLAGS.SILENT <flag list> Equivalent to FLAGS, but without returning a new value.
FLAGS.SILENT <フラグリスト> FLAGSと同じですが、新しい値を返しません。
+FLAGS <flag list> Add the argument to the flags for the message. The new value of the flags is returned as if a FETCH of those flags was done.
+ FLAGS <フラグリスト>メッセージのフラグに引数を追加します。フラグの新しい値は、それらのフラグのFETCHが行われたかのように返されます。
+FLAGS.SILENT <flag list> Equivalent to +FLAGS, but without returning a new value.
+ FLAGS.SILENT <フラグリスト> + FLAGSと同じですが、新しい値を返しません。
-FLAGS <flag list> Remove the argument from the flags for the message. The new value of the flags is returned as if a FETCH of those flags was done.
-FLAGS <フラグリスト>メッセージのフラグから引数を削除します。フラグの新しい値は、それらのフラグのFETCHが行われたかのように返されます。
-FLAGS.SILENT <flag list> Equivalent to -FLAGS, but without returning a new value.
-FLAGS.SILENT <フラグリスト> -FLAGSと同じですが、新しい値を返しません。
Example: C: A003 STORE 2:4 +FLAGS (\Deleted)
S: * 2 FETCH (FLAGS (\Deleted \Seen))
S: * 3 FETCH (FLAGS (\Deleted))
S: * 4 FETCH (FLAGS (\Deleted \Flagged \Seen))
S: A003 OK STORE completed
Arguments: sequence set mailbox name
引数：シーケンスセットのメールボックス名
Responses: no specific responses for this command
応答：このコマンドに対する特定の応答はありません
Result: OK - copy completed NO - copy error: can't copy those messages or to that name BAD - command unknown or arguments invalid
結果：OK-コピー完了NO-コピーエラー：それらのメッセージまたはその名前にコピーできませんBAD-不明なコマンドまたは引数が無効です
The COPY command copies the specified message(s) to the end of the specified destination mailbox. The flags and internal date of the message(s) SHOULD be preserved, and the Recent flag SHOULD be set, in the copy.
COPYコマンドは、指定されたメッセージを指定された宛先メールボックスの最後にコピーします。コピーでは、メッセージのフラグと内部日付を保持する必要があり、Recentフラグを設定する必要があります（SHOULD）。
If the destination mailbox does not exist, a server SHOULD return an error. It SHOULD NOT automatically create the mailbox. Unless it is certain that the destination mailbox can not be created, the server MUST send the response code "[TRYCREATE]" as the prefix of the text of the tagged NO response. This gives a hint to the client that it can attempt a CREATE command and retry the COPY if the CREATE is successful.
宛先メールボックスが存在しない場合、サーバーはエラーを返す必要があります（SHOULD）。自動的にメールボックスを作成するべきではありません。宛先メールボックスが作成できないことが確実でない限り、サーバーはタグ付きNO応答のテキストの接頭辞として応答コード「[TRYCREATE]」を送信する必要があります。これにより、クライアントがCREATEコマンドを試行し、CREATEが成功した場合はCOPYを再試行できるというヒントがクライアントに与えられます。
If the COPY command is unsuccessful for any reason, server implementations MUST restore the destination mailbox to its state before the COPY attempt.
何らかの理由でCOPYコマンドが失敗した場合、サーバーの実装は宛先メールボックスをCOPY試行前の状態に復元する必要があります。
Example: C: A003 COPY 2:4 MEETING
S: A003 OK COPY completed
Arguments: command name command arguments
引数：コマンド名コマンド引数
Responses: untagged responses: FETCH, SEARCH
応答：タグなしの応答：FETCH、SEARCH
Result: OK - UID command completed NO - UID command error BAD - command unknown or arguments invalid
結果：OK-UIDコマンドが完了したNO-UIDコマンドエラーBAD-不明なコマンドまたは引数が無効
The UID command has two forms. In the first form, it takes as its arguments a COPY, FETCH, or STORE command with arguments appropriate for the associated command. However, the numbers in the sequence set argument are unique identifiers instead of message sequence numbers. Sequence set ranges are permitted, but there is no guarantee that unique identifiers will be contiguous.
UIDコマンドには2つの形式があります。最初の形式では、関連するコマンドに適切な引数を持つCOPY、FETCH、またはSTOREコマンドを引数として受け取ります。ただし、シーケンスセット引数の番号は、メッセージシーケンス番号ではなく、一意の識別子です。シーケンスセットの範囲は許可されますが、一意の識別子が連続している保証はありません。
A non-existent unique identifier is ignored without any error message generated. Thus, it is possible for a UID FETCH command to return an OK without any data or a UID COPY or UID STORE to return an OK without performing any operations.
存在しない一意の識別子は無視され、エラーメッセージは生成されません。したがって、UID FETCHコマンドがデータなしでOKを返すか、UID COPYまたはUID STOREが操作を実行せずにOKを返すことが可能です。
In the second form, the UID command takes a SEARCH command with SEARCH command arguments. The interpretation of the arguments is the same as with SEARCH; however, the numbers returned in a SEARCH response for a UID SEARCH command are unique identifiers instead of message sequence numbers. For example, the command UID SEARCH 1:100 UID 443:557 returns the unique identifiers corresponding to the intersection of two sequence sets, the message sequence number range 1:100 and the UID range 443:557.
2番目の形式では、UIDコマンドはSEARCHコマンド引数を指定したSEARCHコマンドを取ります。引数の解釈は、SEARCHと同じです。ただし、UID SEARCHコマンドのSEARCH応答で返される番号は、メッセージシーケンス番号ではなく一意の識別子です。たとえば、コマンドUID SEARCH 1：100 UID 443：557は、2つのシーケンスセット（メッセージシーケンス番号の範囲1：100とUIDの範囲443：557）の共通部分に対応する一意の識別子を返します。
Note: in the above example, the UID range 443:557 appears. The same comment about a non-existent unique identifier being ignored without any error message also applies here. Hence, even if neither UID 443 or 557 exist, this range is valid and would include an existing UID 495.
注：上記の例では、UID範囲443：557が表示されます。エラーメッセージなしで存在しない一意の識別子が無視されるという同じコメントがここでも当てはまります。したがって、UID 443も557も存在しない場合でも、この範囲は有効であり、既存のUID 495が含まれます。
Also note that a UID range of 559:* always includes the UID of the last message in the mailbox, even if 559 is higher than any assigned UID value. This is because the contents of a range are independent of the order of the range endpoints. Thus, any UID range with * as one of the endpoints indicates at least one message (the message with the highest numbered UID), unless the mailbox is empty.
また、559：*のUID範囲には、559が割り当てられたUID値よりも大きい場合でも、メールボックス内の最後のメッセージのUIDが常に含まれることに注意してください。これは、範囲の内容が範囲の端点の順序に依存しないためです。したがって、メールボックスが空でない限り、エンドポイントの1つとして*を含むUID範囲は、少なくとも1つのメッセージ（UIDが最も大きいメッセージ）を示します。
The number after the "*" in an untagged FETCH response is always a message sequence number, not a unique identifier, even for a UID command response. However, server implementations MUST implicitly include the UID message data item as part of any FETCH response caused by a UID command, regardless of whether a UID was specified as a message data item to the FETCH.
タグなしFETCH応答の「*」の後の番号は、UIDコマンド応答であっても、一意の識別子ではなく、常にメッセージシーケンス番号です。ただし、サーバー実装は、UIDがメッセージデータ項目としてFETCHに指定されているかどうかに関係なく、UIDコマンドによって引き起こされるすべてのFETCH応答の一部として暗黙的にUIDメッセージデータ項目を含める必要があります。
Note: The rule about including the UID message data item as part of a FETCH response primarily applies to the UID FETCH and UID STORE commands, including a UID FETCH command that does not include UID as a message data item. Although it is unlikely that the other UID commands will cause an untagged FETCH, this rule applies to these commands as well.
注：UIDメッセージデータ項目をFETCH応答の一部として含めることに関する規則は、メッセージデータ項目としてUIDを含まないUID FETCHコマンドを含む、UID FETCHおよびUID STOREコマンドに主に適用されます。他のUIDコマンドがタグなしFETCHを引き起こす可能性は低いですが、このルールはこれらのコマンドにも適用されます。
Example: C: A999 UID FETCH 4827313:4828442 FLAGS
S: * 23 FETCH (FLAGS (\Seen) UID 4827313)
S: * 24 FETCH (FLAGS (\Seen) UID 4827943)
S: * 25 FETCH (FLAGS (\Seen) UID 4828442)
S: A999 OK UID FETCH completed
Arguments: implementation defined
引数：定義された実装
Responses: implementation defined
応答：実装定義
Result: OK - command completed NO - failure BAD - command unknown or arguments invalid
結果：OK-コマンド完了NO-失敗BAD-コマンドが不明、または引数が無効
Any command prefixed with an X is an experimental command. Commands which are not part of this specification, a standard or standards-track revision of this specification, or an IESG-approved experimental protocol, MUST use the X prefix.
Xで始まるコマンドはすべて実験的なコマンドです。この仕様の一部ではないコマンド、この仕様の標準または標準トラックリビジョン、またはIESG承認の実験プロトコルでは、Xプレフィックスを使用する必要があります。
Any added untagged responses issued by an experimental command MUST also be prefixed with an X. Server implementations MUST NOT send any such untagged responses, unless the client requested it by issuing the associated experimental command.
実験的なコマンドによって発行されたタグなしの応答も追加します。Xをプレフィックスとして付ける必要があります。サーバー実装は、クライアントが関連する実験的なコマンドを発行して要求しない限り、そのようなタグなしの応答を送信してはなりません。
Example: C: a441 CAPABILITY
S: * CAPABILITY IMAP4rev1 XPIG-LATIN
S: a441 OK CAPABILITY completed
C: A442 XPIG-LATIN
S: * XPIG-LATIN ow-nay eaking-spay ig-pay atin-lay
S: A442 OK XPIG-LATIN ompleted-cay
Server responses are in three forms: status responses, server data, and command continuation request. The information contained in a server response, identified by "Contents:" in the response descriptions below, is described by function, not by syntax. The precise syntax of server responses is described in the Formal Syntax section.
サーバーの応答は、ステータス応答、サーバーデータ、およびコマンド継続要求の3つの形式です。以下の応答の説明の「内容：」で識別されるサーバー応答に含まれる情報は、構文ではなく機能別に記述されています。サーバー応答の正確な構文は、「正式な構文」セクションで説明されています。
The client MUST be prepared to accept any response at all times.
クライアントは常に応答を受け入れる準備ができていなければなりません。
Status responses can be tagged or untagged. Tagged status responses indicate the completion result (OK, NO, or BAD status) of a client command, and have a tag matching the command.
ステータス応答にはタグを付けることも、付けないこともできます。タグ付きステータス応答は、クライアントコマンドの完了結果（OK、NO、またはBADステータス）を示し、コマンドと一致するタグがあります。
Some status responses, and all server data, are untagged. An untagged response is indicated by the token "*" instead of a tag. Untagged status responses indicate server greeting, or server status that does not indicate the completion of a command (for example, an impending system shutdown alert). For historical reasons, untagged server data responses are also called "unsolicited data", although strictly speaking, only unilateral server data is truly "unsolicited".
一部のステータス応答とすべてのサーバーデータにはタグが付けられていません。タグなしの応答は、タグの代わりにトークン「*」で示されます。タグなしのステータス応答は、サーバーグリーティング、またはコマンドの完了を示さないサーバーステータス（たとえば、差し迫ったシステムシャットダウンアラート）を示します。歴史的な理由から、タグなしのサーバーデータ応答は「非請求データ」とも呼ばれますが、厳密には、一方的なサーバーデータのみが本当に「非請求」です。
Certain server data MUST be recorded by the client when it is received; this is noted in the description of that data. Such data conveys critical information which affects the interpretation of all subsequent commands and responses (e.g., updates reflecting the creation or destruction of messages).
特定のサーバーデータは、受信時にクライアントによって記録される必要があります。これは、そのデータの説明に記載されています。そのようなデータは、後続のすべてのコマンドと応答の解釈に影響を与える重要な情報を伝えます（たとえば、メッセージの作成または破棄を反映する更新）。
Other server data SHOULD be recorded for later reference; if the client does not need to record the data, or if recording the data has no obvious purpose (e.g., a SEARCH response when no SEARCH command is in progress), the data SHOULD be ignored.
他のサーバーデータは、後で参照できるように記録する必要があります。クライアントがデータを記録する必要がない場合、またはデータの記録に明確な目的がない場合（たとえば、SEARCHコマンドが進行中でないときのSEARCH応答）、データは無視されるべきです（SHOULD）。
An example of unilateral untagged server data occurs when the IMAP connection is in the selected state. In the selected state, the server checks the mailbox for new messages as part of command execution. Normally, this is part of the execution of every command; hence, a NOOP command suffices to check for new messages. If new messages are found, the server sends untagged EXISTS and RECENT responses reflecting the new size of the mailbox. Server implementations that offer multiple simultaneous access to the same mailbox SHOULD also send appropriate unilateral untagged FETCH and EXPUNGE responses if another agent changes the state of any message flags or expunges any messages.
IMAP接続が選択された状態にあるときに、タグなしの一方的なサーバーデータの例が発生します。選択された状態では、サーバーはコマンド実行の一部として新しいメッセージがないかメールボックスをチェックします。通常、これはすべてのコマンドの実行の一部です。したがって、新しいメッセージをチェックするにはNOOPコマンドで十分です。新しいメッセージが見つかった場合、サーバーはタグなしのEXISTSおよびRECENT応答を送信し、メールボックスの新しいサイズを反映します。同じメールボックスへの複数の同時アクセスを提供するサーバー実装は、別のエージェントがメッセージフラグの状態を変更したり、メッセージを消去したりした場合に、適切な一方的なタグなしFETCHおよびEXPUNGE応答も送信する必要があります。
Command continuation request responses use the token "+" instead of a tag. These responses are sent by the server to indicate acceptance of an incomplete client command and readiness for the remainder of the command.
コマンド継続要求応答は、タグの代わりにトークン「+」を使用します。これらの応答は、不完全なクライアントコマンドの受け入れと残りのコマンドの準備を示すためにサーバーから送信されます。
Status responses are OK, NO, BAD, PREAUTH and BYE. OK, NO, and BAD can be tagged or untagged. PREAUTH and BYE are always untagged.
ステータス応答は、OK、NO、BAD、PREAUTH、BYEです。 OK、NO、BADにはタグを付けることも付けないこともできます。 PREAUTHとBYEは常にタグなしです。
Status responses MAY include an OPTIONAL "response code". A response code consists of data inside square brackets in the form of an atom, possibly followed by a space and arguments. The response code contains additional information or status codes for client software beyond the OK/NO/BAD condition, and are defined when there is a specific action that a client can take based upon the additional information.
ステータス応答には、オプションの「応答コード」が含まれる場合があります。応答コードは、角括弧内のアトムの形式のデータで構成され、スペースと引数が続く場合があります。応答コードには、OK / NO / BAD条件を超えたクライアントソフトウェアの追加情報またはステータスコードが含まれ、クライアントが追加情報に基づいて実行できる特定のアクションがある場合に定義されます。
The currently defined response codes are:
現在定義されている応答コードは次のとおりです。
ALERT
アラート
The human-readable text contains a special alert that MUST be presented to the user in a fashion that calls the user's attention to the message.
The human-readable text contains a special alert that MUST be presented to the user in a fashion that calls the user's attention to the message.
BADCHARSET
BADCHARSET
Optionally followed by a parenthesized list of charsets. A SEARCH failed because the given charset is not supported by this implementation. If the optional list of charsets is given, this lists the charsets that are supported by this implementation.
オプションで、括弧で囲まれた文字セットのリストが続きます。指定された文字セットがこの実装でサポートされていないため、検索が失敗しました。文字セットのオプションのリストが指定されている場合、これは、この実装でサポートされている文字セットをリストします。
CAPABILITY
能力
Followed by a list of capabilities. This can appear in the initial OK or PREAUTH response to transmit an initial capabilities list. This makes it unnecessary for a client to send a separate CAPABILITY command if it recognizes this response.
機能のリストが続きます。これは、最初の機能リストを送信するための最初のOKまたはPREAUTH応答に表示されます。これにより、クライアントがこの応答を認識した場合に、別のCAPABILITYコマンドを送信する必要がなくなります。
PARSE
パース
The human-readable text represents an error in parsing the [RFC-2822] header or [MIME-IMB] headers of a message in the mailbox.
人間が読めるテキストは、メールボックス内のメッセージの[RFC-2822]ヘッダーまたは[MIME-IMB]ヘッダーの解析におけるエラーを表します。
PERMANENTFLAGS
PERMANENTFLAGS
Followed by a parenthesized list of flags, indicates which of the known flags the client can change permanently. Any flags that are in the FLAGS untagged response, but not the PERMANENTFLAGS list, can not be set permanently. If the client attempts to STORE a flag that is not in the PERMANENTFLAGS list, the server will either ignore the change or store the state change for the remainder of the current session only. The PERMANENTFLAGS list can also include the special flag \*, which indicates that it is possible to create new keywords by attempting to store those flags in the mailbox.
括弧で囲まれたフラグのリストが後に続き、クライアントが永続的に変更できる既知のフラグを示します。 FLAGSタグなし応答にあるが、PERMANENTFLAGSリストにないフラグは、永続的に設定することはできません。クライアントがPERMANENTFLAGSリストにないフラグをSTOREしようとすると、サーバーは変更を無視するか、現在のセッションの残りの部分についてのみ状態の変更を保存します。 PERMANENTFLAGSリストには、特別なフラグ\ *を含めることもできます。これは、これらのフラグをメールボックスに保存しようとすることで新しいキーワードを作成できることを示します。
READ-ONLY
読み取り専用
The mailbox is selected read-only, or its access while selected has changed from read-write to read-only.
メールボックスが読み取り専用で選択されているか、選択中のメールボックスのアクセスが読み取り/書き込みから読み取り専用に変更されました。
READ-WRITE
読み書き
The mailbox is selected read-write, or its access while selected has changed from read-only to read-write.
メールボックスが読み取り/書き込みとして選択されているか、選択中のメールボックスのアクセスが読み取り専用から読み取り/書き込みに変更されました。
TRYCREATE
TRYCREATE
An APPEND or COPY attempt is failing because the target mailbox does not exist (as opposed to some other reason). This is a hint to the client that the operation can succeed if the mailbox is first created by the CREATE command.
他の理由とは対照的に、ターゲットメールボックスが存在しないため、APPENDまたはCOPYの試行が失敗しています。これは、メールボックスが最初にCREATEコマンドによって作成された場合に操作が成功する可能性があるというクライアントへのヒントです。
UIDNEXT
UIDNEXT
Followed by a decimal number, indicates the next unique identifier value. Refer to section 2.3.1.1 for more information.
10進数が後に続く、次の固有ID値を示します。詳細については、セクション2.3.1.1を参照してください。
UIDVALIDITY
UIDVALIDITY
Followed by a decimal number, indicates the unique identifier validity value. Refer to section 2.3.1.1 for more information.
10進数が後に続く、一意の識別子の有効性の値を示します。詳細については、セクション2.3.1.1を参照してください。
UNSEEN
見えない
Followed by a decimal number, indicates the number of the first message without the \Seen flag set.
10進数が後に続く、\ Seenフラグが設定されていない最初のメッセージの番号を示します。
Additional response codes defined by particular client or server implementations SHOULD be prefixed with an "X" until they are added to a revision of this protocol. Client implementations SHOULD ignore response codes that they do not recognize.
Additional response codes defined by particular client or server implementations SHOULD be prefixed with an "X" until they are added to a revision of this protocol. Client implementations SHOULD ignore response codes that they do not recognize.
Contents: OPTIONAL response code human-readable text
内容：オプションの応答コード人間が読めるテキスト
The OK response indicates an information message from the server. When tagged, it indicates successful completion of the associated command. The human-readable text MAY be presented to the user as an information message. The untagged form indicates an information-only message; the nature of the information MAY be indicated by a response code.
OK応答は、サーバーからの情報メッセージを示します。タグ付けされている場合、関連するコマンドが正常に完了したことを示します。人間が読めるテキストは、情報メッセージとしてユーザーに提示される場合があります。タグなしのフォームは、情報のみのメッセージを示します。情報の性質は、応答コードによって示される場合があります。
The untagged form is also used as one of three possible greetings at connection startup. It indicates that the connection is not yet authenticated and that a LOGIN command is needed.
タグなしフォームは、接続の開始時に3つの可能なグリーティングの1つとしても使用されます。これは、接続がまだ認証されておらず、LOGINコマンドが必要であることを示しています。
Example: S: * OK IMAP4rev1 server ready
C: A001 LOGIN fred blurdybloop
S: * OK [ALERT] System shutdown in 10 minutes
S: A001 OK LOGIN Completed
Contents: OPTIONAL response code human-readable text
内容：オプションの応答コード人間が読めるテキスト
The NO response indicates an operational error message from the server. When tagged, it indicates unsuccessful completion of the associated command. The untagged form indicates a warning; the command can still complete successfully. The human-readable text describes the condition.
NO応答は、サーバーからの操作エラーメッセージを示します。タグ付けされている場合、関連するコマンドが正常に完了しなかったことを示します。タグなしのフォームは警告を示します。コマンドはまだ正常に完了することができます。人間が読めるテキストで状態を説明します。
Example: C: A222 COPY 1:2 owatagusiam
S: * NO Disk is 98% full, please delete unnecessary data
S: A222 OK COPY completed
C: A223 COPY 3:200 blurdybloop
S: * NO Disk is 98% full, please delete unnecessary data
S: * NO Disk is 99% full, please delete unnecessary data
S: A223 NO COPY failed: disk is full
Contents: OPTIONAL response code human-readable text
内容：オプションの応答コード人間が読めるテキスト
The BAD response indicates an error message from the server. When tagged, it reports a protocol-level error in the client's command; the tag indicates the command that caused the error. The untagged form indicates a protocol-level error for which the associated command can not be determined; it can also indicate an internal server failure. The human-readable text describes the condition.
BAD応答は、サーバーからのエラーメッセージを示します。タグ付けされると、クライアントのコマンドでプロトコルレベルのエラーを報告します。タグは、エラーの原因となったコマンドを示します。タグなしの形式は、関連するコマンドを特定できないプロトコルレベルのエラーを示します。また、内部サーバーの障害を示している場合もあります。人間が読めるテキストで状態を説明します。
Example: C: ...very long command line...
S: * BAD Command line too long
C: ...empty line...
S: * BAD Empty command line
C: A443 EXPUNGE
S: * BAD Disk crash, attempting salvage to a new disk!
S: * OK Salvage successful, no data lost
S: A443 OK Expunge completed
Contents: OPTIONAL response code human-readable text
内容：オプションの応答コード人間が読めるテキスト
The PREAUTH response is always untagged, and is one of three possible greetings at connection startup. It indicates that the connection has already been authenticated by external means; thus no LOGIN command is needed.
PREAUTH応答は常にタグなしであり、接続の開始時に3つの可能なグリーティングの1つです。これは、接続がすでに外部手段によって認証されていることを示しています。したがって、LOGINコマンドは必要ありません。
Example: S: * PREAUTH IMAP4rev1 server logged in as Smith
Contents: OPTIONAL response code human-readable text
内容：オプションの応答コード人間が読めるテキスト
The BYE response is always untagged, and indicates that the server is about to close the connection. The human-readable text MAY be displayed to the user in a status report by the client. The BYE response is sent under one of four conditions:
BYE応答は常にタグなしであり、サーバーが接続を閉じようとしていることを示します。人間が読めるテキストは、クライアントによるステータスレポートでユーザーに表示される場合があります。 BYE応答は、次の4つの条件のいずれかで送信されます。
1) as part of a normal logout sequence. The server will close the connection after sending the tagged OK response to the LOGOUT command.
1）通常のログアウトシーケンスの一部として。タグ付きOK応答をLOGOUTコマンドに送信した後、サーバーは接続を閉じます。
2) as a panic shutdown announcement. The server closes the connection immediately.
2）パニックシャットダウンのアナウンスとして。サーバーは接続をすぐに閉じます。
3) as an announcement of an inactivity autologout. The server closes the connection immediately.
3）非アクティブな自動ログアウトのアナウンスとして。サーバーは接続をすぐに閉じます。
4) as one of three possible greetings at connection startup, indicating that the server is not willing to accept a connection from this client. The server closes the connection immediately.
4）接続開始時の3つの可能な挨拶の1つとして、サーバーがこのクライアントからの接続を受け入れる用意がないことを示します。サーバーは接続をすぐに閉じます。
The difference between a BYE that occurs as part of a normal LOGOUT sequence (the first case) and a BYE that occurs because of a failure (the other three cases) is that the connection closes immediately in the failure case. In all cases the client SHOULD continue to read response data from the server until the connection is closed; this will ensure that any pending untagged or completion responses are read and processed.
The difference between a BYE that occurs as part of a normal LOGOUT sequence (the first case) and a BYE that occurs because of a failure (the other three cases) is that the connection closes immediately in the failure case. In all cases the client SHOULD continue to read response data from the server until the connection is closed; this will ensure that any pending untagged or completion responses are read and processed.
Example: S: * BYE Autologout; idle for too long
These responses are always untagged. This is how server and mailbox status data are transmitted from the server to the client. Many of these responses typically result from a command with the same name.
これらの応答には常にタグが付けられていません。これは、サーバーとメールボックスのステータスデータがサーバーからクライアントに送信される方法です。これらの応答の多くは、通常、同じ名前のコマンドから発生します。
Contents: capability listing
内容：機能リスト
The CAPABILITY response occurs as a result of a CAPABILITY command. The capability listing contains a space-separated listing of capability names that the server supports. The capability listing MUST include the atom "IMAP4rev1".
CAPABILITY応答は、CAPABILITYコマンドの結果として発生します。機能リストには、サーバーがサポートする機能名のスペース区切りのリストが含まれています。機能リストには、アトム「IMAP4rev1」を含める必要があります。
In addition, client and server implementations MUST implement the STARTTLS, LOGINDISABLED, and AUTH=PLAIN (described in [IMAP-TLS]) capabilities. See the Security Considerations section for important information.
さらに、クライアントとサーバーの実装は、STARTTLS、LOGINDISABLED、およびAUTH = PLAIN（[IMAP-TLS]で説明）機能を実装する必要があります。重要な情報については、セキュリティに関する考慮事項のセクションを参照してください。
A capability name which begins with "AUTH=" indicates that the server supports that particular authentication mechanism.
「AUTH =」で始まる機能名は、サーバーがその特定の認証メカニズムをサポートしていることを示します。
The LOGINDISABLED capability indicates that the LOGIN command is disabled, and that the server will respond with a tagged NO response to any attempt to use the LOGIN command even if the user name and password are valid. An IMAP client MUST NOT issue the LOGIN command if the server advertises the LOGINDISABLED capability.
LOGINDISABLED機能は、LOGINコマンドが無効であること、およびユーザー名とパスワードが有効であっても、サーバーがLOGINコマンドを使用しようとすると、タグ付きのNO応答で応答することを示します。サーバーがLOGINDISABLED機能をアドバタイズする場合、IMAPクライアントはLOGINコマンドを発行してはなりません（MUST NOT）。
Other capability names indicate that the server supports an extension, revision, or amendment to the IMAP4rev1 protocol. Server responses MUST conform to this document until the client issues a command that uses the associated capability.
Other capability names indicate that the server supports an extension, revision, or amendment to the IMAP4rev1 protocol. Server responses MUST conform to this document until the client issues a command that uses the associated capability.
Capability names MUST either begin with "X" or be standard or standards-track IMAP4rev1 extensions, revisions, or amendments registered with IANA. A server MUST NOT offer unregistered or non-standard capability names, unless such names are prefixed with an "X".
機能名は、「X」で始まるか、IANAに登録された標準または標準トラックのIMAP4rev1拡張、改訂、または修正のいずれかである必要があります。サーバーは、そのような名前の前に「X」が付いていない限り、未登録または非標準の機能名を提供してはなりません（MUST NOT）。
Client implementations SHOULD NOT require any capability name other than "IMAP4rev1", and MUST ignore any unknown capability names.
クライアントの実装では、「IMAP4rev1」以外の機能名は必要ありません（SHOULD NOT）。不明な機能名は無視する必要があります。
A server MAY send capabilities automatically, by using the CAPABILITY response code in the initial PREAUTH or OK responses, and by sending an updated CAPABILITY response code in the tagged OK response as part of a successful authentication. It is unnecessary for a client to send a separate CAPABILITY command if it recognizes these automatic capabilities.
サーバーは、最初のPREAUTHまたはOK応答でCAPABILITY応答コードを使用し、認証の成功の一部としてタグ付きOK応答で更新されたCAPABILITY応答コードを送信することにより、機能を自動的に送信できます。クライアントがこれらの自動機能を認識する場合、クライアントが個別のCAPABILITYコマンドを送信する必要はありません。
Example: S: * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI XPIG-LATIN
Contents: name attributes hierarchy delimiter name
内容：名前属性階層区切り文字名
The LIST response occurs as a result of a LIST command. It returns a single name that matches the LIST specification. There can be multiple LIST responses for a single LIST command.
LIST応答は、LISTコマンドの結果として発生します。 LIST指定に一致する単一の名前を返します。 1つのLISTコマンドに対して複数のLIST応答が存在する可能性があります。
Four name attributes are defined:
4つの名前属性が定義されています。
\Noinferiors It is not possible for any child levels of hierarchy to exist under this name; no child levels exist now and none can be created in the future.
\ Noinferiors階層の子レベルがこの名前で存在することはできません。現在、子レベルは存在せず、将来作成することもできません。
\Noselect It is not possible to use this name as a selectable mailbox.
\ Noselectこの名前を選択可能なメールボックスとして使用することはできません。
\Marked The mailbox has been marked "interesting" by the server; the mailbox probably contains messages that have been added since the last time the mailbox was selected.
\ Markedメールボックスはサーバーによって「興味深い」とマークされています。メールボックスには、メールボックスが最後に選択されてから追加されたメッセージが含まれている可能性があります。
\Unmarked The mailbox does not contain any additional messages since the last time the mailbox was selected.
\ Unmarked前回メールボックスが選択されてから、メールボックスには追加のメッセージが含まれていません。
If it is not feasible for the server to determine whether or not the mailbox is "interesting", or if the name is a \Noselect name, the server SHOULD NOT send either \Marked or \Unmarked.
メールボックスが「興味深い」かどうかをサーバーが判断できない場合、または名前が\ Noselectの名前である場合、サーバーは\ Markedまたは\ Unmarkedを送信しないでください。
The hierarchy delimiter is a character used to delimit levels of hierarchy in a mailbox name. A client can use it to create child mailboxes, and to search higher or lower levels of naming hierarchy. All children of a top-level hierarchy node MUST use the same separator character. A NIL hierarchy delimiter means that no hierarchy exists; the name is a "flat" name.
階層区切り文字は、メールボックス名の階層のレベルを区切るために使用される文字です。クライアントはこれを使用して子メールボックスを作成し、名前付け階層の上位または下位レベルを検索できます。トップレベルの階層ノードのすべての子は、同じ区切り文字を使用する必要があります。 NIL階層区切り文字は、階層が存在しないことを意味します。名前は「フラット」な名前です。
The name represents an unambiguous left-to-right hierarchy, and MUST be valid for use as a reference in LIST and LSUB commands. Unless \Noselect is indicated, the name MUST also be valid as an argument for commands, such as SELECT, that accept mailbox names.
名前は明確な左から右の階層を表し、LISTおよびLSUBコマンドでの参照としての使用に有効でなければなりません。 \ Noselectが指定されていない限り、名前は、メールボックス名を受け入れるSELECTなどのコマンドの引数としても有効でなければなりません。
Example: S: * LIST (\Noselect) "/" ~/Mail/foo
Contents: name attributes hierarchy delimiter name
内容：名前属性階層区切り文字名
The LSUB response occurs as a result of an LSUB command. It returns a single name that matches the LSUB specification. There can be multiple LSUB responses for a single LSUB command. The data is identical in format to the LIST response.
LSUB応答は、LSUBコマンドの結果として発生します。 LSUB仕様に一致する単一の名前を返します。 1つのLSUBコマンドに対して複数のLSUB応答が存在する可能性があります。データの形式はLIST応答と同じです。
Example: S: * LSUB () "." #news.comp.mail.misc
Contents: name status parenthesized list
目次：名前ステータスの括弧付きリスト
The STATUS response occurs as a result of an STATUS command. It returns the mailbox name that matches the STATUS specification and the requested mailbox status information.
STATUS応答は、STATUSコマンドの結果として発生します。 STATUS指定と要求されたメールボックスステータス情報に一致するメールボックス名を返します。
Example: S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292)
Contents: zero or more numbers
内容：0個以上の数字
The SEARCH response occurs as a result of a SEARCH or UID SEARCH command. The number(s) refer to those messages that match the search criteria. For SEARCH, these are message sequence numbers; for UID SEARCH, these are unique identifiers. Each number is delimited by a space.
SEARCH応答は、SEARCHまたはUID SEARCHコマンドの結果として発生します。番号は、検索条件に一致するメッセージを示します。 SEARCHの場合、これらはメッセージのシーケンス番号です。 UID SEARCHの場合、これらは一意の識別子です。各番号はスペースで区切られます。
Example: S: * SEARCH 2 3 6
Contents: flag parenthesized list
目次：括弧付きリスト
The FLAGS response occurs as a result of a SELECT or EXAMINE command. The flag parenthesized list identifies the flags (at a minimum, the system-defined flags) that are applicable for this mailbox. Flags other than the system flags can also exist, depending on server implementation.
FLAGS応答は、SELECTまたはEXAMINEコマンドの結果として発生します。フラグの括弧で囲まれたリストは、このメールボックスに適用可能なフラグ（少なくとも、システム定義のフラグ）を識別します。サーバーの実装によっては、システムフラグ以外のフラグも存在する可能性があります。
The update from the FLAGS response MUST be recorded by the client.
FLAGS応答からの更新は、クライアントによって記録される必要があります。
Example: S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
These responses are always untagged. This is how changes in the size of the mailbox are transmitted from the server to the client. Immediately following the "*" token is a number that represents a message count.
これらの応答には常にタグが付けられていません。これは、メールボックスのサイズの変更がサーバーからクライアントに送信される方法です。 「*」トークンの直後には、メッセージ数を表す数値が続きます。
Contents: none
内容：なし
The EXISTS response reports the number of messages in the mailbox. This response occurs as a result of a SELECT or EXAMINE command, and if the size of the mailbox changes (e.g., new messages).
EXISTS応答は、メールボックス内のメッセージ数を報告します。この応答は、SELECTコマンドまたはEXAMINEコマンドの結果として、およびメールボックスのサイズが変更された場合（新しいメッセージなど）に発生します。
The update from the EXISTS response MUST be recorded by the client.
EXISTS応答からの更新は、クライアントによって記録される必要があります。
Example: S: * 23 EXISTS
Contents: none
内容：なし
The RECENT response reports the number of messages with the \Recent flag set. This response occurs as a result of a SELECT or EXAMINE command, and if the size of the mailbox changes (e.g., new messages).
最近の応答は、\ Recentフラグが設定されたメッセージの数を報告します。この応答は、SELECTコマンドまたはEXAMINEコマンドの結果として、およびメールボックスのサイズが変更された場合（新しいメッセージなど）に発生します。
Note: It is not guaranteed that the message sequence numbers of recent messages will be a contiguous range of the highest n messages in the mailbox (where n is the value reported by the RECENT response). Examples of situations in which this is not the case are: multiple clients having the same mailbox open (the first session to be notified will see it as recent, others will probably see it as non-recent), and when the mailbox is re-ordered by a non-IMAP agent.
注：最近のメッセージのメッセージシーケンス番号が、メールボックス内の最も高いn個のメッセージの連続した範囲になることは保証されていません（nはRECENT応答によって報告された値です）。これが当てはまらない状況の例は次のとおりです。同じメールボックスが開いている複数のクライアント（通知される最初のセッションでは最新のセッションとして表示され、他のクライアントでは最新でないと表示される）、およびメールボックスが再非IMAPエージェントによって注文されました。
The only reliable way to identify recent messages is to look at message flags to see which have the \Recent flag set, or to do a SEARCH RECENT.
最近のメッセージを識別する唯一の信頼できる方法は、\ Recentフラグが設定されているメッセージフラグを確認するか、SEARCH RECENTを実行することです。
The update from the RECENT response MUST be recorded by the client.
RECENT応答からの更新は、クライアントによって記録される必要があります。
Example: S: * 5 RECENT
These responses are always untagged. This is how message data are transmitted from the server to the client, often as a result of a command with the same name. Immediately following the "*" token is a number that represents a message sequence number.
これらの応答には常にタグが付けられていません。これは、多くの場合同じ名前のコマンドの結果として、メッセージデータがサーバーからクライアントに送信される方法です。 「*」トークンの直後には、メッセージのシーケンス番号を表す番号が続きます。
Contents: none
内容：なし
The EXPUNGE response reports that the specified message sequence number has been permanently removed from the mailbox. The message sequence number for each successive message in the mailbox is immediately decremented by 1, and this decrement is reflected in message sequence numbers in subsequent responses (including other untagged EXPUNGE responses).
EXPUNGE応答は、指定されたメッセージシーケンス番号がメールボックスから完全に削除されたことを報告します。メールボックス内の連続する各メッセージのメッセージシーケンス番号はすぐに1ずつ減り、この減分は後続の応答（他のタグなしEXPUNGE応答を含む）のメッセージシーケンス番号に反映されます。
The EXPUNGE response also decrements the number of messages in the mailbox; it is not necessary to send an EXISTS response with the new value.
EXPUNGE応答は、メールボックス内のメッセージの数も減らします。新しい値でEXISTS応答を送信する必要はありません。
As a result of the immediate decrement rule, message sequence numbers that appear in a set of successive EXPUNGE responses depend upon whether the messages are removed starting from lower numbers to higher numbers, or from higher numbers to lower numbers. For example, if the last 5 messages in a 9-message mailbox are expunged, a "lower to higher" server will send five untagged EXPUNGE responses for message sequence number 5, whereas a "higher to lower server" will send successive untagged EXPUNGE responses for message sequence numbers 9, 8, 7, 6, and 5.
即時デクリメントルールの結果として、一連の連続するEXPUNGE応答に表示されるメッセージシーケンス番号は、メッセージが小さい番号から大きい番号の順に削除されるか、大きい番号から小さい番号の順に削除されるかによって異なります。たとえば、9メッセージのメールボックスの最後の5つのメッセージが消去された場合、「下位から上位」のサーバーはメッセージシーケンス番号5に対して5つのタグなしEXPUNGE応答を送信し、「上位から下位のサーバー」はタグなしEXPUNGE応答を連続して送信します。メッセージシーケンス番号9、8、7、6、および5の場合。
An EXPUNGE response MUST NOT be sent when no command is in progress, nor while responding to a FETCH, STORE, or SEARCH command. This rule is necessary to prevent a loss of synchronization of message sequence numbers between client and server. A command is not "in progress" until the complete command has been received; in particular, a command is not "in progress" during the negotiation of command continuation.
コマンドが実行されていないとき、またはFETCH、STORE、またはSEARCHコマンドに応答しているときは、EXPUNGE応答を送信してはなりません。このルールは、クライアントとサーバー間のメッセージシーケンス番号の同期が失われないようにするために必要です。コマンドは、完全なコマンドが受信されるまで「進行中」ではありません。特に、コマンド継続のネゴシエーションの間、コマンドは「進行中」ではありません。
Note: UID FETCH, UID STORE, and UID SEARCH are different commands from FETCH, STORE, and SEARCH. An EXPUNGE response MAY be sent during a UID command.
注：UID FETCH、UID STORE、およびUID SEARCHは、FETCH、STORE、およびSEARCHとは異なるコマンドです。 EXPUID応答は、UIDコマンド中に送信される場合があります。
The update from the EXPUNGE response MUST be recorded by the client.
EXPUNGE応答からの更新は、クライアントによって記録される必要があります。
Example: S: * 44 EXPUNGE
Contents: message data
内容：メッセージデータ
The FETCH response returns data about a message to the client. The data are pairs of data item names and their values in parentheses. This response occurs as the result of a FETCH or STORE command, as well as by unilateral server decision (e.g., flag updates).
FETCH応答は、メッセージに関するデータをクライアントに返します。データは、括弧で囲まれたデータ項目名とその値のペアです。この応答は、FETCHまたはSTOREコマンドの結果として、および一方的なサーバーの決定（フラグの更新など）によって発生します。
The current data items are:
現在のデータ項目は次のとおりです。
BODY A form of BODYSTRUCTURE without extension data.
BODY拡張データなしのBODYSTRUCTUREの形式。
BODY[<section>]<<origin octet>> A string expressing the body contents of the specified section. The string SHOULD be interpreted by the client according to the content transfer encoding, body type, and subtype.
BODY [<section>] << origin octet >>指定されたセクションの本文コンテンツを表す文字列。文字列は、コンテンツ転送エンコーディング、ボディタイプ、およびサブタイプに従ってクライアントによって解釈される必要があります（SHOULD）。
If the origin octet is specified, this string is a substring of the entire body contents, starting at that origin octet. This means that BODY[]<0> MAY be truncated, but BODY[] is NEVER truncated.
起点オクテットが指定されている場合、この文字列は、その起点オクテットから始まる、本文コンテンツ全体のサブストリングです。つまり、BODY [] <0>は切り捨てられる可能性がありますが、BODY []は決して切り捨てられません。
Note: The origin octet facility MUST NOT be used by a server in a FETCH response unless the client specifically requested it by means of a FETCH of a BODY[<section>]<<partial>> data item.
注：クライアントがBODY [<section>] << partial >>データ項目のFETCHを使用して明確に要求しない限り、サーバーは起点オクテット機能をFETCH応答で使用してはなりません（MUST NOT）。
8-bit textual data is permitted if a [CHARSET] identifier is part of the body parameter parenthesized list for this section. Note that headers (part specifiers HEADER or MIME, or the header portion of a MESSAGE/RFC822 part), MUST be 7-bit; 8-bit characters are not permitted in headers. Note also that the [RFC-2822] delimiting blank line between the header and the body is not affected by header line subsetting; the blank line is always included as part of header data, except in the case of a message which has no body and no blank line.
[CHARSET]識別子がこのセクションの本文パラメーターの括弧で囲まれたリストの一部である場合、8ビットのテキストデータが許可されます。ヘッダー（パーツ指定子HEADERまたはMIME、またはMESSAGE / RFC822パーツのヘッダー部分）は7ビットでなければならないことに注意してください。ヘッダーでは8ビット文字は使用できません。ヘッダーと本文の間の[RFC-2822]区切りの空白行はヘッダー行のサブセット化の影響を受けないことにも注意してください。空白行は、本文も空白行もないメッセージの場合を除いて、常にヘッダーデータの一部として含まれます。
Non-textual data such as binary data MUST be transfer encoded into a textual form, such as BASE64, prior to being sent to the client. To derive the original binary data, the client MUST decode the transfer encoded string.
バイナリデータなどの非テキストデータは、クライアントに送信する前に、BASE64などのテキスト形式に転送エンコードする必要があります。元のバイナリデータを取得するには、クライアントは転送エンコードされた文字列をデコードする必要があります。
BODYSTRUCTURE A parenthesized list that describes the [MIME-IMB] body structure of a message. This is computed by the server by parsing the [MIME-IMB] header fields, defaulting various fields as necessary.
BODYSTRUCTUREメッセージの[MIME-IMB]本文構造を説明する括弧付きのリスト。これは、サーバーが[MIME-IMB]ヘッダーフィールドを解析して計算し、必要に応じてさまざまなフィールドをデフォルト設定します。
For example, a simple text message of 48 lines and 2279 octets can have a body structure of: ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 2279 48)
たとえば、48行と2279オクテットの単純なテキストメッセージのボディ構造は次のとおりです。（ "TEXT" "PLAIN"（ "CHARSET" "US-ASCII"）NIL NIL "7BIT" 2279 48）
Multiple parts are indicated by parenthesis nesting. Instead of a body type as the first element of the parenthesized list, there is a sequence of one or more nested body structures. The second element of the parenthesized list is the multipart subtype (mixed, digest, parallel, alternative, etc.).
複数のパーツは括弧のネストで示されます。括弧で囲まれたリストの最初の要素としてボディタイプの代わりに、1つ以上のネストされたボディ構造のシーケンスがあります。括弧で囲まれたリストの2番目の要素は、マルチパートサブタイプ（混合、ダイジェスト、並列、代替など）です。
For example, a two part message consisting of a text and a BASE64-encoded text attachment can have a body structure of: (("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 1152 23)("TEXT" "PLAIN" ("CHARSET" "US-ASCII" "NAME" "cc.diff") "<960723163407.20117h@cac.washington.edu>" "Compiler diff" "BASE64" 4554 73) "MIXED")
たとえば、テキストとBASE64でエンコードされたテキストの添付ファイルで構成される2部構成のメッセージは、（（ "TEXT" "PLAIN"（ "CHARSET" "US-ASCII"）NIL NIL "7BIT" 1152 23 ）（ "TEXT" "PLAIN"（ "CHARSET" "US-ASCII" "NAME" "cc.diff"） "<960723163407.20117h@cac.washington.edu>" "コンパイラの差分" "BASE64" 4554 73） "MIXED "）
Extension data follows the multipart subtype. Extension data is never returned with the BODY fetch, but can be returned with a BODYSTRUCTURE fetch. Extension data, if present, MUST be in the defined order. The extension data of a multipart body part are in the following order:
拡張データは、マルチパートサブタイプに従います。拡張データはBODYフェッチでは返されませんが、BODYSTRUCTUREフェッチで返すことができます。拡張データが存在する場合、定義された順序である必要があります。マルチパートボディパーツの拡張データは次の順序です。
body parameter parenthesized list A parenthesized list of attribute/value pairs [e.g., ("foo" "bar" "baz" "rag") where "bar" is the value of "foo", and "rag" is the value of "baz"] as defined in [MIME-IMB].
本文パラメーター括弧付きリスト属性/値ペアの括弧付きリスト[例（（foo "" bar "" baz "" rag "）ここで、" bar "は" foo "の値、" rag "は" [MIME-IMB]で定義されているbaz "]。
body disposition A parenthesized list, consisting of a disposition type string, followed by a parenthesized list of disposition attribute/value pairs as defined in [DISPOSITION].
body disposition [DISPOSITION]で定義されているように、廃棄タイプ文字列と、それに続く廃棄属性/値ペアの括弧付きリストで構成される括弧付きリスト。
body language A string or parenthesized list giving the body language value as defined in [LANGUAGE-TAGS].
本文言語[LANGUAGE-TAGS]で定義されている本文言語値を示す文字列または括弧付きリスト。
body location A string list giving the body content URI as defined in [LOCATION].
本文の場所[LOCATION]で定義されている本文のコンテンツURIを示す文字列リスト。
Any following extension data are not yet defined in this version of the protocol. Such extension data can consist of zero or more NILs, strings, numbers, or potentially nested parenthesized lists of such data. Client implementations that do a BODYSTRUCTURE fetch MUST be prepared to accept such extension data. Server implementations MUST NOT send such extension data until it has been defined by a revision of this protocol.
次の拡張データは、このバージョンのプロトコルではまだ定義されていません。そのような拡張データは、ゼロ以上のNIL、文字列、数値、またはそのようなデータのネストされた括弧で囲まれたリストで構成できます。 BODYSTRUCTUREフェッチを行うクライアント実装は、そのような拡張データを受け入れる準備ができている必要があります。サーバーの実装は、このプロトコルのリビジョンによって定義されるまで、そのような拡張データを送信してはなりません（MUST NOT）。
The basic fields of a non-multipart body part are in the following order:
非マルチパートボディパーツの基本フィールドは次の順序です。
body type A string giving the content media type name as defined in [MIME-IMB].
body type [MIME-IMB]で定義されているコンテンツメディアタイプ名を示す文字列。
body subtype A string giving the content subtype name as defined in [MIME-IMB].
body subtype [MIME-IMB]で定義されているコンテンツサブタイプ名を示す文字列。
body parameter parenthesized list A parenthesized list of attribute/value pairs [e.g., ("foo" "bar" "baz" "rag") where "bar" is the value of "foo" and "rag" is the value of "baz"] as defined in [MIME-IMB].
本文パラメーター括弧付きリスト属性/値ペアの括弧付きリスト[例（（foo "" bar "" baz "" rag "）ここで、" bar "は" foo "の値であり、" rag "は" bazの値です[] [MIME-IMB]で定義されています。
body id A string giving the content id as defined in [MIME-IMB].
body id [MIME-IMB]で定義されているコンテンツIDを表す文字列。
body description A string giving the content description as defined in [MIME-IMB].
body description [MIME-IMB]で定義されているコンテンツの説明を表す文字列。
body encoding A string giving the content transfer encoding as defined in [MIME-IMB].
body encoding [MIME-IMB]で定義されているコンテンツ転送エンコーディングを提供する文字列。
body size A number giving the size of the body in octets. Note that this size is the size in its transfer encoding and not the resulting size after any decoding.
body sizeボディのサイズをオクテットで表す数値。このサイズは転送エンコードのサイズであり、デコード後のサイズではないことに注意してください。
A body type of type MESSAGE and subtype RFC822 contains, immediately after the basic fields, the envelope structure, body structure, and size in text lines of the encapsulated message.
タイプMESSAGEおよびサブタイプRFC822の本体タイプには、基本フィールドの直後に、カプセル化されたメッセージのテキスト行のエンベロープ構造、本体構造、およびサイズが含まれます。
A body type of type TEXT contains, immediately after the basic fields, the size of the body in text lines. Note that this size is the size in its content transfer encoding and not the resulting size after any decoding.
タイプTEXTの本体タイプには、基本フィールドの直後に、テキスト行の本体のサイズが含まれます。このサイズは、コンテンツ転送エンコードのサイズであり、デコード後のサイズではないことに注意してください。
Extension data follows the basic fields and the type-specific fields listed above. Extension data is never returned with the BODY fetch, but can be returned with a BODYSTRUCTURE fetch. Extension data, if present, MUST be in the defined order.
拡張データは、上記の基本フィールドとタイプ固有のフィールドに従います。拡張データはBODYフェッチでは返されませんが、BODYSTRUCTUREフェッチで返すことができます。拡張データが存在する場合、定義された順序である必要があります。
The extension data of a non-multipart body part are in the following order:
非マルチパートボディパーツの拡張データは、次の順序です。
body MD5 A string giving the body MD5 value as defined in [MD5].
本文MD5 [MD5]で定義されている本文のMD5値を示す文字列。
body disposition A parenthesized list with the same content and function as the body disposition for a multipart body part.
body dispositionマルチパートのbody partのbody dispositionと同じ内容と機能を持つ括弧付きリスト。
body language A string or parenthesized list giving the body language value as defined in [LANGUAGE-TAGS].
本文言語[LANGUAGE-TAGS]で定義されている本文言語値を示す文字列または括弧付きリスト。
body location A string list giving the body content URI as defined in [LOCATION].
本文の場所[LOCATION]で定義されている本文のコンテンツURIを示す文字列リスト。
Any following extension data are not yet defined in this version of the protocol, and would be as described above under multipart extension data.
以下の拡張データは、このバージョンのプロトコルではまだ定義されておらず、マルチパート拡張データで前述したとおりです。
ENVELOPE A parenthesized list that describes the envelope structure of a message. This is computed by the server by parsing the [RFC-2822] header into the component parts, defaulting various fields as necessary.
ENVELOPEメッセージのエンベロープ構造を説明する括弧付きのリスト。これは、[RFC-2822]ヘッダーをコンポーネント部分に解析し、必要に応じてさまざまなフィールドをデフォルト設定することにより、サーバーによって計算されます。
The fields of the envelope structure are in the following order: date, subject, from, sender, reply-to, to, cc, bcc, in-reply-to, and message-id. The date, subject, in-reply-to, and message-id fields are strings. The from, sender, reply-to, to, cc, and bcc fields are parenthesized lists of address structures.
エンベロープ構造のフィールドは、日付、件名、差出人、送信者、返信先、宛先、cc、bcc、返信先、メッセージIDの順序です。日付、件名、返信先、メッセージIDの各フィールドは文字列です。 from、sender、reply-to、to、cc、およびbccフィールドは、アドレス構造の括弧付きリストです。
An address structure is a parenthesized list that describes an electronic mail address. The fields of an address structure are in the following order: personal name, [SMTP] at-domain-list (source route), mailbox name, and host name.
アドレス構造は、電子メールアドレスを記述するかっこで囲まれたリストです。アドレス構造のフィールドは、個人名、[SMTP] at-domain-list（ソースルート）、メールボックス名、ホスト名の順になっています。
[RFC-2822] group syntax is indicated by a special form of address structure in which the host name field is NIL. If the mailbox name field is also NIL, this is an end of group marker (semi-colon in RFC 822 syntax). If the mailbox name field is non-NIL, this is a start of group marker, and the mailbox name field holds the group name phrase.
[RFC-2822]グループ構文は、ホスト名フィールドがNILである特別な形式のアドレス構造で示されます。メールボックス名フィールドもNILの場合、これはグループ終了マーカー（RFC 822構文のセミコロン）です。メールボックス名フィールドが非NILの場合、これはグループマーカーの開始であり、メールボックス名フィールドはグループ名句を保持します。
If the Date, Subject, In-Reply-To, and Message-ID header lines are absent in the [RFC-2822] header, the corresponding member of the envelope is NIL; if these header lines are present but empty the corresponding member of the envelope is the empty string.
Date、Subject、In-Reply-To、およびMessage-IDヘッダー行が[RFC-2822]ヘッダーにない場合、エンベロープの対応するメンバーはNILです。これらのヘッダー行は存在するが空の場合、エンベロープの対応するメンバーは空の文字列です。
Note: some servers may return a NIL envelope member in the "present but empty" case. Clients SHOULD treat NIL and empty string as identical.
注：一部のサーバーは、「存在するが空」の場合にNILエンベロープメンバーを返すことがあります。クライアントはNILと空の文字列を同一のものとして扱う必要があります（SHOULD）。
Note: [RFC-2822] requires that all messages have a valid Date header. Therefore, the date member in the envelope can not be NIL or the empty string.
注：[RFC-2822]では、すべてのメッセージに有効な日付ヘッダーが必要です。したがって、エンベロープの日付メンバーをNILまたは空の文字列にすることはできません。
Note: [RFC-2822] requires that the In-Reply-To and Message-ID headers, if present, have non-empty content. Therefore, the in-reply-to and message-id members in the envelope can not be the empty string.
注：[RFC-2822]では、In-Reply-ToおよびMessage-IDヘッダー（存在する場合）に空でないコンテンツが含まれている必要があります。したがって、エンベロープ内の返信先とメッセージIDのメンバーを空の文字列にすることはできません。
If the From, To, cc, and bcc header lines are absent in the [RFC-2822] header, or are present but empty, the corresponding member of the envelope is NIL.
From、To、cc、およびbccヘッダー行が[RFC-2822]ヘッダーにないか、存在しても空の場合、エンベロープの対応するメンバーはNILです。
If the Sender or Reply-To lines are absent in the [RFC-2822] header, or are present but empty, the server sets the corresponding member of the envelope to be the same value as the from member (the client is not expected to know to do this).
SenderまたはReply-To行が[RFC-2822]ヘッダーにない場合、または存在するが空の場合、サーバーはエンベロープの対応するメンバーをfromメンバーと同じ値に設定します（クライアントはこれを行うことを知っている）。
Note: [RFC-2822] requires that all messages have a valid From header. Therefore, the from, sender, and reply-to members in the envelope can not be NIL.
注：[RFC-2822]では、すべてのメッセージに有効なFromヘッダーが必要です。したがって、エンベロープのfrom、sender、およびreply-toメンバーをNILにすることはできません。
FLAGS A parenthesized list of flags that are set for this message.
FLAGSこのメッセージに設定されるフラグの括弧付きリスト。
INTERNALDATE A string representing the internal date of the message.
INTERNALDATEメッセージの内部日付を表す文字列。
RFC822 Equivalent to BODY[].
RFC822 BODY []に相当します。
RFC822.HEADER Equivalent to BODY[HEADER]. Note that this did not result in \Seen being set, because RFC822.HEADER response data occurs as a result of a FETCH of RFC822.HEADER. BODY[HEADER] response data occurs as a result of a FETCH of BODY[HEADER] (which sets \Seen) or BODY.PEEK[HEADER] (which does not set \Seen).
RFC822.HEADER BODY [HEADER]と同等です。 RFC822.HEADER応答データはRFC822.HEADERのFETCHの結果として発生するため、これによって\ Seenが設定されることはありませんでした。 BODY [HEADER]応答データは、BODY [HEADER]（\ Seenを設定）またはBODY.PEEK [HEADER]（\ Seenを設定しない）のFETCHの結果として発生します。
RFC822.SIZE A number expressing the [RFC-2822] size of the message.
RFC822.SIZEメッセージの[RFC-2822]サイズを表す数値。
RFC822.TEXT Equivalent to BODY[TEXT].
RFC822.TEXT BODY [TEXT]と同等です。
UID A number expressing the unique identifier of the message.
UIDメッセージの一意の識別子を表す番号。
Example: S: * 23 FETCH (FLAGS (\Seen) RFC822.SIZE 44827)
The command continuation request response is indicated by a "+" token instead of a tag. This form of response indicates that the server is ready to accept the continuation of a command from the client. The remainder of this response is a line of text.
コマンド継続要求応答は、タグの代わりに「+」トークンで示されます。この形式の応答は、サーバーがクライアントからのコマンドの継続を受け入れる準備ができていることを示します。この応答の残りはテキスト行です。
This response is used in the AUTHENTICATE command to transmit server data to the client, and request additional client data. This response is also used if an argument to any command is a literal.
この応答は、AUTHENTICATEコマンドでサーバーデータをクライアントに送信し、追加のクライアントデータを要求するために使用されます。この応答は、コマンドの引数がリテラルの場合にも使用されます。
The client is not permitted to send the octets of the literal unless the server indicates that it is expected. This permits the server to process commands and reject errors on a line-by-line basis. The remainder of the command, including the CRLF that terminates a command, follows the octets of the literal. If there are any additional command arguments, the literal octets are followed by a space and those arguments.
サーバーはそれが期待されていることを示さない限り、クライアントはリテラルのオクテットを送信することを許可されていません。これにより、サーバーはコマンドを処理し、行ごとにエラーを拒否できます。コマンドを終了するCRLFを含むコマンドの残りの部分は、リテラルのオクテットに従います。追加のコマンド引数がある場合、リテラルオクテットの後にスペースとそれらの引数が続きます。
Example: C: A001 LOGIN {11}
S: + Ready for additional command text
C: FRED FOOBAR {7}
S: + Ready for additional command text
C: fat man
S: A001 OK LOGIN completed
C: A044 BLURDYBLOOP {102856}
S: A044 BAD No such command as "BLURDYBLOOP"
The following is a transcript of an IMAP4rev1 connection. A long line in this sample is broken for editorial clarity.
以下は、IMAP4rev1接続のトランスクリプトです。このサンプルの長い行は、編集を明確にするために改行されています。
S: * OK IMAP4rev1 Service Ready
C: a001 login mrc secret
S: a001 OK LOGIN completed
C: a002 select inbox
S: * 18 EXISTS
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * 2 RECENT
S: * OK [UNSEEN 17] Message 17 is the first unseen message
S: * OK [UIDVALIDITY 3857529045] UIDs valid
S: a002 OK [READ-WRITE] SELECT completed
C: a003 fetch 12 full
S: * 12 FETCH (FLAGS (\Seen) INTERNALDATE "17-Jul-1996 02:44:25 -0700"
RFC822.SIZE 4286 ENVELOPE ("Wed, 17 Jul 1996 02:23:25 -0700 (PDT)"
"IMAP4rev1 WG mtg summary and minutes"
(("Terry Gray" NIL "gray" "cac.washington.edu"))
(("Terry Gray" NIL "gray" "cac.washington.edu"))
(("Terry Gray" NIL "gray" "cac.washington.edu"))
((NIL NIL "imap" "cac.washington.edu"))
((NIL NIL "minutes" "CNRI.Reston.VA.US")
("John Klensin" NIL "KLENSIN" "MIT.EDU")) NIL NIL
"<B27397-0100000@cac.washington.edu>")
BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 3028
92))
S: a003 OK FETCH completed
C: a004 fetch 12 body[header]
S: * 12 FETCH (BODY[HEADER] {342}
S: Date: Wed, 17 Jul 1996 02:23:25 -0700 (PDT)
S: From: Terry Gray <gray@cac.washington.edu>
S: Subject: IMAP4rev1 WG mtg summary and minutes
S: To: imap@cac.washington.edu
S: cc: minutes@CNRI.Reston.VA.US, John Klensin <KLENSIN@MIT.EDU>
S: Message-Id: <B27397-0100000@cac.washington.edu>
S: MIME-Version: 1.0
S: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
S:
S: )
S: a004 OK FETCH completed
C: a005 store 12 +flags \deleted
S: * 12 FETCH (FLAGS (\Seen \Deleted))
S: a005 OK +FLAGS completed
C: a006 logout
S: * BYE IMAP4rev1 server terminating connection
S: a006 OK LOGOUT completed
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [ABNF].
次の構文仕様では、[ABNF]で指定されている拡張バッカスナウア記法（ABNF）表記を使用しています。
In the case of alternative or optional rules in which a later rule overlaps an earlier rule, the rule which is listed earlier MUST take priority. For example, "\Seen" when parsed as a flag is the \Seen flag name and not a flag-extension, even though "\Seen" can be parsed as a flag-extension. Some, but not all, instances of this rule are noted below.
後のルールが前のルールと重複する代替またはオプションのルールの場合、前にリストされているルールを優先する必要があります。たとえば、「\ Seen」はフラグ拡張として解析できますが、フラグとして解析されるときの「\ Seen」は、\ Seenフラグ名であり、フラグ拡張ではありません。すべてではありませんが、このルールのインスタンスの一部を以下に示します。
Note: [ABNF] rules MUST be followed strictly; in particular:
注：[ABNF]ルールは厳密に遵守されなければなりません。特に：
(1) Except as noted otherwise, all alphabetic characters are case-insensitive. The use of upper or lower case characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion.
（1）特に断りのない限り、すべての英字は大文字小文字を区別しません。トークン文字列を定義するための大文字または小文字の使用は、編集上の明確さのためだけです。実装は、大文字と小文字を区別しない方法でこれらの文字列を受け入れる必要があります。
(2) In all cases, SP refers to exactly one space. It is NOT permitted to substitute TAB, insert additional spaces, or otherwise treat SP as being equivalent to LWSP.
（2）すべての場合において、SPは正確に1つのスペースを指します。 TABの代用、追加のスペースの挿入、またはSPをLWSPと同等のものとして扱うことは許可されていません。
(3) The ASCII NUL character, %x00, MUST NOT be used at any time.
（3）ASCII NUL文字％x00は、決して使用してはなりません。
address = "(" addr-name SP addr-adl SP addr-mailbox SP addr-host ")"
アドレス= "（" addr-name SP addr-adl SP addr-mailbox SP addr-host "）"
addr-adl = nstring ; Holds route from [RFC-2822] route-addr if ; non-NIL
addr-adl = nstring;次の場合、[RFC-2822] route-addrからのルートを保持します。非NIL
addr-host = nstring ; NIL indicates [RFC-2822] group syntax. ; Otherwise, holds [RFC-2822] domain name
addr-host = nstring; NILは[RFC-2822]グループ構文を示します。 ;それ以外の場合は、[RFC-2822]ドメイン名を保持します
addr-mailbox = nstring
; NIL indicates end of [RFC-2822] group; if
; non-NIL and addr-host is NIL, holds
; [RFC-2822] group name.
; Otherwise, holds [RFC-2822] local-part
; after removing [RFC-2822] quoting addr-name = nstring
; If non-NIL, holds phrase from [RFC-2822]
; mailbox after removing [RFC-2822] quoting
append = "APPEND" SP mailbox [SP flag-list] [SP date-time] SP literal
append = "APPEND" SPメールボックス[SPフラグリスト] [SP日時] SPリテラル
astring = 1*ASTRING-CHAR / string
ASTRING-CHAR = ATOM-CHAR / resp-specials
ASTRING-CHAR = ATOM-CHAR / resp-specials
atom = 1*ATOM-CHAR
アトム= 1 * ATOM-CHAR
ATOM-CHAR = <any CHAR except atom-specials>
atom-specials = "(" / ")" / "{" / SP / CTL / list-wildcards /
quoted-specials / resp-specials
authenticate = "AUTHENTICATE" SP auth-type *(CRLF base64)
authenticate = "AUTHENTICATE" SP auth-type *（CRLF base64）
auth-type = atom ; Defined by [SASL]
auth-type = atom; [SASL]により定義
base64 = *(4base64-char) [base64-terminal]
base64-char = ALPHA / DIGIT / "+" / "/"
; Case-sensitive
base64-terminal = (2base64-char "==") / (3base64-char "=")
body = "(" (body-type-1part / body-type-mpart) ")"
body-extension = nstring / number /
"(" body-extension *(SP body-extension) ")"
; Future expansion. Client implementations
; MUST accept body-extension fields. Server
; implementations MUST NOT generate
; body-extension fields except as defined by
; future standard or standards-track
; revisions of this specification.
body-ext-1part = body-fld-md5 [SP body-fld-dsp [SP body-fld-lang [SP body-fld-loc *(SP body-extension)]]] ; MUST NOT be returned on non-extensible ; "BODY" fetch
body-ext-1part = body-fld-md5 [SP body-fld-dsp [SP body-fld-lang [SP body-fld-loc *（SP body-extension）]]];非拡張では返さないでください。 「BODY」フェッチ
body-ext-mpart = body-fld-param [SP body-fld-dsp [SP body-fld-lang [SP body-fld-loc *(SP body-extension)]]] ; MUST NOT be returned on non-extensible ; "BODY" fetch
body-ext-mpart = body-fld-param [SP body-fld-dsp [SP body-fld-lang [SP body-fld-loc *（SP body-extension）]]];非拡張では返さないでください。 「BODY」フェッチ
body-fields = body-fld-param SP body-fld-id SP body-fld-desc SP body-fld-enc SP body-fld-octets
body-fields = body-fld-param SP body-fld-id SP body-fld-desc SP body-fld-enc SP body-fld-octets
body-fld-desc = nstring
body-fld-desc = nstring
body-fld-dsp = "(" string SP body-fld-param ")" / nil
body-fld-enc = (DQUOTE ("7BIT" / "8BIT" / "BINARY" / "BASE64"/
"QUOTED-PRINTABLE") DQUOTE) / string
body-fld-id = nstring
body-fld-id = nstring
body-fld-lang = nstring / "(" string *(SP string) ")"
body-fld-loc = nstring
body-fld-loc = nstring
body-fld-lines = number
body-fld-lines =数値
body-fld-md5 = nstring
body-fld-md5 = nstring
body-fld-octets = number
body-fld-octets =数値
body-fld-param = "(" string SP string *(SP string SP string) ")" / nil
body-type-1part = (body-type-basic / body-type-msg / body-type-text)
[SP body-ext-1part]
body-type-basic = media-basic SP body-fields ; MESSAGE subtype MUST NOT be "RFC822"
body-type-basic = media-basic SP body-fields;メッセージサブタイプは「RFC822」であってはなりません
body-type-mpart = 1*body SP media-subtype [SP body-ext-mpart]
body-type-mpart = 1 * body SPメディアサブタイプ[SP body-ext-mpart]
body-type-msg = media-message SP body-fields SP envelope SP body SP body-fld-lines
body-type-msg = media-message SP body-fields SPエンベロープSP body SP body-fld-lines
body-type-text = media-text SP body-fields SP body-fld-lines
body-type-text = media-text SP body-fields SP body-fld-lines
capability = ("AUTH=" auth-type) / atom
; New capabilities MUST begin with "X" or be
; registered with IANA as standard or
; standards-track
capability-data = "CAPABILITY" *(SP capability) SP "IMAP4rev1"
*(SP capability)
; Servers MUST implement the STARTTLS, AUTH=PLAIN,
; and LOGINDISABLED capabilities
; Servers which offer RFC 1730 compatibility MUST
; list "IMAP4" as the first capability.
CHAR8 = %x01-ff
; any OCTET except NUL, %x00
command = tag SP (command-any / command-auth / command-nonauth /
command-select) CRLF
; Modal based on state
command-any = "CAPABILITY" / "LOGOUT" / "NOOP" / x-command
; Valid in all states
command-auth = append / create / delete / examine / list / lsub /
rename / select / status / subscribe / unsubscribe
; Valid only in Authenticated or Selected state
command-nonauth = login / authenticate / "STARTTLS"
; Valid only when in Not Authenticated state
command-select = "CHECK" / "CLOSE" / "EXPUNGE" / copy / fetch / store /
uid / search
; Valid only when in Selected state
continue-req = "+" SP (resp-text / base64) CRLF
copy = "COPY" SP sequence-set SP mailbox
copy = "COPY" SP sequence-set SP mailbox
create = "CREATE" SP mailbox ; Use of INBOX gives a NO error
create = "CREATE" SPメールボックス; INBOXを使用するとNOエラーが発生する
date = date-text / DQUOTE date-text DQUOTE
日付=日付テキスト/ DQUOTE日付テキストDQUOTE
date-day = 1*2DIGIT ; Day of month
date-day = 1 * 2DIGIT;月の日
date-day-fixed = (SP DIGIT) / 2DIGIT
; Fixed-format version of date-day
date-month = "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" /
"Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec"
date-text = date-day "-" date-month "-" date-year date-year = 4DIGIT
日付テキスト=日付-日 "-"日付-月 "-"日付-年日付-年= 4DIGIT
date-time = DQUOTE date-day-fixed "-" date-month "-" date-year SP time SP zone DQUOTE
日付時刻= DQUOTE日付日固定 "-"日付月 "-"日付年SP時間SPゾーンDQUOTE
delete = "DELETE" SP mailbox ; Use of INBOX gives a NO error
delete = "DELETE" SPメールボックス; INBOXを使用するとNOエラーが発生する
digit-nz = %x31-39
; 1-9
envelope = "(" env-date SP env-subject SP env-from SP env-sender SP env-reply-to SP env-to SP env-cc SP env-bcc SP env-in-reply-to SP env-message-id ")"
エンベロープ= "（" env-date SP env-subject SP env-from SP env-sender SP env-reply-to SP env-to SP env-cc SP env-bcc SP env-in-reply-to SP env-message -id "）"
env-bcc = "(" 1*address ")" / nil
env-cc = "(" 1*address ")" / nil
env-date = nstring
env-date = nstring
env-from = "(" 1*address ")" / nil
env-in-reply-to = nstring
env-in-reply-to = nsstring
env-message-id = nstring
env-message-id = nstring
env-reply-to = "(" 1*address ")" / nil
env-sender = "(" 1*address ")" / nil
env-subject = nstring
env-subject = nstring
env-to = "(" 1*address ")" / nil
examine = "EXAMINE" SP mailbox
検査= "EXAMINE" SPメールボックス
fetch = "FETCH" SP sequence-set SP ("ALL" / "FULL" / "FAST" /
fetch-att / "(" fetch-att *(SP fetch-att) ")")
fetch-att = "ENVELOPE" / "FLAGS" / "INTERNALDATE" /
"RFC822" [".HEADER" / ".SIZE" / ".TEXT"] /
"BODY" ["STRUCTURE"] / "UID" /
"BODY" section ["<" number "." nz-number ">"] /
"BODY.PEEK" section ["<" number "." nz-number ">"]
flag = "\Answered" / "\Flagged" / "\Deleted" /
"\Seen" / "\Draft" / flag-keyword / flag-extension
; Does not include "\Recent"
flag-extension = "\" atom
; Future expansion. Client implementations
; MUST accept flag-extension flags. Server
; implementations MUST NOT generate
; flag-extension flags except as defined by
; future standard or standards-track
; revisions of this specification.
flag-fetch = flag / "\Recent"
flag-fetch = flag / "\ Recent"
flag-keyword = atom
フラグキーワード=アトム
flag-list = "(" [flag *(SP flag)] ")"
flag-perm = flag / "\*"
greeting = "*" SP (resp-cond-auth / resp-cond-bye) CRLF
header-fld-name = astring
header-field-name = string
header-list = "(" header-fld-name *(SP header-fld-name) ")"
list = "LIST" SP mailbox SP list-mailbox
list = "LIST" SPメールボックスSPリストメールボックス
list-mailbox = 1*list-char / string
list-char = ATOM-CHAR / list-wildcards / resp-specials
list-wildcards = "%" / "*"
literal = "{" number "}" CRLF *CHAR8
; Number represents the number of CHAR8s
login = "LOGIN" SP userid SP password
login = "LOGIN" SPユーザーID SPパスワード
lsub = "LSUB" SP mailbox SP list-mailbox mailbox = "INBOX" / astring
; INBOX is case-insensitive. All case variants of
; INBOX (e.g., "iNbOx") MUST be interpreted as INBOX
; not as an astring. An astring which consists of
; the case-insensitive sequence "I" "N" "B" "O" "X"
; is considered to be INBOX and not an astring.
; Refer to section 5.1 for further
; semantic details of mailbox names.
mailbox-data = "FLAGS" SP flag-list / "LIST" SP mailbox-list /
"LSUB" SP mailbox-list / "SEARCH" *(SP nz-number) /
"STATUS" SP mailbox SP "(" [status-att-list] ")" /
number SP "EXISTS" / number SP "RECENT"
mailbox-list = "(" [mbx-list-flags] ")" SP (DQUOTE QUOTED-CHAR DQUOTE / nil) SP mailbox
mailbox-list = "（" [mbx-list-flags] "）" SP（DQUOTE QUOTED-CHAR DQUOTE / nil）SPメールボックス
mbx-list-flags = *(mbx-list-oflag SP) mbx-list-sflag
*(SP mbx-list-oflag) /
mbx-list-oflag *(SP mbx-list-oflag)
mbx-list-oflag = "\Noinferiors" / flag-extension
; Other flags; multiple possible per LIST response
mbx-list-sflag = "\Noselect" / "\Marked" / "\Unmarked"
; Selectability flags; only one per LIST response
media-basic = ((DQUOTE ("APPLICATION" / "AUDIO" / "IMAGE" /
"MESSAGE" / "VIDEO") DQUOTE) / string) SP
media-subtype
; Defined in [MIME-IMT]
media-message = DQUOTE "MESSAGE" DQUOTE SP DQUOTE "RFC822" DQUOTE ; Defined in [MIME-IMT]
media-message = DQUOTE "MESSAGE" DQUOTE SP DQUOTE "RFC822" DQUOTE; [MIME-IMT]で定義
media-subtype = string ; Defined in [MIME-IMT]
media-subtype = string; [MIME-IMT]で定義
media-text = DQUOTE "TEXT" DQUOTE SP media-subtype ; Defined in [MIME-IMT]
media-text = DQUOTE "TEXT" DQUOTE SP media-subtype; [MIME-IMT]で定義
message-data = nz-number SP ("EXPUNGE" / ("FETCH" SP msg-att))
message-data = nz-number SP（ "EXPUNGE" /（ "FETCH" SP msg-att））
msg-att = "(" (msg-att-dynamic / msg-att-static)
*(SP (msg-att-dynamic / msg-att-static)) ")"
msg-att-dynamic = "FLAGS" SP "(" [flag-fetch *(SP flag-fetch)] ")"
; MAY change for a message
msg-att-static = "ENVELOPE" SP envelope / "INTERNALDATE" SP date-time /
"RFC822" [".HEADER" / ".TEXT"] SP nstring /
"RFC822.SIZE" SP number /
"BODY" ["STRUCTURE"] SP body /
"BODY" section ["<" number ">"] SP nstring /
"UID" SP uniqueid
; MUST NOT change for a message
nil = "NIL"
Nil = "nil"
nstring = string / nil
nstring = string / nil
number = 1*DIGIT
; Unsigned 32-bit integer
; (0 <= n < 4,294,967,296)
nz-number = digit-nz *DIGIT
; Non-zero unsigned 32-bit integer
; (0 < n < 4,294,967,296)
password = astring
パスワード=文字列
quoted = DQUOTE *QUOTED-CHAR DQUOTE
引用= DQUOTE * QUOTED-CHAR DQUOTE
QUOTED-CHAR = <any TEXT-CHAR except quoted-specials> /
"\" quoted-specials
quoted-specials = DQUOTE / "\"
quoted-specials = DQUOTE / "\"
rename = "RENAME" SP mailbox SP mailbox ; Use of INBOX as a destination gives a NO error
rename = "RENAME" SPメールボックスSPメールボックス; INBOXを宛先として使用すると、エラーは発生しません
response = *(continue-req / response-data) response-done
response-data = "*" SP (resp-cond-state / resp-cond-bye /
mailbox-data / message-data / capability-data) CRLF
response-done = response-tagged / response-fatal
response-done = response-tagged / response-fatal
response-fatal = "*" SP resp-cond-bye CRLF ; Server closes connection immediately
response-fatal = "*" SP resp-cond-bye CRLF;サーバーはすぐに接続を閉じます
response-tagged = tag SP resp-cond-state CRLF
response-tagged = tag SP resp-cond-state CRLF
resp-cond-auth = ("OK" / "PREAUTH") SP resp-text
; Authentication condition
resp-cond-bye = "BYE" SP resp-text
resp-cond-bye = "BYE" SP resp-text
resp-cond-state = ("OK" / "NO" / "BAD") SP resp-text
; Status condition
resp-specials = "]"
resp-specials = "]"
resp-text = ["[" resp-text-code "]" SP] text
resp-text-code = "ALERT" /
"BADCHARSET" [SP "(" astring *(SP astring) ")" ] /
capability-data / "PARSE" /
"PERMANENTFLAGS" SP "("
[flag-perm *(SP flag-perm)] ")" /
"READ-ONLY" / "READ-WRITE" / "TRYCREATE" /
"UIDNEXT" SP nz-number / "UIDVALIDITY" SP nz-number /
"UNSEEN" SP nz-number /
atom [SP 1*<any TEXT-CHAR except "]">]
search = "SEARCH" [SP "CHARSET" SP astring] 1*(SP search-key) ; CHARSET argument to MUST be registered with IANA
search = "SEARCH" [SP "CHARSET" SP astring] 1 *（SP search-key）; CHARSET引数をIANAに登録する必要があります
search-key = "ALL" / "ANSWERED" / "BCC" SP astring /
"BEFORE" SP date / "BODY" SP astring /
"CC" SP astring / "DELETED" / "FLAGGED" /
"FROM" SP astring / "KEYWORD" SP flag-keyword /
"NEW" / "OLD" / "ON" SP date / "RECENT" / "SEEN" /
"SINCE" SP date / "SUBJECT" SP astring /
"TEXT" SP astring / "TO" SP astring /
"UNANSWERED" / "UNDELETED" / "UNFLAGGED" /
"UNKEYWORD" SP flag-keyword / "UNSEEN" /
; Above this line were in [IMAP2]
"DRAFT" / "HEADER" SP header-fld-name SP astring /
"LARGER" SP number / "NOT" SP search-key /
"OR" SP search-key SP search-key /
"SENTBEFORE" SP date / "SENTON" SP date /
"SENTSINCE" SP date / "SMALLER" SP number /
"UID" SP sequence-set / "UNDRAFT" / sequence-set /
"(" search-key *(SP search-key) ")"
section = "[" [section-spec] "]"
セクション= "[" [section-spec] "]"
section-msgtext = "HEADER" / "HEADER.FIELDS" [".NOT"] SP header-list /
"TEXT"
; top-level or MESSAGE/RFC822 part
section-part = nz-number *("." nz-number) ; body part nesting
section-part = nz-number *（ "。" nz-number）;身体の部分の入れ子
section-spec = section-msgtext / (section-part ["." section-text])
section-spec = section-msgtext /（section-part ["。" section-text]）
section-text = section-msgtext / "MIME" ; text other than actual body part (headers, etc.)
section-text = section-msgtext / "MIME";実際の本文部分以外のテキスト（ヘッダーなど）
select = "SELECT" SP mailbox
select = "SELECT" SPメールボックス
seq-number = nz-number / "*"
; message sequence number (COPY, FETCH, STORE
; commands) or unique identifier (UID COPY,
; UID FETCH, UID STORE commands).
; * represents the largest number in use. In
; the case of message sequence numbers, it is
; the number of messages in a non-empty mailbox.
; In the case of unique identifiers, it is the
; unique identifier of the last message in the
; mailbox or, if the mailbox is empty, the
; mailbox's current UIDNEXT value.
; The server should respond with a tagged BAD
; response to a command that uses a message
; sequence number greater than the number of
; messages in the selected mailbox. This
; includes "*" if the selected mailbox is empty.
seq-range = seq-number ":" seq-number
; two seq-number values and all values between
; these two regardless of order.
; Example: 2:4 and 4:2 are equivalent and indicate
; values 2, 3, and 4.
; Example: a unique identifier sequence range of
; 3291:* includes the UID of the last message in
; the mailbox, even if that value is less than 3291.
sequence-set = (seq-number / seq-range) *("," sequence-set)
; set of seq-number values, regardless of order.
; Servers MAY coalesce overlaps and/or execute the
; sequence in any order.
; Example: a message sequence number set of
; 2,4:7,9,12:* for a mailbox with 15 messages is
; equivalent to 2,4,5,6,7,9,12,13,14,15
; Example: a message sequence number set of *:4,5:7
; for a mailbox with 10 messages is equivalent to
; 10,9,8,7,6,5,4,5,6,7 and MAY be reordered and
; overlap coalesced to be 4,5,6,7,8,9,10.
status = "STATUS" SP mailbox SP "(" status-att *(SP status-att) ")"
status = "STATUS" SPメールボックスSP "（" status-att *（SP status-att） "）"
status-att = "MESSAGES" / "RECENT" / "UIDNEXT" / "UIDVALIDITY" /
"UNSEEN"
status-att-list = status-att SP number *(SP status-att SP number)
status-att-list = status-att SP number *（SP status-att SP number）
store = "STORE" SP sequence-set SP store-att-flags
store = "STORE" SPシーケンスセットSP store-att-flags
store-att-flags = (["+" / "-"] "FLAGS" [".SILENT"]) SP
(flag-list / (flag *(SP flag)))
string = quoted / literal
文字列=引用/リテラル
subscribe = "SUBSCRIBE" SP mailbox
subscribe = "SUBSCRIBE" SPメールボックス
tag = 1*<any ASTRING-CHAR except "+">
text = 1*TEXT-CHAR
テキスト= 1 * TEXT-CHAR
TEXT-CHAR = <any CHAR except CR and LF>
time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
; Hours minutes seconds
uid = "UID" SP (copy / fetch / search / store)
; Unique identifiers used instead of message
; sequence numbers
uniqueid = nz-number ; Strictly ascending
uniqueid = nz-number;厳密に上昇
unsubscribe = "UNSUBSCRIBE" SP mailbox
unsubscribe = "UNSUBSCRIBE" SPメールボックス
userid = astring
ユーザーID =文字列
x-command = "X" atom <experimental command arguments>
zone = ("+" / "-") 4DIGIT
; Signed four-digit value of hhmm representing
; hours and minutes east of Greenwich (that is,
; the amount that the given time differs from
; Universal Time). Subtracting the timezone
; from the given time will give the UT form.
; The Universal Time zone is "+0000".
This document is a revision or rewrite of earlier documents, and supercedes the protocol specification in those documents: RFC 2060, RFC 1730, unpublished IMAP2bis.TXT document, RFC 1176, and RFC 1064.
このドキュメントは以前のドキュメントの改訂版または書き換え版であり、RFC 2060、RFC 1730、未公開のIMAP2bis.TXTドキュメント、RFC 1176、およびRFC 1064などのドキュメントのプロトコル仕様に優先します。
IMAP4rev1 protocol transactions, including electronic mail data, are sent in the clear over the network unless protection from snooping is negotiated. This can be accomplished either by the use of STARTTLS, negotiated privacy protection in the AUTHENTICATE command, or some other protection mechanism.
電子メールデータを含むIMAP4rev1プロトコルトランザクションは、スヌーピングからの保護がネゴシエートされない限り、ネットワークを介して平文で送信されます。これは、STARTTLS、AUTHENTICATEコマンドでのネゴシエートされたプライバシー保護、またはその他の保護メカニズムを使用して実現できます。
The specification of the STARTTLS command and LOGINDISABLED capability in this document replaces that in [IMAP-TLS]. [IMAP-TLS] remains normative for the PLAIN [SASL] authenticator.
このドキュメントのSTARTTLSコマンドとLOGINDISABLED機能の仕様は、[IMAP-TLS]の仕様を置き換えます。 [IMAP-TLS]は、プレーン[SASL]オーセンティケーターの規範であり続けます。
IMAP client and server implementations MUST implement the TLS_RSA_WITH_RC4_128_MD5 [TLS] cipher suite, and SHOULD implement the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [TLS] cipher suite. This is important as it assures that any two compliant implementations can be configured to interoperate. All other cipher suites are OPTIONAL. Note that this is a change from section 2.1 of [IMAP-TLS].
IMAPクライアントとサーバーの実装は、TLS_RSA_WITH_RC4_128_MD5 [TLS]暗号スイートを実装する必要があり、TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [TLS]暗号スイートを実装する必要があります（SHOULD）。これは、2つの準拠した実装を相互運用するように構成できることを保証するために重要です。他のすべての暗号スイートはオプションです。これは[IMAP-TLS]のセクション2.1からの変更点であることに注意してください。
During the [TLS] negotiation, the client MUST check its understanding of the server hostname against the server's identity as presented in the server Certificate message, in order to prevent man-in-the-middle attacks. If the match fails, the client SHOULD either ask for explicit user confirmation, or terminate the connection and indicate that the server's identity is suspect. Matching is performed according to these rules:
[TLS]ネゴシエーション中、クライアントは中間者攻撃を防ぐために、サーバーの証明書メッセージに示されているサーバーのIDに対してサーバーのホスト名の理解をチェックする必要があります。一致が失敗した場合、クライアントは明示的なユーザー確認を求めるか、接続を終了してサーバーのIDが疑わしいことを示す必要があります（SHOULD）。マッチングは次のルールに従って実行されます。
The client MUST use the server hostname it used to open the connection as the value to compare against the server name as expressed in the server certificate. The client MUST NOT use any form of the server hostname derived from an insecure remote source (e.g., insecure DNS lookup). CNAME canonicalization is not done.
クライアントは、サーバー証明書で表現されているサーバー名と比較する値として、接続を開くために使用したサーバーホスト名を使用する必要があります。クライアントは、安全でないリモートソース（安全でないDNSルックアップなど）から派生したサーバーホスト名の形式を使用してはなりません（MUST NOT）。 CNAMEの正規化は行われません。
If a subjectAltName extension of type dNSName is present in the certificate, it SHOULD be used as the source of the server's identity.
タイプdNSNameのsubjectAltName拡張が証明書に存在する場合は、サーバーのIDのソースとして使用する必要があります（SHOULD）。
Matching is case-insensitive.
マッチングでは大文字と小文字は区別されません。
A "*" wildcard character MAY be used as the left-most name component in the certificate. For example, *.example.com would match a.example.com, foo.example.com, etc. but would not match example.com.
「*」ワイルドカード文字は、証明書の左端の名前コンポーネントとして使用できます。たとえば、*。example.comはa.example.com、foo.example.comなどと一致しますが、example.comとは一致しません。
If the certificate contains multiple names (e.g., more than one dNSName field), then a match with any one of the fields is considered acceptable.
証明書に複数の名前が含まれている場合（たとえば、複数のdNSNameフィールド）、フィールドのいずれかとの一致は許容できると見なされます。
Both the client and server MUST check the result of the STARTTLS command and subsequent [TLS] negotiation to see whether acceptable authentication or privacy was achieved.
クライアントとサーバーの両方が、STARTTLSコマンドとそれに続く[TLS]ネゴシエーションの結果をチェックして、許容できる認証またはプライバシーが達成されたかどうかを確認する必要があります。
A server error message for an AUTHENTICATE command which fails due to invalid credentials SHOULD NOT detail why the credentials are invalid.
無効な資格情報が原因で失敗するAUTHENTICATEコマンドのサーバーエラーメッセージは、資格情報が無効である理由を詳しく記述すべきではありません（SHOULD NOT）。
Use of the LOGIN command sends passwords in the clear. This can be avoided by using the AUTHENTICATE command with a [SASL] mechanism that does not use plaintext passwords, by first negotiating encryption via STARTTLS or some other protection mechanism.
LOGINコマンドを使用すると、パスワードが平文で送信されます。これは、プレーンテキストのパスワードを使用しない[SASL]メカニズムでAUTHENTICATEコマンドを使用し、最初にSTARTTLSまたはその他の保護メカニズムを介して暗号化をネゴシエートすることで回避できます。
A server implementation MUST implement a configuration that, at the time of authentication, requires: (1) The STARTTLS command has been negotiated. OR (2) Some other mechanism that protects the session from password snooping has been provided. OR (3) The following measures are in place: (a) The LOGINDISABLED capability is advertised, and [SASL] mechanisms (such as PLAIN) using plaintext passwords are NOT advertised in the CAPABILITY list. AND (b) The LOGIN command returns an error even if the password is correct. AND (c) The AUTHENTICATE command returns an error with all [SASL] mechanisms that use plaintext passwords, even if the password is correct.
サーバーの実装は、認証時に必要な構成を実装する必要があります。（1）STARTTLSコマンドがネゴシエートされました。または（2）パスワードスヌーピングからセッションを保護するその他のメカニズムが提供されています。または（3）次の対策が講じられています。（a）LOGINDISABLED機能がアドバタイズされ、プレーンテキストのパスワードを使用する[SASL]メカニズム（プレーンなど）がCAPABILITYリストにアドバタイズされていません。 AND（b）パスワードが正しい場合でも、LOGINコマンドはエラーを返します。 AND（c）AUTHENTICATEコマンドは、パスワードが正しい場合でも、プレーンテキストのパスワードを使用するすべての[SASL]メカニズムでエラーを返します。
A server error message for a failing LOGIN command SHOULD NOT specify that the user name, as opposed to the password, is invalid.
失敗したLOGINコマンドのサーバーエラーメッセージは、パスワードではなくユーザー名が無効であることを指定する必要があります（SHOULD NOT）。
A server SHOULD have mechanisms in place to limit or delay failed AUTHENTICATE/LOGIN attempts.
サーバーは、失敗したAUTHENTICATE / LOGINの試行を制限または遅延するメカニズムを備えている必要があります（SHOULD）。
Additional security considerations are discussed in the section discussing the AUTHENTICATE and LOGIN commands.
セキュリティに関するその他の考慮事項については、AUTHENTICATEコマンドとLOGINコマンドのセクションで説明しています。
IMAP4 capabilities are registered by publishing a standards track or IESG approved experimental RFC. The registry is currently located at:
IMAP4機能は、標準トラックまたはIESG承認の実験的RFCを公開することによって登録されます。レジストリは現在次の場所にあります。
http://www.iana.org/assignments/imap4-capabilities
As this specification revises the STARTTLS and LOGINDISABLED extensions previously defined in [IMAP-TLS], the registry will be updated accordingly.
この仕様は、[IMAP-TLS]で以前に定義されたSTARTTLSおよびLOGINDISABLED拡張を改訂するため、レジストリはそれに応じて更新されます。
Appendices
付録
A. Normative References
A.規範的な参照
The following documents contain definitions or specifications that are necessary to understand this document properly: [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
次のドキュメントには、このドキュメントを正しく理解するために必要な定義または仕様が含まれています。[ABNF] Crocker、D.およびP. Overell、「Augmented BNF for Syntax Specifications：ABNF」、RFC 2234、1997年11月。
[ANONYMOUS] Newman, C., "Anonymous SASL Mechanism", RFC 2245, November 1997.
[匿名]ニューマン、C。、「匿名SASLメカニズム」、RFC 2245、1997年11月。
[CHARSET] Freed, N. and J. Postel, "IANA Character Set Registration Procedures", RFC 2978, October 2000.
[CHARSET] Freed、N。およびJ. Postel、「IANA Character Set Registration Procedures」、RFC 2978、2000年10月。
[DIGEST-MD5] Leach, P. and C. Newman, "Using Digest Authentication as a SASL Mechanism", RFC 2831, May 2000.
[DIGEST-MD5]リーチ、P。およびC.ニューマン、「SASLメカニズムとしてのダイジェスト認証の使用」、RFC 2831、2000年5月。
[DISPOSITION] Troost, R., Dorner, S. and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header", RFC 2183, August 1997.
[DISPOSITION] Troost、R.、Dorner、S。、およびK. Moore、「Communicating Presentation Information in Internet Messages：The Content-Disposition Header」、RFC 2183、1997年8月。
[IMAP-TLS] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June 1999.
[IMAP-TLS]ニューマン、C。、「TLSとIMAP、POP3およびACAPの使用」、RFC 2595、1999年6月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[LANGUAGE-TAGS] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001.
[LANGUAGE-TAGS] Alvestrand、H。、「言語の識別のためのタグ」、BCP 47、RFC 3066、2001年1月。
[LOCATION] Palme, J., Hopmann, A. and N. Shelness, "MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)", RFC 2557, March 1999.
[場所] Palme、J.、Hopmann、A。、およびN. Shelness、「HTML（MHTML）などの集約ドキュメントのMIMEカプセル化」、RFC 2557、1999年3月。
[MD5] Myers, J. and M. Rose, "The Content-MD5 Header Field", RFC 1864, October 1995.
[MD5]マイヤーズ、J。およびM.ローズ、「The Content-MD5 Header Field」、RFC 1864、1995年10月。
[MIME-HDRS] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[MIME-HDRS] Moore、K。、「MIME（Multipurpose Internet Mail Extensions）Part Three：Message Header Extensions for Non-ASCII Text」、RFC 2047、1996年11月。
[MIME-IMB] Freed, N. and N. Borenstein, "MIME (Multipurpose Internet Mail Extensions) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[MIME-IMB] Freed、N。およびN. Borenstein、「MIME（Multipurpose Internet Mail Extensions）Part One：Format of Internet Message Bodys」、RFC 2045、1996年11月。
[MIME-IMT] Freed, N. and N. Borenstein, "MIME (Multipurpose Internet Mail Extensions) Part Two: Media Types", RFC 2046, November 1996.
[MIME-IMT] Freed、N。およびN. Borenstein、「MIME（Multipurpose Internet Mail Extensions）Part Two：Media Types」、RFC 2046、1996年11月。
[RFC-2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[RFC-2822] Resnick、P。、「Internet Message Format」、RFC 2822、2001年4月。
[SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[SASL]マイヤーズ、J。、「Simple Authentication and Security Layer（SASL）」、RFC 2222、1997年10月。
[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[TLS] Dierks、T。およびC. Allen、「The TLS Protocol Version 1.0」、RFC 2246、1999年1月。
[UTF-7] Goldsmith, D. and M. Davis, "UTF-7: A Mail-Safe Transformation Format of Unicode", RFC 2152, May 1997.
[UTF-7] Goldsmith、D。およびM. Davis、「UTF-7：A Mail-Safe Transformation Format of Unicode」、RFC 2152、1997年5月。
The following documents describe quality-of-implementation issues that should be carefully considered when implementing this protocol:
次のドキュメントでは、このプロトコルを実装するときに注意深く検討する必要がある実装品質の問題について説明しています。
[IMAP-IMPLEMENTATION] Leiba, B., "IMAP Implementation Recommendations", RFC 2683, September 1999.
[IMAP-IMPLEMENTATION] Leiba、B。、「IMAP Implementation Recommendations」、RFC 2683、1999年9月。
[IMAP-MULTIACCESS] Gahrns, M., "IMAP4 Multi-Accessed Mailbox Practice", RFC 2180, July 1997.
[IMAP-MULTIACCESS] Gahrns、M。、「IMAP4 Multi-Accessed Mailbox Practice」、RFC 2180、1997年7月。
The following documents describe related protocols:
次のドキュメントでは、関連するプロトコルについて説明しています。
[IMAP-DISC] Austein, R., "Synchronization Operations for Disconnected IMAP4 Clients", Work in Progress.
[IMAP-DISC] Austein、R.、「切断されたIMAP4クライアントの同期操作」、作業中。
[IMAP-MODEL] Crispin, M., "Distributed Electronic Mail Models in IMAP4", RFC 1733, December 1994.
[IMAP-MODEL] Crispin、M。、「Distributed Electronic Mail Models in IMAP4」、RFC 1733、1994年12月。
[ACAP] Newman, C. and J. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997.
[ACAP]ニューマン、C。およびJ.マイヤーズ、「ACAP-Application Configuration Access Protocol」、RFC 2244、1997年11月。
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", STD 10, RFC 2821, April 2001.
[SMTP] Klensin、J。、「Simple Mail Transfer Protocol」、STD 10、RFC 2821、2001年4月。
The following documents are historical or describe historical aspects of this protocol:
次のドキュメントは歴史的であるか、このプロトコルの歴史的側面を説明しています：
[IMAP-COMPAT] Crispin, M., "IMAP4 Compatibility with IMAP2bis", RFC 2061, December 1996.
[IMAP-COMPAT] Crispin、M。、「IMAP4とIMAP2bisの互換性」、RFC 2061、1996年12月。
[IMAP-HISTORICAL] Crispin, M., "IMAP4 Compatibility with IMAP2 and IMAP2bis", RFC 1732, December 1994.
[IMAP-HISTORICAL] Crispin、M。、「IMAP4 Compatibility with IMAP2 and IMAP2bis」、RFC 1732、1994年12月。
[IMAP-OBSOLETE] Crispin, M., "Internet Message Access Protocol - Obsolete Syntax", RFC 2062, December 1996.
[IMAP-OBSOLETE] Crispin、M。、「Internet Message Access Protocol-Obsolete Syntax」、RFC 2062、1996年12月。
[IMAP2] Crispin, M., "Interactive Mail Access Protocol - Version 2", RFC 1176, August 1990.
[IMAP2] Crispin、M。、「Interactive Mail Access Protocol-Version 2」、RFC 1176、1990年8月。
[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
[RFC-822] Crocker、D。、「Standard for the Format for ARPA Internet Text Messages」、STD 11、RFC 822、1982年8月。
[RFC-821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[RFC-821] Postel、J。、「Simple Mail Transfer Protocol」、STD 10、RFC 821、1982年8月。
B. Changes from RFC 2060
B. RFC 2060からの変更
1) Clarify description of unique identifiers and their semantics.
1）一意の識別子とそのセマンティクスの説明を明確にします。
2) Fix the SELECT description to clarify that UIDVALIDITY is required in the SELECT and EXAMINE responses.
2）SELECTの説明を修正して、SELECTおよびEXAMINE応答でUIDVALIDITYが必要であることを明確にします。
3) Added an example of a failing search.
3）失敗した検索の例が追加されました。
4) Correct store-att-flags: "#flag" should be "1#flag".
4）store-att-flagsを修正：「#flag」は「1＃flag」である必要があります。
5) Made search and section rules clearer.
5）検索とセクションのルールがより明確になりました。
6) Correct the STORE example.
6) Correct the STORE example.
7) Correct "BASE645" misspelling.
7）「BASE645」のスペルミスを修正しました。
8) Remove extraneous close parenthesis in example of two-part message with text and BASE64 attachment.
8）テキストとBASE64が添付された2部構成のメッセージの例で、無関係な右括弧を削除します。
9) Remove obsolete "MAILBOX" response from mailbox-data.
9）メールボックスデータから古い「MAILBOX」応答を削除します。
10) A spurious "<" in the rule for mailbox-data was removed.
10）メールボックスデータのルールの誤った「<」が削除されました。
11) Add CRLF to continue-req.
11）continue-reqにCRLFを追加します。
12) Specifically exclude "]" from the atom in resp-text-code.
12）resp-text-codeのアトムから「]」を明確に除外します。
13) Clarify that clients and servers should adhere strictly to the protocol syntax.
13）クライアントとサーバーがプロトコル構文に厳密に従う必要があることを明確にします。
14) Emphasize in 5.2 that EXISTS can not be used to shrink a mailbox.
14）5.2では、EXISTSを使用してメールボックスを縮小できないことを強調します。
15) Add NEWNAME to resp-text-code.
15）NEWNAMEをresp-text-codeに追加します。
16) Clarify that the empty string, not NIL, is used as arguments to LIST.
16）NILではなく空の文字列がLISTの引数として使用されることを明確にします。
17) Clarify that NIL can be returned as a hierarchy delimiter for the empty string mailbox name argument if the mailbox namespace is flat.
17）メールボックスの名前空間がフラットの場合、空の文字列メールボックス名引数の階層区切り文字としてNILが返される可能性があることを明確にします。
18) Clarify that addr-mailbox and addr-name have RFC-2822 quoting removed.
18）addr-mailboxとaddr-nameでRFC-2822の引用が削除されたことを明確にします。
19) Update UTF-7 reference.
19）UTF-7参照を更新します。
20) Fix example in 6.3.11.
20) Fix example in 6.3.11.
21) Clarify that non-existent UIDs are ignored.
21）存在しないUIDは無視されることを明確にします。
22) Update DISPOSITION reference.
22）DISPOSITIONリファレンスを更新します。
23) Expand state diagram.
23) Expand state diagram.
24) Clarify that partial fetch responses are only returned in response to a partial fetch command.
24）部分的なフェッチ応答は、部分的なフェッチコマンドに応答してのみ返されることを明確にします。
25) Add UIDNEXT response code. Correct UIDVALIDITY definition reference.
25）UIDNEXT応答コードを追加します。 UIDVALIDITY定義の参照を訂正してください。
26) Further clarification of "can" vs. "MAY".
26）「できる」と「5月」のさらなる明確化。
27) Reference RFC-2119.
27）RFC-2119を参照してください。
28) Clarify that superfluous shifts are not permitted in modified UTF-7.
28) Clarify that superfluous shifts are not permitted in modified UTF-7.
29) Clarify that there are no implicit shifts in modified UTF-7.
29) Clarify that there are no implicit shifts in modified UTF-7.
30) Clarify that "INBOX" in a mailbox name is always INBOX, even if it is given as a string.
30) Clarify that "INBOX" in a mailbox name is always INBOX, even if it is given as a string.
31) Add missing open parenthesis in media-basic grammar rule.
31）欠落している開き括弧をメディア基本文法規則に追加します。
32) Correct attribute syntax in mailbox-data.
32) Correct attribute syntax in mailbox-data.
33) Add UIDNEXT to EXAMINE responses.
33）UIDNEXTをEXAMINE応答に追加します。
34) Clarify UNSEEN, PERMANENTFLAGS, UIDVALIDITY, and UIDNEXT responses in SELECT and EXAMINE. They are required now, but weren't in older versions.
34) Clarify UNSEEN, PERMANENTFLAGS, UIDVALIDITY, and UIDNEXT responses in SELECT and EXAMINE. They are required now, but weren't in older versions.
35) Update references with RFC numbers.
35）RFC番号で参照を更新します。
36) Flush text-mime2.
36）text-mime2をフラッシュします。
37) Clarify that modified UTF-7 names must be case-sensitive and that violating the convention should be avoided.
37）変更されたUTF-7名は大文字と小文字を区別する必要があり、規則に違反しないようにする必要があることを明確にします。
38) Correct UID FETCH example.
38）UID FETCHの例を修正します。
39) Clarify UID FETCH, UID STORE, and UID SEARCH vs. untagged EXPUNGE responses.
39) Clarify UID FETCH, UID STORE, and UID SEARCH vs. untagged EXPUNGE responses.
40) Clarify the use of the word "convention".
40）「慣習」という言葉の使用を明確にします。
41) Clarify that a command is not "in progress" until it has been fully received (specifically, that a command is not "in progress" during command continuation negotiation).
41) Clarify that a command is not "in progress" until it has been fully received (specifically, that a command is not "in progress" during command continuation negotiation).
42) Clarify envelope defaulting.
42）エンベロープのデフォルトを明確化。
43) Clarify that SP means one and only one space character.
43）SPが唯一のスペース文字を意味することを明確にします。
44) Forbid silly states in LIST response.
44) Forbid silly states in LIST response.
45) Clarify that the ENVELOPE, INTERNALDATE, RFC822*, BODY*, and UID for a message is static.
45) Clarify that the ENVELOPE, INTERNALDATE, RFC822*, BODY*, and UID for a message is static.
46) Add BADCHARSET response code.
46) Add BADCHARSET response code.
47) Update formal syntax to [ABNF] conventions.
47) Update formal syntax to [ABNF] conventions.
48) Clarify trailing hierarchy delimiter in CREATE semantics.
48）CREATEセマンティクスの末尾の階層区切り文字を明確化。
49) Clarify that the "blank line" is the [RFC-2822] delimiting blank line.
49) Clarify that the "blank line" is the [RFC-2822] delimiting blank line.
50) Clarify that RENAME should also create hierarchy as needed for the command to complete.
50）コマンドの完了に必要なRENAMEも階層を作成する必要があることを明確にします。
51) Fix body-ext-mpart to not require language if disposition present.
51) Fix body-ext-mpart to not require language if disposition present.
52) Clarify the RFC822.HEADER response.
52）RFC822.HEADER応答を明確にします。
53) Correct missing space after charset astring in search.
53）検索で文字セット文字列の後に欠落していたスペースを修正しました。
54) Correct missing quote for BADCHARSET in resp-text-code.
54）resp-text-codeのBADCHARSETの欠落した引用を修正しました。
55) Clarify that ALL, FAST, and FULL preclude any other data items appearing.
55) Clarify that ALL, FAST, and FULL preclude any other data items appearing.
56) Clarify semantics of reference argument in LIST.
56）リストの参照引数のセマンティクスを明確化。
57) Clarify that a null string for SEARCH HEADER X-FOO means any message with a header line with a field-name of X-FOO regardless of the text of the header.
57) Clarify that a null string for SEARCH HEADER X-FOO means any message with a header line with a field-name of X-FOO regardless of the text of the header.
58) Specifically reserve 8-bit mailbox names for future use as UTF-8.
58) Specifically reserve 8-bit mailbox names for future use as UTF-8.
59) It is not an error for the client to store a flag that is not in the PERMANENTFLAGS list; however, the server will either ignore the change or make the change in the session only.
59）PERMANENTFLAGSリストにないフラグをクライアントが保存してもエラーにはなりません。ただし、サーバーは変更を無視するか、セッションでのみ変更を行います。
60) Correct/clarify the text regarding superfluous shifts.
60) Correct/clarify the text regarding superfluous shifts.
61) Correct typographic errors in the "Changes" section.
61）「変更」セクションの誤植を修正します。
62) Clarify that STATUS must not be used to check for new messages in the selected mailbox
62) Clarify that STATUS must not be used to check for new messages in the selected mailbox
63) Clarify LSUB behavior with "%" wildcard.
63）「％」ワイルドカードを使用してLSUBの動作を明確にします。
64) Change AUTHORIZATION to AUTHENTICATE in section 7.5.
64）セクション7.5でAUTHORIZATIONをAUTHENTICATEに変更します。
65) Clarify description of multipart body type.
65) Clarify description of multipart body type.
66) Clarify that STORE FLAGS does not affect \Recent.
66）STORE FLAGSが\ Recentに影響しないことを明確にします。
67) Change "west" to "east" in description of timezone.
67）タイムゾーンの説明で「西」を「東」に変更します。
68) Clarify that commands which break command pipelining must wait for a completion result response.
68）コマンドのパイプライン処理を解除するコマンドは、完了結果の応答を待つ必要があることを明確にします。
69) Clarify that EXAMINE does not affect \Recent.
69）EXAMINEが\ Recentに影響しないことを明確にします。
70) Make description of MIME structure consistent.
70）MIME構造の記述に一貫性を持たせます。
71) Clarify that date searches disregard the time and timezone of the INTERNALDATE or Date: header. In other words, "ON 13-APR-2000" means messages with an INTERNALDATE text which starts with "13-APR-2000", even if timezone differential from the local timezone is sufficient to move that INTERNALDATE into the previous or next day.
71）日付検索がINTERNALDATEまたはDate：ヘッダーの時間とタイムゾーンを無視することを明確にします。言い換えると、「ON 13-APR-2000」は、ローカルタイムゾーンとのタイムゾーンの差がそのINTERNALDATEを前日または翌日に移動するのに十分である場合でも、「13-APR-2000」で始まるINTERNALDATEテキストのメッセージを意味します
72) Clarify that the header fetches don't add a blank line if one isn't in the [RFC-2822] message.
72) Clarify that the header fetches don't add a blank line if one isn't in the [RFC-2822] message.
73) Clarify (in discussion of UIDs) that messages are immutable.
73) Clarify (in discussion of UIDs) that messages are immutable.
74) Add an example of CHARSET searching.
74) Add an example of CHARSET searching.
75) Clarify in SEARCH that keywords are a type of flag.
75）キーワードがフラグの一種であることを検索で明確化します。
76) Clarify the mandatory nature of the SELECT data responses.
76）SELECTデータ応答の必須の性質を明確にします。
77) Add optional CAPABILITY response code in the initial OK or PREAUTH.
77) Add optional CAPABILITY response code in the initial OK or PREAUTH.
78) Add note that server can send an untagged CAPABILITY command as part of the responses to AUTHENTICATE and LOGIN.
78) Add note that server can send an untagged CAPABILITY command as part of the responses to AUTHENTICATE and LOGIN.
79) Remove statement about it being unnecessary to issue a CAPABILITY command more than once in a connection. That statement is no longer true.
79) Remove statement about it being unnecessary to issue a CAPABILITY command more than once in a connection. That statement is no longer true.
80) Clarify that untagged EXPUNGE decrements the number of messages in the mailbox.
80）タグなしのEXPUNGEがメールボックス内のメッセージの数を減らすことを明確にします。
81) Fix definition of "body" (concatenation has tighter binding than alternation).
81） "body"の定義を修正します（連結には交互よりも強い結合があります）。
82) Add a new "Special Notes to Implementors" section with reference to [IMAP-IMPLEMENTATION].
82) Add a new "Special Notes to Implementors" section with reference to [IMAP-IMPLEMENTATION].
83) Clarify that an untagged CAPABILITY response to an AUTHENTICATE command should only be done if a security layer was not negotiated.
83) Clarify that an untagged CAPABILITY response to an AUTHENTICATE command should only be done if a security layer was not negotiated.
84) Change the definition of atom to exclude "]". Update astring to include "]" for compatibility with the past. Remove resp-text-atom.
84）「]」を除外するようにアトムの定義を変更します。過去との互換性のために、文字列を「]」を含むように更新します。 resp-text-atomを削除します。
85) Remove NEWNAME. It can't work because mailbox names can be literals and can include "]". Functionality can be addressed via referrals.
85) Remove NEWNAME. It can't work because mailbox names can be literals and can include "]". Functionality can be addressed via referrals.
86) Move modified UTF-7 rationale in order to have more logical paragraph flow.
86）より論理的な段落フローを持たせるために、変更されたUTF-7の根拠を移動します。
87) Clarify UID uniqueness guarantees with the use of MUST.
87）MUSTを使用してUIDの一意性保証を明確化します。
88) Note that clients should read response data until the connection is closed instead of immediately closing on a BYE.
88) Note that clients should read response data until the connection is closed instead of immediately closing on a BYE.
89) Change RFC-822 references to RFC-2822.
89) Change RFC-822 references to RFC-2822.
90) Clarify that RFC-2822 should be followed instead of RFC-822.
90）RFC-822の代わりにRFC-2822に従うべきであることを明確にします。
91) Change recommendation of optional automatic capabilities in LOGIN and AUTHENTICATE to use the CAPABILITY response code in the tagged OK. This is more interoperable than an unsolicited untagged CAPABILITY response.
91）LOGINおよびAUTHENTICATEのオプションの自動機能の推奨を変更して、タグ付きOKでCAPABILITY応答コードを使用します。これは、一方的なタグなしのCAPABILITY応答よりも相互運用性が高くなります。
92) STARTTLS and AUTH=PLAIN are mandatory to implement; add recommendations for other [SASL] mechanisms.
92) STARTTLS and AUTH=PLAIN are mandatory to implement; add recommendations for other [SASL] mechanisms.
93) Clarify that a "connection" (as opposed to "server" or "command") is in one of the four states.
93) Clarify that a "connection" (as opposed to "server" or "command") is in one of the four states.
94) Clarify that a failed or rejected command does not change state.
94) Clarify that a failed or rejected command does not change state.
95) Split references between normative and informative.
95）参照を規範的と情報的の間で分割する。
96) Discuss authentication failure issues in security section.
96）セキュリティセクションで認証失敗の問題を議論します。
97) Clarify that a data item is not necessarily of only one data type.
97) Clarify that a data item is not necessarily of only one data type.
98) Clarify that sequence ranges are independent of order.
98) Clarify that sequence ranges are independent of order.
99) Change an example to clarify that superfluous shifts in Modified-UTF7 can not be fixed just by omitting the shift. The entire string must be recalculated.
99) Change an example to clarify that superfluous shifts in Modified-UTF7 can not be fixed just by omitting the shift. The entire string must be recalculated.
100) Change Envelope Structure definition since [RFC-2822] uses "envelope" to refer to the [SMTP] envelope and not the envelope data that appears in the [RFC-2822] header.
100）[RFC-2822]は[RFC-2822]ヘッダーに表示されるエンベロープデータではなく[SMTP]エンベロープを参照するために「エンベロープ」を使用するため、エンベロープ構造の定義を変更します。
101) Expand on RFC822.HEADER response data vs. BODY[HEADER].
101）RFC822.HEADER応答データ対BODY [HEADER]を展開します。
102) Clarify Logout state semantics, change ASCII art.
102）ログアウト状態のセマンティクスを明確にし、ASCIIアートを変更します。
103) Security changes to comply with IESG requirements.
103）IESG要件に準拠するためのセキュリティの変更。
104) Add definition for body URI.
104) Add definition for body URI.
105) Break sequence range definition into three rules, with rewritten descriptions for each.
105）シーケンス範囲の定義を3つのルールに分割し、それぞれの説明を書き直します。
106) Move STARTTLS and LOGINDISABLED here from [IMAP-TLS].
106) Move STARTTLS and LOGINDISABLED here from [IMAP-TLS].
107) Add IANA Considerations section.
107) Add IANA Considerations section.
108) Clarify valid client assumptions for new message UIDs vs. UIDNEXT.
108) Clarify valid client assumptions for new message UIDs vs. UIDNEXT.
109) Clarify that changes to permanentflags affect concurrent sessions as well as subsequent sessions.
109) Clarify that changes to permanentflags affect concurrent sessions as well as subsequent sessions.
110) Clarify that authenticated state can be entered by the CLOSE command.
110）CLOSEコマンドで認証済み状態に入ることができることを明確にします。
111) Emphasize that SELECT and EXAMINE are the exceptions to the rule that a failing command does not change state.
111）SELECTとEXAMINEは、失敗したコマンドが状態を変更しないというルールの例外であることを強調します。
112) Clarify that newly-appended messages have the Recent flag set.
112）新しく追加されたメッセージに[最近]フラグが設定されていることを明確にします。
113) Clarify that newly-copied messages SHOULD have the Recent flag set.
113）新しくコピーされたメッセージには、Recentフラグが設定されている必要があることを明確にします。
114) Clarify that UID commands always return the UID in FETCH responses.
114) Clarify that UID commands always return the UID in FETCH responses.
C. Key Word Index
C.キーワードインデックス
+FLAGS <flag list> (store command data item) ............... 59
+FLAGS.SILENT <flag list> (store command data item) ........ 59
-FLAGS <flag list> (store command data item) ............... 59
-FLAGS.SILENT <flag list> (store command data item) ........ 59
ALERT (response code) ...................................... 64
ALL (fetch item) ........................................... 55
ALL (search key) ........................................... 50
ANSWERED (search key) ...................................... 50
APPEND (command) ........................................... 45
AUTHENTICATE (command) ..................................... 27
BAD (response) ............................................. 66
BADCHARSET (response code) ................................. 64
BCC <string> (search key) .................................. 51
BEFORE <date> (search key) ................................. 51
BODY (fetch item) .......................................... 55
BODY (fetch result) ........................................ 73
BODY <string> (search key) ................................. 51
BODY.PEEK[<section>]<<partial>> (fetch item) ............... 57
BODYSTRUCTURE (fetch item) ................................. 57
BODYSTRUCTURE (fetch result) ............................... 74
BODY[<section>]<<origin octet>> (fetch result) ............. 74
BODY[<section>]<<partial>> (fetch item) .................... 55
BYE (response) ............................................. 67
Body Structure (message attribute) ......................... 12
CAPABILITY (command) ....................................... 24
CAPABILITY (response code) ................................. 64
CAPABILITY (response) ...................................... 68
CC <string> (search key) ................................... 51
CHECK (command) ............................................ 47
CLOSE (command) ............................................ 48
COPY (command) ............................................. 59
CREATE (command) ........................................... 34
DELETE (command) ........................................... 35
DELETED (search key) ....................................... 51
DRAFT (search key) ......................................... 51
ENVELOPE (fetch item) ...................................... 57
ENVELOPE (fetch result) .................................... 77
EXAMINE (command) .......................................... 33
EXISTS (response) .......................................... 71
EXPUNGE (command) .......................................... 48
EXPUNGE (response) ......................................... 72
Envelope Structure (message attribute) ..................... 12
FAST (fetch item) .......................................... 55
FETCH (command) ............................................ 54
FETCH (response) ........................................... 73
FLAGGED (search key) ....................................... 51
FLAGS (fetch item) ......................................... 57
FLAGS (fetch result) ....................................... 78
FLAGS (response) ........................................... 71
FLAGS <flag list> (store command data item) ................ 59
FLAGS.SILENT <flag list> (store command data item) ......... 59
FROM <string> (search key) ................................. 51
FULL (fetch item) .......................................... 55
Flags (message attribute) .................................. 11
HEADER (part specifier) .................................... 55
HEADER <field-name> <string> (search key) .................. 51
HEADER.FIELDS <header-list> (part specifier) ............... 55
HEADER.FIELDS.NOT <header-list> (part specifier) ........... 55
INTERNALDATE (fetch item) .................................. 57
INTERNALDATE (fetch result) ................................ 78
Internal Date (message attribute) .......................... 12
KEYWORD <flag> (search key) ................................ 51
Keyword (type of flag) ..................................... 11
LARGER <n> (search key) .................................... 51
LIST (command) ............................................. 40
LIST (response) ............................................ 69
LOGIN (command) ............................................ 30
LOGOUT (command) ........................................... 25
LSUB (command) ............................................. 43
LSUB (response) ............................................ 70
MAY (specification requirement term) ....................... 4
MESSAGES (status item) ..................................... 45
MIME (part specifier) ...................................... 56
MUST (specification requirement term) ...................... 4
MUST NOT (specification requirement term) .................. 4
Message Sequence Number (message attribute) ................ 10
NEW (search key) ........................................... 51
NO (response) .............................................. 66
NOOP (command) ............................................. 25
NOT <search-key> (search key) .............................. 52
OK (response) .............................................. 65
OLD (search key) ........................................... 52
ON <date> (search key) ..................................... 52
OPTIONAL (specification requirement term) .................. 4
OR <search-key1> <search-key2> (search key) ................ 52
PARSE (response code) ...................................... 64
PERMANENTFLAGS (response code) ............................. 64
PREAUTH (response) ......................................... 67
Permanent Flag (class of flag) ............................. 12
READ-ONLY (response code) .................................. 65
READ-WRITE (response code) ................................. 65
RECENT (response) .......................................... 72
RECENT (search key) ........................................ 52
RECENT (status item) ....................................... 45
RENAME (command) ........................................... 37
REQUIRED (specification requirement term) .................. 4
RFC822 (fetch item) ........................................ 57
RFC822 (fetch result) ...................................... 78
RFC822.HEADER (fetch item) ................................. 57
RFC822.HEADER (fetch result) ............................... 78
RFC822.SIZE (fetch item) ................................... 57
RFC822.SIZE (fetch result) ................................. 78
RFC822.TEXT (fetch item) ................................... 58
RFC822.TEXT (fetch result) ................................. 79
SEARCH (command) ........................................... 49
SEARCH (response) .......................................... 71
SEEN (search key) .......................................... 52
SELECT (command) ........................................... 31
SENTBEFORE <date> (search key) ............................. 52
SENTON <date> (search key) ................................. 52
SENTSINCE <date> (search key) .............................. 52
SHOULD (specification requirement term) .................... 4
SHOULD NOT (specification requirement term) ................ 4
SINCE <date> (search key) .................................. 52
SMALLER <n> (search key) ................................... 52
STARTTLS (command) ......................................... 27
STATUS (command) ........................................... 44
STATUS (response) .......................................... 70
STORE (command) ............................................ 58
SUBJECT <string> (search key) .............................. 53
SUBSCRIBE (command) ........................................ 38
Session Flag (class of flag) ............................... 12
System Flag (type of flag) ................................. 11
TEXT (part specifier) ...................................... 56
TEXT <string> (search key) ................................. 53
TO <string> (search key) ................................... 53
TRYCREATE (response code) .................................. 65
UID (command) .............................................. 60
UID (fetch item) ........................................... 58
UID (fetch result) ......................................... 79
UID <sequence set> (search key) ............................ 53
UIDNEXT (response code) .................................... 65
UIDNEXT (status item) ...................................... 45
UIDVALIDITY (response code) ................................ 65
UIDVALIDITY (status item) .................................. 45
UNANSWERED (search key) .................................... 53
UNDELETED (search key) ..................................... 53
UNDRAFT (search key) ....................................... 53
UNFLAGGED (search key) ..................................... 53
UNKEYWORD <flag> (search key) .............................. 53
UNSEEN (response code) ..................................... 65
UNSEEN (search key) ........................................ 53
UNSEEN (status item) ....................................... 45
UNSUBSCRIBE (command) ...................................... 39
Unique Identifier (UID) (message attribute) ................ 8
X<atom> (command) .......................................... 62
[RFC-2822] Size (message attribute) ........................ 12
\Answered (system flag) .................................... 11
\Deleted (system flag) ..................................... 11
\Draft (system flag) ....................................... 11
\Flagged (system flag) ..................................... 11
\Marked (mailbox name attribute) ........................... 69
\Noinferiors (mailbox name attribute) ...................... 69
\Noselect (mailbox name attribute) ......................... 69
\Recent (system flag) ...................................... 11
\Seen (system flag) ........................................ 11
\Unmarked (mailbox name attribute) ......................... 69 Author's Address
Mark R. Crispin Networks and Distributed Computing University of Washington 4545 15th Avenue NE Seattle, WA 98105-4527
Mark R. Crispin Networks and Distributed Computing University of Washington 4545 15th Avenue NE Seattle, WA 98105-4527
Phone: (206) 543-5762
電話：（206）543-5762
EMail: MRC@CAC.Washington.EDU
Full Copyright Statement
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（C）The Internet Society（2003）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. v This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。 v本書および本書に含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに含まれる情報の使用が保証するものに限定されないいかなる保証も含め、すべての保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害するものではありません。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
Funding for the RFC Editor function is currently provided by the Internet Society.