Classifications in E-mail Routing
RFC 1711
|
Document |
Type |
|
RFC - Informational
(October 1994; No errata)
|
|
Author |
|
Jeroen Houttuin
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
Legacy
|
|
Formats |
|
plain text
html
pdf
htmlized
bibtex
|
Stream |
Legacy state
|
|
(None)
|
|
Consensus Boilerplate |
|
Unknown
|
|
RFC Editor Note |
|
(None)
|
IESG |
IESG state |
|
RFC 1711 (Informational)
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
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.
Show full document text