RFC1082 日本語訳
1082 Post Office Protocol: Version 3: Extended service offerings. M.T.Rose. November 1988. (Format: TXT=25423 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group M. Rose Request for Comments: 1082 TWG November 1988
コメントを求めるワーキンググループM.バラ要求をネットワークでつないでください: 1082 TWG1988年11月
Post Office Protocol - Version 3 Extended Service Offerings
POP--バージョン3はサービス提供を広げました。
Status of This Memo
このメモの状態
This memo suggests a simple method for workstations to dynamically access mail from a discussion group server, as an extension to an earlier memo which dealt with dynamically accessing mail from a mailbox server using the Post Office Protocol - Version 3 (POP3). This RFC specifies a proposed protocol for the Internet community, and requests discussion and suggestions for improvements. All of the extensions described in this memo to the POP3 are OPTIONAL. Distribution of this memo is unlimited.
このメモはワークステーションがディスカッション・グループサーバからメールにダイナミックにアクセスする簡単なメソッドを示します、ポストオフィスプロトコルを使用するダイナミックにメールボックスサーバからのアクセスメールに対処した以前のメモへの拡大として--バージョン3(POP3)。 このRFCはインターネットコミュニティ、要求議論、および提案のための提案されたプロトコルを改良に指定します。 このメモでPOP3に説明された拡大のすべてがOPTIONALです。 このメモの分配は無制限です。
Introduction and Motivation
序論と動機
It is assumed that the reader is familiar with RFC 1081 that discusses the Post Office Protocol - Version 3 (POP3) [RFC1081]. This memo describes extensions to the POP3 which enhance the service it offers to clients. This additional service permits a client host to access discussion group mail, which is often kept in a separate spool area, using the general POP3 facilities.
読者がポストオフィスプロトコルについて議論するRFC1081に詳しいと思われます--バージョン3(POP3)[RFC1081]。 このメモはそれがクライアントに提供するサービスを機能アップするPOP3に拡大について説明します。 この追加サービスは、クライアントホストが別々のスプール領域にしばしば保管されるディスカッション・グループメールにアクセスすることを許可します、一般的なPOP3施設を使用して。
The next section describes the evolution of discussion groups and the technologies currently used to implement them. To summarize:
次のセクションは現在それらを実装するのに使用されているディスカッション・グループと技術の発展について説明します。 まとめるために:
o An exploder is used to map from a single address to a list of addresses which subscribe to the list, and redirects any subsequent error reports associated with the delivery of each message. This has two primary advantages: - Subscribers need know only a single address - Responsible parties get the error reports and not the subscribers
o 発破器は、ただ一つのアドレスからリストに加入するアドレスのリストまで写像するのにおいて使用されていて、それぞれのメッセージの配送に関連しているどんなその後のエラー・レポートも転送します。 これには、2つのプライマリ利点があります: - 加入者はただ一つのアドレスだけを知らなければなりません--責任があるパーティーは加入者ではなく、エラー・レポートを得ます。
Rose [Page 1] RFC 1082 POP3 Extended Service November 1988
サービス1988年11月に広げられたローズ[1ページ]RFC1082POP3
o Typically, each subscription address is not a person's private maildrop, but a system-wide maildrop, which can be accessed by more than one user. This has several advantages: - Only a single copy of each message need traverse the net for a given site (which may contain several local hosts). This conserves bandwidth and cycles. - Only a single copy of each message need reside on each subscribing host. This conserves disk space. - The private maildrop for each user is not cluttered with discussion group mail.
o それぞれの購読アドレスは人の個人的な郵便受けではなく、通常、システム全体の郵便受けです。(1人以上のユーザがその郵便受けにアクセスできます)。 これには、いくつかの利点があります: - それぞれのメッセージのただ一つのコピーだけが与えられたサイト(数人のローカル・ホストを含むかもしれない)にネットを横断しなければなりません。 これは帯域幅とサイクルを保存します。 - それぞれのメッセージのただ一つのコピーだけがそれぞれの申し込んでいるホストの上になければなりません。 これは椎間腔を保存します。 - 各ユーザのための個人的な郵便受けはディスカッション・グループメールで乱されません。
Despite this optimization of resources, further economy can be achieved at sites with more than one host. Typically, sites with more than one host either:
リソースのこの最適化にもかかわらず、1人以上のホストと共にサイトでさらなる経済を達成できます。 通常、1以上があるサイトはどちらかを接待します:
1. Replicate discussion group mail on each host. This results in literally gigabytes of disk space committed to unnecessarily store redundant information.
1. 各ホストにディスカッション・グループメールを模写してください。 これは文字通り不必要に余分な情報を保存するために遂行された椎間腔のギガバイトをもたらします。
2. Keep discussion group mail on one host and give all users a login on that host (in addition to any other logins they may have). This is usually a gross inconvenience for users who work on other hosts, or a burden to users who are forced to work on that host.
2. 議論が1人のホストに関するグループメールであることを保ってください、そして、そのホスト(それらが持っているかもしれないいかなる他のログインに加えた)の上ですべてのユーザにログインを与えてください。 これは、通常他のホストに働いているユーザにとっての総計の不便、またはやむを得ずそのホストに働いているユーザへの負担です。
As discussed in [RFC1081], the problem of giving workstations dynamic access to mail from a mailbox server has been explored in great detail (originally there was [RFC918], this prompted the author to write [RFC1081], independently of this [RFC918] was upgraded to [RFC937]). A natural solution to the problem outlined above is to keep discussion group mail on a mailbox server at each site and permit different hosts at that site to employ the POP3 to access discussion group mail. If implemented properly, this avoids the problems of both strategies outlined above.
[RFC1081]で議論するように、メールボックスサーバから郵送するワークステーション動的呼出しを与えるという問題は丹念に探られました(作者が、元々、[RFC918]があると書いて[RFC1081]これが、うながした、これの如何にかかわらず[RFC918]は[RFC937]にアップグレードしました)。 上に概説された問題への自然な解決は、議論が各サイトのメールボックスサーバに関するグループメールであることを保って、そのサイトの異なったホストがディスカッション・グループメールにアクセスするのにPOP3を使うことを許可することです。 適切に実装されるなら、これは上に概説された両方の戦略の問題を避けます。
ASIDE: It might be noted that a good distributed filesystem could also solve this problem. Sadly, "good" distributed filesystems, which do not suffer unacceptable response time for interactive use, are few and far between these days!
傍らに: また、良い分配されたファイルシステムがこの問題を解決するかもしれないことに注意されるかもしれません。 悲しげに、分配された「良い」ファイルシステム(対話的な使用のための容認できない応答時間を受けない)は最近、極めてまれです!
Given this motivation, now let's consider discussion groups, both in general and from the point of view of a user agent. Following this, extensions to the POP3 defined in [RFC1081] are presented. Finally, some additional policy details are discussed along with some initial experiences.
この動機を与えて、今、ディスカッション・グループ(一般に、そして、ユーザエージェントの観点からの両方)を考えましょう。 これに続いて、[RFC1081]で定義されたPOP3への拡大は提示されます。 最終的に、いくつかの初体験と共にいくつかの追加方針の詳細について議論します。
Rose [Page 2] RFC 1082 POP3 Extended Service November 1988
サービス1988年11月に広げられたローズ[2ページ]RFC1082POP3
What's in a Discussion Group
ディスカッション・グループにはあるもの
Since mailers and user agents first crawled out of the primordial ARPAnet, the value of discussion groups have been appreciated, (though their implementation has not always been well-understood).
以来郵送者と最初に根本的なARPAnetから這われたユーザエージェント、ディスカッション・グループの値を上げている、(それらの実装はいつもよく理解されているというわけではありませんでしたが。)
Described simply, a discussion group is composed of a number of subscribers with a common interest. These subscribers post mail to a single address, known as a distribution address. From this distribution address, a copy of the message is sent to each subscriber. Each group has a moderator, which is the person that administrates the group. The moderator can usually be reached at a special address, known as a request address. Usually, the responsibilities of the moderator are quite simple, since the mail system handles the distribution to subscribers automatically. In some cases, the interest group, instead of being distributed directly to its subscribers, is put into a digest format by the moderator and then sent to the subscribers. Although this requires more work on the part of the moderator, such groups tend to be better organized.
単に説明されて、ディスカッション・グループは共通の利益で多くの加入者から構成されます。 これらの加入者は分配アドレスとして知られているただ一つのアドレスにメールを掲示します。 この分配アドレスから、メッセージのコピーを各加入者に送ります。 各グループには、議長がいます。(その議長は、グループを管理する人です)。 通常、要求アドレスとして知られている特別なアドレスで議長に連絡できます。 通常、メールシステムが自動的に加入者に分配を扱うので、議長の責任はかなり簡単です。 いくつかの場合、直接加入者に分配されることの代わりに、営利団体を議長がダイジェスト形式に入れて、次に、加入者に送ります。 これは議長側のより多くの仕事を必要としますが、そのようなグループは、組織化するほうがよい傾向があります。
Unfortunately, there are a few problems with the scheme outlined above. First, if two users on the same host subscribe to the same interest group, two copies of the message get delivered. This is wasteful of both processor and disk resources.
残念ながら、上に概説されている体系に関するいくつかの問題があります。 まず最初に、同じホストの上の2人のユーザが同じ営利団体に加入するなら、メッセージのコピー2部は提供されます。 これはプロセッサとディスクリソースの両方で無駄です。
Second, some of these groups carry a lot of traffic. Although subscription to an group does indicate interest on the part of a subscriber, it is usually not interesting to get 50 messages or so delivered to the user's private maildrop each day, interspersed with personal mail, that is likely to be of a much more important and timely nature.
2番目に、これらのグループのいくつかが多くのトラフィックを載せます。 グループの購読は加入者側の関心を示しますが、通常、およそ50のメッセージがはるかに重要でタイムリーな自然において毎日ユーザの個人的な郵便受けに提供されて、個人宛ての郵便物で点在して、すなわち、傾向があるようになるのは、おもしろくはありません。
Third, if a subscriber on the distribution list for a group becomes "bad" somehow, the originator of the message and not the moderator of the group is notified. It is not uncommon for a large list to have 10 or so bogus addresses present. This results in the originator being flooded with "error messages" from mailers across the Internet stating that a given address on the list was bad. Needless to say, the originator usually could not care less if the bogus addresses got a copy of the message or not. The originator is merely interested in posting a message to the group at large. Furthermore, the moderator of the group does care if there are bogus addresses on the list, but ironically does not receive notification.
3番目に、グループのための発送先リストの加入者がどうにか「悪く」なるなら、グループの議長ではなく、メッセージの創始者が通知されます。 大きいリストにはにせのアドレスが提示するおよそ10があるのは、珍しくはありません。 これはインターネット中の郵送者からのリストの上の与えられたアドレスが悪かったと述べる「エラーメッセージ」で水につかっている創始者をもたらします。 言うまでもなく、通常、創始者は、にせのアドレスがメッセージのコピーを手に入れたかどうかより気にかけることができませんでした。 創始者は単に全体のグループにメッセージを掲示したがっています。 その上、グループの議長は、にせのアドレスがリストにあるかを気にかけますが、皮肉にも通知を受け取りません。
There are various approaches which can be used to solve some or all of these problems. Usually these involve placing an exploder agent at the distribution source of the discussion group, which expands the name of the group into the list of subscription addresses for the
使用できる購読アドレスのリストにグループの名前を広げるディスカッション・グループの分配源に発破器エージェントをみなすことにおける. 通常これらがかかわるこれらの問題のいくつかかすべてを解決する様々なアプローチがあります。
Rose [Page 3] RFC 1082 POP3 Extended Service November 1988
サービス1988年11月に広げられたローズ[3ページ]RFC1082POP3
group. In the process, the exploder will also change the address that receives error notifications to be the request address or other responsible party.
分類してください。 また、プロセスでは、発破器は要求アドレスか他の責任があるパーティーになるようにエラー通知を受け取るアドレスを変えるでしょう。
A complementary approach, used in order to cut down on resource utilization of all kinds, replaces all the subscribers at a single host (or group of hosts under a single administration) with a single address at that host. This address maps to a file on the host, usually in a spool area, which all users can access. (Advanced implementations can also implement private discussion groups this way, in which a single copy of each message is kept, but is accessible to only a select number of users on the host.)
すべての種類のリソース利用を控えるのに使用される補足的なアプローチは独身のホスト(または、ただ一つの管理の下におけるホストのグループ)でそのホストのただ一つのアドレスにすべての加入者に取って代わります。 このアドレスがホストの上と、そして、通常、スプール領域のファイルに写像する、アクセサリー。(すべてのユーザはファイルをそうすることができます)。 (高度な実装は、また、民間の議論グループがそれぞれのメッセージのただ一つの写しが取っておかれるこの方法であると実装することができますが、ホストの上の選んだ数のユーザだけに、アクセスしやすいです。)
The two approaches can be combined to avoid all of the problems described above.
上で説明された問題のすべてを避けるために2つのアプローチを結合できます。
Finally, a third approach can be taken, which can be used to aid user agents processing mail for the discussion group: In order to speed querying of the maildrop which contains the local host's copy of the discussion group, two other items are usually associated with the discussion group, on a local basis. These are the maxima and the last-date. Each time a message is received for the group on the local host, the maxima is increased by at least one. Furthermore, when a new maxima is generated, the current date is determined. This is called the last date. As the message is entered into the local maildrop, it is given the current maxima and last-date. This permits the user agent to quickly determine if new messages are present in the maildrop.
最終的に、3番目のアプローチ(ディスカッション・グループのためのメールを処理するユーザエージェントを支援するのに使用できる)を取ることができます: ローカル・ホストのディスカッション・グループのコピーを含む郵便受けの質問を促進するために、通常、他の2つの項目がディスカッション・グループに関連しています、地方ベースで。 これらは、maximaと終日です。 メッセージがローカル・ホストに関するグループのために受け取られる各回、maximaは少なくとも1つ増強されます。 新しいmaximaが発生しているとき、その上、現在の期日は決定しています。 これは終日と呼ばれます。 地方の郵便受けにメッセージを入力するとき、現在のmaximaと終日をそれに与えます。 これは、ユーザエージェントが、新しいメッセージが郵便受けで存在しているかどうかとすぐに決心していることを許可します。
NOTE: The maxima may be characterized as a monotonically increasing quanity. Although sucessive values of the maxima need not be consecutive, any maxima assigned is always greater than any previously assigned value.
以下に注意してください。 maximaは単調に増加するquanityとして特徴付けられるかもしれません。 maximaのsucessive値が連続する必要はありませんが、割り当てられたどんなmaximaもいずれも以前に値を割り当てたよりいつもすばらしいです。
Definition of Terms
用語の定義
To formalize these notions somewhat, consider the following 7 parameters which describe a given discussion group from the perspective of the user agent (the syntax given is from [RFC822]):
これらの概念を正式にするには、いくらか、ユーザエージェントの見解から与えられたディスカッション・グループについて説明する以下の7つのパラメタを考えてください(与えられた構文は[RFC822]から来ています):
Rose [Page 4] RFC 1082 POP3 Extended Service November 1988
サービス1988年11月に広げられたローズ[4ページ]RFC1082POP3
NAME Meaning: the name of the discussion group Syntax: TOKEN (ALPHA *[ ALPHA / DIGIT / "-" ]) (case-insensitive recognition) Example: unix-wizards
意味を命名してください: ディスカッション・グループSyntaxという名前: TOKEN(アルファー*[アルファー/ DIGIT /「-」])(大文字と小文字を区別しない認識)の例: unix-ウィザード
ALIASES Meaning: alternates names for the group, which are locally meaningful; these are typically used to shorten user typein Syntax: TOKEN (case-insensitive recognition) Example: uwiz
別名意味: グループのために名前を交替します。(それは、局所的に重要です)。 これらはユーザtypein Syntaxを短くするのに通常使用されます: TOKEN(大文字と小文字を区別しない認識)の例: uwiz
ADDRESS Meaning: the primary source of the group Syntax: 822 address Example: Unix-Wizards@BRL.MIL
意味を扱ってください: グループSyntaxの一次資料: 822 Exampleを扱ってください: Unix-Wizards@BRL.MIL
REQUEST Meaning: the primary moderator of the group Syntax: 822 address Example: Unix-Wizards-Request@BRL.MIL
意味を要求してください: グループSyntaxのプライマリ議長: 822 Exampleを扱ってください: Unix-Wizards-Request@BRL.MIL
FLAGS Meaning: locally meaningful flags associated with the discussion group; this memo leaves interpretation of this parameter to each POP3 implementation Syntax: octal number Example: 01
以下を意味する旗 局所的に重要な旗はディスカッション・グループと交際しました。 このメモはそれぞれのPOP3実装へのこのパラメタの解釈をSyntaxに残します: 8進数Example: 01
MAXIMA Meaning: the magic cookie associated with the last message locally received for the group; it is the property of the magic cookie that it's value NEVER decreases, and increases by at least one each time a message is locally received Syntax: decimal number Example: 1004
マキシマ意味: 最後のメッセージに関連している魔法のクッキーはグループのために局所的に受信されました。 それはそれの値がメッセージが局所的に受け取られたSyntaxである各時に少なくとも1つ減少して、決して増強しない魔法のクッキーの特性です: 10進数Example: 1004
LASTDATE Meaning: the date that the last message was locally received Syntax: 822 date Example: Thu, 19 Dec 85 10:26:48 -0800
LASTDATE意味: 最後のメッセージが局所的に受け取られたSyntaxであったことの日付: 822 Exampleとデートしてください: 木曜日、1985年12月19日10:26:48 -0800
Note that the last two values are locally determined for the maildrop associated with the discussion group and with each message in that maildrop. Note however that the last message in the maildrop have a different MAXIMA and LASTDATE than the discussion group. This often occurs when the maildrop has been archived.
最後の2つの値がディスカッション・グループとその郵便受けにおける各メッセージに関連している郵便受けのために局所的に決定することに注意してください。 しかしながら、ディスカッション・グループより郵便受けにおける最後のメッセージには異なったマキシマとLASTDATEがあることに注意してください。 郵便受けが格納されたとき、これはしばしば起こります。
Rose [Page 5] RFC 1082 POP3 Extended Service November 1988
サービス1988年11月に広げられたローズ[5ページ]RFC1082POP3
Finally, some local systems provide mechanisms for automatically archiving discussion group mail. In some cases, a two-level archive scheme is used: current mail is kept in the standard maildrop, recent mail is kept in an archive maildrop, and older mail is kept off-line. With this scheme, in addition to having a "standard" maildrop for each discussion group, an "archive" maildrop may also be available. This permits a user agent to examine the most recent archive using the same mechanisms as those used on the current mail.
最終的に、いくつかのローカルシステムが自動的にディスカッション・グループメールを格納するのにメカニズムを提供します。 いくつかの場合、2レベルのアーカイブ体系は使用されています: 現在のメールは標準の郵便受けで保管されます、そして、最近のメールはアーカイブ郵便受けで保管されます、そして、より古いメールはオフラインに保管されます。 また、この体系で、各ディスカッション・グループのための「標準」の郵便受けを持っていることに加えて、「アーカイブ」郵便受けも利用可能であるかもしれません。 これは、ユーザエージェントが最新のアーカイブを調べることを現在のメールで使用されるものと同じメカニズムを使用することで許可します。
The XTND Command
XTNDコマンド
The following commands are valid only in the TRANSACTION state of the POP3. This implies that the POP3 server has already opened the user's maildrop (which may be empty). This maildrop is called the "default maildrop". The phrase "closes the current maildrop" has two meanings, depending on whether the current maildrop is the default maildrop or is a maildrop associated with a discussion group.
以下のコマンドはPOP3のTRANSACTION州だけで有効です。 これは、POP3サーバが既に、ユーザの郵便受け(空であるかもしれない)を開いたのを含意します。 この郵便受けは「デフォルト郵便受け」と呼ばれます。 「現在の郵便受けを閉じる」という句には、2つの意味があります、現在の郵便受けがデフォルト郵便受けですかそれともディスカッション・グループに関連している郵便受けであるかによって。
In the former context, when the current maildrop is closed any messages marked as deleted are removed from the maildrop currently in use. The exclusive-access lock on the maildrop is then released along with any implementation-specific resources (e.g., file- descriptors).
現在の郵便受けが閉じられるとき、前の文脈では、削除されるようにマークされたどんなメッセージも現在使用中の郵便受けから取り除かれます。 そして、郵便受けの排他的なアクセス錠はどんな実装特有のリソース(例えば、ファイル記述子)と共にもリリースされます。
In the latter context, a maildrop associated with a discussion group is considered to be read-only to the POP3 client. In this case, the phrase "closes the current maildrop" merely means that any implementation-specific resources are released. (Hence, the POP3 command DELE is a no-op.)
後者の関係では、ディスカッション・グループに関連している郵便受けはPOP3クライアントへの書き込み禁止であると考えられます。 この場合、「現在の郵便受けを閉じる」という句は、どんな実装特有のリソースも発表されることを単に意味します。 (したがって、POP3コマンドDELEはオプアートではありません。)
All the new facilities are introduced via a single POP3 command, XTND. All positive reponses to the XTND command are multi-line.
XTND、ただ一つのPOP3コマンドですべての新しい設備を導入します。 XTNDコマンドへのすべての積極的な「再-橋」がマルチ系列です。
The most common multi-line response to the commands contains a "discussion group listing" which presents the name of the discussion group along with it's maxima. In order to simplify parsing all POP3 servers are required to use a certain format for discussion group listings:
それに伴うコマンドへの応答が含む中で最も一般的なマルチ系列議論の名前を提示する「ディスカッション・グループリスト」グループによるmaximaです。 構文解析を簡素化するために、すべてのPOP3サーバがディスカッション・グループリストに、ある形式を使用するのに必要です:
NAME SP MAXIMA
名前SPマキシマ
This memo makes no requirement on what follows the maxima in the listing. Minimal implementations should just end that line of the response with a CRLF pair. More advanced implementations may include other information, as parsed from the message.
このメモはリストでmaximaに続くことに要件を全く作りません。 最小限の器具はCRLF組と共に応答のその系列をただ終わらせるべきです。 より高度な実装はメッセージから分析されるように他の情報を含むかもしれません。
NOTE: This memo STRONGLY discourages implementations from supplying additional information in the listing.
以下に注意してください。 このメモSTRONGLYは、実装がリストで追加情報を提供するのを思いとどまります。
Rose [Page 6] RFC 1082 POP3 Extended Service November 1988
サービス1988年11月に広げられたローズ[6ページ]RFC1082POP3
XTND BBOARDS [name] Arguments: the name of a discussion group (optionally) Restrictions: may only be given in the TRANSACTION state. Discussion:
XTND BBOARDS[名前]議論: ディスカッション・グループ(任意に)制限の名前: TRANSACTION状態で与えるだけであるかもしれません。 議論:
If an argument was given, the POP3 server closes the current maildrop. The POP3 server then validates the argument as the name of a discussion group. If this is successful, it opens the maildrop associated with the group, and returns a multi-line response containing the discussion group listing. If the discussion group named is not valid, or the associated archive maildrop is not readable by the user, then an error response is returned.
議論を与えたなら、POP3サーバは現在の郵便受けを閉じます。 そして、POP3サーバはディスカッション・グループの名前として議論を有効にします。 これがうまくいくなら、それは、グループに関連している郵便受けを開いて、ディスカッション・グループリストを含むマルチ系列応答を返します。 指定されたディスカッション・グループが有効でないか、または関連アーカイブ郵便受けがユーザで読み込み可能でないなら、誤り応答を返します。
If no argument was given, the POP3 server issues a multi-line response. After the initial +OK, for each discussion group known, the POP3 server responds with a line containing the listing for that discussion group. Note that only world-readable discussion groups are included in the multi-line response.
議論を全く与えなかったなら、POP3サーバはマルチ系列応答を発行します。 初期かOKだったことの後に、知られている各ディスカッション・グループに関して系列がリストを含んでいて、POP3サーバはそのディスカッション・グループのために反応します。 世界読み込み可能なディスカッション・グループだけがマルチ系列応答に含まれていることに注意してください。
In order to aid user agents, this memo requires an extension to the scan listing when an "XTND BBOARDS" command has been given. Normally, a scan listing, as generated by the LIST, takes the form:
「XTND BBOARDS」コマンドを与えたとき、ユーザエージェントを支援するために、このメモはスキャンリストに拡大を必要とします。 通常、LISTによって生成されるように記載するスキャンは形を取ります:
MSGNO SIZE
MSGNOサイズ
where MSGNO is the number of the message being listed and SIZE is the size of the message in octets. When reading a maildrop accessed via "XTND BBOARDS", the scan listing takes the form
MSGNOがどこのリストアップされているメッセージとSIZEの数であるかは八重奏で、メッセージのサイズです。 「XTND BBOARDS」を通してアクセスされた郵便受けを読むとき、スキャンリストは形を取ります。
MSGNO SIZE MAXIMA
MSGNOサイズマキシマ
where MAXIMA is the maxima that was assigned to the message when it was placed in the BBoard.
それがBBoardに置かれたとき、マキシマがmaximaであるところでは、それはメッセージに割り当てられました。
Possible Responses: +OK XTND -ERR no such bboard Examples: C: XTND BBOARDS S: +OK XTND S: system 10 S: mh-users 100 S: . C: XTND BBOARDS system S: + OK XTND S: system 10 S: .
可能な応答: そのような+ OK XTND -ERRノーbboard Examples: C: XTND BBOARDS S: + OK XTND S: システム10秒間: mh-ユーザ100秒間: . C: XTND BBOARDSシステムS: + OK XTND S: システム10秒間: .
Rose [Page 7] RFC 1082 POP3 Extended Service November 1988
サービス1988年11月に広げられたローズ[7ページ]RFC1082POP3
XTND ARCHIVE name Arguments: the name of a discussion group (required) Restrictions: may only be given in the TRANSACTION state. Discussion:
XTND ARCHIVEはArgumentsを命名します: ディスカッション・グループ(必要である)制限の名前: TRANSACTION状態で与えるだけであるかもしれません。 議論:
The POP3 server closes the current maildrop. The POP3 server then validates the argument as the name of a discussion group. If this is successful, it opens the archive maildrop associated with the group, and returns a multi-line response containing the discussion group listing. If the discussion group named is not valid, or the associated archive maildrop is not readable by the user, then an error response is returned.
POP3サーバは現在の郵便受けを閉じます。 そして、POP3サーバはディスカッション・グループの名前として議論を有効にします。 これがうまくいくなら、それは、グループに関連しているアーカイブ郵便受けを開いて、ディスカッション・グループリストを含むマルチ系列応答を返します。 指定されたディスカッション・グループが有効でないか、または関連アーカイブ郵便受けがユーザで読み込み可能でないなら、誤り応答を返します。
In addition, the scan listing generated by the LIST command is augmented (as described above).
さらに、LISTコマンドで作られたスキャンリストは増大します(上で説明されるように)。
Possible Responses: +OK XTND -ERR no such bboard Examples: C: XTND ARCHIVE system S: + OK XTND S: system 3 S: .
可能な応答: そのような+ OK XTND -ERRノーbboard Examples: C: XTND ARCHIVEシステムS: + OK XTND S: システム3秒間: .
XTND X-BBOARDS name Arguments: the name of a discussion group (required) Restrictions: may only be given in the TRANSACTION state. Discussion:
XTND X-BBOARDSはArgumentsを命名します: ディスカッション・グループ(必要である)制限の名前: TRANSACTION状態で与えるだけであるかもしれません。 議論:
The POP3 server validates the argument as the name of a discussion group. If this is unsuccessful, then an error response is returned. Otherwise a multi-line response is returned. The first 14 lines of this response (after the initial +OK) are defined in this memo. Minimal implementations need not include other information (and may omit certain information, outputing a bare CRLF pair). More advanced implementations may include other information.
POP3サーバはディスカッション・グループの名前として議論を有効にします。 これが失敗しているなら、誤り応答を返します。 さもなければ、マルチ系列応答を返します。 この応答(初期かOKだったことの後の)の最初の14の系列がこのメモで定義されます。 最小限の器具は他の情報(そして、裸のCRLF組をoutputingして、ある情報を省略するかもしれない)を含む必要はありません。 より高度な実装は他の情報を含むかもしれません。
Line Information (refer to "Definition of Terms") ---- ----------- 1 NAME 2 ALIASES, separated by SP 3 system-specific: maildrop 4 system-specific: archive maildrop 5 system-specific: information 6 system-specific: maildrop map 7 system-specific: encrypted password 8 system-specific: local leaders, separated by SP
線情報(「用語の定義」について言及します)---- ----------- 1 システム特有の状態でSP3によって切り離されたNAME2ALIASES: 郵便受け4システム詳細: システム特有の状態で郵便受け5を格納してください: 情報6システム詳細: 郵便受けはシステム特有の状態で7を写像します: 暗号化されたパスワード8システム詳細: SPによって切り離された地元のリーダー
Rose [Page 8] RFC 1082 POP3 Extended Service November 1988
サービス1988年11月に広げられたローズ[8ページ]RFC1082POP3
9 ADDRESS 10 REQUEST 11 system-specific: incoming feed 12 system-specific: outgoing feeds 13 FLAGS SP MAXIMA 14 LASTDATE
9ADDRESS10のREQUEST11システム詳細: 入来は12をシステム特有に食べさせます: 外向的な給送13FLAGS SP MAXIMA14LASTDATE
Most of this information is entirely too specific to the UCI Version of the Rand MH Message Handling System [MRose85]. Nevertheless, lines 1, 2, 9, 10, 13, and 14 are of general interest, regardless of the implementation.
この情報の大部分は完全にRand MH Message Handling System[MRose85]のUCIバージョンに特定過ぎます。 それにもかかわらず、系列1、2、9、10、13、および14は実装にかかわらず一般的興味のものです。
Possible Responses: +OK XTND -ERR no such bboard Examples: C: XTND X-BBOARDS system S: + OK XTND S: system S: local general S: /usr/bboards/system.mbox S: /usr/bboards/archive/system.mbox S: /usr/bboards/.system.cnt S: /usr/bboards/.system.map S: * S: mother S: system@nrtc.northrop.com S: system-request@nrtc.northrop.com S: S: dist-system@nrtc-gremlin.northrop.com S: 01 10 S: Thu, 19 Dec 85 00:08:49 -0800 S: .
可能な応答: そのような+ OK XTND -ERRノーbboard Examples: C: XTND X-BBOARDSシステムS: + OK XTND S: システムS: 地方の一般的なS: /usr/bboards/system.mbox S: /usr/bboards/archive/system.mbox S: /usr/bboards/.system.cnt S: /usr/bboards/.system.map S: * S: 母親S: system@nrtc.northrop.com S: system-request@nrtc.northrop.com S: S: dist-system@nrtc-gremlin.northrop.com S: 01 10秒間: 木曜日、00:08:49の0800秒間1985年12月19日: .
Policy Notes
方針注意
Depending on the particular entity administrating the POP3 service host, two additional policies might be implemented:
POP3サービス・ホストを管理する特定の実体によって、2つの追加政策が実施されるかもしれません:
1. Private Discussion Groups
1. 私設のディスカッション・グループ
In the general case, discussion groups are world-readable, any user, once logged in (via a terminal, terminal server, or POP3, etc.), is able to read the maildrop for each discussion group known to the POP3 service host. Nevertheless, it is desirable, usually for privacy reasons, to implement private discussion groups as well.
一般的な場合に、ディスカッション・グループが世界読み込み可能である、一度ログインされた(端末、ターミナルサーバ、またはPOP3などで)どんなユーザもPOP3サービス・ホストにとって知られている各ディスカッション・グループのために郵便受けを読むことができます。 それにもかかわらず、それは、通常プライバシー理由で個人的な議論がまた、グループであると実装するために望ましいです。
Support of this is consistent with the extensions outlined in this
このサポートはこれに概説されている拡大と一致しています。
Rose [Page 9] RFC 1082 POP3 Extended Service November 1988
サービス1988年11月に広げられたローズ[9ページ]RFC1082POP3
memo. Once the AUTHORIZATION state has successfully concluded, the POP3 server grants the user access to exactly those discussion groups the POP3 service host permits the authenticated user to access. As a "security" feature, discussion groups associated with unreadable maildrops should not be listed in a positive response to the XTND BBOARDS command.
メモ。 AUTHORIZATION状態がいったん首尾よく終わると、ちょうどそれらのディスカッション・グループにアクセスするサーバがPOP3サービス・ホストをユーザに与えるPOP3は認証されたユーザをアクセサリーに可能にします。 「セキュリティ」の特徴として、XTND BBOARDSコマンドへの積極的な応答で読みにくい郵便受けに関連しているディスカッション・グループを記載するべきではありません。
2. Anonymous POP3 Users
2. 匿名のPOP3ユーザ
In order to minimize the authentication problem, a policy permitting "anonymous" access to the world-readable maildrops for discussion groups on the POP3 server may be implemented.
認証問題を最小にするために、ディスカッション・グループのためにPOP3サーバで世界読み込み可能な郵便受けへの「匿名」のアクセスを可能にする政策は実施されるかもしれません。
Support of this is consistent with the extensions outlined in this memo. The POP3 server can be modified to accept a USER command for a well-known pseudonym (i.e., "anonymous") which is valid with any PASS command. As a "security" feature, it is advisable to limit this kind of access to only hosts at the local site, or to hosts named in an access list.
このサポートはこのメモに概説されている拡大と一致しています。 どんなPASSコマンドによっても有効なよく知られる匿名(すなわち、「匿名」の)のためのUSERコマンドを受け入れるようにPOP3サーバを変更できます。 「セキュリティ」の特徴として、この種類のアクセスをローカル・サイトにおける、または、アクセスリストで指定されたホストのホストだけに制限するのは賢明です。
Experiences and Conclusions
経験と結論
All of the facilities described in this memo and in [RFC1081] have been implemented in MH #6.1. Initial experiences have been, on the whole, very positive.
このメモと[RFC1081]で説明された施設のすべてがMH#6.1で実装されました。 初体験は概して非常に積極的です。
After the first implementation, some performance tuning was required. This consisted primarily of caching the datastructures which describe discussion groups in the POP3 server. A second optimization pertained to the client: the program most commonly used to read BBoards in MH was modified to retrieve messages only when needed. Two schemes are used:
最初の実装の後に、何らかの性能チューニングが必要でした。 これは主としてPOP3サーバでディスカッション・グループについて説明するdatastructuresをキャッシュするのから成りました。2番目の最適化はクライアントに関係しました: 必要である場合にだけ、MHでBBoardsを読むのに最も一般的に使用されるプログラムは、メッセージを検索するように変更されました。 2つの体系が使用されています:
o If only the headers (and the first few lines of the body) of the message are required (e.g., for a scan listing), then only these are retrieved. The resulting output is then cached, on a per-message basis.
o メッセージのヘッダー(そして、ボディーのわずかな最初の系列)だけが必要であるなら(例えば、スキャンリストのために)、これらだけが検索されます。 そして、結果として起こる出力は1メッセージあたり1個のベースでキャッシュされます。
o If the entire message is required, then it is retrieved intact, and cached locally.
o 全体のメッセージが必要であるなら、それは、完全な状態で検索されて、局所的にキャッシュされます。
With these optimizations, response time is quite adequate when the POP3 server and client are connected via a high-speed local area network. In fact, the author uses this mechanism to access certain private discussion groups over the Internet. In this case, response is still good. When a 9.6Kbps modem is inserted in the path, response went from good to almost tolerable (fortunately the author only reads a few discussion groups in this fashion).
POP3サーバとクライアントが高速ローカル・エリア・ネットワークを通して接されるとき、これらの最適化で、応答時間はかなり適切です。 事実上、作者は、インターネットの上で、ある私設のディスカッション・グループにアクセスするのにこのメカニズムを使用します。 この場合、応答はまだ良いです。 9.6Kbpsであるときに、モデムは経路に挿入されて、応答は利益からほとんど許容できるまで行きました(幸い、作者はこんなやり方でいくつかのディスカッション・グループを読むだけです)。
Rose [Page 10] RFC 1082 POP3 Extended Service November 1988
サービス1988年11月に広げられたローズ[10ページ]RFC1082POP3
To conclude: the POP3 is a good thing, not only for personal mail but for discussion group mail as well.
結論すると、: POP3は個人宛ての郵便物だけではなく、また、ディスカッション・グループメールのために良いものですも。
References
参照
[RFC1081] Rose, M., "Post Office Protocol - Verison 3 (POP3)", RFC 1081, TWG, November 1988.
[RFC1081]ローズ、M.、「郵便局は議定書を作ります--Verison3(POP3)」、RFC1081、TWG、11月1988日
[MRose85] Rose, M., and J. Romine, "The Rand MH Message Handling System: User's Manual", University of California, Irvine, November 1985.
[MRose85] ローズ、M.、およびJ.Romine、「底ならし革MHメッセージハンドリングシステム:」 「ユーザマニュアル」、カリフォルニア大学アーバイン校、1985年11月。
[RFC822] Crocker, D., "Standard for the Format of ARPA-Internet Text Messages", RFC 822, University of Delaware, August 1982.
[RFC822] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、RFC822、デラウエア大学、1982年8月。
[RFC918] Reynolds, J., "Post Office Protocol", RFC 918, USC/Information Sciences Institute, October 1984.
[RFC918] レイノルズ、J.、「POP」、RFC918、科学が1984年10月に設けるUSC/情報。
[RFC937] Butler, M., J. Postel, D. Chase, J. Goldberger, and J. Reynolds, "Post Office Protocol - Version 2", RFC 937, USC/Information Sciences Institute, February 1985.
[RFC937] バトラー、M.、J.ポステル、D.チェイス、J.Goldberger、およびJ.レイノルズ、「郵便局は議定書を作ります--バージョン2インチ、USC/情報科学が1985年2月に設けるRFC937。」
Author's Address:
作者のアドレス:
Marshall Rose The Wollongong Group 1129 San Antonio Rd. Palo Alto, California 94303
マーシャル・ローズウォロンゴングループ1129サンアントニオ通り パロアルト、カリフォルニア 94303
Phone: (415) 962-7100
以下に電話をしてください。 (415) 962-7100
Email: MRose@TWG.COM
メール: MRose@TWG.COM
Rose [Page 11]
上昇しました。[11ページ]
一覧
スポンサーリンク