As per Relevance of the word distribute, we have this rfc below:
Network Working Group J.
Request for Comments: 1711
Category: Informational October 1994
Classifications in E-mail
Status of this
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
This paper presents a classification for e-mail routing issues.
clearly defines commonly used terminology such as static routing
store-and-forward routing, source routing and others. Real
examples show which routing options are used in existing projects
The goal is to define all terminology in one reference paper.
will also help relatively new mail system managers to understand
issues and make the right choices. The reader is expected to
have a solid understanding of general networking terminology
In this paper, the word Message Transfer Agent (MTA) is used
describe a routing entity, which can be an X.400 MTA, a UNIX mailer
or any other piece of software performing mail routing functions.
MTA processes the so called envelope information of a message.
term User Agent (UA) is used to describe a piece of
performing user related mail functions. It processes the contents
a message's envelope, i.e., the header fields and body parts
Table of
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
A name uniquely identifies a network object (without loss
generality, we will assume the 'object' is a person).
Once a person's name is known, it can be used as a key to
his address
An address uniquely defines where the person is located. It
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
related part (e.g., the RFC 822 localpart or in X.400 a DDA
Surname attribute). The domain related part of an address
consists of several components, which normally have a
hierarchical order. These domain levels can be used for
purposes, as we will see later
Once a person's address is known, it can be used as a key
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
directed Message Transfer
(MTS) graph that a message
for one originator/recipient pair
(see Figure 1)
Note that, in this definition, the User Agents (UAs) are not part
the route themselves. Thus if a message is redirected at the
level, a new route is established from the redirecting UA to the
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
may start from a UA, but stop at a certain point because one of
MTAs is unable to take any further routing decisions. If
happens, a warning is generated by the MTA (not by a UA), and
back to the originator of the undeliverable message. It may
happen that none of the leaves is a UA, for instance if a
message as discussed above turns out to be undeliverable itself.
cautious reader may have noticed that this is a dangerous situation
Special precautions are needed to avoid loops in such cases (
[1]).
user
| ^
v |
+-----------------------------------------+
| | ^ |
| v | |
| +-----+ +-----+ |
| | UA | | UA | |
| +-----+ +-----+ |
| | ^ |
| v | |
| +-------------------------------------+ |
| | v ^ | |
| | v ^ | |
| | v ^ | |
| | +-----+ +-----+ | |
| | | MTA |.....................| MTA | | |
| | +-----+ +-----+ | |
| | v \ ^ | |
| | v \................ ^ | |
| | v \ ^ | | NB The actual
| | +-----+ \ +-----+ | | is drawn
| | | MTA |>>>>>>>>>>>>>>>>>>>>>| MTA | | | v ^
| | +-----+ +-----+ | | v ^
| | Message Transfer System | | v >>>>>>>> ^
| +-------------------------------------+ |
| Message Handling System |
+-----------------------------------------+
Figure 1. A mail
It is important that the graph is directed, because routes are
necessarily symmetric. A reply to a message may be sent over
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
recipients, there will also be two mail routes. Since the delivery
a UA (not the UA itself) is a part of the route, this definition
still valid if two UAs are connected to the same MTA
The words '.. for one originator-recipient pair.' in the
do not imply that this pair provides the MTA with all
information to choose one specific route. One originator-
pair may give an MTA the possibility to choose from a number
possible routes, the so-called routing indicators (see chapter 2).
Other information (e.g., line load, cost, availability) can then
used to choose one route from the routing indicators
Routing is defined as the process of establishing routes. Note
this is a distributed process; every intermediate MTA takes its
routing decisions, thus contributing to the establishment of
complete route
Taking a routing decision is not a purely algorithmic process
otherwise there would hardly be any difference between an address
a route. The address is used as a key to find a route, typically
some sort of rule-based routing database. The possible options
realising this database and algorithms for using it are the
of the rest of this paper
2. Static versus
Dynamic (mail) routing allows a routing decision to be influenced
external factors, such as system availability, network load, etc.
contrast, static (mail) routing is not able to adapt to
constraints. Static routing can be viewed as an extremely simple
of dynamic routing, namely where there is only one choice for
routing decision
Dynamic routing algorithms normally use some kind of
databases to store and retrieve routing information, whereas
routing is typically implemented in routing tables
Note that dynamic routing can occur at different layers: at the
level, dynamic routing might allow a message to be relayed to
choice of MTAs (the routing indicators). As an example, consider
Internet mechanism of using multiple Mail eXchanger (MX) records
describing MTAs that can serve a domain. If the primary choice MTA
not available, a second choice MTA can be tried. If this
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
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
using one certain stack, e.g., RFC1006/TCP/IP, but is also able
accept incoming calls over another stack, such as TP0/CONS/X.25.
will call this dynamic stack routing. Theoretically, dynamic
routing should be transparent to the mail routing application, and
thus not a part of dynamic mail routing. It is mentioned here
in existing products, dynamic stack routing is often very
visible at the mail configuration level, so MTA managers should
least be aware of it
Although static routing is often table based, not all table
routing algorithms are necessarily static in nature. As a
example, X.400 routing according to RFC 1465 [2] is clearly
based, but at the same time allows a fairly dynamic kind of
routing (as well as dynamic stack routing, which in this approach
cleanly separated from the dynamic mail routing part). A mail
can specify a choice of so-called RELAY-MTAs (formerly called WEPs
that will serve it, each with a priority and maximum number
retries
For reasons of flexibility and reliability, dynamic routing is
always the preferred method
3. Direct versus
Direct routing allows the originator's MTA to contact the recipient'
MTA directly, whereas indirect routing (also known as store-and
forward routing) uses intermediate MTAs to relay the message
the recipient. It is difficult to clearly distinguish between
and indirect routing: direct routing assumes the existence of a
meshed routing topology, whereas indirect routing assumes
existence of a more tree-like hierarchical topology. Mail routing
most existing networks is upto some degree indirect. Networks can
classified as being more or less direct according for the
rule of thumb: larger fan out of the routing tree means more
routing, greater depth of the tree means less direct routing.
kinds of indirect routing are presented here: firewalls (downstream
and default routes (upstream).
3.1.
A firewall 'attracts' all messages for a certain set of
(the address sub space behind the firewall) from the outside e-
world to a central relaying MTA (the firewall). This is done
publishing routes to all other MTAs that must relay their
over this firewall (the attracted community). Note that
knowledge should be used to route messages within the address
behind the firewall. An example for this is presented later on.
Houttuin [Page 5]
RFC 1711 Classifications in E-mail Routing October 1994
exist many reasons for using firewalls, e.g., security
or to concentrate the management for a given domain onto one
managed system
The Internet mail system would allow all mail hosts connected to
Internet to directly accept mail from any other host, but not
hosts use this possibility. Many domains are hidden behind one
more 'Mail eXchanger' (MX), which offer to relay all incoming
for those domains. The RELAY-MTAs mentioned earlier can also
considered firewall systems
+-----------------------------------+
| |
| The rest of the e-mail world |
| |
+-----------------------------------+
\ | | /
\ | | /
\| | /
v
+--------------+
|Firewall MTA A
+--------------+
^ / ^ \ ^
/ / | \ \
/ / | \ \
Default route--o / | \ o---Default
/ / | \ \
/ / | \ \
/ v v v \
+-----+ +-----+ +-------+
|MTA B|<----|MTA C| |MTA D |
+-----+ +-----+ +-------+
/ | | | \
/ | | | \
/ | | | \
+----+ +----+ +----+ +----+ +----+
| UA | | UA | | UA | | UA | | UA |
+----+ +----+ +----+ +----+ +----+
Figure 2. Firewall and default
3.2. Default versus rule
Default routing is to outgoing mail what a firewall is for
mail, and is thus often used in conjunction with firewalls. It
about the simplest routing algorithm one can think of: route
message to one and the same MTA, which is trusted to take
Houttuin [Page 6]
RFC 1711 Classifications in E-mail Routing October 1994
care of routing the message towards its destination. Pure
routing is rather useless; it is normally used as a fall
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
In order to avoid loops, it is not acceptable for all MTAs within
certain routing community (see chapter 9) to use default routing.
least one MTA should be able to access all routing rules for
community. Consider the following example: An X.400 MTA A,
serves the organisation organisational unit OU=orgunA within
organisation O=org, receives a message for the domain O=org
OU=orgunB;. Since MTA B in the same organisation serves all
OUs, A will default route the message to B. Suppose that B would
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,
routing set-up will lead to a loop. The decision that a certain
does not exist can only be made if at least one of the MTAs
knowledge of all existing OUs under O
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
an upstream indirection. MTA B and D use default routing; they
only route to one other MTA, MTA A
For more detailed information, please refer to [3], which lists
pros and cons of both approaches. Your choice will depend on
factors that are specific for your messaging environment
4. Routing at user
Normally a message is routed down to the deepest level domain,
then delivered to the recipient per default routing. I.e., every
in this domain is considered to have his mailbox uniquely
within this domain on the same MTA, and every user on that MTA can
distinguished within this domain. Exceptions can occur when the
within a domain have their mailboxes on different MTAs (
domain), or when several domains exist on the same MTA (shared MTA).
4.1. Distributed
Routing is normally performed down to a certain domain level. Mail
all users that are directly registered under this domain is
delivered per default routing, i.e., delivered locally. Explicit
routing (i.e., rule-based routing on user level attributes
to a fixed table listing all users) may be necessary when not
Houttuin [Page 7]
RFC 1711 Classifications in E-mail Routing October 1994
users have their UAs connected to the same MTA
Note that the whole issue of distributed domains is nothing more
a special case of the problems discussed in chapter 3.2: '
versus rule-based'. The only reason for mentioning this in a
chapter is that there are many software products that don't deal
routing based on local address parts in the same way as with
based on domain related address parts
As an example, consider an organisation where two mail platforms
available. Some users prefer using platform A, others prefer
B. Of course, the easiest solution would be to create a subdomain
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
world using only one domain, this scheme cannot be used, at least
without special precautions (see the paragraph about avoiding
in chapter 3.2).
+----------+ +---------------------------+
| MTA A | | Shared MTA B |
+----------+ +---------------------------+
| | / | | |
+-----------------/----+ +-----------+ +----------+
| | | / | | | | | | | |
| +--+ +--+ +--+/ | | +--+ +--+ | | +--+ |
| |UA| |UA| |UA| | | |UA| |UA| | | |UA| |
| +--+ +--+ +--+ | | +--+ +--+ | | +--+ |
| Distributed Domain A | | Domain B | | Domain C |
+----------------------+ +-----------+ +----------+
Figure 3. Distributed domains and shared
Another possibility to have uniform addresses in outgoing e-mail
despite the fact that a domain is distributed, is to make
decisions on information in the local part of the address, e.g.,
X.400 the Surname in exactly the same manner as making
decisions on any other attributes. Thus products and
algorithms that are able to route on user related address parts
said to support distributed domains
4.2. Shared
The opposite of a distributed domain is a shared MTA: several
are routed locally on the same MTA. These domains sharing one MTA
cause problems when two or more domains have a local user with
same name
Houttuin [Page 8]
RFC 1711 Classifications in E-mail Routing October 1994
Theoretically, this problem doesn't exist: the address is
routed down to the deepest domain level, and within that level,
will only be one user with that name (let's at least assume this
simplicity). Some products however use only one database of all
locally connected to this MTA instead of one database per domain,
that default user routing at the deepest level can lead to conflicts
It is beyond the scope of this document to describe the tricks
to avoid these conflicts when using such products
5. Routing
Routing control means that routing decisions can be affected by
originator of a message. This normally takes the form of
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
to be chargeable, or where ADMDs can refuse messages that
relayed to them over international PRMD connections; a policy that
not allowed in the CCITT version of the standards (as opposed to
ISO version). Of course, the PRMDs can also perform routing
themselves in order to circumvent such problems
Although there may be good reasons for using routing control,
must be aware that it can make the messaging
unpredictable for end-users. Where using routing control
unavoidable, the originator whose message has been rejected is
to appreciate receiving a message, clearly telling him where and
routing of his message was refused, whom to contact, and what
are available to avoid such rejections in the future
6. Bulk
In order to reduce network traffic, intelligent mailers may prefer
message addressed to a group of remote users to be transferred to
remote domain only once, thus postponing the 'explosion' into
copies. This technique, called bulk routing, is especially
when an MTA hosts large mailing lists
Several possibilities exist. In a typical hierarchical firewall
system, bulk routing can be done almost automatically by
MTAs. For instance, in an X.400 community, a large
distribution list can create a message with an envelope
1000 recipient addresses, some of which can probably be grouped
the MTA depending on whether they can be routed further to the
remote MTA, according to the normal routing implementation at
MTA. The size and number of these groups will largely depend on
indirect this routing implementation is. In the GO-MHS community,
Houttuin [Page 9]
RFC 1711 Classifications in E-mail Routing October 1994
number of groups will almost always be less than 50, which provides
rather fair distribution of traffic load over the involved MTAs (
is, fair according to the author's taste, who is not aware of
existing fair mail load distribution formula).
As an extreme example, the simplest way to automatically (i.e.,
without using special optimisation tools) bulk route mail is to
one default route. Any outgoing message, regardless of the number
recipients, will be routed over the default route only once.
default remote MTA will then have to break up the message (envelope
into several copies and is thus responsible for the actual
and distribution. NB. This mechanism can be exploited to shift
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,
may be worth to check first if the requesting party is running
planning to run large mailing lists
In more direct routing environments, such as BITNET, bulk
will not function as automatically as described above.
special precautions, an MTA would open a direct connection to
single host that occurs in the message's envelope, regardless
whether some of these hosts are far away from this MTA, but close
each other, measured by underlying network topology. This can
lead to a waste of expensive bandwidth. In order to be able to
such cases, and to act upon it by sending one single copy over
expensive link and have it distributed at some remote hosts, an
must have additional knowledge of the relation between mail
and the underlying network topology
BITNET uses the distribute protocol [4] for this purpose. A
set of hosts is published to have the required topology knowledge
to be able to efficiently distribute the mail on behalf of
MTAs, who can explicitly route all bulk mail to one of those hosts
The complete message, including the envelope, is encoded in a
body, which starts with a distribution request to the
server. This server will break up the rest of the body into
original envelope and contents and then use it's topology
to efficiently distribute the original message. Note that
protocol violates the conceptual model of the layering of MTA and
functionality, but it is about the only trick that will work in
very direct routing environment. It is only needed to overrule a non
efficient (for large mailing lists) routing topology
Bulk routing is an area where mail routing issues start to
with the area of distributing netnews (bulletin board services).
Several organisations, such as ISO, RARE and the IETF have
initiatives in the direction of harmonising the two worlds. The
Houttuin [Page 10]
RFC 1711 Classifications in E-mail Routing October 1994
results, be it standards or products, are not expected before 1995
though
7. Source
Source routing was originally intended to allow a user to force
message to take a certain route. The mechanism works as follows:
MTA that the user wants the message to be routed through
integrated into the address. Once the message has arrived at
specified MTA, that MTA strips itself from the source-routed
and routes the remaining address in the usual way. This mechanism
called explicit source routing and can be useful if a user wants
test a routing path or force a message to be routed over a faster
cheaper, more reliable, or otherwise preferred path
For instance, if the Internet user user@uni-a.edu wants to test
mail connections to and from a remote domain uni-b.edu, he
source route a message to himself over the MTA at uni-b.edu
addressing the mail to: @uni-b.edu:user@uni-a.
Source routing need not always be explicit. Source routes can also
generated automatically by a gateway, in which case we speak
address rooting (to that gateway). The gateway will root itself
the message by putting its own domain in the source route
address, thus ensuring that any replies to the gatewayed message
be routed back through the same gateway
Example 1: RFC 1327 left hand side encoding (see [5]) performed
the gateway 'gw.ch':
C=zz;A=a;P=p;O=oo;S=plork ->
"/C=zz/A=a/P=p/O=oo/S=plork/"@gw.
Example 2: RFC 1327 DDA mapping (see [5]) performed by the
C=zz;A=a
bush@dole.us ->
DD.RFC-822=bush(a)dole.us;C=zz;A=a
Example 3: the so-called %-hack
user%final.domain@1st.
When the relaying host '1st.relay' receives the message, it
its own domain part and interprets the localpart 'user%final.domain':
it changes the % to an @ sign and relays the message to the
user@final.
Houttuin [Page 11]
RFC 1711 Classifications in E-mail Routing October 1994
Example 4: Another example of the already mentioned explicit
routing, this time through two relays
@1st.relay,@2nd.relay:user@final.
In the Internet, use of explicit source routing is
discouraged (see [6]), one reason being that not all mail relays
handle such addresses in a consistent manner. Apart from that,
need to use explicit source routing has disappeared over the
decennia. In earlier days, when the RFC 822 world consisted of
sparsely connected 'mail islands', source routing was
needed to make sure that a message was routed through a gateway
was known to be connected to a remote island. Nowadays, the RFC 822
world is almost fully interconnected through the Internet, so
need for end-users to have knowledge of the mail network's
has become superfluous
8. Poor man's
If we combine static, indirect and source routing, we get what
commonly known as "poor man's routing". The user thus specifies
complete route in the address. A classic example is the old UUCP
style addressing
host1!host2!host3!host4!
Poor man's routing is presented here for historical reasons only
Since, for reasons discussed earlier, most present
discourage source routing and prefer dynamic over static routing
poor man's routing is not widely deployed anymore
9. Routing
A routing community can be defined as follows
Routing community: a set of MTAs X, with the
that for any address a, every
in X except a subset Ya will
the option, according to an
upon set of routing rules,
directly route that address to
least one MTA in Ya
Which is a rather formal way of describing that a routing
consists of a set of MTAs (and human operators) that agreed on
common set of rules on how to route messages among each other
Houttuin [Page 12]
RFC 1711 Classifications in E-mail Routing October 1994
An example of a routing community is the large Internet
community, in which the agreed rules are implemented in the
Name System (DNS). For details, refer to [7]. The subset Ya is
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
not considered direct members of this community, but normally
their own smaller routing community, with one host (the
exchanger/default route) belonging to both communities
Another example is the GO-MHS community, consisting of a set
documented RELAY-MTAs (formerly called WEPs, Well-known
Points). Routing communities can be further classified depending
the openness and topology of their routing rules. [3] defines
classes of routing communities
Local community: The scope of a single MTA.
the MTAs view of the set
bilateral routing agreements,
routing information local to
MTA. Example: any local MTA
Closed community: This is like a local community,
involves more than one MTA.
idea is to route messages
within this closed community.
small subset of the involved
can be in another community
well, in order to get
connectivity to the outside world
as described earlier. Example:
set of Private Management
(PRMDs) representing the
organisation in multiple countries
Open community: All routing information is
and any MTA is invited to use it
Example: the Internet
Hierarchical community:A subtree of the O/R address tree
Note that the subtree will
practice often be pruned; sub-sub
trees may form their own
community. Example: GO-MHS
This classification cannot always be followed too strictly.
example, completely closed communities are relatively rare. In
for e-mail to be an effective communication tool, an
will typically designate at least one of its MTAs as a gateway
Houttuin [Page 13]
RFC 1711 Classifications in E-mail Routing October 1994
another routing community, for instance to the Internet.
organisation will register an Internet domain, say 'org.net',
points to this gateway, and thus acts as a firewall from the
to the domain 'org.net', and as a default route from the
community to the rest of the Internet. At this stage, the gateway
can be regarded as being a member of any of the four types of
communities. The reader is invited to check this himself
Especially the distinction between open and closed communities is
always easy. To some extent, most routing communities are open,
least among their own participants. It is just that some
communities are more open than others. Also, even the most
routing community is not just open to anyone. It is not enough for
community participant to use the community's routing rules
connect to any other MTA in the community. The participant
typically also have to fulfil an agreed upon set of
requirements, for example the Internet host requirements [6] or
GO-MHS domain requirements [8].
The most open routing community known today is certainly the
mail community. As for X.400 routing communities, some problems
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
designed or configured to use passwords for setting up
connections. This, together with the fact that X.400 routing
originally designed to be hierarchical, is one of the main
why most X.400 communities today are either closed or hierarchical
10.
In this chapter some of the routing classifications described
are assigned to existing mail services and projects
10.1. Internet
RFC 822 mail. An operational service. Co-ordination: distributed
Mostly dynamic routing, although static routing is also possible.
based routing rules(*). Mostly direct routing, although indirect
also possible. No dynamic stack routing. Distributed
possible. Shared MTAs possible, but rare. Routing control
normally used. Bulk routing via SMTP envelope grouping;
possible, but not widely deployed, using the 'distribute protocol
[4]. Source routing supported, but strongly discouraged. No
man's routing. Open (and hierarchical) routing community
(*) Sub-communities don't use DNS based routing: The MX records
the DNS are used to "attract" messages from the Internet to
Houttuin [Page 14]
RFC 1711 Classifications in E-mail Routing October 1994
"border" between the Internet and the sub-community. Thus from
Internet we have dynamic, directory based routing but once
"border" is reached, it is no longer possible to use MX records
mail routing, and thus some form of static routing is
needed
10.2.
RFC 822 style mail. An operational service. Co-ordination
distributed. Mostly static routing, although dynamic routing is
possible. Table based routing rules. Mostly indirect routing.
dynamic stack routing. No distributed domains. Shared MTAs possible
but rare. Routing control not normally used. No bulk
possible. Source routing (poor man's routing) still widely used
means of 'bang' addressing, but strongly discouraged. Open (
hierarchical) routing community
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
is also possible. No dynamic stack routing. No distributed domains
No shared MTAs. Routing control not normally used. Bulk
possible using the 'distribute protocol' [4]. Source routing
supported. No poor man's routing. Open routing community
10.4. GO-
X.400 mail. An operational service. Co-ordination: GO-MHS
Team, Switzerland. Mostly static routing, although dynamic routing
getting more and more deployed since the introduction of RFC 1465
[2]. Table based community-wide routing rules. Indirect routing
Dynamic stack routing. Distributed domains possible. Shared MTAs
Routing control not normally used, only to avoid routing
problems when routing international traffic to ADMDs. Bulk
using X.400 'responsibility' envelope flags. Source routing
for gatewaying to the Internet. No poor man's routing. Hierarchical
but open, routing community
10.5. ADMD
X.400 mail. An operational service. Co-ordination: The
Administrative Management Domains (ADMDs), typically operated
PTTs. Mostly static routing. Indirect routing. Table based
routing rules. No dynamic stack routing. Distributed domains
supported. Shared MTAs. Routing control used to prohibit routing
Houttuin [Page 15]
RFC 1711 Classifications in E-mail Routing October 1994
international traffic through PRMDs and to limit access to
gateways. Bulk routing using X.400 'responsibility' envelope flags
Source routing possible for gatewaying to the Internet. No poor man'
routing. Closed hierarchical routing community
10.6. Long
X.400 mail. A pilot project. Co-ordination: The IETF MHS-DS
group. Dynamic routing. X.500 based routing rules. Mostly
routing, although direct is also possible. Dynamic stack routing
Distributed domains. Shared MTAs. No routing control. Bulk
using X.400 'responsibility' envelope flags. Source routing
for gatewaying to the Internet. No poor man's routing.
hierarchical routing community
10.7. X42
X.400 mail. An experiment. Co-ordination: INFN, Italy.
routing. DNS based routing rules as defined in [9]. Mostly
routing, although direct is also possible. Dynamic stack routing.
distributed domains. Shared MTAs. No routing control. Bulk
using X.400 'responsibility' envelope flags. Source routing
for gatewaying to the Internet. No poor man's routing.
hierarchical routing community
11.
We have seen several dimensions in which mail routing can
classified. There are many more issues that were not discussed here
such as how exactly the routing databases are implemented,
algorithms to use for making the actual choices in dynamic routing
etc. A follow-up paper is planned to discuss such aspects in
detail
So far, the author has tried to keep this paper free of opinion,
he would like to conclude by listing his own favourite
options (without any further explanation or justification;
feel free to disagree):
Static/dynamic:
Direct/indirect: Every routing community has its
optimum level of
User routing:
Routing control:
Bulk routing: Efficient distribution should
transparent at mail level, but
may need better e-mail
before this becomes
Houttuin [Page 16]
RFC 1711 Classifications in E-mail Routing October 1994
Source routing: Avoid where
Poor man's routing:
12.
ADMD Administration Management
CCITT Comite Consultatif International
Telegraphique et
CONS Connection Oriented Network
DDA Domain Defined
DNS Domain Name
GO-MHS Global Open
IP Internet
ISO International Organisation for
Long Bud Not an
MHS Message Handling
MHS-DS MHS and Directory
MTA Message Transfer
MTS Message Transfer
MX Mail
O/R address Originator/Recipient
PP Not an
PRMD Private Management
RARE Reseaux Associes pour la Recherche
RFC Internet Request for
RTR RARE Technical
SMTP Simple Mail Transfer
STD Internet Standard
TCP Transfer Control
TP0 Transport Protocol Class 0
UA User
UUCP UNIX to UNIX
WEP Well-known Entry
13.
[1] Houttuin, J., "C-BoMBS : A Classification of
Of Mail Based Servers", RARE WG-MSG Work in Progress
April 1994.
[2] Eppenberger, E., "Routing Coordination for X.400
Services Within a Multi Protocol / Multi
Environment Table Format V3 for Static Routing",
RFC 1465, SWITCH, May 1993.
[3] Kille, S., "MHS use of the Directory to support
routing", Work in Progress, July 1993.
Houttuin [Page 17]
RFC 1711 Classifications in E-mail Routing October 1994
[4] Thomas, E., "Listserv Distribute Protocol",
RFC 1429, Swedish University Network, February 1993.
[5] Kille, S., "Mapping between X.400(1988) / ISO 10021
and RFC 822", RFC 1327, RARE RTR 2,
College London, May 1992.
[6] Braden, R., Editor, "Requirements for Internet
- Application and Support", STD 3, RFC 1123, USC
Information Sciences Institute, October 1989.
[7] Partridge, C., "Mail Routing and the Domain System",
STD 14, RFC 974, BBN, January 1986.
[8] Hansen, A. and R. Hagens, "Operational
for X.400 Management Domains in the GO-
Community", Work in Progress, March 1993.
[9] Allocchio, C., Bonito, A., Cole, B., Giordano, S.,
and R. Hagens "Using the Internet DNS to
RFC1327 Mail Address Mapping Tables", RFC 1664,
GARR-Italy, Cisco Systems Inc, Centro
Calcolo Scientific, Advanced Network & Services
February 1993.
[10] Houttuin, J., "A Tutorial on Gatewaying between X.400
and Internet Mail", RFC 1506, RTR 6, RARE Secretariat
August 1993.
[11] Postel, J., "Simple Mail Transfer Protocol", STD 10,
RFC 821, USC/Information Sciences Institute,
1982.
[12] Crocker, D., "Standard for the Format of
Internet Text Messages", STD 11, RFC 822, UDEL
August 1982.
[13] Alvestrand, H.T., et al, "Introducing Project
Bud Internet Pilot Project for the Deployment
X.500 Directory Information in Support of X.400
Routing", Work in Progress, June 1993.
[14] Kille, S., "A Simple Profile for MHS use
Directory", Work in Progress, July 1993.
[15] Kille, S., "MHS use of the Directory to
Distribution Lists", Work in Progress, November 1992.
Houttuin [Page 18]
RFC 1711 Classifications in E-mail Routing October 1994
[16] Eppenberger, U., "X.500 directory service usage
X.400 e-mail", Computer Networks for Research
Europe No.1: Computer Networks and ISDN Systems 25,
Suppl.1 (1993) S3-8, September 1993.
[17] CCITT Recommendations X.400 - X.430.
Communication Networks: Message Handling Systems
CCITT Red Book, Vol. VIII - Fasc. VIII.7, Malaga
Torremolinos 1984.
[18] CCITT Recommendations X.400 - X.420.
Communication Networks: Message Handling Systems
CCITT Blue Book, Vol. VIII - Fasc. VIII.7,
1988.
14. Security
Security issues are discussed in section 3.1.
15. Author's
Jeroen
RARE
Singel 466-468
NL-1017 AW
The
Phone: +31 20 639 11 31
Fax: +31 20 639 32 89
EMail: houttuin@rare.
Houttuin [Page 19]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
