RFC1711 日本語訳
1711 Classifications in E-mail Routing. J. Houttuin. October 1994. (Format: TXT=47584 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Houttuin Request for Comments: 1711 RARE Category: Informational October 1994
Houttuinがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 1711年のまれなカテゴリ: 情報の1994年10月
Classifications in E-mail Routing
メールルート設定における分類
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
This paper presents a classification for e-mail routing issues. It clearly defines commonly used terminology such as static routing, store-and-forward routing, source routing and others. Real life examples show which routing options are used in existing projects.
この紙はメールルーティング問題のための分類を提示します。 それが明確にスタティックルーティングなどの一般的に使用された用語、店とフォワードルーティングを定義して、ソースは、ルーティングと他のものです。 実例は、どのルーティングオプションが既存のプロジェクトに使用されるかを示します。
The goal is to define all terminology in one reference paper. This will also help relatively new mail system managers to understand the issues and make the right choices. The reader is expected to already have a solid understanding of general networking terminology.
目標は1つの参照箇所の紙のすべての用語を定義することです。 また、これは、比較的新しいメールシステム・マネージャが問題を理解して、正しい選択をするのを助けるでしょう。 読者には一般的なネットワーク用語の確実な理解が既にあると予想されます。
In this paper, the word Message Transfer Agent (MTA) is used to describe a routing entity, which can be an X.400 MTA, a UNIX mailer, or any other piece of software performing mail routing functions. An MTA processes the so called envelope information of a message. The term User Agent (UA) is used to describe a piece of software performing user related mail functions. It processes the contents of a message's envelope, i.e., the header fields and body parts.
この紙では、単語Message Transferエージェント(MTA)は、ルーティング実体について説明するのに使用されます。(実体はX.400 MTAであるかもしれません(メール経路選択機能を実行するUNIX郵送者、またはいかなる他のソフトウェア))。 MTAはメッセージのいわゆる封筒情報を処理します。 Userというエージェント(UA)がソフトウェア一本の働いているユーザについて説明するのに使用される用語はメール機能を関係づけました。 それはすなわち、メッセージの封筒、ヘッダーフィールドと身体の部分のコンテンツを処理します。
Table of Contents
目次
1. Naming, addressing and routing 2 2. Static versus dynamic 4 3. Direct versus indirect 5 3.1. Firewalls 5 3.2. Default versus rule based 6 4. Routing at user level 7 4.1. Distributed domains 7 4.2. Shared MTA 8 5. Routing control 9 6. Bulk routing 9 7. Source routing 11 8. Poor man's routing 12 9. Routing communities 12
1. 2 2を命名して、記述して、発送します。 ダイナミックな4 3に対して静的です。 間接的な5に対してダイレクトな3.1。 ファイアウォール5 3.2。 デフォルト対規則は6 4を基礎づけました。 ユーザレベル7 4.1では、掘ります。 分配されたドメイン7 4.2。 共有されたMTA8 5。 コントロール9 6を発送します。 ルーティング9 7を膨らませてください。 ソースルーティング11 8。 貧者のルーティング12 9。 ルート設定共同体12
Houttuin [Page 1] RFC 1711 Classifications in E-mail Routing October 1994
1994年10月に掘られるメールにおけるHouttuin[1ページ]RFC1711分類
10. Realisations 14 10.1. Internet mail 14 10.2. UUCP 15 10.3. EARN 15 10.4. GO-MHS 15 10.5. ADMD infrastructure 15 10.6. Long Bud 16 10.7. X42D 16 11. Conclusion 16 12. Abbreviations 17 13. References 17 14. Security Considerations 19 15. Author's Address 19
10. Realisations14 10.1。 インターネット・メール14 10.2。 UUCP15 10.3。 15 10.4を得てください。 碁-MHS15 10.5。 ADMDインフラストラクチャ15 10.6。 長い芽16 10.7。 X42D16 11。 結論16 12。 略語17 13。 参照17 14。 セキュリティ問題19 15。 作者のアドレス19
1. Naming, addressing and routing
1. 命名、アドレシング、およびルーティング
A name uniquely identifies a network object (without loss of generality, we will assume the 'object' is a person).
名前は唯一ネットワーク物を特定します(一般性の喪失がなければ、私たちは、'物'が人であると思うつもりです)。
Once a person's name is known, it can be used as a key to determine his address.
人の名前がいったん知られていると、彼のアドレスを決定するのにキーとしてそれを使用できます。
An address uniquely defines where the person is located. It can normally be divided into a domain related part (e.g., the RFC 822 domainpart or in X.400 an ADMD or OU attribute) and a local or user related part (e.g., the RFC 822 localpart or in X.400 a DDA or Surname attribute). The domain related part of an address typically consists of several components, which normally have a certain hierarchical order. These domain levels can be used for routing purposes, as we will see later.
アドレスは、人がどこに位置しているかを唯一定義します。 通常、それをドメイン関連する部分(X.400の例えば、RFC822domainpart、ADMDまたはOU属性)と地方の、または、ユーザ関連する部分(X.400の例えば、RFC822localpart、DDAまたはSurname属性)に分割できます。 アドレスのドメイン関連する部分は数個のコンポーネントから通常成ります。(通常、コンポーネントには、ある階層的順序があります)。 私たちが後で見るようにルーティング目的にこれらのドメインレベルを使用できます。
Once a person's address is known, it can be used as a key to determine a route to that person's location.
人のアドレスがいったん知られていると、その人の位置にルートを決定するのにキーとしてそれを使用できます。
We will use the following definition of an e-mail route:
私たちはメールルートの以下の定義を使用するつもりです:
e-mail route a path between two leaves in a
directed Message Transfer System
(MTS) graph that a message travels
for one originator/recipient pair.
(see Figure 1)
メッセージが1創始者/受取人組旅行する指示されたMessage Transfer System(MTS)グラフによる2枚の葉の間の経路をルートにメールしてください。 (図1を参照します)
Note that, in this definition, the User Agents (UAs) are not part of the route themselves. Thus if a message is redirected at the UA level, a new route is established from the redirecting UA to the UA the message is redirected to.
Userエージェント(UAs)がこの定義で、自分たちでルートの一部でないことに注意してください。 したがって、メッセージがUAレベルで向け直されるなら、新しいルートは向け直しているUAからメッセージが向け直されるUAまで確立されます。
Houttuin [Page 2] RFC 1711 Classifications in E-mail Routing October 1994
1994年10月に掘られるメールにおけるHouttuin[2ページ]RFC1711分類
The first and last leaves in a mail route are not always UAs. A route may start from a UA, but stop at a certain point because one of the MTAs is unable to take any further routing decisions. If this happens, a warning is generated by the MTA (not by a UA), and sent back to the originator of the undeliverable message. It may even happen that none of the leaves is a UA, for instance if a warning message as discussed above turns out to be undeliverable itself. The cautious reader may have noticed that this is a dangerous situation. Special precautions are needed to avoid loops in such cases (see [1]).
航空郵便路による1番目と最後の葉はいつもUAsであるというわけではありません。 ルートはUAから始めるかもしれませんが、MTAsの1つがどんなさらなるルーティング決定も取ることができないので、ある一定のポイント旅装を解いてください。 これが起こるなら、警告は、MTA(UAでないのによる)によって発生して、「非-提出物」メッセージの創始者に返送されます。 例えば、葉のいずれがUAでないことは警告メッセージであるなら外にそれ自体で「非-提出物」になるように回転を超えて議論するように起こりさえするかもしれません。 用心深い読者は、これが危険な状況であるのに気付いたかもしれません。 特別な注意が、そのような場合輪を避けるのに必要です。([1])を見てください。
user user
| ^
v |
+-----------------------------------------+
| | ^ |
| v | |
| +-----+ +-----+ |
| | UA | | UA | |
| +-----+ +-----+ |
| | ^ |
| v | |
| +-------------------------------------+ |
| | v ^ | |
| | v ^ | |
| | v ^ | |
| | +-----+ +-----+ | |
| | | MTA |.....................| MTA | | |
| | +-----+ +-----+ | |
| | v \ ^ | |
| | v \................ ^ | |
| | v \ ^ | | NB The actual route
| | +-----+ \ +-----+ | | is drawn as
| | | MTA |>>>>>>>>>>>>>>>>>>>>>| MTA | | | v ^
| | +-----+ +-----+ | | v ^
| | Message Transfer System | | v >>>>>>>> ^
| +-------------------------------------+ |
| Message Handling System |
+-----------------------------------------+
ユーザユーザ| ^v| +-----------------------------------------+ | | ^ | | v| | | +-----+ +-----+ | | | Ua| | Ua| | | +-----+ +-----+ | | | ^ | | v| | | +-------------------------------------+ | | | ^に対して| | | | ^に対して| | | | ^に対して| | | | +-----+ +-----+ | | | | | MTA|.....................| MTA| | | | | +-----+ +-----+ | | | | v \ ^ | | | | \に対して… ^ | | | | v \ ^ | | ネブラスカは実際のルートです。| | +-----+ \ +-----+ | | 描かれます。| | | MTA| >>>>>>>>>>>>>>>>>>>>>| MTA| | | ^に対して| | +-----+ +-----+ | | ^に対して| | メッセージ転送システム| | >>>>>>>>^に対して| +-------------------------------------+ | | メッセージハンドリングシステム| +-----------------------------------------+
Figure 1. A mail route
図1。 航空郵便路
It is important that the graph is directed, because routes are not necessarily symmetric. A reply to a message may be sent over a completely different mail route for reasons such as cost, non- symmetric network connectivity, network load, etc.
ルートが必ず左右対称であるというわけではないのでグラフが指示されているのは、重要です。 費用などの理由、非左右対称のネットワークの接続性、ネットワーク負荷などのために完全に異なった航空郵便路の上にメッセージに関する回答を送るかもしれません。
Houttuin [Page 3] RFC 1711 Classifications in E-mail Routing October 1994
1994年10月に掘られるメールにおけるHouttuin[3ページ]RFC1711分類
According to the definition, if a message has two different recipients, there will also be two mail routes. Since the delivery to a UA (not the UA itself) is a part of the route, this definition is still valid if two UAs are connected to the same MTA.
また、定義によると、メッセージに2人の異なった受取人がいると、2個の航空郵便路があるでしょう。 UA(UA自身でない)への配送がルートの一部であるので、2UAsが同じMTAに接続されるなら、この定義はまだ有効です。
The words '.. for one originator-recipient pair.' in the definition do not imply that this pair provides the MTA with all necessary information to choose one specific route. One originator-recipient pair may give an MTA the possibility to choose from a number of possible routes, the so-called routing indicators (see chapter 2).
ある創始者受取人に関しては、対にしてください。'単語、'. . '定義では、この組が、ある特定のルートを選ぶためにすべての必要事項をMTAに提供するのを含意しないでください。 1創始者受取人組は多くの可能なルートから選ぶ可能性をMTAに与えるかもしれません、いわゆるルーティングインディケータ(第2章を見てください)。
Other information (e.g., line load, cost, availability) can then be used to choose one route from the routing indicators.
そして、ルーティングインディケータから1つのルートを選ぶのに、他の情報(例えば、回線負荷、費用、有用性)を使用できます。
Routing is defined as the process of establishing routes. Note that this is a distributed process; every intermediate MTA takes its own routing decisions, thus contributing to the establishment of the complete route.
ルート設定はルートを確立する過程と定義されます。 これが分散過程であることに注意してください。 あらゆる中間的MTAがそれ自身のルーティング決定を取って、その結果、完全なルートの確立に貢献します。
Taking a routing decision is not a purely algorithmic process, otherwise there would hardly be any difference between an address and a route. The address is used as a key to find a route, typically in some sort of rule-based routing database. The possible options for realising this database and algorithms for using it are the subject of the rest of this paper.
ルーティング決定を取るのが、純粋にアルゴリズムの過程でない、そうでなければ、アドレスとルートの間には、どんな違いもほとんどあるでしょう。 アドレスは、通常ある種の規則ベースのルーティングデータベースでルートを見つけるのにキーとして使用されます。 このデータベースがわかるための可能なオプションとそれを使用するためのアルゴリズムはこの紙の残りの対象です。
2. Static versus dynamic
2. 静電気対動力
Dynamic (mail) routing allows a routing decision to be influenced by external factors, such as system availability, network load, etc. In contrast, static (mail) routing is not able to adapt to environmental constraints. Static routing can be viewed as an extremely simple form of dynamic routing, namely where there is only one choice for every routing decision.
ダイナミックな(メール)ルーティングはシステム稼働率、ネットワーク負荷などの外部の要素によって影響を及ぼされるというルーティング決定を許します。 対照的に、静的な(メール)ルーティングは環境的制約に順応できません。 非常に簡単なフォームのダイナミックルーティングとしてすなわち、各ルーティング決定あたり1つの選択しかないところでスタティックルーティングを見なすことができます。
Dynamic routing algorithms normally use some kind of distributed databases to store and retrieve routing information, whereas static routing is typically implemented in routing tables.
ダイナミックルーティングアルゴリズムはルーティング情報を格納して、検索するのに通常ある種の分散データベースを使用しますが、スタティックルーティングは経路指定テーブルで通常実行されます。
Note that dynamic routing can occur at different layers: at the mail level, dynamic routing might allow a message to be relayed to a choice of MTAs (the routing indicators). As an example, consider the Internet mechanism of using multiple Mail eXchanger (MX) records, describing MTAs that can serve a domain. If the primary choice MTA is not available, a second choice MTA can be tried. If this second choice MTA is busy, a third one will be tried, etc. On lower layers, there may be more than one presentation address for one MTA, each of which can again have an associated priority and other attributes.
ダイナミックルーティングが異なった層に起こることができることに注意してください: メールレベルでは、ダイナミックルーティングはMTAs(ルーティングインディケータ)の選択にリレーされるべきメッセージを許容するかもしれません。 例と、複数のメールeXchanger(MX)記録を使用するインターネットメカニズムを考えてください、ドメインに役立つことができるMTAsについて説明して。 第一の特選しているMTAが利用可能でないなら、第2の特選しているMTAを試みることができます。 3番目の1つが選択MTAが忙しいこの秒に試みられるなら、などです。 下層に、1MTAのための1つ以上のプレゼンテーションアドレスがあるかもしれません。それは再びそれぞれ関連優先と他の属性を持つことができます。
Houttuin [Page 4] RFC 1711 Classifications in E-mail Routing October 1994
1994年10月に掘られるメールにおけるHouttuin[4ページ]RFC1711分類
These choices may represent that an MTA prefers to be connected to using one certain stack, e.g., RFC1006/TCP/IP, but is also able to accept incoming calls over another stack, such as TP0/CONS/X.25. We will call this dynamic stack routing. Theoretically, dynamic stack routing should be transparent to the mail routing application, and is thus not a part of dynamic mail routing. It is mentioned here because in existing products, dynamic stack routing is often very well visible at the mail configuration level, so MTA managers should at least be aware of it.
これらの選択はそれを表すかもしれません。MTAは1つのあるスタック、例えばRFC1006/TCP/IPを使用すると接続されるのを好みますが、また、別のスタックの上にかかってきた電話を受け入れることができます、TP0/コンズ/X.25などのように。 私たちは、これをダイナミックなスタックルーティングと呼ぶつもりです。 理論的に、ダイナミックなスタックルーティングは、メールルーティングアプリケーションに透明であるべきであり、その結果、ダイナミックなメールルーティングの一部ではありません。 ダイナミックなスタックルーティングが既存の製品の中にメール構成レベルで非常によくしばしば目に見えるのでそれがここに言及されるので、MTAマネージャはそれを少なくとも意識しているべきです。
Although static routing is often table based, not all table based routing algorithms are necessarily static in nature. As a counter example, X.400 routing according to RFC 1465 [2] is clearly table based, but at the same time allows a fairly dynamic kind of mail routing (as well as dynamic stack routing, which in this approach is cleanly separated from the dynamic mail routing part). A mail domain can specify a choice of so-called RELAY-MTAs (formerly called WEPs) that will serve it, each with a priority and maximum number of retries.
しばしばスタティックルーティングはベースのルーティングをすべて見送るのではなく、基づくテーブルですが、アルゴリズムは必ず現実に静的です。 反証として、RFC1465[2]に従ったX.400ルーティングは、明確に基づくテーブルですが、同時に、かなりダイナミックな種類のメールルーティング(ダイナミックなメールルーティング部分とこのアプローチで清潔に切り離されるダイナミックなスタックルーティングと同様に)を許します。 メール・ドメインはそれに役立ついわゆるRELAY-MTAs(以前、WEPsと呼ばれる)の選択を指定できます、それぞれ優先権と最大数の再試行で。
For reasons of flexibility and reliability, dynamic routing is almost always the preferred method.
柔軟性と信頼性の理由で、ほとんどいつもダイナミックルーティングは適した方法です。
3. Direct versus indirect
3. 間接的に対してダイレクトです。
Direct routing allows the originator's MTA to contact the recipient's MTA directly, whereas indirect routing (also known as store-and- forward routing) uses intermediate MTAs to relay the message towards the recipient. It is difficult to clearly distinguish between direct and indirect routing: direct routing assumes the existence of a fully meshed routing topology, whereas indirect routing assumes the existence of a more tree-like hierarchical topology. Mail routing in most existing networks is upto some degree indirect. Networks can be classified as being more or less direct according for the following rule of thumb: larger fan out of the routing tree means more direct routing, greater depth of the tree means less direct routing. Two kinds of indirect routing are presented here: firewalls (downstream) and default routes (upstream).
そして、直接間接的ですが、掘りながらダイレクトルーティングで創始者のMTAに受取人のMTAに連絡する、(また、店として知られている、-、-ルーティング) 用途の中間的MTAsを進めて、受取人に向かってメッセージをリレーしてください。 それは明確にダイレクトに見分ける難しくて間接的なルーティングです: ダイレクトルーティングは完全にかみ合っているルーティングトポロジーの存在を仮定しますが、間接的なルーティングは、より木のような階層的なトポロジーの存在を仮定します。 ほとんどの既存のネットワークにおけるメールルーティングは間接的に何らかの度uptoです。 以下の経験則には多少ダイレクトですネットワークが分類されている場合がある: 多大である、 よりダイレクトなルーティング、木の、より大きい深さが掘りながらそれほど指示しないことを意味するルーティング木の手段を四方八方に広がらせてください。 2種類の間接的なルーティングはここに提示されます: ファイアウォール(川下)とデフォルトルート(上流へ)。
3.1. Firewalls
3.1. ファイアウォール
A firewall 'attracts' all messages for a certain set of addresses (the address sub space behind the firewall) from the outside e-mail world to a central relaying MTA (the firewall). This is done by publishing routes to all other MTAs that must relay their messages over this firewall (the attracted community). Note that local knowledge should be used to route messages within the address space behind the firewall. An example for this is presented later on. There
ファイアウォールは外のメール世界から中央のリレーMTA(ファイアウォール)まであるアドレス(ファイアウォールの後ろのアドレスの潜水艦スペース)へのすべてのメッセージを'引き付けます'。 出版ルートでこのファイアウォール(引き付けられた共同体)の上に彼らのメッセージをリレーしなければならない他のすべてのMTAsにこれをします。 局所的知識がファイアウォールの後ろのアドレス空間の中でメッセージを発送するのに使用されるべきであることに注意してください。 これのための例は後で提示されます。 そこでは
Houttuin [Page 5] RFC 1711 Classifications in E-mail Routing October 1994
1994年10月に掘られるメールにおけるHouttuin[5ページ]RFC1711分類
exist many reasons for using firewalls, e.g., security considerations or to concentrate the management for a given domain onto one well managed system.
存在してください。ファイアウォール、例えばセキュリティ問題を使用するか、または与えられたドメインのための管理を1つによく集結する多くの理由がシステムを管理しました。
The Internet mail system would allow all mail hosts connected to the Internet to directly accept mail from any other host, but not all hosts use this possibility. Many domains are hidden behind one or more 'Mail eXchanger' (MX), which offer to relay all incoming mail for those domains. The RELAY-MTAs mentioned earlier can also be considered firewall systems.
インターネット・メールシステムはホストが使用するすべてではなく、直接受け入れるインターネットに関連しているメールホストがいかなる他のホストからも郵送するすべてにこの可能性を許容するでしょう。 多くのドメインがそれらのドメインのためのすべての入って来るメールをリレーすると申し出る1'メールeXchanger'(MX)の後ろに隠されます。 また、ファイアウォールシステムであると、より早く言及されたRELAY-MTAsを考えることができます。
+-----------------------------------+
| |
| The rest of the e-mail world |
| |
+-----------------------------------+
\ | | /
\ | | /
\| | /
v vv
+--------------+
|Firewall MTA A|
+--------------+
^ / ^ \ ^
/ / | \ \
/ / | \ \
Default route--o / | \ o---Default route
/ / | \ \
/ / | \ \
/ v v v \
+-----+ +-----+ +-------+
|MTA B|<----|MTA C| |MTA D |
+-----+ +-----+ +-------+
/ | | | \
/ | | | \
/ | | | \
+----+ +----+ +----+ +----+ +----+
| UA | | UA | | UA | | UA | | UA |
+----+ +----+ +----+ +----+ +----+
+-----------------------------------+ | | | メール世界の残り| | | +-----------------------------------+ \ | | / \ | | / \| | vv+に対する/--------------+ |ファイアウォールMTA A| +--------------+ ^ / ^ \ ^ / / | \ \ / / | \\デフォルトルート--o/| \o---デフォルトルート//| \ \ / / | \\/v対v\+-----+ +-----+ +-------+ |MTA B| <、-、-、--、|MTA C| |MTA D| +-----+ +-----+ +-------+ / | | | \ / | | | \ / | | | \ +----+ +----+ +----+ +----+ +----+ | Ua| | Ua| | Ua| | Ua| | Ua| +----+ +----+ +----+ +----+ +----+
Figure 2. Firewall and default route
図2。 ファイアウォールとデフォルトルート
3.2. Default versus rule based
3.2. デフォルト対基づく規則
Default routing is to outgoing mail what a firewall is for incoming mail, and is thus often used in conjunction with firewalls. It is about the simplest routing algorithm one can think of: route every message to one and the same MTA, which is trusted to take further
デフォルトルーティングは、ファイアウォールが入って来るメールのためのものであることを外向的に郵送することであり、このようにしてファイアウォールに関連してしばしば使用されます。 それはものが考えることができる中で最も簡単なルーティング・アルゴリズムに関するものです: あらゆるメッセージを全く同じMTAに発送してください。(MTAはさらに取ると信じられます)。
Houttuin [Page 6] RFC 1711 Classifications in E-mail Routing October 1994
1994年10月に掘られるメールにおけるHouttuin[6ページ]RFC1711分類
care of routing the message towards its destination. Pure default routing is rather useless; it is normally used as a fall back mechanism accompanying a rule based algorithm.
目的地に向かってメッセージを発送する注意。 純粋なデフォルトルーティングはかなり役に立ちません。 規則に伴う秋の逆メカニズムがアルゴリズムを基礎づけて、通常、それは使用されます。
For example, the simplest usable default algorithm is the following: first check if a mail should be delivered to a local UA. If not, perform default routing.
例えば、最も簡単な使用可能なデフォルトアルゴリズムは以下です: まず最初に、メールが地方のUAに提供されるべきであるかどうかチェックしてください。 そうでなければ、デフォルトルーティングを実行してください。
In order to avoid loops, it is not acceptable for all MTAs within a certain routing community (see chapter 9) to use default routing. At least one MTA should be able to access all routing rules for that community. Consider the following example: An X.400 MTA A, which serves the organisation organisational unit OU=orgunA within the organisation O=org, receives a message for the domain O=org; OU=orgunB;. Since MTA B in the same organisation serves all other OUs, A will default route the message to B. Suppose that B would use the same mechanism: first check if the OU is local and if not, default route to A. If OU=orgunC is not served by either A or B, this routing set-up will lead to a loop. The decision that a certain OU does not exist can only be made if at least one of the MTAs has knowledge of all existing OUs under O.
輪を避けるために、ある一定のルーティング共同体(第9章を見る)の中のすべてのMTAsがデフォルトルーティングを使用するのは、許容できません。 少なくとも1MTAがすべてのルーティング規則にその共同体にアクセスするはずであることができます。 以下の例を考えてください: X.400 MTA A(機構O=orgの中で機構organisational部隊OU=orgunAに役立つ)はドメインO=orgへのメッセージを受け取ります。 OU=orgunB; 同じ機構サーブ他のすべてのOUs、AにおけるMTA B以来、デフォルトはBが同じメカニズムを使用するだろうというB.Supposeへのメッセージを発送するでしょう: まず最初に、OUが地方であるかどうかチェックして、そうでなければ、A.If OU=orgunCへのデフォルトルートはAかBのどちらかによって役立たれていません、そして、このルーティングセットアップは輪につながるでしょう。 少なくともMTAsの1つがOの下にすべての既存のOUsに関する知識を持っている場合にだけあるOUが存在していないという決定をすることができます。
An example of a firewall and two default routes is shown in figure 2. It visualises that a firewall is a downstream and a default route is an upstream indirection. MTA B and D use default routing; they can only route to one other MTA, MTA A.
ファイアウォールと2つのデフォルトルートに関する例は2が中で計算するのが示されます。 それはそれを想像します。ファイアウォールは川下とデフォルトルートが上流の間接指定であるということです。 MTA BとDはデフォルトルーティングを使用します。 彼らは他のMTA、MTA Aを1つに発送できるだけです。
For more detailed information, please refer to [3], which lists most pros and cons of both approaches. Your choice will depend on many factors that are specific for your messaging environment.
より詳細な情報について、[3]を参照してください。([3]は両方のアプローチのほとんどの賛否両論を記載します)。 あなたのこの選択は多くのあなたのメッセージング環境に、特定の要素次第でしょう。
4. Routing at user level
4. ユーザレベルにおけるルート設定
Normally a message is routed down to the deepest level domain, and then delivered to the recipient per default routing. I.e., every user in this domain is considered to have his mailbox uniquely defined within this domain on the same MTA, and every user on that MTA can be distinguished within this domain. Exceptions can occur when the users within a domain have their mailboxes on different MTAs (distributed domain), or when several domains exist on the same MTA (shared MTA).
通常、メッセージは、デフォルトルーティングあたりの受取人に最も深い平らなドメインまで発送されて、次に、提供されます。 このドメインのすなわちすべてのユーザが同じMTAの上のこのドメインの中で彼のメールボックスを唯一定義させると考えて、このドメインの中でそのMTAの上のすべてのユーザを区別できます。 ドメインの中のユーザが異なったMTAs(分配されたドメイン)に彼らのメールボックスを持っているか、またはいくつかのドメインが同じMTA(共有されたMTA)に存在していると、例外は起こることができます。
4.1. Distributed domains
4.1. 分配されたドメイン
Routing is normally performed down to a certain domain level. Mail to all users that are directly registered under this domain is then delivered per default routing, i.e., delivered locally. Explicit user routing (i.e., rule-based routing on user level attributes according to a fixed table listing all users) may be necessary when not all
通常、ルート設定はあるドメインレベルまで実行されます。 そして、このドメインの下で直接登録されるすべてのユーザへのメールはすなわち、掘るのが局所的に提供したデフォルト単位で提供されます。 すべてでないときに、明白なユーザルーティング(すなわち、すべてのユーザを記載する固定テーブルに従ったユーザレベル属性に関する規則ベースのルーティング)が必要であるかもしれません。
Houttuin [Page 7] RFC 1711 Classifications in E-mail Routing October 1994
1994年10月に掘られるメールにおけるHouttuin[7ページ]RFC1711分類
users have their UAs connected to the same MTA.
ユーザは彼らのUAsを同じMTAに接続させます。
Note that the whole issue of distributed domains is nothing more than a special case of the problems discussed in chapter 3.2: 'Default versus rule-based'. The only reason for mentioning this in a separate chapter is that there are many software products that don't deal with routing based on local address parts in the same way as with routing based on domain related address parts.
分配されたドメインの全体の問題がただ第3.2章で論じられた問題の特別なケースであることに注意してください: '規則ベースに対してデフォルトとしてください'。 別々の章でこれについて言及する唯一の理由は同様に、ドメインに基づいて関連するアドレス部を発送するようにローカルアドレスの部品に基づくルーティングに対処しない多くのソフトウェア・プロダクトがあるということです。
As an example, consider an organisation where two mail platforms are available. Some users prefer using platform A, others prefer platform B. Of course, the easiest solution would be to create a subdomain A and a subdomain B, and then route domain A to system A and B to B. Default user routing on both platforms would then do the rest. However, when an organisation wants to present itself to the outside world using only one domain, this scheme cannot be used, at least not without special precautions (see the paragraph about avoiding loops in chapter 3.2).
例と、2個のメールプラットホームが利用可能である機構を考えてください。 何人かのユーザが、プラットホームAを使用するのを好みます、そして、他のものはプラットホームB.Ofすじを好みます、そして、両方のプラットホームでのB.DefaultユーザルーティングへのBは最も簡単なソリューションがシステムAにサブドメインAとサブドメインBを作成して、次に、ルートドメインAを作成するだろうことであり、次に、残りをするでしょう。 しかしながら、機構が1つのドメインだけを使用することで外の世界に出向きたいと、この体系を使用できません、少なくとも特別な注意で(第3.2章で輪を避けることに関するパラグラフを見てください)。
+----------+ +---------------------------+
| MTA A | | Shared MTA B |
+----------+ +---------------------------+
| | / | | |
+-----------------/----+ +-----------+ +----------+
| | | / | | | | | | | |
| +--+ +--+ +--+/ | | +--+ +--+ | | +--+ |
| |UA| |UA| |UA| | | |UA| |UA| | | |UA| |
| +--+ +--+ +--+ | | +--+ +--+ | | +--+ |
| Distributed Domain A | | Domain B | | Domain C |
+----------------------+ +-----------+ +----------+
+----------+ +---------------------------+ | MTA A| | 共有されたMTA B| +----------+ +---------------------------+ | | / | | | +-----------------/----+ +-----------+ +----------+ | | | / | | | | | | | | | +--+ +--+ +--+/ | | +--+ +--+ | | +--+ | | |Ua| |Ua| |Ua| | | |Ua| |Ua| | | |Ua| | | +--+ +--+ +--+ | | +--+ +--+ | | +--+ | | 分配されたドメインA| | ドメインB| | ドメインC| +----------------------+ +-----------+ +----------+
Figure 3. Distributed domains and shared MTAs
図3。 分配されたドメインと共有されたMTAs
Another possibility to have uniform addresses in outgoing e-mail, despite the fact that a domain is distributed, is to make routing decisions on information in the local part of the address, e.g., in X.400 the Surname in exactly the same manner as making routing decisions on any other attributes. Thus products and routing algorithms that are able to route on user related address parts are said to support distributed domains.
ドメインが分配されているという事実にもかかわらず、送信する電子メールにおける一定のアドレスを持つ別の可能性はまさにルーティングをいかなる他の属性の決定にもするのと同じ方法でアドレスの地方の部分、例えば、X.400の情報のルーティング決定をSurnameにすることです。 したがって、ユーザの上で関連するアドレス部を発送できる製品とルーティング・アルゴリズムは分配されたドメインをサポートすると言われています。
4.2. Shared MTA
4.2. 共有されたMTA
The opposite of a distributed domain is a shared MTA: several domains are routed locally on the same MTA. These domains sharing one MTA may cause problems when two or more domains have a local user with the same name.
分配されたドメインの正反対は共有されたMTAです: いくつかのドメインが同じMTAで局所的に発送されます。 2つ以上のドメインに地元のユーザが同じ名前と共にいるとき、1MTAを共有するこれらのドメインは問題を起こすかもしれません。
Houttuin [Page 8] RFC 1711 Classifications in E-mail Routing October 1994
1994年10月に掘られるメールにおけるHouttuin[8ページ]RFC1711分類
Theoretically, this problem doesn't exist: the address is being routed down to the deepest domain level, and within that level, there will only be one user with that name (let's at least assume this for simplicity). Some products however use only one database of all users locally connected to this MTA instead of one database per domain, so that default user routing at the deepest level can lead to conflicts. It is beyond the scope of this document to describe the tricks needed to avoid these conflicts when using such products.
理論的に、この問題は存在していません: アドレスは最も深いドメインレベルまで発送されています、そして、そのレベルの中では、1人のユーザしかその名前と共にいないでしょう(簡単さのためにこれを少なくとも仮定しましょう)。 しかしながら、いくつかの製品が局所的に1ドメインあたり1つのデータベースの代わりにこのMTAに接続されたすべてのユーザの1つのデータベースだけを使用します、最も深いレベルにおけるデフォルトユーザルーティングが闘争に通じることができるように。 それは、そのような製品を使用するとき、これらの闘争を避けるのに必要であるトリックを説明するためにこのドキュメントの範囲を超えています。
5. Routing control
5. ルート設定コントロール
Routing control means that routing decisions can be affected by the originator of a message. This normally takes the form of either granting or denying access for a certain user or group of users.
ルート設定コントロールは、ルーティング決定がメッセージの創始者で影響を受けることができることを意味します。 通常、これは確信しているユーザかユーザー層のためのアクセスを承諾するか、または拒絶する形を取ります。
Routing control is often useful in an X.400 ADMD/PRMD environment, where it is either used to grant access only to users who are known to be chargeable, or where ADMDs can refuse messages that were relayed to them over international PRMD connections; a policy that is not allowed in the CCITT version of the standards (as opposed to the ISO version). Of course, the PRMDs can also perform routing control themselves in order to circumvent such problems.
ルート設定コントロールはX.400 ADMD/PRMD環境でしばしば役に立ちます。(そこではそれが請求できるのが知られているユーザだけへのアクセスを承諾するのに使用されるか、またはADMDsは国際的なPRMD接続の上でそれらにリレーされたメッセージを拒否できます)。 規格(ISOバージョンと対照的に)のCCITTバージョンに許容されていない方針。 もちろん、また、PRMDsはそのような問題を回避するために自分たちでルーティングコントロールを実行できます。
Although there may be good reasons for using routing control, one must be aware that it can make the messaging environment unpredictable for end-users. Where using routing control is unavoidable, the originator whose message has been rejected is likely to appreciate receiving a message, clearly telling him where and why routing of his message was refused, whom to contact, and what options are available to avoid such rejections in the future.
ルーティングコントロールを使用するもっともな理由があるかもしれませんが、メッセージング環境をエンドユーザにとって予測できるようにすることができないのを意識しているに違いありません。 ルーティングコントロールを使用するのが避けられないところでは、メッセージが拒絶された創始者はメッセージを受け取るのに感謝しそうです、彼のメッセージのルーティングがどこでなぜ拒否されたか、そして、だれに連絡するか、そして、どんなオプションが将来そのような拒絶を避けるために利用可能であるかを明確に彼に言って。
6. Bulk routing
6. 大量のルーティング
In order to reduce network traffic, intelligent mailers may prefer a message addressed to a group of remote users to be transferred to a remote domain only once, thus postponing the 'explosion' into several copies. This technique, called bulk routing, is especially useful when an MTA hosts large mailing lists.
ネットワークトラフィックを減少させるために、知的な郵送者は、リモート・ユーザーのグループに扱われたメッセージが一度だけ遠く離れたドメインに移されるのを好むかもしれません、その結果、'爆発'を数個のコピーに延期します。 MTAが大きいメーリングリストをホスティングするとき、大量のルーティングと呼ばれるこのテクニックは特に役に立ちます。
Several possibilities exist. In a typical hierarchical firewall mail system, bulk routing can be done almost automatically by intelligent MTAs. For instance, in an X.400 community, a large international distribution list can create a message with an envelope containing 1000 recipient addresses, some of which can probably be grouped by the MTA depending on whether they can be routed further to the same remote MTA, according to the normal routing implementation at this MTA. The size and number of these groups will largely depend on how indirect this routing implementation is. In the GO-MHS community, the
いくつかの可能性が存在しています。 典型的な階層的なファイアウォールメールシステムでは、知的なMTAsはほぼ自動的に大量のルーティングができます。 例えば、X.400共同体では、大きい国際流通リストは封筒が1000の受取人アドレスを含んでいるメッセージを作成できます、このMTAの正常なルーティング実装に従って。同じリモートMTAに加えてそれらを発送できるかどうかによるMTAはたぶんアドレスのためにそれの或るものを分類できます。 これらのグループのサイズと数はこのルーティング実装がどれくらい間接的であるか主に依存するでしょう。 GO-MHS共同体で
Houttuin [Page 9] RFC 1711 Classifications in E-mail Routing October 1994
1994年10月に掘られるメールにおけるHouttuin[9ページ]RFC1711分類
number of groups will almost always be less than 50, which provides a rather fair distribution of traffic load over the involved MTAs (that is, fair according to the author's taste, who is not aware of any existing fair mail load distribution formula).
グループの数はほとんどいつも50になるでしょう(かかわったMTAs(作者の趣味に従って、公正です、すなわち、だれがどんな既存の公正なメール負荷分配公式も意識していないか、)の上にトラヒック負荷のかなり公正な分配を供給します)。
As an extreme example, the simplest way to automatically (i.e., without using special optimisation tools) bulk route mail is to use one default route. Any outgoing message, regardless of the number of recipients, will be routed over the default route only once. The default remote MTA will then have to break up the message (envelope) into several copies and is thus responsible for the actual explosion and distribution. NB. This mechanism can be exploited to shift the cost and overhead of exploding a message towards another domain/MTA. If you ever get a request for a bilateral default route agreement; i.e., the requesting party wants to default route over your MTA, it may be worth to check first if the requesting party is running or planning to run large mailing lists.
極端な例として、自動的(すなわち、特別な最適化ツールを使用しないで)に大量のルートメールへの最も簡単な道は1つのデフォルトルートを使用することです。 受取人の数にかかわらず、どんな送信されるメッセージも一度だけデフォルトルートの上に発送されるでしょう。 デフォルトのリモートMTAは次に、メッセージ(封筒)を数個のコピーに終えなければならなくて、その結果、実際の爆発と分配に責任があります。 ネブラスカ。 別のドメイン/MTAに向かってメッセージを爆発させる費用とオーバーヘッドを移行させるのにこのメカニズムを利用できます。 双方のデフォルトを求める要求を得るなら、協定を発送してください。 すなわち、デフォルトへのパーティー必需品があなたのMTAの上で発送する要求であり、最初に、要求パーティーが走るか、そして、大きいメーリングリストを実行する計画をチェックする価値があるかもしれません。
In more direct routing environments, such as BITNET, bulk routing will not function as automatically as described above. Without special precautions, an MTA would open a direct connection to every single host that occurs in the message's envelope, regardless of whether some of these hosts are far away from this MTA, but close to each other, measured by underlying network topology. This can clearly lead to a waste of expensive bandwidth. In order to be able to detect such cases, and to act upon it by sending one single copy over an expensive link and have it distributed at some remote hosts, an MTA must have additional knowledge of the relation between mail domains and the underlying network topology.
Bitnetなどの、よりダイレクトなルーティング環境で、大量のルーティングは上で説明されるほど自動的に機能しないでしょう。 特別な注意がなければ、MTAは何人かのこれらのホストがこのMTAから遠いかどうかにかかわらず互いの近くの基本的なネットワーク形態によって測定されたメッセージの封筒に起こるあらゆるホストにダイレクト接続を公開しているでしょう。 これは明確に高価な帯域幅の浪費に通じることができます。 そのような場合を検出して、ただ一つのコピー1部を高価なリンクの上に送ることによってそれに作用して、何人かのリモートホストでそれを分配させることができるように、MTAにはメール・ドメインと基本的なネットワーク形態との関係に関する追加知識がなければなりません。
BITNET uses the distribute protocol [4] for this purpose. A selected set of hosts is published to have the required topology knowledge and to be able to efficiently distribute the mail on behalf of other MTAs, who can explicitly route all bulk mail to one of those hosts. The complete message, including the envelope, is encoded in a message body, which starts with a distribution request to the distribute server. This server will break up the rest of the body into the original envelope and contents and then use it's topology knowledge to efficiently distribute the original message. Note that this protocol violates the conceptual model of the layering of MTA and UA functionality, but it is about the only trick that will work in a very direct routing environment. It is only needed to overrule a non- efficient (for large mailing lists) routing topology.
Bitnetが使用する、このためにプロトコル[4]を分配してください。 選択されたセットのホストは、必要なトポロジー知識を持って、効率的に他のMTAsを代表してメールを配布できるように発行されます。明らかに、MTAsはそれらのホストのひとりにすべての料金別納郵便を発送できます。 ボディーは分配要求から始まります。サーバを分配してください。封筒を含む完全なメッセージがaがボディーを通信させるコード化されたコネである、このサーバ意志の休み中に、オリジナルの封筒、コンテンツ、および次に、使用へのボディーの残りに、それは効率的にオリジナルのメッセージを分配するトポロジー知識です。 このプロトコルがMTAとUAの機能性のレイヤリングの概念モデルに違反しますが、それが非常にダイレクトなルーティング環境で利く唯一のトリックに関するものであることに注意してください。 それが、非効率的な(大きいメーリングリストのための)ルーティングトポロジーを却下するのに必要であるだけです。
Bulk routing is an area where mail routing issues start to overlap with the area of distributing netnews (bulletin board services). Several organisations, such as ISO, RARE and the IETF have started initiatives in the direction of harmonising the two worlds. The first
大量のルーティングはメールルーティング問題がネットニュース(掲示板のサービス)を分配の領域に重ね合わせ始める領域です。 2つの世界を合わせることの向きにISOや、RAREやIETFなどのいくつかの機構がイニシアチブを始めました。 1番目
Houttuin [Page 10] RFC 1711 Classifications in E-mail Routing October 1994
1994年10月に掘られるメールにおけるHouttuin[10ページ]RFC1711分類
results, be it standards or products, are not expected before 1995 though.
もっとも、結果は1995年前に規格か製品であることにかかわらず予想されません。
7. Source routing
7. ソースルーティング
Source routing was originally intended to allow a user to force a message to take a certain route. The mechanism works as follows: the MTA that the user wants the message to be routed through is integrated into the address. Once the message has arrived at the specified MTA, that MTA strips itself from the source-routed address and routes the remaining address in the usual way. This mechanism is called explicit source routing and can be useful if a user wants to test a routing path or force a message to be routed over a faster, cheaper, more reliable, or otherwise preferred path.
元々、ソースルーティングが、ユーザが、ある一定のルートを取るメッセージを強制するのを許容することを意図しました。 メカニズムは以下の通り動作します: ユーザがメッセージを発送して欲しいMTAはアドレスと統合されます。 メッセージがいったん指定されたMTAに到着すると、そのMTAはソースによって発送されたアドレスから裸になって、不断のとおり残っているアドレスを発送します。 ユーザがルーティング経路をテストしたいか、または、より速いか、より安いか、信頼できるか、または別の方法で好まれた経路の上に発送されるべきメッセージを強制したいなら、このメカニズムは、明白なソースルーティングと呼ばれて、役に立つ場合があります。
For instance, if the Internet user user@uni-a.edu wants to test the mail connections to and from a remote domain uni-b.edu, he might source route a message to himself over the MTA at uni-b.edu by addressing the mail to: @uni-b.edu:user@uni-a.edu
例えば、インターネットユーザ user@uni-a.edu がeduとa遠く離れたドメインuni-b.eduからメール接続をテストしたいなら、彼は以下のことのための自分へのメールを扱うのによるuni-b.eduのMTAの上のルートaメッセージの出典を明示するかもしれません。 @uni b.edu: user@uni-a.edu
Source routing need not always be explicit. Source routes can also be generated automatically by a gateway, in which case we speak of address rooting (to that gateway). The gateway will root itself to the message by putting its own domain in the source route mapped address, thus ensuring that any replies to the gatewayed message will be routed back through the same gateway.
ソースルーティングはいつも明白でなければならないというわけではありません。 また、ゲートウェイで自動的に送信元経路を生成することができます、その場合、私たちはアドレス応援(そのゲートウェイへの)について話します。 ゲートウェイはメッセージに送信元経路の写像しているアドレスにそれ自身のドメインを入れることによって、それ自体を根づかせるでしょう、その結果、gatewayedメッセージに関するどんな回答も同じゲートウェイを通して発送されるのを確実にします。
Example 1: RFC 1327 left hand side encoding (see [5]) performed by the gateway 'gw.ch':
例1: RFC1327は手のサイドコード化を残しました。([5])がゲートウェイ'gw.ch'によって実行されるのを見てください:
C=zz;A=a;P=p;O=oo;S=plork ->
"/C=zz/A=a/P=p/O=oo/S=plork/"@gw.ch
「C=zz; A=a; P=p; O=oo; S=plork->」/Cがzz/A=a/P=p/O=oo/S=plork/と等しい、」 @gw.ch
Example 2: RFC 1327 DDA mapping (see [5]) performed by the gateway C=zz;A=a;
例2: RFC1327DDAマッピング、([5])がゲートウェイC=zzによって実行されるのを見てください; A=a
bush@dole.us ->
DD.RFC-822=bush(a)dole.us;C=zz;A=a;
bush@dole.us --、gt;、DD.RFC-822=bush(a)dole.us; Cはzzと等しいです; A=a
Example 3: the so-called %-hack:
例3: いわゆる%ハッキング:
user%final.domain@1st.relay
user%final.domain@1st.relay
When the relaying host '1st.relay' receives the message, it strips its own domain part and interprets the localpart 'user%final.domain': it changes the % to an @ sign and relays the message to the address
リレーしているホスト'最初の.relay'がメッセージを受け取るとき、それ自身のドメイン部分を剥取って、localpart'ユーザ%final.domain'を解釈します: それは、%を@サインに変えて、アドレスにメッセージをリレーします。
user@final.domain
user@final.domain
Houttuin [Page 11] RFC 1711 Classifications in E-mail Routing October 1994
1994年10月に掘られるメールにおけるHouttuin[11ページ]RFC1711分類
Example 4: Another example of the already mentioned explicit source routing, this time through two relays:
例4: 既に言及された明白なソースルーティングに関する別の例、2個のリレーによる今回:
@1st.relay,@2nd.relay:user@final.domain
@最初の.relay、@の2番目の.relay: user@final.domain
In the Internet, use of explicit source routing is strongly discouraged (see [6]), one reason being that not all mail relays will handle such addresses in a consistent manner. Apart from that, the need to use explicit source routing has disappeared over the last decennia. In earlier days, when the RFC 822 world consisted of many sparsely connected 'mail islands', source routing was sometimes needed to make sure that a message was routed through a gateway that was known to be connected to a remote island. Nowadays, the RFC 822 world is almost fully interconnected through the Internet, so the need for end-users to have knowledge of the mail network's topology has become superfluous.
インターネットでは、明白なソースルーティングの使用は強くお勧めできないです。([6])(すべてのメール中継が一貫した方法でそのようなアドレスを扱うというわけではないということである1つの理由)を見てください。 それは別として、明白なソースルーティングを使用する必要性は最後のdecenniaの上で見えなくなりました。 以前の日に、ソースルーティングが、メッセージが遠く離れた島に接続されるのを知られていたゲートウェイを通して発送されたのを確実にするのに時々必要でした。(その時、RFC822世界は多くのまばらに接続された'メール島'から成りました)。 この頃はRFC822世界がインターネットを通してほぼ完全にインタコネクトされるので、エンドユーザがメールネットワークのトポロジーに関する知識を持つ必要性は余計になりました。
8. Poor man's routing
8. 貧者のルーティング
If we combine static, indirect and source routing, we get what is commonly known as "poor man's routing". The user thus specifies the complete route in the address. A classic example is the old UUCP bang style addressing:
静的であって、間接的に結合するなら、ソースが掘って、「貧しい男性は掘っている」とき、私たちが一般的に知られているものを得ます。 その結果、ユーザはアドレスの完全なルートを指定します。 典型例は古いUUCP衝撃音スタイルアドレシングです:
host1!host2!host3!host4!user
host1!host2!host3!host4!ユーザ
Poor man's routing is presented here for historical reasons only. Since, for reasons discussed earlier, most present networks discourage source routing and prefer dynamic over static routing, poor man's routing is not widely deployed anymore.
貧者のルーティングは歴史的な理由だけでここに提示されます。 ほとんどの現在のネットワークが、より早く議論した理由でソースルーティングに水をさしていて、スタティックルーティングより動力を好むので、貧者のルーティングはそれ以上広く配布されません。
9. Routing communities
9. ルート設定共同体
A routing community can be defined as follows:
以下の通りルーティング共同体を定義できます:
Routing community: a set of MTAs X, with the property
that for any address a, every MTA
in X except a subset Ya will have
the option, according to an agreed
upon set of routing rules, to
directly route that address to at
least one MTA in Ya.
ルート設定共同体: MTAs Xの1セット、いずれのためにもaを扱う特性、XのあらゆるMTA部分集合によって、Yaにはオプションがある、直接Yaの少なくとも1MTAにそのアドレスを発送するためにルーティング規則のセットに同意しました。
Which is a rather formal way of describing that a routing community consists of a set of MTAs (and human operators) that agreed on a common set of rules on how to route messages among each other.
ルーティング共同体がどうメッセージを互いに発送するかの一般的なセットの規則に同意したMTAs(そして、人間のオペレータ)の1セットから成ると説明するかなり正式な方法です。
Houttuin [Page 12] RFC 1711 Classifications in E-mail Routing October 1994
1994年10月に掘られるメールにおけるHouttuin[12ページ]RFC1711分類
An example of a routing community is the large Internet routing community, in which the agreed rules are implemented in the Domain Name System (DNS). For details, refer to [7]. The subset Ya is in this case the set of MTAs that have an MX record in the DNS for a. MTAs that hide behind fire walls or behind default routes are thus not considered direct members of this community, but normally form their own smaller routing community, with one host (the mail exchanger/default route) belonging to both communities.
ルーティング共同体に関する例は大きいインターネット・ルーティング共同体です。(そこでは、同意された規則がドメインネームシステム(DNS)で実装されます)。 詳細について、[7]を参照してください。 この場合、部分集合YaはMXにaのためにDNSに記録させるMTAsのセットです。 ファイアウォールの後ろ、または、デフォルトルートの後ろに隠れるMTAsがこの共同体のダイレクトメンバーであることはこのようにして考えられませんが、通常、それら自身の、より小さいルーティング共同体を形成します、1人のホスト(メール交換器/デフォルトルート)が両方の共同体に属して。
Another example is the GO-MHS community, consisting of a set of documented RELAY-MTAs (formerly called WEPs, Well-known Entry Points). Routing communities can be further classified depending on the openness and topology of their routing rules. [3] defines four classes of routing communities:
別の例は記録されたRELAY-MTAs(以前、WEPsと呼ばれて、Wellによって知られているEntry Points)の1セットから成るGO-MHS共同体です。 それらのルーティング規則の風通しの良さとトポロジーによって、さらにルート設定共同体を分類できます。 [3]は共同体を発送しながら、4つのクラスを定義します:
Local community: The scope of a single MTA. Contains
the MTAs view of the set of
bilateral routing agreements, and
routing information local to the
MTA. Example: any local MTA.
地方の共同体: 独身のMTAの範囲。 双方のルーティング協定、およびMTAへのローカルのルーティング情報のセットのMTAs視点を含んでいます。 例: どんな地方のMTA。
Closed community: This is like a local community, but
involves more than one MTA. The
idea is to route messages only
within this closed community. A
small subset of the involved MTAs
can be in another community as
well, in order to get the
connectivity to the outside world,
as described earlier. Example: A
set of Private Management Domains
(PRMDs) representing the same
organisation in multiple countries.
共同体を閉じます: これは、地方の共同体に似ていますが、1MTAにかかわります。 考えはこの閉じている共同体だけの中でメッセージを発送することです。 かかわったMTAsの小さい部分集合がまた、別の共同体にあることができます、接続性を外の世界に得るために、より早く説明されるように。 例: 複数の国で同じ機構を代表する兵士のManagement Domains(PRMDs)の1セット。
Open community: All routing information is public
and any MTA is invited to use it.
Example: the Internet.
疎生群落: すべてのルーティング情報が公共です、そして、どんなMTAもそれを使用するよう誘われています。 例: インターネット。
Hierarchical community:A subtree of the O/R address tree.
Note that the subtree will in
practice often be pruned; sub-sub-
trees may form their own routing
community. Example: GO-MHS.
階層的な共同体: O/Rアドレス木の下位木。 下位木が実際にはしばしば剪定されることに注意してください。 サブサブ木はそれら自身のルーティング共同体を形成するかもしれません。 例: 碁-MHS。
This classification cannot always be followed too strictly. For example, completely closed communities are relatively rare. In order for e-mail to be an effective communication tool, an organisation will typically designate at least one of its MTAs as a gateway to
いつもあまりに厳密にこの分類に続くことができるというわけではありません。 例えば、完全に閉じている共同体は比較的まれです。 メールが有効なコミュニケーション機器、機構がゲートウェイとして少なくともMTAsの1つを通常指定するということであるために、整然とします。
Houttuin [Page 13] RFC 1711 Classifications in E-mail Routing October 1994
1994年10月に掘られるメールにおけるHouttuin[13ページ]RFC1711分類
another routing community, for instance to the Internet. The organisation will register an Internet domain, say 'org.net', which points to this gateway, and thus acts as a firewall from the Internet to the domain 'org.net', and as a default route from the closed community to the rest of the Internet. At this stage, the gateway MTA can be regarded as being a member of any of the four types of routing communities. The reader is invited to check this himself.
別のもの、例えば、共同体をインターネットに発送します。 機構は、インターネットからドメイン'org.net'までのファイアウォールとして閉じている共同体からインターネットの残りまでのデフォルトルートとしてインターネットドメインを登録して、このゲートウェイを示す'org.net'を言って、その結果、行為を言うでしょう。 現在のところ、ゲートウェイMTAを4つのタイプのルーティング共同体のどれかのメンバーであると見なすことができます。 読者が自分でこれをチェックするよう誘われています。
Especially the distinction between open and closed communities is not always easy. To some extent, most routing communities are open, at least among their own participants. It is just that some routing communities are more open than others. Also, even the most open routing community is not just open to anyone. It is not enough for a community participant to use the community's routing rules and connect to any other MTA in the community. The participant will typically also have to fulfil an agreed upon set of operational requirements, for example the Internet host requirements [6] or the GO-MHS domain requirements [8].
特に開いていて閉じている共同体の区別はいつも簡単であるというわけではありません。 ほとんどのルーティング共同体が少なくともそれら自身の関係者の中である程度、開いています。 まさしく、いくつかのルーティング共同体が他のものより開いているということです。 だれにとっても、最も開いているルーティング共同体さえただ開いていません。 共同体の関係者が共同体のルーティング規則を使用して、共同体のいかなる他のMTAにも接続するのは、十分ではありません。 また、関係者が通常充足しなければならない、操作上の要件、例えば、インターネット・ホスト要件[6]かGO-MHSドメイン要求性[8]のセットに同意しました。
The most open routing community known today is certainly the Internet mail community. As for X.400 routing communities, some problems occur when trying to open a community, the main one being that most X.400 software does not support the so called 'anonymous' connection mode, which allows any remote MTA to connect to it. Most software was designed or configured to use passwords for setting up MTA connections. This, together with the fact that X.400 routing was originally designed to be hierarchical, is one of the main reasons why most X.400 communities today are either closed or hierarchical.
確かに、今日知られている中で最も開いているルーティング共同体はインターネット・メール共同体です。 共同体を開こうとするとき、X.400ルーティング共同体に関して、いくつかの問題が起こります、主なものがほとんどのX.400ソフトウェアがどんなリモートMTAもそれに接続できるいわゆる'匿名'の接続モードをサポートしないということであり。 ほとんどのソフトウェアが、設計されたか、またはMTA接続をセットアップするのにパスワードを使用するのを構成されました。 X.400ルーティングが元々階層的になるように設計されたという事実と共にこれは今日のほとんどのX.400共同体が閉じられるか、または階層的である主な理由の1つです。
10. Realisations
10. Realisations
In this chapter some of the routing classifications described above are assigned to existing mail services and projects.
本章では、上で説明されたルーティング分類のいくつかが既存のメールサービスとプロジェクトに配属されます。
10.1. Internet mail
10.1. インターネット・メール
RFC 822 mail. An operational service. Co-ordination: distributed. Mostly dynamic routing, although static routing is also possible. DNS based routing rules(*). Mostly direct routing, although indirect is also possible. No dynamic stack routing. Distributed domains possible. Shared MTAs possible, but rare. Routing control not normally used. Bulk routing via SMTP envelope grouping; also possible, but not widely deployed, using the 'distribute protocol' [4]. Source routing supported, but strongly discouraged. No poor man's routing. Open (and hierarchical) routing community.
RFC822メール。 操作上のサービス。 コーディネーション: 分配にされる。 また、スタティックルーティングも可能ですが、ほとんどダイナミックルーティング。 DNSはルーティング規則(*)を基礎づけました。 ほとんど、間接的ですが、掘るのは、ダイレクトに、そうです。また、可能です。 ダイナミックなスタックルーティングがありません。 可能な分配されたドメイン。 共有されたMTAs可能ですが、まれです。 通常、使用されないコントロールを発送します。 SMTP封筒組分けでルーティングを膨らませてください。 可能ですがも、'プロトコルを分配してください'という[4]を使用して、広く配布されません。 サポートされますが、強くがっかりするソースルーティング。 どんな貧しい男性も掘っていません。 開いていて(階層的)のルーティング共同体。
(*) Sub-communities don't use DNS based routing: The MX records in the DNS are used to "attract" messages from the Internet to the
(*)サブ共同体はDNSのベースのルーティングを使用しません: DNSでのMX記録は、インターネットからのメッセージを「引き付けること」に使用されます。
Houttuin [Page 14] RFC 1711 Classifications in E-mail Routing October 1994
1994年10月に掘られるメールにおけるHouttuin[14ページ]RFC1711分類
"border" between the Internet and the sub-community. Thus from the Internet we have dynamic, directory based routing but once the "border" is reached, it is no longer possible to use MX records for mail routing, and thus some form of static routing is generally needed.
インターネットとサブ共同体の間の「接してください。」 したがって、私たちがダイナミックにするインターネットから、ディレクトリはルーティングを基礎づけましたが、「境界」にいったん達していると、メールルーティングにMX記録を使用するのがもう可能でなく、その結果、一般に、何らかのフォームのスタティックルーティングが必要です。
10.2. UUCP
10.2. UUCP
RFC 822 style mail. An operational service. Co-ordination: distributed. Mostly static routing, although dynamic routing is also possible. Table based routing rules. Mostly indirect routing. No dynamic stack routing. No distributed domains. Shared MTAs possible, but rare. Routing control not normally used. No bulk routing possible. Source routing (poor man's routing) still widely used by means of 'bang' addressing, but strongly discouraged. Open (and hierarchical) routing community.
RFC822はメールを流行に合わせます。 操作上のサービス。 コーディネーション: 分配にされる。 また、ダイナミックルーティングも可能ですが、ほとんどスタティックルーティング。 ベースのルーティング規則を見送ってください。 ほとんど間接的なルーティング。 ダイナミックなスタックルーティングがありません。 分配されたドメインがありません。 共有されたMTAs可能ですが、まれです。 通常、使用されないコントロールを発送します。 可能な大量のルーティングがありません。 ソースルーティング(貧者ルーティング) '衝撃音'アドレシングによってまだ広く使用されていますが、強くがっかりしています。 開いていて(階層的)のルーティング共同体。
10.3. EARN
10.3. 稼ぎます。
BITNET mail. An operational service. Co-ordination: The EARN Office, France. Static routing. Table based routing rules, although an X.500 based experiment is running. Mostly direct routing, although indirect is also possible. No dynamic stack routing. No distributed domains. No shared MTAs. Routing control not normally used. Bulk routing possible using the 'distribute protocol' [4]. Source routing not supported. No poor man's routing. Open routing community.
Bitnetメール。 操作上のサービス。 コーディネーション: オフィス、フランスを稼いでください。 スタティックルーティング。 X.500のベースの実験は稼働していますが、ベースのルーティング規則を見送ってください。 ほとんど、間接的ですが、掘るのは、ダイレクトに、そうです。また、可能です。 ダイナミックなスタックルーティングがありません。 分配されたドメインがありません。 共有されたMTAsがありません。 通常、使用されないコントロールを発送します。 'プロトコルを分配してください'という[4]を使用して、可能なルーティングを膨らませてください。 ルーティングがサポートしなかったソース。 どんな貧しい男性も掘っていません。 ルーティング共同体を開いてください。
10.4. GO-MHS
10.4. 碁-MHS
X.400 mail. An operational service. Co-ordination: GO-MHS Project Team, Switzerland. Mostly static routing, although dynamic routing is getting more and more deployed since the introduction of RFC 1465 [2]. Table based community-wide routing rules. Indirect routing.
X.400メール。 操作上のサービス。 コーディネーション: 碁-MHSはチーム、スイスを映し出します。 RFC1465[2]の導入以来ダイナミックルーティングはますます配布されていますが、ほとんどスタティックルーティング。 ベースの共同体全体のルーティング規則を見送ってください。 間接的なルーティング。
Dynamic stack routing. Distributed domains possible. Shared MTAs. Routing control not normally used, only to avoid routing control problems when routing international traffic to ADMDs. Bulk routing using X.400 'responsibility' envelope flags. Source routing supported for gatewaying to the Internet. No poor man's routing. Hierarchical, but open, routing community.
ダイナミックなスタックルーティング。 可能な分配されたドメイン。 共有されたMTAs。 通常、使用されない国際輸送をADMDsに発送するとき、制御の問題を発送するのを避けるコントロールを発送します。 X.400'責任'封筒旗を使用して、ルーティングを膨らませてください。 インターネットにgatewayingするようにサポートされたソースルーティング。 どんな貧しい男性も掘っていません。 階層的な、しかし、開いているルーティング共同体。
10.5. ADMD infrastructure
10.5. ADMDインフラストラクチャ
X.400 mail. An operational service. Co-ordination: The joint Administrative Management Domains (ADMDs), typically operated by PTTs. Mostly static routing. Indirect routing. Table based bilateral routing rules. No dynamic stack routing. Distributed domains not supported. Shared MTAs. Routing control used to prohibit routing of
X.400メール。 操作上のサービス。 コーディネーション: PTTによって通常運用された共同Administrative Management Domains(ADMDs)。 ほとんどスタティックルーティング。 間接的なルーティング。 ベースの双方のルーティング規則を見送ってください。 ダイナミックなスタックルーティングがありません。 サポートされなかった分配されたドメイン。 共有されたMTAs。 ルート設定コントロールは、以前はよく掘るのを禁止していました。
Houttuin [Page 15] RFC 1711 Classifications in E-mail Routing October 1994
1994年10月に掘られるメールにおけるHouttuin[15ページ]RFC1711分類
international traffic through PRMDs and to limit access to certain gateways. Bulk routing using X.400 'responsibility' envelope flags. Source routing possible for gatewaying to the Internet. No poor man's routing. Closed hierarchical routing community.
PRMDsを通したあるゲートウェイへの限界アクセスへの国際輸送。 X.400'責任'封筒旗を使用して、ルーティングを膨らませてください。 インターネットにgatewayingするのに、可能なソースルーティング。 どんな貧しい男性も掘っていません。 閉じている階層型ルーティング共同体。
10.6. Long Bud
10.6. 長いバッド
X.400 mail. A pilot project. Co-ordination: The IETF MHS-DS working group. Dynamic routing. X.500 based routing rules. Mostly indirect routing, although direct is also possible. Dynamic stack routing. Distributed domains. Shared MTAs. No routing control. Bulk routing using X.400 'responsibility' envelope flags. Source routing supported for gatewaying to the Internet. No poor man's routing. Open hierarchical routing community.
X.400メール。 試験計画。 コーディネーション: IETF MHS-DSワーキンググループ。 ダイナミックルーティング。 X.500はルーティング規則を基礎づけました。 ダイレクトですが、掘るのは、そうです。ほとんど間接的である、また、可能です。 ダイナミックなスタックルーティング。 分配されたドメイン。 共有されたMTAs。 ルーティングコントロールがありません。 X.400'責任'封筒旗を使用して、ルーティングを膨らませてください。 インターネットにgatewayingするようにサポートされたソースルーティング。 どんな貧しい男性も掘っていません。 階層型ルーティング共同体を開いてください。
10.7. X42D
10.7. X42D
X.400 mail. An experiment. Co-ordination: INFN, Italy. Dynamic routing. DNS based routing rules as defined in [9]. Mostly indirect routing, although direct is also possible. Dynamic stack routing. No distributed domains. Shared MTAs. No routing control. Bulk routing using X.400 'responsibility' envelope flags. Source routing supported for gatewaying to the Internet. No poor man's routing. Open hierarchical routing community.
X.400メール。 実験。 コーディネーション: INFN、イタリア。 ダイナミックルーティング。 DNSは[9]で定義されるようにルーティング規則を基礎づけました。 ダイレクトですが、掘るのは、そうです。ほとんど間接的である、また、可能です。 ダイナミックなスタックルーティング。 分配されたドメインがありません。 共有されたMTAs。 ルーティングコントロールがありません。 X.400'責任'封筒旗を使用して、ルーティングを膨らませてください。 インターネットにgatewayingするようにサポートされたソースルーティング。 どんな貧しい男性も掘っていません。 階層型ルーティング共同体を開いてください。
11. Conclusion
11. 結論
We have seen several dimensions in which mail routing can be classified. There are many more issues that were not discussed here, such as how exactly the routing databases are implemented, which algorithms to use for making the actual choices in dynamic routing, etc. A follow-up paper is planned to discuss such aspects in more detail.
私たちはメールルーティングを分類できる数個の寸法を見ました。 ここで議論しなかったずっと多くの問題があります、あれほど、ルーティングデータベースは実装されて、作成の使用へのどのアルゴリズムがダイナミックルーティングで実際の選択であるかなど。 追跡している論文は、さらに詳細にそのような局面について議論するために計画されています。
So far, the author has tried to keep this paper free of opinion, but he would like to conclude by listing his own favourite routing options (without any further explanation or justification; please feel free to disagree):
今までのところ、作者は意見から自由にこの紙を保管しようとしましたが、彼は彼自身のお気に入りのルーティングオプションを記載することによって、結論を下したがっています(少しも詳細な説明や正当化なしで; 遠慮なく意見を異にしてください):
Static/dynamic: Dynamic
Direct/indirect: Every routing community has its own
optimum level of indirection
User routing: Support
Routing control: Avoid
Bulk routing: Efficient distribution should be
transparent at mail level, but we
may need better e-mail models
before this becomes possible
静電気/動力: 動力は間接的に/を指示します: あらゆるルーティング共同体には、それ自身の最適なレベルの間接指定Userルーティングがあります: ルート設定がコントロールであるとサポートしてください: Bulkルーティングを避けてください: 効率的な分配はメールレベルでわかりやすいはずですが、これが可能になる前に私たちは、より良いメールモデルを必要とするかもしれません。
Houttuin [Page 16] RFC 1711 Classifications in E-mail Routing October 1994
1994年10月に掘られるメールにおけるHouttuin[16ページ]RFC1711分類
Source routing: Avoid where possible
Poor man's routing: Avoid
ソースルーティング: Poor男性が掘っているのが可能であるところで以下を避けてください。 避けます。
12. Abbreviations
12. 略語
ADMD Administration Management Domain
CCITT Comite Consultatif International de
Telegraphique et Telephonique
CONS Connection Oriented Network Service
DDA Domain Defined Attribute
DNS Domain Name System
GO-MHS Global Open MHS
IP Internet Protocol
ISO International Organisation for Standardisation
Long Bud Not an abbreviation
MHS Message Handling System
MHS-DS MHS and Directory Services
MTA Message Transfer Agent
MTS Message Transfer System
MX Mail eXchanger
O/R address Originator/Recipient address
PP Not an abbreviation
PRMD Private Management Domain
RARE Reseaux Associes pour la Recherche Europeenne
RFC Internet Request for Comments
RTR RARE Technical Report
SMTP Simple Mail Transfer Protocol
STD Internet Standard RFC
TCP Transfer Control Protocol
TP0 Transport Protocol Class 0
UA User Agent
UUCP UNIX to UNIX CoPy
WEP Well-known Entry Point
Standardisation LongバッドNotのための国際ADMDのde Telegraphique et TelephoniqueコンズのConnection Oriented Network Service DDA Domain Defined Attribute DNSドメインネームシステムGO-MHS Global政権Management Domain CCITT Comite ConsultatifオープンのMHS IPのインターネットのプロトコルのISOの国際Organisationは略語MHS Message Handling System MHS-DS MHSとディレクトリサービスMTA Message TransferエージェントMTS Messageです; System MXメールeXchanger O/RアドレスOriginator/受取人アドレスPP Notを移してください、略語PRMD兵士のManagement Domain RARE Reseaux AssociesはComments RTR RARE Technical Report SMTPシンプルメールトランスファプロトコルSTDインターネットStandard RFC TCP Transfer ControlプロトコルTP0 TransportプロトコルClass0UA UserエージェントUUCP UNIXのためにUNIXのCoPy WEP Wellによって知られているEntry Pointにla Recherche Europeenne RFCインターネットRequestを注ぎます。
13. References
13. 参照
[1] Houttuin, J., "C-BoMBS : A Classification of Breeds
Of Mail Based Servers", RARE WG-MSG Work in Progress,
April 1994.
[1] Houttuin(J.)は「以下をCで爆撃します」。 まれなWG-MSGは、進歩、1994年4月に「メールのベースのサーバの種類の分類」と扱います。
[2] Eppenberger, E., "Routing Coordination for X.400 MHS
Services Within a Multi Protocol / Multi Network
Environment Table Format V3 for Static Routing",
RFC 1465, SWITCH, May 1993.
[2] Eppenberger、E.、「スタティックルーティングのためのマルチプロトコル/マルチネットワーク環境テーブル形式V3の中のX.400 MHSサービスのためのルート設定コーディネート」、RFC1465は切り替わります、1993年5月。
[3] Kille, S., "MHS use of the Directory to support MHS
routing", Work in Progress, July 1993.
[3]Kille、S.、「MHSがルーティングであるとサポートするディレクトリのMHS使用」、Progress、1993年7月のWork。
Houttuin [Page 17] RFC 1711 Classifications in E-mail Routing October 1994
1994年10月に掘られるメールにおけるHouttuin[17ページ]RFC1711分類
[4] Thomas, E., "Listserv Distribute Protocol",
RFC 1429, Swedish University Network, February 1993.
[4] トーマス、E.、「リストサーブはプロトコルを分配する」RFC1429、スウェーデンの大学ネットワーク、1993年2月。
[5] Kille, S., "Mapping between X.400(1988) / ISO 10021
and RFC 822", RFC 1327, RARE RTR 2, University
College London, May 1992.
[5]Kille、S.、「X.400(1988)/ISO10021とRFC822インチ、RFC1327、まれなRTR2、ユニバーシティ・カレッジロンドンの間で5月1992日を写像すること。
[6] Braden, R., Editor, "Requirements for Internet Hosts
- Application and Support", STD 3, RFC 1123, USC/
Information Sciences Institute, October 1989.
[6] ブレーデン、R.、エディタ、「インターネットホストのための要件--、アプリケーションとサポート、」、STD3、RFC1123(科学が1989年10月に設けるUSC/情報)
[7] Partridge, C., "Mail Routing and the Domain System",
STD 14, RFC 974, BBN, January 1986.
[7] ヤマウズラ、C.が「ルート設定とドメインシステムを郵送する」、STD14、RFC974、BBN、1月1986日
[8] Hansen, A. and R. Hagens, "Operational Requirements
for X.400 Management Domains in the GO-MHS
Community", Work in Progress, March 1993.
[8] 「碁-MHS共同体のX.400管理ドメインのための操作上の要件」というハンセン、A.、およびR.Hagensは進行中(1993年3月)で働いています。
[9] Allocchio, C., Bonito, A., Cole, B., Giordano, S.,
and R. Hagens "Using the Internet DNS to Distribute
RFC1327 Mail Address Mapping Tables", RFC 1664,
GARR-Italy, Cisco Systems Inc, Centro Svizzero
Calcolo Scientific, Advanced Network & Services,
February 1993.
[9]Allocchio、C.、かつお、A.、コール、B.、ジョルダーノ、S.、およびR.Hagensが「テーブルを写像するRFC1327郵便の宛先を配布するのにインターネットDNSを使用し」て、RFC1664、シスコシステムズInc、セントロSvizzero Calcolo科学的なガー-イタリアはネットワークとサービス(1993年2月)を唱えました。
[10] Houttuin, J., "A Tutorial on Gatewaying between X.400
and Internet Mail", RFC 1506, RTR 6, RARE Secretariat,
August 1993.
[10]Houttuin、J.、「X.400とインターネットメールの間のGatewayingの上のチュートリアル」、RFC1506、RTR6、まれな事務局、1993年8月。
[11] Postel, J., "Simple Mail Transfer Protocol", STD 10,
RFC 821, USC/Information Sciences Institute, August
1982.
[11] ポステル、J.、「簡単なメール転送プロトコル」、STD10、RFC821、科学が1982年8月に設けるUSC/情報。
[12] Crocker, D., "Standard for the Format of ARPA
Internet Text Messages", STD 11, RFC 822, UDEL,
August 1982.
[12] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、STD11、RFC822、UDEL、1982年8月。
[13] Alvestrand, H.T., et al, "Introducing Project Long
Bud Internet Pilot Project for the Deployment of
X.500 Directory Information in Support of X.400
Routing", Work in Progress, June 1993.
[13]Alvestrand、H.T.、他、「X.400ルート設定を支持してX.500ディレクトリ情報の展開のためのプロジェクトの長い芽のインターネット試験計画を紹介します」、Progress(1993年6月)のWork。
[14] Kille, S., "A Simple Profile for MHS use of
Directory", Work in Progress, July 1993.
[14]Kille、S.、「ディレクトリのMHS使用のためのSimple Profile」、Progress、1993年7月のWork。
[15] Kille, S., "MHS use of the Directory to Support
Distribution Lists", Work in Progress, November 1992.
[15]Kille、S.、「Support Distribution ListsへのディレクトリのMHS使用」、Progress、1992年11月のWork。
Houttuin [Page 18] RFC 1711 Classifications in E-mail Routing October 1994
1994年10月に掘られるメールにおけるHouttuin[18ページ]RFC1711分類
[16] Eppenberger, U., "X.500 directory service usage for
X.400 e-mail", Computer Networks for Research in
Europe No.1: Computer Networks and ISDN Systems 25,
Suppl.1 (1993) S3-8, September 1993.
[16]Eppenberger、U.、「X.400メールのためのX.500ディレクトリサービス用法」、ヨーロッパNo.1のResearchのためのコンピュータNetworks: コンピュータネットワークとISDNシステム25、Suppl.1(1993)S3-8、1993年9月。
[17] CCITT Recommendations X.400 - X.430. Data
Communication Networks: Message Handling Systems.
CCITT Red Book, Vol. VIII - Fasc. VIII.7, Malaga-
Torremolinos 1984.
[17]CCITT推薦X.400--X.430。 データ通信ネットワーク: メッセージハンドリングシステムCCITT職員録、Vol.VIII--Fasc。 VIII.7、マラガトレモリノス1984。
[18] CCITT Recommendations X.400 - X.420. Data
Communication Networks: Message Handling Systems.
CCITT Blue Book, Vol. VIII - Fasc. VIII.7, Melbourne
1988.
[18]CCITT推薦X.400--X.420。 データ通信ネットワーク: メッセージハンドリングシステムCCITT紳士録、Vol.VIII--Fasc。 VIII.7、メルボルン1988。
14. Security Considerations
14. セキュリティ問題
Security issues are discussed in section 3.1.
セクション3.1で安全保障問題について議論します。
15. Author's Address
15. 作者のアドレス
Jeroen Houttuin RARE Secretariat Singel 466-468 NL-1017 AW Amsterdam The Netherlands
ジョロエン・Houttuinのまれな事務局Singel466-468NL-1017 AWアムステルダムオランダ
Phone: +31 20 639 11 31 Fax: +31 20 639 32 89 EMail: houttuin@rare.nl
以下に電話をしてください。 +31 20 639、11 31、Fax: +31 20 639 32 89はメールされます: houttuin@rare.nl
Houttuin [Page 19]
Houttuin[19ページ]
一覧
スポンサーリンク
