Simple Mail Transfer Protocol

Simple Mail Transfer Protocol. It is the standard communication protocol used for sending and relaying electronic mail across Internet Protocol networks. Defined originally in RFC 821 by Jonathan B. Postel and later updated by RFC 5321, it operates primarily over Transmission Control Protocol and functions at the application layer of the Internet protocol suite. While clients typically use protocols like Post Office Protocol or Internet Message Access Protocol for retrieval, it is the fundamental mechanism for mail submission and transfer between mail servers.

Overview

The protocol was first defined in August 1982 as part of the early ARPANET standards, evolving from earlier systems like Mail Box Protocol. Its design follows a simple client–server model, where a sending mail transfer agent initiates a connection to a receiving agent. The protocol uses a series of plain text commands and numeric reply codes to facilitate the transfer of messages, which are composed of an envelope and content as defined in companion standards like RFC 5322. Its widespread adoption was cemented by its inclusion in the Berkeley Software Distribution implementation of sendmail, which became a cornerstone of early Internet email infrastructure. The core specification has been updated over time by the Internet Engineering Task Force, with important extensions for security and authentication developed later.

Operation

A typical session begins when a client, such as Mozilla Thunderbird or Microsoft Outlook, connects to an outgoing mail server run by an Internet service provider like Comcast or Google. The client issues commands like `EHLO` to initiate the session, followed by `MAIL FROM` and `RCPT TO` to establish the envelope. The actual message data is then transmitted after a `DATA` command, concluding with a final period. For relaying, a server like Exim or Postfix will perform a Domain Name System lookup for MX records of the recipient's domain to find the destination server. This process often involves multiple hops across servers operated by entities such as Amazon Web Services or Microsoft Exchange Server, with each hop adding header fields like `Received`. The protocol traditionally uses Transmission Control Protocol port 25 for server-to-server communication, while port 587 is designated for mail submission agent communication.

Protocol details

The command set is intentionally minimal, with key commands including `HELO`, `EHLO`, `MAIL FROM`, `RCPT TO`, `DATA`, `RSET`, `VRFY`, `EXPN`, and `QUIT`. Replies are three-digit codes, with the first digit indicating success, temporary failure, or permanent failure. The envelope information, separate from the message headers, is defined during the `MAIL FROM` and `RCPT TO` dialogue. The message body transmission is terminated by a line containing only a period. Extensions to the base protocol are announced by a server in response to an `EHLO` command, as formalized in RFC 1869. These extensions can modify or enhance behavior, such as requesting delivery status notifications. The protocol interacts closely with other standards, including the Multipurpose Internet Mail Extensions format for non-text attachments and the DomainKeys Identified Mail system for domain-level authentication.

Security and extensions

The original specification had no inherent security, making it vulnerable to spoofing and spam. Major extensions were developed to address this, including SMTP-AUTH (defined in RFC 4954) for user authentication and STARTTLS (from RFC 3207) for opportunistic encryption of the channel using Transport Layer Security. The use of port 465 for implicit Transport Layer Security was once common but was later deprecated in favor of using STARTTLS on port 587. Other significant extensions include SMTP Service Extension for Message Size Declaration (RFC 1870) and Enhanced Status Codes (RFC 3463). Despite these improvements, the protocol's store-and-forward nature and need for backward compatibility mean that enforcement of policies like Sender Policy Framework or Domain-based Message Authentication, Reporting and Conformance is handled by receiving servers like qmail or Microsoft Exchange rather than by the protocol itself.

Related protocols

For retrieving mail from a server, users rely on different protocols, principally the Post Office Protocol and the more advanced Internet Message Access Protocol. The format of the email message itself is defined separately by standards like RFC 5322 for headers and RFC 2045 through RFC 2049 for Multipurpose Internet Mail Extensions. Submission of mail from a client is often governed by the specifics of RFC 6409, which designates port 587. Other complementary technologies and standards include the Lightweight Directory Access Protocol for address lookups, Secure Sockets Layer as a precursor to Transport Layer Security, and anti-abuse frameworks like the Sender Policy Framework and DomainKeys Identified Mail which are used in conjunction with Domain Name System records.

Category:Internet mail protocols Category:Application layer protocols Category:Internet standards