lemme

SIMPLE MAIL TRANSFER PROTOCOL

INTRODUCTION

Electronic mail (e-mail) is one of the most popular network services nowadays. Most e-mail systems that send mail over the Internet use simple mail transfer protocol (SMTP) to send messages from one server to another. The messages can then be retrieved with an e-mail client using either post office protocol (POP) or Internet message access protocol (IMAP). SMTP is also generally used to send messages from a mail client to a mail server in “hostbased” (or Unix-based) mail systems, where a simple mbox utility might be on the same system [or via Network File System (NFS) provided by Novell] for access without POP or IMAP. This chapter describes the fundamentals of SMTP, elements of its client–server architecture (user agent, mail transfer agent, ports), request–response mechanism, commands,mail transfer phases, SMTP messages, multipurpose internet mail extensions (MIME) for non-ASCII (American Standard Code for Information Interchange) data, e-mail delivery cases, mail access protocols (POP3 and IMAP4), SMTP software, vulnerability and security issues, standards, associations, and organizations.

SMTP FUNDAMENTALS

SMTP is used as the common mechanism for transporting electronic mail among different hosts within the transmission control protocol/Internet protocol (TCP/IP) suite. It is an application layer protocol. Under SMTP, a client SMTP process opens a TCP connection to a server SMTP process on a remote host and attempts to send mail across the connection. The server SMTP listens for a TCP connection on a specific port (25), and the client SMTP process initiates a connection on that port (Cisco SMTP, 2005). When the TCP connection is successful, the two processes execute a simple request–response dialogue, defined by the SMTP protocol (see RFC 821 for details), in which the client process transmits the mail addresses of the originator and the recipient(s) for a message. When the server process accepts these mail addresses, the client process transmits the e-mail instant message. The message must contain amessage header and message text (“body”) formatted in accordance with RFC 822. Mail that arrives via SMTP is forwarded to a remote server, or it is delivered to mailboxes on the local server. POP3 or IMAP allow users download mail that is stored on the local server. Most mail programs such as Eudora allow the client to specify both an SMTP server and a POP server. On UNIX-based systems, Sendmail is the most widely used SMTP server for e-mail. Sendmail includes a POP3 server and also comes in a version forWindows NT (“What is SMTP?”, 2005). The MIME protocol defines the way files are attached to SMTP messages. Microsoft Outlook and Netscape/Mozilla Communicator are the most popular mail-agent programs on Window-based systems. The X.400 International Telecommunication Union standard (Tanenbaum, 2003) that defines transfer protocols for sending electronic mail between mail servers is used in Europe as an alternative to SMTP. Also, the message handling service (MHS) developed by Novell is used for electronic mail on Netware networks (“What is SMTP?”, 2005)
SMTP MODEL AND PROTOCOL

The SMTP model (RFC 821) supports both end-to-end (no intermediate message transfer agents [MTAs]) and store-and-forward mail delivery methods. The end-to-end method is used between organizations, and the store-and forward method is chosen for operating within organizations that have TCP/IP and SMTP-based networks A SMTP client will contact the destination host’s SMTP server directly to deliver the mail. It will keep the mail item from being transmitted until it has been successfully copied to the recipient’s SMTP. This is different from the store-and-forward principle that is common in many other electronic mailing systems, where the mail item may pass through a number of intermediate hosts in the same network on its way to the destination and where successful transmission from the sender only indicates that the mail item has reached the first intermediate hop (“Simple Mail Transfer Protocol” [SMTP], 2004). The RFC 821 standard defines a client–server protocol. The client SMTP is the one, which initiates the session (that is, the sending SMTP) and the server is the one that responds (the receiving SMTP) to the session request. Because the client SMTP frequently acts as a server for a user-mailing program, however, it is often simpler to refer to the client as the sender-SMTP and to the server as the receiver-SMTP. An SMTP-based process can transfer electronic mail to another process on the same network or to another network via a relay or gateway process accessible to both networks (Sheldon, 2001). An e-mail message may pass through a number of intermediate relay or gateway hosts on its path from a sender to a recipient. A simple model of the components of the SMTP system is shown in Figure 1. Users deal with a user agent (UA). Popular user agents for UNIX include Berkeley Mail, Elm, MH, Pine, and Mutt. The user agents for Windows include Microsoft Outlook/Outlook Express and Netscape/Mozilla Communicator. The exchange of mail using TCP is performed by an MTA. The most common MTA for UNIX systems is Sendmail, and MTA for Windows is Microsoft Exchange 2000/2003. In addition to stable hostbased e-mail servers, Microsoft Corporation has developed LDAP/Active-directory servers and B2B-servers that enhance mail-delivery practices. Users normally do not deal with the MTA. It is the responsibility of the system administrator to set up the local MTA. Users often have a choice, however, for their user agent (Stevens, 1993). The MTA maintains a mail queue so that it can schedule repeat delivery attempts in case a remote server is unable. Also the local MTA delivers mail to mailboxes, and the information can be downloaded by the UA (see Figure 1). The RFC 821 standard specifies the SMTP protocol, which is a mechanism of communication between two MTAs across a single TCP connection. The RFC 822 standard specifies the format of the electronic mail message that is transmitted using the SMTP protocol (RFC 821) between the two MTAs. As a result of a user mail request, the sender-SMTP establishes a two-way connection with a receiver-SMTP. The receiver-SMTP can be either the ultimate destination or an intermediate one (known as a mail gateway). The sender-SMTP will generate commands, which are replied to by the receiver-SMTP (see Figure 1).Both the SMTP client and server should have two basic components: UA and local MTA. There are few cases of sending electronic-mail messages across networks. In the first case of communication between the sender and the receiver across the network (see Figure 1), the sender’s UA prepares the message, creates the envelope, and puts message in the envelope. The MTA transfers the mail across the network to the TCP-port 25 of the receiver’s MTA. In the second case of communication between the sending host (client) and the receiving host (server), relaying could be involved (see Figure 2). In addition to one MTA at the sender site and one at the receiving site, other MTAs, acting as client or server, can relay the electronic mail across the network.

The system of relays allows sites that do not use the
TCP/IP protocol suite to send electronic mail to users on other sites that may or may not use the TCP/IP protocol suite. This third scenario of communication between the sender and the receiver can be accomplished through the use of an e-mail gateway, which is a relay MTA that can receive electronic mail prepared by a protocol other than SMTP and transform it to the SMTP format before sending it. The e-mail gateway can also receive electronic mail in the SMTP format, change it to another format, and then send it to the MTA of the client that does not use the TCP/IP protocol suite (Forouzan, 2003). In various implementations, there is the capability to exchange mail between the TCP/IP SMTP mailing system and the locally used mailing systems. These applications are called mail gateways or mail bridges. Sending mail through a mail gateway may alter the end-to-end delivery specification, because SMTP will only guarantee delivery to the mail-gateway host, not to the real destination host, which is located beyond the TCP/IP network. When a mail gateway is used, the SMTP end-to-end transmission is host-togateway, gateway-to-host or gateway-to-gateway; the behavior beyond the gateway is not defined by SMTP.
USER AGENT
Introduced in RFC 821 and RFC 822, the SMTP defines user agent functionality, but not the implementation details.
A survey of the SMTP implementations can be found in RFC 876. The UA is a program that is used to send and receive electronic mail. The most popular user agent programs for UNIX are Berkley Mail, Elm, MH, Mutt,
Mush, and Zmail. Some UAs have an extra user interface
(e.g., Eudora) that allows window-type interactions with the system. The user agents for Windows include
Microsoft Outlook/Outlook Express and Netscape/Mozilla
Communicator.
Sending e-Mail
Electronic mail is sent by a series of request–response transactions between a client and a server. AnSMTPtransaction consists of the envelope and message, which is composed of header (with From: and To: fields) and body
(text after headers sent with the DATA command). The envelope is transmitted separately from the message itself using MAIL FROM and RCPT TO commands (see RFC
1123). A null line, that is, a line with nothing preceding the sequence, terminates the mail header. Some implementations (e.g., VM, which does not support zerolength records in files), however, may interpret this differently and accept a blank line as a terminator (SMTP,
2005). Everything after the null (or blank) line is the message body, which is a sequence of lines containing ASCII characters. The message body contains the actual information that can be read by the recipient.
Mail Header Format
The header includes a number of key words and values that define the sending date, sender’s address, where replies should go, and some other information.
The header is a list of lines, of the form (SMTP, 2005): field-name: field-value
Fields begin in column 1: Lines beginning with white space characters (SPACE or TAB) are continuation lines, which are unfolded to create a single line for each field in the canonical representation. Strings enclosed in ASCII quotation marks indicate single tokens within which special characters such as the colon are not significant. Many important field values (such as those for the “To” and
“From” fields) are “mailboxes.” The most common forms for these are the following:
_ [e-mail]
_ John Smith
_ “John Smith”
The string “John Smith” is intended for human recipients and is the name of the mailbox owner. The string
“[e-mail]” is the computer-readable address of the mailbox (the angle brackets are used to delimit the address but are not part of it). One can see that this form of addressing is closely related to the domain name system (DNS) concept (Internet Assigned Numbers
Authority [IANA], 2005). In fact, the client SMTP uses the DNS to determine the IP address of the destination mailbox. Some frequently used fields (key words) are the following:
_ to Primary recipients of the message.
_ cc Secondary (“carbon-copy”) recipients of the message.
_ from Identity of sender.
_ reply-to The mailbox to which responses are to be sent. This field is added by the originator.
_ return-path Address and route back to the originator.
This field is added by the final transport system that delivers the mail.
_ Subject Summary of the message. The user usually provides the summary.
Receiving e-Mail
The UA periodically checks the content of the mailboxes
(see Figure 1). It informs the user about mail arrival by giving a special notice. When the user tries to read the mail, a list of arrived mail packages is displayed. Each line of the list contains a brief summary of the information about a particular package in the mailbox. The summary may include the sender mail address, the subject, and the time the mail was received or sent. By selecting any of the packages, the user can view its contents on the terminal display. The SMTP Destination Address
The SMTP destination address (a mailbox address), in its general form local-part@domain-name, can take several forms (SMTP, 2005):
_ user@host—For a direct destination on the same TCP/IP network. _ user%remote-host@gateway-host—For a user on a non-
SMTP destination remote-host, via the mail gateway gateway-host. _ @host-a,@host-b:user@host-c—For a relayed message.
This form contains explicit routing information. The message will first be delivered to host-a, who will resend
(relay) the message to host-b. Host-b will then forward the message to the real destination host-c. Note that the message is stored on each of the intermediate hosts; therefore, there is no end-to-end delivery in this case. This address form is obsolete and should not be used (see RFC 1123).
Delayed Delivery
The SMTP protocol allows delayed delivery, and the message can be delayed at the sender site, the receiver site, or the intermediate servers (Forouzan, 2003).

In the case of delaying at the sender site, the client has to accommodate a spooling system, in which e-mail messages are stored before being sent. A message created by the user agent is delivered to the spool storage. The client mail transfer agent periodically (usually every 10 to 30 minutes) checks the spool to find the mail that can be sent. The mail will be sent only if the receiver is ready and the IP address of the server has been obtained though
DNS. If a message cannot be delivered in the timeout period
(usually about 3 to 5 days), the mail returns to the sender. Upon receiving the message, the server-MTA stores it in the mailbox of the receiver (see Figure 1). In this case, the receiver can access the mailbox at any convenient time.
Finally, the SMTP standard procedures allow intermediate
MTAs to serve as clients and servers. Both intermediate clients and servers can receive mail, store mail messages in their mailboxes and spools, and send them later to an appropriate destination.
Aliases
The SMTP mechanism allows one name, an alias, to represent several e-mail addresses (this feature is known as
“one-to-many alias expansion”; Forouzan, 2003). Additionally, a single user can also be defined by several e-mail addresses (this is called “many-to-one alias expansion”).
The system can handle these expansions by including an alias expansion facility (connected to the alias databases) at both the sender and receiver sites.
MAIL TRANSFER AGENT
MTAs transfer actual mail. The system must have the client MTA for sending e-mail and the server MTA for receiving mail (see Figure 1). The SMTP-related RFCs do not define a specific MTA. The UNIX-based MTA uses commonly the Sendmail utility. The most common MTA for
Windows is Microsoft Exchange 2000/2003.
The “mta-name-type” and “address-type” parameters
(e.g., dnc and rfc822 for the Internet mail, respectively) are defined for use in the SMTP delivery status notification document (see RFC1891). An identification of other mail systems can also be used. One of the identification methods has been described in “The COSINE and Internet
X.500 Schema” (section 9.3.18) in the RFC1274 document.
The mail system names listed here are used as the legal values in that schema under the “otherMailbox” attribute “mailboxType” type, which must be a PrintableString.
The “Mapping between X.400 (1988)/ISO 10021 and RFC 822” is described in the section 4.2.2 of the
RFC1327 document. The names listed here are used as the legal values in that schema under the “std-or-address” attribute “registered-dd-type” type, which must be a “keystring”
(for details, see Mail Parameters, 2002).
SMTP Mail Transaction Flow
The SMTP protocol (RFC 821) defines how commands and responses must be sent by the MTAs. The client sends commands to the server, and the server responds with numeric reply codes and optional human-readable strings.
There are a small number of commands (less than a dozen) that the client can send to the server. An example of sending a simple one-line message and an interpretation of the SMTP connection can be found in Stevens (1993).
Although mail commands and replies are rigidly defined
(see “Commands and Responses” later in this chapter), the exchange can easily be followed in Figure 3.
In this scenario (Comer, 1995; SMTP, 2005), the user jsmith at host sun.it.rivier.edu sends a note to users darien, steve and bryan at host mail.unh.edu.
Here the lines sent by the server (receiver) are preceded by S, and the lines sent by the client (sender) preceded by
C. Note that the message header is part of the data being transmitted. All exchanged messages (commands, replies, and data) are text lines, delimited by a . All replies have a numeric code at the beginning of the line.
The scenario includes the following steps (SMTP,
2005):
1. The client (sender-SMTP) establishes a TCP connection with the destination SMTP and then waits for the server to send a 220 Service ready message or a 421 Service not available message when the destination is temporarily unable to proceed.
2. The HELO command is sent, and the receiver is forced to identify himself by sending back its domain name.
The client (sender-SMTP) can use this information to verify if it contacted the right destination SMTP. If the sender-SMTP supports SMTP service extensions as defined in the RFC 1651, it may substitute an EHLO command in place of the HELO command.
A receiver-SMTP, which does not support service extensions, will respond with a 500 Syntax error, command unrecognized message. The client (sender-
SMTP) should then retry with HELO, or if it cannot transmit the message without one or more service extensions, it should send a QUIT message. If a receiver-
SMTP supports service extensions, it responds with a multiline 250 OK messages that include a list of service extensions, which it supports.
3. The client (sender) now initiates the start of a mail transaction by sending a MAIL command to the receiver.
This command contains the reverse-path, which can be used to report errors. Note that a path can be more than just the user-mailbox@host-domain-name pair. In addition, it can contain a list of routing hosts.
Examples of this are when the mail passes a mail bridge or when the user provides explicit routing information in the destination address. If accepted, the server (receiver) replies with a 250 OK message.
4. The second step of the actual mail exchange consists of providing the server SMTP with the destinations for the message (there can be more than one recipient). This is done by sending one or more RCPT TO: commands. Each of them will receive a 250 OK reply if the destination is known to the server or a 550
No such user here reply if it is not.
5. When all RCPT commands are sent, the client (sender) issues a DATA command to notify the server (receiver) that the message contents are following. The server replies with the 354 Start mail input, end with . message.

6. The client now sends the data line by line, ending with the sequence . line on which the receiver acknowledges with a 250 OK or an appropriate error message if anything went wrong.
7. The following actions (SMTP, 2005) are possible after that: _ The sender has no more messages to send; he will end the connection with a QUIT command, which will be answered with a 221 Service closing transmission channel reply (see Figure 3).
_ The client (sender) has another message to send and simply goes back to Step 3 to send a new MAIL command.
In this description, only the most important commands that must be recognized in each SMTP implementation
(see RFC821) have been mentioned. Other optional commands
(the RFC 821 standard does not require them to be implemented everywhere) implement several important functions such as forwarding, relaying, mailing lists, and so on.
SMTP Commands
The commands formed with ASCII (text) are sent from the client to the server. The simple structure of the commands allows for building mail clients and servers on any platform. The list of commands and their description and formats are shown in Table 1. The command consists of a key word followed by zero or more arguments. Five commands (HELO, MAIL FROM, RCPT TO, DATA, and
QUIT) are mandatory, and every implementation must support them. The other three commands (RSET, VRFY, and NOOP) are often used and highly recommended. The next six programs (TURN, EXPN, HELP, SEND FROM,
SOML FROM, and SAML FROM) are seldom used.
For a full list of commands, see the RFC 821 “Simple
Mail Transfer Protocol” and RFC 1123 “Requirements for
Internet Hosts—Application and Support.” For details of
SMTP service extensions, see the RFC 1651 “SMTP Service
Extensions,” RFC 1652 “SMTP Service Extension for
8bit-MIMEtransport,” RFC 1653 “SMTP Service Extension for Message Size Declaration,” and RFC 2554 “SMTP
Service Extension for Authentication.”
The commands normally progress in a sequence (one at a time). The advanced pipelining feature introduced in the RFC 2920 document allows multiple commands to be sent to a server in a single operation of the TCP-send type.
Mail Service Types
The set of services desired from a mail server are sometimes characterized by the “hello” key word. The various mail service types are as follows (Mail Parameters, 2002):
_ HELO for Simple Mail (see RFC821)
_ EHLO for Mail Service Extensions (see RFC1869)
_ LHLO for Local Mail (see RFC2033).

Command
Description
Format
References

References: