Search SLAC
SLAC Home | Computing Home | Computing Outages | Help

This article originally appeared in the UIUCnet newsletter, Computing Services Office at the University of Illinois (Feb/Mar 1990) and is reprinted here with permission. The article was judged Best Article over 1500 words and Best Overall Article in the 1990 ACM-SIGUCCS Technical Writing Competition. It was originally adapted for SLAC use by Mike Sullenberger, SCS in 1993. It was later updated by Teresa Downey, SCS in 1997.

UNDERSTANDING EMAIL ADDRESSES

by Carol Gedney University of Illinois

Note: The notation is used to distinguish email syntax and address examples from the remainder of the text; they are not part of the syntax or address.

Electronic mail, with its gamut of benefits and advantages, can still cause some share of tribulation, especially when one tries to get a message to someone on a seemingly far-out network, or when that someone tries to send mail in return. This article is designed to help the typical SLAC user understand the SLAC email address environment.

Thankfully, the age has come where different networks have been integrated and made compatible with one another, at least to the point where mail messages can be exchanged between them. Network evolution has not yet reached the point, however, of having a uniform email addressing scheme that is independent of the network each user resides on. It doesn't take long to realize that electronic mail addresses take on a variety of formats and syntaxes. These formats may seem confusing and difficult to interpret even to the long-time network user. Yet one only needs a bit of patience to better understand them.

Network mail exchange depends not only on hardware arrangements of the systems involved but on the software packages, called "Mailers," or Mail Transfer Agents, that are responsible for routing incoming and outgoing messages on any one machine. Hardware as well as software environments will vary from system to system on the path between the sender and recipient of a message, and heterogenous email address formats abound as a result. Individual large scale, or wide-area, networks often have their own particular email addressing methods, and while intercommunication is almost always possible, it at times can be problematic.

The syntax of an email address which SLAC users probably see most is based upon the Domain Name System (DNS). This is due to the fact that SLAC is part of the Internet, and DNS is incorporated in the Internet standard of mail addressing. Strong familiarity with DNS is stressed because other wide-area networks are gradually converting to this system as individual network addressing conventions are being phased out. This turnover is far from complete, however. In part two of this series, specific address conventions between the three primary ????? networks to which SLAC has email access will be discussed.

The Domain Naming System (DNS)

The DNS is a distributed, hierarchical structure of names used by most Internet applications including email, telnet and file transfer protocol (ftp). This naming structure reflects administrative levels of organization and/or geography on the Internet. The email address jsmith@popserv.slac.stanford.edu exemplifies a DNS-style address, and a simple analysis of this address will help explain the system and how it relates to mail. A good place to begin in this case, as with many email addresses, is at the "@" sign, since this delimiter typically occurs only once in any given address. Generally speaking, everything to the left of the @ delimiter is referred to as the local part of the address, usually a "mailbox" where a user reads his/her mail. A mailbox name often serves as a person's login name as well. In the example, jsmith is the local part, here signifying a mailbox as well as a login name. DNS is generally not involved in the local part of an address.

Everything to the right of the "@" sign, on the other hand, is referred to as the "domain name", which is based upon DNS and outlines where a mailbox is located. The complete domain name, also called the Fully Qualified Domain Name (FQDN), in the example is popserv.slac.stanford.edu. It consists of a sequence of symbolic labels, called subdomains, separated by periods. In most Internet addresses, as in this example, the first subdomain (in listing from left to right) refers to an actual computer, or host, on which the mailbox resides. popserv is the name of the host where the mailbox for jsmith is found. The next subdomain, slac, refers to SLAC, the local organization which owns or runs the host popserv. slac categorically falls under the next listed subdomain, stanford, which denotes Stanford University. The subdomain listed farthest to the right in a complete domain name is called the top-level-domain. In this example, edu is the top-level-domain signifying the broad category of educational institutions in the U.S..

It should be apparent that subdomains are listed in order from most specific to least, with each subdomain falling "inside" the one to the right. The general email address with DNS format is as follows: localpart@domain, often seen as the more specific form user@host.subdomain.top-level-domain. There may be more than one subdomain and in SLAC's case there are two subdomains, slac and stanford.

Top-level domains are the broadest category of domain names. In the U.S., "generic" top-level domains denote the type of Internet site an address corresponds to: EDU (educational institutions), COM (commercial), GOV (U.S. government), and MIL (U.S. military), among others. Worldwide, top-level domain names are two letter abbreviations called "country codes" which specify the national affiliation of an address: AU (Australia). FR (France), SE (Sweden), UK (United Kingdom), etc.

Some popular addressing conventions resemble DNS but don't strictly conform to the system's model. One of these variations is the use of "pseudo"-top-level-domain names, which indicate a host computer's association with a wide-area, non-Internet network. Though accepted by many machines' mailers, these names are considered invalid by the Internet's formal DNS rules. Prominent examples of pseudo-top-level-domain names are BITNET, UUCP, and HEPNET. An address with one of these pseudotop-level-domains will typically only have one other subdomain listed (to the right of the @ sign), and that subdomain name will usually specify a certain host belonging to the designated network. Thus the general address format would be user@host.pseudotop-level-domain and an example of this type of address would be jdoe@slacvm.bitnet. A local mailer environment that is friendly toward pseudo-top-level-domain names in an address would have to intercept such messages and perform preliminary routing accordingly.

Another widely used variation of DNS is related to the abridging of the complete, or Fully Qualified Domain Names (i.e. user@host.subdomain.subdomain.top-leveldomain) if the sender and recipient belong to the same subdomain. For example, the most abridged form of an address consists solely of the mailbox name, with no @ sign or other delimiters and subsequent domain names involved. This form may usually be used if the sender and recipient mailboxes are located on the same host computer. This means that the remainder of their domain names would be exactly equivalent, and mailer systems provide for this typing shortcut. When sending email anywhere outside of such a very local mailing environment (with the exception of some users' ability to create mail "aliases"), it is strongly encouraged to use the Fully Qualified Domain Name.

Gateways

Different networks have different sets of rules, or protocols, for communication between devices. Gateways are computers used primarily to connect dissimilar networks by translating between the protocols and allowing data traffic, such as mail, to pass between the two systems. Gateways may be placed between networks on the local level, or they may be used to connect otherwise incompatible wide-area networks. For example, many gateways exist at different geographical points between the Internet and BITNET, between the Internet and DECnet-based networks like HEPnet and between the Internet and UUCP-based networks like Usenet. There are also gateways that will gateway mail between BITNET and DECnet-based networks, BITNET and UUCP-based Networks and between DECnet-based and UUCP-based networks. In many cases these gateways are on the same computer and they will gateway mail between any of these four Networks and most likely other networks. Here at SLAC the need to address mail in non-DNS style has diminished to almost nil. Our mail gateways only accept DNS style email addresses.

The gateways' role in linking networks relates to another significant variation of email addresses that incorporates DNS. In many cases, "intelligent" mailer software will automatically forward messages being sent between different networks to an appropriate gateway. This would occur in a "transparent" manner, that is, without the user who is sending the message knowing anything about the gateway involvement.

Other times, mail must be explicitly sent through one or more gateways, requiring the user to specifically invoke them in the email address. These addresses appear in the general format of mailbox%domain0%domain1@domain2, where domain0 refers to the host where the mailbox is found, and domain2 and domain1 represent the sequence of gateways needed to get there, respectively.

In such an address it may be unclear as to how network machines interpret and evaluate the names and symbols in proper order such that the message arrives at its correct destination. An example would probably clarify this. As complex as it may appear, it is not difficult to determine the routing order of a message addressed to maryk%greco.hepnet%dove.uucp@blintz.bio.uiuc.edu. Since the singular @ sign has highest precedence, the portion of the email address to its right would be evaluated first. Thus, the message would initially be routed to the host blintz of the bio subdomain. Blintz, serving as one gateway, would in turn examine the still remaining part of the address, interpreting the rightmost % sign as a secondary @ sign. This figuratively produces maryk%greco.hepnet@dove.uucp. The second routing task, then, would focus on sending the message on to dove of the uucp pseudo-domain. Dove, the name of another gateway, would examine the as yet "unconsumed" address portion, where the one remaining % sign would be changed into an @ sign, resulting in maryk@greco.hepnet. The mail would then be forwarded to the host greco (of the pseudo-domain hepnet), home of the mailbox maryk.

Of course, several other email address formats are encountered besides those derived from DNS. These addresses will use different syntaxes and have different punctuation marks as delimiters between fields. Such addresses will vary as networks with different email systems vary. Not all types can be covered by the scope of this article series, but since the greatest amount of email traffic at SLAC flows between Internet sites, this addressing convention will be discussed further in Part II.

Understanding email Addresses, Part II

Internet mail

The Internet refers to a large collection of national and international networks that are based on the Transmission Control Protocol/Internet Protocol (TCP/IP) protocol suite and which share a common addressing scheme based on the Domain Name System (DNS). Sites on the Internet are currently linked over long distances with T-l (1.54 Mbps) or T-3 (45 Mbps) lines, with links on the local levels approaching up to 100Mbps in signalling speed. Network services offered on the Internet include email exchange, file transfer, remote login and bulletin board news exchange (e.g. Usenet).

The Internet internal mail addressing scheme uses the DNS, with a general address format of localpart@domain, often of the more specific form, user@host.domain where domain consists of one or more subdomains and a top-level-domain, separated by periods.

An example of an address for internal Internet mail might be jsmith@slac.stanford.edu.

Internet to BITNET mail

If given an internal BITNET address of the typical form user at node, the message would have to first be explicitly sent to the nearest Internet/BITNET gateway, which could then forward it on to the appropriate BITNET site. This is done by making the address of the previously explained (in part 1 of this article) form: mailbox%domain1@domain2, or more specifically, user%node.bitnet@gateway.domain where gateway.domain is DNS-based and may consist of subdomains and a top-level-domain, and node is the formal BITNET node (host) name. SLAC is no longer a part of the BITNET pseudo-domain so BITNET mail must be directed at an off-site gateway for delivery. The general form is user%node.bitnet@interbit.cren.net.

An example of an internal BITNET email address would be joe%cucsvm.bitnet@interbit.cren.net.

Internet to DECnet-based network mail

The internal DECnet-based address of the form host::user is usually only accepted by VAX/VMS computers and is an unacceptable address to most, if not all, Internet mailers. In many cases a user must try other forms of the address to get mail delivered. One could try an address converted from the original DECnet-style format to a pseudo-domain-based address of the form user@host.hepnet. However, this format will only work if host is a registered HEPnet site.

Sending the message to the nearest DECnet/Internet gateway might be necessary by using the form "host::user"@gateway.domain[1] or user%host.hepnet@gateway.domain, where gateway.domain is DNS-based. For these two formats, host must be known to the gateway.

[1] (The double quotes (") are necessary in this address, because the ":" character is a syntactically active character in Internet mail addresses. By quoting the mailbox part of the address the local Internet mailer will not try to interpret the ":" characters itself. It will just send the mailbox part of the address intact to the gateway mailer which will then correctly route the message.)

In any case, to get mail to an unregistered site it must be addressed relative to a "well known" site. In the HEPnet world, unregistered hosts are often "hidden" behind registered sites; therefore, mail to these hosts must be routed through a mailer at the registered site. For example, if a user is on node hidden that is "hidden" behind a remote site that has a mailer on node remote, one could address mail in one of these two formats:

"remote::hidden::user"@gateway.domain
user%hidden%remote.hepnet@gateway.domain

The Internet/HEPnet gateway is hep.net and mail would be addressed to "node::user"@hep.net or user%node.hepnet@hepnet.

DECnet-based network to Internet mail

Most VAX/VMS DECnet nodes at SLAC are also directly connected to the Internet and if an intelligent mailer program exists on the sender's DECnet (VAX/VMS) machine, the standard type of Internet DNS-based address (user@host.domain where domain may consist of subdomains and a top-level-domain) should work with only slight modification. The local DECnet mailer must be signaled that the address that is specified is intended for an intelligent mailer rather then just the normal DECnet mailer. This is done by specifying a protocol switch as part of the mail address, for example protocol%"user@host.domain". The three most common protocol switches used at SLAC are IN%, MX%, and SMTP%, which invoke the PMDF mailer, the MX mailer, and the Multinet SMTP mailer, respectively. Most likely only one of these mailers will be available. These intelligent mailers will transparently route the message by sending it directly or by sending the message to a HEPnet/Internet gateway. For VAX/VMS DECnet nodes that do not have an intelligent mailer the sender must route the message to a HEPnet(DECnet)/Internet gateway, such as gatewy::protocol%"user@host.domain".

For example, to reach jsmith@sld.SLAC.Stanford.EDU (and whose local Internet/HEPnet(DECnet) gateway is gatewy), the address should be converted to something like gatewy::protocol%"jsmith@sld.slac.stanford.edu", or if an intelligent mailer is available on the local node then the something like protocol%"jsmith@sld.slac.stanford.edu" could be used.

At SLAC, the HEPnet/Internet gateway is slacmh, so the general form would be slacmh::in%"user@node.domain", but most likely the shorter form can be used in%"user@node.domain".

Final Notes

Although lower-case letters were used to explain syntax and examples in this article, in general email systems are case-insensitive. Mixed and upper-case are usually acceptable as well, though there are some UNIX systems which are are case-sensitive.

This guide to email addressing is certainly not complete but should suffice for most cases. Different mail systems have varying capabilities and may not always behave according to the norm. If suggestions given in this article don't work, feel free to call the SCS Help Desk for further assistance with email addressing.

For more information on email issues specific to SLAC, see: SLAC Email

Teresa Downey
10 Jul 1998