Introduction to SMTP

Simple Mail Transfer Protocol (internet email)

Over 20 years old, inherently insecure from its early days, SMTP is the backbone, the quintessential engine of the worlds largest electronic communications medium. And it has finally begun to evolve.

The first standard (RFC821) for this protocol was written by Jonathan B. Postel on August 1982 while at the Information Sciences Institute of the University of Southern California.

SMTP is the acronym for Simple Mail Transfer Protocol, a standard procedure for regulating data transmission between computers sending electronic (e-) mail messages between dedicated mail servers (powerful computers devoted to handling mail).

Most e-mail systems that send mail over the Internet use SMTP to send messages from one server to another; the messages can then be retrieved with an e-mail client (like your Outlook Express, Netscape, Eudora, or Pegasus mail readers) using either POP (Post Office Protocol) or IMAP (Internet Message Access Protocol).

In addition, SMTP is generally used to send messages from a mail client to a mail server. This is why you need to specify both the POP or IMAP server and the SMTP server when you configure your e-mail application.

Any email message that you send is passed along from your computer across any number of intermediate email servers (which in each case could conceivable be as many as 30 computer hops [hopping from gateway to router to gateway etc] apart from each other) to the server on which the recipient of your message receives his or her email. All of these email servers talk to each other via a language called SMTP. Think of it as being your outgoing e-mail server, the server through which you send email messages.

The primary objective of the Simple Mail Transfer Protocol (SMTP) is to transfer mail reliably and efficiently.

SMTP is independent of the particular transmission subsystem and requires only a reliable ordered data stream channel. While this document specifically discusses transport over Transmission Control Protocol (TCP), other transports are possible.

An important feature of SMTP is its capability to transport mail across networks, usually referred to as "SMTP mail relaying". A network consists of the mutually-TCP-accessible hosts on the public Internet, the mutually-TCP-accessible hosts on a firewall-isolated TCP/IP Intranet, or hosts in some other LAN or WAN environment utilizing a non-TCP transport-level protocol. Using SMTP, a process can transfer mail to another process on the same network or to some other network via a relay or gateway process accessible to both networks.

In this way, a mail message may pass through a number of intermediate relay or gateway hosts on its path from sender to ultimate recipient. The Mail eXchanger mechanisms of the domain name system (and section 5 of this document) are used to identify the appropriate next-hop destination for a message being transported.

When an SMTP client has a message to transmit, it establishes a two- way transmission channel to an SMTP server. The responsibility of an SMTP client is to transfer mail messages to one or more SMTP servers, or report its failure to do so. The means by which a mail message is presented to an SMTP client, and how that client determines the domain name(s) to which mail messages are to be transferred is a local matter, and is not addressed by this document. In some cases, the domain name(s) transferred to, or determined by, an SMTP client will identify the final destination(s) of the mail message.

In other cases, common with SMTP clients associated with implementations of the POP3 or IMAP protocols, or when the SMTP client is inside an isolated transport service environment, the domain name determined will identify an intermediate destination through which all mail messages are to be relayed. SMTP clients that transfer all traffic, regardless of the target domain names associated with the individual messages, or that do not maintain queues for retrying message transmissions that initially cannot be completed, may otherwise conform to this specification but are not considered fully-capable. Fully-capable SMTP implementations, including the relays used by these less capable ones, and their destinations, are expected to support all of the queuing, retrying, and alternate address functions discussed in this specification.