RFC1204 日本語訳
1204 Message Posting Protocol (MPP). S. Yeh, D. Lee. February 1991. (Format: TXT=11371 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Yeh
Request for Comments: 1204 D. Lee
Netix Communications, Inc.
February 1991
コメントを求めるワーキンググループS.イップ要求をネットワークでつないでください: 1204 D.リーNetixコミュニケーションInc.1991年2月
Message Posting Protocol (MPP)
メッセージの投稿プロトコル(MPP)
Status of this Memo
このMemoの状態
This memo describes a protocol for posting messages from workstations (e.g., PCs) to a mail service host. 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.
このメモは、ワークステーション(例えば、PC)からメールサービス・ホストまでメッセージを投稿するためにプロトコルについて説明します。 このRFCはExperimentalプロトコルをインターネットコミュニティに指定します。 議論と改善提案は要求されています。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。
1. INTRODUCTION
1. 序論
Operating systems for personal computers do not provide a mechanism for user authentication. However, such a mechanism is crucial for electronic mail system since authenticating message sender's identity is important in preventing mail forgery. Hence, adding personal computers to an electronic mail network requires an agent (message posting server) to authenticate sender's identity and then submit mail to the message delivery system (e.g., Sendmail, MMDF) on behalf of the sender at a PC. The Netix Message Posting Protocol is developed to be the interface between the message posting server and the PC (client). The protocol is designed to use TCP and is based on the command and reply structures defined for Simple Mail Transfer Protocol (RFC 821) and File Transfer Protocol (RFC 959).
パーソナルコンピュータのためのオペレーティングシステムはメカニズムをユーザー認証に提供しません。 しかしながら、メッセージ送付者のアイデンティティを認証するのがメール偽造を防ぐのにおいて重要であるので、電子メール・システムに、そのようなメカニズムは重要です。 したがって、電子メール・ネットワークにパーソナルコンピュータを加えるのは、エージェント(メッセージの投稿サーバ)がPCの送付者を代表してメッセージ配送システム(例えば、センドメール、MMDF)に送付者のアイデンティティを認証して、次に、メールを提出するのを必要とします。 Netix Message Postingプロトコルは、メッセージの投稿サーバとPC(クライアント)とのインタフェースになるように開発されます。 プロトコルは、TCPを使用するように設計されていて、構造がシンプルメールトランスファプロトコル(RFC821)とFile Transferプロトコル(RFC959)のために定義したコマンドと回答に基づいています。
2. SPECIFICATIONS
2. 仕様
2.1. Command List
2.1. コマンドリスト
USER <SP> <username> <CRLF>
PASS <SP> <password> <CRLF>
DATA <CRLF>
NOOP <CRLF>
QUIT <CRLF>
ユーザ<SP><ユーザ名><CRLF>パス<SP><パスワード><CRLF>データ<CRLF>NOOP<CRLF>は<CRLF>をやめます。
2.2. Reply List
2.2. 回答リスト
220 Message Posting Service Ready.
221 Closing Connection.
250 Command OK.
準備ができていた状態でサービスを掲示する220メッセージ。 221 接続を終えます。 250はOKを命令します。
Yeh & Lee [Page 1] RFC 1204 MPP February 1991
イップとリー[1ページ]RFC1204MPP1991年2月
354 Enter mail, end with <CRLF>.<CRLF>
451 Local error encountered.
500 Command unrecognized.
501 Argument syntax error.
503 Illegal command sequence.
530 Authentication Failure.
550 Error.
354はメール、<CRLF><CRLF>451Local誤りが遭遇している終わりを入れます。 500 コマンド認識されていません。 501議論構文エラー。 503 不正コマンド系列。 530 認証失敗。 550 誤り。
2.3. Command and Reply Descriptions
2.3. コマンドと回答記述
USER <SP> <username> <CRLF>
ユーザ<SP><ユーザ名><CRLF>。
The USER command informs the message posting server about the
username of the user trying to submit mail to the network. The
required argument for the USER command is a string specifying
the message sender's username.
USERコマンドはネットワークにメールを提出しようとするユーザのユーザ名に関するメッセージの投稿サーバを知らせます。 USERコマンドのための必要な議論はメッセージ送付者のユーザ名を指定するストリングです。
The USER command can only be used under three conditions:
3つの条件のもとでUSERコマンドを使用できるだけです:
- when the session with the message posting server has just
started;
- メッセージの投稿サーバとのセッションがちょうど始まったところなとき。
- right after a message text (terminated by the "<CRLF>.<CRLF>"
sequence) has been successfully submitted to the message
posting server;
- メッセージ直後、首尾よく、テキスト(「<CRLF><CRLF>」系列で、終えられる)をメッセージの投稿サーバに提出しました。
- right after a USER command that gets the reply code 501.
- USERコマンド直後、それは回答コード501を得ます。
List of possible reply codes for the USER command:
USERコマンドのための可能な回答コードのリスト:
- 250 The username of the message sender has been accepted.
- 250 メッセージ送付者のユーザ名を受け入れました。
- 451 Internal error has occurred in the message posting
server.
- 451 内部エラーはメッセージの投稿サーバで起こりました。
- 501 Syntax error detected in the username argument.
- ユーザ名議論で検出された501構文エラー。
- 503 The USER command has been used under an inappropriate
condition (i.e., one that is not specified above).
- 503 USERコマンドは不適当な条件(すなわち、上で指定されないもの)のもとで使用されました。
It is recommended that the message posting server should return
250 even if the username is not recognized by the message
posting server, as long as the username is syntactically
correct. This is an attempt to prevent the message posting
server from releasing too much information about the user
database. Client should not be able to test the existence of a
certain username.
ユーザ名がメッセージの投稿サーバによって認識されないでもメッセージの投稿サーバが250を返すのは、お勧めです、ユーザ名がシンタクス上正しい限り。 これはメッセージの投稿サーバがユーザデータベースのあまりに多くの情報を発表するのを防ぐ試みです。 クライアントはあるユーザ名の存在をテストできないべきです。
Yeh & Lee [Page 2] RFC 1204 MPP February 1991
イップとリー[2ページ]RFC1204MPP1991年2月
PASS <SP> <password> <CRLF>
<SP><パスワード><CRLF>を渡してください。
The PASS command is used to inform the message posting server
about the password associated with the username previously
specified. The required argument for the PASS command is a
string specifying the message sender's password.
PASSコマンドは、以前に指定されるユーザ名に関連しているパスワードに関するメッセージの投稿サーバを知らせるのに使用されます。 PASSコマンドのための必要な議論はメッセージ送付者のパスワードを指定するストリングです。
The PASS command can only be used under two conditions:
2つの条件のもとでPASSコマンドを使用できるだけです:
- right after a USER command that gets the reply code 250;
- USERコマンド直後、それは回答コード250を得ます。
- right after a PASS command that gets the reply code 501.
- PASSコマンド直後、それは回答コード501を得ます。
List of possible reply codes for the PASS command:
PASSコマンドのための可能な回答コードのリスト:
- 250 The password has been accepted and verified to be
correctly associated with the username previously
specified.
- 250 パスワードは、正しく以前に指定されるユーザ名に関連しているように受け入れられて、確かめられました。
- 451 Internal error has occurred in the message posting
server.
- 451 内部エラーはメッセージの投稿サーバで起こりました。
- 501 Syntax error detected in the password argument.
- パスワード議論で検出された501構文エラー。
- 503 The PASS command has been used under an inappropriate
condition (i.e., one that is not specified above).
- 503 PASSコマンドは不適当な条件(すなわち、上で指定されないもの)のもとで使用されました。
- 530 The password provided is not the one associated with the
username previously specified.
- 530 提供されたパスワードは以前に指定されるユーザ名に関連しているものではありません。
DATA <CRLF>
データ<CRLF>。
The DATA command is used to inform the message posting server
to get ready to accept a mail message text. No argument is
expected. (This command has the same meaning as the DATA
command defined in RFC 821.)
DATAコマンドは、メールメッセージ・テキストを受け入れるために用意するためにメッセージの投稿サーバを知らせるのに使用されます。 議論は全く予想されません。 (このコマンドには、RFC821で定義されたDATAコマンドと同じ意味があります。)
The DATA command can only be used under two conditions:
2つの条件のもとでDATAコマンドを使用できるだけです:
- right after a PASS command that gets the reply code 250;
- PASSコマンド直後、それは回答コード250を得ます。
- right after a mail message text has been successfully
accepted from the client.
- メール・メッセージ直後、クライアントからテキストを首尾よく受け入れました。
List of possible reply codes for the DATA command:
DATAコマンドのための可能な回答コードのリスト:
- 354 The message posting server is ready to accept the mail
message text.
- 354 メッセージの投稿サーバはメールメッセージ・テキストを受け入れる準備ができています。
Yeh & Lee [Page 3] RFC 1204 MPP February 1991
イップとリー[3ページ]RFC1204MPP1991年2月
- 451 Internal error has occurred in the message posting
server.
- 451 内部エラーはメッセージの投稿サーバで起こりました。
- 503 The DATA command has been used under an inappropriate
condition (i.e., one that is not specified above).
- 503 DATAコマンドは不適当な条件(すなわち、上で指定されないもの)のもとで使用されました。
Upon receiving the reply code 354 for the DATA command, the
client should submit the mail message text to message posting
server and terminate the text by the sequence "<CRLF>.<CRLF>"
as defined in RFC 821. If the message text includes the
"<CRLF>.<CRLF>" sequence, then the sequence is replaced by the
"<CRLF>..<CRLF>" sequence as defined in RFC 821. The extra "."
token will not be included in the final copy of the submitted
message.
DATAコマンドのために回答コード354を受け取ると、クライアントは、RFC821で定義されるようにメッセージの投稿サーバにメールメッセージ・テキストを提出して、系列「<CRLF><CRLF>」でテキストを終えるべきです。 メッセージ・テキストが「<CRLF><CRLF>」系列を含んでいるなら、系列を「<CRLF>」に取り替えます。RFC821で定義される「<CRLF>」系列。 含まれていなくて. 」 トークンがそうする「エキストラ」は決勝で提出されたメッセージをコピーします。
Upon receiving the mail message text terminated by the
"<CRLF>.<CRLF>" sequence, list of possible reply codes is:
「<CRLF><CRLF>」系列によって終えられたメールメッセージ・テキストを受け取ると、可能な回答コードのリストは以下の通りです。
- 250 The mail message text has been successfully queued for
delivery.
- 250 配送のために首尾よくメールメッセージ・テキストを列に並ばせてあります。
- 451 Internal error has occurred in the message posting
server and the mail message text has not been queued.
- 451 内部エラーはメッセージの投稿サーバで起こって、メールメッセージ・テキストは列に並ばせられていません。
NOOP <CRLF>
NOOP<CRLF>。
The NOOP command does not cause any action to be performed by
the message posting server. Instead, it tests the status of
the message posting server. No argument is expected.
メッセージの投稿サーバはNOOPコマンドで少しの動作も実行しません。代わりに、それはメッセージの投稿サーバの状態をテストします。議論は全く予想されません。
The NOOP command cannot be used under one condition:
1つの条件のもとでNOOPコマンドを使用できません:
- right after a DATA command that gets the reply code 354
(i.e., when the message posting server is expecting the client
to submit the mail message text).
- DATAコマンド直後、それは回答コード354を得ます(すなわち、メッセージの投稿サーバは、いつクライアントがメールメッセージ・テキストを提出すると予想していますか)。
List of possible reply codes for the NOOP command:
NOOPコマンドのための可能な回答コードのリスト:
- 250 The message posting server has not encountered any
internal error.
- 250 メッセージの投稿サーバは少しの内部エラーにも遭遇していません。
- 451 Internal error has occurred in the message posting
server during the current session.
- 451 現在のセッションの間、内部エラーはメッセージの投稿サーバで起こっています。
QUIT <CRLF>
<CRLF>をやめてください。
The QUIT command is used to terminate the session with the
message posting server. No argument is expected.
QUITコマンドは、メッセージの投稿サーバとのセッションを終えるのに使用されます。議論は全く予想されません。
Yeh & Lee [Page 4] RFC 1204 MPP February 1991
イップとリー[4ページ]RFC1204MPP1991年2月
The QUIT command can be used under any condition. The message
posting server should always return the reply code 221 for the
QUIT command.
どんな条件のもとでもQUITコマンドを使用できます。 メッセージの投稿サーバはQUITコマンドのためにいつも回答コード221を返すべきです。
3. IMPLEMENTATION OF THE MESSAGE POSTING SERVER
3. メッセージの投稿サーバの実装
There are several issues to be considered when implementing the message posting server:
メッセージの投稿サーバを実装するとき考えられるいくつかの問題があります:
- secured environment - port number assignment - handling of idle client - local/remote password database - message queuing - handling of message delivery failure
- 機密保護している環境--ポートナンバー課題--活動していないクライアントの取り扱い--地方の、または、リモートなパスワードデータベース--メッセージ待ち行列--メッセージ配信障害の取り扱い
3.1 Secured Environment
3.1 機密保護している環境
The message posting server is responsible for authenticating message senders and submitting mail to the message delivery system. Hence, it should be running in a secured environment, such as running on a system (UNIX, VMS, MS-DOS) with well restricted physical and network access.
メッセージの投稿サーバはメッセージ配送システムにメッセージ送付者を認証して、メールを提出するのに原因となります。 したがって、機密保護している環境へ駆け込むべきです、よく制限された物理的、そして、ネットワークのアクセサリーでシステム(UNIX、VMS、MS-DOS)で動くのなどように
3.2 Port Number Assignment
3.2 ポートナンバー課題
Port 218 is assigned for the Netix Message Posting Protocol.
ポート218はNetix Message Postingプロトコルのために割り当てられます。
3.3 Handling of Idle Client
3.3 活動していないクライアントの取り扱い
The message posting server should terminate a session if the client has been idle for too long, to release the resource allocated for the session.
クライアントがセッションのために割り当てられたリソースを発表するためにあまりに長い間活動していないなら、メッセージの投稿サーバはセッションを終えるべきです。
3.4 Local/Remote Password Database
3.4 地方の、または、リモートなパスワードデータベース
To take advantage of existing password databases, such as the passwd file in UNIX, the message posting server can use FTP and POP3 to perform the username and password checking with the appropriate server.
UNIXのpasswdファイルなどの既存のパスワードデータベースを利用するなら、メッセージの投稿サーバは、適切なサーバに問い合わせるユーザ名とパスワードを実行するのにFTPとPOP3を使用できます。
For network that does not have any password database, the message posting server should let the system administrator specify a local password file on the host that the message posting server is running.
どんなパスワードデータベースも持っていないネットワークのために、システム管理者はメッセージの投稿サーバでメッセージの投稿サーバが車で送っているホストのローカルのパスワードファイルを指定できるべきです。
Yeh & Lee [Page 5] RFC 1204 MPP February 1991
イップとリー[5ページ]RFC1204MPP1991年2月
3.5 Message Queuing
3.5 メッセージ待ち行列
The message posting server should attempt to submit accepted messages to the message delivery system as soon as possible.
メッセージの投稿サーバは、できるだけ早くメッセージ配送システムに受け入れられたメッセージを提出するのを試みるべきです。
3.6 Handling of Message Delivery Failure
3.6 メッセージ配信障害の取り扱い
Failure in delivering messages should be handled by the message delivery system and the message posting server should not interfere.
メッセージを提供することにおける失敗はメッセージ配送システムによって扱われるべきです、そして、メッセージの投稿サーバに干渉するべきではありません。
4. REFERENCES
4. 参照
[1] Postel, J., "Simple Mail Transfer Protocol", RFC 821,
USC/Information Sciences Institute, August 1982.
[1] ポステル、J.、「簡単なメール転送プロトコル」、RFC821、科学が1982年8月に設けるUSC/情報。
[2] Postel, J., and J. Reynolds, "File Transfer Protocol", RFC 959,
USC/Information Sciences Institute, October 1985.
[2] ポステル、J.とJ.レイノルズ、「ファイル転送プロトコル」、RFC959、科学が1985年10月に設けるUSC/情報。
Security Considerations
セキュリティ問題
Security issues are discussed in section 3.1.
セクション3.1で安全保障問題について議論します。
Authors' Addresses
作者のアドレス
Shannon Yeh Netix Communications, Inc. 15375 Barranca Parkway, Suite A-215 Irvine, CA 92718
シャノンイップNetix Inc.15375Barrancaパークウェイ、コミュニケーションスイートA-215アーバイン(カリフォルニア)92718
Phone: (714) 727-9335
以下に電話をしてください。 (714) 727-9335
Email: yeh@netix.com
メール: yeh@netix.com
David Lee Netix Communications, Inc. 15375 Barranca Parkway, Suite A-215 Irvine, CA 92718
デヴィッド・リーNetix Inc.15375Barrancaパークウェイ、コミュニケーションスイートA-215アーバイン(カリフォルニア)92718
Phone: (714) 727-9335
以下に電話をしてください。 (714) 727-9335
EMail: dlee@netix.com
メール: dlee@netix.com
Yeh & Lee [Page 6]
イップとリー[6ページ]
一覧
スポンサーリンク
