Simple Mail Transfer Protocol
obsoletes
- rfc-2821 — Simple Mail Transfer Protocol
updated by
- rfc-7504 — SMTP 521 and 556 Reply Codes
updates
- rfc-1123 — Requirements for Internet Hosts - Application and Support
Extracted elements (33)
DNS MX records make the use of explicit source routes in SMTP largely unnecessary and their use undesirable due to many historical problems with interpretation. SMTP clients SHOULD NOT generate explicit source routes except under unusual circumstances.
SMTP's strength comes primarily from its simplicity. Experience with many protocols has shown that protocols with few options tend toward ubiquity, whereas protocols with many options tend toward obscurity. Each extension must be carefully scrutinized with respect to implementation, deployment, and interoperability costs.
The 251 (forwarding address) and 551 (user not local, forwarding suggested) reply codes are optional and potentially expose private address information. Implementations that support them SHOULD provide configuration mechanisms to disable or restrict their use for privacy-sensitive deployments.
Receiving systems MUST NOT reject mail based on the format of a Received: trace header field, and SHOULD be extremely robust in the face of unexpected information or formats in those fields, as messages may originate from non-SMTP environments.
SMTP clients and servers MUST support the original HELO mechanism as a fallback for compatibility with older conforming implementations that do not support ESMTP extensions. If a server returns 'command not recognized' to EHLO, the client SHOULD fall back to HELO.
A client MUST issue HELO or EHLO before starting a mail transaction. Mail transaction commands (MAIL, RCPT, DATA) MUST be used in their specified order; a RCPT command without a prior MAIL command MUST receive a 503 response.
A relay SMTP MUST NOT inspect or modify the header section or body of the message data except to add its own Received: header field and optionally detect looping.
A relay SMTP that accepts mail and later cannot deliver it MUST construct an undeliverable mail notification and send it to the reverse-path. Notification messages MUST use a null reverse-path (MAIL FROM:<>) to prevent error loops.
A server MUST NOT return a 250 reply to VRFY or EXPN unless it has actually verified the address; returning 250 merely because the syntax is valid is prohibited. Reply code 252 SHOULD be used when apparent validity cannot be confirmed in real time.
An originating SMTP client that has not successfully negotiated an 8-bit extension MUST NOT transmit messages with information in the high-order bit of octets. The unextended SMTP service provides 7-bit transport only.
An SMTP server MUST NOT intentionally close the connection except after receiving QUIT (with 221 reply), after detecting a need to shut down (421 response), or after a timeout. A server that closes connections in response to unknown commands is in violation of this specification.
Contemporary SMTP implementations MUST support the basic extension mechanisms. Servers MUST support the EHLO command even if they do not implement any specific extensions, and clients and servers MUST support the original HELO mechanism as a fallback.
Lines MUST be terminated by the sequence CR (0x0D) followed immediately by LF (0x0A). Implementations MUST NOT recognize or generate any other character or sequence as a line terminator. Clients MUST NOT transmit bare CR or LF characters except as part of a CRLF sequence.
Message data MUST NOT be sent unless a 354 reply is received in response to the DATA command. If a 5yz reply is received instead, the client MUST NOT send the message data.
Minimum buffer sizes that SMTP implementations MUST support: local-part 64 octets, domain 255 octets, forward- or reverse-path 256 octets, command line 512 octets, reply line 512 octets, text line 1000 octets, message content 64K octets, and at least 100 recipients per transaction.
Once the server has issued a success response at the end of mail data, the server MUST accept responsibility for either delivering the message or properly reporting the failure to do so.
Only resolvable, fully-qualified domain names (FQDNs) are permitted in SMTP transactions. Local nicknames or unqualified names MUST NOT be used. The domain name given in the EHLO command MUST be a primary host name or an address literal.
SMTP clients MUST implement the following minimum timeout values: 5 minutes for initial 220 greeting, 5 minutes waiting for MAIL/RCPT reply, 2 minutes for DATA initiation reply, 3 minutes per data block, and 10 minutes for the final DATA termination (post-<CRLF>.<CRLF>) reply.
The local-part of a mailbox MUST BE treated as case sensitive; SMTP implementations MUST preserve the case of mailbox local-parts. Command verbs and domain names are case-insensitive.
To locate the target SMTP server for a domain, senders MUST query DNS for MX records; if no MX records exist, an A or AAAA record lookup MAY be used. MX hosts MUST be tried in preference order (lowest number first), with equal-priority hosts load-balanced randomly.
When a mail delivery attempt fails, the client SHOULD retry using an exponential or similar backoff strategy and SHOULD continue retrying for at least 4–5 days before generating a non-delivery notification. Bounce messages MUST use a null reverse-path.
When a message is delivered to a mailing list, the return address in the envelope (MAIL FROM:) MUST be changed to be the address of the list administrator. The message header section 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 in any way a Received: line already in the header section.
Received: trace header fields may disclose the internal topology of a network, the geographic location of users, or details of mail system software. Sites with confidentiality requirements should consider the information disclosed in these fields when configuring their mail infrastructure.
SMTP reply codes are three-digit numbers where the first digit indicates severity: 2yz = positive completion, 3yz = positive intermediate, 4yz = transient negative completion (retry possible), 5yz = permanent negative completion. Key codes include 220 (greeting), 250 (OK), 354 (start mail input), 421 (service unavailable), 550 (mailbox unavailable).
IANA maintains a registry of SMTP service extensions, each identified by an EHLO keyword value. Every registered extension must be defined in a Standards-Track or IESG-approved Experimental document. EHLO keywords beginning with 'X' are reserved for local bilateral use and MUST NOT be registered.
SMTP itself does not verify the identity of a message originator; envelope information (MAIL FROM) can be falsified. Mechanisms such as SPF and DKIM have been developed to provide ways to ascertain address validity, but SMTP servers are not required to use them.
SMTP servers MUST operate within their authorized scope and SHOULD NOT relay mail for arbitrary third-party senders (open relay). Acting as an open relay enables spam and abuse; policy-based rejection of unauthorized relay attempts SHOULD return a 550 response.
VRFY and EXPN commands can be exploited to harvest valid email addresses and enumerate users. Implementations MAY provide local installations a way to disable either or both commands through configuration options for security reasons.
An SMTP session proceeds through the states: (1) connection opened, server sends 220 greeting; (2) client issues EHLO/HELO, transitioning to initial state with buffers cleared; (3) MAIL command begins a transaction; (4) one or more RCPT commands add recipients; (5) DATA command transfers message body, ending with <CRLF>.<CRLF>; (6) 250 OK confirms delivery responsibility; RSET or QUIT resets or terminates.
The EHLO command takes a single argument of a fully-qualified domain name or address literal: 'EHLO SP (Domain / address-literal) CRLF'. The positive EHLO response is a multiline 250 reply where each line carries an ehlo-keyword and optional parameters.
The end-of-data indicator for the DATA command is a line containing only a single period ('.'). To prevent the user's text from prematurely triggering this, any line beginning with a period must be prefixed with an additional period by the sender (dot-stuffing), which the receiver removes.
The MAIL command has the form 'MAIL FROM:<reverse-path> [SP <mail-parameters>] CRLF'; the RCPT command has the form 'RCPT TO:<forward-path> [SP <rcpt-parameters>] CRLF'. Spaces are not permitted on either side of the colon following FROM or TO.