RFC2683 日本語訳
2683 IMAP4 Implementation Recommendations. B. Leiba. September 1999. (Format: TXT=56300 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group B. Leiba Request for Comments: 2683 IBM T.J. Watson Research Center Category: Informational September 1999
Leibaがコメントのために要求するワーキンググループB.をネットワークでつないでください: 2683年のIBM T.J.ワトソン研究所カテゴリ: 情報の1999年9月
IMAP4 Implementation Recommendations
IMAP4実装推薦
Status of this Memo
この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.
Copyright(C)インターネット協会(1999)。 All rights reserved。
1. Abstract
1. 要約
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]はビルクライアントにおける使用のための豊かなプロトコルと電子メールのストレージ、検索、および操作のためのサーバについて説明します。 プロトコルがとても豊かであり、とても多くの実装選択を持っているので、そのようなクライアントとサーバを設計するとき、しなければならないトレードオフと考えなければならない問題がしばしばあります。 このドキュメントは、これらの問題について概説して、最終生産物をできるだけ共同利用できるようにするように推薦状をするのを試みます。
2. Conventions used in this document
2. 本書では使用されるコンベンション
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"、“should not"、および“may"は特定の意味と共に本書では使用されます。 それらの意味がRFC2119で指定されたそれといくらか異なっているので、私たちはここですべての上限にそれらを入れません。 それらの意味は以下の通りです:
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.
必須--動作が説明したこの単語手段が、相互運用性を確実にするのに必要です。 推薦を無視するべきでない、--相互運用性に害を与えるのは動作が説明したこの句の手段がほとんど確かにならなければならないでしょう。 推薦を無視するべきではありません。
Leiba Informational [Page 1] RFC 2683 IMAP4 Implementation Recommendations September 1999
[1ページ]RFC2683IMAP4実装推薦1999年9月の情報のLeiba
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.
--動作が説明したこの単語手段は、強く推薦されて、相互運用性かユーザビリティを高めるべきです。 熟慮なしで推薦を無視するべきでない、--動作が説明したこの句の手段は、強く推薦されて、相互運用性かユーザビリティに害を与えるべきであるかもしれません。 熟慮なしで推薦を無視するべきでない、--動作が説明したこの単語手段は許容できる実装選択であるかもしれません。 どんな特定の推薦も含意されません。 この単語は、明白でないかもしれない選択を指摘するか、または既存の実装でどんな選択をしたかを作成者に知らせるのに使用されます。
3. Interoperability Issues and Recommendations
3. 相互運用性問題と推薦
3.1. Accessibility
3.1. アクセシビリティ
This section describes the issues related to access to servers and server resources. Concerns here include data sharing and maintenance of client/server connections.
このセクションはサーバとサーバリソースへのアクセスに関連する問題について説明します。 ここの関心はクライアント/サーバ接続のデータ共有とメインテナンスを含んでいます。
3.1.1. Multiple Accesses of the Same Mailbox
3.1.1. 同じメールボックスの複数のアクセス
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の1つの長所はPOP3と異なって単一のメールボックスへの複数の同時アクセスを考慮するということです。 その結果、オフィスのクライアントがまだ接されている間、ユーザはホームのクライアントからメールを読むことができます。 または、質問の同じプールをすべて見て、ヘルプデスクスタッフは同じ受信トレイからすべて働くことができます。 もっとも、この能力に関する重要なポイント、そのNO SERVER IS GUARANTEED TO SUPPORT THISはそうです。 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
1. サーバが第2SELECTを拒否するなら、あなたは優雅にSELECTコマンドの失敗を扱わなければならなくて、サーバが、オフに1番目を強制するのによる第2SELECT、3を許容するのを選ぶなら、2 合理的にあなたの接続(以下で「断ち切られたコネクションズ」を見る)の切れることを扱わなければなりません; そして4 あなたが、あなた自身のクライアント(ロードバランシングか他のそのような理由による)で同じメールボックスに複数の接続を作るのを避けなければならなくて、あなたが選択したメールボックスの上にSTATUSコマンドを使用するのを避けなければならない、(SELECTをするときいくつかのサーバ実装によって、STATUSコマンドには複数のアクセスに関する同じ問題がある。
Leiba Informational [Page 2] RFC 2683 IMAP4 Implementation Recommendations September 1999
[2ページ]RFC2683IMAP4実装推薦1999年9月の情報のLeiba
EXAMINE commands).
EXAMINEコマンド)
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がメールボックス名を取るので、それは単独操業です。 これのために、それが返す情報は必ず選択されたメールボックス状態との同期中であるというわけではありません。
3.1.2. Severed Connections
3.1.2. 断ち切られたコネクションズ
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つの理由の1つによって断ち切られるかもしれません: クライアントが接続を断ち切るか、サーバが接続を断ち切るか、または接続はクライアントとサーバのコントロールを超えて外の力によって断ち切られます(例えば、電話回線は低下します)。 クライアントとサーバはともにこれらの状況に対処しなければなりません。
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つの応答を待つのが(untagged 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
サーバが接続を断ち切りたがっているとき、方法でメール店の状態を変えた状況が起こったので、サーバがクライアントに交信できないのは、通常不活発タイムアウトのためにあるか、またはあります。 サーバはuntagged BYEを送るべきです。
Leiba Informational [Page 3] RFC 2683 IMAP4 Implementation Recommendations September 1999
[3ページ]RFC2683IMAP4実装推薦1999年9月の情報のLeiba
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]).
クライアントとその時への応答はソケットを閉じます。 切れる前にuntagged BYE応答を送ると、問題の人間読み込み可能な説明をクライアントに送るサーバ、ユーザへのディスプレイ、または両方が許容されています(.5セクション7.1[RFC-2060]を見てください)。次に、クライアントはそのクライアントを登録するかもしれません。
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のデザインは長命の、そして、(ほとんど不活発)のクライアント/サーバセッションを奨励します。デザインは、クライアントが接続して、メールを検索して、POPに関してログアウトすることです。 ユーザの数が成長するのに従って、これは多くのサーバリソースを使いきることができます、特にユーザがアクセスし終えたメールボックスのためのセッションを維持するように設計されているクライアントと共に。 これを軽減するために、サーバは不活発タイムアウトを実装するかもしれません、一方的に閉会して(最初にuntagged BYEを送った後に上で述べたように)。 サーバオペレータの中にはこれをした後にサーバ性能における劇的な改良を報告した人もいました。 [RFC-2060]で指定されるように、そのようなタイムアウトが完了しているなら、少なくとも30分の不活発までそれはあるはずがありません。 この仕様の理由は単にまた、早いタイムアウトを逸らすために送付コマンド(NOOPなどの)からサーバまで頻繁にクライアントを防ぐことです。 クライアントがそれを知っているなら、サーバは少なくとも30のためのセッションが書き留めないどんなタイムアウト、次にたとえば、25より頻繁な間隔で、投票ではなく、必要性が書き留めるクライアントもそうするかもしれません。
3.2. Scaling
3.2. スケーリング
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には、メール店が、より大きくより非常に多くなるときスケーラビリティを考慮する多くの特徴があります。 ユーザ、メールボックス、メッセージ、および多くの非常に大きいメッセージが効率的にハンドルに考える必要があります。 このドキュメントは多くのユーザにかかわる管理問題を扱わないでしょうが、私たちは他の項目を見るつもりです。
3.2.1. Flood Control
3.2.1. 治水
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に長いコマンドを送ることによってサーバをあふれさせることができるところにあります。 また、私たちはこのセクションでその問題について議論するつもりです。
Leiba Informational [Page 4] RFC 2683 IMAP4 Implementation Recommendations September 1999
[4ページ]RFC2683IMAP4実装推薦1999年9月の情報のLeiba
3.2.1.1. Listing Mailboxes
3.2.1.1. メールボックスを記載します。
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ユーザにユーズネットを提示します。 ニュースグループ、および他のそのような階層的なメールボックス構造は、非常に多数である場合がありますが、トップレベルの階層構造でほんのいくつかのエントリーを持っているかもしれません。 また、いくつかのサーバがサーバに知られずに円形の階層構造を持つことができるメール店に対して組立てられます--“a"と階層構造が終わる間、「/b/c/d」が同じファイル構造に決議するのにおいてすなわち、それは決して可能ではありません。次に、“a"は「/b/c/d/b」が「/b」と同じであることを意味するだろうです。 この場合、LIST応答は無制限になるでしょう。
Clients that will have trouble with this are those that use
この苦労をするクライアントはそれが使用するものです。
C: 001 LIST "" *
C: 001が記載する、「「*」
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:
メールボックスを決定するには、記載してください。 これのために、クライアントはそのようにリストコマンドに資格のない「*」を使用するべきではありません。 より安全なアプローチは個別にそれぞれのレベルの階層構造を記載することです、その結果、ユーザが一度に1つの手足に木を横断するのを許容して:
C: 001 LIST "" %
S: * LIST () "/" Banana
S: * LIST ...etc...
S: 001 OK done
C: 001が記載する、「「%S:」 * 「() 」 /を記載してください」というバナナS: * 記載してください…など。 S: 行われた001OK
and then
そして、その時
C: 002 LIST "" Banana/%
S: * LIST () "/" Banana/Apple
S: * LIST ...etc...
S: 002 OK done
C: 002が記載する、「「バナナ/%S:」 * 」 「リスト()」/バナナ/アップルS: * 記載してください…など。 S: 行われた002OK
Using this technique the client's user interface can give the user full flexibility without choking on the voluminous reply to "LIST *".
多量の回答のときに「*を記載する」ために窒息しないで、このテクニックを使用して、クライアントのユーザーインタフェースはユーザの完全な柔軟性を与えることができます。
Of course, it is still possible that the reply to
もちろん、それがまだ可能である、それ、答え
C: 005 LIST "" alt.fan.celebrity.%
C: 005LIST、「「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の階層構造レベルです。
Leiba Informational [Page 5] RFC 2683 IMAP4 Implementation Recommendations September 1999
[5ページ]RFC2683IMAP4実装推薦1999年9月の情報のLeiba
3.2.1.2. Fetching the List of Messages
3.2.1.2. メッセージのリストをとって来ます。
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
クライアントがメールボックスを選択するとき、カウントをそれに与えます、メールボックスの中のメッセージのuntagged EXISTS応答で。 この数は非常に大きい場合があります。 このような場合にはそれは、使用するために賢明でないかもしれません。
C: 004 FETCH 1:* ALL
C: 004フェッチ1: *すべて
to populate the user's view of the mailbox. One good method to avoid problems with this is to batch the requests, thus:
ユーザのメールボックスの視点に居住するために。 その結果、これに関する問題を避ける1つの良いメソッドがバッチへの要求です:
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...
C: 004 フェッチ1: 50 すべてのS: * 1 とって来ます。など。 S: 004 Cが行われたOK: 005 フェッチ51: 100 すべてのS: * 51 とって来ます。など。 S: 005 Cが行われたOK: 006 フェッチ101: 150 すべて…など。
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本体[1]」などの別のコマンドを挿入できます、そして、クライアントはフェッチ回答の嵐でサーバへのアクセスを妨げさせないでしょう。 (1番目次に、その前の50などをLAST50メッセージにとって来るためにそのようなメソッドを逆にすることができました。)
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番目で見えない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...
C: 003 受信トレイSを選択してください: * 10000が存在している、S: * 80、最近のS: * 旗(\に答えた\は見られた\削除された\草稿\に旗を揚げさせた)のS: * OK[UIDVALIDITY824708485]UID正当性状態S: * 最初の見えないメッセージSを承認してください[UNSEEN9921]: 003 OK[READ-WRITE]SELECTはCを完成しました: 004 FETCH9921: *すべて…、など。
If the server does not return an OK [UNSEEN] response, the client may use SEARCH UNSEEN to obtain that value.
サーバがOK[UNSEEN]応答を返さないなら、クライアントは、その値を得るのにSEARCH UNSEENを使用するかもしれません。
Leiba Informational [Page 6] RFC 2683 IMAP4 Implementation Recommendations September 1999
[6ページ]RFC2683IMAP4実装推薦1999年9月の情報のLeiba
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拡張子を欠いている)、クライアントはすべてのメッセージ記述子を検索しなければならないでしょう。 このサービスを提供するクライアントは、デフォルトでそれをするべきでなくて、大きいメールボックスのためのこのオプションを選ぶコストについてユーザに知らせるべきです。
3.2.1.3. Fetching a Large Body Part
3.2.1.3. かなりの身体の部分をとって来ます。
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応答では、クライアントはそれがとって来るのを計画している身体の部分のバイトで表現されるサイズを知っています。 これが70MBのビデオクリップであると仮定してください。 クライアントは身体の部分をばらばらに検索するのに部分的なフェッチを使用できます、サーバから戻る無停止の70MBのリテラルの問題を避けて:
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...
C: 022 フェッチ3ボディー[1]<0.20000>S: * 3フェッチ((見られた\)ボディー[1]<0>20000S: …データに…旗を揚げさせます) S: 022 Cが行われたOK: 023 フェッチ3ボディー[1]<20001.20000>S: * 3フェッチ(ボディー[1]<20001>20000S: …データ…) S: 023 Cが行われたOK: 024 3本体[1]<40001.20000>をとって来てください…など。
3.2.1.4. BODYSTRUCTURE vs. Entire Messages
3.2.1.4. BODYSTRUCTURE対全体のメッセージ
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.
FETCH BODYSTRUCTUREが身体の部分の数を測定するのに必要であるので、その結果、メッセージに「付属」があるか否かに関係なく、クライアントは彼らのユーザのメールボックスの視点に居住する正常なメソッドとしてしばしばFETCH FULLを使用します。 利益はクライアントが正常なメッセージ概要に伴う紙クリップのアイコンかそのような何らかの指示を表示できるということです。 しかしながら、これはいくつかのサーバ構成と共に多大な費用で来ます。 FETCH ENVELOPEに必要であるそれと比べて、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
クライアントの中には全体のメッセージを検索するのに、FETCH BODYSTRUCTUREを使用するよりむしろ、FETCH BODY[](または、同等なFETCH RFC822)を使用する人もいます。 そして、彼らはクライアントでMIME構文解析をします。 そしてこれがいくつかの領域でわずかに多くの柔軟性をクライアントに与えるかもしれない、(例えば、BODYSTRUCTUREで返されないヘッダーフィールドへのアクセス。
Leiba Informational [Page 7] RFC 2683 IMAP4 Implementation Recommendations September 1999
[7ページ]RFC2683IMAP4実装推薦1999年9月の情報のLeiba
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応答)、ユーザがそれらのいくつかを見るだけでありたいかもしれないときすべての身体の部分の転送を強制することによって、厳しい性能問題を引き起こす場合があります--後でテキストだけを読んで、保存する添付の大きいZIPファイルでモデムによってログオンされて、小さいテキストメッセージを読むとZIPファイルが好まれるかもしれないユーザ したがって、クライアントは、通常、全体のメッセージを検索するはずがなくて、選択的にメッセージ身体の部分を検索するべきです。
3.2.1.5. Long Command Lines
3.2.1.5. 長いコマンドライン
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.
クライアントは、結局、サーバから情報を要求することに関して効率的になろうとするように取り組みにおける非常に長いコマンドラインを造ることができます。クライアントが、選択されたメッセージからメッセージセットを造って、隣接のブロックのメッセージが範囲のグループであるかもしれないと認めないとき、これは通常起こることができます。 ユーザが大きいメールボックスと次に、unselectsメッセージ287のすべての1万のメッセージを選択すると仮定してください。 クライアントが「1:28万6288:10000」としてそのメッセージセットを造ることができましたが、それを扱わないクライアントが個別に各メッセージを列挙して、建てようとするかもしれない、「1 2 3 4 [など]、9999、10000インチ。 とって来コマンドにそれを追加すると、長い間およそ4万9000の八重奏であるコマンドラインはもたらされます、そして、明確に、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応答を送るべきです。
3.2.2. Subscriptions
3.2.2. 購読
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
クライアントは水につかるようになることができる唯一の実体ではありません: また、エンドユーザは何らかの治水を必要とするかもしれません。 IMAP4プロトコルはそのようなコントロールを購読の形に供給します。 ほとんどのサーバがサポートする、登録、登録削除、LSUBは命令して、多くのユーザが、通常、それらが見たがっているものに加入することによって利用可能なメールボックスの大きいリストを限定するのを選びます。 これが念頭にある場合、クライアントは申し込まれたメールボックスだけを見る方法をユーザに与えるべきです。 LSUBコマンドを決して使用しないクライアントは重要なユーザビリティ機能をユーザから取り除きます。 もちろん、クライアントは完全にLISTコマンドを隠したがっているというわけではないでしょう。 道を持っているユーザの必要性
Leiba Informational [Page 8] RFC 2683 IMAP4 Implementation Recommendations September 1999
[8ページ]RFC2683IMAP4実装推薦1999年9月の情報のLeiba
choose between LIST and LSUB. The usual way to do this is to provide a setting like "show which mailboxes?: [] all [] subscribed only".
LISTとLSUBを選んでください。 これをする普通の方法がセットしている同類を提供することである、「どのメールボックスを見せているか、:、」 「すべての[]が申し込んだ[]専用。」
3.2.3. Searching
3.2.3. 探すこと
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 SEARCHコマンドはメールボックスで特に厄介になることができます(すなわち、遅くなります)。 それで、バランスよくそのことについてはいくつかのことを述べましょう。
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).
旗の検索は速いはずです。 旗の検索([国連]SEEN、[国連]ANSWERED、[国連]DELETED、[国連]DRAFT、[国連]FLAGGED、NEW、OLD、RECENT)はクライアントの自己の使用(例えば、メッセージを梢消する前にユーザに警告するために見えないメールを見つけて、「削除されていた状態で、探す」ために「検索見えない」何らかのクライアント使用)にクライアントによって使用されるのが知られています。
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]をサポートするべきです。
Leiba Informational [Page 9] RFC 2683 IMAP4 Implementation Recommendations September 1999
[9ページ]RFC2683IMAP4実装推薦1999年9月の情報のLeiba
3.3 Avoiding Invalid Requests
3.3 無効の要求を避けること。
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はサーバがあらかじめ何があるかをクライアントに言う方法を提供して、いくつかの事情で受入れられません。 クライアントはよくたくらみがあるクライアントが無効であることを知っている要求を送るのを避けるこれらの特徴を使用するべきです。 このセクションはさらに詳細にこれについて説明します。
3.3.1. The CAPABILITY Command
3.3.1. 能力コマンド
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のどんなバージョンとどんなオプション機能をサポートするかを決定するCAPABILITYコマンドを使用するべきです。 クライアントはCAPABILITY応答でどんなadvertize IMAP4rev1もしないサーバにIMAP4rev1コマンドと議論を送るべきではありません。 同様に、クライアントはもうIMAP4rev1にCAPABILITY応答でどんなadvertize IMAP4もしないサーバに存在しないコマンドをIMAP4に送るべきではありません。 IMAP4rev1サーバは、時代遅れのIMAP4かIMAP2bisがコマンドであるとサポートするのに必要ではありません(いくつかですが、してください; そのようなコマンドをIMAP4rev1サーバに送るのが有効であると思うのにこの事実に和らげさせないでください)。
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のために調べるコマンドを送るべきではありません。 すべての規格と標準化過程拡大はそれらの「前-感覚」を示すCAPABILITYトークンを含んでいます。 すべての個人的で実験的な拡大が同じようにするべきです、そして、彼らを利用するクライアントは彼らが使用されるかもしれないかどうか決定するのにCAPABILITY応答を使用するべきです。
3.3.2. Don't Do What the Server Says You Can't
3.3.2. サーバが言うことをしないでください、あなたはそうすることができません。
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旗が設定した\を持っているメールボックスをSELECTに試さないでください。 * Noinferiors旗が設定した\を持っているメールボックスの中にサブメールボックスをCREATEに試さないでください。 * サーバが[TRYCREATE]応答コードで反応しないなら目標メールボックスをCREATEに試すことによって、失敗COPYかAPPENDコマンドに応じないでください。 * [READ唯一]の応答コードで選択されたメールボックスを梢消しようとしないでください。
Leiba Informational [Page 10] RFC 2683 IMAP4 Implementation Recommendations September 1999
[10ページ]RFC2683IMAP4実装推薦1999年9月の情報のLeiba
3.4. Miscellaneous Protocol Considerations
3.4. 種々雑多なプロトコル問題
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実装における重要な相互運用性問題を引き起こしました。 ある一般的な項目はあらゆるimplementerは気付くのが確かであるべきであるということです、そして、分かるには、2.2に.2と序文をIMAP4rev1仕様[RFC-2060]のセクション7に区分してください。
3.4.1. Well Formed Protocol
3.4.1. 整形式のプロトコル
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.
私たちは厳密にプロトコル文法を固く守る重要性を十分強調できません。プロトコルの仕様は全く堅いです。 なにも求められないなら「読み易さ」のためにスペースを挿入できると仮定しないでください。 プロトコル誤りがあればダウンするパーサがむこうにあるのを覚えておいてください。 あらゆるパーサげっぷをユーザに報告するクライアントがいます。 そして、どのような場合でも、分析できない情報は無くなっている情報です。 プロトコル世代では、注意してください。 そして、以下の「テストに関するWord」を見てください。
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日付ストリングでないことに注意してください--ENVELOPE応答における最初のストリングと同じ形式にはすなわち、それがありません。 ほとんどのクライアントがINTERNALDATE応答でRFC-822日付ストリングを事実上受け入れるので、あなたの相互運用性テストでこれを逃すのは簡単です。 しかし、クライアントに関する問題を引き起こすので、この分野に正しいストリングを必ず生成してください。
3.4.2. Special Characters
3.4.2. 特殊文字
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
C: 001が記載する、「「%S:」 * ()を記載してください、「「受信トレイS:」 * 「() 」 \\を記載してください」というテストS: * 「() 」 \\を記載してください」という12、S: 「My」のメールボックスS: 001 Cが行われたOK: 002LIST、「「「\、」 私の\、」 メールボックス\\%、」 S: * 「() 」 \\を記載してください」という17、S: 「My」のメールボックス\くず
Leiba Informational [Page 11] RFC 2683 IMAP4 Implementation Recommendations September 1999
[11ページ]RFC2683IMAP4実装推薦1999年9月の情報のLeiba
S: 002 OK done
S: 行われた002OK
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ビットのキャラクタをここに入れるのを許可しなければならなくて、彼らを通過しなければなりません、変わりがありません、サーバ(必要であるときに、リテラルとして彼らを送るのに慎重である)に。 特に、いくつかのサーバ構成がユーザ名に"@"を使用します、そして、何人かのクライアントはそのキャラクタが入られるのを許可しません。 これは厳しい相互運用性問題を生じさせます。
3.4.3. UIDs and UIDVALIDITY
3.4.3. UIDsとUIDVALIDITY
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.
存在が逆終わりのメール店であるとサポートするサーバはしばしばメッセージのためにUIDsを取っておくどんな良い場所も持っているというわけではありません。 しばしば、既存のメール店はIMAPが持っている意味でUIDsの概念を持つというわけではないでしょう: 決して厳密に増加して、再発行されないで、また32ビットでない整数。 いくつかのサーバがエンドユーザにとって開かれている場所にUIDsを保存することによって、これを解決します、ユーザが彼らを削除する可能性を考慮して。 他のものは、メールボックスが選択されるときはいつも、UIDsを再選任することによって、それを解決します。
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
維持できるなら、サーバは永久に、すべてのメッセージのためにUIDsを維持するべきです。 それが可能でないなら、UIDsのどれかが無効になったかもしれないときはいつも、サーバはメールボックスのためにUIDVALIDITY値を変えなければなりません。 クライアントは、UIDVALIDITYが変化したと認めなければならなくて、彼らがそのメールボックスの中にUIDsに関して節約したとその状態にどんな情報も無駄にすることによって、応答しなければなりません。 クライアントがこれをしていないとき、多くの問題がこの領域にありました。 クライアントであるときに、メールの損失をもたらす、削除
Leiba Informational [Page 12] RFC 2683 IMAP4 Implementation Recommendations September 1999
[12ページ]RFC2683IMAP4実装推薦1999年9月の情報のLeiba
wrong piece of mail by using a stale 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ビットの識別子をサーバに形成すること」が、一般的な誤解であるように思えます。 これは絶対にNOT TRUEです。 2個のメールボックスのUIDVALIDITY値が異なっているという保証が全くないので、UIDVALIDITYはメールボックスを決して特定しません。 それがキャッシュしたUIDsの正当性をチェックする方法をクライアントに与えるために、名前が示すようにUIDVALIDITYの唯一の目的があります。 メッセージのための64ビットの識別子を作るためにこれらの値をまとめるのが、有効な実装選択ですが、UIDsがメールボックスの間でユニークでないという重要な概念がここにあります。 メールボックスを考えて、それらはユニークなWITHIN aであるだけです。
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.
いくつかのサーバ実装が、UIDsを全体のサーバの向こう側にユニークにするのを試みました。これは勧められないです、不必要にUIDsの寿命を制限するので。 UIDは32ビットの数であり、それがサーバの向こう側にグローバルであるなら、合理的に有限な時間の後になくなるでしょう。1個のメールボックスの中にUIDsを連続して割り当てると、あなたは、あなたがいつかそのメールボックスの中に2**32異なったメッセージを持つまで彼らを再使用し始める必要はないでしょう。 グローバルな場合では、いつか全体のメール店にいったん2**32異なったメッセージを持っていると、あなたはそれらを再利用しなければならないでしょう。 サーバでおよそ8000人のユーザを登録する(2**13)と仮定してください。 それは1ユーザあたりの平均2**19UIDsに与えます。 各ユーザが1日あたり32のメッセージ(2**5)を得ると仮定してください。 あなたがなくなる14日(およそ45何16000+日もの=年)前にそれは2**をあなたに与えます。 それは十分のように見えるかもしれませんが、用法をほんの少し(多くのスパム、多くのメーリングリスト購読、より多くのユーザ)掛けてください。そうすれば、あなたはあまりに自分を制限します。
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.
あなたがUIDsを包装しなければならないなら、より悪いことはそれです、そして、その結果、メールボックスの中にUIDVALIDITYを変えて、UIDsを無効にしなければなりません、そして、あなたはEVERYメールボックスのためにシステムでそれをしなければなりません、彼らが皆、同じUIDプールを共有するので。 あなたが1メールボックスあたりのUIDsを割り当てて、問題がありましたら、あなたはその1個のメールボックスのためにUIDsを殺すだけでよいです。
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:
極端な状況(これが極端である、本当に)で、メールボックスがクライアントで使用中である間、サーバはUIDsを無効にしなければならないかもしれません--すなわち、クライアントがアクティブなメールボックスの中に知っているUIDsはもう有効ではありません。 その場合、サーバは、すぐに、UIDVALIDITYを変えなければならなくて、これをクライアントに伝えなければなりません。 サーバは、同じフォームの求められていないUIDVALIDITYメッセージを送ることによって、SELECTコマンドに対応してこれをするかもしれません。 そして、クライアントがそのようなメッセージを扱う用意ができていなければならない、ことによるとプロセスのコマンドのコインシデンス失敗。 例えば:
Leiba Informational [Page 13] RFC 2683 IMAP4 Implementation Recommendations September 1999
[13ページ]RFC2683IMAP4実装推薦1999年9月の情報のLeiba
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...
C: UIDが382+Flags.silent円保存する032はSを削除しました: * OK[UIDVALIDITY12345]の新しいUIDVALIDITY値! S: UIDVALIDITYが変化したのでNO UIDコマンドが拒絶した032! C: ...ローカルの情報と再フェッチを無効にします… C: 033 1をとって来てください: *UID…など。
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.
このドキュメントの書くこと時点で、これをするのが知られている唯一のサーバが以下の条件だけのもとでそうします: クライアントは受信トレイを選択しますが、作成された物理的な受信トレイファイルがまだありません。 それにもかかわらず、1の一時的なUIDVALIDITYと共に人影のない受信トレイをエクスポートして、SELECTは成功します。 受信トレイが選択されたままで残っている間、メールはユーザに提供されます(それは1でなくなるようにありそうです)。(そのユーザは、実際の受信トレイファイルを作成して、永久的なUIDVALIDITYを割り当てます)。 UIDVALIDITYにもかかわらず、メッセージが全くなかったとき、サーバは以前、変化を報告して、したがって、どんなUIDsも実際に変化していなくて、クライアントがしなければならないのは、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はサーバであるに違いありませんが、この不測の事態を扱うように準備されて、将来のexistanceを予期します。
3.4.4. FETCH Responses
3.4.4. 応答をとって来てください。
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
C: 001 フェッチ1UIDはINTERNALDATE Sに旗を揚げさせます: * 5は(旗(削除された\))にSをとって来ます: * 「1つのフェッチ、(INTERNALDATEに旗を揚げさせる、(見られた\)」 … 」 UID345)S: 行われた001OK
(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のための旗のアップデートを返しました。(メッセージはクライアントの要求の一部ではありませんでした)。)
Leiba Informational [Page 14] RFC 2683 IMAP4 Implementation Recommendations September 1999
[14ページ]RFC2683IMAP4実装推薦1999年9月の情報のLeiba
C: 002 FETCH 2 UID FLAGS INTERNALDATE
S: * 2 FETCH (INTERNALDATE "...")
S: * 2 FETCH (UID 399)
S: * 2 FETCH (FLAGS ())
S: 002 OK done
C: 002 フェッチ2UIDはINTERNALDATE Sに旗を揚げさせます: * 「2がとって来る、(INTERNALDATE、」 …、」、)、S: * 2 (UID399)Sをとって来てください: * 2がとって来る、(旗の())S: 行われた002OK
(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
C: 003 フェッチ2ボディー[1]S: * 2フェッチ(旗(見られた\)のボディー[1]14S: こんにちは、世界! S: ) S: 行われた003OK
(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応答はサーバによって加えられました、サーバが部分で設定したボディーにSeenが旗を揚げさせる\をとって来て以来。)
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]を見てください)。
3.4.5. RFC822.SIZE
3.4.5. RFC822.SIZE
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.
これがそうであるときに、いくつかのサーバが、正確にそれを計算するよりむしろサイズを見積もっているのを選びました。 そのような見積りは、クライアントが大体のサイズをユーザに表示して、治水問題(q.v.)に見積りを使用するのを許容しますが、クライアントがバッファの配分などのものにサイズを使用しないのを必要とします、それらのバッファがその時実際のMIMEストリームを保持できないくらい小さいかもしれないので。 代わりに、クライアントはあなたがデータをとって来るときリテラルで戻ったサイズを使用するべきです。
Leiba Informational [Page 15] RFC 2683 IMAP4 Implementation Recommendations September 1999
[15ページ]RFC2683IMAP4実装推薦1999年9月の情報のLeiba
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値がEXACTであることを必要とします。 サイズを見積もるのは、プロトコル違反です、そして、サーバデザイナーはそれらが見積りを使用する際にわかるかもしれない性能貯蓄にもかかわらず、この習慣が何人かのクライアントによっていろいろ失敗されるのを意識しているに違いありません。 できれば、サーバは、特定のメッセージのために一度RFC822.SIZEを計算して、次に、後の検索のためにそれを貯蓄するべきです。 それが可能でないなら、サーバは毎回、まさに値を計算しなければなりません。 不正確な見積りは何人かのクライアントに関する厳しい相互運用性問題を引き起こします。
3.4.6. Expunged Messages
3.4.6. 梢消されたメッセージ
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.
サーバが同じメールボックスに複数の接続を許すなら、1人のクライアントで別のクライアントに知られずに梢消されるべきメッセージに、しばしば可能です。 サーバが、これらに関するクライアントがFETCHコマンドに対応してメッセージを梢消したと言うことができないので、サーバはどう梢消されたメッセージの情報を返すかに関する問題に対処しなければならないかもしれません。 この問題についての大規模な議論がありました、そして、その議論の結果は[RFC-2180]にまとめられます。 詳説と推薦のその参照を見てください。
3.4.7. The Namespace Issue
3.4.7. 名前空間問題
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:
たった今、名前空間はIMAP4実装で非常に泥々の領域(水を少しきれいにするという提案に関して[NAMESPACE]を見る)です。 問題が解決されるまで、クライアント開発者が分かる重要なものはいくつかのサーバがIMAPを通してまさしくユーザの個人的なメールボックス以上にアクセスを提供するということです、そして、事実上、ユーザの個人的なメールボックスはユーザのデフォルト階層構造におけるどこかに「隠されるかもしれません」。 したがって、クライアントはユーザがメールボックスにアクセスするとき、使用されるために接頭語を指定できる設定を提供するべきです。 例えば、そして、「ユーザのメールボックスがすべて」 ~/mail/にある」なら、ユーザはそのストリングを接頭語に入れることができます。 次に、クライアントはどんな名前パターンの接頭語もLISTとLSUBコマンドに入れるでしょう:
C: 001 LIST "" ~/mail/%
C: 001が記載する、「「~/mail/%」
(See also "Reference Names in the LIST Command" below.)
(また、以下の「リストコマンドにおける参照名」を見てください。)
3.4.8. Creating Special-Use Mailboxes
3.4.8. 特別な使用メールボックスを作成します。
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
初めに、これが名前空間問題の一部であるように思えるかもしれません。 それは、なくて、間接的にそれに関連するだけです。 多くのクライアントが、特定の名前で特別な使用メールボックスを作成するのが好きです。 最も一般的に、メッセージ削除の「ごみ箱フォルダ」モデルをもっているクライアントは名前「くず」か「削除されたこと」でメールボックスを作成したがっています。 いくつか
Leiba Informational [Page 16] RFC 2683 IMAP4 Implementation Recommendations September 1999
[16ページ]RFC2683IMAP4実装推薦1999年9月の情報のLeiba
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.
さらに、クライアント開発者はどんな特別な使用メールボックスのためにも名前を選択するためにユーザに便利な道で備えるべきです、ユーザがすべてのクライアントの同じくらいが使用したこれらの名前を作って、ユーザが彼らが欲しいところに彼らを置くのを許容して。
3.4.9. Reference Names in the LIST Command
3.4.9. リストコマンドにおける参照名
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:
クライアントとサーバの両方の多くのimplementersが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"]
>cd/u/中毒/くずの>viバナナ[ファイルは"/u/jones/junk/banana"である]>viもの/バナナ[ファイルは"/u/jones/junk/stuff/banana"である]>vi/etc/hosts[ファイルは"/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ファイルシステムの上で組立てられますが、多くの他のものが組立てられるというわけではありません、そして、ファイルシステム意味論はそれらの構成で理解できません。 2番目に、いくつかのIMAPサーバが基本的なファイルシステムをクライアントに暴露している間、他のものはユーザの個人的なメールボックスだけ、または、ある他の限られたセットのファイルへのアクセスを許します、そのようなファイルシステムのような意味論をより重要でなくして。 3番目に、IMAP仕様が参照名の解釈を過去に同じくらい「実装同じくらい依存していた」状態でおくので、様々なサーバ実装は広大に異なった方法でそれを扱いました。
Leiba Informational [Page 17] RFC 2683 IMAP4 Implementation Recommendations September 1999
[17ページ]RFC2683IMAP4実装推薦1999年9月の情報のLeiba
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.
サーバ実装はできるだけ密接に意図している「変化ディレクトリ」操作に合っている方法で参照議論を実装しなければなりません。 最小の実装として、参照議論はメールボックス名にprependedされるかもしれません(二重デリミタ; 次のパラグラフを見るのを抑圧している間)。 現在の階層構造(以下の「脱走施設」を見る)から抜け出す方法を提供しないサーバさえ参照議論の妥当な実装を提供しなければなりません、ここで説明されるように、彼らがそれを使用するクライアントと共に共同利用するように。
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:
メールボックス名に参照議論をprependするサーバ実装は、階層構造デリミタをそれらの間に挿入するべきであり、1つが既に存在しているなら、1秒は挿入してはいけません:
C: A001 LIST ABC DEF
S: * LIST () "/" ABC/DEF <=== should do this
S: A001 OK done
C: A001はABCのクールなSを記載します: * 」 「リスト()」/ABC/クールな<。=== このSをするべきです: 行われたA001 OK
C: A002 LIST ABC/ /DEF
S: * LIST () "/" ABC//DEF <=== must not do this
S: A002 OK done
C: A002はABC//クールなSを記載します: * 」 「リスト()」/ABC//クールな<。=== この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つが既に存在していないならメールボックスへの参照議論が他のものである間、階層構造デリミタを挿入しないで命名するいくらかのサーバprependが階層構造デリミタを挿入するからです。 デリミタを入れるクライアントは両方のバラエティーのサーバで働くでしょう。
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
脱走施設を実装するクライアント実装で、ユーザは、メールボックス議論のときに主な階層構造デリミタを使用するかどうかを選ぶことができるべきです。 これは主なメールボックス階層構造デリミタの取り扱いがまた、いくつかのケースをサーバによって変えて、異なるさえ同じサーバInでmailstoresするからです、と主な階層構造デリミタが意味する、「破棄、」
Leiba Informational [Page 18] RFC 2683 IMAP4 Implementation Recommendations September 1999
[18ページ]RFC2683IMAP4実装推薦1999年9月の情報のLeiba
reference argument" (implementing the intended breakout facility), thus:
その結果、「参照議論」(意図している脱走施設を実装する)、:
C: A001 LIST ABC/ /DEF
S: * LIST () "/" /DEF
S: A001 OK done
C: A001はABC//クールなSを記載します: * 「() 」 /を記載してください」という/クールなS: 行われたA001 OK
In other cases, however, the two are catenated and the extra hierarchy delimiter is discarded, thus:
しかしながら、他の場合では、2はcatenatedされます、そして、付加的な階層構造デリミタはこのようにして捨てられます:
C: A001 LIST ABC/ /DEF
S: * LIST () "/" ABC/DEF
S: A001 OK done
C: A001はABC//クールなSを記載します: * 「() 」 /を記載してください」というABC/クールなS: 行われたA001 OK
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.
クライアント実装は、サーバが脱走施設をサポートすると仮定してはいけませんが、それが利用可能であるなら、ユーザが1つを使用する方法を提供するかもしれません。 どんな脱走施設もユーザーインタフェースにエクスポートされるべきです。 他の「脱走」キャラクタが階層構造デリミタ以外にあるかもしれなくて(例えば、UNIXファイルシステムサーバはまた、主な「~」を使用しそうです)、彼らの解釈がサーバ依存していることに注意してください。
3.4.10. Mailbox Hierarchy Delimiters
3.4.10. メールボックス階層構造デリミタ
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
いくつかのインタフェースが、階層構造デリミタをユーザに示しているか、またはユーザがそれらを含む適切なメールボックス名を入れるのを許可するので、サーバ実装は一般に、ユーザが名前を分離符とみなすと予想するデリミタキャラクタを使用するべきです。 そして、「これに使用される中で最も一般的なキャラクタはそうです」という/、」 (unixファイル名のように)、「\」(OS/2とWindowsファイル名のように)、」、」 (ニュース・グループのように。) そこでは、ユーザが予想するかもしれないことか基本的なファイルシステムによって書き取られることは別として、少しがこのうちもしあれば選ぶことになっています。 「\」を使用することに関する1つの考慮はまた、それがIMAPプロトコルの特殊文字であるということです。 サーバが特別な目的だけのために意図しない場合、他の階層構造デリミタキャラクタの使用は許されているA DESIGNER IS WELL ADVISED TO STAY WITH ONE FROM THIS SETですが。 「Implementersは、"_"と「-」などのキャラクタを使用するのを考えているかもしれない」;、」、“&"、「#」、"@"、および“!"、彼らだけがユーザにとっての驚きとURLと他の外部仕様への効果を意識しているべきです(これらの何人かのキャラクタがそこに特別な意味を持っているので)。 aも
Leiba Informational [Page 19] RFC 2683 IMAP4 Implementation Recommendations September 1999
[19ページ]RFC2683IMAP4実装推薦1999年9月の情報のLeiba
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):
引用文字列でそのキャラクタから逃げなければならないか、または「\」(そして、そのようなサーバのクライアント)を使用するサーバは代わりに忘れずにリテラルを送らなければなりません。 リテラルは引用文字列に逃げられたキャラクタを許容しなかったより古い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
C: 001が記載する、「「13、S:、」 +はリテラルCを送ります: この\%\、%、\%、\h*S: * 「() 」 \\を記載してください」という27、S: この\は\a\メールボックス\階層構造Sです: OK LISTが完成する001
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インチ)、デリミタ、」、。 ユーザは「費用」が実際に2レベルの階層構造を表したのがわかるのに非常に驚いているでしょう。 そして、サーバは標準の米国キーボードに入るのが非印刷可能であるか難しいかどうしようもないキャラクタを使用するべきではありません。 制御文字、箱図面キャラクタ、および非米国アルファベットからのキャラクタはこのカテゴリに収まります。 彼らの使用は最も良い避ける相互運用性問題を提示します。
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.
繰り返すために: または、「サーバは」 /を使用するべきである」「\」、」 . 」 階層構造デリミタとして。 いかなる他のキャラクタの使用も、問題を起こしそうであって、STRONGLY DISCOURAGEDです。
3.4.11. ALERT Response Codes
3.4.11. 注意深い応答コード
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に提示しなければなりません。
Leiba Informational [Page 20] RFC 2683 IMAP4 Implementation Recommendations September 1999
[20ページ]RFC2683IMAP4実装推薦1999年9月の情報のLeiba
3.4.12. Deleting Mailboxes
3.4.12. メールボックスを削除します。
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
[ユーザは、メールボックスBANANAを削除するようにクライアントに言います…。]BANANAは現在、選択されます。 C: 008はSを閉じます: 008 Cが行われたOK: 009 バナナSを削除してください: 009 どんなDeleteも失敗しませんでした。 メールボックスは空ではありません。 C: 010 バナナSを選択してください: * …untagged SELECT応答S: 010 Cが行われたOK: 011 1を保存してください: *+FLAGS.SILENT\はSを削除しました: 011 Cが行われたOK: 012はSを閉じます: 012 Cが行われたOK: 013 バナナSを削除してください: 行われた013OK
3.5. A Word About Testing
3.5. テストに関するWord
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
IMAPの全体の先が相互運用性であり、真空で相互運用性はテストできないので、この論文の最終勧告は「すべてに対してテストしてください」ということです。 あなたがアカウントを得ることができるあらゆるサーバに対してクライアントをテストしてください。 あなたが捕まえることができるすべてのクライアントと共にサーバを検査してください。 多くのクライアントが限られたテストをウェブでダウンロードに利用可能なバージョンにします。 多くのサーバ所有者がテストするための重大なクライアント開発者ゲスト説明をするでしょう。 それらに連絡してください、そして、尋ねてください。 あなたのクライアントが1か2つのサーバで働いているか、またはあなたのサーバが1か2人のクライアントと共に調子がよいのでよく共同利用すると決して仮定しないでください。
Leiba Informational [Page 21] RFC 2683 IMAP4 Implementation Recommendations September 1999
[21ページ]RFC2683IMAP4実装推薦1999年9月の情報のLeiba
in general.
一般に。
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クライアント、ワシントン大学サーバ、およびサイラスサーバ。
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
IMAP製品とソース: http://www.imap.org/products.html IMC MailConnect: http://www.imc.org/imc-mailconnect
4. Security Considerations
4. セキュリティ問題
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]の説明されるのと同じセキュリティ問題を持っています。
5. References
5. 参照
[RFC-2060] Crispin, M., "Internet Message Access Protocol - Version
4rev1", RFC 2060, December 1996.
[RFC-2060] クリスピン、M.、「バージョン4rev1"、RFC2060、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.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC-2180] Gahrns, M., "IMAP4 Multi-Accessed Mailbox Practice", RFC
2180, July 1997.
[RFC-2180] Gahrns、M.、「マルチアクセスされたメールボックスが練習するIMAP4」、RFC2180、1997年7月。
[UTF-8] Yergeau, F., " UTF-8, a transformation format of Unicode
and ISO 10646", RFC 2044, October 1996.
[UTF-8]Yergeau、1996年10月のF.、「UTF-8、ユニコードとISO10646の変換形式」RFC2044。
[UTF-7] Goldsmith, D. and M. Davis, "UTF-7, a Mail-Safe
Transformation Format of Unicode", RFC 2152, May 1997.
[UTF-7]ゴールドスミス(D.とM.デイヴィス、「UTF-7、ユニコードのメール安全な変換形式」RFC2152)は、1997がそうするかもしれません。
[NAMESPACE] Gahrns, M. and C. Newman, "IMAP4 Namespace", Work in
Progress.
[名前空間] 「IMAP4名前空間」というGahrns、M.、およびC.ニューマンは進行中で働いています。
6. Author's Address
6. 作者のアドレス
Barry Leiba IBM T.J. Watson Research Center 30 Saw Mill River Road Hawthorne, NY 10532
バリーLeiba IBM T.J.ワトソン研究所30の製材機械の川のRoadホーソーン、ニューヨーク 10532
Phone: 1-914-784-7941 EMail: leiba@watson.ibm.com
以下に電話をしてください。 1-914-784-7941 メールしてください: leiba@watson.ibm.com
Leiba Informational [Page 22] RFC 2683 IMAP4 Implementation Recommendations September 1999
[22ページ]RFC2683IMAP4実装推薦1999年9月の情報のLeiba
7. Full Copyright Statement
7. 完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
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機能のための基金は現在、インターネット協会によって提供されます。
Leiba Informational [Page 23]
Leiba情報です。[23ページ]
一覧
スポンサーリンク
