RFC 1711
Classifications in E-mail Routing
RFC 1711: Classifications in E-mail Routing 💌✨
Okay bestie, let's get into it 🎀. This is RFC 1711, and it's titled Classifications in E-mail Routing. It comes from the Network Working Group and was written by J. Houttuin of RARE 🫶. It's filed as Category: Informational and dated October 1994 🌸. The header doesn't list anything it obsoletes or updates, so it stands on its own 💅.
Status of this Memo 🦋
So this memo is just here to provide information for the Internet community. It is not an Internet standard of any kind 💀. Distribution is unlimited, so you can share it with everyone 🍓.
Abstract 💜
Okay so this paper gives a classification for e-mail routing issues 🧚. It clearly defines commonly used terms like:
- static routing
- store-and-forward routing
- source routing
- and others
Real-life examples show which routing options are actually used in existing projects 🔥. It's giving "receipts, not just theory" energy.
The whole goal is to define all the terminology in one reference paper 📚. This will help newer mail system managers understand the issues and make the right choices 🙈. The reader is expected to already have a solid understanding of general networking terminology, so this is not a beginner intro, periodt 💖.
In this paper, Message Transfer Agent (MTA) is the word used for a routing entity 👑. That can be an X.400 MTA, a UNIX mailer, or any other piece of software doing mail routing functions ✨. An MTA processes the so-called envelope information of a message 📮.
The term User Agent (UA) describes a piece of software doing 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
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 191. Naming, addressing and routing 🌸
Okay so a name is how you uniquely identify a network object. For this whole doc we're going to pretend that object is a person, cause that's the vibe 💖
Once you know someone's name, you can use it as a key to figure out their address 🗝️
An address tells you exactly where the person is located. It's usually split into two parts: a domain related part (like the RFC 822 domainpart, or an ADMD or OU attribute in X.400) and a local or user related part (like the RFC 822 localpart, or a DDA or Surname attribute in X.400). The domain part is typically made of several components that sit in a certain hierarchical order, and those domain levels can be used for routing purposes, as we'll see later ✨
Once you have someone's address, you can use it as a key to find a route to that person's location. Main character energy 👑
We'll use this 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. So if a message gets redirected at the UA level, a brand new route is set up from the redirecting UA to the UA the message is redirected to 🦋
The first and last leaves in a mail route aren't always UAs, bestie. A route might start at a UA and then stop partway through, because one of the MTAs can't make any more routing decisions. When that happens, the MTA (not a UA) generates a warning and sends it back to the originator of the undeliverable message. It can even happen that none of the leaves is a UA, for example if that warning message turns out to be undeliverable itself. The cautious reader may have noticed 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's really important that the graph is directed, because routes aren't necessarily symmetric. A reply to a message might go over a completely different mail route for reasons like cost, non-symmetric network connectivity, network load, etc. It's giving unpredictable 🌈
According to the definition, if a message has two different recipients, there will also be two mail routes. And since delivery to a UA (not the UA itself) counts as part of the route, this definition still works if two UAs are connected to the same MTA 🧚
The words '.. for one originator-recipient pair.' in the definition do not mean that this pair gives the MTA all the info it needs to pick one specific route. One originator-recipient pair might let an MTA choose from a number of possible routes, called the routing indicators (see chapter 2) 💜
Other info (like line load, cost, availability) can then be used to choose one route from those 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, and that's how the complete route gets built, one hop at a time 🫶
Taking a routing decision isn't a purely algorithmic process, otherwise there'd be hardly 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 the algorithms for using it, are the subject of the rest of this paper 🎀
2. Static versus dynamic 💅
Dynamic (mail) routing lets a routing decision be influenced by external factors, like system availability, network load, etc. Static (mail) routing, on the other hand, isn't able to adapt to environmental constraints. Honestly, you can think of static routing as an extremely simple form of dynamic routing, where there's 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 happen at different layers! At the mail level, dynamic routing might let a message be relayed to a choice of MTAs (the routing indicators). As an example, look at the Internet mechanism of using multiple Mail eXchanger (MX) records, which describe MTAs that can serve a domain. If the primary choice MTA isn't available, a second choice MTA can be tried. If that second choice is busy, a third one will be tried, and so on. On lower layers, there may be more than one presentation address for one MTA, and each of those can again have an associated priority and other attributes ✨
These choices may represent an MTA that prefers to be connected to using one certain stack, e.g., RFC1006/TCP/IP, but that is also able to accept incoming calls over another stack, such as TP0/CONS/X.25. We'll call this dynamic stack routing. In theory, dynamic stack routing should be transparent to the mail routing application, so it isn't part of dynamic mail routing. It's mentioned here anyway, 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 it 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 a maximum number of retries 🦋
For reasons of flexibility and reliability, dynamic routing is almost always the preferred method 🌸
3. Direct versus indirect 🧚
Direct routing lets the originator's MTA 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's honestly hard to clearly tell direct and indirect apart: direct routing assumes a fully meshed routing topology, whereas indirect routing assumes a more tree-like hierarchical topology. Mail routing in most existing networks is upto some degree indirect 🌈
Networks can be classified as more or less direct using this rule of thumb: a larger fan out of the routing tree means more direct routing, and a greater depth of the tree means less direct routing 🍓 Two kinds of indirect routing are presented here: firewalls (downstream) and default routes (upstream) 💖
3.1. Firewalls 🧱✨
Okay so a firewall basically 'attracts' every message for a certain set of addresses (that's the address sub space hiding behind the firewall) from the outside e-mail world and funnels them into one central relaying MTA, which is the firewall itself 🫶. How does it grab them? It publishes routes to all the other MTAs that have to relay their messages over this firewall. Those MTAs are the attracted community 💅. Local knowledge should be used to route messages within the address space behind the firewall, and we'll get an example of that later on 👀. People use firewalls for loads of reasons, like security considerations, or to concentrate the management for a given domain onto one well managed system 🔥.
The Internet mail system would let all mail hosts connected to the Internet directly accept mail from any other host, but not all hosts actually do that 🙈. Lots of domains are hidden behind one or more 'Mail eXchanger' (MX), which offer to relay all incoming mail for those domains. The RELAY-MTAs we mentioned earlier can also be considered firewall systems 🧚.
+-----------------------------------+
| |
| 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 |
+----+ +----+ +----+ +----+ +----+Figure 2. Firewall and default route 🗺️
3.2. Default versus rule based 🎀
Default routing is basically what a firewall is for incoming mail, but for outgoing mail 💅, which is why the two get used together so often 👯. It's honestly the simplest routing algorithm you can think of: route every message to one and the same MTA, which is trusted to take further care of routing the message towards its destination. Pure default routing is kind of useless tbh 💀, so it's normally used as a fall back mechanism that comes along with a rule based algorithm.
The simplest usable default algorithm goes like this: 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 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. Let's look at an example. An X.400 MTA A, which serves the 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. Now suppose B used the same mechanism: first check if the OU is local, and if not, default route to A. If OU=orgunC isn't 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.
Figure 2 shows it perfectly 📊. A firewall is a downstream indirection, and a default route is an upstream indirection. MTA B and D use default routing, so they can only route to one other MTA, which is MTA A.
For more detailed info, check out [3], which lists most of the pros and cons of both approaches. Your choice will depend on lots of factors that are specific to your messaging environment 🫶.
4. Routing at user level 🧚
Normally a message is routed down to the deepest level domain, and then delivered to the recipient per default routing. Basically, every user in this domain is considered to have their 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) 🌸.
4.1. Distributed domains 🌈
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 users have their UAs connected to the same 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 it gets its own 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 🙄.
Say an organisation has two mail platforms available. Some users prefer 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) 😬.
+----------+ +---------------------------+
| MTA A | | Shared MTA B |
+----------+ +---------------------------+
| | / | | |
+-----------------/----+ +-----------+ +----------+
| | | / | | | | | | | |
| +--+ +--+ +--+/ | | +--+ +--+ | | +--+ |
| |UA| |UA| |UA| | | |UA| |UA| | | |UA| |
| +--+ +--+ +--+ | | +--+ +--+ | | +--+ |
| Distributed Domain A | | Domain B | | Domain C |
+----------------------+ +-----------+ +----------+Figure 3. Distributed domains and shared MTAs 🏘️
Another way to get uniform addresses in outgoing e-mail, even though a domain is distributed, is to make routing decisions on information in the local part of the address. For example, in X.400 you'd use the Surname in exactly the same manner as you'd make routing decisions on any other attributes. So products and routing algorithms that are able to route on user related address parts are said to support distributed domains 💖.
4.2. Shared 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 😭.
Theoretically, this problem doesn't exist 🧠. The address is 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 default user routing at the deepest level can lead to conflicts. It's beyond the scope of this document to describe the tricks needed to avoid these conflicts when using such products 🙈.
5. Routing control 🎮
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 🌐. It's used either 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. That second policy is not allowed in the CCITT version of the standards (as opposed to the ISO version), so heads up on that one 👀. Of course, the PRMDs can also perform routing control themselves in order to circumvent such problems.
Although there may be good reasons for using routing control, you have to 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 that clearly tells them where and why routing of their message was refused, whom to contact, and what options are available to avoid such rejections in the future 💌.
6. Bulk routing 📦
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, which postpones the 'explosion' into several copies. This technique, called bulk routing, is especially useful when an MTA hosts large mailing lists 📬.
There are several possibilities. 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 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 🤷♀️).
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, so it's 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 checking first if the requesting party is running or planning to run large mailing lists 🚨💅.
In more direct routing setups like BITNET, bulk routing won't just happen automatically the way we described above 😭. Without special precautions, an MTA would open a direct connection to every single host in the message's envelope, even when some of those hosts are super far from this MTA but right next to each other on the underlying network topology 💀. That's a total waste of expensive bandwidth 💸. To catch these cases and send one copy over the pricey link, letting it get distributed at remote hosts, an MTA must have extra knowledge of how mail domains relate to the underlying network topology 🧚.
BITNET uses the distribute protocol [4] for this. A selected set of hosts gets published as having the topology knowledge to efficiently distribute mail on behalf of other MTAs, who can explicitly route all their bulk mail to one of those hosts 🦋. The complete message, envelope included, is encoded in a message body. That body starts with a distribution request to the distribute server. The server breaks the rest of the body back into the original envelope and contents, then uses its topology knowledge to distribute the original message efficiently 🚀.
Note that this protocol breaks the conceptual layering of MTA and UA functionality 🙈, but it's honestly about the only trick that works in a very direct routing environment. It's only needed to overrule a non-efficient (for large mailing lists) routing topology 💅.
Bulk routing is also where mail routing starts to overlap with distributing netnews (bulletin board services) 📰. ISO, RARE and the IETF have all started initiatives to harmonise the two worlds 🌈. The first results, whether standards or products, aren't expected before 1995 though ⏳.
7. Source routing ✨
Source routing was originally meant to let a user force a message to take a certain route 🗺️. Here's how it works: the MTA the user wants the message to go through gets baked into the address. Once the message arrives at that MTA, it strips itself out of the source-routed address and routes the remaining address the usual way. This is called explicit source routing, and it's super handy if you want to test a routing path or force a message 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 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 🎀
Source routing doesn't always have to be explicit 🤷♀️. Source routes can also be generated automatically by a gateway, which is called address rooting (to that gateway). The gateway roots itself to the message by putting its own domain in the source route mapped address. That way, any replies to the gatewayed message get routed back through the same gateway 🔁.
Example 1: RFC 1327 left hand side encoding (see [5]) performed by 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.chExample 2: RFC 1327 DDA mapping (see [5]) performed by the gateway 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.relayWhen 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:
user@final.domainExample 4: Another example of the already mentioned explicit source routing, this time through two relays:
@1st.relay,@2nd.relay:user@final.domainOn the Internet, explicit source routing is strongly discouraged (see [6]). One reason is that not all mail relays handle such addresses in a consistent manner 😬. Apart from that, the need to use explicit source routing has disappeared over the last decennia 🕰️. Back when the RFC 822 world was lots of sparsely connected 'mail islands', source routing was sometimes needed to make sure a message went through a gateway known to be connected to a remote island 🏝️. Nowadays the RFC 822 world is almost fully interconnected through the Internet, so end-users having to know the mail network's topology has become superfluous 👑.
8. Poor man's routing
If we combine static, indirect and source routing, we get what's commonly known as "poor man's routing" 🥲. The user specifies the complete route in the address. A classic example is the old UUCP bang style addressing:
host1!host2!host3!host4!userPoor 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 isn't widely deployed anymore 🪦.
9. Routing communities
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.Which is a rather formal way of saying that a routing community is a set of MTAs (and human operators) that agreed on a common set of rules for routing messages among each other 🤝.
An example is the large Internet routing community, where 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 firewalls or behind default routes are thus not considered direct members of this community. They normally form their own smaller routing community, with one host (the mail exchanger/default route) belonging to both communities 🏰.
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:
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.
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.
Open community: All routing information is public
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 in
practice often be pruned; sub-sub-
trees may form their own routing
community. Example: GO-MHS.This classification can't always be followed too strictly 🙃. For example, completely closed communities are relatively rare. For e-mail to be an effective communication tool, an organisation will typically designate at least one of its MTAs as a gateway to another routing community, for instance the Internet. The organisation registers an Internet domain, say 'org.net', which points to this gateway. That makes it act 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. Go check this yourself, bestie 👀.
Especially the distinction between open and closed communities isn't always easy 😵💫. To some extent most routing communities are open, at least among their own participants. It's just that some routing communities are more open than others. Also, even the most open routing community isn't open to just anyone. It's 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] 📋.
The most open routing community known today is certainly the Internet mail community 👑. As for X.400 routing communities, some problems pop up when trying to open a community. The main one is that most X.400 software doesn't 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 🥀.
10. Realisations
In this chapter, some of the routing classifications described above are assigned to existing mail services and projects 📚.
10.1. Internet mail
- 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.
(*) Sub-communities don't use DNS based routing. The MX records in the DNS are used to "attract" messages from the Internet to the "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.
10.2. UUCP 🐚
okay so UUCP is RFC 822 style mail 📬 and it's an operational service 💅. Co-ordination is distributed 🫶. Routing is mostly static, although dynamic routing is also possible ✨. It runs on table based routing rules 🗂️ and is mostly indirect routing 🔀. No dynamic stack routing, no distributed domains. Shared MTAs are possible but rare 🤏. Routing control isn't normally used, and no bulk routing is possible.
Source routing (poor man's routing) is still widely used through 'bang' addressing 💥, but it's strongly discouraged 🚫. The routing community is open (and hierarchical) 🌈.
10.3. EARN 📮
this one is BITNET mail and it's an operational service 🎀. Co-ordination is handled by The EARN Office, France 🥖. Routing is static, and it uses table based routing rules, although an X.500 based experiment is running 🧪. It's mostly direct routing, although indirect is also possible.
No dynamic stack routing, no distributed domains, and no shared MTAs 🙅. Routing control isn't normally used. Bulk routing is possible using the 'distribute protocol' [4] 📦. Source routing isn't supported, so no poor man's routing either 💀. The routing community is open 🌸.
10.4. GO-MHS 🌍
this is X.400 mail and it's an operational service 💖. Co-ordination is handled by the GO-MHS Project Team, Switzerland 🇨🇭. Routing is mostly static, although dynamic routing is getting more and more deployed since the introduction of RFC 1465 [2] 📈. It uses table based community-wide routing rules, with indirect routing.
We've also got dynamic stack routing ⚡, and distributed domains are possible 🧩. There are shared MTAs too 🫂. Routing control isn't normally used, only to avoid routing control problems when routing international traffic to ADMDs ✈️. Bulk routing uses X.400 'responsibility' envelope flags 🏷️. Source routing is supported for gatewaying to the Internet 🌉, but no poor man's routing 🙅. It's a hierarchical, but open, routing community 👑.
10.5. ADMD infrastructure 🏛️
X.400 mail again, and this one is operational 💅. Co-ordination is handled by the joint Administrative Management Domains (ADMDs), typically operated by PTTs 📡. Routing is mostly static, with indirect routing 🔀. It uses table based bilateral routing rules 🤝.
No dynamic stack routing, and distributed domains aren't supported 🙅. There are shared MTAs 🫂. Routing control is used to prohibit routing of international traffic through PRMDs and to limit access to certain gateways 🚧. Bulk routing uses X.400 'responsibility' envelope flags 🏷️. Source routing is possible for gatewaying to the Internet 🌉, but there's no poor man's routing 💀. It's a closed hierarchical routing community 🔒.
10.6. Long Bud 🌷
this one is X.400 mail and it's a pilot project 🧪. Co-ordination is handled by the IETF MHS-DS working group 🫶. Routing is dynamic, using X.500 based routing rules 🧠. It's mostly indirect routing, although direct is also possible.
We've got dynamic stack routing ⚡ and distributed domains 🧩, plus shared MTAs 🫂. There's no routing control 🕊️. Bulk routing uses X.400 'responsibility' envelope flags 🏷️. Source routing is supported for gatewaying to the Internet 🌉, but no poor man's routing 🙅. It's an open hierarchical routing community 🌈.
10.7. X42D 🧁
the last one is X.400 mail and it's an experiment 🔬. Co-ordination is handled by INFN, Italy 🇮🇹. Routing is dynamic, using DNS based routing rules as defined in [9] 🌐. It's mostly indirect routing, although direct is also possible.
Dynamic stack routing is in, but no distributed domains 🙅. There are shared MTAs 🫂 and no routing control 🕊️. Bulk routing uses X.400 'responsibility' envelope flags 🏷️. Source routing is supported for gatewaying to the Internet 🌉, but no poor man's routing 💀. It's an open hierarchical routing community 🌈.
11. Conclusion 🎓
okay so we've now seen several dimensions in which mail routing can be classified 📊. There are way more issues that weren't discussed here 🙈, like how exactly the routing databases are implemented, which algorithms to use for making the actual choices in dynamic routing, and so on. A follow-up paper is planned to dig into those aspects in more detail 👀.
Up until now, the author has tried to keep this paper free of opinion 🙊. But they'd like to end by sharing their own favourite routing options, with no 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
Source routing: Avoid where possible
Poor man's routing: Avoid12. Abbreviations 📖
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 Point13. References 📚
[1] Houttuin, J., "C-BoMBS : A Classification of Breeds Of Mail Based Servers", RARE WG-MSG Work in Progress, April 1994.
[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.
[3] Kille, S., "MHS use of the Directory to support MHS routing", Work in Progress, July 1993.
[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, University College London, May 1992.
[6] Braden, R., Editor, "Requirements for Internet Hosts - 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 Requirements for X.400 Management Domains in the GO-MHS Community", Work in Progress, March 1993.
[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.
[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, August 1982.
[12] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, UDEL, August 1982.
[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.
[14] Kille, S., "A Simple Profile for MHS use of Directory", Work in Progress, July 1993.
[15] Kille, S., "MHS use of the Directory to Support Distribution Lists", Work in Progress, November 1992.
[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.
[17] CCITT Recommendations X.400 - X.430. Data Communication Networks: Message Handling Systems. CCITT Red Book, Vol. VIII - Fasc. VIII.7, Malaga-Torremolinos 1984.
[18] CCITT Recommendations X.400 - X.420. Data Communication Networks: Message Handling Systems. CCITT Blue Book, Vol. VIII - Fasc. VIII.7, Melbourne 1988.
14. Security Considerations 🔐
⚠️ bestie, this one is serious 😭 Security issues are discussed in section 3.1. Go read that section before you do anything else 🫶.
15. Author's Address 💌
Jeroen Houttuin
RARE Secretariat
Singel 466-468
NL-1017 AW Amsterdam
The Netherlands
Phone: +31 20 639 11 31
Fax: +31 20 639 32 89
EMail: houttuin@rare.nl📦 where this page comes from
- ietf: rfc1711 1994-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms