As per Relevance of the word addressed, we have this rfc below:
Network Working Group Craig
Request for Comments: 974 CSNET CIC BBN Laboratories
January 1986
MAIL ROUTING AND THE DOMAIN
Status of this
This RFC presents a description of how mail systems on the
are expected to route messages based on information from the
system described in RFCs 882, 883 and 973. Distribution of this
is unlimited
The purpose of this memo is to explain how mailers are to decide
to route a message addressed to a given Internet domain name.
involves a discussion of how mailers interpret MX RRs, which are
for message routing. Note that this memo makes no statement
how mailers are to deal with MB and MG RRs, which are used
interpreting mailbox names
Under RFC-882 and RFC-883 certain assumptions about mail
have been changed. Up to now, one could usually assume that if
message was addressed to a mailbox, for example, at LOKI.BBN.COM
that one could just open an SMTP connection to LOKI.BBN.COM and
the message along. This system broke down in certain situations
such as for certain UUCP and CSNET hosts which were not
attached to the Internet, but these hosts could be handled as
cases in configuration files (for example, most mailers were set
to automatically forward mail addressed to a CSNET host
CSNET-RELAY.ARPA).
Under domains, one cannot simply open a connection to LOKI.BBN.COM
but must instead ask the domain system where messages to LOKI.BBN.
are to be delivered. And the domain system may direct a mailer
deliver messages to an entirely different host, such as SH.CS.NET
Or, in a more complicated case, the mailer may learn that it has
choice of routes to LOKI.BBN.COM. This memo is essentially a set
guidelines on how mailers should behave in this more complex world
Readers are expected to be familiar with RFCs 882, 883, and
updates to them (e.g., RFC-973).
Partridge [Page 1]
RFC 974 January 1986
Mail Routing and the Domain
What the Domain Servers
The domain servers store information as a series of resource
(RRs), each of which contains a particular piece of information
a given domain name (which is usually, but not always, a host).
simplest way to think of a RR is as a typed pair of datum, a
name matched with relevant data, and stored with some additional
information to help systems determine when the RR is relevant.
the purposes of message routing, the system stores RRs known as
RRs. Each MX matches a domain name with two pieces of data,
preference value (an unsigned 16-bit integer), and the name of
host. The preference number is used to indicate in what order
mailer should attempt deliver to the MX hosts, with the
numbered MX being the one to try first. Multiple MXs with the
preference are permitted and have the same priority
In addition to mail information, the servers store certain
types of RR's which mailers may encounter or choose to use.
are: the canonical name (CNAME) RR, which simply states that
domain name queried for is actually an alias for another domain name
which is the proper, or canonical, name; and the Well Known
(WKS) RR, which stores information about network services (such
SMTP) a given domain name supports
General Routing
Before delving into a detailed discussion of how mailers are
to do mail routing, it would seem to make sense to give a
overview of how this memo is approaching the problems that
poses
The first major principle is derived from the definition of
preference field in MX records, and is intended to prevent
looping. If the mailer is on a host which is listed as an MX for
destination host, the mailer may only deliver to an MX which has
lower preference count than its own host
It is also possible to cause mail looping because routing
is out of date or incomplete. Out of date information is only
problem when domain tables are changed. The changes will not
known to all affected hosts until their resolver caches time out
There is no way to ensure that this will not happen short
requiring mailers and their resolvers to always send their queries
an authoritative server, and never use data stored in a cache.
is an impractical solution, since eliminating resolver caching
make mailing inordinately expensive. What is more, the out-of-
RR problem should not happen if, when a domain table is changed
Partridge [Page 2]
RFC 974 January 1986
Mail Routing and the Domain
affected hosts (those in the list of MXs) have their resolver
flushed. In other words, given proper precautions, mail looping as
result of domain information should be avoidable, without
mailers to query authoritative servers. (The appropriate
is to check with a host's administrator before adding that host to
list of MXs).
The incomplete data problem also requires some care when
domain queries. If the answer section of a query is
critical MX RRs may be left out. This may result in mail looping,
in a message being mistakenly labelled undeliverable. As a result
mailers may only accept responses from the domain system which
complete answer sections. Note that this entire problem can
avoided by only using virtual circuits for queries, but since
situation is likely to be very rare and datagrams are the
way to interact with the domain system, implementors should
just ensure that their mailer will repeat a query with
circuits should the truncation bit ever be set
Determining Where to Send a
The explanation of how mailers should decide how to route a
is discussed in terms of the problem of a mailer on a host
domain name LOCAL trying to deliver a message addressed to the
name REMOTE. Both LOCAL and REMOTE are assumed to be
correct domain names. Furthermore, LOCAL is assumed to be
official name for the host on which the mailer resides (i.e., it
not a alias).
Issuing a
The first step for the mailer at LOCAL is to issue a query for MX
for REMOTE. It is strongly urged that this step be taken every
a mailer attempts to send the message. The hope is that changes
the domain database will rapidly be used by mailers, and thus
administrators will be able to re-route in-transit messages
defective hosts by simply changing their domain databases
Certain responses to the query are considered errors
Getting no response to the query. The domain server the
queried never sends anything back. (This is distinct from
answer which contains no answers to the query, which is not
error).
Getting a response in which the truncation field of the header
Partridge [Page 3]
RFC 974 January 1986
Mail Routing and the Domain
set. (Recall discussion of incomplete queries above).
may not use responses of this type, and should repeat the
using virtual circuits instead of datagrams
Getting a response in which the response code is non-zero
Mailers are expected to do something reasonable in the face of
error. The behaviour for each type of error is not specified here
but implementors should note that different types of errors
probably be treated differently. For example, a response code
"non-existent domain" should probably cause the message to
returned to the sender as invalid, while a response code of "
failure" should probably cause the message to be retried later
There is one other special case. If the response contains an
which is a CNAME RR, it indicates that REMOTE is actually an
for some other domain name. The query should be repeated with
canonical domain name
If the response does not contain an error response, and does
contain aliases, its answer section should be a (possibly
length) list of MX RRs for domain name REMOTE (or REMOTE's
domain name if REMOTE was a alias). The next section describes
this list is interpreted
Interpreting the List of MX
NOTE: This section only discusses how mailers choose which names
try to deliver a message to, working from a list of RR's. It
not discuss how the mailers actually make delivery. Where
delivering a message is mentioned, all that is meant is that
mailer should do whatever it needs to do to transfer a message to
remote site, given a domain name for that site. (For example,
SMTP mailer will try to get an address for the domain name,
involves another query to the domain system, and then, if it gets
address, connect to the SMTP TCP port). The mechanics of
transferring the message over the network to the address
with a given domain name is not within the scope of this memo
It is possible that the list of MXs in the response to the query
be empty. This is a special case. If the list is empty,
should treat it as if it contained one RR, an MX RR with a
value of 0, and a host name of REMOTE. (I.e., REMOTE is its
MX). In addition, the mailer should do no further processing on
list, but should attempt to deliver the message to REMOTE. The
Partridge [Page 4]
RFC 974 January 1986
Mail Routing and the Domain
here is that if a domain fails to advertise any information about
particular name we will give it the benefit of the doubt and
delivery
If the list is not empty, the mailer should remove irrelevant RR'
from the list according to the following steps. Note that the
is significant
For each MX, a WKS query should be issued to see if the
name listed actually supports the mail service desired. MX
which list domain names which do not support the service should
discarded. This step is optional, but strongly encouraged
If the domain name LOCAL is listed as an MX RR, all MX RRs with
preference value greater than or equal to that of LOCAL's must
discarded
After removing irrelevant RRs, the list can again be empty. This
now an error condition and can occur in several ways. The
case is that the WKS queries have discovered that none of the
listed supports the mail service desired. The message is thus
undeliverable, though extremely persistent mail systems might want
try a delivery to REMOTE's address (if it exists) before
the message. Another, more dangerous, possibility is that the
system believes that LOCAL is handling message for REMOTE, but
mailer on LOCAL is not set up to handle mail for REMOTE.
example, if the domain system lists LOCAL as the only MX for REMOTE
LOCAL will delete all the entries in the list. But LOCAL
presumably querying the domain system because it didn't know what
do with a message addressed to REMOTE. Clearly something is wrong
How a mailer chooses to handle these situations is to some
implementation dependent, and is thus left to the implementor'
discretion
If the list of MX RRs is not empty, the mailer should try to
the message to the MXs in order (lowest preference value
first). The mailer is required to attempt delivery to the
valued MX. Implementors are encouraged to write mailers so that
try the MXs in order until one of the MXs accepts the message, or
the MXs have been tried. A somewhat less demanding system, in
a fixed number of MXs is tried, is also reasonable. Note
multiple MXs may have the same preference value. In this case,
MXs at with a given value must be tried before any of a higher
are tried. In addition, in the special case in which there
several MXs with the lowest preference value, all of them should
tried before a message is deemed undeliverable
Partridge [Page 5]
RFC 974 January 1986
Mail Routing and the Domain
Minor Special
There are a couple of special issues left out of the
section because they complicated the discussion. They are
here in no particular order
Wildcard names, those containing the character '*' in them, may
used for mail routing. There are likely to be servers on the
which simply state that any mail to a domain is to be routed
a relay. For example, at the time that this RFC is being written,
mail to hosts in the domain IL is routed through RELAY.CS.NET.
is done by creating a wildcard RR, which states that *.IL has an
of RELAY.CS.NET. This should be transparent to the mailer since
domain servers will hide this wildcard match. (If it matches *.
with HUJI.IL for example, a domain server will return an
containing HUJI.IL, not *.IL). If by some accident a mailer
an RR with a wildcard domain name in its name or data section
should discard the RR
Note that the algorithm to delete irrelevant RRs breaks if LOCAL
a alias and the alias is listed in the MX records for REMOTE. (E.g
REMOTE has an MX of ALIAS, where ALIAS has a CNAME of LOCAL).
can be avoided if aliases are never used in the data section of
RRs
Implementors should understand that the query and interpretation
the query is only performed for REMOTE. It is not repeated for
MX RRs listed for REMOTE. You cannot try to support more
mail routing by building a chain of MXs. (E.g. UNIX.BBN.COM is an
for RELAY.CS.NET and RELAY.CS.NET is an MX for all the hosts in .IL
but this does not mean that UNIX.BBN.COM accepts any
for mail for .IL).
Finally, it should be noted that this is a standard for routing
the Internet. Mailers serving hosts which lie on multiple
will presumably have to make some decisions about which network
route through. This decision making is outside the scope of
memo, although mailers may well use the domain system to help
decide. However, once a mailer decides to deliver a message via
Internet it must apply these rules to route the message
Partridge [Page 6]
RFC 974 January 1986
Mail Routing and the Domain
To illustrate the discussion above, here are three examples of
mailers should route messages. All examples work with the
database
A.EXAMPLE.ORG IN MX 10 A.EXAMPLE.
A.EXAMPLE.ORG IN MX 15 B.EXAMPLE.
A.EXAMPLE.ORG IN MX 20 C.EXAMPLE.
A.EXAMPLE.ORG IN WKS 10.0.0.1 TCP
B.EXAMPLE.ORG IN MX 0 B.EXAMPLE.
B.EXAMPLE.ORG IN MX 10 C.EXAMPLE.
B.EXAMPLE.ORG IN WKS 10.0.0.2 TCP
C.EXAMPLE.ORG IN MX 0 C.EXAMPLE.
C.EXAMPLE.ORG IN WKS 10.0.0.3 TCP
D.EXAMPLE.ORG IN MX 0 D.EXAMPLE.
D.EXAMPLE.ORG IN MX 0 C.EXAMPLE.
D.EXAMPLE.ORG IN WKS 10.0.0.4 TCP
In the first example, an SMTP mailer on D.EXAMPLE.ORG is trying
deliver a message addressed to A.EXAMPLE.ORG. From the answer to
query, it learns that A.EXAMPLE.ORG has three MX RRs. D.EXAMPLE.
is not one of the MX RRs and all three MXs support SMTP
(determined from the WKS entries), so none of the MXs are eliminated
The mailer is obliged to try to deliver to A.EXAMPLE.ORG as
lowest valued MX. If it cannot reach A.EXAMPLE.ORG it can (but
not required to) try B.EXAMPLE.ORG. and if B.EXAMPLE.ORG is
responding, it can try C.EXAMPLE.ORG
In the second example, the mailer is on B.EXAMPLE.ORG, and is
trying to deliver a message addressed to A.EXAMPLE.ORG. There
once again three MX RRs for A.EXAMPLE.ORG, but in this case
mailer must discard the RRs for itself and C.EXAMPLE.ORG (because
MX RR for C.EXAMPLE.ORG has a higher preference value than the RR
B.EXAMPLE.ORG). It is left only with the RR for A.EXAMPLE.ORG,
can only try delivery to A.EXAMPLE.ORG
In the third example, consider a mailer on A.EXAMPLE.ORG trying
deliver a message to D.EXAMPLE.ORG. In this case there are only
MX RRs, both with the same preference value. Either MX will
messages for D.EXAMPLE.ORG. The mailer should try one MX first (
one is up to the mailer, though D.EXAMPLE.ORG seems most reasonable),
and if that delivery fails should try the other MX (e.g
C.EXAMPLE.ORG).
Partridge [Page 7]
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
