ietf-corpus

rfc-821

Simple Mail Transfer Protocol

J. Postel
date1982-08 streamLegacy statusINTERNET STANDARD pages72 canonicalhttps://www.rfc-editor.org/rfc/rfc821 doi10.17487/RFC0821
The objective of 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. Obsoletes RFC 788, 780, and 772.

obsoleted by

obsoletes

also

Extracted elements (29)

design-rationale §1

SMTP is designed to be independent of the underlying transport system, requiring only a reliable ordered data stream channel. This allows SMTP to run over TCP, NCP, NITS, X.25, or any other suitable transport.

email

design-rationale §2

The SMTP dialog is intentionally lock-step: the sender issues one command and must wait for the receiver's reply before sending the next command. This guarantees that the sender always knows the receiver's state.

email

design-rationale §2

When the same message is sent to multiple recipients at the same destination host, SMTP encourages transmitting only one copy of the data for all recipients, reducing unnecessary data transfer.

email

interoperability-note §Appendix A

SMTP is assigned TCP port 25 (octal 31) for the receiver process. The transmission channel is a single full-duplex TCP connection. SMTP data is 7-bit ASCII transmitted right-justified in 8-bit bytes with the high-order bit cleared to zero.

email, tcp

interoperability-note §3.6

Source routing in forward-paths uses the form @ONE,@TWO:user@THREE, where hosts are listed in traversal order. The forward-path and reverse-path are SMTP envelope constructs and need not appear in the message header fields (To:, From:, CC:).

email

interoperability-note §4.1.1

When mail data is partially deliverable (some recipients succeed, some fail), the DATA command reply must be 250 OK, but the receiver-SMTP must compose and send separate undeliverable-mail notifications for each failed recipient to the originator.

email

normative-requirement §4.1.1 MUST

A mail transaction must consist of one of the transaction-beginning commands (MAIL, SEND, SOML, or SAML), followed by one or more RCPT commands, followed by DATA, in that order. If commands are out of order a 503 failure reply must be returned.

email

normative-requirement §4.5.2 MUST

Data transparency requires that the sender-SMTP prepend an extra period to any line of mail data that begins with a period. The receiver-SMTP strips the leading period from such lines; a line consisting solely of a period signals end of mail data.

email

normative-requirement §3.7 MUST

Domain names used in SMTP must be official names only; the use of nicknames or aliases is not allowed.

email

normative-requirement §4.5.3 MUST

Every implementation must be able to receive objects up to the following minimum maximum sizes: user name 64 chars, domain name 64 chars, path 256 chars, command line 512 chars, reply line 512 chars, text line 1000 chars, recipients buffer 100 recipients. Implementations must not send objects larger than these limits.

email

normative-requirement §3.6 MUST

If a server-SMTP has accepted the task of relaying mail and later finds delivery impossible, it must construct an 'undeliverable mail' notification message and send it to the originator indicated by the reverse-path.

email

normative-requirement §4.5.1 REQUIRED

Minimum SMTP implementation requires support for exactly these commands: HELO, MAIL, RCPT, DATA, RSET, NOOP, and QUIT. All receivers must implement at least these commands.

email

normative-requirement §2 MUST

SMTP implementations must preserve the case of mailbox user names exactly as they appear in mailbox arguments. Commands and host names are case-insensitive, but mailbox user names are case-sensitive on some hosts.

email

normative-requirement §4.1.1 MUST

The first command in an SMTP session must be the HELO command. If the HELO argument is not acceptable a 501 failure reply must be returned and the receiver-SMTP must stay in the same state.

email

normative-requirement §4.1.1 MUST

The last command in a session must be QUIT. The receiver should not close the transmission channel until it receives and replies to a QUIT command, even if there was an error. If the connection is closed prematurely, the receiver must act as if RSET was received.

email

normative-requirement §3.6 MUST

Undeliverable mail notification messages must use a null reverse-path in the MAIL command (MAIL FROM:<>) to prevent error-notification loops. Server-SMTPs must not send notification messages about problems with notification messages.

email

normative-requirement §4.1.1 MUST

When a receiver-SMTP accepts a message for relaying or final delivery it must insert a time-stamp line (Received:) at the beginning of the mail data. On final delivery it must also insert a Return-Path: line preserving the reverse-path from the MAIL command.

email

normative-requirement §3.6 MUST

When relaying mail, the relay host must remove itself from the beginning of the forward-path and insert itself at the beginning of the reverse-path, using its name as known in the environment it is sending into.

email

protocol-element §4.2

SMTP reply codes are three-digit numbers where the first digit indicates outcome class: 2xx = success, 3xx = intermediate/positive, 4xx = transient failure, 5xx = permanent failure. Every command must generate exactly one reply. Key codes include 250 (OK), 354 (start mail input), 421 (service unavailable), 550 (mailbox unavailable).

email

protocol-element §3.1

The SMTP mail transaction has three steps: (1) MAIL FROM:<reverse-path> identifying the sender, which resets all state buffers; (2) one or more RCPT TO:<forward-path> commands identifying recipients; (3) DATA command followed by message content terminated by <CRLF>.<CRLF>.

email

protocol-element §3.8

The TURN command allows the sender-SMTP and receiver-SMTP to reverse roles over the existing transmission channel. The receiver may refuse with reply 502. TURN is optional and most useful when channel establishment is costly.

email

protocol-element §3.4

Three optional sending commands supplement MAIL: SEND (deliver to terminal only), SOML (Send Or Mail — deliver to terminal if active, else mailbox), and SAML (Send And Mail — deliver to both terminal and mailbox). These are not required in the minimum implementation.

email

protocol-element §3.3

VRFY asks the receiver to confirm a user name and return the full name and fully-specified mailbox. EXPN asks the receiver to expand a mailing list and return all member mailboxes in a multiline reply. Both are optional and not required to work across relays.

email

security-consideration §3.3

RFC 821 defines no authentication mechanism; the reverse-path (sender identity) in the MAIL FROM command is self-reported and unverified, allowing any sender to claim any origin address. Additionally, the EXPN command can expose full mailing list membership and may need to be access-controlled (e.g., '550 Access Denied').

email, security

state-machine §4.4

Most SMTP commands share a common state model: Begin → send command → Wait (W) → on 2xx go to Success; on 4xx/5xx go to Failure; on 1xx/3xx go to Error. The DATA command has a two-phase model: after 354 intermediate reply, mail data lines are sent with no per-line replies until the end-of-data marker, which then yields a final 250 or failure.

email

wire-format §4.1.2

Mailbox addresses have the form <local-part>@<domain> where local-part is a dot-string or quoted-string. Forward-paths and reverse-paths are enclosed in angle brackets and may include an optional source-route prefix of the form @host1,@host2: before the mailbox.

email

wire-format §4.1.2

SMTP commands consist of a four-character alphabetic command code (case-insensitive), optionally followed by one or more spaces and an argument field, terminated by <CRLF> (CR=ASCII 13, LF=ASCII 10). The argument field is variable length.

email

wire-format §4.5.2

The end-of-mail-data indicator is the sequence <CRLF>.<CRLF> — a line containing only a period. SMTP replies consist of a three-digit code, a space, one line of text, and <CRLF>; multiline replies use a hyphen after the code on all but the last line.

email

wire-format §4.1.2

The Received: time-stamp line format is: 'Received: FROM <domain> BY <domain> [VIA <link>] [WITH <protocol>] [ID <string>] [FOR <path>] ; <dd mon yy hh:mm:ss zone>'. The Return-Path: line format is: 'Return-Path: <SP><reverse-path><CRLF>'.

email