RFC1176 日本語訳
1176 Interactive Mail Access Protocol: Version 2. M.R. Crispin. August 1990. (Format: TXT=67330 bytes) (Obsoletes RFC1064) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group M. Crispin Request for Comments: 1176 Washington Obsoletes: RFC 1064 August 1990
コメントを求めるワーキンググループM.クリスピン要求をネットワークでつないでください: 1176 米国政府は以下を時代遅れにします。 RFC1064 1990年8月
INTERACTIVE MAIL ACCESS PROTOCOL - VERSION 2
対話的なメールアクセス・プロトコル--バージョン2
Status of this Memo
このMemoの状態
This RFC suggests a method for personal computers and workstations to
dynamically access mail from a mailbox server ("repository"). It
obosoletes RFC 1064. This RFC specifies 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はパーソナルコンピュータとワークステーションがメールボックスサーバ(「倉庫」)からメールにダイナミックにアクセスするメソッドを勧めます。 それ、obosoletes RFC1064 このRFCはExperimentalプロトコルをインターネットコミュニティに指定します。 議論と改善提案は要求されています。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。
Introduction
序論
The intent of the Interactive Mail Access Protocol, Version 2 (IMAP2) is to allow a workstation, personal computer, or similar small machine to access electronic mail from a mailbox server. Since the distinction between personal computers and workstations is blurring over time, it is desirable to have a single solution that addresses the need in a general fashion. IMAP2 is the "glue" of a distributed electronic mail system consisting of a family of client and server implementations on a wide variety of platforms, from small single- tasking personal computing engines to complex multi-user timesharing systems.
InteractiveメールAccessプロトコルの意図、バージョン2(IMAP2)はワークステーション、パーソナルコンピュータ、または同様の小さいマシンがメールボックスサーバから電子メールにアクセスするのを許容することです。パーソナルコンピュータとワークステーションの区別が時間がたつにつれてぼけるので、一般的なファッションで必要性を扱うただ一つのソリューションを持っているのは望ましいです。 IMAP2はさまざまなプラットホームのクライアントとサーバ実装のファミリーから成る分配された電子メール・システムの「接着剤」です、個人的なコンピューティングエンジンに仕事を課すわずかなシングルから複雑なマルチユーザ時分割システムまで。
Although different in many ways from the Post Office Protocols (POP2 and POP3, hereafter referred to collectively as "POP") described in RFC 937 and RFC 1081, IMAP2 may be thought of as a functional superset of these. RFC 937 was used as a model for this RFC. There was a cognizant reason for this; POP deals with a similar problem, albeit with a less comprehensive solution, and it was desirable to offer a basis for comparison.
様々な意味でRFC937とRFC1081で説明されたポストオフィスプロトコル(今後「飛び出してください」とまとめて呼ばれたPOP2とPOP3)と異なりますが、IMAP2はこれらの機能的なスーパーセットとして考えられるかもしれません。 RFC937はこのRFCにモデルとして使用されました。 この認識力がある理由がありました。 それほど包括的でないソリューションでPOPは同様の問題に対処します、そして、比較の基準を提供するのは望ましかったです。
Like POP, IMAP2 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).
POPのように、IMAP2はメールを掲示するのではなく、保存されたメールにアクセスする手段を指定します。 この機能はSMTP(RFC821)などのメール転送プロトコルによって扱われます。
This protocol assumes a reliable data stream such as provided by TCP or any similar protocol. When TCP is used, the IMAP2 server listens on port 143.
このプロトコルはTCPかどんな同様のプロトコルでも提供するように確実な資料ストリームを仮定します。 TCPが使用されているとき、IMAP2サーバはポート143の上で聴かれます。
Crispin [Page 1] RFC 1176 IMAP2 August 1990
クリスピン[1ページ]RFC1176IMAP2 August 1990
System Model and Philosophy
システムモデルと哲学
Electronic mail is a primary means of communication for the widely spread Internet community. The advent of distributed personal computers and workstations has forced a significant rethinking of the mechanisms employed to manage electronic mail. With mainframes, each user tends to receive and process mail at the computer he uses 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 many vendors have implemented facilities to do this. However, this approach has several disadvantages:
電子メールは広く広げられたインターネットコミュニティのためのコミュニケーションのプライマリ手段です。 分配されたパーソナルコンピュータとワークステーションの到来は電子メールを管理するのに使われるメカニズムの重要な意識改革を強制しました。 メインフレームで、各ユーザは彼がたいてい使用するコンピュータ、彼の「一次ホスト」でメールを受け取って、処理する傾向があります。 多くのユーザの最初の傾向が独立しているワークステーションが彼らの正面に置かれるとき、ワークステーションにメールを受け取り始めることであり、多くのベンダーが、これをするために施設を実装しました。 しかしながら、このアプローチには、数回の損失があります:
(1) Personal computers and many 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 such as
receiving mail may not run for long periods of time; either
because the user is asking to use all the machine's resources, or
because the user has (perhaps accidentally) manipulated the
environment in such a way that it prevents mail reception. In
many personal computers, the operating system is single-tasking
and this is the only mode of operation. Any of these conditions
could lead to repeated failed delivery attempts by outside agents.
(1) パーソナルコンピュータと多くのワークステーションがコンソールにシステムの全面の完全な支配力をユーザに与えるソフトウェアデザインを持っています。 その結果、メールを受け取ることなどのバックグラウンドタスクに長い期間の間、立候補しないかもしれません。 どちらか、ユーザ、すべてを使用するように頼むのは、マシンのリソースであるかユーザがそれが防ぐそのような方法で環境を操ったので(恐らく偶然)、レセプションに郵送してください。 多くのパーソナルコンピュータでは、オペレーティングシステムはシングル・タスク方式です、そして、これは唯一の運転モードです。 これらの状態のいずれも外部のエージェントによる繰り返された失敗した配送試みにつながるかもしれません。
(2) The hardware failure of a single machine can keep its user
"off the air" for a considerable time, since repair of individual
units may be delayed. Given the growing number of personal
computers and workstations spread throughout office environments,
quick repair of such systems is not assured. On the other hand, a
central mainframe is generally repaired soon after failure.
(2) 単一マシンのハードウェアの故障はかなり長い間「放送されていない」ようにユーザを保つことができます、個々のユニットの修理が遅れるかもしれないので。 オフィス環境中で広げられたパーソナルコンピュータとワークステーションの増加している数を考えて、そのようなシステムの迅速な修理は保証されません。 他方では、一般に、主要なメインフレームは失敗のすぐ後に修理されます。
(3) Personal computers and workstations are often not backed up
with as much diligence as a central mainframe, if at all.
(3) パーソナルコンピュータとワークステーションは主要なメインフレームと同じくらい多くの勤勉さでしばしばせいぜい支援されるというわけではありません。
(4) 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 many 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.
(4) それぞれの人が異なったマシンに関連しているとき、郵送先住所の動向をおさえるのは、より難しいです。 多くの郵便の宛先か電話番号の動向をおさえることにおける苦労を考えてください、特にその組織にあなたがどんな人にも連絡できるだろう組織のためのどんなただ一つのアドレスも電話番号もなかったなら。 伝統的に、アルパネットの電子メールは、名前が個人が働いていた組織を反映した数個の「ホスト」(マシン)の名前と1つを覚えていることを伴いました。 これはほとんどの組織には1人の主要なホストしかいなかった時代に適当でした。 ホストの概念が特定のマシンではなく、組織的な実体について言及するために変えられない場合、それは今日、それほど満足できません。
(5) It is difficult to keep a multitude of heterogeneous machines
(5) 異種のマシンの多数を保つのは難しいです。
Crispin [Page 2] RFC 1176 IMAP2 August 1990
クリスピン[2ページ]RFC1176IMAP2 August 1990
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.
複雑な郵送プロトコルで適切に働いていて、電子コミュニケーション、新しい規格が現れるとき、進歩として前方へ動くのを難しくするのは作られます。 各システムは入って来るメールを受け取るのを心配しなければなりません、送信するメールを発送して、提供して、さまざまな可能なファイリングとプロトコルを郵送する上のメールボックスの安定性をフォーマットして、保存して、備えて。
Consequently, while a personal computer or workstation may be viewed
as an Internet host in the sense that it implements TCP/IP, it should
not be viewed as the entity that contains the user's mailbox.
Instead, a mail server machine ("server", sometimes called a
"repository") should hold the mailbox, and the personal computer or
workstation (hereafter referred to as a "client") should access the
mailbox via mail transactions.
その結果、インターネット・ホストとしてTCP/IPを実装するという意味でパーソナルコンピュータかワークステーションを見なしているかもしれない間、ユーザのメールボックスを含む実体としてそれを見なすべきではありません。 代わりに、メールサーバマシン(「倉庫」と、「サーバ」は時々呼んだ)はメールボックスを支えるはずです、そして、メールトランザクションでパーソナルコンピュータかワークステーション(今後「クライアント」と呼ばれる)がメールボックスにアクセスするはずです。
Because the mail server machine is isolated from direct user manipulation, it should achieve high software reliability easily, and, as a shared resource, it should also achieve high hardware reliability, perhaps through redundancy. The mail server may be accessed from arbitrary locations, allowing users to read mail across campus, town, or country using 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. A mail access protocol retrieves messages, accesss and changes properties of messages, and otherwise manages 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 use 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メール)と異なっています、データ保存がどう使用されているかに関するすべての知識からユーザとクライアントを隔離して。 これは、メールサーバがいかなるその特定の環境におけるメールをまとめるために最も効率的な方法でもデータ保存を使用できることを意味します、異なったマシンの向こう側にストレージ表現の互換性を心配する必要はなくて。
A mail access protocol further differs in that it transmits information only on demand. A well-designed mail access protocol requires considerably less network traffic than Unix mail via NFS, particularly when the mail file is large. The result is that a mail access protocol can scale well to situations of large mailboxes or networks with high latency or low speed.
メールアクセス・プロトコルは要求に応じてだけの情報を伝えるという点においてさらに異なります。 よく設計されたメールアクセス・プロトコルは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 is desirable to allow for a
メールアクセス・プロトコルを定義するのにおいて、クライアントとサーバが両方の長所を利用するのが互いの弱点を補っている間、可能であるべきmacrosystemを形成するのを覚えておくのは重要です。 その上、aを考慮するのは望ましいです。
Crispin [Page 3] RFC 1176 IMAP2 August 1990
クリスピン[3ページ]RFC1176IMAP2 August 1990
growth path beyond the hoary text-only RFC 822 protocol, specifically in the area of attachments and multi-media mail, to ease the eventual transition to ISO solutions.
RFC822がISOソリューションへの最後の変遷を緩和するために特に付属とマルチメディアメールの領域で議定書の中で述べる灰色のテキストのみを超えた成長経路。
Unlike POP, IMAP2 has extensive features for remote searching and parsing of messages on the server. A free text search (optionally with other searching) can be made in 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. The effect of this is twofold: it further improves the ability to scale well in instances where network traffic must be reduced, and it reduces the complexity of the client program.
IMAP2には、POPと異なって、サーバにおけるメッセージのリモート探すのと構文解析のための大規模な特徴があります。無料のテキストを探します。(全体のメールボックスを移さなければならないクライアントなしでクライアントにとって利用可能に作られていて、それ自体を捜しながら、サーバと結果による全体のメールボックスの中に他の探すこと) 缶で任意に作られてください。 構造化された(そして、標準の形式)「封筒」へのメッセージのリモート構文解析が利用可能であるので、どうRFC822を分析するかに関するどんな理解も持っていなくて、クライアントは、封筒情報を表示して、REPLYなどのコマンドを実装することができます、などヘッダー。 この効果は二つです: ネットワークトラフィックが減少しなければならないところでそれはさらに上手にインスタンスを計量する能力を改良します、そして、クライアントプログラムの複雑さを減少させます。
Additionally, IMAP2 offers several facilities for managing individual message state and the mailbox as a whole beyond the simple "delete message" functionality of POP. Another benefit of IMAP2 is the use of tagged responses to reduce the possibility of synchronization errors and the concept of state on the client (a "local cache") that the server may update without explicit request by the client. These concepts and how they are used are explained under "Implementation Discussion" below.
さらに、IMAP2は、「メッセージを削除してください」というPOPの簡単な機能性を超えて個々のメッセージ状態と全体でメールボックスを経営するためにいくつかの施設を提供します。 IMAP2の別の利益はサーバがクライアントによる明白な要求なしでアップデートするかもしれないクライアント(「ローカルなキャッシュ」)で同期誤りの可能性と状態の概念を減らすタグ付けをされた応答の使用です。 これらの概念であってそれらがどう使用されているかは以下の「実装議論」で説明されます。
In spite of this functional richness, IMAP2 is a small protocol. Although servers should implement the full set of IMAP2 functions, a simple client can be written that uses IMAP2 in much the way as a POP client.
この機能的な豊かにもかかわらず、IMAP2は小さいプロトコルです。 サーバはIMAP2機能のフルセットを実装するべきですが、POPクライアントとして方法でIMAP2を使用する純真なクライアントは書くことができます。
A related protocol to POP and IMAP2 is the DMSP protocol of PCMAIL
(RFC 1056). IMAP2 differs from DMSP more fundamentally, reflecting a
differing architecture from PCMAIL. PCMAIL is either an online
("interactive mode"), or offline ("batch mode") system with long-term
shared state. Some POP based systems are also offline; in such
systems, since there is no long-term shared state POP is little more
than a download mechanism of the "mail file" to the client. IMAP2-
based software is primarily an online system in which real-time and
simultaneous mail access were considered important.
POPとIMAP2への関連するプロトコルはPCMAIL(RFC1056)のDMSPプロトコルです。 PCMAILから異なったアーキテクチャを反映して、IMAP2は、より基本的にDMSPと異なっています。 PCMAILは長期の共有された状態があるオンライン(「会話型」)かオフライン(「バッチ・モード」)システムのどちらかです。 また、POPに基づいているいくつかのシステムもオフラインです。 そのようなシステムに、どんな長期の共有された州のPOPもないので、クライアントにはただ「メールファイル」のダウンロードメカニズムがありますか? IMAP2のベースのソフトウェアは主としてリアルタイムで同時のメールアクセスが重要であると考えられたオンラインシステムです。
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 that 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
PCMAILに、何らかのメールボックス状態がクライアントの上に保持される長期のクライアント/サーバ関係があります。 特定のユーザによって使用されたクライアントの登録があります、そして、クライアントは各メッセージのためのメッセージをまとめる1セットの「記述子」を保ちます。 そして、クライアントがしばらくクライアントが完全なリセット(再び荷を積む)をするサーバにアクセスしていないならDMSP接続が始動するとサーバとクライアントがそれらの州を連動させる、それ
Crispin [Page 4] RFC 1176 IMAP2 August 1990
クリスピン[4ページ]RFC1176IMAP2 August 1990
state from the server.
サーバからの状態。
In IMAP2-based software, the client/server relationship lasts only for the duration of the TCP 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" as noted above. There is no client/server synchronization since the client does not remember state between IMAP2 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.
IMAP2ベースのソフトウェアでは、クライアント/サーバ関係はTCP接続の持続時間のためだけに持続します。 すべてのメールボックス状態がサーバで維持されます。クライアントの登録が全くありません。 記述子の機能は「封筒」というメッセージの構造化された表現で上で述べたように扱われます。 クライアントがIMAP2接続の間の状態を覚えていないので、クライアント/サーバ同期が全くありません。 クライアントがただ一つのセッションのときに一般にメールボックスの全体の州を決して必要としないのでこれが問題でない、したがって、それが必要であるように必要である州の情報をとって来るのにおいてオーバーヘッドがあまりありません。
There are also some functional differences between IMAP2 and DMSP. DMSP has functions for sending messages, printing messages, listing mailboxes, and changing passwords; these are done outside IMAP2. DMSP has 16 binary flags of which 8 are defined by the system. IMAP2 has flag names; there are currently 5 defined system flag names and a facility for some number (30 in the current implementations) of user flag names. IMAP2 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.
また、IMAP2とDMSPの間には、いくつかの機能的な違いがあります。 DMSPには、メールボックスを記載して、パスワードを変えて、メッセージを印刷して、メッセージを送るための機能があります。 IMAP2の外でこれらをします。 DMSPには、どの8がシステムによって定義されるかに関する16個の2進の旗があります。 IMAP2には、旗の名があります。 現在、5つの定義されたシステム旗の名と何らかの数(現在の実装における30)のユーザ旗の名のための施設があります。 IMAP2は、クライアントがあらゆるメッセージのためのこのデータをとって来るのを強制しない期日、アドレス、旗の状態、または原文のコンテンツに基づくおもしろいメッセージを特定するためにサーバで洗練されたメッセージ検索施設を持っています。
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 small set of "interesting" messages, which were either new mail or mail based on some user-selected criteria. Consequently, IMAP2 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".
クライアントがどこでシングルユーザーによって使用されるだけであるか、そして、またはアクセスを別のユーザのデータに制限するためにクライアントの上にいくつかの手段があるかがクライアントの上で状態を維持するのがそれらの場合だけに有利であると感じられました。 それはそれの倍数にユーザがきまりきって同じクライアントを使用して、同じユーザがきまりきって異なったクライアントを使用して、クライアントの上にアクセス制限が全くない環境で重大な不都合であるかもしれません。 また、小さいセットの「おもしろい」メッセージにはほとんどのユーザメールアクセスがあるのが観測されました。(いくつかのユーザによって選択された評価基準に基づく新しいメールかメッセージはメールのどちらかでした)。 その結果、IMAP2は、クライアントがそれらではなく、それらの「おもしろくなかった」メッセージの状態をとって来ることができるように容易にそれらの「おもしろい」メッセージを特定するように設計されました。
The Protocol
プロトコル
The IMAP2 protocol consists of a sequence of client commands and server responses, with server data interspersed between the responses. 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. Additionally, the server may send an arbitrary amount of "unsolicited data", which is identified by the special reserved tag of "*". There
IMAP2プロトコルはクライアントコマンドの系列とサーバデータが応答の間に点在するサーバ応答から成ります。 ほとんどのインターネットプロトコルと異なって、コマンドと応答はタグ付けをされています。 すなわち、コマンドはタグと呼ばれるユニークな識別子(通常、Lisp"gensym"機能などの短い英数字の系列は例えば、A0001、A0002などを生成する)で始まります。 同じタグをサーバからこのコマンドへの応答に与えます。さらに、サーバは、任意の量の「求められていないデータ」を送るかもしれません。(それは、「*」の特別な予約されたタグによって特定されます)。 そこでは
Crispin [Page 5] RFC 1176 IMAP2 August 1990
クリスピン[5ページ]RFC1176IMAP2 August 1990
is another special reserved tag, "+", discussed below.
以下で別の特別な予約されたタグ、「+」について議論しますか?
The server must be listening for a connection. When a connection is opened the server sends an unsolicited OK response as a greeting message and then waits for commands.
サーバは接続の聞こうとしなければなりません。 接続が開かれると、サーバは、あいさつメッセージとして求められていないOK応答を送って、コマンドを待っています。
The client opens a connection and waits for the greeting. The client must not send any commands until it has received the greeting from the server.
クライアントは、接続を開いて、挨拶を待ちます。 それがサーバから挨拶を受けるまで、クライアントは少しのコマンドも送ってはいけません。
Once the greeting has been received, the client may begin sending commands and is not under any obligation to wait for a server response to this command before sending another command, within the constraints of TCP flow control. When commands are received the server acts on them and responds with command responses, often interspersed with data. The effect of a command can not be considered complete until a command response with a tag matching the command is received from the server.
いったん挨拶を受けると、クライアントは、コマンドを送り始めるかもしれなくて、別のコマンドを送る前にこのコマンドへのサーバ応答を待つどんな義務の下にもいません、TCPフロー制御の規制の中で。 コマンドが受け取られているとき、サーバは、それらに影響して、しばしばデータで点在したコマンド応答で反応します。 完全であるとコマンドの効果をサーバからタグがコマンドに合っているコマンド応答を受けるまで考えることができません。
Although all known IMAP2 servers at the time of this writing process commands to completion before processing the next command, it is not required that a server do so. However, many commands can affect the results of other commands, creating processing-order dependencies (or, for SEARCH and FIND, ambiguities about which data is associated with which command). All implementations that operate in a non- lockstep fashion must recognize such dependencies and defer or synchronize execution as necessary. In general, such multi- processing is limited to consecutive FETCH commands.
次のコマンドを処理する前にこの書くこと時点のすべての知られているIMAP2サーバが完成にコマンドを処理しますが、サーバがそうするのが必要ではありません。 しかしながら、多くのコマンドが他のコマンドの結果に影響できます、処理命令の依存(または、検索とFINDのためのデータがどのコマンドに関連しているあいまいさ)を引き起こして。 非堅苦しいファッションで作動するすべての実装が、必要に応じて実行をそのような依存を認識して、延期しなければならないか、または同時にさせなければなりません。 一般に、そのようなマルチ処理は連続したFETCHコマンドに制限されます。
Generally, the first command from the client is a LOGIN command with user name and password arguments to establish identity and access authorization, unless this has already been accomplished through other means, e.g. Kerberos. Until identity and access authorization have been established, no operations other than LOGIN or LOGOUT are permitted.
一般に、他の手段(例えば、ケルベロス)でこれが既に達成されていない場合、アイデンティティとアクセス認可を確立するユーザ名とパスワード議論でクライアントからの最初のコマンドはLOGINコマンドです。 アイデンティティとアクセス認可が確立されるまで、LOGINかLOGOUT以外の操作は全く受入れられません。
Once identity and authorization have been established, the client must send a SELECT command to access the desired mailbox; no mailbox is selected by default. SELECT's argument is implementation- dependent; however the word "INBOX" must be implemented to mean the primary or default mailbox for this user, independent of any other server semantics. On a successful SELECT, the server will send a list of valid flags, number of messages, and number of messages arrived since last access for this mailbox as unsolicited data, followed by an OK response. The client may terminate access to this mailbox and access a different one with another SELECT command.
アイデンティティと承認がいったん確立されると、クライアントは必要なメールボックスにアクセスするSELECTコマンドを送らなければなりません。 メールボックスは全くデフォルトで選択されません。 SELECTの議論は実装に依存しています。 しかしながら、このユーザのために予備選挙かデフォルトメールボックスを作るために「受信トレイ」という言葉を実装しなければなりません、いかなる他のサーバ意味論の如何にかかわらず。 うまくいっているSELECTに、サーバは有効な旗のリストを送るでしょう、メッセージの数、そして、このメールボックスのための最後のアクセス以来メッセージの数がOK応答があとに続いた求められていないデータとして到着しました。 クライアントは、このメールボックスへのアクセスを終えて、別のSELECTコマンドがある異なったものにアクセスするかもしれません。
The client reads mailbox information with FETCH commands. The actual
クライアントはFETCHコマンドでメールボックス情報を読みます。 実際
Crispin [Page 6] RFC 1176 IMAP2 August 1990
クリスピン[6ページ]RFC1176IMAP2 August 1990
data is transmitted via the unsolicited data mechanism (that is, FETCH should be viewed as instructing 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 that may be fetched.
データは求められていないデータメカニズムで送られます(それがクライアントに送りたがっているいかなる他のデータに伴う必要なデータも含めるようサーバに命令するとすなわち、FETCHは見なされるべきです)。 とって来られるかもしれないデータの3つの大範疇があります。
The first category is data that is associated with a message as an entity in the mailbox. There are now 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 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 that 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 that 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.] IMAP2 defines a structured and unambiguous representation for the envelope that is particularly suited 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 two categories of 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)封筒に混乱するべきではありません。](封筒は厳密に配送情報に制限されます)。 IMAP2は特にLispベースのパーサに合っている封筒の構造化されて明白な表現を定義します。 クライアントは、返答などなどの操作に封筒を使用して、全くRFC822を心配できません。 さらに詳細に以下で封筒について議論します。 「すべて」というマクロフェッチ単語を使用することによって、データの最初の2つのカテゴリを一緒にとって来ることができます。 すなわち、「すべて」は「(旗のINTERNALDATE RFC822.SIZE封筒)」に広がります。
The third category is that data that is intended for direct human viewing. The present RFC 822 based IMAP2 defines three such items: RFC822.HEADER, RFC822.TEXT, and RFC822 (the latter being the two former appended together in a single text string). RFC822.HEADER is the "raw", unprocessed RFC 822 format header of the message. Fetching "RFC822" is equivalent to fetching the RFC 822 representation of the message as stored on the mailbox without any filtering or processing.
3番目のカテゴリはダイレクト人間の見るために意図するそのデータです。 現在のRFC822ベースのIMAP2はそのような3つの項目を定義します: RFC822.HEADER、RFC822.TEXT、およびRFC822(前者がただ一つのテキスト文字列で一緒に追加した2である後者)。 RFC822.HEADERはメッセージの「生」の、そして、未加工のRFC822形式ヘッダーです。 魅惑的な"RFC822"はメールボックスの上に少しもフィルタリングや処理なしで保存されるようにメッセージのRFC822表現をとって来るのに同等です。
An intelligent 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 POP-type functionality.
知的なクライアントはメッセージ本体を得るプレゼンテーションメニューと特定のメッセージを読むというユーザ願望がいつ「RFC822.TEXTをとって来るか」としての使用のためのメールボックスの中のメッセージのいくつか(すべて)のために「すべてをとって来るでしょう」。 より原始のクライアントがそうすることができた、もちろん、単に「フェッチRFC822」a'laの大衆的なタイプは機能性です。
Crispin [Page 7] RFC 1176 IMAP2 August 1990
クリスピン[7ページ]RFC1176IMAP2 August 1990
The client can alter certain data (currently only the flags) by a STORE command. As an example, a message is deleted from a mailbox by a STORE command that includes the \DELETED flag as a flag being set.
クライアントはストアコマンドで、あるデータ(現在の旗だけ)を変更できます。 例として、メッセージはメールボックスからDELETEDが設定される旗として旗を揚げさせる\を含んでいるストアコマンドで削除されます。
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 that match certain criteria (SEARCH command).
他のクライアント操作は、別のメールボックス(COPYコマンド)にメッセージをコピーするのを含んでいます、永久に削除されたメッセージ(EXPUNGEコマンド)を取り除いて、新しいメッセージ(CHECKコマンド)がないかどうかチェックして、ある評価基準(検索命令)に合っているメッセージを検索して。
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 IMAP2 Server Ready
{Wait for command}
A001 LOGIN Fred Secret -->
<-- A001 OK User Fred logged in
{Wait for command}
A002 SELECT INBOX -->
<-- * FLAGS (Meeting Notice \Answered
\Flagged \Deleted \Seen)
<-- * 19 EXISTS
<-- * 2 RECENT
<-- A0002 OK Select complete
{Wait for command}
A003 FETCH 1:19 ALL -->
<-- * 1 Fetch (......)
...
<-- * 18 Fetch (......)
<-- * 19 Fetch (......)
<-- A003 OK Fetch complete
{Wait for command}
A004 FETCH 8 RFC822.TEXT -->
<-- * 8 Fetch (RFC822.TEXT {893}
...893 characters of text...
<-- )
<-- A004 OK Fetch complete
{Wait for command}
クライアントサーバ------ ------ Connectionを待ってください、開いているConnection--><--*OK IMAP2 Server Readyがコマンドを待っている、A001 LOGINフレッドSecret--><--A001 OK Userフレッド、登録されて、A002 SELECT INBOXは中でコマンドを待っています--><--*FLAGS(ミーティングNotice\Answered\Flagged\Deleted\Seen)<--*、<--*2RECENT<--A0002 OK Selectが完成する19EXISTSがコマンドを待っている、A003 FETCH、1:19 すべて--><--*1、Fetch、() ... <-- * 18がとって来る、() <-- * 19がとって来る、() <-- A003 OK Fetchがコマンドのための待ちを終了する、A004 FETCH8RFC822.TEXT--><--*8Fetch(テキスト(<)のRFC822.TEXT893.893のキャラクタ)<--、A004 OK Fetchは完成します。コマンドを待ってください。
Crispin [Page 8] RFC 1176 IMAP2 August 1990
クリスピン[8ページ]RFC1176IMAP2 August 1990
A005 STORE 8 +Flags \Deleted -->
<-- * 8 Store (Flags (\Deleted
\Seen))
<-- A005 OK Store complete
{Wait for command}
A006 EXPUNGE -->
<-- * 19 EXISTS
<-- * 8 EXPUNGE
<-- * 18 EXISTS
<-- A006 Expunge complete
{Wait for command}
A007 LOGOUT -->
<-- * BYE IMAP2 server quitting
<-- A007 OK Logout complete
{Close Connection} --><-- {Close connection}
{Go back to start}
Conventions
><--*19EXISTS<--8EXPUNGE<--*18EXISTS<--A006 Expungeが完成する*はコマンドを待っています。A005 STORE8+は\Deletedに旗を揚げさせます--><--*8ストア(旗(\Deleted\Seen))<--A005 OKストアがコマンドのための待ちを終了する、A006 EXPUNGE--、A007 LOGOUT--><--<をやめる*BYE IMAP2サーバ--A007 OK Logoutは近いConnectionを完成します--、><、--、浅からぬ関係が始まるように戻るコンベンション
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 that 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文字の人間読み込み可能な系列です。
A common field in the IMAP2 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
IMAP2プロトコルの共同耕地はSTRINGです。(そのSTRINGはATOM、QUOTED-STRING(二重引用符におけるCHARACTERsの系列)、またはLITERALであるかもしれません)。 リテラルが開きの中括弧から成る、(「「)、数、近い支柱(「}」)、CRLF、および次に、nキャラクタのASCII-ストリング、」。そこでは、nが支柱における数の値です。 一般に、できれば、ストリングはATOMかQUOTED-STRINGとして表されるべきです。 QUOTED-STRINGのための意味論かLITERALがそれらの前にATOMがないかどうかチェックされます。 したがって、STRINGで使用されるATOMはそうするだけであるかもしれません。
Crispin [Page 9] RFC 1176 IMAP2 August 1990
クリスピン[9ページ]RFC1176IMAP2 August 1990
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).
CHARACTERsを含んでください。 サーバからクライアントにリテラルをたいてい送ります。 「サーバリテラルへのクライアントのまれなケースには、特別の配慮がある、(見る、」 + テキスト、」、以下での応答)
Another important field is the SEQUENCE, which identifies a set of 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 (equivalent to all numbers between those two numbers), or a list of single numbers 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 those messages.
別の重要な分野はSEQUENCEです。(一連番号に従って、そのSEQUENCEはnがメールボックスの中のメッセージの数であるところで1セットのメッセージを1〜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 || Responses
-------- || -------
tag NOOP || tag OK text
tag LOGIN user password || tag NO text
tag LOGOUT || tag BAD text
tag SELECT mailbox || * number message_data
tag BBOARD bulletin_board || * FLAGS flag_list
tag FIND MAILBOXES pattern || * SEARCH sequence
tag FIND BBOARDS pattern || * BBOARD string
tag CHECK || * MAILBOX string
tag EXPUNGE || * BYE text
tag COPY sequence mailbox || * OK text
tag FETCH sequence data || * NO text
tag STORE sequence data value || * BAD text
tag SEARCH search_program || + text
コマンド|| 応答-------- || ------- タグNOOP|| タグOKテキストタグLOGINユーザパスワード|| タグいいえテキストタグLOGOUT|| タグBADテキストタグSELECTメールボックス|| * 数のメッセージ_データタグBBOARD報告_ボード|| * FLAGS旗_リストタグFIND MAILBOXESパターン|| * 検索塩基配列タグFIND BBOARDSパターン|| * BBOARDストリングタグCHECK|| * MAILBOXストリングタグEXPUNGE|| * BYEテキストタグCOPY系列メールボックス|| * OKテキストタグFETCH系列データ|| * テキストタグストア系列データ価値がありません。|| * BADテキストタグ検索検索_プログラム|| + テキスト
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 that 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 that 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
LOGINコマンドは、サーバにユーザを特定して、このユーザを認証しながら、パスワードを運びます。 この情報は使用されています。
Crispin [Page 10] RFC 1176 IMAP2 August 1990
クリスピン[10ページ]RFC1176IMAP2 August 1990
by the server to control access to the mailboxes.
メールボックスへのアクセスを制御するサーバで。
EXAMPLE: A001 LOGIN SMITH SESAME
logs in as user SMITH with password SESAME.
例: A001 LOGIN SMITH SESAMEはパスワードSESAMEと共にユーザスミスとしてログインします。
tag LOGOUT
タグLOGOUT
The LOGOUT command informs the server that the client is done with
the session. The server should send an unsolicited BYE response
before the (tagged) OK response, and then close the network
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.
Before returning an OK to the client, the server must send the
following unsolicited data to the client:
FLAGS mailbox's defined flags
<n> EXISTS the number of messages in the mailbox
<n> RECENT the number of new messages in the mailbox
in order to define the initial state of the mailbox at the client.
SELECTコマンドは特定のメールボックスを選択します。 サーバは、このメールボックスへのアクセスが読まれて、ユーザが受入れられるのをチェックしなければなりません。 OKをクライアントに返す前に、サーバは以下の求められていないデータをクライアントに送らなければなりません: FLAGSメールボックスが旗の<n>EXISTSを定義した、数、メールボックス<n>RECENTでは、クライアントでメールボックスの初期状態を定義するためにメールボックスの中の新しいメッセージの数を通信させます。
Multiple SELECT commands are permitted in a session, in which case
the previous mailbox is automatically deselected when a new SELECT
is made.
複数のSELECTコマンドがセッションのときに受入れられます、新しい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 filename
path of the mailbox file on the current servers).
SELECTコマンドのためのデフォルトメールボックスが受信トレイである、どれが特別な名前であるかは「このサーバのこのユーザのためのプライマリメールボックス」を平均に予約しました。 他のメールボックス名の形式はオペレーティングシステムに依存しています(この書くこと現在、それは現在のサーバのメールボックスファイルのファイル名経路を反映します)。
It is customary, although not required, for the text of an OK
response to the SELECT command to begin with either "[READ-ONLY]"
or "[READ-WRITE]" to show the mailbox's access status.
それは通例です、初めに、SELECTコマンドへのOK応答のテキストにメールボックスのアクセス状況を示しているために「[読書唯一]」か「[読書して書きます]」であることで必要ではありませんが。
EXAMPLE: A002 SELECT INBOX
selects the default mailbox.
例: A002 SELECT INBOXはデフォルトメールボックスを選択します。
tag BBOARD bulletin_board
タグBBOARD報告_ボード
The BBOARD command is equivalent to SELECT, and returns the same
output. However, it differs from SELECT in that its argument is a
shared mailbox (bulletin board) name instead of an ordinary
mailbox. The format of a bulletin 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
BBOARDコマンドは、SELECTに同等であり、同じ出力を返します。 しかしながら、それは議論が普通のメールボックスの代わりに共有されたメールボックス(掲示板)名であるという点においてSELECTと異なっています。 報告名の形式は実装特有です、ファイルかメールボックス名ではなく、ジェネリック意味で名前に類似している何かを使用するよう強く奨励されますが
Crispin [Page 11] RFC 1176 IMAP2 August 1990
クリスピン[11ページ]RFC1176IMAP2 August 1990
on the particular system. There is no requirement that a bulletin
board name be a mailbox name or a file name (in particular, Unix
netnews has a completely different namespace from mailbox or file
names).
特定のシステムに関して。 掲示板の名がメールボックス名かファイル名であるという要件が全くありません(Unixネットニュースには、特に、メールボックスかファイル名からの完全に異なった名前空間があります)。
Support for BBOARD is optional.
BBOARDのサポートは任意です。
tag FIND MAILBOXES pattern
タグFIND MAILBOXESパターン
The FIND MAILBOXES command accepts as an argument a pattern
(including wildcards) that specifies some set of mailbox names
that are usable by the SELECT command. The format of mailboxes is
implementation dependent. The special mailbox name INBOX is not
included in the output.
FIND MAILBOXESコマンドは議論として何らかのセットのSELECTコマンドで使用可能なメールボックス名を指定するパターン(ワイルドカードを含んでいる)を認めます。 メールボックスの形式は実装に依存しています。 受信トレイという特別なメールボックス名は出力に含まれていません。
Two wildcard characters are defined; "*" specifies any number
(including zero) characters may match at this position and "%"
specifies 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. "*" will match all
mailboxes.
2つのワイルドカードキャラクタが定義されます。 「*」は(ゼロを含んでいます)キャラクタがこの位置で合っているどんな数も指定します、そして、「%」は単独のキャラクタを指定します。この位置で合うかもしれません。 例えば、FOO*BARはFOOBAR、FOOD.ON.THE.BAR、およびFOO.BARに合うでしょうが、FOO%BARはFOO.BARだけに合うでしょう。 「*」はすべてのメールボックスに合うでしょう。
The FIND MAILBOXES command will return some set of unsolicited
MAILBOX replies that have as their value a single mailbox name.
FIND MAILBOXESコマンドはそれらの値としてただ一つのメールボックス名を持っている何らかのセットの求められていないMAILBOX回答を返すでしょう。
EXAMPLE: A002 FIND MAILBOXES *
* MAILBOX FOOBAR
* MAILBOX GENERAL
A002 FIND completed
例: MAILBOX FOOBAR*MAILBOX GENERAL A002 FINDが完成したA002 FIND MAILBOXES**
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 unsolicited reply
be usable in the SELECT command without remembering any path
specification that may have been used in the FIND MAILBOXES
pattern.
明白なファイルかパス名のメールボックスの使用はこの規格でお勧めできないのですが、それは避けられないかもしれません。 MAILBOXの求められていない回答で返された値がFIND MAILBOXESパターンで使用されたどんな経路仕様も覚えていないでSELECTコマンドで使用可能であることは、重要です。
Support for FIND MAILBOXES is optional. If a client's attempt
returns BAD as a response then the client can make no assumptions
about what mailboxes exist on the server other than INBOX.
FIND MAILBOXESのサポートは任意です。 クライアントの試みが応答としてBADを返すなら、クライアントはどんなメールボックスが受信トレイ以外のサーバに存在するかに関する仮定を全くすることができません。
tag FIND BBOARDS pattern
タグFIND BBOARDSパターン
The FIND BBOARDS command accepts as an argument a pattern that
specifies some set of bulletin board names that are usable by the
BBOARD command. Wildcards are permitted as in FIND MAILBOXES.
FIND BBOARDSコマンドは議論として何らかのセットのBBOARDコマンドで使用可能な掲示板の名を指定するパターンを認めます。 ワイルドカードはFIND MAILBOXESのように受入れられます。
The FIND BBOARDS command will return some set of unsolicited
FIND BBOARDSコマンドは求められていないことの何らかのセットを返すでしょう。
Crispin [Page 12] RFC 1176 IMAP2 August 1990
クリスピン[12ページ]RFC1176IMAP2 August 1990
BBOARD replies that have as their value a single bulletin board
name.
それらの値としてただ一つの掲示板の名があるBBOARD回答。
EXAMPLE: A002 FIND BBOARDS *
* BBOARD FOOBAR
* BBOARD GENERAL
A002 FIND completed
例: BBOARD FOOBAR*BBOARD GENERAL A002 FINDが完成したA002 FIND BBOARDS**
Support for FIND BBOARDS is optional. If a client's attempt
returns BAD as a response then the client can make no assumptions
about what bulletin boards exist on the server, or that they exist
at all.
FIND BBOARDSのサポートは任意です。 クライアントの試みが応答としてBADを返すなら、クライアントがどんな掲示板がサーバに存在するかに関する仮定を全くすることができませんか、またはそれらは全く存在しています。
tag CHECK
タグCHECK
The CHECK command forces a check for new messages and a rescan of
the mailbox for internal change for those implementations that
allow multiple simultaneous read/write access to the same mailbox.
It is recommend that periodic implicit checks for new mail be done
by servers as well. The server should send unsolicited EXISTS and
RECENT responses with the current status before returning an OK to
the client.
同時の状態で倍数を許容するそれらの実装のための内的変化のためのメールボックスの再スキャンは、同じメールボックスへのアクセスをCHECKコマンドが新しいメッセージのためのチェックを強制して、読むか、または書きます。 それはまた、サーバで新しいメールのための周期的な暗黙のチェックをすることを勧めることです。 サーバはOKをクライアントに返す前の現在の状態がある応答を求められていないEXISTSとRECENTに送るべきです。
tag EXPUNGE
タグEXPUNGE
The EXPUNGE command permanently removes all messages with the
\DELETED flag set in its flags from the mailbox. Before returning
an OK to the client, for each message that is removed, an
unsolicited EXPUNGE response is sent. The message number for each
successive message in the mailbox is immediately decremented by 1;
this means that if the last 5 messages in a 9-message mail file
are expunged you will receive 5 unsolicited EXPUNGE responses for
message 5. To ensure mailbox integrity and server/client
synchronization, it is recommended that the server do an implicit
check before commencing the expunge and again when the expunge is
completed. Furthermore, if the server allows multiple
simultaneous access to the same mail file the server must lock the
mail file for exclusive access while an expunge is taking place.
EXPUNGEコマンドは永久に、DELETED旗がメールボックスから旗で設定した\があるすべてのメッセージを取り除きます。 取り除かれる各メッセージのためにOKをクライアントに返す前に、求められていないEXPUNGE応答を送ります。 メールボックスの中のそれぞれの連続したメッセージのメッセージ番号はすぐに、1つ減少します。 これは、9メッセージのメールファイルにおける最後の5つのメッセージが梢消されるとあなたがメッセージ5のために5つの求められていないEXPUNGE応答を受けることを意味します。 メールボックス保全とサーバ/クライアント同期を確実にするために、サーバが始まる前に暗黙のチェックをするのが、お勧めである、梢消、再びいつ、梢消、完成されるか。 その上、サーバが同じメールファイルへの複数の同時アクセスを許容するならサーバが排他的なアクセスのためのファイルがゆったり過ごすメールをロックしなければならない、梢消、場所を取っています。
EXPUNGE is not allowed if the user does not have write access to
this mailbox.
EXPUNGEはユーザであるなら許容されていません。このメールボックスへのアクセスを書かせないでください。
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. Before returning an OK to the
client, the server should return an unsolicited <n> COPY response
COPYコマンドは指定されたあて先メールボックスに指定されたメッセージをコピーします。 あて先メールボックスが存在していないなら、サーバはそれを作成するべきです。 OKをクライアントに返す前に、サーバは>COPY応答を求められていない<nに返すべきです。
Crispin [Page 13] RFC 1176 IMAP2 August 1990
クリスピン[13ページ]RFC1176IMAP2 August 1990
for each message copied. A copy should set the \SEEN flag for all
messages that were successfully copied (provided, of course, that
the user has write access to this mailbox).
各メッセージがコピーされたので。 コピーがSEENが首尾よくコピーされたすべてのメッセージのために旗を揚げさせる\を設定するはずである、(もちろん提供する、ユーザがこのメールボックスへのアクセスを書かせる、)
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.
COPYはユーザであるなら許容されていません。あて先メールボックスへのアクセスを書かせないでください。
tag FETCH sequence data
タグFETCH系列データ
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 currently defined data items that
can be fetched are:
FETCHコマンドはメールボックスの中のメッセージに関連しているデータを検索します。 とって来られるデータ項目は、単一原子かS-式リストのどちらかであるかもしれません。 とって来ることができる現在定義されたデータ項目は以下の通りです。
ALL Macro equivalent to:
(FLAGS INTERNALDATE RFC822.SIZE ENVELOPE)
以下とすべてのMacro同等物 (INTERNALDATE RFC822.SIZE封筒に旗を揚げさせます)
ENVELOPE The envelope of the message. The envelope is
computed by the server by parsing the RFC 822
header into the component parts, defaulting
various fields as necessary.
ENVELOPE、メッセージの封筒。 封筒は、RFC822ヘッダーのコンポーネントの部品(必要に応じてデフォルト多岐)を分析することによって、サーバによって計算されます。
FAST Macro equivalent to:
(FLAGS INTERNALDATE RFC822.SIZE)
以下とFAST Macro同等物 (INTERNALDATE RFC822.SIZEに旗を揚げさせます)
FLAGS The flags that are set for this message.
This may include the following system flags:
FLAGS、このメッセージに設定される旗。 これは以下のシステム旗を含むかもしれません:
\RECENT Message arrived since the
previous time this mailbox
was read
\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がSEEN Messageに読み込まれたというこのメールボックスによることであった前回が\FLAGGED Messageが答えられているのが、後のEXPUNGEによる\DELETED Messageが「削除される」緊急の、または、特別な注意のために「旗を揚げられて」取り外しであるということであるので、\RECENT Messageは到着しました。
INTERNALDATE The date and time the message was written to
the mailbox.
INTERNALDATE、メッセージがメールボックスに書かれた日時。
Crispin [Page 14] RFC 1176 IMAP2 August 1990
クリスピン[14ページ]RFC1176IMAP2 August 1990
RFC822 The message in RFC 822 format. The \SEEN
flag is implicitly set; if this causes the
flags to change they should be included as
part of the fetch results. This is the
concatenation of RFC822.HEADER and RFC822.TEXT.
RFC822、RFC822形式におけるメッセージ。 SEENが旗を揚げさせる\はそれとなく設定されます。 旗がこれで変化するなら、フェッチの一部が結果として生じている間、それらは含まれるべきです。 これはRFC822.HEADERとRFC822.TEXTの連結です。
RFC822.HEADER The "raw" RFC 822 format header of the message
as stored on the server.
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. The \SEEN flag is implicitly
set as with RFC822 above.
RFC822.TEXT、RFC822ヘッダーを省略するテキストメッセージ欄。 SEENが旗を揚げさせる\は上であることの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形式ヘッダーをとって来ます。
Note: An attempt to FETCH already-transmitted data may have no
result. See the Implementation Discussion below.
以下に注意してください。 既にFETCHに伝えられたデータがそうする試みはそうしました。結果がありません。 以下のImplementation Discussionを見てください。
tag STORE sequence data value
タグストア系列データ価値
The STORE command alters data associated with a message in the
mailbox. The currently defined data items that can be stored are:
ストアコマンドはメールボックスの中のメッセージに関連しているデータを変更します。 保存できる現在定義されたデータ項目は以下の通りです。
FLAGS Replace the flags for the message with the
argument (in flag list format).
FLAGS Replace、主張(現役将官名簿形式における)があるメッセージのための旗。
+FLAGS Add the flags in the argument to the
message's flag list.
+ メッセージの旗への議論における旗が記載するFLAGS Add。
-FLAGS Remove the flags in the argument from the
message's flag list.
-メッセージの旗からの議論における旗が記載するFLAGS Remove。
STORE is not allowed if the user does not have write access to
this mailbox.
ストアはユーザであるなら許容されていません。このメールボックスへのアクセスを書かせないでください。
Crispin [Page 15] RFC 1176 IMAP2 August 1990
クリスピン[15ページ]RFC1176IMAP2 August 1990
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 that match
the given set of criteria. The unsolicited SEARCH <1#number>
response from the server is a list of messages that express the
intersection (AND function) of all the messages which match that
criteria. For 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 mail file since October 1, 1987.
検索命令は与えられたセットの評価基準に合っているメッセージのためにメールボックスを捜します。 サーバからの求められていない検索<1#数の>応答はその評価基準に合っているすべてのメッセージの交差点(AND機能)を言い表すメッセージのリストです。 例えば、1 10月の87以来のA003検索DELETED FROM「スミス」はメッセージを1987年10月1日以来メールファイルに置かれたスミスからすべての数が削除したメッセージに返します。
In all search criteria which use strings, a message matches the
criteria if the string is a case-independent substring of that
field. The currently defined criteria are:
ストリングを使用するすべての検索評価基準では、メッセージはストリングがその分野のケースから独立しているサブストリングであるなら評価基準に合っています。 現在定義された評価基準は以下の通りです。
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とデートします。
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を結びます。
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も弛みません。 これが機能上相当している、「最近、見えなさ、」
Crispin [Page 16] RFC 1176 IMAP2 August 1990
クリスピン[16ページ]RFC1176IMAP2 August 1990
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を結びます。
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がセットしました。
Crispin [Page 17] RFC 1176 IMAP2 August 1990
クリスピン[17ページ]RFC1176IMAP2 August 1990
Responses
応答
tag OK text
タグOKテキスト
This response identifies successful completion of the command with
that tag. The text is a line of human-readable text that may be
useful in a protocol telemetry log for debugging purposes.
この応答はコマンドの無事終了をそのタグと同一視します。 テキストはデバッグ目的のためのプロトコル遠隔測定法のログで役に立つかもしれない人間読み込み可能なテキストの系列です。
tag NO text
タグいいえテキスト
This response identifies unsuccessful completion of the command
with that tag. The text is a line of human-readable text that
probably should be displayed to the user in an error report by the
client.
この応答はコマンドの失敗の完成をそのタグと同一視します。 テキストはたぶんクライアントによるエラー・レポートにユーザに表示されるべきである人間読み込み可能なテキストの系列です。
tag BAD text
タグBADテキスト
This response identifies faulty protocol received from the client;
The text is a line of human-readable text that should be recorded
in any telemetry as part of a bug report to the maintainer of the
client.
この応答はクライアントから受け取られた不完全なプロトコルを特定します。 テキストはクライアントの維持装置へのバグレポートの一部としてどんな遠隔測定法にも記録されるべきである人間読み込み可能なテキストの系列です。
* number message_data
* 数のメッセージ_データ
This response occurs as a result of several different commands.
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
previous time this mailbox was read.
RECENT、このメールボックスが前の時に読まれて以来、メッセージの指定された数は到着しています。
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.
EXPUNGE、指定されたメッセージ番号は永久に、メールボックスから移されて、メールボックス(もしあれば)の中の次のメッセージはそのメッセージ番号になります。
STORE data
Obsolete and functionally equivalent to FETCH.
Obsoleteの、そして、FETCHに機能上同等なストアデータ。
FETCH data
This is the principle means by which data about a
message is returned to the client. The data is in a
Lisp-like S-expression property list form. The current
properties are:
FETCHデータThisはメッセージに関するデータがクライアントに返される原則手段です。 データがLispのようなS-式特性のリスト形式にあります。 現在の特性は以下の通りです。
ENVELOPE An S-expression format list that describes the
envelope of a message. The envelope is computed
by the server by parsing the RFC 822 header into
メッセージの封筒について説明するENVELOPE An S-式形式リスト。 封筒は、RFC822ヘッダーを分析することによって、サーバによって計算されます。
Crispin [Page 18] RFC 1176 IMAP2 August 1990
クリスピン[18ページ]RFC1176IMAP2 August 1990
the component parts, defaulting various fields
as necessary.
コンポーネントの部品、必要に応じてデフォルト多岐。
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 that
describes an electronic mail address. The fields
of an address are in the following order:
personal name, source-route (a.k.a. the
at-domain-list in SMTP), mailbox name, and
host name.
アドレスは電子メールアドレスについて説明するS-式形式リストです。 アドレスの分野が以下のオーダーにあります: 個人名、送信元経路(通称ドメインリストSMTP)、メールボックス名、およびホスト名。
Any field of an envelope or address that 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 that are set
for this message. This may include the following
system flags:
このメッセージに設定される旗のFLAGS An S-式形式リスト。 これは以下のシステム旗を含むかもしれません:
\RECENT Message arrived since the
previous time this mailbox
was read
\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がSEEN Messageに読み込まれたというこのメールボックスによることであった前回が\FLAGGED Messageが答えられているのが、後のEXPUNGEによる\DELETED 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.
RFC822形式におけるメッセージを言い表すRFC822五弦。
RFC822.HEADER A string expressing the RFC 822 format
header of the message
メッセージのRFC822形式ヘッダーを急送するRFC822.HEADER五弦
RFC822.SIZE A number indicating the number of
characters in the message as expressed
言い表されるようにメッセージのキャラクタの数を示すRFC822.SIZE A番号
Crispin [Page 19] RFC 1176 IMAP2 August 1990
クリスピン[19ページ]RFC1176IMAP2 August 1990
in RFC 822 format.
RFC822形式で。
RFC822.TEXT A string expressing the text body of the
message, omitting the RFC 822 header.
RFC822ヘッダーを省略して、テキストメッセージ欄を言い表すRFC822.TEXT五弦。
* FLAGS flag_list
* FLAGS旗_リスト
This response occurs as a result of a SELECT command. The flag
list are the list of flags (at a minimum, the system-defined
flags) that are applicable for this mailbox. Flags other than the
system flags are a function of the server implementation.
この応答はSELECTコマンドの結果、起こります。 現役将官名簿はこのメールボックスに、適切な旗(最小限におけるシステムで定義された旗)のリストです。 システム旗以外の旗はサーバ実装の機能です。
* SEARCH number(s)
* 検索番号(s)
This response occurs as a result of a SEARCH command. The
number(s) refer to those messages that match the search criteria.
Each number is delimited by a space, e.g., "SEARCH 2 3 6".
この応答は検索命令の結果、起こります。 数は検索評価基準に合っているそれらのメッセージを示します。 各数は例えば、「2 3を何6インチも捜してください」というスペースによって区切られて、ことです。
* BBOARD string
* BBOARDストリング
This response occurs as a result of a FIND BBOARDS command. The
string is a bulletin board name that matches the pattern in the
command.
この応答はFIND BBOARDSコマンドの結果、起こります。 ストリングはコマンドにおけるパターンに合っている掲示板の名です。
* MAILBOX string
* MAILBOXストリング
This response occurs as a result of a FIND MAILBOXES command. The
string is a mailbox name that matches the pattern in the command.
この応答はFIND MAILBOXESコマンドの結果、起こります。 ストリングはコマンドにおけるパターンに合っているメールボックス名です。
* BYE text
* BYEテキスト
This response identifies that the server is about to close the
connection. The text is a line of human-readable text that should
be displayed to the user in a status report by the client. This
may be sent as part of a normal logout sequence, or as a panic
shutdown announcement by the server. It is also used by some
servers as an announcement of an inactivity autologout.
この応答は、サーバが接続を終えようとしているのを特定します。 テキストは現状報告にクライアントによってユーザに表示されるべきである人間読み込み可能なテキストの系列です。 標準の一部がログアウトするとき、これを送るかもしれません。配列するか、またはまた. それが不活発の発表としていくつかのサーバによって使用されるというサーバによるパニック閉鎖発表autologoutします。
* OK text
* OKテキスト
This response identifies normal operation on the server. No
special action by the client is called for, however, the text
should be displayed to the user in some fashion. This is
currently only used by servers at startup as a greeting message to
show they are ready to accept the first command.
この応答はサーバで通常の操作を特定します。クライアントによるどんな特別な動きも求めないで、しかしながら、何らかのファッションでユーザにテキストを表示するべきです。 これは現在、それらが最初のコマンドを受け入れる準備ができているのを示すあいさつメッセージとして始動でサーバによって使用されるだけです。
Crispin [Page 20] RFC 1176 IMAP2 August 1990
クリスピン[20ページ]RFC1176IMAP2 August 1990
* NO text
* テキストがありません。
This response identifies a warning from the server that does not
affect the overall results of any particular request. The text is
a line of human-readable text that should be presented to the user
as a warning of improper operation.
この応答はどんな特定の要求の総合的な結果にも影響しないサーバからの警告を特定します。 テキストは不適当な操作に関する警告としてユーザに提示されるべきである人間読み込み可能なテキストの系列です。
* BAD text
* BADテキスト
This response identifies a serious error at the server; it may
also indicate faulty protocol from the client in which a tag could
not be parsed. The text is a line of human-readable text that
should be presented to the user as a serious or possibly fatal
error. It should also be recorded in any telemetry as part of a
bug report to the maintainer of the client and server.
この応答はサーバにおける重大な誤りを特定します。 また、それはタグを分析できなかったクライアントから不完全なプロトコルを示すかもしれません。 テキストは重大であるかことによると致命的な誤りとしてユーザに提示されるべきである人間読み込み可能なテキストの系列です。 また、それはクライアントとサーバの維持装置へのバグレポートの一部としてどんな遠隔測定法にも記録されるべきです。
+ text
+ テキスト
This response identifies 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 for commands that 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 expects it,
preserving client/server synchronization.
この応答は、サーバをクライアントからリテラルのテキストを受け入れる準備ができているのを特定します。 通常、クライアントからのコマンドはただ一つのテキスト系列です。 サーバがコマンドにおける誤りを検出するなら、それは単に系列の残りを捨てることができます。 それはリテラルを含むコマンドのためにこれができません、リテラルが任意に長い量のテキストであるかもしれなく、サーバがリテラルを予想してさえいないかもしれないので。 このメカニズムはしたがって、クライアントが、サーバがそれを予想するまでリテラルを送らないのを知っているかどうかということです、クライアント/サーバ同期を保存して。
In practice, this condition is rarely encountered. In the current
protocol, the only client command likely to contain a literal is
the LOGIN command. Consider a server that 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コマンドです。 パスワードをチェックする前にユーザを有効にするサーバを考えてください。 パスワードを「おかしい」キャラクタを含んでいて、したがって、リテラルとして送るなら、ユーザが無効であるなら、パスワードが分析される前に誤りは発生するでしょう。
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 caused by a
bug in the client or server.
サーバからクライアントに送られたリテラル、性能理由にどんなそのような同期保護も提供しません。 この方向へのどんな同期問題もクライアントかサーバのバグによって引き起こされるでしょう。
Crispin [Page 21] RFC 1176 IMAP2 August 1990
クリスピン[21ページ]RFC1176IMAP2 August 1990
Sample IMAP2 session
サンプルIMAP2セッション
The following is a transcript of an IMAP2 session. Server output is identified by "S:" and client output by "U:". In cases where lines are too long to fit within the boundaries of this document, the line is continued on the next line.
↓これはIMAP2セッションの転写です。 サーバ出力が特定される、「S:」 出力されたクライアント、「U:」 系列がこのドキュメントの区域内に合うことができないくらい長い場合では、系列は次の系列で続けられています。
S: * OK SUMEX-AIM.Stanford.EDU Interim Mail Access Protocol II Service
6.1(349) at Thu, 9 Jun 88 14:58:30 PDT
U: a001 login crispin secret
S: a002 OK User CRISPIN logged in at Thu, 9 Jun 88 14:58:42 PDT, job 76
U: a002 select inbox
S: * FLAGS (Bugs SF Party Skating Meeting Flames Request AI Question
Note \XXXX \YYYY \Answered \Flagged \Deleted \Seen)
S: * 16 EXISTS
S: * 0 RECENT
S: a002 OK Select complete
U: a003 fetch 16 all
S: * 16 Fetch (Flags (\Seen) InternalDate " 9-Jun-88 12:55:44 PDT"
RFC822.Size 637 Envelope ("Sat, 4 Jun 88 13:27:11 PDT"
"INFO-MAC Mail Message" (("Larry Fagan" NIL "FAGAN"
"SUMEX-AIM.Stanford.EDU")) (("Larry Fagan" NIL "FAGAN"
"SUMEX-AIM.Stanford.EDU")) (("Larry Fagan" NIL "FAGAN"
"SUMEX-AIM.Stanford.EDU")) ((NIL NIL "rindflEISCH"
"SUMEX-AIM.Stanford.EDU")) NIL NIL NIL
"<12403828905.13.FAGAN@SUMEX-AIM.Stanford.EDU>"))
S: a003 OK Fetch completed
U: a004 fetch 16 rfc822
S: * 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: a004 OK Fetch completed
S: * 木曜日のSUMEX-AIM.Stanford.EDU当座メールアクセス・プロトコルIIサービス6.1(349)、1988年6月9日の太平洋夏時間14時58分30秒にUを承認してください: a001ログインcrispin秘密S: 仕事76のU、a002OK Userクリスピンは木曜日、1988年6月9日の太平洋夏時間14時58分42秒にログインしました: a002の選んだ受信トレイS: * 旗(バグSFパーティスケートミーティングフレームズは、\に答えた\が\に旗を揚げさせたというAI質問注意\XXXX\YYYYが見られた\を削除したよう要求する)のS: * 16が存在している、S: * 0、最近のS: a002OK SelectはUを完成します: a003フェッチ、16 すべてのS: * 「16が無 "<12403828905.13.FAGAN@SUMEX-AIM.Stanford.EDU 無無をとって来る、(「1988年6月9日の太平洋夏時間12時55分44秒」というInternalDate RFC822.Size637封筒(「土曜日、1988年6月4日の太平洋夏時間13時27分11秒」のときに、「インフォメーション-MACはメッセージを郵送する」(「ラリー・フェーガン」無「フェーガン」"SUMEX-AIM.Stanford.EDU"))((「ラリー・フェーガン」無「フェーガン」"SUMEX-AIM.Stanford.EDU"))((「ラリー・フェーガン」無「フェーガン」"SUMEX-AIM.Stanford.EDU"))(無"rindflEISCH""SUMEX-AIM.Stanford.EDU"無)に旗を揚げさせます(見られた\))gt;、」、)、S: a003OK FetchはUを完成しました: a004フェッチ16rfc822 S: * 16フェッチ; (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: OK Fetchが完成したa004
Crispin [Page 22] RFC 1176 IMAP2 August 1990
クリスピン[22ページ]RFC1176IMAP2 August 1990
U: a005 logout
S: * BYE DEC-20 IMAP II server terminating connection
S: a005 OK SUMEX-AIM.Stanford.EDU Interim Mail Access Protocol
Service logout
U: a005がログアウトする、S: * 接続Sを終えるBYE DEC-20IMAP IIサーバ: a005OK SUMEX-AIM.Stanford.EDU InterimメールAccessプロトコルServiceはログアウトします。
Crispin [Page 23] RFC 1176 IMAP2 August 1990
クリスピン[23ページ]RFC1176IMAP2 August 1990
Implementation Discussion
実装議論
There are several advantages to the scheme of tags and unsolicited
responses. First, the infamous synchronization problems of SMTP and
similar protocols do not happen with tagged commands; a command is
not considered satisfied until a response with the same tag is seen.
Tagging allows an arbitrary amount of other responses ("unsolicited"
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.
タグと求められていない応答の体系のいくつかの利点があります。 まず最初に、SMTPと同様のプロトコルの悪名高い同期問題はタグ付けをされたコマンドで起こりません。 同じタグによる応答が見られるまで、コマンドは満足していると考えられません。 タグ付けは、他の任意の量の応答(「求められていません、な」データ)がサーバによって同期を失うクライアントの可能性なしで送られるのを許容します。 FTPかSMTPクライアントが継続、部分的な完成、および論評回答コードで持っている問題とこれを比べてください。
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 that would signal the client when the tagged response comes in. Under certain circumstances, the client may have more than one command outstanding.
別の利点は非型にはまったやり方クライアント実装が可能であるということです。 クライアントは、コマンドを送って、タグ付けをされた応答が入るとクライアントに合図する異なったプロセスにサーバ応答の取り扱いを任せることができました。 ある状況で、クライアントには、未払いの1つ以上のコマンドがあるかもしれません。
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 rare; a mechanism (the special "+" tag response) was introduced to handle those few cases. The proper way to address this problem is probably to move towards a record-oriented architecture instead of the text stream model provided by TCP.
リテラルがそういうものとして認識されないなら同期問題がリテラルで起こることができると認められました。 幸い、これが起こることができる場合はまれです。 メカニズム(特別な「+」タグ応答)は、それらのわずかなケースを扱うために紹介されました。 たぶんTCPによって提供されたテキストストリームモデルの代わりに記録指向のアーキテクチャに向かった移動にはこのその問題を訴える適切な方法があります。
An IMAP2 client must maintain a local cache of data from the mailbox. This cache is an incomplete model of the mailbox, and at startup is empty. A listener processes all unsolicited data, and updates the cache based on this data. If a tagged response arrives, the listener unblocks the process that sent the tagged request.
IMAP2クライアントはメールボックスからのデータのローカルなキャッシュを維持しなければなりません。 このキャッシュは、メールボックスの不完全なモデルであり、始動で空です。 リスナーは、すべての求められていないデータを処理して、このデータに基づくキャッシュをアップデートします。 タグ付けをされた応答が到着するなら、リスナーはタグ付けをされた要求を送ったプロセスを「非-妨げ」ます。
Unsolicited data needs some discussion. Unlike most protocols, in which the server merely does the client's bidding, an IMAP2 server has a semi-autonomous role. By sending "unsolicited data", the server is in effect sending a command to the client -- to update or extend the client's cache with new information from the server. In other words, a "fetch" command is merely a request to the server to ensure that the client's cache has the most up-to-date version of the requested information. A server acknowledgement to the "fetch" is a statement that all the requested data has been sent.
求められていないデータは何らかの議論を必要とします。 IMAP2サーバには、ほとんどのプロトコルと異なって、半自治の役割があります。そこでは、サーバが単にクライアントのものの言う通りにします。 送付「求められていないデータ」で、サーバはコマンドをクライアントに送りながら、有効です--新情報でサーバからクライアントのキャッシュをアップデートするか、または広げるために。言い換えれば、「とって来」コマンドは単にクライアントのキャッシュには求められた情報の最も最新のバージョンがあるのを保証するサーバへの要求です。 「フェッチ」へのサーバ承認はすべての要求されたデータを送ったという声明です。
Although no current server does this, a server is not obliged by the protocol to send data that it has already sent and is unchanged. An exception to this is the actual message text fetching operations (RFC822, RFC822.HEADER, and RFC822.TEXT), owing to the possibly excessive resource consumption of maintaining this data in a cache. It can not be assumed that a FETCH will transmit any data; only that an OK to the FETCH means that the client's cache has the most up-to-
どんな現在のサーバもこれをしませんが、サーバは、プロトコルによってそれが既に送ったデータを送るのは強いられないで、変わりがありません。 これへの例外は実際のメッセージ・テキスト魅惑的な操作(RFC822、RFC822.HEADER、およびRFC822.TEXT)です、キャッシュでこのデータを保守することによると過度のリソース消費のために。 FETCHがどんなデータも送ると思うことができません。 FETCHへのOKが、大部分がクライアントのキャッシュで密かに企てることを意味するだけである、-
Crispin [Page 24] RFC 1176 IMAP2 August 1990
クリスピン[24ページ]RFC1176IMAP2 August 1990
date information.
情報の日付を入れてください。
When a mailbox is selected, the initial unsolicited data from the server arrives. The first piece of data is the number of messages. By sending a new EXISTS unsolicited data message the server causes the client to resize its cache (this is how newly arrived mail is handled). If the client attempts to access information from the cache, it will encounter empty spots that will trigger "fetch" requests. The request would be sent, some unsolicited data including the answer to the fetch will flow back, and then the "fetch" response will unblock the client.
メールボックスが選択されるとき、サーバからの初期の求められていないデータは到着します。 最初の片のデータはメッセージの数です。 新しいEXISTS求められていないデータメッセージを送ることによって、クライアントはサーバでキャッシュをリサイズします(これは新たに到着したメールがどう扱われるかということです)。 クライアントが、キャッシュから情報にアクセスするのを試みると、それは「フェッチ」要求の引き金となる人影のないスポットに遭遇するでしょう。 要求を送るでしょう、そして、フェッチの答えを含むいくつかの求められていないデータが還流するでしょう、そして、次に、「フェッチ」応答はクライアントの非ブロックを送られるでしょう。
People familiar with demand-paged virtual memory operating system design will recognize this model as being similar to page-fault handling on a demand-paged system.
要求で呼び出された仮想記憶オペレーティングシステムデザインに詳しい人々は要求で呼び出されたシステムの上でページフォールト取り扱いと同様であるとしてこのモデルを認めるでしょう。
Crispin [Page 25] RFC 1176 IMAP2 August 1990
クリスピン[25ページ]RFC1176IMAP2 August 1990
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.
以下の構文仕様はただ1つを例外としてRFC822の指定されるとしての増大しているBN記法(BNF)記法を使用します。 「#」構造物と共に使用されるデリミタはコンマではなく、シングルスペース(SP)です。
address ::= "(" addr_name SP addr_adl SP addr_mailbox SP
addr_host ")"
以下を扱ってください:= 「(「addr_名前SP addr_adl SP addr_メールボックスSP addr_ホスト」)」
addr_adl ::= nil / string
addr_は以下をadlします:= 無/ストリング
addr_host ::= nil / string
addr_は以下を接待します:= 無/ストリング
addr_mailbox ::= nil / string
addr_メールボックス:、:= 無/ストリング
addr_name ::= nil / string
addr_は以下を命名します:= 無/ストリング
bboard ::= "BBOARD" SP string
bboard:、:= "BBOARD"SPストリング
check ::= "CHECK"
以下をチェックしてください:= 「チェックしてください」
copy ::= "COPY" SP sequence SP mailbox
以下をコピーしてください:= "COPY"SP系列SPメールボックス
data ::= ("FLAGS" SP flag_list / "SEARCH" SP 1#number /
"BYE" SP text_line / "OK" SP text_line /
"NO" SP text_line / "BAD" SP text_line)
データ:、:= (SPが旗を揚げさせる「旗」_リスト/「検索」SP1の#数/「さようなら」SPテキスト_系列/「OK」SPテキスト_系列/「いいえ」SPテキスト_系列/「悪い」SPテキスト_系列)
date ::= string in form "dd-mmm-yy hh:mm:ss-zzz"
以下とデートしてください:= フォームの結び、「えー、ddに、yy hh、: mm: ss-グーグーグー、」
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 ")"
封筒:、:= 「(「SP env_送付者SP env_からのenv_日付のSP env_対象SP env_はSP env_メッセージイドに対してSP env_にSP env_cc SP env_bcc SP env_まで答えます」)」
env_bcc ::= nil / "(" 1*address ")"
env_は以下をbccします:= 「(「1*アドレス」)」という無/
env_cc ::= nil / "(" 1*address ")"
env_cc:、:= 「(「1*アドレス」)」という無/
env_date ::= string
env_は以下とデートします:= ストリング
env_from ::= nil / "(" 1*address ")"
以下からのenv_:= 「(「1*アドレス」)」という無/
env_in-reply-to ::= nil / string
以下に対してenv_:= 無/ストリング
env_message-id ::= nil / string
env_メッセージイド:、:= 無/ストリング
env_reply-to ::= nil / "(" 1*address ")"
env_は以下に答えます:= 「(「1*アドレス」)」という無/
Crispin [Page 26] RFC 1176 IMAP2 August 1990
クリスピン[26ページ]RFC1176IMAP2 August 1990
env_sender ::= nil / "(" 1*address ")"
env_送付者:、:= 「(「1*アドレス」)」という無/
env_subject ::= nil / string
env_対象:、:= 無/ストリング
env_to ::= nil / "(" 1*address ")"
以下へのenv_:= 「(「1*アドレス」)」という無/
expunge ::= "EXPUNGE"
以下を梢消してください:= 「梢消」
fetch ::= "FETCH" SP sequence SP ("ALL" / "FAST" /
fetch_att / "(" 1#fetch_att ")")
以下をとって来てください:= "FETCH"SP系列SP(「(「1#フェッチ_att」)」という「すべて」/「速い」/フェッチ_att/)
fetch_att ::= "ENVELOPE" / "FLAGS" / "INTERNALDATE" /
"RFC822" / "RFC822.HEADER" / "RFC822.SIZE" /
"RFC822.TEXT"
_attに以下をとって来てください:= 「封筒」/「旗」/"INTERNALDATE"/"RFC822"/"RFC822.HEADER"/"RFC822.SIZE"/"RFC822.TEXT"
find ::= "FIND" SP find_option SP string
以下を見つけてください:= "FIND"SP掘り出し物_オプションSPストリング
find_option ::= "MAILBOXES" / "BBOARDS"
_以下をゆだねるように確かめてください:= 「メールボックス」/「BBOARDS」
flag_list ::= ATOM / "(" 1#ATOM ")"
旗の_は以下を記載します:= 「(「1#原子」)」という原子/
literal ::= "{" NUMBER "}" CRLF ASCII-STRING
リテラル:、:= CRLF ASCII-ストリングに「「付番」」。
login ::= "LOGIN" SP userid SP password
ログイン:、:= "LOGIN"SPユーザID SPパスワード
logout ::= "LOGOUT"
ログアウトします:、:= 「ログアウトしてください」
mailbox ::= "INBOX" / string
メールボックス:、:= 「受信トレイ」/ストリング
msg_copy ::= "COPY"
msg_は以下をコピーします:= 「コピー」
msg_data ::= (msg_exists / msg_recent / msg_expunge /
msg_fetch / msg_copy)
msg_データ:、:= (msg_が存在している、/_最近の、または、msgなmsg_が_フェッチ/msg_コピーを梢消するか、またはmsgする、)
msg_exists ::= "EXISTS"
msg_は存在しています:、:= 「存在しています」
msg_expunge ::= "EXPUNGE"
msg_は以下を梢消します:= 「梢消」
msg_fetch ::= ("FETCH" / "STORE") SP "(" 1#("ENVELOPE" SP
envelope / "FLAGS" SP "(" 1#(recent_flag
flag_list) ")" / "INTERNALDATE" SP date /
"RFC822" SP string / "RFC822.HEADER" SP string /
"RFC822.SIZE" SP NUMBER / "RFC822.TEXT" SP
string) ")"
msg_は以下をとって来ます:= (「フェッチ」/「店」) 封筒..封筒..旗..最近..旗..旗..リスト..日付..ストリング..ストリング..数..結ぶ
msg_recent ::= "RECENT"
msg_最近:、:= 「最近です」。
msg_num ::= NUMBER
msg_は以下をnumします:= 数
Crispin [Page 27] RFC 1176 IMAP2 August 1990
クリスピン[27ページ]RFC1176IMAP2 August 1990
nil ::= "NIL"
無:、:= 「無」
noop ::= "NOOP"
noop:、:= "NOOP"
password ::= string
パスワード:、:= ストリング
recent_flag ::= "\RECENT"
最近の_は以下に旗を揚げさせます:= 「\最近です」。
ready ::= "+" SP text_line
以下を準備してください:= 「+」 SPテキスト_系列
request ::= tag SP (noop / login / logout / select / check /
expunge / copy / fetch / store / search / find /
bboard) CRLF
以下を要求してください:= SPにタグ付けをしてください、(noop/ログイン/がログアウトする、/は、bboard) /がCRLFであることが選択するか、チェックする、梢消する、コピーする、とって来る、保存する、捜す、またはわかります。
response ::= tag SP ("OK" / "NO" / "BAD") SP text_line CRLF
応答:、:= タグSP(「OK」/「いいえ」/「悪い」)SPテキスト_系列CRLF
search ::= "SEARCH" SP 1#("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")
以下を探してください:= 「検索」SP1#答える..BCC..ストリング..ストリング..ボディー..ストリング..CC..結ぶ..削除..旗を揚げる..キーワード..原子..新しい..古い..ストリング..最近..見る..ストリング..テキスト..ストリング..ストリング..答えのない..見えない
select ::= "SELECT" SP mailbox
以下を選択してください:= "SELECT"SPメールボックス
sequence ::= NUMBER / (NUMBER "," sequence) / (NUMBER ":"
sequence)
以下を配列してください:= 「NUMBER/、(NUMBER、」、」 系列) /「(NUMBER、」 : 」 系列、)
store ::= "STORE" SP sequence SP store_att
以下を保存してください:= 「ストア」SP系列SPは_attを保存します。
store_att ::= ("+FLAGS" SP flag_list / "-FLAGS" SP flag_list /
"FLAGS" SP flag_list)
_attに以下を保存してください:= (SP旗_リスト/「旗」SPが旗を揚げさせる「+ 旗」_リスト/「旗」SP旗_リスト)
string ::= atom / """" 1*character """" / literal
以下を結んでください:= 原子/、「「「「1*キャラクタ、「「「「/リテラル」
system_flags ::= "\ANSWERED" SP "\FLAGGED" SP "\DELETED" SP
"\SEEN"
システム_は以下に旗を揚げさせます:= 「「」 SPに答えた\」\は」 SPに旗を揚げた」という\が」 SPを削除した、」 見られた\、」
tag ::= atom
以下にタグ付けをしてください:= 原子
unsolicited ::= "*" SP (msg_num SP msg_data / data) CRLF
求められていません:、:= 「*」SP(msg_num SP msg_データ/データ)CRLF
userid ::= string
ユーザID:、:= ストリング
Crispin [Page 28] RFC 1176 IMAP2 August 1990
クリスピン[28ページ]RFC1176IMAP2 August 1990
Implementation Status
実装状態
This information is current as of this writing.
この情報はこの書くこと現在、よく見られます。
The University of Washington has developed an electronic mail client library called the "C-Client". It provides complete IMAP2, SMTP, and local mailbox (both /usr/spool/mail and mail.txt formats) services in a well-defined way to a user interface main program. Using the C- Client, the University of Washington has created an operational client for BSD Unix and two operational clients (one basic, one advanced) for the NeXT.
ワシントン大学は「C-クライアント」と呼ばれる電子メールクライアントライブラリを発展させました。 それはユーザーインタフェース主プログラムへの明確な方法で完全なIMAP2、SMTP、および地方のメールボックス(/usr/スプール/メールとmail.txt形式の両方)サービスを提供します。 Cクライアントを使用して、ワシントン大学はNeXTのために、BSD Unixのための操作上のクライアントと2人の操作上のクライアント(ある基礎、1つは進みました)を創造しました。
Stanford University/SUMEX has developed operational IMAP2 clients for Xerox Lisp machines, Texas Instruments Explorers, and the Apple Macintosh. The core of the Macintosh client is an early version of the C-Client. SUMEX has also developed IMAP2 servers for TOPS-20 and BSD Unix.
スタンフォード大学/SUMEXはゼロックスLispマシン、米国テキサス・インスツルメンツ社エクスプローラー、およびアップルマッキントッシュのために操作上のIMAP2クライアントを開発しました。 マッキントッシュクライアントのコアはC-クライアントの早めのバージョンです。 また、SUMEXはTOPS-20とBSD UnixのためにIMAP2サーバを開発しました。
All of the above software is in production use, with enthusiastic local user communities. Active development continues on the Macintosh and C-Client based clients and the BSD Unix server. This software is freely available from the University of Washington and SUMEX.
上記のソフトウェアのすべてが熱心な地方のユーザーコミュニティと共に生産使用であります。 活発な開発はマッキントッシュとC-クライアントの上でベースのクライアントとBSD Unixサーバーを続けています。このソフトウェアはワシントン大学とSUMEXから自由に利用可能です。
IMAP2 software exists for other platforms; for example Nippon Telephone and Telegraph (NTT) has developed an operational IMAP2 client for the NTT ELIS. Several organizations are working on a PC client.
IMAP2ソフトウェアは他のプラットホームに存在しています。 例えば、日本TelephoneとTelegraph(NTT)は操作上のIMAP2クライアントをNTTエリスに開発しました。 いくつかの組織がPCクライアントに取り組んでいます。
IMAP2 can be used to access mailboxes at very remote sites, where echo delays and frequent outages make TELNET and running a local mail reader intolerable. For example, from a desktop workstation on the University of Washington local network the author routinely uses IMAP2 to read and manage mailboxes on various University of Washington local servers, at two systems at Stanford University, at a Milnet site, and at a site in Tokyo, Japan.
非常に遠く離れたサイトでメールボックスにアクセスするのにIMAP2を使用できます。(そこでは、エコー遅れと頻繁な供給停止がTELNETと地元のメール読者を車で送るのを堪え難くします)。 例えば、ワシントン大学企業内情報通信網のデスクトップ型ワークステーションから、作者は様々なワシントン大学ローカルサーバでメールボックスを読んで、管理するのにIMAP2をきまりきって使用します、スタンフォード大学におけるMilnetサイトにおける東京(日本)のサイトの2台のシステムで。
This specification does not make any formal definition of size restrictions, but the DEC-20 server has the following limitations:
この仕様はサイズ制限の少しの公式の定義もしませんが、12月-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
. メールボックスの長さ: 707万7888のキャラクタ最大数に関するメッセージ: 1万8432のメッセージコマンドラインの長さ: 1万のキャラクタローカル・ホスト名の長さ: 64のキャラクタ「短い」議論の長さ: 39のキャラクタ「長い」議論の長さ: 49万1520のキャラクタシングルにおける最大の量のデータ出力が以下をとって来ます。 65万5360のキャラクタ
Crispin [Page 29] RFC 1176 IMAP2 August 1990
クリスピン[29ページ]RFC1176IMAP2 August 1990
To date, nobody has run up against any of these limitations, many of which are substantially larger than most current user mail reading programs.
これまで、だれもこれらの制限のいずれにもぶつかっていません。その多くがほとんどの現在のユーザメール読み込みプログラムより実質的に大きいです。
Acknowledgements
承認
Bill Yeager and Rich Acuff both contributed invaluable suggestions in the evolution of IMAP2 from the original IMAP. James Rice pointed out several ambiguities in the previous IMAP2 specification and otherwise would not allow me to leave bad enough along. Laurence Lundblade reviewed a draft of this version and made several helpful suggestions.
ビル・イェーガーとリッシュ・エイカフはオリジナルのIMAPからIMAP2の発展で非常に貴重な提案をともに寄付しました。 前のIMAP2仕様によるいくつかのあいまいさを指摘します。別の方法で、ジェームス・ライスは、私がずっと十分悪い状態でいなくなるのを許さないでしょう。 ローレンスLundbladeはこのバージョンの草稿を見直して、いくつかの役立つ提案をしました。
Many dedicated individuals have worked on IMAP2 software, including: Mark Crispin, Frank Gilmurray, Christopher Lane, Hiroshi Okuno, Christopher Schmidt, and Bill Yeager.
多くのひたむきな個人がIMAP2ソフトウェア、包含であることに働いていました: クリスピン、フランクGilmurray、クリストファー・レイン、Hiroshi Okuno、クリストファー・シュミット、およびビル・イェーガーをマークしてください。
Any mistakes, flaws, or sins of omission in this IMAP2 protocol specification are, however, strictly my own; and the mention of any name above does not imply an endorsement.
しかしながら、このIMAP2プロトコル仕様に基づく、省略のどんな誤り、欠点、または罪も全くある、私自身の。 そして、上のどんな名前の言及も裏書きを含意しません。
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Author's Address
作者のアドレス
Mark R. Crispin Panda Programming 6158 Lariat Loop NE Bainbridge Island, WA 98110-2020
マークのR.クリスピンパンダプログラミング6158ラリエット輪のNeベーンブリッジ島、ワシントン98110-2020
Phone: (206) 842-2385
以下に電話をしてください。 (206) 842-2385
EMail: mrc@Tomobiki-Cho.CAC.Washington.EDU
メール: mrc@Tomobiki-Cho.CAC.Washington.EDU
Crispin [Page 30]
クリスピン[30ページ]
一覧
スポンサーリンク
