RFC3501 日本語訳
3501 INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1. M. Crispin. March 2003. (Format: TXT=227640 bytes) (Obsoletes RFC2060) (Updated by RFC4466, RFC4469, RFC4551, RFC5032, RFC5182) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group M. Crispin Request for Comments: 3501 University of Washington Obsoletes: 2060 March 2003 Category: Standards Track
コメントを求めるワーキンググループM.クリスピン要求をネットワークでつないでください: 3501 ワシントン大学は以下を時代遅れにします。 2060 2003年3月のカテゴリ: 標準化過程
INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1
インターネットメッセージアクセス・プロトコル--バージョン4rev1
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)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
Abstract
要約
The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev1 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. IMAP4rev1 also provides the capability for an offline client to resynchronize with the server.
インターネットMessage Accessプロトコル、バージョン4rev1(IMAP4rev1)はクライアントにサーバに関する電子メールメッセージにアクセスして、操らせます。IMAP4rev1は地方のフォルダーに機能上同等な道における、メールボックス(リモートメッセージフォルダー)の操作を可能にします。 また、IMAP4rev1はオフラインクライアントがサーバで再連動する能力を提供します。
IMAP4rev1 includes operations for creating, deleting, and renaming mailboxes, checking for new messages, permanently removing messages, setting and clearing flags, RFC 2822 and RFC 2045 parsing, searching, and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev1 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers.
IMAP4rev1はメールボックスを作成して、削除して、改名するための操作を含んでいます、新しいメッセージがないかどうかチェックして、永久にメッセージを取り除いて、メッセージ属性、テキスト、およびそれの部分を旗、RFC2822とRFC2045構文解析、探すのと、選択しているおよびとって来ることを設定して、きれいにして。 数の使用でIMAP4rev1のメッセージはアクセスされます。 これらの数は、メッセージ通番かユニークな識別子のどちらかです。
IMAP4rev1 supports a single server. A mechanism for accessing configuration information to support multiple IMAP4rev1 servers is discussed in RFC 2244.
IMAP4rev1はただ一つのサーバをサポートします。RFC2244で複数のIMAP4rev1サーバをサポートするために設定情報にアクセスするためのメカニズムについて議論します。
IMAP4rev1 does not specify a means of posting mail; this function is handled by a mail transfer protocol such as RFC 2821.
IMAP4rev1はメールを掲示する手段を指定しません。 この機能はRFC2821などのメール転送プロトコルによって扱われます。
Crispin Standards Track [Page 1] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[1ページ]RFC3501IMAPv4 March 2003
Table of Contents
目次
IMAP4rev1 Protocol Specification ................................ 4 1. How to Read This Document ............................... 4 1.1. Organization of This Document ........................... 4 1.2. Conventions Used in This Document ....................... 4 1.3. Special Notes to Implementors ........................... 5 2. Protocol Overview ....................................... 6 2.1. Link Level .............................................. 6 2.2. Commands and Responses .................................. 6 2.2.1. Client Protocol Sender and Server Protocol Receiver ..... 6 2.2.2. Server Protocol Sender and Client Protocol Receiver ..... 7 2.3. Message Attributes ...................................... 8 2.3.1. Message Numbers ......................................... 8 2.3.1.1. Unique Identifier (UID) Message Attribute ....... 8 2.3.1.2. Message Sequence Number Message Attribute ....... 10 2.3.2. Flags Message Attribute ................................. 11 2.3.3. Internal Date Message Attribute ......................... 12 2.3.4. [RFC-2822] Size Message Attribute ....................... 12 2.3.5. Envelope Structure Message Attribute .................... 12 2.3.6. Body Structure Message Attribute ........................ 12 2.4. Message Texts ........................................... 13 3. State and Flow Diagram .................................. 13 3.1. Not Authenticated State ................................. 13 3.2. Authenticated State ..................................... 13 3.3. Selected State .......................................... 13 3.4. Logout State ............................................ 14 4. Data Formats ............................................ 16 4.1. Atom .................................................... 16 4.2. Number .................................................. 16 4.3. String .................................................. 16 4.3.1. 8-bit and Binary Strings ................................ 17 4.4. Parenthesized List ...................................... 17 4.5. NIL ..................................................... 17 5. Operational Considerations .............................. 18 5.1. Mailbox Naming .......................................... 18 5.1.1. Mailbox Hierarchy Naming ................................ 19 5.1.2. Mailbox Namespace Naming Convention ..................... 19 5.1.3. Mailbox International Naming Convention ................. 19 5.2. Mailbox Size and Message Status Updates ................. 21 5.3. Response when no Command in Progress .................... 21 5.4. Autologout Timer ........................................ 22 5.5. Multiple Commands in Progress ........................... 22 6. Client Commands ........................................ 23 6.1. Client Commands - Any State ............................ 24 6.1.1. CAPABILITY Command ..................................... 24 6.1.2. NOOP Command ........................................... 25 6.1.3. LOGOUT Command ......................................... 26
IMAP4rev1は仕様を議定書の中で述べます… 4 1. どうこのドキュメントを読むか… 4 1.1. このドキュメントの組織… 4 1.2. このドキュメントで中古のコンベンション… 4 1.3. 作成者への特別な注意… 5 2. 概要について議定書の中で述べてください… 6 2.1. レベルをリンクしてください… 6 2.2. コマンドと応答… 6 2.2.1. クライアントプロトコル送付者とサーバは受信機について議定書の中で述べます… 6 2.2.2. サーバプロトコル送付者とクライアントは受信機について議定書の中で述べます… 7 2.3. メッセージ属性… 8 2.3.1. メッセージ番号… 8 2.3.1.1. ユニークな識別子(UID)メッセージ属性… 8 2.3.1.2. メッセージ通番メッセージ属性… 10 2.3.2. メッセージ属性に旗を揚げさせます… 11 2.3.3. 内部の日付のメッセージ属性… 12 2.3.4. [RFC-2822]サイズメッセージ属性… 12 2.3.5. 封筒構造メッセージ属性… 12 2.3.6. ボディー構造メッセージ属性… 12 2.4. メッセージテキスト… 13 3. 状態とフローチャート… 13 3.1. 状態を認証しません… 13 3.2. 状態を認証します… 13 3.3. 状態を選択します… 13 3.4. ログアウト、状態… 14 4. データ形式… 16 4.1. 原子… 16 4.2. 数… 16 4.3. 結びます。 16 4.3.1. 8ビットの、そして、2進のストリング… 17 4.4. リストをParenthesizedしました… 17 4.5. 無… 17 5. 操作上の問題… 18 5.1. メールボックス命名… 18 5.1.1. メールボックス階層構造命名… 19 5.1.2. メールボックス名前空間命名規則… 19 5.1.3. メールボックスの国際命名規則… 19 5.2. メールボックスサイズとメッセージ状態最新版… 21 5.3. ProgressでCommandでないことの応答… 21 5.4. Autologoutタイマ… 22 5.5. 倍数は進行中で命令します… 22 6. クライアントは命令します… 23 6.1. クライアントは命令します--どんな状態。 24 6.1.1. 能力コマンド… 24 6.1.2. NOOPは命令します… 25 6.1.3. ログアウトコマンド… 26
Crispin Standards Track [Page 2] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[2ページ]RFC3501IMAPv4 March 2003
6.2. Client Commands - Not Authenticated State .............. 26 6.2.1. STARTTLS Command ....................................... 27 6.2.2. AUTHENTICATE Command ................................... 28 6.2.3. LOGIN Command .......................................... 30 6.3. Client Commands - Authenticated State .................. 31 6.3.1. SELECT Command ......................................... 32 6.3.2. EXAMINE Command ........................................ 34 6.3.3. CREATE Command ......................................... 34 6.3.4. DELETE Command ......................................... 35 6.3.5. RENAME Command ......................................... 37 6.3.6. SUBSCRIBE Command ...................................... 39 6.3.7. UNSUBSCRIBE Command .................................... 39 6.3.8. LIST Command ........................................... 40 6.3.9. LSUB Command ........................................... 43 6.3.10. STATUS Command ......................................... 44 6.3.11. APPEND Command ......................................... 46 6.4. Client Commands - Selected State ....................... 47 6.4.1. CHECK Command .......................................... 47 6.4.2. CLOSE Command .......................................... 48 6.4.3. EXPUNGE Command ........................................ 49 6.4.4. SEARCH Command ......................................... 49 6.4.5. FETCH Command .......................................... 54 6.4.6. STORE Command .......................................... 58 6.4.7. COPY Command ........................................... 59 6.4.8. UID Command ............................................ 60 6.5. Client Commands - Experimental/Expansion ............... 62 6.5.1. X<atom> Command ........................................ 62 7. Server Responses ....................................... 62 7.1. Server Responses - Status Responses .................... 63 7.1.1. OK Response ............................................ 65 7.1.2. NO Response ............................................ 66 7.1.3. BAD Response ........................................... 66 7.1.4. PREAUTH Response ....................................... 67 7.1.5. BYE Response ........................................... 67 7.2. Server Responses - Server and Mailbox Status ........... 68 7.2.1. CAPABILITY Response .................................... 68 7.2.2. LIST Response .......................................... 69 7.2.3. LSUB Response .......................................... 70 7.2.4 STATUS Response ........................................ 70 7.2.5. SEARCH Response ........................................ 71 7.2.6. FLAGS Response ......................................... 71 7.3. Server Responses - Mailbox Size ........................ 71 7.3.1. EXISTS Response ........................................ 71 7.3.2. RECENT Response ........................................ 72 7.4. Server Responses - Message Status ...................... 72 7.4.1. EXPUNGE Response ....................................... 72 7.4.2. FETCH Response ......................................... 73 7.5. Server Responses - Command Continuation Request ........ 79
6.2. クライアントは命令します--状態を認証しません… 26 6.2.1. STARTTLSは命令します… 27 6.2.2. コマンドを認証してください… 28 6.2.3. ログインコマンド… 30 6.3. クライアントは命令します--状態を認証します… 31 6.3.1. コマンドを選択してください… 32 6.3.2. コマンドを調べてください… 34 6.3.3. コマンドを作成してください… 34 6.3.4. コマンドを削除してください… 35 6.3.5. コマンドを改名してください… 37 6.3.6. コマンドを申し込んでください… 39 6.3.7. コマンドを外してください… 39 6.3.8. コマンドを記載してください… 40 6.3.9. LSUBは命令します… 43 6.3.10. 状態コマンド… 44 6.3.11. コマンドを追加してください… 46 6.4. クライアントは命令します--状態を選択します… 47 6.4.1. コマンドをチェックしてください… 47 6.4.2. コマンドを終えてください… 48 6.4.3. コマンドを梢消してください… 49 6.4.4. コマンドを捜してください… 49 6.4.5. コマンドをとって来てください… 54 6.4.6. コマンドを保存してください… 58 6.4.7. コマンドをコピーしてください… 59 6.4.8. UIDは命令します… 60 6.5. クライアントは命令します--実験的な/拡張 62 6.5.1. X<原子>は命令します… 62 7. サーバ応答… 62 7.1. サーバ応答--状態応答… 63 7.1.1. 応答を承認してください… 65 7.1.2. 応答がありません… 66 7.1.3. 悪い応答… 66 7.1.4. PREAUTH応答… 67 7.1.5. さようなら応答… 67 7.2. サーバ応答--サーバとメールボックス状態… 68 7.2.1. 能力応答… 68 7.2.2. 応答を記載してください… 69 7.2.3. LSUB応答… 70 7.2 .4 状態応答… 70 7.2.5. 応答を捜してください… 71 7.2.6. 応答に旗を揚げさせます… 71 7.3. サーバ応答--メールボックスサイズ… 71 7.3.1. 存在、応答… 71 7.3.2. 最近の応答… 72 7.4. サーバ応答--メッセージ状態… 72 7.4.1. 応答を梢消してください… 72 7.4.2. 応答をとって来てください… 73 7.5. サーバ応答--継続要求を命令してください… 79
Crispin Standards Track [Page 3] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[3ページ]RFC3501IMAPv4 March 2003
8. Sample IMAP4rev1 connection ............................ 80 9. Formal Syntax .......................................... 81 10. Author's Note .......................................... 92 11. Security Considerations ................................ 92 11.1. STARTTLS Security Considerations ....................... 92 11.2. Other Security Considerations .......................... 93 12. IANA Considerations .................................... 94 Appendices ..................................................... 95 A. References ............................................. 95 B. Changes from RFC 2060 .................................. 97 C. Key Word Index ......................................... 103 Author's Address ............................................... 107 Full Copyright Statement ....................................... 108
8. IMAP4rev1接続を抽出してください… 80 9. 正式な構文… 81 10. 作者の注意… 92 11. セキュリティ問題… 92 11.1. STARTTLSセキュリティ問題… 92 11.2. 他のセキュリティ問題… 93 12. IANA問題… 94個の付録… 95 A.参照… 95 B.はRFC2060から変化します… 97C.キーワードインデックス… 103作者のアドレス… 107 完全な著作権宣言文… 108
IMAP4rev1 Protocol Specification
IMAP4rev1プロトコル仕様
1. How to Read This Document
1. このドキュメントを読む方法
1.1. Organization of This Document
1.1. このドキュメントの組織
This document is written from the point of view of the implementor of an IMAP4rev1 client or server. Beyond the protocol overview in section 2, it is not optimized for someone trying to understand the operation of the protocol. The material in sections 3 through 5 provides the general context and definitions with which IMAP4rev1 operates.
このドキュメントはIMAP4rev1クライアントかサーバの作成者の観点から書かれます。セクション2のプロトコル概要を超えて、それは、だれかのためにプロトコルの操作を理解しようとしながら、最適化されません。 セクション3〜5の材料はIMAP4rev1が作動する一般情勢と定義を提供します。
Sections 6, 7, and 9 describe the IMAP commands, responses, and syntax, respectively. The relationships among these are such that it is almost impossible to understand any of them separately. In particular, do not attempt to deduce command syntax from the command section alone; instead refer to the Formal Syntax section.
セクション6、7、および9 それぞれIMAPコマンド、応答、および構文について説明してください。 これらの中の関係がそのようなものであるので、別々にそれらのどれかを理解しているのはほとんど不可能です。 特に、指揮班からコマンド構文を単独で推論するのを試みないでください。 代わりにFormal Syntax部を参照してください。
1.2. Conventions Used in This Document
1.2. 本書では使用されるコンベンション
"Conventions" are basic principles or procedures. Document conventions are noted in this section.
「コンベンション」は、基本原理か手順です。 このセクションでドキュメントコンベンションは注意されます。
In examples, "C:" and "S:" indicate lines sent by the client and server respectively.
例で「C:」 そして、「S:」 クライアントとサーバによってそれぞれ送られた系列を示してください。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「」、「5月」、このドキュメントで「任意」は中[キーワード]で説明されるように解釈されることであるべきです。
The word "can" (not "may") is used to refer to a possible circumstance or situation, as opposed to an optional facility of the protocol.
単語“can"(“may"でない)は可能な状況か状況について言及するのに使用されます、プロトコルの任意の施設と対照的に。
Crispin Standards Track [Page 4] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[4ページ]RFC3501IMAPv4 March 2003
"User" is used to refer to a human user, whereas "client" refers to the software being run by the user.
「ユーザ」は人間のユーザについて言及するのに使用されますが、「クライアント」はユーザによって動かされるソフトウェアを示します。
"Connection" refers to the entire sequence of client/server interaction from the initial establishment of the network connection until its termination.
「接続」はネットワーク接続の当初設定からクライアント/サーバ相互作用の全体の系列を終了まで示します。
"Session" refers to the sequence of client/server interaction from the time that a mailbox is selected (SELECT or EXAMINE command) until the time that selection ends (SELECT or EXAMINE of another mailbox, CLOSE command, or connection termination).
「セッション」はメールボックスが選択される時間(SELECTかEXAMINEコマンド)から選択が終わる時間(別のメールボックス、CLOSEコマンド、または接続終了のSELECTかEXAMINE)までクライアント/サーバ相互作用の系列を示します。
Characters are 7-bit US-ASCII unless otherwise specified. Other character sets are indicated using a "CHARSET", as described in [MIME-IMT] and defined in [CHARSET]. CHARSETs have important additional semantics in addition to defining character set; refer to these documents for more detail.
別の方法で指定されない場合、キャラクターは7ビットの米国-ASCIIです。 他の文字集合は、[MIME-IMT]で説明されて、[CHARSET]で定義されるように"CHARSET"を使用することで示されます。 CHARSETsには、文字集合を定義することに加えて重要な追加意味論があります。 その他の詳細のためのこれらのドキュメントを参照してください。
There are several protocol conventions in IMAP. These refer to aspects of the specification which are not strictly part of the IMAP protocol, but reflect generally-accepted practice. Implementations need to be aware of these conventions, and avoid conflicts whether or not they implement the convention. For example, "&" may not be used as a hierarchy delimiter since it conflicts with the Mailbox International Naming Convention, and other uses of "&" in mailbox names are impacted as well.
数人のプロトコルコンベンションがIMAPにあります。 これらはIMAPの一部が厳密に、一般に慣例を議定書の中で述べますが、反映するということでない仕様の局面について言及します。 実装は、これらのコンベンションを意識しているのが必要であり、それらがコンベンションを実装するか否かに関係なく、摩擦を避けます。 例えば、メールボックスの国際命名規則と衝突するので、階層構造デリミタとして“&"を使用しないかもしれません、そして、また、メールボックス名における、“&"の他の用途に影響を与えます。
1.3. Special Notes to Implementors
1.3. 作成者への特記
Implementors of the IMAP protocol are strongly encouraged to read the IMAP implementation recommendations document [IMAP-IMPLEMENTATION] in conjunction with this document, to help understand the intricacies of this protocol and how best to build an interoperable product.
IMAPプロトコルの作成者は、このドキュメントに関連してIMAP実装推薦ドキュメント[IMAP-IMPLEMENTATION]を読んで、このプロトコルの複雑さと最もりっぱに共同利用できる製品を造る方法を理解しているのを助けるよう強く奨励されます。
IMAP4rev1 is designed to be upwards compatible from the [IMAP2] and unpublished IMAP2bis protocols. IMAP4rev1 is largely compatible with the IMAP4 protocol described in RFC 1730; the exception being in certain facilities added in RFC 1730 that proved problematic and were subsequently removed. In the course of the evolution of IMAP4rev1, some aspects in the earlier protocols have become obsolete. Obsolete commands, responses, and data formats which an IMAP4rev1 implementation can encounter when used with an earlier implementation are described in [IMAP-OBSOLETE].
IMAP4rev1は、[IMAP2]と未発表のIMAP2bisプロトコルから上向きに互換性があるように設計されています。 IMAP4rev1はRFC1730で説明されるIMAP4プロトコルと主に互換性があります。 ある施設にある例外は問題が多いと判明して、次に取り外されたRFC1730を加えました。 IMAP4rev1の発展の間に、以前のプロトコルにおけるいくつかの局面が時代遅れになりました。 以前の実装と共に使用されるとIMAP4rev1実装が遭遇できる時代遅れのコマンド、応答、およびデータ形式は[IMAP-OBSOLETE]で説明されます。
Other compatibility issues with IMAP2bis, the most common variant of the earlier protocol, are discussed in [IMAP-COMPAT]. A full discussion of compatibility issues with rare (and presumed extinct)
[IMAP-COMPAT]でIMAP2bisの他の互換性の問題(以前のプロトコルの最も一般的な異形)について議論します。 まれの互換性の問題の十分な議論(そして、消光していると推定されます)
Crispin Standards Track [Page 5] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[5ページ]RFC3501IMAPv4 March 2003
variants of [IMAP2] is in [IMAP-HISTORICAL]; this document is primarily of historical interest.
[IMAP2]の異形が[IMAP-HISTORICAL]にあります。 このドキュメントは主として歴史的におもしろいです。
IMAP was originally developed for the older [RFC-822] standard, and as a consequence several fetch items in IMAP incorporate "RFC822" in their name. With the exception of RFC822.SIZE, there are more modern replacements; for example, the modern version of RFC822.HEADER is BODY.PEEK[HEADER]. In all cases, "RFC822" should be interpreted as a reference to the updated [RFC-2822] standard.
IMAPは元々より古い[RFC-822]規格のために開発されました、そして、結果として、IMAPの数個のフェッチ項目が"RFC822"をそれらの名前に取り入れます。 RFC822.SIZEを除いて、より現代の交換があります。 例えば、RFC822.HEADERの現代版はBODY.PEEK[HEADER]です。 すべての場合では、"RFC822"はアップデートされた[RFC-2822]規格の参照として解釈されるべきです。
2. Protocol Overview
2. プロトコル概要
2.1. Link Level
2.1. リンク・レベル
The IMAP4rev1 protocol assumes a reliable data stream such as that provided by TCP. When TCP is used, an IMAP4rev1 server listens on port 143.
IMAP4rev1プロトコルはTCPによって提供されたそれなどの確実な資料ストリームを仮定します。 TCPが使用されているとき、IMAP4rev1サーバはポート143の上で聴かれます。
2.2. Commands and Responses
2.2. コマンドと応答
An IMAP4rev1 connection consists of the establishment of a client/server network connection, an initial greeting from the server, and client/server interactions. These client/server interactions consist of a client command, server data, and a server completion result response.
IMAP4rev1接続はクライアント/サーバネットワーク接続、サーバからの初期の挨拶、およびクライアント/サーバ相互作用の設立から成ります。 これらのクライアント/サーバ相互作用は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 IMAP4rev1 client or server is either reading a line, or is reading a sequence of octets with a known count followed by a line.
クライアントとサーバによって伝えられたすべての相互作用がその終わりにCRLFと共にすなわち、系列、ストリングの形にあります。 IMAP4rev1クライアントかサーバのプロトコル受信機は、系列を読んでいるか、または系列が知られているカウントのあとに続いていて、八重奏の系列を読んでいます。
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 an identifier (typically a short alphanumeric string, e.g., A0001, A0002, etc.) called a "tag". A different tag is generated by the client for each command.
クライアントコマンドは操業を開始します。 識別子(通常脆い英数字のストリング、例えば、A0001、A0002など)が「タグ」と呼ばれている状態で、それぞれのクライアントコマンドは前に置かれています。 異なったタグは各コマンドのためにクライアントによって生成されます。
Clients MUST follow the syntax outlined in this specification strictly. It is a syntax error to send a command with missing or extraneous spaces or arguments.
クライアントはこの仕様に厳密に概説された構文に従わなければなりません。 それはなくなったか異質な空間か議論と共にコマンドを送る構文エラーです。
There are two cases in which a line from the client does not represent a complete command. In one case, a command argument is quoted with an octet count (see the description of literal in String under Data Formats); in the other case, the command arguments require server feedback (see the AUTHENTICATE command). In either case, the
クライアントからの系列が完全なコマンドを表さない2つの場合があります。 ある場合では、コマンド議論は八重奏カウントで引用されます(Data Formatsの下でStringのリテラルの記述を見てください)。 もう片方の場合では、コマンド議論はサーバフィードバックを必要とします(AUTHENTICATEコマンドを見てください)。 どちらかの場合で
Crispin Standards Track [Page 6] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[6ページ]RFC3501IMAPv4 March 2003
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 "+".
それが八重奏(適切であるなら)とコマンドの残りの準備ができているなら、サーバはコマンド継続要求応答を送ります。 この応答はトークン「+」で前に置かれています。
Note: If instead, the server detected an error in the
command, it sends a BAD completion response with a tag
matching the command (as described below) to reject the
command and prevent the client from sending any more of the
command.
以下に注意してください。 サーバが代わりにコマンドにおける誤りを検出したなら、それはタグがコマンドを拒絶して、クライアントがコマンドのもっと多くのものを送るのを防ぐコマンド(以下で説明されるように)に合っているBAD完成応答を送ります。
It is also possible for the server to send a completion
response for some other command (if multiple commands are
in progress), or untagged data. In either case, the
command continuation request is still pending; the client
takes the appropriate action for the response, and reads
another response from the server. In all cases, the client
MUST send a complete command (including receiving all
command continuation request responses and command
continuations for the command) before initiating a new
command.
また、サーバがある他のコマンド(複数のコマンドが進行しているなら)、または非タグ付けをされたデータのための完成応答を送るのも、可能です。 どちらかの場合では、コマンド継続要求はまだ未定です。 クライアントは、応答に適切な行動を取って. サーバInからの別の応答にすべてのケースを読み込んで、新しいコマンドを開始する前に、クライアントは完全なコマンド(コマンドのためのすべてのコマンド継続要求応答とコマンド続刊を受けるのを含んでいる)を送らなければなりません。
The protocol receiver of an IMAP4rev1 server reads a command line from the client, parses the command and its arguments, and transmits server data and a server command completion result response.
IMAP4rev1サーバのプロトコル受信機は、クライアントからコマンドラインを読んで、コマンドとその議論を分析して、サーバデータとサーバコマンド完成結果応答を送ります。
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 command is in progress, the tag in a server completion response identifies the command to which the response applies. There are three possible server completion responses: OK (indicating success), NO (indicating failure), or BAD (indicating a protocol error such as unrecognized command or command syntax error).
サーバ完成結果応答は操作の成否を示します。 それは操業を開始したクライアントコマンドと同じタグでタグ付けをされます。 したがって、1つ以上のコマンドが進行しているなら、サーバ完成応答におけるタグは応答が適用されるコマンドを特定します。 3つの可能なサーバ完成応答があります: (成功を示します)、(失敗を示します)、またはBAD(認識されていないコマンドかコマンド構文エラーなどのプロトコル誤りを示す)を承認してください。
Servers SHOULD enforce the syntax outlined in this specification strictly. Any client command with a protocol syntax error, including (but not limited to) missing or extraneous spaces or arguments,
サーバSHOULDはこの仕様に厳密に概説された構文を実施します。 (他)なくなったか異質な空間か議論を含むプロトコル構文エラーがあるどんなクライアントコマンド
Crispin Standards Track [Page 7] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[7ページ]RFC3501IMAPv4 March 2003
SHOULD be rejected, and the client given a BAD server completion response.
SHOULD、拒絶されていてクライアント当然のことのa BADサーバ完成応答になってください。
The protocol receiver of an IMAP4rev1 client reads a response line from the server. It then takes action on the response based upon the first token of the response, which can be a tag, a "*", or a "+".
IMAP4rev1クライアントのプロトコル受信機はサーバから応答系列を読みます。次に、それは最初のトークンに基づく応答を実行します。
A client MUST be prepared to accept any server response at all times. This includes server data that was not requested. Server data SHOULD be recorded, so that the client can reference its recorded copy rather than sending a command to the server to request the data. In the case of certain server data, the data MUST be recorded.
クライアントはいつもあらゆるサーバ応答を受け入れる用意ができていなければなりません。 これは要求されなかったサーバデータを含んでいます。 サーバデータSHOULDが記録されて、クライアントがaを送るよりむしろ記録されたコピーに参照をつけることができるように、データを要求するとサーバに命令してください。 あるサーバデータの場合では、データを記録しなければなりません。
This topic is discussed in greater detail in the Server Responses section.
Server Responses部で詳細によりすばらしいこの話題について議論します。
2.3. Message Attributes
2.3. メッセージ属性
In addition to message text, each message has several attributes associated with it. These attributes can be retrieved individually or in conjunction with other attributes or message texts.
メッセージ・テキストに加えて、各メッセージには、それに関連しているいくつかの属性があります。 個別か他の属性かメッセージ・テキストに関連してこれらの属性を検索できます。
2.3.1. Message Numbers
2.3.1. メッセージ番号
Messages in IMAP4rev1 are accessed by one of two numbers; the unique identifier or the message sequence number.
IMAP4rev1のメッセージは2つの番号の1つによってアクセスされます。 ユニークな識別子かメッセージ通番。
2.3.1.1. Unique Identifier (UID) Message Attribute
2.3.1.1. ユニークな識別子(UID)メッセージ属性
A 32-bit value assigned to each message, which when used with the unique identifier validity value (see below) forms a 64-bit value that MUST NOT refer to any other message in the mailbox or any subsequent mailbox with the same name forever. Unique identifiers are assigned in a strictly ascending fashion in the mailbox; as each message is added to the mailbox it is assigned a higher UID than the message(s) which were added previously. Unlike message sequence numbers, unique identifiers are not necessarily contiguous.
ユニークな識別子と共に使用されると、正当性値(以下を見る)はいつまでも同じ名前でメールボックスかどんなその後のメールボックスの中のいかなる他のメッセージも示してはいけない64ビットの値を形成します。メールボックスにおける厳密に昇っているファッションで割り当てられて、値がユニークな識別子がそうである各メッセージに割り当てた32ビット。 各メッセージがメールボックスに加えられるとき、以前に加えられたメッセージより高いUIDはそれに割り当てられます。 メッセージ通番と異なって、ユニークな識別子は必ず隣接であるというわけではありません。
The unique identifier of a message MUST NOT change during the session, and SHOULD NOT change between sessions. Any change of unique identifiers between sessions MUST be detectable using the UIDVALIDITY mechanism discussed below. Persistent unique identifiers are required for a client to resynchronize its state from a previous session with the server (e.g., disconnected or offline access clients); this is discussed further in [IMAP-DISC].
メッセージのユニークな識別子はセッションの間、変化してはいけません、そして、SHOULD NOTはセッションの間で変化します。 以下で議論したUIDVALIDITYメカニズムを使用して、セッションの間のユニークな識別子のどんな変化も検出可能であるに違いありません。 クライアントがサーバとの前のセッションから状態を再連動させるのに永続的なユニークな識別子が必要です(例えば、クライアントに切断するか、またはオフライン、アクセスしてください)。 [IMAP-DISC]で、より詳しくこれについて議論します。
Crispin Standards Track [Page 8] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[8ページ]RFC3501IMAPv4 March 2003
Associated with every mailbox are two values which aid in unique identifier handling: the next unique identifier value and the unique identifier validity value.
あらゆるメールボックスに関連づけられているのは、ユニークな識別子取り扱いで支援する2つの値です: 次のユニークな識別子値とユニークな識別子正当性価値。
The next unique identifier value is the predicted value that will be assigned to a new message in the mailbox. Unless the unique identifier validity also changes (see below), the next unique identifier value MUST have the following two characteristics. First, the next unique identifier value MUST NOT change unless new messages are added to the mailbox; and second, the next unique identifier value MUST change whenever new messages are added to the mailbox, even if those new messages are subsequently expunged.
次のユニークな識別子値はメールボックスの中の新しいメッセージに割り当てられる予測値です。 また、ユニークな識別子の正当性が変化しない場合(以下を見てください)、次のユニークな識別子値には、以下の2つの特性がなければなりません。 まず最初に、新しいメッセージがメールボックスに加えられない場合、次のユニークな識別子値は変化してはいけません。 そして、新しいメッセージがメールボックスに加えられるときはいつも、2番目に、次のユニークな識別子値は変化しなければなりません、それらの新しいメッセージが次に梢消されても。
Note: The next unique identifier value is intended to
provide a means for a client to determine whether any
messages have been delivered to the mailbox since the
previous time it checked this value. It is not intended to
provide any guarantee that any message will have this
unique identifier. A client can only assume, at the time
that it obtains the next unique identifier value, that
messages arriving after that time will have a UID greater
than or equal to that value.
以下に注意してください。 次のユニークな識別子値がクライアントが、前の時にこの値をチェックして以来何かメッセージがメールボックスに提供されているかどうかと決心する手段を提供することを意図します。 どんなメッセージにもこのユニークな識別子があるのがどんな保証も提供することを意図しません。 クライアントは、それが次のユニークな識別子値を得て、それ以後到着するメッセージがUIDをより持つと当時、仮定できるだけです。その値。
The unique identifier validity value is sent in a UIDVALIDITY response code in an OK untagged response at mailbox selection time. If unique identifiers from an earlier session fail to persist in this session, the unique identifier validity value MUST be greater than the one used in the earlier session.
メールボックス選択時間にOKの非タグ付けをされた応答におけるUIDVALIDITY応答コードでユニークな識別子正当性価値を送ります。 このセッションのときに固執する以前のセッションやり損ないからのユニークな識別子であるなら、ユニークな識別子正当性価値はものが中で以前のセッションを使用したより大きいに違いありません。
Note: Ideally, unique identifiers SHOULD persist at all
times. Although this specification recognizes that failure
to persist can be unavoidable in certain server
environments, it STRONGLY ENCOURAGES message store
implementation techniques that avoid this problem. For
example:
以下に注意してください。 理想的に、ユニークな識別子SHOULDはいつも固執しています。 この仕様はその失敗を認識しますが、固執するのはあるサーバ環境において避けられない場合があり、それはこの問題を避けるSTRONGLY ENCOURAGESメッセージ店実装のテクニックです。 例えば:
1) Unique identifiers MUST be strictly ascending in the
mailbox at all times. If the physical message store is
re-ordered by a non-IMAP agent, this requires that the
unique identifiers in the mailbox be regenerated, since
the former unique identifiers are no longer strictly
ascending as a result of the re-ordering.
1) ユニークな識別子はメールボックスの中にいつも厳密に昇らなければなりません。 物理メッセージ店が非IMAPエージェントによって再注文されるなら、これは、メールボックスの中のユニークな識別子が作り直されるのを必要とします、前のユニークな識別子が再注文の結果、もう厳密に昇っていないので。
2) If the message store has no mechanism to store unique
identifiers, it must regenerate unique identifiers at
each session, and each session must have a unique
UIDVALIDITY value.
2) メッセージ店にユニークな識別子を保存するメカニズムが全くないなら、各セッションのときにユニークな識別子を作り直さなければなりません、そして、各セッションには、ユニークなUIDVALIDITY値がなければなりません。
Crispin Standards Track [Page 9] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[9ページ]RFC3501IMAPv4 March 2003
3) If the mailbox is deleted and a new mailbox with the
same name is created at a later date, the server must
either keep track of unique identifiers from the
previous instance of the mailbox, or it must assign a
new UIDVALIDITY value to the new instance of the
mailbox. A good UIDVALIDITY value to use in this case
is a 32-bit representation of the creation date/time of
the mailbox. It is alright to use a constant such as
1, but only if it guaranteed that unique identifiers
will never be reused, even in the case of a mailbox
being deleted (or renamed) and a new mailbox by the
same name created at some future time.
3) メールボックスが削除されて、同じ名前がある新しいメールボックスが、より後日作成されるなら、サーバがメールボックスの前のインスタンスからのユニークな識別子の動向をおさえなければなりませんか、またはそれは新しいUIDVALIDITY値をメールボックスの新しいインスタンスに割り当てなければなりません。 この場合使用する良いUIDVALIDITY値はメールボックスの作成日付/現代の32ビットの表現です。 1にもかかわらず、それが、ユニークな識別子が決して再利用されないのを保証などだっただけであるかどうかなどの定数を使用するのは問題ありません、削除される(または、改名されます)メールボックスに関するケースと何らかの将来の時間に作成された同じ名前の新しいメールボックスの中にさえ。
4) The combination of mailbox name, UIDVALIDITY, and UID
must refer to a single immutable message on that server
forever. In particular, the internal date, [RFC-2822]
size, envelope, body structure, and message texts
(RFC822, RFC822.HEADER, RFC822.TEXT, and all BODY[...]
fetch data items) must never change. This does not
include message numbers, nor does it include attributes
that can be set by a STORE command (e.g., FLAGS).
4) メールボックス名、UIDVALIDITY、およびUIDの組み合わせはいつまでも、そのサーバに関するただ一つの不変のメッセージを示さなければなりません。特に、内部の期日、[RFC-2822]サイズ、封筒、ボディー構造、およびメッセージ・テキスト(RFC822、RFC822.HEADER、RFC822.TEXT、およびすべてのBODY[…]がデータ項目をとって来る)は決して変化してはいけません。 これはメッセージ番号を含んでいません、そして、それはストアコマンド(例えば、FLAGS)で設定できる属性を含んでいません。
2.3.1.2. Message Sequence Number Message Attribute
2.3.1.2. メッセージ通番メッセージ属性
A relative position from 1 to the number of messages in the mailbox. This position MUST be ordered by ascending unique identifier. As each new message is added, it is assigned a message sequence number that is 1 higher than the number of messages in the mailbox before that new message was added.
相対的な1〜メールボックスの中のメッセージの数までの位置。 ユニークな識別子を昇ることによって、この位置を命令しなければなりません。 それぞれの新しいメッセージが加えられるとき、その新しいメッセージの前のメールボックスの中のメッセージの数が加えられたより高く1であるメッセージ通番はそれに割り当てられます。
Message sequence numbers can be reassigned during the session. For example, when a message is permanently removed (expunged) from the mailbox, the message sequence number for all subsequent messages is decremented. The number of messages in the mailbox is also decremented. Similarly, a new message can be assigned a message sequence number that was once held by some other message prior to an expunge.
セッションの間、メッセージ通番を再選任できます。 メッセージが永久にメールボックスから取り除かれるとき(梢消されます)、例えば、すべてのその後のメッセージのためのメッセージ通番は減少します。 また、メールボックスの中のメッセージの数は減少します。 同様に、一度ある他のメッセージによって保持されたメッセージ通番を新しいメッセージに割り当てることができる前、梢消します。
In addition to accessing messages by relative position in the mailbox, message sequence numbers can be used in mathematical calculations. For example, if an untagged "11 EXISTS" is received, and previously an untagged "8 EXISTS" was received, three new messages have arrived with message sequence numbers of 9, 10, and 11. Another example, if message 287 in a 523 message mailbox has UID 12345, there are exactly 286 messages which have lesser UIDs and 236 messages which have greater UIDs.
メールボックスの中に相対的な位置のそばでメッセージにアクセスすることに加えて、数学上の計算にメッセージ通番を使用できます。 例えば、「11は存在する」、以前に受け取られた非タグ付けをされた非タグ付けをされて、「8は存在していること」を受け取って、3つの新しいメッセージが9、10、および11のメッセージ通番と共に到着しました。 別の例、523メッセージメールボックスの中のメッセージ287にUID12345があるなら、より少ないUIDsを持っている286のメッセージと、よりすばらしいUIDsを持っている236のメッセージがまさにあります。
Crispin Standards Track [Page 10] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[10ページ]RFC3501IMAPv4 March 2003
2.3.2. Flags Message Attribute
2.3.2. メッセージ属性に旗を揚げさせます。
A list of zero or more named tokens associated with the message. A flag is set by its addition to this list, and is cleared by its removal. There are two types of flags in IMAP4rev1. A flag of either type can be permanent or session-only.
ゼロか以上のリストはメッセージに関連しているトークンを命名しました。 旗は、追加によってこのリストに設定されて、取り外しできれいにされます。 2つのタイプの旗がIMAP4rev1にあります。 タイプの旗は、パーマかセッション専用であるかもしれません。
A system flag is a flag name that is pre-defined in this specification. All system flags begin with "\". Certain system flags (\Deleted and \Seen) have special semantics described elsewhere. The currently-defined system flags are:
システム旗はこの仕様に事前に定義される旗の名です。 すべてのシステム旗が「\」で始まります。 あるシステム旗(\Deletedと\Seen)には、ほかの場所で説明された特別な意味論があります。 現在定義されたシステム旗は以下の通りです。
\Seen
Message has been read
\見られたMessageは読まれました。
\Answered
Message has been answered
Messageに答えた\は答えられました。
\Flagged
Message is "flagged" for urgent/special attention
\旗を揚げさせられたMessageは緊急の、または、特別な注意のために「旗を揚げられます」。
\Deleted
Message is "deleted" for removal by later EXPUNGE
\削除されたMessageは取り外しのために後のEXPUNGEによって「削除されます」。
\Draft
Message has not completed composition (marked as a draft).
\草稿Messageは構成(草稿として、マークされる)を終了していません。
\Recent
Message is "recently" arrived in this mailbox. This session
is the first session to have been notified about this
message; if the session is read-write, subsequent sessions
will not see \Recent set for this message. This flag can not
be altered by the client.
\最近のMessageによるメールボックスが「最近」これに届いたということです。 このセッションはこのメッセージに関して通知されるべきであった最初のセッションです。 -セッションがそうなら、読まれて、書いてください、そして、その後のセッションは、\Recentがこのメッセージに用意ができているのを見ないでしょう。 クライアントはこの旗を変更できません。
If it is not possible to determine whether or not this
session is the first session to be notified about a message,
then that message SHOULD be considered recent.
このセッションがその時メッセージSHOULDが最近であると考えられるというメッセージに関して通知されるべき最初のセッションであるかどうか決定するのが可能でないなら。
If multiple connections have the same mailbox selected
simultaneously, it is undefined which of these connections
will see newly-arrived messages with \Recent set and which
will see it without \Recent set.
複数の接続が同時に同じメールボックスを選択させるなら、これらの接続のどれがRecentが設定する\があるRecentが設定する\なしでそれを見る新来のメッセージを見るかは、未定義です。
A keyword is defined by the server implementation. Keywords do not begin with "\". Servers MAY permit the client to define new keywords in the mailbox (see the description of the PERMANENTFLAGS response code for more information).
キーワードはサーバ実装によって定義されます。 キーワードは「\」で始まりません。 サーバは、クライアントがメールボックスの中の新しいキーワードを定義することを許可するかもしれません(詳しい情報のためのPERMANENTFLAGS応答コードの記述を見てください)。
Crispin Standards Track [Page 11] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[11ページ]RFC3501IMAPv4 March 2003
A flag can be permanent or session-only on a per-flag basis. Permanent flags are those which the client can add or remove from the message flags permanently; that is, concurrent and subsequent sessions will see any change in permanent flags. Changes to session flags are valid only in that session.
旗は、1旗あたり1個のベースに関するパーマかセッションであるにすぎないかもしれません。 永久的な旗はクライアントが永久にメッセージ旗から加えるか、または取り除くことができるものです。 すなわち、同時発生の、そして、その後のセッションは永久的な旗におけるどんな変化も見るでしょう。 セッション旗への変化は単にそのセッションのときに有効です。
Note: The \Recent system flag is a special case of a
session flag. \Recent can not be used as an argument in a
STORE or APPEND command, and thus can not be changed at
all.
以下に注意してください。 \Recentシステム旗はセッション旗の特別なケースです。 \最近の缶をストアかAPPENDコマンドにおける議論として使用しないで、その結果、全く変えることができません。
2.3.3. Internal Date Message Attribute
2.3.3. 内部の日付のメッセージ属性
The internal date and time of the message on the server. This is not the date and time in the [RFC-2822] header, but rather a date and time which reflects when the message was received. In the case of messages delivered via [SMTP], this SHOULD be the date and time of final delivery of the message as defined by [SMTP]. In the case of messages delivered by the IMAP4rev1 COPY command, this SHOULD be the internal date and time of the source message. In the case of messages delivered by the IMAP4rev1 APPEND command, this SHOULD be the date and time as specified in the APPEND command description. All other cases are implementation defined.
[RFC-2822]ヘッダー、しかし、むしろメッセージであるときに反射する日時の日時でないことのサーバに関するメッセージの内部の日時を得ました。 [SMTP]によって定義されるように[SMTP]、このSHOULDを通して提供されたメッセージの場合では、メッセージの最終的な配送の日時になってください。 IMAP4rev1 COPYコマンド、このSHOULDによって提供されたメッセージの場合では、ソースメッセージの内部の日時になってください。 IMAP4rev1 APPENDコマンド、このSHOULDによって提供されたメッセージの場合では、APPENDコマンド記述における指定されるとしての日時になってください。 他のすべてのケースが定義された実装です。
2.3.4. [RFC-2822] Size Message Attribute
2.3.4. [RFC-2822]サイズメッセージ属性
The number of octets in the message, as expressed in [RFC-2822] format.
[RFC-2822]形式で言い表されるようなメッセージの八重奏の数。
2.3.5. Envelope Structure Message Attribute
2.3.5. 封筒構造メッセージ属性
A parsed representation of the [RFC-2822] header of the message. Note that the IMAP Envelope structure is not the same as an [SMTP] envelope.
メッセージの[RFC-2822]ヘッダーの分析された表現。 IMAP Envelope構造が[SMTP]封筒と同じでないことに注意してください。
2.3.6. Body Structure Message Attribute
2.3.6. ボディー構造メッセージ属性
A parsed representation of the [MIME-IMB] body structure information of the message.
メッセージの[MIME-IMB]ボディー構造情報の分析された表現。
Crispin Standards Track [Page 12] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[12ページ]RFC3501IMAPv4 March 2003
2.4. Message Texts
2.4. メッセージ・テキスト
In addition to being able to fetch the full [RFC-2822] text of a message, IMAP4rev1 permits the fetching of portions of the full message text. Specifically, it is possible to fetch the [RFC-2822] message header, [RFC-2822] message body, a [MIME-IMB] body part, or a [MIME-IMB] header.
メッセージの完全な[RFC-2822]テキストをとって来ることができることに加えて、IMAP4rev1は完全なメッセージ・テキストの部分をとって来ることを可能にします。 明確に、[RFC-2822]メッセージヘッダー、[RFC-2822]メッセージ本体、[MIME-IMB]身体の部分、または[MIME-IMB]ヘッダーをとって来るのは可能です。
3. State and Flow Diagram
3. 状態とフローチャート
Once the connection between client and server is established, an IMAP4rev1 connection is in one of four states. The initial state is identified in the server greeting. Most commands are only valid in certain states. It is a protocol error for the client to attempt a command while the connection is in an inappropriate state, and the server will respond with a BAD or NO (depending upon server implementation) command completion result.
クライアントとサーバとの関係がいったん確立されると、IMAP4rev1接続が4つの州の1つにあります。 初期状態はサーバ挨拶で特定されます。 ほとんどのコマンドが、ある州だけで有効です。 接続が不適当な状態にありますが、それはクライアントがコマンドを試みるプロトコル誤りです、そして、サーバはBADかいいえ(サーバ実装による)、コマンド完成結果で反応するでしょう。
3.1. Not Authenticated State
3.1. 認証された状態でない
In the not authenticated state, the client MUST supply authentication credentials before most commands will be permitted. This state is entered when a connection starts unless the connection has been pre-authenticated.
認証されなかった状態では、ほとんどのコマンドが受入れられる前にクライアントは認証資格証明書を供給しなければなりません。 接続があらかじめ認証されていない場合接続が始まるとき、この状態は入られます。
3.2. Authenticated State
3.2. 認証された状態
In the authenticated state, the client is authenticated and MUST select a mailbox to access before commands that affect messages will be permitted. This state is entered when a pre-authenticated connection starts, when acceptable authentication credentials have been provided, after an error in selecting a mailbox, or after a successful CLOSE command.
認証された状態では、クライアントは、認証されて、メッセージに影響するコマンドが受入れられる前にアクセスへのメールボックスを選択しなければなりません。 あらかじめ認証された接続が始まるとき、この状態は入られます、許容できる認証資格証明書を提供したとき、メールボックスを選択するか、うまくいっているCLOSEコマンドの後の誤りの後に。
3.3. Selected State
3.3. 選択された状態
In a selected state, a mailbox has been selected to access. This state is entered when a mailbox has been successfully selected.
選択された状態では、メールボックスはアクセサリーに選択されました。 メールボックスが首尾よく選択されたとき、この状態は入られます。
Crispin Standards Track [Page 13] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[13ページ]RFC3501IMAPv4 March 2003
3.4. Logout State
3.4. ログアウト、状態
In the logout state, the connection is being terminated. This state can be entered as a result of a client request (via the LOGOUT command) or by unilateral action on the part of either the client or server.
ログアウトしてください。中、状態、接続は終えられています。 クライアント要求(LOGOUTコマンドを通した)の結果、クライアントかサーバ側の一方的な行動でこの状態に入ることができます。
If the client requests the logout state, the server MUST send an untagged BYE response and a tagged OK response to the LOGOUT command before the server closes the connection; and the client MUST read the tagged OK response to the LOGOUT command before the client closes the connection.
ログアウトしてください。クライアント要求である、状態、接続を終える前にサーバはLOGOUTコマンドへのuntagged BYE応答とタグ付けをされたOK応答を送らなければなりません。 そして、接続を終える前にクライアントはLOGOUTコマンドへのタグ付けをされたOK応答を読まなければなりません。
A server MUST NOT unilaterally close the connection without sending an untagged BYE response that contains the reason for having done so. A client SHOULD NOT unilaterally close the connection, and instead SHOULD issue a LOGOUT command. If the server detects that the client has unilaterally closed the connection, the server MAY omit the untagged BYE response and simply close its connection.
そうした理由を含むuntagged BYE応答を送らないで、サーバは一方的に接続を終えてはいけません。 クライアントSHOULD NOTは一方的に接続を終えます、そして、代わりに、SHOULDはLOGOUTコマンドを発行します。 サーバがそれを検出するならクライアントが一方的に接続を終えて、サーバは、untagged BYE応答を省略して、単に接続を終えるかもしれません。
Crispin Standards Track [Page 14] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[14ページ]RFC3501IMAPv4 March 2003
+----------------------+
|connection established|
+----------------------+
||
\/
+--------------------------------------+
| server greeting |
+--------------------------------------+
|| (1) || (2) || (3)
\/ || ||
+-----------------+ || ||
|Not Authenticated| || ||
+-----------------+ || ||
|| (7) || (4) || ||
|| \/ \/ ||
|| +----------------+ ||
|| | Authenticated |<=++ ||
|| +----------------+ || ||
|| || (7) || (5) || (6) ||
|| || \/ || ||
|| || +--------+ || ||
|| || |Selected|==++ ||
|| || +--------+ ||
|| || || (7) ||
\/ \/ \/ \/
+--------------------------------------+
| Logout |
+--------------------------------------+
||
\/
+-------------------------------+
|both sides close the connection|
+-------------------------------+
+----------------------+ |確立された接続| +----------------------+ || \/ +--------------------------------------+ | サーバ挨拶| +--------------------------------------+ || (1) || (2) || (3) \/ || || +-----------------+ || || |認証されません。| || || +-----------------+ || || || (7) || (4) || || || \/ \/ || || +----------------+ || || | 認証されます。|<=++ || || +----------------+ || || || || (7) || (5) || (6) || || || \/ || || || || +--------+ || || || || |選択されます。|==++ || || || +--------+ || || || || (7) || \/ \/ \/ \/ +--------------------------------------+ | ログアウトしてください。| +--------------------------------------+ || \/ +-------------------------------+ |両側は接続を終えます。| +-------------------------------+
(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 Standards Track [Page 15] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[15ページ]RFC3501IMAPv4 March 2003
4. Data Formats
4. データ形式
IMAP4rev1 uses textual commands and responses. Data in IMAP4rev1 can be in one of several forms: atom, number, string, parenthesized list, or NIL. Note that a particular data item may take more than one form; for example, a data item defined as using "astring" syntax may be either an atom or a string.
IMAP4rev1は原文のコマンドと応答を使用します。 IMAP4rev1のデータがいくつかのフォームの1つにあることができます: 原子(数、ストリング)はリスト、またはNILをparenthesizedしました。 特定のデータ項目が1つ以上の形を取るかもしれないことに注意してください。 例えば、「astring」構文を使用すると定義されたデータ項目は、原子かストリングのどちらかであるかもしれません。
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: either literal or quoted string. The literal form is the general form of string. The quoted string form is an alternative that avoids the overhead of processing a literal at the cost of limitations of characters which may be used.
五弦が2つのフォームの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 represented as either "" (a quoted string
with zero characters between double quotes) or as {0} followed
by CRLF (a literal with an octet count of 0).
空のストリングが表される、「「(二重引用符の間には、キャラクタが全くない引用文字列) または、0としてCRLF(0の八重奏カウントがあるリテラル)が続かれている、」
Note: Even if the octet count is 0, a client transmitting a
literal MUST wait to receive a command continuation request.
以下に注意してください。 八重奏カウントが0であっても、リテラルを伝えるクライアントは、コマンド継続要求を受け取るのを待たなければなりません。
Crispin Standards Track [Page 16] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[16ページ]RFC3501IMAPv4 March 2003
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 a [MIME-IMB] content transfer encoding. IMAP4rev1 implementations MAY transmit 8-bit or multi-octet characters in literals, but SHOULD do so only when the [CHARSET] is identified.
そして、8ビット原文、バイナリメールは[MIME-IMB]満足している転送コード化の使用でサポートされます。 IMAP4rev1実装はリテラルで8ビットの、または、マルチ八重奏のキャラクタを伝えるかもしれませんが、[CHARSET]が特定されるときだけ、SHOULDはそうします。
Although a BINARY body encoding is defined, unencoded binary strings are not permitted. A "binary string" is any string with NUL characters. Implementations MUST encode binary data into a textual form, such as BASE64, before transmitting the data. A string with an excessive amount of CTL characters MAY also be considered to be binary.
BINARYボディーコード化は定義されますが、暗号化されていない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 can 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 form "NIL" represents the non-existence of a particular data item that is represented as a string or parenthesized list, as distinct from the empty string "" or the empty parenthesized list ().
特別なフォーム「無」はストリングとして表されるか、またはparenthesizedされる特定のデータ項目の非存在リストを表します、空のストリングと異なるとして「「または、空はリスト()をparenthesizedしました」。
Note: NIL is never used for any data item which takes the
form of an atom. For example, a mailbox name of "NIL" is a
mailbox named NIL as opposed to a non-existent mailbox
name. This is because mailbox uses "astring" syntax which
is an atom or a string. Conversely, an addr-name of NIL is
a non-existent personal name, because addr-name uses
"nstring" syntax which is NIL or a string, but never an
atom.
以下に注意してください。 NILは原子の形を取るどんなデータ項目にも決して使用されません。 例えば、「無」のメールボックス名は実在しないメールボックス名と対照的にメールボックスの命名された無です。 これはメールボックスが原子かストリングである「astring」構文を使用するからです。 逆に、NILというaddr-名前は実在しない個人名です、addr-名前がNILかストリング、しかし決して原子でない「nstring」構文を使用するので。
Crispin Standards Track [Page 17] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[17ページ]RFC3501IMAPv4 March 2003
5. Operational Considerations
5. 操作上の問題
The following rules are listed here to ensure that all IMAP4rev1 implementations interoperate properly.
以下の規則は、すべてのIMAP4rev1実装が適切に共同利用するのを保証するためにここに記載されています。
5.1. Mailbox Naming
5.1. メールボックス命名
Mailbox names are 7-bit. Client implementations MUST NOT attempt to create 8-bit mailbox names, and SHOULD interpret any 8-bit mailbox names returned by LIST or LSUB as UTF-8. Server implementations SHOULD prohibit the creation of 8-bit mailbox names, and SHOULD NOT return 8-bit mailbox names in LIST or LSUB. See section 5.1.3 for more information on how to represent non-ASCII mailbox names.
メールボックス名は7ビットです。 クライアント実装は、8ビットのメールボックス名を作成するのを試みてはいけません、そして、SHOULDはUTF-8としてLISTかLSUBによって返されたどんな8ビットのメールボックス名も解釈します。 サーバ実装SHOULDは8ビットのメールボックス名の作成を禁止します、そして、SHOULD NOTはLISTかLSUBの8ビットのメールボックス名を返します。 どう非ASCIIメールボックス名を表すかに関する詳しい情報に関してセクション5.1.3を見てください。
Note: 8-bit mailbox names were undefined in earlier
versions of this protocol. Some sites used a local 8-bit
character set to represent non-ASCII mailbox names. Such
usage is not interoperable, and is now formally deprecated.
以下に注意してください。 8ビットのメールボックス名はこのプロトコルの以前のバージョンで未定義でした。 いくつかのサイトが、非ASCIIメールボックス名を表すのに地方の8ビットの文字集合を使用しました。 そのような用法は、共同利用できないで、現在、正式に推奨しないです。
The case-insensitive mailbox name INBOX is a special name reserved to mean "the primary mailbox for this user on this server". The interpretation of all other names is implementation-dependent.
受信トレイという大文字と小文字を区別しないメールボックス名は「このサーバのこのユーザのためのプライマリメールボックス」を意味するために予約された特別な名前です。 他のすべての名前の解釈は実装依存しています。
In particular, this specification takes no position on case sensitivity in non-INBOX mailbox names. Some server implementations are fully case-sensitive; others preserve case of a newly-created name but otherwise are case-insensitive; and yet others coerce names to a particular case. Client implementations MUST interact with any of these. If a server implementation interprets non-INBOX mailbox names as case-insensitive, it MUST treat names using the international naming convention specially as described in section 5.1.3.
特に、この仕様は非受信トレイメールボックス名のケース感度の立場を全く取りません。 いくつかのサーバ実装が完全に大文字と小文字を区別しています。 他のものは、新たに作成された名前に関するケースを保存しますが、そうでなければ、大文字と小文字を区別しないです。 他のもの、強制、特定のケースへの名前。 クライアント実装はこれらのいずれとも対話しなければなりません。 サーバ実装が、非受信トレイメールボックス名が大文字と小文字を区別しないと解釈するなら、特に、セクション5.1.3で説明されるように国際的な命名規則を使用して、それは名前を扱わなければなりません。
There are certain client considerations when creating a new mailbox name:
新しいメールボックス名を作成するとき、あるクライアント問題があります:
1) Any character which is one of the atom-specials (see the Formal
Syntax) will require that the mailbox name be represented as a
quoted string or literal.
1) 原子スペシャル(Formal Syntaxを見る)の1つであるどんなキャラクタも、メールボックス名が引用文字列かリテラルとして表されるのを必要とするでしょう。
2) CTL and other non-graphic characters are difficult to represent
in a user interface and are best avoided.
2) CTLと他の非図形文字をユーザーインタフェースに表すのが難しく、避けるのは最も良いです。
3) Although the list-wildcard characters ("%" and "*") are valid
in a mailbox name, it is difficult to use such mailbox names
with the LIST and LSUB commands due to the conflict with
wildcard interpretation.
3) リストワイルドカードキャラクタ(「%」と「*」)はメールボックス名で有効ですが、リストのそのようなメールボックス名とワイルドカード解釈との闘争によるLSUBコマンドを使用するのは難しいです。
Crispin Standards Track [Page 18] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[18ページ]RFC3501IMAPv4 March 2003
4) Usually, a character (determined by the server implementation)
is reserved to delimit levels of hierarchy.
4) 通常、キャラクタ(サーバ実装で断固とした)は、階層構造のレベルを区切るために予約されます。
5) Two characters, "#" and "&", have meanings by convention, and
should be avoided except when used in that convention.
5) 2つのキャラクタ(「#」と“&")が、コンベンションで意味を持って、そのコンベンションに使用される時を除いて、避けられるべきです。
5.1.1. Mailbox Hierarchy Naming
5.1.1. メールボックス階層構造命名
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.1.2. Mailbox Namespace Naming Convention
5.1.2. メールボックス名前空間命名規則
By convention, the first hierarchical element of any mailbox name which begins with "#" identifies the "namespace" of the remainder of the name. This makes it possible to disambiguate between different types of mailbox stores, each of which have their own namespaces.
コンベンションで、「#」で始まるどんなメールボックス名の最初の階層的な原理も名前の残りの「名前空間」を特定します。 これで、それはメールボックスの異なったタイプの間でそれぞれ店のあいまいさを除くのにおいて可能になります(それら自身の名前空間があります)。
For example, implementations which offer access to USENET
newsgroups MAY use the "#news" namespace to partition the
USENET newsgroup namespace from that of other mailboxes.
Thus, the comp.mail.misc newsgroup would have a mailbox
name of "#news.comp.mail.misc", and the name
"comp.mail.misc" can refer to a different object (e.g., a
user's private mailbox).
「例えばユーズネットへの申し出アクセスが使用するかもしれない実装、」 #ニュース、」 他のメールボックスのものからユーズネット名前空間を仕切る名前空間。 「その結果、comp.mail.miscニュースグループには、」 #news.comp.mail.miscのメールボックス名があっ」て、"comp.mail.misc"という名前は異なったオブジェクト(例えば、ユーザの個人的なメールボックス)について言及できます。
5.1.3. Mailbox International Naming Convention
5.1.3. メールボックスの国際命名規則
By convention, international mailbox names in IMAP4rev1 are specified using a modified version of the UTF-7 encoding described in [UTF-7]. Modified UTF-7 may also be usable in servers that implement an earlier version of this protocol.
コンベンションによって、IMAP4rev1の国際的なメールボックス名は[UTF-7]で説明されたUTF-7コード化の変更されたバージョンを使用することで指定されます。 また、変更されたUTF-7もこのプロトコルの以前のバージョンを実装するサーバで使用可能であるかもしれません。
In modified UTF-7, printable US-ASCII characters, except for "&", represent themselves; that is, characters with octet values 0x20-0x25 and 0x27-0x7e. The character "&" (0x26) is represented by the two-octet sequence "&-".
変更されたUTF-7では、“&"を除いて、印刷可能な米国-ASCII文字は自分たちの代理をします。 すなわち、八重奏値の0×20-0×25と0×27 0x7eがあるキャラクタ。 「キャラクタ“&"(0×26)は2八重奏の系列によって表される」、-、」
All other characters (octet values 0x00-0x1f and 0x7f-0xff) are represented in modified BASE64, with a further modification from [UTF-7] that "," is used instead of "/". Modified BASE64 MUST NOT be used to represent any printing US-ASCII character which can represent itself.
「他のすべてのキャラクタ(八重奏値の0×00 0x1fと0x7f-0xff)が変更されたBASE64で代理をされます、[UTF-7]それからのさらなる変更で」」、」 /の代わりに使用される、」 変更されたBASE64 MUST NOT、使用されて、それ自体を表すことができるあらゆる印刷米国-ASCII文字の代理をしてください。
Crispin Standards Track [Page 19] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[19ページ]RFC3501IMAPv4 March 2003
"&" is used to shift to modified BASE64 and "-" to shift back to
US-ASCII. There is no implicit shift from BASE64 to US-ASCII, and
null shifts ("-&" while in BASE64; note that "&-" while in US-ASCII
means "&") are not permitted. However, all names start in US-ASCII,
and MUST end in US-ASCII; that is, a name that ends with a non-ASCII
ISO-10646 character MUST end with a "-").
"&"は、米国-ASCIIに移動して戻させる変更されたBASE64と「-」に移行するのに使用されます。 暗黙のBASE64から米国-ASCIIまでのシフトがなく、およびヌルシフトがあります。中で米国-ASCIIをゆったり過ごしてください。「("-&"は中でBASE64をゆったり過ごします;、それに注意してください、」、-、」、手段“&") 受入れられません。 しかしながら、すべての名前が、米国-ASCIIで始まって、米国-ASCIIに終わらなければなりません。 すなわち、非ASCII ISO-10646キャラクタを伴う終わりが「-」で終わらせなければならない名前)
The purpose of these modifications is to correct the following problems with UTF-7:
これらの変更の目的はUTF-7に関する以下の問題を修正することです:
1) UTF-7 uses the "+" character for shifting; this conflicts with
the common use of "+" in mailbox names, in particular USENET
newsgroup names.
1) UTF-7は移行するのに「+」キャラクタを使用します。 これはメールボックス名、特定のユーズネット名における「+」の一般の使用と衝突します。
2) UTF-7's encoding is BASE64 which uses the "/" character; this
conflicts with the use of "/" as a popular hierarchy delimiter.
2) 「UTF-7コード化して、BASE64がどの用途であるか、」 /、」 キャラクタ。 ポピュラーな階層構造デリミタとして「これは」 /の使用と衝突します」。
3) UTF-7 prohibits the unencoded usage of "\"; this conflicts with
the use of "\" as a popular hierarchy delimiter.
3) UTF-7は「\」の暗号化されていない用法を禁止します。 これはポピュラーな階層構造デリミタとして「\」の使用と衝突します。
4) UTF-7 prohibits the unencoded usage of "~"; this conflicts with
the use of "~" in some servers as a home directory indicator.
4) UTF-7は「~」の暗号化されていない用法を禁止します。 これはホームディレクトリインディケータとしていくつかのサーバにおける「~」の使用と衝突します。
5) UTF-7 permits multiple alternate forms to represent the same
string; in particular, printable US-ASCII characters can be
represented in encoded form.
5) UTF-7は、複数の代替のフォームが同じストリングを表すのを可能にします。 特に、コード化されたフォームで印刷可能な米国-ASCII文字の代理をされることができます。
Although modified UTF-7 is a convention, it establishes certain
requirements on server handling of any mailbox name with an
embedded "&" character. In particular, server implementations
MUST preserve the exact form of the modified BASE64 portion of a
modified UTF-7 name and treat that text as case-sensitive, even if
names are otherwise case-insensitive or case-folded.
変更されたUTF-7はコンベンションですが、それは埋め込まれた“&"キャラクタのどんなメールボックス名のサーバ取り扱いに関する、ある要件も確立します。 サーバ実装は、特に、変更されたUTF-7名の変更されたBASE64部分の正確なフォームを保存して、大文字と小文字を区別するとしてそのテキストを扱わなければなりません、名前がそうでなければ、大文字と小文字を区別しないかケースによって折り重ねられても。
Server implementations SHOULD verify that any mailbox name with an
embedded "&" character, used as an argument to CREATE, is: in the
correctly modified UTF-7 syntax, has no superfluous shifts, and
has no encoding in modified BASE64 of any printing US-ASCII
character which can represent itself. However, client
implementations MUST NOT depend upon the server doing this, and
SHOULD NOT attempt to create a mailbox name with an embedded "&"
character unless it complies with the modified UTF-7 syntax.
サーバ実装SHOULDは、作成する議論として使用される埋め込まれた“&"キャラクタのどんなメールボックス名も以下の通りであることを確かめます。 中、正しくUTF-7構文を変更して、どんな余計なシフトも持っていなくて、またそれ自体を表すことができるどんな印刷米国-ASCII文字の変更されたBASE64でのコード化も持っていません。 しかしながら、クライアント実装はこれをするサーバによってはいけません、そして、変更されたUTF-7構文に従わない場合、SHOULDは埋め込まれた“&"キャラクタのメールボックス名を作成するのを試みません。
Server implementations which export a mail store that does not
follow the modified UTF-7 convention MUST convert to modified
UTF-7 any mailbox name that contains either non-ASCII characters
or the "&" character.
変更されたUTF-7コンベンションに続かないメール店をエクスポートするサーバ実装は非ASCII文字か“&"キャラクタのどちらかを含むどんなメールボックス名も変更されたUTF-7に変換しなければなりません。
Crispin Standards Track [Page 20] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[20ページ]RFC3501IMAPv4 March 2003
For example, here is a mailbox name which mixes English,
Chinese, and Japanese text:
~peter/mail/&U,BTFw-/&ZeVnLIqe-
例えば、ここに、英語、中国語、および和文を混ぜるメールボックス名があります: ~peter/mail/、u、BTFw/、およびZeVnLIqe、-
For example, the string "&Jjo!" is not a valid mailbox
name because it does not contain a shift to US-ASCII
before the "!". The correct form is "&Jjo-!". The
string "&U,BTFw-&ZeVnLIqe-" is not permitted because it
contains a superfluous shift. The correct form is
"&U,BTF2XlZyyKng-".
“!"の前に米国-ASCIIにシフトを含んでいないので、「」 例えば、ストリングJjo!」は妥当なメールボックス名ではありません。 「訂正用紙はそうです」とJjo、-、」 「ストリング」とU、BTFw、-、ZeVnLIqe、-、」 余計なシフトを含んでいるので、受入れられません。 「訂正用紙は」 U、BTF2XlZyyKngです。」
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 message delivery), change the flags of the messages in the mailbox (e.g., simultaneous access to the same mailbox by multiple agents), or even remove messages from the mailbox. A server MUST send mailbox size updates automatically if a mailbox size change is observed during the processing of a command. A server SHOULD send message flag updates automatically, without requiring the client to request such updates explicitly.
いつでも、サーバはクライアントが要求しなかったデータを送ることができます。 時々、そのような振舞いはREQUIREDです。 例えば、サーバ以外のエージェントは、メールボックス(例えば、新しいメッセージ配送)にメッセージを加えるか、メールボックス(例えば、複数のエージェントによる同じメールボックスへの同時アクセス)の中にメッセージの旗を変えるか、またはメールボックスからメッセージを取り除きさえするかもしれません。 メールボックスサイズ変化がコマンドの処理の間、観測されるなら、サーバは自動的にメールボックスサイズアップデートを送らなければなりません。 クライアントが明らかにそのようなアップデートを要求する必要でないSHOULDが自動的にメッセージ旗の最新版を送るサーバ。
Special rules exist for server notification of a client about the removal of messages to prevent synchronization errors; see the description of the EXPUNGE response for more detail. In particular, it is NOT permitted to send an EXISTS response that would reduce the number of messages in the mailbox; only the EXPUNGE response can do this.
特別な規則はクライアントのサーバ通知のために同期誤りを防ぐメッセージの取り外しに関して存在しています。 その他の詳細のためのEXPUNGE応答の記述を見てください。 特に、メールボックスの中のメッセージの数を減少させるEXISTS応答を送ることは許可されていません。 EXPUNGE応答だけがこれができます。
Regardless of what implementation decisions a client makes on remembering data from the server, a client implementation MUST record mailbox size updates. It MUST NOT assume that any command after the initial mailbox selection will return the size of the mailbox.
クライアントがサーバからデータを覚えているときするすべての実装決定にかかわらず、クライアント実装はメールボックスサイズアップデートを記録しなければなりません。 それは、初期のメールボックス選択の後のどんなコマンドもメールボックスのサイズを返すと仮定してはいけません。
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 Standards Track [Page 21] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[21ページ]RFC3501IMAPv4 March 2003
5.4. Autologout Timer
5.4. 自動ログアウト・タイマー
If a server has an inactivity autologout timer, the duration of that timer MUST be at least 30 minutes. The receipt of ANY command from the client during that interval SHOULD suffice to reset the autologout timer.
サーバに不活発自動ログアウト・タイマーがあるなら、そのタイマの持続時間は少なくとも30分でなければなりません。 SHOULDが自動ログアウト・タイマーをリセットするために満足させるその間隔の間のクライアントからのどんなコマンドの領収書。
5.5. Multiple Commands in Progress
5.5. 進行中の複数のコマンド
The client MAY send another command without waiting for the completion result response of a command, subject to ambiguity rules (see below) and flow control constraints on the underlying data stream. Similarly, a server MAY begin processing another command before processing the current command to completion, subject to ambiguity rules. However, any command continuation request responses and command continuations MUST be negotiated before any subsequent command is initiated.
基本的なデータ・ストリームのときにあいまいさ規則(以下を見る)とフロー制御規制を条件としてコマンドの完成結果応答を待たないで、クライアントは別のコマンドを送るかもしれません。 同様に、サーバは、あいまいさ規則を条件として現在のコマンドを完成に処理する前に別のコマンドを処理し始めるかもしれません。 しかしながら、どんなその後のコマンドも開始される前にどんなコマンド継続要求応答とコマンド続刊も交渉しなければなりません。
The exception is if an ambiguity would result because of a command that would affect the results of other commands. Clients MUST NOT send multiple commands without waiting if an ambiguity would result. If the server detects a possible ambiguity, it MUST execute commands to completion in the order given by the client.
例外はあいまいさが他のコマンドの結果に影響するコマンドで結果として生じるだろうかどうかということです。 あいまいさが結果として生じるなら待たないで、クライアントは複数のコマンドを送ってはいけません。 サーバが可能なあいまいさを検出するなら、それはクライアントによって与えられたオーダーにおける完成にコマンドを実行しなければなりません。
The most obvious example of ambiguity is when a command would affect the results of another command, e.g., a FETCH of a message's flags and a STORE of that same message's flags.
あいまいさの最も明白な例はコマンドが別のコマンド、例えば、メッセージの旗のFETCHの結果とその同じメッセージの旗のストアに影響する時です。
A non-obvious ambiguity occurs with commands that permit an untagged EXPUNGE response (commands other than FETCH, STORE, and SEARCH), since an untagged EXPUNGE response can invalidate sequence numbers in a subsequent command. This is not a problem for FETCH, STORE, or SEARCH commands because servers are prohibited from sending EXPUNGE responses while any of those commands are in progress. Therefore, if the client sends any command other than FETCH, STORE, or SEARCH, it MUST wait for the completion result response before sending a command with message sequence numbers.
非明白なあいまいさはuntagged EXPUNGE応答(FETCH、ストア、および検索以外のコマンド)を可能にするコマンドで起こります、untagged EXPUNGE応答がその後のコマンドにおける一連番号を無効にすることができるので。 それらのコマンドのどれかが進行している間、サーバが送付EXPUNGE応答から禁じられるので、これはFETCH、ストア、または検索命令のための問題ではありません。 したがって、クライアントが何かFETCH、ストア、または検索以外のコマンドを送るなら、コマンドを送る前に、それはメッセージ通番で完成結果応答を待たなければなりません。
Note: UID FETCH, UID STORE, and UID SEARCH are different
commands from FETCH, STORE, and SEARCH. If the client
sends a UID command, it must wait for a completion result
response before sending a command with message sequence
numbers.
以下に注意してください。 UID FETCH、UID STORE、およびUID SEARCHはFETCH、ストア、および検索からの異なったコマンドです。 クライアントがUIDコマンドを送るなら、コマンドを送る前に、それはメッセージ通番で完成結果応答を待たなければなりません。
Crispin Standards Track [Page 22] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[22ページ]RFC3501IMAPv4 March 2003
For example, the following non-waiting command sequences are invalid:
例えば、以下の非の待ちコマンド・シーケンスは無効です:
FETCH + NOOP + STORE
STORE + COPY + FETCH
COPY + COPY
CHECK + FETCH
フェッチ+NOOP+店店+コピー+フェッチコピー+コピーチェック+フェッチ
The following are examples of valid non-waiting command sequences:
↓これは有効な非の待ちコマンド・シーケンスに関する例です:
FETCH + STORE + SEARCH + CHECK
STORE + COPY + EXPUNGE
+が梢消する店+コピーをとって来るか、保存する、捜す、またはチェックしてください。
UID SEARCH + UID SEARCH may be valid or invalid as a non-waiting
command sequence, depending upon whether or not the second UID
SEARCH contains message sequence numbers.
UID SEARCH+UID SEARCHは非の待ちコマンド・シーケンスとして有効であるか、または無効であるかもしれません、第2UID SEARCHがメッセージ通番を含んでいるかどうかによって。
6. Client Commands
6. クライアントコマンド
IMAP4rev1 commands are described in this section. Commands are organized by the state in which the command is permitted. Commands which are permitted in multiple states are listed in the minimum permitted state (for example, commands valid in authenticated and selected state are listed in the authenticated state commands).
IMAP4rev1コマンドはこのセクションで説明されます。 コマンドはコマンドが受入れられる州によって組織化されます。 複数の州で受入れられるコマンドは状態に受入れられた最小限で記載されています(例えば、認証されて選択された状態で有効なコマンドは認証された州のコマンドで記載されています)。
Command arguments, identified by "Arguments:" in the command descriptions below, are described by function, not by syntax. The precise syntax of command arguments is described in the Formal Syntax section.
特定された議論を命令してください、「議論:」 中、記述下を命令して、構文によって説明されるのではなく、機能によって説明されます。 コマンド議論の正確な構文はFormal Syntax部で説明されます。
Some commands cause specific server responses to be returned; these are identified by "Responses:" in the command descriptions below. See the response descriptions in the Responses section for information on these responses, and the Formal Syntax section for the precise syntax of these responses. It is possible for server data to be transmitted as a result of any command. Thus, commands that do not specifically require server data specify "no specific responses for this command" instead of "none".
いくつかのコマンドで、特定のサーバ応答を返します。 これらが特定される、「応答:」 以下でのコマンド記述で。 これらの応答の情報のための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.
「なってください」 コマンド記述では、コマンドへの可能なタグ付けをされた状態応答、およびこれらの状態応答のどんな特別な解釈も示します。
The state of a connection is only changed by successful commands which are documented as changing state. A rejected command (BAD response) never changes the state of the connection or of the selected mailbox. A failed command (NO response) generally does not change the state of the connection or of the selected mailbox; the exception being the SELECT and EXAMINE commands.
状態を変えるとして記録されるうまくいっているコマンドで接続の状態を変えるだけです。 拒絶されたコマンド(BAD応答)は接続か選択されたメールボックスの状態を決して変えません。 一般に、失敗したコマンド(応答がない)は接続か選択されたメールボックスの状態を変えません。 SELECTとEXAMINEである例外は命令します。
Crispin Standards Track [Page 23] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[23ページ]RFC3501IMAPv4 March 2003
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
議論: なし
Responses: REQUIRED untagged response: CAPABILITY
応答: REQUIRED untagged応答: 能力
Result: OK - capability completed
BAD - command unknown or arguments invalid
結果: OK--能力はBADを完成しました--未知か議論病人を命令してください。
The CAPABILITY command requests a listing of capabilities that the
server supports. The server MUST send a single untagged
CAPABILITY response with "IMAP4rev1" as one of the listed
capabilities before the (tagged) OK response.
CAPABILITYコマンドはサーバがサポートする能力のリストを要求します。 サーバは「(タグ付けされる)のOK応答の前の記載された能力の1つとしてのIMAP4rev1"」とのただ一つのuntagged CAPABILITY応答を送らなければなりません。
A capability name which begins with "AUTH=" indicates that the
server supports that particular authentication mechanism. All
such names are, by definition, part of this specification. For
example, the authorization capability for an experimental
"blurdybloop" authenticator would be "AUTH=XBLURDYBLOOP" and not
"XAUTH=BLURDYBLOOP" or "XAUTH=XBLURDYBLOOP".
「AUTH=」と共に始まる能力名は、サーバが、それが特定の認証機構であるとサポートするのを示します。 そのようなすべての名前が定義上この仕様の一部です。 例えば、実験"blurdybloop"固有識別文字のための承認能力は"XAUTH=BLURDYBLOOP"か"XAUTH=XBLURDYBLOOP"ではなく"AUTH=XBLURDYBLOOP"でしょう。
Other capability names refer to extensions, revisions, or
amendments to this specification. See the documentation of the
CAPABILITY response for additional information. No capabilities,
beyond the base IMAP4rev1 set defined in this specification, are
enabled without explicit client action to invoke the capability.
他の能力名はこの仕様の拡大、改正、または改正について言及します。 追加情報のためのCAPABILITY応答のドキュメンテーションを見てください。 能力は全く能力を呼び出す明白なクライアント動作なしでこの仕様に基づき定義されたベースIMAP4rev1セットを超えたところまで可能にされません。
Client and server implementations MUST implement the STARTTLS,
LOGINDISABLED, and AUTH=PLAIN (described in [IMAP-TLS])
capabilities. See the Security Considerations section for
important information.
クライアントとサーバ実装はSTARTTLS、LOGINDISABLED、およびAUTH=PLAIN([IMAP-TLS]では、説明される)に能力を実装しなければなりません。 重要情報に関してSecurity Considerations部を見てください。
See the section entitled "Client Commands -
Experimental/Expansion" for information about the form of site or
implementation-specific capabilities.
セクションがサイトか実装特有のフォームの情報に関する「クライアントは命令します--実験的な/拡張」という能力の権利を与えられるのを見てください。
Crispin Standards Track [Page 24] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[24ページ]RFC3501IMAPv4 March 2003
Example: C: abcd CAPABILITY
S: * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI
LOGINDISABLED
S: abcd OK CAPABILITY completed
C: efgh STARTTLS
S: efgh OK STARTLS completed
<TLS negotiation, further commands are under [TLS] layer>
C: ijkl CAPABILITY
S: * CAPABILITY IMAP4rev1 AUTH=GSSAPI AUTH=PLAIN
S: ijkl OK CAPABILITY completed
例: C: abcd CAPABILITY S: * 能力IMAP4rev1 STARTTLS AUTH=GSSAPI LOGINDISABLED S: abcd OK CAPABILITYはCを完成しました: efgh STARTTLS S: efgh OK STARTLSは<TLS交渉を終了して、[TLS]層の>Cの下にさらなるコマンドがあります: ijkl CAPABILITY S: * 能力IMAP4rev1 AUTH=GSSAPI AUTHは平野Sと等しいです: OK CAPABILITYが完成したijkl
6.1.2. NOOP Command
6.1.2. NOOPコマンド
Arguments: none
議論: なし
Responses: no specific responses for this command (but see below)
応答: このコマンドのための特定の応答がありません。(以下を見てください)
Result: OK - noop completed
BAD - command unknown or arguments invalid
結果: OK--noopはBADを完成しました--未知か議論病人を命令してください。
The NOOP command always succeeds. It does nothing.
NOOPコマンドはいつも成功します。 それは何もしません。
Since any command can return a status update as untagged data, the
NOOP command can be used as a periodic poll for new messages or
message status updates during a period of inactivity (this is the
preferred method to do this). The NOOP command can also be used
to reset any inactivity autologout timer on the server.
どんなコマンドも非タグ付けをされたデータとして状態アップデートを返すことができるので、新しいメッセージかメッセージ状態最新版に不活発の期間、周期的な投票としてNOOPコマンドを使用できます(これはこれをする適した方法です)。 また、サーバのどんな不活発自動ログアウト・タイマーもリセットするのにNOOPコマンドを使用できます。
Example: C: a002 NOOP
S: a002 OK NOOP completed
. . .
C: a047 NOOP
S: * 22 EXPUNGE
S: * 23 EXISTS
S: * 3 RECENT
S: * 14 FETCH (FLAGS (\Seen \Deleted))
S: a047 OK NOOP completed
例: C: a002 NOOP S: a002OK NOOPは…Cを完成しました: a047 NOOP S: * 22 Sを梢消してください: * 23が存在している、S: * 3、最近のS: * 14は(旗(目にふれている\が削除した\))にSをとって来ます: OK NOOPが完成したa047
Crispin Standards Track [Page 25] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[25ページ]RFC3501IMAPv4 March 2003
6.1.3. LOGOUT Command
6.1.3. ログアウトコマンド
Arguments: none
議論: なし
Responses: REQUIRED untagged response: BYE
応答: REQUIRED untagged応答: さようなら
Result: OK - logout completed
BAD - command unknown or arguments invalid
結果: OK--ログアウトするのはBADを完成しました--未知か議論病人を命令してください。
The LOGOUT command informs the server that the client is done with
the connection. The server MUST send a BYE untagged response
before the (tagged) OK response, and then close the network
connection.
LOGOUTコマンドは、クライアントが接続を終えていることをサーバに知らせます。 サーバは、(タグ付けされる)のOK応答の前にBYE untagged応答を送って、次に、ネットワーク接続を終えなければなりません。
Example: C: A023 LOGOUT
S: * BYE IMAP4rev1 Server logging out
S: A023 OK LOGOUT completed
(Server and client then close the connection)
例: C: A023がログアウトする、S: * SをログアウトするBYE IMAP4rev1 Server: 完成したA023 OK LOGOUT(次に、サーバとクライアントは接続を終えます)
6.2. Client Commands - Not Authenticated State
6.2. クライアントは命令します--状態を認証しません。
In the not authenticated state, the AUTHENTICATE or LOGIN command establishes authentication and enters the authenticated state. The AUTHENTICATE command provides a general mechanism for a variety of authentication techniques, privacy protection, and integrity checking; whereas the LOGIN command uses a traditional user name and plaintext password pair and has no means of establishing privacy protection or integrity checking.
認証されなかった状態では、AUTHENTICATEかLOGINコマンドが、認証を確立して、認証された状態に入れます。 AUTHENTICATEコマンドはさまざまな認証のテクニック、プライバシー保護、および保全の照合に一般的機構を提供します。 LOGINコマンドは、伝統的なユーザ名と平文パスワード組を使用して、プライバシー保護か保全の照合を確立する手段を全く持っていませんが。
The STARTTLS command is an alternate form of establishing session privacy protection and integrity checking, but does not establish authentication or enter the authenticated state.
STARTTLSコマンドは代替のフォームについてセッションプライバシー保護と保全の照合を確立します、認証を確立しないか、または認証された状態に入れませんが。
Server implementations MAY allow access to certain mailboxes without establishing authentication. This can be done by means of the ANONYMOUS [SASL] authenticator described in [ANONYMOUS]. An older convention is a LOGIN command using the userid "anonymous"; in this case, a password is required although the server may choose to accept any password. The restrictions placed on anonymous users are implementation-dependent.
認証を確立しないで、サーバ実装はあるメールボックスへのアクセスを許すかもしれません。 [更生会]で説明された更生会[SASL]固有識別文字によってこれができます。 より古いコンベンションはユーザID「匿名」を使用するLOGINコマンドです。 この場合、サーバは、どんなパスワードも受け入れるのを選ぶかもしれませんが、パスワードが必要です。 匿名のユーザに関して課される制限は実装依存しています。
Once authenticated (including as anonymous), it is not possible to re-enter not authenticated state.
いったん認証されると(匿名として、含んでいます)、再入するのが状態を認証しなかったのは、可能ではありません。
Crispin Standards Track [Page 26] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[26ページ]RFC3501IMAPv4 March 2003
In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT), the following commands are valid in the not authenticated state: STARTTLS, AUTHENTICATE and LOGIN. See the Security Considerations section for important information about these commands.
普遍的なコマンド(CAPABILITY、NOOP、およびLOGOUT)に加えて、以下のコマンドは認証されなかった状態で有効です: STARTTLS、認証、そして、ログイン。 これらのコマンドに関する重要情報に関してSecurity Considerations部を見てください。
6.2.1. STARTTLS Command
6.2.1. STARTTLSコマンド
Arguments: none
議論: なし
Responses: no specific response for this command
応答: このコマンドのための特定の応答がありません。
Result: OK - starttls completed, begin TLS negotiation
BAD - command unknown or arguments invalid
結果: OK--starttlsが完成して、TLS交渉BADを始めてください--未知か議論病人を命令してください。
A [TLS] negotiation begins immediately after the CRLF at the end
of the tagged OK response from the server. Once a client issues a
STARTTLS command, it MUST NOT issue further commands until a
server response is seen and the [TLS] negotiation is complete.
[TLS]交渉はCRLF直後タグ付けをされたOK応答の終わりにサーバから始まります。クライアントがいったんSTARTTLSコマンドを発行すると、サーバ応答が見られて、[TLS]交渉が終了するまで、それはさらなるコマンドを発行してはいけません。
The server remains in the non-authenticated state, even if client
credentials are supplied during the [TLS] negotiation. This does
not preclude an authentication mechanism such as EXTERNAL (defined
in [SASL]) from using client identity determined by the [TLS]
negotiation.
[TLS]交渉の間、クライアント資格証明書を供給しても、サーバは非認証された州に残っています。 これは、[TLS]交渉で決定しているクライアントのアイデンティティを使用するので、EXTERNALなどの認証機構([SASL]では、定義される)を排除しません。
Once [TLS] has been started, the client MUST discard cached
information about server capabilities and SHOULD re-issue the
CAPABILITY command. This is necessary to protect against man-in-
the-middle attacks which alter the capabilities list prior to
STARTTLS. The server MAY advertise different capabilities after
STARTTLS.
[TLS]がいったん始められると、クライアントはサーバ能力のキャッシュされた情報を捨てなければなりません、そして、SHOULDはCAPABILITYコマンドを再発行します。 これが中の男性から守るのに必要である、-、-、中央、能力を変更する攻撃がSTARTTLSの前に記載します。 サーバはSTARTTLSの後に異なった能力の広告を出すかもしれません。
Example: C: a001 CAPABILITY
S: * CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED
S: a001 OK CAPABILITY completed
C: a002 STARTTLS
S: a002 OK Begin TLS negotiation now
<TLS negotiation, further commands are under [TLS] layer>
C: a003 CAPABILITY
S: * CAPABILITY IMAP4rev1 AUTH=PLAIN
S: a003 OK CAPABILITY completed
C: a004 LOGIN joe password
S: a004 OK LOGIN completed
例: C: a001 CAPABILITY S: * 能力IMAP4rev1 STARTTLS LOGINDISABLED S: a001OK CAPABILITYはCを完成しました: a002 STARTTLS S: a002は現在、Begin TLS交渉を承認します。[TLS]層の>Cの下に<TLS交渉、より遠いコマンドがあります: a003 CAPABILITY S: * 能力IMAP4rev1 AUTHは平野Sと等しいです: a003OK CAPABILITYはCを完成しました: a004 LOGIN joeパスワードS: OK LOGINが完成したa004
Crispin Standards Track [Page 27] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[27ページ]RFC3501IMAPv4 March 2003
6.2.2. AUTHENTICATE Command
6.2.2. 認証コマンド
Arguments: authentication mechanism name
議論: 認証機構名
Responses: continuation data can be requested
応答: 継続データを要求できます。
Result: OK - authenticate completed, now in authenticated state
NO - authenticate failure: unsupported authentication
mechanism, credentials rejected
BAD - command unknown or arguments invalid,
authentication exchange cancelled
結果: OK--完成して、現在中で認証された州のノーを認証してください--失敗を認証してください: サポートされない認証機構、資格証明書はBADを拒絶しました--コマンド未知か議論病人、認証交換が中止されました。
The AUTHENTICATE command indicates a [SASL] authentication
mechanism to the server. If the server supports the requested
authentication mechanism, it performs an authentication protocol
exchange to authenticate and identify the client. It MAY also
negotiate an OPTIONAL security layer for subsequent protocol
interactions. If the requested authentication mechanism is not
supported, the server SHOULD reject the AUTHENTICATE command by
sending a tagged NO response.
AUTHENTICATEコマンドは[SASL]認証機構をサーバに示します。サーバが要求された認証機構をサポートするなら、それは、クライアントを認証して、特定するために認証プロトコル交換を実行します。 また、それはその後のプロトコル相互作用のためにOPTIONALセキュリティ層を交渉するかもしれません。 要求された認証機構がサポートされないなら、サーバSHOULDは、タグ付けをされたいいえ応答を送ることによって、AUTHENTICATEコマンドを拒絶します。
The AUTHENTICATE command does not support the optional "initial
response" feature of [SASL]. Section 5.1 of [SASL] specifies how
to handle an authentication mechanism which uses an initial
response.
AUTHENTICATEコマンドは[SASL]の任意の「初期の応答」の特徴をサポートしません。 [SASL]のセクション5.1は初期の応答を使用する認証機構を扱う方法を指定します。
The service name specified by this protocol's profile of [SASL] is
"imap".
このプロトコルの[SASL]のプロフィールによって指定されたサービス名は"imap"です。
The authentication protocol exchange consists of a series of
server challenges and client responses that are specific to the
authentication mechanism. A server challenge consists of a
command continuation request response with the "+" token followed
by a BASE64 encoded string. The client response consists of a
single line consisting of a BASE64 encoded string. If the client
wishes to cancel an authentication exchange, it issues a line
consisting of a single "*". If the server receives such a
response, it MUST reject the AUTHENTICATE command by sending a
tagged BAD response.
認証プロトコル交換は一連の認証機構に特定のサーバ挑戦とクライアント応答から成ります。 サーバ挑戦は「+」トークンがBASE64によって続かれている応答がストリングをコード化したというコマンド継続要求から成ります。 クライアント応答は、BASE64から成りながら、単線から成ります。ストリングをコード化しました。 クライアントが認証交換を中止したいなら、それは単一の「*」から成る系列を発行します。 サーバがそのような応答を受けるなら、それは、タグ付けをされたBAD応答を送ることによって、AUTHENTICATEコマンドを拒絶しなければなりません。
If a security layer is negotiated through the [SASL]
authentication exchange, it takes effect immediately following the
CRLF that concludes the authentication exchange for the client,
and the CRLF of the tagged OK response for the server.
セキュリティ層が[SASL]認証交換を通して交渉されるなら、すぐにクライアントへの認証交換、およびサーバのためのタグ付けをされたOK応答のCRLFを結論づけるCRLFに続いて、それは効きます。
While client and server implementations MUST implement the
AUTHENTICATE command itself, it is not required to implement any
authentication mechanisms other than the PLAIN mechanism described
クライアントとサーバ実装が、AUTHENTICATEがコマンド自体であると実装しなければならない間、それはPLAINメカニズム以外のどんな認証機構も説明した道具に必要ではありません。
Crispin Standards Track [Page 28] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[28ページ]RFC3501IMAPv4 March 2003
in [IMAP-TLS]. Also, an authentication mechanism is not required
to support any security layers.
[IMAP-TLS]で。 また、認証機構は、どんなセキュリティも層であるとサポートするのに必要ではありません。
Note: a server implementation MUST implement a
configuration in which it does NOT permit any plaintext
password mechanisms, unless either the STARTTLS command
has been negotiated or some other mechanism that
protects the session from password snooping has been
provided. Server sites SHOULD NOT use any configuration
which permits a plaintext password mechanism without
such a protection mechanism against password snooping.
Client and server implementations SHOULD implement
additional [SASL] mechanisms that do not use plaintext
passwords, such the GSSAPI mechanism described in [SASL]
and/or the [DIGEST-MD5] mechanism.
以下に注意してください。 サーバ実装はそれがどんな平文パスワードメカニズムも可能にしない構成を実装しなければなりません、STARTTLSコマンドが交渉されたか、またはパスワード詮索からセッションを保護するある他のメカニズムが提供されていない場合。 サーバサイトSHOULD NOTはパスワード詮索に対してそのような保護メカニズムなしで平文パスワードメカニズムを可能にするどんな構成も使用します。 クライアントとサーバ実装SHOULDは平文パスワードを使用しない追加[SASL]メカニズムを実装します、とそのようなGSSAPIメカニズムは[SASL]、そして/または、[DIGEST-MD5]メカニズムで説明しました。
Servers and clients can support multiple authentication
mechanisms. The server SHOULD list its supported authentication
mechanisms in the response to the CAPABILITY command so that the
client knows which authentication mechanisms to use.
サーバとクライアントは、複数の認証がメカニズムであるとサポートすることができます。サーバSHOULDがCAPABILITYコマンドへの応答でサポートしている認証機構を記載するので、クライアントは、どの認証機構を使用したらよいかを知っています。
A server MAY include a CAPABILITY response code in the tagged OK
response of a successful AUTHENTICATE command in order to send
capabilities automatically. It is unnecessary for a client to
send a separate CAPABILITY command if it recognizes these
automatic capabilities. This should only be done if a security
layer was not negotiated by the AUTHENTICATE command, because the
tagged OK response as part of an AUTHENTICATE command is not
protected by encryption/integrity checking. [SASL] requires the
client to re-issue a CAPABILITY command in this case.
サーバは、自動的に能力を送るためにうまくいっているAUTHENTICATEコマンドのタグ付けをされたOK応答にCAPABILITY応答コードを含むかもしれません。 これらの自動能力を認識するなら、クライアントが別々のCAPABILITYコマンドを送るのは、不要です。 AUTHENTICATEコマンドでセキュリティ層を交渉しない場合にだけ、これをするでしょうに、AUTHENTICATEコマンドの一部としてのタグ付けをされたOK応答が暗号化/保全の照合で保護されないので。 [SASL]は、クライアントがこの場合CAPABILITYコマンドを再発行するのを必要とします。
If an AUTHENTICATE command fails with a NO response, the client
MAY try another authentication mechanism by issuing another
AUTHENTICATE command. It MAY also attempt to authenticate by
using the LOGIN command (see section 6.2.3 for more detail). In
other words, the client MAY request authentication types in
decreasing order of preference, with the LOGIN command as a last
resort.
いいえ応答に応じてAUTHENTICATEコマンドが失敗するなら、クライアントは、別のAUTHENTICATEコマンドを発行することによって、別の認証機構を試すかもしれません。 また、それは、使用するのによるLOGINコマンドを認証するのを試みるかもしれません(その他の詳細に関してセクション6.2.3を見てください)。 言い換えれば、クライアントは、認証が最後の手段としてLOGINコマンドがある減少しているよく使われる順をタイプするよう要求するかもしれません。
The authorization identity passed from the client to the server
during the authentication exchange is interpreted by the server as
the user name whose privileges the client is requesting.
認証交換の間にクライアントからサーバまで通過された承認のアイデンティティはクライアントが特権を要求しているユーザ名としてサーバによって解釈されます。
Crispin Standards Track [Page 29] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[29ページ]RFC3501IMAPv4 March 2003
Example: S: * OK IMAP4rev1 Server
C: A001 AUTHENTICATE GSSAPI
S: +
C: YIIB+wYJKoZIhvcSAQICAQBuggHqMIIB5qADAgEFoQMCAQ6iBw
MFACAAAACjggEmYYIBIjCCAR6gAwIBBaESGxB1Lndhc2hpbmd0
b24uZWR1oi0wK6ADAgEDoSQwIhsEaW1hcBsac2hpdmFtcy5jYW
Mud2FzaGluZ3Rvbi5lZHWjgdMwgdCgAwIBAaEDAgEDooHDBIHA
cS1GSa5b+fXnPZNmXB9SjL8Ollj2SKyb+3S0iXMljen/jNkpJX
AleKTz6BQPzj8duz8EtoOuNfKgweViyn/9B9bccy1uuAE2HI0y
C/PHXNNU9ZrBziJ8Lm0tTNc98kUpjXnHZhsMcz5Mx2GR6dGknb
I0iaGcRerMUsWOuBmKKKRmVMMdR9T3EZdpqsBd7jZCNMWotjhi
vd5zovQlFqQ2Wjc2+y46vKP/iXxWIuQJuDiisyXF0Y8+5GTpAL
pHDc1/pIGmMIGjoAMCAQGigZsEgZg2on5mSuxoDHEA1w9bcW9n
FdFxDKpdrQhVGVRDIzcCMCTzvUboqb5KjY1NJKJsfjRQiBYBdE
NKfzK+g5DlV8nrw81uOcP8NOQCLR5XkoMHC0Dr/80ziQzbNqhx
O6652Npft0LQwJvenwDI13YxpwOdMXzkWZN/XrEqOWp6GCgXTB
vCyLWLlWnbaUkZdEYbKHBPjd8t/1x5Yg==
S: + YGgGCSqGSIb3EgECAgIAb1kwV6ADAgEFoQMCAQ+iSzBJoAMC
AQGiQgRAtHTEuOP2BXb9sBYFR4SJlDZxmg39IxmRBOhXRKdDA0
uHTCOT9Bq3OsUTXUlk0CsFLoa8j+gvGDlgHuqzWHPSQg==
C:
S: + YDMGCSqGSIb3EgECAgIBAAD/////6jcyG4GE3KkTzBeBiVHe
ceP2CWY0SR0fAQAgAAQEBAQ=
C: YDMGCSqGSIb3EgECAgIBAAD/////3LQBHXTpFfZgrejpLlLImP
wkhbfa2QteAQAgAG1yYwE=
S: A001 OK GSSAPI authentication successful
例: S: * IMAP4rev1サーバCを承認してください: A001はGSSAPI Sを認証します: + C: YIIB+wYJKoZIhvcSAQICAQBuggHqMIIB5qADAgEFoQMCAQ6iBw MFACAAAACjggEmYYIBIjCCAR6gAwIBBaESGxB1Lndhc2hpbmd0 b24uZWR1oi0wK6ADAgEDoSQwIhsEaW1hcBsac2hpdmFtcy5jYW Mud2FzaGluZ3Rvbi5lZHWjgdMwgdCgAwIBAaEDAgEDooHDBIHA cS1GSa5b+fXnPZNmXB9SjL8Ollj2SKyb+3S0iXMljen/jNkpJX AleKTz6BQPzj8duz8EtoOuNfKgweViyn/9B9bccy1uuAE2HI0y C/PHXNNU9ZrBziJ8Lm0tTNc98kUpjXnHZhsMcz5Mx2GR6dGknb; + YGgGCSqGSIb3EgECAgIAb1kwV6ADAgEFoQMCAQ+iSzBJoAMC AQGiQgRAtHTEuOP2BXb9sBYFR4SJlDZxmg39IxmRBOhXRKdDA0 uHTCOT9Bq3OsUTXUlk0CsFLoa8j+gvGDlgHuqzWHPSQg=C: S: + YDMGCSqGSIb3EgECAgIBAAD/////6jcyG4GE3KkTzBeBiVHe ceP2CWY0SR0fAQAgAAQEBAQ= C: YDMGCSqGSIb3EgECAgIBAAD/////3LQBHXTpFfZgrejpLlLImP wkhbfa2QteAQAgAG1yYwE= S: A001 OK GSSAPI認証うまくいきます。
Note: The line breaks within server challenges and client
responses are for editorial clarity and are not in real
authenticators.
以下に注意してください。 サーバ挑戦とクライアント応答の中のラインブレイクは、編集の明快ためにあって、本当の固有識別文字にはありません。
6.2.3. LOGIN Command
6.2.3. ログインコマンド
Arguments: user name
password
議論: ユーザ名前パスワード
Responses: no specific responses for this command
応答: このコマンドのための特定の応答がありません。
Result: OK - login completed, now in authenticated state
NO - login failure: user name or password rejected
BAD - command unknown or arguments invalid
結果: OK--さあ、認証された状態でいいえ--ログイン失敗ログインが終了して、: ユーザ名かパスワードがBADを拒絶しました--未知か議論病人を命令してください。
The LOGIN command identifies the client to the server and carries
the plaintext password authenticating this user.
LOGINコマンドは、サーバにクライアントを特定して、このユーザを認証しながら、平文パスワードを運びます。
Crispin Standards Track [Page 30] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[30ページ]RFC3501IMAPv4 March 2003
A server MAY include a CAPABILITY response code in the tagged OK
response to a successful LOGIN command in order to send
capabilities automatically. It is unnecessary for a client to
send a separate CAPABILITY command if it recognizes these
automatic capabilities.
サーバは、自動的に能力を送るためにうまくいっているLOGINコマンドへのタグ付けをされたOK応答にCAPABILITY応答コードを含むかもしれません。 これらの自動能力を認識するなら、クライアントが別々のCAPABILITYコマンドを送るのは、不要です。
Example: C: a001 LOGIN SMITH SESAME
S: a001 OK LOGIN completed
例: C: a001 LOGIN SMITH SESAME S: OK LOGINが完成したa001
Note: Use of the LOGIN command over an insecure network
(such as the Internet) is a security risk, because anyone
monitoring network traffic can obtain plaintext passwords.
The LOGIN command SHOULD NOT be used except as a last
resort, and it is recommended that client implementations
have a means to disable any automatic use of the LOGIN
command.
以下に注意してください。 不安定なネットワーク(インターネットなどの)の上のLOGINコマンドの使用はセキュリティリスクです、ネットワークトラフィックをモニターしているだれでも平文パスワードを得ることができるので。 LOGINは、最後の手段としてを除いて、SHOULD NOTが使用されると命令します、そして、クライアント実装にはLOGINコマンドのどんな自動使用も無効にする手段があるのは、お勧めです。
Unless either the STARTTLS command has been negotiated or
some other mechanism that protects the session from
password snooping has been provided, a server
implementation MUST implement a configuration in which it
advertises the LOGINDISABLED capability and does NOT permit
the LOGIN command. Server sites SHOULD NOT use any
configuration which permits the LOGIN command without such
a protection mechanism against password snooping. A client
implementation MUST NOT send a LOGIN command if the
LOGINDISABLED capability is advertised.
STARTTLSコマンドが交渉されたか、またはパスワード詮索からセッションを保護するある他のメカニズムが提供されていない場合、サーバ実装は、それが広告を出す構成にLOGINDISABLED能力を実装しなければならなくて、コマンドをLOGINに可能にしません。 サーバサイトSHOULD NOTはパスワード詮索に対してそのような保護メカニズムなしでLOGINコマンドを可能にするどんな構成も使用します。 LOGINDISABLED能力が広告に掲載されるなら、クライアント実装はLOGINコマンドを送ってはいけません。
6.3. Client Commands - Authenticated State
6.3. クライアントコマンド--認証された状態
In the authenticated state, commands that manipulate mailboxes as atomic entities are permitted. Of these commands, the SELECT and EXAMINE commands will select a mailbox for access and enter the selected state.
認証された状態では、原子実体としてメールボックスを操作するコマンドが受入れられます。 これらのコマンドでは、SELECTとEXAMINEコマンドは、アクセスのためにメールボックスを選択して、選択された状態に入れるでしょう。
In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT), the following commands are valid in the authenticated state: SELECT, EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, STATUS, and APPEND.
普遍的なコマンド(CAPABILITY、NOOP、およびLOGOUT)に加えて、以下のコマンドは認証された状態で有効です: そして、選ぶ、審査、作成、削除、改名、登録、登録削除、リスト、LSUB、状態、追加します。
Crispin Standards Track [Page 31] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[31ページ]RFC3501IMAPv4 March 2003
6.3.1. SELECT Command
6.3.1. 選択コマンド
Arguments: mailbox name
議論: メールボックス名
Responses: REQUIRED untagged responses: FLAGS, EXISTS, RECENT
REQUIRED OK untagged responses: UNSEEN, PERMANENTFLAGS,
UIDNEXT, UIDVALIDITY
応答: REQUIRED untagged応答: FLAGS、EXISTS、RECENT REQUIRED OKは応答に非タグ付けをしました: 見えなさ、PERMANENTFLAGS、UIDNEXT、UIDVALIDITY
Result: OK - select completed, now in selected state
NO - select failure, now in authenticated state: no
such mailbox, can't access mailbox
BAD - command unknown or arguments invalid
結果: OK--完成して、現在中で選択された州のノーを選択してください--現在、認証された状態で失敗を選択してください: どんなそのようなメールボックス、もメールボックスBADにアクセスできません--未知か議論病人を命令しないでください。
The SELECT command selects a mailbox so that messages in the
mailbox can be accessed. Before returning an OK to the client,
the server MUST send the following untagged data to the client.
Note that earlier versions of this protocol only required the
FLAGS, EXISTS, and RECENT untagged data; consequently, client
implementations SHOULD implement default behavior for missing data
as discussed with the individual item.
SELECTコマンドは、メールボックスの中のメッセージにアクセスできるようにメールボックスを選択します。 OKをクライアントに返す前に、サーバは以下の非タグ付けをされたデータをクライアントに送らなければなりません。 このプロトコルの以前のバージョンがFLAGS、EXISTS、およびRECENT untaggedデータを必要としただけであることに注意してください。 その結果、クライアント実装SHOULDは、個別品目と議論するようにデフォルトが欠測値のための振舞いであると実装します。
FLAGS Defined flags in the mailbox. See the description
of the FLAGS response for more detail.
FLAGS Definedはメールボックスの中に弛みます。 その他の詳細のためのFLAGS応答の記述を見てください。
<n> EXISTS The number of messages in the mailbox. See the
description of the EXISTS response for more detail.
<n>EXISTS、メールボックスの中のメッセージの数。 その他の詳細のためのEXISTS応答の記述を見てください。
<n> RECENT The number of messages with the \Recent flag set.
See the description of the RECENT response for more
detail.
<n>RECENT、Recentが旗を揚げさせる\があるメッセージの数はセットしました。 その他の詳細のためのRECENT応答の記述を見てください。
OK [UNSEEN <n>]
The message sequence number of the first unseen
message in the mailbox. If this is missing, the
client can not make any assumptions about the first
unseen message in the mailbox, and needs to issue a
SEARCH command if it wants to find it.
メールボックスにおける最初の見えないメッセージの[UNSEEN<n>]メッセージ通番を承認してください。 これがなくなるなら、クライアントは、メールボックスにおける最初の見えないメッセージに関する少しの仮定もすることができないで、それを見つけたいなら、検索命令を発行する必要があります。
OK [PERMANENTFLAGS (<list of flags>)]
A list of message flags that the client can change
permanently. If this is missing, the client should
assume that all flags can be changed permanently.
クライアントが永久に変えることができるメッセージ旗の[PERMANENTFLAGS(旗の>の<リスト)]リストを承認してください。 これがなくなるなら、クライアントは、永久にすべての旗を変えることができると仮定するべきです。
OK [UIDNEXT <n>]
The next unique identifier value. Refer to section
2.3.1.1 for more information. If this is missing,
the client can not make any assumptions about the
next unique identifier value.
次の[UIDNEXT<n>]ユニークな識別子価値を承認してください。 セクション2.3を参照してください。.1 .1 詳しい情報のために。 これがなくなるなら、クライアントは次のユニークな識別子値に関する少しの仮定もすることができません。
Crispin Standards Track [Page 32] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[32ページ]RFC3501IMAPv4 March 2003
OK [UIDVALIDITY <n>]
The unique identifier validity value. Refer to
section 2.3.1.1 for more information. If this is
missing, the server does not support unique
identifiers.
[UIDVALIDITY<n>]ユニークな識別子正当性価値を承認してください。 セクション2.3を参照してください。.1 .1 詳しい情報のために。 これがなくなるなら、サーバはユニークな識別子を支持しません。
Only one mailbox can be selected at a time in a connection;
simultaneous access to multiple mailboxes requires multiple
connections. The SELECT command automatically deselects any
currently selected mailbox before attempting the new selection.
Consequently, if a mailbox is selected and a SELECT command that
fails is attempted, no mailbox is selected.
一度に、接続で1個のメールボックスしか選択できません。 複数のメールボックスへの同時アクセスは複数の接続を必要とします。 SELECTは自動的にいずれも現在新しい選択を試みながらメールボックスを選択したdeselectsを命令します。 その結果、メールボックスが選択されて、失敗するSELECTコマンドが試みられるなら、メールボックスは全く選択されません。
If the client is permitted to modify the mailbox, the server
SHOULD prefix the text of the tagged OK response with the
"[READ-WRITE]" response code.
クライアントがメールボックスを変更することが許可されるなら、サーバSHOULDは「[-読まれて、書いてください]」応答コードでタグ付けをされたOK応答のテキストを前に置きます。
If the client is not permitted to modify the mailbox but is
permitted read access, the mailbox is selected as read-only, and
the server MUST prefix the text of the tagged OK response to
SELECT with the "[READ-ONLY]" response code. Read-only access
through SELECT differs from the EXAMINE command in that certain
read-only mailboxes MAY permit the change of permanent state on a
per-user (as opposed to global) basis. Netnews messages marked in
a server-based .newsrc file are an example of such per-user
permanent state that can be modified with read-only mailboxes.
クライアントがメールボックスを変更することは許可されていませんが、アクセスが読まれて、受入れられるなら、メールボックスは書き込み禁止として選定されます、そして、サーバは「[書き込み禁止]」応答コードで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: * OK [UIDNEXT 4392] Predicted next UID
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
S: A142 OK [READ-WRITE] SELECT completed
例: C: A142は受信トレイSを選択します: * 172が存在している、S: * 1、最近のS: * OK[UNSEEN12]メッセージ12は最初に、見えないSです: * OK[UIDVALIDITY3857529045]のUIDs有効なS: * OK[UIDNEXT4392]は次のUID Sを予測しました: * 旗(\に答えた\は\削除された\見られた\草稿に旗を揚げさせた)のS: * OK[PERMANENTFLAGS(\は\見られた\*を削除した)]はSを制限しました: 完成したA142 OK[READ-WRITE]SELECT
Crispin Standards Track [Page 33] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[33ページ]RFC3501IMAPv4 March 2003
6.3.2. EXAMINE Command
6.3.2. 審査コマンド
Arguments: mailbox name
議論: メールボックス名
Responses: REQUIRED untagged responses: FLAGS, EXISTS, RECENT
REQUIRED OK untagged responses: UNSEEN, PERMANENTFLAGS,
UIDNEXT, UIDVALIDITY
応答: REQUIRED untagged応答: FLAGS、EXISTS、RECENT REQUIRED OKは応答に非タグ付けをしました: 見えなさ、PERMANENTFLAGS、UIDNEXT、UIDVALIDITY
Result: OK - examine completed, now in selected state
NO - examine failure, now in authenticated state: no
such mailbox, can't access mailbox
BAD - command unknown or arguments invalid
結果: OK--完成して、現在中で選択された州のノーを調べてください--現在、認証された状態で失敗を調べてください: どんなそのようなメールボックス、もメールボックスBADにアクセスできません--未知か議論病人を命令しないでください。
The EXAMINE command is identical to SELECT and returns the same
output; however, the selected mailbox is identified as read-only.
No changes to the permanent state of the mailbox, including
per-user state, are permitted; in particular, EXAMINE MUST NOT
cause messages to lose the \Recent flag.
EXAMINEコマンドは、SELECTと同じであり、同じ出力を返します。 しかしながら、選択されたメールボックスは書き込み禁止として特定されます。 1ユーザあたりの状態を含むメールボックスの永久的な状態への変化は全く受入れられません。 特に、\RecentをなくすEXAMINE MUST NOT原因メッセージは弛みます。
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: * OK [UIDNEXT 4392] Predicted next UID
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * OK [PERMANENTFLAGS ()] No permanent flags permitted
S: A932 OK [READ-ONLY] EXAMINE completed
例: C: A932 EXAMINE blurdybloop S: * 17が存在している、S: * 2、最近のS: * OK[UNSEEN8]メッセージ8は最初に、見えないSです: * OK[UIDVALIDITY3857529045]のUIDs有効なS: * OK[UIDNEXT4392]は次のUID Sを予測しました: * 旗(\に答えた\は\削除された\見られた\草稿に旗を揚げさせた)のS: * OKである、[PERMANENTFLAGS()]いいえの永久的な旗はSを可能にしました: 完成したA932 OK[READだけ]EXAMINE
6.3.3. CREATE Command
6.3.3. 作成コマンド
Arguments: mailbox name
議論: メールボックス名
Responses: no specific responses for this command
応答: このコマンドのための特定の応答がありません。
Result: OK - create completed
NO - create failure: can't create mailbox with that name
BAD - command unknown or arguments invalid
結果: 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応答を返します。 実在のメールボックスについて言及するのは、名前で受信トレイかメールボックスを作成するのを試みる誤りです。 創造におけるどんな誤りもタグ付けをされたいいえ応答を返すでしょう。
Crispin Standards Track [Page 34] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[34ページ]RFC3501IMAPv4 March 2003
If the mailbox name is suffixed with the server's hierarchy
separator character (as returned from the server by a LIST
command), this is a declaration that the client intends to create
mailbox names under this name in the hierarchy. Server
implementations that do not require this declaration MUST ignore
the declaration. In any case, the name created is without the
trailing hierarchy delimiter.
メールボックス名がサーバの階層構造分離符キャラクタと共にsuffixedされるなら(サーバからLISTコマンドで返すように)、これはクライアントがこの名前の下でメールボックス名を階層構造で作成するつもりであるという宣言です。 この宣言を必要としないサーバ実現は宣言を無視しなければなりません。 どのような場合でも、作成という名前が引きずっている階層構造デリミタなしであります。
If the server's hierarchy separator character appears elsewhere in
the name, the server SHOULD create any superior hierarchical names
that are needed for the CREATE command to be successfully
completed. In other words, an attempt to create "foo/bar/zap" on
a server in which "/" is the hierarchy separator character SHOULD
create foo/ and foo/bar/ if they do not already exist.
サーバの階層構造分離符キャラクタが名前におけるほかの場所に現れるなら、サーバSHOULDは首尾よく完成するべきCREATEコマンドに必要であるどんな優れた階層的な名前も作成します。 「言い換えれば、作成する試みは中のサーバでどれを「fooするか、禁じる、または急に動く」、/、」、既に存在していないなら、階層構造分離符キャラクタがfooに/とfoo/bar/を作成するべきです。
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
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
議論: メールボックス名
Responses: no specific responses for this command
応答: このコマンドのための特定の応答がありません。
Result: OK - delete completed
NO - delete failure: can't delete mailbox with that name
BAD - command unknown or arguments invalid
結果: OK--完成したノーを削除してください--失敗を削除してください: その名前BADと共にメールボックスを削除できません--未知か議論病人を命令してください。
Crispin Standards Track [Page 35] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[35ページ]RFC3501IMAPv4 March 2003
The DELETE command permanently removes the mailbox with the given
name. A tagged OK response is returned only if the mailbox has
been deleted. It is an error to attempt to delete INBOX or a
mailbox name that does not exist.
DELETEコマンドは永久に、名がいるメールボックスを取り外します。 メールボックスを削除した場合にだけ、タグ付けをされたOK応答を返します。 存在しないのは、受信トレイかメールボックス名を削除するのを試みる誤りです。
The DELETE command MUST NOT remove inferior hierarchical names.
For example, if a mailbox "foo" has an inferior "foo.bar"
(assuming "." is the hierarchy delimiter character), removing
"foo" MUST NOT remove "foo.bar". It is an error to attempt to
delete a name that has inferior hierarchical names and also has
the \Noselect mailbox name attribute (see the description of the
LIST response for more details).
DELETEコマンドは劣った階層的な名前を取り除いてはいけません。 「例えば、"foo"には劣った"foo.bar"がメールボックスであるならある、(仮定、」、」、階層構造デリミタキャラクタ)、"foo"を取り除くと、"foo.bar"は取り除かれてはいけません。 劣った階層的な名前を持っていて、また、属性という\Noselectメールボックス名を持つのは、名前を削除するのを試みる誤り(その他の詳細のためのLIST応答の記述を見る)です。
It is permitted to delete a name that has inferior hierarchical
names and does not have the \Noselect mailbox name attribute. In
this case, all messages in that mailbox are removed, and the name
will acquire the \Noselect mailbox name attribute.
それは、劣った階層的な名前を持っている名前を削除することが許可されていて、属性という\Noselectメールボックス名を持っていません。 この場合、そのメールボックスの中のすべてのメッセージが取り除かれます、そして、名前は属性という\Noselectメールボックス名を習得するでしょう。
The value of the highest-used unique identifier of the deleted
mailbox MUST be preserved so that a new mailbox created with the
same name will not reuse the identifiers of the former
incarnation, UNLESS the new incarnation has a different unique
identifier validity value. See the description of the UID command
for more detail.
新しい肉体化のUNLESSには、削除されたメールボックスの最も高く使用されたユニークな識別子の価値は同じ名前で作成された新しいメールボックスが前の肉体化に関する識別子を再利用しないように、守られなければならなくて、異なったユニークな識別子正当性価値があります。 その他の詳細のためのUIDコマンドの記述を見てください。
Examples: C: A682 LIST "" *
S: * LIST () "/" blurdybloop
S: * LIST (\Noselect) "/" foo
S: * LIST () "/" foo/bar
S: A682 OK LIST completed
C: A683 DELETE blurdybloop
S: A683 OK DELETE completed
C: A684 DELETE foo
S: A684 NO Name "foo" has inferior hierarchical names
C: A685 DELETE foo/bar
S: A685 OK DELETE Completed
C: A686 LIST "" *
S: * LIST (\Noselect) "/" foo
S: A686 OK LIST completed
C: A687 DELETE foo
S: A687 OK DELETE Completed
例: C: A682が記載する、「「*S:」 * 」 「LIST()」/blurdybloop S: * 」 「LIST(\Noselect)」/foo S: * 」 「LIST()」/foo/バーS: A682 OK LISTはCを完成しました: A683 DELETE blurdybloop S: A683 OK DELETEはCを完成しました: A684 DELETE foo S: A684 NO Name"foo"には、劣った階層的な名前Cがあります: A685 DELETE foo/バーS: A685OKは完成したCを削除します: A686が記載する、「「*S:」 * 」 「LIST(\Noselect)」/foo S: A686 OK LISTはCを完成しました: A687 DELETE foo S: 完成されて、A687OKは削除します。
Crispin Standards Track [Page 36] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[36ページ]RFC3501IMAPv4 March 2003
C: A82 LIST "" *
S: * LIST () "." blurdybloop
S: * LIST () "." foo
S: * LIST () "." foo.bar
S: A82 OK LIST completed
C: A83 DELETE blurdybloop
S: A83 OK DELETE completed
C: A84 DELETE foo
S: A84 OK DELETE Completed
C: A85 LIST "" *
S: * LIST () "." foo.bar
S: A85 OK LIST completed
C: A86 LIST "" %
S: * LIST (\Noselect) "." foo
S: A86 OK LIST completed
C: A82が記載する、「「*S:」 * 「LIST()」 」 blurdybloop S: * 「LIST()」 」 foo S: * 「LIST()」 」 foo.bar S: A82 OK LISTはCを完成しました: A83 DELETE blurdybloop S: A83 OK DELETEはCを完成しました: A84 DELETE foo S: A84OKは完成したCを削除します: A85が記載する、「「*S:」 * 「LIST()」 」 foo.bar S: A85 OK LISTはCを完成しました: A86が記載する、「「%S:」 * 「LIST(\Noselect)」 」 foo S: 完成したA86 OK LIST
6.3.5. RENAME Command
6.3.5. 改名コマンド
Arguments: existing mailbox name
new mailbox name
議論: 既存のメールボックス名前新しいメールボックス名
Responses: no specific responses for this command
応答: このコマンドのための特定の応答がありません。
Result: OK - rename completed
NO - rename failure: can't rename mailbox with that name,
can't rename to mailbox with that name
BAD - command unknown or arguments invalid
結果: OK--完成したノーを改名してください--失敗を改名してください: その名前でメールボックスを改名できないで、その名前でBADをメールボックスに改名できません--未知か議論病人を命令してください。
The RENAME command changes the name of a mailbox. A tagged OK
response is returned only if the mailbox has been renamed. It is
an error to attempt to rename from a mailbox name that does not
exist or to a mailbox name that already exists. Any error in
renaming will return a tagged NO response.
RENAMEコマンドはメールボックスの名前を変えます。 メールボックスを改名した場合にだけ、タグ付けをされたOK応答を返します。 それは存在しないメールボックス名から改名する試み、または、既に存在するメールボックス名への誤りです。 改名におけるどんな誤りもタグ付けをされたいいえ応答を返すでしょう。
If the name has inferior hierarchical names, then the inferior
hierarchical names MUST also be renamed. For example, a rename of
"foo" to "zap" will rename "foo/bar" (assuming "/" is the
hierarchy delimiter character) to "zap/bar".
また、名前に劣った階層的な名前があるなら、劣った階層的な名前を改名しなければなりません。 「例えば、aが意志が改名する「活力」への「foo」という「foo/バー」について改名する、(」 /を仮定する、」、階層構造デリミタキャラクタ) 「急に動くか、または禁じる」ために。
If the server's hierarchy separator character appears in the name,
the server SHOULD create any superior hierarchical names that are
needed for the RENAME command to complete successfully. In other
words, an attempt to rename "foo/bar/zap" to baz/rag/zowie on a
server in which "/" is the hierarchy separator character SHOULD
create baz/ and baz/rag/ if they do not already exist.
サーバの階層構造分離符キャラクタが名前に現れるなら、サーバSHOULDは首尾よく終了するRENAMEコマンドに必要であるどんな優れた階層的な名前も作成します。 「言い換えれば、中のサーバでどれをbazするか、ぼろ切れである、またはzowieするように「foo/バー/活力」を改名するか試み」/、」、既に存在していないなら、階層構造分離符キャラクタはbazに/とbaz/rag/を作成するべきです。
Crispin Standards Track [Page 37] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[37ページ]RFC3501IMAPv4 March 2003
The value of the highest-used unique identifier of the old mailbox
name MUST be preserved so that a new mailbox created with the same
name will not reuse the identifiers of the former incarnation,
UNLESS the new incarnation has a different unique identifier
validity value. See the description of the UID command for more
detail.
新しい肉体化のUNLESSには、古いメールボックス名の最も高く使用されたユニークな識別子の価値は同じ名前で作成された新しいメールボックスが前の肉体化に関する識別子を再利用しないように、守られなければならなくて、異なったユニークな識別子正当性価値があります。 その他の詳細のためのUIDコマンドの記述を見てください。
Renaming INBOX is permitted, and has special behavior. It moves
all messages in INBOX to a new mailbox with the given name,
leaving INBOX empty. If the server implementation supports
inferior hierarchical names of INBOX, these are unaffected by a
rename of INBOX.
受信トレイを改名するのは、受入れられて、特別な振舞いを持っています。 受信トレイを空の状態でおいて、それは受信トレイの中に名ですべてのメッセージを新しいメールボックスに動かします。 サーバ実現が受信トレイの劣った階層的な名前をサポートするなら、これらはaで影響を受けないです。受信トレイについて改名します。
Examples: C: A682 LIST "" *
S: * LIST () "/" blurdybloop
S: * LIST (\Noselect) "/" foo
S: * LIST () "/" foo/bar
S: A682 OK LIST completed
C: A683 RENAME blurdybloop sarasoop
S: A683 OK RENAME completed
C: A684 RENAME foo zowie
S: A684 OK RENAME Completed
C: A685 LIST "" *
S: * LIST () "/" sarasoop
S: * LIST (\Noselect) "/" zowie
S: * LIST () "/" zowie/bar
S: A685 OK LIST completed
例: C: A682が記載する、「「*S:」 * 」 「LIST()」/blurdybloop S: * 」 「LIST(\Noselect)」/foo S: * 」 「LIST()」/foo/バーS: A682 OK LISTはCを完成しました: A683 RENAME blurdybloop sarasoop S: A683 OK RENAMEはCを完成しました: A684 RENAME foo zowie S: A684OKは完成したCを改名します: A685が記載する、「「*S:」 * 」 「LIST()」/sarasoop S: * 」 「LIST(\Noselect)」/zowie S: * 」 「LIST()」/zowie/バーS: 完成したA685 OK LIST
C: Z432 LIST "" *
S: * LIST () "." INBOX
S: * LIST () "." INBOX.bar
S: Z432 OK LIST completed
C: Z433 RENAME INBOX old-mail
S: Z433 OK RENAME completed
C: Z434 LIST "" *
S: * LIST () "." INBOX
S: * LIST () "." INBOX.bar
S: * LIST () "." old-mail
S: Z434 OK LIST completed
C: Z432が記載する、「「*S:」 * 「()を記載してください」、」 受信トレイS: * 「()を記載してください」、」 INBOX.bar S: Z432 OK LISTはCを完成しました: Z433 RENAME INBOX古いメールS: Z433 OK RENAMEはCを完成しました: Z434が記載する、「「*S:」 * 「()を記載してください」、」 受信トレイS: * 「()を記載してください」、」 INBOX.bar S: * 「LIST()」 」 古いメールS: 完成したZ434 OK LIST
Crispin Standards Track [Page 38] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[38ページ]RFC3501IMAPv4 March 2003
6.3.6. SUBSCRIBE Command
6.3.6. 申し込みコマンド
Arguments: mailbox
議論: メールボックス
Responses: no specific responses for this command
応答: このコマンドのための特定の応答がありません。
Result: OK - subscribe completed
NO - subscribe failure: can't subscribe to that name
BAD - command unknown or arguments invalid
結果: 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応答を返します。
A server MAY validate the mailbox argument to SUBSCRIBE to verify
that it exists. However, it MUST NOT unilaterally remove an
existing mailbox name from the subscription list even if a mailbox
by that name no longer exists.
サーバがメールボックス議論を有効にするかもしれない、登録、それについて確かめるために、それは存在しています。 しかしながら、その名前のメールボックスがもう存在していなくても、それは株式申込者名簿から既存のメールボックス名を一方的に取り除いてはいけません。
Note: This requirement is because a server site can
choose to routinely remove a mailbox with a well-known
name (e.g., "system-alerts") after its contents expire,
with the intention of recreating it when new contents
are appropriate.
以下に注意してください。 この要件はサーバサイトが、内容が期限が切れた後にきまりきって周知の名前(例えば、「システム警戒」)があるメールボックスを取り外すのを選ぶことができるからです、新しい内容が適切であるときにそれを再作成するという意志で。
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
議論: メールボックス名
Responses: no specific responses for this command
応答: このコマンドのための特定の応答がありません。
Result: OK - unsubscribe completed
NO - unsubscribe failure: can't unsubscribe that name
BAD - command unknown or arguments invalid
結果: 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応答を返します。
Example: C: A002 UNSUBSCRIBE #news.comp.mail.mime
S: A002 OK UNSUBSCRIBE completed
例: C: A002は#news.comp.mail.mime Sを外します: 完成したA002 OK UNSUBSCRIBE
Crispin Standards Track [Page 39] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[39ページ]RFC3501IMAPv4 March 2003
6.3.8. LIST Command
6.3.8. リストコマンド
Arguments: reference name
mailbox name with possible wildcards
議論: 可能なワイルドカードの参照名前メールボックス名
Responses: 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 client. Zero or more untagged LIST
replies are returned, containing the name attributes, hierarchy
delimiter, and name; see the description of the LIST reply for
more detail.
LISTコマンドはクライアントにとって、利用可能なすべての名前の完全なセットから名前の部分集合を返します。 名前属性、階層構造デリミタ、および名前を含んでいて、ゼロか以上が返されますuntagged LISTが、返答する。 その他の詳細のためのLIST回答の記述を見てください。
The LIST command SHOULD return its data quickly, without undue
delay. For example, it SHOULD NOT go to excess trouble to
calculate the \Marked or \Unmarked status or perform other
processing; if each name requires 1 second of processing, then a
list of 1200 names would take 20 minutes!
LISTコマンドSHOULDは不当な遅延なしでデータをすばやく返します。 例えば、それ、SHOULD NOTは\Markedについて計算する余分な問題か\Unmarked状態に行くか、または他の処理を実行します。 各名前が処理の1秒を必要とするなら、1200の名前のリストは20分かかります!
An empty ("" string) reference name argument indicates that the
mailbox name is interpreted as by SELECT. The returned mailbox
names MUST match the supplied mailbox name pattern. A non-empty
reference name argument is the name of a mailbox or a level of
mailbox hierarchy, and indicates the context in which the mailbox
name is interpreted.
ストリング) 参照名前引数は、メールボックス名が解釈されるのを示します。空である、(「「選択する、」 返されたメールボックス名はパターンという供給されたメールボックス名に合わなければなりません。 非空の参照名前引数は、メールボックスの名前かメールボックス階層構造のレベルであり、メールボックス名が解釈される文脈を示します。
An empty ("" string) mailbox name argument is a special request to
return the hierarchy delimiter and the root name of the name given
in the reference. The value returned as the root MAY be the empty
string if the reference is non-rooted or is an empty string. In
all cases, a hierarchy delimiter (or NIL if there is no hierarchy)
is returned. This permits a client to get the hierarchy delimiter
(or find out that the mailbox names are flat) even when no
mailboxes by that name currently exist.
空である、(「「ストリング) メールボックス名前引数は参照で付与という名前の階層構造デリミタと根の名を返すという特別な要求です」。 値は、参照が非根づいているか、空のストリングであるなら根が空のストリングであるかもしれないので、戻りました。 すべての場合では、階層構造デリミタ(そこであるなら、NILは階層構造でない)を返します。 その名前のメールボックスが全く現在存在しないと、これは、クライアントが階層構造デリミタ(メールボックス名が平坦であることを調べる)を得ることを許可します。
The reference and mailbox name arguments are interpreted into a
canonical form that represents an unambiguous left-to-right
hierarchy. The returned mailbox names will be in the interpreted
form.
参照とメールボックス名前引数は左から右への明白な階層構造を表す標準形に解釈されます。 返されたメールボックス名が解釈されたフォームにあるでしょう。
Crispin Standards Track [Page 40] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[40ページ]RFC3501IMAPv4 March 2003
Note: The interpretation of the reference argument is
implementation-defined. It depends upon whether the
server implementation has a concept of the "current
working directory" and leading "break out characters",
which override the current working directory.
以下に注意してください。 参照議論の解釈は実現で定義されています。 それはサーバ実現が、「現在の働くディレクトリ」と先導の概念が「キャラクタを開けること」を持っているかどうかによります(現在の働くディレクトリに優越します)。
For example, on a server which exports a UNIX or NT
filesystem, the reference argument contains the current
working directory, and the mailbox name argument would
contain the name as interpreted in the current working
directory.
例えば、UNIXかNTファイルシステムを輸出するサーバでは参照議論は現在の働くディレクトリを含んでいます、そして、議論というメールボックス名は現在の働くディレクトリで解釈されるように名前を含んでいるでしょう。
If a server implementation has no concept of break out
characters, the canonical form is normally the reference
name appended with the mailbox name. Note that if the
server implements the namespace convention (section
5.1.2), "#" is a break out character and must be treated
as such.
サーバ実現に中断アウトキャラクタの概念が全くないなら、通常、標準形はメールボックス名と共に追加された参照名です。 サーバが名前空間コンベンション(セクション5.1.2)を実行するなら、「#」を中断アウトキャラクタであり、そういうものとして扱わなければならないことに注意してください。
If the reference argument is not a level of mailbox
hierarchy (that is, it is a \NoInferiors name), and/or
the reference argument does not end with the hierarchy
delimiter, it is implementation-dependent how this is
interpreted. For example, a reference of "foo/bar" and
mailbox name of "rag/baz" could be interpreted as
"foo/bar/rag/baz", "foo/barrag/baz", or "foo/rag/baz".
A client SHOULD NOT use such a reference argument except
at the explicit request of the user. A hierarchical
browser MUST NOT make any assumptions about server
interpretation of the reference unless the reference is
a level of mailbox hierarchy AND ends with the hierarchy
delimiter.
参照議論であるなら、メールボックス階層構造がレベルがありません、そして、(すなわち、それは\NoInferiors名です)参照議論は階層構造デリミタで終わりません、そして、これがどのように解釈されるかは、実現依存しています。 例えば、「foo/バー/ぼろ切れ/baz」、「foo/barrag/baz」、または「foo/ぼろ切れ/baz」として「foo/バー」の参照と「ぼろ切れ/baz」のメールボックス名を解釈できました。 ユーザの明白な要求を除いて、SHOULD NOTがそのような参照議論に使用するクライアント。 階層的なブラウザは参照が階層構造デリミタがあるメールボックス階層構造ANDエンドのレベルでないなら参照のサーバ解釈に関する少しの仮定もしてはいけません。
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が解釈されたフォームを前に置くという参照主張のどんな部分。 それ、参照が議論を命名するとき、SHOULDも同じフォームのそうです。 この規則は、クライアントが、返されたメールボックス名が参照議論の文脈にあったか、またはメールボックス議論に関する何かが参照議論をくつがえしたかどうかと決心していることを許可します。 この規則がなければ、クライアントには、命名文脈に優越する「脱走」というサーバが、キャラクタが何であるかを含んでいると意味論を命名することに関する知識がなければならないでしょう。
Crispin Standards Track [Page 41] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[41ページ]RFC3501IMAPv4 March 2003
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"のように変形するか、または「それに注意してください」という~鍛冶屋/は」 SHOULD NOTに郵送します。クライアントが、解釈が参照の文脈にあったと決心しているのは、不可能でしょう。
The character "*" is a wildcard, and matches zero or more
characters at this position. The character "%" is similar to "*",
but it does not match a hierarchy delimiter. If the "%" wildcard
is the last character of a mailbox name argument, matching levels
of hierarchy are also returned. If these levels of hierarchy are
not also selectable mailboxes, they are returned with the
\Noselect mailbox name attribute (see the description of the LIST
response for more details).
キャラクタ「*」は、この位置のワイルドカードと、マッチゼロか、より多くのキャラクタです。 キャラクタ「%」は「*」と同様ですが、それは階層構造デリミタに合っていません。 また、「%」ワイルドカードがメールボックス名前引数の最後のキャラクタであるなら、階層構造の合っているレベルは返されます。 また、階層構造のこれらのレベルが選択可能なメールボックスでないなら、属性という\Noselectメールボックス名と共にそれらを返します(その他の詳細のためのLIST応答の記述を見てください)。
Server implementations are permitted to "hide" otherwise
accessible mailboxes from the wildcard characters, by preventing
certain characters or names from matching a wildcard in certain
situations. For example, a UNIX-based server might restrict the
interpretation of "*" so that an initial "/" character does not
match.
サーバ実現がワイルドカードキャラクタからそうでなければ、アクセスしやすいメールボックスを「隠すこと」が許可されています、確信しているキャラクタか名前が、ある状況でワイルドカードに合っているのを防ぐことによって。 「例えば、したがって、UNIXベースのサーバが「*」の解釈を制限するかもしれない、それ、」 」 キャラクタが合っていない/に頭文字をつけてください。
The special name INBOX is included in the output from LIST, if
INBOX is supported by this server for this user and if the
uppercase string "INBOX" matches the interpreted reference and
mailbox name arguments with wildcards as described above. The
criteria for omitting INBOX is whether SELECT INBOX will return
failure; it is not relevant whether the user's real INBOX resides
on this or some other server.
受信トレイという特別な名前は出力にLISTから含まれています、受信トレイがこのユーザのためにこのサーバによって支持されて、大文字しているストリング「受信トレイ」が上で説明されるように解釈された参照とメールボックス名前引数をワイルドカードに合わせるなら。 受信トレイを省略するのが、SELECT INBOXがそうするかどうかということであるので、評価基準は失敗を返します。 ユーザの実際の受信トレイがこれかある他のサーバに住んでいるか否かに関係なく、それは関連していません。
Crispin Standards Track [Page 42] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[42ページ]RFC3501IMAPv4 March 2003
Example: C: A101 LIST "" ""
S: * LIST (\Noselect) "/" ""
S: A101 OK LIST Completed
C: A102 LIST #news.comp.mail.misc ""
S: * LIST (\Noselect) "." #news.
S: A102 OK LIST Completed
C: A103 LIST /usr/staff/jones ""
S: * LIST (\Noselect) "/" /
S: A103 OK LIST Completed
C: A202 LIST ~/Mail/ %
S: * LIST (\Noselect) "/" ~/Mail/foo
S: * LIST () "/" ~/Mail/meetings
S: A202 OK LIST completed
例: C: A101が記載する、「「「「S:」 * 「」 (\Noselect)/を記載してください」、「「S:」 A101はリストの完成したCを承認します: A102が#news.comp.mail.miscを記載する、「「S:」 * 「(\Noselect)を記載してください」、」 #ニュース。 S: A102はリストの完成したCを承認します: A103が/usr/staff/jonesを記載する、「「S:」 * 「」 (\Noselect)/を記載してください」という/S: A103はリストの完成したCを承認します: A202は~/Mail/%Sを記載します: * 「リスト(\Noselect)」/」 ~/Mail/foo S: * 「リスト()」/」 ~/Mail/meetings S: 完成したA202 OK LIST
6.3.9. LSUB Command
6.3.9. LSUBコマンド
Arguments: reference name
mailbox name with possible wildcards
議論: 可能なワイルドカードの参照名前メールボックス名
Responses: untagged responses: LSUB
応答: 非タグ付けをされた応答: LSUB
Result: OK - lsub completed
NO - lsub failure: can't list that reference or name
BAD - command unknown or arguments invalid
結果: 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のためのそれらと同じフォームにあります。
The returned untagged LSUB response MAY contain different mailbox
flags from a LIST untagged response. If this should happen, the
flags in the untagged LIST are considered more authoritative.
返されたuntagged LSUB応答はLIST untagged応答からの異なったメールボックス旗を含むかもしれません。 これがそうするなら、起こってください、そして、untagged LISTの旗は、より正式であると考えられます。
A special situation occurs when using LSUB with the % wildcard.
Consider what happens if "foo/bar" (with a hierarchy delimiter of
"/") is subscribed but "foo" is not. A "%" wildcard to LSUB must
return foo, not foo/bar, in the LSUB response, and it MUST be
flagged with the \Noselect attribute.
%ワイルドカードがあるLSUBを使用するとき、特別な状況は起こります。 「何が「foo/バー」であるなら起こるか考えてください、(」 /の階層構造デリミタ、」、)、申し込まれますが、「fooに」ありません。 LSUBへの「%」ワイルドカードはLSUB応答でfoo/バーではなく、fooを返さなければなりません、そして、Noselectが結果と考える\でそれに旗を揚げさせなければなりません。
The server MUST NOT unilaterally remove an existing mailbox name
from the subscription list even if a mailbox by that name no
longer exists.
その名前のメールボックスがもう存在していなくても、サーバは株式申込者名簿から既存のメールボックス名を一方的に取り除いてはいけません。
Crispin Standards Track [Page 43] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[43ページ]RFC3501IMAPv4 March 2003
Example: C: A002 LSUB "#news." "comp.mail.*"
S: * LSUB () "." #news.comp.mail.mime
S: * LSUB () "." #news.comp.mail.misc
S: A002 OK LSUB completed
C: A003 LSUB "#news." "comp.%"
S: * LSUB (\NoSelect) "." #news.comp.mail
S: A003 OK LSUB completed
例: C: "A002 LSUB"#ニュース、」 「comp.mail*」、S: * 「LSUB()」、」 #news.comp.mail.mime S: * 「LSUB()」、」 #news.comp.mail.misc S: A002 OK LSUBはCを完成しました: "A003 LSUB"#ニュース、」 「コンピュータ%」、S: * 「LSUB(\NoSelect)」、」 #news.comp.mail S: 完成したA003 OK LSUB
6.3.10. STATUS Command
6.3.10. 状態コマンド
Arguments: mailbox name
status data item names
議論: メールボックス名前状態データ項目名
Responses: untagged responses: STATUS
応答: 非タグ付けをされた応答: 状態
Result: OK - status completed
NO - status failure: no status for that name
BAD - command unknown or arguments invalid
結果: OK--状態完成したノー--状態失敗: その名前BADのための状態がありません--コマンド未知か議論病人
The STATUS command requests the status of the indicated mailbox.
It does not change the currently selected mailbox, nor does it
affect the state of any messages in the queried mailbox (in
particular, STATUS MUST NOT cause messages to lose the \Recent
flag).
STATUSコマンドは示されたメールボックスの状態を要求します。 それは現在選択されたメールボックスを変えません、そして、質問されたメールボックスの中のどんなメッセージの状態にも影響しません(特に、\RecentをなくすSTATUS MUST NOT原因メッセージは弛みます)。
The STATUS command provides an alternative to opening a second
IMAP4rev1 connection and doing an EXAMINE command on a mailbox to
query that mailbox's status without deselecting the current
mailbox in the first IMAP4rev1 connection.
STATUSコマンドは2番目のIMAP4rev1接続を開いて、最初のIMAP4rev1接続で現在のメールボックスを反選択しないでそのメールボックスの状態について質問するメールボックスにおけるEXAMINEコマンドをすることへの代替手段を提供します。
Unlike the LIST command, the STATUS command is not guaranteed to
be fast in its response. Under certain circumstances, it can be
quite slow. In some implementations, the server is obliged to
open the mailbox read-only internally to obtain certain status
information. Also unlike the LIST command, the STATUS command
does not accept wildcards.
LISTコマンドと異なって、STATUSコマンドは、応答で速くなるように保証されません。 ある状況で、それは全く遅い場合があります。 いくつかの実現では、サーバが内部的に、ある状態情報を得るためには読書唯一のメールボックスを開けるのが強いられます。 LISTコマンドと異なっても、STATUSコマンドはワイルドカードを受け入れません。
Note: The STATUS command is intended to access the
status of mailboxes other than the currently selected
mailbox. Because the STATUS command can cause the
mailbox to be opened internally, and because this
information is available by other means on the selected
mailbox, the STATUS command SHOULD NOT be used on the
currently selected mailbox.
以下に注意してください。 STATUSコマンドが現在選択されたメールボックス以外のメールボックスの状態にアクセスすることを意図します。 STATUSコマンドで内部的にメールボックスを開けることができて、この情報が選択されたメールボックスの上の他の手段で利用可能であるので、STATUSは、SHOULD NOTが現在選択されたメールボックスの上に使用されると命令します。
Crispin Standards Track [Page 44] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[44ページ]RFC3501IMAPv4 March 2003
The STATUS command MUST NOT be used as a "check for new
messages in the selected mailbox" operation (refer to
sections 7, 7.3.1, and 7.3.2 for more information about
the proper method for new message checking).
「選択されたメールボックスの中の新しいメッセージのためのチェック」操作としてSTATUSコマンドを使用してはいけません(セクション7、7.3.1を参照して、新しいメッセージのための適切な方法に関する詳しい情報のための.2がチェックして、7.3に参照してください)。
Because the STATUS command is not guaranteed to be fast
in its results, clients SHOULD NOT expect to be able to
issue many consecutive STATUS commands and obtain
reasonable performance.
STATUSコマンドが結果で速くなるように保証されないので、クライアントSHOULD NOTは多くの連続したSTATUSコマンドを発行して、妥当な性能を得ることができると予想します。
The currently defined status data items that can be requested are:
要求できる現在定義された状態データ項目は以下の通りです。
MESSAGES
The number of messages in the mailbox.
MESSAGES、メールボックスの中のメッセージの数。
RECENT
The number of messages with the \Recent flag set.
RECENT、Recentが旗を揚げさせる\があるメッセージの数はセットしました。
UIDNEXT
The next unique identifier value of the mailbox. Refer to
section 2.3.1.1 for more information.
メールボックスの次のUIDNEXTユニークな識別子値。 セクション2.3を参照してください。.1 .1 詳しい情報のために。
UIDVALIDITY
The unique identifier validity value of the mailbox. Refer to
section 2.3.1.1 for more information.
識別子の正当性が評価するメールボックスのユニークなUIDVALIDITY。 セクション2.3を参照してください。.1 .1 詳しい情報のために。
UNSEEN
The number of messages which do not have the \Seen flag set.
UNSEEN、Seenが旗を揚げさせる\を持っていないメッセージの数はセットしました。
Example: C: A042 STATUS blurdybloop (UIDNEXT MESSAGES)
S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292)
S: A042 OK STATUS completed
例: C: A042 STATUS blurdybloop(UIDNEXT MESSAGES)S: * STATUS blurdybloop(MESSAGES231UIDNEXT44292)S: 完成したA042 OK STATUS
Crispin Standards Track [Page 45] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[45ページ]RFC3501IMAPv4 March 2003
6.3.11. APPEND Command
6.3.11. 追加コマンド
Arguments: mailbox name
OPTIONAL flag parenthesized list
OPTIONAL date/time string
message literal
議論: メールボックス名前OPTIONAL旗は文字通りでリストOPTIONAL日付/時間ストリングメッセージをparenthesizedしました。
Responses: no specific responses for this command
応答: このコマンドのための特定の応答がありません。
Result: OK - append completed
NO - append error: can't append to that mailbox, error
in flags or date/time or message text
BAD - command unknown or arguments invalid
結果: OK--完成したノーを追加してください--誤りを追加してください: メールボックス、旗、日付/時間またはメッセージ・テキストBADにおける誤りをそれに追加できません--未知か議論病人を命令してください。
The APPEND command appends the literal argument as a new message
to the end of the specified destination mailbox. This argument
SHOULD be in the format of an [RFC-2822] message. 8-bit
characters are permitted in the message. A server implementation
that is unable to preserve 8-bit data properly MUST be able to
reversibly convert 8-bit APPEND data to 7-bit using a [MIME-IMB]
content transfer encoding.
APPENDコマンドは新しいメッセージとして指定されたあて先メールボックスの端に文字通りの議論を追加します。 この議論SHOULDは[RFC-2822]メッセージの形式においてそうです。 8ビットのキャラクタはメッセージで受入れられます。 適切に8ビットのデータを保存できないサーバ実現はreversiblyに[MIME-IMB]内容を使用する7ビット転送コード化に8ビットのAPPENDデータを変換できなければなりません。
Note: There MAY be exceptions, e.g., draft messages, in
which required [RFC-2822] header lines are omitted in
the message literal argument to APPEND. The full
implications of doing so MUST be understood and
carefully weighed.
以下に注意してください。 例外、例えば草稿メッセージがあるかもしれません。そこでは、必要な[RFC-2822]ヘッダー線がメッセージの文字通りの議論でAPPENDに省略されます。 そうする完全な含意を理解されて、慎重に熟慮しなければなりません。
If a flag parenthesized list is specified, the flags SHOULD be set
in the resulting message; otherwise, the flag list of the
resulting message is set to empty by default. In either case, the
Recent flag is also set.
旗がparenthesizedされたなら、リストは指定されて、旗はSHOULDです。結果として起こるメッセージに設定されてください。 さもなければ、結果として起こるメッセージに関する現役将官名簿がデフォルトで空になるように設定されます。 また、どちらの場合ではも、Recent旗は設定されます。
If a date-time is specified, the internal date SHOULD be set in
the resulting message; otherwise, the internal date of the
resulting message is set to the current date and time by default.
日付-時間が指定されるなら、インターナルは中のセットが結果として起こるメッセージであったならSHOULDとデートします。 さもなければ、結果として起こるメッセージの内部の期日はデフォルトで現在の期日と時間に決められます。
If the append is unsuccessful for any reason, the mailbox MUST be
restored to its state before the APPEND attempt; no partial
appending is permitted.
追加、どんな理由でも失敗していて、APPEND試みの前にメールボックスを状態に返さなければならないということです。 部分的な追加は受入れられません。
If the destination mailbox does not exist, a server MUST return an
error, and MUST NOT automatically create the mailbox. Unless it
is certain that the destination mailbox can not be created, the
server MUST send the response code "[TRYCREATE]" as the prefix of
the text of the tagged NO response. This gives a hint to the
client that it can attempt a CREATE command and retry the APPEND
if the CREATE is successful.
あて先メールボックスが存在していないなら、サーバは、誤りを返さなければならなくて、自動的にメールボックスを作成してはいけません。 あて先メールボックスを作成できないのが確かでない場合、サーバはタグ付けをされたいいえ応答のテキストの接頭語として「[TRYCREATE]」という応答コードを送らなければなりません。 これはCREATEがうまくいくなら、CREATEコマンドを試みて、APPENDを再試行できるというクライアントへのヒントを与えます。
Crispin Standards Track [Page 46] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[46ページ]RFC3501IMAPv4 March 2003
If the mailbox is currently selected, the normal new message
actions SHOULD occur. Specifically, the server SHOULD notify the
client immediately via an untagged EXISTS response. If the server
does not do so, the client MAY issue a NOOP command (or failing
that, a CHECK command) after one or more APPEND commands.
メールボックスが現在選択されるなら、正常な新しいメッセージ動作SHOULDは起こります。 明確に、すぐuntagged EXISTS応答でサーバSHOULDはクライアントに通知します。 サーバがそうしないなら、1APPENDが命令した後にクライアントはNOOPコマンド(または、それに失敗するCHECKコマンド)を発行するかもしれません。
Example: C: A003 APPEND saved-messages (\Seen) {310}
S: + Ready for literal data
C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
C: From: Fred Foobar <foobar@Blurdybloop.COM>
C: Subject: afternoon meeting
C: To: mooch@owatagu.siam.edu
C: Message-Id: <B27397-0100000@Blurdybloop.COM>
C: MIME-Version: 1.0
C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
C:
C: Hello Joe, do you think we can meet at 3:30 tomorrow?
C:
S: A003 OK APPEND completed
例: C: A003 APPEND救われたメッセージ(\Seen)310S: +は文字通りのデータのためにCを準備します: 日付: 月曜日、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 the selected state, commands that manipulate messages in a mailbox are permitted.
選択された状態では、メールボックスの中のメッセージを操るコマンドが受入れられます。
In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT), and the authenticated state commands (SELECT, EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, STATUS, and APPEND), the following commands are valid in the selected state: CHECK, CLOSE, EXPUNGE, SEARCH, FETCH, STORE, COPY, and UID.
普遍的なコマンド(CAPABILITY、NOOP、およびLOGOUT)、および認証された州のコマンド(SELECT、EXAMINE、CREATE、DELETE、RENAME、登録、登録削除、LIST、LSUB、STATUS、およびAPPEND)に加えて、以下のコマンドは選択された状態で有効です: チェック、閉鎖が梢消する、検索、フェッチ、店、コピー、およびUID。
6.4.1. CHECK Command
6.4.1. チェックコマンド
Arguments: none
議論: なし
Responses: no specific responses for this command
応答: このコマンドのための特定の応答がありません。
Result: OK - check completed
BAD - command unknown or arguments invalid
結果: OK--完成したBADをチェックしてください--未知か議論病人を命令してください。
The CHECK command requests a checkpoint of the currently selected
mailbox. A checkpoint refers to any implementation-dependent
housekeeping associated with the mailbox (e.g., resolving the
server's in-memory state of the mailbox with the state on its
CHECKコマンドは現在選択されたメールボックスのチェックポイントを要求します。 状態がオンな状態でチェックポイントが(が例えば、メモリでサーバを決議する述べるメールボックスのメールボックスに関連しているどんな実現依存する家事についても言及する、それ
Crispin Standards Track [Page 47] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[47ページ]RFC3501IMAPv4 March 2003
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はNOOPに同等です。
There is no guarantee that an EXISTS untagged response will happen
as a result of CHECK. NOOP, not CHECK, SHOULD be used for new
message polling.
EXISTS untagged応答がCHECKの結果、起こるという保証が全くありません。 CHECK、SHOULDではなく、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
議論: なし
Responses: no specific responses for this command
応答: このコマンドのための特定の応答がありません。
Result: OK - close completed, now in authenticated state
BAD - command unknown or arguments invalid
結果: OK--現在、認証された州のBADで完成した閉鎖--コマンド未知か議論病人
The CLOSE command permanently removes all messages that have the
\Deleted flag set from the currently selected mailbox, and returns
to the authenticated state from the selected state. No untagged
EXPUNGE responses are sent.
CLOSEコマンドは、永久にDeleted旗が現在選択されたメールボックスから設定した\を持っているすべてのメッセージを取り除いて、選択された状態から認証された状態に戻ります。 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 if a mailbox is selected, a SELECT, EXAMINE, or LOGOUT
command MAY be issued without previously issuing a CLOSE command.
The SELECT, EXAMINE, and LOGOUT commands implicitly close the
currently selected mailbox without doing an expunge. However,
when many messages are deleted, a CLOSE-LOGOUT or CLOSE-SELECT
sequence is considerably faster than an EXPUNGE-LOGOUT or
EXPUNGE-SELECT because no untagged EXPUNGE responses (which the
client would probably ignore) are sent.
メールボックスを選択しても、以前にCLOSEコマンドを発行しないで、SELECT、EXAMINE、またはLOGOUTコマンドを発行するかもしれません。 SELECT、EXAMINE、およびLOGOUTコマンドがそれとなくしないで現在選択されたメールボックスを閉じる、梢消します。 しかしながら、多くのメッセージが削除されるとき、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
Crispin Standards Track [Page 48] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[48ページ]RFC3501IMAPv4 March 2003
6.4.3. EXPUNGE Command
6.4.3. 梢消コマンド
Arguments: none
議論: なし
Responses: 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 all messages that have the
\Deleted flag set from the currently selected mailbox. Before
returning an OK to the client, an untagged EXPUNGE response is
sent for each message that is removed.
EXPUNGEコマンドは永久に、Deleted旗が現在選択されたメールボックスから設定した\を持っているすべてのメッセージを取り除きます。 OKをクライアントに返す前に、取り除かれる各メッセージのために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応答の記述を見てください。
6.4.4. SEARCH Command
6.4.4. 検索命令
Arguments: OPTIONAL [CHARSET] specification
searching criteria (one or more)
議論: OPTIONAL[CHARSET]仕様探す評価基準(1以上)
Responses: REQUIRED untagged response: SEARCH
応答: REQUIRED untagged応答: 検索
Result: OK - search completed
NO - search error: can't search that [CHARSET] or
criteria
BAD - command unknown or arguments invalid
結果: OK--完成したノーを捜してください--誤りを捜してください: それ[CHARSET]か評価基準BADを捜すことができません--未知か議論病人を命令してください。
The SEARCH command searches the mailbox for messages that match
the given searching criteria. Searching criteria consist of one
or more search keys. The untagged SEARCH response from the server
contains a listing of message sequence numbers corresponding to
those messages that match the searching criteria.
検索命令は与えられた探す評価基準に合っているメッセージのためにメールボックスを捜します。 探す評価基準は1個以上の検索キーから成ります。 サーバからの非タグ付けをされた検索応答は探す評価基準に合っているそれらのメッセージに対応するメッセージ通番のリストを含んでいます。
Crispin Standards Track [Page 49] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[49ページ]RFC3501IMAPv4 March 2003
When multiple keys are specified, the result is the intersection
(AND function) of all the messages that match those keys. For
example, the criteria DELETED FROM "SMITH" SINCE 1-Feb-1994 refers
to all deleted messages from Smith that were placed in the mailbox
since February 1, 1994. A search key can also be a parenthesized
list of one or more search keys (e.g., for use with the OR and NOT
keys).
複数のキーが指定されるとき、結果はそれらのキーに合っているすべてのメッセージの交差点(AND機能)です。 例えば、DELETED FROM「スミス」が1994年2月1日に以来示す評価基準はすべて、1994年2月1日以来メールボックスに置かれたスミスからメッセージを削除しました。 また、検索キーは1個以上の検索キー(例えば、キーではなく、ORとの使用のための)のparenthesizedリストであるかもしれません。
Server implementations MAY exclude [MIME-IMB] body parts with
terminal content media types other than TEXT and MESSAGE from
consideration in SEARCH matching.
検索における端末の内容のTEXT以外のメディアタイプと考慮からのMESSAGEが合っていて、サーバ実現は身体の部分を除くかもしれません[MIME-IMB]。
The OPTIONAL [CHARSET] specification consists of the word
"CHARSET" followed by a registered [CHARSET]. It indicates the
[CHARSET] of the strings that appear in the search criteria.
[MIME-IMB] content transfer encodings, and [MIME-HDRS] strings in
[RFC-2822]/[MIME-IMB] headers, MUST be decoded before comparing
text in a [CHARSET] other than US-ASCII. US-ASCII MUST be
supported; other [CHARSET]s MAY be supported.
OPTIONAL[CHARSET]仕様はaがあとに続いた"CHARSET"が登録したという約束[CHARSET]から成ります。 それは検索評価基準に現れるストリングの[CHARSET]を示します。 [MIME-IMB] 米国-ASCIIを除いた[CHARSET]のテキストを比較する前に、内容転送encodings、および[RFC-2822]/[MIME-IMB]ヘッダーの[MIME-HDRS]ストリングを解読しなければなりません。 米国-ASCIIを支持しなければなりません。 他の[CHARSET]sは支持されるかもしれません。
If the server does not support the specified [CHARSET], it MUST
return a tagged NO response (not a BAD). This response SHOULD
contain the BADCHARSET response code, which MAY list the
[CHARSET]s supported by the server.
サーバが指定を支持しないなら[CHARSET]、それはタグ付けをされたいいえ応答(BADでない)を返さなければなりません。 この応答SHOULDはBADCHARSET応答コードを含んでいます。(それは、サーバによって支持された[CHARSET]sを記載するかもしれません)。
In all search keys that use strings, a message matches the key if
the string is a substring of the field. The matching is
case-insensitive.
ストリングを使用するすべての検索キーでは、メッセージはストリングが分野に関するサブストリングであるならキーに合っています。 マッチングは大文字と小文字を区別しないです。
The defined search keys are as follows. Refer to the Formal
Syntax section for the precise syntactic definitions of the
arguments.
定義された検索キーは以下の通りです。 議論の正確な構文の定義についてFormal Syntax部を参照してください。
<sequence 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はセットしました。
Crispin Standards Track [Page 50] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[50ページ]RFC3501IMAPv4 March 2003
BCC <string>
Messages that contain the specified string in the envelope
structure's BCC field.
封筒構造のBCC分野に指定されたストリングを保管している<ストリング>MessagesをBCCしてください。
BEFORE <date>
Messages whose internal date (disregarding time and timezone)
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-2822]) and that contains the specified string
in the text of the header (what comes after the colon). If the
string to search is zero-length, this matches all messages that
have a header line with the specified field-name regardless of
the contents.
ヘッダーが指定されたフィールド名([RFC-2822]で定義されるように)とそれと共にあるHEADER<フィールド名><ストリング>Messagesがヘッダー(コロンに続くこと)のテキストに指定されたストリングを含んでいます。 捜すストリングがゼロ・レングスであるなら、これはコンテンツにかかわらずヘッダー線を持っているすべてのメッセージを指定されたフィールド名に合わせます。
KEYWORD <flag>
Messages with the specified keyword flag set.
指定されたキーワード旗があるKEYWORD<旗の>Messagesはセットしました。
LARGER <n>
Messages with an [RFC-2822] size larger than the specified
number of octets.
[RFC-2822]サイズが八重奏の指定された数より大きい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 Standards Track [Page 51] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[51ページ]RFC3501IMAPv4 March 2003
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 (disregarding time and timezone)
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-2822] Date: header (disregarding time and
timezone) is earlier than the specified date.
SENTBEFORE<は[RFC-2822]日付:と>Messagesをデートします。 ヘッダー(時間を無視して、タイムゾーン)は指定された期日より初期です。
SENTON <date>
Messages whose [RFC-2822] Date: header (disregarding time and
timezone) is within the specified date.
SENTON<は[RFC-2822]日付:と>Messagesをデートします。 指定された日の中に、ヘッダー(時間を無視して、タイムゾーン)があります。
SENTSINCE <date>
Messages whose [RFC-2822] Date: header (disregarding time and
timezone) is within or later than the specified date.
SENTSINCE<は[RFC-2822]日付:と>Messagesをデートします。 ヘッダー(時間を無視して、タイムゾーン)は、中にあるか、または指定された期日より遅れています。
SINCE <date>
Messages whose internal date (disregarding time and timezone)
is within or later than the specified date.
内部の期日(時間を無視して、タイムゾーン)が中にあるか、または指定された期日より遅れているSINCE<日付>Messages。
SMALLER <n>
Messages with an [RFC-2822] size smaller than the specified
number of octets.
[RFC-2822]サイズが八重奏の指定された数より小さいSMALLER<n>Messages。
Crispin Standards Track [Page 52] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[52ページ]RFC3501IMAPv4 March 2003
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 <sequence set>
Messages with unique identifiers corresponding to the specified
unique identifier set. Sequence set ranges are permitted.
指定されたユニークな識別子に対応するユニークな識別子があるUID<シーケンスセット>Messagesはセットしました。 シーケンスセット範囲は受入れられます。
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 flag set.
指定されたキーワード旗を持っていないUNKEYWORD<旗の>Messagesがセットしました。
UNSEEN
Messages that do not have the \Seen flag set.
Seenが旗を揚げさせる\を持っていないUNSEEN Messagesがセットしました。
Crispin Standards Track [Page 53] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[53ページ]RFC3501IMAPv4 March 2003
Example: C: A282 SEARCH FLAGGED SINCE 1-Feb-1994 NOT FROM "Smith"
S: * SEARCH 2 84 882
S: A282 OK SEARCH completed
C: A283 SEARCH TEXT "string not in mailbox"
S: * SEARCH
S: A283 OK SEARCH completed
C: A284 SEARCH CHARSET UTF-8 TEXT {6}
C: XXXXXX
S: * SEARCH 43
S: A284 OK SEARCH completed
例: C: どんな「スミス」Sからの少しの1994年2月1日以来もA282検索は弛みませんでした: * 882秒間の検索2 84: A282 OK SEARCHはCを完成しました: A283 SEARCH TEXTはSを「メールボックスの中ではなく結びます」: * 検索S: A283 OK SEARCHはCを完成しました: A284はCHARSET UTF-8をテキスト6C捜します: XXXXXX S: * 43秒間、探してください: 完成したA284 OK SEARCH
Note: Since this document is restricted to 7-bit ASCII
text, it is not possible to show actual UTF-8 data. The
"XXXXXX" is a placeholder for what would be 6 octets of
8-bit data in an actual transaction.
以下に注意してください。 このドキュメントが7ビットのASCIIテキストに制限されるので、実際のUTF-8データを示しているのは可能ではありません。 "XXXXXX"は現物売買で、8ビットのデータの6つの八重奏であることのためのプレースホルダです。
6.4.5. FETCH Command
6.4.5. とって来コマンド
Arguments: sequence set
message data item names or macro
議論: シーケンスセットメッセージデータ項目名かマクロ
Responses: 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 can be either a single atom
or a parenthesized list.
FETCHコマンドはメールボックスの中のメッセージに関連しているデータを検索します。 とって来られるデータ項目は、単一原子かparenthesizedリストのどちらかであるかもしれません。
Most data items, identified in the formal syntax under the
msg-att-static rule, are static and MUST NOT change for any
particular message. Other data items, identified in the formal
syntax under the msg-att-dynamic rule, MAY change, either as a
result of a STORE command or due to external events.
msg-att静的な規則の下で正式な構文で特定されたほとんどのデータ項目が、静的であり、どんな特定のメッセージのためにも変化してはいけません。 msg-attダイナミックな規則の下で正式な構文で特定された他のデータ項目はストアコマンドの結果、外部の出来事のため変化するかもしれません。
For example, if a client receives an ENVELOPE for a
message when it already knows the envelope, it can
safely ignore the newly transmitted envelope.
例えば、既に封筒を知るとき、クライアントがメッセージのためにENVELOPEを受け取るなら、それは安全に新たに伝えられた封筒を無視できます。
There are three macros which specify commonly-used sets of data
items, and can be used instead of data items. A macro must be
used by itself, and not in conjunction with other macros or data
items.
一般的に使用されたデータ項目を指定する3つのマクロがあります、そして、データ項目の代わりに使用できます。他のマクロかデータ項目に関連して使用するのではなく、それ自体でマクロを使用しなければなりません。
Crispin Standards Track [Page 54] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[54ページ]RFC3501IMAPv4 March 2003
ALL
Macro equivalent to: (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE)
以下とすべてのMacro同等物 (INTERNALDATE RFC822.SIZE封筒に旗を揚げさせます)
FAST
Macro equivalent to: (FLAGS INTERNALDATE RFC822.SIZE)
以下とFAST Macro同等物 (INTERNALDATE RFC822.SIZEに旗を揚げさせます)
FULL
Macro equivalent to: (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE
BODY)
以下とFULL Macro同等物 (INTERNALDATE RFC822.SIZE封筒ボディーに旗を揚げさせます)
The currently defined data items that can be fetched are:
とって来ることができる現在定義されたデータ項目は以下の通りです。
BODY
Non-extensible form of BODYSTRUCTURE.
BODYSTRUCTUREのBODY Non広げることができるフォーム。
BODY[<section>]<<partial>>
The text of a particular body section. The section
specification is a set of zero or more part specifiers
delimited by periods. A part specifier is either a part number
or one of the following: HEADER, HEADER.FIELDS,
HEADER.FIELDS.NOT, MIME, and TEXT. An empty section
specification refers to the entire message, including the
header.
特定のボディーのテキストが区分するBODY[<部の>]の<の<の部分的な>>。 セクション仕様は1セットのゼロであるか以上が周期的に区切られている特許説明書の作成書を分けます。 部分特許説明書の作成書は、部品番号か以下のひとりのどちらかです: ヘッダー、HEADER.FIELDS、HEADER.FIELDS.NOT、MIME、およびテキスト。 ヘッダーを含んでいて、口先だけのセクション仕様は全体のメッセージを示します。
Every message has at least one part number. Non-[MIME-IMB]
messages, and non-multipart [MIME-IMB] messages with no
encapsulated message, only have a part 1.
あらゆるメッセージには、少なくとも一部番号があります。 ノーが要約のメッセージであって、唯一での[MIME-IMB]メッセージの、そして、非複合[MIME-IMB]の非メッセージには、第1部があります。
Multipart messages are assigned consecutive part numbers, as
they occur in the message. If a particular part is of type
message or multipart, its parts MUST be indicated by a period
followed by the part number within that nested multipart part.
メッセージに起こるとき、連続した部品番号は複合メッセージに割り当てられます。 特定の部分がタイプメッセージがあるか、または複合であるなら、部品番号がその入れ子にされた複合部分の中であとに続いていて、期間までに部品を示さなければなりません。
A part of type MESSAGE/RFC822 also has nested part numbers,
referring to parts of the MESSAGE part's body.
MESSAGE部分の身体の部分について言及して、タイプMESSAGE/RFC822の一部も部品番号を入れ子にしました。
The HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, and TEXT part
specifiers can be the sole part specifier or can be prefixed by
one or more numeric part specifiers, provided that the numeric
part specifier refers to a part of type MESSAGE/RFC822. The
MIME part specifier MUST be prefixed by one or more numeric
part specifiers.
HEADER、HEADER.FIELDS、HEADER.FIELDS.NOT、およびTEXT部分特許説明書の作成書を、唯一の部分特許説明書の作成書であることができるか1人以上の数値部分特許説明書の作成書が前に置くことができます、数値部分特許説明書の作成書がタイプMESSAGE/RFC822の一部について言及すれば。 1人以上の数値部分特許説明書の作成書がMIME部分特許説明書の作成書を前に置かなければなりません。
The HEADER, HEADER.FIELDS, and HEADER.FIELDS.NOT part
specifiers refer to the [RFC-2822] header of the message or of
an encapsulated [MIME-IMT] MESSAGE/RFC822 message.
HEADER.FIELDS and HEADER.FIELDS.NOT are followed by a list of
field-name (as defined in [RFC-2822]) names, and return a
HEADER、HEADER.FIELDS、およびHEADER.FIELDS.NOT部分特許説明書の作成書はメッセージか要約[MIME-IMT]のMESSAGE/RFC822メッセージの[RFC-2822]ヘッダーについて言及します。 HEADER.FIELDSとHEADER.FIELDS.NOTはフィールド名([RFC-2822]で定義されるように)名のリストがあとに続いていて、aを返します。
Crispin Standards Track [Page 55] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[55ページ]RFC3501IMAPv4 March 2003
subset of the header. The subset returned by HEADER.FIELDS
contains only those header fields with a field-name that
matches one of the names in the list; similarly, the subset
returned by HEADER.FIELDS.NOT contains only the header fields
with a non-matching field-name. The field-matching is
case-insensitive but otherwise exact. Subsetting does not
exclude the [RFC-2822] delimiting blank line between the header
and the body; the blank line is included in all header fetches,
except in the case of a message which has no body and no blank
line.
ヘッダーの部分集合。 HEADER.FIELDSによって返された部分集合はリストの名前の1つに合っているフィールド名でそれらのヘッダーフィールドだけを含んでいます。 同様に、HEADER.FIELDS.NOTによって返された部分集合は非突合せフィールドの名前があるヘッダーフィールドだけを含んでいます。 分野を合わせるのは、大文字と小文字を区別しないのですが、そうでなければ、正確です。 Subsettingはヘッダーとボディーの間の[RFC-2822]区切りの空白の線を遮断しません。 空白行はすべてのヘッダーフェッチに含まれています、ボディーがなくて空白行を全く持っていないメッセージに関するケースを除いて。
The MIME part specifier refers to the [MIME-IMB] header for
this part.
MIME部分特許説明書の作成書はこの部分への[MIME-IMB]ヘッダーについて言及します。
The TEXT part specifier refers to the text body of the message,
omitting the [RFC-2822] header.
[RFC-2822]ヘッダーを省略して、TEXT部分特許説明書の作成書はテキストメッセージ欄について言及します。
Here is an example of a complex message with some of its
part specifiers:
ここに、複雑なメッセージに関する例が何人かの部分特許説明書の作成書と共にあります:
HEADER ([RFC-2822] header of the message)
TEXT ([RFC-2822] text body of the message) MULTIPART/MIXED
1 TEXT/PLAIN
2 APPLICATION/OCTET-STREAM
3 MESSAGE/RFC822
3.HEADER ([RFC-2822] header of the message)
3.TEXT ([RFC-2822] text body of the message) MULTIPART/MIXED
3.1 TEXT/PLAIN
3.2 APPLICATION/OCTET-STREAM
4 MULTIPART/MIXED
4.1 IMAGE/GIF
4.1.MIME ([MIME-IMB] header for the IMAGE/GIF)
4.2 MESSAGE/RFC822
4.2.HEADER ([RFC-2822] header of the message)
4.2.TEXT ([RFC-2822] text body of the message) MULTIPART/MIXED
4.2.1 TEXT/PLAIN
4.2.2 MULTIPART/ALTERNATIVE
4.2.2.1 TEXT/PLAIN
4.2.2.2 TEXT/RICHTEXT
HEADER(メッセージのRFC-2822ヘッダー)TEXT(RFC-2822テキストメッセージ欄)MULTIPART/Mixed1TEXT/PLAIN2APPLICATION/OCTET-STREAM3MESSAGE/RFC822 3.HEADER(メッセージのRFC-2822ヘッダー)3.TEXT(RFC-2822テキストメッセージ欄)MULTIPART/Mixed3.1TEXT/PLAIN3; 2APPLICATION/OCTET-STREAM4MULTIPART/Mixed4.1IMAGE/GIF 4.1.MIME(IMAGE/GIFのためのMIME-IMBヘッダー)4.2MESSAGE/RFC822 4.2.HEADER(メッセージのRFC-2822ヘッダー)4.2.TEXT(RFC-2822テキストメッセージ欄)MULTIPART/Mixed4.2.1TEXT/PLAIN4.2.2MULTIPART/ALTERNATIVE4.2.2.1TEXT/PLAIN4.2.2、.2TEXT/RICHTEXT
It is possible to fetch a substring of the designated text.
This is done by appending an open angle bracket ("<"), the
octet position of the first desired octet, a period, the
maximum number of octets desired, and a close angle bracket
(">") to the part specifier. If the starting octet is beyond
the end of the text, an empty string is returned.
指定されたテキストに関するサブストリングをとって来るのは可能です。 開いている角ブラケット("<")、最初の必要な八重奏、八重奏の最大数が望んでいた期間の八重奏位置、および近い角ブラケット(">")を部分特許説明書の作成書に追加することによって、これをします。 始めの八重奏がテキストの終わりにあるなら、空のストリングを返します。
Crispin Standards Track [Page 56] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[56ページ]RFC3501IMAPv4 March 2003
Any partial fetch that attempts to read beyond the end of the
text is truncated as appropriate. A partial fetch that starts
at octet 0 is returned as a partial fetch, even if this
truncation happened.
テキストの終わりに読むのを試みるどんな部分的なフェッチも適宜先端を切られます。 このトランケーションが起こったとしても、部分的なフェッチとして八重奏0で始まる部分的なフェッチを返します。
Note: This means that BODY[]<0.2048> of a 1500-octet message
will return BODY[]<0> with a literal of size 1500, not
BODY[].
以下に注意してください。 これは、1500八重奏のメッセージのBODY[]<0.2048>がBODY[]ではなく、サイズ1500における文字通りのaがあるBODY[]<0>を返すことを意味します。
Note: A substring fetch of a HEADER.FIELDS or
HEADER.FIELDS.NOT part specifier is calculated after
subsetting the header.
以下に注意してください。 ヘッダーを副設定した後に、HEADER.FIELDSかHEADER.FIELDS.NOT部分特許説明書の作成書のサブストリングフェッチは計算されます。
The \Seen flag is implicitly set; if this causes the flags to
change, they SHOULD be included as part of the FETCH responses.
Seenが旗を揚げさせる\はそれとなく設定されます。 旗はこれで変化して、それらはSHOULDです。FETCH応答の一部として、含まれています。
BODY.PEEK[<section>]<<partial>>
An alternate form of BODY[<section>] that does not implicitly
set the \Seen flag.
BODY.PEEK[<部の>]の<の<の部分的な>>AnはそれとなくSeenが旗を揚げさせる\を設定しないBODY[<部の>]のフォームを交替します。
BODYSTRUCTURE
The [MIME-IMB] body structure of the message. This is computed
by the server by parsing the [MIME-IMB] header fields in the
[RFC-2822] header and [MIME-IMB] headers.
BODYSTRUCTURE、メッセージの[MIME-IMB]ボディー構造。 これは、[RFC-2822]ヘッダーと[MIME-IMB]ヘッダーで[MIME-IMB]ヘッダーフィールドを分析することによって、サーバによって計算されます。
ENVELOPE
The envelope structure of the message. This is computed by the
server by parsing the [RFC-2822] header into the component
parts, defaulting various fields as necessary.
ENVELOPE、メッセージの封筒構造。 これは、必要に応じてコンポーネントの部品への[RFC-2822]ヘッダー、デフォルト多岐を分析することによって、サーバによって計算されます。
FLAGS
The flags that are set for this message.
FLAGS、このメッセージに設定される旗。
INTERNALDATE
The internal date of the message.
内部のINTERNALDATEはメッセージとデートします。
RFC822
Functionally equivalent to BODY[], differing in the syntax of
the resulting untagged FETCH data (RFC822 is returned).
結果として起こるuntagged FETCHデータ(RFC822を返す)の構文において異なるBODY[]に同等なRFC822 Functionally。
RFC822.HEADER
Functionally equivalent to BODY.PEEK[HEADER], differing in the
syntax of the resulting untagged FETCH data (RFC822.HEADER is
returned).
結果として起こるuntagged FETCHデータ(RFC822.HEADERを返す)の構文において異なるBODY.PEEK[HEADER]に同等なRFC822.HEADER Functionally。
RFC822.SIZE
The [RFC-2822] size of the message.
メッセージの[RFC-2822]サイズのRFC822.SIZE。
Crispin Standards Track [Page 57] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[57ページ]RFC3501IMAPv4 March 2003
RFC822.TEXT
Functionally equivalent to BODY[TEXT], differing in the syntax
of the resulting untagged FETCH data (RFC822.TEXT is returned).
結果として起こるuntagged FETCHデータ(RFC822.TEXTを返す)の構文において異なるBODY[TEXT]に同等なRFC822.TEXT Functionally。
UID
The unique identifier for the message.
UID、メッセージのためのユニークな識別子。
Example: C: A654 FETCH 2:4 (FLAGS BODY[HEADER.FIELDS (DATE FROM)])
S: * 2 FETCH ....
S: * 3 FETCH ....
S: * 4 FETCH ....
S: A654 OK FETCH completed
例: C: A654は2:4(旗のボディー[HEADER.FIELDS(さかのぼる)])Sをとって来ます: * 2 とって来ます。 S: * 3 とって来ます。 S: * 4 とって来ます。 S: 完成したA654 OK FETCH
6.4.6. STORE Command
6.4.6. 格納命令
Arguments: sequence set
message data item name
value for message data item
議論: メッセージデータ項目のためのシーケンスセットメッセージデータ項目名前価値
Responses: 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
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応答と共にデータのアップデートされた値を返すでしょう。 データ項目名の".SILENT"の接尾語が非タグ付けをされたフェッチを防いで、サーバは、クライアントがアップデートされた値自体を決定したと仮定するべきであるか、またはアップデートされた値を心配しません。
Note: Regardless of whether or not the ".SILENT" suffix
was used, the server SHOULD send an untagged FETCH
response if a change to a message's flags from an
external source is observed. The intent is that the
status of the flags is determinate without a race
condition.
以下に注意してください。 ".SILENT"接尾語が使用されたかどうかにかかわらず、外部電源からのメッセージの旗への変化が観測されるなら、サーバは非タグ付けをされたフェッチ応答を送るべきです。 意図は旗の状態が競合条件なしで確定的であるということです。
Crispin Standards Track [Page 58] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[58ページ]RFC3501IMAPv4 March 2003
The currently defined data items that can be stored are:
格納できる現在定義されたデータ項目は以下の通りです。
FLAGS <flag list>
Replace the flags for the message (other than \Recent) with the
argument. The new value of the flags is returned as if a FETCH
of those flags was done.
FLAGS<はリスト>Replaceに旗を揚げさせます。議論があるメッセージ(\Recentを除いた)のための旗。 まるでそれらの旗の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 is 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 is 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
6.4.7. COPY Command
6.4.7. コピーコマンド
Arguments: sequence set
mailbox name
議論: シーケンスセットメールボックス名
Responses: no specific responses for this command
応答: このコマンドのための特定の応答がありません。
Result: OK - copy completed
NO - copy error: can't copy those messages or to that
name
BAD - command unknown or arguments invalid
結果: OK--コピーはいいえを完成しました--誤りをコピーしてください: それらのメッセージかその名前BADにコピーできません--未知か議論病人を命令してください。
Crispin Standards Track [Page 59] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[59ページ]RFC3501IMAPv4 March 2003
The COPY command copies the specified message(s) to the end of the
specified destination mailbox. The flags and internal date of the
message(s) SHOULD be preserved, and the Recent flag SHOULD be set,
in the copy.
COPYコマンドは指定されたメッセージを指定されたあて先メールボックスの端までコピーします。 メッセージSHOULDでは、保存されていてRecent旗のSHOULDになってください。旗と内部の期日、セットになってください、コピーで。
If the destination mailbox does not exist, a server SHOULD return
an error. It SHOULD NOT automatically create the mailbox. Unless
it is certain that the destination mailbox can not be created, the
server MUST send the response code "[TRYCREATE]" as the prefix of
the text of the tagged NO response. This gives a hint to the
client that it can attempt a CREATE command and retry the COPY if
the CREATE is successful.
あて先メールボックスが存在していないなら、SHOULDが誤りを返すサーバです。 それ、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.8. UID Command
6.4.8. UIDコマンド
Arguments: command name
command arguments
議論: コマンド名コマンド議論
Responses: 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 sequence set argument are unique identifiers instead of
message sequence numbers. Sequence set ranges are permitted, but
there is no guarantee that unique identifiers will be contiguous.
UIDコマンドには、2つのフォームがあります。最初のフォームでは、それは議論として関連コマンドに、適切な議論でCOPY、FETCH、またはストアコマンドをみなします。 しかしながら、シーケンスセット議論における数はメッセージ通番の代わりにユニークな識別子です。 シーケンスセット範囲は受入れられますが、ユニークな識別子が隣接になるという保証が全くありません。
A non-existent unique identifier is ignored without any error
message generated. Thus, it is possible for a UID FETCH command
to return an OK without any data or a UID COPY or UID STORE to
return an OK without performing any operations.
実在しないユニークな識別子は少しも発生しているエラーメッセージなしで無視されます。 したがって、少しもデータなしでOKを返すUID FETCHコマンド、UID COPYまたはUID STOREがどんな操作も実行しないでOKを返すのは、可能です。
In the second form, the UID command takes a SEARCH command with
SEARCH command arguments. The interpretation of the arguments is
the same as with SEARCH; however, the numbers returned in a SEARCH
response for a UID SEARCH command are unique identifiers instead
2番目のフォームでは、UIDコマンドは検索コマンド議論で検索命令を取ります。 議論の解釈は検索と同じです。 しかしながら、UID SEARCHコマンドのための検索応答で返された数は代わりにユニークな識別子です。
Crispin Standards Track [Page 60] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[60ページ]RFC3501IMAPv4 March 2003
of message sequence numbers. For example, the command UID SEARCH
1:100 UID 443:557 returns the unique identifiers corresponding to
the intersection of two sequence sets, the message sequence number
range 1:100 and the UID range 443:557.
メッセージ通番について。 例えば、UID SEARCH1:100UIDを命令してください、443:557、2つのシーケンスセットの交差点に対応するユニークな識別子、メッセージ通番範囲に1:100とUID範囲を返す、443:557
Note: in the above example, the UID range 443:557
appears. The same comment about a non-existent unique
identifier being ignored without any error message also
applies here. Hence, even if neither UID 443 or 557
exist, this range is valid and would include an existing
UID 495.
以下に注意してください。 例、上記のUID範囲443: 557 現れます。 また、少しもエラーメッセージなしで無視される実在しないユニークな識別子に関する同じコメントはここに適用されます。 したがって、どちらのUID443か557も存在していなくても、この範囲は、有効であり、既存のUID495を含んでいるでしょう。
Also note that a UID range of 559:* always includes the
UID of the last message in the mailbox, even if 559 is
higher than any assigned UID value. This is because the
contents of a range are independent of the order of the
range endpoints. Thus, any UID range with * as one of
the endpoints indicates at least one message (the
message with the highest numbered UID), unless the
mailbox is empty.
また、559のUID範囲: *がいつもメールボックスにおける最後のメッセージのUIDを含んでいることに注意してください、559がいずれか値をUIDに割り当てたよりさらに高いなら。 これは1つの範囲の内容が範囲終点の注文から独立しているからです。 したがって、終点のひとりが少なくとも1つのメッセージ(最も高い番号付のUIDがあるメッセージ)を示すとき、どんなUIDも*で及びます、メールボックスが空でない場合。
The number after the "*" in an untagged FETCH response is always a
message sequence number, not a unique identifier, even for a UID
command response. However, server implementations MUST implicitly
include the UID message data item as part of any FETCH response
caused by a UID command, regardless of whether a UID was specified
as a message data item to the FETCH.
いつも非タグ付けをされたフェッチ応答における「*」の後の数はユニークな識別子ではなく、メッセージ通番です、UIDコマンド応答のためにさえ。 しかしながら、サーバ実装はUIDコマンドで引き起こされたどんなFETCH応答の一部としてもそれとなくUIDメッセージデータ項目を含まなければなりません、UIDがメッセージデータ項目としてFETCHに指定されたかどうかにかかわらず。
Note: The rule about including the UID message data item as part
of a FETCH response primarily applies to the UID FETCH and UID
STORE commands, including a UID FETCH command that does not
include UID as a message data item. Although it is unlikely that
the other UID commands will cause an untagged FETCH, this rule
applies to these commands as well.
以下に注意してください。 FETCH応答の一部が主としてUID FETCHとUID STOREに適用されながらUIDメッセージデータ項目を含むことに関する規則は命令します、メッセージデータ項目としてUIDを含んでいないUID FETCHコマンドを含んでいて。 他のUIDコマンドがuntagged FETCHを引き起こすのが、ありそうもないのですが、この規則はまた、これらのコマンドに適用されます。
Example: C: A999 UID FETCH 4827313:4828442 FLAGS
S: * 23 FETCH (FLAGS (\Seen) UID 4827313)
S: * 24 FETCH (FLAGS (\Seen) UID 4827943)
S: * 25 FETCH (FLAGS (\Seen) UID 4828442)
S: A999 OK UID FETCH completed
例: C: A999 UIDフェッチ4827313: 4828442個の旗S: * 23 (UID4827313に旗を揚げさせます(見られた\))Sをとって来てください: * 24 (UID4827943に旗を揚げさせます(見られた\))Sをとって来てください: * 25 (UID4828442に旗を揚げさせます(見られた\))Sをとって来てください: 完成したA999 OK UID FETCH
Crispin Standards Track [Page 61] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[61ページ]RFC3501IMAPv4 March 2003
6.5. Client Commands - Experimental/Expansion
6.5. クライアントコマンド--実験的な/拡張
6.5.1. X<atom> Command
6.5.1. X<原子>コマンド
Arguments: implementation defined
議論: 定義された実装
Responses: 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, a standard or
standards-track revision of this specification, or an
IESG-approved experimental protocol, MUST use the X prefix.
Xと共に前に置かれたどんなコマンドも実験的なコマンドです。 この仕様の一部でないコマンド(この仕様の規格か標準化過程改正、またはIESGによって承認された実験プロトコル)は、X接頭語を使用しなければなりません。
Any added untagged responses issued by an experimental command
MUST also be prefixed with an X. Server implementations MUST NOT
send any such untagged responses, unless the client requested it
by issuing the associated experimental command.
いずれも、また、Server実装がそのような少しの非タグ付けをされた応答も送ってはいけないX.で実験的なコマンドで発行された非タグ付けをされた応答を前に置かなければならないと言い足しました、クライアントが関連実験的なコマンドを発行することによってそれを要求しなかったなら。
Example: C: a441 CAPABILITY
S: * CAPABILITY IMAP4rev1 XPIG-LATIN
S: a441 OK CAPABILITY completed
C: A442 XPIG-LATIN
S: * XPIG-LATIN ow-nay eaking-spay ig-pay atin-lay
S: A442 OK XPIG-LATIN ompleted-cay
例: C: a441 CAPABILITY S: * 能力IMAP4rev1 XPIG-ラテンS: a441OK CAPABILITYはCを完成しました: A442 XPIG-ラテンS: * XPIG-ラテン語、痛い、-いいえ、eakingしてig支払っているatin横たえているSの卵巣を除去してください: A442 OK XPIGラテン語のompleted小島
7. Server Responses
7. サーバ応答
Server responses are in three forms: status responses, server data, and command continuation request. The information contained in a server response, identified by "Contents:" in the response descriptions below, is described by function, not by syntax. The precise syntax of server responses is described in the Formal Syntax section.
サーバ応答が3つのフォームにあります: 応答、サーバデータ、およびコマンド継続が要求する状態。 サーバに応答であって、特定されていた状態で含まれた情報は「以下を満足します」。 以下での応答記述で説明する、機能で、構文によって説明されるのではなく、説明されます。 サーバ応答の正確な構文はFormal Syntax部で説明されます。
The client MUST be prepared to accept any response at all times.
クライアントはいつもあらゆる応答を受け入れる用意ができていなければなりません。
Status responses can be tagged or untagged. Tagged status responses indicate the completion result (OK, NO, or BAD status) of a client command, and have a tag matching the command.
状態応答にタグ付けをするか、または非タグ付けをすることができます。 タグ付けをされた状態応答で、クライアントコマンドの完成結果(OK、ノー、またはBAD状態)を示して、タグはコマンドに合っています。
Some status responses, and all server data, are untagged. An untagged response is indicated by the token "*" instead of a tag. Untagged status responses indicate server greeting, or server status
いくつかの状態応答、およびすべてのサーバデータが非タグ付けをされます。 非タグ付けをされた応答はタグの代わりにトークン「*」によって示されます。 Untagged状態応答はサーバ挨拶、またはサーバ状態を示します。
Crispin Standards Track [Page 62] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[62ページ]RFC3501IMAPv4 March 2003
that does not indicate the completion of a command (for example, an impending system shutdown alert). For historical reasons, untagged server data responses are also called "unsolicited data", although strictly speaking, only unilateral server data is truly "unsolicited".
それはコマンド(例えば、差し迫っているシステム・シャットダウン警戒)の完成を示しません。 歴史的な理由で、また、非タグ付けをされたサーバデータ応答は「求められていないデータ」と呼ばれます、一方的なサーバデータだけが厳密に言うと本当に「求められていませんです」が。
Certain server data MUST be recorded by the client when it is received; this is noted in the description of that data. Such data conveys critical information which affects the interpretation of all subsequent commands and responses (e.g., updates reflecting the creation or destruction of messages).
それが受け取られているとき、クライアントはあるサーバデータを記録しなければなりません。 そのデータの記述でこれに注意します。 そのようなデータはすべてのその後のコマンドの解釈に影響する重要情報と応答(例えば、メッセージの作成か破壊を反映するアップデート)を伝えます。
Other server data SHOULD be recorded for later reference; if the client does not need to record the data, or if recording the data has no obvious purpose (e.g., a SEARCH response when no SEARCH command is in progress), the data SHOULD be ignored.
他のサーバデータSHOULD、後の参照には、記録されてください。 クライアントがそうする必要はないなら、データを記録してください、またはデータを記録するなら、明白な目的がない(例えば、検索命令が全く進行していないときの検索応答)、データSHOULDは無視されましたか?
An example of unilateral untagged server data occurs when the IMAP connection is in the selected state. In the selected state, the server checks the mailbox for new messages as part of command execution. Normally, this is part of the execution of every command; hence, a NOOP command suffices to check for new messages. If new messages are found, the server sends untagged EXISTS and RECENT responses reflecting the new size of the mailbox. Server implementations that offer multiple simultaneous access to the same mailbox SHOULD also send appropriate unilateral untagged FETCH and EXPUNGE responses if another agent changes the state of any message flags or expunges any messages.
IMAP接続が選択された状態にあるとき、一方的な非タグ付けをされたサーバデータに関する例は現れます。 選択された状態では、サーバは新しいメッセージがないかどうかコマンド実行の一部としてメールボックスをチェックします。 通常、これはあらゆるコマンドの実行の一部です。 したがって、NOOPコマンドは、新しいメッセージがないかどうかチェックするために十分です。 新しいメッセージが見つけられるなら、サーバで、untagged EXISTSとRECENT応答はメールボックスの新しいサイズを反映します。 また、別のエージェントがどんなメッセージ旗の状態も変えるか、または何かメッセージを梢消するなら、同じメールボックスSHOULDへの複数の同時アクセスを提供するサーバ実装が適切な一方的な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.
コマンド継続要求応答はタグの代わりにトークン「+」を使用します。 サーバでこれらの応答を送って、コマンドの残りのための不完全なクライアントコマンドと準備の承認を示します。
7.1. Server Responses - Status Responses
7.1. サーバ応答--状態応答
Status responses are OK, NO, BAD, PREAUTH and BYE. OK, NO, and BAD can be tagged or untagged. PREAUTH and BYE are always untagged.
ノー、BAD、PREAUTH、およびBYE、状態応答はOKです。 OK、いいえ、BADにタグ付けをするか、または非タグ付けをすることができます。 PREAUTHとBYEはいつも非タグ付けをされます。
Status responses MAY include an OPTIONAL "response code". A response code consists of data inside square brackets in the form of an atom, possibly followed by a space and arguments. The response code contains additional information or status codes for client software beyond the OK/NO/BAD condition, and are defined when there is a specific action that a client can take based upon the additional information.
状態応答はOPTIONAL「応答コード」を含むかもしれません。 応答コードはスペースと議論がことによるとあとに続いた原子の形で角括弧でデータから成ります。 応答コードは、OK/いいえ、/BAD状態を超えてクライアントソフトウェアのための追加情報かステータスコードを含んでいて、追加情報に基づいて、クライアントが取ることができる特定の行動があるとき、定義されます。
Crispin Standards Track [Page 63] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[63ページ]RFC3501IMAPv4 March 2003
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.
人間読み込み可能なテキストはメッセージへのユーザの注意を呼ぶファッションでユーザに提示しなければならない特別な警戒を含んでいます。
BADCHARSET
BADCHARSET
Optionally followed by a parenthesized list of charsets. A
SEARCH failed because the given charset is not supported by
this implementation. If the optional list of charsets is
given, this lists the charsets that are supported by this
implementation.
charsetsのparenthesizedリストは任意にあとに続きます。 与えられたcharsetがこの実装によってサポートされないので、検索は失敗しました。 charsetsの任意のリストを与えるなら、これはこの実装によってサポートされるcharsetsを記載します。
CAPABILITY
能力
Followed by a list of capabilities. This can appear in the
initial OK or PREAUTH response to transmit an initial
capabilities list. This makes it unnecessary for a client to
send a separate CAPABILITY command if it recognizes this
response.
能力のリストはあとに続いています。 これは初期の能力リストを伝える初期のOKかPREAUTH応答に現れることができます。 これで、この応答を認識するなら、クライアントが別々のCAPABILITYコマンドを送るのが不要になります。
PARSE
分析してください。
The human-readable text represents an error in parsing the
[RFC-2822] header or [MIME-IMB] headers of a message in the
mailbox.
人間読み込み可能なテキストはメールボックスの中のメッセージの[RFC-2822]ヘッダーか[MIME-IMB]ヘッダーを分析する際に誤りを表します。
PERMANENTFLAGS
PERMANENTFLAGS
Followed by a parenthesized list of flags, indicates which of
the known flags the client can change permanently. Any flags
that are in the FLAGS untagged response, but not the
PERMANENTFLAGS list, can not be set permanently. If the client
attempts to STORE a flag that is not in the PERMANENTFLAGS
list, the server will either ignore the change or store the
state change for the remainder of the current session only.
The PERMANENTFLAGS list can also include the special flag \*,
which indicates that it is possible to create new keywords by
attempting to store those flags in the mailbox.
旗のparenthesizedリストで続いて、クライアントが永久に知られている旗のどれを変えることができるかを示します。 永久に、どんなPERMANENTFLAGSリストではなく、FLAGS untagged応答中であることの旗も設定できません。 クライアントがPERMANENTFLAGSリストにない旗をストアに試みると、サーバは、現在のセッションの残りだけのために変化を無視するか、または州の変化を保存するでしょう。 また、PERMANENTFLAGSリストは特別な旗の\*を含むことができます。(それは、メールボックスの中にそれらの旗を保存するのを試みることによって新しいキーワードを作成するのが可能であることを示します)。
Crispin Standards Track [Page 64] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[64ページ]RFC3501IMAPv4 March 2003
READ-ONLY
書き込み禁止
The mailbox is selected read-only, or its access while selected
has changed from read-write to read-only.
メールボックスは選択された書き込み禁止であるかアクセスが選択されている間、読書して書くのから書き込み禁止に変化しています。
READ-WRITE
-読まれて、書いてください。
The mailbox is selected read-write, or its access while
selected has changed from read-only to read-write.
メールボックスが読書して書いた状態で選択されるか、またはアクセスは、読書して書くために選択されている間、書き込み禁止から変化しています。
TRYCREATE
TRYCREATE
An APPEND or COPY attempt is failing because the target mailbox
does not exist (as opposed to some other reason). This is a
hint to the client that the operation can succeed if the
mailbox is first created by the CREATE command.
目標メールボックスが存在していないので、APPENDかCOPY試みが失敗(ある他の理由と対照的に)です。 これはクライアントへのメールボックスが最初にCREATEコマンドで作成されるなら操作が成功できるというヒントです。
UIDNEXT
UIDNEXT
Followed by a decimal number, indicates the next unique
identifier value. Refer to section 2.3.1.1 for more
information.
10進数に従って続いて、次のユニークな識別子値を示します。 セクション2.3を参照してください。.1 .1 詳しい情報のために。
UIDVALIDITY
UIDVALIDITY
Followed by a decimal number, indicates the unique identifier
validity value. Refer to section 2.3.1.1 for more information.
10進数に従って続いて、ユニークな識別子正当性価値を示します。 セクション2.3を参照してください。.1 .1 詳しい情報のために。
UNSEEN
見えない
Followed by a decimal number, indicates the number of the first
message without the \Seen flag set.
10進数に従って続いて、Seenが旗を揚げさせる\のない最初のメッセージの数がセットしたのを示します。
Additional response codes defined by particular client or server
implementations SHOULD be prefixed with an "X" until they are
added to a revision of this protocol. Client implementations
SHOULD ignore response codes that they do not recognize.
追加応答コードは特定のクライアントかサーバ実装でSHOULDを定義しました。それらがこのプロトコルの改正に加えられるまで、「X」と共に前に置かれています。 クライアント実装SHOULDは彼らが認識しない応答コードを無視します。
7.1.1. OK Response
7.1.1. OK応答
Contents: OPTIONAL response code
human-readable text
コンテンツ: OPTIONALの応答のコードの人間読み込み可能なテキスト
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
OK応答はサーバから情報メッセージを示します。タグ付けをされると、それは関連コマンドの無事終了を示します。 人間読み込み可能なテキストは情報メッセージとしてユーザに提示されるかもしれません。 非タグ付けをされたフォームは示します。
Crispin Standards Track [Page 65] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[65ページ]RFC3501IMAPv4 March 2003
information-only message; the nature of the information MAY be
indicated by a response code.
情報だけメッセージ。 情報の本質は応答コードによって示されるかもしれません。
The untagged form is also used as one of three possible greetings
at connection startup. It indicates that the connection is not
yet authenticated and that a LOGIN command is needed.
また、非タグ付けをされたフォームは接続始動での3つの可能な挨拶の1つとして使用されます。 それは、接続がまだ認証されていなくて、LOGINコマンドが必要であることを示します。
Example: S: * OK IMAP4rev1 server ready
C: A001 LOGIN fred blurdybloop
S: * OK [ALERT] System shutdown in 10 minutes
S: A001 OK LOGIN Completed
例: S: * IMAP4rev1サーバ持ち合わせのCを承認してください: A001 LOGIN fred blurdybloop S: * 10分Sで[ALERT]システム・シャットダウンを承認してください: 終了するA001OKログイン
7.1.2. NO Response
7.1.2. 応答がありません。
Contents: OPTIONAL response code
human-readable text
コンテンツ: OPTIONALの応答のコードの人間読み込み可能なテキスト
The NO response indicates an operational error message from the
server. When tagged, it indicates unsuccessful completion of the
associated command. The untagged form indicates a warning; the
command can still complete successfully. The human-readable text
describes the condition.
いいえ応答はサーバから誤操作メッセージを示します。タグ付けをされると、それは関連コマンドの失敗の完成を示します。 非タグ付けをされたフォームは警告を示します。 コマンドはまだ首尾よく完成できます。 人間読み込み可能なテキストは状態について説明します。
Example: C: A222 COPY 1:2 owatagusiam
S: * NO Disk is 98% full, please delete unnecessary data
S: A222 OK COPY completed
C: A223 COPY 3:200 blurdybloop
S: * NO Disk is 98% full, please delete unnecessary data
S: * NO Disk is 99% full, please delete unnecessary data
S: A223 NO COPY failed: disk is full
例: C: A222 COPY1: 2owatagusiam S: * どんなDiskも98%完全でなく、不要なデータSを削除してください: A222 OK COPYはCを完成しました: A223 COPY3: 200blurdybloop S: * どんなDiskも98%完全でなく、不要なデータSを削除してください: * どんなDiskも99%完全でなく、不要なデータSを削除してください: A223 NO COPYは失敗しました: ディスクは完全です。
7.1.3. BAD Response
7.1.3. 誤応答
Contents: OPTIONAL response code
human-readable text
コンテンツ: OPTIONALの応答のコードの人間読み込み可能なテキスト
The BAD response indicates an error message from the server. When
tagged, it reports a protocol-level error in the client's command;
the tag indicates the command that caused the error. The untagged
form indicates a protocol-level error for which the associated
command can not be determined; it can also indicate an internal
server failure. The human-readable text describes the condition.
BAD応答はサーバからエラーメッセージを示します。タグ付けをされると、クライアントのコマンドにおけるプロトコルレベル誤りを報告します。 タグは誤りを引き起こしたコマンドを示します。 非タグ付けをされたフォームは関連コマンドが決定できないプロトコルレベル誤りを示します。 また、それは内部のサーバ失敗を示すことができます。 人間読み込み可能なテキストは状態について説明します。
Crispin Standards Track [Page 66] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[66ページ]RFC3501IMAPv4 March 2003
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応答
Contents: OPTIONAL response code
human-readable text
コンテンツ: OPTIONALの応答のコードの人間読み込み可能なテキスト
The PREAUTH response is always untagged, and is one of three
possible greetings at connection startup. It indicates that the
connection has already been authenticated by external means; thus
no LOGIN command is needed.
PREAUTH応答は、いつも非タグ付けをされて、接続始動での3つの可能な挨拶の1つです。 それは、接続が外部の手段で既に認証されたのを示します。 したがって、LOGINコマンドは全く必要ではありません。
Example: S: * PREAUTH IMAP4rev1 server logged in as Smith
例: S: * スミスとしてログインされたPREAUTH IMAP4rev1サーバ
7.1.5. BYE Response
7.1.5. さようなら応答
Contents: OPTIONAL response code
human-readable text
コンテンツ: OPTIONALの応答のコードの人間読み込み可能なテキスト
The BYE response is always untagged, and indicates that the server
is about to close the connection. The human-readable text MAY be
displayed to the user in a status report by the client. The BYE
response is sent under one of four conditions:
BYE応答は、いつも非タグ付けをされて、サーバが接続を終えようとしているのを示します。 人間読み込み可能なテキストは現状報告にクライアントによってユーザに表示されるかもしれません。 4つの状態の1つ未満をBYE応答に送ります:
1) as part of a normal logout sequence. The server will close
the connection after sending the tagged OK response to the
LOGOUT command.
1) 標準の一部として、ログアウトしてください。系列。 タグ付けをされたOK応答をLOGOUTコマンドに送った後に、サーバは接続を終えるでしょう。
2) as a panic shutdown announcement. The server closes the
connection immediately.
2) パニック閉鎖発表として。 サーバはすぐに、接続を終えます。
3) as an announcement of an inactivity autologout. The server
closes the connection immediately.
3) 不活発autologoutの発表として。 サーバはすぐに、接続を終えます。
4) as one of three possible greetings at connection startup,
indicating that the server is not willing to accept a
connection from this client. The server closes the
connection immediately.
4) サーバがこのクライアントから接続を受け入れることを望んでいないのを示す接続始動での3つの可能な挨拶の1つとして。 サーバはすぐに、接続を終えます。
Crispin Standards Track [Page 67] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[67ページ]RFC3501IMAPv4 March 2003
The difference between a BYE that occurs as part of a normal
LOGOUT sequence (the first case) and a BYE that occurs because of
a failure (the other three cases) is that the connection closes
immediately in the failure case. In all cases the client SHOULD
continue to read response data from the server until the
connection is closed; this will ensure that any pending untagged
or completion responses are read and processed.
正常なLOGOUT系列の一部として起こるBYE(最初のケース)と失敗で起こるBYE(他の3つのケース)の違いは接続がすぐ失敗事件で閉じるということです。 すべての場合では、クライアントSHOULDは、接続が閉じられるまでサーバから応答データを読み続けています。 これが、未定のいずれも非タグ付けをされたのを確実にするか、完成応答は、読まれて、処理されます。
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 and mailbox status data are transmitted from the server to the client. Many of these responses typically result from a command with the same name.
これらの応答はいつも非タグ付けをされます。 これはサーバとメールボックス状態データがサーバからクライアントまでどう送られるかということです。 これらの応答の多くが同じ名前によるコマンドから通常生じます。
7.2.1. CAPABILITY Response
7.2.1. 能力応答
Contents: capability listing
コンテンツ: 能力リスト
The CAPABILITY response occurs as a result of a CAPABILITY
command. The capability listing contains a space-separated
listing of capability names that the server supports. The
capability listing MUST include the atom "IMAP4rev1".
CAPABILITY応答はCAPABILITYコマンドの結果、起こります。 能力リストはサーバがサポートする能力名のスペースで切り離されたリストを含んでいます。 能力リストは原子"IMAP4rev1""を含まなければなりません。
In addition, client and server implementations MUST implement the
STARTTLS, LOGINDISABLED, and AUTH=PLAIN (described in [IMAP-TLS])
capabilities. See the Security Considerations section for
important information.
さらに、クライアントとサーバ実装はSTARTTLS、LOGINDISABLED、およびAUTH=PLAIN([IMAP-TLS]では、説明される)に能力を実装しなければなりません。 重要情報に関してSecurity Considerations部を見てください。
A capability name which begins with "AUTH=" indicates that the
server supports that particular authentication mechanism.
「AUTH=」と共に始まる能力名は、サーバが、それが特定の認証機構であるとサポートするのを示します。
The LOGINDISABLED capability indicates that the LOGIN command is
disabled, and that the server will respond with a tagged NO
response to any attempt to use the LOGIN command even if the user
name and password are valid. An IMAP client MUST NOT issue the
LOGIN command if the server advertises the LOGINDISABLED
capability.
LOGINDISABLED能力はLOGINコマンドは障害があって、ユーザ名とパスワードが妥当であってもサーバがLOGINコマンドを使用するどんな試みへのタグ付けをされたいいえ応答でも反応するのを示します。 サーバがLOGINDISABLED能力の広告を出すなら、IMAPクライアントはLOGINコマンドを発行してはいけません。
Other capability names indicate that the server supports an
extension, revision, or amendment to the IMAP4rev1 protocol.
Server responses MUST conform to this document until the client
issues a command that uses the associated capability.
他の能力名は、サーバがIMAP4rev1プロトコルの拡大、改正、または修正をサポートするのを示します。 クライアントが関連能力を使用するコマンドを発行するまで、サーバ応答はこのドキュメントに従わなければなりません。
Capability names MUST either begin with "X" or be standard or
standards-track IMAP4rev1 extensions, revisions, or amendments
registered with IANA. A server MUST NOT offer unregistered or
能力名が、「X」と共に始まるか、標準であるに違いありません、または標準化過程IMAP4rev1拡張子、改正、または修正がIANAとともに記名しました。 またはサーバが提供してはいけない、登録されていなさ。
Crispin Standards Track [Page 68] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[68ページ]RFC3501IMAPv4 March 2003
non-standard capability names, unless such names are prefixed with
an "X".
標準的でない能力名そのような名前が「X」と共に前に置かれていない場合。
Client implementations SHOULD NOT require any capability name
other than "IMAP4rev1", and MUST ignore any unknown capability
names.
クライアント実装SHOULD NOTが能力名を必要とする、「IMAP4rev1"、どんな未知の能力名も無視しなければならない、」
A server MAY send capabilities automatically, by using the
CAPABILITY response code in the initial PREAUTH or OK responses,
and by sending an updated CAPABILITY response code in the tagged
OK response as part of a successful authentication. It is
unnecessary for a client to send a separate CAPABILITY command if
it recognizes these automatic capabilities.
サーバは、初期のPREAUTHかOKの応答にCAPABILITY応答コードを使用して、うまくいっている認証の一部としてタグ付けをされたOK応答でアップデートされたCAPABILITY応答コードを送ることによって、自動的に能力を送るかもしれません。 これらの自動能力を認識するなら、クライアントが別々のCAPABILITYコマンドを送るのは、不要です。
Example: S: * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI XPIG-LATIN
例: S: * 能力IMAP4rev1 STARTTLS AUTH=GSSAPI XPIG-ラテン
7.2.2. LIST Response
7.2.2. リスト応答
Contents: name attributes
hierarchy delimiter
name
コンテンツ: 名前属性階層構造デリミタ名
The LIST response occurs as a result of a LIST command. It
returns a single name that matches the LIST specification. There
can be multiple LIST responses for a single LIST command.
LIST応答はLISTコマンドの結果、起こります。 それはLIST仕様に合っているただ一つの名前を返します。 ただ一つの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.
\無印、メールボックスが最後の時間選択されたので、メールボックスはどんな追加メッセージも含んでいません。
Crispin Standards Track [Page 69] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[69ページ]RFC3501IMAPv4 March 2003
If it is not feasible for the server to determine whether or not
the mailbox is "interesting", or if the name is a \Noselect name,
the server SHOULD NOT send either \Marked or \Unmarked.
サーバが、メールボックスが「おもしろいかどうか」かそれとも、名前が\Noselect名であるかどうか決定するのが、可能でないなら、サーバSHOULD NOTは\Markedか\Unmarkedのどちらかを送ります。
The hierarchy delimiter is a character used to delimit levels of
hierarchy in a mailbox name. A client can use it to create child
mailboxes, and to search higher or lower levels of naming
hierarchy. All children of a top-level hierarchy node MUST use
the same separator character. A NIL hierarchy delimiter means
that no hierarchy exists; the name is a "flat" name.
階層構造デリミタはメールボックス名の階層構造のレベルを区切るのに使用されるキャラクタです。 クライアントは、子供メールボックスを作成して、より高いか下側のレベルの命名階層構造を捜すのにそれを使用できます。 トップレベル階層構造ノードのすべての子供が同じ分離符キャラクタを使用しなければなりません。 NIL階層構造デリミタは、階層構造が全く存在しないことを意味します。 名前は「平坦な」名前です。
The name represents an unambiguous left-to-right hierarchy, and
MUST be valid for use as a reference in LIST and LSUB commands.
Unless \Noselect is indicated, the name MUST also be valid as an
argument for commands, such as SELECT, that accept mailbox names.
名前は、左から右への明白な階層構造を表して、LISTとLSUBでの参照が命令するように使用に、妥当であるに違いありません。 また、\Noselectが示されない場合、名前もメールボックス名を受け入れるSELECTなどのコマンドのための議論として妥当であるに違いありません。
Example: S: * LIST (\Noselect) "/" ~/Mail/foo
例: S: * 「リスト(\Noselect)」/」 ~/Mail/foo
7.2.3. LSUB Response
7.2.3. LSUB応答
Contents: name attributes
hierarchy delimiter
name
コンテンツ: 名前属性階層構造デリミタ名
The LSUB response occurs as a result of an LSUB command. It
returns a single name that matches the LSUB specification. There
can be multiple LSUB responses for a single LSUB command. The
data is identical in format to the LIST response.
LSUB応答はLSUBコマンドの結果、起こります。 それはLSUB仕様に合っているただ一つの名前を返します。 ただ一つのLSUBコマンドのための複数のLSUB応答があることができます。 データは形式がLIST応答と同じです。
Example: S: * LSUB () "." #news.comp.mail.misc
例: S: * 「LSUB()」、」 #news.comp.mail.misc
7.2.4 STATUS Response
7.2.4 状態応答
Contents: name
status parenthesized list
コンテンツ: 名前状態はリストをparenthesizedしました。
The STATUS response occurs as a result of an STATUS command. It
returns the mailbox name that matches the STATUS specification and
the requested mailbox status information.
STATUS応答はSTATUSコマンドの結果、起こります。 それはSTATUS仕様と要求されたメールボックス状態情報に合っているメールボックス名を返します。
Example: S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292)
例: S: * STATUS blurdybloop(メッセージ231UIDNEXT44292)
Crispin Standards Track [Page 70] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[70ページ]RFC3501IMAPv4 March 2003
7.2.5. SEARCH Response
7.2.5. 検索応答
Contents: 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.6. FLAGS Response
7.2.6. 応答に旗を揚げさせます。
Contents: 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 can 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: * 旗(旗を揚げさせられた\\削除された\見られた\草稿に答えた\)
7.3. Server Responses - Mailbox Size
7.3. サーバ応答--メールボックスサイズ
These responses are always untagged. This is how changes in the size of the mailbox are transmitted from the server to the client. Immediately following the "*" token is a number that represents a message count.
これらの応答はいつも非タグ付けをされます。 これはメールボックスのサイズにおける変化がサーバからクライアントまでどう伝えられるかということです。 すぐに「*」トークンに続くのは、メッセージカウントを表す数です。
7.3.1. EXISTS Response
7.3.1. 存在、応答
Contents: none
コンテンツ: なし
The EXISTS response reports the number of messages in the mailbox.
This response occurs as a result of a SELECT or EXAMINE command,
and if the size of the mailbox changes (e.g., new messages).
EXISTS応答はメールボックスの中のメッセージの数を報告します。 SELECTかEXAMINEコマンドの結果とメールボックスのサイズが(例えば、新しいメッセージ)を変えるかどうかとしてこの応答は起こります。
The update from the EXISTS response MUST be recorded by the
client.
クライアントはEXISTS応答からのアップデートを記録しなければなりません。
Example: S: * 23 EXISTS
例: S: * 23は存在しています。
Crispin Standards Track [Page 71] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[71ページ]RFC3501IMAPv4 March 2003
7.3.2. RECENT Response
7.3.2. 最近の応答
Contents: none
コンテンツ: なし
The RECENT response reports the number of messages with the
\Recent flag set. This response occurs as a result of a SELECT or
EXAMINE command, and if the size of the mailbox changes (e.g., new
messages).
RECENT応答は、Recentが旗を揚げさせる\があるメッセージの数がセットしたと報告します。 SELECTかEXAMINEコマンドの結果とメールボックスのサイズが(例えば、新しいメッセージ)を変えるかどうかとしてこの応答は起こります。
Note: It is not guaranteed that the message sequence
numbers of recent messages will be a contiguous range of
the highest n messages in the mailbox (where n is the
value reported by the RECENT response). Examples of
situations in which this is not the case are: multiple
clients having the same mailbox open (the first session
to be notified will see it as recent, others will
probably see it as non-recent), and when the mailbox is
re-ordered by a non-IMAP agent.
以下に注意してください。 最近のメッセージのメッセージ通番がnメールボックス(nがRECENT応答で報告された値であるところ)で最も高いメッセージの隣接の範囲になるのが保証されません。 これがそうでない状況に関する例は以下の通りです。 同じメールボックスを持っている複数のクライアントが開きます、そして、(通知されるべき最初のセッションは、それが最近であるとみなして、他のものは、それが非最近であるとたぶんみなすでしょう)いつ、メールボックスがあるかは非IMAPエージェントに再注文されました。
The only reliable way to identify recent messages is to
look at message flags to see which have the \Recent flag
set, or to do a SEARCH RECENT.
最近のメッセージを特定する唯一の信頼できる方法は、Recent旗が設定した\を持っている見るメッセージ旗を見るか、またはSEARCH RECENTをすることです。
The update from the RECENT response MUST be recorded by the
client.
クライアントはRECENT応答からのアップデートを記録しなければなりません。
Example: S: * 5 RECENT
例: S: * 5、最近
7.4. Server Responses - Message Status
7.4. サーバ応答--メッセージ状態
These responses are always untagged. This is how message data are transmitted from the server to the client, often as a result of a command with the same name. Immediately following the "*" token is a number that represents a message sequence number.
これらの応答はいつも非タグ付けをされます。 これはメッセージデータがサーバからクライアントまでどう送られるかということです、しばしば同じ名前によるコマンドの結果、。 すぐに「*」トークンに続くのは、メッセージ通番を表す数です。
7.4.1. EXPUNGE Response
7.4.1. 応答を梢消してください。
Contents: none
コンテンツ: なし
The EXPUNGE response reports that the specified message sequence
number has been permanently removed from the mailbox. The message
sequence number for each successive message in the mailbox is
immediately decremented by 1, and this decrement is reflected in
message sequence numbers in subsequent responses (including other
untagged EXPUNGE responses).
EXPUNGE応答は、永久にメールボックスから指定されたメッセージ通番を取り除いてあると報告します。 メールボックスの中のそれぞれの連続したメッセージのためのメッセージ通番はすぐに1つ減少します、そして、この減少はその後の応答でメッセージ通番に反映されます(他のuntagged EXPUNGE応答を含んでいて)。
Crispin Standards Track [Page 72] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[72ページ]RFC3501IMAPv4 March 2003
The EXPUNGE response also decrements the number of messages in the
mailbox; it is not necessary to send an EXISTS response with the
new value.
また、EXPUNGE応答はメールボックスの中のメッセージの数を減少させます。 新しい値があるEXISTS応答を送るのは必要ではありません。
As a result of the immediate decrement rule, message sequence
numbers that appear in a set of successive EXPUNGE responses
depend upon whether the messages are removed starting from lower
numbers to higher numbers, or from higher numbers to lower
numbers. For example, if the last 5 messages in a 9-message
mailbox are expunged, a "lower to higher" server will send five
untagged EXPUNGE responses for message sequence number 5, whereas
a "higher to lower server" will send successive untagged EXPUNGE
responses for message sequence numbers 9, 8, 7, 6, and 5.
即座の減少規則の結果、連続したEXPUNGE応答のセットに現れるメッセージ通番は下側の数から、より大きい数までより大きい数から数を下げ始めて、メッセージが取り除かれるかどうかによります。 例えば、9メッセージのメールボックスにおける最後の5つのメッセージが梢消されると、「より高く下ろしてください」サーバはメッセージ通番5のために5つの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. A command is not "in progress" until the complete command
has been received; in particular, a command is not "in progress"
during the negotiation of command continuation.
コマンドが全く進行していなくて、FETCH、ストア、または検索命令に応じている間、EXPUNGE応答を送ってはいけません。 この規則が、クライアントとサーバの間のメッセージ通番の同期の損失を防ぐのに必要です。コマンドは完全なコマンドを受け取るまで「進行中ではありません」。 コマンドはコマンド継続の交渉の間、特に、「進行中ではありません」。
Note: UID FETCH, UID STORE, and UID SEARCH are different
commands from FETCH, STORE, and SEARCH. An EXPUNGE
response MAY be sent during a UID command.
以下に注意してください。 UID FETCH、UID STORE、およびUID SEARCHはFETCH、ストア、および検索からの異なったコマンドです。 UIDコマンドの間、EXPUNGE応答を送るかもしれません。
The update from the EXPUNGE response MUST be recorded by the
client.
クライアントはEXPUNGE応答からのアップデートを記録しなければなりません。
Example: S: * 44 EXPUNGE
例: S: * 44は梢消します。
7.4.2. FETCH Response
7.4.2. 応答をとって来てください。
Contents: message data
コンテンツ: メッセージデータ
The FETCH response returns data about a message to the client.
The data are pairs of data item names and their values in
parentheses. This response occurs as the result of a FETCH or
STORE command, as well as by unilateral server decision (e.g.,
flag updates).
FETCH応答はメッセージに関するデータをクライアントに返します。 データは、組のデータ項目名と括弧のそれらの値です。 FETCHかストアコマンドの結果、および一方的なサーバ決定(例えば、旗のアップデート)でこの応答は起こります。
The current data items are:
現在のデータ項目は以下の通りです。
BODY
A form of BODYSTRUCTURE without extension data.
拡大データのないBODYSTRUCTUREのBODY Aフォーム。
Crispin Standards Track [Page 73] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[73ページ]RFC3501IMAPv4 March 2003
BODY[<section>]<<origin octet>>
A string expressing the body contents of the specified section.
The string SHOULD be interpreted by the client according to the
content transfer encoding, body type, and subtype.
指定されたセクションのボディーコンテンツを言い表すBODY[<部の>]<<発生源八重奏>>五弦。 ストリングSHOULDは満足している転送コード化に従ってクライアントによって解釈されて、タイプを具体化させて、副タイプします。
If the origin octet is specified, this string is a substring of
the entire body contents, starting at that origin octet. This
means that BODY[]<0> MAY be truncated, but BODY[] is NEVER
truncated.
発生源八重奏が指定されるなら、このストリングは全身コンテンツに関するサブストリングです、その発生源八重奏から。 これは、BODY[]<0>が先端を切られるかもしれませんが、BODY[]は決して先端を切られないことを意味します。
Note: The origin octet facility MUST NOT be used by a server
in a FETCH response unless the client specifically requested
it by means of a FETCH of a BODY[<section>]<<partial>> data
item.
以下に注意してください。 クライアントがBODY[<部の>]の<の<の部分的な>>データ項目のFETCHによって明確にそれを要求しなかったなら、発生源八重奏施設はサーバによってFETCH応答に使用されてはいけません。
8-bit textual data is permitted if a [CHARSET] identifier is
part of the body parameter parenthesized list for this section.
Note that headers (part specifiers HEADER or MIME, or the
header portion of a MESSAGE/RFC822 part), MUST be 7-bit; 8-bit
characters are not permitted in headers. Note also that the
[RFC-2822] delimiting blank line between the header and the
body is not affected by header line subsetting; the blank line
is always included as part of header data, except in the case
of a message which has no body and no blank line.
8ビットの原文のデータは[CHARSET]識別子がこのセクションのためのボディーのパラメタのparenthesizedリストの一部であるなら受入れられます。 ヘッダー(パート特許説明書の作成書HEADER、MIME、またはMESSAGE/RFC822部分のヘッダー部分)が7ビットでなければならないことに注意してください。 8ビットのキャラクタはヘッダーで受入れられません。 また、[RFC-2822]区切りの空白の系列が副設定しながらヘッダーとボディーの間でヘッダー系列で影響を受けないことに注意してください。 空白行はヘッダー・データの一部としていつも含まれています、ボディーがなくて空白行を全く持っていないメッセージに関するケースを除いて。
Non-textual data such as binary data MUST be transfer encoded
into a textual form, such as BASE64, prior to being sent to the
client. To derive the original binary data, the client MUST
decode the transfer encoded string.
バイナリ・データなどの非原文のデータは原文のフォームにコード化された転送であるに違いありません、BASE64などのように、クライアントに送る前に。 オリジナルのバイナリ・データを引き出すために、クライアントは転送のコード化されたストリングを解読しなければなりません。
BODYSTRUCTURE
A parenthesized list that describes the [MIME-IMB] body
structure of a message. This is computed by the server by
parsing the [MIME-IMB] header fields, defaulting various fields
as necessary.
BODYSTRUCTURE Aはメッセージの[MIME-IMB]ボディー構造について説明するリストをparenthesizedしました。 これは[MIME-IMB]ヘッダーフィールドを分析するのによるサーバ、必要に応じてデフォルトの多岐によって計算されます。
For example, a simple text message of 48 lines and 2279 octets
can have a body structure of: ("TEXT" "PLAIN" ("CHARSET"
"US-ASCII") NIL NIL "7BIT" 2279 48)
例えば、48の系列と2279の八重奏の簡単なテキストメッセージは以下のボディー構造を持つことができます。 (「テキスト」「明瞭である」("CHARSET"「米国-ASCII」)無い無い「7ビット」2279 48)
Multiple parts are indicated by parenthesis nesting. Instead
of a body type as the first element of the parenthesized list,
there is a sequence of one or more nested body structures. The
second element of the parenthesized list is the multipart
subtype (mixed, digest, parallel, alternative, etc.).
複数の部品が挿入句巣篭もりで示されます。 parenthesizedリストの最初の要素としてのボディータイプの代わりに、1つ以上の入れ子にされたボディー構造の系列があります。 parenthesizedリストの2番目の要素は複合「副-タイプ」(混ぜられて、平行に代替手段などを読みこなす)です。
Crispin Standards Track [Page 74] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[74ページ]RFC3501IMAPv4 March 2003
For example, a two part message consisting of a text and a
BASE64-encoded text attachment can have a body structure of:
(("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 1152
23)("TEXT" "PLAIN" ("CHARSET" "US-ASCII" "NAME" "cc.diff")
"<960723163407.20117h@cac.washington.edu>" "Compiler diff"
"BASE64" 4554 73) "MIXED")
例えば、テキストから成る2部分メッセージとBASE64によってコード化されたテキスト付属は以下のボディー構造を持つことができます。 「(「テキスト」「明瞭である」("CHARSET"「米国-ASCII」)無い無い「7ビット」1152 23)、(「テキスト」「明瞭である」("CHARSET"「米国-ASCII」「名前」"cc.diff") "<960723163407.20117h@cac.washington.edu 、gt;、」 「コンパイラデフ」、「BASE64"4554 73) 「Mixed」、)、」
Extension data follows the multipart subtype. Extension data
is never returned with the BODY fetch, but can be returned with
a BODYSTRUCTURE fetch. Extension data, if present, MUST be in
the defined order. The extension data of a multipart body part
are in the following order:
拡大データは複合「副-タイプ」に続きます。 拡大データをBODYフェッチと共に決して返しませんが、BODYSTRUCTUREフェッチと共に返すことができます。 存在しているなら、拡大データは定義されたオーダーのそうであるに違いありません。 複合身体の部分に関する拡大データが以下のオーダーにあります:
body parameter parenthesized list
A parenthesized list of attribute/value pairs [e.g., ("foo"
"bar" "baz" "rag") where "bar" is the value of "foo", and
"rag" is the value of "baz"] as defined in [MIME-IMB].
ボディーのパラメタのparenthesizedリストAは[MIME-IMB]で定義されるように属性/値の組[例えば、「バー」が"foo"の値であり、「ぼろ切れ」が"baz"の値である("foo"「バー」"baz"「ぼろ切れ」)]のリストをparenthesizedしました。
body disposition
A parenthesized list, consisting of a disposition type
string, followed by a parenthesized list of disposition
attribute/value pairs as defined in [DISPOSITION].
ボディー気質Aはリストをparenthesizedしました、気質属性/価値の組のparenthesizedリストが[DISPOSITION]で定義されるようにあとに続いた気質タイプストリングから成って。
body language
A string or parenthesized list giving the body language
value as defined in [LANGUAGE-TAGS].
[LANGUAGE-TAGS]で定義されるようにボディー・ランゲージ値を与えるボディー・ランゲージAストリングかparenthesizedリスト。
body location
A string list giving the body content URI as defined in
[LOCATION].
[LOCATION]で定義されるようにボディー内容URIを与えるボディー位置の五弦リスト。
Any following extension data are not yet defined in this
version of the protocol. Such extension data can consist of
zero or more NILs, strings, numbers, or potentially nested
parenthesized lists of such data. Client implementations that
do a BODYSTRUCTURE fetch MUST be prepared to accept such
extension data. Server implementations MUST NOT send such
extension data until it has been defined by a revision of this
protocol.
少しの次の拡大データもプロトコルのこのバージョンでまだ定義されていません。 そのような拡大データがゼロから成ることができましたか、または、より多くのNILs、数の、または、潜在的に入れ子にされたストリングはそのようなデータのリストをparenthesizedしました。 そのような拡大データを受け入れるようにBODYSTRUCTUREフェッチをするクライアント実現を準備しなければなりません。 それがこのプロトコルの改正で定義されるまで、サーバ実現はそのような拡大データを送ってはいけません。
The basic fields of a non-multipart body part are in the
following order:
非複合の身体の部分の基礎体が以下のオーダーにあります:
body type
A string giving the content media type name as defined in
[MIME-IMB].
[MIME-IMB]で定義されるように満足しているメディアに型名を与えるボディータイプAストリング。
Crispin Standards Track [Page 75] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[75ページ]RFC3501IMAPv4 March 2003
body subtype
A string giving the content subtype name as defined in
[MIME-IMB].
[MIME-IMB]で定義されるように満足している「副-タイプ」名を与えるボディー「副-タイプ」Aストリング。
body parameter parenthesized list
A parenthesized list of attribute/value pairs [e.g., ("foo"
"bar" "baz" "rag") where "bar" is the value of "foo" and
"rag" is the value of "baz"] as defined in [MIME-IMB].
ボディーのパラメタのparenthesizedリストAは[MIME-IMB]で定義されるように属性/値の組[例えば、「バー」が"foo"と「ぼろ切れ」の値である("foo"「バー」"baz"「ぼろ切れ」)は"baz"の値である]のリストをparenthesizedしました。
body id
A string giving the content id as defined in [MIME-IMB].
[MIME-IMB]で定義されるように満足しているイドを与えるボディーイドAストリング。
body description
A string giving the content description as defined in
[MIME-IMB].
[MIME-IMB]で定義されるように満足している記述を与える身体的特徴Aストリング。
body encoding
A string giving the content transfer encoding as defined in
[MIME-IMB].
[MIME-IMB]で定義されるように満足している転送をコード化しているのに与える五弦をコード化するボディー。
body size
A number giving the size of the body in octets. Note that
this size is the size in its transfer encoding and not the
resulting size after any decoding.
八重奏における、ボディーのサイズを与えるボディーサイズA番号。 このサイズが転送コード化でサイズであり、どんな後のいずれの結果として起こるサイズも解読でないことに注意してください。
A body type of type MESSAGE and subtype RFC822 contains,
immediately after the basic fields, the envelope structure,
body structure, and size in text lines of the encapsulated
message.
タイプMESSAGEとsubtype RFC822のボディータイプは基礎体直後要約のメッセージのテキスト線に封筒構造、ボディー構造、およびサイズを含んでいます。
A body type of type TEXT contains, immediately after the basic
fields, the size of the body in text lines. Note that this
size is the size in its content transfer encoding and not the
resulting size after any decoding.
タイプTEXTのボディータイプは基礎体直後テキスト線における、ボディーのサイズを含んでいます。 このサイズがどんな解読の後の結果として起こるサイズではなく、満足している転送コード化でサイズであることにも注意してください。
Extension data follows the basic fields and the type-specific
fields listed above. Extension data is never returned with the
BODY fetch, but can be returned with a BODYSTRUCTURE fetch.
Extension data, if present, MUST be in the defined order.
拡大データは基礎体と上に記載されたタイプ特有の野原に続きます。 拡大データをBODYフェッチと共に決して返しませんが、BODYSTRUCTUREフェッチと共に返すことができます。 存在しているなら、拡大データは定義されたオーダーのそうであるに違いありません。
The extension data of a non-multipart body part are in the
following order:
非複合の身体の部分に関する拡大データが以下のオーダーにあります:
body MD5
A string giving the body MD5 value as defined in [MD5].
[MD5]で定義されるようにボディーMD5価値を与えるボディーMD5Aストリング。
Crispin Standards Track [Page 76] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[76ページ]RFC3501IMAPv4 March 2003
body disposition
A parenthesized list with the same content and function as
the body disposition for a multipart body part.
同じ内容があるボディーの気質のA parenthesizedリストと複合ボディーのためのボディー気質としての機能は離れています。
body language
A string or parenthesized list giving the body language
value as defined in [LANGUAGE-TAGS].
[LANGUAGE-TAGS]で定義されるようにボディー・ランゲージ値を与えるボディー・ランゲージAストリングかparenthesizedリスト。
body location
A string list giving the body content URI as defined in
[LOCATION].
[LOCATION]で定義されるようにボディー内容URIを与えるボディー位置の五弦リスト。
Any following extension data are not yet defined in this
version of the protocol, and would be as described above under
multipart extension data.
どんな次の拡大データも、プロトコルのこのバージョンでまだ定義されていなくて、上で複合拡大データの下で説明されるようにあるでしょう。
ENVELOPE
A parenthesized list that describes the envelope structure of a
message. This is computed by the server by parsing the
[RFC-2822] header into the component parts, defaulting various
fields as necessary.
ENVELOPE Aはメッセージの封筒構造について説明するリストをparenthesizedしました。 これは、必要に応じてコンポーネントの部品への[RFC-2822]ヘッダー、デフォルト多岐を分析することによって、サーバによって計算されます。
The fields of the envelope structure are in the following
order: date, subject, from, sender, reply-to, to, cc, bcc,
in-reply-to, and message-id. The date, subject, in-reply-to,
and message-id fields are strings. The from, sender, reply-to,
to, cc, and bcc fields are parenthesized lists of address
structures.
封筒構造の分野が以下のオーダーにあります: に対して日付、対象、送付者、答え、cc、bcc、イドを通信させます。 に対して日付、対象、メッセージイド分野はストリングです。 cc、およびbcc分野はそうです。送付者、答え、アドレス構造のリストをparenthesizedしました。
An address structure is a parenthesized list that describes an
electronic mail address. The fields of an address structure
are in the following order: personal name, [SMTP]
at-domain-list (source route), mailbox name, and host name.
アドレス構造は電子メールアドレスについて説明するparenthesizedリストです。 アドレス構造の分野が以下のオーダーにあります: 個人名、ドメインリスト(送信元経路)の[SMTP]メールボックス名、およびホスト名。
[RFC-2822] group syntax is indicated by a special form of
address structure in which the host name field is NIL. If the
mailbox name field is also NIL, this is an end of group marker
(semi-colon in RFC 822 syntax). If the mailbox name field is
non-NIL, this is a start of group marker, and the mailbox name
field holds the group name phrase.
[RFC-2822]グループ構文はホスト名前欄がNILである特別な形式のアドレス構造によって示されます。 また、メールボックス名前欄がNILであるなら、これはグループのマーカー(RFC822構文によるセミコロン)の端です。 メールボックス名前欄が非NILであるなら、これはグループのマーカーの始まりです、そして、メールボックス名前欄はグループ名句を保持します。
If the Date, Subject, In-Reply-To, and Message-ID header lines
are absent in the [RFC-2822] header, the corresponding member
of the envelope is NIL; if these header lines are present but
empty the corresponding member of the envelope is the empty
string.
Date、Subjectである、Inが答える、Message-IDヘッダー線が[RFC-2822]ヘッダーで欠けている、封筒の通信会員がNILである、。 これらのヘッダー線が現在ですが、人影がないなら、封筒の通信会員は空のストリングです。
Crispin Standards Track [Page 77] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[77ページ]RFC3501IMAPv4 March 2003
Note: some servers may return a NIL envelope member in the
"present but empty" case. Clients SHOULD treat NIL and
empty string as identical.
以下に注意してください。 いくつかのサーバが「現在にもかかわらず、空」の場合でNIL封筒メンバーを返すかもしれません。 クライアントSHOULDは同じであるとしてNILと空のストリングを扱います。
Note: [RFC-2822] requires that all messages have a valid
Date header. Therefore, the date member in the envelope can
not be NIL or the empty string.
以下に注意してください。 [RFC-2822]は、すべてのメッセージには有効なDateヘッダーがあるのを必要とします。 したがって、封筒の日付のメンバーは、NILか空のストリングであるはずがありません。
Note: [RFC-2822] requires that the In-Reply-To and
Message-ID headers, if present, have non-empty content.
Therefore, the in-reply-to and message-id members in the
envelope can not be the empty string.
以下に注意してください。 そして、[RFC-2822]がそれを必要とする、Inが答える、Message-IDヘッダーには、存在しているなら、非空の内容があります。 そして、に対してしたがって、封筒のメッセージイドメンバーは空のストリングであるはずがありません。
If the From, To, cc, and bcc header lines are absent in the
[RFC-2822] header, or are present but empty, the corresponding
member of the envelope is NIL.
From、To、cc、およびbccヘッダー線が[RFC-2822]ヘッダーで欠けるか、現在にもかかわらず、または人影がないなら、封筒の通信会員はNILです。
If the Sender or Reply-To lines are absent in the [RFC-2822]
header, or are present but empty, the server sets the
corresponding member of the envelope to be the same value as
the from member (the client is not expected to know to do
this).
または、Senderである、Reply、-、線が[RFC-2822]ヘッダーで欠けるか、現在にもかかわらず、または人影がありません、サーバが封筒の通信会員に同じ値であるように設定する、メンバー(クライアントが、これをするのを知らないと予想される)から。
Note: [RFC-2822] requires that all messages have a valid
From header. Therefore, the from, sender, and reply-to
members in the envelope can not be NIL.
以下に注意してください。 [RFC-2822]は、すべてのメッセージには有効なFromヘッダーがあるのを必要とします。 封筒でメンバーに答えてください。したがって、送付者、NILであることができません。
FLAGS
A parenthesized list of flags that are set for this message.
FLAGS Aはこのメッセージに設定される旗のリストをparenthesizedしました。
INTERNALDATE
A string representing the internal date of the message.
メッセージの内部の期日を表すINTERNALDATE五弦。
RFC822
Equivalent to BODY[].
ボディー[]に同等なRFC822。
RFC822.HEADER
Equivalent to BODY[HEADER]. Note that this did not result in
\Seen being set, because RFC822.HEADER response data occurs as
a result of a FETCH of RFC822.HEADER. BODY[HEADER] response
data occurs as a result of a FETCH of BODY[HEADER] (which sets
\Seen) or BODY.PEEK[HEADER] (which does not set \Seen).
ボディー[ヘッダー]に同等なRFC822.HEADER。 これが用意ができている\Seenをもたらさなかったことに注意してください、RFC822.HEADER応答データがRFC822.HEADERのFETCHの結果、現れるので。 BODY[HEADER]応答データはBODY[HEADER](\Seenを設定する)かBODY.PEEK[HEADER](\Seenを設定しない)のFETCHの結果、現れます。
RFC822.SIZE
A number expressing the [RFC-2822] size of the message.
メッセージの[RFC-2822]サイズを表すRFC822.SIZE A番号。
Crispin Standards Track [Page 78] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[78ページ]RFC3501IMAPv4 March 2003
RFC822.TEXT
Equivalent to BODY[TEXT].
ボディー[テキスト]に同等なRFC822.TEXT。
UID
A number expressing the unique identifier of the message.
メッセージのユニークな識別子を言い表すUID A番号。
Example: S: * 23 FETCH (FLAGS (\Seen) RFC822.SIZE 44827)
例: S: * 23フェッチ(RFC822.SIZE44827に旗を揚げさせます(見られた\))
7.5. Server Responses - Command Continuation Request
7.5. サーバ応答--コマンド継続要求
The command continuation request response is indicated by a "+" token instead of a tag. This form of response indicates that the server is ready to accept the continuation of a command from the client. The remainder of this response is a line of text.
コマンド継続要求応答はタグの代わりに「+」象徴によって示されます。 この形式の応答は、サーバをクライアントからコマンドの継続を受け入れる準備ができているのを示します。 この応答の残りはテキスト行です。
This response is used in the AUTHENTICATE command to transmit server data to the client, and request additional client data. This response is also used if an argument to any command is a literal.
この応答はサーバデータをクライアントに送って、追加クライアントデータを要求するAUTHENTICATEコマンドに使用されます。 また、どんなコマンドへの議論もa文字通りなら、この応答は使用されます。
The client is not permitted to send the octets of the literal unless the server indicates that it is expected. This permits the server to process commands and reject errors on a line-by-line basis. The remainder of the command, including the CRLF that terminates a command, follows the octets of the literal. If there are any additional command arguments, the literal octets are followed by a space and those arguments.
サーバが、それが予想されるのを示さない場合、クライアントが文字通りの八重奏を送ることが許可されません。 これは、サーバが1行ずつベースでコマンドを処理して、誤りを拒絶することを許可します。 コマンドを終えるCRLFを含むコマンドの残りは文字通りの八重奏に続きます。 何か追加コマンド議論があれば、スペースとそれらの議論は文字通りの八重奏のあとに続いています。
Example: C: A001 LOGIN {11}
S: + Ready for additional command text
C: FRED FOOBAR {7}
S: + Ready for additional command text
C: fat man
S: A001 OK LOGIN completed
C: A044 BLURDYBLOOP {102856}
S: A044 BAD No such command as "BLURDYBLOOP"
例: C: A001ログイン11S: +は追加コマンドテキストのためにCを準備します: フレッドFOOBAR7S: +は追加コマンドテキストのためにCを準備します: 太った男の人S: A001 OK LOGINはCを完成しました: A044 BLURDYBLOOP102856S: そのようなものが"BLURDYBLOOP"として命令するA044 BADノー
Crispin Standards Track [Page 79] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[79ページ]RFC3501IMAPv4 March 2003
8. Sample IMAP4rev1 connection
8. サンプルIMAP4rev1接続
The following is a transcript of an IMAP4rev1 connection. A long line in this sample is broken for editorial clarity.
↓これはIMAP4rev1接続の転写です。 このサンプルの長い線は編集の明快ために壊されます。
S: * OK IMAP4rev1 Service Ready
C: a001 login mrc secret
S: a001 OK LOGIN completed
C: a002 select inbox
S: * 18 EXISTS
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * 2 RECENT
S: * OK [UNSEEN 17] Message 17 is the first unseen message
S: * OK [UIDVALIDITY 3857529045] UIDs valid
S: a002 OK [READ-WRITE] SELECT completed
C: a003 fetch 12 full
S: * 12 FETCH (FLAGS (\Seen) INTERNALDATE "17-Jul-1996 02:44:25 -0700"
RFC822.SIZE 4286 ENVELOPE ("Wed, 17 Jul 1996 02:23:25 -0700 (PDT)"
"IMAP4rev1 WG mtg summary and minutes"
(("Terry Gray" NIL "gray" "cac.washington.edu"))
(("Terry Gray" NIL "gray" "cac.washington.edu"))
(("Terry Gray" NIL "gray" "cac.washington.edu"))
((NIL NIL "imap" "cac.washington.edu"))
((NIL NIL "minutes" "CNRI.Reston.VA.US")
("John Klensin" NIL "KLENSIN" "MIT.EDU")) NIL NIL
"<B27397-0100000@cac.washington.edu>")
BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 3028
92))
S: a003 OK FETCH completed
C: a004 fetch 12 body[header]
S: * 12 FETCH (BODY[HEADER] {342}
S: Date: Wed, 17 Jul 1996 02:23:25 -0700 (PDT)
S: From: Terry Gray <gray@cac.washington.edu>
S: Subject: IMAP4rev1 WG mtg summary and minutes
S: To: imap@cac.washington.edu
S: cc: minutes@CNRI.Reston.VA.US, John Klensin <KLENSIN@MIT.EDU>
S: Message-Id: <B27397-0100000@cac.washington.edu>
S: MIME-Version: 1.0
S: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
S:
S: )
S: a004 OK FETCH completed
C: a005 store 12 +flags \deleted
S: * 12 FETCH (FLAGS (\Seen \Deleted))
S: a005 OK +FLAGS completed
C: a006 logout
S: * BYE IMAP4rev1 server terminating connection
S: a006 OK LOGOUT completed
S: * IMAP4rev1のサービスの持ち合わせのCを承認してください: a001ログインmrc秘密S: a001OK LOGINはCを完成しました: a002の選んだ受信トレイS: * 18が存在している、S: * 旗(\に答えた\は\削除された\見られた\草稿に旗を揚げさせた)のS: * 2、最近のS: * OK[UNSEEN17]メッセージ17は最初の見えないメッセージSです: * OK[UIDVALIDITY3857529045]のUIDs有効なS: a002OK[READ-WRITE]SELECTはCを完成しました: a003フェッチ12の完全なS: * 12フェッチ; (FLAGS(\Seen)INTERNALDATE「1996年7月17日02:44:25 -0700」RFC822.SIZE4286ENVELOPE、(「水曜日、1996年7月17日、02:23:25 -0700(太平洋夏時間の) 」 「IMAP4rev1 WG mtg概要と数分」((「Terryグレー」NIL「グレー」"cac.washington.edu"))((「Terryグレー」NIL「グレー」"cac.washington.edu"))、(「Terryグレー」NILは「高齢化します」; 「"cac.washington.edu") ((無"imap"無"cac.washington.edu"))(「数分」「CNRI.Reston.VA.US」無無)(「ジョンKlensin」無"KLENSIN""MIT.EDU")無 "<B27397-0100000@cac.washington.edu 無、gt;、」、)、ボディー(「テキスト」「明瞭である」("CHARSET"「米国-ASCII」)無い無い「7ビット」3028 92); S: a003OK FETCHはCを完成しました: a004フェッチ12ボディー[ヘッダー]S: * 12FETCH、(BODY[HEADER]342S: 1996年7月17日02:23:25 -0700(太平洋夏時間の)のS: From: 日付: 水曜日、テリー Gray <gray@cac.washington.edu 、gt;、S: Subject: IMAP4rev1 WG mtg概要と数分S(To: imap@cac.washington.edu S: cc: minutes@CNRI.Reston.VA.US 、ジョン Klensin <KLENSIN@MIT.EDU 、)gt;、S: メッセージイド: <B27397-0100000@cac.washington.edu 、gt;、S: MIMEバージョン: 1.0秒間:コンテントタイプ:TEXT/PLAIN; CHARSETは米国のASCIIのS: Sと等しいです:、)、S: a004OK FETCHはCを完成しました: a005店12+旗の\はSを削除しました: * 12は(旗(目にふれている\が削除した\))にSをとって来ます: a005OK+FLAGSはCを完成しました: a006がログアウトする、S: * 接続Sを終えるBYE IMAP4rev1サーバ: OK LOGOUTが完成したa006
Crispin Standards Track [Page 80] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[80ページ]RFC3501IMAPv4 March 2003
9. Formal Syntax
9. 正式な構文
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [ABNF].
以下の構文仕様は[ABNF]の指定されるとしてのAugmented BN記法(ABNF)記法を使用します。
In the case of alternative or optional rules in which a later rule overlaps an earlier rule, the rule which is listed earlier MUST take priority. For example, "\Seen" when parsed as a flag is the \Seen flag name and not a flag-extension, even though "\Seen" can be parsed as a flag-extension. Some, but not all, instances of this rule are noted below.
後の規則が以前の規則を重ね合わせる代替の、または、任意の規則の場合では、より早く記載される規則は優先しなければなりません。 見られて、」 旗として分析された時は旗拡大ではなく、\Seen旗の名であり、」 \ですが、見ました。「例えば」、\、」 旗拡大として分析できます。 例ではなく、この規則のいくつかが以下に述べられます。
Note: [ABNF] rules MUST be followed strictly; in
particular:
以下に注意してください。 厳密に[ABNF]規則に従わなければなりません。 特に:
(1) Except as noted otherwise, all alphabetic characters
are case-insensitive. The use of upper or lower case
characters to define token strings is for editorial clarity
only. Implementations MUST accept these strings in a
case-insensitive fashion.
(1) 別の方法で注意されるのを除いて、すべての英字が大文字と小文字を区別しないです。 象徴ストリングを定義する上側の、または、下側のケースキャラクタの使用は編集の明快だけのためのものです。 実現は大文字と小文字を区別しないファッションでこれらのストリングを受け入れなければなりません。
(2) In all cases, SP refers to exactly one space. It is
NOT permitted to substitute TAB, insert additional spaces,
or otherwise treat SP as being equivalent to LWSP.
(2) すべての場合では、SPはまさに1つのスペースについて言及します。 それは、TABを代入するか、追加空間を挿入するか、またはそうでなければ、LWSPに同等であるとしてSPを扱うことが許可されていません。
(3) The ASCII NUL character, %x00, MUST NOT be used at any
time.
(3) いつでも、ASCII NULキャラクタ(%x00)を使用してはいけません。
address = "(" addr-name SP addr-adl SP addr-mailbox SP
addr-host ")"
アドレスは「(「addr-名前SP addr-adl SP addr-メールボックスSP addr-ホスト」)」と等しいです。
addr-adl = nstring
; Holds route from [RFC-2822] route-addr if
; non-NIL
addr-adlはnstringと等しいです。 船倉が[RFC-2822]からルート-addrを発送する、。 非無
addr-host = nstring
; NIL indicates [RFC-2822] group syntax.
; Otherwise, holds [RFC-2822] domain name
addr-ホストはnstringと等しいです。 NILは[RFC-2822]グループ構文を示します。 ; そうでなければ、船倉[RFC-2822]ドメイン名
addr-mailbox = nstring
; NIL indicates end of [RFC-2822] group; if
; non-NIL and addr-host is NIL, holds
; [RFC-2822] group name.
; Otherwise, holds [RFC-2822] local-part
; after removing [RFC-2822] quoting
addr-メールボックスはnstringと等しいです。 NILは[RFC-2822]グループの終わりを示します。 。 非NILとaddr-ホストはNIL、船倉です。 [RFC-2822]グループ名。 ; そうでなければ、船倉[RFC-2822]の地方の部分。 取り外し[RFC-2822]引用の後に
Crispin Standards Track [Page 81] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[81ページ]RFC3501IMAPv4 March 2003
addr-name = nstring
; If non-NIL, holds phrase from [RFC-2822]
; mailbox after removing [RFC-2822] quoting
addr-名前はnstringと等しいです。 非NILであるなら、[RFC-2822]からの船倉句です。 [RFC-2822]引用を取り除いた後のメールボックス
append = "APPEND" SP mailbox [SP flag-list] [SP date-time] SP
literal
文字通りで「追加=」SPメールボックス[SP現役将官名簿][SP日付-時間]SPを追加してください。
astring = 1*ASTRING-CHAR / string
astringは1*ASTRING-CHAR/ストリングと等しいです。
ASTRING-CHAR = ATOM-CHAR / resp-specials
ASTRING-CHARはATOM-CHAR / resp-特別番組と等しいです。
atom = 1*ATOM-CHAR
原子=1*ATOM-CHAR
ATOM-CHAR = <any CHAR except atom-specials>
ATOM-CHAR=<は原子スペシャル>以外のあらゆるCHARです。
atom-specials = "(" / ")" / "{" / SP / CTL / list-wildcards /
quoted-specials / resp-specials
原子スペシャルが「(「/」)」/と等しい、「「resp引用された/ SP / CTL / list-ワイルドカード/特別番組/スペシャル」
authenticate = "AUTHENTICATE" SP auth-type *(CRLF base64)
=「認証」SP auth-タイプ*を認証してください。(CRLF base64)
auth-type = atom
; Defined by [SASL]
auth-タイプは原子と等しいです。 定義されます。[SASL]
base64 = *(4base64-char) [base64-terminal]
base64は*と等しいです(4base64-炭)。[base64-端末]
base64-char = ALPHA / DIGIT / "+" / "/"
; Case-sensitive
「base64-炭=アルファー/ DIGIT /「+」/」/、」、。 大文字と小文字を区別
base64-terminal = (2base64-char "==") / (3base64-char "=")
base64-端末=(2base64-炭の「=」)/(3base64-炭の「=」)
body = "(" (body-type-1part / body-type-mpart) ")"
「(「(ボディータイプボディータイプ1part/mpart)」)」というボディー=
body-extension = nstring / number /
"(" body-extension *(SP body-extension) ")"
; Future expansion. Client implementations
; MUST accept body-extension fields. Server
; implementations MUST NOT generate
; body-extension fields except as defined by
; future standard or standards-track
; revisions of this specification.
ボディー拡大はnstring/数の/と等しいです「(「ボディー拡大*(SPボディー拡張子)」)」という。 今後の拡大。 クライアント実現。 ボディー拡大野原を受け入れなければなりません。 サーバ。 実現、発生してはいけません。 ボディー拡大分野は定義されるように除かれます。 将来の規格か標準化過程。 この仕様の改正。
body-ext-1part = body-fld-md5 [SP body-fld-dsp [SP body-fld-lang
[SP body-fld-loc *(SP body-extension)]]]
; MUST NOT be returned on non-extensible
; "BODY" fetch
ボディー-ext-1partはボディー-fld-md5と等しいです[SPボディー-fld-dsp[SPボディー-fld-lang[SPボディー-fld-loc*(SPボディー拡張子)]]]。 非広げることができるところで返してはいけません。 "BODY"フェッチ
Crispin Standards Track [Page 82] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[82ページ]RFC3501IMAPv4 March 2003
body-ext-mpart = body-fld-param [SP body-fld-dsp [SP body-fld-lang
[SP body-fld-loc *(SP body-extension)]]]
; MUST NOT be returned on non-extensible
; "BODY" fetch
ボディー-ext-mpartはボディー-fld-paramと等しいです[SPボディー-fld-dsp[SPボディー-fld-lang[SPボディー-fld-loc*(SPボディー拡張子)]]]。 非広げることができるところで返してはいけません。 "BODY"フェッチ
body-fields = body-fld-param SP body-fld-id SP body-fld-desc SP
body-fld-enc SP body-fld-octets
ボディー分野はボディー-fld-param SPボディーfldイドSPボディー-fld-desc SPボディー-fld-enc SPボディーfld八重奏と等しいです。
body-fld-desc = nstring
ボディー-fld-descはnstringと等しいです。
body-fld-dsp = "(" string SP body-fld-param ")" / nil
「(「ストリングSPボディー-fld-param」)」というボディー-fld-dsp=/無いです。
body-fld-enc = (DQUOTE ("7BIT" / "8BIT" / "BINARY" / "BASE64"/
"QUOTED-PRINTABLE") DQUOTE) / string
ボディー-fld-encが等しい、(DQUOTE、(「「引用されて印刷可能な」BASE64"/) DQUOTE) /は結ぶ」「7ビット」/「8ビット」/「バイナリー」/
body-fld-id = nstring
ボディーfldイド=nstring
body-fld-lang = nstring / "(" string *(SP string) ")"
ボディー-fld-langは/をnstringするのと等しいです「(「ストリング*(SPストリング)」)」という。
body-fld-loc = nstring
ボディー-fld-locはnstringと等しいです。
body-fld-lines = number
ボディーfld線は数と等しいです。
body-fld-md5 = nstring
ボディー-fld-md5はnstringと等しいです。
body-fld-octets = number
ボディーfld八重奏は数と等しいです。
body-fld-param = "(" string SP string *(SP string SP string) ")" / nil
「(「ストリングSPストリング*(SPストリングSPストリング)」)」というボディー-fld-param=/無いです。
body-type-1part = (body-type-basic / body-type-msg / body-type-text)
[SP body-ext-1part]
ボディータイプ1partは(ボディーが基本的にタイプしている/ボディータイプボディータイプmsg/テキスト)と等しいです。[SPボディー-ext-1part]
body-type-basic = media-basic SP body-fields
; MESSAGE subtype MUST NOT be "RFC822"
ボディーが基本的にタイプしている=メディア基本的なSPボディー分野。 MESSAGE subtypeは"RFC822"であるはずがありません。
body-type-mpart = 1*body SP media-subtype
[SP body-ext-mpart]
ボディータイプmpartは1*ボディーSPメディア-「副-タイプ」と等しいです。[SPボディー-ext-mpart]
body-type-msg = media-message SP body-fields SP envelope
SP body SP body-fld-lines
ボディータイプmsgはメディアメッセージSPボディー分野SP封筒SPボディーSPボディーfld行と等しいです。
body-type-text = media-text SP body-fields SP body-fld-lines
ボディータイプテキストはメディアテキストSPボディー分野SPボディーfld線と等しいです。
capability = ("AUTH=" auth-type) / atom
; New capabilities MUST begin with "X" or be
; registered with IANA as standard or
; standards-track
能力は/原子と等しいです(「AUTH=」auth-タイプ)。 新しい能力は、「X」と共に始まるに違いないか、またはあるに違いありません。 または、標準の同じくらいIANAとともに記名する、。 標準化過程
Crispin Standards Track [Page 83] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[83ページ]RFC3501IMAPv4 March 2003
capability-data = "CAPABILITY" *(SP capability) SP "IMAP4rev1"
*(SP capability)
; Servers MUST implement the STARTTLS, AUTH=PLAIN,
; and LOGINDISABLED capabilities
; Servers which offer RFC 1730 compatibility MUST
; list "IMAP4" as the first capability.
能力データが「能力」*(SP能力)SPと等しい、「IMAP4rev1"*(SP能力)」。 サーバはSTARTTLS、AUTH=PLAINを実行しなければなりません。 LOGINDISABLED能力。 RFC1730に互換性を提供するサーバはそうしなければなりません。 「最初の能力としてのIMAP4"」を記載してください。
CHAR8 = %x01-ff
; any OCTET except NUL, %x00
CHAR8は%x01ffと等しいです。 NUL以外のどんなOCTET、%x00
command = tag SP (command-any / command-auth / command-nonauth /
command-select) CRLF
; Modal based on state
コマンドはタグSP(コマンドコマンドコマンドいくらかコマンド/auth/nonauth/選んだ)CRLFと等しいです。 状態に基づいて、モーダルです。
command-any = "CAPABILITY" / "LOGOUT" / "NOOP" / x-command
; Valid in all states
いくらかコマンドはx「能力」/「ログアウト」/"NOOP"/コマンドと等しいです。 すべての州では、有効です。
command-auth = append / create / delete / examine / list / lsub /
rename / select / status / subscribe / unsubscribe
; Valid only in Authenticated or Selected state
=が追加するか、作成する、削除する、調べる、または記載するコマンド-auth/ lsub /は状態/が申し込むか、または外す/を改名するか、または選択します。 AuthenticatedかSelected状態だけでは、有効です。
command-nonauth = login / authenticate / "STARTTLS"
; Valid only when in Not Authenticated state
コマンド-nonauth=ログイン/は/「STARTTLS」を認証します。 Not Authenticated状態でだけ有効です。
command-select = "CHECK" / "CLOSE" / "EXPUNGE" / copy / fetch / store /
uid / search
; Valid only when in Selected state
コマンド選んだ=は、/ uid /検索を「チェックする」か、「閉じる」、「梢消する」、コピーする、とって来る、または格納します。 Selected状態でだけ有効です。
continue-req = "+" SP (resp-text / base64) CRLF
「+」 reqが継続的な=SP(resp-テキスト/base64)CRLF
copy = "COPY" SP sequence-set SP mailbox
コピーは「コピー」SPシーケンスセットSPメールボックスと等しいです。
create = "CREATE" SP mailbox
; Use of INBOX gives a NO error
「作成=」SPメールボックスを作成してください。 受信トレイの使用はいいえ誤りを与えます。
date = date-text / DQUOTE date-text DQUOTE
DQUOTE日付日付=日付テキスト/テキストDQUOTE
date-day = 1*2DIGIT
; Day of month
日付-日は1*2DIGITと等しいです。 月の日
date-day-fixed = (SP DIGIT) / 2DIGIT
; Fixed-format version of date-day
日付の日が固定された=(SP DIGIT)/2DIGIT。 日付-日の固定フォーマットバージョン
date-month = "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" /
"Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec"
日付-月=「1月」/「2月」/「3月」/「4月」/「5月」/「6月」/「7月」/「8月」/「9月」/「10月」/「11月」/「12月」
date-text = date-day "-" date-month "-" date-year
日付テキスト=日付-日「-」日付-月の「-」日付-年
Crispin Standards Track [Page 84] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[84ページ]RFC3501IMAPv4 March 2003
date-year = 4DIGIT
日付-年=4DIGIT
date-time = DQUOTE date-day-fixed "-" date-month "-" date-year
SP time SP zone DQUOTE
日付-時間はDQUOTE日付の日が固定された「-」日付-月の「-」SP時間日付-年のSPゾーンDQUOTEと等しいです。
delete = "DELETE" SP mailbox
; Use of INBOX gives a NO error
「削除=」SPメールボックスを削除してください。 受信トレイの使用はいいえ誤りを与えます。
digit-nz = %x31-39
; 1-9
ケタ-nz=%x31-39。 1-9
envelope = "(" env-date SP env-subject SP env-from SP
env-sender SP env-reply-to SP env-to SP env-cc SP
env-bcc SP env-in-reply-to SP env-message-id ")"
に対して封筒=、「(「env-日付のSP env-対象、SP env、-、SP env-送付者、SP envが答える、SP env、-、SP env-cc、SP env-bcc SP env、-、SP envメッセージイド、」、)、」
env-bcc = "(" 1*address ")" / nil
env-bcc=「(「1*アドレス」)」/無
env-cc = "(" 1*address ")" / nil
env-cc=「(「1*アドレス」)」/無
env-date = nstring
env-日付=nstring
env-from = "(" 1*address ")" / nil
env、-、=「(「1*アドレス」)」/無
env-in-reply-to = nstring
に対してenv、-、=nstring
env-message-id = nstring
envメッセージイド=nstring
env-reply-to = "(" 1*address ")" / nil
envに答える、=「(「1*アドレス」)」/無
env-sender = "(" 1*address ")" / nil
env-送付者=「(「1*アドレス」)」/無
env-subject = nstring
env-対象=nstring
env-to = "(" 1*address ")" / nil
env、-、=「(「1*アドレス」)」/無
examine = "EXAMINE" SP mailbox
「審査=」SPメールボックスを調べてください。
fetch = "FETCH" SP sequence-set SP ("ALL" / "FULL" / "FAST" /
fetch-att / "(" fetch-att *(SP fetch-att) ")")
=「フェッチ」SPシーケンスセットSPをとって来てください。(「(「フェッチ-att*(SPフェッチ-att)」)」という「完全である」か「すべて」/「速い」/フェッチ-att/)
fetch-att = "ENVELOPE" / "FLAGS" / "INTERNALDATE" /
"RFC822" [".HEADER" / ".SIZE" / ".TEXT"] /
"BODY" ["STRUCTURE"] / "UID" /
"BODY" section ["<" number "." nz-number ">"] /
"BODY.PEEK" section ["<" number "." nz-number ">"]
「フェッチ-attは"BODY.PEEK"が区分する「封筒」/「旗」/"INTERNALDATE"/"RFC822"[".HEADER"/".SIZE"/".TEXT"]/「ボディー」[「構造」]/"UID"/「ボディー」セクション[」 . 」 "<"番号nz-数の">"]/と等しいです。「[」 . 」 "<"番号nz-数の">"]
Crispin Standards Track [Page 85] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[85ページ]RFC3501IMAPv4 March 2003
flag = "\Answered" / "\Flagged" / "\Deleted" /
"\Seen" / "\Draft" / flag-keyword / flag-extension
; Does not include "\Recent"
「」 旗=\は」 」 \が旗を揚げさせた/に」 /に答えた」という\が」 /を削除した、」 \、」 /を見る、」 \は」 旗/旗キーワード/拡大を作成します。 「どんなインクルードにも最近で」 \をしません」
flag-extension = "\" atom
; Future expansion. Client implementations
; MUST accept flag-extension flags. Server
; implementations MUST NOT generate
; flag-extension flags except as defined by
; future standard or standards-track
; revisions of this specification.
旗拡大は「\」原子と等しいです。 今後の拡大。 クライアント実現。 旗拡大旗を受け入れなければなりません。 サーバ。 実現、発生してはいけません。 定義されるのを除いて、旗拡大は弛みます。 将来の規格か標準化過程。 この仕様の改正。
flag-fetch = flag / "\Recent"
「=旗/に最近で」 \を旗でとって来てください」
flag-keyword = atom
旗キーワード=原子
flag-list = "(" [flag *(SP flag)] ")"
現役将官名簿は「(「[旗*(SPは弛みます)]」)」と等しいです。
flag-perm = flag / "\*"
「旗パーマ=旗/」\*、」
greeting = "*" SP (resp-cond-auth / resp-cond-bye) CRLF
挨拶=「*」SP(resp-cond-auth / resp-cond-さようなら)CRLF
header-fld-name = astring
ヘッダーfld名=astring
header-list = "(" header-fld-name *(SP header-fld-name) ")"
「(「ヘッダーfld名の*(SPヘッダーfld名)」)」というヘッダーリスト=
list = "LIST" SP mailbox SP list-mailbox
リスト=「リスト」SPメールボックスSPリストメールボックス
list-mailbox = 1*list-char / string
リストメールボックス=1*リスト炭/ストリング
list-char = ATOM-CHAR / list-wildcards / resp-specials
リスト炭はrespリストATOM-CHAR/ワイルドカード/スペシャルと等しいです。
list-wildcards = "%" / "*"
リストワイルドカード=「%」/「*」
literal = "{" number "}" CRLF *CHAR8
; Number represents the number of CHAR8s
文字通りの=はCRLF*CHAR8に「「付番」」。 数はCHAR8sの数を表します。
login = "LOGIN" SP userid SP password
ログイン=「ログイン」SPユーザID SPパスワード
lsub = "LSUB" SP mailbox SP list-mailbox
lsubは"LSUB"SPメールボックスSPリストメールボックスと等しいです。
Crispin Standards Track [Page 86] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[86ページ]RFC3501IMAPv4 March 2003
mailbox = "INBOX" / astring
; INBOX is case-insensitive. All case variants of
; INBOX (e.g., "iNbOx") MUST be interpreted as INBOX
; not as an astring. An astring which consists of
; the case-insensitive sequence "I" "N" "B" "O" "X"
; is considered to be INBOX and not an astring.
; Refer to section 5.1 for further
; semantic details of mailbox names.
メールボックスは「受信トレイ」/astringと等しいです。 受信トレイは大文字と小文字を区別しないです。 異形をすべてケースに入れます。 受信トレイとして受信トレイ(例えば、「受信トレイ」)を解釈しなければなりません。 astringとしてでない。 どれをastringするかが成る、。 大文字と小文字を区別しない系列「I」「N」「B」「O」「X」。 astringではなく、受信トレイであると考えられます。 ; 参照、さらに5.1を区分するために。 メールボックス名の意味詳細。
mailbox-data = "FLAGS" SP flag-list / "LIST" SP mailbox-list /
"LSUB" SP mailbox-list / "SEARCH" *(SP nz-number) /
"STATUS" SP mailbox SP "(" [status-att-list] ")" /
number SP "EXISTS" / number SP "RECENT"
メールボックスデータ=は"LSUB"SPメールボックス「リスト」SPメールボックスSP現役将官名簿/リスト/リスト/「検索」*(SP nz-数)/「状態」SPメールボックスに「存在数のSP」/数のSP「(「[状態attリスト]」)」というSP/「最近」で「旗を揚げさせます」。
mailbox-list = "(" [mbx-list-flags] ")" SP
(DQUOTE QUOTED-CHAR DQUOTE / nil) SP mailbox
「(「[mbxリスト旗]」)」というメールボックスリスト=SP(DQUOTE QUOTED-CHAR DQUOTE/無)SPメールボックス
mbx-list-flags = *(mbx-list-oflag SP) mbx-list-sflag
*(SP mbx-list-oflag) /
mbx-list-oflag *(SP mbx-list-oflag)
mbxリスト旗は*(mbxリストoflag SP)mbxリストsflag*(SP mbxリストoflag)/mbxリストoflag*と等しいです。(SP mbxリストoflag)
mbx-list-oflag = "\Noinferiors" / flag-extension
; Other flags; multiple possible per LIST response
「」 mbxリストoflag=\Noinferiors」/旗拡大。 他の旗。 LIST応答あたり可能な倍数
mbx-list-sflag = "\Noselect" / "\Marked" / "\Unmarked"
; Selectability flags; only one per LIST response
」 \が」 /であるとマークした「」 mbxリストsflag=\Noselect」/、」、\無印、」、。 Selectabilityは弛みます。 LIST応答あたり1つだけ
media-basic = ((DQUOTE ("APPLICATION" / "AUDIO" / "IMAGE" /
"MESSAGE" / "VIDEO") DQUOTE) / string) SP
media-subtype
; Defined in [MIME-IMT]
メディア基本的な=(DQUOTE(「アプリケーション」/「オーディオ」/「イメージ」/「メッセージ」/「ビデオ」)DQUOTE)/ストリング) SPメディア-「副-タイプ」。 中では、定義されます。[MIME-IMT]
media-message = DQUOTE "MESSAGE" DQUOTE SP DQUOTE "RFC822" DQUOTE
; Defined in [MIME-IMT]
メディアメッセージ=DQUOTE「メッセージ」DQUOTE SP DQUOTE"RFC822"DQUOTE。 中では、定義されます。[MIME-IMT]
media-subtype = string
; Defined in [MIME-IMT]
メディア-「副-タイプ」はストリングと等しいです。 中では、定義されます。[MIME-IMT]
media-text = DQUOTE "TEXT" DQUOTE SP media-subtype
; Defined in [MIME-IMT]
DQUOTEメディアテキスト=「テキスト」DQUOTE SPメディア-「副-タイプ」。 中では、定義されます。[MIME-IMT]
message-data = nz-number SP ("EXPUNGE" / ("FETCH" SP msg-att))
メッセージデータはnz-数のSPと等しいです。(/(SP msg-attを「とって来る」)を「梢消します」)
msg-att = "(" (msg-att-dynamic / msg-att-static)
*(SP (msg-att-dynamic / msg-att-static)) ")"
msg-attは「(「(msg-attダイナミックであるかmsg-att静的)の*(SP(msg-attダイナミックであるかmsg-att静的な))」)」と等しいです。
msg-att-dynamic = "FLAGS" SP "(" [flag-fetch *(SP flag-fetch)] ")"
; MAY change for a message
msg-attダイナミックな=は「(「[旗フェッチ*(SP旗フェッチ)]」)」というSPに「旗を揚げさせます」。 メッセージのための5月の変化
Crispin Standards Track [Page 87] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[87ページ]RFC3501IMAPv4 March 2003
msg-att-static = "ENVELOPE" SP envelope / "INTERNALDATE" SP date-time /
"RFC822" [".HEADER" / ".TEXT"] SP nstring /
"RFC822.SIZE" SP number /
"BODY" ["STRUCTURE"] SP body /
"BODY" section ["<" number ">"] SP nstring /
"UID" SP uniqueid
; MUST NOT change for a message
msg-att静的な=「封筒」SP封筒/"INTERNALDATE"SP日付-時間/"RFC822"[".HEADER"/".TEXT"]SP nstring/"RFC822.SIZE"SP数/「ボディー」[「構造」]SPボディー/「ボディー」セクション["<"番号">"]SP nstring/"UID"SP uniqueid。 aのための変化は通信してはいけませんか?
nil = "NIL"
=「無」無
nstring = string / nil
=ストリング/無をnstringします。
number = 1*DIGIT
; Unsigned 32-bit integer
; (0 <= n < 4,294,967,296)
数は1*DIGITと等しいです。 32ビットの無記名の整数。 (n0<=<4,294,967,296)
nz-number = digit-nz *DIGIT
; Non-zero unsigned 32-bit integer
; (0 < n < 4,294,967,296)
nz-数はケタ-nz*DIGITと等しいです。 非ゼロの無記名の32ビットの整数。 (0<n<4,294,967,296)
password = astring
パスワード=astring
quoted = DQUOTE *QUOTED-CHAR DQUOTE
引用された=DQUOTE*QUOTED-CHAR DQUOTE
QUOTED-CHAR = <any TEXT-CHAR except quoted-specials> /
"\" quoted-specials
QUOTED-CHAR=<は引用された特別番組の「\」引用された>/スペシャル以外のあらゆるTEXT-CHARです。
quoted-specials = DQUOTE / "\"
引用された特別番組はDQUOTE/「\」と等しいです。
rename = "RENAME" SP mailbox SP mailbox
; Use of INBOX as a destination gives a NO error
「改名」SPメールボックスSPメールボックスに=を改名してください。 目的地としての受信トレイの使用はいいえ誤りを与えます。
response = *(continue-req / response-data) response-done
応答は*(reqが継続的な/応答データ)と応答でしていた状態で等しいです。
response-data = "*" SP (resp-cond-state / resp-cond-bye /
mailbox-data / message-data / capability-data) CRLF
応答データは「*」SP(能力メッセージメールボックスresp-cond resp-cond-状態/不戦勝/データ/データ/データ)CRLFと等しいです。
response-done = response-tagged / response-fatal
応答で応答によってタグ付けをされているか、または応答致命的に=をします。
response-fatal = "*" SP resp-cond-bye CRLF
; Server closes connection immediately
応答致命的な=「*」SP resp-cond-さようなら、CRLF。 サーバはすぐに、接続を終えます。
response-tagged = tag SP resp-cond-state CRLF
応答でタグ付けをされた=タグSP resp-cond-州CRLF
resp-cond-auth = ("OK" / "PREAUTH") SP resp-text
; Authentication condition
resp-cond-auth=(「OK」/"PREAUTH")SP resp-テキスト。 認証状態
Crispin Standards Track [Page 88] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[88ページ]RFC3501IMAPv4 March 2003
resp-cond-bye = "BYE" SP resp-text
resp-cond-さようなら、=「さようなら」というSP resp-テキスト
resp-cond-state = ("OK" / "NO" / "BAD") SP resp-text
; Status condition
resp-cond-州の=(「OK」/「いいえ」/「悪い」)SP resp-テキスト。 状態状態
resp-specials = "]"
「resp-特別番組=」]、」
resp-text = ["[" resp-text-code "]" SP] text
resp-テキストはテキストと等しいです[「[「respテキストコード」]」SP]。
resp-text-code = "ALERT" /
"BADCHARSET" [SP "(" astring *(SP astring) ")" ] /
capability-data / "PARSE" /
"PERMANENTFLAGS" SP "("
[flag-perm *(SP flag-perm)] ")" /
"READ-ONLY" / "READ-WRITE" / "TRYCREATE" /
"UIDNEXT" SP nz-number / "UIDVALIDITY" SP nz-number /
"UNSEEN" SP nz-number /
atom [SP 1*<any TEXT-CHAR except "]">]
テキスト..コード..警戒..能力..データ..分析..旗..パーマ..旗..パーマ..読む..のみが..読書..書く..数..数..見えない..数..原子..テキスト..炭..除く
search = "SEARCH" [SP "CHARSET" SP astring] 1*(SP search-key)
; CHARSET argument to MUST be registered with IANA
=「検索」[SP"CHARSET"SP astring]1*(SP検索キー)を捜してください。 CHARSET議論、IANAに登録しなければなりません。
search-key = "ALL" / "ANSWERED" / "BCC" SP astring /
"BEFORE" SP date / "BODY" SP astring /
"CC" SP astring / "DELETED" / "FLAGGED" /
"FROM" SP astring / "KEYWORD" SP flag-keyword /
"NEW" / "OLD" / "ON" SP date / "RECENT" / "SEEN" /
"SINCE" SP date / "SUBJECT" SP astring /
"TEXT" SP astring / "TO" SP astring /
"UNANSWERED" / "UNDELETED" / "UNFLAGGED" /
"UNKEYWORD" SP flag-keyword / "UNSEEN" /
; Above this line were in [IMAP2]
"DRAFT" / "HEADER" SP header-fld-name SP astring /
"LARGER" SP number / "NOT" SP search-key /
"OR" SP search-key SP search-key /
"SENTBEFORE" SP date / "SENTON" SP date /
"SENTSINCE" SP date / "SMALLER" SP number /
"UID" SP sequence-set / "UNDRAFT" / sequence-set /
"(" search-key *(SP search-key) ")"
検索主要な=「すべて」/「回答」/「BCC」SP astring/“BEFORE" SP日付/「ボディー」SP astring/「CC」SP astring/が/を「削除した」、「」 「最近」の、または、「新しい」か/“FROM" SP astring/「キーワード」SP旗キーワード/「古い」/“ON" SP期日/「見られた」/“SINCE" SP日付/「対象」というSP astring/「テキスト」SP astring/“TO" SP astring/「答えのない」/"UNDELETED"/"UNFLAGGED"/"UNKEYWORD"に旗を揚げさせる、SP旗キーワード/「見えない」/。 Above this line were in [IMAP2] "DRAFT" / "HEADER" SP header-fld-name SP astring / "LARGER" SP number / "NOT" SP search-key / "OR" SP search-key SP search-key / "SENTBEFORE" SP date / "SENTON" SP date / "SENTSINCE" SP date / "SMALLER" SP number / "UID" SP sequence-set / "UNDRAFT" / sequence-set / "(" search-key *(SP search-key) ")"
section = "[" [section-spec] "]"
セクション=、「[「[セクション仕様]」]、」
section-msgtext = "HEADER" / "HEADER.FIELDS" [".NOT"] SP header-list /
"TEXT"
; top-level or MESSAGE/RFC822 part
セクション-msgtext=「ヘッダー」/「HEADER.FIELDS」[".NOT"]というSPヘッダーリスト/「テキスト」。 トップレベルかMESSAGE/RFC822部分
section-part = nz-number *("." nz-number)
; body part nesting
セクション一部がnz-数の*と等しい、(「. 」 nz-数、)、。 ボディー部分巣篭もり
Crispin Standards Track [Page 89] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[89ページ]RFC3501IMAPv4 March 2003
section-spec = section-msgtext / (section-part ["." section-text])
セクション仕様=セクション-msgtext/(セクション一部、[「」、セクションテキスト)
section-text = section-msgtext / "MIME"
; text other than actual body part (headers, etc.)
セクションテキストはセクション-msgtext/「MIME」と等しいです。 実際の身体の部分以外のテキスト(ヘッダーなど)
select = "SELECT" SP mailbox
=「選んだ」SPメールボックスを選択してください。
seq-number = nz-number / "*"
; message sequence number (COPY, FETCH, STORE
; commands) or unique identifier (UID COPY,
; UID FETCH, UID STORE commands).
; * represents the largest number in use. In
; the case of message sequence numbers, it is
; the number of messages in a non-empty mailbox.
; In the case of unique identifiers, it is the
; unique identifier of the last message in the
; mailbox or, if the mailbox is empty, the
; mailbox's current UIDNEXT value.
; The server should respond with a tagged BAD
; response to a command that uses a message
; sequence number greater than the number of
; messages in the selected mailbox. This
; includes "*" if the selected mailbox is empty.
seq-数はnz-数/「*」と等しいです。 メッセージ通番(COPY、FETCH、ストア;コマンド)かユニークな識別子(UID COPY; UID FETCH、UID STOREコマンド)。 ; * 使用中の最多数を表します。 中。 メッセージ通番に関するケースであり、それはそうです。 非空のメールボックスの中のメッセージの数。 ; ユニークな識別子の場合では、それがそうである、。 中の最後のメッセージのユニークな識別子、。 メールボックス、メールボックスがそうなら空になってください、。 メールボックスの現在のUIDNEXT値。 ; サーバはタグ付けをされたBADと共に反応するべきです。 メッセージを使用するコマンドへの応答。 数より大きい一連番号、。 選択されたメールボックスの中のメッセージ。 これ。 選択されたメールボックスが空であるなら、「*」を含んでいます。
seq-range = seq-number ":" seq-number
; two seq-number values and all values between
; these two regardless of order.
; Example: 2:4 and 4:2 are equivalent and indicate
; values 2, 3, and 4.
; Example: a unique identifier sequence range of
; 3291:* includes the UID of the last message in
; the mailbox, even if that value is less than 3291.
「seq-範囲=seq-番号」:、」 seq-数。 2はseqに間の値とすべての値に付番します。 注文にかかわらずこれらの2。 ; 例: そして、2:4と4:2が同等である、示します。 値2、3、および4。 ; 例: 系列が及ぶユニークな識別子。 : *が最後のメッセージのUIDを含む3291。 メールボックスその値が3291未満であっても。
sequence-set = (seq-number / seq-range) *("," sequence-set)
; set of seq-number values, regardless of order.
; Servers MAY coalesce overlaps and/or execute the
; sequence in any order.
; Example: a message sequence number set of
; 2,4:7,9,12:* for a mailbox with 15 messages is
; equivalent to 2,4,5,6,7,9,12,13,14,15
; Example: a message sequence number set of *:4,5:7
; for a mailbox with 10 messages is equivalent to
; 10,9,8,7,6,5,4,5,6,7 and MAY be reordered and
; overlap coalesced to be 4,5,6,7,8,9,10.
シーケンスセット=(seq seq-数/範囲)*、(「」、シーケンスセット)、。 注文にかかわらずseq-数の値のセット。 ; サーバがオーバラップを合体させるかもしれない、実行、。 順不同な系列。 ; 例: セットされたメッセージ通番。 2、4: 7、9、12: 15のメッセージがあるメールボックスのための*はそうです。 2、4、5、6、7、9、12、13、14と同等物、15。 例: *のメッセージ通番セット: 4、5:7。 10があるメッセージが相当しているメールボックスのために。 そして、10、9、8、7、6、5、4、5、6、7、および5月、再命令される、。 オーバラップは、4、5、6、7、8、9、10になるように合体しました。
status = "STATUS" SP mailbox SP
"(" status-att *(SP status-att) ")"
状態は「(「状態-att*(SP状態-att)」)」という「状態」SPメールボックスSPと等しいです。
Crispin Standards Track [Page 90] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[90ページ]RFC3501IMAPv4 March 2003
status-att = "MESSAGES" / "RECENT" / "UIDNEXT" / "UIDVALIDITY" /
"UNSEEN"
状態-att=「メッセージ」/「最近」/"UIDNEXT"/"UIDVALIDITY"/「見えないです」。
status-att-list = status-att SP number *(SP status-att SP number)
状態attリスト=状態-att SP番号*(SP状態-att SP番号)
store = "STORE" SP sequence-set SP store-att-flags
=「店」SPシーケンスセットSP店att旗を保存してください。
store-att-flags = (["+" / "-"] "FLAGS" [".SILENT"]) SP
(flag-list / (flag *(SP flag)))
店att旗の=[「+」/「-」]「旗」[".SILENT"]) SP(現役将官名簿/(旗*(SPは弛みます)))
string = quoted / literal
ストリング=は/リテラルを引用しました。
subscribe = "SUBSCRIBE" SP mailbox
=「申し込んでください」SPメールボックスを申し込んでください。
tag = 1*<any ASTRING-CHAR except "+">
どんなASTRING-CHARも除く=1*<にタグ付けをしてください、「+ ">"
text = 1*TEXT-CHAR
テキストは1*TEXT-CHARと等しいです。
TEXT-CHAR = <any CHAR except CR and LF>
テキスト炭はCRとLF>を除いて、いずれも炭にする<と等しいです。
time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
; Hours minutes seconds
「時間は2DIGITと等しい」:、」 "2DIGIT":、」 2DIGIT。 時間、秒を書き留めます。
uid = "UID" SP (copy / fetch / search / store)
; Unique identifiers used instead of message
; sequence numbers
uidは"UID"SPと等しいです(コピーするか、とって来る、捜す、または保存します)。 メッセージの代わりに使用されるユニークな識別子。 一連番号
uniqueid = nz-number
; Strictly ascending
uniqueidはnz-数と等しいです。 厳密に、昇ります。
unsubscribe = "UNSUBSCRIBE" SP mailbox
=「外してください」SPメールボックスを外してください。
userid = astring
ユーザID=astring
x-command = "X" atom <experimental command arguments>
x-コマンドは「X」原子の<の実験的なコマンド議論>と等しいです。
zone = ("+" / "-") 4DIGIT
; Signed four-digit value of hhmm representing
; hours and minutes east of Greenwich (that is,
; the amount that the given time differs from
; Universal Time). Subtracting the timezone
; from the given time will give the UT form.
; The Universal Time zone is "+0000".
ゾーンは(「+」/「-」)4DIGITと等しいです。 hhmmの表すことの署名している4ケタの値。 グリニッジ(すなわち; 与えられた時間が異なっている量;、世界標準時)の何時間も何分も東。 タイムゾーンを引き算します。 付与から、時間はユタ書式を与えるでしょう。 ; 世界標準時のゾーンは「+0000」です。
Crispin Standards Track [Page 91] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[91ページ]RFC3501IMAPv4 March 2003
10. Author's Note
10. 著者注
This document is a revision or rewrite of earlier documents, and supercedes the protocol specification in those documents: RFC 2060, RFC 1730, unpublished IMAP2bis.TXT document, RFC 1176, and RFC 1064.
このドキュメントは、それらのプロトコル仕様が記録する以前のドキュメント、およびsupercedesの改正か書き直しです: RFC2060、RFC1730、未発表のIMAP2bis.TXTドキュメント、RFC1176、およびRFC1064。
11. Security Considerations
11. セキュリティ問題
IMAP4rev1 protocol transactions, including electronic mail data, are sent in the clear over the network unless protection from snooping is negotiated. This can be accomplished either by the use of STARTTLS, negotiated privacy protection in the AUTHENTICATE command, or some other protection mechanism.
詮索からの保護を交渉しない場合、ネットワークの上の明確で電子メールデータを含むIMAP4rev1プロトコルトランザクションを送ります。 STARTTLSの使用、AUTHENTICATEコマンドにおける交渉されたプライバシー保護、またはある他の保護メカニズムはこれを達成できます。
11.1. STARTTLS Security Considerations
11.1. STARTTLSセキュリティ問題
The specification of the STARTTLS command and LOGINDISABLED capability in this document replaces that in [IMAP-TLS]. [IMAP-TLS] remains normative for the PLAIN [SASL] authenticator.
STARTTLSコマンドとLOGINDISABLED能力の仕様は[IMAP-TLS]で本書ではそれを取り替えます。 [IMAP-TLS]はPLAIN[SASL]固有識別文字に規範的なままで残っています。
IMAP client and server implementations MUST implement the TLS_RSA_WITH_RC4_128_MD5 [TLS] cipher suite, and SHOULD implement the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [TLS] cipher suite. This is important as it assures that any two compliant implementations can be configured to interoperate. All other cipher suites are OPTIONAL. Note that this is a change from section 2.1 of [IMAP-TLS].
IMAPクライアントとサーバ実装はTLS_RSA_WITH_RC4_128_MD5[TLS]暗号スイートを実装しなければなりません、そして、SHOULDはTLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA[TLS]暗号スイートを実装します。 共同利用するためにどんな2つの対応する実装も構成できることを保証するので、これは重要です。 他のすべての暗号スイートがOPTIONALです。 これが[IMAP-TLS]のセクション2.1からの変化であることに注意してください。
During the [TLS] negotiation, the client MUST check its understanding of the server hostname against the server's identity as presented in the server Certificate message, in order to prevent man-in-the-middle attacks. If the match fails, the client SHOULD either ask for explicit user confirmation, or terminate the connection and indicate that the server's identity is suspect. Matching is performed according to these rules:
[TLS]交渉の間、クライアントはサーバCertificateメッセージに示されるようにサーバのアイデンティティに対してサーバホスト名の理解をチェックしなければなりません、介入者攻撃を防ぐために。 マッチが失敗するなら、クライアントSHOULDは、明白なユーザ確認を求めるか、接続を終えて、またはサーバのアイデンティティが疑わしいのを示します。 これらの規則に従って、マッチングは実行されます:
The client MUST use the server hostname it used to open the
connection as the value to compare against the server name
as expressed in the server certificate. The client MUST
NOT use any form of the server hostname derived from an
insecure remote source (e.g., insecure DNS lookup). CNAME
canonicalization is not done.
クライアントはそれがサーバ証明書で言い表されるようにサーバー名に対して比較するために値として接続を開くのに使用したサーバホスト名を使用しなければなりません。 クライアントは不安定なリモートソース(例えば、不安定なDNSルックアップ)から得られたサーバホスト名のどんなフォームも使用してはいけません。 CNAME canonicalizationは完了していません。
If a subjectAltName extension of type dNSName is present in
the certificate, it SHOULD be used as the source of the
server's identity.
タイプdNSNameの拡大はsubjectAltNameであるなら証明書に存在していて、それはSHOULDです。サーバのアイデンティティの源として、使用されます。
Matching is case-insensitive.
マッチングは大文字と小文字を区別しないです。
Crispin Standards Track [Page 92] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[92ページ]RFC3501IMAPv4 March 2003
A "*" wildcard character MAY be used as the left-most name
component in the certificate. For example, *.example.com
would match a.example.com, foo.example.com, etc. but would
not match example.com.
「*」ワイルドカードキャラクタはコンポーネントという最も左の名として証明書で使用されるかもしれません。 *例えば、.example.comはa.example.com、foo.example.comなどを合わせるでしょうが、example.comは合っていないでしょう。
If the certificate contains multiple names (e.g., more than
one dNSName field), then a match with any one of the fields
is considered acceptable.
証明書が複数の名前(例えば、1つ以上のdNSName分野)を含んでいるなら、分野のどれかとのマッチは許容できると考えられます。
Both the client and server MUST check the result of the STARTTLS command and subsequent [TLS] negotiation to see whether acceptable authentication or privacy was achieved.
ともに、クライアントとサーバは、許容できる認証かプライバシーが達成されたかどうかを見るためにSTARTTLSコマンドとその後の[TLS]交渉の結果をチェックしなければなりません。
11.2. Other Security Considerations
11.2. 他のセキュリティ問題
A server error message for an AUTHENTICATE command which fails due to invalid credentials SHOULD NOT detail why the credentials are invalid.
無効の資格証明書SHOULD NOTのため失敗するAUTHENTICATEコマンドのためのサーバエラーメッセージは、資格証明書がなぜ無効であるかを詳しく述べます。
Use of the LOGIN command sends passwords in the clear. This can be avoided by using the AUTHENTICATE command with a [SASL] mechanism that does not use plaintext passwords, by first negotiating encryption via STARTTLS or some other protection mechanism.
LOGINコマンドの使用は明確でパスワードを送ります。 STARTTLSを通して最初に暗号化を交渉することによって平文パスワードを使用しない[SASL]メカニズムによるAUTHENTICATEコマンドかある他の保護メカニズムを使用することによって、これを避けることができます。
A server implementation MUST implement a configuration that, at the
time of authentication, requires:
(1) The STARTTLS command has been negotiated.
OR
(2) Some other mechanism that protects the session from password
snooping has been provided.
OR
(3) The following measures are in place:
(a) The LOGINDISABLED capability is advertised, and [SASL]
mechanisms (such as PLAIN) using plaintext passwords are NOT
advertised in the CAPABILITY list.
AND
(b) The LOGIN command returns an error even if the password is
correct.
AND
(c) The AUTHENTICATE command returns an error with all [SASL]
mechanisms that use plaintext passwords, even if the password
is correct.
サーバ実装は認証時点で以下を必要とする構成を実装しなければなりません。 (1) STARTTLSコマンドは交渉されました。 OR、(2) パスワード詮索からセッションを保護するある他のメカニズムを提供しました。 以下が測定するOR(3)が適所にあります: (a) LOGINDISABLED能力の広告を出します、そして、平文パスワードを使用する[SASL]メカニズム(PLAINなどの)はCAPABILITYリストに広告を出しません。 パスワードが正しくても、LOGINが命令するAND(b)は誤りを返します。 AUTHENTICATEが命令するAND(c)は平文パスワードを使用するすべての[SASL]メカニズムによる誤りを返します、パスワードが正しくても。
A server error message for a failing LOGIN command SHOULD NOT specify that the user name, as opposed to the password, is invalid.
失敗LOGINコマンドSHOULD NOTのためのサーバエラーメッセージは、ユーザ名がパスワードと対照的に無効であると指定します。
A server SHOULD have mechanisms in place to limit or delay failed AUTHENTICATE/LOGIN attempts.
サーバSHOULDは、失敗したAUTHENTICATE/LOGIN試みを制限するか、または遅らせるために適所にメカニズムを持っています。
Crispin Standards Track [Page 93] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[93ページ]RFC3501IMAPv4 March 2003
Additional security considerations are discussed in the section discussing the AUTHENTICATE and LOGIN commands.
AUTHENTICATEとLOGINコマンドについて論ずるセクションで追加担保問題について議論します。
12. IANA Considerations
12. IANA問題
IMAP4 capabilities are registered by publishing a standards track or IESG approved experimental RFC. The registry is currently located at:
IMAP4能力が標準化過程を発行することによって、登録されたか、またはIESGは実験的なRFCを承認しました。 登録は現在、以下に位置しています。
http://www.iana.org/assignments/imap4-capabilities
http://www.iana.org/assignments/imap4-capabilities
As this specification revises the STARTTLS and LOGINDISABLED extensions previously defined in [IMAP-TLS], the registry will be updated accordingly.
拡大が以前に[IMAP-TLS]で定義したこの仕様の改正のSTARTTLSとLOGINDISABLEDとして、それに従って、登録をアップデートするでしょう。
Crispin Standards Track [Page 94] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[94ページ]RFC3501IMAPv4 March 2003
Appendices
付録
A. Normative References
A。 引用規格
The following documents contain definitions or specifications that
are necessary to understand this document properly:
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", RFC 2234,
November 1997.
以下のドキュメントは適切にこのドキュメントを理解するのに必要な定義か仕様を含んでいます: [ABNF] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
[ANONYMOUS] Newman, C., "Anonymous SASL Mechanism", RFC
2245, November 1997.
[匿名の] ニューマン、C.、「匿名のSASLメカニズム」、RFC2245、1997年11月。
[CHARSET] Freed, N. and J. Postel, "IANA Character Set
Registration Procedures", RFC 2978, October
2000.
解放された[CHARSET]とN.とJ.ポステル、「IANA文字コード登録手順」、RFC2978、2000年10月。
[DIGEST-MD5] Leach, P. and C. Newman, "Using Digest
Authentication as a SASL Mechanism", RFC 2831,
May 2000.
[ダイジェスト-MD5] リーチ、P.、およびC.ニューマン(「SASLメカニズムとしてダイジェスト認証を使用します」、RFC2831)は2000がそうするかもしれません。
[DISPOSITION] Troost, R., Dorner, S. and K. Moore,
"Communicating Presentation Information in
Internet Messages: The Content-Disposition
Header", RFC 2183, August 1997.
[気質] Troost、R.、デルナー、S.、およびK.ムーア、「中でプレゼンテーション情報を伝えて、インターネットは通信します」。 「満足している気質ヘッダー」、RFC2183、1997年8月。
[IMAP-TLS] Newman, C., "Using TLS with IMAP, POP3 and
ACAP", RFC 2595, June 1999.
[IMAP-TLS]ニューマン、C.、「IMAP、POP3、およびACAPとTLSを使用します」、RFC2595、1999年6月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14, RFC 2119,
March 1997.
[KEYWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[LANGUAGE-TAGS] Alvestrand, H., "Tags for the Identification of
Languages", BCP 47, RFC 3066, January 2001.
Alvestrand(H.)が「言語の識別のためにタグ付けをする」[言語タグ]、BCP47、RFC3066、2001年1月。
[LOCATION] Palme, J., Hopmann, A. and N. Shelness, "MIME
Encapsulation of Aggregate Documents, such as
HTML (MHTML)", RFC 2557, March 1999.
[LOCATION] パルメ、J.、Hopmann、A.、およびN.シェル、「HTMLなどのAggregate Documents(MHTML)のMIME Encapsulation」RFC2557(1999年3月)。
[MD5] Myers, J. and M. Rose, "The Content-MD5 Header
Field", RFC 1864, October 1995.
[MD5] マイアーズとJ.とM.ローズ、「内容-MD5ヘッダーフィールド」、RFC1864、1995年10月。
Crispin Standards Track [Page 95] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[95ページ]RFC3501IMAPv4 March 2003
[MIME-HDRS] Moore, K., "MIME (Multipurpose Internet Mail
Extensions) Part Three: Message Header
Extensions for Non-ASCII Text", RFC 2047,
November 1996.
[MIME-HDRS]ムーア、K.、「パートThreeをまねてください(マルチパーパスインターネットメールエクステンション)」 「非ASCIIテキストのためのメッセージヘッダー拡張子」、RFC2047、1996年11月。
[MIME-IMB] Freed, N. and N. Borenstein, "MIME
(Multipurpose Internet Mail Extensions) Part
One: Format of Internet Message Bodies", RFC
2045, November 1996.
解放された[MIME-IMB]、N.、およびN.Borenstein、「パート1をまねてください(マルチパーパスインターネットメールエクステンション)」 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。
[MIME-IMT] Freed, N. and N. Borenstein, "MIME
(Multipurpose Internet Mail Extensions) Part
Two: Media Types", RFC 2046, November 1996.
解放された[MIME-IMT]、N.、およびN.Borenstein、「パートTwoをまねてください(マルチパーパスインターネットメールエクステンション)」 「メディアタイプ」、RFC2046、1996年11月。
[RFC-2822] Resnick, P., "Internet Message Format", RFC
2822, April 2001.
[RFC-2822] レズニック、P.、「インターネットメッセージ・フォーマット」、RFC2822、2001年4月。
[SASL] Myers, J., "Simple Authentication and Security
Layer (SASL)", RFC 2222, October 1997.
[SASL] マイアーズ、J.、「簡易認証とセキュリティは(SASL)を層にする」RFC2222、1997年10月。
[TLS] Dierks, T. and C. Allen, "The TLS Protocol
Version 1.0", RFC 2246, January 1999.
[TLS] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。
[UTF-7] Goldsmith, D. and M. Davis, "UTF-7: A Mail-Safe
Transformation Format of Unicode", RFC 2152,
May 1997.
[UTF-7]金細工職人(D.とM.デイヴィス)、「UTF-7:」 「ユニコードのメール安全な変換形式」(RFC2152)は1997がそうするかもしれません。
The following documents describe quality-of-implementation issues that should be carefully considered when implementing this protocol:
以下のドキュメントはこのプロトコルを実装するとき慎重に考えられるべきである導入問題の品質について説明します:
[IMAP-IMPLEMENTATION] Leiba, B., "IMAP Implementation
Recommendations", RFC 2683, September 1999.
[IMAP-実装] Leiba、B.、「IMAP実装推薦」、RFC2683、1999年9月。
[IMAP-MULTIACCESS] Gahrns, M., "IMAP4 Multi-Accessed Mailbox
Practice", RFC 2180, July 1997.
[IMAP-多重処理] Gahrns、M.、「マルチアクセスされたメールボックスが練習するIMAP4」、RFC2180、1997年7月。
A.1 Informative References
A.1の有益な参照
The following documents describe related protocols:
以下のドキュメントは関連するプロトコルについて説明します:
[IMAP-DISC] Austein, R., "Synchronization Operations for
Disconnected IMAP4 Clients", Work in Progress.
R.、「切断しているIMAP4クライアントのための同期操作」という[IMAP-ディスク]Austeinは進行中で働いています。
[IMAP-MODEL] Crispin, M., "Distributed Electronic Mail
Models in IMAP4", RFC 1733, December 1994.
[IMAP-モデル]クリスピン(M.)は「1994年12月にIMAP4"、RFC1733で電子メールモデルを分配しました」。
Crispin Standards Track [Page 96] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[96ページ]RFC3501IMAPv4 March 2003
[ACAP] Newman, C. and J. Myers, "ACAP -- Application
Configuration Access Protocol", RFC 2244,
November 1997.
[ACAP] ニューマン、C.、およびJ.マイアーズ、「ACAP--アプリケーション構成アクセスは議定書を作る」、RFC2244、11月1997日
[SMTP] Klensin, J., "Simple Mail Transfer Protocol",
STD 10, RFC 2821, April 2001.
[SMTP] Klensin、J.、「簡単なメール転送プロトコル」、STD10、RFC2821、2001年4月。
The following documents are historical or describe historical aspects of this protocol:
以下のドキュメントは、歴史的であるか、またはこのプロトコルの歴史的な局面について説明します:
[IMAP-COMPAT] Crispin, M., "IMAP4 Compatibility with
IMAP2bis", RFC 2061, December 1996.
[IMAP-COMPAT] クリスピン、M.、「IMAP2bisとのIMAP4の互換性」、RFC2061、1996年12月。
[IMAP-HISTORICAL] Crispin, M., "IMAP4 Compatibility with IMAP2
and IMAP2bis", RFC 1732, December 1994.
[IMAP歴史的]のクリスピン、M.、「IMAP2とIMAP2bisとのIMAP4の互換性」、RFC1732、1994年12月。
[IMAP-OBSOLETE] Crispin, M., "Internet Message Access Protocol
- Obsolete Syntax", RFC 2062, December 1996.
[IMAP時代遅れの] クリスピン、M.、「インターネットメッセージアクセスは議定書を作ります--構文を時代遅れにしてください」、RFC2062、1996年12月。
[IMAP2] Crispin, M., "Interactive Mail Access Protocol
- Version 2", RFC 1176, August 1990.
[IMAP2] クリスピン、M.、「バージョン2インチ、RFC1176、1990年対話的なメールアクセス・プロトコル--8月。」
[RFC-822] Crocker, D., "Standard for the Format of ARPA
Internet Text Messages", STD 11, RFC 822,
August 1982.
[RFC-822] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、STD11、RFC822、1982年8月。
[RFC-821] Postel, J., "Simple Mail Transfer Protocol",
STD 10, RFC 821, August 1982.
[RFC-821] ポステル、J.、「簡単なメール転送プロトコル」、STD10、RFC821、1982年8月。
B. Changes from RFC 2060
B。 RFC2060からの変化
1) Clarify description of unique identifiers and their semantics.
1) ユニークな識別子とそれらの意味論の記述をはっきりさせてください。
2) Fix the SELECT description to clarify that UIDVALIDITY is required in the SELECT and EXAMINE responses.
2) SELECTとEXAMINE応答で必要な状態ではっきりさせるUIDVALIDITYがそうであるSELECT記述を修理してください。
3) Added an example of a failing search.
3) 失敗検索に関する例を加えました。
4) Correct store-att-flags: "#flag" should be "1#flag".
4) 店att旗を修正してください: 「#旗」は「1#旗」であるべきです。
5) Made search and section rules clearer.
5) 検索とセクション規則を明らかにしました。
6) Correct the STORE example.
6) ストアの例を修正してください。
7) Correct "BASE645" misspelling.
7) "BASE645"スペルミスを修正してください。
8) Remove extraneous close parenthesis in example of two-part message with text and BASE64 attachment.
8) 2部分のメッセージに関する例のテキストとBASE64付属の異質な近い挿入句を取り除いてください。
Crispin Standards Track [Page 97] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[97ページ]RFC3501IMAPv4 March 2003
9) Remove obsolete "MAILBOX" response from mailbox-data.
9) メールボックスデータから時代遅れの「メールボックス」応答を取り除いてください。
10) A spurious "<" in the rule for mailbox-data was removed.
10) メールボックスデータのための規則による偽りの"<"を取り除きました。
11) Add CRLF to continue-req.
11) reqを続けているのにCRLFを加えてください。
12) Specifically exclude "]" from the atom in resp-text-code.
12) 「明確に、除く」、]、」 respテキストコードの原子から。
13) Clarify that clients and servers should adhere strictly to the protocol syntax.
13) そのクライアントをはっきりさせてください。そうすれば、サーバは厳密にプロトコル構文を固く守るべきです。
14) Emphasize in 5.2 that EXISTS can not be used to shrink a mailbox.
14) 5.2では、メールボックスを縮小するのにEXISTSを使用できないと強調してください。
15) Add NEWNAME to resp-text-code.
15) respテキストコードにNEWNAMEを追加してください。
16) Clarify that the empty string, not NIL, is used as arguments to LIST.
16) はっきりさせてください。NILではなく、空のストリングが議論としてLISTに使用されます。
17) Clarify that NIL can be returned as a hierarchy delimiter for the empty string mailbox name argument if the mailbox namespace is flat.
17) そのNILをはっきりさせてください。メールボックス名前空間が平坦であるなら、議論という空のストリングメールボックス名のための階層構造デリミタとして返すことができます。
18) Clarify that addr-mailbox and addr-name have RFC-2822 quoting removed.
18) そのaddr-メールボックスをはっきりさせてください。そうすれば、addr-名前はRFC-2822引用を取り除きます。
19) Update UTF-7 reference.
19) UTF-7参照をアップデートしてください。
20) Fix example in 6.3.11.
20) .11に6.3における例を修理してください。
21) Clarify that non-existent UIDs are ignored.
21) はっきりさせてください。実在しないUIDsは無視されます。
22) Update DISPOSITION reference.
22) DISPOSITION参照をアップデートしてください。
23) Expand state diagram.
23) 州のダイヤグラムを広げてください。
24) Clarify that partial fetch responses are only returned in response to a partial fetch command.
24) 応答が部分的なとって来コマンドに対応して返されるだけであるその部分的なフェッチをはっきりさせてください。
25) Add UIDNEXT response code. Correct UIDVALIDITY definition reference.
25) UIDNEXT応答コードを加えてください。 UIDVALIDITY定義参照を修正してください。
26) Further clarification of "can" vs. "MAY".
26) “can"対「5月」のさらなる明確化。
27) Reference RFC-2119.
27) 参照RFC-2119。
28) Clarify that superfluous shifts are not permitted in modified UTF-7.
28) はっきりさせてください。余計なシフトは変更されたUTF-7で受入れられません。
29) Clarify that there are no implicit shifts in modified UTF-7.
29) はっきりさせてください。変更されたUTF-7におけるどんな暗黙のシフトもありません。
Crispin Standards Track [Page 98] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[98ページ]RFC3501IMAPv4 March 2003
30) Clarify that "INBOX" in a mailbox name is always INBOX, even if it is given as a string.
30) はっきりさせてください。ストリングとしてそれを与えても、メールボックス名の「受信トレイ」はいつも受信トレイです。
31) Add missing open parenthesis in media-basic grammar rule.
31) メディア基本的な文法規則でなくなった開いている挿入句を加えてください。
32) Correct attribute syntax in mailbox-data.
32) メールボックスデータの属性構文を修正してください。
33) Add UIDNEXT to EXAMINE responses.
33) EXAMINE応答にUIDNEXTを加えてください。
34) Clarify UNSEEN, PERMANENTFLAGS, UIDVALIDITY, and UIDNEXT responses in SELECT and EXAMINE. They are required now, but weren't in older versions.
34) SELECTとEXAMINEでUNSEEN、PERMANENTFLAGS、UIDVALIDITY、およびUIDNEXT応答をはっきりさせてください。 彼らは、現在、必要でしたが、旧式のバージョンにいませんでした。
35) Update references with RFC numbers.
35) RFC番号で参照をアップデートしてください。
36) Flush text-mime2.
36) テキスト-mime2を洗い流してください。
37) Clarify that modified UTF-7 names must be case-sensitive and that violating the convention should be avoided.
37) はっきりさせてください。変更されたUTF-7名は大文字と小文字を区別しているに違いありません、そして、コンベンションがそうするべきである違反は避けられます。
38) Correct UID FETCH example.
38) UID FETCHの例を修正してください。
39) Clarify UID FETCH, UID STORE, and UID SEARCH vs. untagged EXPUNGE responses.
39) untagged EXPUNGE応答に対してUID FETCH、UID STORE、およびUID SEARCHをはっきりさせてください。
40) Clarify the use of the word "convention".
40) 「コンベンション」という言葉の使用をはっきりさせてください。
41) Clarify that a command is not "in progress" until it has been fully received (specifically, that a command is not "in progress" during command continuation negotiation).
41) それをはっきりさせてください。コマンドはそれを完全に受け取るまで(明確に、そのaコマンドはコマンド継続交渉の間、「進行中でない」)「進行中ではありません」。
42) Clarify envelope defaulting.
42) 封筒デフォルトをはっきりさせてください。
43) Clarify that SP means one and only one space character.
43) そのSP手段1と1つの間隔文字だけをはっきりさせてください。
44) Forbid silly states in LIST response.
44) LIST応答で愚かな州を禁じてください。
45) Clarify that the ENVELOPE, INTERNALDATE, RFC822*, BODY*, and UID for a message is static.
45) はっきりさせてください。ENVELOPE、INTERNALDATE、RFC822*、BODY*、およびメッセージのためのUIDは静的です。
46) Add BADCHARSET response code.
46) BADCHARSET応答コードを加えてください。
47) Update formal syntax to [ABNF] conventions.
47) [ABNF]コンベンションに正式な構文をアップデートしてください。
48) Clarify trailing hierarchy delimiter in CREATE semantics.
48) CREATE意味論における引きずっている階層構造デリミタをはっきりさせてください。
49) Clarify that the "blank line" is the [RFC-2822] delimiting blank line.
49) はっきりさせてください。「空白行」は空白行を区切る[RFC-2822]です。
Crispin Standards Track [Page 99] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[99ページ]RFC3501IMAPv4 March 2003
50) Clarify that RENAME should also create hierarchy as needed for the command to complete.
50) はっきりさせてください。また、RENAMEは終了するコマンドのために必要に応じて階層構造を作成するはずです。
51) Fix body-ext-mpart to not require language if disposition present.
51) 気質プレゼントであるなら言語を必要としないようにボディー-ext-mpartを修理してください。
52) Clarify the RFC822.HEADER response.
52) RFC822.HEADER応答をはっきりさせてください。
53) Correct missing space after charset astring in search.
53) charset astringの後に検索でなくなったスペースを修正してください。
54) Correct missing quote for BADCHARSET in resp-text-code.
54) BADCHARSETのためにrespテキストコードでなくなった引用文を修正してください。
55) Clarify that ALL, FAST, and FULL preclude any other data items appearing.
55) はっきりさせてください。すべて、FAST、およびFULLは、現れながら、いかなる他のデータ項目も排除します。
56) Clarify semantics of reference argument in LIST.
56) LISTで参照議論の意味論をはっきりさせてください。
57) Clarify that a null string for SEARCH HEADER X-FOO means any message with a header line with a field-name of X-FOO regardless of the text of the header.
57) いずれもヘッダーのテキストにかかわらずX-FOOのフィールド名があるヘッダー系列で通信させるSEARCH HEADER X-FOO手段のためにそのaヌルストリングをはっきりさせてください。
58) Specifically reserve 8-bit mailbox names for future use as UTF-8.
58) 今後の使用のためにUTF-8として明確に8ビットのメールボックス名を予約してください。
59) It is not an error for the client to store a flag that is not in the PERMANENTFLAGS list; however, the server will either ignore the change or make the change in the session only.
59) PERMANENTFLAGSリストにないのは、クライアントが旗を保存する誤りではありません。 しかしながら、サーバは、セッションだけのときに変化を無視するか、または変更を行うでしょう。
60) Correct/clarify the text regarding superfluous shifts.
60) 余計なシフトに関するテキストを修正するか、またははっきりさせてください。
61) Correct typographic errors in the "Changes" section.
61) 「変化」セクションで誤植を修正してください。
62) Clarify that STATUS must not be used to check for new messages in the selected mailbox
62) はっきりさせる、選択されたメールボックスの中の新しいメッセージがないかどうかチェックするのにそのSTATUSを使用してはいけません。
63) Clarify LSUB behavior with "%" wildcard.
63) 「%」ワイルドカードによるLSUBの振舞いをはっきりさせてください。
64) Change AUTHORIZATION to AUTHENTICATE in section 7.5.
64) AUTHORIZATIONをセクション7.5のAUTHENTICATEに変えてください。
65) Clarify description of multipart body type.
65) 複合ボディータイプの記述をはっきりさせてください。
66) Clarify that STORE FLAGS does not affect \Recent.
66) はっきりさせてください。STORE FLAGSは\Recentに影響しません。
67) Change "west" to "east" in description of timezone.
67) 「西で」タイムゾーンの記述における「東」に変わってください。
68) Clarify that commands which break command pipelining must wait for a completion result response.
68) それの中断コマンド連続送信が完成結果応答を待たなければならないそのコマンドをはっきりさせてください。
69) Clarify that EXAMINE does not affect \Recent.
69) はっきりさせてください。EXAMINEは\Recentに影響しません。
Crispin Standards Track [Page 100] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[100ページ]RFC3501IMAPv4 March 2003
70) Make description of MIME structure consistent.
70) MIME構造の記述を一貫するようにしてください。
71) Clarify that date searches disregard the time and timezone of the INTERNALDATE or Date: header. In other words, "ON 13-APR-2000" means messages with an INTERNALDATE text which starts with "13-APR-2000", even if timezone differential from the local timezone is sufficient to move that INTERNALDATE into the previous or next day.
71) はっきりさせる、日付の検索はINTERNALDATEか日付:の時間とタイムゾーンを無視します。 ヘッダー。 言い換えれば、「2000年4月13日」は「2000年4月13日」から始まるINTERNALDATEテキストがあるメッセージを意味します、ローカルのタイムゾーンからのタイムゾーンデフ装置が前であるか次の日までそのINTERNALDATEを動かすために十分であっても。
72) Clarify that the header fetches don't add a blank line if one isn't in the [RFC-2822] message.
72) はっきりさせてください。1つが[RFC-2822]メッセージにないなら、ヘッダーフェッチは空白行を加えません。
73) Clarify (in discussion of UIDs) that messages are immutable.
73) はっきりさせてください(UIDsの議論で)。メッセージは不変です。
74) Add an example of CHARSET searching.
74) CHARSETの探すのに関する例を加えてください。
75) Clarify in SEARCH that keywords are a type of flag.
75) キーワードがある検索ではっきりさせてください。一種の旗。
76) Clarify the mandatory nature of the SELECT data responses.
76) SELECTデータ応答の義務的な本質をはっきりさせてください。
77) Add optional CAPABILITY response code in the initial OK or PREAUTH.
77) 初期のOKかPREAUTHの任意のCAPABILITY応答コードを加えてください。
78) Add note that server can send an untagged CAPABILITY command as part of the responses to AUTHENTICATE and LOGIN.
78) サーバがAUTHENTICATEとLOGINへの応答の一部としてuntagged CAPABILITYコマンドを送ることができるというメモを加えてください。
79) Remove statement about it being unnecessary to issue a CAPABILITY command more than once in a connection. That statement is no longer true.
79) 接続で一度より多くのコマンドをCAPABILITYに発行するために不要であることで、それに関する声明を取り除いてください。 その声明はもう正しくはありません。
80) Clarify that untagged EXPUNGE decrements the number of messages in the mailbox.
80) はっきりさせてください。untagged EXPUNGEはメールボックスの中のメッセージの数を減少させます。
81) Fix definition of "body" (concatenation has tighter binding than alternation).
81) 「ボディー」の定義を修理してください(連結には、交互よりきつい結合があります)。
82) Add a new "Special Notes to Implementors" section with reference to [IMAP-IMPLEMENTATION].
82) [IMAP-IMPLEMENTATION]に関して「作成者への特記」新しいセクションを加えてください。
83) Clarify that an untagged CAPABILITY response to an AUTHENTICATE command should only be done if a security layer was not negotiated.
83) はっきりさせてください。セキュリティ層を交渉しない場合にだけ、AUTHENTICATEコマンドへのuntagged CAPABILITY応答をするでしょうに。
84) Change the definition of atom to exclude "]". Update astring to include "]" for compatibility with the past. Remove resp-text-atom.
84) 「除く原子の定義を変えてください」、]、」 「含んでいるアップデートastring」] 」 過去との互換性のために。 respテキスト原子を取り除いてください。
85) Remove NEWNAME. It can't work because mailbox names can be literals and can include "]". Functionality can be addressed via referrals.
85) NEWNAMEを取り外してください。 「メールボックス名がリテラルと缶のインクルードであるかもしれないので、働くことができない」]、」 紹介で機能性を扱うことができます。
Crispin Standards Track [Page 101] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[101ページ]RFC3501IMAPv4 March 2003
86) Move modified UTF-7 rationale in order to have more logical paragraph flow.
86) より論理的なパラグラフを流れさせるように変更されたUTF-7原理を動かしてください。
87) Clarify UID uniqueness guarantees with the use of MUST.
87) 使用によるUIDユニークさの保証をはっきりさせなければなりません。
88) Note that clients should read response data until the connection is closed instead of immediately closing on a BYE.
88) すぐにBYEに迫ることの代わりに接続が閉店するまでクライアントが応答データを読むべきであることに注意してください。
89) Change RFC-822 references to RFC-2822.
89) RFC-2822のRFC-822参照を変えてください。
90) Clarify that RFC-2822 should be followed instead of RFC-822.
90) はっきりさせてください。RFC-2822はRFC-822の代わりに続かれるべきです。
91) Change recommendation of optional automatic capabilities in LOGIN and AUTHENTICATE to use the CAPABILITY response code in the tagged OK. This is more interoperable than an unsolicited untagged CAPABILITY response.
91) タグ付けをされたOKでCAPABILITY応答コードを使用するというLOGINとAUTHENTICATEの任意の自動能力の推薦を変えてください。 これは求められていないuntagged CAPABILITY応答より共同利用できます。
92) STARTTLS and AUTH=PLAIN are mandatory to implement; add recommendations for other [SASL] mechanisms.
92) STARTTLSとAUTH=PLAINは実装するために義務的です。 他の[SASL]メカニズムのための推薦を加えてください。
93) Clarify that a "connection" (as opposed to "server" or "command") is in one of the four states.
93) はっきりさせてください。「接続」(「サーバ」か「コマンド」と対照的に)が4つの州の1つにあります。
94) Clarify that a failed or rejected command does not change state.
94) 失敗されたそのaをはっきりさせてください。さもないと、拒絶されたコマンドは状態を変えません。
95) Split references between normative and informative.
95) 標準で有益であることの間の参照を分けてください。
96) Discuss authentication failure issues in security section.
96) セキュリティ部の認証失敗問題について議論してください。
97) Clarify that a data item is not necessarily of only one data type.
97) はっきりさせてください。データ項目は必ず1つのデータ型だけのそうではありません。
98) Clarify that sequence ranges are independent of order.
98) はっきりさせてください。系列範囲は注文の如何にかかわらずそうです。
99) Change an example to clarify that superfluous shifts in Modified-UTF7 can not be fixed just by omitting the shift. The entire string must be recalculated.
99) シフトを省略するだけでModified-UTF7における余計なシフトを固定できないはっきりさせる例を変えてください。 全体のストリングについて再計算しなければなりません。
100) Change Envelope Structure definition since [RFC-2822] uses "envelope" to refer to the [SMTP] envelope and not the envelope data that appears in the [RFC-2822] header.
100) [RFC-2822]が封筒データではなく、[RFC-2822]ヘッダーに現れる[SMTP]封筒について言及するのに「封筒」を使用するので、Envelope Structure定義を変えてください。
101) Expand on RFC822.HEADER response data vs. BODY[HEADER].
101) BODY[HEADER]に対してRFC822.HEADER応答データについて詳述してください。
102) Clarify Logout state semantics, change ASCII art.
102) Logout州の意味論、変化ASCII芸術をはっきりさせてください。
103) Security changes to comply with IESG requirements.
103) セキュリティは、IESG要件に従うために変化します。
Crispin Standards Track [Page 102] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[102ページ]RFC3501IMAPv4 March 2003
104) Add definition for body URI.
104) ボディーURIのための定義を加えてください。
105) Break sequence range definition into three rules, with rewritten descriptions for each.
105) それぞれのための書き直された記述で系列範囲定義を3つの規則に始めてください。
106) Move STARTTLS and LOGINDISABLED here from [IMAP-TLS].
106) STARTTLSとLOGINDISABLEDを[IMAP-TLS]からここに動かしてください。
107) Add IANA Considerations section.
107) IANA Considerations部を加えてください。
108) Clarify valid client assumptions for new message UIDs vs. UIDNEXT.
108) 新しいメッセージUIDs対UIDNEXTのために有効なクライアント仮定をはっきりさせてください。
109) Clarify that changes to permanentflags affect concurrent sessions as well as subsequent sessions.
109) その後のセッションと同様にpermanentflagsの感情の同時発生のセッションへのその変化をはっきりさせてください。
110) Clarify that authenticated state can be entered by the CLOSE command.
110) はっきりさせてください。CLOSEコマンドで認証された状態に入ることができます。
111) Emphasize that SELECT and EXAMINE are the exceptions to the rule that a failing command does not change state.
111) SELECTとEXAMINEが失敗コマンドが状態を変えないという規則への例外であると強調してください。
112) Clarify that newly-appended messages have the Recent flag set.
112) はっきりさせてください。新たに追加されたメッセージで、Recent旗を設定します。
113) Clarify that newly-copied messages SHOULD have the Recent flag set.
113) SHOULDがRecent旗に設定させる新たにそんなにコピーされたメッセージをはっきりさせてください。
114) Clarify that UID commands always return the UID in FETCH responses.
114) コマンドがFETCH応答でUIDをいつも返すそのUIDをはっきりさせてください。
C. Key Word Index
C。 キーワードインデックス
+FLAGS <flag list> (store command data item) ............... 59
+FLAGS.SILENT <flag list> (store command data item) ........ 59
-FLAGS <flag list> (store command data item) ............... 59
-FLAGS.SILENT <flag list> (store command data item) ........ 59
ALERT (response code) ...................................... 64
ALL (fetch item) ........................................... 55
ALL (search key) ........................................... 50
ANSWERED (search key) ...................................... 50
APPEND (command) ........................................... 45
AUTHENTICATE (command) ..................................... 27
BAD (response) ............................................. 66
BADCHARSET (response code) ................................. 64
BCC <string> (search key) .................................. 51
BEFORE <date> (search key) ................................. 51
BODY (fetch item) .......................................... 55
BODY (fetch result) ........................................ 73
BODY <string> (search key) ................................. 51
+ FLAGS<現役将官名簿>(コマンドデータ項目を保存します)… 59+FLAGS.SILENT<現役将官名簿>(コマンドデータ項目を保存します)… 59-FLAGS<現役将官名簿>(コマンドデータ項目を保存します)… 59 -FLAGS.SILENT<現役将官名簿>(コマンドデータ項目を保存します)… 59ALERT(応答コード)… 64 すべて(項目をとって来ます)… 55 (検索キー)… 50ANSWERED(検索キー)… 50 (コマンド)を追加してください… 45 (コマンド)を認証してください… 27 悪い(応答)… 66BADCHARSET(応答コード)… 64 <ストリング>(検索キー)をBCCしてください… 51 BEFORE<日付>(検索キー)… 51BODY(項目をとって来ます)… 55BODY(結果をとって来ます)… 73 BODY<ストリング>(検索キー)… 51
Crispin Standards Track [Page 103] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[103ページ]RFC3501IMAPv4 March 2003
BODY.PEEK[<section>]<<partial>> (fetch item) ............... 57
BODYSTRUCTURE (fetch item) ................................. 57
BODYSTRUCTURE (fetch result) ............................... 74
BODY[<section>]<<origin octet>> (fetch result) ............. 74
BODY[<section>]<<partial>> (fetch item) .................... 55
BYE (response) ............................................. 67
Body Structure (message attribute) ......................... 12
CAPABILITY (command) ....................................... 24
CAPABILITY (response code) ................................. 64
CAPABILITY (response) ...................................... 68
CC <string> (search key) ................................... 51
CHECK (command) ............................................ 47
CLOSE (command) ............................................ 48
COPY (command) ............................................. 59
CREATE (command) ........................................... 34
DELETE (command) ........................................... 35
DELETED (search key) ....................................... 51
DRAFT (search key) ......................................... 51
ENVELOPE (fetch item) ...................................... 57
ENVELOPE (fetch result) .................................... 77
EXAMINE (command) .......................................... 33
EXISTS (response) .......................................... 71
EXPUNGE (command) .......................................... 48
EXPUNGE (response) ......................................... 72
Envelope Structure (message attribute) ..................... 12
FAST (fetch item) .......................................... 55
FETCH (command) ............................................ 54
FETCH (response) ........................................... 73
FLAGGED (search key) ....................................... 51
FLAGS (fetch item) ......................................... 57
FLAGS (fetch result) ....................................... 78
FLAGS (response) ........................................... 71
FLAGS <flag list> (store command data item) ................ 59
FLAGS.SILENT <flag list> (store command data item) ......... 59
FROM <string> (search key) ................................. 51
FULL (fetch item) .......................................... 55
Flags (message attribute) .................................. 11
HEADER (part specifier) .................................... 55
HEADER <field-name> <string> (search key) .................. 51
HEADER.FIELDS <header-list> (part specifier) ............... 55
HEADER.FIELDS.NOT <header-list> (part specifier) ........... 55
INTERNALDATE (fetch item) .................................. 57
INTERNALDATE (fetch result) ................................ 78
Internal Date (message attribute) .......................... 12
KEYWORD <flag> (search key) ................................ 51
Keyword (type of flag) ..................................... 11
LARGER <n> (search key) .................................... 51
LIST (command) ............................................. 40
BODY.PEEK[<部の>]の<の<の部分的な>>(項目をとって来ます)… 57BODYSTRUCTURE(項目をとって来ます)… 57BODYSTRUCTURE(結果をとって来ます)… 74BODY[<部の>]<<発生源八重奏>>(結果をとって来ます)… 74 BODY[<部の>]の<の<の部分的な>>(項目をとって来ます)… 55 さようなら(応答)… 67 ボディーStructure(メッセージ属性)… 12 能力(コマンド)… 24CAPABILITY(応答コード)… 64 能力(応答)… 68 <ストリング>(検索キー)をCCしてください… 51 チェックしてください(命令してください)… 47 閉じてください(命令してください)… 48 コピーしてください(命令してください)… 59 (コマンド)を作成してください… 34 (コマンド)を削除してください… 35DELETED(検索キー)… 51DRAFT(検索キー)… 51ENVELOPE(項目をとって来ます)… 57ENVELOPE(結果をとって来ます)… 77 (コマンド)を調べてください… 33 存在しています(応答)… 71 (コマンド)を梢消してください… 48 (応答)を梢消してください… 72 封筒Structure(メッセージ属性)… 12FAST(項目をとって来ます)… 55は(コマンド)をとって来ます… 54は(応答)をとって来ます… 73FLAGGED(検索キー)… 51FLAGS(項目をとって来ます)… 57FLAGS(結果をとって来ます)… 78 (応答)に旗を揚げさせます… 71FLAGS<現役将官名簿>(コマンドデータ項目を保存します)… 59 FLAGS.SILENT<現役将官名簿>(コマンドデータ項目を保存します)… 59 FROM<ストリング>(検索キー)… 51FULL(項目をとって来ます)… 55 (メッセージ属性)に旗を揚げさせます… 11HEADER(部分特許説明書の作成書)… 55HEADER<フィールド名><ストリング>(検索キー)… 51HEADER.FIELDS<ヘッダーリスト>(部分特許説明書の作成書)… 55HEADER.FIELDS.NOT<ヘッダーリスト>(部分特許説明書の作成書)… 55INTERNALDATE(項目をとって来ます)… 57INTERNALDATE(結果をとって来ます)… 78 内部のDate(メッセージ属性)… 12 KEYWORD<旗の>(検索キー)… 51キーワード(旗のタイプ)… 11 LARGER<n>(検索キー)… 51 記載してください(命令してください)… 40
Crispin Standards Track [Page 104] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[104ページ]RFC3501IMAPv4 March 2003
LIST (response) ............................................ 69
LOGIN (command) ............................................ 30
LOGOUT (command) ........................................... 25
LSUB (command) ............................................. 43
LSUB (response) ............................................ 70
MAY (specification requirement term) ....................... 4
MESSAGES (status item) ..................................... 45
MIME (part specifier) ...................................... 56
MUST (specification requirement term) ...................... 4
MUST NOT (specification requirement term) .................. 4
Message Sequence Number (message attribute) ................ 10
NEW (search key) ........................................... 51
NO (response) .............................................. 66
NOOP (command) ............................................. 25
NOT <search-key> (search key) .............................. 52
OK (response) .............................................. 65
OLD (search key) ........................................... 52
ON <date> (search key) ..................................... 52
OPTIONAL (specification requirement term) .................. 4
OR <search-key1> <search-key2> (search key) ................ 52
PARSE (response code) ...................................... 64
PERMANENTFLAGS (response code) ............................. 64
PREAUTH (response) ......................................... 67
Permanent Flag (class of flag) ............................. 12
READ-ONLY (response code) .................................. 65
READ-WRITE (response code) ................................. 65
RECENT (response) .......................................... 72
RECENT (search key) ........................................ 52
RECENT (status item) ....................................... 45
RENAME (command) ........................................... 37
REQUIRED (specification requirement term) .................. 4
RFC822 (fetch item) ........................................ 57
RFC822 (fetch result) ...................................... 78
RFC822.HEADER (fetch item) ................................. 57
RFC822.HEADER (fetch result) ............................... 78
RFC822.SIZE (fetch item) ................................... 57
RFC822.SIZE (fetch result) ................................. 78
RFC822.TEXT (fetch item) ................................... 58
RFC822.TEXT (fetch result) ................................. 79
SEARCH (command) ........................................... 49
SEARCH (response) .......................................... 71
SEEN (search key) .......................................... 52
SELECT (command) ........................................... 31
SENTBEFORE <date> (search key) ............................. 52
SENTON <date> (search key) ................................. 52
SENTSINCE <date> (search key) .............................. 52
SHOULD (specification requirement term) .................... 4
SHOULD NOT (specification requirement term) ................ 4
記載してください(応答)… 69 ログインしてください(命令してください)… 30 ログアウトしてください(命令してください)… 25 LSUB(コマンド)… 43 LSUB(応答)… 5月70日(仕様書要求事項用語)… 4MESSAGES(状態項目)… 45MIME(部分特許説明書の作成書)… 56は(仕様書要求事項用語)がそうしなければなりません。 4はそうしてはいけません(仕様書要求事項用語)… 4 メッセージSequence Number(メッセージ属性)… 10NEW(検索キー)… 51 (応答)がありません… 66 NOOP(コマンド)… 25 <の検索主要な>(検索キー)でない… 52は(応答)を承認します… 65OLD(検索キー)… 52 ON<日付>(検索キー)… 52OPTIONAL(仕様書要求事項用語)… 4 key1><検索-key2を探しているOR<>(検索キー)… 52PARSE(応答コード)… 64PERMANENTFLAGS(応答コード)… 64 PREAUTH(応答)… 67 永久的なFlag(旗のクラス)… 12 READ唯一(応答コード)… 65READ-WRITE(応答コード)… 65 最近の(応答)… 72RECENT(検索キー)… 52RECENT(状態項目)… 45 (コマンド)を改名してください… 37REQUIRED(仕様書要求事項用語)… 4RFC822(項目をとって来ます)… 57RFC822(結果をとって来ます)… 78RFC822.HEADER(項目をとって来ます)… 57RFC822.HEADER(結果をとって来ます)… 78RFC822.SIZE(項目をとって来ます)… 57RFC822.SIZE(結果をとって来ます)… 78RFC822.TEXT(項目をとって来ます)… 58RFC822.TEXT(結果をとって来ます)… 79 探してください(命令してください)… 49 探してください(応答)… 71SEEN(検索キー)… 52 (コマンド)を選択してください… 31 SENTBEFORE<日付>(検索キー)… 52 SENTON<日付>(検索キー)… 52 SENTSINCE<日付>(検索キー)… 52SHOULD(仕様書要求事項用語)… 4SHOULD NOT(仕様書要求事項用語)… 4
Crispin Standards Track [Page 105] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[105ページ]RFC3501IMAPv4 March 2003
SINCE <date> (search key) .................................. 52
SMALLER <n> (search key) ................................... 52
STARTTLS (command) ......................................... 27
STATUS (command) ........................................... 44
STATUS (response) .......................................... 70
STORE (command) ............................................ 58
SUBJECT <string> (search key) .............................. 53
SUBSCRIBE (command) ........................................ 38
Session Flag (class of flag) ............................... 12
System Flag (type of flag) ................................. 11
TEXT (part specifier) ...................................... 56
TEXT <string> (search key) ................................. 53
TO <string> (search key) ................................... 53
TRYCREATE (response code) .................................. 65
UID (command) .............................................. 60
UID (fetch item) ........................................... 58
UID (fetch result) ......................................... 79
UID <sequence set> (search key) ............................ 53
UIDNEXT (response code) .................................... 65
UIDNEXT (status item) ...................................... 45
UIDVALIDITY (response code) ................................ 65
UIDVALIDITY (status item) .................................. 45
UNANSWERED (search key) .................................... 53
UNDELETED (search key) ..................................... 53
UNDRAFT (search key) ....................................... 53
UNFLAGGED (search key) ..................................... 53
UNKEYWORD <flag> (search key) .............................. 53
UNSEEN (response code) ..................................... 65
UNSEEN (search key) ........................................ 53
UNSEEN (status item) ....................................... 45
UNSUBSCRIBE (command) ...................................... 39
Unique Identifier (UID) (message attribute) ................ 8
X<atom> (command) .......................................... 62
[RFC-2822] Size (message attribute) ........................ 12
\Answered (system flag) .................................... 11
\Deleted (system flag) ..................................... 11
\Draft (system flag) ....................................... 11
\Flagged (system flag) ..................................... 11
\Marked (mailbox name attribute) ........................... 69
\Noinferiors (mailbox name attribute) ...................... 69
\Noselect (mailbox name attribute) ......................... 69
\Recent (system flag) ...................................... 11
\Seen (system flag) ........................................ 11
\Unmarked (mailbox name attribute) ......................... 69
SINCE<日付>(検索キー)… 52 SMALLER<n>(検索キー)… 52STARTTLS(コマンド)… 27 状態(コマンド)… 44 状態(応答)… 70は(コマンド)を保存します… 58 SUBJECT<ストリング>(検索キー)… 53 (コマンド)を申し込んでください… 38 セッションFlag(旗のクラス)… 12 システムFlag(旗のタイプ)… 11TEXT(部分特許説明書の作成書)… 56 TEXT<ストリング>(検索キー)… 53 TO<ストリング>(検索キー)… 53TRYCREATE(応答コード)… 65 UID(コマンド)… 60UID(項目をとって来ます)… 58UID(結果をとって来ます)… 79UID<シーケンスセット>(検索キー)… 53UIDNEXT(応答コード)… 65UIDNEXT(状態項目)… 45UIDVALIDITY(応答コード)… 65UIDVALIDITY(状態項目)… 45UNANSWERED(検索キー)… 53UNDELETED(検索キー)… 53UNDRAFT(検索キー)… 53UNFLAGGED(検索キー)… 53 UNKEYWORD<旗の>(検索キー)… 53UNSEEN(応答コード)… 65UNSEEN(検索キー)… 53UNSEEN(状態項目)… 45 (コマンド)を外してください… 39 ユニークなIdentifier(UID)(メッセージ属性)… 8 X<原子>(コマンド)… 62 [RFC-2822]サイズ(メッセージ属性)… 12円は(システム旗)に答えました… 11円は(システム旗)を削除しました… 11円の草稿(システム旗)… 11円は(システム旗)に旗を揚げさせました… 11円は(メールボックス名前属性)をマークしました… 69円のNoinferiors(メールボックス名前属性)… 69円のNoselect(メールボックス名前属性)… 69円最近(システム旗)… 11円見られる(システム旗)… 11円無印(メールボックス名前属性)… 69
Crispin Standards Track [Page 106] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[106ページ]RFC3501IMAPv4 March 2003
Author's Address
作者のアドレス
Mark R. Crispin Networks and Distributed Computing University of Washington 4545 15th Avenue NE Seattle, WA 98105-4527
マークR.クリスピンネットワークと第15分散コンピューティングワシントン大学4545アベニューNeシアトル、ワシントン98105-4527
Phone: (206) 543-5762
以下に電話をしてください。 (206) 543-5762
EMail: MRC@CAC.Washington.EDU
メール: MRC@CAC.Washington.EDU
Crispin Standards Track [Page 107] RFC 3501 IMAPv4 March 2003
クリスピン標準化過程[107ページ]RFC3501IMAPv4 March 2003
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. v This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう; Thisドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証に対して。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Crispin Standards Track [Page 108]
クリスピン標準化過程[108ページ]
一覧
スポンサーリンク
