Introduction to SMTP
| The Simple Mail Transfer Protocol (SMTP) is one of the oldest communication protocols on the Internetnearly as old as email itself. SMTP's purpose is to transfer plain-text messages from one host to another. This transfer often occurs between several servers in sequence, as when a dial-up client running Windows sends an email message to the ISP's mail server, which then transfers it to the recipient's mail server to be picked up by the recipient's mail program. SMTP sequences rarely get much longer than this example, though. It isn't like the Internet itself, with its hierarchical routing structure in which a packet is handed off by as many as 20 or 30 routers on its journey from one end to the other. Rather, the sender's SMTP server communicates directly with the recipient's SMTP server, and additional links in this chain are a rarity. SMTP itself is, as its name suggests, simple. An SMTP clientsuch as a desktop email program or a relaying SMTP serverinitiates a connection to TCP port 25 on the remote SMTP server, followed by an automated greeting code, some optional authentication commands, and a couple more commands to establish what type of transaction the sender is attempting. Then, the recipient asks for the message, and the sender sends it. Finally, a termination command is sent, and the connection is closed. That's about all SMTP is ever really used for, and there really aren't many other capabilities designed into the protocol. No specialized software is necessary for using SMTP; in fact, you can execute a completely valid SMTP transaction right from the FreeBSD command line. Listing 25.1 is an example of such a transaction. Note that the bold type indicates your input during the session. Listing 25.1. Executing a Valid SMTP Transaction
Note The HELO command, which initiates the SMTP session, is usually replaced by the EHLO (Extended HELO) command, which takes more complex arguments. As you can see, communication between the two servers is done with four-letter command codes, by convention in caps, and with arguments that are incorporated into the message headers. The message that bob@destination.com receives will come up in his email program with the following headers: From: frank@sender.com To: bob@destination.com Subject: Testing, 123... The headers are separated from the body of the message by a single blank line. A single dot on a line by itself marks the end of the message body; when the receiving SMTP program sees this, it delivers the messagein the case of Sendmail, by appending it to the recipient's mailbox file (/var/mail/bob if it's a FreeBSD machine). And that's all there is to it. A full-featured SMTP server such as Sendmail transmits its messages using a few extra commands to enhance performance and efficiency, but functionally it uses exactly the same method as the example you've just seen during the actual connection. Sendmail's complexity lies mostly in areas outside the actual SMTP transaction, usually having to do with ensuring that only authorized users can access the SMTP functions. The reason the client has to communicate first with its own ISP's SMTP server, rather than connecting directly to the recipient's, is to take advantage of queuing. With queuing, an SMTP server can keep each message it receives from a client (on either a local or remote machine) in a "holding area" directory (commonly referred to as a queue), where it waits for a connection to the final recipient's SMTP server. This connection might be immediately available, in which case the message spends almost no time in the queue. If the connection isn't available, however, the message sits in the queue until a connection opens up, at which time the SMTP program sends it. Note Queuing is an application-level behavior of SMTP servers. The benefits of queuing for SMTP are much like those of DNS, which enhances the functionality of Internet applications while not actually being a part of the TCP/IP stack. The benefit of queuing is that it converts email delivery from a "synchronous" to an "asynchronous" process, where both clients need not be involved at all phases of the transaction. Queuing removes from the dial-up client the burden of looking up the destination host's SMTP server, queuing the message, and retrying the connection at regular intervals. When the client dials up, it can make a single connection, upload all its pending email messages into the outgoing SMTP queue, and then disconnect. The server handles all the steps beyond that point, and the client is thus freed of the mail-sending task. |
