Simple Mail Transfer Protocol
obsoleted by
- rfc-5321 — Simple Mail Transfer Protocol
obsoletes
- rfc-1869 — SMTP Service Extensions
- rfc-821 — Simple Mail Transfer Protocol
- rfc-974 — Mail routing and the domain system
updated by
- rfc-5336 — SMTP Extension for Internationalized Email Addresses
Extracted elements (32)
EHLO was introduced as a superset of HELO to enable the service extension model without breaking existing implementations. HELO is retained as a required fallback to ensure interoperability with older systems. The extension model was deliberately designed so that each extension must be separately negotiated, preserving SMTP's simplicity and ubiquity.
Explicit source routing in SMTP (specifying a list of relay hosts in the RCPT TO path) has been deprecated because MX records in DNS make it unnecessary and its historical use caused many problems with interpretation and reliability. Servers SHOULD ignore or strip source route information.
Accepting lines ending only in bare <LF> (without <CR>) has historically caused more interoperability problems than it solves. SMTP server systems MUST NOT accept bare <LF> as a line terminator, even as a robustness concession to non-conforming UNIX systems.
Some SMTP servers, in violation of the specification, require command verbs to be in upper case. Client implementations MAY use upper-case encoding to accommodate those servers. EHLO keywords MUST always be recognized in a case-insensitive manner regardless of how they are transmitted.
A client MUST issue HELO or EHLO before starting a mail transaction. Servers MUST support HELO; clients SHOULD preferentially use EHLO. If the server returns 'command not recognized' to EHLO, the client SHOULD fall back to HELO.
A server MUST NOT return 250 in response to VRFY or EXPN unless it has actually verified the address; returning 250 for syntax-valid-only addresses is prohibited. VRFY and EXPN MUST return only valid domain addresses usable in SMTP RCPT commands, and MUST NOT return source routes.
An originating SMTP client that has not successfully negotiated an appropriate extension (such as 8BITMIME) with the server MUST NOT transmit messages with information in the high-order bit of octets. Envelope commands MUST be in US-ASCII only.
An SMTP server MUST NOT intentionally close the connection except after receiving QUIT (responding with 221) or after detecting a need to shut down and returning 421. A server that closes connections in response to unrecognized commands is in violation; servers MUST issue a 500 reply and await further instructions.
If a relay SMTP accepts a message and later cannot deliver it, it MUST construct an 'undeliverable mail' notification and send it to the originator indicated by the reverse-path. SMTP servers MUST NOT send notification messages about problems transporting notification messages.
Mail transaction commands MUST be used in order: MAIL, then one or more RCPT, then DATA. If a RCPT command appears without a prior MAIL command the server MUST return 503 'Bad sequence of commands'. Message data MUST NOT be sent unless a 354 reply is received.
Notification (bounce) messages MUST use a null reverse-path: 'MAIL FROM:<>'. This prevents mail loops in error reporting.
Only resolvable fully-qualified domain names (FQDNs) are permitted when domain names are used in SMTP. Local nicknames or unqualified names MUST NOT be used. The domain name in EHLO MUST be either a primary host name (resolving to an A RR) or an address literal.
SMTP commands and message data are transmitted in lines terminated by <CRLF> (CR hex 0D followed immediately by LF hex 0A). Implementations MUST NOT recognize or generate any other character sequence as a line terminator. Clients MUST NOT transmit bare CR or LF except as part of <CRLF>.
The local-part of a mailbox MUST be treated as case sensitive. SMTP implementations MUST preserve the case of mailbox local-parts. Mailbox domains are not case sensitive.
The reserved mailbox 'postmaster' MUST be accepted in a RCPT command without domain qualification. Every SMTP server MUST maintain a 'postmaster' address.
To prevent the end-of-data marker from appearing in message text, transparency is required: any line beginning with a period must have an additional period prepended by the sender, and the receiver strips the leading period. The end-of-data sequence <CRLF>.<CRLF> MUST NOT be treated as equivalent to <LF>.<LF>.
When a list expander sends a message, the reverse-path (MAIL FROM:) MUST be changed to the address of the list administrator. The message header's 'From' field MUST be left unchanged.
When forwarding a message into or out of the Internet environment, a gateway MUST prepend a Received: line but MUST NOT alter any existing Received: line. Receiving systems MUST NOT reject mail based on the format of a trace field.
DATA command initiates transfer of message content. The server responds with 354, then accepts lines until the end-of-data indicator '<CRLF>.<CRLF>'. On successful receipt the server must return 250 OK, taking full responsibility for delivery; partial delivery failures are not allowed at this point.
EHLO command identifies the SMTP client to the server and requests a list of supported service extensions. The server responds with a multiline 250 reply listing extension keywords and optional parameters. HELO is the legacy fallback that MUST be supported but does not return extension information.
MAIL FROM command initiates a mail transaction, specifying the reverse-path (sender mailbox or null '<>'). It clears all state buffers (reverse-path, forward-path, mail data) and may carry optional service extension parameters.
RCPT TO command identifies one recipient; may be repeated for multiple recipients. The server returns 250 OK if accepted, 550 if the address is not deliverable. The forward-path is enclosed in angle brackets and may include extension parameters.
Received: trace header is inserted by each SMTP server that accepts a message, recording the sending host identity, receiving host identity, and date/time received. Relay messages accumulate multiple Received: lines. Details of the required syntax are specified in section 4.4.
RSET command aborts the current mail transaction; stored sender, recipients, and mail data MUST be discarded and all buffers cleared. The server MUST reply 250 OK. SMTP servers MUST NOT close the connection upon receiving RSET.
IANA maintains a registry of SMTP service extensions. Each registered extension requires a formal standards-track or IESG-approved experimental document specifying: the extension name, EHLO keyword, parameter syntax, any new SMTP verbs, MAIL/RCPT parameter additions, and behavioral description. Keywords beginning with 'X' are local-use only and MUST NOT be registered.
Received: trace headers disclose the identities of intermediate hosts and, potentially, the internal network topology of an organization. The 251 and 551 reply codes can disclose forwarding addresses. Servers SHOULD provide configuration to suppress or restrict this information.
SMTP's lack of sender authentication makes mail spoofing trivial. The protocol itself cannot verify that the claimed sender (MAIL FROM address) is authentic. Implementers and operators must understand that the reverse-path provides no security guarantee about message origin.
VRFY and EXPN commands can disclose information about valid users and mailing list memberships, aiding spammers and attackers. Implementations SHOULD provide configuration options to disable or restrict VRFY and EXPN, and servers MAY return 252 rather than confirming addresses.
SMTP session states: (1) Initial — after EHLO/HELO accepted, all buffers clear; (2) MAIL received — reverse-path buffer set; (3) RCPT received — one or more recipients in forward-path buffer; (4) DATA transfer — 354 issued, accumulating mail data; (5) Transaction complete — 250 returned after end-of-data, buffers cleared. RSET returns to Initial from any state; QUIT terminates session.
EHLO positive response is a multiline 250 reply: first line '250-' followed by the server domain and optional greeting; subsequent extension lines use '250-'; final line uses '250 '. Each extension line is an ehlo-keyword optionally followed by space-separated parameters.
End-of-data indicator for the DATA command is a line containing only a period: the byte sequence <CRLF>.<CRLF>. Transparency is achieved by prepending a period to any message line beginning with a period; the receiver strips the extra period. '<LF>.<LF>' MUST NOT be treated as equivalent.
SMTP reply format: a three-digit numeric code followed by a space (or hyphen for multiline continuations) and a text string, terminated by <CRLF>. The first digit indicates success (2), intermediate (3), transient failure (4), or permanent failure (5). Reply code 354 signals start of data; 250 signals general success.