RFC1339 日本語訳

Network Working Group                                         S. Dorner
Request for Comments: 1339                                   P. Resnick
                                     U. of Illinois at Urbana-Champaign
                                                              June 1992

コメントを求めるワーキンググループS.デルナーの要求をネットワークでつないでください: 1339 Urbana-Champaign1992年6月におけるイリノイのP.レズニックU.

                     Remote Mail Checking Protocol

リモートメール照合プロトコル

Status of this Memo

このMemoの状態

   This memo defines 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.

このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 議論と改善提案は要求されています。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。

Abstract

要約

   This RFC defines a protocol to provide a mail checking service to be
   used between a client and server pair. Typically, a small program on
   a client workstation would use the protocol to query a server in
   order to find out whether new mail has arrived for a specified user.

このRFCは、クライアントとサーバ組の間で使用されるためにサービスをチェックするメールを提供するためにプロトコルを定義します。 通常、クライアントワークステーションの上の小さいプログラムは、新しいメールが指定されたユーザのために到着したかどうか見つけるためにサーバについて質問するのにプロトコルを使用するでしょう。

Intent

意図

   This RFC defines a simple, low-overhead protocol for checking the
   status of a maildrop on a host. It is primarily intended for use in
   adjunct with "remote mail" servers such as those implementing the
   Post Office Protocol (RFC 1225). Remote mail clients must poll their
   servers to discover the arrival of mail. Using one of the remote mail
   protocols for periodic checking can be quite impractical and
   expensive for the server since either a constant connection between
   client and server must be maintained or repeated and expensive user
   validations must be done. Furthermore, users on less capable
   computers may not wish to devote the memory required to have a full
   implementation of the client polling for mail.  Thus, we feel that an
   easy to implement and inexpensive to use polling scheme would be of
   benefit both to mail servers and their clients.

このRFCは、ホストの上で郵便受けの状態をチェックするために簡単で、低いオーバーヘッドのプロトコルを定義します。 それらなどの「リモートメール」サーバが、ポストオフィスがプロトコル(RFC1225)であると実装していて、それは付属物における使用のために主として意図します。 リモートメールクライアントは、メールの到着を発見するために彼らのサーバに投票しなければなりません。 サーバに、周期的な照合のためのリモートメールプロトコルの使用1は、クライアントとサーバの間の常時接続を維持しなければならないか、または繰り返さなければならなくて、高価なユーザの確認をしなければならないので、かなり非実用的であって、高価である場合があります。 その上、それほどできないコンピュータの上のユーザはメールのためのクライアント世論調査の完全な実施を持つのに必要であるメモリを注ぎたがっていないかもしれません。 したがって、私たちは、世論調査体系を使用するために道具で安価への小休止がともにサーバと彼らのクライアントに郵送するのに有益であると感じます。

Protocol Overview

プロトコル概要

   To avoid connection overhead, the Remote Mail Checking Protocol is
   based on the User Datagram Protocol (UDP), using UDP port 50 decimal
   (62 octal) for the server. The protocol provides for both non-
   authenticated and authenticated polling. Non-authenticated polling is
   simplest for both client and server. Authenticated polling provides a
   small increment of privacy, at the cost of more complexity in both
   client and server (but still far less than polling with one of the

接続オーバーヘッドを避けるために、RemoteメールCheckingプロトコルはユーザー・データグラム・プロトコル(UDP)に基づいています、サーバに、UDPポート50小数(62 8進)を使用して。プロトコルは非認証されて認証の両方にされた世論調査に備えます。 クライアントとサーバの両方に、非認証された世論調査は最も簡単です。しかし、認証された世論調査はプライバシーのわずかな増分を提供します、クライアントとサーバの両方の、より多くの複雑さの費用で(1で投票するよりはるかに静まりません。

Dorner & Resnick                                                [Page 1]

RFC 1339             Remote Mail Checking Protocol             June 1992

プロトコル1992年6月にチェックするデルナーとレズニック[1ページ]RFC1339のリモートメール

   remote mail protocols).

リモートメールプロトコル)

Non-Authenticated Protocol

非認証されたプロトコル

   In the non-authenticated version of the protocol, the server will
   listen on port 50 for maildrop check requests for users with
   maildrops on the machine. A client will send a single UDP datagram
   from a randomly chosen unreserved UDP port to UDP port 50 on the
   server. The datagram will contain a 32-bit (four-octet) number which
   is set to all zeros (0), followed by a case-sensitive ASCII string of
   a username on the server system. The server will find the maildrop on
   the system for that user and determine the amount of time that has
   passed since the last message in the maildrop was appended, as well
   as the amount of time that has passed since the maildrop was last
   accessed for reading. The server will then send back a single UDP
   datagram containing three 32-bit numbers in network byte order to the
   originating port on the client. Again, the first will be zero (0),
   the second will contain the number of seconds plus one since the last
   addition to the specified user's maildrop and the third will contain
   the number of seconds plus one since the last read on the user's
   maildrop. If the username provided does not exist, if the maildrop is
   not on the system or if the maildrop is empty, the server will send
   back zero (0) in the last two numbers for its reply. The client will
   consider the maildrop to contain new mail if the number of seconds
   since the last read access is greater than or equal to the number of
   seconds since the last addition access of the maildrop and either
   number is non-zero, old mail if the number of seconds since the last
   read access is less than or equal to the number of seconds since the
   last addition access of the maildrop and either number is non-zero,
   and empty if both numbers are zero.

プロトコルの非認証されたバージョンでは、マシンの上に郵便受けがある状態で、サーバはユーザを求める郵便受けチェック要求のためにポート50の上で聴かれるでしょう。 クライアントはサーバで手当たりしだいに選ばれた予約していないUDPポートからUDPポート50に単一のUDPデータグラムを送るでしょう。データグラムはサーバシステムに関するユーザ名の大文字と小文字を区別するASCIIストリングが支えたすべてのゼロ(0)に設定される(4八重奏)の32ビットの数を含むでしょう。 サーバは、そのユーザのシステムの上で郵便受けを見つけて、郵便受けにおける最後のメッセージを追加して以来経過している時間を決定するでしょう、郵便受けが最後に読書するためにアクセスされて以来経過している時間と同様に。 そして、サーバはネットワークバイトオーダーにおける3つの32ビットの番号をクライアントの上の起因するポートに含む単一のUDPデータグラムを返送するでしょう。 一方、1番目がどんな(0)にもならない、最終がユーザの郵便受けで読んだので指定されたユーザの郵便受けへの最後の追加と3番目が秒数と1つを含むので、2番目は秒数と1つを含むでしょう。 システムの上に郵便受けがないか、または郵便受けが空であるなら提供されたユーザ名が存在していないと、サーバは回答の最後の2つの番号における(0)を全く返送しないでしょう。 クライアントは、最終がアクセスを読んだので郵便受けとどちらかの数の最後の追加アクセスが郵便受けとどちらかの数の最後の追加アクセスが非ゼロであって、空であるので最後に読まれたアクセスが、より秒数である時から秒の数が両方の数であるならゼロであるなら非ゼロの、そして、古いメールであることで秒数が秒の数以上であるなら郵便受けが新しいメールを含むと考えるでしょう。

Authenticated Protocol

認証されたプロトコル

   The authenticated protocol operates identically to the non-
   authenticated protocol with the exception of the first interaction
   between the server and the client. After the client has sent its
   initial request containing the requested username, the server will
   send back a single UDP packet containing three 32-bit numbers. The
   first number will be a bit-mask instead of the normal 32-bits of
   zero. The bit-mask will indicate a request for authentication. Each
   bit in the mask represents a type of authentication that the server
   accepts. The bits (with the least significant bit numbered 0, and the
   most significant bit 31) are defined as follows:

サーバとクライアントとの最初の相互作用を除いて、認証されたプロトコルは同様に非認証されたプロトコルに作動します。 クライアントが要求されたユーザ名を含む初期の要求を送った後に、サーバは3つの32ビットの番号を含む単一のUDPパケットを返送するでしょう。 最初の数は標準の代わりにゼロの32ビットに少しマスクをかけるためにことになるでしょう。 ビットマスクは認証を求める要求を示すでしょう。 マスクの各ビットはサーバが受け入れる一種の認証を表します。 ビット(最下位ビットで、0、および最も重要なビット31に達する)は以下の通り定義されます:

Dorner & Resnick                                                [Page 2]

RFC 1339             Remote Mail Checking Protocol             June 1992

プロトコル1992年6月にチェックするデルナーとレズニック[2ページ]RFC1339のリモートメール

      0     Cleartext password The password for the maildrop, not
            NULL-terminated.

0はパスワードをCleartextします。郵便受けであって、NULLによって終えられないパスワード。

      1-23  Reserved for future use

1-23 今後の使用のために、予約されました。

      24-31 Implementation-dependent. Implementors wishing to
            experiment may use these.

24-31 実装依存しています。 実験したがっている作成者はこれらを使用するかもしれません。

   For each type of authentication that the server accepts, the
   corresponding bit will be set to one. All other bits will be set to
   zero.  The last two 32-bit numbers in the reply will be set to zero.
   If the client supports authentication, it will send back a 32-bit
   mask with the bit representing the kind of authentication it is using
   set to one, followed by the data used for authentication. The client
   is free to use any of the types of authentication indicated by the
   authentication request from the server. If the client does not
   support authentication and it receives an authentication request, it
   SHOULD stop sending requests (though this behavior is not required).

サーバが受け入れるそれぞれのタイプの認証において、対応するビットは1つに設定されるでしょう。 他のすべてのビットがゼロに設定されるでしょう。 回答における最後の2つの32ビットの番号がゼロに設定されるでしょう。 クライアントが認証をサポートすると、認証に使用されるデータがあとに続いた1つにセットしたビットがそれが使用している認証の種類を表していて、それは32ビットのマスクを返送するでしょう。 クライアントは自由にサーバからの認証要求で示された認証のタイプのどれかを使用できます。クライアントがそうしないなら、認証をサポートしてください。そうすれば、認証要求を受け取って、それはSHOULD停止送付要求(この振舞いは必要ではありませんが)です。

   Once a valid authentication is received by the server for a
   particular maildrop, the server considers the IP address and UDP port
   of the client along with that maildrop to be an authenticated
   address/port/maildrop triple. From then on, normal non-authenticated
   transactions take place between the server and the client as
   described above. Should a datagram come from an authenticated
   address/port pair with a different username, or if some amount of
   time has elapsed since the last request (which is implementation
   dependent), the server should remove the address/port/maildrop triple
   from its list of authenticated triples and send another
   authentication request. Since the time required for an authenticated
   triple to become unauthenticated is implementation dependent, clients
   should be prepared to send an authentication reply to containing the
   server whenever it is requested.

特定の郵便受けのためにサーバでいったん有効な認証を受けると、サーバは、3倍その郵便受けに伴うクライアントのIPアドレスとUDPポートが認証されたアドレス/ポート/郵便受けであると考えます。 それ以来、正常な非認証されたトランザクションは上で説明されるようにサーバとクライアントの間の場所を取ります。 データグラムが認証されたアドレス/ポート組と異なったユーザ名と共に来るはずであるか、または最後の要求(実装に依存している)以来いくらかの時間が経過しているなら、サーバは、認証された三重のリストからアドレス/ポート/郵便受けを3倍取り除いて、別の認証要求を送るべきです。 認証された三重が非認証されるようになるのに必要である時間が実装に依存しているので、クライアントはそれが要求されているときはいつも、サーバを含むのに認証回答を送る用意ができているべきです。

Server Implementation Notes

サーバ実装注意

   Servers which implement either the authenticated or non-authenticated
   protocol may decide that they do not wish to reveal the actual amount
   of time that has passed since the last update or read from a
   maildrop. (See the "Security Considerations" section below for
   reasons some feel this is problematic.) In this case, a server may
   instead reply with the following:

認証されたか非認証されたプロトコルを実装するサーバは、アップデート以来経過している実際の時間を明らかにしたくないか、郵便受けから読みたがっていないと決めるかもしれません。 (或るものが、これが問題が多いと感じる理由で下の「セキュリティ問題」セクションを見てください。) この場合、サーバは代わりに以下で返答するかもしれません:

                   First 32 bits     Second 32 bits     Third 32 bits
      New mail           0                 0                  1
      Old mail           0                 1                  0
      No mail            0                 0                  0

最初に、32ビットの32ビットの32ビットのSecond Third Newメール0 0 1Oldメール0 1 0いいえメール0 0 0

Dorner & Resnick                                                [Page 3]

RFC 1339             Remote Mail Checking Protocol             June 1992

プロトコル1992年6月にチェックするデルナーとレズニック[3ページ]RFC1339のリモートメール

   These values will appear to the client as correctly representing new,
   old or no mail respectively but will give no indication of the actual
   times that the changes took place.

これらの値は、それぞれ正しく新しくて、古い状態で表すとしてのクライアントにもかかわらず、どんなメールにも見えませんが、変化が起こったという実際の時勢のしるしを全く与えないでしょう。

   Servers implementing the non-authenticated protocol MUST provide some
   mechanism by which users on the system can give permission for their
   maildrops to accessed by the protocol. See the "Security
   Considerations" section below for specifics.

非認証されたプロトコルを実装するサーバはシステムの上のユーザがアクセスされることへのプロトコルによる彼らの郵便受けのために許可できる何らかのメカニズムを提供しなければなりません。 詳細に関して下の「セキュリティ問題」セクションを見てください。

Client Implementation Notes

クライアント実装注意

   Clients MUST not send more than one poll (and one authentication) per
   minute. In particular, lack of server response should not result in
   retransmission.

クライアントは1分あたり1つ以上の投票(そして、1つの認証)を送ってはいけません。 特に、サーバ応答の不足は「再-トランスミッション」をもたらすべきではありません。

   Since the last two numbers in an authentication request from a server
   are always 0 as are the last two numbers in a response for an empty
   or non-existent maildrop, clients that do not support authentication
   need not examine the first number in the server datagram at all
   (though they are encouraged to do so for the sake of proper reporting
   to the user).

いつもサーバからの認証要求における最後の2つの番号が応答における、空の、または、実在しない郵便受けの最後の2つの番号のように0であるので、認証をサポートしないクライアントは全くサーバデータグラムにおける最初の数を調べる必要はありません(彼らがユーザへの適切な報告のためにそうするよう奨励されますが)。

   Clients can turn the modification interval into absolute time, and
   track the changing of this absolute time in order to discern the
   arrival of new mail (as opposed to the mere existence of unread
   mail). However, such clients should bear three things in mind.
   First, network delays and clock vagaries may result in small
   inconsistencies in times. A "slop factor" of several seconds is
   encouraged. Second, the reading of mail often entails modification of
   the maildrop; the relationship of the access and modification
   intervals should always be consulted. Third, the special results of
   (1,0) and (0,1) are most properly handled as special cases.

クライアントは、新しいメール(読まれていないメールの単なる存在と対照的に)の到着について明察するために変更間隔を絶対時間に変えて、この絶対時間の変化を追跡できます。 しかしながら、そのようなクライアントは3つのことを覚えておくべきです。 まず最初に、ネットワーク遅延と時計気まぐれは時代に小さい矛盾をもたらすかもしれません。 数秒の「要素をこぼしてください」は奨励されます。 2番目に、メールの読書は郵便受けの変更をしばしば伴います。 アクセスと変更間隔の関係はいつも相談されるべきです。 3番目に、(1、0)の特別な結果、および(0、1)は特別なケースとして最も適切に扱われます。

   Clients need not recall whether or not they are authenticated (though
   they must use a consistent port if they receive any authentication
   requests for a given maildrop). It is sufficient to issue requests
   when desired, and to respond to any authentication requests that
   appear.

クライアントは、彼らが認証されたかどうかと(何か与えられた郵便受けを求める認証要求を受け取るなら、彼らが一貫したポートを使用しなければなりませんが)思い出す必要はありません。 要求を望まれていると出して、現れるどんな認証要求にも応じるのは十分です。

Security Considerations

セキュリティ問題

   The are two security considerations for the protocol. The first is
   one mainly of privacy. Some sites and individual users consider it
   problematic to have information about mail arrival available freely.
   This can be a simple privacy issue for individuals or a security
   issue for highly secure sites. The authenticated version of the
   protocol allows sites to have a reasonable amount of security in that
   only people with passwords can access this information. The protocol

プロトコルのための2つのセキュリティ問題がそうです。 1番目は主にプライバシーの1つです。 いくつかのサイトと個々のユーザは、自由に利用可能なメール到着の情報を持っているのが問題が多いと考えます。 これは、個人のための簡単なプライバシーの問題か非常に安全なサイトへの安全保障問題であるかもしれません。 プロトコルの認証されたバージョンで、パスワードをもっている人々だけがこの情報にアクセスできるので、サイトは十分な量のセキュリティを持つことができます。 プロトコル

Dorner & Resnick                                                [Page 4]

RFC 1339             Remote Mail Checking Protocol             June 1992

プロトコル1992年6月にチェックするデルナーとレズニック[4ページ]RFC1339のリモートメール

   currently only uses cleartext passwords, but can be simply modified
   to use other authentication formats. The scheme mentioned in "Server
   Implementation Notes" of using only (0,1) and (1,0) in the responses
   also may limit access to some types of information.  Implementations
   that do not use the authenticated scheme MUST have a mechanism by
   which a user can give consent to have this information made
   available; the default for the unauthenticated implementation should
   be that a user's maildrop cannot be accessed until consent of the
   user is given. (For example, UNIX server implementations may wish to
   make use of the "owner execute" bit to indicate whether a particular
   maildrop allows use of the unauthenticated protocol. If this is done,
   a single "stat" call can be used to gather all information required
   to respond to a poll.) Servers which do not implement authentication
   should simply return a zero-filled datagram for maildrops which don't
   have permission.

現在cleartextパスワードを使用するだけですが、他の認証形式を使用するように単に変更できます。 体系は使用だけの「サーバ実装注意」で(0、1)について言及しました、そして、応答における(1、0)もアクセスを何人かのタイプの情報に制限するかもしれません。 認証された体系を使用しない実装はユーザがこの情報を利用可能にさせるように承諾を与えることができるメカニズムを持たなければなりません。 非認証された実装のためのデフォルトはユーザの同意を与えるまでユーザの郵便受けにアクセスできないということであるべきです。 (例えば、Unixサーバー実装が利用したがっているかもしれない、「所有者は、特定の郵便受けが非認証されたプロトコルの使用を許すかどうかを示すために」 ビットを実行します。 これが完了しているなら、すべての情報が投票に応じるのが必要であると推測するのにただ一つの「スタット」呼び出しを使用できます。) 認証を実装しないサーバは許可を持っていない郵便受けのために単に無いっぱいにされたデータグラムを返すべきです。

   The other security consideration involves unknown maildrops and
   usernames. Some site administrators consider it a security risk give
   out any information which would reveal the existence or non-existence
   of a certain username or maildrop on the system. For this reason, we
   have chosen to have the server send back a zero-filled datagram as
   the response to either a request for an unknown username or a
   maildrop that does not exist or is empty. In this way, potential
   security violations are limited, since there is no way to tell the
   difference between an empty maildrop and non-existent maildrop, and
   also no way to tell if the user exists on the system or not. If
   greater security is desired, the protocol should probably not be run
   in the first place.

もう片方の警備上の配慮は未知の郵便受けとユーザ名にかかわります。 サイトの管理者の中にはそれがリスクがシステムで、あるユーザ名か郵便受けの存在か非存在を明らかにするどんな情報からも与えるセキュリティであると考える人もいます。 この理由で、私たちは、サーバに未知のユーザ名に関する要求か既存でないか、または空の郵便受けのどちらかへの応答として無いっぱいにされたデータグラムを返送させるのを選びました。 このように、潜在的安全の侵害は限られています、空の郵便受けと実在しない郵便受けの違いを言いますが、ユーザがシステムの上に存在するかどうか言うどんな方法も教えない方法が全くないので。 よりすばらしいセキュリティが望まれているなら、プロトコルはたぶん1位に立候補することであるべきではありません。

Authors' Addresses

作者のアドレス

   Steve Dorner
   Digital Computer Laboratory
   University of Illinois at Urbana-Champaign
   1304 West Springfield Avenue
   Urbana, Illinois 61801

Urbana-Champaign1304の西スプリングフィールドAvenueアーバナ、イリノイ 61801のイリノイのスティーブデルナーデジタル・コンピュータ研究所大学

   Phone: (217) 244-1765
   EMail: s-dorner@uiuc.edu

以下に電話をしてください。 (217) 244-1765 メールしてください: s-dorner@uiuc.edu

   Pete Resnick
   The Beckman Institute
   University of Illinois at Urbana-Champaign
   405 North Mathews Avenue
   Urbana, Illinois 61801

Urbana-Champaign405の北のマシューズ・Avenueアーバナ、イリノイ 61801のイリノイのピートレズニックBeckman研究所大学

   Phone: (217) 244-1265
   EMail: resnick@cogsci.uiuc.edu

以下に電話をしてください。 (217) 244-1265 メールしてください: resnick@cogsci.uiuc.edu

Dorner & Resnick                                                [Page 5]

RFC 1339             Remote Mail Checking Protocol             June 1992

プロトコル1992年6月にチェックするデルナーとレズニック[5ページ]RFC1339のリモートメール

Dorner & Resnick                                                [Page 6]

デルナーとレズニック[6ページ]