Email addresses are made up of at least two parts. One part is the
name of a mail domain that will ultimately
translate to either the recipient's host or some host that accepts
mail on behalf of the recipient. The other part is some form of unique
user identification that may be the login name of that user, the real
name of that user in “Firstname.Lastname” format, or an
arbitrary alias that will be translated into a user or list of
users. Other mail addressing schemes, like X.400, use a more general
set of “attributes” that are used to look up the
recipient's host in an X.500 directory server.
How email addresses are interpreted depends greatly on what type of
network you use. We'll concentrate on how TCP/IP and UUCP networks
interpret email addresses.
Internet sites adhere to the RFC-822 standard, which requires the
familiar notation of [email protected], for which host.domain is the host's fully
qualified domain name. The character separating the two is properly
called a “commercial at” sign, but it helps if you read it
as “at.” This notation does not specify a route to the
destination host. Routing of the mail message is left to the
mechanisms we'll describe shortly.
You will see a lot of RFC-822 if you run an Internet connected site. Its
use extends not only to mail, but has also spilled over into other services,
such as news. We discuss how RFC-822 is used for news in
Chapter 20.
In the original UUCP environment, the prevalent form was
path!host!user, for which
path described a sequence of hosts
the message had to travel through before reaching the destination
host. This construct is called
the bang path notation, because an exclamation mark
is colloquially called a “bang.” Today, many UUCP-based networks
have adopted RFC-822 and understand domain-based addresses.
Other networks have still different means of addressing. DECnet-based
networks, for example, use two colons as an address separator,
yielding an address of host::user.[1]
The X.400 standard uses an entirely different scheme, describing a
recipient by a set of attribute-value pairs, like country and organization.
Lastly, on FidoNet, each user is identified by a code like 2:320/204.9, consisting of four numbers
denoting zone (2 is for Europe), net (320 being Paris and Banlieue),
node (the local hub), and point (the individual user's PC). Fidonet
addresses can be mapped to RFC-822; the above, for example, would be written as [email protected]. Now didn't we say domain names were easy to remember?
It is inevitable that when you bring together a number of different
systems and a number of clever people, they will seek ways to
interconnect the differing systems so they are capable of
internetworking. Consequently, there are a number of different mail
gateways that are able to link two different email systems together so
that mail may be forwarded from one to another. Addressing is the
critical question when linking two systems. We won't look at the
gateways themselves in any detail, but let's take a look at some of
the addressing complications that may arise when gateways of this sort
are used.
Consider mixing the UUCP style bang-path notation and RFC-822. These
two types of addressing don't mix too well. Assume there is an address
of domainA!user@domainB. It
is not clear whether the @
sign takes precedence over the path, or vice versa: do we have to send
the message to domainB,
which mails it to domainA!user, or should it be sent to
domainA, which forwards it
to user@domainB ?
Addresses that mix different types of address operators are called
hybrid addresses. The most common type, which we
just illustrated, is usually resolved by giving the @ sign precedence over the path. In
domainA!user@domainB, this
means sending the message to domainB first.
However, there is a way to specify routes in RFC-822 conformant ways:
<@domainA,@domainB:user@domainC > denotes the address of user on
domainC, where
domainC is to be reached through
domainA and
domainB (in that order). This type
of address is frequently called a source routed address.
It's not a good idea to rely on this behavior, as revisions to the
RFCs describing mail routing recommend that source routing in a mail
address be ignored and instead an attempt should be made to deliver directly
to the remote destination.
Then there is the % address
operator: user %domainB@domainA is first sent
to domainA, which expands
the rightmost (in this case, the only) percent sign to an @ sign. The address is now user@domainB, and the mailer happily
forwards your message to domainB, which delivers it to
user. This type of address
is sometimes referred to as “Ye Olde ARPAnet Kludge,” and
its use is discouraged.
There are some implications to using these different types of
addressing that will be described throughout the following
sections. In an RFC-822 environment, you should avoid using anything
other than absolute addresses, such as [email protected].
