RFC1203 日本語訳
1203 Interactive Mail Access Protocol: Version 3. J. Rice. February 1991. (Format: TXT=123325 bytes) (Obsoletes RFC1064) (Status: HISTORIC)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Rice Request for Comments: 1203 Stanford Obsoletes: RFC 1064 February 1991
コメントを求めるワーキンググループJ.ライス要求をネットワークでつないでください: 1203 スタンフォードは以下を時代遅れにします。 RFC1064 1991年2月
INTERACTIVE MAIL ACCESS PROTOCOL - VERSION 3
対話的なメールアクセス・プロトコル--バージョン3
Status of this Memo
このMemoの状態
This RFC suggests a method for workstations to access mail
dynamically from a mailbox server ("repository"). This RFC specifies
a standard for the SUMEX-AIM community and an Experimental Protocol
for the Internet community. Discussion and suggestions for
improvement are requested. Please refer to the current edition of
the "IAB Official Protocol Standards" for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
このRFCはワークステーションがメールボックスサーバ(「倉庫」)からメールにダイナミックにアクセスするメソッドを勧めます。 このRFCはSUMEX-AIM社会とExperimentalプロトコルの規格をインターネットコミュニティに指定します。 議論と改善提案は要求されています。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。
Scope
範囲
The following document is a modified version of RFC 1064, the definition of the IMAP2 protocol. This RFC has been written specifically as a counter proposal to RFC 1176, which itself proposes modifications to IMAP2. Sadly, RFC 1176 was made without internal consultation with the IMAP community, so we are in a position of feeling we have to present a counter proposal to what, if we do not act, will become a de facto standard. The reasons for this counter proposal are numerous but fall mostly into the following categories:
以下のドキュメントはRFC1064の変更されたバージョン、IMAP2プロトコルの定義です。 このRFCは特に対案としてRFC1176に書かれています。(RFC自身はIMAP2への変更を提案します)。 悲しげに、RFC1176がIMAP共同体との内部の相談なしで作られたので、私たちは私たちが私たちが行動しないならデファクトスタンダードになることに対案を提示しなければならないと感じる位置にいます。 この対案の理由は、多数ですが、ほとんど以下のカテゴリになります:
- IMAP2 is insufficiently powerful for a number of server/client
interactions which we believe to be important. RFC 1176
negligibly enhances the functionality of IMAP2.
- 私たちが重要であると信じている多くのサーバ/クライアントとの対話には、IMAP2は不十分に強力です。 RFC1176はIMAP2の機能性を無視しうる程度にわずかに高めます。
- IMAP2 makes what we believe to be an erroneous definition for
unsolicited vs. solicited data. IMAP3 as specified herein
attempts to correct this. RFC 1176 makes no effort to remedy
these problems.
- IMAP2は私たちが請求されるに対して求められていないデータのための誤った定義であると信じているものを作ります。 指定されるとしてのIMAP3は、これを修正するのをここに試みます。 RFC1176は、これらの問題を改善するために取り組みを全く作りません。
- RFC 1176 has explicitly modified the intent of RFC 1064 by
allowing the server to make assumptions about the client's
caching architecture. We believe this to be a grave error
and do not support it in this proposal.
- サーバがクライアントがアーキテクチャをキャッシュすることに関する仮定をするのを許容することによって、RFC1176は明らかにRFC1064の意図を変更しました。 私たちは、これが荘重な誤りであると信じて、この提案でそれをサポートしません。
- RFC 1176 specifies a number of "optional" features in the
protocol without specifying a suitable metaprotocol by which
servers and clients can adequately negotiate over the set of
implemented features. This proposal specifies a mechanism
by which servers and clients can come to an unambiguous
understanding about which features are usable by each party.
- サーバとクライアントが適切に実装している特徴のセットを交渉できる適当なmetaprotocolを指定しないで、RFC1176はプロトコルにおける多くの「任意」の特徴を指定します。 この提案はサーバとクライアントが特徴が各当事者が使用可能である明白な理解に来ることができるメカニズムを指定します。
Rice [Page 1] RFC 1203 IMAP3 February 1991
ライス[1ページ]RFC1203IMAP3 February 1991
- RFC 1176 pays only lip-service to being network protocol
independent and, in fact assumes the use of TCP/IP. Neither
RFC 1064 nor this proposal make any such assumption.
- そして、RFC1176がネットワーク・プロトコル独立者にリップサービスだけを支払う、事実上、TCP/IPの使用を仮定します。 RFC1064もこの提案も少しのそのような仮定もしません。
Although there are numerous other detailed objections to RFC 1176, we believe that the above will serve to show that we believe strongly in the importance of mailbox abstraction level mail protocols and, after a couple of years of use of IMAP2 under RFC 1064 we believe that we have a good enough understanding of the issues involved to be able to take the next step.
RFC1176への他の頻繁な詳細な反論がありますが、私たちは、私たちが強くメールボックス抽象度メールプロトコルの重要性を信じるのを示すために上記が役立つと信じています、そして、RFC1064の下でIMAP2で役に立つ2、3の年の後に、問題の十分良い理解を次の手段を取ることができるようにかかわらせると信じています。
It is important to take this next step because of the rapid pace of both mail system and user interface development. We believe that, for IMAP not to die in its infancy, IMAP must be ready to respond to emerging ISO and RFC standards in mail, such as for multi-media mail. We believe that RFC 1176 not only provides a very small increment in functionality over RFC 1064 but also adds a number of bugs, which would be detrimental to the IMAP cause. Thus we propose the following definition for IMAP3.
メールシステムとユーザーインタフェース開発の両方の急速なペースのためにこの次の方法を採るのは重要です。 私たちは、IMAPが始まったばかり死なないように、IMAPがISOとRFC規格としてメールに現れるのに応じる準備ができていなければなりません、マルチメディアメールなどのように信じています。 私たちは、RFC1176がRFC1064の上の機能性に非常にわずかな増分を提供するだけではなく、多くのバグを加えもすると信じています。(バグはIMAP原因に有害でしょう)。 したがって、私たちはIMAP3のために以下の定義を提案します。
Compatibility notes:
互換性注意:
In revising the IMAP2 protocol it has been our intent, wherever possible to make upwards compatible changes to produce IMAP3. There were, however, some places that had to be changed incompatibly in order to compensate for either ambiguities in the IMAP2 protocol as defined by RFC 1064 or behavior that proved undesirable in the light of experience.
IMAP2プロトコルを改訂するのにおいて、IMAP3を生産するために上向きにコンパチブル変更を行うのは、どこでも、可能であるところの私たちの意図です。 しかしながら、RFC1064によって定義されるIMAP2プロトコルのあいまいさか経験の見地から望ましくないと判明した振舞いのどちらかを補うために相容れないほどに変えられなければならなかったいくつかの場所がありました。
It is our goal, however, that existing IMAP2 clients should still be supported and that, at least for the foreseeable future, all IMAP3 servers will support IMAP2 behavior as their default mode.
しかしながら、既存のIMAP2クライアントがまだサポートされているべきであり、すべてのIMAP3サーバが、それらのデフォルトモードとしてIMAP2が振舞いであると少なくとも予見できる未来にサポートするのは、私たちの目標です。
The following are the major differences between this proposal, RFC 1176 and RFC 1064:
↓これはこの提案と、RFC1176とRFC1064の主要な違いです:
- In this proposal we specify a difference between "solicited" and
"unsolicited" data sent from the server. It is generally the
case that data sent by the server can be sent either in response
to an explicit request by the client or by the server of its own
volition. Any data that the server is required to sent to the
client as the result of a request is said to be solicited and
carries the same tag as the request that provoked it. Any data
sent by the server to the client that is not required by the
protocol is said to be unsolicited and carries the special "*"
tag. RFC 1176 preserves the original RFC 1064 terminology that
calls all such data sent by the server "unsolicited" even when
- この提案では、私たちはサーバから送られた「請求され」て「求められていません、な」データの違いを指定します。一般に、クライアントによる明白な要求に対応したそれ自身の意志のサーバでサーバによって送られたデータは送ることができるのが、事実です。 要求の結果が請求されると言われていて、それを引き起こした要求と同じタグを運ぶので、サーバが必要であるどんなデータもクライアントに発信しました。 サーバによってプロトコルによって必要とされないクライアントに送られたどんなデータも、求められていないと言われていて、特別な「*」タグを運びます。 RFC1176がサーバによって送られたそのようなすべてのデータが「求められていません」と言いさえするオリジナルのRFC1064用語を保存する、いつ
Rice [Page 2] RFC 1203 IMAP3 February 1991
ライス[2ページ]RFC1203IMAP3 February 1991
it is, in fact, solicited.
事実上、それは請求されます。
- This proposal introduces the experimental concept of
distinguishing between Generic, Canonical and Concrete keys,
allowing the mailbox to be viewed as a relational database
indexed by these keys. This should allow the IMAP protocol
to evolve away from its current reliance on RFC 822. RFC 1176
does not have such a unifying model.
- この提案はGeneric、Canonical、およびConcreteキーを見分ける実験概念を紹介します、関係型データベースがこれらのキーで索引をつけたときメールボックスが見られるのを許容して。 これで、IMAPプロトコルはRFC822への現在の信用から遠くで発展するべきです。 RFC1176には、そのような統一されているモデルがありません。
- The SEARCH command has been changed so as to allow multiple
simultaneous searches to be made and to allow unsolicited
search messages to be sent by the server. Such a change is
essential to allow more sophisticated servers that can process
commands asynchronously, possibly substantially delaying
searches over slow backing storage media, for example. It is
also important to allow servers to be able to send unsolicited
search messages that might inform the client of interesting
patterns of messages, such as new and unseen mail.
- 複数の同時の検索がサーバによって送られるべき求められていない検索メッセージを作られていて、許容するのを許容するために検索命令を変えました。そのような変化はコマンドを非同期に処理できるより精巧なサーバを許容するのに不可欠です、ことによると実質的に例えば、遅い補助記憶装置メディアの上の検索を遅らせて また、サーバがメッセージのおもしろいパターンについてクライアントに知らせるかもしれない求められていない検索メッセージを送ることができるのを許容するのも重要です、新しくて見えないメールなどのように。
- This proposal introduces a specific protocol for the negotiation
of protocol versions and server features. This is important
because it allows client/server pairs to come to an agreement on
what behavior is really available to it. RFC 1176 introduces a
number of "optional" commands, which are in some way analogous
to "feature-introduced" commands in this proposal. The principle
distinction between these is that in RFC 1176 there is no way
for a client to discover the set of optional commands, nor is
there a way for it to determine whether a specific command
really is supported, since RFC 1176 requires the use of the
"BAD" response if a feature is not supported. There is,
therefore, no way for the client to determine why the attempted
command did not work. This also means that, for example, a
client cannot disable certain user commands or make them
invisible on menus if they are not supported, since there
is no way for the client to discover whether the commands are
indeed supported without trying to execute such a command.
- この提案はプロトコルバージョンとサーバ機能の交渉のために特定のプロトコルを紹介します。 どんな振舞いが本当にそれに利用可能であるかに関してクライアント/サーバ組がそれで協定に達することができるので、これは重要です。 RFC1176は多くの「任意」のコマンドを紹介します。(コマンドがこの提案における「特徴で導入された」コマンドへの類似の何らかの方法であります)。 これらの原則区別はRFC1176年に、クライアントが任意のコマンドのセットを発見する方法が全くなくて、また特定のコマンドが本当にサポートされるかどうか決定する方法がないということです、特徴がサポートされないならRFC1176が「悪い」応答の使用を必要とするので。 したがって、クライアントが試みられたコマンドがなぜ働かなかったかを決心する方法が全くありません。 また、これがそれを意味して、クライアントは、例えば、それらがサポートされないならあるユーザコマンドを無効にすることができませんし、それらをメニューで目に見えなくすることができません、クライアントが、本当に、コマンドがそのようなコマンドを実行しようとしないでサポートされるかどうか発見する方法が全くないので。
- This proposal introduces a mechanism for clients to create and
delete user flags (keywords). This is nor supported in either
RFC 1176 or RFC 1064, requiring the user to add keys manually
on the server, generally by editing some form of "init" file.
- クライアントがユーザ旗(キーワード)を作成して、削除するように、この提案はメカニズムを紹介します。 これは、あって、RFC1176かRFC1064のどちらかでサポートされます、ユーザがサーバで手動でキーを加えるのが必要であることで、一般に、何らかの形式の「イニット」ファイルを編集することによって。
- RFC 1064 has no mechanism for determining whether a mailbox is
readonly or not. RFC 1176 introduces a non-enforced convention
of encoding data about the readonly status of a mailbox in the
SELECT message's OK respose comment field. This is not regular
with respect to the rest of the protocol, in which the comment
field is used for no purpose other than documentation. This
- RFC1064には、メールボックスがreadonlyかどうか決定するためのメカニズムが全くありません。 RFC1176はSELECTメッセージのOK respose注釈欄でメールボックスのreadonly状態に関してデータを暗号化する非実施されたコンベンションを導入します。 これは注釈欄がドキュメンテーション以外の目的がないために使用されるプロトコルの残りに関して通常ではありません。 これ
Rice [Page 3] RFC 1203 IMAP3 February 1991
ライス[3ページ]RFC1203IMAP3 February 1991
proposal introduces specific protocol additions for the dynamic
determination and modification of the readonly/readwrite status
of mailboxes.
提案はメールボックスのreadonly/readwrite状態のダイナミックな決断と変更のために特定のプロトコル追加を導入します。
Introduction
序論
The intent of the Interactive Mail Access Protocol, Version 3 (IMAP3) is to allow a (possibly unreliable) workstation or similar machine to access electronic mail from a reliable mailbox server in an efficient manner.
InteractiveメールAccessプロトコルの意図、バージョン3(IMAP3)は効率的な方法で(ことによると頼り無い)のワークステーションか同様のマシンが高信頼のメールボックスサーバから電子メールにアクセスするのを許容することです。
Although different in many ways from POP2 (RFC 937), IMAP3 may be thought of as a functional superset of POP2, and the POP2 RFC was used as a model for this RFC. There was a cognizant reason for this; RFC 937 deals with an identical problem and it was desirable to offer a basis for comparison.
様々な意味でPOP2(RFC937)と異なります、IMAP3はPOP2の機能的なスーパーセットとして考えられたかもしれません、そして、POP2 RFCはこのRFCにモデルとして使用されましたが。 この認識力がある理由がありました。 RFC937は同じ問題に対処します、そして、比較の基準を提供するのは望ましかったです。
Like POP2, IMAP3 specifies a means of accessing stored mail and not of posting mail; this function is handled by a mail transfer protocol such as SMTP (RFC 821). A comparison with the DMSP protocol of PCMAIL can be found at the end of "System Model and Philosophy" section.
POP2のように、IMAP3はメールを掲示するのではなく、保存されたメールにアクセスする手段を指定します。 この機能はSMTP(RFC821)などのメール転送プロトコルによって扱われます。 「システムモデルと哲学」セクションの端でPCMAILのDMSPプロトコルとの比較を見つけることができます。
This protocol assumes a reliable data stream such as provided by TCP or any similar protocol. When TCP is used, the IMAP server listens on port 220. When CHAOS is used the IMAP server listens for the logical contact name "IMAP3".
このプロトコルはTCPかどんな同様のプロトコルでも提供するように確実な資料ストリームを仮定します。 TCPが使用されているとき、IMAPサーバはポート220の上で聴かれます。 CHAOSが使用されているとき、IMAPサーバは"IMAP3""という論理的な連絡名の聞こうとします。
Communication in IMAP is defined to be using the ASCII character interpretation of data. Communication using other conventions may be possible by the selection of features on some servers.
IMAPのコミュニケーションは、データのASCII文字解釈を使用しているために定義されます。 他のコンベンションを使用するコミュニケーションはいくつかのサーバにおける特徴の品揃えで可能であるかもしれません。
System Model and Philosophy
システムモデルと哲学
Electronic mail is a primary means of communication for the widely spread SUMEX-AIM community. The advent of distributed workstations is forcing a significant rethinking of the mechanisms employed to manage such mail. With mainframes, each user tends to receive and process mail at the computer he used most of the time, his "primary host". The first inclination of many users when an independent workstation is placed in front of them is to begin receiving mail at the workstation, and, in fact, many vendors have implemented facilities to do this. However, this approach has several disadvantages:
電子メールは広く広げられたSUMEX-AIM社会のためのコミュニケーションのプライマリ手段です。 分配されたワークステーションの到来はそのようなメールを管理するのに使われたメカニズムの重要な意識改革を強制しています。 メインフレームで、各ユーザは彼がたいてい使用したコンピュータ、彼の「一次ホスト」でメールを受け取って、処理する傾向があります。 多くのユーザの最初の傾向が独立しているワークステーションが彼らの正面に置かれるとき、ワークステーションにメールを受け取り始めることであり、事実上、多くのベンダーが、これをするために施設を実装しました。 しかしながら、このアプローチには、数回の損失があります:
(1) Workstations (especially Lisp workstations) have a software
design that gives full control of all aspects of the system
to the user at the console. As a result, background tasks,
(1) ワークステーション(特にLispワークステーション)はコンソールにシステムの全面の完全な支配力をユーザに与えるソフトウェアデザインを持っています。 結果、バックグラウンドタスクとして
Rice [Page 4] RFC 1203 IMAP3 February 1991
ライス[4ページ]RFC1203IMAP3 February 1991
like receiving mail, could well be kept from running for
long periods of time either because the user is asking to
use all of the machine's resources, or because, in the course
of working, the user has (perhaps accidentally) manipulated
the environment in such a way as to prevent mail reception.
This could lead to repeated failed delivery attempts by
outside agents.
ユーザが、マシンのリソースのすべてを使用するように頼んでいるので長い期間の間、上演するのから妨げられるか、またはユーザが働きの間に環境をメールレセプションを防ぐほどそのような方法で操ったので(恐らく偶然)たぶんメールを受け取るように、である。 これは外部のエージェントによる繰り返された失敗した配送試みに通じるかもしれません。
(2) The hardware failure of a single workstation could keep its
user "off the air" for a considerable time, since repair of
individual workstation units might be delayed. Given the
growing number of workstations spread throughout office
environments, quick repair would not be assured, whereas a
centralized mainframe is generally repaired very soon after
failure.
(2) 単一のワークステーションのハードウェアの故障はかなり長い間「放送されていない」ようにユーザを保つかもしれません、個々のワークステーションユニットの修理が遅れるかもしれないので。 オフィス環境中で広げられたワークステーションの増加している数を考えて、迅速な修理は保証されないでしょうが、一般に、集結されたメインフレームは失敗の後にすぐ、修理されます。
(3) It is more difficult to keep track of mailing addresses when
each person is associated with a distinct machine. Consider
the difficulty in keeping track of a large number of postal
addresses or phone numbers, particularly if there was no
single address or phone number for an organization through
which you could reach any person in that organization.
Traditionally, electronic mail on the ARPANET involved
remembering a name and one of several "hosts" (machines)
whose name reflected the organization in which the
individual worked. This was suitable at a time when most
organizations had only one central host. It is less
satisfactory today unless the concept of a host is changed
to refer to an organizational entity and not a particular
machine.
(3) それぞれの人が異なったマシンに関連しているとき、郵送先住所の動向をおさえるのは、より難しいです。 多くの郵便の宛先か電話番号の動向をおさえることにおける苦労を考えてください、特にその組織にあなたがどんな人にも連絡できるだろう組織のためのどんなただ一つのアドレスも電話番号もなかったなら。 伝統的に、アルパネットの電子メールは、名前が個人が働いていた組織を反映した数個の「ホスト」(マシン)の名前と1つを覚えていることを伴いました。 これはほとんどの組織には1人の主要なホストしかいなかった時代に適当でした。 ホストの概念が特定のマシンではなく、組織的な実体について言及するために変えられない場合、それは今日、それほど満足できません。
(4) It is very difficult to keep a multitude of heterogeneous
workstations working properly with complex mailing protocols,
making it difficult to move forward as progress is made in
electronic communication and as new standards emerge. Each
system has to worry about receiving incoming mail, routing
and delivering outgoing mail, formatting, storing, and
providing for the stability of mailboxes over a variety of
possible filing and mailing protocols.
(4) 異種のワークステーションの多数を複雑な郵送プロトコルで適切に働かせ続けるのは非常に難しいです、電子コミュニケーション、新しい規格が現れるとき進歩が見られるとき前方へ動くのを難しくして。 各システムは入って来るメールを受け取るのを心配しなければなりません、送信するメールを発送して、提供して、さまざまな可能なファイリングとプロトコルを郵送する上のメールボックスの安定性をフォーマットして、保存して、備えて。
Consequently, while the workstation may be viewed as an Internet host in the sense that it implements IP, it should not be viewed as the entity which contains the user's mailbox. Rather, a mail server machine (sometimes called a "repository") should hold the mailbox, and the workstation (hereafter referred to as a "client") should access the mailbox via mail transactions. Because the mail server machine would be isolated from direct user manipulation, it could achieve high software reliability easily, and, as a shared resource,
その結果、インターネット・ホストとしてIPを実装するという意味でワークステーションを見なしているかもしれない間、ユーザのメールボックスを含む実体としてそれを見なすべきではありません。 むしろ、メールサーバマシン(時々「倉庫」と呼ばれる)はメールボックスを支えるはずです、そして、メールトランザクションでワークステーション(今後「クライアント」と呼ばれる)はメールボックスにアクセスするはずです。 メールサーバマシンはダイレクトユーザ操作から隔離されるでしょう、したがって、そして、それが共用資源として容易に高いソフトウェアの信頼性を獲得するかもしれません。
Rice [Page 5] RFC 1203 IMAP3 February 1991
ライス[5ページ]RFC1203IMAP3 February 1991
it could achieve high hardware reliability, perhaps through redundancy. The mail server could be used from arbitrary locations, allowing users to read mail across campus, town, or country using more and more commonly available clients. Furthermore, the same user may access his mailbox from different clients at different times, and multiple users may access the same mailbox simultaneously.
それは恐らく冗長を通して高いハードウェアの信頼性を獲得するかもしれません。 任意の位置からメールサーバを使用できました、ユーザがキャンパス、町、または国の向こう側にメールを読むのをますます多くの一般的に手があいているクライアントを使用することで許容して。 その上、同じユーザは異なったクライアントといろいろな時間に彼のメールボックスにアクセスするかもしれません、そして、複数のユーザが同時に、同じメールボックスにアクセスするかもしれません。
The mail server acts an an interface among users, data storage, and other mailers. The mail access protocol is used to retrieve messages, access and change properties of messages, and manage mailboxes. This differs from some approaches (e.g., Unix mail via NFS) in that the mail access protocol is used for all message manipulations, isolating the user and the client from all knowledge of how the data storage is used. This means that the mail server can utilize the data storage in whatever way is most efficient to organize the mail in that particular environment, without having to worry about storage representation compatibility across different machines.
メールサーバはユーザの中のインタフェース、データ保存、および他の郵送者を演じます。 メールアクセス・プロトコルは、メッセージのメッセージ、アクセス、および変化の特性を検索して、メールボックスを管理するのに使用されます。 これはメールアクセス・プロトコルがすべてのメッセージ操作に使用されるという点においていくつかのアプローチ(例えば、NFSを通したUnixメール)と異なっています、データ保存がどう使用されているかに関するすべての知識からユーザとクライアントを隔離して。 これは、メールサーバがいかなるその特定の環境におけるメールをまとめるために最も効率的な方法でもデータ保存を利用できることを意味します、異なったマシンの向こう側にストレージ表現の互換性を心配する必要はなくて。
In defining a mail access protocol, it is important to keep in mind that the client and server form a macrosystem, in which it should be possible to exploit the strong points of both while compensating for each other's weaknesses. Furthermore, it's desirable to allow for a growth path beyond the hoary text-only RFC 822 protocol. Unlike POP2, IMAP3 has extensive features for remote searching and parsing of messages on the server. For example, a free text search (optionally in conjunction with other searching) can be made throughout the entire mailbox by the server and the results made available to the client without the client having to transfer the entire mailbox and searching itself. Since remote parsing of a message into a structured (and standard format) "envelope" is available, a client can display envelope information and implement commands such as REPLY without having any understanding of how to parse RFC 822, etc., headers.
メールアクセス・プロトコルを定義するのにおいて、クライアントとサーバが両方の長所を利用するのが互いの弱点を補っている間、可能であるべきmacrosystemを形成するのを覚えておくのは重要です。 その上、灰色のテキストのみを超えてRFC822プロトコルを成長経路に許容するのは望ましいです。 IMAP3には、POP2と異なって、サーバにおけるメッセージのリモート探すのと構文解析のための大規模な特徴があります。例えば、無料のテキストを探します。(全体のメールボックスを移さなければならないクライアントなしでクライアントにとって利用可能に作られていて、それ自体を捜しながら、全体のメールボックス中でサーバと結果によって任意に他の探すこと) 缶に関連して作られてください。 構造化された(そして、標準の形式)「封筒」へのメッセージのリモート構文解析が利用可能であるので、どうRFC822などを分析するかに関するどんな理解も持っていなくて、クライアントは、封筒情報を表示して、REPLYなどのコマンドを実装することができます、ヘッダー。
Additionally, IMAP3 offers several facilities for managing a mailbox beyond the simple "delete message" functionality of POP2.
さらに、IMAP3は、「メッセージを削除してください」というPOP2の簡単な機能性を超えてメールボックスを管理するためにいくつかの施設を提供します。
In spite of this, IMAP3 is a relatively simple protocol. Although servers should implement the full set of IMAP3 functions, a simple client can be written which uses IMAP3 in much the way as a POP2 client.
これにもかかわらず、IMAP3は比較的簡単なプロトコルです。 サーバはIMAP3機能のフルセットを実装するべきですが、純真なクライアントを書くことができます(POP2クライアントとして方法でIMAP3を使用します)。
IMAP3 differs from the DMSP protocol of PCMAIL (RFC 1056) in a more
fundamental manner, reflecting the differing architectures of IMAP
and PCMAIL. PCMAIL is either an online ("interactive mode"), or
offline ("batch mode") system. IMAP is primarily an online system in
which real-time and simultaneous mail access were considered
IMAP3は、より基本的な方法でPCMAIL(RFC1056)のDMSPプロトコルと異なっています、IMAPとPCMAILの異なったアーキテクチャを反映して。 PCMAILはオンライン(「会話型」)かオフライン(「バッチ・モード」)システムのどちらかです。 IMAPは主としてリアルタイムで同時のメールアクセスが考えられたオンラインシステムです。
Rice [Page 6] RFC 1203 IMAP3 February 1991
ライス[6ページ]RFC1203IMAP3 February 1991
important.
重要。
In PCMAIL, there is a long-term client/server relationship in which some mailbox state is preserved on the client. There is a registration of clients used by a particular user, and the client keeps a set of "descriptors" for each message which summarize the message. The server and client synchronize their states when the DMSP connection starts up, and, if a client has not accessed the server for a while, the client does a complete reset (reload) of its state from the server.
PCMAILに、何らかのメールボックス状態がクライアントの上に保持される長期のクライアント/サーバ関係があります。 特定のユーザによって使用されたクライアントの登録があります、そして、クライアントは各メッセージのためのメッセージをまとめる1セットの「記述子」を保ちます。 DMSP接続が始動すると、サーバとクライアントはそれらの州を連動させます、そして、クライアントがしばらくサーバにアクセスしていないなら、クライアントはサーバから状態の完全なリセット(再び荷を積む)をします。
In IMAP, the client/server relationship lasts only for the duration of the IMAP3 connection. All mailbox state is maintained on the server. There is no registration of clients. The function of a descriptor is handled by a structured representation of the message "envelope". This structure makes it unnecessary for a client to know anything about RFC 822 parsing. There is no synchronization since the client does not remember state between IMAP3 connections. This is not a problem since in general the client never needs the entire state of the mailbox in a single session, therefore there isn't much overhead in fetching the state information that is needed as it is needed.
IMAPでは、クライアント/サーバ関係はIMAP3接続の持続時間のためだけに持続します。 すべてのメールボックス状態がサーバで維持されます。クライアントの登録が全くありません。 記述子の機能は「封筒」というメッセージの構造化された表現で扱われます。 この構造で、クライアントがRFC822構文解析に関して何でも知るのが不要になります。 クライアントがIMAP3接続の間の状態を覚えていないので、同期が全くありません。 クライアントがただ一つのセッションのときに一般にメールボックスの全体の州を決して必要としないのでこれが問題でない、したがって、それが必要であるように必要である州の情報をとって来るのにおいてオーバーヘッドがあまりありません。
There are also some functional differences between IMAP3 and DMSP. DMSP has functions for sending messages, printing messages, and changing passwords, all of which are done outside of IMAP3. DMSP has 16 binary flags of which 8 are defined by the system. IMAP has flag names; there are currently 5 defined system flag names and a facility for some number (29 in the current implementations) of user flag names. IMAP3 has a sophisticated message search facility in the server to identify interesting messages based on dates, addresses, flag status, or textual contents without compelling the client to fetch this data for every message.
また、IMAP3とDMSPの間には、いくつかの機能的な違いがあります。 DMSPには、メッセージを印刷して、パスワード(それのすべてがIMAP3の外で行われる)を変えて、送付メッセージのための機能があります。 DMSPには、どの8がシステムによって定義されるかに関する16個の2進の旗があります。 IMAPには、旗の名があります。 現在、5つの定義されたシステム旗の名と何らかの数(現在の実装における29)のユーザ旗の名のための施設があります。 IMAP3は、クライアントがあらゆるメッセージのためのこのデータをとって来るのを強制しない期日、アドレス、旗の状態、または原文のコンテンツに基づくおもしろいメッセージを特定するためにサーバで洗練されたメッセージ検索施設を持っています。
It was felt that maintaining state on the client is advantageous only in those cases where the client is only used by a single user, or if there is some means on the client to restrict access to another user's data. It can be a serious disadvantage in an environment in which multiple users routinely use the same client, the same user routinely uses different clients, and where there are no access restrictions on the client. It was also observed that most user mail access is to a relatively small set of "interesting" messages, which were either "new" mail or mail based upon some user-selected criteria. Consequently, IMAP3 was designed to easily identify those "interesting" messages so that the client could fetch the state of those messages and not those that were not "interesting".
クライアントがどこでシングルユーザーによって使用されるだけであるか、そして、またはアクセスを別のユーザのデータに制限するためにクライアントの上にいくつかの手段があるかがクライアントの上で状態を維持するのがそれらの場合だけに有利であると感じられました。 それはそれの倍数にユーザがきまりきって同じクライアントを使用して、同じユーザがきまりきって異なったクライアントを使用して、クライアントの上にアクセス制限が全くない環境で重大な不都合であるかもしれません。 また、比較的小さいセットの「おもしろい」メッセージにはほとんどのユーザメールアクセスがあるのが観測されました。(いくつかのユーザによって選択された評価基準に基づく「新しい」メールかメッセージはメールのどちらかでした)。 その結果、IMAP3は、クライアントがそれらではなく、それらの「おもしろくなかった」メッセージの状態をとって来ることができるように容易にそれらの「おもしろい」メッセージを特定するように設計されました。
One crucial philosophical difference between IMAP and other common
IMAPで他の間で一般的な1つの重要な哲学的な違い
Rice [Page 7] RFC 1203 IMAP3 February 1991
ライス[7ページ]RFC1203IMAP3 February 1991
mail protocols is that IMAP is a mailbox access protocol, not a protocol for manipulating mail files. In the IMAP model, unlike other mail system models in which mail is stored in a linear mail file, no specification is made for the implementation architecture for mail storage. Servers may choose to implement mailboxes as files but this is a detail of which the client can be totally unaware.
メールプロトコルはIMAPがメールファイルを操作するためのプロトコルではなく、メールボックスアクセス・プロトコルであるということです。 IMAPモデルでは、メールが直線的なメールファイルに保存される他のメールシステムモデルと異なって、仕様は全くメールストレージのための実装アーキテクチャのために作られていません。 サーバは、ファイルとしてメールボックスを実装するのを選ぶかもしれませんが、これはクライアントが全く気づかない場合がある詳細です。
What is more, in the IMAP model, mailboxes are viewed as mappings from keys into values. There are broadly three types of keys, generic, canonical and concrete. Generic keys are generic, mail protocol independent keys defined by IMAP which are meaningful across multiple mail encoding formats. An example of such a generic key might be "TO", which would be associated with the "To:" field of an RFC 822 format message.
さらに、IMAPモデルでは、メールボックスはマッピングとしてキーから値に見なされます。 キー、3つのタイプの正準で具体的なジェネリックは、広くあります。 総称キーがジェネリックである、メールプロトコルの独立しているキーはIMAPでどれが複数のメールコード化形式の向こう側に重要であるかを定義しました。 そのような総称キーに関する例は“TO"であるかもしれません。(「To:」にその“TO"関連するだろう) RFC822形式メッセージの分野。
Canonical keys represent the way in which the server can associate values that are generally "about" a certain key concept, possibly integrating several mail format specific fields, without having to worry the client with the particular details of any particular message format. Thus, the canonical TO key (called $TO) could denote anything that could reasonably be construed as being directed towards someone. Hence, in an RFC 822 message the server could find the union of the "To:", "Resent-To", "Apparently-To:" and "CC:" fields to be the appropriate value associated with the canonical $TO key.
正準なキーはサーバが一般に、“about"のaある重要な考えである値を関連づけることができる方法を表します、ことによるといくつかのメール書式の特定の野原を統合して、どんな特定のメッセージ・フォーマットの特定の詳細をもっているクライアントも心配させる必要はなくて。 したがって、正準なTOキー($をTOと呼ぶ)は合理的にだれかに向けられるのに理解できたものは何でも指示するかもしれません。 したがって、RFC822メッセージでは、サーバが「To:」の組合を見つけるかもしれない、「憤慨、-、」、「明らかにTo:」 そして、「CC:」 正準な$TOに主要な状態で関連づけられた適切な値になるように、さばきます。
Concrete keys allow the client to gain access to certain mail format specific concepts, that are not pre-specified by the IMAP protocol, in a well defined manner. For example, If the client asks for the value associated with the "APPARENTLY-TO" key then, if the message were to be in RFC 822 format, the server would look for a header field called "Apparently-To:". If no such field is found or the field is not implemented or meaningful for the particular message format then the server will respond with the null value, called NIL, indicating the non-existence of the field.
クライアントはコンクリートのキーで、あるメール書式種概念へのアクセスを得ることができて、それはIMAPプロトコルによってあらかじめ指定されません、よく定義された方法で。 例えば、クライアントのIfが交際した値を求める、「明らかである、-、」 次に、主要です、メッセージがRFC822形式であることであるなら、サーバは「明らかにTo:」と呼ばれるヘッダーフィールドを探します。 NILは、特定のメッセージ・フォーマットには、分野がどんなそのような分野も見つけられないか、実装されないで、またまたは重要でないならサーバがヌル値で反応すると呼びました、分野の非存在を示して。
Thus, IMAP servers are at liberty to implement mailboxes as a relational databases if it seems convenient. Indeed, we anticipate that future mail systems will tend to use database technology for the storage and indexing of mailboxes as a result of the pressure caused by the increasing size of mailboxes.
したがって、便利に見えるなら、IMAPサーバは関係型データベースとしてメールボックスを実装するのにおいて自由です。 本当に、私たちは将来のメールシステムが、メールボックスの増加するサイズによって引き起こされた圧力の結果、メールボックスのストレージとインデックスにデータベース技術を使用する傾向があると予期します。
Although for historical reasons IMAP is currently somewhat closely associated with RFC 822, we anticipate that future developments in IMAP will remove these mail format specific components and will move towards the generic model mentioned above. This will allow IMAP more easily to incorporate such things as multi-media mail.
IMAPは現在、歴史的な理由で密接にRFC822にいくらか関連していますが、私たちは、IMAPの未来の発展がこれらのメール書式の特定の成分を取り除いて、前記のようにジェネリックモデルに近づくと予期します。 これは、マルチメディアが郵送するようなものを組み込むために、より容易にIMAPを許容するでしょう。
Rice [Page 8] RFC 1203 IMAP3 February 1991
ライス[8ページ]RFC1203IMAP3 February 1991
The Protocol
プロトコル
The IMAP3 protocol consists of a sequence of client commands and server responses to those commands, with extra information from the server data being sent asynchronously to and independent to the responses to client commands. Unlike most Internet protocols, commands and responses are tagged. That is, a command begins with a unique identifier (typically a short alphanumeric sequence such as a Lisp "gensym" function would generate e.g., A0001, A0002, etc.), called a tag. The response to this command is given the same tag from the server.
プロトコルがクライアントコマンドの系列とサーバデータからのその他の情報を非同期に送るそれらのコマンドへのサーバ応答から成るIMAP3とクライアントコマンドへの応答への独立者。 ほとんどのインターネットプロトコルと異なって、コマンドと応答はタグ付けをされています。 すなわち、コマンドはタグと呼ばれるユニークな識別子(通常、Lisp"gensym"機能などの短い英数字の系列は例えば、A0001、A0002などを生成する)で始まります。 同じタグをサーバからこのコマンドへの応答に与えます。
We distinguish between data sent by the server as the result of a client request, which we term "SOLICITED" and data sent by the server not as the result of a client request, which we term "UNSOLICITED". The server may send unsolicited data at any time that would not fragment another piece of data on the same stream rendering it unintelligible. The server is contractually required, however, to return all data that is solicited by the client before the return of the completion signal for that command, i.e., all solicited data must be returned within the temporal extent of the request/completion acknowledgement wrapper. This does not, however, preclude the simultaneous processing of multiple requests by the client, it simply requires that the client be confident that it has all the requested data when a request finishes. This allows the implementation of both synchronous and asynchronous clients.
私たちがクライアント要求の結果としてサーバによって送られたデータを見分ける、どれ、私たち、「請求される」という用語とクライアント要求の結果でないとしてサーバによって送られたデータ、どれ、私たち、用語「求められていませんか」。 サーバで、いつでももう1片の同じストリームに関するデータを断片化しない求められていないデータはそれを難解にするかもしれません。 しかしながら、そのコマンドのための完成信号の復帰の前にクライアントによって請求されるすべてのデータを返すためにサーバを契約上必要とします、すなわち、要求/完成承認ラッパーの時の範囲の中ですべての請求されたデータを返さなければなりません。 しかしながら、これはクライアントによる複数の要求の同時処理を排除しないで、それは、クライアントが要求が終わるとそれにはすべての要求されたデータがあると確信しているのを単に必要とします。 これは同時の、そして、非同期の両方クライアントの実装を許容します。
Solicited data is identified by the tag of the initial request by the client. Unsolicited data is identified by the special reserved tag of "*". There is another special reserved tag, "+", discussed below.
請求されたデータはクライアントによる初期の要求のタグによって特定されます。 求められていないデータは「*」の特別な予約されたタグによって特定されます。 別の特別な予約されたタグ、以下で議論した「+」があります。
Note: the tagging of SOLICITED data is only permitted for a selected server version other than 2.0.
以下に注意してください。 SOLICITEDデータのタグ付けは2.0以外の選択されたサーババージョンのために受入れられるだけです。
No assumptions concerning serial or monolithic processing by the server can be made by a correct client. The server is at liberty to process multiple requests by the same client in any order. This allows servers to process costly searches over mailboxes on slow backing storage media in the background, while still preserving interactive performance. Clients can, however, assume the serialization of the request/data/completion behavior mentioned above.
正しいクライアントはサーバによる連続の、または、一枚岩的な処理に関する仮定を全くすることができません。 サーバは順不同な同じクライアントによる複数の要求を処理するのにおいて自由です。 まだ対話的な性能を保存している間、これで、サーバはバックグラウンドでメールボックスの上の高価な検索を遅い補助記憶装置メディアに処理できます。 しかしながら、クライアントは前記のように要求/データ/完成の振舞いの連載を仮定できます。
When a connection is opened the server sends an unsolicited OK response as a greeting message and then waits for commands. When commands are received the server acts on them and responds with responses, often interspersed with data.
接続が開かれると、サーバは、あいさつメッセージとして求められていないOK応答を送って、コマンドを待っています。 コマンドが受け取られているとき、サーバは、それらに影響して、しばしばデータで点在した応答で反応します。
Rice [Page 9] RFC 1203 IMAP3 February 1991
ライス[9ページ]RFC1203IMAP3 February 1991
The client opens a connection, waits for the greeting, then sends a LOGIN command with user name and password arguments to establish authorization. Following an OK response from the server, the client then sends a SELECT command to access the desired mailbox. The user's default mailbox has a special reserved name of "INBOX" which is independent of the operating system that the server is implemented on. The server will generally send a list of valid flags, number of messages, and number of messages arrived since last access for this mailbox as solicited data, followed by an OK response. The client may terminate access to this mailbox and access a different one with another SELECT command.
クライアントは、接続を開いて、挨拶を待っていて、次に、承認を証明するためにユーザ名とパスワード議論と共にLOGINコマンドを送ります。 サーバからOK応答に続いて、そして、クライアントは必要なメールボックスにアクセスするSELECTコマンドを送ります。 ユーザのデフォルトメールボックスはサーバが実装されるオペレーティングシステムから独立している「受信トレイ」の特別な予約された名前をオンに持っています。 一般に、サーバは有効な旗のリストを送るでしょう、メッセージの数、そして、このメールボックスのための最後のアクセス以来メッセージの数がOK応答があとに続いた請求されたデータとして到着しました。 クライアントは、このメールボックスへのアクセスを終えて、別のSELECTコマンドがある異なったものにアクセスするかもしれません。
Because the SELECT command affects the state of the server in a fundamental way, the server is required to process all outstanding commands for any given mailbox before sending the OK tag for the SELECT command. Thus, the client will always know that all responses before an OK SELECT response will refer to the old mailbox and all responses following it will apply to the new mailbox.
SELECTコマンドが基本的な方法でサーバの事情に影響するので、サーバがSELECTコマンドのためのOKタグを送る前にどんな与えられたメールボックスのためのすべての傑出しているコマンドも処理するのに必要です。 したがって、クライアントは、いつもそれに続いて、OK SELECT応答が古いメールボックスとすべての応答について言及する前にすべての応答が新しいメールボックスに適用されるのを知るでしょう。
Because, in the real world, local needs or experimental work will dictate that servers will support both supersets of the defined behavior and incompatible changes, servers will support a SELECT.VERSION command and a SELECT.FEATURES command, the purpose of which is to allow clients to select the overall behavior and specific features that they want from a server. The default behavior of any server is to process commands and to have interaction syntax the same as is specified by IMAP2 in RFC 1064. A server may not behave in any other manner unless the SELECT.VERSION or SELECT.FEATURES commands are used to select different behavior.
地方の必要性か実験研究が、本当の世界でサーバが定義された振舞いのスーパーセットと非互換な変化の両方をサポートすると決めるので、サーバは、SELECT.VERSIONコマンドとSELECT.FEATURESがコマンドであることをサポートするでしょう。(それの目的はコマンドのためにクライアントが彼らがサーバから欲しい総合的な振舞いと特定の特徴を選択するのを許容することです)。どんなサーバのデフォルト働きも、コマンドを処理して、RFC1064にIMAP2による指定されているのと同じ相互作用構文を持つことです。 SELECT.VERSIONかSELECT.FEATURESコマンドが異なった振舞いを選択するのに使用されない場合、サーバはいかなる他の態度でも振る舞わないかもしれません。
Over time, when groups of generally useful changes to the current, default behavior of the server are found, these will be collected together and incorporated in such a way that all of the features can be selected simply by selecting a particular major version number of the protocol. It should be noted that the version numbers (both major and minor) selected by the SELECT.VERSION command denote versions of the IMAP protocol, not versions of the server per se. Thus, although in general changes to the protocol specification will be made in such a way that they are upwards compatible, this cannot be guaranteed. No client should rely on tests of the form "if major_version > 2 then..." being valid for all protocol versions, since incompatible changes might be made in the future.
時、これらは、単にプロトコルの特定のメジャーバージョン番号を選択することによって特徴のすべてを選択できるような方法で一緒に集められて、取り入れられるでしょう。(その時、一般に役に立つ変化のグループはサーバの現在のデフォルト働きに見つけられます)。 SELECT.VERSIONコマンドで選択されたバージョン番号(主要なものと同様に小さい方の)がそういうものとしてサーバのバージョンではなく、IMAPプロトコルのバージョンを指示することに注意されるべきです。 したがって、プロトコル仕様への変更は一般にそれらが上向きに互換性があるような方法で行われるでしょうが、これを保証できません。 どんなクライアントも形式のテストに依存するべきでない、「少佐_バージョン>2であるなら、」 すべてのプロトコルバージョンに、非互換な変化以来有効な…は将来、作られるかもしれません。
The client reads mailbox information by means of FETCH commands. The actual data is transmitted via the solicited data mechanism (that is, FETCH should be viewed as poking the server to include the desired data along with any other data it wishes to transmit to the client). There are three major categories of data which may be fetched.
クライアントはFETCHコマンドによってメールボックス情報を読みます。 実際のデータは請求されたデータメカニズムで送られます(すなわち、FETCHはそれがクライアントに送りたがっているいかなる他のデータに伴う必要なデータも含むようにサーバを小突くと見なされるべきです)。 とって来られるかもしれないデータの3つの大範疇があります。
Rice [Page 10] RFC 1203 IMAP3 February 1991
ライス[10ページ]RFC1203IMAP3 February 1991
The first category is that data which is associated with a message as an entity in the mailbox. There are presently three such items of data: the "internal date", the "RFC 822 size", and the "flags". The internal date is the date and time that the message was placed in the mailbox. The RFC 822 size is subject to deletion in the future; it is the size in bytes of the message, expressed as an RFC 822 text string. Current clients only use it as part of a status display line. The flags are a list of status flags associated with the message (see below). All of the first category data can be fetched by using the macro-fetch word "FAST"; that is, "FAST" expands to "(FLAGS INTERNALDATE RFC822.SIZE)".
最初のカテゴリは実体としてメールボックスの中にメッセージに関連しているそのデータです。 現在、データのそのような3つの項目があります: 「内部の期日」、「RFC822サイズ」、および「旗。」 内部の期日はメッセージがメールボックスに置かれた日時です。 RFC822サイズは将来、削除を受けることがあります。 それはRFC822テキスト文字列として言い表されたメッセージのバイトで表現されるサイズです。 現在のクライアントは状態表示行の一部としてそれを使用するだけです。 旗はメッセージに関連している状態旗のリスト(以下を見る)です。 「速い」というマクロフェッチ単語を使用することによって、最初のカテゴリデータのすべてをとって来ることができます。 すなわち、「速い」は「(旗のINTERNALDATE RFC822.SIZE)」に広がります。
The second category is that data which describes the composition and delivery information of a message; that is, information such as the message sender, recipient lists, message-ID, subject, etc. This is the information which is stored in the message header in RFC 822 format message and is traditionally called the "envelope". [Note: this should not be confused with the SMTP (RFC 821) envelope, which is strictly limited to delivery information.] IMAP3 defines a structured and unambiguous representation for the envelope which is particularly nice for Lisp-based parsers. A client can use the envelope for operations such as replying and not worry about RFC 822 at all. Envelopes are discussed in more detail below. The first and second category data can be fetched together by using the macro-fetch word "ALL"; that is, "ALL" expands to "(FLAGS INTERNALDATE RFC822.SIZE ENVELOPE)".
2番目のカテゴリはメッセージの構成と配送情報について説明するそのデータです。 すなわち、メッセージ送付者などの情報、受取人リスト、メッセージID、対象など これはRFC822形式メッセージにメッセージヘッダーに格納されて、伝統的に「封筒」と呼ばれる情報です。 [注意: これはSMTP(RFC821)封筒に混乱するべきではありません。](封筒は厳密に配送情報に制限されます)。 IMAP3はLispベースのパーサには、特に良い封筒の構造化されて明白な表現を定義します。 クライアントは、返答などなどの操作に封筒を使用して、全くRFC822を心配できません。 さらに詳細に以下で封筒について議論します。 「すべて」というマクロフェッチ単語を使用することによって、1番目と2番目のカテゴリデータを一緒にとって来ることができます。 すなわち、「すべて」は「(旗のINTERNALDATE RFC822.SIZE封筒)」に広がります。
The third category is that data which is intended for direct human viewing. The present RFC 822 based IMAP3 defines three such items: RFC822.HEADER, RFC822.TEXT, and RFC822 (the latter being the two former appended together in a single text string). Fetching "RFC822" is equivalent to typing the RFC 822 representation of the message as stored on the mailbox without any filtering or processing.
3番目のカテゴリはダイレクト人間の見るために意図するそのデータです。 現在のRFC822ベースのIMAP3はそのような3つの項目を定義します: RFC822.HEADER、RFC822.TEXT、およびRFC822(前者がただ一つのテキスト文字列で一緒に追加した2である後者)。 魅惑的な"RFC822"は少しもフィルタリングや処理なしでメールボックスに格納されるようにメッセージのRFC822表現をタイプするのに同等です。
Typically, a client will "FETCH ALL" for some or all of the messages
in the mailbox for use as a presentation menu, and when the user
wishes to read a particular message will "FETCH RFC822.TEXT" to get
the message body. A more primitive client could, of course, simply
"FETCH RFC822" a la POP2-type functionality.
通常、クライアントはメッセージ本体を得るプレゼンテーションメニューと特定のメッセージを読むというユーザ願望がいつ「RFC822.TEXTをとって来るか」としての使用のためのメールボックスの中のメッセージのいくつかかすべてのために「すべてをとって来るでしょう」。 より原始のクライアントはもちろんPOP2-タイプの機能性のように単に「RFC822をとって来ることができました」。
The client can alter certain data by means of a STORE command. As an example, a message is deleted from a mailbox by a STORE command which includes the \DELETED flag as one of the flags being set.
クライアントはストアコマンドによって、あるデータを変更できます。 例として、メッセージはメールボックスからDELETEDが設定される旗の1つとして旗を揚げさせる\を含んでいるストアコマンドで削除されます。
Other client operations include copying a message to another mailbox (COPY command), permanently removing deleted messages (EXPUNGE command), checking for new messages (CHECK command), and searching for messages which match certain criteria (SEARCH command).
他のクライアント操作は、別のメールボックス(COPYコマンド)にメッセージをコピーするのを含んでいます、永久に削除されたメッセージ(EXPUNGEコマンド)を取り除いて、新しいメッセージ(CHECKコマンド)がないかどうかチェックして、ある評価基準(検索命令)に合っているメッセージを検索して。
Rice [Page 11] RFC 1203 IMAP3 February 1991
ライス[11ページ]RFC1203IMAP3 February 1991
The client terminates the session with the LOGOUT command. The server returns a "BYE" followed by an "OK".
クライアントはLOGOUTコマンドとのセッションを終えます。 サーバは「OK」によって続かれた「さようなら」を返します。
A Typical Scenario
典型的なシナリオ
Client Server
------ ------
{Wait for Connection}
{Open Connection} -->
<-- * OK IMAP3 Server Ready
{Wait for command}
A001 SUPPORTED.VERSIONS -->
<-- * SUPPORTED.VERSIONS ((2 0 )
(3 0 EIGHT.BIT.TRANSPARENT
AUTO.SET.SEEN
TAGGED.SOLICITED))
A001 OK Supported Versions returned.
{Wait for command}
A002 SELECT.VERSION (3 0) -->
<-- A002 OK Version 3.0 Selected.
{Wait for command}
A002 SELECT.FEATURES TAGGED.SOLICITED -->
<-- A002 OK Features selected.
{Wait for command}
A003 LOGIN Fred Secret -->
<-- A003 OK User Fred logged in
{Wait for command}
A004 SELECT INBOX -->
<-- A004 FLAGS (Meeting Notice \Answered
\Flagged \Deleted \Seen)
<-- A004 19 EXISTS
<-- A004 2 RECENT
<-- A004 OK Select complete
{Wait for command}
A005 FETCH 1:19 ALL -->
<-- A005 1 Fetch (......)
...
<-- A005 18 Fetch (......)
<-- A005 19 Fetch (......)
<-- A005 OK Fetch complete
{Wait for command}
A006 FETCH 8 RFC822.TEXT -->
<-- A006 8 Fetch (RFC822.TEXT {893}
...893 characters of text...
<-- )
<-- A006 OK Fetch complete
{Wait for command}
クライアントサーバ------ ------ 開いているConnection--><--*OK IMAP3 Server Readyはコマンドを待っています。Connectionを待ってください、A001 SUPPORTED.VERSIONS--><--*SUPPORTED.VERSIONS((2 0 )(3 0EIGHT.BIT.TRANSPARENT AUTO.SET.SEEN TAGGED.SOLICITED)A001 OK Supportedバージョンは戻りました。 コマンドを待ってください。A002 SELECT.VERSION(3 0)--><--A002 OKバージョン3.0Selected。 コマンドを待ってください。A002 SELECT.FEATURES TAGGED.SOLICITED--><--選択されたA002 OK Features。 コマンドを待ってください、A003 LOGINフレッドSecret--><--A003 OK Userフレッド、登録されて、A004 SELECT INBOXは中でコマンドを待っています--><--A004 FLAGS(ミーティングNotice\Answered\Flagged\Deleted\Seen)<--A004 19EXISTS<--A004 2RECENT<--A004 OK Selectがコマンドのための待ちを終了する、A005 FETCH1:19、すべて--><--A005 1Fetch、() ... <-- A005 18がとって来る、() <-- A005 19がとって来る、() <-- A005 OK Fetchがコマンドのための待ちを終了する、A006 FETCH8RFC822.TEXT--><--A006 8Fetch(テキスト(<)のRFC822.TEXT893.893のキャラクタ)<--、A006 OK Fetchは完成します。コマンドを待ってください。
Rice [Page 12] RFC 1203 IMAP3 February 1991
ライス[12ページ]RFC1203IMAP3 February 1991
A007 STORE 8 +Flags \Deleted -->
<-- A007 8 Store (Flags (\Deleted
\Seen))
<-- A007 OK Store complete
{Wait for command}
A008 EXPUNGE -->
<-- A008 19 EXISTS
<-- A008 8 EXPUNGE
<-- A008 18 EXISTS
<-- A008 Expunge complete
{Wait for command}
A009 LOGOUT -->
<-- A009 BYE IMAP3 server quitting
<-- A009 OK Logout complete
{Close Connection} --><-- {Close connection}
{Go back to start}
><--A008 19EXISTS<--A008 Expungeが完成するA008 8EXPUNGE<(A008 18EXISTS<)はコマンドを待っています。A007 STORE8+は\Deletedに旗を揚げさせます--><--A007 8ストア(旗(\Deleted\Seen))<--A007 OKストアがコマンドのための待ちを終了する、A008 EXPUNGE--、A009 LOGOUT--><--<をやめるA009 BYE IMAP3サーバ--A009 OK Logoutは近いConnectionを完成します--、><--、浅からぬ関係始まるには、戻ってください。
A more complex scenario produced by a pipelining multiprocess client.
パイプライン処理によって製作されたより複雑なシナリオはクライアントを多重処理します。
Client Server
------ ------
{Wait for Connection}
{Open session as above}
<-- A004 19 EXISTS
<-- A004 2 RECENT
<-- A004 OK Select complete
{Wait for command}
A005 SEARCH RECENT -->
<-- A005 SEARCH (18 19) (RECENT)
<---A005 OK Search complete
A006 FETCH 18:19 ALL RFC822.TEXT
A007 STORE 18:19 +FLAGS (\SEEN)
A008 FETCH 1:17 ALL -->
<-- A006 18 Fetch (... RFC822.TEXT ...)
A009 STORE 18 +FLAGS (\DELETED)
<-- A006 19 Fetch (... RFC822.TEXT ...)
<-- A006 OK Fetch complete
<-- A007 18 STORE (Flags (\Seen))
A010 STORE 19 +FLAGS (\DELETED)
<-- A007 19 STORE (Flags (\Seen))
<-- A007 OK Store complete
<-- A008 1 Fetch (......)
...
<-- A008 16 Fetch (......)
<-- A008 17 Fetch (......)
<-- A008 OK Fetch complete
<-- A009 18 STORE (Flags (\Seen
\Deleted))
クライアントサーバ------ ------ Connectionを待ってください、上の公開審議、<、--、<--A004 2RECENT<--A004 OK Selectが完成するA004 19EXISTSがコマンドを待っているA005 SEARCH RECENT--><--A005 SEARCH(18 19)(RECENT)<。---A005 OK検索完全なA006 FETCH18:19ALL RFC822.TEXT A007 STORE18:19+FLAGS(\SEEN)A008 FETCH1:17、すべて--><--A006 18Fetch(…RFC822.TEXT…) A009は18+旗(削除された\)の<を格納します--A006 19は(…RFC822.TEXT)をとって来ます。 <-- A006 OK Fetchが<--A007 18ストア(旗(\Seen))A010 STORE19+FLAGS(\DELETED)<--A007 19ストア(旗(\Seen))<--A007 OKストアの完全な<--A008 1Fetchを完成する、() ... <-- A008 16がとって来る、() <-- A008 17がとって来る、() <-- A008 OKのFetchの完全な<--A009 18ストア(旗(目にふれている\が削除した\))
Rice [Page 13] RFC 1203 IMAP3 February 1991
ライス[13ページ]RFC1203IMAP3 February 1991
<-- A009 OK Store complete
<-- A010 19 STORE (Flags (\Seen
\Deleted))
<-- A010 OK Store complete
{Wait for command}
<-- * EXISTS 23
<-- * RECENT 4
<-- * SEARCH (20 21 22 23) (RECENT)
A011 FETCH 20:23 ALL RFC822.TEXT
<、--、A009 OKストアの完全な<--A010 19ストア(旗(\Seen\Deleted))<--A010 OKストアがコマンドのための待ちを終了する<--*EXISTS23<--*RECENT4<--*検索(20 21 22 23)(RECENT)A011 FETCH20:23ALL RFC822.TEXT
Conventions
コンベンション
The following terms are used in a meta-sense in the syntax specification below:
次の用語は以下の構文仕様によるメタ意味で使用されます:
An ASCII-STRING is a sequence of arbitrary ASCII characters.
ASCII-STRINGは任意のASCII文字の系列です。
An ATOM is a sequence of ASCII characters delimited by SP or CRLF.
ATOMはSPかCRLFによって区切られたASCII文字の系列です。
A CHARACTER is any ASCII character except """", "{", CR, LF, "%",
or "\".
キャラクターがどんなASCII文字も除くということである、「「「「「「CR、LF、「%」、または「\」、」
A CRLF is an ASCII carriage-return character followed immediately
by an ASCII linefeed character.
CRLFはASCIIラインフィードキャラクタによるすぐにいうことになられたASCII復帰文字です。
A NUMBER is a sequence of the ASCII characters which represent
decimal numerals ("0" through "9"), delimited by SP, CRLF, ",", or
":".
「NUMBERが10進数字を表すASCII文字の系列である、(「「9インチ) CRLF SPによって区切られて、」を通した0インチ、」、」、:、」
A SP is the ASCII space character.
SPはASCII間隔文字です。
A TEXT_LINE is a human-readable sequence of ASCII characters up to
but not including a terminating CRLF.
TEXT_線は包含だけでないのへの終わりCRLFへのASCII文字の人間読み込み可能な系列です。
One of the most common fields in the IMAP3 protocol is a STRING,
which may be an ATOM, QUOTED-STRING (a sequence of CHARACTERs inside
double-quotes), or a LITERAL. A literal consists of an open brace
("{"), a number, a close brace ("}"), a CRLF, and then an ASCII-
STRING of n characters, where n is the value of the number inside the
brace. In general, a string should be represented as an ATOM or
QUOTED-STRING if at all possible. The semantics for QUOTED-STRING or
LITERAL are checked before those for ATOM; therefore an ATOM used in
a STRING may only contain CHARACTERs. Literals are most often sent
from the server to the client; in the rare case of a client to server
literal there is a special consideration (see the "+ text" response
below).
IMAP3プロトコルで最も一般的な分野の1つはSTRINGです。(そのSTRINGはATOM、QUOTED-STRING(二重引用符におけるCHARACTERsの系列)、またはLITERALであるかもしれません)。 A文字通り、開きの中括弧から成る、(「「)、数、近い支柱(「}」)、CRLF、および次に、nキャラクタのASCIIストリング、」。そこでは、nが支柱における数の値です。 一般に、できれば、ストリングはATOMかQUOTED-STRINGとして表されるべきです。 QUOTED-STRINGのための意味論かLITERALがそれらの前にATOMがないかどうかチェックされます。 したがって、STRINGで使用されるATOMはCHARACTERsを含むだけであるかもしれません。 サーバからクライアントに誤字誤植をたいてい送ります。 「そこの文字通りのサーバへのクライアントのまれなケースには、特別の配慮がある、(見る、」 + テキスト、」、以下での応答)
Another important field is the SEQUENCE, which identifies a set of
別の重要な分野はSEQUENCEです。(そのSEQUENCEは設定していた状態でaを特定します)。
Rice [Page 14] RFC 1203 IMAP3 February 1991
ライス[14ページ]RFC1203IMAP3 February 1991
messages by consecutive numbers from 1 to n where n is the number of messages in the mailbox. A sequence may consist of a single number, a pair of numbers delimited by colon indicating all numbers between those two numbers, or a list of single numbers and/or number pairs. For example, the sequence 2,4:7,9,12:15 is equivalent to 2,4,5,6,7,9,12,13,14,15 and identifies all of those messages.
1〜nまでの一連番号に従ったnがメールボックスの中のメッセージの数であるメッセージ。 系列は1つの数、それらの2つの番号の間のすべての数を示すコロンによって区切られた1組の数、またはただ一つの数、そして/または、数の組のリストから成るかもしれません。 例えば、系列2、4:7、9、12:15は、2、4、5、6、7、9、12、13、14、15に同等であり、それらのメッセージのすべてを特定します。
Definitions of Commands and Responses
コマンドと応答の定義
Summary of Commands and Responses
コマンドと応答の概要
Commands:
tag NOOP
tag LOGIN user password
tag LOGOUT
tag SELECT mailbox
tag CHECK
tag EXPUNGE
tag COPY sequence mailbox
tag FETCH sequence data
tag STORE sequence data value
tag SEARCH criteria
tag BBOARD bboard
tag FIND (BBOARDS / MAILBOXES) pattern
tag READONLY
tag READWRITE
tag SELECT.VERSION (major_version minor_version)
tag SELECT.FEATURES features
tag SUPPORTED.VERSIONS
tag FLAGS
tag SET.FLAGS
コマンド: タグNOOPタグLOGINユーザパスワードタグLOGOUTタグSELECTメールボックスタグCHECKタグEXPUNGEタグCOPY系列メールボックスタグFETCH系列データタグストア系列データ値のタグ検索評価基準タグBBOARD bboardタグFIND(BBOARDS / MAILBOXES)パターンタグREADONLYタグREADWRITEタグSELECT.VERSION(主要な_バージョン小さい方の_バージョン)タグSELECT.FEATURES機能タグSUPPORTED.VERSIONSタグFLAGSタグSET.FLAGS
Responses (can be either solicited or unsolicited):
*/tag FLAGS flag_list
*/tag SEARCH (numbers) (criteria)
*/tag EXISTS
*/tag RECENT
*/tag EXPUNGE
*/tag STORE data
*/tag FETCH data
*/tag BBOARD bboard_name
*/tag MAILBOX non_inbox_mailbox_name
*/tag SUPPORTED.VERSIONS version_data
*/tag READONLY
*/tag READWRITE
*/tag OK text
*/tag NO text
*/tag BAD text
応答(請求されているか、または求められていない場合があります): */、タグFLAGS旗_リスト*/タグ検索(数)(評価基準)*/タグEXISTS*/タグRECENT*/タグEXPUNGE*/タグストアデータ*/タグFETCHデータ*/タグBBOARD bboard_名前*/タグMAILBOXの非_の受信トレイ_メールボックス_名前*/タグSUPPORTED.VERSIONSバージョン_データ*/タグREADONLY*/タグREADWRITE*/タグはテキスト*/タグいいえテキスト*/タグBADテキストを承認します。
Rice [Page 15] RFC 1203 IMAP3 February 1991
ライス[15ページ]RFC1203IMAP3 February 1991
*/tag BYE text
*/タグBYEテキスト
Responses (can only be solicited):
tag COPY message_number
応答(請求できるだけです): タグCOPYメッセージ_番号
Responses (can only be unsolicited):
+ text
応答(求められていないだけである場合があります): + テキスト
Commands
コマンド
tag NOOP
タグNOOP
The NOOP command returns an OK to the client. By itself, it does
nothing, but certain things may happen as side effects. For
example, server implementations which implicitly check the mailbox
for new mail may do so as a result of this command. The primary
use of this command is to for the client to see if the server is
still alive (and notify the server that the client is still alive,
for those servers which have inactivity autologout timers).
NOOPコマンドはOKをクライアントに返します。 何もしませんが、あることは副作用として起こるかもしれません。 例えば、新しいメールがないかどうかそれとなくメールボックスをチェックするサーバ実現はこのコマンドの結果、そうするかもしれません。 クライアントが、サーバがまだ生きているかどうか(不活発自動ログアウト・タイマーを持っているそれらのサーバにおいて、クライアントがまだ生きているようにサーバに通知してください)確認するようにこのコマンドの使用がある予備選挙。
tag LOGIN user password
タグLOGINユーザパスワード
The LOGIN command identifies the user to the server and carries
the password authenticating this user. This information is used
by the server to control access to the mailboxes.
LOGINコマンドは、サーバにユーザを特定して、このユーザを認証しながら、パスワードを運びます。 この情報はサーバによって使用されて、メールボックスへのアクセスを制御します。
EXAMPLE: A001 LOGIN SMITH SESAME logs in as user SMITH with
password SESAME.
例: A001 LOGIN SMITH SESAMEはパスワードSESAMEと共にユーザスミスとしてログインします。
tag LOGOUT
タグLOGOUT
The LOGOUT command indicates the client is done with the session.
The server sends a solicited BYE response before the (tagged) OK
response, and then closes the connection.
LOGOUTコマンドは、クライアントがセッションを終えているのを示します。 サーバは、(タグ付けされる)のOK応答の前に請求されたBYE応答を送って、次に、接続を終えます。
tag SELECT mailbox
タグSELECTメールボックス
The SELECT command selects a particular mailbox. The server must
check that the user is permitted read access to this mailbox.
Prior to returning an OK to the client, the server must send an
solicited FLAGS and <n> EXISTS response to the client giving the
flags list for this mailbox (simply the system flags if this
mailbox doesn't have any special flags) and the number of messages
in the mailbox. It is also recommended that the server send a <n>
RECENT unsolicited response to the client for the benefit of
clients which make use of the number of new messages in a mailbox.
It is further recommended that servers should send an unsolicited
READONLY message if the mailbox that has been selected is not
SELECTコマンドは特定のメールボックスを選択します。 サーバは、このメールボックスへのアクセスが読まれて、ユーザが受入れられるのをチェックしなければなりません。 OKをクライアントに返す前に、サーバはこのメールボックス(単に、このメールボックスにどれか特別な旗がないなら、システムは弛む)のためのリストとメールボックスの中のメッセージの数を旗に与えるクライアントへの応答を請求されたFLAGSと<n>EXISTSに送らなければなりません。 また、サーバがクライアントの利益のためにクライアントへの>のRECENTの求められていない応答を<nに送るのも、お勧めです(メールボックスの中の新しいメッセージの数を利用します)。 選択されたメールボックスが送らないならサーバが求められていないREADONLYメッセージを送るのは、さらにお勧めです。
Rice [Page 16] RFC 1203 IMAP3 February 1991
ライス[16ページ]RFC1203IMAP3 February 1991
writable by the user.
ユーザは書き込み可能です。
Multiple SELECT commands are permitted in a session, in which case
the prior mailbox is deselected first.
複数のSELECTコマンドがセッションのときに受入れられます、その場合、先のメールボックスは最初に、反選択されます。
The default mailbox for the SELECT command is INBOX, which is a
special name reserved to mean "the primary mailbox for this user
on this server". The format of other mailbox names is operating
system dependent (as of this writing, it reflects the path of the
mailbox on the current servers), though it could reflect any
server-specific naming convention for the namespace of mailboxes.
Such a namespace need not and should not be viewed as being
equivalent or linked to the server machine's file system.
SELECTコマンドのためのデフォルトメールボックスが受信トレイである、どれが特別な名前であるかは「このサーバのこのユーザのためのプライマリメールボックス」を平均に予約しました。 他のメールボックス名の形式はオペレーティングシステムに依存しています(この書くこと現在、それはメールボックスの経路を現在のサーバに反映します)、メールボックスの名前空間のためにどんなサーバ特有の命名規則も反映するかもしれませんが。 そのような名前空間はいずれリンクして、同等であるとして見なすべきではありませんし、またサーバマシンのファイルシステムにリンクするべきである必要はありませんない。
EXAMPLES: A002 SELECT INBOX ;; selects the default mailbox.
A002 197 EXISTS ;; server says 197 messages in INBOX
A002 5 RECENT ;; server says 5 are recent.
A002 OK Select complete.
or
A003 SELECT /usr/fred/my-mail.txt
;; select a different user specified mailbox.
...
例: A002は受信トレイを選択します。 デフォルトメールボックスを選択します。 A002 197は存在しています。 サーバはINBOX A002 5RECENTの197のメッセージを言います。 サーバは、5が最近であると言います。 A002 OK Selectが. A003 SELECT/usr/fred/を完成する、私、-、mail.txt、。 異なったユーザ指定されたメールボックスを選択してください。 ...
tag CHECK
タグCHECK
The CHECK command forces a check for new messages and a rescan of
the mailbox for internal change for those implementations which
allow multiple simultaneous read/write access to the same mailbox
(e.g., TOPS-20). It is recommend that periodic implicit checks
for new mail be done by servers as well. The server must send a
solicited <n> EXISTS response prior to returning an OK to the
client.
同時の状態で倍数を許容するそれらの実装のための内的変化のためのメールボックスの再スキャンは、同じメールボックス(例えば、TOPS-20)へのアクセスをCHECKコマンドが新しいメッセージのためのチェックを強制して、読むか、または書きます。 それはまた、サーバで新しいメールのための周期的な暗黙のチェックをすることを勧めることです。 OKをクライアントに返す前に、サーバは>EXISTS応答を請求された<nに送らなければなりません。
tag EXPUNGE
タグEXPUNGE
The EXPUNGE command permanently removes all messages with the
\DELETED flag set in its flags from the mailbox. Prior to
returning an OK to the client, for each message which is removed,
a solicited <n> EXPUNGE response is sent indicating which message
was removed. The message number of each subsequent message in the
mailbox is immediately decremented by 1; this means that if the
last 5 messages in a 9-message mailbox are expunged you will
receive 5 "5 EXPUNGE" responses for message 5. To ensure mailbox
integrity and server/client synchronization, it is recommended
that the server do an implicit check prior to commencing the
expunge and again when the expunge is completed. Furthermore, if
the server allows multiple simultaneous access to the same mailbox
the server must guarantee both the integrity of the mailbox and
EXPUNGEコマンドは永久に、DELETED旗がメールボックスから旗で設定した\があるすべてのメッセージを取り除きます。 取り除かれる各メッセージのためにOKをクライアントに返す前に、請求された<n>EXPUNGE応答にどのメッセージが取り除かれたかを示させます。 メールボックスの中のそれぞれのその後のメッセージのメッセージ番号はすぐに、1つ減少します。 これはメッセージ5のためのメールボックスによる梢消されたあなたが「5は梢消する」5を受け取るということであるという9メッセージ応答における最後の5つのメッセージであるならそれを意味します。 メールボックス保全とサーバ/クライアント同期を確実にするために、サーバが始めの前に暗黙のチェックをするのが、お勧めである、梢消、再びいつ、梢消、完成されるか。 そしてその上、サーバが同じメールボックスへの複数の同時アクセスを許容するならサーバがメールボックスの保全を両方に保証しなければならない。
Rice [Page 17] RFC 1203 IMAP3 February 1991
ライス[17ページ]RFC1203IMAP3 February 1991
the views of it held by the clients.
それの視点はクライアントを固守しました。
EXPUNGE is not allowed if the user does not have write access to
this mailbox. If a user does not have write access to the mailbox
then the server is required to signal this fact by replying with a
NO response with a suitable text string that can be presented to
the user explaining that the mailbox is read-only. It is further
recommended that servers send an unsolicited READONLY message to
clients that attempt an expunge operation on a read only mailbox.
EXPUNGEはユーザであるなら許容されていません。このメールボックスへのアクセスを書かせないでください。 ユーザはaであるなら持っていません。メールボックスが書き込み禁止であると説明しながらユーザに贈ることができる適当なテキスト文字列によるいいえ応答で返答することによって、この事実に合図する次にサーバが必要であるメールボックスへのアクセスを書かせます。 サーバがクライアントへのその試みを求められていないREADONLYメッセージに送るのが、さらにお勧めである、書き込み禁止メールボックスで操作を梢消してください。
tag COPY sequence mailbox
タグCOPY系列メールボックス
The COPY command copies the specified message(s) to the specified
destination mailbox. If the destination mailbox does not exist,
the server should create it. Prior to returning an OK to the
client, the server must return a solicited <n> COPY response for
each message copied.
COPYコマンドは指定されたあて先メールボックスに指定されたメッセージをコピーします。 あて先メールボックスが存在していないなら、サーバはそれを作成するべきです。 OKをクライアントに返す前に、サーバは各メッセージのための>COPY応答がコピーした請求された<nを返さなければなりません。
EXAMPLE: A003 COPY 2:4 MEETING copies messages 2, 3, and 4 to
mailbox "MEETING".
例: A003 COPY2:4MEETINGはメールボックス「ミーティング」にメッセージ2、3、および4をコピーします。
COPY is not allowed if the user does not have write access to the
destination mailbox. If a user does not have write access to the
destination mailbox then the server is required to signal this
fact by replying with a NO response with a suitable text string
that can be presented to the user explaining that the mailbox is
read-only. It is further recommended that servers send an
unsolicited READONLY message to clients that attempt to copy to a
read only mailbox. IMAP3 does not specify "where" the message
will be put in the mailbox to which it has been copied.
COPYはユーザであるなら許容されていません。あて先メールボックスへのアクセスを書かせないでください。 ユーザはaであるなら持っていません。メールボックスが書き込み禁止であると説明しながらユーザに贈ることができる適当なテキスト文字列によるいいえ応答で返答することによって、この事実に合図する次にサーバが必要であるあて先メールボックスへのアクセスを書かせます。 サーバが書き込み禁止メールボックスにコピーするのを試みるクライアントに求められていないREADONLYメッセージを送るのは、さらにお勧めです。 IMAP3は、メッセージが「どこ」でそれをコピーしてあるメールボックスに入れられるかを指定しません。
tag FETCH sequence fetch_att
タグFETCH系列フェッチ_att
The FETCH command retrieves data associated with a message in the
mailbox. The data items to be fetched may be either a single atom
or an S-expression list. The attributes that can be fetched are
any of those mentioned specifically below along with any generic,
canonical or concrete key. The set of predefined generic keys is:
{BCC, BODY, CC, FROM, HEADER, SIZE, SUBJECT, TEXT, TO}. The set
of predefined canonical keys is {$CC, $FROM, $SUBJECT, $TO}. The
value returned by the server for a non-existent or non-meaningful
key is defined to be the null value, NIL.
FETCHコマンドはメールボックスの中のメッセージに関連しているデータを検索します。 とって来られるデータ項目は、単一原子かS-式リストのどちらかであるかもしれません。 明確に以下に言及されて、どんなジェネリック(正準であるかコンクリートのキー)と共にとって来ることができる属性はそれらのいずれでもあります。 事前に定義された総称キーのセットは以下の通りです。 BCC、ボディー、CC、ヘッダー、サイズ、対象、テキスト 事前に定義された正準なキーのセットは$CC、$FROM、$SUBJECT、$TOです。 NIL、実在しないか非重要なキーのためにサーバによって返された値は、ヌル値になるように定義されます。
ALL Equivalent to:
(FLAGS INTERNALDATE RFC822.SIZE ENVELOPE)
以下へのすべてのEquivalent (INTERNALDATE RFC822.SIZE封筒に旗を揚げさせます)
ENVELOPE The envelope of the message. The envelope is
computed by the server by parsing the header,
ENVELOPE、メッセージの封筒。 封筒は、ヘッダーを分析することによって、サーバによって計算されます。
Rice [Page 18] RFC 1203 IMAP3 February 1991
ライス[18ページ]RFC1203IMAP3 February 1991
i.e., the RFC 822 header for an RFC822 format
message, into the component parts, defaulting
various fields as necessary.
すなわち、デフォルトコンポーネントの部品に様々なRFC822形式メッセージのための822ヘッダーが必要に応じてさばくRFC。
FAST Macro equivalent to:
(FLAGS INTERNALDATE RFC822.SIZE)
以下とFAST Macro同等物 (INTERNALDATE RFC822.SIZEに旗を揚げさせます)
FLAGS The flags which are set for this message.
This may include the following system flags:
FLAGS、このメッセージに設定される旗。 これは以下のシステム旗を含むかもしれません:
\RECENT Message arrived since
last read of this mailbox
\SEEN Message has been read
\ANSWERED Message has been answered
\FLAGGED Message is "flagged" for
urgent/special attention
\DELETED Message is "deleted" for
removal by later EXPUNGE
\ANSWERED Messageによる\FLAGGED Messageが答えられているのが、後のEXPUNGEによる\DELETED Messageが「削除される」緊急の、または、特別な注意のために「旗を揚げられて」取り外しであるということであったので最後に\SEEN Messageが読み込まれたこのメールボックスについて読まれて、\RECENT Messageは到着しました。
INTERNALDATE The date and time the message was written to
the mailbox.
INTERNALDATE、メッセージがメールボックスに書かれた日時。
RFC822 The message in RFC 822 format.
RFC822、RFC822形式におけるメッセージ。
RFC822.HEADER The RFC 822 format header of the message.
RFC822.HEADER RFC822はメッセージのヘッダーをフォーマットします。
RFC822.SIZE The number of characters in the message as
expressed in RFC 822 format.
RFC822.SIZE、RFC822形式で言い表されるメッセージのキャラクタの数。
RFC822.TEXT The text body of the message, omitting the
RFC 822 header.
RFC822.TEXT、RFC822ヘッダーを省略するテキストメッセージ欄。
EXAMPLES:
例:
A003 FETCH 2:4 ALL
fetches the flags, internal date, RFC 822 size, and envelope
for messages 2, 3, and 4.
2:4がメッセージ2、3、および4のために旗、内部の期日、RFC822サイズ、および封筒をすべてとって来るA003 FETCH。
A004 FETCH 3 RFC822
fetches the RFC 822 representation for message 3.
A004 FETCH3RFC822はメッセージ3のRFC822表現をとって来ます。
A005 FETCH 4 (FLAGS RFC822.HEADER)
fetches the flags and RFC 822 format header for message 4.
A005 FETCH4(FLAGS RFC822.HEADER)はメッセージ4のために旗とRFC822形式ヘッダーをとって来ます。
A006 FETCH 42 $SUBJECT
A006 FETCH $SUBJECT "Some subject text..."
A006 OK FETCH completed ok.
fetches the canonical subject field.
A006 FETCH42ドルSUBJECT A006 FETCH$SUBJECT、「何らかの対象のテキスト」… A006 OK FETCHの完成したOK正準な対象の分野をとって来ます。
Rice [Page 19] RFC 1203 IMAP3 February 1991
ライス[19ページ]RFC1203IMAP3 February 1991
A007 FETCH 42 APPARENTLY-TO
A007 FETCH APPARENTLY-TO NIL
A007 OK FETCH found no value.
fetches the concrete apparently-to field.
A007 FETCH42APPARENTLY-TO A007 FETCH APPARENTLY-TO NIL A007 OK FETCHがどんな値にも. フェッチを見つけなかった、コンクリート、明らかである、-、分野。
tag STORE sequence data value
タグストア系列データ価値
The STORE command alters the values associated with particular
keys for a message in the mailbox. As is the case for the FETCH
command, any generic, canonical or concrete key may be used to
index the value provided. In addition to these, the following
pre-defined keys are provided.
ストアコマンドはメールボックスの中のメッセージのために特定のキーに関連している値を変更します。 FETCHコマンド、どんなジェネリックのためのケースのようにも、正準であるかコンクリートのキーは、提供された値に索引をつけるのに使用されるかもしれません。 これらに加えて、以下の事前に定義されたキーを提供します。
FLAGS Replace the flags for the message with the
argument (in flag list format).
The server must respond with a solicited STORE FLAGS
message, showing the new state of the flags after
the store.
FLAGS Replace、主張(現役将官名簿形式における)があるメッセージのための旗。 店の後に旗の新しい状態を見せて、サーバは請求されたSTORE FLAGSメッセージで反応しなければなりません。
+FLAGS Add the flags in the argument to the
message's flag list.
The server must respond with a solicited STORE FLAGS
message, showing the new state of the flags after
the store.
+ メッセージの旗への議論における旗が記載するFLAGS Add。 店の後に旗の新しい状態を見せて、サーバは請求されたSTORE FLAGSメッセージで反応しなければなりません。
-FLAGS Remove the flags in the argument from the
message's flag list.
The server must respond with a solicited STORE FLAGS
message, showing the new state of the flags after
the store.
-メッセージの旗からの議論における旗が記載するFLAGS Remove。 店の後に旗の新しい状態を見せて、サーバは請求されたSTORE FLAGSメッセージで反応しなければなりません。
RFC822.HEADER Replace the header of the message(s) with that
specified. This allows users to use their mailboxes
as databases with header fields as keys.
The server must respond with solicited
STORE RFC822.HEADER, STORE RFC822.SIZE and
STORE ENVELOPE messages, showing the new state
of the reparsed header after the store.
それがあるメッセージのヘッダーのRFC822.HEADER Replaceは指定しました。 これで、ユーザはデータベースとしてキーとしてのヘッダーフィールドで彼らのメールボックスを使用できます。 サーバは請求されたSTORE RFC822.HEADER、STORE RFC822.SIZE、およびSTORE ENVELOPEメッセージで反応しなければなりません、店の後に再分析されたヘッダーの新しい状態を見せて。
RFC822.TEXT Replace the body of the messages with that specified.
The server must respond with solicited
STORE RFC822.TEXT and STORE RFC822.SIZE messages,
showing the new state of the message after the store.
それがあるメッセージ欄が指定したRFC822.TEXT Replace。 サーバは請求されたSTORE RFC822.TEXTとSTORE RFC822.SIZEメッセージで反応しなければなりません、店の後にメッセージの新しい状態を見せて。
STORE is not allowed if the user does not have write access to
this mailbox.
ストアはユーザであるなら許容されていません。このメールボックスへのアクセスを書かせないでください。
The server is required to send a solicited STORE response for
サーバが、請求されたストア応答を送るのに必要です。
Rice [Page 20] RFC 1203 IMAP3 February 1991
ライス[20ページ]RFC1203IMAP3 February 1991
each store operation that results in a format transformation by
the server. For example, the server is required to send a
STORE FLAGS response when the client performs a STORE +FLAGS or
a STORE -FLAGS, since the client may not easily be able to know
what the result of this command will be. Similarly, if the
client emits a STORE FROM command then the server should
respond with a suitable STORE FROM response because the client
would be sending a string value to be stored and the server
should transform this into a set of addresses. In general,
however, although it is legal for the server to send a
solicited STORE response for each STORE operation, this is
discouraged, since it might result in the retransmission of
very large and unnecessary amounts of data that have been
stored.
クライアントであるときにSTORE FLAGS応答を送る. 例えばサーバが必要であるサーバで形式変換をもたらす各店舗運営がストア+FLAGSかストア-FLAGSを実行します、クライアントが、このコマンドの結果が何になるかを容易に知ることができないかもしれないので。 同様に、クライアントがSTORE FROMコマンドを放つなら、クライアントが保存されるためにストリング値を送って、サーバがこれを1セットのアドレスに変えるべきであるので、サーバは適当なSTORE FROM応答で反応するべきです。 しかしながら、一般に、サーバがそれぞれのストア操作のための請求されたストア応答を送るのが、法的ですが、これはがっかりしています、保存された非常に大きくて不要な量のデータの「再-トランスミッション」をもたらすかもしれないので。
EXAMPLE: A003 STORE 2:4 +FLAGS (\DELETED) marks messages 2, 3,
and 4 for deletion.
例: A003 STORE2:4+FLAGS(\DELETED)は、削除のためにメッセージが2と、3と、4であるとマークします。
tag SEARCH search_criteria
タグ検索検索_評価基準
The SEARCH command searches the mailbox for messages which match
the given set of criteria. The server response SEARCH (criteria)
(numbers) gives the set of messages which match the conjunction of
the criteria specified. In addition to each of the search
criteria there is its logical inverse. The logical inverse
criterion is denoted by the ~ (tilda) sign.
検索命令は与えられたセットの評価基準に合っているメッセージのためにメールボックスを捜します。 検索(評価基準)(数)が評価基準の接続詞に合っているメッセージのセットに与えるサーバ応答は指定しました。 それぞれの検索評価基準に加えて、論理的な逆があります。 論理的な逆さの評価基準は~tilda()サインによって指示されます。
Thus, no message that matches the criterion:
FROM crispin
その結果、評価基準に合っているメッセージがありません: FROM crispin
will match the criterion:
~FROM crispin
評価基準を合わせるでしょう: ~FROM crispin
The criteria for the search can be any generic, canonical or
concrete key. In addition to these, the following pre-defined
keys are also provided:
検索の評価基準はどんなジェネリック、正準であるかコンクリートのキーであるかもしれません。 また、これらに加えて、以下の事前に定義されたキーを提供します:
ALL All messages in the mailbox; the default
initial criterion for ANDing.
メールボックスの中のすべてのAllメッセージ。 デフォルトはANDingのために評価基準に頭文字をつけます。
ANSWERED Messages with the \ANSWERED flag set.
ANSWEREDが旗を揚げさせる\があるANSWERED Messagesはセットしました。
BCC string Messages which contain the specified string
in the envelope's BCC field.
封筒のBCC分野に指定されたストリングを保管しているストリングMessagesをBCCしてください。
BEFORE date Messages whose internal date is earlier than
the specified date.
BEFOREは期日指定された期日より内部の前半であるMessagesとデートします。
Rice [Page 21] RFC 1203 IMAP3 February 1991
ライス[21ページ]RFC1203IMAP3 February 1991
BODY string Messages which contain the specified string
in the body of the message.
BODYはメッセージ欄に指定されたストリングを含むMessagesを結びます。
CC string Messages which contain the specified string
in the envelope's CC field.
封筒のCC分野に指定されたストリングを保管しているストリングMessagesをCCしてください。
DELETED Messages with the \DELETED flag set.
DELETEDが旗を揚げさせる\があるDELETED Messagesはセットしました。
FLAGGED Messages with the \FLAGGED flag set.
FLAGGEDが旗を揚げさせる\があるFLAGGED Messagesはセットしました。
FROM string Messages which contain the specified string
in the envelope's FROM field.
FROMは封筒のFROM分野に指定されたストリングを保管しているMessagesを結びます。
HEADER string Messages which contain the specified string
in the message header.
HEADERはメッセージヘッダーに指定されたストリングを含むMessagesを結びます。
KEYWORD flag Messages with the specified flag set.
指定された旗があるKEYWORD旗のMessagesはセットしました。
NEW Messages which have the \RECENT flag set but
not the \SEEN flag. This is functionally
equivalent to "RECENT UNSEEN".
RECENTが旗を揚げさせる\を持っているNEW Messagesがセットしましたが、どんな\SEENも弛みません。 これが機能上相当している、「最近、見えなさ、」
OLD Messages which do not have the \RECENT flag
set.
RECENTが旗を揚げさせる\を持っていないOLD Messagesがセットしました。
ON date Messages whose internal date is the same as
the specified date.
ONは内部の期日が指定された期日と同じであるMessagesとデートします。
RECENT Messages which have the \RECENT flag set.
RECENTが旗を揚げさせる\を持っているRECENT Messagesがセットしました。
SEEN Messages which have the \SEEN flag set.
SEENが旗を揚げさせる\を持っているSEEN Messagesがセットしました。
SINCE date Messages whose internal date is later than
the specified date.
SINCEは内部の期日が指定された期日より遅いMessagesとデートします。
SUBJECT string Messages which contain the specified string
in the envelope's SUBJECT field.
SUBJECTは封筒のSUBJECT分野に指定されたストリングを保管しているMessagesを結びます。
TEXT string Messages which contain the specified string.
TEXTは指定されたストリングを含むMessagesを結びます。
TO string Messages which contain the specified string in
the envelope's TO field.
TOは封筒のTO分野に指定されたストリングを保管しているMessagesを結びます。
EXAMPLE: A003 SEARCH DELETED FROM "SMITH" SINCE 1-OCT-87
returns the message numbers for all deleted messages from Smith
that were placed in the mailbox since October 1, 1987.
例: 1 10月の87以来のA003検索DELETED FROM「スミス」はメッセージを1987年10月1日以来メールボックスに置かれたスミスからすべての数が削除したメッセージに返します。
Implementation note: The UNANSWERED, UNDELETED, UNFLAGGED,
実装注意: 答えのなさ、UNDELETED、UNFLAGGED
Rice [Page 22] RFC 1203 IMAP3 February 1991
ライス[22ページ]RFC1203IMAP3 February 1991
UNKEYWORD and UNSEEN criteria, described below, are preserved in
IMAP3 for IMAP2 compatibility. They are, however, considered
obsolete and new Client programs are encouraged to use the ~
notation for the logical inverses of search criteria with a view
to the dropping of this outmoded syntax in later versions.
以下で説明されたUNKEYWORDとUNSEEN評価基準はIMAP2の互換性のためにIMAP3に保存されます。 しかしながら、それらは時代遅れであると考えられます、そして、新しいClientプログラムが後のバージョンの、この時代遅れな構文の低下検索評価基準の論理的な逆に~記法を使用するよう奨励されます。
UNANSWERED Messages which do not have the \ANSWERED flag
set.
ANSWEREDが旗を揚げさせる\を持っていないUNANSWERED Messagesがセットしました。
UNDELETED Messages which do not have the \DELETED flag
set.
DELETEDが旗を揚げさせる\を持っていないUNDELETED Messagesがセットしました。
UNFLAGGED Messages which do not have the \FLAGGED flag
set.
FLAGGEDが旗を揚げさせる\を持っていないUNFLAGGED Messagesがセットしました。
UNKEYWORD flag Messages which do not have the specified flag
set.
指定された旗を持っていないUNKEYWORD旗のMessagesがセットしました。
UNSEEN Messages which do not have the \SEEN flag set.
SEENが旗を揚げさせる\を持っていないUNSEEN Messagesがセットしました。
tag READONLY
タグREADONLY
The READONLY command indicates that the client wishes to make the
mailbox read-only. The server is required to reply with a
solicited READONLY or READWRITE response.
READONLYコマンドは、クライアントがメールボックス書き込み禁止を作りたがっているのを示します。 サーバが、請求されたREADONLYかREADWRITE応答で返答するのに必要です。
tag READWRITE
タグREADWRITE
The READWRITE command indicates that the client wishes to make the
mailbox read-write. The server is required to reply with a
solicited READONLY or READWRITE response.
READWRITEコマンドは、クライアントが、-読まれて、メールボックスを作るために、書くように願っているのを示します。 サーバが、請求されたREADONLYかREADWRITE応答で返答するのに必要です。
tag SUPPORTED.VERSIONS
タグSUPPORTED.VERSIONS
The SUPPORTED.VERSIONS solicits from the server a
SUPPORTED.VERSIONS message, which encapsulates information about
which versions and features the server supports.
SUPPORTED.VERSIONSはサーバからSUPPORTED.VERSIONSメッセージに請求します。(それは、どのバージョンに関して情報をカプセル化するか、そして、サーバサポートを特徴とします)。
tag SELECT.VERSION (major_version minor_version)
タグSELECT.VERSION(主要な_バージョン小さい方の_バージョン)
The SELECT.VERSION command indicates that the client wishes to
select certain behavior on the part of the server. The major and
minor versions indicate the specific version of the protocol being
selected.
SELECT.VERSIONコマンドは、クライアントがサーバ側のある振舞いを選択したがっているのを示します。主要で小さい方のバージョンは選択されるプロトコルの特定のバージョンを示します。
EXAMPLE: A002 SELECT.VERSION (3 0)
例: A002 SELECT.VERSION(3 0)
A client may not request a server version that is not supported by
クライアントはそれがサポートされないサーババージョンを要求しないかもしれません。
Rice [Page 23] RFC 1203 IMAP3 February 1991
ライス[23ページ]RFC1203IMAP3 February 1991
the server, i.e., which is specifically mentioned in the response
to a SUPPORTED.VERSIONS command. An attempt to do so by a client
will result in a NO response from the server. It is an error for
the SELECT.VERSION command to be used after a mailbox has been
selected. The rationale for this is that for some server
implementations it might be necessary to spawn separate programs
to implement widely divergent protocol versions. Thus, the client
cannot be allowed to expect any server state to be preserved after
the use of the SELECT.VERSION command. The default version of all
servers is 2.0, i.e., IMAP2 as defined by RFC 1064.
サーバでありSUPPORTED.VERSIONSへの応答で言及されて、すなわち、どれが明確にそうかは命令します。 クライアントでそうする試みはサーバからのいいえ応答をもたらすでしょう。それはメールボックスが選択された後に使用されるべきSELECT.VERSIONコマンドのための誤りです。 これのための原理はいくつかのサーバ実装に、広く分岐しているプロトコルバージョンを実装するために別々のプログラムを量産するのが必要であるかもしれないということです。 したがって、クライアントは、どんなサーバ状態もSELECT.VERSIONコマンドの使用の後に保持されると予想できません。 すべてのサーバのデフォルトバージョンはすなわち、2.0、RFC1064によって定義されるIMAP2です。
tag SELECT.FEATURES 1#features
タグSELECT.FEATURES1#の特徴
The SELECT.FEATURES command indicates that the client wishes to
select certain specific features on the part of the server. A
client may not request a feature that is not supported by the
server, i.e., one that is explicitly mentioned in the set of
features for the selected version returned by the
SUPPORTED.VERSIONS command. An attempt to do so by a client will
result in a NO response from the server.
SELECT.FEATURESコマンドは、クライアントがサーバ側のある特定の特徴を選択したがっているのを示します。クライアントはサーバによってサポートされない特徴を要求しないかもしれません、すなわち、SUPPORTED.VERSIONSコマンドで返された選択されたバージョンのための特徴のセットで明らかに言及するもの。 クライアントでそうする試みはサーバからのいいえ応答をもたらすでしょう。
EXAMPLE: A002 SELECT.FEATURES AUTO.SET.SEEN ~TAGGED.SOLICITED
EIGHT.BIT.TRANSPARENT
例: A002 SELECT.FEATURES AUTO.SET.SEEN~TAGGED.SOLICITED EIGHT.BIT.TRANSPARENT
i.e., select the set of features called AUTO.SET.SEEN and
EIGHT.BIT.TRANSPARENT and deselect the feature called
TAGGED.SOLICITED. The use of the SELECT.FEATURES command
completely resets the set of selected features. Note: These are
only example feature names and are not necessarily supported by
any server. See the appendix on features for more information on
features. Note: Some features, when present in the server, will
cause the upwards compatible extension of the grammar, i.e., by
adding extra commands. The server is at liberty not to remove
these upwards compatible extensions to the command tables when a
feature is disabled. Thus, it is an error for a client to rely on
getting a NO or BAD response in any way, for instance to determine
the selectedness or presence of a feature.
すなわち、特徴がTAGGED.SOLICITEDと呼んだAUTO.SET.SEEN、EIGHT.BIT.TRANSPARENT、およびdeselectと呼ばれる特徴のセットを選択してください。 SELECT.FEATURESコマンドの使用は選択された特徴のセットを完全にリセットします。 以下に注意してください。 これらは、例の特徴名だけであり、必ずどんなサーバによってもサポートされるというわけではありません。詳しい情報のための特徴の特徴の付録を見てください。 以下に注意してください。 サーバで存在しているとき、いくつかの特徴が文法の上向きにコンパチブル拡大を引き起こすでしょう、すなわち、付加的なコマンドを加えることによって。 サーバは、特徴が障害があるとき、これらの上向きにコンパチブル拡大をコマンド表に移さないように自由です。 したがって、それは何らかの方法で、例えば、特徴の選択か存在を決定するためにノーかBAD応答を得るクライアントが依存する誤りです。
tag BBOARD bboard
タグBBOARD bboard
The BBOARD command is equivalent to SELECT, except that its
argument is a bulletin board (BBoard) name. The format of a
BBoard name is implementation specific, although it is strongly
encouraged to use something that resembles a name in a generic
sense and not a file or mailbox name on the particular system.
There is no requirement that a BBoard name be a mailbox name or a
file name (in particular, Unix netnews has a completely different
namespace from mailbox or file names).
議論が掲示板(BBoard)の名であるのを除いて、BBOARDコマンドはSELECTに同等です。 BBoard名の形式は実装特有です、特定のシステムの上でファイルかメールボックス名ではなく、ジェネリック意味で名前に類似している何かを使用するよう強く奨励されますが。 BBoard名がメールボックス名かファイル名であるという要件が全くありません(Unixネットニュースには、特に、メールボックスかファイル名からの完全に異なった名前空間があります)。
Rice [Page 24] RFC 1203 IMAP3 February 1991
ライス[24ページ]RFC1203IMAP3 February 1991
The result from the BBOARD command is identical from that of the
SELECT command. For example, in the TOPS-20 server
implementation, the command
A0002 BBOARD FOO
is exactly equivalent to the command
A0002 SELECT POBOX:<BBOARD>FOO.TXT
Note: the equivalence in this example is *not* required by the
protocol, and merely reflects the fuzzy distinction between
mailboxes and BBoards on TOPS-20.
BBOARDコマンドからの結果はSELECTコマンドのものから同じです。 例えば、TOPS-20サーバ実装では、コマンドA0002 BBOARD FOOはまさにA0002 SELECT POBOX: コマンド<BBOARD>FOO.TXT Noteに同等です: この例の等価性は、*でないのがプロトコルで必要とした*であり、単にメールボックスとBBoardsのあいまいな区別をTOPS-20に反映します。
tag FIND (BBOARDS / MAILBOXES) pattern
タグFIND(BBOARDS / MAILBOXES)パターン
The FIND command accepts as arguments the keywords BBOARDS or
MAILBOXES and a pattern which specifies some set of BBoard/mailbox
names which are usable by the BBOARD/SELECT command. Two wildcard
characters are defined; "*" specifies that any number (including
zero) characters may match at this position and "%" specifies that
a single character may match at this position. For example,
FOO*BAR will match FOOBAR, FOOD.ON.THE.BAR and FOO.BAR, whereas
FOO%BAR will match only FOO.BAR; furthermore, "*" will match all
BBoards/mailboxes. The following quoting convention applies to
wildcards: "\*" is the literal "*" character, "\%" is the literal
"%" character and "\\" is the literal "\" character. Notes: The
format of mailboxes is server implementation dependent. The
special mailbox name INBOX is not included in the output to the
FIND MAILBOXES command.
Findコマンドは議論としてキーワードBBOARDSかMAILBOXESと何らかのセットのBBOARD/SELECTコマンドで使用可能なBBoard/メールボックス名を指定するパターンを認めます。 2つのワイルドカードキャラクタが定義されます。 「*」は、どんな数(ゼロを含んでいる)のキャラクタもこの位置で合うかもしれなくて、「%」が、単独のキャラクタがこの位置で合うかもしれないと指定すると指定します。 例えば、FOO*BARはFOOBAR、FOOD.ON.THE.BAR、およびFOO.BARに合うでしょうが、FOO%BARはFOO.BARだけに合うでしょう。 その上、「*」はすべてのBBoards/メールボックスに合うでしょう。 以下の引用コンベンションはワイルドカードに適用されます: 「「\*」は文字通りの「*」キャラクタです」、\%」 リテラルが「%」であるというキャラクタと」 \\、」 文字通りの「\」はキャラクタですか? 注意: メールボックスの形式はサーバ実装に依存しています。 受信トレイという特別なメールボックス名は出力でFIND MAILBOXESコマンドに含められていません。
The FIND command solicits any number of BBOARD or MAILBOX
responses from the server as appropriate.
FindコマンドはサーバからいろいろなBBOARDかMAILBOX応答に適宜請求します。
Examples:
A0002 FIND BBOARDS *
A0002 BBOARD FOOBAR
A0002 BBOARD GENERAL
A0002 OK FIND completed
or
A0002 FIND MAILBOXES FOO%BA*
A0002 MAILBOX FOO.BAR
A0002 MAILBOX FOO.BAZZAR
A0002 OK FIND completed
例: A0002 BBOARD FOOBAR A0002 BBOARD GENERAL A0002 OK FINDが完成したA0002 FIND BBOARDS*かA0002 MAILBOX FOO.BAR A0002 MAILBOX FOO.BAZZAR A0002 OK FINDが完成したA0002 FIND MAILBOXES FOO%BA*
Note: Although the use of explicit file or path names for
mailboxes is discouraged by this standard, it may be unavoidable.
It is important that the value returned in the MAILBOX solicited
reply be usable in the SELECT command without remembering any path
specification which may have been used in the FIND MAILBOXES
pattern.
以下に注意してください。 明白なファイルかパス名のメールボックスの使用はこの規格でお勧めできないのですが、それは避けられないかもしれません。 請求されたMAILBOXで返された値が使用可能なコネがFIND MAILBOXESパターンで使用されたどんな経路仕様も覚えていることのないSELECTコマンドであったなら返答するのは、重要です。
Rice [Page 25] RFC 1203 IMAP3 February 1991
ライス[25ページ]RFC1203IMAP3 February 1991
tag FLAGS
タグFLAGS
The FLAGS command solicits a FLAGS response from the server.
FLAGSコマンドはサーバからFLAGS応答に請求します。
tag SET.FLAGS flag_list
タグSET.FLAGS旗_リスト
The SET.FLAGS command defines the user specifiable flags for this
mailbox, i.e., the keywords. If this set does not include flags
formerly sent to the client by the server in a FLAGS message then
this constitutes a request to delete the flag. Any new flags
should be created. This command does not affect the system
defined flags and any system flags that are included in the
flag_list will be ignored. The server must respond to this
command with a solicited FLAGS message. If the deletion of a flag
results in the invalidation of the flag sets of any messages then
the server is required to send solicited STORE FLAGS messages to
the client for each modified message.
SET.FLAGSコマンドはすなわち、このメールボックス、キーワードのためにユーザの明記できる旗を定義します。 このセットがFLAGSメッセージに以前サーバによってクライアントに送られた旗を含んでいないなら、これは旗を削除するという要求を構成します。 どんな新しい旗も作成されるべきです。 このコマンドはシステムの定義された旗に影響しません、そして、旗_リストに含まれているどんなシステム旗も無視されるでしょう。 サーバは請求されたFLAGSメッセージでこのコマンドに反応しなければなりません。 旗の削除がどんなメッセージの旗のセットも無効にするのをもたらすなら、サーバが、それぞれの変更されたメッセージのために請求されたSTORE FLAGSメッセージをクライアントに送るのに必要です。
Responses:
応答:
*/tag OK text
*/タグOKテキスト
In its solicited form this response identifies successful
completion of the command with the indicated tag. The text is a
line of human-readable text which may be useful in a protocol
telemetry log for debugging purposes.
請求されたフォームでは、この応答はコマンドの無事終了を示されたタグと同一視します。 テキストはデバッグ目的のためのプロトコル遠隔測定法のログで役に立つかもしれない人間読み込み可能なテキストの系列です。
In its unsolicited form, this response indicates simply that the
server is alive. No special action on the part of the client is
called for. This is presently only used by servers at startup as
a greeting message indicating that they are ready to accept the
first command. This usage, although legal, is by no means
required. The text is a line of human-readable text which may be
logged in protocol telemetry.
求められていないフォームでは、この応答は、サーバが生きているのを単に示します。 クライアント側のどんな特別な動きも求められません。 これは現在、それらが最初のコマンドを受け入れる準備ができているのを示すあいさつメッセージとして始動でサーバによって使用されるだけです。 法的ですが、この用法は決して必要ではありません。 テキストはプロトコル遠隔測定法で登録されるかもしれない人間読み込み可能なテキストの系列です。
*/tag NO text
*/タグいいえテキスト
In its solicited form this response identifies unsuccessful
completion of the command with the indicated tag. The text is a
line of human-readable text which probably should be displayed to
the user in an error report by the client.
請求されたフォームでは、この応答はコマンドの失敗の完成を示されたタグと同一視します。 テキストはたぶんクライアントによるエラー・レポートにユーザに表示されるべきである人間読み込み可能なテキストの系列です。
In its unsolicited form this response indicates some operational
error at the server which cannot be traced to any protocol
command. The text is a line of human-readable text which should
be logged in protocol telemetry for the maintainer of the server
and/or the client.
求められていないフォームでは、この応答はどんなプロトコルコマンドにもたどることができないサーバで何らかの誤操作を示します。 テキストはサーバ、そして/または、クライアントの維持装置のためにプロトコル遠隔測定法で登録されるべきである人間読み込み可能なテキストの系列です。
Rice [Page 26] RFC 1203 IMAP3 February 1991
ライス[26ページ]RFC1203IMAP3 February 1991
*/tag BAD text
*/タグBADテキスト
In its solicited form response indicates faulty protocol received
from the client and indicates a bug. The text is a line of
human-readable text which should be recorded in any telemetry as
part of a bug report to the maintainer of the client.
請求されたフォームでは、応答は、不完全なプロトコルがクライアントから受信されたのを示して、バグを示します。 テキストはクライアントの維持装置へのバグレポートの一部としてどんな遠隔測定法にも記録されるべきである人間読み込み可能なテキストの系列です。
In its unsolicited form response indicates some protocol error at
the server which cannot be traced to any protocol command. The
text is a line of human-readable text which should be logged in
protocol telemetry for the maintainer of the server and/or the
client. This generally indicates a protocol synchronization
problem, and examination of the protocol telemetry is advised to
determine the cause of the problem.
求められていないフォーム応答では、どんなプロトコルコマンドにもたどることができないサーバにおける何らかのプロトコル誤りを示します。 テキストはサーバ、そして/または、クライアントの維持装置のためにプロトコル遠隔測定法で登録されるべきである人間読み込み可能なテキストの系列です。 一般に、これはプロトコル同期問題を示します、そして、プロトコル遠隔測定法の試験が問題の原因を決定するように教えられます。
*/tag BYE text
*/タグBYEテキスト
This indicates that the server is about to close the connection.
The text is a line of human-readable text which should be
displayed to the user in a status report by the client. IMAP2
requires that the server emit a solicited BYE response as part of
a normal logout sequence. This solicited form is not required
under IMAP3, though is still legal for compatibility. In its
unsolicited form the BYE response is used as a panic shutdown
announcement by the server. It is required to be used by any
server which performs autologouts due to inactivity.
これは、サーバが接続を終えようとしているのを示します。 テキストは現状報告にクライアントによってユーザに表示されるべきである人間読み込み可能なテキストの系列です。 IMAP2は、標準の一部がログアウトするときサーバが請求されたBYE応答を放つのを必要とします。系列。 もっとも、この請求されたフォームはIMAP3の下で必要でない、互換性に、法的なスチール写真がそうです。 求められていないフォームでは、BYE応答はパニック閉鎖発表としてサーバによって使用されます。それが、不活発のためautologoutsを実行するどんなサーバでも使用されるのに必要です。
*/tag number message_data
*/タグ数メッセージ_データ
The solicited (tag number message_data) response is generated as
the result of a number of client requests. The server may also
emit any the following at any time as unsolicited data (i.e., *
number message_data). The message_data is one of the following:
請求された(タグ数のメッセージ_データ)応答は多くのクライアント要求の結果として生成されます。 サーバはそうするかもしれません、また、いずれも放ってください。いつでも求められていないデータ(すなわち、*数メッセージ_データ)として以下。 メッセージ_データは以下の1つです:
EXISTS The specified number of messages exists in the mailbox.
指定が付番するメッセージのEXISTSはメールボックスの中に存在しています。
RECENT The specified number of messages have arrived since the
last time this mailbox was selected with the SELECT
command or equivalent.
RECENT、このメールボックスが最後の時間SELECTコマンドか同等物で選択されて以来、メッセージの指定された数は到着しています。
EXPUNGE The specified message number has been permanently
removed from the mailbox, and the next message in the
mailbox (if any) becomes that message number.
The server must send a solicited EXPUNGE response
for each message that it expunges as the result
of an EXPUNGE command. Note: future versions of the
protocol may allow the use of a message sequence
as a value returned by the EXPUNGE response to allow the
EXPUNGE、指定されたメッセージ番号は永久に、メールボックスから移されて、メールボックス(もしあれば)の中の次のメッセージはそのメッセージ番号になります。 サーバはそれがEXPUNGEコマンドの結果として梢消する各メッセージのための請求されたEXPUNGE応答を送らなければなりません。 以下に注意してください。 許容するEXPUNGE応答で値が戻ったので、プロトコルの将来のバージョンはメッセージ系列の使用を許すかもしれません。
Rice [Page 27] RFC 1203 IMAP3 February 1991
ライス[27ページ]RFC1203IMAP3 February 1991
more efficient compaction of client representations of
mailboxes.
メールボックスのクライアント表現の、より効率的な圧縮。
STORE data
Functionally equivalent to FETCH, only it is sent by the
server when the state of a mailbox changes. The server
must send solicited STORE responses as the result of
any change caused by a STORE command.
FETCHに同等なストアデータFunctionally、メールボックスの状態が変化するとき、サーバはそれだけを送ります。 サーバはストアコマンドで引き起こされたどんな変化の結果としても請求されたストア応答を送らなければなりません。
FETCH data
This is the principle means by which data about a
message is sent to the client. The data is in a
Lisp-like S-expression property list form. Just as the
FETCH request from the client can fetch any generic,
canonical or concrete key, so also the FETCH response
can return values for any of these keys as well as for
the pre-defined attributes mentioned below. Note that
the server is permitted to send any unsolicited FETCH
or STORE messages that it should choose, be they the
values associated with generic, canonical or concrete
keys. Clients are required to ignore any such
FETCH responses that it cannot interpret. For example,
clients are not required to be able to understand, i.e.,
use fruitfully, the canonical $TO key, but they are
required to be able to ignore an unsolicited $TO message
correctly.
FETCHデータThisはメッセージに関するデータがクライアントに送られる原則手段です。 データがLispのようなS-式特性のリスト形式にあります。 また、ちょうどクライアントからのFETCH要求がどんなジェネリック、正準であるかコンクリートのキーもとって来ることができるように、FETCH応答はこれらのキーのどれかと以下に言及された事前に定義された属性のために値を返すことができます。 サーバがどんな求められていないFETCHやストアにも選ぶべきであるというメッセージを送ることが許可されていることに注意してください、それらがジェネリックに関連している値であったなら、正準であるかコンクリートのキー。 クライアントは解釈できないくらいのどんなFETCH応答も無視しなければなりません。 例えば、すなわち、クライアントは、実り多さを使用するように理解する必要はないことができます、正準な$TOキー、しかし、彼らは正しく求められていない$TOメッセージを無視できなければなりません。
ENVELOPE An S-expression format list which describes the
envelope of a message. The envelope is computed
by the server by parsing the RFC 822 header into
the component parts, defaulting various fields
as necessary.
メッセージの封筒について説明するENVELOPE An S-式形式リスト。 封筒は、RFC822ヘッダーのコンポーネントの部品(必要に応じてデフォルト多岐)を分析することによって、サーバによって計算されます。
The fields of the envelope are in the following
order: date, subject, from, sender, reply-to, to,
cc, bcc, in-reply-to, and message-id. The date,
subject, in-reply-to, and message-id fields are
strings. The from, sender, reply-to, to, cc,
and bcc fields are lists of addresses.
封筒の分野が以下のオーダーにあります: に対して日付、対象、送付者、答え、cc、bcc、イドを通信させます。 に対して日付、対象、メッセージイド分野はストリングです。 cc、およびbcc分野はそうです。送付者、答え、アドレスのリスト。
An address is an S-expression format list which
describes an electronic mail address. The fields
of an address are in the following order:
personal name, source-route (i.e., the
at-domain-list in SMTP), mailbox name, host name
and comments. Implementation note: The addition
of the comment field is an incompatible extension
from IMAP2. The server is required not to provide
アドレスは電子メールアドレスについて説明するS-式形式リストです。 アドレスの分野が以下のオーダーにあります: 個人名、送信元経路(すなわち、ドメインリストSMTP)、メールボックス名、ホスト名、およびコメント。 実装注意: 注釈欄の追加はIMAP2からの両立しない拡大です。 サーバが、提供しないように必要です。
Rice [Page 28] RFC 1203 IMAP3 February 1991
ライス[28ページ]RFC1203IMAP3 February 1991
this field when running in IMAP2 mode.
これは、IMAP2モードへ駆け込みながら、いつをさばくか。
Any field of an envelope or address which is
not applicable is presented as the atom NIL.
Note that the server must default the reply-to
and sender fields from the from field; a client is
not expected to know to do this.
適切でない封筒かアドレスのどんな分野も原子NILとして提示されます。 サーバがデフォルトとしなければならないことに注意してください、答え、送付者分野、分野から。 クライアントが、これをするのを知らないと予想されます。
FLAGS An S-expression format list of flags which are set
for this message. This may include the following
system flags:
このメッセージに設定される旗のFLAGS An S-式形式リスト。 これは以下のシステム旗を含むかもしれません:
\RECENT Message arrived since last
read of this mailbox
\SEEN Message has been read
\ANSWERED Message has been answered
\FLAGGED Message is "flagged" for
urgent/special attention
\DELETED Message is "deleted" for
removal by later EXPUNGE
\ANSWERED Messageによる\FLAGGED Messageが答えられているのが、後のEXPUNGEによる\DELETED Messageが「削除される」緊急の、または、特別な注意のために「旗を揚げられて」取り外しであるということであったので最後に\SEEN Messageが読み込まれたこのメールボックスについて読まれて、\RECENT Messageは到着しました。
INTERNALDATE A string containing the date and time the
message was written to the mailbox.
メッセージがメールボックスに書かれた日時を含むINTERNALDATE五弦。
RFC822 A string expressing the message in RFC 822
format.
Note: Some implementations of IMAP2 servers
had the (undocumented) behavior of setting
the \SEEN flag as a side effect of fetching
the body of a message. This resulted in
erroneous behavior for clients that prefetch
messages that the user might not get
around to reading. Thus, this behavior is
explicitly disallowed in IMAP3.
Note: this is not a significant performance
restriction because it is always possible for
IMAP3 clients to use an interaction with the
server of the following type:
A001 FETCH 42 RFC822
A002 STORE 42 +FLAGS (\SEEN)
A001 42 FETCH RFC822 {637} ......
A001 OK Fetch completed
A002 42 STORE FLAGS (\SEEN \FLAGGED...)
A002 OK Store Completed.
RFC822形式におけるメッセージを言い表すRFC822五弦。 以下に注意してください。 IMAP2サーバのいくつかの実装には、SEENがメッセージのボディーをとって来る副作用として旗を揚げさせる\を設定する(正式書類のない)の振舞いがありました。 これはユーザが読書まで逃れないかもしれない先取りが通信させるクライアントにとって、誤った振舞いをもたらしました。 したがって、この振舞いはIMAP3で明らかに禁じられます。 以下に注意してください。 IMAP3クライアントが以下のタイプのサーバとの相互作用を使用するのが、いつも可能であるので、これは重要な性能制限ではありません: A001フェッチ42RFC822 A002店42+旗(見られた\)のA001 42はRFC822 637をとって来ます… A001 OK FetchはA002 42STORE FLAGS(\SEEN\FLAGGED…)を完成しました。 A002は完成したストアを承認します。
RFC822.HEADER A string expressing the RFC 822 format
header of the message
メッセージのRFC822形式ヘッダーを急送するRFC822.HEADER五弦
Rice [Page 29] RFC 1203 IMAP3 February 1991
ライス[29ページ]RFC1203IMAP3 February 1991
RFC822.SIZE A number indicating the number of
characters in the message as expressed
in RFC 822 format.
RFC822形式で言い表されるようにメッセージのキャラクタの数を示すRFC822.SIZE A番号。
RFC822.TEXT A string expressing the text body of the
message, omitting the RFC 822 header.
See also note for RFC822.
RFC822ヘッダーを省略して、テキストメッセージ欄を言い表すRFC822.TEXT五弦。 また、RFC822に関して注意を見てください。
*/tag FLAGS flag_list
*/タグFLAGS旗_リスト
A solicited FLAGS response must occur as a result of a SELECT
command. The flag list is the list of flags (at a minimum, the
IMAP defined flags) which are applicable for this mailbox. Flags
other than the system flags are a function of the server
implementation.
請求されたFLAGS応答はSELECTコマンドの結果、起こらなければなりません。 現役将官名簿はこのメールボックスに、適切な旗(最小限で、IMAPは旗を定義した)のリストです。 システム旗以外の旗はサーバ実装の機能です。
*/tag SEARCH (numbers) (search_criteria)
*/タグ検索(数)(検索_評価基準)
This response occurs as a result of a SEARCH command. The
number(s) refer to those messages which match the search criteria.
In its solicited form this message allows clients to find
interesting groups of messages, e.g., unseen messages from
Crispin. In its unsolicited form it allows the server to inform
the client of interesting patterns, e.g., when new mail arrives,
recent and from Crispin. Compatibility note: The search_criteria
are sent by the server along with the matching numbers so
unsolicited SEARCH messages may be interpreted. This syntax is
not upwards compatible with IMAP2 and so the new syntax is
intended to make it simple for clients that are not able to take
advantage of unsolicited SEARCH messages still to interpret
solicited SEARCH messages simply by ignoring everything that
follows the list of numbers with minimal parsing. Such clients
may not, however, simply discard the rest of the line because
there might be LITERALs in the search pattern.
この応答は検索命令の結果、起こります。 数は検索評価基準に合っているそれらのメッセージを示します。 請求されたフォームでは、このメッセージで、クライアントはクリスピンからメッセージ、例えば、見えないメッセージのおもしろいグループを見つけることができます。 それがおもしろいパターンについてクライアントに例えば、新しいメールが到着するとき、最近で知らせるのをサーバを許容する求められていないフォームとクリスピンから。 互換性注意: 検索メッセージを解釈できるようにとても求められていない合っている数に伴うサーバは検索_評価基準を送ります。 この構文は上向きにIMAP2と互換性がないので、新しい構文で単に最小量の構文解析がある数のリストに従うすべてを無視することによってまだ請求された検索メッセージを解釈している求められていない検索メッセージを利用するのができないクライアントにとって簡単になることを意図します。 検索パターンにはLITERALsがあるかもしれないので、しかしながら、そのようなクライアントは系列の残りを絶対に捨てないかもしれません。
Examples:
A00042 SEARCH (2 3 6) (FROM Crispin ~SEEN)
and
* SEARCH (42) (FROM Crispin RECENT)
例: A00042検索(2 3 6)(クリスピン~から、見られます)と*検索(42)(クリスピンから最近)です。
*/tag READONLY
*/タグREADONLY
This indicates that the mailbox is read-only. The server is
required to respond to a READONLY or READWRITE command with either
a solicited READONLY or a solicited READWRITE response. Note: If
the client attempts a mutation operation, such as STORE, on a
mailbox to which it does not have write access then the server is
required to reply with a solicited READONLY response on the first
これは、メールボックスが書き込み禁止であることを示します。 サーバが、請求されたREADONLYか請求されたREADWRITE応答のどちらかでREADONLYかREADWRITEコマンドに応じるのに必要です。 以下に注意してください。 クライアントがメールボックスの上のストアなどの変異操作をそれでアクセスを書かないものに試みるなら、サーバが、請求されたREADONLY応答が1日にある状態で返答するのに必要です。
Rice [Page 30] RFC 1203 IMAP3 February 1991
ライス[30ページ]RFC1203IMAP3 February 1991
such attempted mutation. The server may also choose to send
solicited READONLY responses for each subsequent attempted
mutation.
そのようなものは変異を試みました。 また、サーバは、それぞれのその後の試みられた変異のための請求されたREADONLY応答を送るのを選ぶかもしれません。
*/tag READWRITE
*/タグREADWRITE
This indicates that the mailbox is read-write. The server is
required to respond to a READONLY or READWRITE command with either
a solicited READONLY or a solicited READWRITE response.
これは、メールボックスが読書して書いているのを示します。 サーバが、請求されたREADONLYか請求されたREADWRITE応答のどちらかでREADONLYかREADWRITEコマンドに応じるのに必要です。
*/tag BBOARD bboard_name
*/タグBBOARD bboard_名
This message is produced in its solicited form as a response to a
FIND BBOARDS command. In its unsolicited form it represents a
notification by the server that a new BBoard has been added.
Bboard_name must be a name that can be supplied to the BBOARD
command so as to select the appropriate bboard.
このメッセージはFIND BBOARDSコマンドへの応答として請求されたフォームで出されます。 求められていないフォームでは、それは新しいBBoardが加えられるというサーバによる通知を表します。 Bboard_名前は適切なbboardを選択するためにBBOARDコマンドに提供できる名前であるに違いありません。
*/tag MAILBOX non_inbox_mailbox_name
*/タグMAILBOX非_の受信トレイ_メールボックス_名
This message is produced in its solicited form as a response to a
FIND MAILBOXES command. In its unsolicited form it represents a
notification by the server that a new mailbox has been added,
perhaps as the result of a COPY command creating a new mailbox.
Non_inbox_mailbox_name must be a name that can be supplied to the
SELECT command so as to select the appropriate mailbox. Note:
non_inbox_mailbox_name is never the string "INBOX".
このメッセージはFIND MAILBOXESコマンドへの応答として請求されたフォームで出されます。 求められていないフォームでは、新しいメールボックスが加えられるというサーバによる通知を表します、恐らく新しいメールボックスを作成するCOPYコマンドの結果として。 非_の受信トレイ_メールボックス_名は適切なメールボックスを選択するためにSELECTコマンドに提供できる名前であるに違いありません。 以下に注意してください。 非_の受信トレイ_メールボックス_名は決してストリング「受信トレイ」ではありません。
*/tag SUPPORTED.VERSIONS (version_specs)
*/タグSUPPORTED.VERSIONS(バージョン_仕様)
This message is used either as a response to the
SUPPORTED.VERSIONS or, in its unsolicited form, to indicate the
dynamic addition or removal of support for features or protocol
versions. Each version_spec is of the form (4 2
EIGHT.BIT.TRANSPARENT AUTO.SET.SEEN ...), i.e., a major version
number and a minor version number for the protocol and the set of
features supported under the server's implementation of that
protocol version. A server may not dynamically remove support for
any version or feature that has been selected by any currently
logged in client by the use of the VERSION command.
それは求められていません。または、このメッセージがSUPPORTED.VERSIONSへの応答として使用される、コネ、形成して、特徴かプロトコルバージョンのサポートのダイナミックな追加か取り外しを示してください。 各バージョン_仕様はフォーム(4 2EIGHT.BIT.TRANSPARENT AUTO.SET.SEEN…)のものであり、サーバのその実装の下でサポートされた特徴のプロトコルとセットのためのすなわち、メジャーバージョン番号とマイナーバージョン番号はバージョンについて議定書の中で述べます。 サーバがダイナミックにどんなバージョンのサポートも取り除かないかもしれませんか、またはバージョンコマンドの使用でいずれによっても選択された特徴は現在、クライアントにログインしました。
Example:
A00005 SUPPORTED.VERSIONS ((2 0 )
(2 2 TAGGED.SOLICITED)
(3 0 EIGHT.BIT.TRANSPARENT TAGGED.SOLICITED))
例: A00005 SUPPORTED.VERSIONS((2 0 )(2 2TAGGED.SOLICITED)、(3 0、8.BIT.TRANSPARENT TAGGED.SOLICITED)
Indicates that two major versions are supported and one minor
version is supported and that tagged solicited messages are
2つの主要なバージョンがサポートされて、1つの小さい方のバージョンがサポートされて、タグ付けをされた請求されたメッセージがそうであることを示します。
Rice [Page 31] RFC 1203 IMAP3 February 1991
ライス[31ページ]RFC1203IMAP3 February 1991
supported in versions 2.2 and 3.0 with eight bit characters being
supported under version 3. For each feature mentioned in the list
of features there is also always the negation of that feature.
For example, if the server supports the TAGGED.SOLICITED feature
then it also supports the ~TAGGED.SOLICITED feature, which
disables this feature. Note: These are only example feature
names and are not necessarily supported by any server. See the
appendix on features for more information on features.
バージョン2.2と3.0では、8ビットのキャラクタがバージョン3の下でサポートされている状態で、サポートされます。 特徴のリストで言及された各特徴のために、その特徴の否定がいつももあります。 例えば、また、サーバがTAGGED.SOLICITEDの特徴をサポートするなら、それは~TAGGED.SOLICITEDの特徴をサポートします。(それは、この特徴を無効にします)。 以下に注意してください。 これらは、例の特徴名だけであり、必ずどんなサーバによってもサポートされるというわけではありません。詳しい情報のための特徴の特徴の付録を見てください。
+ text
+ テキスト
This response indicates that the server is ready to accept the
text of a literal from the client. Normally, a command from the
client is a single text line. If the server detects an error in
the command, it can simply discard the remainder of the line. It
cannot do this in the case of commands which contain literals,
since a literal can be an arbitrarily long amount of text, and the
server may not even be expecting a literal. This mechanism is
provided so the client knows not to send a literal until the
server definitely expects it, preserving client/server
synchronization.
この応答は、サーバをクライアントからリテラルのテキストを受け入れる準備ができているのを示します。 通常、クライアントからのコマンドはただ一つのテキスト系列です。 サーバがコマンドにおける誤りを検出するなら、それは単に系列の残りを捨てることができます。 それはリテラルを含むコマンドの場合でこれができません、リテラルが任意に長い量のテキストであるかもしれなく、サーバがリテラルを予想してさえいないかもしれないので。 このメカニズムはしたがって、クライアントが、サーバが確実にそれを予想するまでリテラルを送らないのを知っているかどうかということです、クライアント/サーバ同期を保存して。
In actual practice, this situation is rarely encountered. In the
current protocol, the only client commands likely to contain
literals are the LOGIN command and the STORE RFC822.HEADER or
STORE RFC822.TEXT commands. Consider a situation in which a
server validates the user before checking the password. If the
password contains "funny" characters and hence is sent as a
literal, then if the user is invalid an error would occur before
the password is parsed.
実際行なわれているところでは、この状況はめったに遭遇しません。 現在のプロトコルでは、リテラルを含みそうな唯一のクライアントコマンドが、LOGINコマンドとSTORE RFC822.HEADERかSTORE RFC822.TEXTコマンドです。 パスワードをチェックする前にサーバがユーザを有効にする状況を考えてください。 パスワードを「おかしい」キャラクタを含んでいて、したがって、リテラルとして送るなら、ユーザが無効であるなら、パスワードが分析される前に誤りは発生するでしょう。
No such synchronization protection is provided for literals sent
from the server to the client, for performance reasons. Any
synchronization problems in this direction would be due to a bug
in the client or server and not for some operational problem.
サーバからクライアントに送られたリテラル、性能理由にどんなそのような同期保護も提供しません。 この方向へのどんな同期問題も何らかの運転上の問題ではなく、クライアントかサーバのバグのためでしょう。
Sample IMAP3 session
サンプルIMAP3セッション
The following is a transcript of an actual IMAP3 session. Server output is identified by "S:" and client output by "U:". In cases where lines were too long to fit within the boundaries of this document, the line was continued on the next line preceded by a tab.
↓これは実際のIMAP3セッションの転写です。 サーバ出力が特定される、「S:」 出力されたクライアント、「U:」 系列がこのドキュメントの区域内に合うことができないくらい長かった場合では、系列はタブが先行した次の系列で続けられていました。
S: * OK SUMEX-AIM.Stanford.EDU Interactive Mail Access Protocol
III Service 6.1(349) at Mon, 14 May 90 14:58:30 PDT
U: a001 SUPPORTED.VERSIONS
S: * SUPPORTED.VERSIONS ((2 0 ) (3 0 EIGHT.BIT.TRANSPARENT
AUTO.SET.SEEN TAGGED.SOLICITED))
S: * 月曜日、1990年5月14日の太平洋夏時間14時58分30秒UにSUMEX-AIM.Stanford.EDUの対話的なメールアクセス・プロトコルIIIサービス6.1(349)を承認してください: a001 SUPPORTED.VERSIONS S: * SUPPORTED.VERSIONS((2 0 )、(3 0、8.BIT.TRANSPARENT AUTO.SET.SEEN TAGGED.SOLICITED)
Rice [Page 32] RFC 1203 IMAP3 February 1991
ライス[32ページ]RFC1203IMAP3 February 1991
S: A001 Supported Versions returned.
U: a002 SELECT.VERSION (3 0)
S: a002 OK Version 3.0 Selected.
U: a003 SELECT.FEATURES TAGGED.SOLICITED
S: a003 OK Features selected.
U: a004 login crispin secret
S: a004 OK User CRISPIN logged in at Thu, 9 Jun 90 14:58:42 PDT,
job 76
U: a005 select inbox
S: a005 FLAGS (Bugs SF Party Skating Meeting Flames Request AI
Question Note \XXXX \YYYY \Answered \Flagged \Deleted
\Seen)
S: a005 16 EXISTS
S: a005 0 RECENT
S: a006 OK Select complete
U: a006 fetch 16 all
S: a006 16 Fetch (Flags (\Seen) InternalDate " 9-Jun-88 12:55:
RFC822.Size 637 Envelope ("Sat, 4 Jun 88 13:27:11 PDT"
"INFO-MAC Mail Message" (("Larry Fagan" NIL "FAGAN"
"SUMEX-AIM.Stanford.EDU" NIL)) (("Larry Fagan" NIL "FAGAN"
"SUMEX-AIM.Stanford.EDU" NIL)) (("Larry Fagan" NIL "FAGAN"
"SUMEX-AIM.Stanford.EDU" NIL)) ((NIL NIL "rindflEISCH"
"SUMEX-AIM.Stanford.EDU" NIL)) NIL NIL NIL
"<12403828905.13.FAGAN@SUMEX-AIM.Stanford.EDU>"))
S: a006 OK Fetch completed
U: a007 fetch 16 rfc822
S: a007 16 Fetch (RFC822 {637}
S: Mail-From: RINDFLEISCH created at 9-Jun-88 12:55:43
S: Mail-From: FAGAN created at 4-Jun-88 13:27:12
S: Date: Sat, 4 Jun 88 13:27:11 PDT
S: From: Larry Fagan <FAGAN@SUMEX-AIM.Stanford.EDU>
S: To: rindflEISCH@SUMEX-AIM.Stanford.EDU
S: Subject: INFO-MAC Mail Message
S: Message-ID: <12403828905.13.FAGAN@SUMEX-AIM.Stanford.EDU>
S: ReSent-Date: Thu, 9 Jun 88 12:55:43 PDT
S: ReSent-From: TC Rindfleisch <Rindfleisch@SUMEX-AIM.Stanford.EDU>
S: ReSent-To: Yeager@SUMEX-AIM.Stanford.EDU,
Crispin@SUMEX-AIM.Stanford.EDU
S: ReSent-Message-ID:
<12405133897.80.RINDFLEISCH@SUMEX-AIM.Stanford.EDU>
S:
S: The file is <info-mac>usenetv4-55.arc ...
S: Larry
S: -------
S: )
S: a007 OK Fetch completed
U: a008 logout
S: a008 BYE UNIX IMAP III server terminating connection
S: A001 Supportedバージョンは戻りました。 U: a002 SELECT.VERSION(3 0)S: a002OKバージョン3.0Selected。 U: a003 SELECT.FEATURES TAGGED.SOLICITED S: OK Featuresが選択したa003。 U: a004ログインcrispin秘密S: 仕事76のU、a004OK Userクリスピンは木曜日、1990年6月9日の太平洋夏時間14時58分42秒にログインしました: a005の選んだ受信トレイS: a005 FLAGS(SFパーティSkating MeetingフレームズRequest AI Question Note\XXXX\YYYY\Answered\Flagged\Deleted\Seenを悩ます)S: a005 16EXISTS S: a005 0RECENT S: a006OK SelectはUを完成します: a006フェッチ、16 すべてのS: a006 16Fetch、((\Seen)InternalDateに旗を揚げさせる、「12:55:RFC822.Size637封筒(「土曜日、1988年6月4日の太平洋夏時間13時27分11秒」のときに、「インフォメーション-MACはメッセージを郵送する」(「ラリー・フェーガン」NIL「フェーガン」"SUMEX-AIM.Stanford.EDU"無))((「ラリー・フェーガン」「フェーガン」"SUMEX-AIM.Stanford.EDU"無無))((「ラリー・フェーガン」「フェーガン」"SUMEX-AIM.Stanford.EDU"無無))(("rindflEISCH""SUMEX-AIM.Stanford.EDU"無無無))無 "<12403828905.13.FAGAN@SUMEX-AIM.Stanford.EDU 無無1988年6月9日、gt;、」、)、S: a006OK FetchはUを完成しました: a007フェッチ16rfc822 S: a007 16Fetch; (S: メールFrom:RINDFLEISCHが12:55:43秒間1988年6月9日: From:を郵送しているフェーガンで作成したRFC822 637が土曜日の1988年6月4日13:27:12秒間:日付:、1988年6月4日の太平洋夏時間13時27分11秒にS: From: ラリー Fagan <FAGAN@SUMEX-AIM.Stanford.EDU を作成した、gt;、S: To: rindflEISCH@SUMEX-AIM.Stanford.EDU S: Subject: INFO-MACメールMessage S: Message ID: <12403828905.13.FAGAN@SUMEX-AIM.Stanford.EDU 、gt; S: a007OK FetchはUを完成しました: a008がログアウトする、S: 接続を終えるa008 BYE UNIX IMAP IIIサーバ
Rice [Page 33] RFC 1203 IMAP3 February 1991
ライス[33ページ]RFC1203IMAP3 February 1991
S: a008 OK SUMEX-AIM.Stanford.EDU Interim Mail Access Protocol
Service logout
S: a008OK SUMEX-AIM.Stanford.EDU InterimメールAccessプロトコルServiceはログアウトします。
Implementation Discussion
実装議論
As of this writing, SUMEX has completed an IMAP2 client for Xerox Lisp machines written in hybrid Interlisp/CommonLisp and is beginning distribution of a client for TI Explorer Lisp machines. SUMEX has also completed a portable IMAP2 client protocol library module written in C. This library, with the addition of a small main program (primarily user interface) and a TCP/IP driver, became a rudimentary remote system mail-reading program under Unix. The first production use of this library is as a part of a MacII client which has now been under daily use (by real users) at Stanford for quite some time.
この書くこと現在、SUMEXはハイブリッドInterlisp/CommonLispに書かれたゼロックスLispマシンのためのIMAP2クライアントを完成して、TIエクスプローラーLispマシンのためにクライアントの分配を始めます。 また、SUMEXはC.に書かれた携帯用のIMAP2クライアントプロトコルライブラリモジュールを完成しました。小さい主プログラム(主としてユーザーインタフェース)の追加があるThisライブラリとTCP/IPドライバーはUnixの下でメールを閲読する初歩的なリモートシステムプログラムになりました。 長い間現在スタンフォードで毎日、使用中である(リアル・ユーザによる)MacIIクライアントの一部としてこのライブラリの最初の生産使用があります。
As of this writing, SUMEX has completed IMAP2 servers for TOPS-20 written in DEC-20 assembly language and 4.2/3 BSD Unix written in C. The TOPS-20 server is fully compatible with MM-20, the standard TOPS-20 mailsystem, and requires no special action or setup on the part of the user. The INBOX under TOPS-20 is the user's MAIL.TXT. The TOPS-20 server also supports multiple simultaneous access to the same mailbox, including simultaneous access between the IMAP3 server and MM-20. The 4.2/3 BSD Unix server requires that the user use either Unix Mail format or mail.txt format which is compatible with SRI MM-32 or Columbia MM-C. The 4.2/3 BSD Unix server allows simultaneous read access; write access must be exclusive. There is also an experimental IMAP3 server running on the TI Explorer class of machine, which uses MM mailbox format and which can communicate over both TCP and Chaos.
この書くこと現在、SUMEXが12月-20アセンブリ言語で書かれているTOPS-20のためにIMAP2サーバを完成して、C. TOPS-20サーバで書かれている4.2/3BSD UnixはMM-20、標準のTOPS-20 mailsystemと完全に互換性があって、ユーザ側のどんな特別な動きもセットアップも必要としません。 TOPS-20の下の受信トレイはユーザのMAIL.TXTです。 また、TOPS-20サーバは同じメールボックスへの複数の同時アクセスをサポートします、IMAP3サーバとMM-20の間に同時アクセスを含んでいて。 4.2/3BSD Unixサーバーは、どちらのUnixメールがもフォーマットするユーザ使用かmail.txtがどれがSRI MM-32と互換性があるか、そして、コロンビアMM-Cをフォーマットするのを必要とします。 4.2/3BSD Unixサーバーは同時の読書アクセスを許します。 書いてください。アクセスは排他的であるに違いありません。 また、MMメールボックス形式を使用して、TCPとChaosの両方の上で交信できるマシンのTIエクスプローラーのクラスで動く実験用IMAP3サーバがあります。
The Xerox Lisp client and DEC-20 server have been in production use for over two years; the Unix server was been in production use for over a year. IMAP3 has been used to access mailboxes at remote sites from a local workstation via the Internet. For example, from the Stanford local network one of the authors has read his mailbox at a Milnet site.
ゼロックスのLispクライアントと12月-20サーバが2年以上の生産使用でありました。 Unixサーバーはそうでした。1年以上の生産使用で、あります。 IMAP3は、インターネットを通してリモートサイトでローカルワークステーションからメールボックスにアクセスするのに使用されました。 例えば、スタンフォード企業内情報通信網から、作者のひとりはMilnetサイトで彼のメールボックスを読みました。
A number of IMAP clients have now been developed or are being developed. Amongst these are versions that run on the following machines:
多くのIMAPクライアントが、現在、開発されるか、または開発されています。 これらの中に、以下のマシンで動くバージョンがあります:
. Xerox Lisp machines
. Apple Macintosh
. NeXT
. IBM PC
. TI Explorer Lisp machines
. "Glass teletype" version that runs under Unix
. ゼロックスLispマシンアップルマッキントッシュNeXT IBM PC TIエクスプローラーLispマシンUnixで実行される「ガラステレタイプ」バージョン
Rice [Page 34] RFC 1203 IMAP3 February 1991
ライス[34ページ]RFC1203IMAP3 February 1991
. GNU Emacs
. X Windows
. NTT ELIS
. GNU Emacs X-windows NTTエリス
Each of these client programs is carefully tuned to optimize the performance and user interface in a manner that is consistent with the the user interface model of the native machine. For example, the Macintosh client features a "messy-desk" interface that allows the cutting and pasting of text with the use of the clipboard with a menu driven interface with keyboard accelerators.
Each of these client programs is carefully tuned to optimize the performance and user interface in a manner that is consistent with the the user interface model of the native machine. For example, the Macintosh client features a "messy-desk" interface that allows the cutting and pasting of text with the use of the clipboard with a menu driven interface with keyboard accelerators.
This specification does not make any formal definition of size restrictions, but some of the existing servers have the following limitations:
This specification does not make any formal definition of size restrictions, but some of the existing servers have the following limitations:
DEC-20
. length of a mailbox: 7,077,888 characters
. maximum number of messages: 18,432 messages
. length of a command line: 10,000 characters
. length of the local host name: 64 characters
. length of a "short" argument: 39 characters
. length of a "long" argument: 491,520 characters
. maximum amount of data output in a single fetch:
655,360 characters
DEC-20 . length of a mailbox: 7,077,888 characters . maximum number of messages: 18,432 messages . length of a command line: 10,000 characters . length of the local host name: 64 characters . length of a "short" argument: 39 characters . length of a "long" argument: 491,520 characters . maximum amount of data output in a single fetch: 655,360 characters
TI-Explorer
. length of a mailbox: limited by the Minimum of the size of the
virtual address space and the size of the file system
. maximum number of messages: limited by the the size of the
virtual address space
. length of a command line: limited by the the size of the
virtual address space
. length of the local host name: limited by the the size of the
virtual address space
. length of a "short" argument: limited by the the size of the
virtual address space
. length of a "long" argument: limited by the the size of the
virtual address space
. maximum amount of data output in a single fetch: not limited
TI-Explorer . length of a mailbox: limited by the Minimum of the size of the virtual address space and the size of the file system . maximum number of messages: limited by the the size of the virtual address space . length of a command line: limited by the the size of the virtual address space . length of the local host name: limited by the the size of the virtual address space . length of a "short" argument: limited by the the size of the virtual address space . length of a "long" argument: limited by the the size of the virtual address space . maximum amount of data output in a single fetch: not limited
Typical values for these limits are 30Mb for file systems and 128Mb for virtual address space.
Typical values for these limits are 30Mb for file systems and 128Mb for virtual address space.
To date, nobody has run up against any of these limitations, many of which are substantially larger than most current user mail reading programs.
To date, nobody has run up against any of these limitations, many of which are substantially larger than most current user mail reading programs.
There are several advantages to the scheme of tags and solicited
There are several advantages to the scheme of tags and solicited
Rice [Page 35] RFC 1203 IMAP3 February 1991
Rice [Page 35] RFC 1203 IMAP3 February 1991
responses and unsolicited data. First, the infamous synchronization
problems of SMTP and similar protocols do not happen with tagged
commands; a command is not considered satisfied until a completion
acknowledgement with the same tag is seen. Tagging allows an
arbitrary amount of other responses ("solicited" data) to be sent by
the server with no possibility of the client losing synchronization.
Compare this with the problems that FTP or SMTP clients have with
continuation, partial completion, and commentary reply codes.
responses and unsolicited data. First, the infamous synchronization problems of SMTP and similar protocols do not happen with tagged commands; a command is not considered satisfied until a completion acknowledgement with the same tag is seen. Tagging allows an arbitrary amount of other responses ("solicited" data) to be sent by the server with no possibility of the client losing synchronization. Compare this with the problems that FTP or SMTP clients have with continuation, partial completion, and commentary reply codes.
Another advantage is that a non-lockstep client implementation is possible. The client could send a command, and entrust the handling of the server responses to a different process which would signal the client when the tagged response comes in. Some clients might be implemented in a thoroughly asynchronous manner, having, perhaps, multiple outstanding commands at any given time. Note: this does not require that the server process these commands in anything other than a lock-step manner. It simply allows clients to take advantage of servers that are able to do such asynchronous operations.
Another advantage is that a non-lockstep client implementation is possible. The client could send a command, and entrust the handling of the server responses to a different process which would signal the client when the tagged response comes in. Some clients might be implemented in a thoroughly asynchronous manner, having, perhaps, multiple outstanding commands at any given time. Note: this does not require that the server process these commands in anything other than a lock-step manner. It simply allows clients to take advantage of servers that are able to do such asynchronous operations.
It was observed that synchronization problems can occur with literals if the literal is not recognized as such. Fortunately, the cases in which this can happen are relatively rare; a mechanism (the special "+" tag response) was introduced to handle those few cases which could happen. The proper way to address this problem in all cases is probably to move towards a record-oriented architecture instead of the text stream model provided by TCP.
It was observed that synchronization problems can occur with literals if the literal is not recognized as such. Fortunately, the cases in which this can happen are relatively rare; a mechanism (the special "+" tag response) was introduced to handle those few cases which could happen. The proper way to address this problem in all cases is probably to move towards a record-oriented architecture instead of the text stream model provided by TCP.
Unsolicited data needs some discussion. Unlike most protocols, in which the server merely does the client's bidding, an IMAP3 server has a semi-autonomous role. By means of sending "unsolicited data", the server is in effect sending a command to the client -- to update and/or extend its (incomplete) model of the mailbox with new information from the server. In this viewpoint, although a "fetch" command is a request for specific information from the client, the server is always at liberty to include more than the desired data as "unsolicited". A server acknowledgement to the "fetch" is a statement that at least all the requested data has been sent.
Unsolicited data needs some discussion. Unlike most protocols, in which the server merely does the client's bidding, an IMAP3 server has a semi-autonomous role. By means of sending "unsolicited data", the server is in effect sending a command to the client -- to update and/or extend its (incomplete) model of the mailbox with new information from the server. In this viewpoint, although a "fetch" command is a request for specific information from the client, the server is always at liberty to include more than the desired data as "unsolicited". A server acknowledgement to the "fetch" is a statement that at least all the requested data has been sent.
In terms of implementation, a simple lock-step client may have a local cache of data from the mailbox. This cache is incomplete in general, and at select time is empty. A listener on the IMAP connection in the client processes all solicited and unsolicited data symmetrically, and updates the cache based on this data, i.e., the client faults on a cache miss and asks the server to fill that cache slot synchronously. If a tagged completion response arrives, the listener unblocks the process which sent the tagged request.
In terms of implementation, a simple lock-step client may have a local cache of data from the mailbox. This cache is incomplete in general, and at select time is empty. A listener on the IMAP connection in the client processes all solicited and unsolicited data symmetrically, and updates the cache based on this data, i.e., the client faults on a cache miss and asks the server to fill that cache slot synchronously. If a tagged completion response arrives, the listener unblocks the process which sent the tagged request.
Clearly, given this model it is not strictly necessary to distinguish
Clearly, given this model it is not strictly necessary to distinguish
Rice [Page 36] RFC 1203 IMAP3 February 1991
Rice [Page 36] RFC 1203 IMAP3 February 1991
most solicited from unsolicited data. Doing so, however, apart from being clearer, also allows such simplistic, lock-step client implementations that extract the specific value of the response to command by trapping the tagged response. This allows the client not to have to block on some complex predicate that involves watching to see an update in a cache cell.
most solicited from unsolicited data. Doing so, however, apart from being clearer, also allows such simplistic, lock-step client implementations that extract the specific value of the response to command by trapping the tagged response. This allows the client not to have to block on some complex predicate that involves watching to see an update in a cache cell.
For example, perhaps as a result of opening a mailbox, solicited data from the server arrives. The first piece of data is the number of messages. This is used to size the cache; note that, if new mail arrives, by sending a new "number of messages" unsolicited data message server will cause the cache to be re-sized. If the client attempts to access information from the cache, it will encounter empty spots which will trigger "fetch" requests. The request would be sent, some solicited data including the answer to the fetch will flow back, and then the "fetch" response will unblock the client.
For example, perhaps as a result of opening a mailbox, solicited data from the server arrives. The first piece of data is the number of messages. This is used to size the cache; note that, if new mail arrives, by sending a new "number of messages" unsolicited data message server will cause the cache to be re-sized. If the client attempts to access information from the cache, it will encounter empty spots which will trigger "fetch" requests. The request would be sent, some solicited data including the answer to the fetch will flow back, and then the "fetch" response will unblock the client.
People familiar with demand-paged virtual memory design will recognize this model as being very similar to page-fault handling on a demand-paged system.
People familiar with demand-paged virtual memory design will recognize this model as being very similar to page-fault handling on a demand-paged system.
Formal Syntax
Formal Syntax
The following syntax specification uses the augmented Backus-Naur Form (BNF) notation as specified in RFC 822 with one exception; the delimiter used with the "#" construct is a single space (SP) and not a comma.
The following syntax specification uses the augmented Backus-Naur Form (BNF) notation as specified in RFC 822 with one exception; the delimiter used with the "#" construct is a single space (SP) and not a comma.
address ::= "(" addr_name SP addr_adl SP addr_mailbox SP
addr_host addr_comment ")"
address ::= "(" addr_name SP addr_adl SP addr_mailbox SP addr_host addr_comment ")"
addr_adl ::= nil / string
addr_adl ::= nil / string
addr_comment ::= nil / string
addr_comment ::= nil / string
addr_host ::= nil / string
addr_host ::= nil / string
addr_mailbox ::= nil / string
addr_mailbox ::= nil / string
addr_name ::= nil / string
addr_name ::= nil / string
bboard ::= "BBOARD" SP bboard_name
bboard ::= "BBOARD" SP bboard_name
bboard_name ::= string
bboard_name ::= string
bboard_notify ::= "BBOARD" sp bboard_name
bboard_notify ::= "BBOARD" sp bboard_name
canonical_key ::= "$CC" / "$FROM" / "$SUBJECT" / "$TO"
canonical_key ::= "$CC" / "$FROM" / "$SUBJECT" / "$TO"
Rice [Page 37] RFC 1203 IMAP3 February 1991
Rice [Page 37] RFC 1203 IMAP3 February 1991
check ::= "CHECK"
check ::= "CHECK"
concrete_key ::= string
concrete_key ::= string
copy ::= "COPY" SP sequence SP mailbox
copy ::= "COPY" SP sequence SP mailbox
criterion ::= "ALL" / "ANSWERED" /
"BCC" SP string / "BEFORE" SP string /
"BODY" SP string / "CC" SP string / "DELETED" /
"FLAGGED" / "KEYWORD" SP atom / "NEW" / "OLD" /
"ON" SP string / "RECENT" / "SEEN" /
"SINCE" SP string / "TEXT" SP string /
"TO" SP string / "UNANSWERED" / "UNDELETED" /
"UNFLAGGED" / "UNKEYWORD" / "UNSEEN" / key SP string
criterion ::= "ALL" / "ANSWERED" / "BCC" SP string / "BEFORE" SP string / "BODY" SP string / "CC" SP string / "DELETED" / "FLAGGED" / "KEYWORD" SP atom / "NEW" / "OLD" / "ON" SP string / "RECENT" / "SEEN" / "SINCE" SP string / "TEXT" SP string / "TO" SP string / "UNANSWERED" / "UNDELETED" / "UNFLAGGED" / "UNKEYWORD" / "UNSEEN" / key SP string
criteria ::= 1#criterion
criteria ::= 1#criterion
data ::= ("FLAGS" SP flag_list /
search_notify / bboard_notify / mailbox_notify /
supported_versions_notify / "READONLY" / "READWRITE" /
"BYE" SP text_line / "OK" SP text_line /
"NO" SP text_line / "BAD" SP text_line)
data ::= ("FLAGS" SP flag_list / search_notify / bboard_notify / mailbox_notify / supported_versions_notify / "READONLY" / "READWRITE" / "BYE" SP text_line / "OK" SP text_line / "NO" SP text_line / "BAD" SP text_line)
date ::= string in form "dd-mmm-yy hh:mm:ss-zzz"
date ::= string in form "dd-mmm-yy hh:mm:ss-zzz"
envelope ::= "(" env_date SP env_subject SP env_from SP
env_sender SP env_reply-to SP env_to SP
env_cc SP env_bcc SP env_in-reply-to SP
env_message-id ")"
envelope ::= "(" env_date SP env_subject SP env_from SP env_sender SP env_reply-to SP env_to SP env_cc SP env_bcc SP env_in-reply-to SP env_message-id ")"
env_bcc ::= nil / "(" 1*address ")"
env_bcc ::= nil / "(" 1*address ")"
env_cc ::= nil / "(" 1*address ")"
env_cc ::= nil / "(" 1*address ")"
env_date ::= string
env_date ::= string
env_from ::= nil / "(" 1*address ")"
env_from ::= nil / "(" 1*address ")"
env_in-reply-to ::= nil / string
env_in-reply-to ::= nil / string
env_length ::= NUMBER
env_length ::= NUMBER
env_message-id ::= nil / string
env_message-id ::= nil / string
env_reply-to ::= nil / "(" 1*address ")"
env_reply-to ::= nil / "(" 1*address ")"
env_sender ::= nil / "(" 1*address ")"
env_sender ::= nil / "(" 1*address ")"
Rice [Page 38] RFC 1203 IMAP3 February 1991
Rice [Page 38] RFC 1203 IMAP3 February 1991
env_subject ::= nil / string
env_subject ::= nil / string
env_to ::= nil / "(" 1*address ")"
env_to ::= nil / "(" 1*address ")"
expunge ::= "EXPUNGE"
expunge ::= "EXPUNGE"
feature ::= ATOM
feature ::= ATOM
fetch ::= "FETCH" SP sequence SP ("ALL" / "FAST" /
fetch_att / "(" 1#fetch_att ")")
fetch ::= "FETCH" SP sequence SP ("ALL" / "FAST" / fetch_att / "(" 1#fetch_att ")")
fetch_att ::= "ENVELOPE" / "FLAGS" / "INTERNALDATE" /
"RFC822" / "RFC822.HEADER" / "RFC822.SIZE" /
"RFC822.TEXT" / key
fetch_att ::= "ENVELOPE" / "FLAGS" / "INTERNALDATE" / "RFC822" / "RFC822.HEADER" / "RFC822.SIZE" / "RFC822.TEXT" / key
find ::= "FIND" ("BBOARDS" / "MAILBOXES") pattern
find ::= "FIND" ("BBOARDS" / "MAILBOXES") pattern
flag_list ::= ATOM / "(" 1#ATOM ")"
flag_list ::= ATOM / "(" 1#ATOM ")"
flags ::= "FLAGS"
flags ::= "FLAGS"
generic_key ::= "BCC" / "BODY" / "CC" / "FROM" / "HEADER" / "SIZE" /
"SUBJECT" / "TEXT" / "TO"
generic_key ::= "BCC" / "BODY" / "CC" / "FROM" / "HEADER" / "SIZE" / "SUBJECT" / "TEXT" / "TO"
key ::= generic_key / canonical_key / concrete_key
key ::= generic_key / canonical_key / concrete_key
literal ::= "{" NUMBER "}" CRLF ASCII-STRING
literal ::= "{" NUMBER "}" CRLF ASCII-STRING
login ::= "LOGIN" SP userid SP password
login ::= "LOGIN" SP userid SP password
logout ::= "LOGOUT"
logout ::= "LOGOUT"
mailbox ::= "INBOX" / string
mailbox ::= "INBOX" / string
mailbox_notify ::= MAILBOX non_inbox_mailbox_name
mailbox_notify ::= MAILBOX non_inbox_mailbox_name
msg_copy ::= "COPY"
msg_copy ::= "COPY"
msg_data ::= (msg_exists / msg_recent / msg_expunge /
msg_fetch / msg_copy)
msg_data ::= (msg_exists / msg_recent / msg_expunge / msg_fetch / msg_copy)
msg_exists ::= "EXISTS"
msg_exists ::= "EXISTS"
msg_expunge ::= "EXPUNGE"
msg_expunge ::= "EXPUNGE"
msg_fetch ::= ("FETCH" / "STORE") SP "(" 1#("ENVELOPE" SP
env_length envelope / "FLAGS" SP "(" 1#(recent_flag
flag_list) ")" / "INTERNALDATE" SP date /
msg_fetch ::= ("FETCH" / "STORE") SP "(" 1#("ENVELOPE" SP env_length envelope / "FLAGS" SP "(" 1#(recent_flag flag_list) ")" / "INTERNALDATE" SP date /
Rice [Page 39] RFC 1203 IMAP3 February 1991
Rice [Page 39] RFC 1203 IMAP3 February 1991
"RFC822" SP string / "RFC822.HEADER" SP string /
"RFC822.SIZE" SP NUMBER / "RFC822.TEXT" SP
string / key SP string_list) ")"
"RFC822" SP string / "RFC822.HEADER" SP string / "RFC822.SIZE" SP NUMBER / "RFC822.TEXT" SP string / key SP string_list) ")"
msg_recent ::= "RECENT"
msg_recent ::= "RECENT"
msg_num ::= NUMBER
msg_num ::= NUMBER
nil ::= "NIL"
nil ::= "NIL"
non_inbox_mailbox_name ::= string
non_inbox_mailbox_name ::= string
noop ::= "NOOP"
noop ::= "NOOP"
numbers ::= 1#NUMBER
numbers ::= 1#NUMBER
password ::= string
password ::= string
pattern ::= string
pattern ::= string
recent_flag ::= "\RECENT"
recent_flag ::= "\RECENT"
read_only ::= "READONLY"
read_only ::= "READONLY"
read_write ::= "READWRITE"
read_write ::= "READWRITE"
ready ::= "+" SP text_line
ready ::= "+" SP text_line
request ::= tag SP (noop / login / logout / select / check /
expunge / copy / fetch / store / search /
select_version / select_features /
supported_versions / bboard / find /
read_only / read_write / flags / set_flags ) CRLF
request ::= tag SP (noop / login / logout / select / check / expunge / copy / fetch / store / search / select_version / select_features / supported_versions / bboard / find / read_only / read_write / flags / set_flags ) CRLF
response ::= tag SP ("OK" / "NO" / "BAD") SP text_line CRLF
response ::= tag SP ("OK" / "NO" / "BAD") SP text_line CRLF
search ::= "SEARCH" SP criteria
search ::= "SEARCH" SP criteria
search_notify ::= "SEARCH" SP (numbers) SP (criteria)
search_notify ::= "SEARCH" SP (numbers) SP (criteria)
select ::= "SELECT" SP mailbox
select ::= "SELECT" SP mailbox
select_features ::= "SELECT.FEATURES" 1#feature
select_features ::= "SELECT.FEATURES" 1#feature
select_version ::= "SELECT.VERSION" SP "(" NUMBER SP NUMBER ")"
select_version ::= "SELECT.VERSION" SP "(" NUMBER SP NUMBER ")"
sequence ::= NUMBER / (NUMBER "," sequence) / (NUMBER ":"
sequence)
sequence ::= NUMBER / (NUMBER "," sequence) / (NUMBER ":" sequence)
Rice [Page 40] RFC 1203 IMAP3 February 1991
Rice [Page 40] RFC 1203 IMAP3 February 1991
set_flags ::= "SET.FLAGS" SP flag_list
set_flags ::= "SET.FLAGS" SP flag_list
solicited ::= tag SP (msg_num SP msg_data / data /
solicited_only) CRLF
solicited ::= tag SP (msg_num SP msg_data / data / solicited_only) CRLF
solicited_only ::= {None currently defined}
solicited_only ::= {None currently defined}
store ::= "STORE" SP sequence SP store_att
store ::= "STORE" SP sequence SP store_att
store_att ::= ("+FLAGS" SP flag_list / "-FLAGS" SP flag_list /
"FLAGS" SP flag_list / RFC822.TEXT SP string
/ RFC822.HEADER SP string / key SP string)
store_att ::= ("+FLAGS" SP flag_list / "-FLAGS" SP flag_list / "FLAGS" SP flag_list / RFC822.TEXT SP string / RFC822.HEADER SP string / key SP string)
string ::= atom / """" 1*character """" / literal
string ::= atom / """" 1*character """" / literal
string_list ::= string / ("(" 1#string ")")
string_list ::= string / ("(" 1#string ")")
supported_versions ::= "SUPPORTED.VERSIONS"
supported_versions ::= "SUPPORTED.VERSIONS"
supported_versions_notify ::= "SUPPORTED.VERSIONS" "(" 1#version_spec
")"
supported_versions_notify ::= "SUPPORTED.VERSIONS" "(" 1#version_spec ")"
system_flags ::= "\ANSWERED" SP "\FLAGGED" SP "\DELETED" SP
"\SEEN"
system_flags ::= "\ANSWERED" SP "\FLAGGED" SP "\DELETED" SP "\SEEN"
tag ::= atom
tag ::= atom
unsolicited ::= "*" SP (msg_num SP msg_data / data) CRLF
unsolicited ::= "*" SP (msg_num SP msg_data / data) CRLF
userid ::= string
userid ::= string
version_spec ::= "(" NUMBER SP NUMBER SP 1#feature ")"
version_spec ::= "(" NUMBER SP NUMBER SP 1#feature ")"
Appendix: Features.
Appendix: Features.
In this section we outline the standard features that are supported by all IMAP3 servers and identify those features which are recommended or experimental. For each of these features the default setting is specified. This means that it is required of any server that supports a given feature to make the default enabledness of that feature as is specified below. It is required that for each feature supported by a server the inverse feature should also be supported. The inverse feature name shall always be defined as the feature name preceded by the "~" character. Thus, the AUTO.SET.SEEN feature is disabled by the ~AUTO.SET.SEEN feature.
In this section we outline the standard features that are supported by all IMAP3 servers and identify those features which are recommended or experimental. For each of these features the default setting is specified. This means that it is required of any server that supports a given feature to make the default enabledness of that feature as is specified below. It is required that for each feature supported by a server the inverse feature should also be supported. The inverse feature name shall always be defined as the feature name preceded by the "~" character. Thus, the AUTO.SET.SEEN feature is disabled by the ~AUTO.SET.SEEN feature.
Rice [Page 41] RFC 1203 IMAP3 February 1991
Rice [Page 41] RFC 1203 IMAP3 February 1991
Required Features:
Required Features:
AUTO.SET.SEEN - When this features is enabled (default is disabled),
the \\SEEN flag is set for all appropriate messages as a side
effect of any of the following:
FETCH of RFC822
FETCH of RFC822.TEXT
COPY
Justification: This feature is provided for the use of clients
that are unable to pipeline their commands effectively and
communicate over high latency connections. When disabled,
the server will not perform any such side effects. This feature
is also provided so as to smooth the transition from IMAP2 to
IMAP3.
AUTO.SET.SEEN - When this features is enabled (default is disabled), the \\SEEN flag is set for all appropriate messages as a side effect of any of the following: FETCH of RFC822 FETCH of RFC822.TEXT COPY Justification: This feature is provided for the use of clients that are unable to pipeline their commands effectively and communicate over high latency connections. When disabled, the server will not perform any such side effects. This feature is also provided so as to smooth the transition from IMAP2 to IMAP3.
TAGGED.SOLICITED - When this feature is enabled (default is enabled
for IMAP3, disabled for IMAP2 mode), solicited responses from
the server will have the tag specified by the client.
When this feature is disabled, solicited responses from the
server will have the IMAP2 compatible tag "*", not the
tag specified by the client.
Justification: This feature is provided so as to smooth the
transition from IMAP2 to IMAP3.
TAGGED.SOLICITED - When this feature is enabled (default is enabled for IMAP3, disabled for IMAP2 mode), solicited responses from the server will have the tag specified by the client. When this feature is disabled, solicited responses from the server will have the IMAP2 compatible tag "*", not the tag specified by the client. Justification: This feature is provided so as to smooth the transition from IMAP2 to IMAP3.
Recommended Features.
Recommended Features.
EIGHT.BIT.TRANSPARENT - When this feature is enabled
(default is disabled), the server allows the transparent
transmission of eight bit characters. When this feature is
disabled, the value of any bit other than the least significant
7 bits transmitted by the server is unspecified. If this
feature is enabled, the characters that compose all command
keywords specified in the IMAP3 grammar and all feature names
use only their 7 least significant bits.
Justification: This feature is provided for the purpose of
supporting national character sets within messages, encoded
languages such as Japanese Kanji characters and also of binary
data, such as programs, graphics and sound.
EIGHT.BIT.TRANSPARENT - When this feature is enabled (default is disabled), the server allows the transparent transmission of eight bit characters. When this feature is disabled, the value of any bit other than the least significant 7 bits transmitted by the server is unspecified. If this feature is enabled, the characters that compose all command keywords specified in the IMAP3 grammar and all feature names use only their 7 least significant bits. Justification: This feature is provided for the purpose of supporting national character sets within messages, encoded languages such as Japanese Kanji characters and also of binary data, such as programs, graphics and sound.
NEW.MAIL.NOTIFY - When this feature is enabled (default is
disabled for compatibility with the majority of existing
IMAP2 servers), the server will notify the client of the
arrival of new mail in the currently selected mailbox
using the appropriate RECENT and EXISTS unsolicited messages
without the client needing to send periodic CHECK commands.
Justification: This feature is provided to allow clients to
NEW.MAIL.NOTIFY - When this feature is enabled (default is disabled for compatibility with the majority of existing IMAP2 servers), the server will notify the client of the arrival of new mail in the currently selected mailbox using the appropriate RECENT and EXISTS unsolicited messages without the client needing to send periodic CHECK commands. Justification: This feature is provided to allow clients to
Rice [Page 42] RFC 1203 IMAP3 February 1991
Rice [Page 42] RFC 1203 IMAP3 February 1991
switch off any periodic polling strategy that they may use
to look for new mail. Such polling unnecessarily uses bandwidth
and can cause the interactive performance to degrade because
the user can be kept waiting while some background process
is doing a CHECK.
switch off any periodic polling strategy that they may use to look for new mail. Such polling unnecessarily uses bandwidth and can cause the interactive performance to degrade because the user can be kept waiting while some background process is doing a CHECK.
SEND - When this feature is enabled (default is disabled) a new
"SEND" command becomes available to the client. The SEND
command instructs the server to send a message, rather
than requiring the client to use its own, local message
sending capability, for example. An example of of the
send command might be as follows:
tag42 SEND RFC822 {2083}
From: James Rice <Rice@Sumex-Aim.Stanford.Edu>
To:.....
If the server is unable to parse the message being sent then
it is required to issue a suitable NO notification to the client.
If the message cannot be delivered for some reason then the
server should send a suitable message to the FROM: address
of the message detailing the delivery failure.
When the SEND feature is enabled, the "send" production in
the grammar is added and as defined below. The "send"
request is added to the list of requests in the request
production also as shown below:
SEND - When this feature is enabled (default is disabled) a new "SEND" command becomes available to the client. The SEND command instructs the server to send a message, rather than requiring the client to use its own, local message sending capability, for example. An example of of the send command might be as follows: tag42 SEND RFC822 {2083} From: James Rice <Rice@Sumex-Aim.Stanford.Edu> To:..... If the server is unable to parse the message being sent then it is required to issue a suitable NO notification to the client. If the message cannot be delivered for some reason then the server should send a suitable message to the FROM: address of the message detailing the delivery failure. When the SEND feature is enabled, the "send" production in the grammar is added and as defined below. The "send" request is added to the list of requests in the request production also as shown below:
message_format ::= RFC822
message_format ::= RFC822
request ::= tag SP (noop / login / logout / select / check /
expunge / copy / fetch / store / search /
select_version / select_features /
supported_versions / bboard / find /
read_only / read_write / flags /
set_flags / send) CRLF
request ::= tag SP (noop / login / logout / select / check / expunge / copy / fetch / store / search / select_version / select_features / supported_versions / bboard / find / read_only / read_write / flags / set_flags / send) CRLF
send ::= SEND SP message_format SP string
send ::= SEND SP message_format SP string
Justification: This feature is provided so that mail can be
sent by the same reliable server that is used for the storage
of mail. This has, amongst others, the following benefits:
- Single process clients need not be delayed by mail
transmission.
- Mail sent by the client will have the server named as the
message's sender. This can be important because there are
a lot of mailers that erroneously cause reply mail to be
sent to the Sender, not the From or Reply-To address. Since
the client in general is not listening for mail being sent
to it directly this can cause mail to be lost.
Justification: This feature is provided so that mail can be sent by the same reliable server that is used for the storage of mail. This has, amongst others, the following benefits: - Single process clients need not be delayed by mail transmission. - Mail sent by the client will have the server named as the message's sender. This can be important because there are a lot of mailers that erroneously cause reply mail to be sent to the Sender, not the From or Reply-To address. Since the client in general is not listening for mail being sent to it directly this can cause mail to be lost.
Rice [Page 43] RFC 1203 IMAP3 February 1991
Rice [Page 43] RFC 1203 IMAP3 February 1991
- Clients can be written that do not have any native message
sending capability.
- Clients can be written that do not have any native message sending capability.
ADD.MESSAGE - When this feature is enabled (default is disabled)
a new "ADD.MESSAGE" command becomes available to the client.
The ADD.MESSAGE command instructs the server to add the
specified message to the designated mailbox. This command
can be thought of as being like a COPY command except in
this case the message that is put in the designated mailbox
is specified as a string, rather than as a message number to
be copied from the currently selected mailbox. An example
use of this command might be as follows:
tag42 ADD.MESSAGE OUTGOING-MAIL RFC822 {2083}
From: James Rice <Rice@Sumex-Aim.Stanford.Edu>
To:.....
This will have the effect of adding the message to the mailbox
called OUTGOING-MAIL.
If the server is unable to parse the message being added then
it is required to issue a suitable NO notification to the client.
When the ADD.MESSAGE feature is enabled, the "add_message"
production in the grammar is added and as defined below.
The "add_message" request is added to the list of requests
in the request production also as shown below:
ADD.MESSAGE - When this feature is enabled (default is disabled) a new "ADD.MESSAGE" command becomes available to the client. The ADD.MESSAGE command instructs the server to add the specified message to the designated mailbox. This command can be thought of as being like a COPY command except in this case the message that is put in the designated mailbox is specified as a string, rather than as a message number to be copied from the currently selected mailbox. An example use of this command might be as follows: tag42 ADD.MESSAGE OUTGOING-MAIL RFC822 {2083} From: James Rice <Rice@Sumex-Aim.Stanford.Edu> To:..... This will have the effect of adding the message to the mailbox called OUTGOING-MAIL. If the server is unable to parse the message being added then it is required to issue a suitable NO notification to the client. When the ADD.MESSAGE feature is enabled, the "add_message" production in the grammar is added and as defined below. The "add_message" request is added to the list of requests in the request production also as shown below:
add_message ::= ADD.MESSAGE SP mailbox SP format SP string
add_message ::= ADD.MESSAGE SP mailbox SP format SP string
message_format ::= RFC822
message_format ::= RFC822
request ::= tag SP (noop / login / logout / select / check /
expunge / copy / fetch / store / search /
select_version / select_features /
supported_versions / bboard / find /
read_only / read_write / flags / set_flags /
add_message) CRLF
request ::= tag SP (noop / login / logout / select / check / expunge / copy / fetch / store / search / select_version / select_features / supported_versions / bboard / find / read_only / read_write / flags / set_flags / add_message) CRLF
Justification: This feature is provided so that clients can
easily add mail to specific mailboxes. This allows clients
to implement such behavior as outgoing mail storage (BCC)
without the need to resort to mailing to special BCC mailboxes.
Justification: This feature is provided so that clients can easily add mail to specific mailboxes. This allows clients to implement such behavior as outgoing mail storage (BCC) without the need to resort to mailing to special BCC mailboxes.
RENUMBER - When this feature is enabled (default is disabled)
the RENUMBER command becomes available to the client.
The RENUMBER command will reorder the assignment of message
numbers to the messages in the mailbox. If this results in a
change to the association of any message number with any
message then the server is required to send solicited RESET
RENUMBER - When this feature is enabled (default is disabled) the RENUMBER command becomes available to the client. The RENUMBER command will reorder the assignment of message numbers to the messages in the mailbox. If this results in a change to the association of any message number with any message then the server is required to send solicited RESET
Rice [Page 44] RFC 1203 IMAP3 February 1991
Rice [Page 44] RFC 1203 IMAP3 February 1991
responses to the client. The intent of this command is
to allow users to view mailboxes in user-meaningful order
efficiently. While the client could do the ordering,
it would be less efficient in general. Note that the
server may or may not change the actual storage of the
messages and the ordering may or may not remain in effect
after another mailbox is selected or the IMAP session is
terminated. Informally, the syntax for the RENUMBER
command is:
responses to the client. The intent of this command is to allow users to view mailboxes in user-meaningful order efficiently. While the client could do the ordering, it would be less efficient in general. Note that the server may or may not change the actual storage of the messages and the ordering may or may not remain in effect after another mailbox is selected or the IMAP session is terminated. Informally, the syntax for the RENUMBER command is:
tag RENUMBER field_name ordering_type
tag RENUMBER field_name ordering_type
this has the effect of changing the IMAP grammar to be
as follows:
this has the effect of changing the IMAP grammar to be as follows:
ordering_type ::= DATE / NUMERIC / ALPHA
ordering_type ::= DATE / NUMERIC / ALPHA
renumber ::= RENUMBER SP field_name SP ordering_type
renumber ::= RENUMBER SP field_name SP ordering_type
request ::= tag SP (noop / login / logout / select / check /
expunge / copy / fetch / store / search /
select_version / select_features /
supported_versions / bboard / find /
read_only / read_write / flags / set_flags /
renumber) CRLF
request ::= tag SP (noop / login / logout / select / check / expunge / copy / fetch / store / search / select_version / select_features / supported_versions / bboard / find / read_only / read_write / flags / set_flags / renumber) CRLF
For example:
tag42 RENUMBER FROM ALPHA
;;;RENUMBER alphabetically by the from field
tag42 RESET 10:20,49
;;;Messages 10 to 20 and 49 have changed
tag42 OK RENUMBER finished. Sequence has changed
tag43 FETCH ALL 10:20,49
;;;Client chooses to fetch the changed msgs.
For example: tag42 RENUMBER FROM ALPHA ;;;RENUMBER alphabetically by the from field tag42 RESET 10:20,49 ;;;Messages 10 to 20 and 49 have changed tag42 OK RENUMBER finished. Sequence has changed tag43 FETCH ALL 10:20,49 ;;;Client chooses to fetch the changed msgs.
To support this the RESET message is defined as follows:
To support this the RESET message is defined as follows:
*/tag RESET message_sequence
This solicited of unsolicited message from the server informs the
client that it should flush any information that it has
retained for the specified messages.
*/tag RESET message_sequence This solicited of unsolicited message from the server informs the client that it should flush any information that it has retained for the specified messages.
Justification: This feature is provided so that clients can
view mailboxes in an order that is convenient to the user.
This is particularly important in the context of mailboxes
that the user copies messages to from other mailboxes. This
user-controlled filing process often does not happen in any
well-defined order. Because messages in a mailbox are
Justification: This feature is provided so that clients can view mailboxes in an order that is convenient to the user. This is particularly important in the context of mailboxes that the user copies messages to from other mailboxes. This user-controlled filing process often does not happen in any well-defined order. Because messages in a mailbox are
Rice [Page 45] RFC 1203 IMAP3 February 1991
Rice [Page 45] RFC 1203 IMAP3 February 1991
implicitly ordered (usually by arrival date, though this is
not a required ordering predicate), the user can be confused
by the apparent order of messages in the mailbox. The
addition of the RENUMBER command makes it unnecessary
for the user to leave IMAP and use some other mail system to
sort mailboxes.
implicitly ordered (usually by arrival date, though this is not a required ordering predicate), the user can be confused by the apparent order of messages in the mailbox. The addition of the RENUMBER command makes it unnecessary for the user to leave IMAP and use some other mail system to sort mailboxes.
ENCODING - When this feature is enabled (default is disabled) a new
generic key named ENCODING is defined. The value associated
with the generic ENCODING key is a list of (tag encoding-type
options...) lists that represent the ordered, possibly encoded
body of the message. Each such list represents a segment of
the body of the message and the way in which it is encoded.
Any options that follow the encoding_type are further
qualifiers that describe the format of the segment. Each tag
is created by the server and is unique with respect to the
other tags allocated for the other elements in the ENCODING
list. The client may use the tags returned by the server as
concrete keys to access a field which is encoded using the
encoding type and options mentioned in the appropriate list.
Thus:
ENCODING - When this feature is enabled (default is disabled) a new generic key named ENCODING is defined. The value associated with the generic ENCODING key is a list of (tag encoding-type options...) lists that represent the ordered, possibly encoded body of the message. Each such list represents a segment of the body of the message and the way in which it is encoded. Any options that follow the encoding_type are further qualifiers that describe the format of the segment. Each tag is created by the server and is unique with respect to the other tags allocated for the other elements in the ENCODING list. The client may use the tags returned by the server as concrete keys to access a field which is encoded using the encoding type and options mentioned in the appropriate list. Thus:
tag41 FETCH 196 ENCODING ; Client asks for encoding field of msg 196. tag41 FETCH ENCODING NIL ; Server replies. This message is not encoded. tag41 OK Fetch completed. tag42 FETCH 197 ENCODING ; Client asks for encoding field of msg 197. tag42 FETCH ENCODING ((G001 UUENCODE) (G002 HEX)) ; Server replies. tag42 OK Fetch completed. tag43 FETCH 197 G002 ; Client asks for field named G002 tag43 FETCH G002 "A0 00 FF 13 42......." ; Server sends value of field. tag43 OK Fetch completed.
tag41 FETCH 196 ENCODING ; Client asks for encoding field of msg 196. tag41 FETCH ENCODING NIL ; Server replies. This message is not encoded. tag41 OK Fetch completed. tag42 FETCH 197 ENCODING ; Client asks for encoding field of msg 197. tag42 FETCH ENCODING ((G001 UUENCODE) (G002 HEX)) ; Server replies. tag42 OK Fetch completed. tag43 FETCH 197 G002 ; Client asks for field named G002 tag43 FETCH G002 "A0 00 FF 13 42......." ; Server sends value of field. tag43 OK Fetch completed.
or
or
tag44 STORE 197 G002 "0A 00 FF 31 24......."
; Store back the segment with nibbles swapped
tag44 STORE 197 G002 "0A 00 FF 31 24......." ; Store back the segment with nibbles swapped
Note: As a side-effect of enabling this feature, the generic key
TEXT will be redefined so as to return only those body parts of a
message that are of type TEXT. The concrete key RFC822.TEXT, on
the other hand, would still return everything in the body of the
message, even if it was full of strange, binary character
sequences.
Note: As a side-effect of enabling this feature, the generic key TEXT will be redefined so as to return only those body parts of a message that are of type TEXT. The concrete key RFC822.TEXT, on the other hand, would still return everything in the body of the message, even if it was full of strange, binary character sequences.
When the client STOREs to a field denoted by one of the above tags
the server will interpret the value being passed as being in the
same format as is currently specified in the ENCODING field. The
When the client STOREs to a field denoted by one of the above tags the server will interpret the value being passed as being in the same format as is currently specified in the ENCODING field. The
Rice [Page 46] RFC 1203 IMAP3 February 1991
Rice [Page 46] RFC 1203 IMAP3 February 1991
server is not required to be able to reformat the data associated
with the ENCODING tags if the client STOREs a new value for the
ENCODING field. The interpretability of a message in the context
of its ENCODING field is undefined if the client side-effects that
ENCODING field, unless the client also STOREs new, reformatted
values for the fields that have had their encoding changed.
server is not required to be able to reformat the data associated with the ENCODING tags if the client STOREs a new value for the ENCODING field. The interpretability of a message in the context of its ENCODING field is undefined if the client side-effects that ENCODING field, unless the client also STOREs new, reformatted values for the fields that have had their encoding changed.
If the client stores a new value for the ENCODING field then the
tags in the new value will be used to index the parts of the body.
All tags in a client-STOREd ENCODING that are the same as those
originally generated by the server in response to a FETCH ENCODING
command are said still to denote the fields that they originally
denoted, though possibly reordered. Any tags not originally
defined by the server will denote new message parts, in the
appropriate format, in the relative position specified. The
exclusion of any tags that the server originally defined in a
FETCH of the ENCODING field will indicate the deletion of that
part of the message. Newly created message parts are undefined by
default, so if the client fails to follow the STOREing of the
ENCODING field with suitable STORE commands for the values
associated with any newly created tags, these fields will contain
the null value NIL.
If the client stores a new value for the ENCODING field then the tags in the new value will be used to index the parts of the body. All tags in a client-STOREd ENCODING that are the same as those originally generated by the server in response to a FETCH ENCODING command are said still to denote the fields that they originally denoted, though possibly reordered. Any tags not originally defined by the server will denote new message parts, in the appropriate format, in the relative position specified. The exclusion of any tags that the server originally defined in a FETCH of the ENCODING field will indicate the deletion of that part of the message. Newly created message parts are undefined by default, so if the client fails to follow the STOREing of the ENCODING field with suitable STORE commands for the values associated with any newly created tags, these fields will contain the null value NIL.
Justification: This feature is supplied so as to allow support
for emergent multi-part and multi-media mail standards.
Justification: This feature is supplied so as to allow support for emergent multi-part and multi-media mail standards.
INDEXABLE.FIELDS - When this feature is enabled (default is
disabled) the grammar of fetch commands is changed to allow the
client to select a specific subsequence from the field in
question. For example:
INDEXABLE.FIELDS - When this feature is enabled (default is disabled) the grammar of fetch commands is changed to allow the client to select a specific subsequence from the field in question. For example:
tag42 FETCH 197 BODY 2000:3999
tag42 FETCH 197 BODY 2000:3999
would fetch the second two thousand bytes of the body of message
197. This feature allows resource limited clients to access
small parts of large messages. The formal syntax for this is:
would fetch the second two thousand bytes of the body of message 197. This feature allows resource limited clients to access small parts of large messages. The formal syntax for this is:
fetch_att ::= "ENVELOPE" / "FLAGS" / "INTERNALDATE" /
fetch_key / (fetch_key SP NUMBER ":" NUMBER)
fetch_att ::= "ENVELOPE" / "FLAGS" / "INTERNALDATE" / fetch_key / (fetch_key SP NUMBER ":" NUMBER)
fetch_key ::= "RFC822" / "RFC822.HEADER" / "RFC822.SIZE" /
"RFC822.TEXT" / key
fetch_key ::= "RFC822" / "RFC822.HEADER" / "RFC822.SIZE" / "RFC822.TEXT" / key
If the lower bound number (the number to the left of the colon)
exceeds the maximum size of the field then the empty string is
returned. If the upper bound exceeds the maximum size of the
field but the lower bound does not then the server will return the
remaining substring of the field after the lower bound. The
If the lower bound number (the number to the left of the colon) exceeds the maximum size of the field then the empty string is returned. If the upper bound exceeds the maximum size of the field but the lower bound does not then the server will return the remaining substring of the field after the lower bound. The
Rice [Page 47] RFC 1203 IMAP3 February 1991
Rice [Page 47] RFC 1203 IMAP3 February 1991
bounds specified are zero indexed into the fields and the bounds
index fields by 8-bit bytes.
bounds specified are zero indexed into the fields and the bounds index fields by 8-bit bytes.
Justification: This feature is provided so as to allow resource-
limited clients to read very large messages and also to allow
clients to improve interactive response for the reading of large
messages by fetching the first "screen full" of data to display
immediately and fetching the rest of the message in the
background.
Justification: This feature is provided so as to allow resource- limited clients to read very large messages and also to allow clients to improve interactive response for the reading of large messages by fetching the first "screen full" of data to display immediately and fetching the rest of the message in the background.
SET.EOL - When enabled (default is disabled), this feature
allows the new command SET.EOL to be available, changing the
grammar as follows:
SET.EOL - When enabled (default is disabled), this feature allows the new command SET.EOL to be available, changing the grammar as follows:
character ::= "CR" / "LF" / number
character ::= "CR" / "LF" / number
request ::= tag SP (noop / login / logout / select / check /
expunge / copy / fetch / store / search /
select_version / select_features /
supported_versions / bboard / find /
read_only / read_write / flags / set_flags /
set_eol) CRLF
request ::= tag SP (noop / login / logout / select / check / expunge / copy / fetch / store / search / select_version / select_features / supported_versions / bboard / find / read_only / read_write / flags / set_flags / set_eol) CRLF
set_eol ::= "SET.EOL" 1#character
set_eol ::= "SET.EOL" 1#character
This has the effect of changing the end of line character sequence
generated by the server for newlines within strings to the
sequence of characters specified. The characters in the sequence
can be either the specified symbolically named characters or a
numerical value, specifying the decimal value of the character to
use. Thus, if the client would like newlines in strings to be
indicated by a carriage return followed by a control-d, the client
would issue the following command:
This has the effect of changing the end of line character sequence generated by the server for newlines within strings to the sequence of characters specified. The characters in the sequence can be either the specified symbolically named characters or a numerical value, specifying the decimal value of the character to use. Thus, if the client would like newlines in strings to be indicated by a carriage return followed by a control-d, the client would issue the following command:
tag42 SET.EOL CR 4
tag42 SET.EOL CR 4
If the server is unable to support the combination of characters
requested by the client as its end-of-line pattern it will reply
with a NO response. This might be the case, for example, if a
server is only able to generate its own native line feed pattern
and the CRLF required by IMAP by default.
If the server is unable to support the combination of characters requested by the client as its end-of-line pattern it will reply with a NO response. This might be the case, for example, if a server is only able to generate its own native line feed pattern and the CRLF required by IMAP by default.
The server is required to change any length denoting values, such
as envelope byte counts for all future transactions to reflect the
new eol setting. This change in reported sizes should apply to
all generic size fetching keys, but not to concrete ones such as
RFC822.SIZE, which by their very nature require a size measurement
in RFC822 format, i.e., with CRLF as the end-of-line convention.
The server is required to change any length denoting values, such as envelope byte counts for all future transactions to reflect the new eol setting. This change in reported sizes should apply to all generic size fetching keys, but not to concrete ones such as RFC822.SIZE, which by their very nature require a size measurement in RFC822 format, i.e., with CRLF as the end-of-line convention.
Rice [Page 48] RFC 1203 IMAP3 February 1991
Rice [Page 48] RFC 1203 IMAP3 February 1991
Justification: This feature is provided because frequently clients
and servers might have end-of-line conventions other than the CRLF
specified by RFC822. It is undesirable that the IMAP be linked
too closely to RFC822 and selecting a different convention might
allow substantial performance improvements in both clients and
servers by saving either client, server or both from having to
shuffle text around so as to add or remove non-local end-of-line
sequences.
Justification: This feature is provided because frequently clients and servers might have end-of-line conventions other than the CRLF specified by RFC822. It is undesirable that the IMAP be linked too closely to RFC822 and selecting a different convention might allow substantial performance improvements in both clients and servers by saving either client, server or both from having to shuffle text around so as to add or remove non-local end-of-line sequences.
Acknowledgements:
Acknowledgements:
This text is based on RFC 1064 by Mark Crispin.
This text is based on RFC 1064 by Mark Crispin.
The following have made major contributions to this proposed update to the IMAP2 protocol:
The following have made major contributions to this proposed update to the IMAP2 protocol:
James Rice <Rice@sumex-aim.stanford.edu>
Richard Acuff <acuff@sumex-aim.stanford.edu>
Bill Yeager <yeager@sumex-aim.stanford.edu>
Christopher Lane <lane@sumex-aim.stanford.edu>
Bjorn Victor <Bjorn.Victor@docs.uu.se>
James Rice <Rice@sumex-aim.stanford.edu> Richard Acuff <acuff@sumex-aim.stanford.edu> Bill Yeager <yeager@sumex-aim.stanford.edu> Christopher Lane <lane@sumex-aim.stanford.edu> Bjorn Victor <Bjorn.Victor@docs.uu.se>
Additional input was also received from:
Additional input was also received from:
Andrew Sweer <sweer@sumex-aim.stanford.edu>
Tom Gruber <Gruber@sumex-aim.stanford.edu>
Kevin Brock <Brock@Sumex-Aim.Stanford.Edu>
Mark Crispin <MRC@cac.washington.edu>
Andrew Sweer <sweer@sumex-aim.stanford.edu> Tom Gruber <Gruber@sumex-aim.stanford.edu> Kevin Brock <Brock@Sumex-Aim.Stanford.Edu> Mark Crispin <MRC@cac.washington.edu>
Security Considerations
Security Considerations
Security issues are not discussed in this memo.
Security issues are not discussed in this memo.
Author's Address
Author's Address
James Rice Stanford University Knowledge Systems Laboratory 701 Welch Road Building C Palo Alto, CA 94304
James Rice Stanford University Knowledge Systems Laboratory 701 Welch Road Building C Palo Alto, CA 94304
Phone: (415) 723-8405 EMail: RICE@SUMEX-AIM.STANFORD.EDU
Phone: (415) 723-8405 EMail: RICE@SUMEX-AIM.STANFORD.EDU
Rice [Page 49]
Rice [Page 49]
一覧
スポンサーリンク
