Ex. GOOG 1045
`
`
`
`
`
`

`
`Tllifd Eclilion
`
`INTERNETWORKING WITH
`
`KP
`
`I
`II M E
`v 0 I
`PRINCIPLES, PROTOCOLS,
`
`;:%22sa;°as::
`
`_AND ARCHITECTURE
`
`DOUGLAS E. COMER
`
`Ex. GOOG 1045
`
`

`
`l.ibnry of Congre"" Cotologina-in-Pul>licotion D01o
`
`Comer, Dou&la•
`ln~ecnctwodtina wilh TCJ>/IP I Doualu E. Comer. -
`an.
`P
`Includes bibliopphicol "'fer=ca ond indcl.
`ConLCn<s: v. I. Principlu, protocou, 1nd on:hita:turc
`ISDN ~13-216917-1 (v. I)
`I. TCP/JP (Compu~er net"'c>r\ prot«ol) 2. Client/s<:rver coonputina.
`I. Title.
`J. lnlemetworking (Telecommunication)
`TKSIOS.58S.C66
`1995
`OOS.2-dc20
`
`lr<l ed.
`
`95-1830
`aP
`
`Acquisitions editor: ALAN APT
`ProduchOn edi!or. IRWIN ZUCKER
`Cover designer: WENDY ALLING JUDY
`Buyer: LORI BULWIN
`Editorial assrstant: SHIRl.EY MCGUIRE
`
`0 1995 by Prenuce-f:lall, Inc.
`A Simon &. Schuster Company
`:= Upper Saddle River. New Jersey 07458
`
`All rights reserved. No part of thiS book may be
`reproduced, in any fonn or by any means,
`without permission in writing from Hte publisher.
`
`The author and publisher oftllis book have used their best cffons in prep:uing thrs book. These effons include the
`development, research, Md testing of the theories and progr:uns 10 determine their effectiveness. The author and
`publisher make no wanamy of any kind, expressed or implied, with regard to these programs or the documemation
`contained in th1s book. The author and publisher shall not be liable in any event for incidental or consequential damages
`in connection with, or :uisinz out of, the furnishing. pcrfonnancc, oc use of these prot;r:un>.
`
`UNIX 1s a registered trademark of UNIX System Laboratories, Incorporated
`proNET-10 is a trademark of Protcon Corporation
`l..SI II tS a tradcrnarlc of Digital Equipment Corporation
`Microsoft Windows is a trademark of Microsort Corporation
`
`Printed in the United States of Arncnca
`
`10 9 8 7 6 5 4
`
`ISBN 0-13 -216987-8
`
`l'renuc:c-IIall International (UK) l..imrtcd, London
`Prentice-Hall of Australia Pty Limned, Sydney
`Prenticc-llall Canada lnc., Toronto
`Prcnticc-llall llispanoamcricana. S.A., Mexico
`Prentice-I I all of Indta Private Limited. New Delhi
`Prentice-Hall of Japan, Inc., Tokyo
`Simon & Schuster Asia Pte. Ltd., Singarorc
`Editora Prentice- Hall do Brasil, l..tda .. R1o de Janeiro
`
`Ex. GOOG 1045
`
`

`
`25
`
`Applications: Electronic Mail
`(822, SMTP, MIME)
`
`25.1 Introduction
`
`This chapter continues our exploration of imernetworking by considering electronic
`mail service and the protocols that support it. The chapter describes how a mail system
`is organized, explains alias expansion, and shows how mail system software uses the
`client-server paradigm to transfer each message.
`
`25.2 Electronic Mail
`
`Many users first encounter complller networks when they send or receive electronic
`mail (e-mail) to or from a remote site. E-mail is the most widely used application ser(cid:173)
`vice. Indeed, many computer users access networks only through electronic mail.
`E-mail is popular because it offers a fast, convenient method of transferring infor(cid:173)
`mation. E-mail can accommodate small notes or large voluminous memos with a single
`mechanism. It should not surprise you to learn that more users send files with electron(cid:173)
`ic mail than with file transfer protocols.
`Mail delivery is a new concept because it differs fundamentally from other uses of
`networks that we have discussed. In all our examples, network protocols send packets
`directly to destinations, using timeout and retransmission for individual segments if no
`acknowledgement returns. In the case of electronic mail, however, the system must
`provide for instances when the remote machine or the network connections have failed.
`A sender does not want to wait for the remote machine to become available before con-
`
`Ex. GOOG 1045
`
`

`
`434
`
`Appliclllions: Electronic Mail (822, SMTP, MIME)
`
`tinuing work, nor docs the user want the transfer to abon merely because communica(cid:173)
`tion with the remote machine becomes temrorarily unavailable.
`To handle delayed delivery, mail systems use a technique known as spooling.
`When the user sends u mail message, the system places a copy in its private storage
`{spoolt) area along with identification of the sender, recipient, dcstinmion machine, and
`time of deposit. The system then initiates the transfer to the remote machine as a back(cid:173)
`ground activity, allowing the sender to proceed with other computational activities.
`Figure 25.1 illustrates the idea.
`
`user sends mail
`
`IIStr rcads mail
`
`outgoing
`mail spool
`area
`
`mailboxes
`for
`incoming
`mail
`
`TCP conflection
`
`for OUifOing mail
`
`TCP connectio11
`
`for lflcoming mal(
`
`Figure 25.1 Conceptual components of an electronic mail system. The user
`invokes a user interface to deposit or retrieve mail; all transfers
`occur in the background.
`
`The background mail transfer process becomes a c lient. The process first uses the
`domain name system to map the destination machine name to an IP address, and then
`attempts to fonn a TCP connection to the mail server on the destination machine. If it
`succeeds, the transfer process passes a copy of the message to the remote server, which
`stores the copy in the remote system's spool area. Once the client and server agree that
`the copy has been accepted and stored, the client removes the local copy. If it cannot
`fonn a TCP connection or if the connection fails, the transfer process records the time
`delivery was attempted and terminates. The background transfer process sweeps
`through the spool area periodically, typically once every 30 minutes, checking for un(cid:173)
`delivered maiL Whenever it finds a message or whenever a user deposits new outgoing
`mail, the background process attempts delivery again. If it finds that a mail message
`cannot be delivered after an extended time (e.g., 3 days), the mail software returns the
`message to the sender.
`
`t Mait spool aiCOIS are sometimes called mail qurue areas even though the tenn is technically maccurate.
`
`Ex. GOOG 1045
`
`

`
`Sec. 25.3
`
`Mailbo~ Names And Aliases
`
`435
`
`25.3 Mailbox Names And Aliases
`
`There are three imponant ideas hidden in our simplistic description of mail
`delivery. First, users specify recipients by giving pairs of strings that identify the mail
`destirliltion machine name and a mailbox addre.~s on that machine. Second, the names
`used in such specifications are independent of ~ther names assigned to machines. Usual(cid:173)
`ly, a mailbox address is the same as a user's login id, and a destination machine name is
`the same as a machine's domain name, but that is not necessary. It is possible to assign
`a mailbox to a position of employment (e.g., the mailbox identifier departmenl-head can
`refer to whoever currently chairs the depanmem). Also, because the domain name sys(cid:173)
`tem includes a separate query type for mail destinations, it is possible to decouple mail
`destination names from the usual domain names assigned to machines. Thus, mail sent
`to a user at machine.com may go to a different machine than a telnet connection 10 the
`same machine name. Third, our simplistic diagram fails to account for mail processing
`and mail forwarding, which include mail sent from one user to another on the same
`machine, and mail that arrives on a machine but which should be forwarded to another
`machine.
`
`25.4 Alias Expansion And Mail Forwarding
`
`Most systems provide mail forwarding software that includes a mail alias expan·
`sion mechanism. A mail forwarder allows the local site to map identifiers used in mail
`addresses to a set of one or more new mail addresses. Usually, after a user composes a
`message und names a recipient, the mail interface program consults the local aliases to
`replace the recipient with the mapped version before passing the message to the delivery
`system. Recipients for which no mapping has been specified remain unchanged. Simi(cid:173)
`larly, the underlying mail system uses the mail aliases to map in~oming recipient ad(cid:173)
`dresses.
`In
`Aliases increase mail system functionality and convenience substantially.
`mathematical terms, alias mappings can be many-one or one-many. For example, the
`alias system allows a single user to have multiple mail identifiers, including nicknames
`and positions, by mapping a set of identifiers to a single person. The system also al(cid:173)
`lows a site to associate groups of recipients with a single identifier. Using aliases that
`map an identifier to a Jist of identifiers makes it possible to establish a mail exploder
`that accepts one incoming message and sends it to a large set of recipients. The set of
`recipiems associated with an identifier is called an electronic mailing list. Not all the
`recipients on a list need to be local. Although it is uncommon, it is possible to have a
`mailing list at site, Q, with none of the recipients from the list located at Q. Expanding
`a mail alias into a large set of recipients is a popular technique used widely. Figure
`25.2 illustrates the components of a mail system that suppons mail aliases and list ex(cid:173)
`pansion.
`
`Ex. GOOG 1045
`
`

`
`436
`
`Applic3lions: Elcctrooic Mail (822. SMTP. MIME)
`
`alias
`database
`
`outgoing
`mall spool
`area
`
`Figure 25.2 An extension of the mail system in Figure 25.1 that suppons mail
`aliases and forwarding. Both incoming and outgoing ma11
`passes through the alias expansion mechanism.
`
`As Figure 25.2 shows, incoming and outgoing mail passes through the mail for(cid:173)
`warder that expands aliases. Thus, if the alias database specifies that mail address x
`maps to replacement y, alias expansion will rewrite destination address x, changing it to
`y. The alias expansion program then determines whether y specifies a local or remote
`address, so it knows whether co place the message in the incoming mail queue or outgo(cid:173)
`ing mail queue.
`Mail alias expansion can be dangerous. Suppose two sites establish conflicting
`aliases. For example, assume site A maps mail address x imo mail address y at site B,
`while site B maps mail address y into address x at site A. A mail message sent to ad(cid:173)
`dress x at site A could bounce forever between the two sitest. Similarly, if the manager
`at site A accidentally maps a user's login name at that site to an address at another site,
`the user will be unable to receive mail. The mail may go to another user or, if the alias
`specifies an illegal address, senders will receive error messages.
`
`25.5 The Relations hip Of lnternetworking And Mail
`
`Many commercial computer systems can forward electronic mail from sites that do
`not connect to the Internet. How do such systems differ from the mail system described
`here? There are two crucial differences. First, a TCP/IP internet makes possible
`universal delivery service. Second, electronic mail systems built on TCP/IP are in-
`
`tin practice. most mail forwarders terminate messages after the number of exchanges reaches a prcdcter·
`mined threshold.
`
`Ex. GOOG 1045
`
`

`
`Sec. 2S.S
`
`The Relationship Of lmcmetworldog And Mail
`
`437
`
`herently more reliable than those built from arbitrary networks. The fust idea is easy to
`understand. TCP/IP makes possible universal mail delivery because it provides univer(cid:173)
`sal interconnection among machines. ln essence, all machines auached to an internet
`behave as if attached to a single, vendor independent network. With the basic network
`services in place, devising a standard mail exchange protocol becomes easier.
`The second claim, t11at using TCP/IP makes mail delivery more reliable than other
`mechanisms, needs explanation. The key idea here is that TCP provides end-to-end
`connectivity. That is, mail software on the sending machine acts as a client, contacting
`a server on the ullimate destination. Only after the client successfully transfers a mail
`message to the server does it remove the message from the local machine. Thus, direct,
`end-to-end delivery enforces the following principle:
`
`Mail systems that ust end-to-end delivery can guarantee that each
`mail message remaim ;, the sender's machine until it has been suc(cid:173)
`cessjuf/y copied to the recipient's machine.
`
`With such systems, the sender can always determine the exact status of a message by
`checking the local mail spool area.
`The alternative form of electronic mail delivery uses mail gatewayst, sometimes
`called mail bridges, mail relays, or intermediate mail stops to transfer messages. In
`such systems, the sender's machine does not contact the recipient's machine directly,
`but sends mail across one or more intermediate machines that forward it on.
`The main disadvantage of using mail gateways is that they introduce unreliability.
`Once the sender's machine transfers a message to the first intermediate machine, it dis(cid:173)
`cards the local copy. Thus, while the message is in transit, neither the sender nor the
`recipient have a copy. Failures at intermediate machines may result in message loss
`without informing either the sender or recipient. Message loss can Ollso result if the
`mail gateways route mail incorrectly. Another disadvantage of mail gateways is that
`they introduce delay. A mail gateway can hold messages for minutes, hours, or even
`days if it cannot forward them on to the next machine. Neither the sender nor receiver
`can determine where a message has been delayed, why it has not arrived, or how long
`the delay will last. The important point is that the sender and recipient must depend on
`machines over which they may have no control.
`If mail gateways are less reliable than end-to-end delivery, why are they used?
`The chief advantage of mail gateways is int~.-roperability. Mail gateways provide con(cid:173)
`nections among standard TCP/IP mail systems and other mail systems, as well as
`between TCP/IP internets and networks that do not support Internet protocols. Suppose,
`for example, that company X has a large internal network and that employees use elec(cid:173)
`tronic mail, but that the network software does not support TCP/IP. Although it may be
`infeasible to make the company's network part of the connected lmernet, it might be
`easy to place a mail gateway between the company's private network and the Internet,
`and ro devise software that accepts mail messages from the local network and forwan!s
`them to the Internet.
`
`tReaders should not confuse the tenn mail gateway with the tenn IP gateway, diS(:Ussed earher.
`
`Ex. GOOG 1045
`
`

`
`438
`
`Applications: Eloc1r0nic Mml (822, SMTI', MIME)
`
`Chap. 25
`
`While rhe idea of mail gateways may seem somewllar awkward, elecrronic mail ltas
`rurned into such an imponant tool that users who do nor have Internet access depend on
`them. Thus, allhougb gateways service is not as reliable or convenient as end-to-en<J
`delivery, it can still be useful.
`
`25.6 TCP/IP Standards For Electronic Mail Service
`
`Recall that the gonl of the TCP/IP protocol effort is to provide for interoperability
`across the widest range of computer systems and networks. To extend the interoperabil(cid:173)
`ity of electronic mail, TCP/IP divides its mail standards imo two sets. One standard
`specifies the fonnat for mail messagest. The other specifies the details of electronic
`mail exchange between two computers. Keeping !he two standards for elec1ronic mail
`separate makes ir possible to build mail gateways lhat connect TCP/IP interncts to some
`other vendor's mail delivery system, while still using the same message fonnat for both.
`As anyone who has used electronic mail knows, each memo is divided into two
`parts: a header and a body, separarcd by a blank line. The TCP/IP standard for mail
`messages specifies the exact format of mail headers as well as the semantic interpreta(cid:173)
`tion of each header field; it leaves the format of the body up to the sender. In panicu(cid:173)
`lar, the standard specifies that headers contain readable text, divided into lines that con(cid:173)
`sist of a keyword followed by a colon followed by a value. Some keywords are re(cid:173)
`quired, others are optional, and lhe rest are uninterpreted. For example, thP- header must
`contain a line that specifies the destination. The line begins To: and contains the elec(cid:173)
`tronic mail address of the intended recipient on the remainder of the line. A line that
`begins From: contains the electronic mail address of the sender. Optionally, the sender
`may specify an address to which replies should be sent (i.e., to allow the sender to
`specify that replies should be sent to an address orher than the sender's mailbox). If
`present, a line thar begins Reply-to: specifies the address for replies. If no such line ex(cid:173)
`ists, the recipient will use infonnation on the From: line as the return address.
`The mail message fonnat is chosen to make it easy to process and transpon across
`heterogeneous machines. Keeping the mail header format straightforward allows it to
`be used on a wide range of systems. Restricting messages to readable text avoids the
`problems of selecting a standard binary representation and translating between the stan(cid:173)
`dard representation and the local machine's representation.
`
`25.7 Electronic Mail Addresses
`
`A user fam iliar with electronic mail knows that mail address formats vary among
`e-mail systems. Thus, it can be difficult to determine a correct electronic mail address,
`or even to understand the sender's intentions. Within the global Internet, addresses
`have a simple, easy to remember form:
`
`local-part @ do111Jlin-11am~
`
`tMail system eApcns oflen refer to the rna1l message fonn.at as •·s22" because RFC 822 contains the
`standard (RFC 733 is a former standard no longer used).
`
`Ex. GOOG 1045
`
`

`
`Sec. 25.7
`
`Elecuonic M~il Addresses
`
`439
`
`where domain-name is the domain name of a mail destinationt to which the mail should
`be delivered, and local-parr is the address of a mailbox on that machine. For example,
`within the- Internet, the author's electronic mail address is:
`
`comer @purdue . edu
`
`However, mail gateways make addresses complex. Someone outside the Internet must
`either address the mail to the nearest mail gateway or have software that automatically
`does so. For example, when CSNET operated a mail gateway that connected between
`outside networks and the Internet, someone with access to the gateway might have used
`the following address to reach the author:
`
`comer% purdue. edu @ relay . cs . net
`
`Once the mail reached machine relay. cs . net, the mail gateway software extracted
`local-part, changed the percent sign (%) into an at sign (@), and used the result as a
`destination address to forward the mail.
`The reason addresses become complex when they include non-Internet sites is that
`the electronic mail address mapping function is local to each machine. Thus, some mail
`gateways require the local pan to contain addresses of the form:
`
`while others require:
`
`user% domain-name
`
`user : domain-name
`
`and still others use completely different forms. More important, electronic mail systems
`do not usually agree on conventions for precedence or quoting, making it impossible for
`a user to guarantee how addresses will be treated. For example, consider the electronic
`mail' address:
`
`comer% purdue.edu@ relay.cs.net
`
`mentioned earlier. A site using the TCP/IP standard for mail would interpret the ad(cid:173)
`dress to mean, "send the message to mail exchanger relay. cs. net and let that mail ex(cid:173)
`changer decide how to interpret comer% purdue. edu" (the local part). In essence, 'the
`sites act as if the address were parenthesized:
`
`(comer% purdue. edu) @ (relay. cs. net)
`
`At sites that use % to separate user names from destination machines, the same address
`might mean, "send the mail to user comer at the site given by the remainder of the ad(cid:173)
`dress." That is, such sites act as if the address were parenthesized;
`
`(comer) % (purdue . edu @relay. cs . net)
`
`tTechnically, the domain name spectfies a mat/ exchanger, not a machine name.
`
`Ex. GOOG 1045
`
`

`
`440
`
`Applications: El«:tronic Mail (822, SMTP, MIME)
`
`Chap. 2S
`
`We can summarize the problem:
`
`Because each maif gateway determines the exact details of how it in(cid:173)
`terprets and maps electronic mail addresses, there is no standard for
`addresses that cross mail gateway boundaries to networks outside the
`Internet.
`
`25.8 Pseudo Domain Addresses
`
`To help solve the problem of multiple mail systems, each with its own e-mail ad(cid:173)
`dress fom1at, a site can use domain-style names for all e-mail addresses. even if the site
`does not use the domain nam~stem. For example, a site that uses UUCP can imple(cid:173)
`ment a pseudo-domain, uucp, that allows users to specify mail addresses of the form:
`
`or a related form:
`
`uucp-style address @ uucp
`
`user @ uucp-site. uucp
`
`The local mail forwarding software recognizes the special addresses and translates them
`to the address syntax required by tlte UUCP network software. From the user's per(cid:173)
`spective, the advantage is clear: all electronic addresses have the same general format
`independent of the underlying communication network used to reach the recipient Of
`course, such addresses only work whCJ'e local mailers have been instructed to map them
`into appropriate forms and only when the appropriate transport mechanisms are avail(cid:173)
`able. Furthermore, even though pseudo-domain mail addresses have the same form as
`domain names, they can only be used with electronic mail - one caMot find IP ad(cid:173)
`dresses or mail exchanger addresses for them using the domain name system.
`
`25.9 Simple Mail Transfer Protocol (~MTP)
`
`In addition to message formats, the TCPIIP protocol suite specifies a standard for
`the exchange of mail between machines. That is, the standard specifies the exact fonnat
`of messages a client on one machine uses to transfer mail to a server on another. The
`standard transfer protocol is known as SMTP, the Simple Mail Transfer Protocol. As
`you might guess, SMTP is simpler than an earlier Mail Transfer Protocol, MTP. The
`SMTP protocol focuses specifically on how the underlying mail delivery system passes
`messages across a link from one machine to another. It does not specify how the mail
`system accepts mail from a user or how the user interface presents the user with incom(cid:173)
`mg maiL Also, SMTP docs not specify how mail is stored or how frequently the mail
`system attempts to send messages.
`
`l • . ,
`
`Ex. GOOG 1045
`
`

`
`Sec. 25.9
`
`Simple Mail Transfer Protocol (SMTP)
`
`441
`
`SMTP is surprisingly straightforward. Communication between a client and server
`consists of readable ASCJI text. Although SMTP rigidly defines the command format,
`humans can easily read a transcript of interactions between a client and server. Initially,
`the client establishes a reliable stream connection to the server and waits for the server
`to send a 220 READY FOR MAIL message. (If the server is overloaded, it may delay
`sending the 220 message temporarily.) Upon receipt of the 220 message, the client
`sends a HELOt command. The end of a line marks the end of a command. The server
`responds by identifying itself. Once communication has been established, the sender
`can transmit one or more mail messages, tenninate the connection, or request the server
`to exchange the roles of sender and receiver so messages can flow in the opposite direc(cid:173)
`tion. The receiver must acknowledge each message. It can also abort the entire con(cid:173)
`nection or abort the current message transfer.
`Mail transactions begin with a MAIL command that gives the sender identification
`as well as a FROM: field that contains the address to which errors should be reported.
`A recipient prepares its data structures to receive a new mail message, and replies to a
`MAIL command by sending the response 250. Response 250 means that all is well.
`The full response consists of the text 250 OK. As with other application protocols, pro(cid:173)
`grams read the abbreviated commands and 3-digit numbers at the beginning of lines;
`the remaining text is intended to help humans debug mail software.
`After a successful MAIL command, the sender issues a series of RCPT commands
`that identify recipients of the mail message. The receiver must acknowledge each
`RCPT command by sending 250 OK or by sending the error message 550 No such user
`here.
`After all RCPT commands have been acknowledged, the sender issues a_ DATA
`command. In essence, a DATA command informs the receiver that the sender is ready
`to transfer a complete mail message. The receiver responds with message 354 Start
`mail input and specifies the sequence of characters used to terminate the mail message.
`The tennination sequence consists of 5 characters: carriage return, line feed, period, car(cid:173)
`riage return, and line feed;.
`An example will clarify the SMTP exchange. Suppose user Smith at host
`11/pha.EDU sends a message to users Jones~reen, and Brown at hosb Beta.GOV. The
`SMTP client software on host Alpha.EDU contacts the SMTP server software on host
`Beta.GOV and begins the exchange shown in Figure 25.3.
`
`tHEW is an abbreviation for "hello ...
`~SMTP uses CR LF to tenninate a line, and forbids the body of a mail message to have a period on a line
`by itself.
`
`Ex. GOOG 1045
`
`

`
`442
`
`Applicacions: Elcccronic Mail (822. SMTI', MIME)
`
`S: 220 Beta.GOV Simple Mail Trans fer Service Ready
`C: HELO Alpha.EDU
`S: 250 Beta.GOV
`
`C: MAIL FROM:<Smith@Alpha . EDU>
`S: 250 OK
`
`C: RCPT TO:<Jones@Beta .GOV>
`S: 250 OK
`
`C: RCPT TO:<Green@Beta.GOV>
`
`S: 550 No such user here -
`
`C: RCPT TO:<Brown@Beta.GOV>
`S: 250 OK
`
`C: DATA
`S: 354 Start mail input; end with <CR><LF> .<CR><LF>
`C : ... sends body of mail message ...
`C : ... continues for as many lines as messa ge contains
`C : <CR><LF>.<CR><LF>
`S: 250 OK
`
`C: QUIT
`S: 221 Beta.GOV Service closing transmission channel
`
`Figure 25.3 EJtamplc of SMTP transfer from Alpha.EDU to Bcta.GOV.
`Lines that begin with "C:" are transmitted by the client (Al(cid:173)
`pha), while lines that begin " S:" arc transmitted by the server.
`In the cJtamplc, machine Beta.GOV docs not recognize the in(cid:173)
`tended recipient Green.
`
`[
`
`In the example, the server rejects recipient Green because it docs not recognize the
`name as a valid mail destination (i.e., it is neither a user nor a mailing list). The SMTP
`protocol does not specify the details of how a client handles such errors -
`the client
`must decide. Although clients can abort the delivery completely if an error occurs,
`most cliems do not. Instead, they continue delivery to all valid recipients and then re·
`port problems to the original sender. Usually, the client repons errors using electronic
`mail. The error message contains a summary of the error as well as the header of the
`mail message that caused the problem.
`Once a client has finished sending all the mail messages it has for a particular des(cid:173)
`tination, the client may issue tlte TURNt command to tum the connection around. If it
`does, the receiver responds 250 OK and assumes control of the connection. With the
`roles reversed, the side that was originally a server sends back any waiting mail mes-
`
`tin pracllce, few mail servers use rhe TURN command.
`
`Ex. GOOG 1045
`
`

`
`Sec. 25.9
`
`Simple Mail Transfer Protocol (SMlP)
`
`443
`
`sages. Whichever side controls the interaction can choose to terminate the session. To
`do so, it issues a QUIT command. The other side responds with command 221, which
`means it agrees to terminate. Both sides then close the TCP connection gracefully.
`SMTP is much more complex than we have outlined here. For example, if a user
`has moved, the server may know the user's new mailbox address. SMTP allows the
`server to choose to inform the client about the new address so the client can use it in
`the future. When informing the client about a new address, the server may choose to
`forward the mail that triggered the message, or it may request that the client take the
`responsibility for forwarding.
`
`25.10 The MIME Extension For Non-ASCII Data
`
`To allow l.ransmission of non-ASCU data through e-mail, the IETF defined the
`Multipurpose Internet Mail Extensions (MIME). MIME does not change SMTP or re(cid:173)
`Instead, MIME allows arbilrary data to be encoded in ASCII and then
`place iL
`transmitted in a standard e-mail message. To accommodate arbil.rary data types and
`representations, each MIME message includes information that tells the recipient the
`type of the data and the encoding used. MIME information resides in the 822 mail
`header- the MIME header lines specify the version of MIME used, the type of the data
`being sent, and the encoding used to c~mvert the data to ASCII. For example, Figure
`25.4 illustrates a MIME message that contains a photograph in standard GIFt represen(cid:173)
`tation. The GIF image has been converted to a 7-bit ASCII representation using the
`base64 encoding.
`
`From: bill@acollege.edu
`To: john@somewhere.com
`MIME-Version : 1.0
`Content~Type: image/gif
`Content-Transfer-Encoding: base64
`
`... data for the image ...
`Figure 25.4 An example MIME message. Lines in the header identify the
`type of the dal.ii.,ils well as the encoding used.
`
`In the figure, the header line MIME-Version: declares that the message was com(cid:173)
`posed using version I .0 of the MIME protocol. The Content-Type: declaration specifies
`that the data is a GIF image, and the Content-Transfer-Encoding: header declares that
`base64 encoding was used to convert the image to ASCU. To view the image, a
`receiver's mail system must first convert from base64 encoding back to binary, and then
`run an application that displays a GIF image on the user's screen.
`The MIME standard specifies that a Content-Type declaration must contain two
`identifiers, a content type and a subtype. separated by a slash. In the example, image is
`the content type, and gif is the subtype.
`
`tGIF is the Graphics Interchange Fonnat
`
`Ex. GOOG 1045
`
`

`
`Applications: Electronic Mail (822, SMn', MIME)
`
`Chap. 2S
`
`The standard defines seven basic conteall types, the valid subtypes for each, and
`transfer cncodings. For example, although an image must be of subtype }peg or gif, I ext
`cannot use ei1her subtype. In addition to 1he s1andard types and subtypes, MIME per(cid:173)
`mits a sender and receiver to define priva1e content typest. Figure 25.5 lists the seven
`basic content types.
`
`Content Type
`text
`image
`audio
`video
`application
`multipart
`
`message
`
`Used When Data In the Message Is
`Textual {e.g. a document).
`A still photograph or computer-generated image
`A sound recording
`A video recording that includes motion
`Raw data for a program
`Multiple messages that each htwe a separate content
`type and encoding
`An entire e-mail message (e.g., a memo that has been
`forwarded) or an external reference to a
`message (e.g., an FTP server and file name)
`
`Figure 25.5 The seven bas1c types thai can appe:1r in a MIME Conum-Type
`declaration and their meanings.
`
`25.11 MIME Multipart Messages
`
`The MIME multipart content type is useful because it adds considerable flexibility.
`The standard defines four possible subtypes for a multipart message; each provides im(cid:173)
`portant functionality. Subtype mixed allows a single message to contain multiple, in(cid:173)
`dependent submessages that each can have an independent type and encoding. Mixed
`muhipart messages make it possible to include text, graphics, and audio in a single mes(cid:173)
`sage, or to send a memo with additional da1a segments attached, similar to enclosures
`included with a business leiter. Subtype allernalive allows a single message to include
`multiple representations of the same data. Alternative multipart messages are useful
`when sending a memo to many recipients who do not all use the same hardware and
`software system. For example, one can send a documenl as both plain ASCII text and
`in formaued form, allowing recipients who have compurers with graphic capabilities to
`select the formatted form for viewing. Subtype parallel permits a single message to in(cid:173)
`clude subparts that should be viewed together (e.g ., video and audio subparts that must
`be played simuhaneously). Finally, subtype digest permits a single message to contain
`a set of other messages (e.g., a collection of the e-mail messages from a discussion).
`Figure 25.6 illustrates one. of the prime uses for multipart messages: an e-mail mes·
`sage can contain both a short text that explains 1he purpose of the message and other
`parts that contain nontextual information. In the figure, a note in the first part or the
`message explains that