RFC771 日本語訳
0771 Mail transition plan. V.G. Cerf, J. Postel. September 1980. (Format: TXT=18623 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group V. Cerf (ARPA)
Request for Comments: 771 J. Postel (ISI)
September 1980
コメントを求めるワーキンググループV.サーフの(アルパ)要求をネットワークでつないでください: 771 J.ポステル(ISI)1980年9月
MAIL TRANSITION PLAN
メール変遷プラン
PREFACE
序文
This is a draft memo and comments are requested.
これは草稿メモです、そして、コメントは要求されています。
INTRODUCTION
序論
The principal aim of the mail service transition plan is to provide orderly support for computer mail service during the period of transition from the old ARPANET protocols to the new Internet protocols.
メールサービス変遷プランの主な目的は古いアルパネットプロトコルから新しいインターネットプロトコルまでの過渡期の間、コンピュータメールサービスの規則的なサポートを提供することです。
This plan covers only the transition from the current text computer mail in the ARPANET environment to text computer mail in an Internet environment. This plan does not address a second transition from text only mail to multimedia mail [10,11].
このプランはアルパネット環境における現在のテキストコンピュータメールからインターネット環境におけるテキストコンピュータメールまでの変遷だけをカバーしています。 このプランはマルチメディアメール[10、11]への唯一のメールをテキストからの2番目の変遷に扱いません。
The goal is to provide equivalent or better service in the new Internet environment as was available in the ARPANET environment. During the interim period, when both protocol environments are in use, the goal is to minimize the impact on users and existing software, yet to permit the maximum mail exchange connectivity.
目標は利用可能であったようにアルパネット環境で同等であるか、より良いサービスを新しいインターネット環境に提供することです。 当座の期間、目標はユーザと既存のソフトウェアで影響を最小にすることです、まだ、最大のメール交換の接続性を可能にしていません。(その時、両方のプロトコル環境は使用中です)。
It is assumed that the user is familiar with both the ARPANET and Internet protocol environments [1-8]. The Internet protocols are designed to be used in a diverse collection of networks including the ARPANET, Packet Radio nets, Satellite nets, and local nets (e.g., Ethernets, Ring nets); while the ARPANET protocol are, of course, limited to the ARPANET.
ユーザがアルパネットとインターネットプロトコル環境[1-8]の両方に詳しいと思われます。 インターネットプロトコルはアルパネット、Packet Radioネット、Satelliteネット、およびローカルのネットを含んでいて、ネットワークのさまざまの収集で使用されるように設計されています(例えば、Ethernets、Ringは網状になります)。 アルパネットプロトコルはもちろんアルパネットに制限されますが。
The Internet protocol environment specifies TCP as the host-to-host transport protocol. The ARPANET protocol environment specifies NCP as the host-to-host transport protocol. Both TCP and NCP provide connection type process-to-process communication. The problem in the transition is to bridge these two different interprocess communication systems.
インターネットプロトコル環境はホストからホストへのトランスポート・プロトコルとしてTCPを指定します。 アルパネットプロトコル環境はホストからホストへのトランスポート・プロトコルとしてNCPを指定します。 TCPとNCPの両方がプロセス間通信を結合方式に提供します。 変遷における問題はこれらが2台の異なったプロセス間通信システムであるとブリッジすることです。
The objective of this plan is to specify the means by which the ARPANET computer mail services may be extended into the Internet system without disruptive changes for the users during the transition.
このプランの目的はアルパネットコンピュータメールサービスがユーザのために変遷の間に破壊的な変化なしでインターネット・システムに広げられるかもしれない手段を指定することです。
1
1
September 1980 RFC 771 Mail Transition Plan
1980年9月のRFC771メール変遷プラン
MODEL OF MAIL SERVICE
メールサービスのモデル
The model of the computer mail system taken here separates the mail composition and reading functions from the mail transport functions. In the following, the discussion will be hoplessly TOPS20-oriented. We appologize to users of other systems, but we feel it is better to discuss examples we know than to attempt to be abstract.
ここに連れて行かれたコンピュータメールシステムのモデルはメール輸送機能とメール構成と読書機能を切り離します。 以下では、議論はhoplessly TOPS20指向になるでしょう。 他のシステムのユーザにappologizeしますが、私たちは、抽象的であることを試みるより私たちが知っている例について議論するのが良いと感じます。
In the ARPANET mail service, composition and reading is done with user programs such as HERMES, MSG, MM, etc., while mail transmission is done by system programs such as MAILER (sending) and FTPSRV (receiving).
アルパネットメールサービスでは、構成で読書しているのは、エルメス、MSG、MMなどのユーザ・プログラムでしています、メールである間、メイラー(発信)やFTPSRV(受信)などのシステムプログラムでトランスミッションをするということです。
One element of the ARPANET mail service is the assumption that every source of mail can have a direct interprocess communication connection (via the NCPs) to every destination for mail. (There are some cases where special handling and forwarding of mail violates this assumption.)
あるアルパネットメールサービスの要素がメールのすべての源がダイレクトプロセス間通信接続(NCPを通した)をメールのためのあらゆる目的地に持つことができるという仮定です。 (いくつかのケースがメールの特別な取り扱いと推進がこの仮定に違反するところにあります。)
Mailbox names are of the form "MAILBOX@HOST", and it is assumed that MAILBOX is a destination mailbox on that host.
メールボックス名はフォーム" MAILBOX@HOST "のものです、そして、メールボックスがそのホストの上のあて先メールボックスであると思われます。
The messages are actually transmitted according to the provisions of the File Transfer Protocol. Mail may be transimitted via either the control connection (MAIL command), or via a data connection (MLFL command). In either case, the argument specifies only the mailbox since the destination host is assumed to be the host receiving the transmission.
File Transferプロトコルに関する条項に応じて、メッセージは実際に送られます。 コントロール接続(メールコマンド)かデータ接続(MLFLコマンド)でメールはtransimittedされるかもしれません。 どちらの場合ではも、あて先ホストがトランスミッションを受けるホストであると思われるので、議論はメールボックスだけを指定します。
For example: messages sent from Postel at USC-ISIF to Cerf at
USC-ISIA would arrive at ISIA with the argument "Cerf" but no
indication of the host.
例えば: USC-ISIFのポステルからUSC-ISIAのサーフに送られたメッセージは議論「サーフ」にもかかわらず、ホストのどんなしるしでもISIAに到着しないでしょう。
COMPOUND AND ALTERNATE NAMES
合成AND別名称
Mailboxes are of the form "mailbox@host" where mailbox is usually a name like "Postel" and host is a host identifier like "USC-ISIF". In some cases it will be useful to allow the host to be a compound name such as:
メールボックスは通常、メールボックスが「ポステル」のように名前であり、ホストが"USC-ISIF"のようにホスト識別子であるところのフォーム" mailbox@host "のものです。 化合物であることをホストを許容するのが役に立ついくつかの場合では、以下としてそのようなものを命名してください。
USC-ISIA
ARPANET-ISIA
SATNET-NDRE
PPSN-RSRE
HOST1.SRINET
LSCNET/MAILROOM
USC-ISIAアルパネット-ISIA SATNET-NDRE PPSN-RSRE HOST1.SRINET LSCNET/郵便室
2
2
RFC 771 September 1980
Mail Transition Plan
RFC771 1980年9月のメール変遷プラン
or even the name of an organization:
組織の名前さえ:
BBN
ARPA
MIT
SRI
BBNアルパMIT様
The only restriction is that "@" not appear in either the "mailbox" or the "host" strings in the destination address.
唯一の制限は"@"が送付先アドレスの「メールボックス」か「ホスト」ストリングのどちらかに現れないということです。
To actually send the message the mailer program must convert the host string into the physical address to which to transmit the message. This name-to-address conversion is typically done by looking the name up in a table and finding the physical address in another field of that table entry. This means that all the compound and organization names (and any other alternate names or synonyms) must also be in the host table.
実際に郵送者プログラムをメッセージに送るのはメッセージを送る物理アドレスにホストストリングを変換しなければなりません。 通常テーブルで名前を調べて、そのテーブル項目の別の分野で物理アドレスを見つけることによって、この名前からアドレス変換をします。 これは、また、すべての化合物と組織名(そして、いかなる他の別名称か同義語も)がホストテーブルにあるに違いないことを意味します。
HIDDEN HOSTS
隠されたホスト
Sometimes the mailbox part of the destination address is a compound name and is used to mark a set of mailboxes which are not really on the host at all, but rather on another host which is connected to this host in a non-standard way.
送付先アドレスのメールボックス部分は、時々、化合物名であり、標準的でない方法でむしろこのホストに接される別のホストの上に本当に全くホストの上にあるのではなく、ある1セットのメールボックスをマークするのに使用されます。
It is important to users of computer mail that replies to messages may be easily composed with automatic assistance from the mail processing programs. To preserve this capability it is important that a host understand the mailbox part of every address in every message it sends if the host part of the address is itself.
コンピュータメールのユーザにとって、メッセージに関する回答が自動支援でメール処理プログラムから容易に構成されるのは、重要です。この能力を保持するために、ホストがアドレスのホスト部分がそれ自体であるならそれが送るあらゆるメッセージのあらゆるアドレスのメールボックス部分を理解しているのは、重要です。
That is, for every message, in every header field, in every address "m@h", host h must understand all values of m. Thus when a host prepares a message it should check all the addresses that appear in the header and for any address whose host part is this host the mailbox part should be verified.
すなわち、あらゆるメッセージに関しては、あらゆるヘッダーフィールド、あらゆるアドレス" m@h "では、ホストhはmのすべての値を理解しなければなりません。 ホストがメッセージを準備するとき、したがって、ヘッダーに現れるすべてのアドレスをチェックするべきです、そして、ホスト部分がこのホストであるどんなアドレスにおいても、メールボックス部分は確かめられるべきです。
3
3
September 1980 RFC 771 Mail Transition Plan
1980年9月のRFC771メール変遷プラン
THE TRANSITION PLAN
変遷プラン
The basic ground rules for the transition are:
変遷のための基本的な基本規則は以下の通りです。
1. ARPANET mailbox names must continue to work correctly.
1. アルパネットメールボックス名は、正しく働き続けなければなりません。
2. No changes should be required to mail editor software which
parses message headers to compose replies and the like.
Specifically, non-ARPANET mailbox designators must be
accommodated without change to the parsing and checking mechanisms
of mail processing programs.
2. 変化は全く構成するためにメッセージヘッダーを分析するエディタソフトウェアに回答と同様のものを郵送するのが必要であるべきではありません。 明確に、非アルパネットメールボックス指示子は、構文解析への変化なしで対応されて、メール処理プログラムのメカニズムをチェックしなければなりません。
3. Automatic forwarding of messages between NCP and TCP
environments without user (or operator) intervention.
3. NCPとTCP環境の間のユーザ(または、オペレータ)介入のないメッセージの自動推進。
For the communication of messages between NCP and TCP hosts a mail relay service will be provided on a few hosts that implement both TCP and NCP. These will be "well known" in the same sense that sockets or ports for contacting Telnet or FTP servers are well known.
NCPとTCPホストの間のメッセージに関するコミュニケーションにおいて、TCPとNCPの両方を実装する数人のホストの上でメール中継サービスを提供するでしょう。 これらはTelnetに連絡するためのソケットかポートかFTPサーバがよく知られているという同じ意味で「よく知られているでしょう」。
To make use of these relay servers changes will be made to the mailer programs. The mailer program will be responsible for determining if the destination address of the message is directly reachable via the interprocess communication system it has available (TCP or NCP or both), or if the mail must be relayed. If the mail must be relayed, the mailer must choose a relay server and transmit the message to it.
これらのリレーサーバ変化を利用するのを郵送者プログラムにするでしょう。郵送者プログラムはそれが利用可能にするプロセス間通信システム(TCP、NCPまたは両方)でメッセージの送付先アドレスが直接届くかどうか、またはメールをリレーしなければならないかどうか決定するのに原因となるようになるでしょう。 メールをリレーしなければならないなら、郵送者は、リレーサーバを選んで、メッセージをそれに送らなければなりません。
The basis for the decision the mailer must make is an expanded host name table. There will be a table which translates host names to physical addresses. The physical addresses in this table will be the 32-bit Internet addresses. (This makes sense for even NCP-only hosts, since after 1 January 1981 even they must use 96-bit leader format which requires 24-bit ARPANET physical addresses). Each entry in this table will also have some flag bits.
郵送者がしなければならない決定の基礎は拡張ホスト名テーブルです。 ホスト名を物理アドレスに翻訳するテーブルがあるでしょう。 このテーブルの物理アドレスは32ビットのインターネット・アドレスになるでしょう。 (これはNCPだけホストのためにさえ理解できます、彼らさえ1981年1月1日以降に24ビットのアルパネット物理アドレスを必要とする96ビットのリーダー形式を使用しなければならないので。) また、このテーブルの各エントリーには、いくつかのフラグビットがあるでしょう。
The flag bits will include information to indicate if the host in this entry is (1) a NCP host with "old tables", (2) a NCP host with "new tables", (3) a TCP host, or (4) some other kind of host. All TCP hosts are assumed to have "new tables". "Old tables" are those without these flag bits, while "new tables" do have these flags.
フラグビットは(4) (3) (1) 「古いテーブル」をもっているNCPホスト、(2) 「新しいテーブル」をもっているNCPホスト、TCPホストがホストであるならこのエントリーに、いるのを示す情報かある他の種類のホストを含むでしょう。 すべてのTCPホストには「新しいテーブル」があると思われます。 「古いテーブル」はこれらのフラグビットがなければそれらですが、「新しいテーブル」には、これらの旗があります。
A separate table may be useful to list the addresses of the hosts with relay servers.
別々のテーブルは、リレーサーバでホストのアドレスを記載するために役に立つかもしれません。
4
4
RFC 771 September 1980
Mail Transition Plan
RFC771 1980年9月のメール変遷プラン
When a message is sent to a relay server, the control information (in the argument of the mail transfer command) must be augmented to include the destination host identifier.
リレーサーバにメッセージを送るとき、目的地ホスト識別子を含むように、制御情報(メール転送命令の議論における)を増大させなければなりません。
The relay server may accept messages to be relayed without knowing that destination mailbox is actually reachable. This means that it may later discover that the destination mailbox does not exist (or some other condition prevents mail delivery). To be able to report the error to the originating user, the mailbox (mailbox@host) of the originating user must be included in the argument of the mail transfer command. If the argument does not contain the address of the originating user no error response is attempted. The error report, which is itself a message, does not carry an originator address in the command argument to avoid the possibility of a endless chain of error reports (however, an originator address does appear the header).
リレーサーバはあて先メールボックスが実際に届いているのを知らないリレーされるべきメッセージを受け入れるかもしれません。 これは、後であて先メールボックスが存在しないと発見するかもしれないことを意味します(ある他の状態は郵便配達を防ぎます)。 起因しているユーザに誤りを報告できるように、メール転送命令の議論に起因しているユーザのメールボックス( mailbox@host )を含まなければなりません。 議論が起因しているユーザのアドレスを含んでいないなら、どんな誤り応答も試みられません。 エラー・レポート(それ自体で、メッセージである)は、エラー・レポートのエンドレス・チェーンの可能性を避けるためにコマンド議論における創始者アドレスを載せません(しかしながら、創始者アドレスはヘッダーに現れます)。
Since the originating host will act as if the mail was successfully delivered when it is accepted by the relay server, it deletes any back up copies of the message it was keeping in case of errors. For this reason, the relay server must include the complete message in any error report it sends to the originator. The relay server should parse the addresses in the argument before accepting a message. If it does not understand how deliver locally, or both relay and reply (if the originating address is present) to the message, it should not accept it.
送信元ホストがリレーサーバでそれを受け入れるとき、まるで首尾よくメールを提供するかのように行動するので、それはそれが誤りの場合に保っていたメッセージのコピーにどんな後部も削除します。 この理由で、リレーサーバはそれが創始者に送るどんなエラー・レポートにも完全なメッセージを含まなければなりません。 メッセージを受け入れる前に、リレーサーバは議論におけるアドレスを分析するべきです。 どのように両方がメッセージに関して局所的に配送するか、リレーして、または返答して(起因するアドレスが存在しているなら)、それを受け入れるべきでないかを理解していないなら。
There are enough differences in the transmission procedure that the relay server will use a distinct mail transfer protocol, separate from the file transfer protocol.
リレーサーバが異なったメール転送プロトコルの、そして、ファイル転送プロトコルから別々の使用を望んでいるトランスミッション手順の違いが十分あります。
MAIL TRANSFER PROTOCOL
メール転送プロトコル
The mail trasfer protocol to be used by the relay server and all TCP hosts is documented in reference [9].
リレーサーバとすべてのTCPホストによって使用されるべきメールtrasferプロトコルは参照[9]に記録されます。
CONNECTIVITY
接続性
There are nine cases of mail exchange, the three by three matrix of (1) old-table NCP hosts, (2) new-table NCP hosts, (3) TCP hosts. There are also two transfer mechanisms: file transfer and mail transfer. The diagonal is easy, each type of host can exchange mail with other hosts of its type. The other cases are more subtle.
9つのケースのメール交換があります、(1) 古いテーブルNCPホストの3マトリクスによる3、(2)新しいテーブルNCPホスト、(3)TCPホスト。 また、2台のトランスファ・メカニズムがあります: ファイル転送とメールは移されます。 対角線が簡単である、それぞれのタイプのホストはタイプの他のホストとメールを交換できます。 他のケースは、より微妙です。
5
5
September 1980 RFC 771 Mail Transition Plan
1980年9月のRFC771メール変遷プラン
An old-table NCP host is assumed to have a table with 32-bit physical addresses, but no flag bits. It has NCP and file transfer. It does not have the separate mail transfer protocol.
古いテーブルNCPホストが32ビットの物理アドレスにもかかわらず、フラグビットがないテーブルを持っていると思われます。 それには、NCPとファイル転送があります。 それには、別々のメール転送プロトコルがありません。
An new-table NCP host is assumed to have a table with 32-bit physical addresses, and the flag bits. It has NCP and file transfer. It also has the new separate mail transfer.
新しいテーブルNCPホストが32ビットの物理アドレス、およびフラグビットがあるテーブルを持っていると思われます。 それには、NCPとファイル転送があります。 また、それで、新しい別メールは移されます。
An TCP host is assumed to have a table with 32-bit physical addresses, and the flag bits. It has the new separate mail transfer. It probably has a file transfer, but does not use it for mail.
TCPホストが32ビットの物理アドレス、およびフラグビットがあるテーブルを持っていると思われます。 それで、新しい別メールは移されます。 それは、たぶんファイル転送を持っていますが、メールにそれを使用しません。
1. Old-table NCP to Old-table NCP
1. 古いテーブルNCPへの古いテーブルNCP
This transfer is direct and uses the old mechanisms -- NCP and
file transfer.
この転送は、ダイレクトであり、古いメカニズムを使用します--NCPとファイル転送。
2. New-table NCP to Old-table NCP
2. 古いテーブルNCPへの新しいテーブルNCP
This transfer is direct and uses the old mechanisms -- NCP and
file transfer.
この転送は、ダイレクトであり、古いメカニズムを使用します--NCPとファイル転送。
3. TCP to Old-table NCP
3. 古いテーブルNCPへのTCP
This transfer must use a relay server. The first transfer (from
the TCP host to the relay server) is via TCP and the mail transfer
protocol. The second transfer (from the relay server to the
old-table NCP) is via NCP and file transfer protocol.
この転送はリレーサーバを使用しなければなりません。最初の転送(TCPホストからリレーサーバまでの)がTCPとメール転送プロトコルであります。 NCPとファイル転送プロトコルを通して2番目の転送(リレーサーバから古いテーブルNCPまでの)があります。
4. Old-table NCP to New-table NCP
4. 新しいテーブルNCPへの古いテーブルNCP
This transfer is direct and uses the old mechanisms -- NCP and
file transfer.
この転送は、ダイレクトであり、古いメカニズムを使用します--NCPとファイル転送。
5. New-table NCP to New-table NCP
5. 新しいテーブルNCPへの新しいテーブルNCP
This transfer is done with the NCP and the mail transfer protocol,
that is, using the old interprocess communication system and the
new mail transmission scheme.
NCPとメール転送プロトコルでこの転送をします、すなわち、古いプロセス間通信システムを使用して、新しいメール送信は計画されます。
6. TCP to New-table NCP
6. 新しいテーブルNCPへのTCP
This transfer must use a relay server. The first transfer (from
the TCP host to the relay server) is via TCP and the mail transfer
protocol. The second transfer (from the relay server to the
new-table NCP) is via NCP and mail transfer protocol.
この転送はリレーサーバを使用しなければなりません。最初の転送(TCPホストからリレーサーバまでの)がTCPとメール転送プロトコルであります。 2番目の転送(リレーサーバから新しいテーブルNCPまでの)がNCPとメール転送プロトコルであります。
6
6
RFC 771 September 1980
Mail Transition Plan
RFC771 1980年9月のメール変遷プラン
7. Old-table NCP to TCP
7. TCPへの古いテーブルNCP
This transfer must use a special relay server. The first transfer
(from the old-table NCP to the relay server) is via NCP and the
file transfer protocol. The second transfer (from the relay
server to the TCP host) is via TCP and mail transfer protocol.
This relay server must be special because the messages coming from
the old-table NCP host will not have the destination host
information in the command argument. This relay server must have
a list of registered TCP user mailboxes and their associated TCP
host identifiers. Since such a registry could be potentially
large and frequently changing (and will grow as more TCP hosts
come into existence) it will be necessary to limit the mailboxes
on the registry.
この転送は特別なリレーサーバを使用しなければなりません。NCPとファイル転送プロトコルを通して最初の転送(古いテーブルNCPからリレーサーバまでの)があります。 2番目の転送(リレーサーバからTCPホストまでの)がTCPとメール転送プロトコルであります。 古いテーブルNCPホストから来るメッセージがコマンド議論におけるあて先ホスト情報を持たないので、このリレーサーバは特別であるに違いありません。 このリレーサーバには、登録されたTCPユーザメールボックスとそれらの関連TCPホスト識別子のリストがなければなりません。 以来、そのような登録は潜在的に大きいかもしれません、そして、頻繁にそれを変えるのが(そして、より多くのTCPホストが生まれるのに従って、成長するでしょう)、登録のメールボックスを制限するのに必要でしょう。
8. New-table NCP to TCP
8. TCPへの新しいテーブルNCP
This transfer must use a relay server. The first transfer (from
the new-table NCP to the relay server) is via NCP and the mail
transfer protocol. The second transfer (from the relay server to
the TCP host) is via TCP and mail transfer protocol.
この転送はリレーサーバを使用しなければなりません。最初の転送(新しいテーブルNCPからリレーサーバまでの)がNCPとメール転送プロトコルであります。 2番目の転送(リレーサーバからTCPホストまでの)がTCPとメール転送プロトコルであります。
9. TCP to TCP
9. TCPへのTCP
This transfer is direct and uses the new mechanisms -- TCP and the
mail transfer protocol.
この転送は、ダイレクトであり、新しいメカニズムを使用します--TCPとメール転送プロトコル。
In general, whenever possible the new procedures are to be used.
一般に、新しい手順は可能であるときはいつも、使用されていることです。
MULTIPLE RECIPIENTS
複数の受取人
A substantial portion of the mail sent is addressed to multiple recipients. It would substantially cut the transmission and processing costs if such multiple recipient mail were transfered using the multiple recipient technique available for use in both the old file transfer protocol [12] and new mail transfer protocol [9].
送られたメールのかなりの部分が複数の受取人に扱われます。 そのような複数の受取人メールが古いファイル転送プロトコル[12]と新しいメール転送プロトコル[9]の両方における使用に利用可能な複数の受取人のテクニックを使用することでtransferedされるなら、それは実質的にトランスミッションと処理コストを削減するでしょうに。
The relay servers will attempt to use a multiple recipient commands whenever applicable on transmitting messages, and will accept such commands when revceiving messages.
リレーサーバは、メッセージを送るとき適切であるときはいつも、複数の受取人にコマンドを使用するのを試みて、メッセージをrevceivingするとき、そのようなコマンドを受け入れるでしょう。
7
7
September 1980 RFC 771 Mail Transition Plan
1980年9月のRFC771メール変遷プラン
COMPOSITION AND READING PROGRAMS
構成と読み込みプログラム
The impact on the mail composition and reading programs is minimal. If these programs use a table to recognize, complete, or verify host identifiers, then they must be modified to use the new table.
メール構成と読み込みプログラムでの影響は最小限です。 これらのプログラムがホスト識別子について認識するか、完成するか、または確かめるのにテーブルを使用するなら、新しいテーブルを使用するようにそれらを変更しなければなりません。
To assist the user in replying to messages it will be important that all addresses in the header fields (TO:, CC:, etc.) be complete with both the mailbox and host parts. In some cases this has not previously been necessary since the addresses without host parts could be assumed to be local to the originating host, and the sending host was recorded by the receiving host. When the messages were sent directly the originating host was the sending host, but when messages are relayed the originating host will not be the host sending the mail to the destination host.
メッセージに答えるのにユーザを助けるために、ヘッダーフィールド(TO:、CC:など)におけるすべてのアドレスがメールボックスとホストの部品の両方で完全であることは、重要でしょう。 いくつかの場合、ホストの部品のないアドレスが送信元ホストにとって地方であると思うことができて、これは以前に必要ではありません、そして、送付ホストは受信ホストによって記録されました。 直接メッセージを送ったとき、送信元ホストは送付ホストでしたが、メッセージがリレーされるとき、送信元ホストはメールをあて先ホストに送るホストにならないでしょう。
8
8
RFC 771 September 1980
Mail Transition Plan
RFC771 1980年9月のメール変遷プラン
REFERENCES
参照
[1] Cerf, V., "The Catenet Model for Internetworking," IEN 48,
DARPA/IPTO, July 1978.
[1] サーフ、V.、「インターネットワーキングのためのCatenetモデル」、IEN48、DARPA/IPTO、1978年7月。
[2] Postel, J., "Internet Protocol," RFC 760, USC/Information
Sciences Institute, NTIS ADA079730, January 1980.
[2] ポステル、J.、「インターネットプロトコル」、RFC760、科学が設けるUSC/情報、NTIS ADA079730、1980年1月。
[3] Postel, J., "Transmission Control Protocol," RFC 761,
USC/Information Sciences Institute, NTIS ADA082609,
January 1980.
[3] ポステル、J.、「通信制御プロトコル」、RFC761、科学が設けるUSC/情報、NTIS ADA082609、1980年1月。
[4] Postel, J., "Telnet Protocol Specification," RFC 764,
USC/Information Sciences Institute, June 1980.
[4] ポステル、J.、「telnetプロトコル仕様」、RFC764、科学が1980年6月に設けるUSC/情報。
[4] Postel, J., "File Transfer Protocol," RFC 765,
USC/Information Sciences Institute, June 1980.
[4] ポステル、J.、「ファイル転送プロトコル」、RFC765、科学が1980年6月に設けるUSC/情報。
[5] Postel, J., "Assigned Numbers," USC/Information Sciences
Institute, RFC 762, January 1980.
[5] RFC762、ポステル、J.、「規定番号」とUSC/情報科学は設けて、1月は1980です。
[6] Postel, J., "Internet Protocol Handbook," USC/Information
Sciences Institute, RFC 766, July 1980.
[6] RFC766、ポステル、J.、「インターネットプロトコルハンドブック」とUSC/情報科学は設けて、7月は1980です。
[7] Feinler, E. and, J. Postel, "ARPANET Protocol Handbook,"
NIC 7104, Network Information Center, SRI International,
January 1978.
そして、[7]Feinler、E.、J.ポステル、「アルパネットプロトコルハンドブック」、NIC7104、Networkインフォメーション・センター、SRIインターナショナル、1月1978日
[8] Crocker, D., J. Vittal, K. Pogran, and, D. Henderson,
"Standards for the Format of ARPA Network Text Messages,"
RFC 733 7104, Network Information Center, SRI International,
November 1977.
[8] クロッカー、D.、J.Vittal、K.Pogran、D.ヘンダーソン、「アルパの形式の規格はテキスト・メッセージをネットワークでつなぎます」、RFC、733、7104、Networkインフォメーション・センター、SRIインターナショナル(1977年11月)
[9] Sluizer, S. and, J. Postel, "Mail Transfer Protocol,"
USC/Information Sciences Institute, RFC rrr, September 1980.
そして、[9]Sluizer、S.、J.ポステル、「メール転送プロトコル」、USC/情報Sciences Institute、RFC rrr、9月1980日
[10] Postel, J., "Internet Message Protocol," USC/Information
Sciences Institute, RFC 759, August 1980.
[10] RFC759、ポステル、J.、「インターネットメッセージプロトコル」とUSC/情報科学は設けて、8月は1980です。
[11] Postel, J., "A Structured Format for Transmission of
Multi-Media Documents," USC/Information Sciences Institute,
RFC 767, August 1980.
[11] RFC767、ポステル、J.、「マルチメディアドキュメントの伝達のための構造化された形式」とUSC/情報科学は設けて、8月は1980です。
[12] Harrenstien, K., "FTP Extension: XRSQ/XRCP,"
SRI International, RFC 743, December 1977.
[12]Harrenstien、K.、「FTP拡大:」 "XRSQ/XRCP"、SRIインターナショナル、RFC743、1977年12月。
9
9
一覧
スポンサーリンク
