[要約] 要約：RFC 2683は、IMAP4プロトコルの実装に関する推奨事項を提供しています。 目的：このRFCの目的は、IMAP4クライアントとサーバーの間の効率的な通信を確保し、信頼性とセキュリティを向上させるためのガイドラインを提供することです。
Network Working Group B. Leiba
Request for Comments: 2683 IBM T.J. Watson Research Center
Category: Informational September 1999
IMAP4 Implementation Recommendations
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 (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
The IMAP4 specification [RFC-2060] describes a rich protocol for use in building clients and servers for storage, retrieval, and manipulation of electronic mail. Because the protocol is so rich and has so many implementation choices, there are often trade-offs that must be made and issues that must be considered when designing such clients and servers. This document attempts to outline these issues and to make recommendations in order to make the end products as interoperable as possible.
IMAP4仕様[RFC-2060]は、電子メールの保存、検索、および操作のためのクライアントとサーバーを構築する際に使用するための豊富なプロトコルを記述しています。プロトコルはとても豊富で、非常に多くの実装の選択肢を持っているので、そのようなクライアントとサーバーを設計する際に考慮されなければならないなされなければならないトレードオフと問題がしばしばあります。この文書では、これらの問題の概要を説明すると、可能な限り相互運用可能として最終製品を作るための推奨事項を作成しようとします。
In examples, "C:" indicates lines sent by a client that is connected to a server. "S:" indicates lines sent by the server to the client.
実施例では、「C：」はサーバに接続されているクライアントから送信されたラインを示します。 「S：」はサーバからクライアントに送られた行を示します。
The words "must", "must not", "should", "should not", and "may" are used with specific meaning in this document; since their meaning is somewhat different from that specified in RFC 2119, we do not put them in all caps here. Their meaning is as follows:
言葉「MUST」、「MUST NOT」、「SHOULD」、「すべきではない」と、この文書の特定の意味で使用されている「こと」。その意味は、RFC 2119で指定されたものとは若干異なるため、ここではすべて大文字に入れないでください。次のようにそれぞれの意味は以下のとおりです。
must -- This word means that the action described is necessary to ensure interoperability. The recommendation should not be ignored. must not -- This phrase means that the action described will be almost certain to hurt interoperability. The recommendation should not be ignored.
なければならない - この言葉は説明したアクションは、相互運用性を確保する必要があることを意味しています。勧告は無視すべきではありません。いけません - この句は、記述された動作は、相互運用性を傷つけることはほぼ一定であることを意味します。勧告は無視すべきではありません。
should -- This word means that the action described is strongly recommended and will enhance interoperability or usability. The recommendation should not be ignored without careful consideration. should not -- This phrase means that the action described is strongly recommended against, and might hurt interoperability or usability. The recommendation should not be ignored without careful consideration. may -- This word means that the action described is an acceptable implementation choice. No specific recommendation is implied; this word is used to point out a choice that might not be obvious, or to let implementors know what choices have been made by existing implementations.
必要があります - この言葉は説明したアクションが強く推奨されていることを意味し、相互運用性や使い勝手を向上させます。勧告は慎重に考慮せず、無視すべきではありません。すべきではない - この句は、記述された動作を強くに対して推奨され、相互運用性や使い勝手を傷つける可能性があることを意味します。勧告は慎重に考慮せず、無視すべきではありません。かもしれない - この言葉は説明したアクションが許容実装の選択であることを意味しています。具体的な勧告が暗示されていません。この言葉は明らかではないかもしれない、または実装者は既存の実装によって行われているものを選択知っているように選択肢を指摘するために使用されます。
This section describes the issues related to access to servers and server resources. Concerns here include data sharing and maintenance of client/server connections.
このセクションでは、サーバーおよびサーバーのリソースにアクセスするために、関連する問題について説明します。ここでの懸念は、クライアント/サーバー接続のデータ共有とメンテナンスが含まれます。
One strong point of IMAP4 is that, unlike POP3, it allows for multiple simultaneous access to a single mailbox. A user can, thus, read mail from a client at home while the client in the office is still connected; or the help desk staff can all work out of the same inbox, all seeing the same pool of questions. An important point about this capability, though is that NO SERVER IS GUARANTEED TO SUPPORT THIS. If you are selecting an IMAP server and this facility is important to you, be sure that the server you choose to install, in the configuration you choose to use, supports it.
IMAP4の一つの強力な点は、POP3とは異なり、それは単一のメールボックスへの複数の同時アクセスを可能にし、ということです。オフィス内のクライアントがまだ接続されている間、ユーザーは、このように、自宅でクライアントからのメールを読むことができます。またはヘルプデスクのスタッフは、すべてのすべての質問の同じプールを見て、同じ受信トレイの外に動作することができます。この機能についての重要な点は、しかしNOサーバがこれをサポートするために保証されませんということです。あなたはIMAPサーバと、この機能を選択している場合に重要であり、あなたが選択したサーバーをインストールすることを確認してください、あなたが使用することを選択した構成で、それをサポートしています。
If you are designing a client, you must not assume that you can access the same mailbox more than once at a time. That means
あなたはクライアントを設計している場合、あなたは一度に何度も同じメールボックスの詳細にアクセスできることを仮定してはいけません。ことを意味します
1. you must handle gracefully the failure of a SELECT command if the server refuses the second SELECT, 2. you must handle reasonably the severing of your connection (see "Severed Connections", below) if the server chooses to allow the second SELECT by forcing the first off, 3. you must avoid making multiple connections to the same mailbox in your own client (for load balancing or other such reasons), and 4. you must avoid using the STATUS command on a mailbox that you have selected (with some server implementations the STATUS command has the same problems with multiple access as do the SELECT and
サーバはあなたが合理的にあなたの接続の切断を処理しなければならない2番目のSELECT、2を拒否した場合、サーバは秒で選択することを可能することを選択した場合1.あなたは（以下、「切断された接続」を参照）優雅にSELECTコマンドの失敗を処理しなければなりませんあなたは（負荷分散やその他などの理由で）独自のクライアントで同じメールボックスに複数の接続を避ける必要があります最初のオフ、3を強制的に、そして4.あなたが選択したメールボックスのSTATUSコマンドを使用して避けなければならない（とSELECTを行うようSTATUSコマンドは、複数のアクセスと同じ問題を抱えているいくつかのサーバーの実装と
EXAMINE commands).
）コマンドを調べます。
A further note about STATUS: The STATUS command is sometimes used to check a non-selected mailbox for new mail. This mechanism must not be used to check for new mail in the selected mailbox; section 5.2 of [RFC-2060] specifically forbids this in its last paragraph. Further, since STATUS takes a mailbox name it is an independent operation, not operating on the selected mailbox. Because of this, the information it returns is not necessarily in synchronization with the selected mailbox state.
STATUSについての更なる注意：STATUSコマンドは時々新しいメールの非選択されたメールボックスをチェックするために使用されます。このメカニズムは、選択したメールボックスに新しいメールをチェックするために使用することはできません。 [RFC-2060]のセクション5.2は、特にその最後の段落でこれを禁止します。 STATUSは、メールボックス名を取りますので、それは選択されたメールボックス上で動作していない、独立した動作です。このため、それが返した情報は、選択されたメールボックスの状態と同期して必ずしもありません。
The client/server connection may be severed for one of three reasons: the client severs the connection, the server severs the connection, or the connection is severed by outside forces beyond the control of the client and the server (a telephone line drops, for example). Clients and servers must both deal with these situations.
クライアント/サーバー接続は、3つのいずれかの理由で切断されることがあります。クライアントが接続を切断し、サーバーは接続を切断し、または接続は、クライアントの管理とサーバ（電話線が低下し、用を超えて外部の力によって切断されます例）。クライアントとサーバの両方でこれらの状況に対処しなければなりません。
When the client wants to sever a connection, it's usually because it has finished the work it needed to do on that connection. The client should send a LOGOUT command, wait for the tagged response, and then close the socket. But note that, while this is what's intended in the protocol design, there isn't universal agreement here. Some contend that sending the LOGOUT and waiting for the two responses (untagged BYE and tagged OK) is wasteful and unnecessary, and that the client can simply close the socket. The server should interpret the closed socket as a log out by the client. The counterargument is that it's useful from the standpoint of cleanup, problem determination, and the like, to have an explicit client log out, because otherwise there is no way for the server to tell the difference between "closed socket because of log out" and "closed socket because communication was disrupted". If there is a client/server interaction problem, a client which routinely terminates a session by breaking the connection without a LOGOUT will make it much more difficult to determine the problem.
クライアントが接続を切断しようとするとき、それはその接続上で行うために必要な作業を終えたので、それが通常です。クライアントは、LOGOUTコマンドを送信し、タグ付きの応答を待機した後、ソケットを閉じる必要があります。しかし、これはプロトコル設計で意図しているものである一方で、普遍的な合意がここに存在しない、ということに注意してください。いくつかはLOGOUTを送信し、2つの応答を待っている（タグなしBYEおよびOKをタグ付けすることは）無駄と不要であること、そしてクライアントは単純にソケットを閉じることができると主張しています。サーバーは、クライアントによってログとして閉じたソケットを解釈する必要があります。反論は、それ以外のサーバは、「閉じたのでアウトログのソケット」との違いを教えて方法はありませんので、明示的なクライアントがログアウト持って、クリーンアップ、問題の決意の観点から便利だ、などということです「通信が途絶したため、ソケットを閉じて」。クライアント/サーバの対話に問題がある場合は、日常LOGOUTなしで接続を切断してセッションを終了し、クライアントはそれをはるかに困難な問題を決定することになります。
Because of this disagreement, server designers must be aware that some clients might close the socket without sending a LOGOUT. In any case, whether or not a LOGOUT was sent, the server should not implicitly expunge any messages from the selected mailbox. If a client wants the server to do so, it must send a CLOSE or EXPUNGE command explicitly.
このため不一致により、サーバーの設計者は、いくつかのクライアントがLOGOUTを送信せずにソケットを閉じる可能性があることを認識する必要があります。いずれの場合も、LOGOUTが送信されたかどうかにかかわらず、サーバが暗黙的に選択されたメールボックスからのメッセージを抹消べきではありません。クライアントは、サーバがそうすることを望んでいるなら、それはCLOSEを送信したり、明示的にコマンドをEXPUNGEしなければなりません。
When the server wants to sever a connection it's usually due to an inactivity timeout or is because a situation has arisen that has changed the state of the mail store in a way that the server can not communicate to the client. The server should send an untagged BYE response to the client and then close the socket. Sending an untagged BYE response before severing allows the server to send a human-readable explanation of the problem to the client, which the client may then log, display to the user, or both (see section 7.1.5 of [RFC-2060]).
サーバーが接続を切断しようとする場合には、通常、非アクティブタイムアウトが原因だかの状況は、サーバーがクライアントに通信できないような方法でメールストアの状態が変更されたことが生じているためです。サーバーは、クライアントへのタグなしBYE応答を送信して、ソケットを閉じる必要があります。切断前にタグ無しBYE応答を送信すると、サーバは、クライアントは、次に、ユーザに表示を記録、または両方（[RFC-2060]のセクション7.1.5を参照することができるクライアントに問題の人間可読な説明を送信することができ）。
Regarding inactivity timeouts, there is some controversy. Unlike POP, for which the design is for a client to connect, retrieve mail, and log out, IMAP's design encourages long-lived (and mostly inactive) client/server sessions. As the number of users grows, this can use up a lot of server resources, especially with clients that are designed to maintain sessions for mailboxes that the user has finished accessing. To alleviate this, a server may implement an inactivity timeout, unilaterally closing a session (after first sending an untagged BYE, as noted above). Some server operators have reported dramatic improvements in server performance after doing this. As specified in [RFC-2060], if such a timeout is done it must not be until at least 30 minutes of inactivity. The reason for this specification is to prevent clients from sending commands (such as NOOP) to the server at frequent intervals simply to avert a too-early timeout. If the client knows that the server may not time out the session for at least 30 minutes, then the client need not poll at intervals more frequent than, say, 25 minutes.
無活動タイムアウトに関しては、いくつかの論争があります。クライアントは、接続するメールを取得し、ログアウトするためにPOPとは異なり、そのために設計され、IMAPのデザインは、長寿命（および主に非アクティブ）のクライアント/サーバー・セッションを奨励しています。ユーザーの数が増えるにつれ、これは特に、ユーザがアクセスを終了したメールボックスのセッションを維持するように設計されているクライアントと、サーバリソースの多くを使用することができます。これを軽減するために、サーバは、（上述のように、最初のタグなしBYEを送信した後に）片側セッションを閉じ、非活動タイムアウトを実装することができます。一部のサーバー事業者はこれをやった後、サーバーのパフォーマンスの劇的な改善を報告しています。 [RFC-2060]で指定されたように、このようなタイムアウトが行われている場合、それは非アクティブの少なくとも30分までであってはなりません。この仕様のための理由は、あまりにも早タイムアウトを回避するために、頻繁な間隔でサーバに（例えばNOOPなど）のコマンドを送信してからクライアントを防ぐためです。クライアントは、サーバが少なくとも30分間のセッションをタイムアウトないかもしれないことを知っている場合、クライアントは25分、たとえば、より頻繁にポーリングする必要はありません。
IMAP4 has many features that allow for scalability, as mail stores become larger and more numerous. Large numbers of users, mailboxes, and messages, and very large messages require thought to handle efficiently. This document will not address the administrative issues involved in large numbers of users, but we will look at the other items.
IMAP4はメールストアが大きく、数が多くなると、スケーラビリティを可能に多くの機能を備えています。ユーザー、メールボックス、および多数のメッセージ、および非常に大きなメッセージを効率的に処理するために考えが必要です。この文書では、多数のユーザーに関係する管理上の問題に対処していないだろうが、我々は他の項目を見ていきます。
There are three situations when a client can make a request that will result in a very large response - too large for the client reasonably to deal with: there are a great many mailboxes available, there are a great many messages in the selected mailbox, or there is a very large message part. The danger here is that the end user will be stuck waiting while the server sends (and the client processes) an enormous response. In all of these cases there are things a client can do to reduce that danger.
利用できる非常に多くのメールボックスがあり、非常に多くのメッセージが選択したメールボックス内にある、またはクライアントのためにあまりにも大きな合理的に対処する - があり、クライアントが非常に大きな応答になります要求を行うことができる3つの状況があります非常に大きなメッセージ部分があります。ここで危険なのは、エンドユーザーは、サーバーが送信（およびクライアント・プロセス）しながら、巨大な応答を待って立ち往生するということです。これらのケースの全てにおいて、クライアントはその危険性を減らすためにできることがあります。
There is also the case where a client can flood a server, by sending an arbitratily long command. We'll discuss that issue, too, in this section.
クライアントがarbitratily長いコマンドを送信することにより、サーバーをあふれさせることができ場合もあります。私たちは、このセクションでは、あまりにも、その問題を説明します。
Some servers present Usenet newsgroups to IMAP users. Newsgroups, and other such hierarchical mailbox structures, can be very numerous but may have only a few entries at the top level of hierarchy. Also, some servers are built against mail stores that can, unbeknownst to the server, have circular hierarchies - that is, it's possible for "a/b/c/d" to resolve to the same file structure as "a", which would then mean that "a/b/c/d/b" is the same as "a/b", and the hierarchy will never end. The LIST response in this case will be unlimited.
IMAPユーザーに一部のサーバー現在のUsenetニュースグループ。ニュースグループ、および他のこのような階層のメールボックス構造は、非常に数多くのことができますが、階層の最上位レベルでほんの数のエントリを有することができます。また、いくつかのサーバは、サーバにすることができ、知られずメールストアに対して構築された円形の階層を持っている - つまり、それは「A」と同じファイル構造に解決するために、「A / B / C / D」は可能ですが、これだろうその後、 "A / B / C / D / B" は "A / B" と同じであることを意味し、階層が終わることは決してありません。この場合、LIST応答は無制限になります。
Clients that will have trouble with this are those that use
これで問題がありますクライアントが使用するものです
C: 001 LIST "" *
C：001 LIST "" *
to determine the mailbox list. Because of this, clients should not use an unqualified "*" that way in the LIST command. A safer approach is to list each level of hierarchy individually, allowing the user to traverse the tree one limb at a time, thus:
メールボックスのリストを決定します。このため、クライアントは、LISTコマンドで修飾されていない「*」そのように使用すべきではありません。より安全なアプローチは、このように、ユーザは一度に1ツリー肢を横断することができ、個々の階層の各レベルをリストすることです。
C: 001 LIST "" %
S: * LIST () "/" Banana
S: * LIST ...etc...
S: 001 OK done
and then
その後
C: 002 LIST "" Banana/%
S: * LIST () "/" Banana/Apple
S: * LIST ...etc...
S: 002 OK done
Using this technique the client's user interface can give the user full flexibility without choking on the voluminous reply to "LIST *".
この技術を使用して、クライアントのユーザーインターフェースは、「LISTの*」への膨大な回答をのどに詰まらせずに、ユーザーに完全な柔軟性を与えることができます。
Of course, it is still possible that the reply to
もちろん、それはまだ可能であることへの返信
C: 005 LIST "" alt.fan.celebrity.%
C：005 LIST "" alt.fan.celebrity％。
may be thousands of entries long, and there is, unfortunately, nothing the client can do to protect itself from that. This has not yet been a notable problem.
長いエントリの何千も、クライアントがそのから自分自身を守るためにできることは何も、残念ながら、存在しないかもしれません。これはまだ顕著な問題ではなかったです。
Servers that may export circular hierarchies (any server that directly presents a UNIX file system, for instance) should limit the hierarchy depth to prevent unlimited LIST responses. A suggested depth limit is 20 hierarchy levels.
円形の階層（直接例えば、UNIXのファイルシステムを提供する任意のサーバ）をエクスポートするサーバーは、無制限のLIST応答を防ぐために、階層の深さを制限する必要があります。提案深さ限界は20の階層レベルです。
When a client selects a mailbox, it is given a count, in the untagged EXISTS response, of the messages in the mailbox. This number can be very large. In such a case it might be unwise to use
クライアントがメールボックスを選択すると、それはカウントが与えられ、タグなしでメールボックス内のメッセージの応答を、存在しています。この数は非常に大きくなることができます。そのような場合には、それを使用するのは賢明であるかもしれません
C: 004 FETCH 1:* ALL
C：004はFETCH 1：* ALL
to populate the user's view of the mailbox. One good method to avoid problems with this is to batch the requests, thus:
メールボックスのユーザーのビューを移入します。これで問題を回避するための一つの良い方法は、このように、バッチに要求しています。
C: 004 FETCH 1:50 ALL
S: * 1 FETCH ...etc...
S: 004 OK done
C: 005 FETCH 51:100 ALL
S: * 51 FETCH ...etc...
S: 005 OK done
C: 006 FETCH 101:150 ALL
...etc...
Using this method, another command, such as "FETCH 6 BODY[1]" can be inserted as necessary, and the client will not have its access to the server blocked by a storm of FETCH replies. (Such a method could be reversed to fetch the LAST 50 messages first, then the 50 prior to that, and so on.)
例えば、この方法は、別のコマンドを使用して、「6 BODYをFETCH [1]、」必要に応じて挿入することができ、クライアントは応答をFETCHの嵐によって遮断サーバへのアクセスを持っていないであろう。 （このような方法は、次に50その前に、というように最初LAST 50件のメッセージを取得するために逆にすることができます。）
As a smart extension of this, a well designed client, prepared for very large mailboxes, will not automatically fetch data for all messages AT ALL. Rather, the client will populate the user's view only as the user sees it, possibly pre-fetching selected information, and only fetching other information as the user scrolls to it. For example, to select only those messages beginning with the first unseen one:
非常に大規模なメールボックスの準備このスマート延長、うまく設計されたクライアントとして、自動的にAT ALLすべてのメッセージのデータを取得しません。むしろ、クライアントは、ユーザーがそれを見ているだけのようにユーザーのビューに移入されます、おそらくプリフェッチ選択した情報、およびそれだけにユーザーがスクロールなどの他の情報を取得します。例えば、最初に目に見えない1で始まるメッセージのみを選択するには：
C: 003 SELECT INBOX
S: * 10000 EXISTS
S: * 80 RECENT
S: * FLAGS (\Answered \Flagged \Deleted \Draft \Seen)
S: * OK [UIDVALIDITY 824708485] UID validity status
S: * OK [UNSEEN 9921] First unseen message
S: 003 OK [READ-WRITE] SELECT completed
C: 004 FETCH 9921:* ALL
... etc...
If the server does not return an OK [UNSEEN] response, the client may use SEARCH UNSEEN to obtain that value.
サーバはOK [UNSEEN]応答を返さない場合、クライアントは、その値を取得するためにUNSEEN検索を使用することができます。
This mechanism is good as a default presentation method, but only works well if the default message order is acceptable. A client may want to present various sort orders to the user (by subject, by date sent, by sender, and so on) and in that case (lacking a SORT extension on the server side) the client WILL have to retrieve all message descriptors. A client that provides this service should not do it by default and should inform the user of the costs of choosing this option for large mailboxes.
このメカニズムは、デフォルトの提示方法として良いですが、デフォルトのメッセージの順序が許容される場合にのみ適しています。クライアントは、（送信者によって、送信された日付により、被験者によって、など）、ユーザーに様々なソート順を提示し、その場合（サーバ側のSORT拡張を欠く）で、クライアントは、すべてのメッセージ記述子を取得する必要がありますすることができます。このサービスを提供するクライアントは、デフォルトでそれを行うべきではないと大きなメールボックスには、このオプションを選択するのコストをユーザに知らせる必要があります。
The issue here is similar to the one for a list of messages. In the BODYSTRUCTURE response the client knows the size, in bytes, of the body part it plans to fetch. Suppose this is a 70 MB video clip. The client can use partial fetches to retrieve the body part in pieces, avoiding the problem of an uninterruptible 70 MB literal coming back from the server:
ここでの問題は、メッセージのリストのためのものと同様です。 BODYSTRUCTURE応答では、クライアントはそれをフェッチすることを計画し、本体部分のサイズをバイト単位で、知っています。これは、70メガバイトのビデオクリップであると仮定します。クライアントは、サーバから戻ってくるリテラル無停電70メガバイトの問題を回避、バラバラに身体の一部を取得するために、部分的なフェッチを使用することができます。
C: 022 FETCH 3 BODY[1]<0.20000>
S: * 3 FETCH (FLAGS(\Seen) BODY[1]<0> {20000}
S: ...data...)
S: 022 OK done
C: 023 FETCH 3 BODY[1]<20001.20000>
S: * 3 FETCH (BODY[1]<20001> {20000}
S: ...data...)
S: 023 OK done
C: 024 FETCH 3 BODY[1]<40001.20000>
...etc...
Because FETCH BODYSTRUCTURE is necessary in order to determine the number of body parts, and, thus, whether a message has "attachments", clients often use FETCH FULL as their normal method of populating the user's view of a mailbox. The benefit is that the client can display a paperclip icon or some such indication along with the normal message summary. However, this comes at a significant cost with some server configurations. The parsing needed to generate the FETCH BODYSTRUCTURE response may be time-consuming compared with that needed for FETCH ENVELOPE. The client developer should consider this issue when deciding whether the ability to add a paperclip icon is worth the tradeoff in performance, especially with large mailboxes.
、BODYSTRUCTUREメッセージは「添付ファイル」を持っているかどうか、このように、体の部分の数を決定するために必要であり、FETCHので、クライアントは、多くの場合、メールボックスのユーザーのビューを埋める彼らの通常の方法としてFULL FETCHを使用します。利点は、クライアントがクリップアイコンまたは通常のメッセージサマリと共にいくつかのこのような指示を表示することができるということです。しかし、これは一部のサーバー構成で大幅なコストがかかります。 FETCH BODYSTRUCTURE応答を生成するために必要な解析は、エンベロープをフェッチするために必要なものと比べて時間がかかるかもしれません。特に大規模なメールボックスで、クリップアイコンを追加する機能は、パフォーマンスのトレードオフの価値があるかどうかを決定する際にクライアント開発者は、この問題を考慮する必要があります。
Some clients, rather than using FETCH BODYSTRUCTURE, use FETCH BODY[] (or the equivalent FETCH RFC822) to retrieve the entire message. They then do the MIME parsing in the client. This may give the client slightly more flexibility in some areas (access, for instance, to header fields that aren't returned in the BODYSTRUCTURE and
一部のクライアントは、むしろBODYSTRUCTUREのFETCH使用するよりも、FETCH使用BODY []（または同等のRFC822をFETCH）メッセージ全体を取得するために。そして、彼らは、クライアントでMIMEの解析を行います。これは、クライアントに、たとえば、BODYSTRUCTUREで返されていないフィールドをヘッダに一部の地域では少しより多くの柔軟性（アクセス権を与えることと
ENVELOPE responses), but it can cause severe performance problems by forcing the transfer of all body parts when the user might only want to see some of them - a user logged on by modem and reading a small text message with a large ZIP file attached may prefer to read the text only and save the ZIP file for later. Therefore, a client should not normally retrieve entire messages and should retrieve message body parts selectively.
ENVELOPE応答）が、それはユーザーだけでそれらのいくつかを見たいかもしれないときに、すべての身体の部分の転送を強制することにより、深刻なパフォーマンスの問題を引き起こす可能性があります - ユーザーは、モデムでログオンし、5月付属の大型ZIPファイルに小さなテキストメッセージを読みますテキストだけを読んで、後でZIPファイルを保存することを好みます。そのため、クライアントは通常、全体のメッセージを取得すべきではなく、選択のメッセージ本文部分を取得する必要があります。
A client can wind up building a very long command line in an effort to try to be efficient about requesting information from a server. This can typically happen when a client builds a message set from selected messages and doesn't recognise that contiguous blocks of messages may be group in a range. Suppose a user selects all 10,000 messages in a large mailbox and then unselects message 287. The client could build that message set as "1:286,288:10000", but a client that doesn't handle that might try to enumerate each message individually and build "1,2,3,4, [and so on] ,9999,10000". Adding that to the fetch command results in a command line that's almost 49,000 octets long, and, clearly, one can construct a command line that's even longer.
クライアントは、サーバから情報を要求について効率的になろうとする努力には非常に長いコマンドラインを構築する羽目になることができます。クライアントは、選択したメッセージからのメッセージセットを構築し、メッセージの連続したブロックは、範囲内の基であってもよいことを認識していないとき、これは一般的に発生することがあります。 「：286288：10000 1」、それを処理しないクライアントは、個別のメッセージを列挙しようとする可能性があり、ユーザーが大規模なメールボックス内のすべての万件のメッセージを選択し、クライアントのように設定し、そのメッセージを構築できるメッセージ287を選択解除と仮定構築 "1,2,3,4、[など]、9999,10000"。明らかに、ほとんど49,000オクテット長だし、コマンドラインでコマンドの結果をフェッチするために、1がさらに長いのコマンドラインを構築することができると付け加えました。
A client should limit the length of the command lines it generates to approximately 1000 octets (including all quoted strings but not including literals). If the client is unable to group things into ranges so that the command line is within that length, it should split the request into multiple commands. The client should use literals instead of long quoted strings, in order to keep the command length down.
クライアントは、それが（すべて引用符で囲まれた文字列を含むが、リテラルは含まない）約1000個のオクテットに生成するコマンドラインの長さを制限する必要があります。クライアントが範囲にグループのものにできない場合は、コマンドラインは、その長さの範囲内になるように、それが複数のコマンドに要求を分割する必要があります。クライアントは、コマンドの長さを抑えるために、代わりに長い引用符で囲まれた文字列のリテラルを使用する必要があります。
For its part, a server should allow for a command line of at least 8000 octets. This provides plenty of leeway for accepting reasonable length commands from clients. The server should send a BAD response to a command that does not end within the server's maximum accepted command length.
その一部については、サーバーには、少なくとも8000オクテットのコマンドラインを可能にすべきです。これは、クライアントからの合理的な長さのコマンドを受け入れるための余裕の多くを提供します。サーバーは、サーバーの最大受け入れられたコマンドの長さの中に終わらないコマンドにBAD応答を送信する必要があります。
The client isn't the only entity that can get flooded: the end user, too, may need some flood control. The IMAP4 protocol provides such control in the form of subscriptions. Most servers support the SUBSCRIBE, UNSUBSCRIBE, and LSUB commands, and many users choose to narrow down a large list of available mailboxes by subscribing to the ones that they usually want to see. Clients, with this in mind, should give the user a way to see only subscribed mailboxes. A client that never uses the LSUB command takes a significant usability feature away from the user. Of course, the client would not want to hide the LIST command completely; the user needs to have a way to choose between LIST and LSUB. The usual way to do this is to provide a setting like "show which mailboxes?: [] all [] subscribed only".
クライアントは、浸水を受けることができる唯一のエンティティではありません。エンドユーザーは、あまりにも、いくつかの洪水調節が必要な場合があります。 IMAP4プロトコルは、サブスクリプションの形で、このような制御を提供します。ほとんどのサーバは、SUBSCRIBE、UNSUBSCRIBE、およびLSUBコマンドをサポートし、多くのユーザー、彼らは通常、見たいものに加入することによって利用可能なメールボックスの大規模なリストを絞り込むことを選択します。クライアントは、この点を考慮して、ユーザーにのみ加入してメールボックスを確認する方法を与える必要があります。 LSUBコマンドを使用したことがないクライアントは、ユーザから離れた重要なユーザビリティの機能を取ります。もちろん、クライアントは完全にLISTコマンドを非表示にしたくないでしょう。ユーザーはLISTとLSUBの間で選択するための方法を持っている必要があります。これを行うための通常の方法は、「メールボックスは？：[]すべて[]のみ加入ショー」のような設定を提供することです。
IMAP SEARCH commands can become particularly troublesome (that is, slow) on mailboxes containing a large number of messages. So let's put a few things in perspective in that regard.
IMAPの検索コマンドは、多数のメッセージを含むメールボックスに（即ち、遅い）、特に問題になることができます。それでは、その点での視点でいくつかのことを入れてみましょう。
The flag searches should be fast. The flag searches (ALL, [UN]SEEN, [UN]ANSWERED, [UN]DELETED, [UN]DRAFT, [UN]FLAGGED, NEW, OLD, RECENT) are known to be used by clients for the client's own use (for instance, some clients use "SEARCH UNSEEN" to find unseen mail and "SEARCH DELETED" to warn the user before expunging messages).
フラグ検索は高速である必要があります。フラグ検索（ALLは、[UN]はSEEN、[UN]は、[UN]は削除、[UN] DRAFTに答え、[UN] FLAGGED、NEW、OLD、最近は）（クライアント自身の使用のためにクライアントによって使用されることが知られています例えば、いくつかのクライアント）は、メッセージを抹消する前にユーザーに警告するために目に見えないメールや「SEARCH DELETED」を見つけるために「UNSEENを検索」を使用します。
Other searches, particularly the text searches (HEADER, TEXT, BODY) are initiated by the user, rather than by the client itself, and somewhat slower performance can be tolerated, since the user is aware that the search is being done (and is probably aware that it might be time-consuming). A smart server might use dynamic indexing to speed commonly used text searches.
その他の検索、特にテキスト検索（HEADER、TEXT、BODYは）むしろ、クライアント自身によるよりも、ユーザによって開始され、ユーザーは検索が行われていることを認識している（そしておそらくですので、多少のパフォーマンス低下が、許容できます）それは、時間がかかるかもしれないことに注意してください。スマートサーバは、一般的に使用されるテキスト検索を高速化するために、動的インデックスを使用する場合があります。
The client may allow other commands to be sent to the server while a SEARCH is in progress, but at the time of this writing there is little or no server support for parallel processing of multiple commands in the same session (and see "Multiple Accesses of the Same Mailbox" above for a description of the dangers of trying to work around this by doing your SEARCH in another session).
クライアントは、検索が進行中に、他のコマンドがサーバに送信されることを可能にすることができるが、この記事の執筆時点で、複数のコマンドの並列処理のためにほとんど、あるいはまったくサーバーのサポートは、同じセッションであり（との「多重アクセスを参照してください）別のセッションで検索を行うことによってこの問題を回避しようとしていることの危険性の説明については、上記と同じメールボックス」。
Another word about text searches: some servers, built on database back-ends with indexed search capabilities, may return search results that do not match the IMAP spec's "case-insensitive substring" requirements. While these servers are in violation of the protocol, there is little harm in the violation as long as the search results are used only in response to a user's request. Still, developers of such servers should be aware that they ARE violating the protocol, should think carefully about that behaviour, and must be certain that their servers respond accurately to the flag searches for the reasons outlined above.
テキスト検索についてのもう一つの単語：インデックス付き検索機能を使用して、データベースのバックエンド上に構築されたいくつかのサーバは、IMAP仕様の「大文字と小文字を区別しないストリング」の要件に合致しない検索結果を返すことがあります。これらのサーバは、プロトコルに違反している間に、検索結果のみがユーザの要求に応じて使用されているように、違反にはほとんど害は限りがあります。それでも、そのようなサーバの開発者は、プロトコルに違反していることを認識しておく必要があり、その行動について慎重に検討する必要があり、そのサーバが上記で概説した理由のためにフラグの検索に的確に対応することを特定する必要があります。
In addition, servers should support CHARSET UTF-8 [UTF-8] in searches.
また、サーバは検索でCHARSETのUTF-8 [UTF-8]をサポートする必要があります。
IMAP4 provides ways for a server to tell a client in advance what is and isn't permitted in some circumstances. Clients should use these features to avoid sending requests that a well designed client would know to be invalid. This section explains this in more detail.
IMAP4であり、いくつかの状況で許可されていないものを事前にクライアントに通知するためのサーバーのための方法を提供しています。クライアントは、うまく設計されたクライアントが無効であることを知っているだろうリクエストを送るのを避けるために、これらの機能を使用する必要があります。このセクションでは、これをより詳細に説明します。
All IMAP4 clients should use the CAPABILITY command to determine what version of IMAP and what optional features a server supports. The client should not send IMAP4rev1 commands and arguments to a server that does not advertize IMAP4rev1 in its CAPABILITY response. Similarly, the client should not send IMAP4 commands that no longer exist in IMAP4rev1 to a server that does not advertize IMAP4 in its CAPABILITY response. An IMAP4rev1 server is NOT required to support obsolete IMAP4 or IMAP2bis commands (though some do; do not let this fact lull you into thinking that it's valid to send such commands to an IMAP4rev1 server).
すべてのIMAP4クライアントは、サーバーがサポートしていますIMAPのバージョンとオプションの内容を決定する機能コマンドを使用する必要があります。クライアントは、その能力応答でのIMAP4rev1を広告していないサーバーへのIMAP4rev1コマンドと引数を送信するべきではありません。同様に、クライアントIMAP4を送るべきではありませんが、もはやその能力応答でIMAP4を広告していないサーバへのIMAP4rev1には存在しないことを命じます。 （;それはIMAP4rev1のサーバーにそのようなコマンドを送信するために有効だという考えにこの事実小康状態にあなたを聞かせていない一部が行うが）のIMAP4rev1サーバは時代遅れIMAP4またはIMAP2bisコマンドをサポートする必要はありません。
A client should not send commands to probe for the existance of certain extensions. All standard and standards-track extensions include CAPABILITY tokens indicating their presense. All private and experimental extensions should do the same, and clients that take advantage of them should use the CAPABILITY response to determine whether they may be used or not.
クライアントは、特定の拡張子のexistanceをプローブするためのコマンドを送るべきではありません。すべての標準および標準化過程の拡張機能は、彼らのpresenseを示すCAPABILITYトークンが含まれます。すべてのプライベートと実験の拡張機能は、同じことを行う必要があり、それらを利用するクライアントは、彼らが使用してもしなくてもよいかどうかを判断する能力応答を使用する必要があります。
In many cases, the server, in response to a command, will tell the client something about what can and can't be done with a particular mailbox. The client should pay attention to this information and should not try to do things that it's been told it can't do.
多くの場合、サーバーは、コマンドに応答して、特定のメールボックスで行うことができないことができるかについてクライアントに何かを教えてくれます。クライアントは、この情報に注意を払う必要があり、それを行うことができないと言われています事をやろうではないはずです。
Examples:
例：
* Do not try to SELECT a mailbox that has the \Noselect flag set. * Do not try to CREATE a sub-mailbox in a mailbox that has the \Noinferiors flag set. * Do not respond to a failing COPY or APPEND command by trying to CREATE the target mailbox if the server does not respond with a [TRYCREATE] response code. * Do not try to expunge a mailbox that has been selected with the [READ-ONLY] response code.
* \ NOSELECTフラグが設定されているメールボックスを選択しないでください。 * \ Noinferiorsフラグがセットされているメールボックス内のサブメールボックスを作成しようとしないでください。 *障害のあるコピーへの対応や、サーバーが[TRYCREATE]応答コードで応答しない場合は、対象のメールボックスを作成しようとすることで、コマンドを追加しないでください。 * [読み取り専用]応答コードで選択されたメールボックスを抹消しようとしないでください。
We describe here a number of important protocol-related issues, the misunderstanding of which has caused significant interoperability problems in IMAP4 implementations. One general item is that every implementer should be certain to take note of and to understand section 2.2.2 and the preamble to section 7 of the IMAP4rev1 spec [RFC-2060].
私たちは、の誤解は、IMAP4の実装で重要な相互運用性の問題を引き起こしている、ここで重要なプロトコル関連の問題の数を記述する。一つの一般的な項目は、すべての実装は、メモを取ることと、セクション2.2.2およびIMAP4rev1の仕様[RFC-2060]のセクション7にプリアンブルを理解するために特定でなければならないということです。
We cannot stress enough the importance of adhering strictly to the protocol grammar. The specification of the protocol is quite rigid; do not assume that you can insert blank space for "readability" if none is called for. Keep in mind that there are parsers out there that will crash if there are protocol errors. There are clients that will report every parser burp to the user. And in any case, information that cannot be parsed is information that is lost. Be careful in your protocol generation. And see "A Word About Testing", below.
私たちは、プロトコルの文法に厳密に付着するのに十分な重要性を強調することはできません。プロトコルの仕様は非常に剛性です。どれもが求めていない場合は、「読みやすさ」のために空白を挿入できることを前提としていません。プロトコル・エラーがある場合、クラッシュしますそこにパーサがあることに留意してください。ユーザーにすべてのパーサげっぷを報告するクライアントがあります。そして、どのような場合には、解析できない情報は失われている情報です。あなたのプロトコルの世代では注意してください。そして、以下、「テストについての言葉」を参照してください。
In particular, note that the string in the INTERNALDATE response is NOT an RFC-822 date string - that is, it is not in the same format as the first string in the ENVELOPE response. Since most clients will, in fact, accept an RFC-822 date string in the INTERNALDATE response, it's easy to miss this in your interoperability testing. But it will cause a problem with some client, so be sure to generate the correct string for this field.
特に、INTERNALDATE応答の文字列がRFC-822日付の文字列でないことに注意してください - つまり、エンベロープ応答の最初の列と同じ形式ではありません。ほとんどのクライアントは、実際には、INTERNALDATE応答にRFC-822日付文字列を受け付けますので、それはあなたの相互運用性テストでこれを欠場するのは簡単です。しかし、それはいくつかのクライアントとの問題を引き起こすので、このフィールドに正しい文字列を生成するようにしてくださいます。
Certain characters, currently the double-quote and the backslash, may not be sent as-is inside a quoted string. These characters must be preceded by the escape character if they are in a quoted string, or else the string must be sent as a literal. Both clients and servers must handle this, both on output (they must send these characters properly) and on input (they must be able to receive escaped characters in quoted strings). Example:
引用符で囲まれた文字列内-あるとして、特定の文字、現在は二重引用符やバックスラッシュは、送信されない場合があります。彼らは引用符で囲まれた文字列である場合、これらの文字は、エスケープ文字を付ける必要があり、さもなければ、文字列リテラルとして送信する必要があります。クライアントとサーバの両方が両方の出力に（彼らは適切にこれらの文字を送信する必要があります）、これを処理しなければならないし、入力に（彼らは引用符で囲まれた文字列にエスケープ文字を受け取ることができなければなりません）。例：
C: 001 LIST "" %
S: * LIST () "" INBOX
S: * LIST () "\\" TEST
S: * LIST () "\\" {12}
S: "My" mailbox
S: 001 OK done
C: 002 LIST "" "\"My\" mailbox\\%"
S: * LIST () "\\" {17}
S: "My" mailbox\Junk
S: 002 OK done
S：完了002 OK
Note that in the example the server sent the hierarchy delimiter as an escaped character in the quoted string and sent the mailbox name containing imbedded double-quotes as a literal. The client used only quoted strings, escaping both the backslash and the double-quote characters.
例では、サーバは、引用符で囲まれた文字列にエスケープ文字として階層区切り文字を送信し、リテラルとして埋め込まれた二重引用符を含むメールボックス名を送っていることに注意してください。クライアントは、バックスラッシュと二重引用符の両方をエスケープ、引用符で囲まれた文字列のみを使用します。
The CR and LF characters may be sent ONLY in literals; they are not allowed, even if escaped, inside quoted strings.
CRとLF文字はリテラルにのみ送信することができます。それらは引用符で囲まれた文字列内で、エスケープしても、許可されていません。
And while we're talking about special characters: the IMAP spec, in the section titled "Mailbox International Naming Convention", describes how to encode mailbox names in modified UTF-7 [UTF-7 and RFC-2060]. Implementations must adhere to this in order to be interoperable in the international market, and servers should validate mailbox names sent by client and reject names that do not conform.
私たちは、特殊文字の話をしている間、および：IMAPの仕様、「メールボックスの国際命名規則」というタイトルのセクションでは、修正UTF-7 [UTF-7およびRFC-2060]でメールボックス名をエンコードする方法について説明します。実装は、国際市場での相互運用可能にするためにこれに準拠する必要があり、およびサーバは、クライアントから送信されたメールボックス名を検証し、準拠していない名前を拒否すべきです。
As to special characters in userids and passwords: clients must not restrict what a user may type in for a userid or a password. The formal grammar specifies that these are "astrings", and an astring can be a literal. A literal, in turn can contain any 8-bit character, and clients must allow users to enter all 8-bit characters here, and must pass them, unchanged, to the server (being careful to send them as literals when necessary). In particular, some server configurations use "@" in user names, and some clients do not allow that character to be entered; this creates a severe interoperability problem.
ユーザーIDとパスワードに特殊文字については：クライアントユーザーは、ユーザーIDやパスワードを入力して何を制限してはなりません。正式な文法は、これらは「astrings」であることを指定し、AStringとは文字通りすることができます。サーバー（必要な場合にリテラルとしてそれらを送信するように注意して）に、そのまま、リテラルは、順番に任意の8ビット文字を含めることができ、クライアントは、ユーザーがここにすべての8ビット文字を入力できるようにする必要があり、それらを渡す必要があります。特に、一部のサーバー構成では、ユーザー名に「@」を使用し、いくつかのクライアントは、その文字を入力することはできません。これは深刻な相互運用性の問題を作成します。
Servers that support existing back-end mail stores often have no good place to save UIDs for messages. Often the existing mail store will not have the concept of UIDs in the sense that IMAP has: strictly increasing, never re-issued, 32-bit integers. Some servers solve this by storing the UIDs in a place that's accessible to end users, allowing for the possibility that the users will delete them. Others solve it by re-assigning UIDs every time a mailbox is selected.
既存のバックエンドのメールストアをサポートするサーバーは、多くの場合、メッセージのためのUIDを保存する何の良い場所を持っていません。厳密に増加、決して再発行され、32ビット整数を：多くの場合、既存のメールストアは、IMAPを持っているという意味でのUIDの概念を持っていません。一部のサーバーは、ユーザーがそれらを削除する可能性を考慮し、エンドユーザーにアクセス可能な場所でのUIDを格納することによってこの問題を解決します。その他には、再割り当てのUIDでメールボックスが選択されるたびにそれを解決します。
The server should maintain UIDs permanently for all messages if it can. If that's not possible, the server must change the UIDVALIDITY value for the mailbox whenever any of the UIDs may have become invalid. Clients must recognize that the UIDVALIDITY has changed and must respond to that condition by throwing away any information that they have saved about UIDs in that mailbox. There have been many problems in this area when clients have failed to do this; in the worst case it will result in loss of mail when a client deletes the wrong piece of mail by using a stale UID.
それができれば、サーバーはすべてのメッセージのための恒久的UIDを維持する必要があります。それが不可能な場合のUIDのいずれかが無効になっている可能性がありたび、サーバーは、メールボックスのUIDVALIDITY値を変更する必要があります。クライアントは、UIDVALIDITYが変更されたことを認識しなければならないと、彼らはそのメールボックス内のUIDについて保存されているすべての情報を捨てることで、その条件に応答しなければなりません。クライアントはこれを行うに失敗しているこの分野で多くの問題がありました。クライアントが古いUIDを使用してメールの間違った部分を削除するとき、最悪のケースでは、メールが失われます。
It seems to be a common misunderstanding that "the UIDVALIDITY and the UID, taken together, form a 64-bit identifier that uniquely identifies a message on a server". This is absolutely NOT TRUE. There is no assurance that the UIDVALIDITY values of two mailboxes be different, so the UIDVALIDITY in no way identifies a mailbox. The ONLY purpose of UIDVALIDITY is, as its name indicates, to give the client a way to check the validity of the UIDs it has cached. While it is a valid implementation choice to put these values together to make a 64-bit identifier for the message, the important concept here is that UIDs are not unique between mailboxes; they are only unique WITHIN a given mailbox.
「一緒になってUIDVALIDITYとUIDは、一意のサーバ上のメッセージを識別する64ビットの識別子を形成する」という一般的な誤解であると思われます。これは絶対に真実ではありません。そこ2つのメールボックスのUIDVALIDITY値が異なるという保証がないので、決してUIDVALIDITYは、メールボックスを識別します。その名は、クライアントにそれがキャッシュされているのUIDの妥当性をチェックする方法を提供すること、を示しているようUIDVALIDITYの唯一の目的は、あります。それはメッセージの64ビットの識別子を作るために一緒にこれらの値を置くために、有効な実装の選択肢がありますが、ここで重要な概念は、UIDのメールボックスの間で固有のものではないということです。彼らは与えられたメールボックス内でのみ一意です。
Some server implementations have attempted to make UIDs unique across the entire server. This is inadvisable, in that it limits the life of UIDs unnecessarily. The UID is a 32-bit number and will run out in reasonably finite time if it's global across the server. If you assign UIDs sequentially in one mailbox, you will not have to start re-using them until you have had, at one time or another, 2**32 different messages in that mailbox. In the global case, you will have to reuse them once you have had, at one time or another, 2**32 different messages in the entire mail store. Suppose your server has around 8000 users registered (2**13). That gives an average of 2**19 UIDs per user. Suppose each user gets 32 messages (2**5) per day. That gives you 2**14 days (16000+ days = about 45 years) before you run out. That may seem like enough, but multiply the usage just a little (a lot of spam, a lot of mailing list subscriptions, more users) and you limit yourself too much.
一部のサーバーの実装は、サーバ全体にわたるのUIDを一意にすることを試みてきました。それは不必要のUIDの寿命を制限している中で、これはお勧めできません。 UIDは32ビットの数値であり、それは、サーバ全体でグローバルかどう合理的に有限の時間内で実行されます。あなたが1つのメールボックスでのUIDを順次割り当てた場合は、そのメールボックスに、1時間または別では、2 ** 32種類のメッセージを持っていたまで、あなたはそれらを再使用して起動する必要はありません。グローバルなケースでは、あなたが持っていた後、1時間または別では、全体のメールストアで2つの** 32件の異なるメッセージを再利用する必要があります。お使いのサーバが登録周り8000ユーザー（2 ** 13）を持っていると仮定します。つまり、ユーザごとに2つの** 19のUIDの平均を与えます。各ユーザーは、一日あたり32のメッセージ（2 ** 5）を取得したとします。あなたが出て実行する前に、それはあなたに2 ** 14日（16000+日=約45年間）を提供します。それは十分のように見えるが、ほんの少し（スパムの多くは、メーリングリストの購読の多くは、より多くのユーザ）の使用を掛け、あなたはあまり自分を制限する可能性があります。
What's worse is that if you have to wrap the UIDs, and, thus, you have to change UIDVALIDITY and invalidate the UIDs in the mailbox, you have to do it for EVERY mailbox in the system, since they all share the same UID pool. If you assign UIDs per mailbox and you have a problem, you only have to kill the UIDs for that one mailbox.
さらに悪いのは、それらはすべて同じUIDプールを共有しているため、あなたはこのように、UIDをラップし、必要がある場合、あなたはUIDVALIDITYを変更して、メールボックス内のUIDを無効にする必要があり、あなたは、システム内のすべてのメールボックスのためにそれをしなければならないということです。メールボックスあたりのUIDを割り当てて、あなたは問題がある場合は、あなただけのその1つのメールボックスのUIDを殺さなければなりません。
Under extreme circumstances (and this is extreme, indeed), the server may have to invalidate UIDs while a mailbox is in use by a client - that is, the UIDs that the client knows about in its active mailbox are no longer valid. In that case, the server must immediately change the UIDVALIDITY and must communicate this to the client. The server may do this by sending an unsolicited UIDVALIDITY message, in the same form as in response to the SELECT command. Clients must be prepared to handle such a message and the possibly coincident failure of the command in process. For example:
極端な状況下では（これは極端で、確かに）、サーバはメールボックスがクライアントによって使用されている間、UIDを無効にする必要があります - つまり、そのアクティブメールボックスにクライアントが知っているのUIDは、もはや有効ではありません。その場合、サーバーはすぐにUIDVALIDITYを変更する必要がありますし、クライアントにこれを通信する必要があります。サーバは、SELECTコマンドに応答したのと同じ形で、迷惑UIDVALIDITYメッセージを送信することにより、これを行うことがあります。クライアントは、メッセージやプロセスにおけるコマンドの可能性が一致失敗を処理するために準備する必要があります。例えば：
C: 032 UID STORE 382 +Flags.silent \Deleted
S: * OK [UIDVALIDITY 12345] New UIDVALIDITY value!
S: 032 NO UID command rejected because UIDVALIDITY changed!
C: ...invalidates local information and re-fetches...
C: 033 FETCH 1:* UID
...etc...
At the time of the writing of this document, the only server known to do this does so only under the following condition: the client selects INBOX, but there is not yet a physical INBOX file created. Nonetheless, the SELECT succeeds, exporting an empty INBOX with a temporary UIDVALIDITY of 1. While the INBOX remains selected, mail is delivered to the user, which creates the real INBOX file and assigns a permanent UIDVALIDITY (that is likely not to be 1). The server reports the change of UIDVALIDITY, but as there were no messages before, so no UIDs have actually changed, all the client must do is accept the change in UIDVALIDITY.
このドキュメントの執筆時点では、これを行うことが知られている唯一のサーバーでのみ、以下の条件の下でそうする：クライアントは、INBOXを選択するが、作成した物理INBOXファイルがまだありません。それにもかかわらず、SELECTが成功し、INBOXが選択されたままであるが1の一時的なUIDVALIDITYと空のINBOXをエクスポート、メールは実際のINBOXファイルを作成し、恒久的なUIDVALIDITYを割り当てるユーザー（つまり1ではないと思われる）に配信されます。サーバはUIDVALIDITYの変更を報告しますが、何もメッセージが前になかったようなので、何のUIDが実際に変化しなかったが、すべてのクライアントが行う必要がありますUIDVALIDITYの変化を受け入れることです。
Alternatively, a server may force the client to re-select the mailbox, at which time it will obtain a new UIDVALIDITY value. To do this, the server closes this client session (see "Severed Connections" above) and the client then reconnects and gets back in synch. Clients must be prepared for either of these behaviours.
また、サーバは、それが新しいUIDVALIDITY値を取得しますその時点でメールボックスを再選択するようにクライアントを強制することがあります。これを行うために、サーバは（上記の「切断された接続」を参照）、このクライアントセッションを閉じ、その後、クライアントは、再接続して同期して戻って取得します。クライアントは、これらの動作のいずれかのために準備しなければなりません。
We do not know of, nor do we anticipate the future existance of, a server that changes UIDVALIDITY while there are existing messages, but clients must be prepared to handle this eventuality.
私たちは知らない、また我々は、将来の存在を予測しない、既存のメッセージがある一方でUIDVALIDITYを変更し、サーバが、クライアントは、この不測の事態に対処する準備をしなければなりません。
When a client asks for certain information in a FETCH command, the server may return the requested information in any order, not necessarily in the order that it was requested. Further, the server may return the information in separate FETCH responses and may also return information that was not explicitly requested (to reflect to the client changes in the state of the subject message). Some examples:
クライアントは、FETCHコマンドで特定の情報を要求すると、サーバーは、必ずしもそれが要求された順序で、任意の順序で要求された情報を返すことがあります。また、サーバは、別々のFETCH応答で情報を返すことができ、また（件名メッセージの状態のクライアントの変化に反映させるために）明示的に要求されなかった情報を返すことがあります。いくつかの例：
C: 001 FETCH 1 UID FLAGS INTERNALDATE
S: * 5 FETCH (FLAGS (\Deleted))
S: * 1 FETCH (FLAGS (\Seen) INTERNALDATE "..." UID 345)
S: 001 OK done
(In this case, the responses are in a different order. Also, the server returned a flag update for message 5, which wasn't part of the client's request.)
（この場合、応答は、異なる順序である。また、サーバがクライアントの要求の一部ではありませんでしたメッセージ5、フラグの更新を返しました。）
C: 002 FETCH 2 UID FLAGS INTERNALDATE
S: * 2 FETCH (INTERNALDATE "...")
S: * 2 FETCH (UID 399)
S: * 2 FETCH (FLAGS ())
S: 002 OK done
(In this case, the responses are in a different order and were returned in separate responses.)
（この場合、応答は、異なる順序であり、別の応答で返されました。）
C: 003 FETCH 2 BODY[1]
S: * 2 FETCH (FLAGS (\Seen) BODY[1] {14}
S: Hello world!
S: )
S: 003 OK done
(In this case, the FLAGS response was added by the server, since fetching the body part caused the server to set the \Seen flag.)
（身体部分をフェッチする\見フラグを設定するようにサーバに起因するので、この場合には、FLAGS応答は、サーバによって追加されました。）
Because of this characteristic a client must be ready to receive any FETCH response at any time and should use that information to update its local information about the message to which the FETCH response refers. A client must not assume that any FETCH responses will come in any particular order, or even that any will come at all. If after receiving the tagged response for a FETCH command the client finds that it did not get all of the information requested, the client should send a NOOP command to the server to ensure that the server has an opportunity to send any pending EXPUNGE responses to the client (see [RFC-2180]).
このため、特性のクライアントは、任意の時点での応答をFETCH受信する準備ができなければならず、応答が参照FETCHしたメッセージについて、そのローカルの情報を更新するために、その情報を使用する必要があります。クライアントは、任意の応答が特定の順序で来る、またはいずれかが全く来るさえというFETCHと仮定してはいけません。クライアントが要求された情報のすべてを取得していないことを発見コマンドFETCHのためのタグ付けされた応答を受け取った後、クライアントはサーバーが保留中のEXPUNGE応答を送信する機会を持っていることを確認するためにサーバにNOOPコマンドを送信する必要がある場合クライアント（[RFC-2180]を参照）。
Some back-end mail stores keep the mail in a canonical form, rather than retaining the original MIME format of the messages. This means that the server must reassemble the message to produce a MIME stream when a client does a fetch such as RFC822 or BODY[], requesting the entire message. It also may mean that the server has no convenient way to know the RFC822.SIZE of the message. Often, such a server will actually have to build the MIME stream to compute the size, only to throw the stream away and report the size to the client.
いくつかのバックエンドのメールストアではなく、メッセージの元のMIME形式を保持するよりも、標準的な形式でメールを保ちます。これにより、サーバーは、クライアントがメッセージ全体を要求し、RFC822またはBODY []のようなフェッチしMIMEストリームを生成するためにメッセージを再構築しなければならないことを意味します。また、サーバーがメッセージのRFC822.SIZEを知るための便利な方法を持っていないことを意味します。しばしば、このようなサーバーは、実際にはわずかな距離のストリームを投げると、クライアントにサイズを報告し、大きさを計算するためにMIMEストリームを構築する必要があります。
When this is the case, some servers have chosen to estimate the size, rather than to compute it precisely. Such an estimate allows the client to display an approximate size to the user and to use the estimate in flood control considerations (q.v.), but requires that the client not use the size for things such as allocation of buffers, because those buffers might then be too small to hold the actual MIME stream. Instead, a client should use the size that's returned in the literal when you fetch the data.
これが事実である場合には、いくつかのサーバは、正確にそれを計算するのではなく、大きさを推定することを選択しました。このような推定値は、クライアントがユーザーにおおよそのサイズを表示し、治水上の考慮事項（QV）で推定値を使用することができますが、これらのバッファが、その後可能性があるため、クライアントは、そのようなバッファの割り当てなど、物事のサイズを使用しないことを要求します実際のMIMEストリームを保持するには小さすぎます。代わりに、クライアントは、データをフェッチする際リテラルで返されるサイズを使用する必要があります。
The protocol requires that the RFC822.SIZE value returned by the server be EXACT. Estimating the size is a protocol violation, and server designers must be aware that, despite the performance savings they might realize in using an estimate, this practice will cause some clients to fail in various ways. If possible, the server should compute the RFC822.SIZE for a particular message once, and then save it for later retrieval. If that's not possible, the server must compute the value exactly every time. Incorrect estimates do cause severe interoperability problems with some clients.
プロトコルは、サーバから返されたRFC822.SIZE値が正確であることが必要です。サイズを推定することは、プロトコル違反であり、サーバの設計者は、彼らが推定値を使用して実現するかもしれないパフォーマンスの節約にもかかわらず、このような行為は、いくつかのクライアントはさまざまな方法で失敗する原因になります、ということを認識する必要があります。可能であれば、サーバは一度、特定のメッセージのRFC822.SIZEを計算し、その後、後の検索のためにそれを保存する必要があります。それができない場合は、サーバーは正確に毎回値を計算しなければなりません。誤った推定値は、いくつかのクライアントとの深刻な相互運用性の問題を引き起こしません。
If the server allows multiple connections to the same mailbox, it is often possible for messages to be expunged in one client unbeknownst to another client. Since the server is not allowed to tell the client about these expunged messages in response to a FETCH command, the server may have to deal with the issue of how to return information about an expunged message. There was extensive discussion about this issue, and the results of that discussion are summarized in [RFC-2180]. See that reference for a detailed explanation and for recommendations.
サーバーは、同じメールボックスに複数の接続を許可している場合、それは他のクライアントに知られずに一つのクライアントに抹消されるメッセージのためにしばしば可能です。サーバはFETCHコマンドに応答して、これらの抹消のメッセージについてクライアントに通知するために許可されていないので、サーバーは、消去されたメッセージについての情報を返す方法の問題に対処する必要があります。そここの問題について広範な議論があって、その議論の結果は、[RFC-2180]にまとめられています。詳細な説明のためにと勧告のためにそのリファレンスを参照してください。
Namespaces are a very muddy area in IMAP4 implementation right now (see [NAMESPACE] for a proposal to clear the water a bit). Until the issue is resolved, the important thing for client developers to understand is that some servers provide access through IMAP to more than just the user's personal mailboxes, and, in fact, the user's personal mailboxes may be "hidden" somewhere in the user's default hierarchy. The client, therefore, should provide a setting wherein the user can specify a prefix to be used when accessing mailboxes. If the user's mailboxes are all in "~/mail/", for instance, then the user can put that string in the prefix. The client would then put the prefix in front of any name pattern in the LIST and LSUB commands:
名前空間は（水にビットをクリアするための提案のための[NAMESPACE]を参照）今IMAP4の実装では非常に泥の領域です。問題が解決されるまでは、理解するためのクライアントの開発者にとって重要なことは、実際には、ユーザの個人のメールボックスは、ユーザーのデフォルトのどこかに「隠された」であってもよく、一部のサーバーだけで、ユーザーの個人のメールボックス以上にIMAP経由のアクセスを提供していることで、階層。クライアントは、そのため、ユーザーはメールボックスにアクセスするときに使用する接頭辞を指定することができ、前記設定を提供する必要があります。ユーザーのメールボックスがすべて「〜/メール/」にある場合、例えば、ユーザは、接頭辞にその文字列を置くことができます。次に、クライアントは、リスト内の任意の名前パターンの前に接頭辞を置くとLSUBコマンド：
C: 001 LIST "" ~/mail/%
C：001 LIST "" 〜/メール/％
(See also "Reference Names in the LIST Command" below.)
（以下「LISTコマンドでリファレンスの名前」も参照してください。）
It may seem at first that this is part of the namespace issue; it is not, and is only indirectly related to it. A number of clients like to create special-use mailboxes with particular names. Most commonly, clients with a "trash folder" model of message deletion want to create a mailbox with the name "Trash" or "Deleted". Some clients want to create a "Drafts" mailbox, an "Outbox" mailbox, or a "Sent Mail" mailbox. And so on. There are two major interoperability problems with this practice:
名前空間の問題の一部であることを最初に見えるかもしれません。そうではありません、そして間接的にしか、それに関連しています。クライアントの数は、特定の名前を持つ特殊な用途のメールボックスを作成したいです。最も一般的には、メッセージ削除の「ごみ箱フォルダ」モデルとクライアントが名前を「ゴミ箱」または「削除」してメールボックスを作成します。一部のクライアントは、「下書き」メールボックス、「送信トレイ」のメールボックス、または「送信済みメール」のメールボックスを作成します。等々。この習慣を持つ2つの主要な相互運用性の問題があります。
1. different clients may use different names for mailboxes with similar functions (such as "Trash" and "Deleted"), or may manage the same mailboxes in different ways, causing problems if a user switches between clients and 2. there is no guarantee that the server will allow the creation of the desired mailbox.
1.異なるクライアントは、ユーザがクライアントと2の間で切り替わる場合に保証はない問題を引き起こし、（例えば、「ゴミ箱」と「削除」など）は、同様の機能を持つメールボックスに異なる名前を使用することができ、又は異なる方法で同じメールボックスを管理することができますそのサーバーは、希望のメールボックスの作成を許可します。
The client developer is, therefore, well advised to consider carefully the creation of any special-use mailboxes on the server, and, further, the client must not require such mailbox creation - that is, if you do decide to do this, you must handle gracefully the failure of the CREATE command and behave reasonably when your special-use mailboxes do not exist and can not be created.
クライアント開発者は、それゆえ、十分慎重にサーバー上の特別な用途のメールボックスの作成を検討することをお勧めします、そして、さらに、クライアントは、メールボックスの作成を要求してはならない - つまり、あなたがこれを行うことにしたならば、あなたがしなければなりません優雅にCREATEコマンドの失敗を処理し、あなたの特別な用途のメールボックスが存在しないと作成できない場合、合理的に振る舞います。
In addition, the client developer should provide a convenient way for the user to select the names for any special-use mailboxes, allowing the user to make these names the same in all clients used and to put them where the user wants them.
また、クライアント開発者は、ユーザーがすべてのクライアントにこれらの名前は同じにすることができ、特別な用途のメールボックスの名前を選択するユーザーのための便利な方法を提供する必要があります使用して、ユーザーがそれらを望んでいる場所にそれらを置きます。
Many implementers of both clients and servers are confused by the "reference name" on the LIST command. The reference name is intended to be used in much the way a "cd" (change directory) command is used on Unix, PC DOS, Windows, and OS/2 systems. That is, the mailbox name is interpreted in much the same way as a file of that name would be found if one had done a "cd" command into the directory specified by the reference name. For example, in Unix we have the following:
クライアントとサーバの両方の多くの実装は、LISTコマンドの「参照名」で混乱しています。参照名は、「CD」（ディレクトリ変更）コマンドはUnixの、PC DOS、Windows、およびOS / 2システム上で使用されている多くの方法で使用されることを意図しています。 1が基準名前で指定されたディレクトリへの「CD」コマンドを行っていた場合には、メールボックス名が見られるという名前のファイルとほとんど同じように解釈されています。たとえば、UNIXで我々は次のようにあります。
> cd /u/jones/junk
> vi banana [file is "/u/jones/junk/banana"]
> vi stuff/banana [file is "/u/jones/junk/stuff/banana"]
> vi /etc/hosts [file is "/etc/hosts"]
In the past, there have been several interoperability problems with this. First, while some IMAP servers are built on Unix or PC file systems, many others are not, and the file system semantics do not make sense in those configurations. Second, while some IMAP servers expose the underlying file system to the clients, others allow access only to the user's personal mailboxes, or to some other limited set of files, making such file-system-like semantics less meaningful. Third, because the IMAP spec leaves the interpretation of the reference name as "implementation-dependent", in the past the various server implementations handled it in vastly differing ways.
過去には、このにはいくつかの相互運用性の問題がありました。一部のIMAPサーバは、UNIXやPCのファイルシステム上に構築されている間、まず、多くの人はそうではありません、およびファイルシステムのセマンティクスは、これらの構成では意味がありません。一部のIMAPサーバがクライアントに基本的なファイルシステムを公開しながら、第二に、他の人がそのようなファイル・システムのような意味があまり意味のある作り、唯一のユーザーの個人のメールボックスに、またはファイルの他のいくつかの限定されたセットへのアクセスを許可します。第三に、「実装依存」は、過去に様々なサーバの実装が大幅に異なる方法でそれを処理してIMAPの仕様は、参照名の解釈を残しているため。
The following recommendations are the result of significant operational experience, and are intended to maximize interoperability.
次の推奨事項は、重要な運用経験の結果である、との相互運用性を最大化することを意図しています。
Server implementations must implement the reference argument in a way that matches the intended "change directory" operation as closely as possible. As a minimum implementation, the reference argument may be prepended to the mailbox name (while suppressing double delimiters; see the next paragraph). Even servers that do not provide a way to break out of the current hierarchy (see "breakout facility" below) must provide a reasonable implementation of the reference argument, as described here, so that they will interoperate with clients that use it.
サーバ実装はできるだけ密接に意図され、「変更ディレクトリ」に合致した方法で、参照引数を実装する必要があります。 （二重の区切り文字を抑制しつつ、次の段落を参照）最小の実装としては、参照引数は、メールボックス名の前に付加することができます。現在の階層から抜け出すための方法を提供していなくても、サーバは、ここで説明したように、彼らはそれを使用するクライアントと相互運用するように、参照引数の合理的な実装を提供する必要があります（「ブレイクアウト機能」は下記参照します）。
Server implementations that prepend the reference argument to the mailbox name should insert a hierarchy delimiter between them, and must not insert a second if one is already present:
メールボックス名への参照引数を付加サーバ実装は、それらの間の階層区切り文字を挿入する必要があり、もう1つは既に存在している場合は、2番目を挿入してはいけません。
C: A001 LIST ABC DEF
S: * LIST () "/" ABC/DEF <=== should do this
S: A001 OK done
C: A002 LIST ABC/ /DEF S: * LIST () "/" ABC//DEF <=== must not do this S: A002 OK done
C：A002のLIST ABC / / DEF S：* LIST（）は、 "/" ABCは// DEF <===この操作を行う必要がありませんS：A002はOK完了
On clients, the reference argument is chiefly used to implement a "breakout facility", wherein the user may directly access a mailbox outside the "current directory" hierarchy. Client implementations should have an operational mode that does not use the reference argument. This is to interoperate with older servers that did not implement the reference argument properly. While it's a good idea to give the user access to a breakout facility, clients that do not intend to do so should not use the reference argument at all.
クライアントに、参照引数は主にユーザが直接「カレントディレクトリ」の階層外のメールボックスにアクセスすることができる、請求「ブレイクアウト機能」を実現するために使用されます。クライアントの実装は、参照引数を使用しない動作モードを持っている必要があります。これは、適切に参照引数を実装していない古いサーバと相互運用することです。それはユーザーにブレイクアウト施設へのアクセスを提供することをお勧めしますが、そうすることを意図していないクライアントは、すべての参照引数を使用しないでください。
Client implementations should always place a trailing hierarchy delimiter on the reference argument. This is because some servers prepend the reference argument to the mailbox name without inserting a hierarchy delimiter, while others do insert a hierarchy delimiter if one is not already present. A client that puts the delimiter in will work with both varieties of server.
クライアントの実装は、常に参照引数の末尾の階層区切り文字を配置する必要があります。他の人が1がすでに存在していない場合は、階層区切り文字を挿入しない間、いくつかのサーバーは、階層区切り文字を挿入することなく、メールボックス名への参照引数を付加するためです。で区切り文字を置くクライアントはサーバの両方の品種で動作します。
Client implementations that implement a breakout facility should allow the user to choose whether or not to use a leading hierarchy delimiter on the mailbox argument. This is because the handling of a leading mailbox hierarchy delimiter also varies from server to server, and even between different mailstores on the same server. In some cases, a leading hierarchy delimiter means "discard the reference argument" (implementing the intended breakout facility), thus:
ブレイクアウト機能を実装するクライアントの実装では、ユーザーがメールボックス引数の主要な階層区切り文字を使用するかどうかを選択できるようにする必要があります。主要なメールボックスの階層区切り文字の取り扱いは、サーバからサーバへ、さらには、同じサーバー上の別のメールストア間で変動するためです。いくつかの場合において、主要階層デリミタは、したがって、（意図ブレイクアウト機能を実現）「参照引数を破棄」を意味します。
C: A001 LIST ABC/ /DEF
S: * LIST () "/" /DEF
S: A001 OK done
In other cases, however, the two are catenated and the extra hierarchy delimiter is discarded, thus:
他の場合では、しかし、2つの鎖状に連結され、余分な階層デリミタは、このように、廃棄されます。
C: A001 LIST ABC/ /DEF
S: * LIST () "/" ABC/DEF
S: A001 OK done
Client implementations must not assume that the server supports a breakout facility, but may provide a way for the user to use one if it is available. Any breakout facility should be exported to the user interface. Note that there may be other "breakout" characters besides the hierarchy delimiter (for instance, UNIX filesystem servers are likely to use a leading "~" as well), and that their interpretation is server-dependent.
クライアントの実装は、サーバーがブレイクアウト機能をサポートしていることを仮定してはいけませんが、それが利用可能な場合、ユーザーがいずれかを使用するための方法を提供することができます。どれブレイクアウト機能は、ユーザーインターフェイスにエクスポートする必要があります。階層区切り文字以外の「ブレイクアウト」の文字があるかもしれないことに注意してください（たとえば、UNIXファイルシステムのサーバーが使用する可能性がある先頭の「〜」だけでなく）、およびその解釈は、サーバーに依存していること。
The server's selection of what to use as a mailbox hierarchy delimiter is a difficult one, involving several issues: What characters do users expect to see? What characters can they enter for a hierarchy delimiter if it is desired (or required) that the user enter it? What character can be used for the hierarchy delimiter, noting that the chosen character can not otherwise be used in the mailbox name?
メールボックスの階層の区切り文字として使用するかのサーバの選択は、いくつかの問題を含む、難しいものです：ユーザーが見るために何文字期待していますか？ユーザーがそれを入力することが望ましい（または必要）されている場合、彼らは、階層区切りのためにどのような文字を入力することができますか？どのような文字は、選択した文字が、そうでない場合は、メールボックス名に使用できないことに注意して、階層区切り文字のために使用することができますか？
Because some interfaces show users the hierarchy delimiters or allow users to enter qualified mailbox names containing them, server implementations should use delimiter characters that users generally expect to see as name separators. The most common characters used for this are "/" (as in Unix file names), "\" (as in OS/2 and Windows file names), and "." (as in news groups). There is little to choose among these apart from what users may expect or what is dictated by the underlying file system, if any. One consideration about using "\" is that it's also a special character in the IMAP protocol. While the use of other hierarchy delimiter characters is permissible, A DESIGNER IS WELL ADVISED TO STAY WITH ONE FROM THIS SET unless the server is intended for special purposes only. Implementers might be thinking about using characters such as "-", "_", ";", "&", "#", "@", and "!", but they should be aware of the surprise to the user as well as of the effect on URLs and other external specifications (since some of these characters have special meanings there). Also, a server that uses "\" (and clients of such a server) must remember to escape that character in quoted strings or to send literals instead. Literals are recommended over escaped characters in quoted strings in order to maintain compatibility with older IMAP versions that did not allow escaped characters in quoted strings (but check the grammar to see where literals are allowed):
いくつかのインタフェースは、ユーザーが階層区切り文字を表示したり、ユーザーがそれらを含む修飾メールボックス名を入力することを可能にするため、サーバーの実装は、ユーザーが一般的に名の区切りとして見ることを期待区切り文字を使用する必要があります。このために使用される最も一般的な文字は「/」（Unixファイル名のように）、「\」（OS / 2およびWindowsのファイル名のように）、と「」 （ニュースグループのように）。これらの離れがあれば、基本的なファイルシステムによって決定されたものを、ユーザーが期待するか、何の中から選択することが少しはあります。 「\」を使用する方法について考慮すべき事項の1つは、それはまた、IMAPプロトコルでの特殊文字であるということです。他の階層区切り文字の使用が許可されているものの、DESIGNERはWELLサーバは特別な目的のためにのみ意図されていない限り、このセットから1に滞在することをお勧めします。 「@」、「＆」、「＃」、そして、彼らはのように、ユーザーに驚きを認識しておく必要があり、「」、「_」、「 - 」実装者は、次のような文字を使用することについて考えるかもしれません「！」うまくURLおよびその他の外部仕様（これらの文字の一部が特別な意味を持っているので）への影響のよう。また、「\」（および、そのようなサーバーのクライアント）を使用するサーバーは、引用符で囲まれた文字列にその文字をエスケープするか、代わりにリテラルを送信するために覚えておく必要があります。リテラルは、引用符で囲まれた文字列にエスケープ文字を許可する（ただし、リテラルは許可されている場所を確認するには文法をチェック）していない古いIMAPのバージョンとの互換性を維持するために、引用符で囲まれた文字列にエスケープ文字の上に推奨されています：
C: 001 LIST "" {13}
S: + send literal
C: this\%\%\%\h*
S: * LIST () "\\" {27}
S: this\is\a\mailbox\hierarchy
S: 001 OK LIST complete
In any case, a server should not use normal alpha-numeric characters (such as "X" or "0") as delimiters; a user would be very surprised to find that "EXPENDITURES" actually represented a two-level hierarchy. And a server should not use characters that are non-printable or difficult or impossible to enter on a standard US keyboard. Control characters, box-drawing characters, and characters from non-US alphabets fit into this category. Their use presents interoperability problems that are best avoided.
いずれの場合においても、サーバは、区切り文字として（例えば、「X」または「0」のような）通常の英数字文字を使用しないでください。ユーザーは、「支出」は実際には二つのレベルの階層を表現することを見つけることは非常に驚くだろう。そして、サーバは、標準のUSキーボードに入力する印刷不能または困難または不可能な文字を使用しないでください。制御文字、ボックス描画文字、および米国以外のアルファベットからの文字がこのカテゴリーに収まります。これらの使用は最高の回避されている相互運用性の問題を提示します。
The UTF-7 encoding of mailbox names also raises questions about what to do with the hierarchy delimiters in encoded names: do we encode each hierarchy level and separate them with delimiters, or do we encode the fully qualified name, delimiters and all? The answer for IMAP is the former: encode each hierarchy level separately, and insert delimiters between. This makes it particularly important not to use as a hierarchy delimiter a character that might cause confusion with IMAP's modified UTF-7 [UTF-7 and RFC-2060] encoding.
メールボックス名のUTF-7エンコードはまた、エンコードされた名前で階層区切り文字をどうするかについての質問を提起：我々は、各階層レベルをエンコードし、区切り文字で区切り、または私達は完全修飾名、区切り文字とすべてをエンコードするんですか？ IMAPのための答えは前者である：個別に各階層レベルを符号化との間の区切り文字を挿入します。これは、階層構造デリミタとしてIMAPの修正UTF-7 [UTF-7およびRFC-2060]のエンコードと混乱を引き起こす可能性がある文字を使用しないことが特に重要となります。
To repeat: a server should use "/", "\", or "." as its hierarchy delimiter. The use of any other character is likely to cause problems and is STRONGLY DISCOURAGED.
繰り返すには：サーバーが「/」、「\」、または使用する必要があります「」その階層の区切り文字として。他の文字の使用は問題を引き起こす可能性があると強くお勧めします。
The protocol spec is very clear on the matter of what to do with ALERT response codes, and yet there are many clients that violate it so it needs to be said anyway: "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." That should be clear enough, but I'll repeat it here: Clients must present ALERT text clearly to the user.
プロトコルの仕様は、ALERT応答コードをどうするかの問題について非常に明確で、しかもそれがとにかく言われる必要があるので、それに違反した多くのクライアントがあります。「人間が読めるテキストはに提示しなければならない特別な警告が含まれていますメッセージにユーザの注意を呼び出す形でユーザー。」それは十分に明確にする必要がありますが、私はここでそれを繰り返すだろう：クライアントは、ユーザーに明確にALERTテキストを提示する必要があります。
The protocol does not guarantee that a client may delete a mailbox that is not empty, though on some servers it is permissible and is, in fact, much faster than the alternative or deleting all the messages from the client. If the client chooses to try to take advantage of this possibility it must be prepared to use the other method in the even that the more convenient one fails. Further, a client should not try to delete the mailbox that it has selected, but should first close that mailbox; some servers do not permit the deletion of the selected mailbox.
プロトコルは、クライアントがいくつかのサーバ上で、それは、実際には、多くの代替よりも速いか、クライアントからのすべてのメッセージを削除することが許容されるとあるが、空でないメールボックスを削除することを保証するものではありません。クライアントは、この可能性を利用しようとすることを選択した場合には、さらに便利いずれかに障害が発生したことで、他の方法を使用する準備をしなければなりません。さらに、クライアントは、それが選択したメールボックスを削除しようとしないはずですが、最初にそのメールボックスを閉じる必要があります。いくつかのサーバは、選択されたメールボックスの削除を許可していません。
That said, a server should permit the deletion of a non-empty mailbox; there's little reason to pass this work on to the client. Moreover, forbidding this prevents the deletion of a mailbox that for some reason can not be opened or expunged, leading to possible denial-of-service problems.
これは、サーバーが空のメールボックスの削除を許可しなければならない、と述べました。クライアントにこの作業を透過しにくい理由があります。また、これを禁止することは、何らかの理由で可能なサービス拒否の問題につながる、オープンまたは抹消することはできませんメールボックスの削除を防ぐことができます。
Example:
例：
[User tells the client to delete mailbox BANANA, which is
currently selected...]
C: 008 CLOSE
S: 008 OK done
C: 009 DELETE BANANA
S: 009 NO Delete failed; mailbox is not empty.
C: 010 SELECT BANANA
S: * ... untagged SELECT responses
S: 010 OK done
C: 011 STORE 1:* +FLAGS.SILENT \DELETED
S: 011 OK done
C: 012 CLOSE
S: 012 OK done
C: 013 DELETE BANANA
S: 013 OK done
Since the whole point of IMAP is interoperability, and since interoperability can not be tested in a vacuum, the final recommendation of this treatise is, "Test against EVERYTHING." Test your client against every server you can get an account on. Test your server with every client you can get your hands on. Many clients make limited test versions available on the Web for the downloading. Many server owners will give serious client developers guest accounts for testing. Contact them and ask. NEVER assume that because your client works with one or two servers, or because your server does fine with one or two clients, you will interoperate well in general.
IMAPの全体のポイントは相互運用性であり、および相互運用性から真空で試験することができないので、この論文の最終的な勧告は、「全てに対してテスト」です。すべてのサーバに対してクライアントをテストし、あなたは上のアカウントを取得することができます。あなたがを手に入れることができ、すべてのクライアントとサーバーをテストします。多くのクライアントがダウンロードするWeb上の限られたテストバージョンが利用できるようにします。多くのサーバーの所有者は、テストのための深刻なクライアント開発者のゲストアカウントを与えます。それらに連絡し、尋ねます。ので、あなたのクライアントは、1台のまたは2つのサーバで動作する、またはサーバーが1つのまたは2つのクライアントと罰金ないので、あなたは一般的にうまく相互運用することを前提としないでください。
In particular, in addition to everything else, be sure to test against the reference implementations: the PINE client, the University of Washington server, and the Cyrus server.
PINEクライアント、ワシントン大学のサーバー、およびCyrusサーバ：特に、他のすべてに加えて、リファレンス実装に対してテストしてください。
See the following URLs on the web for more information here:
ここでの詳細については、ウェブ上で以下のURLを参照してください。
IMAP Products and Sources: http://www.imap.org/products.html
IMC MailConnect: http://www.imc.org/imc-mailconnect
This document describes behaviour of clients and servers that use the IMAP4 protocol, and as such, has the same security considerations as described in [RFC-2060].
この文書は、IMAP4プロトコルを使用するクライアントとサーバーの動作を説明し、[RFC-2060]に記載されているようなように、同じセキュリティ上の考慮事項があります。
[RFC-2060] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 2060, December 1996.
[RFC-2060]のCrispin、M.、 "インターネットメッセージアクセスプロトコル - バージョン4rev1"、RFC 2060、1996年12月。
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC-2180] Gahrns, M., "IMAP4 Multi-Accessed Mailbox Practice", RFC 2180, July 1997.
[RFC-2180] Gahrns、M.、 "IMAP4マルチアクセスされるメールボックスの実践"、RFC 2180、1997年7月。
[UTF-8] Yergeau, F., " UTF-8, a transformation format of Unicode and ISO 10646", RFC 2044, October 1996.
[UTF-8] Yergeau、F.、 "UTF-8、UnicodeとISO 10646の変換フォーマット"、RFC 2044、1996年10月。
[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、ユニコードのメールセーフ変換形式"、RFC 2152、1997年5月。
[NAMESPACE] Gahrns, M. and C. Newman, "IMAP4 Namespace", Work in Progress.
[NAMESPACE] Gahrns、M.とC.ニューマン、 "IMAP4名前空間"、ProgressのWork。
Barry Leiba IBM T.J. Watson Research Center 30 Saw Mill River Road Hawthorne, NY 10532
バリー・レイバIBM T.J。ワトソン研究所30ソウミルリバーロードホーソーン、NY 10532
Phone: 1-914-784-7941 EMail: leiba@watson.ibm.com
電話：1-914-784-7941 Eメール：leiba@watson.ibm.com
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。