In the long run, it will not be practicable for every internet host to include all internet hosts in its name-address tables. Even now, with over four hundred names and nicknames in the combined ARPANET-DCNET tables, this has become awkward. Some sort of hierarchical name-space partitioning can easily be devised to deal with this problem; however, it has been wickedly difficult to find one compatible with the known mail systems throughout the community. The one proposed here is the product of several discussions and meetings and is believed both compatible with existing systems and extensible for future systems involving thousands of hosts.
長い目で見れば、全ての internet ホストが全ての internet ホストを名前‐ address 表に含めることは実行可能ではないでしょう。現在既に、結合 ARPANET-DCNET 表には400以上の名前と愛称があるので、厄介になっています。何らかの形での階層的な名前空間の分割で、この問題を処理する工夫が簡単に出来ます。しかし、世間中の既知のメイル処理系と互換性を保つのは非常に難しいことです。ここに提案するものは、数度にわたる議論と会合の成果であり、既存の処理系との互換性があって、将来の幾千ものホストを含む処理系への拡張性もあると信じています。
We first observe that every internet host is uniquely identified by one or more 32-bit internet addresses and that the entire system is fully connected. For the moment, the issue of protocol compatibility will be ignored, so that all hosts can be assumed MTP-competent. We next impose a topological covering on the space of all internet addresses with a set of so-called name domains. In the natural model, name domains would correspond to institutions such as ARPA, UCL and COMSAT, and would not be necessarily disjoint or complete. While in principle name domains could be hierarchically structured, we will assume in the following only a single-level structure.
まず始めに、全ての internet ホストは1つ以上の32ビット internet address で比類なく識別され、処理系全体は完全に接続されているとします。さしあたって、プロトコル互換性問題は無視するので、全てのホストが MTP 適合と仮定出来ます。次に全ての internet address をいわゆる名前ドメインの集合で位相的な覆いを被せます。自然モデルでは、名前ドメインは ARPA, UCL, COMSAT のような施設と一致するでしょうから、解体や連結は必要ないでしょう。原則として名前ドメインは階層的に構造化出来るでしょうから、以降では単一階位構造だけを仮定します。
Every name domain is associated with one or more internet processes called mail forwarders and the name of that domain is the name for any of these processes. Each forwarder process for a particular domain is expected to maintain duplicate name-address tables containing the names of all hosts in its domain and, in addition, the name of at least one forwarder process for every other domain. Forwarder processes may be replicated in the interests of robustness; however, the resulting complexities in addressing and routing will not be discussed further here. A particular internet host may support a number of forwarder processes and their collective names represent nicknames for that host, in addition to any other names that host may have. In the following an internet host supporting one or more forwarder proceses will be called simply a forwarder.
各名前ドメインはメイル転送者に呼ばれる一つ以上の internet 処理と関連付けられていて、そのドメインの名前はこれらの処理のいずれもの名前です。特定ドメインへの各転送者処理は、そのドメイン内の全てのホストの名前に加えて最低一つの他のドメインへの転送者処理の名前から成る複製の名前‐ address 表で維持することになっています。転送者処理は頑強性のため繰り返しても構いません。しかし、 address 指定と経路制御の結果複雑性はここでは扱いません。ある internet ホストは、幾つもの転送者処理とそのホストの愛称を表す集成名, 更にそのホストが持ち得る他の名前に対応して構いません。続いて1つ以上の転送者処理に対応した internet ホストが単に転送者を呼ぶでしょう。
Every host is expected to maintain name-address tables including the names of at least one forwarder for every domain together with additional hosts as convenient. A host may belong to several domains, but it is not necessary that all hosts in any domain, be included in its tables. Following current practice, several nicknames may be associated with the principal name of a host in any domain and these names need not be unique relative to any other domain. Furthermore, hosts can be multi-homed, that is, respond to more than one address. For the purpose of mail forwarding and delivery, we will assume that any of these addresses can be used without prejudice. The use of multi-homing to facilitate source routing is a topic for future study.
全ホストはその名前と最低一つの転送者をあると都合の良い追加のホストと共に含めた名前‐ address 表を維持することになります。あるホストは複数のドメインに所属出来ますが、すべてのホストがその表に含まれている必要はありません。現在の慣習に従い、幾つかの愛称をどのドメインのホストの原則名に関連付けて構いませんし、この名前が他のドメインも含めて独特である必要はありません。なお、ホストは multi-home であることが出来ます。つまり、複数の address に反応することが出来ます。メイル転送・配送目的で、この address のうちのいずれかが不利益無しに利用可能と仮定します。始点経路制御促進のため multi-home で使用することは将来の課題とします。
In its most general form, a standard internet mailbox name has the syntax
非常に一般的な形では、標準 internet メイル箱名は次の様な構文になります。
where <user> is the name of a user known at the host <host> in the name domain <domain>. This syntax is intended to suggest a three-level hierarchically structured name (reading from the right) which is unique throughout the internet system. However, hosts within a single domain may agree to adopt another structure, as long as it does not conflict with the above syntax and as long as the forwarders for that domain are prepared to make the requisite transformations. For instance, let the name of a domain including DCNET be COMSAT and the name of one of its hosts be COMSAT-DLM with Mills a user known to that host. From within the COMSAT domain the name Mills@COMSAT-DLM uniquely identifies that mailbox as could, for example, the name Mills.COMSAT-DLM@COMSAT from anywhere in the internet system. However, Mills@COMSAT-DLM is not necessarily meaningful anywhere outside the COMSAT domain (but it could be).
ここで <user> は名前ドメイン <domain> のホスト <host> の利用者の名前です。この構文は internet 体系内で独特である3段階階層化構造名 (右から読む) を提唱するということです。しかし、単一ドメイン内のホストは、上記構文と衝突しない限り、また必要な変形を施す当該ドメイン用転送者が準備される限り、他の構造を採用しても構いません。例えば、 DCNET を含むドメインの名前を COMSAT とし、その中のホストの一つの名前を COMSAT-DLM とし、そのホストに利用者 Millds がいるとします。 COMSAT ドメイン中からは、名前 Mills@COMSAT-DLM はそのメイル箱を唯一に識別することが出来、名前 Mills.COMSAT-DLM@COMSAT は internet 体系のどこからでも出来ます。しかし、 Mills@COMSAT-DLM は COMSAT ドメインの外のいずこにおいても意味を持っている必要はありません (持たせることはできます)。
A typical set of name domains covering the current internet system might include ARPA (ARPANET), COMSAT (DCNET), DCA (EDNET, WBNET), UCL (UCLNET, RSRENET, SRCNET), MIT (CHAOSNET), INTELPOST (INTELPOSTNET) and the various public data networks. The ARPA forwarder would use a name-address table constructed from the latest version of the HOSTS.TXT table in the NIC data base. The other forwarders would construct their own, but be expected to deposit a copy in the NIC data base.
現在の internet 体系を覆う名前ドメインの典型的集合は、
ARPA (ARPANET), COMSAT (DCNET), DCA (EDNET,
WBNET), UCL (UCLNET, RSRENET, SRCNET), MIT (CHAOSNET), INTELPOST
(INTELPOSTNET), 各種公的データ網を含むのが良いでしょう。
ARPA 転送者は
NIC データベースの HOSTS.TXT
表の最新版から構築した名前‐ address 表を使いましょう。
In the interests of economy and simplicity, it is expected that the bulk of all mail transport in the internet system will take place directly from originator to recipient host and without intermediate relay. A technique of caching will probably be necessary for many hosts in order to reduce the traffic with forwarders merely to learn the internet address associated with a correspondent host. This naturally encourages naming strategies designed to minimize duplicate names in the various domains; however, such duplicates are not forbidden.
質素倹約のために、 internet 体系内の全てのメイル転送の bulk は発信者から受信ホストに中継なしに直接しましょう。転送者に、単に通信ホストに関連付けられた internet address を覚えておく cache の技術がおそらく、混雑を減らすために多くのホストに必要でしょう。これは当然各ドメイン中の名前の重複を最小化するように設計した命名戦略を推奨することになります。しかし、この重複は禁止はしません。
There are several reasons why some messages will have to be staged at an intermediate relay, among them the following:
メッセージが中継を経なければならない理由が次に挙げる様にいくつかあります。
It may not be possible or convenient for the originator and recipient hosts to be up on the internet system at the same time for the duration of the transfer.
発信・受信ホストが同時刻に internet 体系で転送の間稼動していないといけないのは可能でないか不便である。
The originator host may not have the resources to perform all name-address translations required.
発信ホストは必要な全ての名前‐ address 対応を持つ資源が無いかもしれない。
A direct-connection path may not be feasible due to regulatory economic or security constraints.
直接接続経路が経済上または安全上規制されていて利用出来ないかもしれない。
The originator and recipient hosts may not recognize the same lower-level transport protocol (e.g. TCP and NCP).
発信・受信ホストが同じ低水準転送プロトコルを認知しないかもしれない (例えば TCP と NCP)。
A mail relay is an internet process equipped to store an MTP message for subsequent transmission. A mail forwarder is a mail relay, but not all relays are forwarders, since they might not include the full name-address capability required of forwarders. In addition, relays may not be competent in all domains. For instance, a MTP/TCP relay may not understand NCP. In other words, the forwarders must be fully connected, but the relays may not.
メイル中継は、後続転送のための MTP メッセージを蓄える必要のある internet 処理です。メイル転送者はメイル中継者ですが、 全ての中継者が転送者ではありません。転送者の完全名前‐ address 能力要件を含んでいないからです。また、中継者は全てのドメインで有能ではないかもしれません。例えば、 MTP/TCP 中継は NCP を理解しません。言い換えれば、転送者は完全に接続されていなければなりませんが、中継者はそうではありません。
The particular sequence of relays traversed by a message is determined by the sender by means of the source route specification in the MRCP command. There are several implications to this:
メッセージが通り抜ける特定の中継列は、送信者により MRCP 命令の始点経路指定で決定されます。これには幾つかの係わり合いがあります。
Advisory messages returned to the originator by a relay or recipient host are expected to traverse the route in reverse order.
中継または受信ホストから発信者に返される勧告メッセージは、経路を逆順で通ることが期待される。
Relay host names follow the same naming convention as all host names relative to their domain. Since it may not be possible (see below) to use internet addresses to dis-ambiguate the domain, the complete standard internet name .<host>@<domain> is required everywhere.
中継ホスト名は、そのドメインに関係のある全てのホスト名と同じ命名規約に従う。 internet address を dis-ambiguate なドメインに使うのは不可能 (下記参照) ので、完全な標準 internet 名 .<host>@<domain> が全ての場所で必須です。
There is no current provision for strict/loose route specifications. If, in fact, the "ordinary" host specification @<host> were used, each relay or forwarder would use the rules outlined in the next section for routing. This may result in additional relay hops.
厳格/適当な経路指定が現在供給されていない。実際、「普通の」 ホスト指定 @<host> が使われていたなら、各中継者や転送者は、次の節で概説する規則を使っていましょう。これは中継ホップ数を増やす結果になるかもしれません。
This section describes a likely scenario involving hosts, relays and forwarders and typical internet routes. When a forwarder receives a message for <user>.<host>@<domain>, it transforms <host> if necessary and forwards the message to its address found in the name-address table for <domain>. Note that a single host can be a forwarder for several independent domains in this model and that these domains can intersect. Thus, the names Mills@USC-ISIE, Mills.USC-ISIE@ARPA and Mills.USC-ISIE@COMSAT can all refer to the same mailbox and the names USC-ISIE, ARPA and COMSAT can, conceivably, all be known in the same domain. Such use would be permissable only in case the name USC-ISIE did not conflict with other names in this domain.
この章では、ホスト, 中継者, 転送者, それに典型的な internet 経路を含めた 適当な筋書きを説明します。転送者が <user>.<host>@<domain> への メッセージを受信した時、必要なら <host> を変換して、 メッセージを <domain> の名前‐ address 表に見える address に転送します。 単一のホストがこのモデルでは幾つかの独立したドメインの転送者に なり得て、各ドメインは交叉し得ることに注意して下さい。 ですから、名前 Mills@USC-ISIE, Mills.USC-ISIE@ARPA, Mills.USC-ISIE@COMSAT は全て同じメイル箱を参照し得て、名前 USC-ISIE, ARPA, COMSAT はおそらく全て、同じドメイン中にあるとし得ます。こうした使用は、 名前 USC-ISIE がこのドメイン中の他の名前と衝突しない場合に限って 認められます。
In order for this scheme to work efficiently, it is desireable that messages transiting forwarders always contain standard internet mailbox names. When this is not feasible, as in the current ARPANET mail system, the forwarder must be able to determine which domain the message came from and edit the names accordingly. This would be necessary in order to compose a reply to the message in any case.
この方式が能率的に動くように、メッセージを輸送する転送者は 常に標準 internet メイル箱名を含むのが望ましいです。 これが出来無い場合、現在の ARPANET メイル処理系のように、 転送者はメッセージが来たドメインを決定し、それに従って 名前を編集出来なければなりません。これはメッセージへの返信を 構成するためにはどんな場合でも必要なことでしょう。
In the RFC-780 model a message arriving at a forwarder is processed by the MTP server there. The server extracts the first entry in the recipient-route field of an MRCP command. There are two cases, depending on whether this entry specifies a domain name or a host name. If a domain name, as determined by a search of a universal table, it refers to one of the domains the server represents. If not, it must a name or nickname of the server's host relative to ooe of the domains to which the sender belongs. This allows a distinction to be made between the domains COMSAT and INTELPOST on one hand and the COMSAT host COMSAT-PLA on the other, all of which might be represented by the same internet address, and implies that domain names must be unique in all domains.
RFC 780 モデルでは、転送者に届いたメッセージはそこの MTP サーバーで処理します。サーッバーは、 MRCP 命令の 受信者経路欄の最初の項目を取り出します。この項目にドメイン名が 指定されているかホスト名が指定されているかで、2つの場合に分けます。 ドメイン名の場合、 universal 表の検索で決定するので、 これはサーバーが代表するドメインの一つを参照します。 そうでない場合、これは送信者が属するドメインの一つと関係のあるサーバーのホストの名前か愛称でなければなりません。これにより、一方でドメイン COMSAT と INTELPOST の区別が、他方では COMSAT ホスト COMSAT-PLA の区別が、 これらの全てが同じ internet address で表現されるとしても、 全てのドメインのドメイン名が独特であると仮定した時、 区別することが出来ます。
The server next extracts the second entry in the recipient-route field of the MRCP command and resolves its address relative to the domain established by the first entry. If the second entry specifies an explicit domain, then that overrides the first entry. If not and the first entry specifies a domain, then that domain is effective. However, if the first entry specifies the server's host, it may not be apparent which domain is intended. For instance, consider the following two MRCP commands:
サーバーは次に、 MRCP 命令の受信者経路欄の第2 entry を取り出して、 最初の項目で確立したドメインとの address 関係を解決します。 第2項目がドメインを明示して指定されていた場合、最初の項目を 上書きします。そうでなくて最初の項目にドメインが指定してある場合、 そのドメインが有効になります。しかし、最初の項目がサーバーのホストを 指定している場合、どのドメインを意図しているのか明確でないかもしれません。 例えば、次の2つの MRCP 命令を考えてみましょう。
where Mills.HOST@COMSAT and Mills.HOST@INTELPOST are distinct mailboxes on different hosts. A receiving host supporting forwarders for both COMSAT and INTELPOST can then preserve this distinction and forward correctly using the above rules.
ここで、 Mills.HOST@COMSAT と Mills.HOST@INTELPOST は異なるホストの別個のメイル箱とします。 COMSAT と INTELPOST の双方への転送者を持つ受信したホスト は、上記の規則を使って正しくこの区別を保持し, 転送することが出来ます。
Now let the forwarder host have the name FORWARDER in both the COMSAT and INTELPOST domains and consider its options when receiving the command
いま、転送者ホストが名前 FORWARDER を COMSAT と INTERPOST 両ドメインに 持っていて、次の命令を受信した時を考えてみましょう。
The forwarder is being asked simply to relay within the domain of the sender; however, it belongs to more than one domain! The obvious way to resolve this issue would be to forbid the use of implicit domains, as represented by Mills@HOST, and require the full internet mailbox names Mills.HOST@COMSAT or Mills.HOST@INTELPOST. It is also possible to dis-ambiguate the domain by inspecting the first entry of the sender-route field of the MAIL command (see below).
転送者は単に送信者のドメインの中に中継することを求められています。 しかし、こいつは複数のドメインに属しています! この問題を解決する明らかな方法は、 Mills@HOST のような暗黙ドメインの使用を禁止して、 Mills.HOST@COMSAT か Mills.HOST@INTELPOST のように完全 internet メイル箱を使用することを必須とすることでしょう。 また、 MAIL 命令の送信者経路欄の最初の項目 (下記参照) を調べることで dis-ambiguate するのも可能でしょう。
In the RFC-780 model, routes can be specified in the recipient-route field of the MRCP command and in the sender-route field of the MAIL command. In point of fact, neither the recipient-route or sender-route is necessary if the originator specifies standard internet mailbox names. So long as the routes, when used, consist only of domain names, there is no conflict with the current RFC-780 specification. If for some reason forwarding must be done via other hosts, then the use of a complete and unambigous syntax like .<host>@<domain> is required in order to avoid problems like that described above.
RFC 780 モデルでは、経路は MRCP 命令の受信者経路欄と MAIL 命令の送信者経路欄に指定できます。実際は、 受信者経路も送信者経路も、発信者が標準 internet メイル箱命を 指定していれば必要ありません。経路が使われている場合に ドメイン名のみで成っている限りにおいては、現行の RFC 780 仕様とは衝突しません。何らかの理由で転送が他のホストを経て 行われた場合は、 .<host>@<domain> のような完全で曖昧でない構文が、 上で説明したような問題を避けるために必要です。
The present RFC-780 specification requires the receiver to construct a name for the sender and insert this at the beginning of the sender-route. Presumably, the only information it has to construct this name is the internet address of the sender. Consider the case, as in the example above, where multiple domains are supported by a single server on a particular host. If hosts receiving a message relayed via that server were to map its address into a name, there would be no way to determine which domain was intended. We conclude that the sending host must update the sender-route as well as the recipient-route. It does this simply by copying the first entry in the recipient-route as received as the new first entry in the sender-route.
現行の RFC 780 の仕様では、受信者が送信者の名前を組み立て、 送信者経路の始めにこれを挿入する必要があります。おそらく、 この名前を組み立てる唯一の情報は送信者の internet address でしょう。 上の例のように、複数のドメインが特定ホストの単一サーバーで 支えられている場合を考えてみて下さい。そのサーバーで中継された メッセージを受信したホストがその address を名前に対応させる時に、 どのドメインを意図していたのか判断する方法はないでしょう。 ですから、送信するホストは受信者経路同様に送信者経路をも 更新しなければならないと結論付けられます。受信者経路の最初の項目を受信したまま送信者経路の最初の項目に複写することで簡単に出来ます。
Every effort should be made to avoid editing the RFC-733 header, since this is an invasive procedure requiring extensive analysis. It is expected that newly developed mail systems will be aware of the standard internet mailbox syntax and ensure its use everywhere in the RFC-733 and RFC-780 fields. On the occasions where this is not possible, such as in many current ARPANET hosts, the necessary editing should be performed upon first entry to the internet mail system from the local mail system. This avoids the problems mentioned above and simplifies reply functions.
RFC 733 頭を編集することは避けるように最大限の努力を払うべきでしょう。 なぜなら、これは広範囲の分析を要する侵略的処理だからです。 新たに開発されるメイル処理系は、標準 internet メイル箱構文に 注意を払い、 RFC 733 と RFC 780 の欄のどこにおいても これを使うことを確実にすることが期待されます。 これが可能でない場合、例えば多くの現在の ARPANET ホストでは、 必要な編集を局地メイル処理系から internet メイル処理系へ 最初の項目に施すべきです。これによって上で述べた問題が避けられ、 返信機能が簡単になります。
In the case of ARPANET hosts, the editing operations assume that all names in the form <anything>@<domain>, where <domain> is the name of a domain, are unchanged. Names in the form <anything>@<host>, where <host> is the name of a host in the ARPA domain, are transformed to the form <anything>.<host>@ARPA. Anything else is an error. Before handing off to an ARPANET NCP mailer, an ARPA MTP forwarder might optionally transform <anything>.<host>@ARPA to <anything>@<host> in order to reduce the forwarder traffic when local mail systems are available. Similar situations might exist elsewhere.
ARPANET ホストの場合、編集処理は、 <anything>@<domain> (<domain> はドメインの名前。) の形式の全ての名前は変更しないとします。 <anything>@<host> (<host> は ARPA ドメイン中のホストの名前。) の形式の名前は <anything>.<host>@ARPA の形式に変換します。 他のものは誤りです。 ARPANET NCP mailer に手渡す前に、 ARPA MTP 転送者は <anything>.<host>@ARPA から <anything>@<host> に、局地メイル処理系が利用可能な時に転送者の混雑を減らすために、 任意で変換しても構いません。同様の状況は他の場所でもあるかもしれません。
This memorandum is intended to stimulate discussion, not simulate it.
この覚書は議論を刺激せんとするものであって、それを擬態しようとする ものではありません。
この翻訳文は、自由に複製・配布・改変して構いません。 (rfc-copyright-story も参照して下さい。)