RFC 2821

RFC 2821: Simple Mail Transfer Protocol 📬✨

Okay bestie, here are the deets 💌 This one is from the Network Working Group, written by J. Klensin (Editor 🫶) at AT&T Laboratories, dated April 2001.

• Category: Standards Track 🎀
• Obsoletes: 821, 974, 1869 💅
• Updates: 1123 🌈

Status of this Memo 🦋

This document specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 💖

Copyright Notice 🌸

Copyright (C) The Internet Society (2001). All Rights Reserved. ✨

Abstract 💜

Okay so this doc is a self-contained spec for the basic protocol used for Internet electronic mail transport 📬 It consolidates, updates and clarifies stuff, but it does NOT add new functionality or change what already exists. It's basically pulling together:

• the original SMTP (Simple Mail Transfer Protocol) specification of RFC 821 [30],
• domain name system requirements and implications for mail transport from RFC 1035 [22] and RFC 974 [27],
• the clarifications and applicability statements in RFC 1123 [2], and
• material drawn from the SMTP Extension mechanisms [19].

It obsoletes RFC 821 and RFC 974, and updates RFC 1123 (it replaces the mail transport materials of RFC 1123) 🎀 RFC 821 has some features that weren't really in use across the Internet by the mid-1990s, plus some extra transport models in its appendices. Those parts are left out here for clarity and brevity, so if you need them, go check RFC 821 🧚

It also pulls in some extra material from RFC 1123 that needed more explaining 🙈 This stuff was spotted in a bunch of ways, mostly by tracking flame wars on mailing lists and newsgroups, and by weird readings or interpretations that popped up as SMTP extensions got deployed. Wherever this spec goes beyond consolidation and actually differs from earlier documents, it supersedes them, both technically and textually 🔥

Even though SMTP was designed as a mail transport and delivery protocol, this spec also has info that matters for its use as a "mail submission" protocol, as recommended for POP [3, 26] and IMAP [6] 💌 More submission stuff is discussed in RFC 2476 [15] 💅

Section 2.3 has definitions of terms specific to this document ✨ Unless the historical terminology is needed for clarity, this doc uses the current "client" and "server" terminology to mean the sending and receiving SMTP processes, respectively 🦋

A companion document [32] talks about message headers, message bodies, the formats and structures for them, and how they relate 🌈

Table of Contents 🧚

1. Introduction ..................................................  4
2. The SMTP Model ................................................  5
2.1 Basic Structure ..............................................  5
2.2 The Extension Model ..........................................  7
2.2.1 Background .................................................  7
2.2.2 Definition and Registration of Extensions ..................  8
2.3 Terminology ..................................................  9
2.3.1 Mail Objects ............................................... 10
2.3.2 Senders and Receivers ...................................... 10
2.3.3 Mail Agents and Message Stores ............................. 10
2.3.4 Host ....................................................... 11
2.3.5 Domain ..................................................... 11
2.3.6 Buffer and State Table ..................................... 11
2.3.7 Lines ...................................................... 12
2.3.8 Originator, Delivery, Relay, and Gateway Systems ........... 12
2.3.9 Message Content and Mail Data .............................. 13
2.3.10 Mailbox and Address ....................................... 13
2.3.11 Reply ..................................................... 13
2.4 General Syntax Principles and Transaction Model .............. 13
3. The SMTP Procedures: An Overview .............................. 15
3.1 Session Initiation ........................................... 15
3.2 Client Initiation ............................................ 16
3.3 Mail Transactions ............................................ 16
3.4 Forwarding for Address Correction or Updating ................ 19
3.5 Commands for Debugging Addresses ............................. 20
3.5.1 Overview ................................................... 20
3.5.2 VRFY Normal Response ....................................... 22
3.5.3 Meaning of VRFY or EXPN Success Response ................... 22
3.5.4 Semantics and Applications of EXPN ......................... 23
3.6 Domains ...................................................... 23
3.7 Relaying ..................................................... 24
3.8 Mail Gatewaying .............................................. 25
3.8.1 Header Fields in Gatewaying ................................ 26
3.8.2 Received Lines in Gatewaying ............................... 26
3.8.3 Addresses in Gatewaying .................................... 26
3.8.4 Other Header Fields in Gatewaying .......................... 27
3.8.5 Envelopes in Gatewaying .................................... 27
3.9 Terminating Sessions and Connections ......................... 27
3.10 Mailing Lists and Aliases ................................... 28
3.10.1 Alias ..................................................... 28
3.10.2 List ...................................................... 28
4. The SMTP Specifications ....................................... 29
4.1 SMTP Commands ................................................ 29
4.1.1 Command Semantics and Syntax ............................... 29
4.1.1.1  Extended HELLO (EHLO) or HELLO (HELO) ................... 29
4.1.1.2 MAIL (MAIL) .............................................. 31
4.1.1.3 RECIPIENT (RCPT) ......................................... 31
4.1.1.4 DATA (DATA) .............................................. 33
4.1.1.5 RESET (RSET) ............................................. 34
4.1.1.6 VERIFY (VRFY) ............................................ 35
4.1.1.7 EXPAND (EXPN) ............................................ 35
4.1.1.8 HELP (HELP) .............................................. 35
4.1.1.9 NOOP (NOOP) .............................................. 35
4.1.1.10 QUIT (QUIT) ............................................. 36
4.1.2 Command Argument Syntax .................................... 36
4.1.3 Address Literals ........................................... 38
4.1.4 Order of Commands .......................................... 39
4.1.5 Private-use Commands ....................................... 40
4.2  SMTP Replies ................................................ 40
4.2.1 Reply Code Severities and Theory ........................... 42
4.2.2 Reply Codes by Function Groups ............................. 44
4.2.3  Reply Codes in Numeric Order .............................. 45
4.2.4 Reply Code 502 ............................................. 46
4.2.5 Reply Codes After DATA and the Subsequent <CRLF>.<CRLF> .... 46
4.3 Sequencing of Commands and Replies ........................... 47
4.3.1 Sequencing Overview ........................................ 47
4.3.2 Command-Reply Sequences .................................... 48
4.4 Trace Information ............................................ 49
4.5 Additional Implementation Issues ............................. 53
4.5.1 Minimum Implementation ..................................... 53
4.5.2 Transparency ............................................... 53
4.5.3 Sizes and Timeouts ......................................... 54
4.5.3.1 Size limits and minimums ................................. 54
4.5.3.2 Timeouts ................................................. 56
4.5.4 Retry Strategies ........................................... 57
4.5.4.1 Sending Strategy ......................................... 58
4.5.4.2 Receiving Strategy ....................................... 59
4.5.5 Messages with a null reverse-path .......................... 59
5. Address Resolution and Mail Handling .......................... 60
6. Problem Detection and Handling ................................ 62
6.1 Reliable Delivery and Replies by Email ....................... 62
6.2 Loop Detection ............................................... 63
6.3 Compensating for Irregularities .............................. 63
7. Security Considerations ....................................... 64
7.1 Mail Security and Spoofing ................................... 64
7.2 "Blind" Copies ............................................... 65
7.3 VRFY, EXPN, and Security ..................................... 65
7.4 Information Disclosure in Announcements ...................... 66
7.5 Information Disclosure in Trace Fields ....................... 66
7.6 Information Disclosure in Message Forwarding ................. 67
7.7 Scope of Operation of SMTP Servers ........................... 67
8. IANA Considerations ........................................... 67
9. References .................................................... 68
10. Editor's Address ............................................. 70
11. Acknowledgments .............................................. 70
Appendices ....................................................... 71
A. TCP Transport Service ......................................... 71
B. Generating SMTP Commands from RFC 822 Headers ................. 71
C. Source Routes ................................................. 72
D. Scenarios ..................................................... 73
E. Other Gateway Issues .......................................... 76
F. Deprecated Features of RFC 821 ................................ 76
Full Copyright Statement ......................................... 79

1. Introduction 🌸

The goal of the Simple Mail Transfer Protocol (SMTP) is to transfer mail reliably and efficiently 💖

SMTP doesn't care about the particular transmission subsystem and only needs a reliable, ordered data stream channel 🦋 This document specifically talks about transport over TCP, but other transports are possible. Some of them are described in the appendices to RFC 821 ✨

A big feature of SMTP is that it can carry mail across networks, which is usually called "SMTP mail relaying" (see section 3.8) 🧚 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 🌈 With SMTP, a process can send mail to another process on the same network, or to some other network through a relay or gateway process that can reach both networks 💅

So a mail message might hop through a bunch of intermediate relay or gateway hosts on its way from the sender to the final recipient 🫶 The Mail eXchanger mechanisms of the domain name system [22, 27] (and section 5 of this document) are used to figure out the right next-hop destination for a message being transported 🎀

2. The SMTP Model 💜

2.1. Basic Structure ✨

okay so picture the SMTP setup like this 🦋

               +----------+                +----------+
   +------+    |          |                |          |
   | User |<-->|          |      SMTP      |          |
   +------+    |  Client- |Commands/Replies| Server-  |
   +------+    |   SMTP   |<-------------->|    SMTP  |    +------+
   | File |<-->|          |    and Mail    |          |<-->| File |
   |System|    |          |                |          |    |System|
   +------+    +----------+                +----------+    +------+
                SMTP client                SMTP server

When an SMTP client has a message to send, it sets up a two-way transmission channel to an SMTP server. The client's whole job is to pass mail messages along to one or more SMTP servers, or to report if it couldn't 💌

How a mail message gets handed to an SMTP client, and how that client figures out which domain name(s) to send it to, is a local thing 🏠 and this document doesn't cover it. Sometimes the domain name it ends up with is the final destination. Other times, like with clients tied to POP [3, 26] or IMAP [6] implementations, or when the client is stuck inside an isolated transport service environment, the domain name points to an intermediate spot where everything gets relayed. SMTP clients that send all traffic no matter what the target domain is, or that don't keep queues for retrying messages that couldn't go through the first time, can still follow this spec, but they're not considered fully-capable 💅 Fully-capable SMTP implementations, including the relays those less capable ones use and their destinations, are expected to support all the queuing, retrying, and alternate address functions talked about here.

Once the client knows a target domain name, figuring out which SMTP server to send a copy of the message to, and then actually doing the transfer, IS covered in this doc 🙌 To transfer mail to an SMTP server, the client sets up a two-way transmission channel to that server. It finds the address of a suitable host running an SMTP server 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 an intermediate "relay" (which means it can turn into an SMTP client after getting the message), or a "gateway" (which means it can carry the message further using some protocol other than SMTP) 🔁 SMTP commands come from the client and go to the server, and SMTP replies go from the server back to the client in response to those commands.

Basically, message transfer can happen in one connection between the original SMTP-sender and the final SMTP-recipient, or in a bunch of hops through middle systems 🦘 Either way there's a formal handoff of responsibility for the message: the protocol requires that a server accept responsibility for either delivering the message or properly reporting that it couldn't.

Once the channel is set up and the initial handshaking is done, the SMTP client usually starts a mail transaction. That's a series of commands that specify who the mail is from and where it's going, plus the message content itself (headers and any other structure included) 📬 When the same message goes to multiple recipients, this protocol encourages sending only one copy of the data for all recipients at the same destination (or intermediate relay) host.

The server answers every command with a reply. Replies can say the command was accepted, that more commands are expected, or that there's a temporary or permanent error 🚦 Commands that specify the sender or recipients may include server-permitted SMTP service extension requests, as discussed in section 2.2. The dialog is purposely lock-step, one-at-a-time, although mutually-agreed extension requests, like command pipelining [13], can change that 🔒

After a message has been sent, the client can either ask for the connection to be shut down or 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 mailing list subscriber addresses.

Like I said earlier, this protocol gives mechanisms for transmitting mail. Normally that goes straight from the sending user's host to the receiving user's host when both are connected to the same transport service 🎯 When they aren't on the same transport service, transmission goes through one or more relay SMTP servers. 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 by explicit "source" routing (see section 5 and appendices C and F.2) 🗺️

2.2. The Extension Model

2.2.1. Background

back in 1990, roughly a decade after RFC 821 was finished, the protocol got a glow-up 💖 with a "service extensions" model. This lets the client and server agree to use shared functionality beyond the original SMTP requirements. The SMTP extension mechanism gives an extended SMTP client and server a way to recognize each other, and lets the server tell the client which service extensions it supports 🤝

Contemporary SMTP implementations MUST support the basic extension mechanisms. For instance, servers MUST support the EHLO command even if they do not implement any specific extensions, and clients SHOULD preferentially utilize EHLO rather than 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 must be identified for interoperability purposes, this document discusses only EHLO.

SMTP is widely deployed and high-quality implementations have proven to be very robust 💪 However, 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 consists 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 [33].

SMTP's strength comes mainly from its simplicity. Experience with lots of protocols shows that protocols with few options tend toward ubiquity, while protocols with many options tend toward obscurity 🧸

Every single extension, no matter how nice its benefits, has to 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 keeps a registry of SMTP service extensions 📋 Each one gets a matching EHLO keyword value. Each service extension registered with the IANA must be defined in a formal standards-track or IESG-approved experimental protocol document. The 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. Flip side: keyword values presented in the EHLO response that do not 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 are not described in a registered extension.

Additional verbs and parameter names follow the same rules as EHLO keywords. So verbs starting with "X" are local extensions that may not be registered or standardized, and verbs not beginning with "X" must always be registered 📝

2.3. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described below 🎀

1. MUST: This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification.
2. MUST NOT: This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification.
3. SHOULD: This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
4. SHOULD NOT: This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.
5. MAY: This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.)

2.3.1 Mail Objects 📮

okay so SMTP's whole job is transporting a mail object, and a mail object is made of two things: an envelope and content 💌

The envelope is sent as a series of SMTP protocol units (more on those in section 3) 🎀 It has an originator address, which is where error reports should be directed 🚨, one or more recipient addresses 👯, and optional protocol extension material ✨. Historically, you could use variations on the recipient address command (RCPT TO) to ask for other delivery modes, like immediate display 👀. Those variations are now deprecated, so don't do it, bestie 🙅‍♀️ (see appendix F, section F.6).

The content is sent in the SMTP DATA protocol unit and it has two parts: the headers and the body 🩷 If the content follows other contemporary standards, the headers are a collection of field/value pairs structured as in the message format specification [32] 🧾, and if the body is structured, it's defined according to MIME [12] 🌈. The content is textual and uses the US-ASCII repertoire [1] 🔤. SMTP extensions like "8BITMIME" [20] can relax that restriction for the content body 🦋, but the content headers are always US-ASCII encoded, no exceptions 💅. A MIME extension [23] gives an algorithm for representing header values outside the US-ASCII repertoire, and it still encodes them using US-ASCII. Galaxy brain stuff, iykyk 🧠✨

---

2.3.2 Senders and Receivers 🫶

so in RFC 821, the two hosts in an SMTP transaction were called the "SMTP-sender" and "SMTP-receiver" 🕰️. This document updated that to current industry terms, so now they're the "SMTP client" (or sometimes just "the client") and the "SMTP server" (or just "the server") 💜. Here's the tea: a host can act as both server and client in a relay situation 🔁, so "receiver" and "sender" are still used where needed for clarity 💅.

---

2.3.3 Mail Agents and Message Stores 🏠

after RFC 821 came out, more mail system terms got popular, and where it's convenient, this spec uses them 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 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 hands the mail off to an MUA, or at least transfers responsibility to it, like by depositing the message in a "message store" 📥.

BUT, and this is important 🚩, these terms sound super precise in other environments, and the boundaries between MUAs and MTAs often don't actually match common, conforming practice with Internet mail 🫠. So be careful about assuming the strong relationships and responsibilities those terms might imply if you see them somewhere else 🙈.

---

2.3.4 Host 🖥️

for this spec, 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 "domain") 🏷️, and identifying them by numerical address is discouraged 🙅‍♀️.

---

2.3.5 Domain 🌸

a domain (or domain name) is one or more dot-separated components 🧩. These components ("labels" in DNS terminology [22]) are restricted for SMTP purposes to letters, digits, and hyphens drawn from the ASCII character set [1] 🔡. Domain names name hosts and other entities in the domain name hierarchy 🌳. For example, a domain may refer to an alias (a label of a CNAME RR) 🎭, or to the label of Mail eXchanger records used to deliver mail instead of naming a host 📮. See [22] and section 5 of this spec 📖.

The domain name, as described here and in [22], is the entire, fully-qualified name (often called an "FQDN") 💎. A domain name that isn't in FQDN form is just a local alias, and this is the part that matters most: local aliases MUST NOT appear in any SMTP transaction 🚫💥

---

2.3.6 Buffer and State Table 🧠

SMTP sessions are stateful, and both parties carefully keep a common view of the current state 🤝. In this document, the server's state is modelled by a virtual "buffer" and a "state table" 🗂️. The client can use these to do things like "clear the buffer" or "reset the state table," which discards the information in the buffer and returns the state to some previous state 🔄✨.

---

2.3.7 Lines 📏

SMTP commands and, unless a service extension changes it, message data get sent in "lines" 🧵. A line is zero or more data characters ended by the ASCII character "CR" (hex value 0D) immediately followed by the ASCII character "LF" (hex value 0A) 💫. This ending is written as <CRLF> in this document 🩵. Conforming implementations MUST NOT recognize or generate any other character or character sequence as a line terminator 🙅‍♀️. Servers MAY impose limits on line lengths (see section 4.5.3) 📐.

Also, "bare" "CR" or "LF" characters in text (meaning one without the other) have a long history of causing problems for mail implementations and apps that use mail as a tool 😭. SMTP client implementations MUST NOT send these characters unless they're meant as line terminators, and then they MUST, as said above, send them only as a <CRLF> sequence 🎀.

---

2.3.8 Originator, Delivery, Relay, and Gateway Systems 🛤️

this spec distinguishes four types of SMTP systems based on the role they play in sending email 💁‍♀️.

An "originating" system (sometimes an SMTP originator) puts mail into the Internet, or more generally into a transport service environment 🚀. A "delivery" SMTP system gets mail from a transport service environment and passes it to a mail user agent, or deposits it in a message store that an MUA is expected to access later 📬. A "relay" SMTP system (usually just a "relay") gets mail from an SMTP client and sends it on to another SMTP server, for more relaying or for delivery, without changing the message data except for adding trace information 🔁🧾.

A "gateway" SMTP system (usually just a "gateway") gets mail from a client in one transport environment and sends it to a server in another transport environment 🌉. If the protocols or message semantics differ on either side of a gateway, the gateway may need to transform the message in ways that SMTP relays are not allowed to 🔧. For this spec, firewalls that rewrite addresses should be considered gateways, even if SMTP is used on both sides of them (see [11]) 🧱.

---

2.3.9 Message Content and Mail Data 📦

"message content" and "mail data" mean the same thing in this document 💞. They describe the material sent after the DATA command is accepted and before the end of data indication is sent 🏁. Message content includes the message headers and the possibly-structured message body 🎁. The MIME specification [12] gives the standard mechanisms for structured message bodies 🌈.

---

2.3.10 Mailbox and Address 📫

in this spec, an "address" is a character string that identifies a user who will get mail, or a location where mail gets deposited 🏡. "Mailbox" refers to that depository 📭. The two terms are usually used interchangeably, unless the difference between the place where mail is stored (the mailbox) and the reference to it (the address) matters 🧐. An address normally has user and domain specifications 👤🌍. The standard mailbox naming convention is "local-part@domain", but contemporary usage allows way more than simple "user names" 💅.

Because of that, and because intermediate hosts have a long history of breaking things when they try 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.3.11 Reply 💬

an SMTP reply is an acknowledgment, positive or negative, sent from receiver to sender over the transmission channel in response to a command 📨. It's usually a numeric completion code (showing failure or success) followed by a text string 🔢. The codes are for programs, and the text is usually for human users 🧑‍💻. Recent work [34] has specified more structure for the reply strings, including supplemental and more specific completion codes 🪄🎀

2.4. General Syntax Principles and Transaction Model ✨

okay so SMTP commands and replies have a super rigid syntax 🎀 every command starts with a command verb, and every reply starts with a three digit numeric code 🔢 some commands and replies MUST have arguments that follow the verb or reply code, some commands don't take any arguments after the verb, and some reply codes get followed (sometimes optionally) by free form text 💅 whenever text shows up, it's separated from the verb or reply code by a space character. the full definitions of every command and reply are in section 4 🦋

verbs and argument values are not case sensitive 🌸 so "TO:" and "to:" in the RCPT command mean the same thing, and so do extension name keywords. the one big exception in this spec is the local-part of a mailbox (SMTP Extensions are allowed to make their own elements case-sensitive, though). so a command verb, an argument value other than a local-part, and free form text MAY be written in upper case, lower case, or any mix of the two, and the meaning doesn't change at all. but the local-part of a mailbox is a different story 🙈 it MUST BE treated as case sensitive, which means SMTP implementations MUST take care to preserve the case of mailbox local-parts. mailbox domains are not case sensitive, though. for some hosts, the user "smith" is literally a different person from "Smith" 😭 exploiting that case sensitivity messes with interoperability, so it's discouraged. honestly just don't do it 🫶

a few SMTP servers ignore this spec (and RFC 821) and insist that clients send command verbs in upper case 🙄 implementations MAY wish to use that encoding so they can work with those servers. it's a little annoying but totally valid ✨

the argument field is a variable length character string that ends with the end of the line, which is the character sequence <CRLF>. the receiver won't do anything until it gets that sequence 🍓

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 up of characters from the ASCII character set [1]. when the transport service gives you an 8-bit byte (octet) channel, each 7-bit character gets sent right justified in an octet, with the high order bit cleared to zero 🧚 more specifically, the unextended SMTP service only provides seven bit transport. an originating SMTP client that hasn't successfully negotiated an appropriate extension with a particular server MUST NOT transmit messages with information in the high-order bit of octets 🚫 if messages get sent anyway 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 received is valid, and as long as the envelope allows it, relay it without inspecting that content 🫧 but if the content is mislabeled and the data path can't handle what's actually in there, the recipient could end up with a seriously garbled message. delivery SMTP systems MAY reject ("bounce") such messages instead of delivering them 🥲

no sending SMTP system is allowed to send envelope commands in any character set other than US-ASCII, and receiving systems SHOULD reject such commands, normally with "500 syntax error - invalid character" replies ✨ the "500 syntax error - invalid character" reply is the one you'll want to remember 💅

eight-bit message content transmission MAY be requested of the server by a client using extended SMTP facilities, notably the "8BITMIME" extension [20]. 8BITMIME SHOULD be supported by SMTP servers 🌈 however, it MUST not be construed as authorization to send unrestricted eight bit material. 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 you're not familiar with that syntax, go check the ABNF specification [8] 📖 metalanguage terms used in running text are wrapped in pointed brackets (like <CRLF>) so they stand out 💜

---

3. The SMTP Procedures: An Overview 🌟

this section walks through the procedures SMTP uses: session initiation, the mail transaction, forwarding mail, verifying mailbox names and expanding mailing lists, and the 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 answers 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 it way easier to isolate and fix problems 🔧 implementations MAY make provision for SMTP servers to disable the software and version announcement where it causes security concerns 🔒 some systems also list their contact point for mail problems, but that is NOT a substitute for maintaining the required "postmaster" address (see section 4.5.1) 📮

wait, careful, "NOT" there is standalone, not a key word, so I'll keep it as plain text. (Revised below.)

Final version of that paragraph:

SMTP server implementations MAY include identification of their software and version information in the connection greeting reply after the 220 code, which makes it way easier to isolate and fix problems 🔧 implementations MAY make provision for SMTP servers to disable the software and version announcement where it causes security concerns 🔒 some systems also list their contact point for mail problems, but that is not a substitute for maintaining the required "postmaster" address (see section 4.5.1) 📮

the SMTP protocol lets a server formally reject a transaction 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 a system like that 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

once the server has sent the welcoming message and the client has received it, the client normally sends the EHLO command to the server to say who it is 👋 along with opening the session, using EHLO tells the server the client can handle service extensions, and it asks the server for a list of the extensions it supports ✨ older SMTP systems that can't support service extensions, and modern clients that don't need them for the session being started, MAY use HELO instead of EHLO 🕰️ servers MUST NOT return the extended EHLO-style response to a HELO command 🚫 and for a given connection attempt, if the server replies "command not recognized" to EHLO, the client SHOULD be able to fall back and send HELO 🔁

in the EHLO command, the sending host identifies itself. the command can be read as saying "Hello, I am <domain>" (and, in the case of EHLO, "and I support service extension requests") 💜

3.3 Mail Transactions ✨

Okay so bestie, an SMTP mail transaction is a three-step glow-up 💅 First there's the MAIL command, which says who's sending the mail. Then you get one or more RCPT commands for the receivers. Then DATA kicks off the actual message and ends with that "end of mail" data indicator, which also confirms the whole transaction 🫶 (Generally, the MAIL command may be sent only when no mail transaction is already in progress. See section 4.1.4 💖)

Step one is MAIL, obvi 🎀

MAIL FROM:<reverse-path> [SP <mail-parameters> ] <CRLF>

This tells the SMTP-receiver that a brand new transaction is starting, and that it should reset all its state tables and buffers 🧹 That includes any recipients and mail data from before. The <reverse-path> part of the first or only argument holds the source mailbox (between "<" 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 (aka it'll keep happening if the client tries the same address again) or temporary (aka the address might work if the client tries again later) 😭

Now here's the twist: the acceptability of the reverse-path sometimes can't be decided 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 after the forward-paths are received and examined. Normally, failures produce 550 or 553 replies.

Historically, the <reverse-path> could contain more than just a mailbox. However, contemporary systems SHOULD NOT use source routing (see appendix C). Not it 💀

The optional <mail-parameters> are tied to negotiated SMTP service extensions (see section 2.2) ✨

Step two is RCPT 🦋

RCPT TO:<forward-path> [ SP <rcpt-parameters> ] <CRLF>

The first or only argument 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 not to be deliverable, the server returns a 550 reply, usually with a string like "no such user - " and the mailbox name (other circumstances and reply codes are possible). This step can be repeated any number of times, so go wild 🌈

The <forward-path> can contain more than just a mailbox too. Historically, it could be 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 that's 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. 😭 Not a safe assumption, bestie.

If a 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) 🎀

Step three is DATA (or some alternative specified in a service extension) 🧚

DATA <CRLF>

If it's accepted, the server returns a 354 Intermediate reply and treats all the lines coming after it, up to but not including the end of mail data indicator, as the message text. When the end of the text is successfully received and stored, the SMTP-receiver sends a 250 OK reply 💖

Since the mail data goes over the same transmission channel, the end of mail data has to be marked so the command and reply dialog can pick back up. SMTP does this by sending a line containing only a . (period or full stop). A transparency procedure stops that dot from messing with the user's actual 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. If it's accepted, the server returns a 250 OK reply. Okay, but the DATA command can only fail at two points in the 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) is received, the client MUST NOT send the message data. More generally, message data MUST NOT be sent unless a 354 reply is 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, no recipients), if resources were unavailable (including, of course, the server unexpectedly becoming unavailable), or if the server decides the message should be rejected for policy or other reasons 🔥

However, in practice, some servers don't do recipient verification until after the message text is 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. Using a "550 mailbox not found" (or equivalent) reply code after the data is accepted makes it difficult or impossible for the client to figure out which recipients failed 😭

When RFC 822 format [7, 32] is being used, the mail data includes memo header items like Date, Subject, To, Cc, and From. Server SMTP systems SHOULD NOT reject messages based on perceived defects in the RFC 822 or MIME [12] message header or message body. In particular, they MUST NOT reject messages where the numbers of Resent-fields don't match, or where Resent-to shows up without Resent-from and/or Resent-date 🫶

Mail transaction commands MUST be used in the order discussed above. No skipping steps, bestie 💅

---

3.4 Forwarding for Address Correction or Updating 🦋

Forwarding support is most often needed to consolidate and simplify addresses within, or relative to, some enterprise. Less frequently, it's used to link a person's prior address with their current one 🌸 Silent forwarding of messages (without notifying the sender), for security or non-disclosure purposes, is pretty common on the contemporary Internet 🕵️‍♀️

In both the enterprise and the "new address" cases, information hiding (and sometimes security) considerations argue against exposing the "final" address through the SMTP protocol as a side effect of the forwarding activity. This matters a lot when the final address may not even be reachable by the sender 👀 So, the "forwarding" mechanisms described in section 3.2 of RFC 821, and 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 🧐

In particular:

• Servers MAY forward messages when they're aware of an address change. When they do, they MAY either provide address-updating information with a 251 code, or forward "silently" and return a 250 code. But, if a 251 code 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 or bounce messages when they're not deliverable as addressed. When they do, they MAY either provide address-updating information with a 551 code, or may reject the message as undeliverable with a 550 code and no address-specific information. But, if a 551 code 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 are strongly encouraged to provide configuration mechanisms, so that sites which conclude they'd undesirably disclose information can disable or restrict their use. Privacy queen behavior 👑🌈

---

3.5 Commands for Debugging Addresses ✨

3.5.1 Overview ✨

okay so SMTP has these two commands, VRFY and EXPN 🫶. they check if a user name is real or peek inside a mailing list, and both take a character string argument. Implementations SHOULD support VRFY and EXPN (but see section 3.5.2 and 7.3, there's some drama 💀).

for VRFY, the string is a user name, or a user name plus a domain (more on that below). if you get a normal (i.e., 250) response, the reply MAY include the full name of the user and MUST include their mailbox 💖. it MUST be in one of these two forms:

User Name <local-part@domain>
local-part@domain

if a name you send to VRFY could match more than one mailbox, the server MAY either point out the ambiguity or list the options 👀. so all of these are legit replies to VRFY:

553 User ambiguous

or

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 🌸. sticking to these exact forms, plus the "user ambiguous" or "ambiguous" keywords (maybe with extended reply codes like the ones in [34]), makes it way easier to auto-translate into other languages 🌈. a client that's super automated, or that runs in a language that isn't English, could totally choose to translate the reply, show the user something other than the literal text, or do something automatic first, like checking a directory service for more info before reporting back ✨.

for EXPN, the string names a mailing list, and a successful (i.e., 250) multiline reply MAY include the full names of the users and MUST list the mailboxes on that mailing list 📬.

on some hosts, a mailing list and an alias for a single mailbox are kinda blurry, because one data structure can hold both, and a mailing list can have only one mailbox in it 🦋. if someone asks VRFY about a mailing list, a positive reply MAY be sent if a message addressed to it 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 reply with a list holding just that one name, or an error MAY be reported (like "550 That is a user name, not a mailing list") 💅.

when a multiline reply succeeds (which is normal for EXPN), each line has to name exactly one mailbox 🍓. we already talked about the ambiguous case above.

"user name" is a fuzzy term, and that's on purpose 🧚. an implementation of VRFY or EXPN MUST at least recognize local mailboxes as "user names". but since current Internet practice often has one host handling mail for multiple domains, hosts (especially the ones offering this feature) SHOULD accept the "local-part@domain" form as a "user name", and hosts MAY also choose to recognize 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 like this:

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 implementations handle user names and mailbox lists in so many different ways 🎀. on some systems, the EXPN argument might be a file name for a file holding a mailing list, but the Internet has a bunch of file naming conventions too 🫠. the replies from these commands have also varied a lot over time, so the response SHOULD be read very carefully (if at all) and SHOULD generally only be used for diagnostic purposes 🔍.

3.5.2 VRFY Normal Response 💌

when VRFY or EXPN gets a normal reply (2yz or 551), the reply normally includes the mailbox name, i.e., "<local-part@domain>", where "domain" is a fully qualified domain name, and this MUST appear in the syntax 🧁. only in situations exceptional enough to justify breaking the spirit of this spec MAY free-form text be returned 😭. so that both computers and people can parse it, 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 🔥. that means 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 turn off either or both commands through configuration options or something equivalent 🔐. when these commands are supported, they don't have to work across relays when relaying is supported 🌸. because both were optional in RFC 821, they MUST be listed as service extensions in an EHLO response, if they're supported 📋.

3.5.3 Meaning of VRFY or EXPN Success Response 🥹

a server MUST NOT return a 250 code in reply 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 noted elsewhere, actually validating addresses and returning info for VRFY and EXPN is strongly recommended 🫶. so implementations that return 500 or 502 for VRFY aren't in full compliance with this spec 😤.

there can be times when an address looks valid but can't realistically be verified in real time, especially when a server acts as a mail exchanger for another server or domain 🦋. "apparent validity" in that case would normally involve at least syntax checking, and might involve checking that the domains listed are ones the host expected to relay mail for 🌈. in these situations, reply code 252 SHOULD be returned 💅. these cases match the RCPT verification talk in section 2.1 🧚. likewise, section 3.4 applies to using reply codes 251 and 551 with VRFY (and EXPN), to flag addresses that are recognized but would be forwarded or bounced 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 bit longer 🏃‍♀️✨.

3.5.4 Semantics and Applications of EXPN 🧩

EXPN is super useful for debugging and figuring out what's going wrong with mailing lists and aliases that point to multiple targets 🔍. some systems have tried to use source expansion of mailing lists to get rid of duplicates 🙈. but aliasing is everywhere on the Internet now: for hosts (usually with MX and CNAME DNS records), for mailboxes (all sorts of local host aliases), and in different proxying setups. that has made it nearly impossible for these strategies to work consistently, so mail systems SHOULD NOT attempt them 🚫💀.

3.6 Domains 🌍

only resolvable, fully-qualified domain names (FQDNs) are allowed when domain names show up in SMTP 🎀. in other words, names that can be resolved to MX RRs or A RRs (as talked about in section 5) are fine, and so are CNAME RRs whose targets can in turn be resolved to MX or A 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 A RR) or, if the host has no name, an address literal as described in section 4.1.1.1 💖.
• the reserved mailbox name "postmaster" may be used in a RCPT command without domain qualification (see section 4.1.1.3), and it MUST be accepted if used that way 👑.

3.7 Relaying 💌

Okay so, bestie, the availability of Mail eXchanger records in the domain name system [22, 27] makes explicit source routes in the Internet mail system basically unnecessary 🙈 Lots of historical problems came from interpreting them, so they're pretty undesirable now. 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, servers are also allowed to ignore it and just send to the final destination, which is the last element in the route, and they SHOULD do so ✨

There's a sketchy practice where people use names that don't exist in the DNS as destinations, counting on the intermediate hosts in the source route to sort out the mess 💀 If source routes get stripped, that's going to fail. 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 from RFC 821 for building a reverse-path from the forward-path doesn't apply. The reverse-path at delivery time will just be the address that showed up in the MAIL command 🦋

A relay SMTP server is usually the target of a DNS MX record that points to it, not the final delivery system 🌸 The relay can accept or reject the job of relaying the mail the same way it would accept or reject mail for a local user. If it accepts, 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 the mail along 💅 If it refuses to relay to a certain address for policy reasons, a 550 response SHOULD be returned 🔥

Lots of mail-sending clients exist, especially alongside facilities that get mail through POP3 or IMAP, and they have limited ability to meet some of this spec's requirements, like queuing messages for later delivery attempts 🧚 For these clients it's common to make private arrangements that send everything to one server for processing and distribution. SMTP as specified here isn't ideally suited for that role, and work is underway on standardized mail submission protocols that might eventually supersede current practice ✨ Anyway, those arrangements are private and outside this spec's scope, so they aren't described here.

It's important to know that MX records can point to SMTP servers that act as gateways into other environments, not just relays and final delivery systems 🌈 See sections 3.8 and 5.

If an SMTP server accepted the job of relaying mail and later finds out the destination is wrong or the mail can't be delivered for some other reason, 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 (see, for example, [24, 25]) SHOULD be used if possible 💖

This notification has to come from the SMTP server at the relay host, or from the host that first figures out that delivery can't happen 🎀 And obviously, SMTP servers MUST NOT send notification messages about problems transporting notification messages 💀 One way to avoid loops in error reporting is to use a null reverse-path in the MAIL command of a notification message. When a message like that is transmitted, the reverse-path MUST be set to null (see section 4.5.5 for additional discussion) 🙈 A MAIL command with a null reverse-path looks like this:

MAIL FROM:<>

As discussed in section 2.4.1, a relay SMTP has no reason to inspect or act on the headers or body of the message data, and it MUST NOT do so, except to add its own "Received:" header (section 4.4) and, optionally, to try detecting looping in the mail system (see section 6.2) 🔥

3.8 Mail Gatewaying 🌉

So the relay function we just talked about works inside the Internet SMTP transport service environment, but MX records or different kinds of explicit routing might require an intermediate SMTP server to translate between one transport service and another 🦋 As discussed in section 2.3.8, when 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 complicated and doesn't really lend itself to standardization 😭 Still, some general requirements can be given for a gateway between the Internet and another mail environment ✨

3.8.1 Header Fields in Gatewaying 💅

Header fields MAY be rewritten when needed as messages are gatewayed across mail environment boundaries 🌸 This might mean inspecting the message body or interpreting the local-part of the destination address, despite the prohibitions in section 2.4.1 🙈

Other mail systems gatewayed to the Internet often use a subset of RFC 822 headers or give similar functionality with different syntax, but some of them don't have anything 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. One possible fix is creating new header fields to carry the envelope info (for example, "X-SMTP-MAIL:" and "X-SMTP-RCPT:"). But that would need changes in mail programs in foreign environments and might risk disclosing private information (see section 7.2) 💀

3.8.2 Received Lines in Gatewaying 📬

When a gateway forwards a message into or out of the Internet environment, it MUST prepend a Received: line, but it MUST NOT alter in any way a Received: line that's already in the header 🎀

"Received:" fields from messages originating in other environments might not conform exactly to this spec 🌈 Still, the most important use of Received: lines is debugging mail faults, and well-meaning gateways that try to "fix" a Received: line can seriously wreck that debugging 😭 Another consequence of trace fields coming from non-SMTP environments is that receiving systems MUST NOT reject mail based on the format of a trace field, and they SHOULD be extremely robust when they see unexpected information or formats in those fields 💖

The gateway SHOULD indicate the environment and protocol in the "via" clauses of the Received field(s) it supplies 🫶

3.8.3 Addresses in Gatewaying 🌷

From the Internet side, the gateway SHOULD accept all valid address formats in SMTP commands and in RFC 822 headers, and all valid RFC 822 messages 💜 Addresses and headers that gateways generate MUST conform to applicable Internet standards (including this one and RFC 822) 🔥 Gateways are, of course, subject to the same rules for handling source routes as the ones described for other SMTP systems in section 3.3 ✨

3.8.4 Other Header Fields in Gatewaying 🍓

The gateway MUST ensure that all header fields of a message it forwards into the Internet mail environment meet the requirements for Internet mail 💅 Specifically, all addresses in "From:", "To:", "Cc:", etc., fields MUST be transformed (if necessary) to satisfy RFC 822 syntax, MUST reference only fully-qualified domain names, and MUST be effective and useful for sending replies 😭 The translation algorithm used to convert mail from Internet protocols to another environment's protocol SHOULD ensure that error messages from the foreign mail environment get delivered to the return path from the SMTP envelope, not to the sender listed in the "From:" field (or other fields) of the RFC 822 message 🎀

3.8.5 Envelopes in Gatewaying 💌

Similarly, when forwarding a message from another environment into the Internet, the gateway SHOULD set the envelope return path to match 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.9 Terminating Sessions and Connections 👋

An SMTP connection gets terminated when the client sends a QUIT command. The server responds with a positive reply code, and after that it closes the connection 🌸

An SMTP server MUST NOT intentionally close the connection except:

• After receiving a QUIT command and responding with a 221 reply.
• After detecting the need to shut down the SMTP service and returning a 421 response 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).

In particular, a server that closes connections in response to commands it doesn't understand is violating this spec 💀 Servers are expected to be tolerant of unknown commands, issuing a 500 reply and waiting for further instructions from the client 🧚

An SMTP server that's forcibly shut down through external means SHOULD try 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 because of circumstances outside their control (which violates the intent of this spec but is sometimes unavoidable) SHOULD, to keep the mail system robust, treat the mail transaction as if a 451 response had been received and act accordingly 💖

3.10 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, the return address in the envelope ("MAIL FROM:") MUST be changed to the address of a person or other entity who administers the list 🔥 In this case, though, the message header [32] MUST be left unchanged. Specifically, the "From" field of the message header is unaffected 💅

An important mail facility is a mechanism for multi-destination delivery of a single message, where a pseudo-mailbox address gets transformed (or "expanded" or "exploded") into a list of destination mailbox addresses 🦋 When a message is sent to one of these pseudo-mailboxes (sometimes called an "exploder"), copies get forwarded or redistributed to each mailbox on the expanded list 👑 Servers SHOULD simply use the addresses on the list. Applying heuristics or other matching rules to drop some addresses, like the originator's, is strongly discouraged 😭 We classify such a pseudo-mailbox as an "alias" or a "list", depending on the expansion rules 🌸

3.10.1 Alias 🎭

To expand an alias, the recipient mailer just swaps the pseudo-mailbox address in the envelope for each of the expanded addresses, one at a time. The rest of the envelope and the message body stay unchanged 🫶 The message then gets delivered or forwarded to each expanded address ✨

3.10.2 List 💌

Okay so a mailing list can be said to work by "redistribution" instead of "forwarding," and that's a whole vibe 🦋. To expand a list, the recipient mailer swaps the pseudo-mailbox address in the envelope for all of the expanded addresses. The return address in the envelope also gets changed, so every error message from the final deliveries goes to a list administrator instead of the message originator. The originator usually has zero control over what's on the list and would just find those error messages annoying 😭

4. The SMTP Specifications ✨

4.1 SMTP Commands 💅

4.1.1 Command Semantics and Syntax 🧚

The SMTP commands define the mail transfer or mail system function that the user requests 💖. They're character strings terminated by <CRLF>. The commands themselves are alphabetic characters, terminated by <SP> if parameters follow and by <CRLF> otherwise. (For improved interoperability, SMTP receivers are encouraged to 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 specified in section 4.1.2. The SMTP commands are discussed below, and the SMTP replies are discussed in section 4.2.

A mail transaction involves several data objects that get passed as arguments to different commands. The reverse-path is the argument of the MAIL command, the forward-path is the argument of the RCPT command, and the mail data is the argument of the DATA command. These arguments or data objects must be transmitted and held pending the confirmation communicated by the end of mail data indication, which finalizes the transaction. The model is that distinct buffers hold the types of data objects: there's a reverse-path buffer, a forward-path buffer, and a mail data buffer. Specific commands cause information to be appended to a specific buffer, or cause one or more buffers to be cleared 🌸.

Several commands (RSET, DATA, QUIT) are specified as not permitting parameters. Unless specific extensions are offered by the server and accepted by the client, clients MUST NOT send such parameters, and servers SHOULD reject commands containing them as having invalid syntax 🙅

4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO) 🎀

These commands identify the SMTP client to the SMTP server 🪞. The argument field contains the fully-qualified domain name of the SMTP client if one is available. If the SMTP client system doesn't have a meaningful domain name (for example, when its address is dynamically allocated and no reverse mapping record is available), the client SHOULD send an address literal (see section 4.1.3), optionally followed by information that will help identify the client system. The SMTP server identifies itself to the SMTP client in the connection greeting reply and in the response to this command.

A client SMTP SHOULD start an SMTP session by issuing the EHLO command. If the SMTP server supports the SMTP service extensions, it will give a successful response, a failure response, or an error response. If the SMTP server, in violation of this specification, does not 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. In any event, a client MUST issue HELO or EHLO before starting a mail transaction 🔥

These commands, and a "250 OK" reply to one of them, confirm that both the SMTP client and the SMTP server are in the initial state. That means there's no transaction in progress and all state tables and buffers are cleared 🧹

Syntax:

ehlo            = "EHLO" SP Domain CRLF
helo            = "HELO" SP Domain CRLF

Normally, the response to EHLO will be a multiline reply. Each line of the response contains a keyword and, optionally, one or more parameters. Following the normal syntax for multiline replies, these keywords follow the code (250) and a hyphen for all but the last line, and the code and a space for the last line. The syntax for a positive response, using the ABNF notation and terminal symbols of [8], is:

ehlo-ok-rsp  =    ( "250"    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-127)
             ; any CHAR excluding <SP> and all
             ; control characters (US-ASCII 0-31 inclusive)

Although EHLO keywords may be specified in upper, lower, or mixed case, they MUST always be recognized and processed in a case-insensitive manner. This is simply an extension of practices specified in RFC 821 and section 2.4.1 💜

4.1.1.2 MAIL (MAIL) 💌

This command initiates a mail transaction in which the mail data is delivered to an SMTP server, which may in turn deliver it to one or more mailboxes or pass it on to another system (possibly using SMTP). The argument field contains a reverse-path and may contain optional parameters. In general, the MAIL command may be sent only when no mail transaction is in progress, see section 4.1.4.

The reverse-path consists of 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 types of reporting messages for which a reply is likely to cause a mail loop (for example, mail delivery and nondelivery notifications), the reverse-path may be null (see section 3.7) 🔄

This command clears the reverse-path buffer, the forward-path buffer, and the mail data buffer, and inserts the reverse-path information from this command into the reverse-path buffer 🧼

If service extensions were negotiated, the MAIL command may also carry parameters associated with a particular service extension ✨

Syntax:

"MAIL FROM:" ("<>" / Reverse-Path)
                       [SP Mail-parameters] CRLF

4.1.1.3 RECIPIENT (RCPT) 🦋

This command identifies an individual recipient of the mail data. Multiple recipients are specified by multiple uses of this command. The argument field 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 utilize the domain name associated with the mailbox as if the source route had not been provided 🗺️

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 (the forward-path contains only a destination mailbox), the SMTP server inserts it into the destination mailbox in accordance with its host mail conventions 💖

For example, mail received at relay host xyz.com with envelope commands

MAIL FROM:<userx@y.foo.org>
RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org>

will normally be sent directly on to host d.bar.org with envelope commands

MAIL FROM:<userx@y.foo.org>
RCPT TO:<userc@d.bar.org>

As provided in appendix C, xyz.com MAY also choose to relay the message to hosta.int, using the envelope commands

MAIL FROM:<userx@y.foo.org>
RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org>

or to jkl.org, using the envelope commands

MAIL FROM:<userx@y.foo.org>
RCPT TO:<@jkl.org:userc@d.bar.org>

Of course, since hosts are not 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 associated with a particular service extension offered by the server. The client MUST NOT transmit parameters other than those associated with a service extension offered by the server in its EHLO response 🫶

Syntax:

"RCPT TO:" ("<Postmaster@" domain ">" / "<Postmaster>" / Forward-Path)
                    [SP Rcpt-parameters] CRLF

4.1.1.4 DATA (DATA) 📨

okay bestie, so after you send DATA the receiver usually replies with a 354, which basically means "go ahead, spill the mail" 💌 Then every line you send that ends in a <CRLF> (see section 2.3.7) counts as mail data from the sender. This command adds all that stuff to the mail data buffer. The mail data can have 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 on it, so the sequence "<CRLF>.<CRLF>" (see section 4.5.2). That's the end of mail data indication 🎀 The first <CRLF> of that terminator is also the one that ends the last line of your message. If there was no data at all, it ends the DATA command itself. An extra <CRLF> MUST NOT be added, because that would sneak an empty line into the message, which is so not it 💀 The only exception is if the message body got handed to the originating SMTP-sender with a final "line" that doesn'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 spot the "end of data" condition.

Some systems accept lines that end only in <LF>. This was a concession to some UNIX systems that didn't behave, and honestly it has caused more interoperability drama than it's ever solved 😭 So SMTP server systems MUST NOT do this, even in the name of "improved robustness." Bare line feeds without carriage returns, "<LF>.<LF>", MUST NOT be treated as equivalent to <CRLF>.<CRLF> as the end of mail data indication. No cap, don't be that server 🚫

Receiving the end of mail data indication means the server has to process the stored mail transaction information. That processing uses up everything in the reverse-path buffer, the forward-path buffer, and the mail data buffer, and once this command finishes, all three get cleared ✨ If the processing works, the receiver MUST send an OK reply. If it fails, the receiver MUST send a failure reply. SMTP doesn't do partial failures at this point, so it's one or the other: the server either accepts the message for delivery and sends a positive response, or it doesn't accept it and sends a failure reply. When the receiver sends a positive completion reply to the end of data indication, it takes full responsibility for the message (see section 6.1) 👑 Any errors that get diagnosed later MUST be reported in a mail message, as discussed in section 4.4.

When the SMTP server accepts a message, whether for relaying or final delivery, it adds a trace record at the top of the mail data. This is also called a "time stamp line" or a "Received" line, and it's giving paper trail 📜 It says which host sent the message, which host received it (and is adding this time stamp), and the date and time it arrived. Relayed messages end up with multiple time stamp lines. The details of how these lines get formed, including their syntax, are in section 4.4.

There's more about how DATA works in section 3.3.

Syntax:

"DATA" CRLF

4.1.1.5 RESET (RSET) 🧹

This command says the current mail transaction is getting aborted, so 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. The client can issue a reset at any time 💅 It's effectively the same as a NOOP (i.e., if has no effect) when it's 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. That's reserved for QUIT (see section 4.1.1.10). Don't ghost people with RSET, periodt 🙅‍♀️

RSET is usually more efficient than reissuing EHLO, since EHLO means extra processing and a response from the server. The formal semantics are still the same though 🦋

There are situations, against what this spec intends, where an SMTP server might get an indication that the underlying TCP connection has been closed or reset. To keep the mail system robust, SMTP servers SHOULD be ready for that and SHOULD treat it as if a QUIT had been received before the connection disappeared 🌸

Syntax:

"RSET" CRLF

4.1.1.6 VERIFY (VRFY) 🔍

This command asks the receiver to confirm that the argument identifies a user or a mailbox. If it's a user name, the info comes back the way section 3.5 describes 👀

This command has no effect on the reverse-path buffer, the forward-path buffer, or the mail data buffer.

Syntax:

"VRFY" SP String CRLF

4.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 it works, the reply contains info as described in section 3.5. That reply will have multiple lines, unless it's 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 issued at any time.

Syntax:

"EXPN" SP String CRLF

4.1.1.8 HELP (HELP) 🆘

This command makes the server send helpful info to the client 🫶 The command MAY take an argument (for example, 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 issued at any time.

SMTP servers SHOULD support HELP without arguments and MAY support it with arguments.

Syntax:

"HELP" [ SP String ] CRLF

4.1.1.9 NOOP (NOOP) 😴

This command doesn't change any parameters or previously entered commands. It doesn't do anything except make the receiver send an OK reply, which is very chill 🌈

This command has no effect on the reverse-path buffer, the forward-path buffer, or the mail data buffer, and it can be issued at any time. If a parameter string is specified, servers SHOULD ignore it.

Syntax:

"NOOP" [ SP String ] CRLF

4.1.1.10 QUIT (QUIT) 👋

This command says the receiver MUST send an OK reply, and then close the transmission channel. Bye bye, bestie 💜

The receiver MUST NOT intentionally close the transmission channel until it has received and replied 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 there was an error response to a previous command. If the connection gets closed early because of any of the violations above, or because of a system or network failure, the server MUST cancel any pending transaction. It does not undo any transaction that was already completed. It generally MUST act as if the command or transaction in progress had received a temporary error (i.e., a 4yz response) 💀

The QUIT command can be issued at any time.

Syntax:

"QUIT" CRLF

4.1.2 Command Argument Syntax 🧩

The syntax for the argument fields of the commands above is given below. It uses the syntax specified in [8] where that applies. Some of the productions here are only used with source routes, as described in appendix C. Terminals that aren't defined in this document, like ALPHA, DIGIT, SP, CR, LF, and CRLF, are defined in the "core" syntax [8 (section 6)] or in the message format syntax [32] 🎀

Reverse-path = Path
Forward-path = Path
Path = "<" [ A-d-l ":" ] Mailbox ">"
A-d-l = At-domain *( "," A-d-l )
      ; 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-127)
      ; any CHAR excluding "=", SP, and control characters
Keyword  = Ldh-str
Argument = Atom
Domain = (sub-domain 1*("." sub-domain)) / address-literal
sub-domain = Let-dig [Ldh-str]

address-literal = "[" IPv4-address-literal /
                      IPv6-address-literal /
                      General-address-literal "]"
      ; See section 4.1.3

Mailbox = Local-part "@" Domain

Local-part = Dot-string / Quoted-string
      ; MAY be case-sensitive

Dot-string = Atom *("." Atom)

Atom = 1*atext

Quoted-string = DQUOTE *qcontent DQUOTE

String = Atom / Quoted-string

While the Local-part definition above is pretty permissive, a host that expects to receive mail SHOULD avoid defining mailboxes where the Local-part requires (or uses) the Quoted-string form, or where the Local-part is case-sensitive, so things stay interoperable 🤝 For anything that needs to generate or compare Local-parts (like matching specific mailbox names), 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). These characters MUST NOT be used in MAIL or RCPT commands, or in other commands that require mailbox names. 🙅‍♀️

Note that the backslash, "\", is a quote character. It means the next character should be read literally, instead of with its normal meaning. For example, "Joe\,Smith" is a single nine character user field, with the comma as the fourth character of the field ✨

To promote interoperability, and to match long-standing guidance about being conservative with the DNS when naming things and building applications (for example, see section 2.3.1 of the base DNS document, RFC1035 [22]), characters outside the set of alphas, digits, and hyphen MUST NOT appear in domain name labels for SMTP clients or servers. In particular, the underscore character is not permitted 🚫 SMTP servers that receive a command with invalid character codes, and where there's no other reason to reject it, MUST reject that command with a 501 response.

4.1.3 Address Literals 🦋

okay so sometimes a host isn't in the domain name system at all, and then communication gets blocked, including the messages you'd need to report and fix the problem 💀 🙈. to get around that barrier, there's a special literal form of the address you can use instead of a domain name. for IPv4, it's four small decimal integers separated by dots and wrapped in brackets, like [123.255.37.2], which means an (IPv4) Internet Address in sequence-of-octets form. for IPv6 and any other addressing that might get standardized later, it's a standardized "tag" that names the address syntax, then a colon, then the address itself, in a format specified as part of the IPv6 standards [17] 🌈

Specifically:

   IPv4-address-literal = Snum 3("." Snum)
   IPv6-address-literal = "IPv6:" IPv6-addr
   General-address-literal = Standardized-tag ":" 1*dcontent
   Standardized-tag = Ldh-str
         ; MUST be specified in a standards-track RFC
         ; and registered with IANA

   Snum = 1*3DIGIT  ; representing a decimal integer
         ; value in the range 0 through 255
   Let-dig = ALPHA / DIGIT
   Ldh-str = *( ALPHA / DIGIT / "-" ) Let-dig

   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 👑

there are restrictions on the order in which these commands may be used, so pay attention bestie 📝

okay rule number one: a session that's going to have mail transactions in it MUST first get set up with the EHLO command 💌 an SMTP server SHOULD accept commands for non-mail transactions (e.g., VRFY or EXPN) without this initialization though 🦋

an EHLO command MAY be issued by a client later in the session. if it shows up after the session has already begun, the SMTP server MUST clear all buffers and reset the state exactly as if a RSET command had been issued. so basically, RSET followed right away by EHLO is redundant, but not harmful, except it costs performance for running commands you didn't need 🙄

if the EHLO command isn't acceptable to the SMTP server, 501, 500, or 502 failure replies MUST be returned as appropriate. the SMTP server MUST stay in the same state after sending these replies that it was in before the EHLO arrived 🛑

the SMTP client MUST, if possible, make sure the domain parameter to the EHLO command is a valid principal host name (not a CNAME or MX name) for its host. if that's not possible (like when the client's address is dynamically assigned and it doesn't have an obvious name), an address literal SHOULD be swapped in for the domain name, with supplemental information that helps identify the client 🎀

an SMTP server MAY verify that the domain name parameter in the EHLO command actually matches the IP address of the client. but the server MUST NOT refuse to accept a message for this reason if the check fails. the verification failure info is for logging and tracing only, not for gatekeeping 🫶

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 return a 503 code) even if no EHLO has been received yet, and clients SHOULD open a session with EHLO before sending these commands 💅

if these rules are followed, 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 is based on the client's IP address or other authentication or authorization-determining mechanisms 😭

the MAIL command (or the obsolete SEND, SOML, or SAML commands) starts a mail transaction. once it's started, a mail transaction is a transaction beginning command, one or more RCPT commands, and then a DATA command, in that order. a mail transaction can be aborted by the RSET (or a new EHLO) 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. so it should only be sent if no mail transaction has been started in the session, or it the previous one successfully concluded with a successful DATA command, or if the previous one was aborted with a RSET 🌸

if the transaction beginning command 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 QUIT command can't be used at any other time in a session, but SHOULD be used by the client SMTP to request connection closure, even when no session opening command was sent and accepted. it's the polite goodbye, honestly 🌙

---

4.1.5 Private-use Commands 🔐

as specified in section 2.2.2, commands starting with "X" may 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 💌

replies to SMTP commands keep everything in sync during mail transfer and make sure the SMTP client always knows the state of the SMTP server. so basically, the vibe is "every command gets exactly one reply, no ghosting" 👻 Every command MUST generate exactly one reply.

the details of the command-reply sequence are described 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 automata to figure out what state to enter next, and the text is for the human user 🤖 the three digits pack in enough encoded info that the SMTP client doesn't need to read the text at all. it can discard it or pass it along to the user, whichever makes sense 💅 exceptions are noted elsewhere in this document. the big ones are the 220, 221, 251, 421, and 551 reply codes, because their message text has to be parsed and interpreted by machines 🙈 in general the text can be receiver dependent and context dependent, so you'll likely see different texts for each reply code. the theory behind reply codes is discussed in section 4.2.1. formally, a reply is defined as: a three-digit code, <SP>, one line of text, and <CRLF>, or a multiline reply (as defined in section 4.2.1). since, in violation of this specification, the text is sometimes not sent, clients that don't receive it SHOULD be prepared to process the code alone (with or without a trailing space character). only the EHLO, EXPN, and HELP commands are expected to result in multiline replies in normal circumstances, but multiline replies are allowed for any command 🌈

in ABNF, server responses look like this:

   Greeting = "220 " Domain [ SP text ] CRLF
   Reply-line = Reply-code [ SP text ] CRLF

where "Greeting" only shows up in the 220 response that announces the server is opening its part of the connection 🎀

an SMTP server SHOULD send only the reply codes listed in this document. an SMTP server SHOULD use the text shown in the examples whenever appropriate 💖

an SMTP client MUST determine its actions only by the reply code, not by the text (except for the "change of address" 251 and 551 and, if necessary, 220, 221, and 421 replies). in general, any text, including no text at all (although senders SHOULD NOT send bare codes), MUST be acceptable. the space (blank) after the reply code counts as part of the text. whenever possible, a receiver-SMTP SHOULD test the first digit (severity indication) of the reply code 🔥

the list of codes below MUST NOT be construed as permanent. adding new codes should be rare and a big deal, with supplemental info in the textual part of the response being the preferred move, but new codes may still show up as the result of new Standards or Standards-track specifications 👑 so a sender-SMTP MUST be prepared to handle codes not specified in this document, and MUST do so by interpreting the first digit only 🧠✨

4.2.1 Reply Code Severities and Theory 💖

okay so each of the three digits in a reply has its own job 🔍 The first digit tells you if the response is good, bad, or still in progress. A simple SMTP client (or one that gets a code it wasn't expecting) can figure out its next move from that digit alone: proceed as planned, redo, retrench, etc. 💅 If the client wants to know roughly what kind of error happened (like a mail system error vs. a command syntax error), it can look at the second digit. The third digit and any extra info are for the finest-grained details ✨

There are five values for the first digit 🌈

• 1yz Positive Preliminary reply: The command was accepted, but the requested action is on hold until the information in this reply is confirmed. The SMTP client should send another command saying whether to continue or abort. Note: unextended SMTP doesn't have any commands that allow this kind of reply, so it also doesn't have continue or abort commands 🙈
• 2yz Positive Completion reply: The requested action finished successfully. A new request can be started 🎀
• 3yz Positive Intermediate reply: The command was accepted, but the requested action is on hold until more information arrives. The SMTP client should send another command with that information. This reply is used in command sequence groups (i.e., in DATA) 🧚
• 4yz Transient Negative Completion reply: The command wasn't accepted and the requested action didn't happen. The error is temporary though, so the action can be requested again. The sender should go back to the beginning of the command sequence (if there is one). "Transient" is tricky to pin down when two different sites (the receiver and sender SMTP agents) have to agree on what it means. Each reply in this category might have a different time value, but the SMTP client is encouraged to try again 🦋 A handy rule of thumb for telling a 4yz apart from a 5yz (see below): a reply is 4yz if it could succeed when repeated with no change in the command form or in the properties of the sender or receiver. That means the command gets repeated exactly the same way, and the receiver doesn't put up a new implementation.
• 5yz Permanent Negative Completion reply: The command wasn't accepted and the requested action didn't happen. The SMTP client is discouraged from repeating the exact same request (in the same sequence). Even some "permanent" errors can be fixed, so a human user may want to send the SMTP client back to start the command sequence later, after something changes (like the spelling getting fixed, or the user's account status being updated) 😭

The second digit groups the replies into specific categories 💜

• x0z Syntax: These replies cover syntax errors, syntactically correct commands that don't fit any functional category, and unimplemented or superfluous commands.
• x1z Information: These are replies to requests for information, like status or help 🌸
• x2z Connections: These replies are about the transmission channel 🍓
• x3z Unspecified.
• x4z Unspecified.
• x5z Mail 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 within each category set by the second digit. The reply list below shows how this works. Each reply's text is recommended rather than mandatory, and it may even change depending on the command it goes with 🌈 On the other hand, the reply codes themselves must strictly follow the specs in this section. Receiver implementations should not invent new codes for situations that are a bit different from the ones described here. They should adapt codes that are already defined instead 👑

Here's an 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 non-site-specific action. A refinement of that is the 504 reply, for a command that is implemented but asks for an unimplemented parameter ✨

Sometimes the reply text runs longer than one line. In those cases, the complete text has to be marked so the SMTP client knows when to stop reading. That calls for a special format for multiline replies 🎀

For multiline replies, every line except the last begins with the reply code, immediately followed by a hyphen, - (also known as minus), and then the text. The last line begins with the reply code, immediately followed by <SP>, then optionally some text, and then <CRLF>. As noted above, servers SHOULD send the <SP> if no subsequent text is sent, but clients MUST be prepared for it to be omitted 🫶

For example:

123-First line
123-Second line
123-234 text beginning with numbers
123 The last line

In a lot of cases, the SMTP client just needs to look for a line that begins with the reply code followed by <SP> or <CRLF>, and ignore all the lines before it. In a few cases there's important data for the client in the reply "text". The client can tell these cases apart from the current context 💅

4.2.2 Reply Codes by Function Groups 🧚

      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

      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
      421 <domain> Service not available, closing transmission channel
         (This may be a reply to any command if the service knows it
         must shut down)

      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)
      450 Requested mail action not taken: mailbox unavailable
         (e.g., mailbox busy)
      550 Requested action not taken: mailbox unavailable
         (e.g., mailbox not found, no access, or command rejected
         for policy reasons)
      451 Requested action aborted: error in processing
      551 User not local; please try <forward-path>
         (See section 3.4)
      452 Requested action not taken: insufficient system storage
      552 Requested mail action aborted: exceeded storage allocation
      553 Requested action not taken: mailbox name not allowed
         (e.g., mailbox syntax incorrect)
      354 Start mail input; end with <CRLF>.<CRLF>
      554 Transaction failed (Or, in the case of a connection-opening
          response, "No SMTP service here")

4.2.3 Reply Codes in Numeric Order 🌸

      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)
      451 Requested action aborted: local error in processing
      452 Requested action not taken: insufficient system storage
      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")

4.2.4 Reply Code 502 🙈

Questions have come up about when reply code 502 (Command not implemented) SHOULD be returned instead of other codes. 502 SHOULD be used when the SMTP server actually recognizes the command but doesn't implement it. If the command isn't recognized at all, code 500 SHOULD be returned. Extended SMTP systems MUST NOT list capabilities in response to EHLO that they will answer with 502 (or 500) replies 💀

4.2.5 Reply Codes After DATA and the Subsequent <CRLF>.<CRLF> 💌

When an SMTP server returns a positive completion status (2yz code) after the DATA command is completed with <CRLF>.<CRLF>, it takes 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).

When an SMTP server returns a permanent error status (5yz) code after the DATA command is completed with <CRLF>.<CRLF>, it MUST NOT make any subsequent attempt to deliver that message. The SMTP client keeps responsibility for delivering that message and may either return it to the user or requeue it for a later attempt (see section 4.5.4.1) 📬

The user who originated the message SHOULD be able to interpret the return of a transient failure status (by mail message or otherwise) as a non-delivery indication, just like a permanent failure would be interpreted. In other words, if the client SMTP successfully handles these conditions, the user won't receive such a reply ✨

When an SMTP server returns a permanent error status (5yz) code after the DATA command is completely with <CRLF>.<CRLF>, it MUST NOT make any subsequent attempt to deliver the message. As with temporary error status codes, the SMTP client keeps responsibility for the message, but it SHOULD not again attempt delivery to the same server without user review and intervention of the message 🫶

4.3 Sequencing of Commands and Replies 🦋

4.3.1 Sequencing Overview ✨

Okay so the chat between sender and receiver is an alternating dialogue, and the sender is totally in charge 💅. The sender issues a command, the receiver replies, and round and round we go. Unless other arrangements are negotiated through service extensions, the sender MUST wait for this response before sending further commands. 🫶

One super important reply is the connection greeting. Normally a receiver sends a 220 "Service ready" reply once the connection is completed, and the sender SHOULD wait for that 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 has no meaningful name at all, so see 4.1.3 for a discussion of alternatives in those situations. 🧚

For example, 🎀

220 ISIF.USC.EDU Service ready
or
220 mail.foo.com SuperSMTP v 6.1.2 Service ready
or
220 [10.0.0.1] Clueless host service ready

The 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 meaning and action implied by the code numbers and by the specific command reply sequence cannot be altered. No rewriting the vibe of the codes, bestie 💖

4.3.2 Command-Reply Sequences 💅

Each command is listed with its usual possible replies. The prefixes used before the possible replies are "I" for intermediate, "S" for success, and "E" for error. Since some servers may generate other replies under special circumstances, and to allow for future extension, SMTP clients SHOULD, when possible, interpret only the first digit of the reply, and they 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. Main character energy for the codes, honestly 👑

These sequencing rules and, in principle, the codes themselves, can be extended or modified by SMTP extensions offered by the server and accepted (requested) by the client. 🌈

In addition to the codes listed below, any SMTP command can return any of the following codes if the corresponding unusual circumstances are encountered:

• 500 is for the "command line too long" case, or if the command name was not recognized. Note that producing a "command not recognized" error in response to the required subset of these commands is a violation of this specification. 😭
• 501 is a syntax error in command or arguments. To provide for future extensions, commands that are specified in this document as not accepting arguments (DATA, RSET, QUIT) SHOULD return a 501 message if arguments are supplied in the absence of EHLO-advertised extensions. 🧚
• 421 is service shutting down and closing transmission channel. 💀

Specific sequences are: ✨

CONNECTION ESTABLISHMENT
   S: 220
   E: 554
EHLO or HELO
   S: 250
   E: 504, 550
MAIL
   S: 250
   E: 552, 451, 452, 550, 553, 503
RCPT
   S: 250, 251 (but see section 3.4 for discussion of 251 and 551)
   E: 550, 551, 552, 553, 450, 451, 452, 503, 550
DATA
   I: 354 -> data -> S: 250
                     E: 552, 554, 451, 452
   E: 451, 554, 503
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: 221

---

4.4 Trace Information 🦋

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. The vibe is "leave your receipts" 🧾

This line MUST be structured as follows:

• The FROM field, 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 field MAY contain an "@" as suggested in RFC 822, but this is not required. 🎀
• The FOR field MAY contain a list of <path> entries when multiple RCPT commands have been given. This may raise some security issues and is usually not desirable; see section 7.2. 🙈

An Internet mail program MUST NOT change a Received: line that was previously added to the message header. 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 timeline, periodt 💅

As the Internet grows, comparability of Received fields is important for detecting problems, especially slow relays. SMTP servers that create Received fields SHOULD use explicit offsets in the dates (e.g., -0800), rather than time zone names of any type. Local time (with an offset) is preferred to UT when feasible, because this formulation allows slightly more information about local circumstances to be specified. If UT is needed, the receiver need merely do some simple arithmetic to convert the values. Use of UT loses information about the time zone-location of the server. If it is desired to supply a time zone name, it SHOULD be included in a comment. Give the offset, not the vibe 🌍

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, this would mean it had been delivered to the destination user or an associated mail drop, but in some cases it may be further processed and transmitted by another mail system. 💌

It is possible for the mailbox in the return path to be different from the actual sender's mailbox, for example, if error responses are to be delivered to a special error handling mailbox rather than to the message sender. When mailing lists are involved, this arrangement is common and useful as a means of directing errors to the list maintainer rather than the message originator. The list maintainer is the one who gets the drama 🍓

The text above implies that the final mail data will begin with a return path line, followed by one or more time stamp lines. These lines will be followed by the mail data headers and body [32]. ✨

It is sometimes difficult for an SMTP server to determine whether or not it is making final delivery, since forwarding or other operations may occur after the message is accepted for delivery. Consequently, any further (forwarding, gateway, or relay) systems MAY remove the return path and rebuild the MAIL command as needed to ensure that exactly one such line appears in a delivered message. Tidy line, no duplicates 🧹

A message-originating SMTP system SHOULD NOT send a message that already contains a Return-path header. SMTP servers performing a relay function MUST NOT inspect the message data, and especially not to the extent needed to determine if Return-path headers are present. SMTP servers making final delivery MAY remove Return-path headers before adding their own. 🫣

The primary purpose of the Return-path is to designate the address to which messages indicating non-delivery or other mail system failures are to be sent. For this 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, associated with the transport envelope, to which error reports (e.g., non-delivery messages) should be sent. Error reports need a clear home 📬

Historical note: Text in RFC 822 that appears to contradict the use of the Return-path header (or the envelope reverse path address from the MAIL command) as the destination for error messages is not applicable 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, 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 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 in which the processing following 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 that the mail data could be successfully delivered to some, but not all, of the recipients. In such 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. Partial success is still a flex, but it needs a follow-up 🥺

A single notification listing all of the failed recipients or separate notification messages MUST be sent for each failed recipient. For economy of processing by the sender, the former is preferred when possible. All undeliverable mail notification messages are sent using the MAIL command (even if they result from processing the obsolete SEND, SOML, or SAML commands) and use a null return path as discussed in section 3.7. One group text beats a hundred DMs 💜

The time stamp line and the return path line are formally defined as follows: 🎀

Return-path-line = "Return-Path:" FWS Reverse-path <CRLF>

Time-stamp-line = "Received:" FWS Stamp <CRLF>

Stamp = From-domain By-domain Opt-info ";"  FWS date-time

      ; where "date-time" is as defined in [32]
      ; but the "obs-" forms, especially two-digit
      ; years, are prohibited in SMTP and MUST NOT be used.

From-domain = "FROM" FWS Extended-Domain CFWS

By-domain = "BY" FWS Extended-Domain CFWS

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]

Via = "VIA" FWS Link CFWS

With = "WITH" FWS Protocol CFWS

ID = "ID" FWS String / msg-id CFWS

For = "FOR" FWS 1*( Path / Mailbox ) CFWS

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).  SMTP servers
         ; SHOULD NOT use unregistered names.

4.5 Additional Implementation Issues 🧚

4.5.1 Minimum Implementation 💅

okay so, to make SMTP actually workable, every receiver needs this minimum set of commands 🎀. to conform, these commands MUST be supported:

EHLO
HELO
MAIL
RCPT
DATA
RSET
NOOP
QUIT
VRFY

any system with an SMTP server that does mail relaying or delivery MUST support the reserved mailbox "postmaster" as a case-insensitive local name 👑. the postmaster address isn't strictly necessary if the server always returns 554 on connection opening (as described in section 3.1), but accepting mail for postmaster means that RCPT commands naming a postmaster mailbox at any of the domains the server handles MUST be supported, and so does the special case RCPT TO:<Postmaster> with no domain specified ✨.

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 (like containing a denial of service attack or some other breach of security) an SMTP server may block mail directed to Postmaster 🛡️. however, those arrangements SHOULD be narrowly tailored so they don't block messages that aren't part of the attack 🧚.

4.5.2 Transparency 🦋

okay so without some kind of data transparency, the character sequence <CRLF>.<CRLF> ends the mail text, and the user literally can't send it 💀. users usually don't know about these "forbidden" sequences 🙈. so, to let all user-composed text get sent through transparently, these procedures are used:

• 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 may contain any of the 128 ASCII characters 🌈. all characters are to be 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 get transmitted right justified in the octets, with the high order bits cleared to zero 💜. see 3.7 for the special treatment of these conditions in SMTP systems that serve a relay function 🔁.

sometimes a system has to transform the data as it's received and stored 🔄. that might be needed 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 those transformations are necessary, they MUST be reversible, especially if they're applied to mail being relayed 🔐.

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 [16], will often need larger objects, so clients MAY attempt to transmit these, but they MUST be prepared for a server to reject them if the server can't handle them 🫠. to the maximum extent possible, implementation techniques that impose no limits on the length of these objects should be used 🌸.

local-part The maximum total length of a user name or other local-part is 64 characters.

domain The maximum total length of a domain name or number is 255 characters.

path The maximum total length of a reverse-path or forward-path is 256 characters (including the punctuation and element separators).

command line The maximum total length of a command line, including the command word and the <CRLF>, is 512 characters. SMTP extensions may be used to increase this limit.

reply line The maximum total length of a reply line, including the reply code and the <CRLF>, is 512 characters. More information may be conveyed through multiple-line replies.

text line The maximum total length of a text line, including the <CRLF>, is 1000 characters (not counting the leading dot duplicated for transparency). This number may be increased by the use of SMTP Service Extensions.

message content The maximum total length of a message content (including any message headers as well as the message body) MUST BE at least 64K octets. ever since multimedia mail standards [12] came along, message lengths on the Internet have grown dramatically 📈, so message size restrictions should be avoided if at all possible 🙏. SMTP server systems that must impose restrictions SHOULD implement the "SIZE" service extension [18], and SMTP client systems that will send large messages SHOULD utilize it when possible 💖.

recipients buffer The minimum total number of recipients that must be buffered is 100 recipients. rejecting messages (for having too many recipients) with fewer than 100 RCPT commands is a violation of this specification 🚫. the general principle is that relaying SMTP servers MUST NOT, and delivery SMTP servers SHOULD NOT, perform validation tests on message headers, which suggests that rejecting a message based on the total number of recipients shown in header fields is to be discouraged 🙃. 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 📦✨.

errors from exceeding these limits may be reported using reply codes. some examples:

500 Line too long.
   or
501 Path too long
   or
452 Too many recipients  (see below)
   or
552 Too much mail data.

RFC 821 [30] incorrectly listed the error where an SMTP server runs out of its implementation limit on RCPT commands ("too many recipients") as 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 those 100 addresses will be removed from the SMTP client's queue 🎉. when the client retransmits the addresses that got 452 responses, at least 100 of them will fit in the SMTP server's recipients buffer 💅. each retransmission attempt that can deliver anything will be able to dispose of at least 100 of these recipients 🫶.

if an SMTP server has an implementation limit on the number of RCPT commands and that 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 limit on the number of RCPT commands, it MAY instead use a 5XX response code 🌷. this would be most appropriate if the policy limit was meant to apply to the total recipient count for a particular message body, even when that body is sent across multiple mail transactions 🧾.

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 🙅‍♀️. timeouts SHOULD be easily reconfigurable, preferably without recompiling the SMTP code 🎀. to do this, a timer is set for each SMTP command and for each buffer of the data transfer, which means the overall timeout is inherently proportional to the size of the message 📐.

based on extensive experience with busy mail-relay hosts 🔥, the minimum per-command timeout values SHOULD be as follows:

Initial 220 Message: 5 minutes An SMTP client process needs to tell apart a failed TCP connection from a delay in receiving the initial 220 greeting message 👀. lots of SMTP servers accept a TCP connection but hold off on the 220 message until their system load allows more mail to be processed 😴.

MAIL Command: 5 minutes

RCPT Command: 5 minutes a longer timeout is required if processing of mailing lists and aliases is not deferred until after the message has been accepted 📬.

DATA Initiation: 2 minutes this is the wait for the "354 Start Input" reply to a DATA command ⏳.

Data Block: 3 minutes this is the wait for each TCP SEND call transmitting a chunk of data 📤.

DATA Termination: 10 minutes. this is the wait for 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 was already successfully sent and the server has accepted responsibility for delivery 😭. see section 6.1 for additional discussion 📖.

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 varies depending on what the users on the host need and how many mailing lists and how big they are 📋. we describe several optimizations that have proved helpful, especially for mailers handling 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 🚫💌.

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 setup, the program that writes the message has a way to say "hey, this one needs attention NOW" 🏃‍♀️. Mail that can't go out right away MUST be queued and retried periodically by the sender. Each queue entry holds not just the message but also the envelope info 📮

The sender MUST delay retrying a particular destination after one attempt has failed. Generally the retry interval SHOULD be at least 30 minutes 🕧. Fancier, variable strategies are awesome when the client can figure out why delivery didn't work 🧠

Retries keep going until the message gets through or the sender gives up. The give-up time generally needs to be at least 4-5 days 📅, and 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, instead of just retrying every queued item over and over 🙅‍♀️

Experience says failures are usually transient (the target system or its connection 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 🕰️

The SMTP client can shorten the queuing delay by working with the SMTP server 🤝. For example, if mail arrives from a particular address, it's likely that mail queued for that host can now be sent 🎉. Applying this principle can, in lots of cases, get rid of the need for an explicit "send queues now" function like ETRN [9] 🙌

The strategy may be tweaked further based on multiple addresses per host (see below) to balance delivery time vs. resource usage ⚖️

An SMTP client might have a huge queue for each unavailable destination host 📦. If all of those messages got retried every cycle, there'd be excessive Internet overhead, and the sending system would be blocked for ages 😩. Note that a client can usually only tell a delivery attempt failed after a timeout of several minutes, and even a one-minute timeout per connection adds up to a massive delay if you retry 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 is issued multiple times during the same SMTP connection, different answers may come back from the server 🤷‍♀️. More significantly, 5yz responses to the MAIL command MUST NOT be cached 🚫

When a message is going to multiple recipients, and the SMTP server receiving a copy 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 the sequence MAIL, RCPT, DATA, ..., MAIL, RCPT, DATA 💅. However, if there are very many addresses, a limit on the number of RCPT commands per MAIL command MAY be imposed. Implementing this efficiency feature is strongly encouraged 🫶

Similarly, to achieve timely delivery, the SMTP client MAY support multiple concurrent outgoing mail transactions 🏎️. Some limit may be appropriate, though, to protect the host from devoting all its resources to mail 🛑

4.5.4.2 Receiving Strategy 📥

The SMTP server SHOULD try to keep a pending listen on the SMTP port at all times 👀. This requires 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 are not in conformance with the intent of this specification 🚨

As discussed above, when the SMTP server receives 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 types 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) [24], and Message Disposition Notifications (MDNs) [10]. 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 points to a problem with the mail system of the host the notification is addressed to. For this reason, at some hosts the MTA is set up to forward such failed notifications to someone who can fix problems with the mail system, e.g., via the postmaster alias 🛠️

Every other type of message (anything that isn't required by a standards-track RFC 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 the various kinds of messages with a null reverse-path get handled correctly. In particular, such systems SHOULD NOT reply to messages with a null reverse-path 🙅‍♀️

5. Address Resolution and Mail Handling 🗺️

Once an SMTP client lexically identifies a domain that mail will be delivered to for processing (as described in sections 3.6 and 3.7), a DNS lookup MUST be performed to resolve the domain name [22] 🔍. 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 and, due to a history of problems, are generally discouraged 🙃

The lookup first attempts to locate an MX record for the name. If a CNAME record is found instead, the resulting name is processed as if it were the initial name 🔀. If no MX records are found but an A RR is found, the A RR is treated as if it were associated with an implicit MX RR, with a preference of 0, pointing to that host 📍. If one or more MX RRs are found for a given name, SMTP systems MUST NOT utilize any A RRs associated with that name unless they are located using the MX RRs. The "implicit MX" rule above applies only 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 the lookup succeeds, the mapping can result in a list of alternative delivery addresses rather than 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. However, there MAY also be a configurable limit on the number of alternate addresses that can be tried 🔢. In any case, the SMTP client SHOULD try at least two addresses 👯

Two types of information are used to rank the host addresses: multiple MX records, and multihomed hosts 🏆

Multiple MX records contain a preference indication that MUST be used in sorting (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 recognition of 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 will return a list of alternative IP addresses 🌍. It is the responsibility of the domain name resolver interface to have ordered this list by decreasing preference if necessary, and SMTP MUST try them in the order presented 📋

Although the capability to try multiple alternative addresses is required, specific installations may want to limit or disable the use of alternative addresses 🙈. Whether a sender should attempt retries using the different addresses of a multihomed host has been controversial 🥊. The main argument for using multiple addresses is that it maximizes the probability of timely delivery, and indeed sometimes the probability of any delivery at all. The counter-argument is that it may result in unnecessary resource use 🧐. Note that resource use is also strongly determined by the sending strategy discussed in section 4.5.4.1 💡

If an SMTP server receives a message with a destination for which it is a designated Mail eXchanger, it MAY relay the message (potentially after having rewritten 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 latter requires that the list of MX records be examined further 🫠

If it determines that it should relay the message without rewriting the address, it MUST sort the MX records to determine candidates for delivery. The records are first ordered by preference, 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 is 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 🏅

6.1 Reliable Delivery and Replies by Email 💌

Okay so, when the receiver-SMTP accepts a message by sending back a "250 OK" in response to DATA, it's basically raising its hand and saying "I've got this, I'll deliver or relay it." That's a big deal, bestie 🫶 It MUST take that responsibility seriously. It MUST NOT lose the message for dumb reasons like the host crashing later or some resource shortage it could have seen coming 😭

If delivery fails after the message has already been accepted, the receiver-SMTP MUST put together a notification and send it. That notification MUST go out with a null (<>) reverse path in the envelope 📮 The recipient has to 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, because there's nobody to send it to 💀 None of this stops the local system (the same environment as the receiver-SMTP) from making its own choice to log or pass along info about null address events if it wants to. That's totally its call 🧚 And if the address is an explicit source route, it MUST be stripped down to its final hop ✂️

Here's an example, because examples are everything 🍓 Say an error notification has to go out for a message that came in with:

MAIL FROM:<@a,@b:user@d>

Then the notification MUST be sent using:

RCPT TO:<user@d>

Real talk though, some delivery failures after SMTP accepts a message are just unavoidable 😩 The receiving server might not be able to check every address in the RCPT command(s) because of a "soft" domain system error, or because the target is a mailing list (see the earlier RCPT discussion), or because the server is acting as a relay and can't directly reach the delivering system. Sad, but true 🥲

Now the big one: to avoid getting duplicate messages because of timeouts, a receiver-SMTP MUST try to minimize how long it takes to respond to the final <CRLF>.<CRLF> end of data indicator ⏱️ If you want the deep dive on why, check out RFC 1047 [28], it's giving research paper energy 📚

6.2 Loop Detection 🔁

Counting the "Received:" headers in a message has actually proven to be an effective way to catch loops in mail systems. Not always the most optimal, but ngl it works 💅 SMTP servers using this method SHOULD use a large rejection threshold, normally at least 100 Received entries. And no matter what mechanisms you use, servers MUST have provisions for detecting and stopping trivial loops 🌀 Non-negotiable, bestie.

6.3 Compensating for Irregularities 🙈

Okay this section is spicy. Variations, creative interpretations, and straight-up violations of Internet mail protocols happen all the time, and some people would say it's constant 😭 The big debate is whether a well-behaved SMTP receiver or relay should reject a malformed message, pass it along unchanged, or try to fix it so it has a better shot at being delivered (or replied to). That argument has been going since the dawn of structured network mail and it is NOT slowing down 🍿

Team rejection says fixes are rarely fully adequate, and rejecting bad messages is the only way to force the offending software to get fixed 🔧 Team "deliver no matter what" says users want their mail to go through if at all possible, and there are serious market pressures pushing that way 💸 In practice, those market pressures can matter more to some vendors than strict conformance to the standards, even when the developers themselves think differently 🥺

Things got messier with the split-UA mail reading protocols [3, 26, 5, 21]. Those protocols encouraged using SMTP as a posting protocol, and SMTP servers as relay systems for client hosts that are often only on the Internet part-time 📡 A lot of those client machines were missing stuff that SMTP (and the mail format protocol [7] too) assumed they'd have. Some couldn't keep track of time, some had no concept of time zones, some couldn't figure out their own names or addresses, and none of them could meet the assumptions behind RFC 822's idea of authenticated addresses 🫠

So to help these weak SMTP clients, lots of SMTP systems now finish up messages delivered to them that are incomplete or incorrect 🩹 This is generally considered fine when the server can identify or authenticate the client and they have prior agreements. But when a relay or delivery server knows little or nothing about the user or the client machine, there's at best a lot of concern about the fixes it applies 😬

The following changes MAY be applied to a message being processed when necessary, by an originating SMTP server, or by one used as the target of SMTP as an initial posting 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 the server knows about the client, the less likely these changes are to be right, so more caution and conservatism should be used when deciding whether to fix things and how 🧐 These changes MUST NOT be applied by an SMTP server that provides an intermediate relay function. Hard no, babe 🚫

Across the board, properly-operating clients who supply correct info are preferred over corrections made by the SMTP server 💖 And in every case, documenting what the servers did (in trace fields and/or header comments) is strongly encouraged 📝 Leave a paper trail, bestie 🌸

---

7. Security Considerations ✨

7.1 Mail Security and Spoofing 🕵️‍♀️

Real talk: SMTP mail is inherently insecure 😭 Even fairly casual users can talk directly to receiving and relaying SMTP servers and craft messages that trick a naive recipient into thinking they came from somewhere else. Making a spoofed message that an expert can't spot is harder, but not so much that it stops someone who's determined and knowledgeable 💀 So as people learn more about Internet mail, they also learn that SMTP mail inherently can't be authenticated, and integrity checks can't be provided, at the transport level. Real mail security only lives in end-to-end methods that involve the message bodies, like digital signatures (see [14] and, e.g., PGP [4] or S/MIME [31]) 🔐 Main character energy for the encryption era 👑

Transport-level authentication from an SMTP client to an SMTP server, through protocol extensions and configuration options, does improve things compared to the traditional situation I just described 📈 But unless it's paired with careful handoffs of responsibility in a carefully designed trust environment, it's still inherently weaker than end-to-end mechanisms that use digitally signed messages instead of depending on the transport system's integrity 🥀

Trying to make it harder for users to point the envelope return path and header "From" fields at valid addresses other than their own is largely misguided 🙅‍♀️ It frustrates legit stuff, like one user sending mail on behalf of another, or error (or normal) replies needing to go to a special address. (Systems that give users easy ways to change these fields per message should try to set up a primary and permanent mailbox address for each user, so Sender fields in the message data can be generated sensibly 🧠)

This spec doesn't go any further into SMTP authentication issues, except to say that useful functionality shouldn't get disabled just to hopefully add a tiny bit of protection against some clueless user trying to fake mail 🫶

7.2 "Blind" Copies 🙊

Addresses that don't show up in the message headers can still appear in RCPT commands to an SMTP server, for a few reasons. The two big ones are using a mailing address as a "list exploder" (one address that expands into multiple addresses) and "blind copies" (bcc) 🎭 Especially when there's more than one RCPT command, SMTP clients and servers SHOULD NOT copy the full set of RCPT command arguments into the headers, whether as trace headers or as informational or private-extension headers. That's how you keep those mechanisms from being defeated 🛡️ This rule gets broken all the time and can't be enforced, so sending systems that know about "bcc" use MAY find it helpful to send each blind copy as its own message transaction with just one RCPT command 💌

There's no inherent relationship between the "reverse" addresses (from MAIL, SAML, etc. commands) or "forward" addresses (RCPT) in the SMTP transaction (the "envelope") and the addresses in the headers 🧩 Receiving systems SHOULD NOT try to guess at such relationships and use them to change the message headers for delivery 🙅‍♀️ The popular "Apparently-to" header goes against this principle, is a common source of accidental info disclosure, and SHOULD NOT be used. Bye bye, "Apparently-to" 👋

7.3 VRFY, EXPN, and Security 🔎

As covered in section 3.5, individual sites may want to disable VRFY or EXPN, or both, for security reasons 🔒 Along the same lines, implementations that allow 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, not 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 only checking its syntax breaks this rule 💀 And an implementation that "supports" VRFY by always returning 550, whether or not the address is valid, is also not in conformance. Nice try, but no 😤

In the last few years, mailing list contents have gotten popular as an address source for so-called "spammers" 📧 Using EXPN to "harvest" addresses has increased as list admins put protections in place against inappropriate uses of their lists. Implementations SHOULD still support EXPN, but sites SHOULD carefully weigh the tradeoffs ⚖️ As authentication gets built into SMTP, some sites might choose to make EXPN available only to authenticated requestors 🔑

7.4 Information Disclosure in Announcements 📢

There's an ongoing debate about the tradeoffs here, and honestly it's a juicy one 🍿 On one side, announcing server type and version (and sometimes even the server's domain name) in the greeting or in response to the HELP command is super useful for debugging. On the other side, it exposes info that could help a hostile attack. The debugging value is beyond doubt 🧡 Folks who want it out there argue that it's way better to actually secure an SMTP server than to hope hiding its exact identity will protect known vulnerabilities 💪 Sites are encouraged to weigh that tradeoff with this in mind, and implementations are strongly encouraged to at least make type and version info available to other network hosts in some way 🌈

7.5 Information Disclosure in Trace Fields 🕵️‍♀️

Okay so, when mail comes from inside a LAN whose hosts aren't directly on the public Internet, the trace ("Received") fields made under this spec can reveal host names and similar info that nobody would normally see. Ngl, that's usually not a big deal, but sites that really care about keeping names private should know about it 🔒✨ Also, the optional FOR clause should be handled with care or skipped entirely when there are multiple recipients, because it could accidentally tell everyone who the "blind copy" recipients are 🙈

7.6 Information Disclosure in Message Forwarding 📬

Remember section 3.4? Using the 251 or 551 reply codes to show the replacement address for a mailbox can accidentally leak sensitive info 😬 If that worries your site, pick and configure your servers carefully 💅

7.7 Scope of Operation of SMTP Servers 🌍

It's a well-established rule that an SMTP server can refuse to take mail for any operational or technical reason that makes sense to the site running it. BUT, the whole internet only works because sites cooperate 🫶 If sites abuse the right to reject traffic, email being available everywhere (one of the Internet's best features) gets put at risk, so anyone deciding to be picky about what they accept needs to be careful and keep things balanced ⚖️

Lowkey, in recent years the relay function through random sites has been used in hostile attempts to hide where mail really came from 👀 Some sites have decided to only use relaying for known or identifiable sources, and implementations SHOULD provide the ability to do this kind of filtering 🔥 When mail gets rejected for these or other policy reasons, a 550 code SHOULD be used in response to EHLO, MAIL, or RCPT, as appropriate 💀

8. IANA Considerations 📋

IANA is going to keep three registries for this spec, bestie 🎀 The first one holds SMTP service extensions with their keywords and, as needed, parameters and verbs. As section 2.2.2 says, no entry in this registry can start with an "X" 🚫 Entries can only be added for service extensions (and their keywords, parameters, or verbs) that are defined in standards-track or experimental RFCs specifically approved by the IESG for this purpose ✨

The second registry holds "tags" that identify kinds of domain literals other than IPv4 addresses (covered in RFC 821 and in this document) and IPv6 addresses (covered in this document) 🧚 New literal types need standardization before anyone can use them, and none are expected right now 🙌

The third one was set up by RFC 821 and renewed by this spec. It's a registry of link and protocol identifiers for the "via" and "with" subclauses of the time stamp ("Received: header") described in section 4.4 🦋 You can only register extra link and protocol identifiers through standardization, or through an RFC-documented, IESG-approved, Experimental protocol extension 💜

9. References 📚

[1] American National Standards Institute (formerly United States of America Standards Institute), X3.4, 1968, "USA Code for Information Interchange". ANSI X3.4-1968 has been replaced by newer versions with slight modifications, but the 1968 version remains definitive for the Internet. 🔤

[2] Braden, R., "Requirements for Internet hosts - application and support", STD 3, RFC 1123, October 1989. 🖥️

[3] Butler, M., Chase, D., Goldberger, J., Postel, J. and J. Reynolds, "Post Office Protocol - version 2", RFC 937, February 1985. 📫

[4] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998. 🔐

[5] Crispin, M., "Interactive Mail Access Protocol - Version 2", RFC 1176, August 1990. 📨

[6] Crispin, M., "Internet Message Access Protocol - Version 4", RFC 2060, December 1996. 📥

[7] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", RFC 822, August 1982. ✍️

[8] Crocker, D. and P. Overell, Eds., "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. 🧩

[9] De Winter, J., "SMTP Service Extension for Remote Message Queue Starting", RFC 1985, August 1996. 🚀

[10] Fajman, R., "An Extensible Message Format for Message Disposition Notifications", RFC 2298, March 1998. 📑

[11] Freed, N, "Behavior of and Requirements for Internet Firewalls", RFC 2979, October 2000. 🧱

[12] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, December 1996. 🎨

[13] Freed, N., "SMTP Service Extension for Command Pipelining", RFC 2920, September 2000. ⏩

[14] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995. 🛡️

[15] Gellens, R. and J. Klensin, "Message Submission", RFC 2476, December 1998. 📤

[16] Kille, S., "Mapping between X.400 and RFC822/MIME", RFC 2156, January 1998. 🗺️

[17] Hinden, R and S. Deering, Eds. "IP Version 6 Addressing Architecture", RFC 2373, July 1998. 🌐

[18] Klensin, J., Freed, N. and K. Moore, "SMTP Service Extension for Message Size Declaration", STD 10, RFC 1870, November 1995. 📏

[19] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker, "SMTP Service Extensions", STD 10, RFC 1869, November 1995. 🧩

[20] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker, "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, July 1994. 💾

[21] Lambert, M., "PCMAIL: A distributed mail system for personal computers", RFC 1056, July 1988. 💻

[22] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. 🏷️

Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. 🏷️

[23] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, December 1996. 🌏

[24] Moore, K., "SMTP Service Extension for Delivery Status Notifications", RFC 1891, January 1996. ✅

[25] Moore, K., and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 1894, January 1996. 📩

[26] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996. 📬

[27] Partridge, C., "Mail routing and the domain system", RFC 974, January 1986. 🧭

[28] Partridge, C., "Duplicate messages and SMTP", RFC 1047, February 1988. 👯

[29] Postel, J., ed., "Transmission Control Protocol - DARPA Internet Program Protocol Specification", STD 7, RFC 793, September 1981. 🔌

[30] Postel, J., "Simple Mail Transfer Protocol", RFC 821, August 1982. 💌

[31] Ramsdell, B., Ed., "S/MIME Version 3 Message Specification", RFC 2633, June 1999. 🔏

[32] Resnick, P., Ed., "Internet Message Format", RFC 2822, April 2001. 📝

[33] Vaudreuil, G., "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", RFC 1830, August 1995. 🖼️

[34] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893, January 1996. 🔢

10. Editor's Address ✏️

John C. Klensin
AT&T Laboratories
99 Bedford St
Boston, MA 02111 USA

Phone: 617-574-3076
EMail: klensin@research.att.com

11. Acknowledgments 🫶

Okay, a huge shoutout to everyone who worked long and hard on the many versions of this document 💖 The IETF DRUMS Working Group had wide-ranging debate, both on its mailing list and in face-to-face discussions, about lots of technical issues and the role of a revised standard for Internet mail transport, and many contributors helped shape the wording in this spec ✨ There have been so many participants in the discussions since RFC 821 came out that they're too numerous to name, but they all helped this document become what it is 🌈

APPENDICES 🎀

A. TCP Transport Service 🔌

The TCP connection supports the transmission of 8-bit bytes. The SMTP data is 7-bit ASCII characters. Each character is sent as an 8-bit byte with the high-order bit cleared to zero. Service extensions may change this rule to allow full 8-bit data bytes as part of the message body, but not in SMTP commands or responses 💅✨

B. Generating SMTP Commands from RFC 822 Headers ✨

okay so some systems only use RFC 822 headers in a mail submission protocol, or they generate SMTP commands straight from those headers when a message gets handed to an MTA from a UA 📨. the MTA-UA protocol is a private matter that no Internet Standard covers, but this approach causes problems 💀. there have been repeated messes with "bcc" copies and redistribution lists when envelope info (which conceptually belongs to the mail envelope) isn't pulled out early and kept separate from the header info 😭.

It is recommended that the UA give its initial ("submission client") MTA an envelope separate from the message itself. However, if the envelope isn't supplied, SMTP commands SHOULD be generated as follows:

1. 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 fields SHOULD then be removed from the headers. Once this process is completed, the remaining headers SHOULD be checked to verify that at least one To:, Cc:, or Bcc: header remains. If none do, then a bcc: header with no additional information SHOULD be inserted as specified in [32].
2. 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 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 in this way, it bears responsibility for ensuring that 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 headers or the foreign system's envelope. no shortcuts, bestie 🚫

Attempts to gateway messages using only their header "to" and "cc" fields have repeatedly caused mail loops and other behavior adverse to the proper functioning of the Internet mail environment. These problems have been especially common when the message originates from an Internet mailing list and is distributed into the foreign environment using envelope information. When these messages are then processed by a header-only remailer, loops back to the Internet environment (and the mailing list) are almost inevitable. 🔁😵‍💫

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> SHOULD be the host sending the MAIL command. Similarly, the <forward-path> may be a source routing lists 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; while servers MUST be prepared to receive and handle them as discussed in section 3.3 and F.2, clients SHOULD NOT transmit them and this section was included only to provide context. so they're kinda old news 🕰️

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 distinction between an address and a route. The mailbox 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- and reverse-paths.

The SMTP server transforms the command arguments by moving its own identifier (its domain name or that of any domain for which it is acting as a mail exchanger), if it appears, from the forward-path to the beginning of the reverse-path.

Notice that the forward-path and reverse-path appear in the SMTP commands and replies, but not necessarily in the message. That is, there is no need for these paths and especially this syntax to appear in the "To:" , "From:", "CC:", etc. fields of the message header. Conversely, SMTP servers MUST NOT derive final message delivery information from message header fields. 🚫📭

When the list of hosts is present, it is a "reverse" source route and indicates that 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. As each relay host adds itself to the beginning of the list, it MUST use its name as known in the transport environment to which it is relaying the mail rather than that of the transport environment from which the mail came (if they are different). 🧚

D. Scenarios 🎬

This section presents complete scenarios of several types of SMTP sessions. In the examples, "C:" indicates what is said by the SMTP client, and "S:" indicates what is said by the SMTP server. ok let's watch them play out 🍿

D.1 A Typical SMTP Transaction Scenario 💌

This SMTP example shows mail sent by Smith at host bar.com, to Jones, Green, and Brown at host foo.com. Here we assume that host bar.com contacts host foo.com directly. The mail is accepted for Jones and Brown. Green does not have a mailbox at host 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 channel

D.2 Aborted SMTP Transaction Scenario 🙅‍♀️

   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 channel

D.3 Relayed Mail Scenario 🔀

Step 1 -- Source Host to Relay Host

   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:<@foo.com: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 channel

Step 2 -- Relay Host to Destination Host

   S: 220 xyz.com Simple Mail Transfer Service Ready
   C: EHLO foo.com
   S: 250 xyz.com is on the air
   C: MAIL FROM:<@foo.com: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 channel

D.4 Verifying and Sending Scenario 🔍

   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: SEND 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 channel

E. Other Gateway Issues 🌉

In general, gateways between the Internet and other mail systems SHOULD attempt to preserve any layering semantics across the boundaries between the two mail systems involved. Gateway-translation approaches that attempt to take shortcuts by mapping, (such as envelope information from one system to the message headers or body of another) have generally proven to be inadequate in important ways. Systems translating between environments that do not support both envelopes and headers and Internet mail must be written with the understanding that some information loss is almost inevitable. shortcuts = sad gateways 😔

F. Deprecated Features of RFC 821 🥀

A few features of RFC 821 have proven to be problematic and SHOULD NOT be used in Internet mail. these are the ones we're retiring 👋

F.1 TURN 🔄

This command, described in RFC 821, raises important security issues since, in the absence of strong authentication of the host requesting that the client and server switch roles, it can easily be used to divert mail from its correct destination. Its use is deprecated; SMTP systems SHOULD NOT use it unless the server can authenticate the client. this one is dangerous, bestie, it can literally send your mail to the wrong place 🚨

F.2 Source Routing 🛣️

okay so RFC 821 leaned on explicit source routing to get mail from one host to another through a series of relays 📬. then the domain name system "MX" record came along and made regular mail stop needing source routes 🙌. the last big justification got wiped out when RFC 1123 added a clear rule that addresses following an "@" must all be fully-qualified domain names 💅. so now the only reasons left are supporting super old SMTP clients or MUAs 👵 and debugging mail systems 🔧. 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 🫶. no skipping it! they MAY, if necessary, ignore the routes and just use the target domain in the address 🎯. but if they do use the source route, the message MUST be sent to the first domain shown in the address 📍. and in particular, a server MUST NOT guess at shortcuts within the source route 🙅‍♀️.

Clients SHOULD NOT utilize explicit source routing except under unusual circumstances, such as debugging or potentially relaying around firewall or mail system configuration errors 🧯.

F.3 HELO 👋

as discussed in sections 3.1 and 4.1.1, EHLO is strongly preferred over HELO when the server will accept the former ✨. servers must continue to accept and process HELO so older clients still work 🥹.

F.4 #-literals 🔢

RFC 821 let you specify an Internet address as a decimal integer host number with a pound sign, #, in front of it 🧐. in practice that form has been obsolete since TCP/IP came along. it is deprecated and MUST NOT be used 🚫.

F.5 Dates and Years 📅

when dates get inserted into messages by SMTP clients or servers (e.g., in trace fields), four-digit years MUST BE used 🗓️. two-digit years are deprecated, and three-digit years were never permitted in the Internet mail system 💀.

F.6 Sending versus Mailing 📱

in addition to delivering messages to users' mailboxes, RFC 821 had extra, optional commands to deliver messages straight to the user's terminal screen 🖥️. those commands (SEND, SAML, SOML) were rarely implemented, and changes in workstation technology plus newer protocols may have made them obsolete even where they're still around 🥲.

Clients SHOULD NOT provide SEND, SAML, or SOML as services. Servers MAY implement them. If servers do implement them, the implementation model specified in RFC 821 MUST be used and the command names MUST be published in the response to the EHLO command ✅.

---

Full Copyright Statement 📜

Copyright (C) The Internet Society (2001). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.

Acknowledgement 🙏

Funding for the RFC Editor function is right now provided by the Internet Society 💖.