RFC799 日本語訳

Network Working Group                                     D. L. Mills
Request for Comments:  799                        COMSAT Laboratories
                                                       September 1981

L.工場がコメントのために要求するワーキンググループD.をネットワークでつないでください: 799 コムサット研究所1981年9月

	                   Internet Name Domains

インターネット名前ドメイン

1.  Introduction

1. 序論

     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.

結局、すべてのインターネットホストが名前アドレス・テーブルのすべてのインターネットホストを入れるのは、実用的でないでしょう。 今でも、400以上の名前とあだ名が結合したアルパネット-DCNETテーブルにある状態で、これは無器用になりました。 この問題に対処するために容易にある種の階層的な名前スペース仕切りについて工夫できます。 しかしながら、1つは共同体中の知られているメールシステムと互換性があるのがわかるのが意地悪く難しいです。 ここで提案されたのは、いくつかの議論とミーティングの成果であり、既存のシステムと互換性があって、かつ何千人ものホストにかかわる将来のシステムにおいて広げることができると信じられています。

2.  General Topology

2. 一般トポロジー

     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.

私たちは、最初に、すべてのインターネットホストが1つ以上の32ビットのインターネットアドレスによって唯一特定されて、全体のシステムが完全に接続されるのを観測します。 さしあたり、プロトコルの互換性の問題は、MTP有能であるとすべてのホストを思うことができるように無視されるでしょう。 私たち、次は1セットのいわゆる名前ドメインですべてのインターネットアドレスのスペースに位相的な覆いを課します。 名前ドメインは、生まれながらのモデルでは、ARPAや、UCLやコムサットなどの団体に対応しているだろう、必ずばらばらになることでないでしょう。完全。 原則として階層的で名前ドメインを構造化できた間、私たちは以下だけでただ一つのレベル構造を仮定するつもりです。

     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.

あらゆる名前ドメインがメール混載業者と呼ばれる1つ以上のインターネットの過程に関連しています、そして、そのドメインの名前は名前ですこれらの過程のどんなも。 他のあらゆるドメインへのすべてのドメインのホストとさらに、少なくとも1つの混載業者の過程の名前の名前を含んでいて、特定のドメインへのそれぞれの混載業者の過程が写し名前アドレス・テーブルを維持すると予想されます。 混載業者の過程は丈夫さのために模写されるかもしれません。 しかしながら、ここでさらにアドレシングとルーティングにおける結果として起こる複雑さについて議論しないでしょう。 特定のインターネットホストは多くの混載業者の過程を支持するかもしれません、そして、それらの集合名はそのホストのためにあだ名を表します、ホストが持っているかもしれないいかなる他の名前に加えて。 以下の1混載業者procesesを支持しているインターネットホストは単に混載業者と呼ばれるでしょう。

     Every host is expected to maintain name-address tables including
the names of at least one forwarder for every

すべてのホストが少なくとも1の名前を含む名前アドレス・テーブル混載業者を維持すると予想される、あらゆる


Internet Name Domains                               PAGE   2

インターネット名前ドメイン2ページ

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.

便利であるとしての追加ホストに伴うドメイン。 ホストはいくつかのドメインに属すかもしれませんが、すべてがいずれでもドメインを接待するのは必要でなく、テーブルで含められてください。 順流習慣、いくつかのあだ名がどんなドメインでもホストの主要な名前に関連しているかもしれません、そして、これらの名前はいかなる他のドメインに比例してユニークである必要はありません。 その上、ホストがそうであることができる、マルチ、家へ帰り、すなわち、1つ以上のアドレスまで応じてください。 メール転送と配送の目的のために、私たちは、偏見なしでこれらのアドレスのどれかを使用できると思うつもりです。 ソースルーティングを容易にするマルチホーミングの使用は今後の研究への話題です。

3.  Naming Conventions

3. 命名規則

     In its most general form, a standard internet mailbox name has
the syntax

最も一般的なフォームでは、標準のインターネットメールボックス名は構文を持っています。

                  <user>.<host>@<domain> ,

<ユーザ><ホスト>@<ドメイン>。

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).

<ユーザ>がホスト<で知られているユーザの名前であるところでは、名前ドメイン<ドメイン>で>を接待してください。 この構文がインターネットシステム中でユニークな階層的で構造化された3レベルの名前(右から、読む)を示すことを意図します。 しかしながら、単一領域の中のホストは、別の構造を採用するのに同意するかもしれません、そのドメインへの混載業者が必要な変化をする用意ができているとき上の同じくらい構文で同じくらい長い状態で衝突しない限り。 例えば、ミルズがいるコミュニケーションサテライトコーポレーション-DLMがそのホストにとって知られているユーザであったなら、ドメインがDCNETを含む名前がホストのひとりのコムサットと名前であることをさせてください。 コミュニケーションサテライトコーポレーションドメインから、 Mills@COMSAT-DLM という名前は例えば、 Mills.COMSAT-DLM@COMSAT という名前であることができたことのようにそのメールボックスを唯一インターネットシステムでどこからでも特定します。 しかしながら、 Mills@COMSAT-DLM は必ずコミュニケーションサテライトコーポレーションドメインの外でどこでも重要であるというわけではありません(それはそうであるかもしれません)。

     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.

現在のインターネットシステムをカバーする典型的なセットの名前ドメインはARPA(アルパネット)、コムサット(DCNET)、DCA(EDNET、WBNET)、UCL(UCLNET、RSRENET、SRCNET)、MIT(CHAOSNET)、インテルポスト(INTELPOSTNET)、および様々な公衆データネットワークを含むかもしれません。 ARPA混載業者はNICデータベースの中でHOSTS.TXTテーブルの最新版から組み立てられた名前アドレス・テーブルを使用するでしょう。 他の混載業者はそれら自身のを組み立てるでしょうが、NICデータベースにコピーを預けると予想されてください。

4.  Mail Transport Principles

4. 輸送プリンシプルズに郵送してください。

     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

経済と簡単さのために、インターネットシステムのすべてのメール輸送の大半が直接創始者から受取人まで行われると予想されます。


Internet Name Domains                               PAGE   3

インターネット名前ドメイン3ページ

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.

接待して、中間介在物リレーします。 キャッシュのテクニックは、単に通信員のホストに関連しているインターネットアドレスを学ぶために混載業者と共に交通を抑えるためにたぶん多くのホストに必要になるでしょう。 これは、様々なドメインで写し名を最小にするように設計された戦略を命名するよう自然に奨励します。 しかしながら、そのような写しは禁じられません。

     There are several reasons why some messages will have to be
staged at an intermediate relay, among them the following:

いくつかのメッセージが中間的リレー、それらの中で以下で上演されなければならないいくつかの理由があります:

1.  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.

1. 転送の持続時間において、創始者と受取人ホストが同時にインターネットシステムの上で起きているのは、可能であるか、または便利でないかもしれません。

2.  The originator  host  may  not  have  the  resources  to
    perform all name-address translations required.

2. 創始者ホストには、名前アドレス変換が必要としたすべてを実行するリソースがないかもしれません。

3.  A direct-connection path may  not  be  feasible  due  to
    regulatory economic or security constraints.

3. ダイレクト接続道は経済かセキュリティの規定の規制のために可能でないかもしれません。

4.  The originator and recipient hosts may not recognize the
    same lower-level transport protocol (e.g.  TCP and NCP).

4. 創始者と受取人ホストは同じ低レベルトランスポート・プロトコル(例えば、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メッセージを格納するために備えていたインターネットの過程です。 メール混載業者はメール中継ですが、すべてのリレーが混載業者であるというわけではありません、彼らが混載業者に必要である完全な名前アドレス能力を含まないかもしれないので。 さらに、リレーはすべてのドメインで有能でないかもしれません。 例えば、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コマンドにおける送信元経路仕様によって送付者によって決定されます。 これへのいくつかの含意があります:

1.  Advisory messages returned to the originator by a relay
    or recipient host are expected to traverse the route in
    reverse order.

1. リレーか受取人ホストによって創始者に返された顧問メッセージが逆順でルートを横断すると予想されます。

2.  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.

2. リレーホスト名は、すべてがそれらのドメインに比例して名前をホスティングしながらコンベンションを命名しながら、同じくらい続きます。 それが可能でないかもしれないので(以下を見てください)、ドメイン(完全な標準のインターネット名)<ホスト>@<ドメイン>のあいまいさを除くインターネットアドレスを使用するのがいたる所で必要です。

3.  There is no current  provision  for  strict/loose  route
    specifications.    If,  in  fact,  the  "ordinary"  host
    specification @<host> were used, each relay or forwarder

Internet Name Domains                               PAGE   4

3. 厳しいかゆるいルート仕様へのどんな現在の支給もありません。 それぞれの事実上、「普通」のホスト仕様@<ホスト>は使用されたか、そして、リレーか混載業者インターネットName Domains4ページ

    would  use  the  rules  outlined in the next section for
    routing.  This may result in additional relay hops.

ルーティングのために次のセクションで概説された規則を使用するでしょう。 これは追加リレーホップをもたらすかもしれません。

5.  Forwarder Operations

5. 混載業者Operations

     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.

このセクションはホスト、リレー、および混載業者を伴うありそうなシナリオと典型的なインターネットルートを説明します。 混載業者が<ユーザ><ホスト>@<ドメイン>にメッセージを受け取るとき、それは、名前アドレス・テーブルで<ドメイン>に見つけられたアドレスに、必要なら、<ホスト>を変えて、メッセージを転送します。 独身のホストがこのモデルのいくつかの独立しているドメインへの混載業者であるかもしれなく、これらのドメインが横切られることができることに注意してください。 したがって、名前の Mills@USC-ISIE 、Mills.USC-ISIE@ARPA、および Mills.USC-ISIE@COMSAT は同じメールボックスについてすべて言及できます、そして、多分同じドメインでUSC-ISIEという名前、ARPA、およびコムサットは皆、知ることができます。 単にUSC-ISIEという名前がこのドメインで他の名前と衝突しないといけなかったので、そのような使用はpermissableでしょう。

     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.

効率的に扱うこの計画において整然とします、混載業者を通過するメッセージがいつも標準のインターネットメールボックス名を含むのは、「望-可能」です。 これが現在のアルパネットメールシステムのように可能でないときに、混載業者は、メッセージがどのドメインから来たかを決定して、それに従って、名前を編集できなければなりません。 これが、どのような場合でも、回答をメッセージに構成するのに必要でしょう。

     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つのケースがあります。 ドメイン名であるなら、普遍的なテーブルの検索で決定するように、それはサーバが表すドメインの1つを参照します。 そうでなければ、それは送付者が属するドメインのooeに比例したサーバのホストの名前かあだ名がそうしなければなりません。 これで、区別は片手の上のドメインコミュニケーションサテライトコーポレーションとインテルポストともう片方のコムサットのホストコミュニケーションサテライトコーポレーション-PLAの間でします。同じインターネットアドレスによって表されるかもしれません。それは、そのすべてが、ドメイン名がすべてのドメインでユニークであるに違いないことを含意します。

     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:

Internet Name Domains                               PAGE   5

次のサーバは、MRCPコマンドの受取人ルート分野で2番目のエントリーを抽出して、初記入で確立されたドメインに比例してアドレスを決議します。 2番目のエントリーが明白なドメインを指定するなら、それは初記入をくつがえします。 そうでなければ、そして、初記入はドメインを指定して、そして、ドメインは有効です。 しかしながら、初記入がサーバのホストを指定するなら、どのドメインが意図するかは、明らかでないかもしれません。 例えば、以下の2つのMRCPコマンドを考えてください: インターネット名前ドメイン5ページ

MRCP to:<@COMSAT,Mills@HOST> and 
MRCP to:<@INTELPOST,Mills@HOST> ,

MRCP to:<@COMSAT (工場@HOST>とMRCP to:<@INTELPOST )は@HOST>を製粉します。

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が異なったホストの上の異なったメールボックスであるところ。 そして、コムサットとインテルポストの両方のために混載業者を支持している受信ホストは、正しく上の規則を使用することでこの区別とフォワードを保持できます。

     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という名前を持って、コマンドを受け取るとき、オプションを考えさせてください。

MRCP to:<@FORWARDER,Mills@HOST> .

MRCP to:<@FORWARDER 、工場@HOST>。

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).

混載業者は送付者のドメインの中で単にリレーする尋ねることにされます。 しかしながら、それは1つ以上のドメインに属します! この問題を解決する当たり前の方法は、 Mills@HOST によって表されるように暗黙のドメインの使用を禁じて、@INTELPOSTという完全なインターネットメールボックス名の Mills.HOST@COMSAT かMills.HOSTを必要とするだろうことです。また、メールコマンドの送付者ルート分野の初記入を点検することによってドメインのあいまいさを除くのも可能です(以下を見てください)。

6.  Source and Return Routing

6. ソースとリターンルート設定

     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コマンドの受取人ルート分野とメールコマンドの送付者ルート分野でルートを指定できます。 事実上、創始者が標準のインターネットメールボックス名を指定するなら、受取人ルートも送付者ルートも必要ではありません。 使用されるとルートがドメイン名だけから成る限り、現在のRFC-780仕様との闘争が全くありません。 他のホストを通してある理由で推進しなければならないなら、上で説明されたそのような問題を避けるために. <ホスト>@<ドメイン>のような完全、そして、unambigous構文の使用を必要とします。

     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.

Internet Name Domains                               PAGE   6

現在のRFC-780仕様は、送付者のために名前を構成して、送付者ルートの始めにこれを挿入するために受信機を必要とします。 おそらく、それがこの名前を構成するために持っている唯一の情報がインターネット送信者のアドレスです。 ケースを考えてください、上記の例のように。そこでは、複数のドメインが特定のホストの上でただ一つのサーバによって支持されます。 そのサーバでリレーされたメッセージを受け取るホストがアドレスを名前に写像するなら、どのドメインが意図したかを決定する方法が全くないでしょうに。 私たちは、送付ホストが受取人ルートと同様に送付者ルートをアップデートしなければならないと結論を下します。 それは、単に新しい初記入として送付者ルートに受け取るように受取人ルートに初記入をコピーすることによって、これをします。 インターネット名前ドメイン6ページ

7.  Editing the RFC-733 Header

7. RFC-733ヘッダーを編集します。

     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ヘッダーを編集するのを避けるのをあらゆる努力をするべきです。 新たに開発されたメールシステムが標準のインターネットメールボックス構文を意識していて、RFC-733とRFC-780分野のいたる所で使用を確実にすると予想されます。 時に、これが多くの現在のアルパネットホストなどのように可能でないところで必要な編集はローカルのメールシステムからインターネットメールシステムへの初記入に実行されるべきです。 これは、前記のように問題を避けて、回答機能を簡素化します。

     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.

アルパネットホストの場合では、編集操作はすべてがフォーム<で<ドメイン>がドメインの名前である>@<ドメイン>と何でも命名して、変わりがないと仮定します。 フォーム<で>@<ホスト>と何でも命名して、 form <anything>.<host>@ARPA に変えられます。(そこでは、<ホスト>がARPAドメインのホストの名前です)。 他の何かが誤りです。 アルパネットNCP郵送者に下に、ARPA MTP混載業者が任意にそうするかもしれない手渡す前、 transform <anything>.<host>@ARPA 、lt;、何、でもgt;、@<は、ローカルのメールシステムが利用可能であるときに、混載業者交通を抑えるために>を接待します。 同様の状況はほかの場所に存在するかもしれません。

8.  Concluding Remarks

8. 結びの言葉

     This memorandum is intended to stimulate discussion, not simulate
it. 
-------

このメモがそれをシミュレートするのではなく、議論を刺激することを意図します。 -------