Charles M. Kozierok The TCP-IP Guide

Подождите немного. Документ загружается.

URL E-Mail Address Specification

It is also possible to specify an e-mail address using an Internet-standard Uniform

Resource Locator (URL). This allows a link to be embedded in a hypertext (Web) document

that when clicked, invokes an e-mail client to send mail to a user. E-mail URLs are created

by preceding the address by the special URL scheme string “mailto:”, like this:

mailto:cmk@athena.mit.edu

The Special Requirements of E-Mail Addresses

Having e-mail addressing refer to the user's local SMTP server provides a great deal of

flexibility compared to having addresses mention a specific client computer. But it doesn't

provide enough flexibility to handle various situations:

☯ An organization may want to use “generic” addresses that do not specify the name of

the SMTP server to handle mail. The reason is that this requires people sending them

mail to know the name of that server. For example, if someone knew my real name

and that I was at MIT, it would be easier for them to remember my old e-mail address

as “cmk@mit.edu” than “cmk@athena.mit.edu”.

☯ An administrator may change which machines handle mail over a period of time. This

would mean all the users's e-mail addresses would have to change— and most of us

know what a pain that is. For example, if I moved from the “athena” machine to the

“jabberwocky” machine, my old address would have needed to change to

“cmk@jabberwocky.mit.edu”. But if it were just “cmk@mit.edu” the change would not

affect me.

☯ In larger organizations, it might be desirable to have multiple servers share the load of

handling incoming mail.

The Mail Exchange (MX) DNS Record

To address all of these requirements, the DNS system includes a feature that was specifi-

cally designed to support electronic mail addressing. A special mail exchange (MX) record

can be set up that specifies which SMTP server should be used for mail coming in to a

particular domain name. If properly configured, this allows considerable flexibility to handle

the cases I described above and more. For more details, please see the description of the

MX record and DNS electronic mail support.

For example, I am the owner of the “pcguide.com” domain name. E-mail can be sent to me

at “pcguide.com”, but it is not actually stored on any server by that name. It is redirected to

the real server where my inbox is located. This allows me to handle all incoming mail to

“pcguide.com” regardless of where my mailbox is actually located.

DNS is also significant in that its “MX” resource records eliminated the need to “relay” e-

mail from one SMTP server to the next to deliver it. In modern TCP/IP it is possible to send

e-mail directly from the sender's SMTP server to the recipient's, making communication

faster and more efficient. See the section devoted to SMTP for details.

Key Concept: Some form of addressing is required for all network communication;

since electronic mail is user-oriented, e-mail addresses are based on users as well.

In modern TCP/IP e-mail, standard addresses consist of a user name, which

specifies who the recipient is, and a domain name, which specifies the DNS domain where

the user is located. A special DNS mail exchange (MX) record is set up for each domain

that accepts e-mail, so a sending SMTP server can determine what SMTP server it should

use to send mail to a particular recipient.

TCP/IP Historical and Special Electronic Mail Addressing

TCP/IP electronic mail has been so successful that it is arguably the most important

worldwide standard for electronic messaging. The widespread acceptance of e-mail is tied

inextricably to that of TCP/IP and the Internet as a whole. Since most organizations want to

be part of the Internet, they connect to it and use its technologies, including the Domain

Name System that is the basis for TCP/IP e-mail addresses. In turn, the use of simple DNS-

style e-mail addresses (“user@domain”) encourages further use of e-mail because people

find it conceptually easy to decide how to send messages.

TCP/IP is not, however, the only electronic mail system around. Over the years several

other networks have developed e-mail systems. Due to the fact that the Internet is the

largest internetwork in the world, TCP/IP e-mail has often been used as a “clearing house”

of sorts to link together some of these different e-mail mechanism. This is called

gatewaying, and allows someone using a non-SMTP e-mail system to interact with

someone using TCP/IP, and vice-versa. Gatewaying is complex, and one of the reasons is

that e-mail systems use different ways of addressing mail. Let's take a look at a couple of

these systems and how they interact with TCP/IP.

FidoNet Addressing

One of the earliest independent e-mail systems was the FidoNet, which has been around

for a long time and is still in use today. FidoNet is a worldwide network connected using

modems and proprietary protocols; it is in essence, a “competitor” to the global TCP/IP

Internet. I put “competitor” in quotes because the two are not really comparable in terms of

number of users and the kinds of applications they support, but they are similar in overall

objectives: worldwide electronic communication.

FidoNet users are identified using four numbers that specify the FidoNet zone, net, node

and point (connection point). These addressing elements are used for sending mail on this

system, which again is completely distinct from TCP/IP. However, to allow communication

between TCP/IP and FidoNet, the FidoNet administrators have set up a gateway system

that allows mail to be sent to FidoNet using TCP/IP style domain names. This style of

mapping was also used by other systems with proprietary mail address formats to allow

them to interface with the Internet.

For example, if a user was on machine 4, node 205, net 141, zone 1 (North America), the

FidoNet address would be 1:141/205:4. The equivalent domain name would be

p4.f205.n141.z1.fidonet.org, and could be used for TCP/IP-style “user@domain”

addressing.

UUCP-Style Addressing

An older address style commonly associated with e-mail was the “UUCP style” address.

The Unix-to-Unix Copy Protocol (UUCP) was commonly used years ago to route mail

before SMTP became widely deployed (again, it is still used, just not as much as before).

The addresses in this system are specified as a path of hosts separated by exclamation

marks (“!”). The path dictates the route that mail takes to get to a particular user, passing

through a series of intermediate machines running UUCP. For example, if mail to “joe” at

the host “joesplace” had to go through three hosts “host1”, “host2” and “host3”, the address

would be:

host1!host2!host3!joesplace!joe

Since the slang term for an exclamation mark is “bang”, this came to be called bang path

notation.

The use of UUCP style notation was sometimes mixed with TCP/IP style domain name

address notation when DNS came into use. So you might have seen something like

“host1!user@domain”. There was some confusion in how exactly to interpret such an

address: does it mean to send mail first to “host1” and then to “user@domain”? Or does it

mean to first send it to the “domain” which then goes to “user” at “host1”? There was no

universal answer to this. The problem was mostly resolved both by the decrease in use of

UUCP and the move on the part of UUCP systems to TCP/IP style domain name

addressing.

Addressing for Gatewaying

Finally, you may encounter e-mail addresses that appear like multiple TCP/IP addresses

that have been nested using unusual punctuation. For example, you may see something

that looks like this:

user%domain1.com@subdomain.domain2.edu

This is a way of addressing sometimes seen when e-mail gateways are used; it will cause

the mail to be sent to “user%domain1.com” at “subdomain.domain2.edu”. The address then

is interpreted as “user@domain1.com”. However, again, not all systems are guaranteed to

interpret this the same way.

E-mail gatewaying is not a simple matter in general, and as you can see, one reason is the

use of different e-mail address styles and the problems of consistency in how complex

“hybrid” addresses are interpreted, as discussed above. However, as the Internet expands

and TCP/IP becomes more widespread, it is becoming less and less common to see these

older, special address formats in use. They are becoming more and more a “historical

curiosity” (unless you happen to use one of them!)

TCP/IP Electronic Mail Aliases / Address Books, Multiple Recipient Addressing

and Electronic Mailing Lists

Electronic mail is analogous to regular mail, but superior to it due to two main advantages of

digital and electronic communication. One of these is speed, which is why modern Internet

users have come up with the slang term “snail mail” to refer to the regular postal service. ☺

But the other is also essential: flexibility. E-mail allows you to send messages easily in ways

that would be cumbersome with regular mail. And one of the ways this flexibility can be

seen is in addressing.

The first way that e-mail addressing is flexible is that most e-mail clients support advanced

features that allow users to specify the identity of recipients in convenient ways. While TCP/

IP addressing really is fairly straight-forward, remembering the addresses of everyone you

know is difficult. In the real world we use address books to help us remember addresses.

With e-mail, we can do the same, by allowing e-mail software to associate a name with an

e-mail address. This is usually done in one of two ways.

E-Mail Address Aliases

In “old-fashioned” text-based e-mail such as that used on many UNIX systems, name and

address association is performed using aliases. These are short forms for e-mail addresses

that save typing. For example, my wife's name is Robyn and I often send her e-mail, but I'm

too lazy to type in her address all the time. So I have defined an alias for her in my e-mail

program called simply “r”. I enter the mail command and specify the alias “r” as the intended

recipient, and it expands it for me. (Yeah, I could have used “robyn” but hey, I'm really lazy.

☺)

Electronic Address Books

In modern graphical e-mail systems, aliases aren’t used. Instead, an electronic address

book is usually implemented, which is of course the equivalent of the paper address book.

The difference is that there is no manual copying; you just choose the name from the list

using your mouse; nothing could be simpler unless the system could somehow read your

mind.

Specifying Multiple Recipients

Another advantage of electronic mail addressing is that it allows the easy specification of

multiple recipients. With paper mail, sending a message to ten people means you need ten

copies of the message, ten envelopes and also—ten stamps. With e-mail, you just list the

recipient addresses separated by a comma in the recipient list:

<user1@domain1>,<user2@domain2>,<user3@domain3>…

A separate copy is mailed to each recipient, easy as can be. Of course, aliases and/or

address books can be used to specify each recipient here as well, making this even simpler.

Since e-mail makes it so easy for one person to send information to a set of others, so-

called one-to-many messaging, it was also one of the first ways in which electronic group

communication was implemented. Prior to e-mail, sharing information in a group setting

either required a face-to-face meeting, or a telephone conference call. In both cases, all

parties have to be present simultaneously, and there is a cost involved, especially when the

parties are geographically distant.

With e-mail, a group of individuals can share information without needing to meet or even

be available at the same time. Suppose there is a group with four individuals: persons A, B,

C and D. Person A has a proposal that he wants discussed. He sends it to B, C and D.

Each recipient will read it at a time convenient for him or her. Each can then reply back to

the group. For example, D might have a comment on the proposal, so she just sends it to A,

B and C. Most e-mail clients include a group reply feature for this purpose.

Mailing Lists

In larger groups, communication by simply writing out the addresses of each recipient

becomes cumbersome. Instead, a mailing list is used. The list is created by an individual

termed the list owner and contains the electronic mail addresses of all the members of the

group. Then, a special list address is created. This address looks and functions just like a

regular e-mail address. However, when anyone sends mail to this special address, it is not

simply deposited into a mailbox. It is instead intercepted by special software that processes

the message and sends it out automatically to all recipients on the list. Any recipient can

reply back to the list address and all members will receive the reply.

There are many thousands of mailing lists on the Internet, covering every subject

imaginable. Each list differs in a number of regards, including the following:

☯ Implementation: Usually some sort of special software is used to allow the list owner

to manage it, add and remove users and set parameters that control how the list

operates. These programs are commonly called robots or listservs (list servers). One

of the more common ones is named Majordomo. There are also now mailing lists that

are actually implemented and managed using the World Wide Web. (The line between

Internet applications continues to get more and more blurry…)

☯ Subscription Rules and Technique: Some mailing lists are open to anyone who

wishes to join, while others are “by invitation only”. Most allow a new subscriber to join

automatically using software, others require the list owner to add new members.

☯ Management Method and Style: The list owner decides what is acceptable for

discussion on the list. Some lists are moderated, meaning that all submissions to the

list must be approved by the list owner before they are sent to list members. Some lists

allow mail to the list from non-members, some do not.

☯ “Culture”: Like all groups, groups of people on mailing lists have their own “culture”,

interesting “personalities” and so forth. New members of a list are often encouraged to

read the list and not send to it for a while until they become accustomed to it and how

it works. This is similar to the acclimation process for Usenet “newbies”.

☯ Special Features: Some lists support special features, such as the ability to subscribe

in digest mode (where messages are collected into large digests to cut down on the

number of individual messages sent) or to access messages on the Web.

Key Concept: One of the many benefits of electronic mail is that it is easy to send a

message to many people at once, simply by specifying several recipient addresses.

This permits easy and simple group communication, because each recipient can

then do a group reply to send a response to each of the people who were sent the original

message. Electronic mailing lists provide a more formalized way for groups to exchange

ideas and information; there are many thousands of such lists in existence on the Internet.

There are many other ways for groups to share information today, such as World Wide Web

bulletin boards, Usenet newsgroups, Internet Relay Chat and so forth. Some of these have

a lot of features that make mailing lists seem “unsophisticated” by comparison. Despite this,

electronic mailing lists are still very popular, largely because e-mail is the most universal

Internet communication method, and one of the easiest to use.

TCP/IP Electronic Mail Message Formats and Message Processing: RFC

822 and MIME

The advantages of using computers for communication are obvious, but there are also

some limitations that are imposed by the use of computer technology. When I compare

electronic mail to regular mail, I always point out that e-mail is much faster and more flexible

in how it can be delivered, and this is true. An electronic mail message can reach its desti-

nation in seconds, where a conventional letter would take days.

But one drawback computers have is that they are not very adaptable in figuring out how to

understand messages. Consider that anyone can put any type of letter, memorandum or

other communication in an envelope and send it to you, and assuming you know the

language it is written in, you can open the envelope and understand it. You can automati-

cally figure out how to deal with the date being in an unusual place in the letter, or your

name appearing at the top compared to the bottom, or the body of the message being

structured in different ways. You can read notes that are typed or hand-written; in pen,

pencil or crayon; as long as the letters are decipherable, you can understand what is being

said.

Computers are not very good at this at all. And it is for that reason that e-mail systems must

rely on standard message formats to ensure that all messages have the same form and

structure. This then makes it possible for all devices in the electronic mail system are able

to read and understand each others' messages, to enable TCP/IP e-mail to work on many

different types of computers.

In this section, I describe the two formats used for TCP/IP electronic mail messages, in two

subsections. The first describes the main TCP/IP electronic mail standard, which is called

the RFC 822 format after the standard that defines it. The second describes the Multi-

purpose Internet Mail Extensions (MIME) standard, which greatly expands the ability of

electronic mail to support the communication of different types of information, by defining

methods of encoding various media and non-English language text into the standard RFC

822 format.

TCP/IP Electronic Mail Standard Message Format: RFC 822

One of the most astute observations I have read about internetworking applications is that

their usefulness is proportional to the number of people who use them. TCP/IP e-mail is a

great example: it is a powerful communication method in large part because almost

everyone with a computer today participates in the system. The more people who sign on to

use e-mail, the more powerful it becomes.

The creators of TCP/IP email realized that people who use the system would employ many

different types of hardware and software. To ensure that everyone was able to understand

all e-mail messages, regardless of who sent them, they specified a common message

format for electronic mail messages. This format doesn't have an official fancy name; it is

simply known by the name of the standard that defines it: the RFC 822 message format.

In this section I describe the RFC 822 message format, which forms the basis for electronic

mail message transfer in TCP/IP. I begin with an overview of the format and the general

structure of messages, and some of the overall rules used to format RFC 822 messages. I

then describe the many headers used in RFC 822 e-mail messages, and how they are

arranged into groups. I conclude with a brief look at how RFC 822 messages are processed

and their contents interpreted.

Related Information: This section may make certain references to the one on

SMTP, but was designed so that you could read it prior to reading about SMTP

without getting confused. Well, I tried, anyway. ☺

TCP/IP Electronic Mail RFC 822 Standard Message Format Overview, Structure and

General Formatting Rules

The primary protocol for delivering electronic mail is the Simple Mail Transfer Protocol

(SMTP). For this reason, the message format used for TCP/IP e-mail could be considered

SMTP's “protocol message format”, not unlike the special message formats discussed for

other protocols, such as IP and TCP. However, the TCP/IP e-mail message format is used

not only by SMTP but by all protocols and applications that deal with electronic mail. This

includes the mail access protocols POP3 and IMAP, as well as others. It was also intended

to potentially be usable by other non-TCP/IP mail delivery protocols.

Perhaps for this reason, the TCP/IP e-mail format was not specified as part of the SMTP

itself, RFC 821, but rather in a companion document: RFC 822. Both were published in

1982. No official fancy name was given to this message format, and as a result the format

became known by the name of the standard itself: the RFC 822 message format.

Development of the RFC 822 Message Format Standard

The history of the message format used in TCP/IP goes back long before 1982, of course. It

was originally defined as the format for passing text messages on the Internet’s precursor,

the ARPAnet, in the early 1970s. Over time the format was refined several times, leading to

the publication, in 1977, of the important e-mail standard RFC 733 (Standard for the Format

of ARPA Network Text Messages). RFC 822 later streamlined the contents of RFC 733,

removing some of the features described in the earlier standard that failed to gain accep-

tance, and simplifying the specification.

In 2001, both SMTP and the RFC 822 message format were revised; SMTP is now

described in RFC 2821 and the message format in RFC 2822. This newer standard makes

relatively small changes to the RFC 822 message format to reflect modern use of TCP/IP e-

mail. Even though RFC 2822 is the current standard, the original name is still the one most

commonly used. I will respect that convention in this discussion, describing the message

format based on RFC 2822 while still calling it the “RFC 822” message format.

The RFC 822 format describes the form, structure and content of TCP/IP electronic mail

messages. It is, as I said, analogous to the message formats used for other protocols in

TCP/IP. Like those other formats, the RFC 822 format can be logically divided into two main

sections: the message header, which contains important control and descriptive infor-

mation, and the message body or payload, which carries the data.

Overview of RFC 822 Messages

Where RFC 822 differs from the field formats of other protocols is in expression. Most TCP/

IP protocols encode header information into a compact set of bytes that are read and

understood based on their location in the message and the semantic meaning assigned to

them. Consider the Internet Protocol, for example. The 9th byte of every IP datagram is the

Time To Live (TTL) field, which is encoded as a value from 0 to 255. A device reading an IP

datagram simply knows that byte number 9 contains the TTL value. If it sees the binary

value “00010011” there, it knows the TTL value for this datagram is the decimal value 19.

In contrast, RFC 822 messages do not use a binary format. They are entirely comprised of

lines of regular ASCII text (as used in the United States, called US-ASCII by the standard),

even the headers. Each line ends with an ASCII carriage return (CR) character, followed by

a line feed (LF) character; the combination is collectively termed “CRLF”. Each line of text

should be 78 characters or less (not including the terminating “CRLF”) and must not be

more than 998 characters (again, excluding the “CRLF”). Also, the characters CR and LF

must not appear by themselves within the text.

The RFC 822 message begins with a set of lines of text that collectively comprise the

message header. Each header field is expressed in the following form, in text:

So, for example, if there were a Time To Live field in RFC 822 messages (there isn't, of

course, as that concept has no meaning to e-mail) and a value of 19 needed to be

expressed, the header field would appear like this:

Time To Live: 19

This expressing of all fields as simple text means each header takes up more space in each

message; the string “Time To Live: 19” takes up 18 bytes including the terminating “CRLF”,

where the binary-encoded Time To Live field in the IP header takes only a single byte. What

we gain from this are two important benefits. First, any user can easily check the headers

and immediately understand what headers are present and what their values are, which

makes RFC 822 messages very readable. Second, since each header is explicitly labeled,

RFC 822 messages can vary in terms of the number of headers they contain, and even in

what order they appear, making them flexible.

General Structure

The RFC 822 message always starts with a set of header fields as described above; the

next topic describes them in more detail. After all the headers, an empty line must occur.

This consists simply of the characters “CRLF” by themselves, immediately following the

“CRLF” at the end of the final header field line. Seeing two “CRLF” character pairs in

sequence tells the device reading the message that the end of the headers have been

reached. All the remaining lines are considered the body of the message. Like the header

lines, body lines are comprised of ASCII text and must be no more than 998 characters,

with 78 characters or less recommended (for easier reading on standard 80-character

terminal displays).

Since both the header and body of e-mail messages are simply ASCII text, this means the

entire message is just a text file. This makes these messages very readable, as I said

above, and also quite easy to create. One can use a simple text editor to create a complete

electronic mail message, including headers, and can read it with a simple text display utility.

This contributes to e-mail's universal appeal.

The drawback is that the decision to make messages entirely ASCII means there is no

native support in RFC 822 messages for anything that requires more complex structuring,

or that cannot be expressed using the small number of ASCII characters. One cannot

express pictures, or binary files, spreadsheets, sound clips and so forth directly using

ASCII. Also, the use of ASCII makes RFC 822 well-suited to expressing messages in

English, but not in many other languages, which use characters that ASCII cannot

represent. All of these limitations eventually prompted the creation of the enhanced MIME

message format.

Key Concept: To ensure that every device on a TCP/IP internetwork can read e-mail

sent by every other device, all messages are required to adhere to a specific

structure. The standard that first specified the form of modern TCP/IP e-mail

messages was RFC 822, and as a result, this is now called the RFC 822 message format.

An RFC 822 message consist of a set of message headers and a message body, which are

separated by a blank line. RFC 822 messages must contain only plain ASCII text

characters; each line must be no more than 1000 characters in length, and the last two

characters must be the ASCII characters “CR” and “LF” to mark the end of the line.