RFC 5321
Simple Mail Transfer Protocol
Simple Mail Transfer Protocol (RFC 5321) 💌
Okay bestie, this is RFC 5321, aka the Simple Mail Transfer Protocol, the spec that literally moves your emails around 📬✨ It's by J. Klensin, dated October 2008, and it's a Standards Track doc from the Network Working Group 🎀 It obsoletes RFC 2821 (so 2821 is retired, no cap) and updates RFC 1123 💅
Status of This Memo
This is an Internet standards track protocol for the Internet community, and the authors are literally asking for discussion and suggestions for improvements 🦋 If you want the standardization state and status, check the current edition of "Internet Official Protocol Standards" (STD 1) 🔥 Distribution of this memo is unlimited, so share away 💜
Abstract
This doc is the basic protocol spec for Internet electronic mail transport 💖 It consolidates, updates, and clarifies several older documents, which means all or parts of most of them are now obsolete 🫶 It covers the SMTP extension mechanisms and best practices for the modern Internet, but it does not go into the details of particular extensions 🌸
Here's the iconic part: SMTP was designed as a mail transport and delivery protocol, but this spec also has info that matters if you're using it as a "mail submission" protocol for "split-UA" (User Agent) mail reading systems and mobile environments 📱✨ Main character energy 👑
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Transport of Electronic Mail . . . . . . . . . . . . . . . 5
1.2. History and Context for This Document . . . . . . . . . . 5
1.3. Document Conventions . . . . . . . . . . . . . . . . . . . 6
2. The SMTP Model . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Basic Structure . . . . . . . . . . . . . . . . . . . . . 7
2.2. The Extension Model . . . . . . . . . . . . . . . . . . . 9
2.2.1. Background . . . . . . . . . . . . . . . . . . . . . . 9
2.2.2. Definition and Registration of Extensions . . . . . . 10
2.2.3. Special Issues with Extensions . . . . . . . . . . . . 11
2.3. SMTP Terminology . . . . . . . . . . . . . . . . . . . . . 11
2.3.1. Mail Objects . . . . . . . . . . . . . . . . . . . . . 11
2.3.2. Senders and Receivers . . . . . . . . . . . . . . . . 12
2.3.3. Mail Agents and Message Stores . . . . . . . . . . . . 12
2.3.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.5. Domain Names . . . . . . . . . . . . . . . . . . . . . 13
2.3.6. Buffer and State Table . . . . . . . . . . . . . . . . 14
2.3.7. Commands and Replies . . . . . . . . . . . . . . . . . 14
2.3.8. Lines . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.9. Message Content and Mail Data . . . . . . . . . . . . 15
2.3.10. Originator, Delivery, Relay, and Gateway Systems . . . 15
2.3.11. Mailbox and Address . . . . . . . . . . . . . . . . . 15
2.4. General Syntax Principles and Transaction Model . . . . . 16
3. The SMTP Procedures: An Overview . . . . . . . . . . . . . . . 17
3.1. Session Initiation . . . . . . . . . . . . . . . . . . . . 18
3.2. Client Initiation . . . . . . . . . . . . . . . . . . . . 18
3.3. Mail Transactions . . . . . . . . . . . . . . . . . . . . 19
3.4. Forwarding for Address Correction or Updating . . . . . . 21
3.5. Commands for Debugging Addresses . . . . . . . . . . . . . 22
3.5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 22
3.5.2. VRFY Normal Response . . . . . . . . . . . . . . . . . 24
3.5.3. Meaning of VRFY or EXPN Success Response . . . . . . . 25
3.5.4. Semantics and Applications of EXPN . . . . . . . . . . 26
3.6. Relaying and Mail Routing . . . . . . . . . . . . . . . . 26
3.6.1. Source Routes and Relaying . . . . . . . . . . . . . . 26
3.6.2. Mail eXchange Records and Relaying . . . . . . . . . . 26
3.6.3. Message Submission Servers as Relays . . . . . . . . . 27
3.7. Mail Gatewaying . . . . . . . . . . . . . . . . . . . . . 28
3.7.1. Header Fields in Gatewaying . . . . . . . . . . . . . 28
3.7.2. Received Lines in Gatewaying . . . . . . . . . . . . . 29
3.7.3. Addresses in Gatewaying . . . . . . . . . . . . . . . 29
3.7.4. Other Header Fields in Gatewaying . . . . . . . . . . 29
3.7.5. Envelopes in Gatewaying . . . . . . . . . . . . . . . 30
3.8. Terminating Sessions and Connections . . . . . . . . . . . 30
3.9. Mailing Lists and Aliases . . . . . . . . . . . . . . . . 31
3.9.1. Alias . . . . . . . . . . . . . . . . . . . . . . . . 31
3.9.2. List . . . . . . . . . . . . . . . . . . . . . . . . . 31
4. The SMTP Specifications . . . . . . . . . . . . . . . . . . . 32
4.1. SMTP Commands . . . . . . . . . . . . . . . . . . . . . . 32
4.1.1. Command Semantics and Syntax . . . . . . . . . . . . . 32
4.1.2. Command Argument Syntax . . . . . . . . . . . . . . . 41
4.1.3. Address Literals . . . . . . . . . . . . . . . . . . . 43
4.1.4. Order of Commands . . . . . . . . . . . . . . . . . . 44
4.1.5. Private-Use Commands . . . . . . . . . . . . . . . . . 46
4.2. SMTP Replies . . . . . . . . . . . . . . . . . . . . . . . 46
4.2.1. Reply Code Severities and Theory . . . . . . . . . . . 48
4.2.2. Reply Codes by Function Groups . . . . . . . . . . . . 50
4.2.3. Reply Codes in Numeric Order . . . . . . . . . . . . . 52
4.2.4. Reply Code 502 . . . . . . . . . . . . . . . . . . . . 53
4.2.5. Reply Codes after DATA and the Subsequent
<CRLF>.<CRLF> . . . . . . . . . . . . . . . . . . . . 53
4.3. Sequencing of Commands and Replies . . . . . . . . . . . . 54
4.3.1. Sequencing Overview . . . . . . . . . . . . . . . . . 54
4.3.2. Command-Reply Sequences . . . . . . . . . . . . . . . 55
4.4. Trace Information . . . . . . . . . . . . . . . . . . . . 57
4.5. Additional Implementation Issues . . . . . . . . . . . . . 61
4.5.1. Minimum Implementation . . . . . . . . . . . . . . . . 61
4.5.2. Transparency . . . . . . . . . . . . . . . . . . . . . 62
4.5.3. Sizes and Timeouts . . . . . . . . . . . . . . . . . . 62
4.5.3.1. Size Limits and Minimums . . . . . . . . . . . . . 62
4.5.3.1.1. Local-part . . . . . . . . . . . . . . . . . . 63
4.5.3.1.2. Domain . . . . . . . . . . . . . . . . . . . . 63
4.5.3.1.3. Path . . . . . . . . . . . . . . . . . . . . . 63
4.5.3.1.4. Command Line . . . . . . . . . . . . . . . . . 63
4.5.3.1.5. Reply Line . . . . . . . . . . . . . . . . . . 63
4.5.3.1.6. Text Line . . . . . . . . . . . . . . . . . . 63
4.5.3.1.7. Message Content . . . . . . . . . . . . . . . 63
4.5.3.1.8. Recipients Buffer . . . . . . . . . . . . . . 64
4.5.3.1.9. Treatment When Limits Exceeded . . . . . . . . 64
4.5.3.1.10. Too Many Recipients Code . . . . . . . . . . . 64
4.5.3.2. Timeouts . . . . . . . . . . . . . . . . . . . . . 65
4.5.3.2.1. Initial 220 Message: 5 Minutes . . . . . . . . 65
4.5.3.2.2. MAIL Command: 5 Minutes . . . . . . . . . . . 65
4.5.3.2.3. RCPT Command: 5 Minutes . . . . . . . . . . . 65
4.5.3.2.4. DATA Initiation: 2 Minutes . . . . . . . . . . 66
4.5.3.2.5. Data Block: 3 Minutes . . . . . . . . . . . . 66
4.5.3.2.6. DATA Termination: 10 Minutes. . . . . . . . . 66
4.5.3.2.7. Server Timeout: 5 Minutes. . . . . . . . . . . 66
4.5.4. Retry Strategies . . . . . . . . . . . . . . . . . . . 66
4.5.5. Messages with a Null Reverse-Path . . . . . . . . . . 68
5. Address Resolution and Mail Handling . . . . . . . . . . . . . 69
5.1. Locating the Target Host . . . . . . . . . . . . . . . . . 69
5.2. IPv6 and MX Records . . . . . . . . . . . . . . . . . . . 71
6. Problem Detection and Handling . . . . . . . . . . . . . . . . 71
6.1. Reliable Delivery and Replies by Email . . . . . . . . . . 71
6.2. Unwanted, Unsolicited, and "Attack" Messages . . . . . . . 72
6.3. Loop Detection . . . . . . . . . . . . . . . . . . . . . . 73
6.4. Compensating for Irregularities . . . . . . . . . . . . . 73
7. Security Considerations . . . . . . . . . . . . . . . . . . . 75
7.1. Mail Security and Spoofing . . . . . . . . . . . . . . . . 75
7.2. "Blind" Copies . . . . . . . . . . . . . . . . . . . . . . 76
7.3. VRFY, EXPN, and Security . . . . . . . . . . . . . . . . . 76
7.4. Mail Rerouting Based on the 251 and 551 Response Codes . . 77
7.5. Information Disclosure in Announcements . . . . . . . . . 77
7.6. Information Disclosure in Trace Fields . . . . . . . . . . 78
7.7. Information Disclosure in Message Forwarding . . . . . . . 78
7.8. Resistance to Attacks . . . . . . . . . . . . . . . . . . 78
7.9. Scope of Operation of SMTP Servers . . . . . . . . . . . . 78
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 79
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 80
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 81
10.1. Normative References . . . . . . . . . . . . . . . . . . . 81
10.2. Informative References . . . . . . . . . . . . . . . . . . 82
Appendix A. TCP Transport Service . . . . . . . . . . . . . . . . 85
Appendix B. Generating SMTP Commands from RFC 822 Header
Fields . . . . . . . . . . . . . . . . . . . . . . . 85
Appendix C. Source Routes . . . . . . . . . . . . . . . . . . . . 86
Appendix D. Scenarios . . . . . . . . . . . . . . . . . . . . . . 87
D.1. A Typical SMTP Transaction Scenario . . . . . . . . . . . 88
D.2. Aborted SMTP Transaction Scenario . . . . . . . . . . . . 89
D.3. Relayed Mail Scenario . . . . . . . . . . . . . . . . . . 90
D.4. Verifying and Sending Scenario . . . . . . . . . . . . . . 92
Appendix E. Other Gateway Issues . . . . . . . . . . . . . . . . 92
Appendix F. Deprecated Features of RFC 821 . . . . . . . . . . . 93
F.1. TURN . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
F.2. Source Routing . . . . . . . . . . . . . . . . . . . . . . 93
F.3. HELO . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
F.4. #-literals . . . . . . . . . . . . . . . . . . . . . . . . 94
F.5. Dates and Years . . . . . . . . . . . . . . . . . . . . . 94
F.6. Sending versus Mailing . . . . . . . . . . . . . . . . . . 941. Introduction ✨
Part 1 wraps here, the Introduction keeps going in part 2 💖
1.1. Transport of Electronic Mail ✨
okay so the whole goal of SMTP (Simple Mail Transfer Protocol) is to move mail reliably and efficiently 💌
SMTP doesn't care what transmission system is underneath it. all it needs is a reliable, ordered data stream channel 🦋 This document talks about transport over TCP, but other transports are possible too. Appendices to RFC 821 [1] describe some of them.
the big feature here is that SMTP can carry mail across multiple networks, which people usually call "SMTP mail relaying" (see Section 3.6) 🌸 A network can be 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 that uses a non-TCP transport-level protocol. so a process can send mail to another process on the same network, or to a different network through a relay or gateway process that both networks can reach. it's giving teamwork 🫶
so a message can hop through a bunch of intermediate relay or gateway hosts on its way from sender to final recipient 🧚 The Mail eXchanger mechanisms of the domain name system (RFC 1035 [2], RFC 974 [12], and Section 5 of this document) are what figure out the right next-hop destination for each message as it moves along 🗺️
1.2. History and Context for This Document ✨
this document is the basic protocol spec for Internet email transport 💅 It consolidates, updates and clarifies the following, but it does not add new functionality or change what already exists:
- the original SMTP (Simple Mail Transfer Protocol) specification of RFC 821 [1],
- domain name system requirements and implications for mail transport from RFC 1035 [2] and RFC 974 [12],
- the clarifications and applicability statements in RFC 1123 [3], and
- material drawn from the SMTP Extension mechanisms in RFC 1869 [13].
- Editorial and clarification changes to RFC 2821 [14] to bring that specification to Draft Standard.
it obsoletes RFC 821, RFC 974, RFC 1869, and RFC 2821, and updates RFC 1123 (replacing the mail transport materials of RFC 1123) 🎀 BUT RFC 821 has some features that weren't really used on the Internet by the mid-1990s, plus some extra transport models in its appendices. those parts got left out here for clarity and brevity 🙈 if you need them, go check RFC 821.
it also picks up some extra material from RFC 1123 that needed more explaining 🔍 That stuff was found in a bunch of ways, mostly by tracking flame wars on various lists and newsgroups, plus weird readings and interpretations that popped up as the SMTP extensions got deployed 💀 Wherever this spec goes beyond just consolidating and actually differs from older docs, it replaces them, both technically and in the text 👑
SMTP was designed as a mail transport and delivery protocol, but this spec also has info that matters if you're using it as a "mail submission" protocol 📨 That's how it's recommended for Post Office Protocol (POP) (RFC 937 [15], RFC 1939 [16]) and IMAP (RFC 3501 [17]). honestly though, the separate mail submission protocol in RFC 4409 [18] is the one people prefer now over using SMTP directly. RFC 4409 goes deeper on that 🌈
Section 2.3 has definitions for the terms specific to this document 📖 Unless the old terminology is needed for clarity, this doc uses the current 'client' and 'server' terms to mean the sending and receiving SMTP processes, respectively 💖
A companion document, RFC 5322 [4], covers message header sections and bodies and specifies their formats and structures 📬
1.3. Document Conventions ✨
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document get read the way RFC 2119 [5] describes 🔥 These words were picked super carefully to make email more interoperable, so every single use of them counts as a conformance requirement. no vibes-based interpreting allowed 🙅♀️
the doc has a long history, and to avoid messing things up and confusing readers and other docs that point here, most examples and the domain names in them are kept from RFC 2821 🧸 Heads up though: these examples are just illustrations, so don't copy them into real code or config files 🚫
2. The SMTP Model 🌸
2.1. Basic Structure ✨
here's how the SMTP design looks:
+----------+ +----------+
+------+ | | | |
| User |<-->| | SMTP | |
+------+ | Client- |Commands/Replies| Server- |
+------+ | SMTP |<-------------->| SMTP | +------+
| File |<-->| | and Mail | |<-->| File |
|System| | | | | |System|
+------+ +----------+ +----------+ +------+
SMTP client SMTP serverwhen an SMTP client has a message to send, it sets up a two-way transmission channel to an SMTP server 💌 The client's job is to pass mail messages to one or more SMTP servers, or to report that it couldn't 😤
how a mail message gets handed to an SMTP client, and how that client figures out the identifier(s) ("names") of the domain(s) the mail should go to, is a local matter 🏠 This document doesn't cover it. sometimes the domain(s) you get will be the final destination(s) of the mail ✅ other times, like with SMTP clients tied to POP (RFC 937 [15], RFC 1939 [16]) or IMAP (RFC 3501 [17]) implementations, or when the client is stuck in an isolated transport service environment, the domain just points to an intermediate destination where every message has to get relayed 🔁 SMTP clients that send all traffic no matter what the target domains are, or that don't keep queues to retry messages that initially fail, can still follow this spec, but they're not considered fully-capable 🥺 Fully-capable SMTP implementations, including the relays that the less capable ones depend on, and their destinations, are expected to support all the queuing, retrying, and alternate address functions discussed in this spec 💪 In lots of situations and configurations, those less-capable clients SHOULD be using the message submission protocol (RFC 4409 [18]) instead of plain SMTP 🙌
the way an SMTP client gets a target domain, figures out which SMTP server a copy of the message should go to, and then actually does the transfer, is all covered by this document 📦 To transfer mail to an SMTP server, the client sets up a two-way transmission channel to that server. the client finds the right host by resolving the destination domain name to either an intermediate Mail eXchanger host or a final target host 🧭
an SMTP server can be the ultimate destination, or it can be an intermediate "relay" (meaning it takes on the SMTP client role after getting the message) or a "gateway" (meaning it moves the message along using some protocol other than SMTP) 🌉 SMTP commands come from the SMTP client and go to the SMTP server 📤 SMTP replies go back from the server to the client in response to those commands 📥
so the message can move in one connection straight from the original SMTP sender to the final SMTP recipient, or it can move in a series of hops through middle systems 🦋 Either way, once the server gives a success response at the end of the mail data, responsibility for the message gets formally handed off 🤝 The protocol says a server MUST accept responsibility for either delivering the message or properly reporting the failure to do so (see Sections 6.1, 6.2, and 7.8, below) 🫡
once the channel is up and the initial handshaking is done, the SMTP client usually starts a mail transaction 💬 A transaction is a series of commands that set the originator and destination of the mail, followed by the message content itself (including any lines in the header section or other structure) 📝 When the same message goes to multiple recipients, this protocol encourages sending just one copy of the data to all recipients at the same destination (or intermediate relay) host ♻️
the server replies to every command, and replies can say the command was accepted, that more commands are expected, or that there's a temporary or permanent error ⚠️ Commands that name the sender or recipients can include service extension requests the server allows, which Section 2.2 talks about 🧩 The dialog is on purpose lock-step, one at a time, though mutually agreed extension requests like command pipelining (RFC 2920 [19]) can change that 🕺
after a message has been sent, the client can ask for the connection to shut down, or it can start other mail transactions 🌷 An SMTP client can also use a connection to an SMTP server for side services, like verifying email addresses or getting the addresses of mailing list subscribers 🔎
as mentioned above, this protocol is how mail gets transmitted 📮 Back in the day, the transmission usually went straight from the sending user's host to the receiving user's host, as long as both hosts were on the same transport service 🕰️ When they weren't, the mail went through one or more relay SMTP servers 🔀 Today, a super common setup is submitting the original message to an intermediate "message submission" server, which is kind of like a relay but with some extra properties 🎀 Section 2.3.10 covers those servers, and RFC 4409 [18] goes into a lot more detail 💅 An intermediate host that acts as an SMTP relay, or as a gateway into some other transmission environment, is usually picked using the domain name service (DNS) Mail eXchanger mechanism 🗂️
usually, intermediate hosts are found through the DNS MX record, not through explicit "source" routing (see Section 5 and Appendix C and Appendix F.2) 🧭✨
2.2. The Extension Model ✨
2.2.1. Background ✨
okay so, in 1990 (about a decade after RFC 821 was finished) SMTP got a whole glow-up 💅 with a "service extensions" model. Now a client and server can literally agree to use shared features beyond the original SMTP basics 🦋 The extension mechanism lets an extended SMTP client and server recognize each other, and the server can tell the client which service extensions it supports 🫶
Contemporary SMTP implementations MUST support the basic extension mechanisms. For example, servers MUST support the EHLO command even if they don't implement any specific extensions, and clients SHOULD preferentially use EHLO instead of HELO. (However, for compatibility with older conforming implementations, SMTP clients and servers MUST support the original HELO mechanisms as a fallback.) Unless the different characteristics of HELO have to be identified for interoperability purposes, this document only talks about EHLO 💖
SMTP is super widely deployed, and high-quality implementations have proven to be very robust 💪 But the Internet community now considers some services important that weren't anticipated when the protocol was first designed. If support for those services is going to be added, it must be done in a way that lets older implementations keep working acceptably 🌸 The extension framework is made up of:
- The SMTP command EHLO, superseding the earlier HELO,
- a registry of SMTP service extensions,
- additional parameters to the SMTP MAIL and RCPT commands, and
- optional replacements for commands defined in this protocol, such as for DATA in non-ASCII transmissions (RFC 3030 [20]).
SMTP's strength comes mainly from its simplicity 🍓 Experience with lots of protocols has shown that protocols with few options tend toward ubiquity, while protocols with many options tend toward obscurity 🧚
Every single extension, no matter how good it sounds, must be carefully scrutinized for its implementation, deployment, and interoperability costs 🔍 In many cases, the cost of extending the SMTP service will likely outweigh the benefit 💀
2.2.2. Definition and Registration of Extensions 📚
The IANA maintains a registry of SMTP service extensions. Each extension gets a matching EHLO keyword value. Every service extension registered with the IANA must be defined in a formal Standards-Track or IESG-approved Experimental protocol document. That definition must include:
- the textual name of the SMTP service extension;
- the EHLO keyword value associated with the extension;
- the syntax and possible values of parameters associated with the EHLO keyword value;
- any additional SMTP verbs associated with the extension (additional verbs will usually be, but are not required to be, the same as the EHLO keyword value);
- any new parameters the extension associates with the MAIL or RCPT verbs;
- a description of how support for the extension affects the behavior of a server and client SMTP; and
- the increment by which the extension is increasing the maximum length of the commands MAIL and/or RCPT, over that specified in this Standard.
Also, any EHLO keyword value starting with an upper or lower case "X" refers to a local SMTP service extension used exclusively through bilateral agreement 🤝 Keywords beginning with "X" MUST NOT be used in a registered service extension. On the flip side, keyword values in the EHLO response that don't begin with "X" MUST correspond to a Standard, Standards-Track, or IESG-approved Experimental SMTP service extension registered with IANA. A conforming server MUST NOT offer non-"X"-prefixed keyword values that aren't described in a registered extension 🙈
Additional verbs and parameter names follow the same rules as EHLO keywords. Specifically, verbs beginning with "X" are local extensions that may not be registered or standardized. Conversely, verbs not beginning with "X" must always be registered ✨
2.2.3. Special Issues with Extensions 🎀
Extensions that change fairly basic properties of SMTP operation are permitted, so the text in other sections of this document must be understood in that context 🫠 In particular, extensions can change the minimum limits specified in Section 4.5.3, can change the ASCII character set requirement as mentioned above, or can introduce some optional modes of message handling.
Here's the tricky part 👀 If an extension implies that the delivery path normally supports its special features, and an intermediate SMTP system finds a next hop that doesn't support the required extension, it MAY choose, based on the specific extension and circumstances, to requeue the message and try later and/or try an alternate MX host. If this strategy is used, the timeout to fall back to an unextended format (if one is available) SHOULD be less than the normal timeout for bouncing as undeliverable (e.g., if normal timeout is three days, the requeue timeout before attempting to transmit the mail without the extension might be one day) ⏳
2.3. SMTP Terminology 🧠
2.3.1. Mail Objects 💌
SMTP transports a mail object. A mail object contains an envelope and content.
The SMTP envelope gets sent as a series of SMTP protocol units (described in Section 3). It has an originator address (where error reports should go), one or more recipient addresses, and optional protocol extension material. Historically, variations on the reverse-path (originator) address specification command (MAIL) could be used to specify alternate delivery modes, like immediate display. Those variations are now deprecated (see Appendix F and Appendix F.6) 🙅♀️
The SMTP content is sent in the SMTP DATA protocol unit and has two parts: the header section and the body. If the content conforms to other contemporary standards, the header section is a collection of header fields. Each one has a header name, a colon, and data, structured as in the message format specification (RFC 5322 [4]). The body, if structured, is defined according to MIME (RFC 2045 [21]). The content is textual in nature and expressed using the US-ASCII repertoire [6]. Although SMTP extensions (such as "8BITMIME", RFC 1652 [22]) may relax this restriction for the content body, the content header fields are always encoded using the US-ASCII repertoire. Two MIME extensions (RFC 2047 [23] and RFC 2231 [24]) define an algorithm for representing header values outside the US-ASCII repertoire, while still encoding them using the US-ASCII repertoire 🌈
2.3.2. Senders and Receivers 🫂
In RFC 821, the two hosts in an SMTP transaction were called the "SMTP-sender" and "SMTP-receiver". This document has been updated to match current industry terminology, so it calls them the "SMTP client" (or sometimes just "the client") and "SMTP server" (or just "the server"), respectively. Since one host can act as both server and client in a relay situation, "receiver" and "sender" terminology is still used where needed for clarity 🔁
2.3.3. Mail Agents and Message Stores 📮
More mail system terminology became common after RFC 821 was published, and where it's convenient, this specification uses it too. SMTP servers and clients provide a mail transport service, so they act as "Mail Transfer Agents" (MTAs). "Mail User Agents" (MUAs or UAs) are usually thought of as the sources and targets of mail. At the source, an MUA might collect mail from a user and hand it off to an MTA. The final ("delivery") MTA would be thought of as handing the mail off to an MUA (or at least transferring responsibility to it, e.g., by depositing the message in a "message store"). However, these terms are used with a lot of confidence in other environments, and the boundaries between MUAs and MTAs often don't line up with common, conforming practice on the Internet. So be careful about assuming the strong relationships and responsibilities those terms might imply if they were used somewhere else 🧐
2.3.4. Host 🖥️
For this specification, a host is a computer system attached to the Internet (or, in some cases, to a private TCP/IP network) that supports the SMTP protocol. Hosts are known by names (see the next section). They SHOULD NOT be identified by numerical addresses, i.e., by address literals as described in Section 4.1.2 🔢
2.3.5. Domain Names 🌐
A domain name (or often just a "domain") is made of one or more components, separated by dots if there's more than one. If a top-level domain is used by itself in an email address, a single string is used with no dots. This is why the requirement (described in more detail below) that only fully-qualified domain names appear in SMTP transactions on the public Internet matters so much, especially when top-level domains are involved 💅 These components ("labels" in DNS terminology, RFC 1035 [2]) are restricted for SMTP purposes to a sequence of letters, digits, and hyphens drawn from the ASCII character set [6]. Domain names are used as names of hosts and of other entities in the domain name hierarchy. For example, a domain may refer to an alias (label of a CNAME RR) or the label of Mail eXchanger records used to deliver mail, instead of representing a host name. See RFC 1035 [2] and Section 5 of this specification 🗺️
The domain name, as described in this document and in RFC 1035 [2], is the entire, fully-qualified name (often called an "FQDN"). A domain name that isn't in FQDN form is no more than a local alias. Local aliases MUST NOT appear in any SMTP transaction 🚫
Only resolvable, fully-qualified domain names (FQDNs) are allowed when domain names are used in SMTP. In other words, names that can be resolved to MX RRs or address (i.e., A or AAAA) RRs (as discussed in Section 5) are allowed, and so are CNAME RRs whose targets can be resolved, in turn, to MX or address RRs. Local nicknames or unqualified names MUST NOT be used. There are two exceptions to the FQDN rule:
- The domain name given in the EHLO command MUST be either a primary host name (a domain name that resolves to an address RR) or, if the host has no name, an address literal, as described in Section 4.1.3 and discussed further in the EHLO discussion of Section 4.1.4.
- The reserved mailbox name "postmaster" may be used in a RCPT command without domain qualification (see Section 4.1.1.3) and MUST be accepted if so used 💜
2.3.6. Buffer and State Table 🧺
SMTP sessions are stateful, and both parties carefully keep a shared view of the current state 👯 In this document, we model that state with a virtual "buffer" and a "state table" on the server. The client can use them to, for example, "clear the buffer" or "reset the state table". That discards the information in the buffer and returns the state to some previous state 🔄
2.3.7. Commands and Replies
okay so SMTP commands and, unless a service extension changes it, message data get sent from the sender to the receiver over the transmission channel in "lines" 💌
a reply is the receiver's acknowledgment, positive or negative, sent back to the sender in "lines" as a response to a command 🫶 the general shape is a numeric completion code (failure or success) that's usually followed by a text string. the codes are for programs and the text is mostly for humans 🧚 RFC 3463 [25], specifies further structuring of the reply strings, including supplemental and more specific completion codes (see also RFC 5248 [26]) ✨
2.3.8. Lines
lines are zero or more data characters ended by the sequence ASCII character "CR" (hex value 0D) followed immediately by ASCII character "LF" (hex value 0A) 🦋 this termination sequence is denoted as <CRLF> in this document. Conforming implementations MUST NOT recognize or generate any other character or character sequence as a line terminator. Limits MAY be imposed on line lengths by servers (see Section 4) 💅
bestie, the bare "CR" or "LF" characters (meaning one without the other) inside text have a long history of causing chaos in mail implementations and in apps that use the mail system as a tool 😭 so SMTP client implementations MUST NOT transmit these characters except when they're meant as line terminators, and then they MUST, as mentioned above, send them only as a <CRLF> sequence 🔥
2.3.9. Message Content and Mail Data
"message content" and "mail data" mean the same thing in this document 🌸 they both describe the material sent after the DATA command is accepted and before the end of data indication is sent. message content includes the message header section plus the possibly structured message body. the MIME specification (RFC 2045 [21]) gives the standard mechanisms for structured message bodies 🎀
2.3.10. Originator, Delivery, Relay, and Gateway Systems
this spec splits SMTP systems into four types, based on the role they play in moving electronic mail 👑 an "originating" system (sometimes called an SMTP originator) introduces mail into the Internet or, more generally, into a transport service environment ✨ a "delivery" SMTP system receives mail from a transport service environment and hands it to a mail user agent, or drops it into a message store that a mail user agent is expected to access later 📬 a "relay" SMTP system (usually just called a "relay") receives mail from an SMTP client and sends it on to another SMTP server for further relaying or for delivery, without changing the message data, except for adding trace information 🍓
a "gateway" SMTP system (usually just called a "gateway") receives mail from a client system in one transport environment and sends it to a server system in another transport environment 🌈 differences in protocols or message semantics between the two transport environments can mean the gateway has to transform the message in ways that relay systems aren't allowed to do 🙈 for the purposes of this spec, firewalls that rewrite addresses should be considered gateways, even when SMTP is used on both sides (see RFC 2979 [27]) 💜
2.3.11. Mailbox and Address
in this spec, an "address" is a character string that identifies a user who mail will be sent to, or a location where mail will be deposited 📮 the term "mailbox" refers to that depository. The two terms are usually used interchangeably, unless the difference between the place where mail is put (the mailbox) and the reference to it (the address) matters 🧚 an address normally has user and domain parts. the standard mailbox naming convention is local-part@domain, but contemporary usage allows a much broader set of applications than plain "user names" 🌸 because of a long history of problems when intermediate hosts tried to optimize transport by changing them, the local-part MUST be interpreted and assigned semantics only by the host specified in the domain part of the address 🔒
2.4. General Syntax Principles and Transaction Model
SMTP commands and replies have a rigid syntax, bestie 💅 all commands begin with a command verb, and all replies begin with a three digit numeric code 🔢 some commands and replies need arguments after the verb or reply code, some commands don't accept arguments at all, and some reply codes are followed (sometimes optionally) by free form text ✨ wherever text shows up, it's separated from the verb or reply code by a space character 🫶 complete definitions of commands and replies are in Section 4 📖
verbs and argument values (for example "TO:" or "to:" in the RCPT command, and extension name keywords) are not case sensitive 🎀 the one exception in this spec is a mailbox local-part (SMTP Extensions may explicitly specify case-sensitive elements) 🙈 so a command verb, an argument value other than a mailbox local-part, and free form text MAY be written in upper case, lower case, or any mix of the two with no change to their meaning 🦋 the local-part of a mailbox MUST BE treated as case sensitive, so SMTP implementations MUST take care to preserve the case of mailbox local-parts 😭 for some hosts, the user "smith" is different from the user "Smith" 👀 still, exploiting case sensitivity in local-parts impedes interoperability and is discouraged 🚫 mailbox domains follow normal DNS rules, so they are not case sensitive 🌈
a few SMTP servers, in violation of this specification (and RFC 821), require clients to write command verbs in upper case 💀 Implementations MAY wish to use this encoding to accommodate those servers 🫠
the argument clause is a variable-length character string that ends with the end of the line, i.e. with the character sequence <CRLF> 🔚 the receiver won't take any action until that sequence arrives ⏳
the syntax for each command is shown with the discussion of that command 📝 common elements and parameters are shown in Section 4.1.2 💖
commands and replies are made of characters from the ASCII character set [6] ✨ when the transport service gives an 8-bit byte (octet) channel, each 7-bit character is sent right justified in an octet with the high-order bit cleared to zero 🔧 basically, the unextended SMTP service only does 7-bit transport 🧸 an originating SMTP client that hasn't successfully negotiated an appropriate extension with a particular server (see the next paragraph) MUST NOT transmit messages with information in the high-order bit of octets 🚫 if messages are sent in violation of this rule, receiving SMTP servers MAY clear the high-order bit or reject the message as invalid 💥 in general, a relay SMTP SHOULD assume the message content it got is valid, and, as long as the envelope allows it, relay it without inspecting that content 🫶 of course, if the content is mislabeled and the data path can't handle the real content, the recipient might end up with a seriously garbled message 😵💫 delivery SMTP systems MAY reject such messages, or return them as undeliverable, instead of delivering them 📭 unless a server-offered extension explicitly permits it, a sending SMTP system isn't allowed to send envelope commands in any character set other than US-ASCII 🔤 receiving systems SHOULD reject such commands, normally with "500 syntax error - invalid character" replies ❌
8-bit message content transmission MAY be requested of the server by a client using extended SMTP facilities, notably the "8BITMIME" extension, RFC 1652 [22] 🌟 8BITMIME SHOULD be supported by SMTP servers 💖 however, it MUST NOT be construed as authorization to send unrestricted 8-bit material, and 8BITMIME doesn't authorize sending any envelope material in anything other than ASCII 🙅♀️ 8BITMIME MUST NOT be requested by senders for material with the high bit on that isn't in MIME format with an appropriate content-transfer encoding, and servers MAY reject such messages 🛑
the metalinguistic notation in this document matches the "Augmented BNF" used in other Internet mail system documents 🧠 if that syntax is new to you, go read the ABNF specification in RFC 5234 [7] 📚 metalanguage terms used in running text are wrapped in pointed brackets (e.g., <CRLF>) so they stand out 💅 the reader is cautioned that the grammar in the metalanguage is not comprehensive 😬 there are lots of cases where the text's provisions constrain or otherwise modify the syntax or semantics the grammar implies 🤯
3. The SMTP Procedures: An Overview
this section covers the procedures SMTP uses: session initiation, mail transactions, forwarding mail, verifying mailbox names and expanding mailing lists, and opening and closing exchanges 🎬 comments on relaying, a note on mail domains, and a discussion of changing roles are at the end of this section 💫 several complete scenarios are presented in Appendix D 🦋
3.1. Session Initiation
an SMTP session starts when a client opens a connection to a server and the server replies with an opening message 🌷
SMTP server implementations MAY include identification of their software and version information in the connection greeting reply after the 220 code, which makes problems way easier to isolate and fix 🔍 Implementations MAY make provision for SMTP servers to disable the software and version announcement where it causes security concerns 🔐 some systems also list a contact point for mail problems, but that is not a substitute for keeping the required "postmaster" address (see Section 4) 📮
the SMTP protocol lets a server formally reject a mail session while still allowing the initial connection, like this: a 554 response MAY be given in the initial connection opening message instead of the 220 🙅♀️ a server doing this MUST still wait for the client to send a QUIT (see Section 4.1.1.10) before closing the connection, and SHOULD respond to any intervening commands with "503 bad sequence of commands" 🚪 since trying to make an SMTP connection to such a system is probably a mistake, a server returning a 554 response on connection opening SHOULD give enough information in the reply text to help debug the sending system 🛠️💜
3.2. Client Initiation 💖
Okay so, once the server has sent its greeting (the welcoming message) and the client has received it, the client normally sends the EHLO command to introduce itself 🫶. Using EHLO does two things at once: it opens the session, and it tells the server "hey, I can handle service extensions, so please list the ones you support" ✨. Older SMTP systems that can't handle service extensions, and modern clients that don't need extensions for the session they're starting, MAY use HELO instead of EHLO 🌸. Servers MUST NOT return the extended EHLO-style response to a HELO command 🙅. For a particular connection attempt, if the server replies with a "command not recognized" response to EHLO, the client SHOULD be able to fall back and send HELO 🔁.
In the EHLO command, the sending host introduces itself. It's basically saying "Hello, I am <domain>" and, for EHLO, also "and I support service extension requests" 👑.
3.3. Mail Transactions 📬
There are three steps to an SMTP mail transaction, and honestly it's giving very organized ✨. The transaction starts with a MAIL command that gives the sender's identity. (Generally, MAIL may only be sent when no mail transaction is in progress; see Section 4.1.4.) Then comes a series of one or more RCPT commands that give the receiver info 💌. Finally, a DATA command starts the transfer of the mail data, which ends with the "end of mail" data indicator. That indicator also confirms the whole transaction 💅.
The first step is the MAIL command.
MAIL FROM:<reverse-path> [SP <mail-parameters> ] <CRLF>This command tells the SMTP receiver that a brand-new mail transaction is starting, and that it should reset all of its state tables and buffers, including any recipients or mail data 🧹. The <reverse-path> part of the first or only argument holds the source mailbox (between the "<" and ">" brackets), which can be used to report errors (see Section 4.2 for a discussion of error reporting) 📮. If it's accepted, the SMTP server returns a 250 OK reply 🎉. If the mailbox specification isn't acceptable for some reason, the server MUST return a reply saying whether the failure is permanent (meaning it will happen again if the client tries that same address again) or temporary (meaning the address might be accepted if the client tries again later) 🚦. Now, despite how strict that sounds, there are situations where the reverse-path can't be judged until one or more forward-paths (in RCPT commands) have been checked 🤔. In those cases, the server MAY reasonably accept the reverse-path (with a 250 reply) and then report problems once the forward-paths arrive and get examined. Normally, failures produce 550 or 553 replies 🙈.
Historically, the <reverse-path> was allowed to hold more than just a mailbox. However, contemporary systems SHOULD NOT use source routing (see Appendix C) 🚫.
The optional <mail-parameters> are tied to negotiated SMTP service extensions (see Section 2.2) 🧩.
The second step is the RCPT command, and this step can be repeated any number of times 🔁.
RCPT TO:<forward-path> [ SP <rcpt-parameters> ] <CRLF>The first or only argument to this command includes a forward-path (normally a mailbox and domain, always wrapped in "<" and ">" brackets) that identifies one recipient 💖. If it's accepted, the SMTP server returns a 250 OK reply and stores the forward-path. If the recipient is known to not be a deliverable address, the SMTP server returns a 550 reply, typically with a string like "no such user - " followed by the mailbox name (other circumstances and reply codes are possible) 💀.
The <forward-path> can contain more than just a mailbox. Historically, it was allowed to contain a source routing list of hosts plus the destination mailbox. However, contemporary SMTP clients SHOULD NOT utilize source routes (see Appendix C) 🙅. Servers MUST be prepared to encounter a list of source routes in the forward-path, but they SHOULD ignore the routes or MAY decline to support the relaying they imply 🛤️. Similarly, servers MAY decline to accept mail destined for other hosts or systems 🙅♀️. These restrictions make a server useless as a relay for clients that don't support full SMTP functionality. So, restricted-capability clients MUST NOT assume that any SMTP server on the Internet can be used as their mail processing (relaying) site 😭. If an RCPT command shows up without a previous MAIL command, the server MUST return a 503 "Bad sequence of commands" response 🚨. The optional <rcpt-parameters> are tied to negotiated SMTP service extensions (see Section 2.2) 🧩.
Since this has been a common source of errors, it's worth pointing out that spaces are NOT allowed on either side of the colon after FROM in the MAIL command or after TO in the RCPT command. The syntax is exactly as shown above 🎀. No cap, be precise.
The third step is the DATA command (or some alternative specified in a service extension) 🪄.
DATA <CRLF>If it's accepted, the SMTP server returns a 354 Intermediate reply and treats every line that follows, up to but not including the end of mail data indicator, as the message text ✍️. Once the end of text has been received and stored, the SMTP receiver sends a 250 OK reply 🎉.
Because the mail data travels over the transmission channel, the end of mail data has to be marked so that the command and reply dialog can pick back up 🔚. SMTP marks the end by sending a line that contains only a "." (period or full stop) 🦋. A transparency procedure keeps that from messing with the user's text (see Section 4.5.2) 🛡️.
The end of mail data indicator also confirms the mail transaction and tells the SMTP server to process the stored recipients and mail data now 💜. If accepted, the SMTP server returns a 250 OK reply. The DATA command can fail at only two points in the protocol exchange 🧐:
If there was no MAIL or no RCPT command, or if all such commands were rejected, the server MAY return a "command out of sequence" (503) or "no valid recipients" (554) reply in response to the DATA command 🙃. If one of those replies (or any other 5yz reply) comes back, the client MUST NOT send the message data. More generally, message data MUST NOT be sent unless a 354 reply has been received 🛑.
If the verb is initially accepted and the 354 reply is issued, the DATA command should fail only if the mail transaction was incomplete (for example, there are no recipients), if resources were unavailable (including, of course, the server unexpectedly going down), or if the server decides the message should be rejected for policy or other reasons 🧾.
However, in practice, some servers don't check recipients until after the message text has been received 👀. These servers SHOULD treat a failure for one or more recipients as a "subsequent failure" and return a mail message as discussed in Section 6 and, in particular, in Section 6.1 📨. Using a 550 mailbox not found (or equivalent) reply code after the data has been accepted makes it hard or impossible for the client to figure out which recipients failed 😵💫.
When the RFC 822 format ([28], [4]) is in use, the mail data includes header fields like Date, Subject, To, Cc, and From 📝. Server SMTP systems SHOULD NOT reject messages based on perceived defects in the RFC 822 or MIME (RFC 2045 [21]) message header section or message body 💅. In particular, they MUST NOT reject messages where the numbers of Resent- header fields don't match, or where Resent-to appears without Resent-from and/or Resent-date 🙅♀️.
Mail transaction commands MUST be used in the order discussed above 📋. Order matters, bestie!
3.4. Forwarding for Address Correction or Updating 🦋
Forwarding support is most often needed to consolidate and simplify addresses within an enterprise, or relative to one, and less often to link a person's old address with their current one 🏢. Silent forwarding (where the sender isn't notified by the server), done for security or non-disclosure reasons, is pretty common on the contemporary Internet 🤫.
In both the enterprise case and the "new address" case, information hiding (and sometimes security) considerations argue against exposing the "final" address through the SMTP protocol as a side effect of forwarding 🙈. This matters even more when the final address may not even be reachable by the sender 🔒. So the "forwarding" mechanisms described in Section 3.2 of RFC 821, especially the 251 (corrected destination) and 551 reply codes from RCPT, must be evaluated carefully by implementers and, when they're available, by the people configuring systems (see also Section 7.4) 🧐.
In particular:
- Servers MAY forward messages when they are aware of an address change. When they do, they MAY either provide address-updating information with a
251code, or forward "silently" and return a250code. However, if a251code is used, they MUST NOT assume that the client will actually update address information or even return that information to the user 🫶.
Alternately:
- Servers MAY reject messages or return them as non-deliverable when they cannot be delivered precisely as addressed. When they do, they MAY either provide address-updating information with a
551code, or reject the message as undeliverable with a550code and no address-specific information. However, if a551code is used, they MUST NOT assume that the client will actually update address information or even return that information to the user 💌.
SMTP server implementations that support the 251 and/or 551 reply codes SHOULD provide configuration mechanisms, so that sites that decide they'd be disclosing information they don't want to can disable or restrict those codes 🔐✨.
3.5. Commands for Debugging Addresses 🔍
3.5.1. Overview ✨
okay so SMTP has commands that let you check whether a user name is real or pull up the members of a mailing list 🔍 Those are the VRFY and EXPN commands, and they both take character string arguments. Implementations SHOULD support VRFY and EXPN 💅 (however, see Section 3.5.2 and Section 7.3 🙈)
For VRFY, the string is a user name or a user name and domain (see below) 🎀 If you get a normal (i.e., 250) response back, the response MAY include the full name of the user, and it MUST include the mailbox of the user. The mailbox MUST be in one of these two forms:
User Name <local-part@domain>
local-part@domainWhen a name you send to VRFY could point at more than one mailbox, the server MAY either flag the ambiguity or list the options 👀 So all of these are legit responses to VRFY:
553 User ambiguousor
553- Ambiguous; Possibilities are
553-Joe Smith <jsmith@foo.com>
553-Harry Smith <hsmith@foo.com>
553 Melvin Smith <dweep@foo.com>or
553-Ambiguous; Possibilities
553- <jsmith@foo.com>
553- <hsmith@foo.com>
553 <dweep@foo.com>Normally, when a client gets a 553 reply, it's expected to show the result to the user 💖 Using exactly the forms above, plus the "user ambiguous" or "ambiguous" keywords (maybe with extended reply codes, like the ones in RFC 3463 [25] 🧚), makes it way easier to auto-translate things into other languages. Now, a client that's super automated, or one that runs in a language other than English, might decide to translate the response and show the user something else instead of the literal reply text 🌈 It could also take an automated step, like checking a directory service for more info before reporting back. Iconic behaviour, honestly 💅
For EXPN, the string identifies a mailing list, and the successful (i.e., 250) multiline response MAY include the full names of the users. It MUST give the mailboxes on the mailing list 📬
Okay this part is so real: in some hosts, the line between a mailing list and an alias for one mailbox is kinda blurry 🫠 A single data structure can hold both kinds of entries, and a mailing list can even have just one mailbox in it. If someone asks to VRFY a mailing list, a positive response MAY be given if a message addressed that way would reach everyone on the list. Otherwise an error SHOULD be reported, like "550 That is a mailing list, not a user" or "252 Unable to verify members of mailing list" 🙃 If someone asks to expand a user name, the server MAY send back a positive response that's a list with one name in it. Or an error MAY be reported, like "550 That is a user name, not a mailing list" 💀
When you get a successful multiline reply (which is normal for EXPN), each line of the reply has to specify exactly one mailbox 🍓 We already talked about how ambiguous requests work above.
"User name" is a deliberately fuzzy term, btw ✨ An implementation of VRFY or EXPN MUST at least recognise local mailboxes as "user names". BUT, since current Internet practice often has one host handling mail for multiple domains, hosts (especially the ones that offer this functionality) SHOULD accept the "local-part@domain" form as a "user name". Hosts MAY also choose to recognise other strings as "user names" 🌸
Expanding a mailbox list needs a multiline reply, like this:
C: EXPN Example-People
S: 250-Jon Postel <Postel@isi.edu>
S: 250-Fred Fonebone <Fonebone@physics.foo-u.edu>
S: 250 Sam Q. Smith <SQSmith@specific.generic.com>or
C: EXPN Executive-Washroom-List
S: 550 Access Denied to You.The character string arguments for VRFY and EXPN can't be restricted any further, because user name and mailbox list concepts vary so much between implementations 🦋 On some systems, the EXPN argument might be a file name for a file holding a mailing list, but there are all sorts of file naming conventions across the Internet. Also, what these commands return has varied historically, so the response SHOULD be interpreted very carefully (if at all) and SHOULD generally only be used for diagnostic purposes 🔧
3.5.2. VRFY Normal Response 🫶
When a VRFY or EXPN request gets a normal (2yz or 551) response, the reply MUST include the <Mailbox> name in a "<local-part@domain>" construction, where "domain" is a fully-qualified domain name 💜 Free-form text MAY be returned, but only in circumstances exceptional enough to justify breaking the intent of this specification. To help both computers and people parse things, addresses SHOULD appear in pointed brackets 🌟 When addresses are returned (instead of free-form debugging info), EXPN and VRFY MUST return only valid domain addresses that can be used in SMTP RCPT commands. So if an address implies delivery to a program or some other system, the mailbox name used to reach that target MUST be given 🎯 Paths (explicit source routes) MUST NOT be returned by VRFY or EXPN 🚫
Server implementations SHOULD support both VRFY and EXPN. For security reasons, implementations MAY give local installations a way to disable either or both of these commands through configuration options or the equivalent (see Section 7.3) 🔒 When these commands are supported, they aren't required to work across relays when relaying is supported. Both were optional in RFC 821, but VRFY was made mandatory in RFC 1123 [3], so if EXPN is supported, it MUST be listed as a service extension in an EHLO response 📋 VRFY MAY be listed as a convenience, but since support for it is required, SMTP clients don't have to check for its presence on the extension list before using it 😌
3.5.3. Meaning of VRFY or EXPN Success Response 🎀
A server MUST NOT return a 250 code in response to a VRFY or EXPN command unless it has actually verified the address 🙅♀️ Especially, a server MUST NOT return 250 if all it did was check that the syntax is valid. In that case, 502 (Command not implemented) or 500 (Syntax error, command unrecognized) SHOULD be returned. As mentioned elsewhere, actually implementing VRFY and EXPN (validating addresses and returning info) is strongly recommended 💖 So implementations that return 500 or 502 for VRFY are not in full compliance with this specification 💀
There can be situations where an address looks valid but can't reasonably be verified in real time, especially when a server is acting as a mail exchanger for another server or domain 🤔 In this case, "apparent validity" would normally involve at least syntax checking, and might involve confirming that any domains specified are ones the host expected to be able to relay mail to. In these situations, reply code 252 SHOULD be returned 🌈 These cases parallel the RCPT verification discussion in Section 2.1. Similarly, the discussion in Section 3.4 applies to using reply codes 251 and 551 with VRFY (and EXPN) to show addresses that are recognised but would be forwarded or rejected if mail came in for them ✨ Implementations generally SHOULD be more aggressive about address verification for VRFY than for RCPT, even if it takes a little longer 🏃♀️
3.5.4. Semantics and Applications of EXPN 🧚
EXPN is honestly super useful for debugging and figuring out what's going wrong with mailing lists and multiple-target-address aliases 🔍 Some systems have tried to use source expansion of mailing lists to get rid of duplicates. But aliasing across mail on the Internet (for hosts, usually with MX and CNAME DNS records, for mailboxes via various kinds of local host aliases, and in various proxying setups) has made it nearly impossible for these strategies to work consistently 😭 So mail systems SHOULD NOT attempt them 🙅♀️
3.6. Relaying and Mail Routing 🦋
3.6.1. Source Routes and Relaying 🗺️
In general, Mail eXchanger records in the domain name system (RFC 1035 [2], RFC 974 [12]) make explicit source routes unnecessary in the Internet mail system 💅 Lots of historical problems with interpreting explicit source routes made using them undesirable. SMTP clients SHOULD NOT generate explicit source routes except under unusual circumstances. SMTP servers MAY decline to act as mail relays or to accept addresses that specify source routes. When route information shows up, SMTP servers MAY ignore it and just send to the final destination (the last element in the route), and SHOULD do so 🎯 There's been an invalid practice of using names that don't appear in the DNS as destination names, with senders counting on the intermediate hosts in source routing to sort out any problems 🙈 If source routes get stripped, this practice will cause failures. This is one of several reasons why SMTP clients MUST NOT generate invalid source routes or depend on serial resolution of names 🚫
When source routes aren't used, the process RFC 821 describes for building a reverse-path from the forward-path doesn't apply. The reverse-path at delivery time will just be the address that appeared in the MAIL command 💌
3.6.2. Mail eXchange Records and Relaying 📮
A relay SMTP server is usually the target of a DNS MX record that designates it, rather than the final delivery system 🌸 The relay server can accept or reject the job of relaying the mail, the same way it accepts or rejects mail for a local user. If it accepts the job, it becomes an SMTP client, opens a transmission channel to the next SMTP server listed in the DNS (following the rules in Section 5), and sends it the mail 📤 If it declines to relay mail to a particular address for policy reasons, a 550 response SHOULD be returned 🙅♀️
This specification doesn't deal with verifying return paths for delivery notifications 🕵️♀️ Recent work, like SPF [29] and DKIM [30] [31], has been done to offer ways to check that an address is valid or belongs to the person who actually sent the message. A server MAY attempt to verify the return path before using its address for delivery notifications. But methods for doing so aren't defined here, and no particular method is recommended at this time 🫶
3.6.3. Message Submission Servers as Relays
okay so, tons of mail-sending clients exist 🌸 especially the ones hooked up to POP3 or IMAP mailboxes, and they're kinda limited 😭. they can't always handle stuff this spec asks for, like being able to queue messages for later delivery attempts. so the common move is making private arrangements where every message goes to one server for processing and distribution. SMTP as written here isn't ideally suited for that job 🙈. there's a standardized mail submission protocol that's slowly replacing SMTP-based setups (see RFC 4409 [18]). anyway, these arrangements are private and outside the scope of this spec, so we're not describing them here 💅
btw, MX records can point to SMTP servers that act as gateways into other environments, not just relays and final delivery systems 🦋 see Sections 3.7 and 5.
if an SMTP server has accepted the task of relaying mail and later finds that the destination is wrong or the mail can't be delivered for some other reason, then it MUST construct an "undeliverable mail" notification message and send it to the originator of the undeliverable mail (as indicated by the reverse-path) 📨. formats specified for non-delivery reports by other standards (like RFC 3461 [32] and RFC 3464 [33]) SHOULD be used if possible 🫶
this notification message must be from the SMTP server at the relay host, or the host that first determines delivery can't happen. and of course, SMTP servers MUST NOT send notification messages about problems transporting notification messages 🙅♀️. one way to prevent loops in error reporting is to use a null reverse-path in the MAIL command of a notification message 🔁. when one of these is transmitted, the reverse-path MUST be set to null (see Section 4.5.5 for more) 🌈. it looks like this:
MAIL FROM:<>as discussed in Section 6.4, a relay SMTP has no need to inspect or act upon the header section or body of the message data 👀. it MUST NOT do so, except to add its own Received: header field (Section 4.4) and, optionally, to attempt to detect looping in the mail system (see Section 6.3). and yes, this no-touch rule also covers any changes to these header fields or text (see also Section 7.9) 🔒
3.7. Mail Gatewaying
while the relay function we just covered runs inside the Internet SMTP transport service environment, MX records or various forms of explicit routing may require an intermediate SMTP server to translate between one transport service and another 🔄. as discussed in Section 2.3.10, when such a system sits at the boundary between two transport service environments, we call it a "gateway" or "gateway SMTP" 🚪
gatewaying mail between different mail environments, like different mail formats and protocols, is complex and doesn't easily yield to standardization 🤯. however, some general requirements can be given for a gateway between the Internet and another mail environment 💖
3.7.1. Header Fields in Gatewaying
header fields MAY be rewritten when necessary as messages are gatewayed across mail environment boundaries 🪄. this may involve inspecting the message body or interpreting the local-part of the destination address, in spite of the prohibitions in Section 6.4.
other mail systems gatewayed to the Internet often use a subset of the RFC 822 header section or provide similar functionality with a different syntax, but some of these don't have an equivalent to the SMTP envelope 📭. so when a message leaves the Internet environment, it may be necessary to fold the SMTP envelope information into the message header section. a possible solution would be to create new header fields to carry the envelope info (e.g., X-SMTP-MAIL: and X-SMTP-RCPT:) 🧩. however, that would require changes in mail programs in foreign environments and might risk disclosure of private information (see Section 7.2) 😬
3.7.2. Received Lines in Gatewaying
when forwarding a message into or out of the Internet environment, a gateway MUST prepend a Received: line, but it MUST NOT alter in any way a Received: line that's already in the header section 📜.
Received: header fields from messages originating in other environments may not conform exactly to this specification 🤷♀️. but the most important use of Received lines is debugging mail faults, and this debugging can get seriously hampered by well-meaning gateways that try to "fix" a Received line 😤. as another consequence of trace header fields arising in non-SMTP environments, receiving systems MUST NOT reject mail based on the format of a trace header field, and SHOULD be extremely robust in the light of unexpected information or formats in those header fields 💅
the gateway SHOULD indicate the environment and protocol in the "via" clauses of Received header field(s) that it supplies 🏷️
3.7.3. Addresses in Gatewaying
from the Internet side, the gateway SHOULD accept all valid address formats in SMTP commands and in the RFC 822 header section, and all valid RFC 822 messages 📬. addresses and header fields generated by gateways MUST conform to applicable standards (including this one and RFC 5322 [4]). gateways are, of course, subject to the same rules for handling source routes as those described for other SMTP systems in Section 3.3 🗺️
3.7.4. Other Header Fields in Gatewaying
the gateway MUST ensure that all header fields of a message that it forwards into the Internet mail environment meet the requirements for Internet mail 🛡️. in particular, all addresses in From:, To:, Cc:, etc., header fields MUST be transformed (if necessary) to satisfy the standard header syntax of RFC 5322 [4], MUST reference only fully-qualified domain names, and MUST be effective and useful for sending replies 💌. the translation algorithm used to convert mail from the Internet protocols to another environment's protocol SHOULD ensure that error messages from the foreign mail environment are delivered to the reverse-path from the SMTP envelope, not to an address in the From:, Sender:, or similar header fields of the message 📮
3.7.5. Envelopes in Gatewaying
similarly, when forwarding a message from another environment into the Internet, the gateway SHOULD set the envelope return path in accordance with an error message return address, if the foreign environment supplies one 💫. if the foreign environment has no equivalent concept, the gateway must select and use a best approximation, with the message originator's address as the default of last resort 🫠
3.8. Terminating Sessions and Connections
an SMTP connection is terminated when the client sends a QUIT command 👋. the server responds with a positive reply code, after which it closes the connection 🚪
An SMTP server MUST NOT intentionally close the connection under normal operational circumstances (see Section 7.8) except:
- After receiving a QUIT command and responding with a
221reply. - After detecting the need to shut down the SMTP service and returning a
421response code. This response code can be issued after the server receives any command or, if necessary, asynchronously from command receipt (on the assumption that the client will receive it after the next command is issued). - After a timeout, as specified in Section 4.5.3.2, occurs waiting for the client to send a command or data.
in particular, a server that closes connections in response to commands that aren't understood is in violation of this specification 🚫. servers are expected to be tolerant of unknown commands, issuing a 500 reply and awaiting further instructions from the client 🥰
an SMTP server that is forcibly shut down via external means SHOULD attempt to send a line containing a 421 response code to the SMTP client before exiting 💥. the SMTP client will normally read the 421 response code after sending its next command 📖
SMTP clients that experience a connection close, reset, or other communications failure due to circumstances not under their control (in violation of the intent of this specification but sometimes unavoidable) SHOULD, to maintain the robustness of the mail system, treat the mail transaction as if a 451 response had been received and act accordingly 🛠️
3.9. Mailing Lists and Aliases
An SMTP-capable host SHOULD support both the alias and the list models of address expansion for multiple delivery 🌟. when a message is delivered or forwarded to each address of an expanded list form, the return address in the envelope (MAIL FROM:) MUST be changed to be the address of a person or other entity who administers the list 👑. however, in this case, the message header section (RFC 5322 [4]) MUST be left unchanged; in particular, the "From" field of the header section is unaffected 🙌
an important mail facility is a mechanism for multi-destination delivery of a single message, by transforming (or "expanding" or "exploding") a pseudo-mailbox address into a list of destination mailbox addresses 🧨. when a message is sent to such a pseudo-mailbox (sometimes called an "exploder"), copies are forwarded or redistributed to each mailbox in the expanded list 📬. Servers SHOULD simply utilize the addresses on the list; application of heuristics or other matching rules to eliminate some addresses, such as that of the originator, is strongly discouraged 🙅♀️. we classify such a pseudo-mailbox as an "alias" or a "list", depending upon the expansion rules 🏷️
3.9.1. Alias
to expand an alias, the recipient mailer simply replaces the pseudo-mailbox address in the envelope with each of the expanded addresses in turn 🔁. the rest of the envelope and the message body are left unchanged. the message is then delivered or forwarded to each expanded address 💜
3.9.2. List
a mailing list may be said to operate by "redistribution" rather than by "forwarding" 🎀. to expand a list, the recipient mailer replaces the pseudo-mailbox address in the envelope with each of the expanded addresses in turn. the return (backward-pointing) address in the envelope is changed so that all error messages generated by the final deliveries will be returned to a list administrator, not to the message originator, who generally has no control over the contents of the list and will typically find error messages annoying 😩. note that the key difference between handling aliases (Section 3.9.1) and forwarding (this subsection) is the change to the backward-pointing address in this case 🔑. when a list constrains its processing to the very limited set of modifications and actions described here, it is attempting to emulate an MTA; such lists can be treated as a continuation in email transit 🚆
there exist mailing lists that perform additional, sometimes extensive, modifications to a message and its envelope 🛠️. such mailing lists need to be viewed as full MUAs, which accept a delivery and post a new message 📝
4. The SMTP Specifications ✨
4.1. SMTP Commands
4.1.1. Command Semantics and Syntax 💌
Okay bestie, SMTP commands are the little messages that tell the server what mail job you want done 📬. Each one is a character string that ends in <CRLF>. The command word is alphabetic characters, followed by <SP> if parameters come next, or by <CRLF> if they don't 🎀. (For better interoperability, SMTP receivers SHOULD tolerate trailing white space before the terminating <CRLF> 🫶.) The syntax of the local part of a mailbox MUST conform to receiver site conventions and the syntax in Section 4.1.2 ✨. We'll go through the commands below, and the replies are in Section 4.2 💅.
A mail transaction juggles several data objects, and each one gets passed to a different command as an argument 🧚. There's the reverse-path (the argument to MAIL), the forward-path (the argument to RCPT), and the mail data (the argument to DATA). These have to be transmitted and held until the end of mail data indication finalizes the transaction, so they're stuck in limbo until then 🌸. The way to picture it is that there are separate buffers for each type: a reverse-path buffer, a forward-path buffer, and a mail data buffer 🍓. Specific commands either add info to one particular buffer or clear one or more buffers 🧹.
Some commands (RSET, DATA, QUIT) don't allow parameters at all. Unless the server offers a specific extension and the client accepts it, clients MUST NOT send parameters with them, and servers SHOULD reject any command that includes them as having invalid syntax 🙅♀️. Not allowed, periodt 💅.
4.1.1.1. Extended HELLO (EHLO) or HELLO (HELO) 👋
These commands introduce the SMTP client to the SMTP server 🌈. The argument clause holds the fully-qualified domain name of the SMTP client, if it has one 🌐. If the client doesn't have a meaningful domain name (like when its address is dynamically allocated and there's no reverse mapping record), the client SHOULD send an address literal instead (see Section 4.1.3) 🦋.
RFC 2821, and some earlier informal practices, encouraged following the literal with info that would help identify the client system. That convention never really caught on, and plenty of SMTP servers treated it as an error 🙈. For interoperability it's probably wise for servers to be ready for that string showing up, but SMTP clients SHOULD NOT send it 🚫.
The SMTP server identifies itself to the client in the connection greeting reply and again in the response to this command 🪞.
A client SMTP SHOULD start a session by issuing the EHLO command 💜. If the server supports the SMTP service extensions, it gives a successful, failure, or error response. If the server, in violation of this specification, doesn't support any SMTP service extensions, it will generate an error response 😭. Older client SMTP systems MAY, as discussed above, use HELO (as specified in RFC 821) instead of EHLO, and servers MUST support the HELO command and reply properly to it 🎀. Either way, a client MUST issue HELO or EHLO before starting a mail transaction ✨.
Both commands, and a "250 OK" reply to one of them, confirm that the SMTP client and server are both in the initial state. That means no transaction is in progress and all state tables and buffers are cleared 🧼.
Syntax:
ehlo = "EHLO" SP ( Domain / address-literal ) CRLF
helo = "HELO" SP Domain CRLFNormally, the response to EHLO is a multiline reply 📜. Each line has a keyword and, optionally, one or more parameters. Following the normal syntax for multiline replies, the keywords come after the code (250). Every line except the last gets a hyphen after the code, and the last line gets a space. The syntax for a positive response, using the ABNF notation and terminal symbols of RFC 5234 [7], is:
ehlo-ok-rsp = ( "250" SP Domain [ SP ehlo-greet ] CRLF )
/ ( "250-" Domain [ SP ehlo-greet ] CRLF
*( "250-" ehlo-line CRLF )
"250" SP ehlo-line CRLF )
ehlo-greet = 1*(%d0-9 / %d11-12 / %d14-127)
; string of any characters other than CR or LF
ehlo-line = ehlo-keyword *( SP ehlo-param )
ehlo-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
; additional syntax of ehlo-params depends on
; ehlo-keyword
ehlo-param = 1*(%d33-126)
; any CHAR excluding <SP> and all
; control characters (US-ASCII 0-31 and 127
; inclusive)EHLO keywords can be written in upper, lower, or mixed case, but they MUST always be recognized and processed in a case-insensitive manner 🔤. This just extends practices from RFC 821 and Section 2.4, so nothing brand new here 💖.
The EHLO response MUST contain keywords (and associated parameters if required) for all commands not listed as "required" in Section 4.5.1, with the only exception being private-use commands described in Section 4.1.5 🔑. Private-use commands MAY be listed 🌸.
4.1.1.2. MAIL (MAIL) 📨
This command starts a mail transaction, where the mail data gets delivered to an SMTP server 🚀. That server might then deliver it to one or more mailboxes, or pass it on to another system (possibly using SMTP again) 🔁. The argument clause contains a reverse-path and may contain optional parameters. Generally, the MAIL command may be sent only when no mail transaction is in progress, see Section 4.1.4 🙅♀️.
The reverse-path is the sender mailbox. Historically, that mailbox might optionally have been preceded by a list of hosts, but that behavior is now deprecated (see Appendix C) 🗑️. In some reporting messages where a reply is likely to cause a mail loop (like mail delivery and non-delivery notifications), the reverse-path may be null (see Section 3.6) 🌀.
This command clears the reverse-path buffer, the forward-path buffer, and the mail data buffer 🧹. Then it puts the reverse-path info from its argument clause into the reverse-path buffer 💌.
If service extensions were negotiated, the MAIL command may also carry parameters tied to a specific service extension 🎀.
Syntax:
mail = "MAIL FROM:" Reverse-path
[SP Mail-parameters] CRLF4.1.1.3. RECIPIENT (RCPT) 💁♀️
This command identifies one individual recipient of the mail data. You specify multiple recipients by using this command multiple times 👯♀️. The argument clause contains a forward-path and may contain optional parameters 🧁.
The forward-path normally consists of the required destination mailbox. Sending systems SHOULD NOT generate the optional list of hosts known as a source route 🚫. Receiving systems MUST recognize source route syntax, but SHOULD strip off the source route specification and use the domain name associated with the mailbox as if no source route had been given 🧼.
Similarly, relay hosts SHOULD strip or ignore source routes, and names MUST NOT be copied into the reverse-path 🙅♀️. When mail reaches its ultimate destination (when the forward-path contains only a destination mailbox), the SMTP server puts it in the destination mailbox according to its host mail conventions 🏡.
This command appends its forward-path argument to the forward-path buffer. It doesn't change the reverse-path buffer or the mail data buffer 🧚.
For example, say mail arrives at relay host xyz.com with these envelope commands:
MAIL FROM:<userx@y.foo.org>
RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org>It will normally be sent straight on to host d.bar.org with these envelope commands:
MAIL FROM:<userx@y.foo.org>
RCPT TO:<userc@d.bar.org>As Appendix C explains, xyz.com MAY also choose to relay the message to hosta.int, using these envelope commands:
MAIL FROM:<userx@y.foo.org>
RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org>Or it can relay the message to jkl.org, using these envelope commands:
MAIL FROM:<userx@y.foo.org>
RCPT TO:<@jkl.org:userc@d.bar.org>Relaying like this is now strongly discouraged 🚨. Since hosts aren't required to relay mail at all, xyz.com MAY also reject the message entirely when the RCPT command is received, using a 550 code (since this is a "policy reason") 🙅♀️.
If service extensions were negotiated, the RCPT command may also carry parameters tied to a particular service extension the server offers 🌈. The client MUST NOT transmit parameters other than those associated with a service extension that the server offered in its EHLO response 🔒.
Syntax:
rcpt = "RCPT TO:" ( "<Postmaster@" Domain ">" / "<Postmaster>" /
Forward-path ) [SP Rcpt-parameters] CRLFNote that, in a departure from the usual rules for local-parts, the "Postmaster" string shown above is treated as case-insensitive 🙌.
4.1.1.4. DATA (DATA) 💌
okay bestie, the receiver normally sends a 354 response to DATA 💅 and then treats the lines (strings ending in <CRLF> sequences, as described in Section 2.3.7) after the command as mail data from the sender 📨. This command makes that mail data get appended to the mail data buffer 🫶. The mail data can contain any of the 128 ASCII character codes ✨, but experience has shown that control characters other than SP, HT, CR, and LF can cause problems, so they SHOULD be avoided when possible 🙈.
The mail data ends with a line that has only a period 🛑, aka the character sequence "<CRLF>.<CRLF>", where the first <CRLF> is actually the terminator of the previous line (see Section 4.5.2). This is the end of mail data indication 🏁. The first <CRLF> of this terminating sequence is also the <CRLF> that ends the final line of the data (message text) or, if there was no mail data, ends the DATA command itself (the "no mail data" case does not conform to this specification since it would require that neither the trace header fields required by this specification nor the message header section required by RFC 5322 [4] be transmitted) 🤓. An extra <CRLF> MUST NOT be added, because that would make an empty line show up in the message 🙅. The only exception would be if the message body got passed to the originating SMTP-sender with a final "line" that didn't end in <CRLF>. In that case, the originating SMTP system MUST either reject the message as invalid or add <CRLF> so the receiving SMTP server can recognize the "end of data" condition 💀.
The habit of accepting lines that end only in <LF>, a concession to non-conforming behavior from some UNIX systems, has caused more interoperability problems than it solves 😤. SMTP server systems MUST NOT do this, even in the name of improved robustness. Specifically, the sequence "<LF>.<LF>" (bare line feeds, without carriage returns) MUST NOT be treated as equivalent to <CRLF>.<CRLF> as the end of mail data indication 🚫.
Receiving the end of mail data indication means the server has to process the stored mail transaction information 🧠. That processing uses up the information in the reverse-path buffer, the forward-path buffer, and the mail data buffer, and once this command finishes, all of those buffers get cleared 🧹. If the processing succeeds, the receiver MUST send an OK reply. If the processing fails, the receiver MUST send a failure reply. The SMTP model doesn't allow partial failures at this point, so either the message is accepted for delivery and a positive response comes back, or it isn't accepted and a failure reply comes back 🙅♀️. When the receiver sends a positive "250 OK" completion reply to the end of data indication, it takes full responsibility for the message (see Section 6.1) 👑. Errors diagnosed later MUST be reported in a mail message, as discussed in Section 4.4 📬.
When the SMTP server accepts a message for relaying or final delivery, it adds a trace record (also called a "time stamp line" or "Received" line) at the top of the mail data ⏰. This trace record shows who sent the message, which host received it (and is adding this time stamp), and the date and time it was received. Relayed messages end up with multiple time stamp lines 🧾. The details for forming these lines, including their syntax, are in Section 4.4 🎀.
There's more about how DATA works in Section 3.3 📚.
Syntax:
data = "DATA" CRLF4.1.1.5. RESET (RSET) 🧼
This command says the current mail transaction gets aborted 🙅♀️. Any stored sender, recipients, and mail data MUST be discarded, and all buffers and state tables get cleared 🫧. The receiver MUST send a "250 OK" reply to an RSET command with no arguments 💖. A reset command can be sent by the client at any time. It's effectively the same as a NOOP (aka it does nothing) if sent right after EHLO, before EHLO has been issued in the session, after an end of data indicator has been sent and acknowledged, or right before a QUIT ✨. An SMTP server MUST NOT close the connection because it got an RSET 🚪. Only QUIT gets to do that (see Section 4.1.1.10) 👑.
Since EHLO involves extra processing and a response from the server, RSET is usually more efficient than sending that command again 🏃♀️, even though the formal semantics are the same 💅.
Sometimes, against what this spec intends, an SMTP server might get word that the underlying TCP connection was closed or reset 😱. To keep the mail system robust, SMTP servers SHOULD be ready for this and SHOULD treat it as if a QUIT had been received before the connection disappeared 🛡️.
Syntax:
rset = "RSET" CRLF4.1.1.6. VERIFY (VRFY) 🔍
This command asks the receiver to confirm that the argument identifies a user or mailbox 🕵️♀️. If it's a user name, the info comes back as specified in Section 3.5 💁♀️.
This command has no effect on the reverse-path buffer, the forward-path buffer, or the mail data buffer 🌸.
Syntax:
vrfy = "VRFY" SP String CRLF4.1.1.7. EXPAND (EXPN) 📜
This command asks the receiver to confirm that the argument identifies a mailing list and, if it does, to return the membership of that list 📋. If the command works, a reply comes back with info as described in Section 3.5. This reply will have multiple lines, except in the trivial case of a one-member list 🧚.
This command has no effect on the reverse-path buffer, the forward-path buffer, or the mail data buffer, and it can be sent at any time ⭐.
Syntax:
expn = "EXPN" SP String CRLF4.1.1.8. HELP (HELP) 🆘
This command makes the server send helpful info to the client 🦋. The command MAY take an argument (e.g., any command name) and return more specific info as a response 💜.
This command has no effect on the reverse-path buffer, the forward-path buffer, or the mail data buffer, and it can be sent at any time 🌈.
SMTP servers SHOULD support HELP without arguments and MAY support it with arguments 🫶.
Syntax:
help = "HELP" [ SP String ] CRLF4.1.1.9. NOOP (NOOP) 😴
This command doesn't change any parameters or previously entered commands 🫠. It does nothing except make the receiver send a "250 OK" reply ✅.
This command has no effect on the reverse-path buffer, the forward-path buffer, or the mail data buffer, and it can be sent at any time 🍓. If a parameter string is given, servers SHOULD ignore it 🙈.
Syntax:
noop = "NOOP" [ SP String ] CRLF4.1.1.10. QUIT (QUIT) 👋
This command says the receiver MUST send a "221 OK" reply, and then close the transmission channel 💋.
The receiver MUST NOT intentionally close the transmission channel until it receives and replies to a QUIT command (even if there was an error) 🚫. The sender MUST NOT intentionally close the transmission channel until it sends a QUIT command, and it SHOULD wait until it gets the reply (even if the previous command got an error response) 🥹. If the connection gets closed early because of the violations above, or because of system or network failure, the server MUST cancel any pending transaction, but not undo any transaction that already completed. It generally MUST act as if the command or transaction in progress got a temporary error (i.e., a 4yz response) 😭.
The QUIT command can be sent at any time, and any current uncompleted mail transaction gets aborted 🌷.
Syntax:
quit = "QUIT" CRLF4.1.1.11. Mail-Parameter and Rcpt-Parameter Error Responses 🚨
If the server SMTP doesn't recognize or can't implement one or more of the parameters attached to a particular MAIL FROM or RCPT TO command, it will return code 555 🙅♀️.
If, for some reason, the server is temporarily unable to accommodate one or more of the parameters attached to a MAIL FROM or RCPT TO command, and the definition of that specific parameter doesn't require a different code, it should return code 455 🕐.
Errors specific to particular parameters and their values will be specified in the parameter's defining RFC 📖✨.
4.1.2. Command Argument Syntax ✨
okay so this is where the commands finally get their arguments and we see exactly what's allowed in them 🎀 the grammar below uses the syntax from RFC 5234 [7] wherever it applies. Some of these productions only matter alongside source routes, which are covered in Appendix C 🧚. Terminals that aren't defined in this document, like ALPHA, DIGIT, SP, CR, LF, and CRLF, come from the "core" syntax in Section 6 of RFC 5234 [7] or from the message format syntax in RFC 5322 [4] 💅
Reverse-path = Path / "<>"
Forward-path = Path
Path = "<" [ A-d-l ":" ] Mailbox ">"
A-d-l = At-domain *( "," At-domain )
; Note that this form, the so-called "source
; route", MUST BE accepted, SHOULD NOT be
; generated, and SHOULD be ignored.
At-domain = "@" Domain
Mail-parameters = esmtp-param *(SP esmtp-param)
Rcpt-parameters = esmtp-param *(SP esmtp-param)
esmtp-param = esmtp-keyword ["=" esmtp-value]
esmtp-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
esmtp-value = 1*(%d33-60 / %d62-126)
; any CHAR excluding "=", SP, and control
; characters. If this string is an email address,
; i.e., a Mailbox, then the "xtext" syntax [32]
; SHOULD be used.
Keyword = Ldh-str
Argument = Atom
Domain = sub-domain *("." sub-domain)
sub-domain = Let-dig [Ldh-str]
Let-dig = ALPHA / DIGIT
Ldh-str = *( ALPHA / DIGIT / "-" ) Let-dig
address-literal = "[" ( IPv4-address-literal /
IPv6-address-literal /
General-address-literal ) "]"
; See Section 4.1.3
Mailbox = Local-part "@" ( Domain / address-literal )
Local-part = Dot-string / Quoted-string
; MAY be case-sensitive
Dot-string = Atom *("." Atom)
Atom = 1*atext
Quoted-string = DQUOTE *QcontentSMTP DQUOTE
QcontentSMTP = qtextSMTP / quoted-pairSMTP
quoted-pairSMTP = %d92 %d32-126
; i.e., backslash followed by any ASCII
; graphic (including itself) or SPace
qtextSMTP = %d32-33 / %d35-91 / %d93-126
; i.e., within a quoted string, any
; ASCII graphic or space is permitted
; without blackslash-quoting except
; double-quote and the backslash itself.
String = Atom / Quoted-stringokay so the Local-part rule is pretty permissive, but for the best interop, a host that expects to receive mail SHOULD avoid defining mailboxes where the Local-part needs (or uses) the Quoted-string form, or where the Local-part is case-sensitive 🙈 when you're generating or comparing Local-parts (say, to match a specific mailbox name), all quoted forms MUST be treated as equivalent, and the sending system SHOULD transmit the form that uses the minimum quoting possible 🫶
Systems MUST NOT define mailboxes in a way that requires SMTP to use non-ASCII characters (octets with the high order bit set to one) or ASCII "control characters" (decimal value 0-31 and 127). Those characters MUST NOT be used in MAIL or RCPT commands, or in other commands that need mailbox names. no thank you 🙅♀️
Quick backslash moment 🦋: the backslash, \, is a quote character, which means "the next character is literal, not its usual meaning." For example, "Joe\,Smith" is one single nine-character user name, with the comma sitting as the fourth character.
To keep things interoperable, and in line with the long-standing advice about being conservative with DNS naming (see Section 2.3.1 of the base DNS document, RFC 1035 [2]), characters outside letters, digits, and hyphen MUST NOT appear in domain name labels for SMTP clients or servers. The underscore especially is not allowed 💀 if an SMTP server gets a command with invalid character codes, and there's no other reason to reject it, it MUST reject that command with a 501 response. (This rule, like the others, could be overridden by appropriate SMTP extensions.) 💖
4.1.3. Address Literals ✨
sometimes a host isn't known to the domain name system, and communication (especially the communication you'd need to report and fix the problem) gets blocked 😭 to get around that, there's a special literal form of the address that works as an alternative to a domain name. For IPv4, it's four small decimal integers separated by dots and wrapped in brackets, like [123.255.37.2], which names an (IPv4) Internet Address in sequence-of-octets form. For IPv6 and any other addressing forms that might get standardized someday, the form is a standardized "tag" that identifies the address syntax, then a colon, then the address itself. The exact format comes from the relevant standards (for IPv6, that's RFC 4291 [8]). 🧚
Here's the breakdown:
IPv4-address-literal = Snum 3("." Snum)
IPv6-address-literal = "IPv6:" IPv6-addr
General-address-literal = Standardized-tag ":" 1*dcontent
Standardized-tag = Ldh-str
; Standardized-tag MUST be specified in a
; Standards-Track RFC and registered with IANA
dcontent = %d33-90 / ; Printable US-ASCII
%d94-126 ; excl. "[", "\", "]"
Snum = 1*3DIGIT
; representing a decimal integer
; value in the range 0 through 255
IPv6-addr = IPv6-full / IPv6-comp / IPv6v4-full / IPv6v4-comp
IPv6-hex = 1*4HEXDIG
IPv6-full = IPv6-hex 7(":" IPv6-hex)
IPv6-comp = [IPv6-hex *5(":" IPv6-hex)] "::"
[IPv6-hex *5(":" IPv6-hex)]
; The "::" represents at least 2 16-bit groups of
; zeros. No more than 6 groups in addition to the
; "::" may be present.
IPv6v4-full = IPv6-hex 5(":" IPv6-hex) ":" IPv4-address-literal
IPv6v4-comp = [IPv6-hex *3(":" IPv6-hex)] "::"
[IPv6-hex *3(":" IPv6-hex) ":"]
IPv4-address-literal
; The "::" represents at least 2 16-bit groups of
; zeros. No more than 4 groups in addition to the
; "::" and IPv4-address-literal may be present.4.1.4. Order of Commands ✨
okay this part is all about who has to show up first 👑 there are rules for the order these commands can be used in.
A session that will contain mail transactions MUST first be initialized with the EHLO command. An SMTP server SHOULD accept commands for non-mail transactions (like VRFY or EXPN) even without that initialization. 🎀
An EHLO command MAY be issued by a client later in the session. If it's issued after the session has begun and the server finds it acceptable, the SMTP server MUST clear all buffers and reset the state exactly as if an RSET command had been issued. So RSET followed right away by EHLO is redundant, but not harmful, apart from the performance cost of running unnecessary commands 🧹
If the EHLO command isn't acceptable to the SMTP server, failure replies of 501, 500, 502, or 550 MUST be returned as appropriate. After sending those replies, the SMTP server MUST stay in the same state it was in before the EHLO was received. 😤
The SMTP client MUST, if possible, make sure the domain parameter to the EHLO command is a primary host name, as specified for this command in Section 2.3.5. If that's not possible (for example, when the client's address is dynamically assigned and the client doesn't have an obvious name), an address literal SHOULD be substituted for the domain name. 🌸
An SMTP server MAY check that the domain name argument in the EHLO command actually matches the IP address of the client. However, if that check fails, the server MUST NOT refuse to accept a message on that basis. Anything captured during the check is for logging and tracing purposes only. Note that this prohibition only covers matching the parameter to its IP address. For a deeper dive into rejecting incoming connections or mail messages, see Section 7.9 💅
The NOOP, HELP, EXPN, VRFY, and RSET commands can be used at any time during a session, or without initializing a session first. SMTP servers SHOULD process these normally (meaning, not returning a 503 code), even if no EHLO command has been received yet. Clients SHOULD open a session with EHLO before sending these commands, though 🦋
If these rules are followed, then the example in RFC 821 that shows "550 access denied to you" in response to an EXPN command is incorrect, unless an EHLO command came before the EXPN, or the denial of access is based on the client's IP address or on other authentication or authorization-determining mechanisms. not it being messy 🙈
The MAIL command (or the obsolete SEND, SOML, or SAML commands) begins a mail transaction. Once started, a mail transaction consists of a transaction beginning command, one or more RCPT commands, and a DATA command, in that order. A mail transaction can be aborted by the RSET, a new EHLO, or the QUIT command. There can be zero or more transactions in a session. MAIL (or SEND, SOML, or SAML) MUST NOT be sent if a mail transaction is already open. It should only be sent if no mail transaction has been started in the session, or if the previous one successfully concluded with a successful DATA command, or if the previous one was aborted (for example, with a RSET or a new EHLO). 🔥
If the transaction beginning command's argument isn't acceptable, a 501 failure reply MUST be returned, and the SMTP server MUST stay in the same state. If the commands in a transaction are out of order to the point that the server can't process them, a 503 failure reply MUST be returned, and the SMTP server MUST stay in the same state. 😭
The last command in a session MUST be the QUIT command. The client SMTP SHOULD use the QUIT command to request that the connection be closed, even when no session opening command was sent and accepted. bye bye 👋💜
4.1.5. Private-Use Commands ✨
as specified in Section 2.2.2, commands starting with "X" can be used by bilateral agreement between the client (sending) and server (receiving) SMTP agents 🧚 an SMTP server that doesn't recognize such a command is expected to reply with "500 Command not recognized". An extended SMTP server MAY list the feature names associated with these private commands in its response to the EHLO command. 🌈
Commands sent or accepted by SMTP systems that don't start with "X" MUST conform to the requirements of Section 2.2.2. ✨
4.2. SMTP Replies ✨
Okay so replies are how the server and client stay in sync 🫶 Every command MUST generate exactly one reply, no exceptions, bestie. That's how the client always knows what state the server is in 💅
The whole command-reply dance is explained in Section 4.3 🎀
An SMTP reply is a three-digit number (sent as three numeric characters) followed by some text, unless this document says otherwise 🌸 The number is for machines to figure out what state to jump to next, and the text is for the humans 🦋 The three digits hold enough info that the client doesn't even need to read the text. It can toss it or show it to the user, whatever fits 💖 Exceptions are noted elsewhere in the doc, and the big ones are 220, 221, 251, 421, and 551. Those come with message text that machines actually have to parse and interpret 😭 In general the text can depend on the receiver and the context, so yeah, you'll probably see different texts for the same code 🙈 The theory behind reply codes is in Section 4.2.1. Formally, a reply is a three-digit code, <SP>, one line of text, and <CRLF>, or a multiline reply (same section). Since the text sometimes just doesn't get sent, which goes against this spec, clients that don't receive it SHOULD be ready to process the code alone, with or without a trailing space character 💅 Only EHLO, EXPN, and HELP are expected to give multiline replies in normal circumstances. Multiline replies are allowed for any command though ✨
In ABNF, server responses look like this:
Greeting = ( "220 " (Domain / address-literal)
[ SP textstring ] CRLF ) /
( "220-" (Domain / address-literal)
[ SP textstring ] CRLF
*( "220-" [ textstring ] CRLF )
"220" [ SP textstring ] CRLF )
textstring = 1*(%d09 / %d32-126) ; HT, SP, Printable US-ASCII
Reply-line = *( Reply-code "-" [ textstring ] CRLF )
Reply-code [ SP textstring ] CRLF
Reply-code = %x32-35 %x30-35 %x30-39"Greeting" only shows up in the 220 response that announces the server is opening its part of the connection. Any other server responses on connect follow the Reply-line syntax 🧚
An SMTP server SHOULD send only the reply codes listed in this document. It SHOULD also use the text shown in the examples whenever that makes sense 🍓
An SMTP client MUST determine its actions only by the reply code, not by the text. The exceptions are the "change of address" 251 and 551 replies and, if needed, 220, 221, and 421 replies 👑 In general, any text is fine, including no text at all. Senders SHOULD NOT send bare codes, but if they do, it MUST be acceptable 💅 The space after the reply code counts as part of the text. Whenever possible, a receiver-SMTP SHOULD test the first digit (the severity indication) of the reply code 🔥
The list of codes below MUST NOT be treated as permanent. New codes should be a rare and big deal, and extra info in the text part is preferred. But new codes can still show up through new Standards or Standards-Track specs 🌈 So a sender-SMTP MUST be prepared to handle codes that aren't in this document, and it MUST do that by only looking at the first digit 🫶
Unless extensions were negotiated with the client, SMTP servers MUST NOT send reply codes whose first digits are anything other than 2, 3, 4, or 5 🙅 Clients that get those out-of-range codes SHOULD normally treat them as fatal errors and end the mail transaction 💀
4.2.1. Reply Code Severities and Theory
Each of the three digits in a reply means something special 🔮 The first digit tells you if the response is good, bad, or incomplete. A simple SMTP client, or one that gets an unexpected code, can figure out its next move (carry on as planned, redo it, back off, etc.) just by checking that first digit 🌸 A client that wants to know roughly what kind of error happened (like a mail system error or a command syntax error) can look at the second digit. The third digit, plus any extra info that's there, is for the finest level of detail ✨
There are four possible values for the first digit:
2yzPositive Completion reply: The requested action was completed successfully. A new request may be started 🎉3yzPositive Intermediate reply: The command was accepted, but the action is on hold until more info arrives. The SMTP client should send another command that gives that info. This reply is used in command sequence groups (i.e., inDATA) 🧁4yzTransient Negative Completion reply: The command wasn't accepted and the action didn't happen. The error is temporary though, so the action can be requested again. The sender should go back to the start of the command sequence (if there is one). "Transient" is tricky, since two different sites (the receiver and sender SMTP agents) have to agree on what it means 🤔 Each reply in this group might have a different wait time, but the SMTP client SHOULD try again. A rule of thumb for telling 4yz apart from 5yz is this: replies are 4yz if they could succeed when repeated with no change in the command's form or in the properties of the sender or receiver. That means the command gets repeated exactly the same way, and the receiver hasn't put up a new implementation 🦋5yzPermanent Negative Completion reply: The command wasn't accepted and the action didn't happen. The SMTP client SHOULD NOT repeat the exact same request (in the same sequence). Some "permanent" errors can still be fixed, though, so the human user might want to restart the command sequence later on purpose, like after fixing a spelling or changing their account status 😭
It's worth knowing that the file transfer protocol (FTP) [34] uses a super similar code structure, and the SMTP codes are based on the FTP model. But SMTP does one command and one response at a time (FTP is asynchronous), and FTP's 1yz codes aren't part of the SMTP model 🙅♀️
The second digit sorts responses into specific categories:
x0zSyntax: These replies cover syntax errors, syntactically correct commands that don't fit any functional category, and unimplemented or superfluous commands 🙈x1zInformation: These are replies to requests for info, like status or help 💜x2zConnections: These replies are about the transmission channel 🌈x3zUnspecified. 🫥x4zUnspecified. 🫥x5zMail system: These replies show the status of the receiver's mail system in relation to the requested transfer or other mail system action 📬
The third digit gives a finer level of meaning inside each category set by the second digit. The reply list shows how this works 🎀 Each reply text is recommended, not mandatory, and it can even change depending on the command it's attached to 🍓 But the reply codes themselves must strictly follow the rules in this section. Receiver implementations should not invent new codes for slightly different situations from the ones described here. They should adapt the codes that are already defined instead 🧚
For example, a command like NOOP, which doesn't give the SMTP client any new info when it succeeds, returns a 250 reply. The reply is 502 when the command asks for an unimplemented action that isn't site-specific. And if the command is implemented but asks for an unimplemented parameter, you get the 504 reply, which is a more specific version of that ✨
Reply text can be longer than one line, and in that case the full text has to be marked so the SMTP client knows when to stop reading. This needs a special format for multiline replies 🌸
The multiline format says that every line except the last one starts with the reply code, immediately followed by a hyphen, "-" (also known as minus), and then the text. The last line starts with the reply code, immediately followed by <SP>, then optionally some text, and then <CRLF>. As mentioned above, servers SHOULD send the <SP> if no subsequent text is sent, but clients MUST be prepared for it to be left out 🫶
For example:
250-First line
250-Second line
250-234 Text beginning with numbers
250 The last lineIn a multiline reply, the reply code on every line MUST be the same. The client can rely on this, so it can make decisions based on the code from any line, knowing the rest will match 🔥 In a few cases there's important data in the reply "text" for the client. The client can tell when that's happening from the current context 💖
4.2.2. Reply Codes by Function Groups
Here's the reply list, grouped by function. Remember, the texts are recommendations 💅
500Syntax error, command unrecognized (this may include errors such as command line too long) 🙈501Syntax error in parameters or arguments 🙈502Command not implemented (see Section 4.2.4) 🙅503Bad sequence of commands 🙅♀️504Command parameter not implemented 🙅211System status, or system help reply 💜214Help message (information on how to use the receiver or the meaning of a particular non-standard command; this reply is useful only to the human user) 🧁220<domain>Service ready 🎀221<domain>Service closing transmission channel 👋421<domain>Service not available, closing transmission channel (this may be a reply to any command if the service knows it must shut down) 💀250Requested mail action okay, completed ✨251User not local; will forward to<forward-path>(See Section 3.4) 🦋252Cannot VRFY user, but will accept message and attempt delivery (See Section 3.5.3) 🌈455Server unable to accommodate parameters 😭555MAIL FROM/RCPT TO parameters not recognized or not implemented 💀450Requested mail action not taken: mailbox unavailable (e.g., mailbox busy or temporarily blocked for policy reasons) 🫥550Requested action not taken: mailbox unavailable (e.g., mailbox not found, no access, or command rejected for policy reasons) 🚫451Requested action aborted: error in processing 😭551User not local; please try<forward-path>(See Section 3.4) 🦋452Requested action not taken: insufficient system storage 📦552Requested mail action aborted: exceeded storage allocation 📦553Requested action not taken: mailbox name not allowed (e.g., mailbox syntax incorrect) 🙅354Start mail input; end with<CRLF>.<CRLF>📝554Transaction failed (or, in the case of a connection-opening response, "No SMTP service here") 💀
4.2.3. Reply Codes in Numeric Order ✨
okay bestie, here's the whole reply code lineup sorted by number so you can find any code fast 🧚💅
211 System status, or system help reply
214 Help message (Information on how to use the receiver or the
meaning of a particular non-standard command; this reply is useful
only to the human user)
220 <domain> Service ready
221 <domain> Service closing transmission channel
250 Requested mail action okay, completed
251 User not local; will forward to <forward-path> (See Section 3.4)
252 Cannot VRFY user, but will accept message and attempt delivery
(See Section 3.5.3)
354 Start mail input; end with <CRLF>.<CRLF>
421 <domain> Service not available, closing transmission channel
(This may be a reply to any command if the service knows it must
shut down)
450 Requested mail action not taken: mailbox unavailable (e.g.,
mailbox busy or temporarily blocked for policy reasons)
451 Requested action aborted: local error in processing
452 Requested action not taken: insufficient system storage
455 Server unable to accommodate parameters
500 Syntax error, command unrecognized (This may include errors such
as command line too long)
501 Syntax error in parameters or arguments
502 Command not implemented (see Section 4.2.4)
503 Bad sequence of commands
504 Command parameter not implemented
550 Requested action not taken: mailbox unavailable (e.g., mailbox
not found, no access, or command rejected for policy reasons)
551 User not local; please try <forward-path> (See Section 3.4)
552 Requested mail action aborted: exceeded storage allocation
553 Requested action not taken: mailbox name not allowed (e.g.,
mailbox syntax incorrect)
554 Transaction failed (Or, in the case of a connection-opening
response, "No SMTP service here")
555 MAIL FROM/RCPT TO parameters not recognized or not implemented4.2.4. Reply Code 502 🙈
people keep asking when 502 (Command not implemented) SHOULD be returned instead of the other codes, so here's the deal. 502 SHOULD be used when the server actually recognizes the command but doesn't implement it. If the command isn't recognized at all, code 500 SHOULD be returned instead. Extended SMTP systems MUST NOT list capabilities in response to EHLO for which they will return 502 (or 500) replies, so don't advertise something you'll then reject 💅
4.2.5. Reply Codes after DATA and the Subsequent <CRLF>.<CRLF> 📬
okay so when an SMTP server sends a positive completion status (2yz code) after the DATA command finishes with <CRLF>.<CRLF>, it takes on responsibility for:
- delivering the message (if the recipient mailbox exists), or
- if attempts to deliver the message fail due to transient conditions, retrying delivery some reasonable number of times at intervals as specified in Section 4.5.4.
- if attempts to deliver the message fail due to permanent conditions, or if repeated attempts to deliver the message fail due to transient conditions, returning appropriate notification to the sender of the original message (using the address in the SMTP MAIL command).
now the temporary error case 🥺 when an SMTP server returns a temporary error status (4yz) code after the DATA command finishes with <CRLF>.<CRLF>, it MUST NOT make a subsequent attempt to deliver that message. The SMTP client is still responsible for that message and can either hand it back to the user or requeue it for another try (see Section 4.5.4.1).
the person who sent the message SHOULD be able to read a transient failure status (by mail message or otherwise) as a non-delivery indication, the same way they'd read a permanent failure. If the client SMTP handles these conditions successfully, the user won't get such a reply ✨
and the permanent error case 💀 when an SMTP server returns a permanent error status (5yz) code after the DATA command finishes with <CRLF>.<CRLF>, it MUST NOT make any subsequent attempt to deliver the message. Just like with temporary error codes, the SMTP client keeps responsibility for the message, but it SHOULD not again attempt delivery to the same server without user review of the message and response and appropriate intervention.
4.3. Sequencing of Commands and Replies 🎀
4.3.1. Sequencing Overview
so the sender and receiver basically take turns in a dialogue, and the sender is the one running the show 👑 the sender sends a command and the receiver answers with a reply. Unless other arrangements are negotiated through service extensions, the sender MUST wait for that response before sending anything else. One super important reply is the connection greeting. Normally, a receiver sends a 220 "Service ready" reply once the connection is completed. The sender SHOULD wait for this greeting before sending any commands.
note: every greeting-type reply has the official name (the fully-qualified primary domain name) of the server host as the first word after the reply code. Sometimes the host doesn't have a meaningful name, so see Section 4.1.3 for a discussion of alternatives in those situations 🫶
for example,
220 ISIF.USC.EDU Service readyor
220 mail.example.com SuperSMTP v 6.1.2 Service readyor
220 [10.0.0.1] Clueless host service readythe table below lists the alternative success and failure replies for each command. These SHOULD be strictly adhered to 🔥 A receiver MAY substitute text in the replies, but the meanings and actions implied by the code numbers and by the specific command reply sequence MUST be preserved.
4.3.2. Command-Reply Sequences 🌈
each command comes with its usual possible replies. The prefixes used in front of them are "I" for intermediate, "S" for success, and "E" for error. Some servers may send other replies under special circumstances, and the codes need to leave room for future extension, so SMTP clients SHOULD, when possible, interpret only the first digit of the reply, and MUST be prepared to deal with unrecognized reply codes by interpreting the first digit only. Unless extended using the mechanisms described in Section 2.2, SMTP servers MUST NOT transmit reply codes to an SMTP client that are other than three digits or that do not start in a digit between 2 and 5 inclusive.
these sequencing rules, and in principle the codes too, can be extended or modified by SMTP extensions that the server offers and the client accepts (requests). However, if the goal is more precise granularity in the codes, rather than codes for totally new purposes, the system described in RFC 3463 [25] SHOULD be used in preference to inventing new codes 💖
in addition to the codes listed below, any SMTP command can return any of the following codes if the matching unusual circumstances come up:
500: for the "command line too long" case or if the command name wasn't recognized. Producing a "command not recognized" error in response to the required subset of these commands is a violation of this specification. Similarly, producing a "command too long" message for a command line shorter than 512 characters would violate the provisions of Section 4.5.3.1.4.501: syntax error in the command or its arguments. To leave room for future extensions, commands that this document specifies as not accepting arguments (DATA, RSET, QUIT) SHOULD return a501message if arguments are supplied when no EHLO-advertised extensions are present.421: service shutting down and closing the transmission channel.
now the specific sequences, bestie 📋
CONNECTION ESTABLISHMENT
S: 220
E: 554
EHLO or HELO
S: 250
E: 504 (a conforming implementation could return this code only
in fairly obscure cases), 550, 502 (permitted only with an old-
style server that does not support EHLO)
MAIL
S: 250
E: 552, 451, 452, 550, 553, 503, 455, 555
RCPT
S: 250, 251 (but see Section 3.4 for discussion of 251 and 551)
E: 550, 551, 552, 553, 450, 451, 452, 503, 455, 555
DATA
I: 354 -> data -> S: 250
E: 552, 554, 451, 452
E: 450, 550 (rejections for policy reasons)
E: 503, 554
RSET
S: 250
VRFY
S: 250, 251, 252
E: 550, 551, 553, 502, 504
EXPN
S: 250, 252
E: 550, 500, 502, 504
HELP
S: 211, 214
E: 502, 504
NOOP
S: 250
QUIT
S: 2214.4. Trace Information 🦋
okay bestie, this is where a message gets its receipts 🧾✨ When an SMTP server receives a message for delivery or further processing, it MUST insert trace ("time stamp" or "Received") information at the beginning of the message content, as discussed in Section 4.1.1.4.
This line MUST be structured as follows:
- The FROM clause, which MUST be supplied in an SMTP environment, SHOULD contain both (1) the name of the source host as presented in the EHLO command and (2) an address literal containing the IP address of the source, determined from the TCP connection.
- The ID clause MAY contain an "@" as suggested in RFC 822, but this is not required.
- If the FOR clause appears, it MUST contain exactly one
<path>entry, even when multiple RCPT commands have been given. Multiple<path>s raise some security issues and have been deprecated, see Section 7.2.
An Internet mail program MUST NOT change or delete a Received: line that was previously added to the message header section. SMTP servers MUST prepend Received lines to messages; they MUST NOT change the order of existing lines or insert Received lines in any other location. Hands off the receipts, no edits, no shuffling! 🙅♀️
As the Internet grows, comparing Received header fields gets more important for spotting problems, especially slow relays 🐢 SMTP servers that create Received header fields SHOULD use explicit offsets in the dates (e.g., -0800), rather than time zone names of any type. Local time (with an offset) SHOULD be used rather than UT when feasible. This format carries a bit more info about local circumstances. If UT is needed, the receiver just does some simple arithmetic to convert the values. Using UT loses information about the time zone-location of the server. If you want to supply a time zone name, it SHOULD be included in a comment. 🌍
When the delivery SMTP server makes the "final delivery" of a message, it inserts a return-path line at the beginning of the mail data. This use of return-path is required; mail systems MUST support it. The return-path line preserves the information in the <reverse-path> from the MAIL command. Here, final delivery means the message has left the SMTP environment. Normally that means it was delivered to the destination user or an associated mail drop, but sometimes it gets further processed and transmitted by another mail system. 📬
The mailbox in the return path can be different from the actual sender's mailbox. For example, error responses might go to a special error handling mailbox instead of the message sender. This is super common with mailing lists, where errors get sent to the list maintainer instead of the message originator. Iconic routing 👑
The text above implies that the final mail data will begin with a return path line, followed by one or more time stamp lines. Those lines are followed by the rest of the mail data: first the balance of the mail header section, then the body (RFC 5322 [4]). 💌
It can be tricky for an SMTP server to tell whether it's making final delivery, since forwarding or other operations may happen after the message is accepted for delivery. So any further (forwarding, gateway, or relay) systems MAY remove the return path and rebuild the MAIL command as needed, to make sure exactly one such line shows up in a delivered message. 🔁
A message-originating SMTP system SHOULD NOT send a message that already contains a Return-path header field. SMTP servers performing a relay function MUST NOT inspect the message data, and especially not to the extent needed to determine whether Return-path header fields are present. SMTP servers making final delivery MAY remove Return-path header fields before adding their own. 🙈
The main purpose of the Return-path is to name the address where non-delivery notices and other mail system failures should go 💌 For that to be unambiguous, exactly one return path SHOULD be present when the message is delivered. Systems using RFC 822 syntax with non-SMTP transports SHOULD designate an unambiguous address, tied to the transport envelope, where error reports (e.g., non-delivery messages) should be sent.
Historical note: text in RFC 822 that seems to contradict using the Return-path header field (or the envelope reverse-path address from the MAIL command) as the destination for error messages doesn't apply on the Internet. The reverse-path address (as copied into the Return-path) MUST be used as the target of any mail containing delivery error messages. 🕰️
In particular:
- a gateway from SMTP -> elsewhere SHOULD insert a return-path header field, unless it is known that the "elsewhere" transport also uses Internet domain addresses and maintains the envelope sender address separately.
- a gateway from elsewhere -> SMTP SHOULD delete any return-path header field present in the message, and either copy that information to the SMTP envelope or combine it with information present in the envelope of the other transport system to construct the reverse-path argument to the MAIL command in the SMTP envelope.
The server must give special treatment to cases where the processing after the end of mail data indication is only partially successful. This could happen if, after accepting several recipients and the mail data, the SMTP server finds the mail data can be delivered to some, but not all, of the recipients. In those cases, the response to the DATA command MUST be an OK reply. However, the SMTP server MUST compose and send an "undeliverable mail" notification message to the originator of the message. 😬
A single notification listing all of the failed recipients, or separate notification messages for each failed recipient, MUST be sent. For economy of processing by the sender, the former SHOULD be used when possible. The key difference between handling aliases (Section 3.9.1) and forwarding (this subsection) is the change to the backward-pointing address in this case. All notification messages about undeliverable mail MUST be sent using the MAIL command (even if they result from processing the obsolete SEND, SOML, or SAML commands), and MUST use a null return path as discussed in Section 3.6. 📨
The time stamp line and the return path line are formally defined as follows (the definitions for "FWS" and "CFWS" appear in RFC 5322 [4]):
Return-path-line = "Return-Path:" FWS Reverse-path <CRLF>
Time-stamp-line = "Received:" FWS Stamp <CRLF>
Stamp = From-domain By-domain Opt-info [CFWS] ";"
FWS date-time
; where "date-time" is as defined in RFC 5322 [4]
; but the "obs-" forms, especially two-digit
; years, are prohibited in SMTP and MUST NOT be used.
From-domain = "FROM" FWS Extended-Domain
By-domain = CFWS "BY" FWS Extended-Domain
Extended-Domain = Domain /
( Domain FWS "(" TCP-info ")" ) /
( address-literal FWS "(" TCP-info ")" )
TCP-info = address-literal / ( Domain FWS address-literal )
; Information derived by server from TCP connection
; not client EHLO.
Opt-info = [Via] [With] [ID] [For]
[Additional-Registered-Clauses]
Via = CFWS "VIA" FWS Link
With = CFWS "WITH" FWS Protocol
ID = CFWS "ID" FWS ( Atom / msg-id )
; msg-id is defined in RFC 5322 [4]
For = CFWS "FOR" FWS ( Path / Mailbox )
Additional-Registered-Clauses = CFWS Atom FWS String
; Additional standard clauses may be
added in this
; location by future standards and
registration with
; IANA. SMTP servers SHOULD NOT use
unregistered
; names. See Section 8.
Link = "TCP" / Addtl-Link
Addtl-Link = Atom
; Additional standard names for links are
; registered with the Internet Assigned Numbers
; Authority (IANA). "Via" is primarily of value
; with non-Internet transports. SMTP servers
; SHOULD NOT use unregistered names.
Protocol = "ESMTP" / "SMTP" / Attdl-Protocol
Attdl-Protocol = Atom
; Additional standard names for protocols are
; registered with the Internet Assigned Numbers
; Authority (IANA) in the "mail parameters"
; registry [9]. SMTP servers SHOULD NOT
; use unregistered names.4.5. Additional Implementation Issues 🛠️
4.5.1. Minimum Implementation
To make SMTP workable, the following minimum implementation MUST be provided by all receivers. The following commands MUST be supported to conform to this specification:
EHLO
HELO
MAIL
RCPT
DATA
RSET
NOOP
QUIT
VRFYAny system that includes an SMTP server supporting mail relaying or delivery MUST support the reserved mailbox "postmaster" as a case-insensitive local name. This postmaster address isn't strictly necessary if the server always returns 554 on connection opening (as described in Section 3.1). The requirement to accept mail for postmaster means that RCPT commands specifying a mailbox for postmaster at any of the domains the SMTP server provides mail service for, as well as the special case of RCPT TO:<Postmaster> (with no domain specification), MUST be supported. 📮✨
SMTP systems are expected to make every reasonable effort to accept mail directed to Postmaster from any other system on the Internet. In extreme cases, such as containing a denial of service attack or another breach of security, an SMTP server may block mail directed to Postmaster. However, those arrangements SHOULD be narrowly tailored so they avoid blocking messages that aren't part of such attacks. Blocking the good mail along with the bad is a major vibe-killer 💔
4.5.2. Transparency ✨
Okay so, bestie, this is the drama 😭 Without some provision for data transparency, the sequence <CRLF>.<CRLF> ends the mail text, which means nobody can actually send it. Users don't know these "forbidden" sequences exist, so the fix is a little dance to let all user-typed text get through safely 💅
- Before sending a line of mail text, the SMTP client checks the first character of the line. If it is a period, one additional period is inserted at the beginning of the line.
- When a line of mail text is received by the SMTP server, it checks the line. If the line is composed of a single period, it is treated as the end of mail indicator. If the first character is a period and there are other characters on the line, the first character is deleted.
The mail data can have any of the 128 ASCII characters, and all of them are delivered to the recipient's mailbox, including spaces, vertical and horizontal tabs, and other control characters 🌈 If the transmission channel gives you an 8-bit byte (octet) data stream, the 7-bit ASCII codes are sent right justified in the octets, with the high-order bits cleared to zero. See Section 3.6 for the special treatment of these conditions in SMTP systems serving a relay function 🎀
In some systems, the data might need a makeover when it's received and stored 💖 This can happen for hosts that use a character set other than ASCII as their local one, hosts that store data in records instead of strings, or hosts that use special character sequences as delimiters inside mailboxes. If these transformations are needed, they MUST be reversible, especially if they are applied to mail being relayed. No cap, that part is non-negotiable 🫶
4.5.3. Sizes and Timeouts 🧚
4.5.3.1. Size Limits and Minimums 📏
There are several objects with required minimum and maximum sizes. Every implementation MUST be able to receive objects of at least these sizes. Objects larger than these sizes SHOULD be avoided when possible. Some Internet mail constructs, like encoded X.400 addresses (RFC 2156 [35]), will often need larger objects anyway. Clients MAY attempt to transmit these, but MUST be prepared for a server to reject them if they can't be handled by it. To the maximum extent possible, implementation techniques that impose no limits on the length of these objects should be used.
Extensions to SMTP may use characters that take up more than a single octet each 🍓 This section therefore specifies lengths in octets wherever absolute lengths, rather than character counts, are intended.
4.5.3.1.1. Local-part 💜
The maximum total length of a user name or other local-part is 64 octets.
4.5.3.1.2. Domain 🌸
The maximum total length of a domain name or number is 255 octets.
4.5.3.1.3. Path 🛤️
The maximum total length of a reverse-path or forward-path is 256 octets, including the punctuation and element separators.
4.5.3.1.4. Command Line ⌨️
The maximum total length of a command line, including the command word and the <CRLF>, is 512 octets. SMTP extensions may be used to increase this limit.
4.5.3.1.5. Reply Line 💬
The maximum total length of a reply line, including the reply code and the <CRLF>, is 512 octets. More information may be conveyed through multiple-line replies.
4.5.3.1.6. Text Line 📝
The maximum total length of a text line, including the <CRLF>, is 1000 octets (not counting the leading dot duplicated for transparency). This number may be increased by the use of SMTP Service Extensions.
4.5.3.1.7. Message Content 💌
The maximum total length of a message content, including any message header section as well as the message body, MUST BE at least 64K octets. Message lengths on the Internet have grown dramatically since the introduction of Internet Standards for multimedia mail (RFC 2045 [21]), so message size restrictions should be avoided if at all possible. SMTP server systems that must impose restrictions SHOULD implement the "SIZE" service extension of RFC 1870 [10], and SMTP client systems that will send large messages SHOULD utilize it when possible 📦
4.5.3.1.8. Recipients Buffer 👯
The minimum total number of recipients that MUST be buffered is 100 recipients. Rejecting messages for having too many recipients when there are fewer than 100 RCPT commands is a violation of this specification 🚫 The general principle that relaying SMTP server MUST NOT, and delivery SMTP servers SHOULD NOT, perform validation tests on message header fields suggests that messages SHOULD NOT be rejected based on the total number of recipients shown in header fields. A server that imposes a limit on the number of recipients MUST behave in an orderly fashion, such as rejecting additional addresses over its limit rather than silently discarding addresses it already accepted. A client that needs to deliver a message containing over 100 RCPT commands SHOULD be prepared to transmit in 100-recipient "chunks" if the server declines to accept more than 100 recipients in a single message. Chunk it up, girl 💅
4.5.3.1.9. Treatment When Limits Exceeded 🚨
Errors due to exceeding these limits may be reported using the reply codes. Some examples of reply codes are:
500 Line too long.or
501 Path too longor
452 Too many recipients (see below)or
552 Too much mail data.4.5.3.1.10. Too Many Recipients Code 🙈
Okay, tea time! ☕ RFC 821 [1] incorrectly listed the error where an SMTP server runs out of its implementation limit on the number of RCPT commands ("too many recipients") as having reply code 552. The correct reply code for this condition is 452. Clients SHOULD treat a 552 code in this case as a temporary, rather than permanent, failure so the logic below works.
When a conforming SMTP server hits this condition, it has at least 100 successful RCPT commands in its recipients buffer. If the server is able to accept the message, then at least these 100 addresses will be removed from the SMTP client's queue. When the client retries the addresses that got 452 responses, at least 100 of them will fit in the SMTP server's recipients buffer. Each retransmission attempt that is able to deliver anything will be able to dispose of at least 100 of these recipients. The cycle is giving "keep going until everyone's delivered" 🔁✨
If an SMTP server has an implementation limit on the number of RCPT commands and this limit is exhausted, it MUST use a response code of 452 (but the client SHOULD also be prepared for a 552, as noted above). If the server has a configured site-policy limitation on the number of RCPT commands, it MAY instead use a 5yz response code. In particular, if the intent is to prohibit messages with more than a site-specified number of recipients, rather than merely limit the number of recipients in a given mail transaction, it would be reasonable to return a 503 response to any DATA command received after the 452 (or 552) code, or to simply return the 503 after DATA without returning any previous negative response 🧐
4.5.3.2. Timeouts ⏰
An SMTP client MUST provide a timeout mechanism. It MUST use per-command timeouts rather than trying to time the entire mail transaction somehow. Timeouts SHOULD be easily reconfigurable, preferably without recompiling the SMTP code. To implement this, a timer is set for each SMTP command and for each buffer of the data transfer. The latter means that the overall timeout is inherently proportional to the size of the message, which is honestly so logical 🥹
Based on extensive experience with busy mail-relay hosts, the minimum per-command timeout values SHOULD be as follows:
4.5.3.2.1. Initial 220 Message: 5 Minutes 👋
An SMTP client process needs to tell the difference between a failed TCP connection and a delay in receiving the initial 220 greeting message. Many SMTP servers accept a TCP connection but hold off on delivering the 220 message until their system load allows more mail to be processed.
4.5.3.2.2. MAIL Command: 5 Minutes 📨
4.5.3.2.3. RCPT Command: 5 Minutes 📬
A longer timeout is required if processing of mailing lists and aliases is not deferred until after the message was accepted.
4.5.3.2.4. DATA Initiation: 2 Minutes 🚪
This is while awaiting the "354 Start Input" reply to a DATA command.
4.5.3.2.5. Data Block: 3 Minutes 🧱
This is while awaiting the completion of each TCP SEND call transmitting a chunk of data.
4.5.3.2.6. DATA Termination: 10 Minutes. 🫡
This is while awaiting the "250 OK" reply. When the receiver gets the final period ending the message data, it typically does processing to deliver the message to a user mailbox. A spurious timeout at this point would be very wasteful and would typically result in delivery of multiple copies of the message, since it has been successfully sent and the server has accepted responsibility for delivery. See Section 6.1 for additional discussion.
4.5.3.2.7. Server Timeout: 5 Minutes. 🛎️
An SMTP server SHOULD have a timeout of at least 5 minutes while it is awaiting the next command from the sender.
4.5.4. Retry Strategies 🔄
The common structure of a host SMTP implementation includes user mailboxes, one or more areas for queuing messages in transit, and one or more daemon processes for sending and receiving mail. The exact structure will vary depending on the needs of the users on the host and the number and size of mailing lists the host supports. We describe several optimizations that have proved helpful, particularly for mailers supporting high traffic levels 🚀
Any queuing strategy MUST include timeouts on all activities on a per-command basis. A queuing strategy MUST NOT send error messages in response to error messages under any circumstances. Never send an error about an error, periodt 💀🎀
4.5.4.1. Sending Strategy 🚀
okay so the general model for an SMTP client is one or more processes that keep popping up to try sending outgoing mail 💌. In a typical system, the program that composes a message has a way to say "hey, this one needs attention NOW" 🙈. Mail that can't go out right away MUST be queued and periodically retried by the sender 💅. A mail queue entry holds not just the message but also the envelope information ✨.
The sender MUST delay retrying a particular destination after one attempt has failed 🫶. In general, the retry interval SHOULD be at least 30 minutes. Tho more sophisticated and variable strategies are gonna be beneficial when the SMTP client can figure out why delivery didn't work 🧠.
Retries keep going until the message gets transmitted or the sender gives up 🥹. The give-up time generally needs to be at least 4-5 days, no cap 📅. It MAY be appropriate to set a shorter maximum number of retries for non-delivery notifications and equivalent error messages than for standard messages. The parameters to the retry algorithm MUST be configurable 🎀.
A client SHOULD keep a list of hosts it can't reach, along with the matching connection timeouts 📋. That's way better than just retrying every queued mail item over and over, bestie 😭.
Experience suggests failures are usually transient (the target system or its connection has crashed) 💫. So the move is two connection attempts in the first hour the message is in the queue, then backing off to one every two or three hours ⏰. It's giving patience 🦋.
The SMTP client can shorten the queuing delay by working with the SMTP server 🤝. For example, if mail comes in from a particular address, it's likely that mail queued for that host can now be sent 📬. Using this principle can, in many cases, remove the need for an explicit "send queues now" function like ETRN, RFC 1985 [36] 🌸.
The strategy may be further tweaked because of multiple addresses per host (see below) so it balances delivery time against resource usage 💜.
An SMTP client may have a huge queue of messages for each unavailable destination host 😩. If all of those got retried in every retry cycle, there would be excessive Internet overhead, and the sending system would be blocked for ages 💀. Note that an SMTP client can usually only tell that a delivery attempt failed after a timeout of several minutes. Even a one-minute timeout per connection adds up to a very large delay if retries repeat for dozens, or even hundreds, of queued messages to the same host 🐢.
At the same time, SMTP clients SHOULD use great care in caching negative responses from servers 🧐. In an extreme case, if EHLO gets issued multiple times during the same SMTP connection, the server might send back different answers. More significantly, 5yz responses to the MAIL command MUST NOT be cached 🚫.
When a message is going to multiple recipients, and the SMTP server that a copy is headed to is the same for several of them, then only one copy of the message SHOULD be transmitted ✨. So the SMTP client SHOULD use the command sequence MAIL, RCPT, RCPT, ..., RCPT, DATA instead of MAIL, RCPT, DATA, ..., MAIL, RCPT, DATA 👑. Still, if there are very many addresses, a limit on the number of RCPT commands per MAIL command MAY be imposed 🌈. This efficiency feature SHOULD be implemented 💅.
Similarly, to get timely delivery, the SMTP client MAY support multiple concurrent outgoing mail transactions 🏃♀️. Some limit may be appropriate, though, so the host doesn't put all its resources into mail 🙃.
4.5.4.2. Receiving Strategy 📥
The SMTP server SHOULD try to keep a pending listen on the SMTP port (specified by IANA as port 25) at all times 🔊. This needs support for multiple incoming TCP connections for SMTP. Some limit MAY be imposed, but servers that can't handle more than one SMTP transaction at a time aren't in conformance with the intent of this specification 🙅♀️.
As we talked about above, when the SMTP server gets mail from a particular host address, it could activate its own SMTP queuing mechanisms to retry any mail pending for that host address 🔁💖.
4.5.5. Messages with a Null Reverse-Path 🫥
There are several kinds of notification messages that existing and proposed Standards require to be sent with a null reverse-path 🙈. These are non-delivery notifications (as discussed in Section 3.7), other kinds of Delivery Status Notifications (DSNs, RFC 3461 [32]), and Message Disposition Notifications (MDNs, RFC 3798 [37]). All of these are notifications about a previous message, and they get sent to the reverse-path of that previous mail message 📨. (If delivery of one of these notifications fails, that usually means something's up with the mail system of the host the notification is addressed to. That's why some hosts set up their MTA to forward failed notifications to someone who can fix the mail system, e.g., via the postmaster alias 🛠️.)
All other types of messages (aka any message that a Standards-Track RFC doesn't require to have a null reverse-path) SHOULD be sent with a valid, non-null reverse-path 💌.
Anyone building automated email processors needs to be careful that these null reverse-path messages get handled correctly 🤖. Specifically, such systems SHOULD NOT reply to messages with a null reverse-path, and they SHOULD NOT add a non-null reverse-path to such messages when forwarding, or change a null reverse-path to a non-null one 🚫🔁.
5. Address Resolution and Mail Handling ✨
5.1. Locating the Target Host 🗺️
Once an SMTP client lexically identifies a domain that mail will be delivered to for processing (as described in Sections 2.3.5 and 3.6), a DNS lookup MUST be performed to resolve the domain name (RFC 1035 [2]) 🔎. The names are expected to be fully-qualified domain names (FQDNs). Mechanisms for inferring FQDNs from partial names or local aliases are outside this specification 🙅♀️. Because of a history of problems, SMTP servers used for initial submission of messages SHOULD NOT make such inferences (Message Submission Servers [18] have somewhat more flexibility), and intermediate (relay) SMTP servers MUST NOT make them 🥲.
The lookup first tries to find an MX record for the name 🔍. If a CNAME record is found, the resulting name gets processed as if it were the initial name 🔁. If a non-existent domain error comes back, this situation MUST be reported as an error 🚨. If a temporary error comes back, the message MUST be queued and retried later (see Section 4.5.4.1) ⏳. If an empty list of MXs comes back, the address is treated as if it were associated with an implicit MX RR, with a preference of 0, pointing to that host 🧚. If MX records are present but none of them are usable, or the implicit MX is unusable, this situation MUST be reported as an error 💔.
If one or more MX RRs are found for a given name, SMTP systems MUST NOT utilize any address RRs associated with that name unless they're located using the MX RRs 🙅♀️. The "implicit MX" rule above only applies if there are no MX records present. If MX records are present but none of them are usable, this situation MUST be reported as an error 😤.
When a domain name associated with an MX RR gets looked up and its data field obtained, the data field of that response MUST contain a domain name 📛. That domain name, when queried, MUST return at least one address record (e.g., A or AAAA RR) that gives the IP address of the SMTP server the message should be directed to 📍. Any other response, specifically including a value that will return a CNAME record when queried, is outside the scope of this Standard 🙃. The prohibition on labels in the data that resolve to CNAMEs is discussed in more detail in RFC 2181, Section 10.3 [38] 📖.
When the lookup succeeds, the mapping can result in a list of alternative delivery addresses instead of a single address, because of multiple MX records, multihoming, or both 🌐. To provide reliable mail transmission, the SMTP client MUST be able to try (and retry) each of the relevant addresses in this list in order, until a delivery attempt succeeds 💪. There MAY also be a configurable limit on the number of alternate addresses that can be tried. Either way, the SMTP client SHOULD try at least two addresses ✌️.
Two types of information get used to rank the host addresses: multiple MX records, and multihomed hosts 🏆.
MX records contain a preference indication that MUST be used in sorting if more than one such record shows up (see below) 🎯. Lower numbers are more preferred than higher ones 📉. If there are multiple destinations with the same preference and there's no clear reason to favor one (e.g., by recognizing an easily reached address), then the sender-SMTP MUST randomize them to spread the load across multiple mail exchangers for a specific organization 🎲.
The destination host (perhaps taken from the preferred MX record) may be multihomed, in which case the domain name resolver returns a list of alternative IP addresses 🌍. It's the responsibility of the domain name resolver interface to have ordered this list by decreasing preference if needed, and the SMTP sender MUST try them in the order presented 📋.
Although the capability to try multiple alternative addresses is required, specific installations might want to limit or disable the use of alternative addresses 🙈. Whether a sender should retry using the different addresses of a multihomed host has been a big debate 🥊. The main argument for using multiple addresses is that it maximizes the chance of timely delivery, and sometimes the chance of any delivery at all 🎉. The counter-argument is that it may cause unnecessary resource use 🫠. Also, resource use is strongly determined by the sending strategy discussed in Section 4.5.4.1 💅.
If an SMTP server gets a message with a destination for which it is a designated Mail eXchanger, it MAY relay the message (potentially after rewriting the MAIL FROM and/or RCPT TO addresses), make final delivery of the message, or hand it off using some mechanism outside the SMTP-provided transport environment 📦. Of course, neither of the last two options requires that the list of MX records be examined any further 🙌.
If it decides to relay the message without rewriting the address, it MUST sort the MX records to figure out the candidates for delivery 🗂️. The records get ordered by preference first, with the lowest-numbered records being most preferred 🥇. The relay host MUST then inspect the list for any of the names or addresses by which it might be known in mail transactions 🔍. If a matching record is found, all records at that preference level and higher-numbered ones MUST be discarded from consideration 🗑️. If there are no records left at that point, it's an error condition, and the message MUST be returned as undeliverable 😭. If records do remain, they SHOULD be tried, best preference first, as described above 💖.
5.2. IPv6 and MX Records ✨
okay bestie, so on the modern internet, SMTP clients and servers can live on IPv4 systems, IPv6 systems, or dual-stack systems that handle either version of the Internet Protocol 💅. That means the host domains MX records point at might have "A RR"s (IPv4), "AAAA RR"s (IPv6), or any mix of the two 🦋.
RFC 3974 [39] shares some operational experience from mixed environments, but it wasn't thorough enough to justify standardization, and some of its recommendations seem to clash with this spec 🙈.
The right moves depend on local stuff, like how the relevant networks perform and any conversions that might be needed. Other times it's obvious, like how an IPv6-only client doesn't need to look up A RRs or try to reach IPv4-only servers 🌸.
Designers of SMTP implementations that might run in IPv6 or dual-stack environments should study the procedures above, especially the comments about multihomed hosts. They should also, preferably, provide mechanisms that make operational tuning and mail interoperability between IPv4 and IPv6 systems easier, while considering local circumstances 🫶.
6. Problem Detection and Handling 🔥
6.1. Reliable Delivery and Replies by Email 💌
okay so when the receiver-SMTP accepts a piece of mail (by sending a "250 OK" reply to DATA), it's basically promising to deliver or relay that message 🤝. It has to take that promise seriously. It MUST NOT lose the message for frivolous reasons, like because the host crashes later or because of a predictable resource shortage 😭. Some reasons that aren't considered frivolous are covered in the next subsection and in Section 7.8 ✨.
If a delivery fails after the message has been accepted, the receiver-SMTP MUST formulate and mail a notification message 📨. This notification MUST be sent using a null ("<>") reverse-path in the envelope. The recipient of this notification MUST be the address from the envelope return path (or the Return-Path: line). But if that address is null ("<>"), the receiver-SMTP MUST NOT send a notification 💀. Nothing in this section can or should stop local decisions (the same system environment as the receiver-SMTP) from logging or otherwise sending information about null address events locally if that's wanted 🌈. And if the address is an explicit source route, it MUST be stripped down to its final hop 💅.
here's an example: say an error notification needs to go out for a message that arrived with:
MAIL FROM:<@a,@b:user@d>The notification message MUST be sent using:
RCPT TO:<user@d>Some delivery failures after SMTP has accepted a message are just unavoidable 😩. For example, the receiving SMTP server might not be able to validate all the delivery addresses in the RCPT command(s) because of a "soft" domain system error, because the target is a mailing list (see the earlier discussion of RCPT), or because the server is acting as a relay and has no immediate access to the delivering system 🧚.
To avoid getting duplicate messages because of timeouts, a receiver-SMTP MUST seek to minimize the time it takes to respond to the final <CRLF>.<CRLF> end of data indicator ⏱️. See RFC 1047 [40] for a discussion of this problem 🎀.
6.2. Unwanted, Unsolicited, and "Attack" Messages 🚫
the whole point of the internet mail system is being useful and predictable 🌷. So messages that can be delivered should be delivered, no matter what syntax or other faults they have and no matter what their content is 💜. If they can't be delivered and the SMTP server couldn't reject them during the SMTP transaction, they should be "bounced" (sent back with non-delivery notification messages) like we described above 📬. But honestly? In today's world, lots of SMTP server operators have noticed that undesirable bulk email way outnumbers the mail people actually want 😵💫. And accepting a message can trigger even more unwanted traffic by confirming that the address is real. So those principles may not be practical anymore 💀.
As discussed in Section 7.8 and Section 7.9 below, dropping mail without telling the sender is allowed in practice. BUT it's extremely dangerous, and it goes against a long tradition and community expectations that mail is either delivered or returned 😱. If silent dropping gets misused, it could easily wreck confidence in how reliable the Internet's mail systems are. So silent dropping of messages should only be considered in cases where there's very high confidence that the messages are seriously fraudulent or otherwise inappropriate 🔒.
To stretch the delivery principle even further, it might be a rational policy to not deliver mail with an invalid return address. Still, the history of the network shows that users are usually better off when any deliverable message gets delivered 🌸. Reliably figuring out that a return address is invalid can be a hard and time-consuming job, especially if the sending system isn't directly accessible or doesn't fully and accurately support VRFY. And even if a "drop messages with invalid return addresses" policy is adopted, it SHOULD be applied only when there is near-certainty that the return addresses really are invalid 🧐.
On the flip side, if a message gets rejected because it contains hostile content (a decision that's outside the scope of an SMTP server as defined in this document), rejection ("bounce") messages SHOULD NOT be sent unless the receiving site is confident those messages will be usefully delivered 🙅♀️. The preference and default in these cases is to avoid sending non-delivery messages when the incoming message is determined to contain hostile content 🦋.
6.3. Loop Detection 🔁
counting the "Received:" header fields in a message is an effective (though rarely optimal) way to catch loops in mail systems 🌀. SMTP servers using this technique SHOULD use a large rejection threshold, normally at least 100 Received entries 🔢. Whatever mechanisms are used, servers MUST contain provisions for detecting and stopping trivial loops 🛑.
6.4. Compensating for Irregularities 🧩
ngl the mail world is messy 😭. Variations, creative interpretations, and outright violations of Internet mail protocols do happen, and some would say they happen quite a lot 🙈. The argument over whether a well-behaved SMTP receiver or relay should reject a malformed message, pass it on unchanged, or try to repair it so it has better odds of delivery (or a successful reply) started almost at the dawn of structured network mail and is still going strong 🍿. Rejection fans say repairs are rarely completely adequate, and that rejecting bad messages is the only way to get the offending software fixed 🔧. "Repair" or "deliver no matter what" fans say users want their mail to go through if at all possible, and that there are big market pressures pushing that way 💸. In practice, those market pressures may matter more to certain vendors than strict conformance to the standards, whatever the actual developers prefer 👀.
The problems with ill-formed messages got worse when split-UA mail reading protocols showed up (Post Office Protocol (POP) version 2 [15], Post Office Protocol (POP) version 3 [16], IMAP version 2 [41], and PCMAIL [42]) 📱. These protocols encouraged using SMTP as a posting (message submission) protocol, and SMTP servers as relay systems for client hosts, which are often only connected to the Internet now and then 🌙. Historically, a lot of those client machines were missing some of the mechanisms and information that SMTP (and the mail format protocol, RFC 822 [28]) assumed. Some couldn't keep track of time well, some had no concept of time zones, some couldn't identify their own names or addresses, and, of course, none could meet the assumptions behind RFC 822's idea of authenticated addresses 😵.
To deal with these weak SMTP clients, lots of SMTP systems now complete messages that get delivered to them when they arrive incomplete or incorrect 🩹. This approach is generally considered appropriate when the server can identify or authenticate the client, and there are prior agreements between them 🤝. But by contrast, there's at best great concern about fixes applied by a relay or delivery SMTP server that has little or no knowledge of the user or client machine 😬. A lot of these issues are handled by using a separate protocol for message submission, like the one defined in RFC 4409 [18], instead of relying on originating SMTP servers for that job 🌟.
The following changes to a message being processed MAY be applied when necessary by an originating SMTP server, or by one used as the target of SMTP as an initial posting (message submission) protocol 🎀:
- Addition of a message-id field when none appears
- Addition of a date, time, or time zone when none appears
- Correction of addresses to proper FQDN format
The less information the server has about the client, the less likely these changes are to be correct. So the more caution and conservatism should be applied when deciding whether to make fixes and how to make them 🧠. These changes MUST NOT be applied by an SMTP server that provides an intermediate relay function 🚧.
In all cases, properly operating clients that supply correct information are preferred over corrections by the SMTP server 👑. And in all cases, documentation SHOULD be provided in trace header fields and/or header field comments for actions the servers perform 📝 ✨.
7. Security Considerations 🛡️
7.1. Mail Security and Spoofing 🎭
okay so SMTP mail is inherently insecure, bestie 😭 It's feasible for even fairly casual users to negotiate directly with receiving and relaying SMTP servers and make messages that trick a naive recipient into thinking they came from somewhere else 💀 Making a "spoofed" message that an expert can't detect is harder, but not so much harder that it stops someone who's determined and knowledgeable 🕵️♀️ So as people learn more about Internet mail, they also learn that SMTP mail can't be authenticated, or given integrity checks, at the transport level. Real mail security only lives end-to-end, in the message bodies, with things like digital signatures (see RFC 1847 [43] and, e.g., Pretty Good Privacy (PGP) in RFC 4880 [44] or Secure/Multipurpose Internet Mail Extensions (S/MIME) in RFC 3851 [45]) 🔐✨
Transport-level authentication is a glow-up, though 🌸 Various protocol extensions and configuration options that authenticate from an SMTP client to an SMTP server (e.g., from one client to one server) improve things a bit compared to the old way. However, in general, they only authenticate one server to another, not a whole chain of relays and servers, and definitely not users or user machines 🙃 So unless they come with careful handoffs of responsibility in a carefully designed trust environment, they stay inherently weaker than end-to-end mechanisms that use digitally signed messages instead of depending on the integrity of the transport system 💅
Trying to stop users from setting the envelope return path and the header "From" field to point at valid addresses other than their own is largely misguided, ngl 🙅♀️ It frustrates legit stuff: mail sent by one user on behalf of another, error (or normal) replies that should go to a special address, or one message sent to multiple recipients on different hosts. (Systems that give users easy ways to change these header fields on a per-message basis should try to set up a primary and permanent mailbox address for each user, so that Sender header fields within the message data can be generated sensibly 💡)
This specification doesn't dig further into the authentication issues tied to SMTP. The only real advice is to not disable useful functionality in the hope of getting some tiny margin of protection against someone trying to fake mail 🤷♀️✨
7.2. "Blind" Copies 🙈
Addresses that don't appear in the message header section can still show up in RCPT commands to an SMTP server, for a bunch of reasons 📬 The two most common are using a mailing address as a "list exploder" (one address that resolves into multiple addresses) and "blind copies." Especially when more than one RCPT command is present, and so the purpose of these mechanisms doesn't get defeated, SMTP clients and servers SHOULD NOT copy the full set of RCPT command arguments into the header section 🚫 That's whether it's part of trace header fields or informational or private-extension header fields. This rule gets broken all the time and can't be enforced, so sending SMTP systems that know about "bcc" use MAY find it helpful to send each blind copy as a separate message transaction containing only a single RCPT command 🫣
There's no inherent relationship between the "reverse" addresses (from MAIL, SAML, etc., commands) or "forward" (RCPT) addresses in the SMTP transaction (the "envelope") and the addresses in the header section 💖 Receiving systems SHOULD NOT try to deduce those relationships and use them to alter the header section of the message for delivery 🙅♀️ The popular "Apparently-to" header field goes against this principle, and it's a common source of unintended information disclosure, so it SHOULD NOT be used 💀
7.3. VRFY, EXPN, and Security 🕵️♀️
As discussed in Section 3.5, individual sites may want to disable VRFY or EXPN, or both, for security reasons (see below) 🔒 Following on from that, implementations that permit this MUST NOT appear to have verified addresses that aren't actually verified 🚫 If a site disables these commands for security reasons, the SMTP server MUST return a 252 response, rather than a code that could be mistaken for successful or unsuccessful verification 🙌
Returning a 250 reply code with the address listed in the VRFY command after checking it only for syntax breaks this rule 😤 And an implementation that "supports" VRFY by always returning 550, whether or not the address is valid, is just as much not in conformance 💀
On the public Internet, the contents of mailing lists have become a popular address info source for so-called "spammers" 📧 The use of EXPN to "harvest" addresses has gone up as list admins have put protections in place against inappropriate uses of the lists themselves. Still, VRFY and EXPN are useful for authenticated users and within an administrative domain 💅 For example, they're handy for internal audits of how email gets routed, to check that no one is automatically forwarding sensitive mail outside the organization 👀 Sites implementing SMTP authentication may choose to make VRFY and EXPN available only to authenticated requestors ✨ Implementations SHOULD still provide support for EXPN, but sites SHOULD carefully evaluate the tradeoffs ⚖️
Whether disabling VRFY gives any real extra security depends on a series of other conditions 🤔 In many cases, RCPT commands can be used to get the same info about address validity. On the other hand, especially where determining address validity for RCPT commands is deferred until after the DATA command is received, RCPT may return no information at all, while VRFY is expected to make a serious attempt to determine validity before generating a response code (see discussion above) 🧠
7.4. Mail Rerouting Based on the 251 and 551 Response Codes 🔀
Before a client uses the 251 or 551 reply codes from a RCPT command to automatically update its future behavior (e.g., updating the user's address book), it should be certain of the server's authenticity 🫠 If it isn't, it may be subject to a man in the middle attack 😱
7.5. Information Disclosure in Announcements 📣
There's been an ongoing debate about the tradeoffs between the debugging advantages of announcing server type and version (and, sometimes, even server domain name) in the greeting response or in response to the HELP command, and the disadvantages of exposing info that might be useful in a potential hostile attack 🤺 The debugging info is beyond doubt useful. People who argue for making it available point out that it's way better to actually secure an SMTP server than to hope that hiding its precise identity will conceal known vulnerabilities and give more protection 💪 Sites are encouraged to weigh that tradeoff with that issue in mind. Implementations SHOULD minimally provide for making type and version information available in some way to other network hosts 🌈
7.6. Information Disclosure in Trace Fields 🕳️
In some situations, like when mail comes from within a LAN whose hosts aren't directly on the public Internet, trace ("Received") header fields made in line with this specification may disclose host names and similar info that wouldn't normally be available 👀 This usually isn't a problem, but sites with special concerns about name disclosure should be aware of it. Also, the optional FOR clause should be supplied with caution, or not at all, when multiple recipients are involved, lest it accidentally reveal the identities of "blind copy" recipients to others 🙈
7.7. Information Disclosure in Message Forwarding 📨
As discussed in Section 3.4, using the 251 or 551 reply codes to identify the replacement address for a mailbox may accidentally disclose sensitive info ⚠️ Sites that are concerned about those issues should make sure they select and configure servers appropriately 🛠️
7.8. Resistance to Attacks 🛡️
In recent years, attacks on SMTP servers have increased. They happen either alongside attempts to find addresses for sending unsolicited messages, or just to make servers inaccessible to others (i.e., as an application-level denial of service attack) 😤 The means of doing this are beyond the scope of this Standard, but rational operational behavior requires that servers be permitted to detect such attacks and take action to defend themselves 🧱 For example, if a server determines that a large number of RCPT TO commands are being sent, most or all with invalid addresses, as part of such an attack, it would be reasonable for the server to close the connection after generating an appropriate number of 5yz (normally 550) replies 🔌
7.9. Scope of Operation of SMTP Servers 🌍
It's a well-established principle that an SMTP server may refuse to accept mail for any operational or technical reason that makes sense to the site providing the server 💁♀️ But cooperation among sites and installations is what makes the Internet possible 🫶 If sites take excessive advantage of the right to reject traffic, the ubiquity of email availability (one of the big strengths of the Internet) will be threatened, so considerable care should be taken, and balance maintained, if a site decides to be selective about the traffic it will accept and process ⚖️
In recent years, the relay function through arbitrary sites has been used as part of hostile efforts to hide the actual origins of mail 🥷 Some sites have decided to limit use of the relay function to known or identifiable sources, and implementations SHOULD provide the capability to perform this type of filtering 🎀 When mail is rejected for these or other policy reasons, a 550 code SHOULD be used in response to EHLO (or HELO), MAIL, or RCPT as appropriate 💜
8. IANA Considerations ✨
okay so IANA keeps three registries for this spec 🗂️💖 all three were made back in RFC 2821 or earlier, and this doc expands the third one. the registry links are only correct as of publication, and IANA doesn't promise the URLs will stay put 🙈 here's the lineup:
- ok first up is "Simple Mail Transfer Protocol (SMTP) Service Extensions" [46] 📮 it holds SMTP service extensions plus their keywords, and parameters and verbs when needed. per Section 2.2.2, nothing starting with an "X" can get added here 🚫 entries only go in for extensions (and their keywords, parameters, or verbs) defined in Standards-Track or Experimental RFCs that the IESG specifically approved for this 🫶
- next is "Address Literal Tags" [47] 🌐 it has "tags" for domain literal forms other than IPv4 addresses (IPv4 is covered by RFC 821 and this doc). the first entry is IPv6, which this doc specifies ✨ any new literal type needs standardization before it can be used, and nobody expects any right now 💅
- the third one is "Mail Transmission Types" [46] 🦋 it was made by RFC 821, renewed by this spec, and it's the list of link and protocol identifiers you use with the "via" and "with" subclauses of the time stamp ("Received:" header field) from Section 4.4 💜 new identifiers can only get in through standardization or an RFC-documented, IESG-approved, Experimental protocol extension 🔥 the namespace isn't capped in size, and the IESG is encouraged to approve based on clear docs and a distinct method, not on personal vibes about how the method works 😤
the "VIA link types" and "WITH protocol types" subsections of that registry got a new subsection for "Additional-registered-clauses" 🎀 that's where clause registrations live. each entry has a clause name, a description, a summary of the syntax of the associated String, and a reference 📚 when new clauses get defined, they might specify their own registries, but only if their Strings are made of reserved terms or keywords instead of looser strings 🧠 same deal as before: clauses can only be registered through standardization or an RFC-documented, IESG-approved, Experimental protocol extension ✅ the clause namespace isn't limited in size either, and the IESG is encouraged to approve on clear docs, actual use or strong signs it'll be used, and a distinct requirement, not preferences about the clause's properties 💖
and one more thing 🌸 if extra trace header fields ever get created (beyond Return-path and Received), those trace fields MUST be added to the IANA registry from BCP 90 (RFC 3864) [11] for use with RFC 5322 [4] 🧚
9. Acknowledgments
okay so RFC 2821 had SO many contributors 🥹 that doc is where you should look for those thank-yous 💜 for this one, the editor and the whole community owe a huge thanks to Dawn Mann and Tony Hansen 🫶 they helped with the very painful job of editing and converting the document's internal format from one system to another 😭
neither this doc nor RFC 2821 would exist without the incredible work and insights of the late Jon Postel 🕯️✨ that includes the original SMTP spec in RFC 821 🎀 a big chunk of text from RFC 821 is still here, and so are several of Jon's original examples, which got updated only where the rest of the spec changed 🌈
people also left comments and suggestions on the mailing list or in notes to the author 💌 important corrections and clarifications came from a bunch of folks, including Matti Aarnio, Glenn Anderson, Derek J. Balling, Alex van den Bogaerdt, Stephane Bortzmeyer, Vint Cerf, Jutta Degener, Steve Dorner, Lisa Dusseault, Frank Ellerman, Ned Freed, Randy Gellens, Sabahattin Gucukoglu, Philip Guenther, Arnt Gulbrandsen, Eric Hall, Richard O. Hammer, Tony Hansen, Peter J. Holzer, Kari Hurtta, Bryon Roche Kain, Valdis Kletnieks, Mathias Koerber, John Leslie, Bruce Lilly, Jeff Macdonald, Mark E. Mallett, Mark Martinec, S. Moonesamy, Lyndon Nerenberg, Chris Newman, Douglas Otis, Pete Resnick, Robert A. Rosenberg, Vince Sabio, Hector Santos, David F. Skoll, Paul Smith, and Brett Watson 🙌🦋
the Area Directors -- Lisa Dusseault, Ted Hardie, and Chris Newman -- deserve credit for getting this effort restarted and keeping it moving 👑 so does an ad hoc committee with the same goal 🫡 that committee was (in alphabetical order) Dave Crocker, Cyrus Daboo, Tony Finch, Ned Freed, Randall Gellens, Tony Hansen, the author, and Alexey Melnikov 💅 Tony Hansen also acted as ad hoc chair on the mailing list reviewing this doc, and without his effort, sense of balance and fairness, and patience, it clearly wouldn't have happened 🥹💖
10. References
10.1. Normative References
- [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982. 📜
- [2] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. 🌐
- [3] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989. 🧱
- [4] Resnick, P., "Internet Message Format", RFC 5322, October 2008. ✉️
- [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 🔑
- [6] American National Standards Institute (formerly United States of America Standards Institute), "USA Code for Information Interchange", ANSI X3.4-1968, 1968. 🔤
ANSI X3.4-1968 has been replaced by newer versions with slight modifications, but the 1968 version remains definitive for the Internet. 📌
- [7] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. 🧩
- [8] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. 🦋
- [9] Newman, C., "ESMTP and LMTP Transmission Types Registration", RFC 3848, July 2004. 🏷️
- [10] Klensin, J., Freed, N., and K. Moore, "SMTP Service Extension for Message Size Declaration", STD 10, RFC 1870, November 1995. 📏
- [11] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004. 📝
10.2. Informative References
- [12] Partridge, C., "Mail routing and the domain system", RFC 974, January 1986. 🗺️
- [13] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, "SMTP Service Extensions", STD 10, RFC 1869, November 1995. 🧩
- [14] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. 📮
- [15] Butler, M., Postel, J., Chase, D., Goldberger, J., and J. Reynolds, "Post Office Protocol: Version 2", RFC 937, February 1985. 📬
- [16] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996. 📭
- [17] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003. 📥
- [18] Gellens, R. and J. Klensin, "Message Submission for Mail", RFC 4409, April 2006. 🚀
- [19] Freed, N., "SMTP Service Extension for Command Pipelining", STD 60, RFC 2920, September 2000. 🏎️
- [20] Vaudreuil, G., "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", RFC 3030, December 2000. 📦
- [21] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. 🎨
- [22] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, July 1994. 🔢
- [23] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996. 🌏
- [24] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, November 1997. 🗣️
- [25] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003. 🚦
- [26] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced Mail System Status Codes", BCP 138, RFC 5248, June 2008. 🗃️
- [27] Freed, N., "Behavior of and Requirements for Internet Firewalls", RFC 2979, October 2000. 🧱🔥
- [28] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982. 📄
- [29] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1", RFC 4408, April 2006. 🛡️
- [30] Fenton, J., "Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)", RFC 4686, September 2006. 🕵️
- [31] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures", RFC 4871, May 2007. 🔏
- [32] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003. 🔔
- [33] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003. 📨
- [34] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985. 📁
- [35] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156, January 1998. 🔀
- [36] De Winter, J., "SMTP Service Extension for Remote Message Queue Starting", RFC 1985, August 1996. ⏯️
- [37] Hansen, T. and G. Vaudreuil, "Message Disposition Notification", RFC 3798, May 2004. ✅
- [38] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997. 🔍
- [39] Nakamura, M. and J. Hagino, "SMTP Operational Experience in Mixed IPv4/v6 Environments", RFC 3974, January 2005. 🌉
- [40] Partridge, C., "Duplicate messages and SMTP", RFC 1047, February 1988. 👯
- [41] Crispin, M., "Interactive Mail Access Protocol: Version 2", RFC 1176, August 1990. 🗂️
- [42] Lambert, M., "PCMAIL: A distributed mail system for personal computers", RFC 1056, June 1988. 💻
- [43] Galvin, J., Murphy, S., Crocker, S., and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995. 🔐
- [44] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 🗝️
- [45] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004. 🔒
- [46] Internet Assigned Number Authority (IANA), "IANA Mail Parameters", 2007,
<http://www.iana.org/assignments/mail-parameters>. 🗄️ - [47] Internet Assigned Number Authority (IANA), "Address Literal Tags", 2007,
<http://www.iana.org/assignments/address-literal-tags>. 🏷️
Appendix A. TCP Transport Service ✨
Okay bestie, the TCP connection supports sending 8-bit bytes 🦋. But SMTP data is 7-bit ASCII characters, so each character goes out as an 8-bit byte with the high-order bit cleared to zero 💅. Service extensions can change this and let full 8-bit data bytes through as part of the message body 🌈, or in SMTP commands or responses if they're specifically designed for that 🫶.
Appendix B. Generating SMTP Commands from RFC 822 Header Fields 💌
Some systems only use an RFC 822 header section in a mail submission protocol, or otherwise generate SMTP commands from RFC 822 header fields when a message gets handed from a UA to an MTA 📨. The MTA-UA protocol is a private matter, not covered by any Internet Standard, and this approach has real problems 💀. There have been repeated messes with "bcc" copies and redistribution lists when stuff that conceptually belongs to the mail envelope isn't separated early in processing from the header field info (and kept separate) 🙈.
It is recommended that the UA give its initial ("submission client") MTA an envelope separate from the message itself 🎀. However, if the envelope is not supplied, SMTP commands SHOULD be generated as follows:
- Each recipient address from a TO, CC, or BCC header field SHOULD be copied to a RCPT command (generating multiple message copies if that is required for queuing or delivery) 📬. This includes any addresses listed in a RFC 822 "group". Any BCC header fields SHOULD then be removed from the header section. Once this process is completed, the remaining header fields SHOULD be checked to verify that at least one TO, CC, or BCC header field remains. If none do, then a BCC header field with no additional information SHOULD be inserted as specified in [4] 🧚.
- The return address in the MAIL command SHOULD, if possible, be derived from the system's identity for the submitting (local) user, and the "From:" header field otherwise 🍓. If there is a system identity available, it SHOULD also be copied to the Sender header field if it is different from the address in the From header field. (Any Sender header field that was already there SHOULD be removed.) Systems may provide a way for submitters to override the envelope return address, but may want to restrict its use to privileged users 👑. This will not prevent mail forgery, but may lessen its incidence; see Section 7.1 😤.
When an MTA is being used this way, it bears responsibility for making sure the message being transmitted is valid 🫡. The mechanisms for checking that validity, and for handling (or returning) messages that are not valid at the time of arrival, are part of the MUA-MTA interface and not covered by this specification 🔍.
A submission protocol based on Standard RFC 822 information alone MUST NOT be used to gateway a message from a foreign (non-SMTP) mail system into an SMTP environment 🚫. Additional information to construct an envelope must come from some source in the other environment, whether supplemental header fields or the foreign system's envelope 💜.
Attempts to gateway messages using only their header "To" and "Cc" fields have repeatedly caused mail loops and other behaviour that's adverse to the proper functioning of the Internet mail environment 🌀. These problems have been especially common when the message comes from an Internet mailing list and gets distributed into the foreign environment using envelope information 📣. When those messages are then processed by a header-section-only remailer, loops back to the Internet environment (and the mailing list) are almost inevitable 😭.
Appendix C. Source Routes 🗺️
Historically, the <reverse-path> was a reverse source routing list of hosts and a source mailbox 🕰️. The first host in the <reverse-path> was historically the host sending the MAIL command. Today, source routes SHOULD NOT appear in the reverse-path 🙅♀️. Similarly, the <forward-path> may be a source routing list of hosts and a destination mailbox. However, in general, the <forward-path> SHOULD contain only a mailbox and domain name, relying on the domain name system to supply routing information if required 🌸. The use of source routes is deprecated (see Appendix F.2). While servers MUST be prepared to receive and handle them as discussed in Section 3.3 and Appendix F.2, clients SHOULD NOT transmit them, and this section is included in the current specification only to provide context 📚. It has been modified somewhat from the material in RFC 821 to stop server actions that might confuse clients or subsequent servers that don't expect a full source route implementation 🙃.
For relay purposes, the forward-path may be a source route of the form "@ONE,@TWO:JOE@THREE", where ONE, TWO, and THREE MUST be fully-qualified domain names 🔗. This form is used to emphasize the difference between an address and a route ✨. The mailbox (here, JOE@THREE) is an absolute address, and the route is information about how to get there. The two concepts should not be confused 🧠.
If source routes are used, RFC 821 and the text below should be consulted for the mechanisms for constructing and updating the forward-path 🛠️. A server that is reached by means of a source route (e.g., its domain name appears first in the list in the forward-path) MUST remove its domain name from any forward-paths in which that domain name appears before forwarding the message, and MAY remove all other source routing information. The reverse-path SHOULD NOT be updated by servers conforming to this specification 🫶.
Notice that the forward-path and reverse-path appear in the SMTP commands and replies, but not necessarily in the message 👀. That means there's no need for these paths, and especially this syntax, to show up in the "To:", "From:", "CC:", etc. fields of the message header section. Conversely, SMTP servers MUST NOT derive final message routing information from message header fields 🚦.
When the list of hosts is present despite the recommendations above, it's a "reverse" source route and shows the mail was relayed through each host on the list (the first host in the list was the most recent relay) 🔁. This list is used as a source route to return non-delivery notices to the sender. If, contrary to the recommendations here, a relay host adds itself to the beginning of the list, it MUST use its name as known in the transport environment it's relaying the mail to, rather than the name from the transport environment the mail came from (if they're different) 🏷️. Note that a situation could easily come up where some relay hosts add their names to the reverse source route and others don't, creating discontinuities in the routing list 😵💫. This is another reason why servers needing to return a message SHOULD ignore the source route entirely and simply use the domain as specified in the Mailbox 💅.
Appendix D. Scenarios 🎬
This section presents complete scenarios of several types of SMTP sessions 🍿. In the examples, "C:" means what the SMTP client says, and "S:" means what the SMTP server says 🎭.
D.1. A Typical SMTP Transaction Scenario
This one's the classic: mail from Smith at bar.com to Jones, Green, and Brown at foo.com 💜. Here we assume bar.com contacts foo.com directly. The mail is accepted for Jones and Brown. Green doesn't have a mailbox at foo.com 💀.
S: 220 foo.com Simple Mail Transfer Service Ready
C: EHLO bar.com
S: 250-foo.com greets bar.com
S: 250-8BITMIME
S: 250-SIZE
S: 250-DSN
S: 250 HELP
C: MAIL FROM:<Smith@bar.com>
S: 250 OK
C: RCPT TO:<Jones@foo.com>
S: 250 OK
C: RCPT TO:<Green@foo.com>
S: 550 No such user here
C: RCPT TO:<Brown@foo.com>
S: 250 OK
C: DATA
S: 354 Start mail input; end with <CRLF>.<CRLF>
C: Blah blah blah...
C: ...etc. etc. etc.
C: .
S: 250 OK
C: QUIT
S: 221 foo.com Service closing transmission channelD.2. Aborted SMTP Transaction Scenario
Here Green gets rejected and the client bails out with RSET 🙃.
S: 220 foo.com Simple Mail Transfer Service Ready
C: EHLO bar.com
S: 250-foo.com greets bar.com
S: 250-8BITMIME
S: 250-SIZE
S: 250-DSN
S: 250 HELP
C: MAIL FROM:<Smith@bar.com>
S: 250 OK
C: RCPT TO:<Jones@foo.com>
S: 250 OK
C: RCPT TO:<Green@foo.com>
S: 550 No such user here
C: RSET
S: 250 OK
C: QUIT
S: 221 foo.com Service closing transmission channelD.3. Relayed Mail Scenario
This one's a whole saga with two steps 🧵.
Step 1 -- Source Host to Relay Host
The source host does a DNS lookup on XYZ.COM (the destination address) and finds DNS MX records specifying xyz.com as the best preference and foo.com as a lower preference. It tries to open a connection to xyz.com and fails. Then it opens a connection to foo.com, with the following dialogue 📞:
S: 220 foo.com Simple Mail Transfer Service Ready
C: EHLO bar.com
S: 250-foo.com greets bar.com
S: 250-8BITMIME
S: 250-SIZE
S: 250-DSN
S: 250 HELP
C: MAIL FROM:<JQP@bar.com>
S: 250 OK
C: RCPT TO:<Jones@XYZ.COM>
S: 250 OK
C: DATA
S: 354 Start mail input; end with <CRLF>.<CRLF>
C: Date: Thu, 21 May 1998 05:33:29 -0700
C: From: John Q. Public <JQP@bar.com>
C: Subject: The Next Meeting of the Board
C: To: Jones@xyz.com
C:
C: Bill:
C: The next meeting of the board of directors will be
C: on Tuesday.
C: John.
C: .
S: 250 OK
C: QUIT
S: 221 foo.com Service closing transmission channelStep 2 -- Relay Host to Destination Host
foo.com got the message, so now it does a DNS lookup on xyz.com 🔎. It finds the same set of MX records, but it can't use the one that points to itself (or to any other host with a worse preference). It tries to open a connection to xyz.com itself, and it works! ✅ Then we have:
S: 220 xyz.com Simple Mail Transfer Service Ready
C: EHLO foo.com
S: 250 xyz.com is on the air
C: MAIL FROM:<JQP@bar.com>
S: 250 OK
C: RCPT TO:<Jones@XYZ.COM>
S: 250 OK
C: DATA
S: 354 Start mail input; end with <CRLF>.<CRLF>
C: Received: from bar.com by foo.com ; Thu, 21 May 1998
C: 05:33:29 -0700
C: Date: Thu, 21 May 1998 05:33:22 -0700
C: From: John Q. Public <JQP@bar.com>
C: Subject: The Next Meeting of the Board
C: To: Jones@xyz.com
C:
C: Bill:
C: The next meeting of the board of directors will be
C: on Tuesday.
C: John.
C: .
S: 250 OK
C: QUIT
S: 221 foo.com Service closing transmission channelD.4. Verifying and Sending Scenario
Last one! This session checks the address with VRFY first, then sends the mail 🎀.
S: 220 foo.com Simple Mail Transfer Service Ready
C: EHLO bar.com
S: 250-foo.com greets bar.com
S: 250-8BITMIME
S: 250-SIZE
S: 250-DSN
S: 250-VRFY
S: 250 HELP
C: VRFY Crispin
S: 250 Mark Crispin <Admin.MRC@foo.com>
C: MAIL FROM:<EAK@bar.com>
S: 250 OK
C: RCPT TO:<Admin.MRC@foo.com>
S: 250 OK
C: DATA
S: 354 Start mail input; end with <CRLF>.<CRLF>
C: Blah blah blah...
C: ...etc. etc. etc.
C: .
S: 250 OK
C: QUIT
S: 221 foo.com Service closing transmission channelAppendix E. Other Gateway Issues ✨
Okay so, gateways between the Internet and other mail systems SHOULD try to keep any layering semantics intact when crossing between the two systems 🌉. Shortcut translations that map stuff like envelope info into the message header section or body of another system have generally been a total fail 💀. Systems translating between environments that don't support both envelopes and a header section, and Internet mail, have to be built knowing that some information loss is almost inevitable 😭.
Appendix F. Deprecated Features of RFC 821 💅
Bestie, a few features of RFC 821 turned out to be major problems, so they SHOULD NOT be used in Internet mail 🚫. Let's go through the drama 🍿.
F.1. TURN 🔄
This command is from RFC 821, and it's giving security nightmare 😱. Without strong authentication of the host asking the client and server to switch roles, it can super easily be used to divert mail away from where it's supposed to go 📭. So yeah, it's deprecated 🙅♀️. SMTP systems SHOULD NOT use it unless the server can authenticate the client 🔐.
F.2. Source Routing 🗺️
RFC 821 used explicit source routing to get mail from one host to another through a series of relays 🛤️. That's not required for regular mail anymore, thanks to the domain name system "MX" record 🙌. The last big reason for source routes got wiped out when RFC 1123 made it clear that addresses after an "@" must all be fully-qualified domain names 💯. So now the only leftover reasons to use source routes are supporting really old SMTP clients or MUAs, and mail system debugging 🛠️. They can still be useful for debugging, and for routing mail around serious-but-temporary problems, like broken DNS records 🧩.
SMTP servers MUST continue to accept source route syntax as specified in the main body of this document and in RFC 1123 🫶. They MAY, if necessary, ignore the routes and only use the target domain in the address 🙈. If they do use the source route, the message MUST be sent to the first domain shown in the address 📬. And honestly, a server MUST NOT guess at shortcuts within the source route 🚫✨.
Clients SHOULD NOT utilize explicit source routing except under unusual circumstances, like debugging or maybe relaying around firewall or mail system configuration errors 🧯.
F.3. HELO 👋
As discussed in Sections 3.1 and 4.1.1, EHLO SHOULD be used rather than HELO when the server will accept the former 🌟. Servers MUST continue to accept and process HELO to support older clients 🫶. We're being nice to the oldies 👵💖.
F.4. #-literals 🔢
RFC 821 let you specify an Internet address as a decimal integer host number with a pound sign, "#", in front 🤓. In practice though, that form has been obsolete since TCP/IP came along 🥱. It's deprecated and MUST NOT be used 🚫.
F.5. Dates and Years 📅
When dates get inserted into messages by SMTP clients or servers (for example, in trace header fields), four-digit years MUST BE used 🗓️✨. Two-digit years are deprecated 😬. Three-digit years were never permitted in the Internet mail system, so no notes 🙅♀️.
F.6. Sending versus Mailing 📬
Besides delivering messages to users' mailboxes, RFC 821 had extra optional commands to deliver messages straight to the user's terminal screen 🖥️. Those commands were SEND, SAML, and SOML, and they were rarely implemented 🥲. Workstation tech changed and other protocols showed up, so they may be obsolete even where they do exist 🕰️.
Clients SHOULD NOT provide SEND, SAML, or SOML as services 🚫. Servers MAY implement them 🤷♀️. If servers do implement them, the implementation model from RFC 821 MUST be used, and the command names MUST be published in the response to the EHLO command 📣.
Author's Address 🖋️
John C. Klensin
1770 Massachusetts Ave, Suite 322
Cambridge, MA 02140
USA
EMail: john+smtp@jck.comFull Copyright Statement ©️
Copyright (C) The IETF Trust (2008). The legal stuff, but make it cute 🎀.
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights 🔒.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. ⚠️
Intellectual Property 💡
The IETF takes no position on whether any Intellectual Property Rights or other rights that might be claimed to apply to the implementation or use of the technology in this document are valid or in scope, or whether any license under those rights might or might not be available 🤐. It also doesn't say it has made any independent effort to identify any such rights 🔍. Info on how rights work for RFC documents is in BCP 78 and BCP 79 📚.
Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for implementers or users to use those proprietary rights, can be found in the IETF on-line IPR repository at http://www.ietf.org/ipr 🌐.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology required to implement this standard 🫵. Send that info to the IETF at ietf-ipr@ietf.org 💌. Thanks for reading, bestie 🦋💖
📦 where this page comes from
- ietf: rfc5321 2008-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms