[要約] RFC 4549は、切断されたIMAP4クライアントの同期操作に関する標準仕様です。目的は、オフライン時にメールクライアントがサーバーと同期できるようにすることです。
Network Working Group A. Melnikov, Ed.
Request for Comments: 4549 Isode Ltd.
Category: Informational June 2006
Synchronization Operations for Disconnected IMAP4 Clients
切断されたIMAP4クライアントの同期操作
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
This document attempts to address some of the issues involved in building a disconnected IMAP4 client. In particular, it deals with the issues of what might be called the "driver" portion of the synchronization tool: the portion of the code responsible for issuing the correct set of IMAP4 commands to synchronize the disconnected client in the way that is most likely to make the human who uses the disconnected client happy.
このドキュメントは、切断されたIMAP4クライアントの構築に伴う問題のいくつかに対処しようとします。特に、同期ツールの「ドライバー」部分と呼ばれる可能性のある問題の問題を扱っています。コードの部分の部分は、正しいIMAP4コマンドを発行して、切断されたクライアントを同期する可能性が最も高い方法で同期します。切断されたクライアントを使用する人間を幸せにします。
This note describes different strategies that can be used by disconnected clients and shows how to use IMAP protocol in order to minimize the time of the synchronization process.
このメモは、切断されたクライアントが使用できるさまざまな戦略について説明し、同期プロセスの時間を最小化するためにIMAPプロトコルを使用する方法を示しています。
This note also lists IMAP extensions that a server should implement in order to provide better synchronization facilities to disconnected clients.
このメモには、クライアントを切断するためのより良い同期機能を提供するために、サーバーが実装する必要があるIMAP拡張機能もリストされています。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
2. Design Principles ...............................................3
3. Overall Picture of Synchronization ..............................4
4. Mailbox Synchronization Steps and Strategies ....................7
4.1. Checking UID Validity ......................................7
4.2. Synchronizing Local Changes with the Server ................8
4.2.1. Uploading Messages to the Mailbox ...................8
4.2.2. Optimizing "move" and "copy" Operations .............9
4.2.3. Replaying Local Flag Changes .......................14
4.2.4. Processing Mailbox Compression (EXPUNGE) Requests ..15
4.2.5. Closing a Mailbox ..................................17
4.3. Details of "Normal" Synchronization of a Single Mailbox ...18
4.3.1. Discovering New Messages and Changes to Old
Messages ...........................................18
4.3.2. Searching for "Interesting" Messages. ..............20
4.3.3. Populating Cache with "Interesting" Messages. ......21
4.3.4. User-Initiated Synchronization .....................22
4.4. Special Case: Descriptor-Only Synchronization .............22
4.5. Special Case: Fast New-Only Synchronization ...............23
4.6. Special Case: Blind FETCH .................................23
5. Implementation Considerations ..................................24
5.1. Error Recovery during Playback ............................26
5.2. Quality of Implementation Issues ..........................28
5.3. Optimizations .............................................28
6. IMAP Extensions That May Help ..................................30
6.1. CONDSTORE Extension .......................................30
7. Security Considerations ........................................33
8. References .....................................................33
8.1. Normative References ......................................33
8.2. Informative References ....................................34
9. Acknowledgements ...............................................34
Several recommendations presented in this document are generally applicable to all types of IMAP clients. However, this document tries to concentrate on disconnected mail clients [IMAP-MODEL]. It also suggests some IMAP extensions* that should be implemented by IMAP servers in order to make the life of disconnected clients easier. In particular, the [UIDPLUS] extension was specifically designed to streamline certain disconnected operations, like expunging, uploading, and copying messages (see Sections 4.2.1, 4.2.2.1, and 4.2.4).
このドキュメントに示されているいくつかの推奨事項は、一般にすべてのタイプのIMAPクライアントに適用されます。ただし、このドキュメントは、切断されたメールクライアント[IMAP-Model]に集中しようとします。また、切断されたクライアントの寿命を容易にするために、IMAPサーバーが実装する必要があるIMAP拡張*をいくつか提案しています。特に、[uidplus]拡張機能は、メッセージを展開、アップロード、コピーなどの特定の切断された操作を合理化するように特別に設計されています（セクション4.2.1、4.2.2.1、および4.2.4を参照）。
Readers of this document are also strongly advised to read RFC 2683 [RFC2683].
この文書の読者は、RFC 2683 [RFC2683]を読むことも強くお勧めします。
* Note that the functionality provided by the base IMAP protocol [IMAP4] is sufficient to perform basic synchronization.
* ベースIMAPプロトコル[IMAP4]によって提供される機能は、基本的な同期を実行するのに十分であることに注意してください。
In examples, "C:" and "S:" indicate lines sent by the client and server, respectively. Long lines in examples are broken for editorial clarity.
例では、「C：」と「S：」は、それぞれクライアントとサーバーから送信された行を示します。例の長い行は、編集上の明確さのために壊れています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [KEYWORDS].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、RFC 2119 [キーワード]に記載されているとおりに解釈されます。
Let's call an IMAP command idempotent if the result of executing the command twice sequentially is the same as the result of executing the command just once.
コマンドを2回順番に実行した結果がコマンドを1回実行した結果と同じである場合、IMAPコマンドiDempotentを呼び出します。
All mailbox state or content information stored on the disconnected client should be viewed strictly as a cache of the state of the server. The "master" state remains on the server, just as it would with an interactive IMAP4 client. The one exception to this rule is that information about the state of the disconnected client's cache (the state includes flag changes while offline and during scheduled message uploads) remains on the disconnected client: that is, the IMAP4 server is not responsible for remembering the state of the disconnected IMAP4 client.
切断されたクライアントに保存されているすべてのメールボックス状態またはコンテンツ情報は、サーバーの状態のキャッシュと厳密に表示する必要があります。「マスター」状態は、インタラクティブなIMAP4クライアントと同じように、サーバー上に残ります。このルールの1つの例外は、切断されたクライアントのキャッシュの状態に関する情報（状態にはオフライン中およびスケジュールされたメッセージのアップロード中にフラグの変更が含まれます）が切断されたクライアントに残っていることです。つまり、IMAP4サーバーは状態を覚えている責任はありません切断されたIMAP4クライアントの。
We assume that a disconnected client is a client that, for whatever reason, wants to minimize the length of time that it is "on the phone" to the IMAP4 server. Often this will be because the client is using a dialup connection, possibly with very low bandwidth, but sometimes it might just be that the human is in a hurry to catch an airplane, or some other event beyond our control. Whatever the reason, we assume that we must make efficient use of the network connection, both in the usual sense (not generating spurious traffic) and in the sense that we would prefer not to have the connection sitting idle while the client and/or the server is performing strictly local computation or I/O. Another, perhaps simpler way of stating this is that we assume that network connections are "expensive".
切断されたクライアントは、何らかの理由で、IMAP4サーバーに「電話で」である時間の長さを最小限に抑えたいクライアントであると仮定します。多くの場合、これは、クライアントがおそらく非常に低い帯域幅を持つダイヤルアップ接続を使用しているためですが、人間が飛行機を捕まえようと急いでいるか、私たちの制御を超えた他のイベントである可能性があります。理由が何であれ、私たちは、通常の意味（偽のトラフィックを生成しない）と、クライアントや/または/またはサーバーは、厳密にローカル計算またはI/Oを実行しています。これを述べるもう1つの、おそらくより簡単な方法は、ネットワーク接続が「高価」であると仮定することです。
Practical experience with disconnected mail systems has shown that there is no single synchronization strategy that is appropriate for all cases. Different humans have different preferences, and the same human's preference will vary depending both on external circumstance (how much of a hurry the human is in today) and on the value that the human places on the messages being transferred. The point here is that there is no way that the synchronization program can guess exactly what the human wants to do, so the human will have to provide some guidance.
切断されたメールシステムでの実際の経験は、すべてのケースに適した単一の同期戦略がないことを示しています。異なる人間には異なる好みがあり、同じ人間の好みは、外部の状況（今日の人間がどれだけ急いでいるか）と、転送されるメッセージの人間の場所の両方によって異なります。ここでのポイントは、同期プログラムが人間がやりたいことを正確に推測する方法がないため、人間は何らかのガイダンスを提供しなければならないということです。
Taken together, the preceding two principles lead to the conclusion that the synchronization program must make its decisions based on some kind of guidance provided by the human, by selecting the appropriate options in the user interface or through some sort of configuration file. Almost certainly, it should not pause for I/O with the human in the middle of the synchronization process. The human will almost certainly have several different configurations for the synchronization program, for different circumstances.
まとめると、前述の2つの原則は、同期プログラムが、ユーザーインターフェイスの適切なオプションまたは何らかの構成ファイルを介して適切なオプションを選択することにより、人間が提供する何らかのガイダンスに基づいて決定を下さなければならないという結論につながります。ほぼ確実に、同期プロセスの途中で人間とI/Oのために一時停止するべきではありません。人間は、ほぼ間違いなく、異なる状況で、同期プログラムのいくつかの異なる構成を持っています。
Since a disconnected client has no way of knowing what changes might have occurred to the mailbox while it was disconnected, message numbers are not useful to a disconnected client. All disconnected client operations should be performed using UIDs, so that the client can be sure that it and the server are talking about the same messages during the synchronization process.
切断されたクライアントは、切断されている間にメールボックスにどのような変更が発生したかを知る方法がないため、メッセージ番号は切断されたクライアントには役に立ちません。クライアントが同期プロセス中に同じメッセージについて話していることをクライアントが確認できるように、UIDを使用して切断されたすべてのクライアント操作を実行する必要があります。
The basic strategy for synchronization is outlined below. Note that the real strategy may vary from one application to another or may depend on a synchronization mode.
同期のための基本的な戦略を以下に概説します。実際の戦略は、アプリケーションから別のアプリケーションによって異なる場合があるか、同期モードに依存する場合があることに注意してください。
a) Process any "actions" that were pending on the client that were not associated with any mailbox. (In particular sending messages composed offline with SMTP. This is not part of IMAP synchronization, but it is mentioned here for completeness.)
a) メールボックスに関連付けられていないクライアントに保留中の「アクション」を処理します。（特に、SMTPでオフラインで構成されたメッセージを送信します。これはIMAP同期の一部ではありませんが、完全性についてはここで言及されています。）
b) Fetch the current list of "interesting" mailboxes. (The disconnected client should allow the user to skip this step completely.)
b) 「興味深い」メールボックスの現在のリストを取得します。（切断されたクライアントは、ユーザーがこのステップを完全にスキップできるようにする必要があります。）
c) "Client-to-server synchronization": for each IMAP "action" that was pending on the client, do the following:
c) 「クライアントとサーバーへの同期」：クライアントに保留されていた各IMAP「アクション」について、次のことを行います。
1) If the action implies opening a new mailbox (any operation that operates on messages), open the mailbox. Check its UID validity value (see Section 4.1 for more details) returned in the UIDVALIDITY response code. If the UIDVALIDITY value returned by the server differs, the client MUST empty the local cache of the mailbox and remove any pending "actions" that refer to UIDs in that mailbox (and consider them failed). Note that this doesn't affect actions performed on client-generated fake UIDs (see Section 5).
1) アクションが新しいメールボックス（メッセージで動作する任意の操作）を開くことを意味する場合は、メールボックスを開きます。UIDALIDITINITITITITITITITITITITITITIUNDの妥当性の値（詳細については、セクション4.1を参照）を確認してください。サーバーによって返されたuidialidity値が異なる場合、クライアントはメールボックスのローカルキャッシュを空にし、そのメールボックス内のUIDを参照する保留中の「アクション」を削除する必要があります（および失敗したと考える）。これは、クライアントで生成された偽のUIDで実行されるアクションに影響しないことに注意してください（セクション5を参照）。
2) Perform the action. If the action is to delete a mailbox (DELETE), make sure that the mailbox is closed first (see also Section 3.4.12 of [RFC2683]).
2) アクションを実行します。アクションがメールボックス（削除）を削除する場合、メールボックスが最初に閉じられていることを確認してください（[RFC2683]のセクション3.4.12も参照）。
d) "Server-to-client synchronization": for each mailbox that requires synchronization, do the following:
d) 「サーバーとクライアントの同期」：同期が必要な各メールボックスについて、次のことを行います。
1) Check the mailbox UIDVALIDITY (see Section 4.1 for more details) with SELECT/EXAMINE/STATUS.
1) Select/Execine/Statusで、メールボックスのuidalidity（詳細については、セクション4.1を参照）を確認してください。
If UIDVALIDITY value returned by the server differs, the client MUST
サーバーによって返されたuidvalidity値が異なる場合、クライアントは
* empty the local cache of that mailbox; * remove any pending "actions" that refer to UIDs in that mailbox and consider them failed; and * skip step 2-II.
* そのメールボックスのローカルキャッシュを空にします。*そのメールボックス内のUIDを参照する保留中の「アクション」を削除し、それらが失敗したと考える。および *ステップ2-IIをスキップします。
2) Fetch the current "descriptors";
2) 現在の「記述子」を取得します。
I) Discover new messages.
i）新しいメッセージを発見します。
II) Discover changes to old messages.
ii）古いメッセージの変更を発見します。
3) Fetch the bodies of any "interesting" messages that the client doesn't already have.
3) クライアントがまだ持っていない「興味深い」メッセージのボディを取得します。
e) Close all open mailboxes not required for further operations (if staying online) or disconnect all open connections (if going offline).
e) さらなる操作には必要ないすべてのオープンメールボックスを閉じます（オンラインにとどまる場合）またはすべてのオープン接続を切断します（オフラインになっている場合）。
Terms used:
使用される用語：
"Actions" are queued requests that were made by the human to the client's Mail User Agent (MUA) software while the client was disconnected.
「アクション」は、クライアントが切断されている間に、人間がクライアントのメールユーザーエージェント（MUA）ソフトウェアに行われたキューに巻き込まれた要求です。
We define "descriptors" as a set of IMAP4 FETCH data items. Conceptually, a message's descriptor is that set of information that allows the synchronization program to decide what protocol actions are necessary to bring the local cache to the desired state for this message; since this decision is really up to the human, this information probably includes at least a few header fields intended for human consumption. Exactly what will constitute a descriptor depends on the client implementation. At a minimum, the descriptor contains the message's UID and FLAGS. Other likely candidates are the RFC822.SIZE, RFC822.HEADER, BODYSTRUCTURE, or ENVELOPE data items.
「記述子」をIMAP4フェッチデータ項目のセットとして定義します。概念的には、メッセージの記述子とは、同期プログラムがこのメッセージのためにローカルキャッシュを目的の状態にするために必要なプロトコルアクションを決定できるようにする情報のセットです。この決定は本当に人間次第であるため、この情報にはおそらく、人間の消費を目的とした少なくともいくつかのヘッダーフィールドが含まれています。記述子を構成するものは、クライアントの実装に依存します。少なくとも、記述子にはメッセージのUIDとフラグが含まれています。他の候補者は、RFC822.Size、RFC822.Header、Bodystructure、またはEnvelopeデータ項目です。
Comments:
コメント：
1) The list of actions should be ordered. For example, if the human deletes message A1 in mailbox A, then expunges mailbox A, and then deletes message A2 in mailbox A, the human will expect that message A1 is gone and that message A2 is still present but is now deleted.
1) アクションのリストを注文する必要があります。たとえば、HumanがメールボックスAでメッセージA1を削除し、メールボックスAを抹消し、メールボックスAでメッセージA2を削除する場合、人間はメッセージA1がなくなり、メッセージA2がまだ存在するが、削除されることを期待します。
By processing all the actions before proceeding with synchronization, we avoid having to compensate for the local MUA's changes to the server's state. That is, once we have processed all the pending actions, the steps that the client must take to synchronize itself will be the same no matter where the changes to the server's state originated.
同期を進める前にすべてのアクションを処理することにより、サーバーの状態に対するローカルMUAの変更を補う必要がありません。つまり、すべての保留中のアクションを処理すると、サーバーの状態の変更がどこに起因するかに関係なく、クライアントがそれ自体を同期するためにとらなければならないステップは同じになります。
2) Steps a and b can be performed in parallel. Alternatively, step a can be performed after d.
2) ステップAとBは並行して実行できます。または、ステップAはdの後に実行できます。
3) On step b, the set of "interesting" mailboxes pretty much has to be determined by the human. What mailboxes belong to this set may vary between different IMAP4 sessions with the same server, client, and human. An interesting mailbox can be a mailbox returned by LSUB command (see Section 6.3.9 of [IMAP4]). The special mailbox "INBOX" SHOULD be in the default set of mailboxes that the client considers interesting. However, providing the ability to ignore INBOX for a particular session or client may be valuable for some mail filtering strategies.
3) ステップBでは、「興味深い」メールボックスのセットは、人間によってほぼ決定されなければなりません。このセットに属するメールボックスは、同じサーバー、クライアント、および人間との異なるIMAP4セッションによって異なる場合があります。興味深いメールボックスは、LSUBコマンドによって返されるメールボックスです（[IMAP4]のセクション6.3.9を参照）。特別なメールボックス「Inbox」は、クライアントが興味深いと考えるメールボックスのデフォルトのセットにある必要があります。ただし、特定のセッションまたはクライアントに受信トレイを無視する機能を提供することは、一部のメールフィルタリング戦略にとって価値がある場合があります。
4) On step d-2-II, the client also finds out about changes to the flags of messages that the client already has in its local cache, and about messages in the local cache that no longer exist on the server (i.e., messages that have been expunged).
4) ステップD-2-IIで、クライアントは、クライアントが既にローカルキャッシュに持っているメッセージのフラグの変更や、サーバーに存在しなくなったローカルキャッシュ内のメッセージ（つまり、削除されました）。
5) "Interesting" messages are those messages that the synchronization program thinks the human wants to have cached locally, based on the configuration and the data retrieved in step b.
5) 「興味深い」メッセージは、Synchronizationプログラムが、ステップbで取得した構成とデータに基づいて、人間がローカルにキャッシュしたいと考えているメッセージです。
6) A disconnected IMAP client is a special case of an IMAP client, so it MUST be able to handle any "unexpected" unsolicited responses, like EXISTS and EXPUNGE, at any time. The disconnected client MAY ignore EXPUNGE response during "client-to-server" synchronization phase (step c).
6) 切断されたIMAPクライアントは、IMAPクライアントの特別なケースであるため、いつでも存在したり抹消するなどの「予期しない」未承諾応答を処理できる必要があります。切断されたクライアントは、「クライアントからサーバーへの」同期フェーズ（ステップC）の間に、抹消反応を無視する場合があります。
The rest of this discussion will focus primarily on the synchronization issues for a single mailbox.
この議論の残りの部分は、主に単一のメールボックスの同期の問題に焦点を当てます。
The "UID validity" of a mailbox is a number returned in an UIDVALIDITY response code in an OK untagged response at mailbox selection time. The UID validity value changes between sessions when UIDs fail to persist between sessions.
メールボックスの「uidの妥当性」は、メールボックスの選択時にOK未編成の応答でuidalidity応答コードで返される数字です。UIDの妥当性値は、UIDがセッション間に持続しない場合のセッション間で変化します。
Whenever the client selects a mailbox, the client must compare the returned UID validity value with the value stored in the local cache. If the UID validity values differ, the UIDs in the client's cache are no longer valid. The client MUST then empty the local cache of that mailbox and remove any pending "actions" that refer to UIDs in that mailbox. The client MAY also issue a warning to the human. The client MUST NOT cancel any scheduled uploads (i.e., APPENDs) for the mailbox.
クライアントがメールボックスを選択するたびに、クライアントは、返されたUIDの有効性値をローカルキャッシュに保存されている値と比較する必要があります。UIDの妥当性の値が異なる場合、クライアントのキャッシュのUIDはもはや有効ではありません。その後、クライアントはそのメールボックスのローカルキャッシュを空にし、そのメールボックス内のUIDを参照する保留中の「アクション」を削除する必要があります。クライアントは、人間に警告を発することもあります。クライアントは、メールボックスのスケジュールされたアップロード（つまり、追加）をキャンセルしてはなりません。
Note that UIDVALIDITY is not only returned on a mailbox selection. The COPYUID and APPENDUID response codes defined in the [UIDPLUS] extension (see also 4.2.2) and the UIDVALIDITY STATUS response data item also contain a UIDVALIDITY value for some other mailbox. The client SHOULD behave as described in the previous paragraph (but it should act on the other mailbox's cache), no matter how it obtained the UIDVALIDITY value.
uidialidityは、メールボックスの選択だけで返されるだけではないことに注意してください。[uidplus]拡張機能（4.2.2も参照）で定義されているcopyuidおよびappenduid応答コードと、他のメールボックスのuidvalidity性値も含まれています。クライアントは、前の段落で説明されているように動作する必要があります（ただし、他のメールボックスのキャッシュに基づいて動作するはずです）。
Two of the most common examples of operations resulting in message uploads are:
メッセージのアップロードをもたらす操作の最も一般的な例の2つは次のとおりです。
1) Saving a draft message
1) ドラフトメッセージを保存します
2) Copying a message between remote mailboxes on two different IMAP servers or a local mailbox and a remote mailbox.
2) 2つの異なるIMAPサーバー上のリモートメールボックス間のメッセージをコピーするか、ローカルメールボックスとリモートメールボックス。
Message upload is performed with the APPEND command. A message scheduled to be uploaded has no UID associated with it, as all UIDs are assigned by the server. The APPEND command will effectively associate a UID with the uploaded message that can be stored in the local cache for future reference. However, [IMAP4] doesn't describe a simple mechanism to discover the message UID by just performing the APPEND command. In order to discover the UID, the client can do one of the following:
メッセージのアップロードは、appendコマンドで実行されます。すべてのUIDがサーバーによって割り当てられているため、アップロードするようにスケジュールされたメッセージにはUIDが関連付けられていません。Appendコマンドは、将来の参照のためにローカルキャッシュに保存できるアップロードされたメッセージにUIDを効果的に関連付けます。ただし、[IMAP4]は、Appendコマンドを実行するだけでメッセージUIDを発見する簡単なメカニズムを説明していません。UIDを発見するために、クライアントは次のいずれかを実行できます。
1) Remove the uploaded message from cache. Then, use the mechanism described in 4.3 to fetch the information about the uploaded message as if it had been uploaded by some other client.
1) アップロードされたメッセージをキャッシュから削除します。次に、4.3で説明されているメカニズムを使用して、アップロードされたメッセージに関する情報を他のクライアントによってアップロードしたかのように取得します。
2) Try to fetch header information as described in 4.2.2 in order to find a message that corresponds to the uploaded message. One strategy for doing this is described in 4.2.2.
2) アップロードされたメッセージに対応するメッセージを見つけるために、4.2.2で説明されているようにヘッダー情報を取得してみてください。これを行うための1つの戦略は、4.2.2で説明されています。
Case 1 describes a not particularly smart client.
ケース1は、特にスマートなクライアントではないと説明しています。
C: A003 APPEND Drafts (\Seen $MDNSent) {310}
S: + Ready for literal data
C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
C: From: Fred Foobar <foobar@blt.example.COM>
C: Subject: afternoon meeting
C: To: mooch@owatagu.siam.edu
C: Message-Id: <B27397-0100000@blt.example.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
Fortunately, there is a simpler way to discover the message UID in the presence of the [UIDPLUS] extension:
幸いなことに、[uidplus]拡張機能の存在下でメッセージを発見する簡単な方法があります。
C: A003 APPEND Drafts (\Seen $MDNSent) {310}
S: + Ready for literal data
C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
C: From: Fred Foobar <foobar@blt.example.COM>
C: Subject: afternoon meeting
C: To: mooch@owatagu.siam.edu
C: Message-Id: <B27397-0100000@blt.example.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 [APPENDUID 1022843275 77712] APPEND completed
The UID of the appended message is the second parameter of APPENDUID response code.
追加されたメッセージのUIDは、appenduid応答コードの2番目のパラメーターです。
Practical experience with IMAP and other mailbox access protocols that support multiple mailboxes suggests that moving a message from one mailbox to another is an extremely common operation.
複数のメールボックスをサポートするIMAPおよびその他のメールボックスアクセスプロトコルでの実際の経験は、あるメールボックスから別のメールボックスにメッセージを移動することが非常に一般的な操作であることを示唆しています。
In IMAP4, a "move" operation between two mailboxes on the same server is really a combination of a COPY operation and a STORE +FLAGS (\Deleted) operation. This makes good protocol sense for IMAP, but it leaves a simple-minded disconnected client in the silly position of deleting and possibly expunging its cached copy of a message, then fetching an identical copy via the network.
IMAP4では、同じサーバー上の2つのメールボックス間の「移動」操作は、実際にはコピー操作とストアフラグ（\削除）操作の組み合わせです。これはIMAPにとって良いプロトコルを意味しますが、メッセージのキャッシュされたコピーを削除し、おそらく削除し、ネットワークを介して同一のコピーを取得するという愚かな位置に単純な切断されたクライアントを残します。
However, the presence of the UIDPLUS extension in the server can help:
ただし、サーバー内のuidplus拡張機能の存在は次のとおりです。
C: A001 UID COPY 567,414 "Interesting Messages"
S: A001 OK [COPYUID 1022843275 414,567 5:6] Completed
This tells the client that the message with UID 414 in the current mailbox was successfully copied to the mailbox "Interesting Messages" and was given the UID 5, and that the message with UID 567 was given the UID 6.
これにより、現在のメールボックスにあるUID 414のメッセージがメールボックス「興味深いメッセージ」に正常にコピーされ、UID 5に与えられ、UID 567のメッセージにUID 6が与えられたことがクライアントに伝えます。
In the absence of UIDPLUS extension support in the server, the following trick can be used. By including the Message-ID: header and the INTERNALDATE data item as part of the descriptor, the client can check the descriptor of a "new" message against messages that are already in its cache and avoid fetching the extra copy. Of course, it's possible that the cost of checking to see if the message is already in the local cache may exceed the cost of just fetching it, so this technique should not be used blindly. If the MUA implements a "move" command, it makes special provisions to use this technique when it knows that a copy/delete sequence is the result of a "move" command.
サーバーにuidplus拡張サポートがない場合、次のトリックを使用できます。メッセージ-ID：ヘッダーと内部デートデータ項目を記述子の一部として含めることにより、クライアントは、すでにキャッシュに含まれているメッセージに対する「新しい」メッセージの記述子をチェックし、追加のコピーの取得を避けることができます。もちろん、メッセージが既にローカルキャッシュにあるかどうかを確認するためにチェックするコストが、それを取得するだけのコストを超える可能性があるため、この手法は盲目的に使用すべきではありません。MUAが「移動」コマンドを実装している場合、コピー/削除シーケンスが「移動」コマンドの結果であることがわかっている場合、この手法を使用する特別な規定を作成します。
Note that servers are not required (although they are strongly encouraged with "SHOULD language") to preserve INTERNALDATE when copying messages.
メッセージをコピーするときに内部dateを保持するためには、サーバーは必要ではないことに注意してください（「言語が必要なのは言語」では強く奨励されていますが）。
Also note that since it's theoretically possible for this algorithm to find the wrong message (given sufficiently malignant Message-ID headers), implementers should provide a way to disable this optimization, both permanently and on a message-by-message basis.
また、このアルゴリズムが間違ったメッセージ（十分に悪性のメッセージ-IDヘッダーが与えられた場合）を見つけることは理論的には可能であるため、実装者は、この最適化を永続的およびメッセージごとに無効にする方法を提供する必要があることに注意してください。
Example 1: Copying a message in the absence of UIDPLUS extension.
例1：uidplus拡張機能がない場合にメッセージをコピーします。
At some point in time the client has fetched the source message and some information was cached:
ある時点で、クライアントはソースメッセージを取得し、いくつかの情報がキャッシュされました。
C: C021 UID FETCH <uids> (BODY.PEEK[] INTERNALDATE FLAGS)
...
S: * 27 FETCH (UID 123 INTERNALDATE "31-May-2002 05:26:59 -0600"
FLAGS (\Draft $MDNSent) BODY[] {1036}
S: ...
S: Message-Id: <20040903110856.22a127cd@chardonnay>
S: ...
S: ...message body...
S: )
...
S: C021 OK fetch completed
Later on, the client decides to copy the message:
後で、クライアントはメッセージをコピーすることにしました。
C: C035 UID COPY 123 "Interesting Messages"
S: C035 OK Completed
As the server hasn't provided the COPYUID response code, the client tries the optimization described above:
サーバーはCopyUID応答コードを提供していないため、クライアントは上記の最適化を試みます。
C: C036 SELECT "Interesting Messages"
...
C: C037 UID SEARCH ON 31-May-2002 HEADER
"Message-Id" "20040903110856.22a127cd@chardonnay"
S: SEARCH 12368
S: C037 OK completed
Note that if the server has returned multiple UIDs in the SEARCH response, the client MUST NOT use any of the returned UID.
サーバーが検索応答で複数のUIDを返した場合、クライアントは返されたUIDを使用してはならないことに注意してください。
Moving a message from a remote mailbox to a local is done with FETCH (that includes FLAGS and INTERNALDATE) followed by UID STORE <uid> +FLAGS.SILENT (\Deleted):
リモートメールボックスからローカルへのメッセージの移動は、Fetch（フラグと内部デートを含む）で行われます。
C: A003 UID FETCH 123 (BODY.PEEK[] INTERNALDATE FLAGS)
S: * 27 FETCH (UID 123 INTERNALDATE "31-May-2002 05:26:59 -0600"
FLAGS (\Seen $MDNSent) BODY[]
S: ...message body...
S: )
S: A003 OK UID FETCH completed
C: A004 UID STORE <uid> +FLAGS.SILENT (\Deleted)
S: A004 STORE completed
Note that there is no reason to fetch the message during synchronization if it's already in the client's cache. Also, the client SHOULD preserve delivery date in the local cache.
既にクライアントのキャッシュに含まれている場合、同期中にメッセージを取得する理由はないことに注意してください。また、クライアントはローカルキャッシュに配達日を保持する必要があります。
Moving a message from a local mailbox to a remote is done with APPEND:
メッセージをローカルメールボックスからリモコンに移動すると、append：
C: A003 APPEND Drafts (\Seen $MDNSent) "31-May-2002 05:26:59 -0600"
{310}
S: + Ready for literal data
C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
C: From: Fred Foobar <foobar@blt.example.COM>
C: Subject: afternoon meeting
C: To: mooch@owatagu.siam.edu
C: Message-Id: <B27397-0100000@blt.example.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 [APPENDUID 1022843275 77712] completed
The client SHOULD specify the delivery date from the local cache in the APPEND.
クライアントは、付録のローカルキャッシュから配信日を指定する必要があります。
If the [LITERAL+] extension is available, the client can save a
round-trip*:
C: A003 APPEND Drafts (\Seen $MDNSent) "31-May-2002 05:26:59 -0600"
{310+}
C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
C: From: Fred Foobar <foobar@blt.example.COM>
C: Subject: afternoon meeting
C: To: mooch@owatagu.siam.edu
C: Message-Id: <B27397-0100000@blt.example.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 [APPENDUID 1022843275 77712] completed
* Note that there is a risk that the server will reject the message due to its size. If this happens, the client will waste bandwidth transferring the whole message. If the client wouldn't have used the LITERAL+, this could have been avoided:
* サーバーがそのサイズのためにメッセージを拒否するリスクがあることに注意してください。これが発生した場合、クライアントはメッセージ全体を転送する帯域幅を無駄にします。クライアントが文字通りを使用しなかった場合、これは避けられた可能性があります。
C: A003 APPEND Drafts (\Seen $MDNSent) "31-May-2004 05:26:59 -0600"
{16777215}
S: A003 NO Sorry, message is too big
Moving a message between two mailbox on two different servers is a combination of the operations described in 4.2.2.2 followed by the operations described in 4.2.2.3.
2つの異なるサーバーの2つのメールボックス間でメッセージを移動すると、4.2.2.2で説明されている操作に続いて4.2.2.3で説明されている操作が組み合わされています。
When there is a need to upload multiple messages to a remote mailbox (e.g., as per 4.2.2.3), the presence of certain IMAP extensions may significantly improve performance. One of them is [MULTIAPPEND].
複数のメッセージをリモートメールボックスにアップロードする必要がある場合（たとえば、4.2.2.3によると）、特定のIMAP拡張機能の存在はパフォーマンスを大幅に改善する可能性があります。そのうちの1つは[MultiaPend]です。
For some mail stores, opening a mailbox for appending might be expensive. [MULTIAPPEND] tells the server to open the mailbox once (instead of opening and closing it "n" times per "n" messages to be uploaded) and to keep it open while a group of messages is being uploaded to the server.
一部の郵便物店では、追加のためにメールボックスを開くのは高価かもしれません。[MultiaPend]は、（アップロードするn "メッセージごとに「n」n"メッセージを開閉する代わりに、メールボックスを1回開くのではなく、メールボックスを1回開くようにサーバーに指示し、メッセージのグループがサーバーにアップロードされている間に開いたままにします。
Also, if the server supports both [MULTIAPPEND] and [LITERAL+] extensions, the entire upload is accomplished in a single command/response round-trip.
また、サーバーが[MultiaPend]と[リテラル]拡張機能の両方をサポートする場合、アップロード全体が単一のコマンド/応答のラウンドトリップで達成されます。
Note: Client implementers should be aware that [MULTIAPPEND] performs append of multiple messages atomically. This means, for example, if there is not enough space to save "n"-th message (or the message has invalid structure and is rejected by the server) after successful upload of "n-1" messages, the whole upload operation fails, and no message will be saved in the mailbox. Although this behavior might be desirable in certain situations, it might not be what you want. Otherwise, the client should use the regular APPEND command (Section 4.2.2.3), possibly utilizing the [LITERAL+] extension. See also Section 5.1 for discussions about error recovery.
注：クライアントの実装者は、[MultiaPend]が複数のメッセージの追加を原子的に実行することに注意する必要があります。これは、たとえば、「N-1」メッセージのアップロードが成功した後、「n」メッセージ（またはメッセージが無効な構造があり、サーバーによって拒否される）を保存するのに十分なスペースがない場合、アップロード操作全体が失敗することを意味します。、そしてメールボックスにメッセージは保存されません。この動作は特定の状況で望ましいかもしれませんが、それはあなたが望むものではないかもしれません。それ以外の場合、クライアントは通常の追加コマンド（セクション4.2.2.3）を使用して、[リテラル]拡張機能を使用する可能性があります。エラー回復に関する議論については、セクション5.1も参照してください。
Note: MULTIAPPEND can be used together with the UIDPLUS extension in a way similar to what was described in Section 4.2.1. [MULTIAPPEND] extends the syntax of the APPENDUID response code to allow for multiple message UIDs in the second parameter.
注：MultiaPendは、セクション4.2.1で説明されているものと同様の方法で、uidplus拡張機能と一緒に使用できます。[MultiaPend] appenduid応答コードの構文を拡張して、2番目のパラメーターで複数のメッセージUIDを可能にします。
Example 2:
例2：
This example demonstrates the use of MULTIAPPEND together with UIDPLUS (synchronization points where the client waits for confirmations from the server are marked with "<--->"):
この例では、uidplusと一緒にマルチアドペンドの使用を示しています（クライアントがサーバーからの確認を待つ同期ポイントに「<--->」でマークされている）：
C: A003 APPEND Jan-2002 (\Seen $MDNSent) "31-May-2002 05:26:59 -0600"
{310}
<--->
S: + Ready for literal data
C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
C: From: Fred Foobar <foobar@blt.example.COM>
C: Subject: afternoon meeting
C: To: mooch@owatagu.siam.edu
C: Message-Id: <B27397-0100000@blt.example.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: (\Seen) " 1-Jun-2002 22:43:04 -0800" {286}
<--->
S: + Ready for literal data
C: Date: Mon, 7 Feb 1994 22:43:04 -0800 (PST)
C: From: Joe Mooch <mooch@OWaTaGu.siam.EDU>
C: Subject: Re: afternoon meeting
C: To: foobar@blt.example.com
C: Message-Id: <a0434793874930@OWaTaGu.siam.EDU>
C: MIME-Version: 1.0
C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
C:
C: 3:30 is fine with me.
C:
S: A003 OK [APPENDUID 1022843275 77712,77713] completed
The upload takes 3 round-trips.
アップロードには3つの往復が必要です。
Example 3:
例3：
In this example, Example 2 was modified for the case when the server supports MULTIAPPEND, LITERAL+, and UIDPLUS. The upload takes only 1 round-trip.
この例では、サーバーがMultiaPend、リテラル、およびuidplusをサポートする場合、例2が変更されました。アップロードには1回の往復のみが必要です。
C: A003 APPEND Jan-2002 (\Seen $MDNSent) "31-May-2002 05:26:59 -0600"
{310+}
C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
C: From: Fred Foobar <foobar@blt.example.COM>
C: Subject: afternoon meeting
C: To: mooch@owatagu.siam.edu
C: Message-Id: <B27397-0100000@blt.example.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: (\Seen) " 1-Jun-2002 22:43:04 -0800" {286+}
C: Date: Mon, 7 Feb 1994 22:43:04 -0800 (PST)
C: From: Joe Mooch <mooch@OWaTaGu.siam.EDU>
C: Subject: Re: afternoon meeting
C: To: foobar@blt.example.com
C: Message-Id: <a0434793874930@OWaTaGu.siam.EDU>
C: MIME-Version: 1.0
C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
C:
C: 3:30 is fine with me.
C:
S: A003 OK [APPENDUID 1022843275 77712,77713] completed
The disconnected client uses the STORE command to synchronize local flag state with the server. The disconnected client SHOULD use +FLAGS.SILENT or -FLAGS.SILENT in order to set or unset flags modified by the user while offline. The FLAGS form MUST NOT be used, as there is a risk that this will overwrite flags on the server that have been changed by some other client.
切断されたクライアントは、Storeコマンドを使用して、ローカルフラグ状態をサーバーと同期させます。切断されたクライアントは、オフライン中にユーザーが変更したフラグを設定または設定するために、flags.silentまたは-flags.silentを使用する必要があります。フラグフォームは、他のクライアントによって変更されたサーバー上のフラグを上書きするリスクがあるため、使用してはなりません。
Example 4:
例4：
For the message with UID 15, the disconnected client stores the following flags \Seen and $Highest. The flags were modified on the server by some other client: \Seen, \Answered, and $Highest. While offline, the user requested that the $Highest flags be removed and that the \Deleted flag be added. The flag synchronization sequence for the message should look like:
UID 15を使用したメッセージの場合、切断されたクライアントは次のフラグを保存し、$ Hightsを保存します。フラグは、他のクライアントによってサーバー上で変更されました：\ seed、\ nessured、$ hight。オフライン中、ユーザーは、$最高のフラグを削除し、\削除されたフラグを追加することを要求しました。メッセージのフラグ同期シーケンスは次のようになります。
C: A001 UID STORE 15 +FLAGS.SILENT (\Deleted)
S: A001 STORE completed
C: A002 UID STORE 15 -FLAGS.SILENT ($Highest)
S: A002 STORE completed
If the disconnected client is able to store an additional binary state information (or a piece of information that can take a value from a predefined set of values) in the local cache of an IMAP mailbox or in a local mailbox (e.g., message priority), and if the server supports storing of arbitrary keywords, the client MUST use keywords to store this state on the server.
切断されたクライアントが、IMAPメールボックスのローカルキャッシュまたはローカルメールボックス（たとえば、メッセージの優先順位）に追加のバイナリ状態情報（または事前定義された値のセットから値を取得できる情報）を追加することができる場合、そして、サーバーが任意のキーワードの保存をサポートする場合、クライアントはキーワードを使用してこの状態をサーバーに保存する必要があります。
Example 5:
例5：
Imagine a speculative mail client that can mark a message as one of work-related ($Work), personal ($Personal), or spam ($Spam). In order to mark a message as personal, the client issues:
メッセージに関連する（$ work）、personal（$ personal）、またはspam（$ spam）の1つとしてメッセージをマークできる投機的なメールクライアントを想像してください。メッセージを個人としてマークするために、クライアントの問題：
C: A001 UID STORE 15 +FLAGS.SILENT ($Personal)
S: A001 STORE completed
C: A002 UID STORE 15 -FLAGS.SILENT ($Work $Spam)
S: A002 STORE completed
In order to mark the message as not work, not personal and not spam, the client issues:
メッセージを機能していない、個人的ではなくスパムではないとマークするために、クライアントは次の問題を発行します。
C: A003 UID STORE 15 -FLAGS.SILENT ($Personal $Work $Spam)
S: A003 STORE completed
A naive disconnected client implementation that supports compressing a mailbox while offline may decide to issue an EXPUNGE command to the server in order to expunge messages marked \Deleted. The problem with this command during synchronization is that it permanently erases all messages with the \Deleted flag set, i.e., even those messages that were marked as \Deleted on the server while the user was offline. Doing this might result in an unpleasant surprise for the user.
オフライン中にメールボックスの圧縮をサポートする素朴な切断されたクライアント実装は、マークされたメッセージを削除するために、サーバーにobungeコマンドを発行することを決定する場合があります。同期中のこのコマンドの問題は、\削除されたフラグセットですべてのメッセージを永久に消去することです。つまり、ユーザーがオフラインである間にサーバーで削除されたものとしてマークされたメッセージでさえさえです。これを行うと、ユーザーにとって不快な驚きになる可能性があります。
Fortunately the [UIDPLUS] extension can help in this case as well. The extension introduces UID EXPUNGE command, that, unlike EXPUNGE, takes a UID set parameter, that lists UIDs of all messages that can be expunged. When processing this command the server erases only messages with \Deleted flag listed in the UID list. Thus, messages not listed in the UID set will not be expunged even if they have the \Deleted flag set.
幸いなことに、[uidplus]拡張機能もこの場合に役立ちます。拡張機能は、expungeとは異なり、owidセットパラメーターを取得し、削除できるすべてのメッセージのuidをリストするuid expungeコマンドを導入します。このコマンドを処理するとき、サーバーはUIDリストにリストされている\削除フラグを使用してメッセージのみを消去します。したがって、UIDセットにリストされていないメッセージは、\削除されたフラグセットがある場合でも削除されません。
Example 6:
例6：
While the user was offline, 3 messages with UIDs 7, 27, and 65 were marked \Deleted when the user requested to compress the open mailbox. Another client marked a message \Deleted on the server (UID 34). During synchronization, the disconnected client issues:
ユーザーがオフラインである間、UID 7、27、および65の3つのメッセージが、ユーザーがオープンメールボックスの圧縮を要求したときに削除されました。別のクライアントは、サーバーで削除されたメッセージ\をマークしました（UID 34）。同期中、切断されたクライアントの問題：
C: A001 UID EXPUNGE 7,27,65
S: * ... EXPUNGE
S: * ... EXPUNGE
S: * ... EXPUNGE
S: A001 UID EXPUNGE completed
If another client issues UID SEARCH DELETED command (to find all messages with the \Deleted flag) before and after the UID EXPUNGE, it will get:
別のクライアントがUID検索削除されたコマンドを発行すると（\削除されたフラグを使用してすべてのメッセージを見つけるため）、UID消去の前後に、次のことが得られます。
Before:
前：
C: B001 UID SEARCH DELETED
S: * SEARCH 65 34 27 7
S: B001 UID SEARCH completed
After:
後：
C: B002 UID SEARCH DELETED
S: * SEARCH 34
S: B002 UID SEARCH completed
In the absence of the [UIDPLUS] extension, the following sequence of commands can be used as an approximation. Note: It's possible for another client to mark additional messages as deleted while this sequence is being performed. In this case, these additional messages will be expunged as well.
[uidplus]拡張機能がない場合、次のコマンドのシーケンスを近似として使用できます。注：このシーケンスが実行されている間に、別のクライアントが追加のメッセージを削除したとマークする可能性があります。この場合、これらの追加のメッセージも削除されます。
1) Find all messages marked \Deleted on the server.
1) サーバーで削除されたすべてのメッセージを見つけます。
C: A001 UID SEARCH DELETED
S: * SEARCH 65 34 27 7
S: A001 UID SEARCH completed
2) Find all messages that must not be erased (for the previous example the list will consist of the message with UID 34).
2) 消去してはならないすべてのメッセージを見つけます（前の例では、リストはUID 34のメッセージで構成されます）。
3) Temporarily remove \Deleted flag on all messages found in step 2.
3) ステップ2で見つかったすべてのメッセージで削除されたフラグを一時的に削除します。
C: A002 UID STORE 34 -FLAGS.SILENT (\Deleted)
S: A002 UID STORE completed
4) Expunge the mailbox.
4) メールボックスを削除します。
C: A003 EXPUNGE
S: * 20 EXPUNGE
S: * 7 EXPUNGE
S: * 1 EXPUNGE
S: A003 EXPUNGE completed
Here, the message with UID 7 has message number 1, with UID 27 has message number 7, and with UID 65 has message number 20.
ここで、UID 7のメッセージにはメッセージ番号1があり、UID 27にはメッセージ番号7があり、UID 65のメッセージ番号20があります。
5) Restore \Deleted flag on all messages found when performing step 2.
5) ステップ2を実行するときに見つかったすべてのメッセージで削除されたフラグを復元します。
C: A004 UID STORE 34 +FLAGS.SILENT (\Deleted)
S: A004 UID STORE completed
When the disconnected client has to close a mailbox, it should not use the CLOSE command, because CLOSE does a silent EXPUNGE. (Section 4.2.4 explains why EXPUNGE should not be used by a disconnected client.) It is safe to use CLOSE only if the mailbox was opened with EXAMINE.
切断されたクライアントがメールボックスを閉じる必要がある場合、Closeはサイレントオーバーを行うため、Closeコマンドを使用しないでください。（セクション4.2.4では、除外されたクライアントが抹消するべきではない理由を説明しています。）検査でメールボックスが開かれた場合にのみ、閉じることが安全です。
If the mailbox was opened with SELECT, the client can use one of the following commands to implicitly close the mailbox and prevent the silent expunge:
メールボックスがSelectで開かれた場合、クライアントは次のコマンドのいずれかを使用して、メールボックスを暗黙的に閉じて、サイレントオーバーを防ぐことができます。
1) UNSELECT - This is a command described in [UNSELECT] that works as CLOSE, but doesn't cause the silent EXPUNGE. This command is supported by the server if it reports UNSELECT in its CAPABILITY list.
1) UNSELECT-これは、[Unselect]で説明されているコマンドであり、近くに機能しますが、サイレント消去を引き起こしません。このコマンドは、機能リストにunselectを報告する場合、サーバーによってサポートされています。
2) SELECT <another_mailbox> - SELECT causes implicit CLOSE without EXPUNGE.
2) <Another_Mailbox>を選択します - 抹消せずに暗黙の閉じる原因を選択します。
3) If the client intends to issue LOGOUT after closing the mailbox, it may just issue LOGOUT, because LOGOUT causes implicit CLOSE without EXPUNGE as well.
3) クライアントがメールボックスを閉じた後にログアウトを発行する予定の場合、ログアウトは抹消せずに暗黙的に近づくため、ログアウトを発行するだけです。
4) SELECT <non_existing_mailbox> - If the client knows a mailbox that doesn't exist or can't be selected, it MAY SELECT it.
4) <non_existing_mailbox>を選択します - クライアントが存在しない、または選択できないメールボックスを知っている場合、選択する場合があります。
If the client opened the mailbox with SELECT and just wants to avoid implicit EXPUNGE without closing the mailbox, it may also use the following:
クライアントがselectでメールボックスを開いた場合、メールボックスを閉じることなく暗黙の抹消を避けたい場合は、以下を使用する場合もあります。
5) EXAMINE <mailbox> - Reselect the same mailbox in read-only mode.
5) <mailbox> - 同じメールボックスを読み取り専用モードで再選択します。
The most common form of synchronization is where the human trusts the integrity of the client's copy of the state of a particular mailbox and simply wants to bring the client's cache up to date so that it accurately reflects the mailbox's current state on the server.
同期の最も一般的な形式は、人間が特定のメールボックスの状態のクライアントのコピーの完全性を信頼し、クライアントのキャッシュを最新の状態にして、サーバー上のメールボックスの現在の状態を正確に反映するようにすることです。
Let <lastseenuid> represent the highest UID that the client knows about in this mailbox. Since UIDs are allocated in strictly ascending order, this is simply the UID of the last message in the mailbox that the client knows about. Let <lastseenuid+1> represent <lastseenuid>'s UID plus one. Let <descriptors> represent a list consisting of all the FETCH data item items that the implementation considers part of the descriptor; at a minimum this is just the FLAGS data item, but it usually also includes BODYSTRUCTURE and RFC822.SIZE. At this step, <descriptors> SHOULD NOT include RFC822.
<lastseenuid>は、クライアントがこのメールボックスで知っている最高のUIDを表します。UIDは厳密に昇順で割り当てられているため、これはクライアントが知っているメールボックス内の最後のメッセージのUIDです。<lastseenuid 1>は<lastseenuid>のuidと1を表します。<descriptors>は、実装が記述子の一部と見なすすべてのFetch Data Iterm項目で構成されるリストを表します。少なくともこれはフラグデータ項目にすぎませんが、通常はボディストラクチャとRFC822.sizeも含まれます。このステップでは、<descriptors>をrfc822を含めるべきではありません。
With no further information, the client can issue the following two commands:
それ以上の情報がないと、クライアントは次の2つのコマンドを発行できます。
tag1 UID FETCH <lastseenuid+1>:* <descriptors>
tag2 UID FETCH 1:<lastseenuid> FLAGS
The first command will request some information about "new" messages (i.e., messages received by the server since the last synchronization). It will also allow the client to build a message number to UID map (only for new messages). The second command allows the client to
最初のコマンドは、「新しい」メッセージ（つまり、最後の同期以降にサーバーが受信したメッセージ）に関する情報を要求します。また、クライアントがUIDマップにメッセージ番号を作成することもできます（新しいメッセージのみ）。2番目のコマンドは、クライアントを許可します
1) update cached flags for old messages;
1) 古いメッセージのキャッシュフラグを更新します。
2) find out which old messages got expunged; and
2) どの古いメッセージが削除されたかを調べます。と
3) build a mapping between message numbers and UIDs (for old messages).
3) メッセージ番号とUIDの間にマッピングを作成します（古いメッセージ用）。
The order here is significant. We want the server to start returning the list of new message descriptors as fast as it can, so that the client can start issuing more FETCH commands, so we start out by asking for the descriptors of all the messages we know the client cannot possibly have cached yet. The second command fetches the information we need to determine what changes may have occurred to messages that the client already has cached. Note that the former command should only be issued if the UIDNEXT value cached by the client differs from the one returned by the server. Once the client has issued these two commands, there's nothing more the client can do with this mailbox until the responses to the first command start arriving. A clever synchronization program might use this time to fetch its local cache state from disk or to start the process of synchronizing another mailbox.
ここでの順序は重要です。クライアントがより多くのフェッチコマンドの発行を開始できるように、できるだけ速く新しいメッセージ記述子のリストの返品をサーバーに開始するようにしたいので、クライアントが持つことができないすべてのメッセージの記述子を要求することから始めますまだキャッシュされています。2番目のコマンドは、クライアントがすでにキャッシュしているメッセージにどのような変更が発生したかを決定するために必要な情報を取得します。前者のコマンドは、クライアントによってキャッシュされたuidnext値がサーバーによって返されたものとは異なる場合にのみ発行する必要があることに注意してください。クライアントがこれらの2つのコマンドを発行すると、最初のコマンドへの応答が到着するまで、クライアントがこのメールボックスでできることはこれ以上ありません。巧妙な同期プログラムは、この時間を使用して、ディスクからローカルキャッシュ状態を取得したり、別のメールボックスを同期するプロセスを開始する場合があります。
The following is an example of the first FETCH:
以下は、最初のフェッチの例です。
C: A011 UID fetch 131:* (FLAGS BODYSTRUCTURE INTERNALDATE RFC822.SIZE)
C：A011 UID FETCH 131：*（Flags BodyStructure InternalDate RFC822.Size）
Note 1: The first FETCH may result in the server's sending a huge volume of data. A smart disconnected client should use message ranges (see also Section 3.2.1.2 of [RFC2683]), so that the user is able to execute a different operation between fetching information for a group of new messages.
注1：最初のフェッチにより、サーバーが膨大な量のデータを送信する場合があります。スマート切断されたクライアントは、メッセージ範囲を使用する必要があります（[RFC2683]のセクション3.2.1.2も参照）。これにより、ユーザーは新しいメッセージのグループの情報を取得する間に異なる操作を実行できます。
Example 7:
例7：
Knowing the new UIDNEXT returned by the server on SELECT or EXAMINE (<uidnext>), the client can split the UID range <lastseenuid+1>:<uidnext> into groups, e.g., 100 messages. After that, the client can issue:
SelectまたはExectine（<uidnext>）でサーバーによって返された新しいuidnextを知っていると、クライアントはuid範囲<lastSeenuid1>：<uidnext>をグループに分割できます。たとえば、100のメッセージ。その後、クライアントは次のことを発行できます。
C: A011 UID fetch <lastseenuid+1>:<lastseenuid+100>
(FLAGS BODYSTRUCTURE INTERNALDATE RFC822.SIZE)
...
C: A012 UID fetch <lastseenuid+101>:<lastseenuid+200>
(FLAGS BODYSTRUCTURE INTERNALDATE RFC822.SIZE)
...
...
C: A0FF UID fetch <lastseenuid+901>:<uidnext>
(FLAGS BODYSTRUCTURE INTERNALDATE RFC822.SIZE)
Note that unless a SEARCH command is issued, it is impossible to determine how many messages will fall into a subrange, as UIDs are not necessarily contiguous.
検索コマンドが発行されない限り、UIDは必ずしも隣接しているわけではないため、サブランジに該当するメッセージの数を判断することは不可能であることに注意してください。
Note 2: The client SHOULD ignore any unsolicited EXPUNGE responses received during the first FETCH command. EXPUNGE responses contain message numbers that are useless to a client that doesn't have the message-number-to-UID translation table.
注2：クライアントは、最初のFetchコマンド中に受信した未承諾の抹消応答を無視する必要があります。expunge応答には、メッセージ番号からUIDへの翻訳テーブルがないクライアントには役に立たないメッセージ番号が含まれています。
The second FETCH command will result in zero or more untagged fetch responses. Each response will have a corresponding UID FETCH data item. All messages that didn't have a matching untagged FETCH response MUST be removed from the local cache.
2番目のFetchコマンドは、ゼロ以上の攻撃されていないフェッチ応答になります。各応答には、対応するUIDフェッチデータ項目があります。一致していないUntagged Fetch Responseを持っていなかったすべてのメッセージは、ローカルキャッシュから削除する必要があります。
For example, if the <lastseenuid> had a value 15000 and the local cache contained 3 messages with the UIDs 12, 777, and 14999, respectively, then after receiving the following responses from the server, the client must remove the message with UID 14999 from its local cache.
たとえば、<lastSeenuid>に値15000があり、ローカルキャッシュにそれぞれUIDS 12、777、および14999に3つのメッセージが含まれていた場合、サーバーから次の応答を受信した後、クライアントはUID 14999でメッセージを削除する必要があります。ローカルキャッシュから。
S: * 1 FETCH (UID 12 FLAGS (\Seen))
S: * 2 FETCH (UID 777 FLAGS (\Answered \Deleted))
Note 3: If the client is not interested in flag changes (i.e., the client only wants to know which old messages are still on the server), the second FETCH command can be substituted with:
注3：クライアントがフラグの変更に関心がない場合（つまり、クライアントはどの古いメッセージがサーバー上にあるかを知りたいだけです）、2番目のFetchコマンドには次のものを置き換えることができます。
tag2 UID SEARCH UID 1:<lastseenuid>
This command will generate less traffic. However, an implementor should be aware that in order to build the mapping table from message numbers to UIDs, the output of the SEARCH command MUST be sorted first, because there is no requirement for a server to return UIDs in SEARCH response in any particular order.
このコマンドは、より少ないトラフィックを生成します。ただし、実装者は、メッセージ番号からUIDにマッピングテーブルを構築するには、検索コマンドの出力を最初にソートする必要があることに注意する必要があります。。
4.3.2. Searching for "Interesting" Messages.
4.3.2. 「興味深い」メッセージを検索します。
This step is performed entirely on the client (from the information received in the step described in 4.3.1), entirely on the server, or on some combination of both. The decision on what is an "interesting" message is up to the client software and the human. One easy criterion that should probably be implemented in any client is whether the message is "too big" for automatic retrieval, where "too big" is a parameter defined in the client's configuration.
このステップは、完全にクライアント（4.3.1で説明されているステップで受け取った情報から）、完全にサーバーで、または両方の組み合わせで実行されます。「興味深い」メッセージとは何かに関する決定は、クライアントソフトウェアと人間次第です。おそらく、クライアントにおそらく実装する必要がある簡単な基準の1つは、メッセージが自動検索に対して「大きすぎる」かどうかです。「大きすぎる」は、クライアントの構成で定義されているパラメーターです。
Another commonly used criterion is the age of a message. For example, the client may choose to download only messages received in the last week (in this case, <date> would be today's date minus 7 days):
一般的に使用される別の基準は、メッセージの時代です。たとえば、クライアントは、先週受信したメッセージのみをダウンロードすることを選択できます（この場合、<date>は今日の日付から7日間です）：
tag3 UID SEARCH UID <uidset> SINCE <date>
Keep in mind that a date search disregards time and time zone. The client can avoid doing this search if it specified INTERNALDATE in <descriptors> on the step described in 4.3.1. If the client did, it can perform the local search on its message cache.
日付検索は時間とタイムゾーンを無視することに注意してください。クライアントは、4.3.1で説明されているステップで<descriptors>でinternaldateを指定した場合、この検索を行うことを避けることができます。クライアントが行った場合、メッセージキャッシュでローカル検索を実行できます。
At this step, the client also decides what kind of information about a particular message to fetch from the server. In particular, even for a message that is considered "too big", the client MAY choose to fetch some part(s) of it. For example, if the message is a multipart/mixed containing a text part and a MPEG attachment, there is no reason for the client not to fetch the text part. The decision of which part should or should not be fetched can be based on the information received in the BODYSTRUCTURE FETCH response data item (i.e., if BODYSTRUCTURE was included in <descriptors> on the step described in 4.3.1).
このステップで、クライアントは、サーバーからフェッチする特定のメッセージに関する情報の種類も決定します。特に、「大きすぎる」と見なされるメッセージの場合でも、クライアントはその一部を取得することを選択できます。たとえば、メッセージがテキストパーツとMPEGの添付ファイルを含むマルチパート/混合である場合、クライアントがテキストパーツを取得しない理由はありません。どの部分を取得すべきか、または入力すべきでないかの決定は、ボディストラクチャフェッチ応答データ項目で受け取った情報に基づいています（つまり、4.3.1に記載されているステップで<decriptors>にボディ構造が含まれている場合）。
4.3.3. Populating Cache with "Interesting" Messages.
4.3.3. キャッシュに「興味深い」メッセージを入力します。
Once the client has found out which messages are "interesting", it can start issuing appropriate FETCH commands for "interesting" messages or parts thereof.
クライアントがどのメッセージが「興味深い」かを見つけたら、「興味深い」メッセージまたはその部分の適切なフェッチコマンドの発行を開始できます。
Note that fetching a message into the disconnected client's local cache does NOT imply that the human has (or even will) read the message. Thus, the synchronization program for a disconnected client should always be careful to use the .PEEK variants of the FETCH data items that implicitly set the \Seen flag.
切断されたクライアントのローカルキャッシュにメッセージを取得することは、人間がメッセージを読み取っている（またはそうする）ことを意味するものではないことに注意してください。したがって、切断されたクライアントの同期プログラムは、\ seedフラグを暗黙的に設定するフェッチデータ項目の.peekバリアントを常に使用するように注意する必要があります。
Once the last descriptor has arrived and the last FETCH command has been issued, the client simply needs to process the incoming fetch items and use them to update the local message cache.
最後の記述子が到着し、最後のFetchコマンドが発行されたら、クライアントは着信フェッチアイテムを処理し、それらを使用してローカルメッセージキャッシュを更新する必要があります。
In order to avoid deadlock problems, the client must give processing of received messages priority over issuing new FETCH commands during this synchronization process. This may necessitate temporary local queuing of FETCH requests that cannot be issued without causing a deadlock. In order to achieve the best use of the "expensive" network connection, the client will almost certainly need to pay careful attention to any flow-control information that it can obtain from the underlying transport connection (usually a TCP connection).
デッドロックの問題を回避するために、クライアントは、この同期プロセス中に新しいFetchコマンドを発行することよりも受信したメッセージの処理を優先する必要があります。これには、デッドロックを引き起こすことなく発行できないフェッチリクエストの一時的なローカルキューイングが必要になる場合があります。「高価な」ネットワーク接続を最大限に活用するために、クライアントは、基礎となる輸送接続（通常はTCP接続）から取得できるフロー制御情報に注意を払う必要があります。
Note: The requirement stated in the previous paragraph might result in an unpleasant user experience, if followed blindly. For example, the user might be unwilling to wait for the client to finish synchronization before starting to process the user's requests. A smart disconnected client should allow the user to perform requested operations in between IMAP commands that are part of the synchronization process. See also Note 1 in Section 4.3.1.
注：前の段落に記載されている要件は、盲目的に従うと、不快なユーザーエクスペリエンスをもたらす可能性があります。たとえば、ユーザーは、ユーザーのリクエストの処理を開始する前に、クライアントが同期を終了するのを待つことを嫌がる場合があります。スマート切断されたクライアントは、同期プロセスの一部であるIMAPコマンド間で要求された操作を実行できるようにする必要があります。セクション4.3.1の注1も参照してください。
Example 8:
例8：
After fetching a message BODYSTRUCTURE, the client discovers a complex MIME message. Then, it decides to fetch MIME headers of the nested MIME messages and some body parts.
メッセージのボディストラクチャを取得した後、クライアントは複雑なmimeメッセージを発見します。次に、ネストされたmimeメッセージといくつかの体の部分のmimeヘッダーを取得することにしました。
C: A011 UID fetch 11 (BODYSTRUCTURE)
S: ...
C: A012 UID fetch 11 (BODY[HEADER] BODY[1.MIME] BODY[1.1.MIME]
BODY[1.2.MIME] BODY[2.MIME] BODY[3.MIME] BODY[4.MIME]
BODY[5.MIME] BODY[6.MIME] BODY[7.MIME] BODY[8.MIME] BODY[9.MIME]
BODY[10.MIME] BODY[11.MIME] BODY[12.MIME] BODY[13.MIME]
BODY[14.MIME] BODY[15.MIME] BODY[16.MIME] BODY[17.MIME]
BODY[18.MIME] BODY[19.MIME] BODY[20.MIME] BODY[21.MIME])
S: ...
C: A013 UID fetch 11 (BODY[1.1] BODY[1.2])
S: ...
C: A014 UID fetch 11 (BODY[3] BODY[4] BODY[5] BODY[6] BODY[7] BODY[8]
BODY[9] BODY[10] BODY[11] BODY[13] BODY[14] BODY[15] BODY[16]
BODY[21])
S: ...
After the client has finished the main synchronization process as described in Sections 4.3.1-4.3.3, the user may optionally request additional synchronization steps while the client is still online. This is not any different from the process described in Sections 4.3.2 and 4.3.3.
セクション4.3.1-4.3.3で説明されているように、クライアントがメインの同期プロセスを終了した後、ユーザーはオプションでクライアントがまだオンラインである間に追加の同期ステップを要求する場合があります。これは、セクション4.3.2および4.3.3で説明したプロセスと違いはありません。
Typical examples are:
典型的な例は次のとおりです。
1) fetch all messages selected in UI. 2) fetch all messages marked as \Flagged on the server.
1) UIで選択されたすべてのメッセージを取得します。2）サーバーにフラグが付けられたとマークされたすべてのメッセージを取得します。
For some mailboxes, fetching the descriptors might be the entire synchronization step. Practical experience with IMAP has shown that a certain class of mailboxes (e.g., "archival" mailboxes) are used primarily for long-term storage of important messages that the human wants to have instantly available on demand but does not want cluttering up the disconnected client's cache at any other time. Messages in this kind of mailbox would be fetched exclusively by explicit actions queued by the local MUA. Thus, the only synchronization desirable on this kind of mailbox is fetching enough descriptor information for the user to be able to identify messages for subsequent download.
一部のメールボックスの場合、記述子を取得することは、完全な同期ステップである可能性があります。IMAPでの実践的な経験は、特定のクラスのメールボックス（「アーカイブ」メールボックスなど）が主に、人間がオンデマンドで即座に利用できるようにしたい重要なメッセージの長期的なストレージに使用されることを示していますが、切断されたクライアントの散らかってしまいたくない他にキャッシュ。この種のメールボックスのメッセージは、ローカルMUAがキューに掲載した明示的なアクションによってのみフェッチされます。したがって、この種のメールボックスで望ましい唯一の同期は、ユーザーがその後のダウンロードのためにメッセージを識別できるように十分な記述情報情報を取得することです。
Special mailboxes that receive messages from a high volume, low priority mailing list might also be in this category, at least when the human is in a hurry.
少なくとも人間が急いでいる場合、大量の低い優先順位メーリングリストからメッセージを受信する特別なメールボックスもこのカテゴリにある可能性があります。
In some cases, the human might be in such a hurry that he or she doesn't care about changes to old messages, just about new messages. In this case, the client can skip the UID FETCH command that obtains the flags and UIDs for old messages (1:<lastseenuid>).
場合によっては、人間は急いでいるので、古いメッセージの変更を気にしないように、新しいメッセージだけです。この場合、クライアントは、古いメッセージのフラグとUIDを取得するUID Fetchコマンドをスキップできます（1：<lastSeenuid>）。
In some cases, the human may know (for whatever reason) that he or she always wants to fetch any new messages in a particular mailbox, unconditionally. In this case, the client can just fetch the messages themselves, rather than just the descriptors, by using a command like:
場合によっては、人間は（何らかの理由で）特定のメールボックスに新しいメッセージを無条件に取得したいことを（何らかの理由で）知っているかもしれません。この場合、クライアントは、次のようなコマンドを使用して、記述子だけでなくメッセージを自分で取得できます。
tag1 UID FETCH <lastseenuid+1>:* (FLAGS BODY.PEEK[])
Note that this example ignores the fact that the messages can be arbitrary long. The disconnected client MUST always check for message size before downloading, unless explicitly told otherwise. A well-behaved client should instead use something like the following:
この例は、メッセージが任意に長くなる可能性があるという事実を無視していることに注意してください。切断されたクライアントは、明示的に特に通知されない限り、ダウンロードする前に常にメッセージサイズをチェックする必要があります。行儀の良いクライアントは、代わりに次のようなものを使用する必要があります。
1) Issue "tag1 UID FETCH <lastseenuid+1>:* (FLAGS RFC822.SIZE)".
1) 問題「tag1 uid fetch <lastseenuid 1>：*（flags rfc822.size）」 "。
2) From the message sizes returned in step 1, construct UID set <required_messages>.
2) ステップ1で返されたメッセージサイズから、uid set <rebys_messages>を作成します。
3) Issue "tag2 UID FETCH <required_messages> (BODY.PEEK[])".
3) 問題 "tag2 uid fetch <required_messages>（body.peek []）"。
or
また
1) Issue "tag1 UID FETCH <lastseenuid+1>:* (FLAGS)".
1) 問題「tag1 uid fetch <lastseenuid 1>：*（flags）」。
2) Construct UID set <old_uids> from the responses of step 1.
2) ステップ1の応答からUIDセット<Old_uids>を作成します。
3) Issue "tag2 SEARCH UID <old_uids> SMALLER <message_limit>". Construct UID set <required_messages> from the result of the SEARCH command.
3) 問題 "Tag2 Search UID <Old_Uids> Smaller <Message_limit>"。検索コマンドの結果からuid set <rebys_messages>を作成します。
4) Issue "tag3 UID FETCH <required_messages> (BODY.PEEK[])".
4) 問題 "tag3 uid fetch <required_messages>（body.peek []）"。
or
また
1) Issue "tag1 UID FETCH <lastseenuid+1>:* (FLAGS BODY.PEEK[]<0.<length>>)", where <length> should be replaced with the maximal message size the client is willing to download.
1) 問題「tag1 uid fetch <lastseenuid 1>：*（flags body.peek [] <0。<length >>）」、<length>は、クライアントが喜んでダウンロードする最大メッセージサイズに置き換える必要があります。
Note: In response to such a command, the server will only return partial data if the message is longer than <length>. It will return the full message data for any message whose size is smaller than or equal to <length>. In the former case, the client will not be able to extract the full MIME structure of the message from the truncated data, so the client should include BODYSTRUCTURE in the UID FETCH command as well.
注：このようなコマンドに応じて、メッセージが<length>より長い場合にのみ、サーバーは部分的なデータを返します。サイズが<length>以下のメッセージの完全なメッセージデータを返します。前者の場合、クライアントは切り捨てられたデータからメッセージの完全なMIME構造を抽出できないため、クライアントはUID FetchコマンドにもBodyStructureを含める必要があります。
Below are listed some common implementation pitfalls that should be considered when implementing a disconnected client.
以下に、切断されたクライアントを実装するときに考慮すべき一般的な実装落とし穴をリストします。
1) Implementing fake UIDs on the client.
1) クライアントに偽のUIDを実装します。
A message scheduled to be uploaded has no UID, as UIDs are selected by the server. The client may implement fake UIDs internally in order to reference not-yet-uploaded messages in further operations. (For example, a message could be scheduled to be uploaded, but subsequently marked as deleted or copied to another mailbox). Here, the client MUST NOT under any circumstances send these fake UIDs to the server. Also, client implementers should be reminded that according to [IMAP4] a UID is a 32-bit unsigned integer excluding 0. So, both 4294967295 and 2147483648 are valid UIDs, and 0 and -1 are both invalid. Some disconnected mail clients have been known to send negative numbers (e.g., "-1") as message UIDs to servers during synchronization.
UIDがサーバーによって選択されているため、アップロードされるようにスケジュールされたメッセージにはUIDがありません。クライアントは、さらなる操作で、まだUPLoadedメッセージを参照するために、内部的に偽のUIDを実装することができます。（たとえば、メッセージをアップロードするようにスケジュールされる可能性がありますが、その後、削除または別のメールボックスにコピーされたものとしてマークされます）。ここで、クライアントはどんな状況でもこれらの偽のUIDをサーバーに送信してはなりません。また、クライアントの実装者は、[IMAP4]によれば、UIDは0を除く32ビットの符号なし整数であることを思い出させる必要があります。したがって、4294967295と2147483648は有効なUIDであり、0と-1は両方とも不回行です。いくつかの切断されたメールクライアントは、同期中にサーバーへのメッセージuidとして負の数（「-1」など）を送信することが知られています。
Situation 1: The user starts composing a new message, edits it, saves it, continues to edit it, and saves it again.
状況1：ユーザーは、新しいメッセージの作成を開始し、編集し、保存し、編集を続け、再び保存します。
A disconnected client may record in its replay log (log of operations to be replayed on the server during synchronization) the sequence of operations as shown below. For the purpose of this situation, we assume that all draft messages are stored in the mailbox called Drafts on an IMAP server. We will also use the following conventions: <old_uid> is the UID of the intermediate version of the draft when it was saved for the first time. This is a fake UID generated on the client. <new_uid> is the UID of the final version of the draft. This is another fake UID generated on the client.
切断されたクライアントは、以下に示すように、そのリプレイログ（同期中にサーバーにリプレイされる操作のログ）に記録できます。この状況の目的のために、すべてのドラフトメッセージがIMAPサーバー上のドラフトと呼ばれるメールボックスに保存されていると想定しています。また、次の規則も使用します。<lows_uid>は、ドラフトが初めて保存されたときの中間バージョンのUIDです。これは、クライアントに生成された偽のuidです。<new_uid>は、ドラフトの最終バージョンのUIDです。これは、クライアントに生成された別の偽のUIDです。
1) APPEND Drafts (\Seen $MDNSent \Drafts) {<nnn>}
...first version of the message follows...
2) APPEND Drafts (\Seen $MDNSent \Drafts) {<mmm>}
...final version of the message follows...
3) STORE <old_uid> +FLAGS (\Deleted)
Step 1 corresponds to the first attempt to save the draft message, step 2 corresponds to the second attempt to save the draft message, and step 3 deletes the first version of the draft message saved in step 1.
ステップ1は、ドラフトメッセージを保存する最初の試みに対応し、ステップ2はドラフトメッセージを保存する2番目の試行に対応し、ステップ3はステップ1で保存されたドラフトメッセージの最初のバージョンを削除します。
A naive disconnected client may send the command in step 3 without replacing the fake client generated <old_uid> with the value returned by the server in step 1. A server will probably reject this command, which will make the client believe that the synchronization sequence has failed.
素朴な切断されたクライアントは、ステップ1のサーバーによって返される値に生成された偽のクライアントを置き換えることなく、ステップ3にコマンドを送信できます。サーバーはおそらくこのコマンドを拒否します。失敗した。
2) Section 5.1 discusses common implementation errors related to error recovery during playback.
2) セクション5.1では、再生中のエラー回復に関連する一般的な実装エラーについて説明します。
3) Don't assume that the disconnected client is the only client used by the user.
3) 切断されたクライアントがユーザーが使用する唯一のクライアントであると想定しないでください。
Situation 2: Some clients may use the \Deleted flag as an indicator that the message should not appear in the user's view. Usage of the \Deleted flag for this purpose is not safe, as other clients (e.g., online clients) might EXPUNGE the mailbox at any time.
状況2：一部のクライアントは、\削除されたフラグをユーザービューにメッセージを表示しないようにすることを指標として使用する場合があります。他のクライアント（オンラインクライアントなど）がいつでもメールボックスを削除する可能性があるため、この目的のための\削除フラグの使用は安全ではありません。
4) Beware of data dependencies between synchronization operations.
4) 同期操作間のデータ依存関係に注意してください。
It might be very tempting for a client writer to perform some optimizations on the playback log. Such optimizations might include removing redundant operations (for example, see optimization 2 in Section 5.3), or their reordering.
クライアントライターが再生ログでいくつかの最適化を実行するのは非常に魅力的かもしれません。このような最適化には、冗長操作の削除（たとえば、セクション5.3の最適化2を参照）またはそれらの並べ替えが含まれる場合があります。
It is not always safe to reorder or remove redundant operations during synchronization because some operations may have dependencies (as Situation 3 demonstrates). So, if in doubt, don't do this.
一部の操作には依存関係がある可能性があるため、同期中に冗長操作を再注文または削除することは常に安全ではありません（状況3が示しているように）。したがって、疑わしい場合は、これをしないでください。
Situation 3: The user copies a message out of a mailbox and then deletes the mailbox.
状況3：ユーザーはメールボックスからメッセージをコピーして、メールボックスを削除します。
C: A001 SELECT Old-Mail
S: ...
C: A002 UID COPY 111 ToDo
S: A002 OK [COPYUID 1022843345 111 94] Copy completed
...
C: A015 CLOSE
S: A015 OK Completed
C: A016 DELETE Old-Mail
S: A016 OK Mailbox deletion completed successfully
If the client performs DELETE (tag A016) first and COPY (tag A002) second, then the COPY fails. Also, the message that the user so carefully copied into another mailbox has been lost.
クライアントが最初に削除（タグA016）を実行し、コピー（タグA002）秒を実行すると、コピーが失敗します。また、ユーザーが非常に慎重に別のメールボックスにコピーしたというメッセージは失われました。
Error recovery during synchronization is one of the trickiest parts to get right. Below, we will discuss certain error conditions and suggest possible choices for handling them.
同期中のエラー回復は、正しくなるのに最も難しい部分の1つです。以下に、特定のエラー条件について説明し、それらを処理するための可能な選択肢を提案します。
1) Lost connection to the server.
1) サーバーへの接続が失われました。
The client MUST remember the current position in the playback (replay) log and replay it starting from the interrupted operation (the last command issued by the client, but not acknowledged by the server) the next time it successfully connects to the same server. If the connection was lost while executing a non-idempotent IMAP command (see the definition in Section 1), then when the client is reconnected, it MUST make sure that the interrupted command was indeed not executed. If it wasn't executed, the client must restart playback from the interrupted command, otherwise from the following command.
クライアントは、再生（リプレイ）ログの現在の位置を覚えていて、中断された操作（クライアントが発行した最後のコマンドが、サーバーによって認められない）から開始することを再生する必要があります。次回は同じサーバーに正常に接続します。非公開のIMAPコマンドの実行中に接続が失われた場合（セクション1の定義を参照）、クライアントが再接続されている場合、中断されたコマンドが実際に実行されていないことを確認する必要があります。実行されていない場合、クライアントは中断されたコマンドから再生を再起動する必要があります。そうでなければ、次のコマンドからです。
Upon reconnect, care must be taken in order to properly reapply logical operations that are represented by multiple IMAP commands, e.g., UID EXPUNGE emulation when UID EXPUNGE is not supported by the server (see Section 4.2.4).
再接続すると、複数のIMAPコマンドで表される論理操作を適切に再度再申請するために、UID消去がサーバーによってサポートされていない場合のUID消去エミュレーションを適切に再適用するために注意を払う必要があります（セクション4.2.4を参照）。
Once the client detects that the connection to the server was lost, it MUST stop replaying its log. There are existing disconnected clients that, to the great annoyance of users, pop up an error dialog for each and every playback operation that fails.
クライアントがサーバーへの接続が失われたことを検出したら、ログの再生を停止する必要があります。ユーザーの非常に迷惑なことに、失敗するすべての再生操作のエラーダイアログをポップアップする既存の切断されたクライアントがあります。
2) Copying/appending messages to a mailbox that doesn't exist. (The server advertises this condition by sending the TRYCREATE response code in the tagged NO response to the APPEND or COPY command.) The user should be advised about the situation and be given one of the following choices:
2) 存在しないメールボックスにメッセージをコピー/アプリすること。（サーバーは、タグ付けされたAppendまたはCopyコマンドへのタグ付きNO応答でTryCreate応答コードを送信することにより、この条件を宣伝します。）ユーザーは、状況についてアドバイスされ、次の選択肢のいずれかを与えられる必要があります。
a) Try to recreate a mailbox. b) Copy/upload messages to another mailbox. c) Skip copy/upload. d) Abort replay.
a) メールボックスを再作成してみてください。b）メッセージを別のメールボックスにコピー/アップロードします。c）コピー/アップロードをスキップします。d）リプレイを中止します。
3) Copying messages from a mailbox that doesn't exist, or renaming or getting/changing ACLs [ACL] on a mailbox that doesn't exist:
3) 存在しないメールボックスからのメッセージのコピー、または存在しないメールボックスでACLS [ACL]の名前を変更または取得/変更：
a) Skip operation. b) Abort replay.
a) 操作をスキップします。b）リプレイを中止します。
4) Deleting mailboxes or deleting/expunging messages that no longer exist.
4) メールボックスを削除するか、存在しなくなったメッセージの削除/消費メッセージ。
This is actually is not an error and should be ignored by the client.
これは実際にはエラーではなく、クライアントが無視する必要があります。
5) Performing operations on messages that no longer exist.
5) もはや存在しないメッセージで操作を実行します。
a) Skip operation. b) Abort replay.
a) 操作をスキップします。b）リプレイを中止します。
In the case of changing flags on an expunged message, the client should silently ignore the error.
抹消されたメッセージでフラグを変更する場合、クライアントは静かにエラーを無視する必要があります。
Note 1: Several synchronization operations map to multiple IMAP commands (for example, "move" described in 4.2.2). The client must guarantee atomicity of each such multistep operation. For example, when performing a "move" between two mailboxes on the same server, if the server is unable to copy messages, the client MUST NOT attempt to set the \Deleted flag on the messages being copied, let alone expunge them. However, the client MAY consider that move operation to have succeeded even if the server was unable to set the \Deleted flag on copied messages.
注1：複数のIMAPコマンドにいくつかの同期操作マップ（たとえば、4.2.2に記載されている「移動」）。クライアントは、このようなマルチステップ操作のそれぞれの原子性を保証する必要があります。たとえば、同じサーバー上の2つのメールボックス間で「移動」を実行する場合、サーバーがメッセージをコピーできない場合、クライアントはコピーされているメッセージの\削除フラグを設定しようとしてはなりません。ただし、クライアントは、サーバーがコピーされたメッセージに\削除フラグを設定できなかった場合でも、その移動操作が成功したと考える場合があります。
Note 2: Many synchronization operations have data dependencies. A failed operation must cause all dependent operations to fail as well. The client should check this and MUST NOT try to perform all dependent operations blindly (unless the user corrected the original problem). For example, a message may be scheduled to be appended to a mailbox on the server and later on the appended message may be copied to another mailbox. If the APPEND operation fails, the client must not attempt to COPY the failed message later on. (See also Section 5, Situation 3).
注2：多くの同期操作にはデータ依存関係があります。操作に失敗すると、すべての依存操作も失敗する必要があります。クライアントはこれをチェックする必要があり、すべての依存操作を盲目的に実行しようとしてはなりません（ユーザーが元の問題を修正しない限り）。たとえば、メッセージはサーバーのメールボックスに追加されるようにスケジュールされ、後で追加されたメッセージが別のメールボックスにコピーされる場合があります。追加の操作が失敗した場合、クライアントは後で失敗したメッセージをコピーしようとしてはなりません。（セクション5、状況3も参照）。
Below, some quality of implementation issues are listed for disconnected clients. They will help to write a disconnected client that works correctly, performs synchronization as quickly as possible (and thus can make the user happier as well as save her some money), and minimizes the server load:
以下では、切断されたクライアント向けにいくつかの品質の実装問題がリストされています。彼らは、正しく動作し、できるだけ早く同期を実行する（したがって、ユーザーをより幸せにし、いくらかのお金を節約することができる）、サーバーの負荷を最小化する切断されたクライアントを書くのに役立ちます。
1) Don't lose information.
1) 情報を失わないでください。
No matter how smart your client is in other areas, if it loses information, users will get very upset.
クライアントが他の分野でどれほど賢くても、情報を失った場合、ユーザーは非常に動揺します。
2) Don't do work unless explicitly asked. Be flexible. Ask all questions BEFORE starting synchronization, if possible.
2) 明示的に尋ねない限り、仕事をしないでください。柔軟です。可能であれば、同期を開始する前にすべての質問をしてください。
3) Minimize traffic.
3) トラフィックを最小限に抑えます。
The client MUST NOT issue a command if the client already received the required information from the server.
クライアントがサーバーから必要な情報をすでに受け取った場合、クライアントはコマンドを発行してはなりません。
The client MUST make use of UIDPLUS extension if it is supported by the server.
クライアントは、サーバーによってサポートされている場合は、uidplus拡張機能を使用する必要があります。
See also optimization 1 in Section 5.3.
セクション5.3の最適化1も参照してください。
4) Minimize the number of round-trips.
4) ラウンドトリップの数を最小限に抑えます。
Round-trips kill performance, especially on links with high latency. Sections 4.2.2.5 and 5.2 give some advice on how to minimize the number of round-trips.
ラウンドトリップは、特に高レイテンシのリンクでパフォーマンスを殺します。セクション4.2.2.5および5.2は、ラウンドトリップの数を最小限に抑える方法についてのアドバイスを提供します。
See also optimization 1 in Section 5.3.
セクション5.3の最適化1も参照してください。
Some useful optimizations are described in this section. A disconnected client that supports the recommendations listed below will give the user a more pleasant experience.
このセクションでは、いくつかの有用な最適化について説明します。以下にリストされている推奨事項をサポートする切断されたクライアントは、ユーザーがより快適なエクスペリエンスを提供します。
1) The initial OK or PREAUTH responses may contain the CAPABILITY response code as described in Section 7.1 of [IMAP4]. This response code gives the same information as returned by the CAPABILITY command*. A disconnected client that pays attention to this response code can avoid sending CAPABILITY command and will save a round-trip.
1) [IMAP4]のセクション7.1で説明されているように、最初のOKまたはPreauth応答には、機能応答コードが含まれている場合があります。この応答コードは、Capabilityコマンド*によって返されたのと同じ情報を提供します。この応答コードに注意を払う切断されたクライアントは、機能コマンドの送信を避け、往復を保存します。
* Note: Some servers report in the CAPABILITY response code extensions that are only relevant in unauthenticated state or in all states. Such servers usually send another CAPABILITY response code upon successful authentication using LOGIN or AUTHENTICATE command (that negotiates no security layer; see Section 6.2.2 of [IMAP4]). The CAPABILITY response code sent upon successful LOGIN/AUTHENTICATE might be different from the CAPABILITY response code in the initial OK response, as extensions only relevant for unauthenticated state will not be advertised, and some additional extensions available only in authenticated and/or selected state will be.
* 注：一部のサーバーは、無許可の状態またはすべての状態でのみ関連する機能応答コード拡張機能に報告しています。このようなサーバーは通常、ログインまたは認証コマンドを使用して認証を成功させたときに別の機能応答コードを送信します（セキュリティレイヤーを交渉しません。[IMAP4]のセクション6.2.2を参照）。成功したログイン/認証時に送信された機能応答コードは、認定されていない状態に関連する拡張機能は宣伝されず、認証された状態および/または選択された状態でのみ利用可能な追加の拡張機能が宣伝されないため、最初のOK応答の機能応答コードとは異なる場合があります。なれ。
Example 9:
例9：
S: * OK [CAPABILITY IMAP4REV1 LOGIN-REFERRALS STARTTLS
AUTH=DIGEST-MD5 AUTH=SRP] imap.example.com ready
C: 2 authenticate DIGEST-MD5
S: 2 OK [CAPABILITY IMAP4REV1 IDLE NAMESPACE MAILBOX-REFERRALS SCAN
SORT THREAD=REFERENCES THREAD=ORDEREDSUBJECT MULTIAPPEND]
User authenticated (no layer)
2) An advanced disconnected client may choose to optimize its replay log. For example, there might be some operations that are redundant (the list is not complete):
2) 高度な切断されたクライアントは、リプレイログを最適化することを選択できます。たとえば、冗長な操作がある場合があります（リストは完全ではありません）：
a) an EXPUNGE followed by another EXPUNGE or CLOSE; b) changing flags (other than the \Deleted flag) on a message that gets immediately expunged; c) opening and closing the same mailbox.
a) 抹消に続いて、別の抹消または閉鎖が続きます。b）すぐに削除されるメッセージにフラグ（\削除されたフラグ以外）を変更します。c）同じメールボックスを開閉します。
When optimizing, be careful about data dependencies between commands. For example, if the client is wishing to optimize (see case b, above)
最適化する場合は、コマンド間のデータ依存関係に注意してください。たとえば、クライアントが最適化を希望している場合（ケースB、上記を参照）
tag1 UID STORE <uid1> +FLAGS (\Deleted)
...
tag2 UID STORE <uid1> +FLAGS (\Flagged)
...
tag3 UID COPY <uid1> "Backup"
...
tag4 UID EXPUNGE <uid1>
it can't remove the second UID STORE command because the message is being copied before it gets expunged.
メッセージが削除される前にコピーされているため、2番目のUIDストアコマンドを削除することはできません。
In general, it might be a good idea to keep mailboxes open during synchronization (see case c above), if possible. This can be more easily achieved in conjunction with optimization 3 described below.
一般に、可能であれば、同期中にメールボックスを開いたままにすることをお勧めします（上記のケースCを参照）。これは、以下で説明する最適化3と組み合わせてより簡単に実現できます。
3) Perform some synchronization steps in parallel, if possible.
3) 可能であれば、いくつかの同期ステップを並行して実行します。
Several synchronization steps don't depend on each other and thus can be performed in parallel. Because the server machine is usually more powerful than the client machine and can perform some operations in parallel, this may speed up the total time of synchronization.
いくつかの同期ステップは互いに依存せず、したがって並行して実行できます。サーバーマシンは通常、クライアントマシンよりも強力であり、並行して操作を実行できるため、同期の合計時間が高速化される可能性があります。
In order to achieve such parallelization, the client will have to open more than one connection to the same server. Client writers should not forget about non-trivial cost associated with establishing a TCP connection and performing an authentication. The disconnected client MUST NOT use one connection per mailbox. In most cases, it is sufficient to have two connections. The disconnected client SHOULD avoid selecting the same mailbox in more than one connection; see Section 3.1.1 of [RFC2683] for more details.
このような並列化を実現するには、クライアントは同じサーバーへの複数の接続を開く必要があります。クライアントライターは、TCP接続の確立と認証の実行に関連する非自明のコストを忘れてはなりません。切断されたクライアントは、メールボックスごとに1つの接続を使用してはなりません。ほとんどの場合、2つの接続を持つだけで十分です。切断されたクライアントは、複数の接続で同じメールボックスを選択しないようにする必要があります。詳細については、[RFC2683]のセクション3.1.1を参照してください。
Any mailbox synchronization MUST start with checking the UIDVALIDITY as described in Section 4.1 of this document. The client MAY use STATUS command to check UID Validity of a non-selected mailbox. This is preferable to opening many connections to the same server to perform synchronization of multiple mailboxes simultaneously. As described in Section 5.3.10 of [IMAP4], this SHOULD NOT be used on the selected mailbox.
メールボックスの同期は、このドキュメントのセクション4.1で説明されているように、uidalivityをチェックすることから始める必要があります。クライアントは、Statusコマンドを使用して、選択されていないメールボックスのUID有効性を確認できます。これは、複数のメールボックスの同期を同時に実行するために、同じサーバーへの多くの接続を開くよりも望ましいです。[IMAP4]のセクション5.3.10で説明されているように、これは選択したメールボックスで使用しないでください。
The following extensions can save traffic and/or the number of round-trips:
次の拡張により、トラフィックやラウンドトリップの数を節約できます。
1) The use of [UIDPLUS] is discussed in Sections 4.1, 4.2.1, 4.2.2.1 and 4.2.4.
1) [uidplus]の使用については、セクション4.1、4.2.1、4.2.2.1、および4.2.4で説明します。
2) The use of the MULTIAPPEND and LITERAL+ extensions for uploading messages is discussed in Section 4.2.2.5.
2) メッセージをアップロードするためのマルチアドペンドおよびリテラル拡張機能の使用については、セクション4.2.2.5で説明します。
3) Use the CONDSTORE extension (see Section 6.1) for quick flag resynchronization.
3) クイックフラグの再同期を得るには、Condstore拡張機能（セクション6.1を参照）を使用します。
An advanced disconnected mail client should use the [CONDSTORE] extension when it is supported by the server. The client must cache the value from HIGHESTMODSEQ OK response code received on mailbox opening and update it whenever the server sends MODSEQ FETCH data items.
高度な切断されたメールクライアントは、サーバーによってサポートされている場合、[condstore]拡張機能を使用する必要があります。クライアントは、ModSeq Fetch Dataアイテムを送信するたびに、Mailboxの開きで受信したHightModseq OK応答コードから値をキャッシュする必要があります。
If the client receives NOMODSEQ OK untagged response instead of HIGHESTMODSEQ, it MUST remove the last known HIGHESTMODSEQ value from its cache and follow the more general instructions in Section 3.
クライアントがhighestmodseqの代わりにnomodseq ok untagged応答を受信した場合、キャッシュから最後に既知のhightimodseq値を削除し、セクション3のより一般的な指示に従う必要があります。
When the client opens the mailbox for synchronization, it first compares UIDVALIDITY as described in step d-1 in Section 3. If the cached UIDVALIDITY value matches the one returned by the server, the client MUST compare the cached value of HIGHESTMODSEQ with the one returned by the server. If the cached HIGHESTMODSEQ value also matches the one returned by the server, then the client MUST NOT fetch flags for cached messages, as they hasn't changed. If the value on the server is higher than the cached one, the client MAY use "SEARCH MODSEQ <cached-value>" to find all messages with flags changed since the last time the client was online and had the mailbox opened. Alternatively, the client MAY use "FETCH 1:* (FLAGS) (CHANGEDSINCE <cached-value>)". The latter operation combines searching for changed messages and fetching new information.
クライアントが同期のためにメールボックスを開くと、セクション3のステップd-1で説明されているようにuidalidity性を比較します。サーバーによって。キャッシュされたhightiestmodseq値もサーバーによって返される値と一致する場合、クライアントは変更されていないため、キャッシュされたメッセージのフラグを取得してはなりません。サーバー上の値がキャッシュされた値よりも高い場合、クライアントは「ModSeq <Cached-Value>を検索」を使用して、クライアントがオンラインで最後にオンラインでメールボックスを開いたときからフラグが変更されたすべてのメッセージを見つけることができます。あるいは、クライアントは「Fetch 1：*（flags）（changed <cached-value>）」を使用する場合があります。後者の操作は、変更されたメッセージの検索と新しい情報の取得を組み合わせています。
In all cases, the client still needs to fetch information about new messages (if requested by the user) as well as discover which messages have been expunged.
すべての場合において、クライアントは引き続き新しいメッセージに関する情報を取得し（ユーザーが要求した場合）、どのメッセージが削除されたかを発見する必要があります。
Step d ("Server-to-client synchronization") in Section 4 in the presence of the CONDSTORE extension is amended as follows:
ステップD（ "サーバー間同期"）Condstore拡張の存在下のセクション4の存在下のセクション4の次のように修正されます。
d) "Server-to-client synchronization" - For each mailbox that requires synchronization, do the following:
d) 「サーバー間同期」 - 同期を必要とする各メールボックスについて、以下を実行します。
1a) Check the mailbox UIDVALIDITY (see section 4.1 for more details) with SELECT/EXAMINE/STATUS.
1a）select/exemine/statusを使用して、メールボックスuidalidity（詳細についてはセクション4.1を参照）を確認します。
If the UIDVALIDITY value returned by the server differs, the client MUST
サーバーによって返されたuidialidity値が異なる場合、クライアントは
* empty the local cache of that mailbox; * "forget" the cached HIGHESTMODSEQ value for the mailbox; * remove any pending "actions" that refer to UIDs in that mailbox (note that this doesn't affect actions performed on client-generated fake UIDs; see Section 5); and * skip steps 1b and 2-II;
* そのメールボックスのローカルキャッシュを空にします。*メールボックスのキャッシュされたHightmodSeq値を「忘れて」。*そのメールボックス内のUIDを参照する保留中の「アクション」を削除します（これは、クライアントで生成された偽のUIDで実行されるアクションに影響しないことに注意してください。セクション5を参照）。および *ステップ1Bおよび2-IIをスキップします。
1b) Check the mailbox HIGHESTMODSEQ. If the cached value is the same as the one returned by the server, skip fetching message flags on step 2-II, i.e., the client only has to find out which messages got expunged.
1b）メールボックスhighestmodseqを確認します。キャッシュされた値がサーバーによって返された値と同じ場合、ステップ2-IIでメッセージフラグの取得をスキップします。つまり、クライアントはどのメッセージが削除されたかを見つけるだけです。
2) Fetch the current "descriptors".
2) 現在の「記述子」を取得します。
I) Discover new messages.
i）新しいメッセージを発見します。
II) Discover changes to old messages and flags for new messages using "FETCH 1:* (FLAGS) (CHANGEDSINCE <cached-value>)" or "SEARCH MODSEQ <cached-value>".
ii）「Fetch 1：*（flags）（changed <cached-value>）」または「search modseq <cached-value>」を使用して、新しいメッセージの古いメッセージとフラグの変更を発見します。
Discover expunged messages; for example, using "UID SEARCH 1:<lastseenuid>". (All messages not returned in this command are expunged.)
削除されたメッセージを発見します。たとえば、「uid検索1：<lastseenuid>」を使用します。（このコマンドで返されないすべてのメッセージは削除されます。）
3) Fetch the bodies of any "interesting" messages that the client doesn't already have.
3) クライアントがまだ持っていない「興味深い」メッセージのボディを取得します。
Example 10:
例10：
The UIDVALIDITY value is the same, but the HIGHESTMODSEQ value has changed on the server while the client was offline.
uidalidityの値は同じですが、クライアントがオフラインである間に、サーバー上で最大のモッズフ値が変更されました。
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 201] Predicted next UID
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
S: * OK [HIGHESTMODSEQ 20010715194045007]
S: A142 OK [READ-WRITE] SELECT completed
After that, either:
その後、どちらも：
C: A143 UID FETCH 1:* (FLAGS) (CHANGEDSINCE 20010715194032001)
S: * 2 FETCH (UID 6 MODSEQ (20010715205008000) FLAGS (\Deleted))
S: * 5 FETCH (UID 9 MODSEQ (20010715195517000) FLAGS ($NoJunk
$AutoJunk $MDNSent))
...
S: A143 OK FETCH completed
or:
または：
C: A143 UID SEARCH MODSEQ 20010715194032001 UID 1:20
S: * SEARCH 6 9 11 12 18 19 20 23 (MODSEQ 20010917162500)
S: A143 OK Search complete
C: A144 UID SEARCH 1:20
S: * SEARCH 6 9 ...
S: A144 OK FETCH completed
It is believed that this document does not raise any new security concerns that are not already present in the base [IMAP4] protocol, and these issues are discussed in [IMAP4]. Additional security considerations may be found in different extensions mentioned in this document; in particular, in [UIDPLUS], [LITERAL+], [CONDSTORE], [MULTIAPPEND], and [UNSELECT].
この文書は、ベース[IMAP4]プロトコルにまだ存在していない新しいセキュリティ上の懸念を提起しておらず、これらの問題について[IMAP4]で説明していると考えられています。このドキュメントに記載されているさまざまな拡張機能に、追加のセキュリティに関する考慮事項があります。特に、[uidplus]、[リテラル]、[condstore]、[multiappend]、および[unselect]で。
Implementers are also reminded about the importance of thorough testing.
実装者は、徹底的なテストの重要性についても思い出させます。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[IMAP4] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[IMAP4] Crispin、M。、「インターネットメッセージアクセスプロトコル -バージョン4REV1」、RFC 3501、2003年3月。
[UIDPLUS] Crispin, M., "Internet Message Access Protocol (IMAP) - UIDPLUS extension", RFC 4315, December 2005.
[uidplus] Crispin、M。、「インターネットメッセージアクセスプロトコル（IMAP） - uidplus拡張機能」、RFC 4315、2005年12月。
[LITERAL+] Myers, J., "IMAP4 non-synchronizing literals", RFC 2088, January 1997.
[リテラル]マイヤーズ、J。、「IMAP4非同期リテラル」、RFC 2088、1997年1月。
[CONDSTORE] Melnikov, A. and S. Hole, "IMAP Extension for Conditional STORE Operation or Quick Flag Changes Resynchronization", RFC 4551, June 2006.
[Condstore] Melnikov、A。and S. Hole、「条件付き店舗運用またはクイックフラグ変更再同期のためのIMAP拡張」、RFC 4551、2006年6月。
[MULTIAPPEND] Crispin, M., "Internet Message Access Protocol (IMAP) - MULTIAPPEND Extension", RFC 3502, March 2003.
[MultiaPend] Crispin、M。、「インターネットメッセージアクセスプロトコル（IMAP） - マルチアドペンド拡張機能」、RFC 3502、2003年3月。
[UNSELECT] Melnikov, A., "Internet Message Access Protocol (IMAP) UNSELECT command", RFC 3691, February 2004.
[UNSELECT] Melnikov、A。、「インターネットメッセージアクセスプロトコル（IMAP）UNSELECTコマンド」、RFC 3691、2004年2月。
[RFC2683] Leiba, B., "IMAP4 Implementation Recommendations", RFC 2683, September 1999.
[RFC2683] Leiba、B。、「IMAP4実装の推奨」、RFC 2683、1999年9月。
[ACL] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", RFC 4314, December 2005.
[ACL] Melnikov、A。、「IMAP4アクセス制御リスト（ACL）拡張機能」、RFC 4314、2005年12月。
[IMAP-MODEL] Crispin, M., "Distributed Electronic Mail Models in IMAP4", RFC 1733, December 1994.
[IMAP-Model] Crispin、M。、「IMAP4の分散電子メールモデル」、RFC 1733、1994年12月。
This document is based on version 01 of the text written by Rob Austein in November 1994.
このドキュメントは、1994年11月にRob Austeinによって書かれたテキストのバージョン01に基づいています。
The editor appreciates comments posted by Mark Crispin to the IMAP mailing list and the comments/corrections/ideas received from Grant Baillie, Cyrus Daboo, John G. Myers, Chris Newman, and Timo Sirainen.
編集者は、Mark CrispinがIMAPメーリングリストに投稿したコメントと、Grant Baillie、Cyrus Daboo、John G. Myers、Chris Newman、Timo Sirainenから受け取ったコメント/修正/アイデアを高く評価しています。
The editor would also like to thank the developers of Netscape Messenger and Mozilla mail clients for providing examples of disconnected mail clients that served as a base for many recommendations in this document.
また、編集者は、Netscape MessengerとMozilla Mailクライアントの開発者に、このドキュメントの多くの推奨事項のベースとして機能した切断されたメールクライアントの例を提供してくれたことにも感謝します。
Editor's Address
編集者のアドレス
Alexey Melnikov Isode Limited 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX United Kingdom
アレクセイメルニコフアイソードリミテッド5キャッスルヴィレッジ36ステーションロードハンプトン、ミドルセックスTW12 2BXイギリス
Phone: +44 77 53759732
EMail: alexey.melnikov@isode.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。