RFC1730 日本語訳
1730 Internet Message Access Protocol - Version 4. M. Crispin. December 1994. (Format: TXT=156660 bytes) (Obsoleted by RFC2060, RFC2061) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group M. Crispin Request for Comments: 1730 University of Washington Category: Standards Track December 1994
コメントを求めるワーキンググループM.クリスピン要求をネットワークでつないでください: 1730年のワシントン大学カテゴリ: 標準化過程1994年12月
INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4
インターネットメッセージアクセス・プロトコル--バージョン4
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
The Internet Message Access Protocol, Version 4 (IMAP4) allows a client to access and manipulate electronic mail messages on a server. IMAP4 permits manipulation of remote message folders, called "mailboxes", in a way that is functionally equivalent to local mailboxes. IMAP4 also provides the capability for an offline client to resynchronize with the server (see also [IMAP-DISC]).
インターネットMessage Accessプロトコル、バージョン4(IMAP4)で、クライアントはサーバに関する電子メールメッセージにアクセスして、操ります。IMAP4は地方のメールボックスに機能上同等な方法で「メールボックス」と呼ばれるリモートメッセージフォルダーの操作を可能にします。 また、IMAP4はオフラインクライアントがサーバ(また[IMAP-DISC]、見る)で再連動する能力を提供します。
IMAP4 includes operations for creating, deleting, and renaming mailboxes; checking for new messages; permanently removing messages; setting and clearing flags; RFC 822 and MIME parsing; searching; and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4 are accessed by the use of numbers. These numbers are either message sequence numbers (relative position from 1 to the number of messages in the mailbox) or unique identifiers (immutable, strictly ascending values assigned to each message, but which are not necessarily contiguous).
IMAP4はメールボックスを作成して、削除して、改名するための操作を含んでいます。 新しいメッセージのための照合。 永久に、メッセージを取り除きます。 設定と開拓地は弛みます。 RFC822とMIME構文解析。 探します。 そして、メッセージ属性、テキスト、およびそれの部分を選択しているとって来ること。 数の使用でIMAP4のメッセージはアクセスされます。 これらの数は、メッセージ通番(相対的な1〜メールボックスの中のメッセージの数までの位置)かユニークな識別子(各メッセージに割り当てられた必ず隣接であるというわけではない不変の、そして、厳密に昇っている値)のどちらかです。
IMAP4 supports a single server. A mechanism for supporting multiple IMAP4 servers is discussed in [IMSP].
IMAP4はただ一つのサーバをサポートします。[IMSP]で複数のIMAP4サーバをサポートするためのメカニズムについて議論します。
IMAP4 does not specify a means of posting mail; this function is handled by a mail transfer protocol such as [SMTP].
IMAP4はメールを掲示する手段を指定しません。 この機能は[SMTP]などのメール転送プロトコルによって扱われます。
IMAP4 is designed to be upwards compatible from the [IMAP2] protocol. Compatibility issues are discussed in [IMAP-COMPAT].
IMAP4は、[IMAP2]プロトコルから上向きに互換性があるように設計されています。 [IMAP-COMPAT]で互換性の問題について議論します。
Crispin [Page i] RFC 1730 IMAP4 December 1994
クリスピン[ページi]RFC1730IMAP4 December 1994
Table of Contents
目次
IMAP4 Protocol Specification ...................................... 1 1. Organization of this Document ............................. 1 1.1. How to Read This Document ................................. 1 1.2. Conventions Used in this Document ......................... 1 2. Protocol Overview ......................................... 1 2.1. Link Level ................................................ 1 2.2. Commands and Responses .................................... 1 2.2.1. Client Protocol Sender and Server Protocol Receiver ....... 2 2.2.2. Server Protocol Sender and Client Protocol Receiver ....... 2 3. State and Flow Diagram .................................... 4 3.1. Non-Authenticated State ................................... 4 3.2. Authenticated State ....................................... 4 3.3. Selected State ............................................ 4 3.4. Logout State .............................................. 4 4. Data Formats .............................................. 6 4.1. Atom ...................................................... 6 4.2. Number .................................................... 6 4.3. String .................................................... 6 4.3.1. 8-bit and Binary Strings .................................. 7 4.4. Parenthesized List ........................................ 7 4.5. NIL ....................................................... 7 5. Operational Considerations ................................ 8 5.1. Mailbox Naming ............................................ 8 5.2. Mailbox Size and Message Status Updates ................... 8 5.3. Response when no Command in Progress ...................... 8 5.4. Autologout Timer .......................................... 9 5.5. Multiple Commands in Progress ............................. 9 6. Client Commands ........................................... 10 6.1. Client Commands - Any State ............................... 10 6.1.1. CAPABILITY Command ........................................ 10 6.1.2. NOOP Command .............................................. 11 6.1.3. LOGOUT Command ............................................ 11 6.2. Client Commands - Non-Authenticated State ................. 12 6.2.1. AUTHENTICATE Command ...................................... 12 6.2.2. LOGIN Command ............................................. 14 6.3. Client Commands - Authenticated State ..................... 14 6.3.1. SELECT Command ............................................ 15 6.3.2. EXAMINE Command ........................................... 16 6.3.3. CREATE Command ............................................ 17 6.3.4. DELETE Command ............................................ 18 6.3.5. RENAME Command ............................................ 18
IMAP4は仕様を議定書の中で述べます… 1 1. このDocumentの組織… 1 1.1. どうこのドキュメントを読むか… 1 1.2. このDocumentのコンベンションUsed… 1 2. 概要について議定書の中で述べてください… 1 2.1. レベルをリンクしてください… 1 2.2. コマンドと応答… 1 2.2.1. クライアントプロトコル送付者とサーバは受信機について議定書の中で述べます… 2 2.2.2. サーバプロトコル送付者とクライアントは受信機について議定書の中で述べます… 2 3. 状態とフローチャート… 4 3.1. 非認証された状態… 4 3.2. 状態を認証します… 4 3.3. 状態を選択します… 4 3.4. ログアウト、状態… 4 4. データ形式… 6 4.1. 原子… 6 4.2. 数… 6 4.3. 結びます。 6 4.3.1. 8ビットの、そして、2進のストリング… 7 4.4. リストをParenthesizedしました… 7 4.5. 無… 7 5. 操作上の問題… 8 5.1. メールボックス命名… 8 5.2. メールボックスサイズとメッセージ状態最新版… 8 5.3. ProgressでCommandでないことの応答… 8 5.4. Autologoutタイマ… 9 5.5. 倍数は進行中で命令します… 9 6. クライアントは命令します… 10 6.1. クライアントは命令します--どんな状態。 10 6.1.1. 能力コマンド… 10 6.1.2. NOOPは命令します… 11 6.1.3. ログアウトコマンド… 11 6.2. クライアントは命令します--非認証された状態。 12 6.2.1. コマンドを認証してください… 12 6.2.2. ログインコマンド… 14 6.3. クライアントは命令します--状態を認証します… 14 6.3.1. コマンドを選択してください… 15 6.3.2. コマンドを調べてください… 16 6.3.3. コマンドを作成してください… 17 6.3.4. コマンドを削除してください… 18 6.3.5. コマンドを改名してください… 18
Crispin [Page ii] RFC 1730 IMAP4 December 1994
クリスピン[ページii]RFC1730IMAP4 December 1994
6.3.6. SUBSCRIBE Command ......................................... 19 6.3.7. UNSUBSCRIBE Command ....................................... 19 6.3.8. LIST Command .............................................. 20 6.3.9. LSUB Command .............................................. 22 6.3.10. APPEND Command ............................................ 22 6.4. Client Commands - Selected State .......................... 23 6.4.1. CHECK Command ............................................. 23 6.4.2. CLOSE Command ............................................. 24 6.4.3. EXPUNGE Command ........................................... 25 6.4.4. SEARCH Command ............................................ 25 6.4.5. FETCH Command ............................................. 29 6.4.6. PARTIAL Command ........................................... 32 6.4.7. STORE Command ............................................. 33 6.4.8. COPY Command .............................................. 34 6.4.9. UID Command ............................................... 35 6.5. Client Commands - Experimental/Expansion .................. 37 6.5.1. X<atom> Command ........................................... 37 7. Server Responses .......................................... 38 7.1. Server Responses - Status Responses ....................... 39 7.1.1. OK Response ............................................... 40 7.1.2. NO Response ............................................... 40 7.1.3. BAD Response .............................................. 41 7.1.4. PREAUTH Response .......................................... 41 7.1.5. BYE Response .............................................. 41 7.2. Server Responses - Server and Mailbox Status .............. 42 7.2.1. CAPABILITY Response ....................................... 42 7.2.2. LIST Response ............................................. 43 7.2.3. LSUB Response ............................................. 44 7.2.4. SEARCH Response ........................................... 44 7.2.5. FLAGS Response ............................................ 44 7.3. Server Responses - Message Status ......................... 45 7.3.1. EXISTS Response ........................................... 45 7.3.2. RECENT Response ........................................... 45 7.3.3. EXPUNGE Response .......................................... 45 7.3.4. FETCH Response ............................................ 46 7.3.5. Obsolete Responses ........................................ 51 7.4. Server Responses - Command Continuation Request ........... 51 8. Sample IMAP4 session ...................................... 52 9. Formal Syntax ............................................. 53 10. Author's Note ............................................. 64 11. Security Considerations ................................... 64 12. Author's Address .......................................... 64 Appendices ........................................................ 65 A. Obsolete Commands ......................................... 65 A.6.3.OBS.1. FIND ALL.MAILBOXES Command ........................ 65 A.6.3.OBS.2. FIND MAILBOXES Command ............................ 65 A.6.3.OBS.3. SUBSCRIBE MAILBOX Command ......................... 66 A.6.3.OBS.4. UNSUBSCRIBE MAILBOX Command ....................... 66
6.3.6. コマンドを申し込んでください… 19 6.3.7. コマンドを外してください… 19 6.3.8. コマンドを記載してください… 20 6.3.9. LSUBは命令します… 22 6.3.10. コマンドを追加してください… 22 6.4. クライアントは命令します--状態を選択します… 23 6.4.1. コマンドをチェックしてください… 23 6.4.2. コマンドを終えてください… 24 6.4.3. コマンドを梢消してください… 25 6.4.4. コマンドを捜してください… 25 6.4.5. コマンドをとって来てください… 29 6.4.6. 部分的なコマンド… 32 6.4.7. コマンドを保存してください… 33 6.4.8. コマンドをコピーしてください… 34 6.4.9. UIDは命令します… 35 6.5. クライアントは命令します--実験的な/拡張 37 6.5.1. X<原子>は命令します… 37 7. サーバ応答… 38 7.1. サーバ応答--状態応答… 39 7.1.1. 応答を承認してください… 40 7.1.2. 応答がありません… 40 7.1.3. 悪い応答… 41 7.1.4. PREAUTH応答… 41 7.1.5. さようなら応答… 41 7.2. サーバ応答--サーバとメールボックス状態… 42 7.2.1. 能力応答… 42 7.2.2. 応答を記載してください… 43 7.2.3. LSUB応答… 44 7.2.4. 応答を捜してください… 44 7.2.5. 応答に旗を揚げさせます… 44 7.3. サーバ応答--メッセージ状態… 45 7.3.1. 存在、応答… 45 7.3.2. 最近の応答… 45 7.3.3. 応答を梢消してください… 45 7.3.4. 応答をとって来てください… 46 7.3.5. 応答を時代遅れにしてください… 51 7.4. サーバ応答--継続要求を命令してください… 51 8. IMAP4セッションを抽出してください… 52 9. 正式な構文… 53 10. 作者の注意… 64 11. セキュリティ問題… 64 12. 作者のアドレス… 64個の付録… 65 A. コマンドを時代遅れにしてください… 65A.6.3.OBS.1。 ALL.MAILBOXESにコマンドを見つけてください… 65A.6.3.OBS.2。 メールボックスコマンドを見つけてください… 65A.6.3.OBS.3。 メールボックスコマンドを申し込んでください… 66A.6.3.OBS.4。 メールボックスコマンドを外してください… 66
Crispin [Page iii] RFC 1730 IMAP4 December 1994
クリスピン[ページiii]RFC1730IMAP4 December 1994
B. Obsolete Responses ........................................ 68 B.7.2.OBS.1. MAILBOX Response .................................. 68 B.7.3.OBS.1. COPY Response ..................................... 68 B.7.3.OBS.2. STORE Response .................................... 69 C. References ................................................ 70 E. IMAP4 Keyword Index ....................................... 71
B。 応答を時代遅れにしてください… 68B.7.2.OBS.1。 メールボックス応答… 68B.7.3.OBS.1。 応答をコピーしてください… 68B.7.3.OBS.2。 応答を保存してください… 69 C.参照… 70 E.IMAP4キーワード索引… 71
Crispin [Page iv] RFC 1730 IMAP4 December 1994
クリスピン[ページiv]RFC1730IMAP4 December 1994
IMAP4 Protocol Specification
IMAP4プロトコル仕様
1. Organization of this Document
1. このDocumentの組織
1.1. How to Read This Document
1.1. このドキュメントを読む方法
This document is written from the point of view of the implementor of an IMAP4 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 IMAP4 operates.
このドキュメントはIMAP4クライアントかサーバの作成者の観点から書かれます。セクション2のプロトコル概要を超えて、それは、だれかのためにプロトコルの操作を理解しようとしながら、最適化されません。 セクション3〜5の材料はIMAP4が作動する一般情勢と定義を提供します。
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, one should not attempt to deduce command syntax from the command section alone; one should instead refer to the formal syntax section.
セクション6、7、および9 それぞれIMAPコマンド、応答、および構文について説明してください。 これらの中の関係がそのようなものであるので、別々にそれらのどれかを理解しているのはほとんど不可能です。 特に、指揮班からコマンド構文を単独で推論するのを試みるべきではありません。 代わりに正式な構文部について言及するべきです。
1.2. Conventions Used in this Document
1.2. このDocumentのコンベンションUsed
In examples, "C:" and "S:" indicate lines sent by the client and server respectively.
例で「C:」 そして、「S:」 クライアントとサーバによってそれぞれ送られた系列を示してください。
2. Protocol Overview
2. プロトコル概要
2.1. Link Level
2.1. リンク・レベル
The IMAP4 protocol assumes a reliable data stream such as provided by TCP. When TCP is used, an IMAP4 server listens on port 143.
TCPによって提供されるようにIMAP4プロトコルは確実な資料ストリームを仮定します。 TCPが使用されているとき、IMAP4サーバはポート143の上で聴かれます。
2.2. Commands and Responses
2.2. コマンドと応答
An IMAP4 session consists of the establishment of a client/server 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.
IMAP4セッションはクライアント/サーバ接続、サーバからの初期の挨拶、およびクライアント/サーバ相互作用の設立から成ります。 これらのクライアント/サーバ相互作用はaクライアントコマンド、サーバデータ、およびサーバ完成結果応答から成ります。
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 IMAP4 client or server is either reading a line, or is reading a sequence of octets with a known count followed by a line.
クライアントとサーバによって伝えられたすべての相互作用が系列の形にあります。 すなわち、CRLFと共に終わるストリング。 IMAP4クライアントかサーバのプロトコル受信機は、系列を読んでいるか、または系列が知られているカウントのあとに続いていて、八重奏の系列を読んでいます。
Crispin [Page 1] RFC 1730 IMAP4 December 1994
クリスピン[1ページ]RFC1730IMAP4 December 1994
2.2.1. Client Protocol Sender and Server Protocol Receiver
2.2.1. クライアントプロトコル送付者とサーバプロトコル受信機
The client command begins an operation. Each client command is prefixed with a 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など)が「タグ」と呼ばれている状態で、それぞれのクライアントコマンドは前に置かれています。 異なったタグは各コマンドのためにクライアントによって生成されます。
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つの場合があります。 ある場合では、コマンド議論は八重奏カウントで引用されます(Data Formatsの下でStringのリテラルの記述を見てください)。 もう片方の場合では、コマンド議論はサーバフィードバックを必要とします(AUTHENTICATEコマンドを見てください)。 どちらの場合ではも、それが八重奏(適切であるなら)とコマンドの残りの準備ができているなら、サーバはコマンド継続要求応答を送ります。 この応答はトークン「+」で前に置かれています。
Note: If, instead, the server detected an error in the
command, it sends a BAD completion response with 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.
また、サーバがある他のコマンド(複数のコマンドが進行しているなら)、または非タグ付けをされたデータのための完成応答を送るのも、可能です。 どちらかの場合では、コマンド継続要求はまだ未定です。 クライアントは、応答に適切な行動を取って、サーバから別の応答を読み込みます。
The protocol receiver of an IMAP4 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.
IMAP4サーバのプロトコル受信機は、クライアントからコマンドラインを読んで、コマンドとその議論を分析して、サーバデータとサーバコマンド完成結果応答を送ります。
2.2.2. Server Protocol Sender and Client Protocol Receiver
2.2.2. サーバプロトコル送付者とクライアントプロトコル受信機
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
サーバ完成結果応答は操作の成否を示します。 それは操業を開始したクライアントコマンドと同じタグでタグ付けをされます。 このようにして、1つより多く
Crispin [Page 2] RFC 1730 IMAP4 December 1994
クリスピン[2ページ]RFC1730IMAP4 December 1994
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 protocol error such as unrecognized command or command syntax error).
コマンドが進行している、サーバ完成応答におけるタグは応答が適用されるコマンドを特定します。 3つの可能なサーバ完成応答があります: (成功を示します)、(失敗を示します)、またはBAD(認識されていないコマンドかコマンド構文エラーなどのプロトコル誤りを示す)を承認してください。
The protocol receiver of an IMAP4 client reads a response line from the server. It then takes action on the response based upon the first token of the response, which may be a tag, a "*", or a "+". As described above.
IMAP4クライアントのプロトコル受信機はサーバから応答系列を読みます。次に、それは最初のトークンに基づく応答を実行します。 上で説明されるように。
A client MUST be prepared to accept any server response at all times. This includes server data that it may not have 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, recording the data is mandatory.
クライアントはいつもあらゆるサーバ応答を受け入れる用意ができていなければなりません。 これはそれが要求していないかもしれないサーバデータを含んでいます。 サーバデータSHOULDが記録されて、クライアントがaを送るよりむしろ記録されたコピーに参照をつけることができるように、データを要求するとサーバに命令してください。 あるサーバデータの場合では、データを記録するのは義務的です。
This topic is discussed in greater detail in the Server Responses section.
Server Responses部で詳細によりすばらしいこの話題について議論します。
Crispin [Page 3] RFC 1730 IMAP4 December 1994
クリスピン[3ページ]RFC1730IMAP4 December 1994
3. State and Flow Diagram
3. 状態とフローチャート
An IMAP4 server is in one of four states. Most commands are valid in only certain states. It is a protocol error for the client to attempt a command while the command is in an inappropriate state. In this case, a server will respond with a BAD or NO (depending upon server implementation) command completion result.
IMAP4サーバが4つの州の1つにあります。 ほとんどのコマンドが、ある州だけで有効です。 それはコマンドが不適当な状態にある間にクライアントがコマンドを試みるプロトコル誤りです。 この場合、サーバはBADかいいえ(サーバ実装による)、コマンド完成結果で反応するでしょう。
3.1. Non-Authenticated State
3.1. 非認証された状態
In non-authenticated state, the user 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.
非認証された状態では、ほとんどのコマンドが受入れられる前にユーザは認証資格証明書を供給しなければなりません。 接続があらかじめ認証されていない場合接続が始まるとき、この状態は入られます。
3.2. Authenticated State
3.2. 認証された状態
In authenticated state, the user 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, or after an error in selecting a mailbox.
認証された状態では、ユーザは、認証されて、メッセージに影響するコマンドが受入れられる前にアクセスへのメールボックスを選択しなければなりません。 この状態は許容できる認証資格証明書を提供したとき、あらかじめ認証された接続が始まるときに時かメールボックスを選択することにおける誤りの後に入られます。
3.3. Selected State
3.3. 選択された状態
In selected state, a mailbox has been selected to access. This state is entered when a mailbox has been successfully selected.
選択された状態では、メールボックスはアクセサリーに選択されました。 メールボックスが首尾よく選択されたとき、この状態は入られます。
3.4. Logout State
3.4. ログアウト、状態
In logout state, the session is being terminated, and the server will close the connection. This state can be entered as a result of a client request or by unilateral server decision.
州は中にログアウトします、そして、セッションは終えられています、そして、サーバは接続を終えるでしょう。 クライアント要求の結果、一方的なサーバ決定でこの状態に入ることができます。
Crispin [Page 4] RFC 1730 IMAP4 December 1994
クリスピン[4ページ]RFC1730IMAP4 December 1994
+--------------------------------------+
|initial connection and server greeting|
+--------------------------------------+
|| (1) || (2) || (3)
VV || ||
+-----------------+ || ||
|non-authenticated| || ||
+-----------------+ || ||
|| (7) || (4) || ||
|| VV VV ||
|| +----------------+ ||
|| | authenticated |<=++ ||
|| +----------------+ || ||
|| || (7) || (5) || (6) ||
|| || VV || ||
|| || +--------+ || ||
|| || |selected|==++ ||
|| || +--------+ ||
|| || || (7) ||
VV VV VV VV
+--------------------------------------+
| logout and close connection |
+--------------------------------------+
+--------------------------------------+ |初期の接続とサーバ挨拶| +--------------------------------------+ || (1) || (2) || (3) VV|| || +-----------------+ || || |非認証されています。| || || +-----------------+ || || || (7) || (4) || || || VV VV|| || +----------------+ || || | 認証されます。|<=++ || || +----------------+ || || || || (7) || (5) || (6) || || || VV|| || || || +--------+ || || || || |選択されます。|==++ || || || +--------+ || || || || (7) || VV VV VV VV+--------------------------------------+ | ログアウトしてください、そして、接続を終えてください。| +--------------------------------------+
(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コマンド、サーバ閉鎖、または接続が閉じました。
Crispin [Page 5] RFC 1730 IMAP4 December 1994
クリスピン[5ページ]RFC1730IMAP4 December 1994
4. Data Formats
4. データ形式
IMAP4 uses textual commands and responses. Data in IMAP4 can be in one of several forms: atom, number, string, parenthesized list, or NIL.
IMAP4は原文のコマンドと応答を使用します。 IMAP4のデータがいくつかのフォームの1つにあることができます: 原子(数、ストリング)はリスト、またはNILをparenthesizedしました。
4.1. Atom
4.1. 原子
An atom consists of one or more non-special characters.
原子は1つ以上の非特殊文字から成ります。
4.2. Number
4.2. 数
A number consists of one or more digit characters, and represents a numeric value.
数は、1つ以上のケタキャラクタから成って、数値を表します。
4.3. String
4.3. ストリング
A string is in one of two forms: literal and 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 restrictions of what may be in a quoted string.
五弦が2つのフォームの1つにあります: リテラルと引用文字列。 文字通りのフォームは一般的な形式のストリングです。 引用文字列フォームは引用文字列にあるかもしれないものに関する制限の費用でリテラルを処理するオーバーヘッドを避ける代替手段です。
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).
リテラルはゼロの系列であるか、より多くの八重奏が(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.
引用文字列は、ゼロの系列か7ビット以上のキャラクタです、CRとLFを除いて、二重引用文で。(「>) それぞれのキャラクタは終わらせる」<。
The empty string is respresented 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).
空のストリングがrespresentedされる、「「(二重引用符の間には、キャラクタが全くない引用文字列) または、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であっても、リテラルを伝えるクライアントは、コマンド継続要求を受け取るのを待たなければなりません。
Crispin [Page 6] RFC 1730 IMAP4 December 1994
クリスピン[6ページ]RFC1730IMAP4 December 1994
4.3.1. 8-bit and Binary Strings
4.3.1. 8ビットの、そして、2進のストリング
8-bit textual and binary mail is supported through the use of [MIME-1] encoding. IMAP4 implementations MAY transmit 8-bit or multi-octet characters in literals, but should do so only when the character set is identified.
そして、8ビット原文、バイナリメールは[MIME-1]コード化の使用でサポートされます。 IMAP4実装は、リテラルで8ビットの、または、マルチ八重奏のキャラクタを伝えるかもしれませんが、文字集合が特定されるときだけ、そうするべきです。
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, although this is not required.
BINARYボディーコード化は定義されますが、暗号化されていない2進のストリングは受入れられません。 「2進のストリング」はNULキャラクタを伴うあらゆるストリングです。 実装はデータを送る前のBASE64などの原文のフォームにバイナリ・データをコード化しなければなりません。 また、過量のCTLキャラクタを伴う五弦が2進であると考えられるかもしれません、これは必要ではありませんが。
4.4. Parenthesized List
4.4. リストをParenthesizedしました。
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 may itself contain other parenthesized lists, using multiple levels of parentheses to indicate nesting.
データ構造は「parenthesizedリスト」として表されます。 スペースで区切られて、各端のときに括弧のそばで境界があるデータ項目の系列。 parenthesizedリストがそうするかもしれない、それ自体、巣篭もりを示すのに複数のレベルの括弧を使用して、他のparenthesizedリストを含んでください。
The empty list is represented as () -- a parenthesized list with no members.
空のリストは()として表されます--メンバーのいないparenthesizedリスト。
4.5. NIL
4.5. 無
The special atom "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 ().
特別な原子「無」はストリングとして表されるか、またはparenthesizedされる特定のデータ項目の非存在リストを表します、空のストリングと異なるとして「「または、空はリスト()をparenthesizedしました」。
Crispin [Page 7] RFC 1730 IMAP4 December 1994
クリスピン[7ページ]RFC1730IMAP4 December 1994
5. Operational Considerations
5. 操作上の問題
5.1. Mailbox Naming
5.1. メールボックス命名
The interpretation of mailbox names is implementation-dependent. However, the mailbox name INBOX is a special name reserved to mean "the primary mailbox for this user on this server". 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.
メールボックス名の解釈は実装依存しています。 しかしながら、受信トレイというメールボックス名は「このサーバのこのユーザのためのプライマリメールボックス」を意味するために予約された特別な名前です。 階層的なメールボックス名をエクスポートするのが必要であるなら、メールボックス名は階層構造のレベルを切り離すのに単独のキャラクタを使用するのにおいて左から右に階層的であるに違いありません。 同じ階層構造分離符キャラクタはすべてのレベルの階層構造にただ一つの名前の中で使用されます。
5.2. Mailbox Size and Message Status Updates
5.2. メールボックスサイズとメッセージ状態最新版
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 mail delivery), change the flags of message 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 details.
いつでも、サーバはクライアントが要求しなかったデータを送ることができます。 時々、そのような振舞いが必要です。 例えば、サーバ以外のエージェントは、メールボックス(例えば、新しい郵便配達)にメッセージを加えるか、メールボックス(例えば、複数のエージェントによる同じメールボックスへの同時アクセス)の中にメッセージの旗を変えるか、またはメールボックスからメッセージを取り除きさえするかもしれません。 メールボックスサイズ変化がコマンドの処理の間、観測されるなら、サーバは自動的にメールボックスサイズアップデートを送らなければなりません。 クライアントが明らかにそのようなアップデートを要求する必要でないSHOULDが自動的にメッセージ旗の最新版を送るサーバ。 特別な規則はクライアントのサーバ通知のために同期誤りを防ぐメッセージの取り外しに関して存在しています。 その他の詳細のためのEXPUNGE応答の記述を見てください。
Regardless of what implementation decisions a client may take on remembering data from the server, a client implementation MUST record mailbox size updates. It MUST NOT assume that any command after initial mailbox selection will return the size of the mailbox.
サーバからデータを覚えているクライアントが帯びるかもしれないすべての実装決定にかかわらず、クライアント実装はメールボックスサイズアップデートを記録しなければなりません。 それは、初期のメールボックス選択の後のどんなコマンドもメールボックスのサイズを返すと仮定してはいけません。
5.3. Response when no Command in Progress
5.3. ProgressでCommandでないことの応答
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)使用を超えていないことを確かめます。
Crispin [Page 8] RFC 1730 IMAP4 December 1994
クリスピン[8ページ]RFC1730IMAP4 December 1994
5.4. Autologout Timer
5.4. 自動ログアウト・タイマー
If a server has an inactivity autologout timer, that timer MUST be of at least 30 minutes' duration. The receipt of ANY command from the client during that interval should suffice to reset the autologout timer.
サーバに不活発自動ログアウト・タイマーがあるなら、そのタイマは少なくとも30分の持続時間のものであるに違いありません。 その間隔の間のクライアントからのどんなコマンドの領収書も、自動ログアウト・タイマーをリセットするために十分であるはずです。
5.5. Multiple Commands in Progress
5.5. 進行中の複数のコマンド
The client is not required to wait for the completion result response of a command before sending another command, subject to flow control constraints on the underlying data stream. Similarly, a server is not required to process a command to completion before beginning processing of the next command, unless an ambiguity would result because of a command that would affect the results of other commands. If there is such an ambiguity, the server executes commands to completion in the order given by the client.
基本的なデータ・ストリームのフロー制御規制を条件として別のコマンドを送る前に、クライアントはコマンドの完成結果応答を待つ必要はありません。 同様に、サーバは次のコマンドの始めの処理の前に完成にコマンドを処理するのに必要ではありません、あいまいさが他のコマンドの結果に影響するコマンドで結果として生じないなら。 そのようなあいまいさがあれば、サーバはクライアントによって与えられたオーダーにおける完成にコマンドを実行します。
Crispin [Page 9] RFC 1730 IMAP4 December 1994
クリスピン[9ページ]RFC1730IMAP4 December 1994
6. Client Commands
6. クライアントコマンド
IMAP4 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).
IMAP4コマンドはこのセクションで説明されます。 コマンドはコマンドが受入れられる州によって組織化されます。 複数の州で受入れられるコマンドは状態に受入れられた最小限で記載されています(例えば、認証されて選択された状態で有効なコマンドは認証された州のコマンドで記載されています)。
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.
特定された議論を命令してください、「議論:」 中、記述下を命令して、構文によって説明されるのではなく、機能によって説明されます。 コマンド議論の正確な構文はFormal Syntax部で説明されます。
Some commands cause specific server data to be returned; these are identified by "Data:" 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 data for this command" instead of "none".
いくつかのコマンドで、特定のサーバデータを返します。 これらが特定される、「データ:」 以下でのコマンド記述で。 これらの応答の情報のためのResponses部、およびこれらの応答の正確な構文のためのFormal Syntax部で応答記述を見てください。 サーバデータがどんなコマンドの結果、送られるのは、可能です。 したがって、明確にサーバデータを必要としないコマンドが「なにも」の代わりに「このコマンドのための特定のデータがありません」を指定します。
The "Result:" in the command description refers to the possible tagged status responses to a command, and any special interpretation of these status responses.
「なってください」 コマンド記述では、コマンドへの可能なタグ付けをされた状態応答、およびこれらの状態応答のどんな特別な解釈も示します。
6.1. Client Commands - Any State
6.1. クライアントコマンド--どんな状態
The following commands are valid in any state: CAPABILITY, NOOP, and LOGOUT.
以下のコマンドはどんな状態でも有効です: そして、能力、NOOP、ログアウトしてください。
6.1.1. CAPABILITY Command
6.1.1. 能力コマンド
Arguments: none
議論: なし
Data: mandatory 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 "IMAP4" as the first listed capability
before the (tagged) OK response. This listing of capabilities is
not dependent upon connection state or user. It is therefore not
necessary to issue a CAPABILITY command more than once in a
session.
CAPABILITYコマンドはサーバがサポートする能力のリストを要求します。 サーバは「(タグ付けされる)のOK応答の前の最初の記載された能力としてのIMAP4"」とのただ一つのuntagged CAPABILITY応答を送らなければなりません。 能力のこのリストは、接続状態の扶養家族でなくて、またユーザでもありません。 したがって、セッションのときに一度より多くのコマンドをCAPABILITYに発行するのは必要ではありません。
Crispin [Page 10] RFC 1730 IMAP4 December 1994
クリスピン[10ページ]RFC1730IMAP4 December 1994
Capability names other than "IMAP4" refer to extensions,
revisions, or amendments to this specification. See the
documentation of the CAPABILITY response for additional
information. No capabilities are enabled without explicit client
action to invoke the capability. See the section entitled "Client
Commands - Experimental/Expansion" for information about the form
of site or implementation-specific capabilities.
「IMAP4"はこの仕様の拡大、改正、または改正について言及すること」を除いた能力名。 追加情報のためのCAPABILITY応答のドキュメンテーションを見てください。 能力は全く能力を呼び出す明白なクライアント動作なしで可能にされません。 セクションがサイトか実装特有のフォームの情報に関する「クライアントは命令します--実験的な/拡張」という能力の権利を与えられるのを見てください。
Example: C: abcd CAPABILITY
S: * CAPABILITY IMAP4
S: abcd OK CAPABILITY completed
例: C: abcd CAPABILITY S: * 能力IMAP4 S: OK CAPABILITYが完成したabcd
6.1.2. NOOP Command
6.1.2. NOOPコマンド
Arguments: none
議論: なし
Data: no specific data 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. 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
例: C: a002 NOOP S: a002OK NOOPは…Cを完成しました: a047 NOOP S: * 22 Sを梢消してください: * 23が存在している、S: * 3、最近のS: * 14は(旗(目にふれている\が削除した\))にSをとって来ます: OK NOOPが完成したa047
Crispin [Page 11] RFC 1730 IMAP4 December 1994
クリスピン[11ページ]RFC1730IMAP4 December 1994
6.1.3. LOGOUT Command
6.1.3. ログアウトコマンド
Arguments: none
議論: なし
Data: mandatory untagged response: 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 session. The server must send a BYE untagged response before
the (tagged) OK response, and then close the network connection.
LOGOUTコマンドは、クライアントがセッションを終えていることをサーバに知らせます。 サーバは、(タグ付けされる)のOK応答の前にBYE untagged応答を送って、次に、ネットワーク接続を終えなければなりません。
Example: C: A023 LOGOUT
S: * BYE IMAP4 Server logging out
S: A023 OK LOGOUT completed
(Server and client then close the connection)
例: C: A023がログアウトする、S: * SをログアウトするBYE IMAP4 Server: 完成したA023 OK LOGOUT(次に、サーバとクライアントは接続を終えます)
6.2. Client Commands - Non-Authenticated State
6.2. クライアントコマンド--非認証された状態
In non-authenticated state, the AUTHENTICATE or LOGIN command establishes authentication and enter authenticated state. The AUTHENTICATE command provides a general mechanism for a variety of authentication techniques, whereas the LOGIN command uses the traditional user name and plaintext password pair.
非認証された状態に、AUTHENTICATEかLOGINコマンドが認証を確立します、そして、認証された状態に入れてください。 AUTHENTICATEコマンドはさまざまな認証のテクニックに一般的機構を提供しますが、LOGINコマンドは伝統的なユーザ名と平文パスワード組を使用します。
Server implementations may allow non-authenticated access to certain mailboxes. The convention is to use a LOGIN command with the userid "anonymous". A password is required. It is implementation-dependent what requirements, if any, are placed on the password and what access restrictions are placed on anonymous users.
サーバ実装はあるメールボックスへの非認証されたアクセスを許すかもしれません。 ユーザIDが「匿名」でコンベンションはLOGINコマンドを使用することになっています。 パスワードが必要です。 もしあればどんな要件がパスワードに置かれるか、そして、どんなアクセス制限が匿名のユーザに関して課されるかは、実装依存しています。
Once authenticated (including as anonymous), it is not possible to re-enter non-authenticated state.
いったん認証されると(匿名として、含んでいます)、非認証された状態に再入するのは可能ではありません。
In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT), the following commands are valid in non-authenticated state: AUTHENTICATE and LOGIN.
普遍的なコマンド(CAPABILITY、NOOP、およびLOGOUT)に加えて、以下のコマンドは非認証された状態で有効です: 認証、そして、ログイン。
Crispin [Page 12] RFC 1730 IMAP4 December 1994
クリスピン[12ページ]RFC1730IMAP4 December 1994
6.2.1. AUTHENTICATE Command
6.2.1. 認証コマンド
Arguments: authentication mechanism name
議論: 認証機構名
Data: continuation data may 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--完成して、現在中で認証された州のノーを認証してください--失敗を認証してください: サポートされない認証機構、資格証明書はBADを拒絶しました--コマンド未知か議論病人、認証交換が中止されました。
The AUTHENTICATE command indicates an authentication mechanism,
such as described in [IMAP-AUTH], to the server. If the server
supports the requested authentication mechanism, it performs an
authentication protocol exchange to authenticate and identify the
user. Optionally, it also negotiates a protection mechanism 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コマンドは認証機構を示します、[IMAP-AUTH]で説明されるように、サーバに。サーバが要求された認証機構をサポートするなら、それは、ユーザを認証して、特定するために認証プロトコル交換を実行します。 また、任意に、それはその後のプロトコル相互作用のために保護メカニズムを交渉します。 要求された認証機構がサポートされないなら、サーバは、タグ付けをされたいいえ応答を送ることによって、AUTHENTICATEコマンドを拒絶するべきです。
The authentication protocol exchange consists of a series of
server challenges and client answers 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 answer consists of a line
consisting of a BASE64 encoded string. If the client wishes to
cancel an authentication exchange, it should issue a line with a
single "*". If the server receives such an answer, it must reject
the AUTHENTICATE command by sending a tagged BAD response.
認証プロトコル交換は一連の認証機構に特定のサーバ挑戦とクライアント答えから成ります。 サーバ挑戦は「+」トークンがBASE64によって続かれている応答がストリングをコード化したというコマンド継続要求から成ります。 クライアント答えは、BASE64から成りながら、系列から成ります。ストリングをコード化しました。 クライアントが認証交換を中止したいなら、それは単一の「*」で系列を発行するべきです。 サーバがそのような答えを受けるなら、それは、タグ付けをされたBAD応答を送ることによって、AUTHENTICATEコマンドを拒絶しなければなりません。
A protection mechanism provides integrity and privacy protection
to the protocol session. If a protection mechanism is negotiated,
it is applied to all subsequent data sent over the connection.
The protection mechanism 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. Once the
protection mechanism is in effect, the stream of command and
response octets is processed into buffers of ciphertext. Each
buffer is transferred over the connection as a stream of octets
prepended with a four octet field in network byte order that
represents the length of the following data. The maximum
ciphertext buffer length is defined by the protection mechanism.
保護メカニズムはプロトコルセッションまで保全とプライバシー保護を提供します。 保護メカニズムが交渉されるなら、それは接続の上に送られたすべての順次データに適用されます。 すぐにクライアントへの認証交換、およびサーバのためのタグ付けをされたOK応答のCRLFを結論づけるCRLFに続いて、保護メカニズムは実施します。保護メカニズムがいったん有効になると、コマンドと応答八重奏のストリームは暗号文に関するバッファの中に処理されます。 八重奏のストリームが以下のデータの長さを表すネットワークバイトオーダーにおける4八重奏分野でprependedされたとき、各バッファを接続の上に移します。 最大の暗号文バッファ長は保護メカニズムによって定義されます。
The server is not required to support any particular
authentication mechanism, nor are authentication mechanisms
required to support any protection mechanisms. If an AUTHENTICATE
command fails with a NO response, the client may try another
サーバはどんな特定の認証機構もサポートするのに必要ではありません、そして、認証機構はどんな保護メカニズムもサポートする必要はありません。いいえ応答に応じてAUTHENTICATEコマンドが失敗するなら、クライアントは別のものを試みるかもしれません。
Crispin [Page 13] RFC 1730 IMAP4 December 1994
クリスピン[13ページ]RFC1730IMAP4 December 1994
authentication mechanism by issuing another AUTHENTICATE command,
or may attempt to authenticate by using the LOGIN command. In
other words, the client may request authentication types in
decreasing order of preference, with the LOGIN command as a last
resort.
AUTHENTICATEが命令するか、またはLOGINコマンドを使用することによって認証するのを試みるかもしれない別のものを発行するのによる認証機構。 言い換えれば、クライアントは、認証が最後の手段としてLOGINコマンドがある減少しているよく使われる順をタイプするよう要求するかもしれません。
Example: S: * OK KerberosV4 IMAP4 Server
C: A001 AUTHENTICATE KERBEROS_V4
S: + AmFYig==
C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
+nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd
WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
S: + or//EoAADZI=
C: DiAF5A4gA+oOIALuBkAAmw==
S: A001 OK Kerberos V4 authentication successful
例: S: * KerberosV4 IMAP4サーバCを承認してください: A001はケルベロス_V4 Sを認証します: + AmFYig=C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh S: +か//EoAADZIがCと等しいです: DiAF5A4gA+oOIALuBkAAmw== S: A001 OKケルベロスV4認証うまくいきます。
Note: the line breaks in the first client answer are for
editorial clarity and are not in real authenticators.
以下に注意してください。 最初のクライアント答えにおけるラインブレイクは、編集の明快ためにあって、本当の固有識別文字にはありません。
6.2.2. LOGIN Command
6.2.2. ログインコマンド
Arguments: user name
password
議論: ユーザ名前パスワード
Data: no specific data 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
結果: OK--さあ、認証された状態でいいえ--ログイン失敗ログインが終了して、: ユーザ名かパスワードがBADを拒絶しました--未知か議論病人を命令してください。
The LOGIN command identifies the user to the server and carries
the plaintext password authenticating this user.
LOGINコマンドは、サーバにユーザを特定して、このユーザを認証しながら、平文パスワードを運びます。
Example: C: a001 LOGIN SMITH SESAME
S: a001 OK LOGIN completed
例: C: a001 LOGIN SMITH SESAME S: OK LOGINが完成したa001
6.3. Client Commands - Authenticated State
6.3. クライアントコマンド--認証された状態
In 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 selected state.
認証された状態では、原子実体としてメールボックスを操作するコマンドが受入れられます。 これらのコマンドでは、SELECTとEXAMINEコマンドは、アクセスのためにメールボックスを選択して、選択された状態に入れるでしょう。
Crispin [Page 14] RFC 1730 IMAP4 December 1994
クリスピン[14ページ]RFC1730IMAP4 December 1994
In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT), the following commands are valid in authenticated state: SELECT, EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, and APPEND.
普遍的なコマンド(CAPABILITY、NOOP、およびLOGOUT)に加えて、以下のコマンドは認証された状態で有効です: そして、選ぶ、審査、作成、削除、改名、登録、登録削除、リスト、LSUB、追加します。
6.3.1. SELECT Command
6.3.1. 選択コマンド
Arguments: mailbox name
議論: メールボックス名
Data: mandatory untagged responses: FLAGS, EXISTS, RECENT
optional OK untagged responses: UNSEEN, PERMANENTFLAGS
データ: 義務的な非タグ付けをされた応答: FLAGS、EXISTS、RECENTの任意のOKは応答に非タグ付けをしました: 見えなさ、PERMANENTFLAGS
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--完成して、現在中で選択された州のノーを選択してください--現在、認証された状態で失敗を選択してください: どんなそのようなメールボックス、もメールボックス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:
SELECTコマンドは、メールボックスの中のメッセージにアクセスできるようにメールボックスを選択します。 OKをクライアントに返す前に、サーバは以下の非タグ付けをされたデータをクライアントに送らなければなりません:
FLAGS Defined flags in the mailbox
メールボックスの中のFLAGS Defined旗
<n> EXISTS The number of messages in the mailbox
<n>EXISTSはメールボックスの中のメッセージの数です。
<n> RECENT The number of messages added to the mailbox since
the previous time this mailbox was read
このメールボックスが前の時に読まれて以来メッセージの数がメールボックスに加えた<n>RECENT
OK [UIDVALIDITY <n>]
The unique identifier validity value. See the
description of the UID command for more detail.
[UIDVALIDITY<n>]ユニークな識別子正当性価値を承認してください。 その他の詳細のためのUIDコマンドの記述を見てください。
to define the initial state of the mailbox at the client. If it
is not possible to determine the messages that were added since
the previous time a mailbox was read, then all messages SHOULD be
considered recent.
クライアントでメールボックスの初期状態を定義するために。 以来加えられたメッセージを決定するのが可能でないなら、メールボックスが読まれて、次に、すべてのメッセージがSHOULDである前回に最近であると考えられてください。
The server SHOULD also send an UNSEEN response code in an OK
untagged response, indicating the message sequence number of the
first unseen message in the mailbox.
また、サーバSHOULDはOKの非タグ付けをされた応答におけるUNSEEN応答コードを送ります、メールボックスにおける最初の見えないメッセージのメッセージ通番を示して。
If the client can not change the permanent state of one or more of
the flags listed in the FLAGS untagged response, the server SHOULD
send a PERMANENTFLAGS response code in an OK untagged response,
listing the flags that the client may change permanently.
クライアントがFLAGS untagged応答で記載された旗の1つ以上の永久的な状態を変えることができないなら、サーバSHOULDはOKの非タグ付けをされた応答におけるPERMANENTFLAGS応答コードを送ります、クライアントが永久に変えるかもしれない旗を記載して。
Only one mailbox may be selected at a time in a session;
simultaneous access to multiple mailboxes requires multiple
セッションのときに一度に、1個のメールボックスだけを選択してもよいです。 複数のメールボックスへの同時アクセスは倍数を必要とします。
Crispin [Page 15] RFC 1730 IMAP4 December 1994
クリスピン[15ページ]RFC1730IMAP4 December 1994
sessions. 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.
セッション。 SELECTは自動的にいずれも現在新しい選択を試みながらメールボックスを選択したdeselectsを命令します。 その結果、メールボックスが選択されて、失敗するSELECTコマンドが試みられるなら、メールボックスは全く選択されません。
If the user is permitted to modify the mailbox, the server SHOULD
prefix the text of the tagged OK response with the "[READ-WRITE]"
response code.
ユーザがメールボックスを変更することが許可されるなら、サーバSHOULDは「[-読まれて、書いてください]」応答コードでタグ付けをされたOK応答のテキストを前に置きます。
If the user 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 user's .newsrc file are an example of such per-user permanent
state that can be modified with read-only mailboxes.
ユーザがメールボックスを変更することは許可されていませんが、アクセスが読まれて、受入れられるなら、メールボックスは書き込み禁止として選定されます、そして、サーバは「[書き込み禁止]」応答コードでSELECTへのタグ付けをされたOK応答のテキストを前に置かなければなりません。 SELECTを通したリード・オンリー・アクセスはある書き込み禁止メールボックスがユーザ(グローバルと対照的に)あたり1個のベースの永久的な状態の変化を可能にするかもしれないという点においてEXAMINEコマンドと異なっています。 ユーザの.newsrcファイルでマークされたネットニュースメッセージは書き込み禁止メールボックスで変更できるそのような1ユーザあたりの永久的な状態に関する例です。
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: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
S: A142 OK [READ-WRITE] SELECT completed
例: C: A142は受信トレイSを選択します: * 172が存在している、S: * 1、最近のS: * OK[UNSEEN12]メッセージ12は最初に、見えないSです: * OK[UIDVALIDITY3857529045]のUIDs有効なS: * 旗(\に答えた\は\削除された\見られた\草稿に旗を揚げさせた)のS: * OK[PERMANENTFLAGS(\は\見られた\*を削除した)]はSを制限しました: 完成したA142 OK[READ-WRITE]SELECT
6.3.2. EXAMINE Command
6.3.2. 審査コマンド
Arguments: mailbox name
議論: メールボックス名
Data: mandatory untagged responses: FLAGS, EXISTS, RECENT
optional OK untagged responses: UNSEEN, PERMANENTFLAGS
データ: 義務的な非タグ付けをされた応答: FLAGS、EXISTS、RECENTの任意のOKは応答に非タグ付けをしました: 見えなさ、PERMANENTFLAGS
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--完成して、現在中で選択された州のノーを調べてください--現在、認証された状態で失敗を調べてください: どんなそのようなメールボックス、もメールボックス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.
EXAMINEコマンドは、SELECTと同じであり、同じ出力を返します。 しかしながら、選択されたメールボックスは書き込み禁止として特定されます。 1ユーザあたりの状態を含むメールボックスの永久的な状態への変化は全く受入れられません。
Crispin [Page 16] RFC 1730 IMAP4 December 1994
クリスピン[16ページ]RFC1730IMAP4 December 1994
The text of the tagged OK response to the EXAMINE command MUST
begin with the "[READ-ONLY]" response code.
EXAMINEコマンドへのタグ付けをされたOK応答のテキストは「[書き込み禁止]」応答コードで始まらなければなりません。
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: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * OK [PERMANENTFLAGS ()] No permanent flags permitted
S: A932 OK [READ-ONLY] EXAMINE completed
例: C: A932 EXAMINE blurdybloop S: * 17が存在している、S: * 2、最近のS: * OK[UNSEEN8]メッセージ8は最初に、見えないSです: * OK[UIDVALIDITY3857529045]のUIDs有効なS: * 旗(\に答えた\は\削除された\見られた\草稿に旗を揚げさせた)のS: * OKである、[PERMANENTFLAGS()]いいえの永久的な旗はSを可能にしました: 完成したA932 OK[READだけ]EXAMINE
6.3.3. CREATE Command
6.3.3. 作成コマンド
Arguments: mailbox name
議論: メールボックス名
Data: no specific data for this command
データ: このコマンドのための特定のデータがありません。
Result: OK - create completed
NO - create failure: can't create mailbox with that name
BAD - command unknown or arguments invalid
結果: OK--完成したノーを作成してください--失敗を作成してください: その名前BADと共にメールボックスを作成できません--未知か議論病人を命令してください。
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応答を返します。 実在のメールボックスについて言及するのは、名前で受信トレイかメールボックスを作成するのを試みる誤りです。 作成におけるどんな誤りもタグ付けをされたいいえ応答を返すでしょう。
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 may, in the
future, create mailbox names under this name in the hierarchy.
Server implementations that do not require this declaration MUST
ignore it.
メールボックス名がサーバの階層構造分離符キャラクタと共にsuffixedされるなら(サーバからLISTコマンドで返すように)、これはクライアントが将来この名前の下でメールボックス名を階層構造で作成するかもしれないという宣言です。 この宣言を必要としないサーバ実装はそれを無視しなければなりません。
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.
削除されたメールボックス、ユニークな識別子がどんなユニークな識別子もメールボックスUNLESSの前の肉体化に新しい肉体化を使用したよりすばらしいに違いないので、新しいメールボックスが同じくらいで作成されるなら、名前には、異なったユニークな識別子正当性価値があります。 その他の詳細のためのUIDコマンドの記述を見てください。
Example: C: A003 CREATE owatagusiam/
S: A003 OK CREATE completed
C: A004 CREATE owatagusiam/blurdybloop
S: A004 OK CREATE completed
例: C: A003 CREATE owatagusiam/S: A003 OK CREATEはCを完成しました: A004 CREATE owatagusiam/blurdybloop S: 完成したA004 OK CREATE
Crispin [Page 17] RFC 1730 IMAP4 December 1994
クリスピン[17ページ]RFC1730IMAP4 December 1994
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.
以下に注意してください。 メンバーが"blurdybloop"と呼ばれている状態で、階層構造分離符、新しいレベルの階層構造は"owatagusiam"と命名されます。「この例の解釈がよる、」 /、」 階層構造分離符としてリストから返した、」 /である、」、作成されます。 さもなければ、同じ階層構造レベルにおける2個のメールボックスが作成されます。
6.3.4. DELETE Command
6.3.4. 削除コマンド
Arguments: mailbox name
議論: メールボックス名
Data: no specific data for this command
データ: このコマンドのための特定のデータがありません。
Result: OK - delete completed
NO - delete failure: can't delete mailbox with that name
BAD - command unknown or arguments invalid
結果: OK--完成したノーを削除してください--失敗を削除してください: その名前BADと共にメールボックスを削除できません--未知か議論病人を命令してください。
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. Any error in deletion will
return a tagged NO response.
DELETEコマンドは永久に、名がいるメールボックスを取り外します。 メールボックスを削除した場合にだけ、タグ付けをされたOK応答を返します。 存在しないのは、受信トレイかメールボックス名を削除するのを試みる誤りです。 削除におけるどんな誤りもタグ付けをされたいいえ応答を返すでしょう。
The value of the highest-used unique indentifier 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.
新しい肉体化のUNLESSには、削除されたメールボックスの最も高く使用されたユニークなindentifierの価値は同じ名前で作成された新しいメールボックスが前の肉体化に関する識別子を再利用しないように、守られなければならなくて、異なったユニークな識別子正当性価値があります。 その他の詳細のためのUIDコマンドの記述を見てください。
Example: C: A683 DELETE blurdybloop
S: A683 OK DELETE completed
例: C: A683 DELETE blurdybloop S: 完成したA683 OK DELETE
6.3.5. RENAME Command
6.3.5. 改名コマンド
Arguments: existing mailbox name
new mailbox name
議論: 既存のメールボックス名前新しいメールボックス名
Data: no specific data 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--完成したノーを改名してください--失敗を改名してください: その名前でメールボックスを改名できないで、その名前でBADをメールボックスに改名できません--未知か議論病人を命令してください。
Crispin [Page 18] RFC 1730 IMAP4 December 1994
クリスピン[18ページ]RFC1730IMAP4 December 1994
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応答を返します。 それは存在しないメールボックス名から改名する試み、または、既に存在するメールボックス名への誤りです。 改名におけるどんな誤りもタグ付けをされたいいえ応答を返すでしょう。
Renaming INBOX is permitted; a new, empty INBOX is created in its
place.
受信トレイを改名するのは受入れられます。 新しくて、人影のない受信トレイは場所で作成されます。
Example: C: Z4S9 RENAME blurdybloop owatagusiam
S: Z4S9 OK RENAME completed
例: C: Z4S9 RENAME blurdybloop owatagusiam S: 完成したZ4S9 OK RENAME
6.3.6. SUBSCRIBE Command
6.3.6. 申し込みコマンド
Arguments: mailbox
議論: メールボックス
Data: no specific data for this command
データ: このコマンドのための特定のデータがありません。
Result: OK - subscribe completed
NO - subscribe failure: can't subscribe to that name
BAD - command unknown or arguments invalid
結果: OK--完成したノーを申し込んでください--失敗を申し込んでください: その名前BADに加入できません--未知か議論病人を命令してください。
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.
登録、コマンドはLSUBコマンドで返すようにサーバの「アクティブである」か「申し込まれた」メールボックスのセットに指定されたメールボックス名を追加します。 購読がうまくいく場合にだけ、このコマンドはタグ付けをされたOK応答を返します。
Example: C: A002 SUBSCRIBE #news.comp.mail.mime
S: A002 OK SUBSCRIBE completed
例: C: A002は#news.comp.mail.mime Sを申し込みます: 完成したA002 OK SUBSCRIBE
6.3.7. UNSUBSCRIBE Command
6.3.7. 外しコマンド
Arguments: mailbox name
議論: メールボックス名
Data: no specific data for this command
データ: このコマンドのための特定のデータがありません。
Result: OK - unsubscribe completed
NO - unsubscribe failure: can't unsubscribe that name
BAD - command unknown or arguments invalid
結果: OK--完成したノーを外してください--失敗を外してください: その名前BADを外すことができません--未知か議論病人を命令してください。
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.
登録削除、コマンドはLSUBコマンドで返すようにサーバの「アクティブである」か「申し込まれた」メールボックスのセットから指定されたメールボックス名を取り除きます。 非購読がうまくいく場合にだけ、このコマンドはタグ付けをされたOK応答を返します。
Crispin [Page 19] RFC 1730 IMAP4 December 1994
クリスピン[19ページ]RFC1730IMAP4 December 1994
Example: C: A002 UNSUBSCRIBE #news.comp.mail.mime
S: A002 OK UNSUBSCRIBE completed
例: C: A002は#news.comp.mail.mime Sを外します: 完成したA002 OK UNSUBSCRIBE
6.3.8. LIST Command
6.3.8. リストコマンド
Arguments: reference name
mailbox name with possible wildcards
議論: 可能なワイルドカードの参照名前メールボックス名
Data: untagged responses: LIST
データ: 非タグ付けをされた応答: リスト
Result: OK - list completed
NO - list failure: can't list that reference or name
BAD - command unknown or arguments invalid
結果: OK--完成したノーを記載してください--失敗を記載してください: その参照か名前BADをリストアップできません--未知か議論病人を命令してください。
The LIST command returns a subset of names from the complete set
of all names available to the user. 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コマンドはユーザにとって、利用可能なすべての名前の完全なセットから名前の部分集合を返します。 名前属性、階層構造デリミタ、および名前を含んでいて、ゼロか以上が返されますuntagged LISTが、返答する。 その他の詳細のためのLIST回答の記述を見てください。
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 a context in which the mailbox
name is interpreted in an implementation-defined manner.
ストリング) 参照名前引数は、メールボックス名が解釈されるのを示します。空である、(「「選択する、」 返されたメールボックス名はパターンという供給されたメールボックス名に合わなければなりません。 非空の参照名前引数は、メールボックスの名前かメールボックス階層構造のレベルであり、メールボックス名が実現で定義された方法で解釈される文脈を示します。
The reference and mailbox name arguments are interpreted, in an
implementation-dependent fashion, into a canonical form that
represents an unambiguous left-to-right hierarchy. The returned
mailbox names will be in the interpreted form.
参照とメールボックス名前引数は解釈されます、実現依存するファッションで、左から右への明白な階層構造を表す標準形に。 返されたメールボックス名が解釈されたフォームにあるでしょう。
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が解釈されたフォームを前に置くという参照主張のどんな部分。 また、それは議論という参照名と同じフォームにあるべきです。 この規則は、クライアントが、返されたメールボックス名が参照議論の文脈にあったか、またはメールボックス議論に関する何かが参照議論をくつがえしたかどうかと決心していることを許可します。 この規則がなければ、クライアントには、命名文脈に優越する「脱走」というサーバが、キャラクタが何であるかを含んでいると意味論を命名することに関する知識がなければならないでしょう。
Crispin [Page 20] RFC 1730 IMAP4 December 1994
クリスピン[20ページ]RFC1730IMAP4 December 1994
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/*
参照メールボックス名前解釈------------ ------------ -------------- ~鍛冶屋/メール/foo*~鍛冶屋/メール/foo*アーカイブ/%アーカイブ/%#ニュースcomp.mail*#news.comp.mail*~鍛冶屋/メール//usr/doc/foo/usr/doc/fooアーカイブ/~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つの例が参照議論の文脈における解釈を示します。 「」 ~鍛冶屋/が郵送する注意」を何か"/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 detail).
キャラクタ「*」は、この位置のワイルドカードと、マッチゼロか、より多くのキャラクタです。 キャラクタ「%」は「*」と同様ですが、それは階層構造デリミタに合っていません。 また、「%」ワイルドカードがメールボックス名前引数の最後のキャラクタであるなら、階層構造の合っているレベルは返されます。 また、階層構造のこれらのレベルが選択可能なメールボックスでないなら、属性という\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 it
matches the input arguments and INBOX is supported by this server
for this user. 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.
受信トレイという特別な名前は合っているなら出力にLISTから含まれていて、入力議論と受信トレイがこのユーザのためにこのサーバによって支持されるということです。 受信トレイを省略するのが、SELECT INBOXがそうするかどうかということであるので、評価基準は失敗を返します。 ユーザの実際の受信トレイがこれかある他のサーバに住んでいるか否かに関係なく、それは関連していません。
Example: C: A002 LIST "~/Mail/" "%"
S: * LIST (\Noselect) "/" ~/Mail/foo
S: * LIST () "/" ~/Mail/meetings
S: A002 OK LIST completed
例: C: 」 「%」Sという「A002リスト」~/Mail/: * 「リスト(\Noselect)」/」 ~/Mail/foo S: * 「リスト()」/」 ~/Mail/meetings S: 完成したA002 OK LIST
Crispin [Page 21] RFC 1730 IMAP4 December 1994
クリスピン[21ページ]RFC1730IMAP4 December 1994
6.3.9. LSUB Command
6.3.9. LSUBコマンド
Arguments: reference name
mailbox name with possible wildcards
議論: 可能なワイルドカードの参照名前メールボックス名
Data: untagged responses: LSUB
データ: 非タグ付けをされた応答: LSUB
Result: OK - lsub completed
NO - lsub failure: can't list that reference or name
BAD - command unknown or arguments invalid
結果: OK--lsubの完成したノー--lsubの故障: その参照か名前BADをリストアップできません--未知か議論病人を命令してください。
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コマンドはユーザが「アクティブである」か、または「申し込まれる」ように宣言した名前のセットから名前の部分集合を返します。 ゼロか以上が返されますuntagged LSUBが、返答する。 LSUBへの議論がLISTのためのそれらと同じフォームにあります。
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: "A002 LSUB"#ニュース、」 「comp.mail*」、S: * 「LSUB()」、」 #news.comp.mail.mime S: * 「LSUB()」、」 #news.comp.mail.misc S: 完成したA002 OK LSUB
6.3.10. APPEND Command
6.3.10. 追加コマンド
Arguments: mailbox name
optional flag parenthesized list
optional date/time string
message literal
議論: メールボックスの名前の任意の旗は文字通りでリスト任意の日付/時間ストリングメッセージをparenthesizedしました。
Data: no specific data 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
結果: OK--完成したノーを追加してください--誤りを追加してください: メールボックス、旗、日付/時間またはメッセージ・テキストBADにおける誤りをそれに追加できません--未知か議論病人を命令してください。
The APPEND command appends the literal argument as a new message
in the specified destination mailbox. This argument is in the
format of an [RFC-822] 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 [MIME-1] encoding.
APPENDコマンドは新しいメッセージとして指定されたあて先メールボックスの中で文字通りの議論を追加します。 [RFC-822]メッセージの形式にはこの議論があります。 8ビットのキャラクタはメッセージで受入れられます。 適切に8ビットのデータを保存できないサーバ実現はreversiblyに7ビットの使用[MIME-1]コード化に8ビットのAPPENDデータを変換できなければなりません。
If a flag parenthesized list or date_time are specified, that data
SHOULD be set in the resulting message; otherwise, the defaults of
empty flags and the current date/time are used.
旗はリストをparenthesizedしたか、そして、_時間が指定されていて、データSHOULDが結果として起こるメッセージで用意ができる日付。 さもなければ、空の旗のデフォルトと現在の日付/時間は使用されています。
Crispin [Page 22] RFC 1730 IMAP4 December 1994
クリスピン[22ページ]RFC1730IMAP4 December 1994
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. If the mailbox is currently selected, the
normal new mail actions should occur.
追加、どんな理由でも失敗していて、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.
あて先メールボックスが存在していないなら、サーバは、誤りを返さなければならなくて、自動的にメールボックスを作成してはいけません。 あて先メールボックスを作成できないのが確かでない場合、サーバはタグ付けをされたいいえ応答のテキストの接頭語として「[TRYCREATE]」という応答コードを送らなければなりません。 これはCREATEがうまくいくなら、CREATEコマンドを試みて、APPENDを再試行できるというクライアントへのヒントを与えます。
Example: C: A003 APPEND saved-messages (\Seen) {310}
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
例: C: A003 APPENDの救われたメッセージ(\Seen)310C: 日付: 月曜日、1994年2月7日21:52:25 -0800(太平洋標準時の)のC: From: フレッド Foobar <foobar@Blurdybloop.COM 、gt;、C: Subject: 午後のミーティングC: To: mooch@owatagu.siam.edu C: メッセージイド: <B27397-0100000@Blurdybloop.COM>C: MIMEバージョン: 1.0C: コンテントタイプ: テキスト/平野。 CHARSETは米国のASCII Cと等しいです: C: こんにちは、ジョー、あなたは私たちが明日の3:30に会うことができると思いますか? C: S: 完成したA003 OK APPEND
Note: the APPEND command is not used for message delivery,
because it does not provide a mechanism to transfer [SMTP]
envelope information.
以下に注意してください。 APPENDコマンドはメッセージ配送に使用されません、[SMTP]封筒情報を移すためにメカニズムを提供しないので。
6.4. Client Commands - Selected State
6.4. クライアントコマンド--選択された状態
In 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, FIND ALL.MAILBOXES, FIND MAILBOXES, and APPEND), the following commands are valid in the selected state: CHECK, CLOSE, EXPUNGE, SEARCH, FETCH, PARTIAL, STORE, COPY, and UID.
普遍的なコマンド(CAPABILITY、NOOP、およびLOGOUT)、および認証された州のコマンド(SELECT、EXAMINE、CREATE、DELETE、RENAME、登録、登録削除、LIST、LSUB、FIND ALL.MAILBOXES、FIND MAILBOXES、およびAPPEND)に加えて、以下のコマンドは選択された状態で有効です: チェック、閉鎖が梢消する、フェッチ的、そして、部分的な検索、店、コピー、およびUID。
Crispin [Page 23] RFC 1730 IMAP4 December 1994
クリスピン[23ページ]RFC1730IMAP4 December 1994
6.4.1. CHECK Command
6.4.1. チェックコマンド
Arguments: none
議論: なし
Data: no specific data 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
mail polling.
EXISTS untagged応答がCHECKの結果、起こるという保証が全くありません。 CHECKではなく、NOOPが新しいメール世論調査に使用されるべきです。
Example: C: FXXZ CHECK
S: FXXZ OK CHECK Completed
例: C: FXXZはSをチェックします: 終了するFXXZ OKチェック
6.4.2. CLOSE Command
6.4.2. 閉鎖コマンド
Arguments: none
議論: なし
Data: no specific data for this command
データ: このコマンドのための特定のデータがありません。
Result: OK - close completed, now in authenticated state
NO - close failure: no mailbox selected
BAD - command unknown or arguments invalid
結果: いいえ--近くのOKが完成して、現在、認証された状態では、失敗を閉じてください: どんなメールボックスもBADを選択しませんでした--未知か議論病人を命令してください。
The CLOSE command permanently removes from the currently selected
mailbox all messages that have the \Deleted flag set, and returns
to authenticated state from selected state. No untagged EXPUNGE
responses are sent.
CLOSEコマンドは永久に、現在選択されたメールボックスからDeleted旗が選択された状態から認証された状態に設定して、返す\を持っているすべてのメッセージを取り除きます。 untagged 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 when a mailbox is selected, it is not required to send a
CLOSE command before a SELECT, EXAMINE, or LOGOUT command. The
SELECT, EXAMINE, and LOGOUT commands implicitly close the
currently selected mailbox without doing an expunge. However,
メールボックスが選択さえされるとき、SELECT、EXAMINE、またはLOGOUTが命令する前にそれは、CLOSEコマンドを送るのに必要ではありません。 SELECT、EXAMINE、およびLOGOUTコマンドがそれとなくしないで現在選択されたメールボックスを閉じる、梢消します。 しかしながら
Crispin [Page 24] RFC 1730 IMAP4 December 1994
クリスピン[24ページ]RFC1730IMAP4 December 1994
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.
多くのメッセージが削除されるとき、untagged EXPUNGE応答(クライアントがたぶん無視するだろう)を全く送らないので、CLOSE-LOGOUTかCLOSE-SELECT系列がEXPUNGE-LOGOUTかEXPUNGE-SELECTよりかなり速いです。
Example: C: A341 CLOSE
S: A341 OK CLOSE completed
例: C: A341はSを閉じます: 完成したA341 OK CLOSE
6.4.3. EXPUNGE Command
6.4.3. 梢消コマンド
Arguments: none
議論: なし
Data: untagged responses: EXPUNGE
データ: 非タグ付けをされた応答: 梢消します。
Result: OK - expunge completed
NO - expunge failure: can't expunge (e.g. permission
denied)
BAD - command unknown or arguments invalid
結果: OK--完成したノーを梢消してください--失敗を梢消してください: BADを梢消できません(例えば否定された許可)--未知か議論病人を命令してください。
The EXPUNGE command permanently removes from the currently
selected mailbox all messages that have the \Deleted flag set.
Before returning an OK to the client, an untagged EXPUNGE response
is sent for each message that is removed.
EXPUNGEコマンドは永久に、現在選択されたメールボックスからDeleted旗が設定した\を持っているすべてのメッセージを取り除きます。 OKをクライアントに返す前に、取り除かれる各メッセージのためにuntagged EXPUNGE応答を送ります。
Example: C: A202 EXPUNGE
S: * 3 EXPUNGE
S: * 3 EXPUNGE
S: * 5 EXPUNGE
S: * 8 EXPUNGE
S: A202 OK EXPUNGE completed
例: C: A202はSを梢消します: * 3 Sを梢消してください: * 3 Sを梢消してください: * 5 Sを梢消してください: * 8 Sを梢消してください: 完成したA202 OK EXPUNGE
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応答の記述を見てください。
Crispin [Page 25] RFC 1730 IMAP4 December 1994
クリスピン[25ページ]RFC1730IMAP4 December 1994
6.4.4. SEARCH Command
6.4.4. 検索命令
Arguments: optional character set specification
searching criteria (one or more)
議論: 任意の文字の組仕様探す評価基準(1以上)
Data: mandatory untagged response: SEARCH
データ: 義務的な非タグ付けをされた応答: 検索
Result: OK - search completed
NO - search error: can't search that character set or
criteria
BAD - command unknown or arguments invalid
結果: OK--完成したノーを捜してください--誤りを捜してください: その文字の組か評価基準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.
検索命令は与えられた探す評価基準に合っているメッセージのためにメールボックスを捜します。 探す評価基準は1個以上の検索キーから成ります。 サーバからの非タグ付けをされた検索応答は探す評価基準に合っているそれらのメッセージに対応するメッセージ通番のリストを含んでいます。
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 may also be a parenthesized
list of one or more search keys (e.g. for use with the OR and NOT
keys).
複数のキーが指定されるとき、結果はそれらのキーに合っているすべてのメッセージの交差点(AND機能)です。 例えば、DELETED FROM「スミス」が1994年2月1日に以来示す評価基準はすべて、1994年2月1日以来メールボックスに置かれたスミスからメッセージを削除しました。 また、検索キーは1個以上の検索キー(例えば、キーではなく、ORとの使用のための)のparenthesizedリストであるかもしれません。
Server implementations MAY exclude [MIME-1] body parts with
terminal content types other than TEXT and MESSAGE from
consideration in SEARCH matching.
検索における考慮からのTEXTとMESSAGE以外の端末の満足しているタイプが合っていて、サーバ実現は身体の部分を除くかもしれません[MIME-1]。
The optional character set specification consists of the word
"CHARSET" followed by a registered MIME character set. It
indicates the character set of the strings that appear in the
search criteria. [MIME-2] strings that appear in RFC 822/MIME
message headers, and [MIME-1] content transfer encodings, MUST be
decoded before matching. Except for US-ASCII, it is not required
that any particular character set be supported. If the server
does not support the specified character set, it MUST return a
tagged NO response (not a BAD).
任意の文字の組仕様は"CHARSET"が登録されたMIME文字の組で続いたという単語から成ります。 それは検索評価基準に現れるストリングの文字の組を示します。 [MIME-2] マッチングの前にRFC822/MIMEメッセージヘッダー、および[MIME-1]満足している転送encodingsに現れるストリングを解読しなければなりません。 米国-ASCII以外に、どんな特定の文字の組もサポートされるのが必要ではありません。 サーバが指定された文字の組をサポートしないなら、それはタグ付けをされたいいえ応答(BADでない)を返さなければなりません。
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.
ストリングを使用するすべての検索キーでは、メッセージはストリングが分野に関するサブストリングであるならキーに合っています。 マッチングは大文字と小文字を区別しないです。
Crispin [Page 26] RFC 1730 IMAP4 December 1994
クリスピン[26ページ]RFC1730IMAP4 December 1994
The defined search keys are as follows. Refer to the Formal
Syntax section for the precise syntactic definitions of the
arguments.
定義された検索キーは以下の通りです。 議論の正確な構文の定義についてFormal Syntax部を参照してください。
<message set> Messages with message sequence numbers
corresponding to the specified message sequence
number set
指定されたメッセージ通番に対応するメッセージ通番がある<メッセージセット>Messagesはセットしました。
ALL All messages in the mailbox; the default initial
key for ANDing.
メールボックスの中のすべてのAllメッセージ。 デフォルトはANDingのためにキーに頭文字をつけます。
ANSWERED Messages with the \Answered flag set.
Answeredが旗を揚げさせる\があるANSWERED Messagesはセットしました。
BCC <string> Messages that contain the specified string in the
envelope structure's BCC field.
封筒構造のBCC分野に指定されたストリングを保管している<ストリング>MessagesをBCCしてください。
BEFORE <date> Messages whose internal date is earlier than the
specified date.
期日指定された期日より内部の前半であるBEFORE<日付>Messages。
BODY <string> Messages that contain the specified string in the
body of the message.
メッセージ欄に指定されたストリングを含むBODY<ストリング>Messages。
CC <string> Messages that contain the specified string in the
envelope structure's CC field.
封筒構造のCC分野に指定されたストリングを保管している<ストリング>MessagesをCCしてください。
DELETED Messages with the \Deleted flag set.
Deletedが旗を揚げさせる\があるDELETED Messagesはセットしました。
DRAFT Messages with the \Draft flag set.
Draftが旗を揚げさせる\があるDRAFT Messagesはセットしました。
FLAGGED Messages with the \Flagged flag set.
Flaggedが旗を揚げさせる\があるFLAGGED Messagesはセットしました。
FROM <string> Messages that contain the specified string in the
envelope structure's FROM field.
封筒構造のFROM分野に指定されたストリングを保管しているFROM<ストリング>Messages。
HEADER <field-name> <string>
Messages that have a header with the specified
field-name (as defined in [RFC-822]) and that
contains the specified string in the [RFC-822]
field-body.
ヘッダーが指定されたフィールド名([RFC-822]で定義されるように)とそれと共にあるHEADER<フィールド名><ストリング>Messagesが[RFC-822]分野本体に指定されたストリングを含んでいます。
KEYWORD <flag> Messages with the specified keyword set.
指定されたキーワードがあるKEYWORD<旗の>Messagesはセットしました。
LARGER <n> Messages with an RFC822.SIZE larger than the
specified number of octets.
RFC822.SIZEが八重奏の指定された数より大きいLARGER<n>Messages。
NEW Messages that have the \Recent flag set but not the
\Seen flag. This is functionally equivalent to
"(RECENT UNSEEN)".
Recentが旗を揚げさせる\を持っているNEW Messagesがセットしましたが、どんな\Seenも弛みません。 これが機能上相当している、「(最近、見えなさ、)、」
Crispin [Page 27] RFC 1730 IMAP4 December 1994
クリスピン[27ページ]RFC1730IMAP4 December 1994
NOT <search-key>
Messages that do not match the specified search
key.
指定された検索キーに合っていない<の検索主要な>Messagesでない。
OLD Messages that do not have the \Recent flag set.
This is functionally equivalent to "NOT RECENT" (as
opposed to "NOT NEW").
Recentが旗を揚げさせる\を持っていないOLD Messagesがセットしました。 これは「最近(「新しくないこと」と対照的に)でないこと」に機能上同等です。
ON <date> Messages whose internal date is within the
specified date.
指定された日の中に、内部の期日があるON<日付>Messages。
OR <search-key1> <search-key2>
Messages that match either search key.
合っているkey1><検索-key2を探しているOR<>Messagesがキーを捜します。
RECENT Messages that have the \Recent flag set.
Recentが旗を揚げさせる\を持っているRECENT Messagesがセットしました。
SEEN Messages that have the \Seen flag set.
Seenが旗を揚げさせる\を持っているSEEN Messagesがセットしました。
SENTBEFORE <date>
Messages whose [RFC-822] Date: header is earlier
than the specified date.
SENTBEFORE<は[RFC-822]日付:と>Messagesをデートします。 ヘッダーは指定された期日より初期です。
SENTON <date> Messages whose [RFC-822] Date: header is within the
specified date.
SENTON<は[RFC-822]日付:と>Messagesをデートします。 指定された日の中に、ヘッダーがあります。
SENTSINCE <date>
Messages whose [RFC-822] Date: header is within or
later than the specified date.
SENTSINCE<は[RFC-822]日付:と>Messagesをデートします。 ヘッダーは、中にあるか、または指定された期日より遅れています。
SINCE <date> Messages whose internal date is within or later
than the specified date.
内部の期日が中にあるか、または指定された期日より遅れているSINCE<日付>Messages。
SMALLER <n> Messages with an RFC822.SIZE smaller than the
specified number of octets.
RFC822.SIZEが八重奏の指定された数より小さいSMALLER<n>Messages。
SUBJECT <string>
Messages that contain the specified string in the
envelope structure's SUBJECT field.
封筒構造のSUBJECT分野に指定されたストリングを保管しているSUBJECT<ストリング>Messages。
TEXT <string> Messages that contain the specified string in the
header or body of the message.
ヘッダーかメッセージ欄に指定されたストリングを含むTEXT<ストリング>Messages。
TO <string> Messages that contain the specified string in the
envelope structure's TO field.
封筒構造のTO分野に指定されたストリングを保管しているTO<ストリング>Messages。
UID <message set>
Messages with unique identifiers corresponding to
the specified unique identifier set.
指定されたユニークな識別子に対応するユニークな識別子があるUID<メッセージセット>Messagesはセットしました。
Crispin [Page 28] RFC 1730 IMAP4 December 1994
クリスピン[28ページ]RFC1730IMAP4 December 1994
UNANSWERED Messages that do not have the \Answered flag set.
Answeredが旗を揚げさせる\を持っていないUNANSWERED Messagesがセットしました。
UNDELETED Messages that do not have the \Deleted flag set.
Deletedが旗を揚げさせる\を持っていないUNDELETED Messagesがセットしました。
UNDRAFT Messages that do not have the \Draft flag set.
Draftが旗を揚げさせる\を持っていないUNDRAFT Messagesがセットしました。
UNFLAGGED Messages that do not have the \Flagged flag set.
Flaggedが旗を揚げさせる\を持っていないUNFLAGGED Messagesがセットしました。
UNKEYWORD <flag>
Messages that do not have the specified keyword
set.
指定されたキーワードを設定させないUNKEYWORD<旗の>Messages。
UNSEEN Messages that do not have the \Seen flag set.
Seenが旗を揚げさせる\を持っていないUNSEEN Messagesがセットしました。
Example: C: A282 SEARCH FLAGGED SINCE 1-Feb-1994 NOT FROM "Smith"
S: * SEARCH 2 84 882
S: A282 OK SEARCH completed
例: C: どんな「スミス」Sからの少しの1994年2月1日以来もA282検索は弛みませんでした: * 882秒間の検索2 84: 完成したA282 OK SEARCH
6.4.5. FETCH Command
6.4.5. とって来コマンド
Arguments: message set
message data item names
議論: メッセージセットメッセージデータ項目名
Data: untagged responses: FETCH
データ: 非タグ付けをされた応答: フェッチ
Result: OK - fetch completed
NO - fetch error: can't fetch that data
BAD - command unknown or arguments invalid
結果: OK--完成したノーをとって来てください--誤りをとって来てください: そのデータBADをとって来ることができません--未知か議論病人を命令してください。
The FETCH command retrieves data associated with a message in the
mailbox. The data items to be fetched may be either a single atom
or a parenthesized list. The currently defined data items that
can be fetched are:
FETCHコマンドはメールボックスの中のメッセージに関連しているデータを検索します。 とって来られるデータ項目は、単一原子かparenthesizedリストのどちらかであるかもしれません。 とって来ることができる現在定義されたデータ項目は以下の通りです。
ALL Macro equivalent to: (FLAGS INTERNALDATE
RFC822.SIZE ENVELOPE)
以下とすべてのMacro同等物 (INTERNALDATE RFC822.SIZE封筒に旗を揚げさせます)
BODY Non-extensible form of BODYSTRUCTURE.
BODYSTRUCTUREのBODY Non広げることができるフォーム。
BODY[<section>]
The text of a particular body section. The section
specification is a set of one or more part numbers
delimited by periods.
BODY、[<部の>] 特定のボディー部のテキスト。 セクション仕様は周期的に区切られている1つ以上の部品番号のセットです。
Single-part messages only have a part 1.
ただ一つの部分メッセージには、第1部があるだけです。
Crispin [Page 29] RFC 1730 IMAP4 December 1994
クリスピン[29ページ]RFC1730IMAP4 December 1994
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.
It is not permitted to fetch a multipart part
itself, only its individual members.
メッセージに起こるとき、連続した部品番号は複合メッセージに割り当てられます。 特定の部分がタイプメッセージがあるか、または複合であるなら、部品番号がその入れ子にされた複合部分の中であとに続いていて、期間までに部品を示さなければなりません。 個人会員だけ、それが複合部分自体をとって来ることが許可されていません。
A part of type MESSAGE and subtype RFC822 also has
nested parts. These are the parts of the MESSAGE
part's body. Nested part 0 of a part of type
MESSAGE and subtype RFC822 is the [RFC-822] header
of the message.
タイプMESSAGEとsubtype RFC822の一部も部品を入れ子にしました。 これらはMESSAGE部分の身体の部分です。 タイプMESSAGEとsubtype RFC822の一部の入れ子にされたパート0はメッセージの[RFC-822]ヘッダーです。
Every message has at least one part.
あらゆるメッセージには、少なくとも一部があります。
Here is an example of a complex message
with its associated section
specifications:
ここに、複雑なメッセージに関する例が関連セクション仕様であります:
0 ([RFC-822] header of the message)
MULTIPART/MIXED
1 TEXT/PLAIN
2 APPLICATION/OCTET-STREAM
3 MESSAGE/RFC822
3.0 ([RFC-822] header of the message)
3.1 TEXT/PLAIN
3.2 APPLICATION/OCTET-STREAM
MULTIPART/MIXED
4.1 IMAGE/GIF
4.2 MESSAGE/RFC822
4.2.0 ([RFC-822] header of the message)
4.2.1 TEXT/PLAIN
MULTIPART/ALTERNATIVE
4.2.2.1 TEXT/PLAIN
4.2.2.2 TEXT/RICHTEXT
メッセージの0[RFC-822]ヘッダー) MULTIPART/Mixed1TEXT/PLAIN2APPLICATION/OCTET-STREAM3MESSAGE/RFC822 3.0(メッセージの[RFC-822] メッセージのヘッダー)3.1TEXT/PLAIN3.2APPLICATION/OCTET-STREAM MULTIPART/Mixed4.1IMAGE/GIF4.2MESSAGE/RFC822 4.2.0[RFC-822]ヘッダー)4.2.1TEXT/PLAIN MULTIPART/ALTERNATIVE4.2.2.1TEXT/PLAIN4.2.2.2TEXT/RICHTEXT
Note that there is no section
specification for the Multi-part parts
(no section 4 or 4.2.2).
Multi-部分の一部(いいえセクション4か4.2.2)のためのセクション仕様が全くないことに注意してください。
The \Seen flag is implicitly set; if this causes
the flags to change they should be included as part
of the fetch responses.
Seenが旗を揚げさせる\はそれとなく設定されます。 旗がこれで変化するなら、それらはフェッチ応答の一部として含まれるべきです。
BODY.PEEK[<section>]
An alternate form of BODY[section] that does not
implicitly set the \Seen flag.
補欠が形成するそれとなくないするBODY[セクション]のBODY.PEEK[<部の>]はSeenが旗を揚げさせる\を設定しました。
Crispin [Page 30] RFC 1730 IMAP4 December 1994
クリスピン[30ページ]RFC1730IMAP4 December 1994
BODYSTRUCTURE The [MIME-1] body structure of the message. This
is computed by the server by parsing the [MIME-1]
header lines.
BODYSTRUCTURE、メッセージの[MIME-1]ボディー構造。 これは、[MIME-1]ヘッダー線を分析することによって、サーバによって計算されます。
ENVELOPE The envelope structure of the message. This is
computed by the server by parsing the [RFC-822]
header into the component parts, defaulting various
fields as necessary.
ENVELOPE、メッセージの封筒構造。 これは、必要に応じてコンポーネントの部品への[RFC-822]ヘッダー、デフォルト多岐を分析することによって、サーバによって計算されます。
FAST Macro equivalent to: (FLAGS INTERNALDATE
RFC822.SIZE)
以下とFAST Macro同等物 (INTERNALDATE RFC822.SIZEに旗を揚げさせます)
FLAGS The flags that are set for this message.
FLAGS、このメッセージに設定される旗。
FULL Macro equivalent to: (FLAGS INTERNALDATE
RFC822.SIZE ENVELOPE BODY)
以下とFULL Macro同等物 (INTERNALDATE RFC822.SIZE封筒ボディーに旗を揚げさせます)
INTERNALDATE The date and time of final delivery of the message
as defined by RFC 821.
RFC821による定義されるとしてのメッセージの最終的な配送の日時のINTERNALDATE。
RFC822 The message in [RFC-822] format. The \Seen flag is
implicitly set; if this causes the flags to change
they should be included as part of the fetch
responses. This is the concatenation of
RFC822.HEADER and RFC822.TEXT.
RFC822、[RFC-822]形式におけるメッセージ。 Seenが旗を揚げさせる\はそれとなく設定されます。 旗がこれで変化するなら、それらはフェッチ応答の一部として含まれるべきです。 これはRFC822.HEADERとRFC822.TEXTの連結です。
RFC822.PEEK An alternate form of RFC822 that does not
implicitly set the \Seen flag.
RFC822.PEEK AnはそれとなくSeenが旗を揚げさせる\を設定しないRFC822のフォームを交替します。
RFC822.HEADER The [RFC-822] format header of the message as
stored on the server including the delimiting blank
line between the header and the body.
ヘッダーとボディーの間の区切りの空白の線を含むサーバの格納されるとしてのメッセージの[RFC-822]形式ヘッダーのRFC822.HEADER。
RFC822.HEADER.LINES <header_list>
All header lines (including continuation lines) of
the [RFC-822] format header of the message with a
field-name (as defined in [RFC-822]) that matches
any of the strings in header_list. The matching is
case-insensitive but otherwise exact. The
delimiting blank line between the header and the
body is always included.
ヘッダー_でストリングのいずれにも合っているフィールド名([RFC-822]で定義されるように)があるメッセージの[RFC-822]形式ヘッダーのRFC822.HEADER.LINES<ヘッダー_リスト>Allヘッダー線(継続行を含んでいる)は記載します。 マッチングは、大文字と小文字を区別しないのですが、そうでなければ、正確です。 ヘッダーとボディーの間の区切りの空白の線はいつも含まれています。
Crispin [Page 31] RFC 1730 IMAP4 December 1994
クリスピン[31ページ]RFC1730IMAP4 December 1994
RFC822.HEADER.LINES.NOT <header_list>
All header lines (including continuation lines) of
the [RFC-822] format header of the message with a
field-name (as defined in [RFC-822]) that does not
match any of the strings in header_list. The
matching is case-insensitive but otherwise exact.
The delimiting blank line between the header and
the body is always included.
ヘッダー_でストリングのいずれにも合っていないフィールド名([RFC-822]で定義されるように)があるメッセージの[RFC-822]形式ヘッダーのRFC822.HEADER.LINES.NOT<ヘッダー_リスト>Allヘッダー線(継続行を含んでいる)は記載します。 マッチングは、大文字と小文字を区別しないのですが、そうでなければ、正確です。 ヘッダーとボディーの間の区切りの空白の線はいつも含まれています。
RFC822.SIZE The number of octets in the message, as expressed
in [RFC-822] format.
RFC822.SIZE、[RFC-822]形式で言い表されるようなメッセージの八重奏の数。
RFC822.TEXT The text body of the message, omitting the
[RFC-822] header. The \Seen flag is implicitly
set; if this causes the flags to change they should
be included as part of the fetch responses.
RFC822.TEXT、[RFC-822]ヘッダーを省略するテキストメッセージ欄。 Seenが旗を揚げさせる\はそれとなく設定されます。 旗がこれで変化するなら、それらはフェッチ応答の一部として含まれるべきです。
RFC822.TEXT.PEEK
An alternate form of RFC822.TEXT that does not
implicitly set the \Seen flag.
RFC822.TEXT.PEEK AnはそれとなくSeenが旗を揚げさせる\を設定しないRFC822.TEXTのフォームを交替します。
UID The unique identifier for the message.
UID、メッセージのためのユニークな識別子。
Example: C: A654 FETCH 2:4 (FLAGS RFC822.HEADER.LINES (DATE FROM))
S: * 2 FETCH ....
S: * 3 FETCH ....
S: * 4 FETCH ....
S: A003 OK FETCH completed
例: C: A654は2:4(旗のRFC822.HEADER.LINES(さかのぼる))Sをとって来ます: * 2 とって来ます。 S: * 3 とって来ます。 S: * 4 とって来ます。 S: 完成したA003 OK FETCH
6.4.6. PARTIAL Command
6.4.6. 部分的なコマンド
Arguments: message sequence number
message data item name
position of first octet
number of octets
議論: 最初に、八重奏の八重奏番号のメッセージ通番メッセージデータ項目名前位置
Data: untagged responses: FETCH
データ: 非タグ付けをされた応答: フェッチ
Result: OK - partial completed
NO - partial error: can't fetch that data
BAD - command unknown or arguments invalid
結果: OK--部分的な完成したノー--部分誤差: そのデータBADをとって来ることができません--未知か議論病人を命令してください。
The PARTIAL command is equivalent to the associated FETCH command,
with the added functionality that only the specified number of
octets, beginning at the specified starting octet, are returned.
Only a single message can be fetched at a time. The first octet
PARTIALコマンドは関連FETCHコマンドに同等です、八重奏の指定された数(指定された始めの八重奏における始め)だけが返される付記された機能性で。 一度に、ただ一つのメッセージしかとって来ることができません。 最初の八重奏
Crispin [Page 32] RFC 1730 IMAP4 December 1994
クリスピン[32ページ]RFC1730IMAP4 December 1994
of a message, and hence the minimum for the starting octet, is
octet 1.
メッセージ、およびしたがって、始めの八重奏のための最小限において、八重奏は1つです。
The following FETCH items are valid data for PARTIAL: RFC822,
RFC822.HEADER, RFC822.TEXT, BODY[section], as well as any .PEEK
forms of these.
以下のFETCHの品目はPARTIALのための有効データです: RFC822、RFC822.HEADER、RFC822.TEXT、BODY[セクション]、およびどんな.PEEK用紙のこれら。
Any partial fetch that attempts to read beyond the end of the text
is truncated as appropriate. If the starting octet is beyond the
end of the text, an empty string is returned.
テキストの終わりに読むのを試みるどんな部分的なフェッチも適宜先端を切られます。 始めの八重奏がテキストの終わりにあるなら、空のストリングを返します。
The data are returned with the FETCH response. There is no
indication of the range of the partial data in this response. It
is not possible to stream multiple PARTIAL commands of the same
data item without processing and synchronizing at each step, since
streamed commands may be executed out of order.
FETCH応答と共にデータを返します。 この応答における、部分的なデータの範囲のしるしが全くありません。 処理なしで同じデータ項目の複数のPARTIALコマンドを流すのが可能でなく、各ステップで連動して、以来流されたコマンドは故障していた状態で実行されるかもしれません。
There is no requirement that partial fetches follow any sequence.
For example, if a partial fetch of octets 1 through 10000 breaks
in an awkward place for BASE64 decoding, it is permitted to
continue with a partial fetch of 9987 through 19987, etc.
部分的なフェッチがどんな順序にも従うという要件が全くありません。 例えば、八重奏1〜10000の部分的なフェッチがBASE64解読のために無器用な場所を使いならすなら、19987などを通した9987年の部分的なフェッチを続行することが許可されます。
The handling of the \Seen flag is the same as in the associated
FETCH command.
Seenが旗を揚げさせる\の取り扱いは関連FETCHコマンドと同じです。
Example: C: A005 PARTIAL 4 RFC822 1 1024
S: * 1 FETCH (RFC822 {1024}
S: Return-Path: <gray@cac.washington.edu>
S: ...
S: ......... FLAGS (\Seen))
S: A005 OK PARTIAL completed
例: C: 1024秒間のA005の部分的な4RFC822 1: * 1つのフェッチ、(RFC822 1024S:リターンパス: <gray@cac.washington.edu 、gt;、S: …S: …… 旗(見られた\)) S: 完成したA005 OK PARTIAL
6.4.7. STORE Command
6.4.7. 保存命令
Arguments: message set
message data item name
value for message data item
議論: メッセージデータ項目のためのメッセージセットメッセージデータ項目名前価値
Data: untagged responses: FETCH
データ: 非タグ付けをされた応答: フェッチ
Result: OK - store completed
NO - store error: can't store that data
BAD - command unknown or arguments invalid
結果: OK--完成したノーを保存してください--誤りを保存してください: そのデータBADを保存できません--未知か議論病人を命令してください。
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
ストアコマンドはメールボックスの中のメッセージに関連しているデータを変更します。 通常、ストアはuntagged FETCH応答と共にデータのアップデートされた値を返すでしょう。 中の".SILENT"の接尾語
Crispin [Page 33] RFC 1730 IMAP4 December 1994
クリスピン[33ページ]RFC1730IMAP4 December 1994
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.
データ項目名がuntagged FETCHを防いで、サーバは、クライアントがアップデートされた値自体を決定したと仮定するべきであるか、またはアップデートされた値を心配しません。
The currently defined data items that can be stored are:
保存できる現在定義されたデータ項目は以下の通りです。
FLAGS <flag list>
Replace the flags for the message with the
argument. The new value of the flags are returned
as if a FETCH of those flags was done.
FLAGS<はリスト>Replaceに旗を揚げさせます。議論があるメッセージのための旗。 まるでそれらの旗のFETCHをするかのように旗の新しい値を返します。
FLAGS.SILENT <flag list>
Equivalent to FLAGS, but without returning a new
value.
しかし、FLAGSへのFLAGS.SILENT<現役将官名簿>Equivalent、戻ることのない新しい値。
+FLAGS <flag list>
Add the argument to the flags for the message. The
new value of the flags are returned as if a FETCH
of those flags was done.
+ FLAGS<旗は>Addを記載します。メッセージのための旗への議論。 まるでそれらの旗のFETCHをするかのように旗の新しい値を返します。
+FLAGS.SILENT <flag list>
Equivalent to +FLAGS, but without returning a new
value.
+ しかし、+ FLAGSへのFLAGS.SILENT<現役将官名簿>Equivalent、戻ることのない新しい値。
-FLAGS <flag list>
Remove the argument from the flags for the message.
The new value of the flags are returned as if a
FETCH of those flags was done.
-FLAGS<はリスト>Removeに旗を揚げさせます。メッセージのための旗からの議論。 まるでそれらの旗のFETCHをするかのように旗の新しい値を返します。
-FLAGS.SILENT <flag list>
Equivalent to -FLAGS, but without returning a new
value.
-しかし、-FLAGSへのFLAGS.SILENT<現役将官名簿>Equivalent、戻ることのない新しい値。
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
例: C: A003店2: 4 +はSに旗を揚げさせます(削除された\): * 2 (\は見られた\を削除しました)Sを旗にとって来てください: * 3 (削除された\)Sを旗にとって来てください: * 4 (\は\目にふれた状態で旗を揚げられた\を削除しました)Sを旗にとって来てください: 完成したA003 OK STORE
Crispin [Page 34] RFC 1730 IMAP4 December 1994
クリスピン[34ページ]RFC1730IMAP4 December 1994
6.4.8. COPY Command
6.4.8. コピーコマンド
Arguments: message set
mailbox name
議論: メッセージセットメールボックス名
Data: no specific data 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--コピーはいいえを完成しました--誤りをコピーしてください: それらのメッセージかその名前BADにコピーできません--未知か議論病人を命令してください。
The COPY command copies the specified message(s) to the specified
destination mailbox. The flags and internal date of the
message(s) SHOULD be preserved in the copy.
COPYコマンドは指定されたあて先メールボックスに指定されたメッセージをコピーします。 旗とインターナルは保存されたコネがコピーであったならメッセージ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が誤りを返すサーバです。 それ、SHOULD NOTは自動的にメールボックスを作成します。 あて先メールボックスを作成できないのが確かでない場合、サーバはタグ付けをされたいいえ応答のテキストの接頭語として「[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
例: C: A003は2:4ミーティングSをコピーします: 完成したA003 OK COPY
6.4.9. UID Command
6.4.9. UIDコマンド
Arguments: command name
command arguments
議論: コマンド名コマンド議論
Data: untagged responses: FETCH, SEARCH
データ: 非タグ付けをされた応答: フェッチ、検索
Result: OK - UID command completed
NO - UID command error
BAD - command unknown or arguments invalid
結果: OK--UIDコマンドはいいえ--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 message set argument are unique identifiers instead of message
sequence numbers.
UIDコマンドには、2つのフォームがあります。最初のフォームでは、それは議論として関連コマンドに、適切な議論でCOPY、FETCH、またはストアコマンドをみなします。 しかしながら、メッセージセット議論における数はメッセージ通番の代わりにユニークな識別子です。
Crispin [Page 35] RFC 1730 IMAP4 December 1994
クリスピン[35ページ]RFC1730IMAP4 December 1994
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 the message sequence number set 1:100 and the
UID set 443:557.
2番目のフォームでは、UIDコマンドは検索コマンド議論で検索命令を取ります。 議論の解釈は検索と同じです。 しかしながら、UID SEARCHコマンドのための検索応答で返された数はメッセージ通番の代わりにユニークな識別子です。 例えば、UID SEARCH1:100UIDを命令してください、443:557、1:100とUIDが設定するメッセージ通番セットの交差点に対応するユニークな識別子を返す、443:557
A unique identifier of a message is a number, and is guaranteed
not to refer to any other message in the mailbox. Unique
identifiers are assigned in a strictly ascending fashion for each
message added to the mailbox. Unlike message sequence numbers,
unique identifiers persist across sessions. This permits 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].
メッセージのユニークな識別子は、数であり、メールボックスの中のいかなる他のメッセージも示さないように保証されます。 ユニークな識別子はメールボックスに加えられた各メッセージのために厳密に昇っているファッションで割り当てられます。 メッセージ通番と異なって、ユニークな識別子はセッションの向こう側に持続しています。 これは、クライアントがサーバとの前のセッションから状態を再連動させることを許可します(例えば、クライアントに切断するか、またはオフライン、アクセスしてください)。 [IMAP-DISC]で、より詳しくこれについて議論します。
Associated with every mailbox is a unique identifier validity
value, which is sent in an UIDVALIDITY response code in an OK
untagged response at message selection time. If unique
identifiers from an earlier session fail to persist to this
session, the unique identifier validity value MUST be greater than
in the earlier session.
あらゆるメールボックスに関連づけられているのは、ユニークな識別子正当性価値(メッセージ選択時間にOKの非タグ付けをされた応答におけるUIDVALIDITY応答コードで送られる)です。 ユニークな固持する以前のセッションやり損ないからこのセッションまでの識別子であるなら、ユニークな識別子正当性価値は以前のセッションより大きいに違いありません。
Note: An example of a good value to use for the unique
identifier validity value would be 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 identifers will never be
reused, even in the case of a mailbox being deleted and
a new mailbox by the same name created at some future
time.
以下に注意してください。 ユニークな識別子正当性価値に使用する値打ち品に関する例はメールボックスの作成日付/現代の32ビットの表現でしょう。 1にもかかわらず、それが、ユニークなidentifersが決して再利用されないのを保証などだっただけであるかどうかなどの定数を使用するのは問題ありません、削除されるメールボックスに関するケースと何らかの将来の時間に作成された同じ名前の新しいメールボックスの中にさえ。
Message set ranges are permitted; however, there is no guarantee
that unique identifiers be contiguous. A non-existent unique
identifier within a message set range is ignored without any error
message generated.
メッセージセット範囲は受入れられます。 しかしながら、ユニークな識別子が隣接であるという保証が全くありません。 メッセージセット範囲の中の実在しないユニークな識別子は少しも発生しているエラーメッセージなしで無視されます。
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 UID was specified
as a message data item to the FETCH.
いつも非タグ付けをされたフェッチ応答における「*」の後の数はユニークな識別子ではなく、メッセージ通番です、UIDコマンド応答のためにさえ。 しかしながら、サーバ実装はUIDコマンドで引き起こされたどんなFETCH応答の一部としてもそれとなくUIDメッセージデータ項目を含まなければなりません、UIDがメッセージデータ項目としてFETCHに指定されたかどうかにかかわらず。
Crispin [Page 36] RFC 1730 IMAP4 December 1994
クリスピン[36ページ]RFC1730IMAP4 December 1994
Example: C: A003 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 UID FETCH completed
例: C: A003 UIDフェッチ4827313: 4828442個の旗S: * 23 (UID4827313に旗を揚げさせます(見られた\))Sをとって来てください: * 24 (UID4827943に旗を揚げさせます(見られた\))Sをとって来てください: * 25 (UID4828442に旗を揚げさせます(見られた\))Sをとって来てください: 完成したA999 UID FETCH
6.5. Client Commands - Experimental/Expansion
6.5. クライアントコマンド--実験的な/拡張
6.5.1. X<atom> Command
6.5.1. X<原子>コマンド
Arguments: implementation defined
議論: 定義された実装
Data: implementation defined
データ: 定義された実装
Result: OK - command completed
NO - failure
BAD - command unknown or arguments invalid
結果: OK--コマンドはいいえ--失敗BAD--コマンド未知か議論病人を完成しました。
Any command prefixed with an X is an experimental command.
Commands which are not part of this specification, or a standard
or standards-track revision of this specification, MUST use the X
prefix.
Xと共に前に置かれたどんなコマンドも実験的なコマンドです。 この仕様の一部でない、またこの仕様の規格か標準化過程改正でないコマンドは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.
いずれも、また、Server実装がそのような少しの非タグ付けをされた応答も送ってはいけないX.で実験的なコマンドで発行された非タグ付けをされた応答を前に置かなければならないと言い足しました、クライアントが関連実験的なコマンドを発行することによってそれを要求しなかったなら。
Example: C: a441 CAPABILITY
S: * CAPABILITY IMAP4 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
例: C: a441 CAPABILITY S: * 能力IMAP4 XPIG-ラテンS: a441OK CAPABILITYはCを完成しました: A442 XPIG-ラテンS: * XPIG-ラテン語、痛い、-いいえ、eakingしてig支払っているatin横たえているSの卵巣を除去してください: A442 OK XPIGラテン語のompleted小島
Crispin [Page 37] RFC 1730 IMAP4 December 1994
クリスピン[37ページ]RFC1730IMAP4 December 1994
7. Server Responses
7. サーバ応答
Server responses are in three forms: status responses, server data, and command continuation request.
サーバ応答が3つのフォームにあります: 応答、サーバデータ、およびコマンド継続が要求する状態。
Server response data, identified by "Data:" in the response descriptions below, are described by function, not by syntax. The precise syntax of server response data is described in the Formal Syntax section.
特定されたサーバ応答データ、「データ:」 以下での応答記述で説明する、機能で、構文によって説明されるのではなく、説明されます。 サーバ応答データの正確な構文はFormal Syntax部で説明されます。
The client MUST be prepared to accept any response at all times.
クライアントはいつもあらゆる応答を受け入れる用意ができていなければなりません。
Status responses that are tagged indicate the completion result of a client command, and have a tag matching the command.
タグ付けををされた状態応答で、クライアントコマンドの完成結果を示して、タグはコマンドに合っています。
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 historical reasons, untagged server data responses are also called "unsolicited data", although strictly speaking only unilateral server data is truly "unsolicited".
いくつかの状態応答、およびすべてのサーバデータが非タグ付けをされます。 非タグ付けをされた応答はタグの代わりにトークン「*」によって示されます。 Untagged状態応答はコマンドの完成を示さないサーバ挨拶、またはサーバ状態を示します。 歴史的な理由で、また、非タグ付けをされたサーバデータ応答は「求められていないデータ」と呼ばれます、厳密に言うと唯一の一方的なサーバデータが本当に「求められていませんです」が。
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 messags).
それが受け取られているとき、クライアントはあるサーバデータを記録しなければなりません。 そのデータの記述でこれに注意します。 そのようなデータはすべてのその後のコマンドの解釈に影響する重要情報と応答(例えば、messagsの作成か破壊を反映するアップデート)を伝えます。
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.
他のサーバデータSHOULD、後の参照には、記録されてください。 クライアントがそうする必要はないなら、データを記録してください、またはデータを記録するなら、明白な目的がない(例えば、検索命令が全く進行していないときの検索応答)、データSHOULDは無視されましたか?
An example of unilateral untagged responses occurs when the IMAP connection is in selected state. In selected state, the server checks the mailbox for new messages as part of the execution of each command. 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接続が選択された状態にあるとき、一方的な非タグ付けをされた応答に関する例は現れます。 選択された状態では、サーバは新しいメッセージがないかどうかそれぞれのコマンドの実行の一部としてメールボックスをチェックします。 新しいメッセージが見つけられるなら、サーバで、untagged EXISTSとRECENT応答はメールボックスの新しいサイズを反映します。 また、別のエージェントがどんなメッセージ旗の状態も変えるか、または何かメッセージを梢消するなら、同じメールボックスへの複数の同時アクセスを提供するサーバ実装は適切な一方的なuntagged 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.
コマンド継続要求応答はタグの代わりにトークン「+」を使用します。 サーバでこれらの応答を送って、コマンドの残りのための不完全なクライアントコマンドと準備の承認を示します。
Crispin [Page 38] RFC 1730 IMAP4 December 1994
クリスピン[38ページ]RFC1730IMAP4 December 1994
7.1. Server Responses - Status Responses
7.1. サーバ応答--状態応答
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/いいえ、/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.
ALERT、人間読み込み可能なテキストはメッセージへのユーザの注意を呼ぶファッションでユーザに提示しなければならない特別な警戒を含んでいます。
PARSE The human-readable text represents an error in
parsing the [RFC-822] or [MIME-1] headers of a
message in the mailbox.
PARSE、人間読み込み可能なテキストはメールボックスの中のメッセージの[RFC-822]か[MIME-1]ヘッダーを分析する際に誤りを表します。
PERMANENTFLAGS Followed by a parenthesized list of flags,
indicates which of the known flags that the client
may 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 reject
it with a NO reply or store the state for the
remainder of the current session only. The
PERMANENTFLAGS list may also include the special
flag \*, which indicates that it is possible to
create new keywords by attempting to store those
flags in the mailbox.
aによるPERMANENTFLAGS Followedは旗のリストをparenthesizedして、クライアントが永久に変えるかもしれない知られている旗のどれを示すか。 永久に、どんなPERMANENTFLAGSリストではなく、FLAGS untagged応答中であることの旗も設定できません。 クライアントがPERMANENTFLAGSリストにない旗をストアに試みると、サーバは、いいえ回答でそれを拒絶するか、または現在のセッションの残りだけのために状態を保存するでしょう。 また、PERMANENTFLAGSリストは特別な旗の\*を含むかもしれません。(それは、メールボックスの中にそれらの旗を保存するのを試みることによって新しいキーワードを作成するのが可能であることを示します)。
READ-ONLY The mailbox is selected read-only, or its access
while selected has changed from read-write to
read-only.
READだけ、メールボックスは選択された書き込み禁止であるかアクセスが選択されている間、読書して書くのから書き込み禁止に変化しています。
READ-WRITE The mailbox is selected read-write, or its access
while selected has changed from read-only to
read-write.
READ-WRITE、メールボックスが読書して書いた状態で選択されるか、またはアクセスは、読書して書くために選択されている間、書き込み禁止から変化しています。
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 may succeed if the mailbox is first
created by the CREATE command.
目標メールボックスが存在していないので、TRYCREATE An APPENDかCOPY試みが失敗(ある他の理由と対照的に)です。 これはクライアントへのメールボックスが最初にCREATEコマンドで作成されるなら操作が成功するかもしれないというヒントです。
Crispin [Page 39] RFC 1730 IMAP4 December 1994
クリスピン[39ページ]RFC1730IMAP4 December 1994
UIDVALIDITY Followed by a decimal number, indicates the unique
identifier validity value. See the description of
the UID command for more detail.
10進数に従ったUIDVALIDITY Followed、ユニークな識別子正当性価値を示します。 その他の詳細のためのUIDコマンドの記述を見てください。
UNSEEN Followed by a decimal number, indicates the number
of the first message without the \Seen flag set.
10進数に従ったUNSEEN Followed、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.
それらがこのプロトコルの改正に加えられるまで、特定のクライアントによって定義された追加応答コードかサーバ実装が「X」と共に前に置かれるべきです。 クライアント実装は彼らが認識しない応答コードを無視するべきです。
7.1.1. OK Response
7.1.1. OK応答
Data: 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 session startup. It indicates that the session is not yet
authenticated and that a LOGIN command is needed.
また、非タグ付けをされたフォームはセッション始動での3つの可能な挨拶の1つとして使用されます。 それは、セッションがまだ認証されていなくて、LOGINコマンドが必要であることを示します。
Example: S: * OK IMAP4 server ready
C: A001 LOGIN fred blurdybloop
S: * OK [ALERT] System shutdown in 10 minutes
S: A001 OK LOGIN Completed
例: S: * OK IMAP4のサーバ持ち合わせのC: A001 LOGIN fred blurdybloop S: * 10分Sで[ALERT]システム・シャットダウンを承認してください: 終了するA001OKログイン
7.1.2. NO Response
7.1.2. 応答がありません。
Data: 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 may still complete successfully. The human-readable text
describes the condition.
いいえ応答はサーバから誤操作メッセージを示します。タグ付けをされると、それは関連コマンドの失敗の完成を示します。 非タグ付けをされたフォームは警告を示します。 コマンドはまだ首尾よく完成しているかもしれません。 人間読み込み可能なテキストは状態について説明します。
Crispin [Page 40] RFC 1730 IMAP4 December 1994
クリスピン[40ページ]RFC1730IMAP4 December 1994
Example: C: A222 COPY 1:2 owatagusiam
S: * NO Disk is 98% full, please delete unnecessary data
S: A222 OK COPY completed
C: A222 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: A222 NO COPY failed: disk is full
例: C: A222 COPY1: 2owatagusiam S: * どんなDiskも98%完全でなく、不要なデータSを削除してください: A222 OK COPYはCを完成しました: A222 COPY3: 200blurdybloop S: * どんなDiskも98%完全でなく、不要なデータSを削除してください: * どんなDiskも99%完全でなく、不要なデータSを削除してください: A222 NO COPYは失敗しました: ディスクは完全です。
7.1.3. BAD Response
7.1.3. 誤応答
Data: 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 may 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
例: C: ...非常に長いコマンドライン… S: * BAD Commandは長過ぎるCを裏打ちします: ...系列を空にしてください… S: * BAD EmptyコマンドラインC: A443はSを梢消します: * 新しいディスクに海難救助を試みて、BAD Diskはダウンします! S: * OK Salvageうまくいって、どんなデータもSを失いませんでした: 完成したA443 OK Expunge
7.1.4. PREAUTH Response
7.1.4. PREAUTH応答
Data: optional response code
human-readable text
データ: 任意の応答コード人間読み込み可能なテキスト
The PREAUTH response is always untagged, and is one of three
possible greetings at session startup. It indicates that the
session has already been authenticated by external means and thus
no LOGIN command is needed.
PREAUTH応答は、いつも非タグ付けをされて、セッション始動での3つの可能な挨拶の1つです。 それは、セッションが外部の手段で既に認証されて、その結果、LOGINコマンドは全く必要でないことを示します。
Example: S: * PREAUTH IMAP4 server ready and logged in as Smith
例: S: * 準備ができてスミスとしてログインされたPREAUTH IMAP4サーバ
Crispin [Page 41] RFC 1730 IMAP4 December 1994
クリスピン[41ページ]RFC1730IMAP4 December 1994
7.1.5. BYE Response
7.1.5. さようなら応答
Data: 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 may be sent as part of a normal logout sequence, or as a
panic shutdown announcement by the server. It is also used by
some server implementations as an announcement of an inactivity
autologout.
BYE応答は、いつも非タグ付けをされて、サーバが接続を終えようとしているのを示します。 人間読み込み可能なテキストは現状報告にクライアントによってユーザに表示されるかもしれません。 標準の一部がログアウトするとき、BYE応答を送るかもしれません。配列するか、またはまた. それが不活発の発表としていくつかのサーバ実装によって使用されるというサーバによるパニック閉鎖発表autologoutします。
This response is also used as one of three possible greetings at
session startup. It indicates that the server is not willing to
accept a session from this client.
また、この応答はセッション始動での3つの可能な挨拶の1つとして使用されます。 それは、サーバがこのクライアントからセッションを受け入れることを望んでいないのを示します。
Example: S: * BYE Autologout; idle for too long
例: S: * さようならAutologout。 あまりに長い間、怠けてください。
7.2. Server Responses - Server and Mailbox Status
7.2. サーバ応答--サーバとメールボックス状態
These responses are always untagged. This is how server data are transmitted from the server to the client, often as a result of a command with the same name.
これらの応答はいつも非タグ付けをされます。 これはサーバデータがサーバからクライアントまでどう送られるかということです、しばしば同じ名前によるコマンドの結果、。
7.2.1. CAPABILITY Response
7.2.1. 能力応答
Data: 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 first
name in the capability listing MUST be the atom "IMAP4".
CAPABILITY応答はCAPABILITYコマンドの結果、起こります。 能力リストはサーバがサポートする能力名のスペースで切り離されたリストを含んでいます。 能力リストの名は原子"IMAP4""であるに違いありません。
A capability name other than IMAP4 indicates that the server
supports an extension, revision, or amendment to the IMAP4
protocol. Server responses MUST conform to this document until
the client issues a command that uses the associated capability.
IMAP4以外の能力名は、サーバがIMAP4プロトコルの拡大、改正、または修正をサポートするのを示します。 クライアントが関連能力を使用するコマンドを発行するまで、サーバ応答はこのドキュメントに従わなければなりません。
Capability names MUST either begin with "X" or be standard or
standards-track IMAP4 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」と共に始まるか、標準であるに違いありません、または標準化過程IMAP4拡張子、改正、または修正がIANAとともに記名しました。 そのような名前が「X」と共に前に置かれていない場合、サーバは登録されていないか標準的でない能力名を提供してはいけません。
Crispin [Page 42] RFC 1730 IMAP4 December 1994
クリスピン[42ページ]RFC1730IMAP4 December 1994
Client implementations SHOULD NOT require any capability name
other than "IMAP4", and MUST ignore any unknown capability names.
クライアント実装SHOULDがどんな能力名も必要としない、「IMAP4"、どんな未知の能力名も無視しなければならない、」
Example: S: * CAPABILITY IMAP4 XPIG-LATIN
例: S: * 能力IMAP4 XPIG-ラテン
7.2.2. LIST Response
7.2.2. リスト応答
Data: 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
may be multiple LIST responses for a single LIST command.
LIST応答はLISTコマンドの結果、起こります。 それはLIST仕様に合っているただ一つの名前を返します。 ただ一つの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 Itは可能ではありません。 子供レベルは全く現在存在しません、そして、将来、なにも作成できません。
\Noselect It is not possible to use this name as a selectable
mailbox.
\Noselect Itは選択可能なメールボックスとしてこの名前を使用するのにおいて可能ではありません。
\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.
メールボックスであるとマークされた\はサーバによって「おもしろい」とマークされました。 メールボックスはたぶんメールボックスが最後の時間選択されて以来加えられるメッセージを含んでいます。
\Unmarked The mailbox does not contain any additional
messages since the last time the mailbox was
selected.
\無印、メールボックスが最後の時間選択されたので、メールボックスはどんな追加メッセージも含んでいません。
If it is not feasible for the server to determine whether the
mailbox is "interesting" or not, 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 may 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階層構造デリミタは、階層構造が全く存在しないことを意味します。 名前は「平坦な」名前です。
Crispin [Page 43] RFC 1730 IMAP4 December 1994
クリスピン[43ページ]RFC1730IMAP4 December 1994
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
例: S: * 「リスト(\Noselect)」/」 ~/Mail/foo
7.2.3. LSUB Response
7.2.3. LSUB応答
Data: 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
may be multiple LSUB responses for a single LSUB command. The
data is identical in format to the LIST response.
LSUB応答はLSUBコマンドの結果、起こります。 それはLSUB仕様に合っているただ一つの名前を返します。 ただ一つのLSUBコマンドのための複数のLSUB応答があるかもしれません。 データは形式がLIST応答と同じです。
Example: S: * LSUB () "." #news.comp.mail.misc
例: S: * 「LSUB()」、」 #news.comp.mail.misc
7.2.4. SEARCH Response
7.2.4. 検索応答
Data: zero or more numbers
データ: ゼロか、より多くの数
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.
検索応答は検索かUID SEARCHコマンドの結果、起こります。 数は検索評価基準に合っているそれらのメッセージを示します。 検索のために、これらはメッセージ通番です。 UID SEARCHに関しては、これらはユニークな識別子です。 各数はスペースによって区切られます。
Example: S: * SEARCH 2 3 6
例: S: * 検索2 3 6
7.2.5. FLAGS Response
7.2.5. 応答に旗を揚げさせます。
Data: flag parenthesized list
データ: 旗はリストをparenthesizedしました。
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 may also exist,
depending on server implementation.
FLAGS応答はSELECTかEXAMINEコマンドの結果、起こります。 旗のparenthesizedリストはこのメールボックスに、適切な旗(最小限におけるシステムで定義された旗)を特定します。 また、サーバ実装によって、システム旗以外の旗は存在するかもしれません。
The update from the FLAGS response MUST be recorded by the client.
クライアントはFLAGS応答からのアップデートを記録しなければなりません。
Example: S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
例: S: * 旗(旗を揚げさせられた\\削除された\見られた\草稿に答えた\)
Crispin [Page 44] RFC 1730 IMAP4 December 1994
クリスピン[44ページ]RFC1730IMAP4 December 1994
7.3. Server Responses - Message Status
7.3. サーバ応答--メッセージ状態
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 either a message sequence number or a message count.
これらの応答はいつも非タグ付けをされます。 これはメッセージデータがサーバからクライアントまでどう送られるかということです、しばしば同じ名前によるコマンドの結果、。 すぐに「*」トークンに続くのは、メッセージ通番かメッセージカウントのどちらかを表す数です。
7.3.1. EXISTS Response
7.3.1. 存在、応答
Data: 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 mail).
EXISTS応答はメールボックスの中のメッセージの数を報告します。 SELECTかEXAMINEコマンドの結果とメールボックスのサイズが(例えば、新しいメール)を変えるかどうかとしてこの応答は起こります。
The update from the EXISTS response MUST be recorded by the
client.
クライアントはEXISTS応答からのアップデートを記録しなければなりません。
Example: S: * 23 EXISTS
例: S: * 23は存在しています。
7.3.2. RECENT Response
7.3.2. 最近の応答
Data: none
データ: なし
The RECENT response reports the number of messages that have
arrived since the previous time a SELECT command was done on this
mailbox. This response occurs as a result of a SELECT or EXAMINE
command, and if the size of the mailbox changes (e.g. new mail).
RECENT応答は前の時にこのメールボックスでSELECTコマンドをして以来到着しているメッセージの数を報告します。 SELECTかEXAMINEコマンドの結果とメールボックスのサイズが(例えば、新しいメール)を変えるかどうかとしてこの応答は起こります。
The update from the RECENT response MUST be recorded by the
client.
クライアントはRECENT応答からのアップデートを記録しなければなりません。
Example: S: * 5 RECENT
例: S: * 5、最近
7.3.3. EXPUNGE Response
7.3.3. 応答を梢消してください。
Data: 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つ減少します、そして、この減少はその後の応答でメッセージ通番に反映されます(他のuntagged EXPUNGE応答を含んでいて)。
Crispin [Page 45] RFC 1730 IMAP4 December 1994
クリスピン[45ページ]RFC1730IMAP4 December 1994
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つのuntagged EXPUNGE応答を送るでしょうが、「サーバを下ろすために、より高さ」はメッセージ通番9、8、7、6、および5のための連続したuntagged EXPUNGE応答を送るでしょう。
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.
コマンドが全く進行していないとき、EXPUNGE応答を送ってはいけません。 また、応じている間、FETCH、ストア、または検索に、命令してください。 この規則が、クライアントとサーバの間のメッセージ通番の同期の損失を防ぐのに必要です。
The update from the EXPUNGE response MUST be recorded by the
client.
クライアントはEXPUNGE応答からのアップデートを記録しなければなりません。
Example: S: * 44 EXPUNGE
例: S: * 44は梢消します。
7.3.4. FETCH Response
7.3.4. 応答をとって来てください。
Data: 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かストアコマンドの結果、および一方的なサーバ決定(例えば、旗のアップデート)でこの応答は起こります。
The current data items are:
現在のデータ項目は以下の通りです。
BODY A form of BODYSTRUCTURE without extension data.
拡大データのないBODYSTRUCTUREのBODY Aフォーム。
BODY[section] 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[セクション]五弦。 満足している転送コード化、ボディータイプ、および「副-タイプ」に従って、ストリングはクライアントによって解釈されるべきです。
8-bit textual data is permitted if a character set
identifier is part of the body parameter
parenthesized list for this section.
8ビットの原文のデータは文字集合識別子がこのセクションのためのボディーのパラメタのparenthesizedリストの一部であるなら受入れられます。
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
バイナリ・データなどの非原文のデータはクライアントに送る前のBASE64などの原文のフォームにコード化された転送であるに違いありません。 派生します。
Crispin [Page 46] RFC 1730 IMAP4 December 1994
クリスピン[46ページ]RFC1730IMAP4 December 1994
original binary data, the client must decode the
transfer encoded string.
オリジナルのバイナリ・データ、クライアントは転送のコード化されたストリングを解読しなければなりません。
BODYSTRUCTURE A parenthesized list that describes the body
structure of a message. This is computed by the
server by parsing the [RFC-822] header and body
into the component parts, defaulting various fields
as necessary.
BODYSTRUCTURE Aはメッセージのボディー構造について説明するリストをparenthesizedしました。 これは、コンポーネントの部品(必要に応じてデフォルト多岐)に[RFC-822]ヘッダーとボディーを分析することによって、サーバによって計算されます。
Multiple parts are indicated by parenthesis
nesting. Instead of a body type as the first
element of the parenthesized list there is a nested
body. The second element of the parenthesized list
is the multipart subtype (mixed, digest, parallel,
alternative, etc.).
複数の部品が挿入句巣篭もりで示されます。 ボディーの代わりに、そこのparenthesizedリストの最初の要素が入れ子にされたボディーであるので、タイプしてください。 parenthesizedリストの2番目の要素は複合「副-タイプ」(混ぜられて、平行に代替手段などを読みこなす)です。
Extension data follows the multipart subtype.
Extension data is never returned with the BODY
fetch, but may be returned with a BODYSTRUCTURE
fetch. Extension data, if present, must be in the
defined order.
拡大データは複合「副-タイプ」に続きます。 拡大データをBODYフェッチと共に決して返しませんが、BODYSTRUCTUREフェッチと共に返すかもしれません。 存在しているなら、拡大データは定義されたオーダーのそうであるに違いありません。
一覧
スポンサーリンク
