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].
| [1] | When trying to reach a DECnet address from an RFC-822 environment, you can use “host::user"@relay, for which relay is the name of a known Internet-DECnet relay. |