rfc1711.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 1,068 行 · 第 1/4 页
TXT
1,068 行
Network Working Group J. Houttuin
Request for Comments: 1711 RARE
Category: Informational October 1994
Classifications in E-mail Routing
Status of this 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.
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.
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
Houttuin [Page 1]
RFC 1711 Classifications in E-mail Routing October 1994
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
1. Naming, addressing and routing
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.
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)
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.
Houttuin [Page 2]
RFC 1711 Classifications in E-mail Routing October 1994
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]).
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 |
+-----------------------------------------+
Figure 1. A mail route
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
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.
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).
Other information (e.g., line load, cost, availability) can then be
used to choose one route from the routing indicators.
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.
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
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.
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.
Houttuin [Page 4]
RFC 1711 Classifications in E-mail Routing October 1994
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.
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.
For reasons of flexibility and reliability, dynamic routing is almost
always the preferred method.
3. Direct versus indirect
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)
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?