1
2
3
4
5
6
7	Network Working Group J. Klensin
8	Request for Comments: 5321 October 2008
9	Obsoletes: 2821
10	Updates: 1123
11	Category: Standards Track
12
13
14	Simple Mail Transfer Protocol
15
16	Status of This Memo
17
18	This document specifies an Internet standards track protocol for the
19	Internet community, and requests discussion and suggestions for
20	improvements. Please refer to the current edition of the "Internet
21	Official Protocol Standards" (STD 1) for the standardization state
22	and status of this protocol. Distribution of this memo is unlimited.
23
24	Abstract
25
26	This document is a specification of the basic protocol for Internet
27	electronic mail transport. It consolidates, updates, and clarifies
28	several previous documents, making all or parts of most of them
29	obsolete. It covers the SMTP extension mechanisms and best practices
30	for the contemporary Internet, but does not provide details about
31	particular extensions. Although SMTP was designed as a mail
32	transport and delivery protocol, this specification also contains
33	information that is important to its use as a "mail submission"
34	protocol for "split-UA" (User Agent) mail reading systems and mobile
35	environments.
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58	Klensin Standards Track [Page 1]
59
60	RFC 5321 SMTP October 2008
61
62
63	Table of Contents
64
65	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
66	1.1. Transport of Electronic Mail . . . . . . . . . . . . . . . 5
67	1.2. History and Context for This Document . . . . . . . . . . 5
68	1.3. Document Conventions . . . . . . . . . . . . . . . . . . . 6
69	2. The SMTP Model . . . . . . . . . . . . . . . . . . . . . . . . 7
70	2.1. Basic Structure . . . . . . . . . . . . . . . . . . . . . 7
71	2.2. The Extension Model . . . . . . . . . . . . . . . . . . . 9
72	2.2.1. Background . . . . . . . . . . . . . . . . . . . . . . 9
73	2.2.2. Definition and Registration of Extensions . . . . . . 10
74	2.2.3. Special Issues with Extensions . . . . . . . . . . . . 11
75	2.3. SMTP Terminology . . . . . . . . . . . . . . . . . . . . . 11
76	2.3.1. Mail Objects . . . . . . . . . . . . . . . . . . . . . 11
77	2.3.2. Senders and Receivers . . . . . . . . . . . . . . . . 12
78	2.3.3. Mail Agents and Message Stores . . . . . . . . . . . . 12
79	2.3.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . 13
80	2.3.5. Domain Names . . . . . . . . . . . . . . . . . . . . . 13
81	2.3.6. Buffer and State Table . . . . . . . . . . . . . . . . 14
82	2.3.7. Commands and Replies . . . . . . . . . . . . . . . . . 14
83	2.3.8. Lines . . . . . . . . . . . . . . . . . . . . . . . . 14
84	2.3.9. Message Content and Mail Data . . . . . . . . . . . . 15
85	2.3.10. Originator, Delivery, Relay, and Gateway Systems . . . 15
86	2.3.11. Mailbox and Address . . . . . . . . . . . . . . . . . 15
87	2.4. General Syntax Principles and Transaction Model . . . . . 16
88	3. The SMTP Procedures: An Overview . . . . . . . . . . . . . . . 17
89	3.1. Session Initiation . . . . . . . . . . . . . . . . . . . . 18
90	3.2. Client Initiation . . . . . . . . . . . . . . . . . . . . 18
91	3.3. Mail Transactions . . . . . . . . . . . . . . . . . . . . 19
92	3.4. Forwarding for Address Correction or Updating . . . . . . 21
93	3.5. Commands for Debugging Addresses . . . . . . . . . . . . . 22
94	3.5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 22
95	3.5.2. VRFY Normal Response . . . . . . . . . . . . . . . . . 24
96	3.5.3. Meaning of VRFY or EXPN Success Response . . . . . . . 25
97	3.5.4. Semantics and Applications of EXPN . . . . . . . . . . 26
98	3.6. Relaying and Mail Routing . . . . . . . . . . . . . . . . 26
99	3.6.1. Source Routes and Relaying . . . . . . . . . . . . . . 26
100	3.6.2. Mail eXchange Records and Relaying . . . . . . . . . . 26
101	3.6.3. Message Submission Servers as Relays . . . . . . . . . 27
102	3.7. Mail Gatewaying . . . . . . . . . . . . . . . . . . . . . 28
103	3.7.1. Header Fields in Gatewaying . . . . . . . . . . . . . 28
104	3.7.2. Received Lines in Gatewaying . . . . . . . . . . . . . 29
105	3.7.3. Addresses in Gatewaying . . . . . . . . . . . . . . . 29
106	3.7.4. Other Header Fields in Gatewaying . . . . . . . . . . 29
107	3.7.5. Envelopes in Gatewaying . . . . . . . . . . . . . . . 30
108	3.8. Terminating Sessions and Connections . . . . . . . . . . . 30
109	3.9. Mailing Lists and Aliases . . . . . . . . . . . . . . . . 31
110	3.9.1. Alias . . . . . . . . . . . . . . . . . . . . . . . . 31
111
112
113
114	Klensin Standards Track [Page 2]
115
116	RFC 5321 SMTP October 2008
117
118
119	3.9.2. List . . . . . . . . . . . . . . . . . . . . . . . . . 31
120	4. The SMTP Specifications . . . . . . . . . . . . . . . . . . . 32
121	4.1. SMTP Commands . . . . . . . . . . . . . . . . . . . . . . 32
122	4.1.1. Command Semantics and Syntax . . . . . . . . . . . . . 32
123	4.1.2. Command Argument Syntax . . . . . . . . . . . . . . . 41
124	4.1.3. Address Literals . . . . . . . . . . . . . . . . . . . 43
125	4.1.4. Order of Commands . . . . . . . . . . . . . . . . . . 44
126	4.1.5. Private-Use Commands . . . . . . . . . . . . . . . . . 46
127	4.2. SMTP Replies . . . . . . . . . . . . . . . . . . . . . . . 46
128	4.2.1. Reply Code Severities and Theory . . . . . . . . . . . 48
129	4.2.2. Reply Codes by Function Groups . . . . . . . . . . . . 50
130	4.2.3. Reply Codes in Numeric Order . . . . . . . . . . . . . 52
131	4.2.4. Reply Code 502 . . . . . . . . . . . . . . . . . . . . 53
132	4.2.5. Reply Codes after DATA and the Subsequent
133	<CRLF>.<CRLF> . . . . . . . . . . . . . . . . . . . . 53
134	4.3. Sequencing of Commands and Replies . . . . . . . . . . . . 54
135	4.3.1. Sequencing Overview . . . . . . . . . . . . . . . . . 54
136	4.3.2. Command-Reply Sequences . . . . . . . . . . . . . . . 55
137	4.4. Trace Information . . . . . . . . . . . . . . . . . . . . 57
138	4.5. Additional Implementation Issues . . . . . . . . . . . . . 61
139	4.5.1. Minimum Implementation . . . . . . . . . . . . . . . . 61
140	4.5.2. Transparency . . . . . . . . . . . . . . . . . . . . . 62
141	4.5.3. Sizes and Timeouts . . . . . . . . . . . . . . . . . . 62
142	4.5.3.1. Size Limits and Minimums . . . . . . . . . . . . . 62
143	4.5.3.1.1. Local-part . . . . . . . . . . . . . . . . . . 63
144	4.5.3.1.2. Domain . . . . . . . . . . . . . . . . . . . . 63
145	4.5.3.1.3. Path . . . . . . . . . . . . . . . . . . . . . 63
146	4.5.3.1.4. Command Line . . . . . . . . . . . . . . . . . 63
147	4.5.3.1.5. Reply Line . . . . . . . . . . . . . . . . . . 63
148	4.5.3.1.6. Text Line . . . . . . . . . . . . . . . . . . 63
149	4.5.3.1.7. Message Content . . . . . . . . . . . . . . . 63
150	4.5.3.1.8. Recipients Buffer . . . . . . . . . . . . . . 64
151	4.5.3.1.9. Treatment When Limits Exceeded . . . . . . . . 64
152	4.5.3.1.10. Too Many Recipients Code . . . . . . . . . . . 64
153	4.5.3.2. Timeouts . . . . . . . . . . . . . . . . . . . . . 65
154	4.5.3.2.1. Initial 220 Message: 5 Minutes . . . . . . . . 65
155	4.5.3.2.2. MAIL Command: 5 Minutes . . . . . . . . . . . 65
156	4.5.3.2.3. RCPT Command: 5 Minutes . . . . . . . . . . . 65
157	4.5.3.2.4. DATA Initiation: 2 Minutes . . . . . . . . . . 66
158	4.5.3.2.5. Data Block: 3 Minutes . . . . . . . . . . . . 66
159	4.5.3.2.6. DATA Termination: 10 Minutes. . . . . . . . . 66
160	4.5.3.2.7. Server Timeout: 5 Minutes. . . . . . . . . . . 66
161	4.5.4. Retry Strategies . . . . . . . . . . . . . . . . . . . 66
162	4.5.5. Messages with a Null Reverse-Path . . . . . . . . . . 68
163	5. Address Resolution and Mail Handling . . . . . . . . . . . . . 69
164	5.1. Locating the Target Host . . . . . . . . . . . . . . . . . 69
165	5.2. IPv6 and MX Records . . . . . . . . . . . . . . . . . . . 71
166	6. Problem Detection and Handling . . . . . . . . . . . . . . . . 71
167
168
169
170	Klensin Standards Track [Page 3]
171
172	RFC 5321 SMTP October 2008
173
174
175	6.1. Reliable Delivery and Replies by Email . . . . . . . . . . 71
176	6.2. Unwanted, Unsolicited, and "Attack" Messages . . . . . . . 72
177	6.3. Loop Detection . . . . . . . . . . . . . . . . . . . . . . 73
178	6.4. Compensating for Irregularities . . . . . . . . . . . . . 73
179	7. Security Considerations . . . . . . . . . . . . . . . . . . . 75
180	7.1. Mail Security and Spoofing . . . . . . . . . . . . . . . . 75
181	7.2. "Blind" Copies . . . . . . . . . . . . . . . . . . . . . . 76
182	7.3. VRFY, EXPN, and Security . . . . . . . . . . . . . . . . . 76
183	7.4. Mail Rerouting Based on the 251 and 551 Response Codes . . 77
184	7.5. Information Disclosure in Announcements . . . . . . . . . 77
185	7.6. Information Disclosure in Trace Fields . . . . . . . . . . 78
186	7.7. Information Disclosure in Message Forwarding . . . . . . . 78
187	7.8. Resistance to Attacks . . . . . . . . . . . . . . . . . . 78
188	7.9. Scope of Operation of SMTP Servers . . . . . . . . . . . . 78
189	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 79
190	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 80
191	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 81
192	10.1. Normative References . . . . . . . . . . . . . . . . . . . 81
193	10.2. Informative References . . . . . . . . . . . . . . . . . . 82
194	Appendix A. TCP Transport Service . . . . . . . . . . . . . . . . 85
195	Appendix B. Generating SMTP Commands from RFC 822 Header
196	Fields . . . . . . . . . . . . . . . . . . . . . . . 85
197	Appendix C. Source Routes . . . . . . . . . . . . . . . . . . . . 86
198	Appendix D. Scenarios . . . . . . . . . . . . . . . . . . . . . . 87
199	D.1. A Typical SMTP Transaction Scenario . . . . . . . . . . . 88
200	D.2. Aborted SMTP Transaction Scenario . . . . . . . . . . . . 89
201	D.3. Relayed Mail Scenario . . . . . . . . . . . . . . . . . . 90
202	D.4. Verifying and Sending Scenario . . . . . . . . . . . . . . 92
203	Appendix E. Other Gateway Issues . . . . . . . . . . . . . . . . 92
204	Appendix F. Deprecated Features of RFC 821 . . . . . . . . . . . 93
205	F.1. TURN . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
206	F.2. Source Routing . . . . . . . . . . . . . . . . . . . . . . 93
207	F.3. HELO . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
208	F.4. #-literals . . . . . . . . . . . . . . . . . . . . . . . . 94
209	F.5. Dates and Years . . . . . . . . . . . . . . . . . . . . . 94
210	F.6. Sending versus Mailing . . . . . . . . . . . . . . . . . . 94
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226	Klensin Standards Track [Page 4]
227
228	RFC 5321 SMTP October 2008
229
230
231	1. Introduction
232
233	1.1. Transport of Electronic Mail
234
235	The objective of the Simple Mail Transfer Protocol (SMTP) is to
236	transfer mail reliably and efficiently.
237
238	SMTP is independent of the particular transmission subsystem and
239	requires only a reliable ordered data stream channel. While this
240	document specifically discusses transport over TCP, other transports
241	are possible. Appendices to RFC 821 [1] describe some of them.
242
243	An important feature of SMTP is its capability to transport mail
244	across multiple networks, usually referred to as "SMTP mail relaying"
245	(see Section 3.6). A network consists of the mutually-TCP-accessible
246	hosts on the public Internet, the mutually-TCP-accessible hosts on a
247	firewall-isolated TCP/IP Intranet, or hosts in some other LAN or WAN
248	environment utilizing a non-TCP transport-level protocol. Using
249	SMTP, a process can transfer mail to another process on the same
250	network or to some other network via a relay or gateway process
251	accessible to both networks.
252
253	In this way, a mail message may pass through a number of intermediate
254	relay or gateway hosts on its path from sender to ultimate recipient.
255	The Mail eXchanger mechanisms of the domain name system (RFC 1035
256	[2], RFC 974 [12], and Section 5 of this document) are used to
257	identify the appropriate next-hop destination for a message being
258	transported.
259
260	1.2. History and Context for This Document
261
262	This document is a specification of the basic protocol for the
263	Internet electronic mail transport. It consolidates, updates and
264	clarifies, but does not add new or change existing functionality of
265	the following:
266
267	o the original SMTP (Simple Mail Transfer Protocol) specification of
268	RFC 821 [1],
269
270	o domain name system requirements and implications for mail
271	transport from RFC 1035 [2] and RFC 974 [12],
272
273	o the clarifications and applicability statements in RFC 1123 [3],
274	and
275
276	o material drawn from the SMTP Extension mechanisms in RFC 1869
277	[13].
278
279
280
281
282	Klensin Standards Track [Page 5]
283
284	RFC 5321 SMTP October 2008
285
286
287	o Editorial and clarification changes to RFC 2821 [14] to bring that
288	specification to Draft Standard.
289
290	It obsoletes RFC 821, RFC 974, RFC 1869, and RFC 2821 and updates RFC
291	1123 (replacing the mail transport materials of RFC 1123). However,
292	RFC 821 specifies some features that were not in significant use in
293	the Internet by the mid-1990s and (in appendices) some additional
294	transport models. Those sections are omitted here in the interest of
295	clarity and brevity; readers needing them should refer to RFC 821.
296
297	It also includes some additional material from RFC 1123 that required
298	amplification. This material has been identified in multiple ways,
299	mostly by tracking flaming on various lists and newsgroups and
300	problems of unusual readings or interpretations that have appeared as
301	the SMTP extensions have been deployed. Where this specification
302	moves beyond consolidation and actually differs from earlier
303	documents, it supersedes them technically as well as textually.
304
305	Although SMTP was designed as a mail transport and delivery protocol,
306	this specification also contains information that is important to its
307	use as a "mail submission" protocol, as recommended for Post Office
308	Protocol (POP) (RFC 937 [15], RFC 1939 [16]) and IMAP (RFC 3501
309	[17]). In general, the separate mail submission protocol specified
310	in RFC 4409 [18] is now preferred to direct use of SMTP; more
311	discussion of that subject appears in that document.
312
313	Section 2.3 provides definitions of terms specific to this document.
314	Except when the historical terminology is necessary for clarity, this
315	document uses the current 'client' and 'server' terminology to
316	identify the sending and receiving SMTP processes, respectively.
317
318	A companion document, RFC 5322 [4], discusses message header sections
319	and bodies and specifies formats and structures for them.
320
321	1.3. Document Conventions
322
323	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
324	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
325	document are to be interpreted as described in RFC 2119 [5]. As each
326	of these terms was intentionally and carefully chosen to improve the
327	interoperability of email, each use of these terms is to be treated
328	as a conformance requirement.
329
330	Because this document has a long history and to avoid the risk of
331	various errors and of confusing readers and documents that point to
332	this one, most examples and the domain names they contain are
333	preserved from RFC 2821. Readers are cautioned that these are
334
335
336
337
338	Klensin Standards Track [Page 6]
339
340	RFC 5321 SMTP October 2008
341
342
343	illustrative examples that should not actually be used in either code
344	or configuration files.
345
346	2. The SMTP Model
347
348	2.1. Basic Structure
349
350	The SMTP design can be pictured as:
351
352	+----------+ +----------+
353	+------+ | | | |
354	| User |<-->| | SMTP | |
355	+------+ | Client- |Commands/Replies| Server- |
356	+------+ | SMTP |<-------------->| SMTP | +------+
357	| File |<-->| | and Mail | |<-->| File |
358	|System| | | | | |System|
359	+------+ +----------+ +----------+ +------+
360	SMTP client SMTP server
361
362	When an SMTP client has a message to transmit, it establishes a two-
363	way transmission channel to an SMTP server. The responsibility of an
364	SMTP client is to transfer mail messages to one or more SMTP servers,
365	or report its failure to do so.
366
367	The means by which a mail message is presented to an SMTP client, and
368	how that client determines the identifier(s) ("names") of the
369	domain(s) to which mail messages are to be transferred, is a local
370	matter, and is not addressed by this document. In some cases, the
371	designated domain(s), or those determined by an SMTP client, will
372	identify the final destination(s) of the mail message. In other
373	cases, common with SMTP clients associated with implementations of
374	the POP (RFC 937 [15], RFC 1939 [16]) or IMAP (RFC 3501 [17])
375	protocols, or when the SMTP client is inside an isolated transport
376	service environment, the domain determined will identify an
377	intermediate destination through which all mail messages are to be
378	relayed. SMTP clients that transfer all traffic regardless of the
379	target domains associated with the individual messages, or that do
380	not maintain queues for retrying message transmissions that initially
381	cannot be completed, may otherwise conform to this specification but
382	are not considered fully-capable. Fully-capable SMTP
383	implementations, including the relays used by these less capable
384	ones, and their destinations, are expected to support all of the
385	queuing, retrying, and alternate address functions discussed in this
386	specification. In many situations and configurations, the less-
387	capable clients discussed above SHOULD be using the message
388	submission protocol (RFC 4409 [18]) rather than SMTP.
389
390
391
392
393
394	Klensin Standards Track [Page 7]
395
396	RFC 5321 SMTP October 2008
397
398
399	The means by which an SMTP client, once it has determined a target
400	domain, determines the identity of an SMTP server to which a copy of
401	a message is to be transferred, and then performs that transfer, is
402	covered by this document. To effect a mail transfer to an SMTP
403	server, an SMTP client establishes a two-way transmission channel to
404	that SMTP server. An SMTP client determines the address of an
405	appropriate host running an SMTP server by resolving a destination
406	domain name to either an intermediate Mail eXchanger host or a final
407	target host.
408
409	An SMTP server may be either the ultimate destination or an
410	intermediate "relay" (that is, it may assume the role of an SMTP
411	client after receiving the message) or "gateway" (that is, it may
412	transport the message further using some protocol other than SMTP).
413	SMTP commands are generated by the SMTP client and sent to the SMTP
414	server. SMTP replies are sent from the SMTP server to the SMTP
415	client in response to the commands.
416
417	In other words, message transfer can occur in a single connection
418	between the original SMTP-sender and the final SMTP-recipient, or can
419	occur in a series of hops through intermediary systems. In either
420	case, once the server has issued a success response at the end of the
421	mail data, a formal handoff of responsibility for the message occurs:
422	the protocol requires that a server MUST accept responsibility for
423	either delivering the message or properly reporting the failure to do
424	so (see Sections 6.1, 6.2, and 7.8, below).
425
426	Once the transmission channel is established and initial handshaking
427	is completed, the SMTP client normally initiates a mail transaction.
428	Such a transaction consists of a series of commands to specify the
429	originator and destination of the mail and transmission of the
430	message content (including any lines in the header section or other
431	structure) itself. When the same message is sent to multiple
432	recipients, this protocol encourages the transmission of only one
433	copy of the data for all recipients at the same destination (or
434	intermediate relay) host.
435
436	The server responds to each command with a reply; replies may
437	indicate that the command was accepted, that additional commands are
438	expected, or that a temporary or permanent error condition exists.
439	Commands specifying the sender or recipients may include server-
440	permitted SMTP service extension requests, as discussed in
441	Section 2.2. The dialog is purposely lock-step, one-at-a-time,
442	although this can be modified by mutually agreed upon extension
443	requests such as command pipelining (RFC 2920 [19]).
444
445	Once a given mail message has been transmitted, the client may either
446	request that the connection be shut down or may initiate other mail
447
448
449
450	Klensin Standards Track [Page 8]
451
452	RFC 5321 SMTP October 2008
453
454
455	transactions. In addition, an SMTP client may use a connection to an
456	SMTP server for ancillary services such as verification of email
457	addresses or retrieval of mailing list subscriber addresses.
458
459	As suggested above, this protocol provides mechanisms for the
460	transmission of mail. Historically, this transmission normally
461	occurred directly from the sending user's host to the receiving
462	user's host when the two hosts are connected to the same transport
463	service. When they are not connected to the same transport service,
464	transmission occurs via one or more relay SMTP servers. A very
465	common case in the Internet today involves submission of the original
466	message to an intermediate, "message submission" server, which is
467	similar to a relay but has some additional properties; such servers
468	are discussed in Section 2.3.10 and at some length in RFC 4409 [18].
469	An intermediate host that acts as either an SMTP relay or as a
470	gateway into some other transmission environment is usually selected
471	through the use of the domain name service (DNS) Mail eXchanger
472	mechanism.
473
474	Usually, intermediate hosts are determined via the DNS MX record, not
475	by explicit "source" routing (see Section 5 and Appendix C and
476	Appendix F.2).
477
478	2.2. The Extension Model
479
480	2.2.1. Background
481
482	In an effort that started in 1990, approximately a decade after RFC
483	821 was completed, the protocol was modified with a "service
484	extensions" model that permits the client and server to agree to
485	utilize shared functionality beyond the original SMTP requirements.
486	The SMTP extension mechanism defines a means whereby an extended SMTP
487	client and server may recognize each other, and the server can inform
488	the client as to the service extensions that it supports.
489
490	Contemporary SMTP implementations MUST support the basic extension
491	mechanisms. For instance, servers MUST support the EHLO command even
492	if they do not implement any specific extensions and clients SHOULD
493	preferentially utilize EHLO rather than HELO. (However, for
494	compatibility with older conforming implementations, SMTP clients and
495	servers MUST support the original HELO mechanisms as a fallback.)
496	Unless the different characteristics of HELO must be identified for
497	interoperability purposes, this document discusses only EHLO.
498
499	SMTP is widely deployed and high-quality implementations have proven
500	to be very robust. However, the Internet community now considers
501	some services to be important that were not anticipated when the
502	protocol was first designed. If support for those services is to be
503
504
505
506	Klensin Standards Track [Page 9]
507
508	RFC 5321 SMTP October 2008
509
510
511	added, it must be done in a way that permits older implementations to
512	continue working acceptably. The extension framework consists of:
513
514	o The SMTP command EHLO, superseding the earlier HELO,
515
516	o a registry of SMTP service extensions,
517
518	o additional parameters to the SMTP MAIL and RCPT commands, and
519
520	o optional replacements for commands defined in this protocol, such
521	as for DATA in non-ASCII transmissions (RFC 3030 [20]).
522
523	SMTP's strength comes primarily from its simplicity. Experience with
524	many protocols has shown that protocols with few options tend towards
525	ubiquity, whereas protocols with many options tend towards obscurity.
526
527	Each and every extension, regardless of its benefits, must be
528	carefully scrutinized with respect to its implementation, deployment,
529	and interoperability costs. In many cases, the cost of extending the
530	SMTP service will likely outweigh the benefit.
531
532	2.2.2. Definition and Registration of Extensions
533
534	The IANA maintains a registry of SMTP service extensions. A
535	corresponding EHLO keyword value is associated with each extension.
536	Each service extension registered with the IANA must be defined in a
537	formal Standards-Track or IESG-approved Experimental protocol
538	document. The definition must include:
539
540	o the textual name of the SMTP service extension;
541
542	o the EHLO keyword value associated with the extension;
543
544	o the syntax and possible values of parameters associated with the
545	EHLO keyword value;
546
547	o any additional SMTP verbs associated with the extension
548	(additional verbs will usually be, but are not required to be, the
549	same as the EHLO keyword value);
550
551	o any new parameters the extension associates with the MAIL or RCPT
552	verbs;
553
554	o a description of how support for the extension affects the
555	behavior of a server and client SMTP; and
556
557
558
559
560
561
562	Klensin Standards Track [Page 10]
563
564	RFC 5321 SMTP October 2008
565
566
567	o the increment by which the extension is increasing the maximum
568	length of the commands MAIL and/or RCPT, over that specified in
569	this Standard.
570
571	In addition, any EHLO keyword value starting with an upper or lower
572	case "X" refers to a local SMTP service extension used exclusively
573	through bilateral agreement. Keywords beginning with "X" MUST NOT be
574	used in a registered service extension. Conversely, keyword values
575	presented in the EHLO response that do not begin with "X" MUST
576	correspond to a Standard, Standards-Track, or IESG-approved
577	Experimental SMTP service extension registered with IANA. A
578	conforming server MUST NOT offer non-"X"-prefixed keyword values that
579	are not described in a registered extension.
580
581	Additional verbs and parameter names are bound by the same rules as
582	EHLO keywords; specifically, verbs beginning with "X" are local
583	extensions that may not be registered or standardized. Conversely,
584	verbs not beginning with "X" must always be registered.
585
586	2.2.3. Special Issues with Extensions
587
588	Extensions that change fairly basic properties of SMTP operation are
589	permitted. The text in other sections of this document must be
590	understood in that context. In particular, extensions can change the
591	minimum limits specified in Section 4.5.3, can change the ASCII
592	character set requirement as mentioned above, or can introduce some
593	optional modes of message handling.
594
595	In particular, if an extension implies that the delivery path
596	normally supports special features of that extension, and an
597	intermediate SMTP system finds a next hop that does not support the
598	required extension, it MAY choose, based on the specific extension
599	and circumstances, to requeue the message and try later and/or try an
600	alternate MX host. If this strategy is employed, the timeout to fall
601	back to an unextended format (if one is available) SHOULD be less
602	than the normal timeout for bouncing as undeliverable (e.g., if
603	normal timeout is three days, the requeue timeout before attempting
604	to transmit the mail without the extension might be one day).
605
606	2.3. SMTP Terminology
607
608	2.3.1. Mail Objects
609
610	SMTP transports a mail object. A mail object contains an envelope
611	and content.
612
613	The SMTP envelope is sent as a series of SMTP protocol units
614	(described in Section 3). It consists of an originator address (to
615
616
617
618	Klensin Standards Track [Page 11]
619
620	RFC 5321 SMTP October 2008
621
622
623	which error reports should be directed), one or more recipient
624	addresses, and optional protocol extension material. Historically,
625	variations on the reverse-path (originator) address specification
626	command (MAIL) could be used to specify alternate delivery modes,
627	such as immediate display; those variations have now been deprecated
628	(see Appendix F and Appendix F.6).
629
630	The SMTP content is sent in the SMTP DATA protocol unit and has two
631	parts: the header section and the body. If the content conforms to
632	other contemporary standards, the header section consists of a
633	collection of header fields, each consisting of a header name, a
634	colon, and data, structured as in the message format specification
635	(RFC 5322 [4]); the body, if structured, is defined according to MIME
636	(RFC 2045 [21]). The content is textual in nature, expressed using
637	the US-ASCII repertoire [6]. Although SMTP extensions (such as
638	"8BITMIME", RFC 1652 [22]) may relax this restriction for the content
639	body, the content header fields are always encoded using the US-ASCII
640	repertoire. Two MIME extensions (RFC 2047 [23] and RFC 2231 [24])
641	define an algorithm for representing header values outside the US-
642	ASCII repertoire, while still encoding them using the US-ASCII
643	repertoire.
644
645	2.3.2. Senders and Receivers
646
647	In RFC 821, the two hosts participating in an SMTP transaction were
648	described as the "SMTP-sender" and "SMTP-receiver". This document
649	has been changed to reflect current industry terminology and hence
650	refers to them as the "SMTP client" (or sometimes just "the client")
651	and "SMTP server" (or just "the server"), respectively. Since a
652	given host may act both as server and client in a relay situation,
653	"receiver" and "sender" terminology is still used where needed for
654	clarity.
655
656	2.3.3. Mail Agents and Message Stores
657
658	Additional mail system terminology became common after RFC 821 was
659	published and, where convenient, is used in this specification. In
660	particular, SMTP servers and clients provide a mail transport service
661	and therefore act as "Mail Transfer Agents" (MTAs). "Mail User
662	Agents" (MUAs or UAs) are normally thought of as the sources and
663	targets of mail. At the source, an MUA might collect mail to be
664	transmitted from a user and hand it off to an MTA; the final
665	("delivery") MTA would be thought of as handing the mail off to an
666	MUA (or at least transferring responsibility to it, e.g., by
667	depositing the message in a "message store"). However, while these
668	terms are used with at least the appearance of great precision in
669	other environments, the implied boundaries between MUAs and MTAs
670	often do not accurately match common, and conforming, practices with
671
672
673
674	Klensin Standards Track [Page 12]
675
676	RFC 5321 SMTP October 2008
677
678
679	Internet mail. Hence, the reader should be cautious about inferring
680	the strong relationships and responsibilities that might be implied
681	if these terms were used elsewhere.
682
683	2.3.4. Host
684
685	For the purposes of this specification, a host is a computer system
686	attached to the Internet (or, in some cases, to a private TCP/IP
687	network) and supporting the SMTP protocol. Hosts are known by names
688	(see the next section); they SHOULD NOT be identified by numerical
689	addresses, i.e., by address literals as described in Section 4.1.2.
690
691	2.3.5. Domain Names
692
693	A domain name (or often just a "domain") consists of one or more
694	components, separated by dots if more than one appears. In the case
695	of a top-level domain used by itself in an email address, a single
696	string is used without any dots. This makes the requirement,
697	described in more detail below, that only fully-qualified domain
698	names appear in SMTP transactions on the public Internet,
699	particularly important where top-level domains are involved. These
700	components ("labels" in DNS terminology, RFC 1035 [2]) are restricted
701	for SMTP purposes to consist of a sequence of letters, digits, and
702	hyphens drawn from the ASCII character set [6]. Domain names are
703	used as names of hosts and of other entities in the domain name
704	hierarchy. For example, a domain may refer to an alias (label of a
705	CNAME RR) or the label of Mail eXchanger records to be used to
706	deliver mail instead of representing a host name. See RFC 1035 [2]
707	and Section 5 of this specification.
708
709	The domain name, as described in this document and in RFC 1035 [2],
710	is the entire, fully-qualified name (often referred to as an "FQDN").
711	A domain name that is not in FQDN form is no more than a local alias.
712	Local aliases MUST NOT appear in any SMTP transaction.
713
714	Only resolvable, fully-qualified domain names (FQDNs) are permitted
715	when domain names are used in SMTP. In other words, names that can
716	be resolved to MX RRs or address (i.e., A or AAAA) RRs (as discussed
717	in Section 5) are permitted, as are CNAME RRs whose targets can be
718	resolved, in turn, to MX or address RRs. Local nicknames or
719	unqualified names MUST NOT be used. There are two exceptions to the
720	rule requiring FQDNs:
721
722	o The domain name given in the EHLO command MUST be either a primary
723	host name (a domain name that resolves to an address RR) or, if
724	the host has no name, an address literal, as described in
725	Section 4.1.3 and discussed further in the EHLO discussion of
726	Section 4.1.4.
727
728
729
730	Klensin Standards Track [Page 13]
731
732	RFC 5321 SMTP October 2008
733
734
735	o The reserved mailbox name "postmaster" may be used in a RCPT
736	command without domain qualification (see Section 4.1.1.3) and
737	MUST be accepted if so used.
738
739	2.3.6. Buffer and State Table
740
741	SMTP sessions are stateful, with both parties carefully maintaining a
742	common view of the current state. In this document, we model this
743	state by a virtual "buffer" and a "state table" on the server that
744	may be used by the client to, for example, "clear the buffer" or
745	"reset the state table", causing the information in the buffer to be
746	discarded and the state to be returned to some previous state.
747
748	2.3.7. Commands and Replies
749
750	SMTP commands and, unless altered by a service extension, message
751	data, are transmitted from the sender to the receiver via the
752	transmission channel in "lines".
753
754	An SMTP reply is an acknowledgment (positive or negative) sent in
755	"lines" from receiver to sender via the transmission channel in
756	response to a command. The general form of a reply is a numeric
757	completion code (indicating failure or success) usually followed by a
758	text string. The codes are for use by programs and the text is
759	usually intended for human users. RFC 3463 [25], specifies further
760	structuring of the reply strings, including the use of supplemental
761	and more specific completion codes (see also RFC 5248 [26]).
762
763	2.3.8. Lines
764
765	Lines consist of zero or more data characters terminated by the
766	sequence ASCII character "CR" (hex value 0D) followed immediately by
767	ASCII character "LF" (hex value 0A). This termination sequence is
768	denoted as <CRLF> in this document. Conforming implementations MUST
769	NOT recognize or generate any other character or character sequence
770	as a line terminator. Limits MAY be imposed on line lengths by
771	servers (see Section 4).
772
773	In addition, the appearance of "bare" "CR" or "LF" characters in text
774	(i.e., either without the other) has a long history of causing
775	problems in mail implementations and applications that use the mail
776	system as a tool. SMTP client implementations MUST NOT transmit
777	these characters except when they are intended as line terminators
778	and then MUST, as indicated above, transmit them only as a <CRLF>
779	sequence.
780
781
782
783
784
785
786	Klensin Standards Track [Page 14]
787
788	RFC 5321 SMTP October 2008
789
790
791	2.3.9. Message Content and Mail Data
792
793	The terms "message content" and "mail data" are used interchangeably
794	in this document to describe the material transmitted after the DATA
795	command is accepted and before the end of data indication is
796	transmitted. Message content includes the message header section and
797	the possibly structured message body. The MIME specification (RFC
798	2045 [21]) provides the standard mechanisms for structured message
799	bodies.
800
801	2.3.10. Originator, Delivery, Relay, and Gateway Systems
802
803	This specification makes a distinction among four types of SMTP
804	systems, based on the role those systems play in transmitting
805	electronic mail. An "originating" system (sometimes called an SMTP
806	originator) introduces mail into the Internet or, more generally,
807	into a transport service environment. A "delivery" SMTP system is
808	one that receives mail from a transport service environment and
809	passes it to a mail user agent or deposits it in a message store that
810	a mail user agent is expected to subsequently access. A "relay" SMTP
811	system (usually referred to just as a "relay") receives mail from an
812	SMTP client and transmits it, without modification to the message
813	data other than adding trace information, to another SMTP server for
814	further relaying or for delivery.
815
816	A "gateway" SMTP system (usually referred to just as a "gateway")
817	receives mail from a client system in one transport environment and
818	transmits it to a server system in another transport environment.
819	Differences in protocols or message semantics between the transport
820	environments on either side of a gateway may require that the gateway
821	system perform transformations to the message that are not permitted
822	to SMTP relay systems. For the purposes of this specification,
823	firewalls that rewrite addresses should be considered as gateways,
824	even if SMTP is used on both sides of them (see RFC 2979 [27]).
825
826	2.3.11. Mailbox and Address
827
828	As used in this specification, an "address" is a character string
829	that identifies a user to whom mail will be sent or a location into
830	which mail will be deposited. The term "mailbox" refers to that
831	depository. The two terms are typically used interchangeably unless
832	the distinction between the location in which mail is placed (the
833	mailbox) and a reference to it (the address) is important. An
834	address normally consists of user and domain specifications. The
835	standard mailbox naming convention is defined to be
836	"local-part@domain"; contemporary usage permits a much broader set of
837	applications than simple "user names". Consequently, and due to a
838	long history of problems when intermediate hosts have attempted to
839
840
841
842	Klensin Standards Track [Page 15]
843
844	RFC 5321 SMTP October 2008
845
846
847	optimize transport by modifying them, the local-part MUST be
848	interpreted and assigned semantics only by the host specified in the
849	domain part of the address.
850
851	2.4. General Syntax Principles and Transaction Model
852
853	SMTP commands and replies have a rigid syntax. All commands begin
854	with a command verb. All replies begin with a three digit numeric
855	code. In some commands and replies, arguments are required following
856	the verb or reply code. Some commands do not accept arguments (after
857	the verb), and some reply codes are followed, sometimes optionally,
858	by free form text. In both cases, where text appears, it is
859	separated from the verb or reply code by a space character. Complete
860	definitions of commands and replies appear in Section 4.
861
862	Verbs and argument values (e.g., "TO:" or "to:" in the RCPT command
863	and extension name keywords) are not case sensitive, with the sole
864	exception in this specification of a mailbox local-part (SMTP
865	Extensions may explicitly specify case-sensitive elements). That is,
866	a command verb, an argument value other than a mailbox local-part,
867	and free form text MAY be encoded in upper case, lower case, or any
868	mixture of upper and lower case with no impact on its meaning. The
869	local-part of a mailbox MUST BE treated as case sensitive.
870	Therefore, SMTP implementations MUST take care to preserve the case
871	of mailbox local-parts. In particular, for some hosts, the user
872	"smith" is different from the user "Smith". However, exploiting the
873	case sensitivity of mailbox local-parts impedes interoperability and
874	is discouraged. Mailbox domains follow normal DNS rules and are
875	hence not case sensitive.
876
877	A few SMTP servers, in violation of this specification (and RFC 821)
878	require that command verbs be encoded by clients in upper case.
879	Implementations MAY wish to employ this encoding to accommodate those
880	servers.
881
882	The argument clause consists of a variable-length character string
883	ending with the end of the line, i.e., with the character sequence
884	<CRLF>. The receiver will take no action until this sequence is
885	received.
886
887	The syntax for each command is shown with the discussion of that
888	command. Common elements and parameters are shown in Section 4.1.2.
889
890	Commands and replies are composed of characters from the ASCII
891	character set [6]. When the transport service provides an 8-bit byte
892	(octet) transmission channel, each 7-bit character is transmitted,
893	right justified, in an octet with the high-order bit cleared to zero.
894	More specifically, the unextended SMTP service provides 7-bit
895
896
897
898	Klensin Standards Track [Page 16]
899
900	RFC 5321 SMTP October 2008
901
902
903	transport only. An originating SMTP client that has not successfully
904	negotiated an appropriate extension with a particular server (see the
905	next paragraph) MUST NOT transmit messages with information in the
906	high-order bit of octets. If such messages are transmitted in
907	violation of this rule, receiving SMTP servers MAY clear the high-
908	order bit or reject the message as invalid. In general, a relay SMTP
909	SHOULD assume that the message content it has received is valid and,
910	assuming that the envelope permits doing so, relay it without
911	inspecting that content. Of course, if the content is mislabeled and
912	the data path cannot accept the actual content, this may result in
913	the ultimate delivery of a severely garbled message to the recipient.
914	Delivery SMTP systems MAY reject such messages, or return them as
915	undeliverable, rather than deliver them. In the absence of a server-
916	offered extension explicitly permitting it, a sending SMTP system is
917	not permitted to send envelope commands in any character set other
918	than US-ASCII. Receiving systems SHOULD reject such commands,
919	normally using "500 syntax error - invalid character" replies.
920
921	8-bit message content transmission MAY be requested of the server by
922	a client using extended SMTP facilities, notably the "8BITMIME"
923	extension, RFC 1652 [22]. 8BITMIME SHOULD be supported by SMTP
924	servers. However, it MUST NOT be construed as authorization to
925	transmit unrestricted 8-bit material, nor does 8BITMIME authorize
926	transmission of any envelope material in other than ASCII. 8BITMIME
927	MUST NOT be requested by senders for material with the high bit on
928	that is not in MIME format with an appropriate content-transfer
929	encoding; servers MAY reject such messages.
930
931	The metalinguistic notation used in this document corresponds to the
932	"Augmented BNF" used in other Internet mail system documents. The
933	reader who is not familiar with that syntax should consult the ABNF
934	specification in RFC 5234 [7]. Metalanguage terms used in running
935	text are surrounded by pointed brackets (e.g., <CRLF>) for clarity.
936	The reader is cautioned that the grammar expressed in the
937	metalanguage is not comprehensive. There are many instances in which
938	provisions in the text constrain or otherwise modify the syntax or
939	semantics implied by the grammar.
940
941	3. The SMTP Procedures: An Overview
942
943	This section contains descriptions of the procedures used in SMTP:
944	session initiation, mail transaction, forwarding mail, verifying
945	mailbox names and expanding mailing lists, and opening and closing
946	exchanges. Comments on relaying, a note on mail domains, and a
947	discussion of changing roles are included at the end of this section.
948	Several complete scenarios are presented in Appendix D.
949
950
951
952
953
954	Klensin Standards Track [Page 17]
955
956	RFC 5321 SMTP October 2008
957
958
959	3.1. Session Initiation
960
961	An SMTP session is initiated when a client opens a connection to a
962	server and the server responds with an opening message.
963
964	SMTP server implementations MAY include identification of their
965	software and version information in the connection greeting reply
966	after the 220 code, a practice that permits more efficient isolation
967	and repair of any problems. Implementations MAY make provision for
968	SMTP servers to disable the software and version announcement where
969	it causes security concerns. While some systems also identify their
970	contact point for mail problems, this is not a substitute for
971	maintaining the required "postmaster" address (see Section 4).
972
973	The SMTP protocol allows a server to formally reject a mail session
974	while still allowing the initial connection as follows: a 554
975	response MAY be given in the initial connection opening message
976	instead of the 220. A server taking this approach MUST still wait
977	for the client to send a QUIT (see Section 4.1.1.10) before closing
978	the connection and SHOULD respond to any intervening commands with
979	"503 bad sequence of commands". Since an attempt to make an SMTP
980	connection to such a system is probably in error, a server returning
981	a 554 response on connection opening SHOULD provide enough
982	information in the reply text to facilitate debugging of the sending
983	system.
984
985	3.2. Client Initiation
986
987	Once the server has sent the greeting (welcoming) message and the
988	client has received it, the client normally sends the EHLO command to
989	the server, indicating the client's identity. In addition to opening
990	the session, use of EHLO indicates that the client is able to process
991	service extensions and requests that the server provide a list of the
992	extensions it supports. Older SMTP systems that are unable to
993	support service extensions, and contemporary clients that do not
994	require service extensions in the mail session being initiated, MAY
995	use HELO instead of EHLO. Servers MUST NOT return the extended EHLO-
996	style response to a HELO command. For a particular connection
997	attempt, if the server returns a "command not recognized" response to
998	EHLO, the client SHOULD be able to fall back and send HELO.
999
1000	In the EHLO command, the host sending the command identifies itself;
1001	the command may be interpreted as saying "Hello, I am <domain>" (and,
1002	in the case of EHLO, "and I support service extension requests").
1003
1004
1005
1006
1007
1008
1009
1010	Klensin Standards Track [Page 18]
1011
1012	RFC 5321 SMTP October 2008
1013
1014
1015	3.3. Mail Transactions
1016
1017	There are three steps to SMTP mail transactions. The transaction
1018	starts with a MAIL command that gives the sender identification. (In
1019	general, the MAIL command may be sent only when no mail transaction
1020	is in progress; see Section 4.1.4.) A series of one or more RCPT
1021	commands follows, giving the receiver information. Then, a DATA
1022	command initiates transfer of the mail data and is terminated by the
1023	"end of mail" data indicator, which also confirms the transaction.
1024
1025	The first step in the procedure is the MAIL command.
1026
1027	MAIL FROM:<reverse-path> [SP <mail-parameters> ] <CRLF>
1028
1029	This command tells the SMTP-receiver that a new mail transaction is
1030	starting and to reset all its state tables and buffers, including any
1031	recipients or mail data. The <reverse-path> portion of the first or
1032	only argument contains the source mailbox (between "<" and ">"
1033	brackets), which can be used to report errors (see Section 4.2 for a
1034	discussion of error reporting). If accepted, the SMTP server returns
1035	a "250 OK" reply. If the mailbox specification is not acceptable for
1036	some reason, the server MUST return a reply indicating whether the
1037	failure is permanent (i.e., will occur again if the client tries to
1038	send the same address again) or temporary (i.e., the address might be
1039	accepted if the client tries again later). Despite the apparent
1040	scope of this requirement, there are circumstances in which the
1041	acceptability of the reverse-path may not be determined until one or
1042	more forward-paths (in RCPT commands) can be examined. In those
1043	cases, the server MAY reasonably accept the reverse-path (with a 250
1044	reply) and then report problems after the forward-paths are received
1045	and examined. Normally, failures produce 550 or 553 replies.
1046
1047	Historically, the <reverse-path> was permitted to contain more than
1048	just a mailbox; however, contemporary systems SHOULD NOT use source
1049	routing (see Appendix C).
1050
1051	The optional <mail-parameters> are associated with negotiated SMTP
1052	service extensions (see Section 2.2).
1053
1054	The second step in the procedure is the RCPT command. This step of
1055	the procedure can be repeated any number of times.
1056
1057	RCPT TO:<forward-path> [ SP <rcpt-parameters> ] <CRLF>
1058
1059	The first or only argument to this command includes a forward-path
1060	(normally a mailbox and domain, always surrounded by "<" and ">"
1061	brackets) identifying one recipient. If accepted, the SMTP server
1062	returns a "250 OK" reply and stores the forward-path. If the
1063
1064
1065
1066	Klensin Standards Track [Page 19]
1067
1068	RFC 5321 SMTP October 2008
1069
1070
1071	recipient is known not to be a deliverable address, the SMTP server
1072	returns a 550 reply, typically with a string such as "no such user -
1073	" and the mailbox name (other circumstances and reply codes are
1074	possible).
1075
1076	The <forward-path> can contain more than just a mailbox.
1077	Historically, the <forward-path> was permitted to contain a source
1078	routing list of hosts and the destination mailbox; however,
1079	contemporary SMTP clients SHOULD NOT utilize source routes (see
1080	Appendix C). Servers MUST be prepared to encounter a list of source
1081	routes in the forward-path, but they SHOULD ignore the routes or MAY
1082	decline to support the relaying they imply. Similarly, servers MAY
1083	decline to accept mail that is destined for other hosts or systems.
1084	These restrictions make a server useless as a relay for clients that
1085	do not support full SMTP functionality. Consequently, restricted-
1086	capability clients MUST NOT assume that any SMTP server on the
1087	Internet can be used as their mail processing (relaying) site. If a
1088	RCPT command appears without a previous MAIL command, the server MUST
1089	return a 503 "Bad sequence of commands" response. The optional
1090	<rcpt-parameters> are associated with negotiated SMTP service
1091	extensions (see Section 2.2).
1092
1093	Since it has been a common source of errors, it is worth noting that
1094	spaces are not permitted on either side of the colon following FROM
1095	in the MAIL command or TO in the RCPT command. The syntax is exactly
1096	as given above.
1097
1098	The third step in the procedure is the DATA command (or some
1099	alternative specified in a service extension).
1100
1101	DATA <CRLF>
1102
1103	If accepted, the SMTP server returns a 354 Intermediate reply and
1104	considers all succeeding lines up to but not including the end of
1105	mail data indicator to be the message text. When the end of text is
1106	successfully received and stored, the SMTP-receiver sends a "250 OK"
1107	reply.
1108
1109	Since the mail data is sent on the transmission channel, the end of
1110	mail data must be indicated so that the command and reply dialog can
1111	be resumed. SMTP indicates the end of the mail data by sending a
1112	line containing only a "." (period or full stop). A transparency
1113	procedure is used to prevent this from interfering with the user's
1114	text (see Section 4.5.2).
1115
1116	The end of mail data indicator also confirms the mail transaction and
1117	tells the SMTP server to now process the stored recipients and mail
1118
1119
1120
1121
1122	Klensin Standards Track [Page 20]
1123
1124	RFC 5321 SMTP October 2008
1125
1126
1127	data. If accepted, the SMTP server returns a "250 OK" reply. The
1128	DATA command can fail at only two points in the protocol exchange:
1129
1130	If there was no MAIL, or no RCPT, command, or all such commands were
1131	rejected, the server MAY return a "command out of sequence" (503) or
1132	"no valid recipients" (554) reply in response to the DATA command.
1133	If one of those replies (or any other 5yz reply) is received, the
1134	client MUST NOT send the message data; more generally, message data
1135	MUST NOT be sent unless a 354 reply is received.
1136
1137	If the verb is initially accepted and the 354 reply issued, the DATA
1138	command should fail only if the mail transaction was incomplete (for
1139	example, no recipients), if resources were unavailable (including, of
1140	course, the server unexpectedly becoming unavailable), or if the
1141	server determines that the message should be rejected for policy or
1142	other reasons.
1143
1144	However, in practice, some servers do not perform recipient
1145	verification until after the message text is received. These servers
1146	SHOULD treat a failure for one or more recipients as a "subsequent
1147	failure" and return a mail message as discussed in Section 6 and, in
1148	particular, in Section 6.1. Using a "550 mailbox not found" (or
1149	equivalent) reply code after the data are accepted makes it difficult
1150	or impossible for the client to determine which recipients failed.
1151
1152	When the RFC 822 format ([28], [4]) is being used, the mail data
1153	include the header fields such as those named Date, Subject, To, Cc,
1154	and From. Server SMTP systems SHOULD NOT reject messages based on
1155	perceived defects in the RFC 822 or MIME (RFC 2045 [21]) message
1156	header section or message body. In particular, they MUST NOT reject
1157	messages in which the numbers of Resent-header fields do not match or
1158	Resent-to appears without Resent-from and/or Resent-date.
1159
1160	Mail transaction commands MUST be used in the order discussed above.
1161
1162	3.4. Forwarding for Address Correction or Updating
1163
1164	Forwarding support is most often required to consolidate and simplify
1165	addresses within, or relative to, some enterprise and less frequently
1166	to establish addresses to link a person's prior address with a
1167	current one. Silent forwarding of messages (without server
1168	notification to the sender), for security or non-disclosure purposes,
1169	is common in the contemporary Internet.
1170
1171	In both the enterprise and the "new address" cases, information
1172	hiding (and sometimes security) considerations argue against exposure
1173	of the "final" address through the SMTP protocol as a side effect of
1174	the forwarding activity. This may be especially important when the
1175
1176
1177
1178	Klensin Standards Track [Page 21]
1179
1180	RFC 5321 SMTP October 2008
1181
1182
1183	final address may not even be reachable by the sender. Consequently,
1184	the "forwarding" mechanisms described in Section 3.2 of RFC 821, and
1185	especially the 251 (corrected destination) and 551 reply codes from
1186	RCPT must be evaluated carefully by implementers and, when they are
1187	available, by those configuring systems (see also Section 7.4).
1188
1189	In particular:
1190
1191	o Servers MAY forward messages when they are aware of an address
1192	change. When they do so, they MAY either provide address-updating
1193	information with a 251 code, or may forward "silently" and return
1194	a 250 code. However, if a 251 code is used, they MUST NOT assume
1195	that the client will actually update address information or even
1196	return that information to the user.
1197
1198	Alternately,
1199
1200	o Servers MAY reject messages or return them as non-deliverable when
1201	they cannot be delivered precisely as addressed. When they do so,
1202	they MAY either provide address-updating information with a 551
1203	code, or may reject the message as undeliverable with a 550 code
1204	and no address-specific information. However, if a 551 code is
1205	used, they MUST NOT assume that the client will actually update
1206	address information or even return that information to the user.
1207
1208	SMTP server implementations that support the 251 and/or 551 reply
1209	codes SHOULD provide configuration mechanisms so that sites that
1210	conclude that they would undesirably disclose information can disable
1211	or restrict their use.
1212
1213	3.5. Commands for Debugging Addresses
1214
1215	3.5.1. Overview
1216
1217	SMTP provides commands to verify a user name or obtain the content of
1218	a mailing list. This is done with the VRFY and EXPN commands, which
1219	have character string arguments. Implementations SHOULD support VRFY
1220	and EXPN (however, see Section 3.5.2 and Section 7.3).
1221
1222	For the VRFY command, the string is a user name or a user name and
1223	domain (see below). If a normal (i.e., 250) response is returned,
1224	the response MAY include the full name of the user and MUST include
1225	the mailbox of the user. It MUST be in either of the following
1226	forms:
1227
1228	User Name <local-part@domain>
1229	local-part@domain
1230
1231
1232
1233
1234	Klensin Standards Track [Page 22]
1235
1236	RFC 5321 SMTP October 2008
1237
1238
1239	When a name that is the argument to VRFY could identify more than one
1240	mailbox, the server MAY either note the ambiguity or identify the
1241	alternatives. In other words, any of the following are legitimate
1242	responses to VRFY:
1243
1244	553 User ambiguous
1245
1246	or
1247
1248	553- Ambiguous; Possibilities are
1249	553-Joe Smith <jsmith@foo.com>
1250	553-Harry Smith <hsmith@foo.com>
1251	553 Melvin Smith <dweep@foo.com>
1252
1253	or
1254
1255	553-Ambiguous; Possibilities
1256	553- <jsmith@foo.com>
1257	553- <hsmith@foo.com>
1258	553 <dweep@foo.com>
1259
1260	Under normal circumstances, a client receiving a 553 reply would be
1261	expected to expose the result to the user. Use of exactly the forms
1262	given, and the "user ambiguous" or "ambiguous" keywords, possibly
1263	supplemented by extended reply codes, such as those described in RFC
1264	3463 [25], will facilitate automated translation into other languages
1265	as needed. Of course, a client that was highly automated or that was
1266	operating in another language than English might choose to try to
1267	translate the response to return some other indication to the user
1268	than the literal text of the reply, or to take some automated action
1269	such as consulting a directory service for additional information
1270	before reporting to the user.
1271
1272	For the EXPN command, the string identifies a mailing list, and the
1273	successful (i.e., 250) multiline response MAY include the full name
1274	of the users and MUST give the mailboxes on the mailing list.
1275
1276	In some hosts, the distinction between a mailing list and an alias
1277	for a single mailbox is a bit fuzzy, since a common data structure
1278	may hold both types of entries, and it is possible to have mailing
1279	lists containing only one mailbox. If a request is made to apply
1280	VRFY to a mailing list, a positive response MAY be given if a message
1281	so addressed would be delivered to everyone on the list, otherwise an
1282	error SHOULD be reported (e.g., "550 That is a mailing list, not a
1283	user" or "252 Unable to verify members of mailing list"). If a
1284	request is made to expand a user name, the server MAY return a
1285
1286
1287
1288
1289
1290	Klensin Standards Track [Page 23]
1291
1292	RFC 5321 SMTP October 2008
1293
1294
1295	positive response consisting of a list containing one name, or an
1296	error MAY be reported (e.g., "550 That is a user name, not a mailing
1297	list").
1298
1299	In the case of a successful multiline reply (normal for EXPN),
1300	exactly one mailbox is to be specified on each line of the reply.
1301	The case of an ambiguous request is discussed above.
1302
1303	"User name" is a fuzzy term and has been used deliberately. An
1304	implementation of the VRFY or EXPN commands MUST include at least
1305	recognition of local mailboxes as "user names". However, since
1306	current Internet practice often results in a single host handling
1307	mail for multiple domains, hosts, especially hosts that provide this
1308	functionality, SHOULD accept the "local-part@domain" form as a "user
1309	name"; hosts MAY also choose to recognize other strings as "user
1310	names".
1311
1312	The case of expanding a mailbox list requires a multiline reply, such
1313	as:
1314
1315	C: EXPN Example-People
1316	S: 250-Jon Postel <Postel@isi.edu>
1317	S: 250-Fred Fonebone <Fonebone@physics.foo-u.edu>
1318	S: 250 Sam Q. Smith <SQSmith@specific.generic.com>
1319
1320	or
1321
1322	C: EXPN Executive-Washroom-List
1323	S: 550 Access Denied to You.
1324
1325	The character string arguments of the VRFY and EXPN commands cannot
1326	be further restricted due to the variety of implementations of the
1327	user name and mailbox list concepts. On some systems, it may be
1328	appropriate for the argument of the EXPN command to be a file name
1329	for a file containing a mailing list, but again there are a variety
1330	of file naming conventions in the Internet. Similarly, historical
1331	variations in what is returned by these commands are such that the
1332	response SHOULD be interpreted very carefully, if at all, and SHOULD
1333	generally only be used for diagnostic purposes.
1334
1335	3.5.2. VRFY Normal Response
1336
1337	When normal (2yz or 551) responses are returned from a VRFY or EXPN
1338	request, the reply MUST include the <Mailbox> name using a
1339	"<local-part@domain>" construction, where "domain" is a fully-
1340	qualified domain name. In circumstances exceptional enough to
1341	justify violating the intent of this specification, free-form text
1342	MAY be returned. In order to facilitate parsing by both computers
1343
1344
1345
1346	Klensin Standards Track [Page 24]
1347
1348	RFC 5321 SMTP October 2008
1349
1350
1351	and people, addresses SHOULD appear in pointed brackets. When
1352	addresses, rather than free-form debugging information, are returned,
1353	EXPN and VRFY MUST return only valid domain addresses that are usable
1354	in SMTP RCPT commands. Consequently, if an address implies delivery
1355	to a program or other system, the mailbox name used to reach that
1356	target MUST be given. Paths (explicit source routes) MUST NOT be
1357	returned by VRFY or EXPN.
1358
1359	Server implementations SHOULD support both VRFY and EXPN. For
1360	security reasons, implementations MAY provide local installations a
1361	way to disable either or both of these commands through configuration
1362	options or the equivalent (see Section 7.3). When these commands are
1363	supported, they are not required to work across relays when relaying
1364	is supported. Since they were both optional in RFC 821, but VRFY was
1365	made mandatory in RFC 1123 [3], if EXPN is supported, it MUST be
1366	listed as a service extension in an EHLO response. VRFY MAY be
1367	listed as a convenience but, since support for it is required, SMTP
1368	clients are not required to check for its presence on the extension
1369	list before using it.
1370
1371	3.5.3. Meaning of VRFY or EXPN Success Response
1372
1373	A server MUST NOT return a 250 code in response to a VRFY or EXPN
1374	command unless it has actually verified the address. In particular,
1375	a server MUST NOT return 250 if all it has done is to verify that the
1376	syntax given is valid. In that case, 502 (Command not implemented)
1377	or 500 (Syntax error, command unrecognized) SHOULD be returned. As
1378	stated elsewhere, implementation (in the sense of actually validating
1379	addresses and returning information) of VRFY and EXPN are strongly
1380	recommended. Hence, implementations that return 500 or 502 for VRFY
1381	are not in full compliance with this specification.
1382
1383	There may be circumstances where an address appears to be valid but
1384	cannot reasonably be verified in real time, particularly when a
1385	server is acting as a mail exchanger for another server or domain.
1386	"Apparent validity", in this case, would normally involve at least
1387	syntax checking and might involve verification that any domains
1388	specified were ones to which the host expected to be able to relay
1389	mail. In these situations, reply code 252 SHOULD be returned. These
1390	cases parallel the discussion of RCPT verification in Section 2.1.
1391	Similarly, the discussion in Section 3.4 applies to the use of reply
1392	codes 251 and 551 with VRFY (and EXPN) to indicate addresses that are
1393	recognized but that would be forwarded or rejected were mail received
1394	for them. Implementations generally SHOULD be more aggressive about
1395	address verification in the case of VRFY than in the case of RCPT,
1396	even if it takes a little longer to do so.
1397
1398
1399
1400
1401
1402	Klensin Standards Track [Page 25]
1403
1404	RFC 5321 SMTP October 2008
1405
1406
1407	3.5.4. Semantics and Applications of EXPN
1408
1409	EXPN is often very useful in debugging and understanding problems
1410	with mailing lists and multiple-target-address aliases. Some systems
1411	have attempted to use source expansion of mailing lists as a means of
1412	eliminating duplicates. The propagation of aliasing systems with
1413	mail on the Internet for hosts (typically with MX and CNAME DNS
1414	records), for mailboxes (various types of local host aliases), and in
1415	various proxying arrangements has made it nearly impossible for these
1416	strategies to work consistently, and mail systems SHOULD NOT attempt
1417	them.
1418
1419	3.6. Relaying and Mail Routing
1420
1421	3.6.1. Source Routes and Relaying
1422
1423	In general, the availability of Mail eXchanger records in the domain
1424	name system (RFC 1035 [2], RFC 974 [12]) makes the use of explicit
1425	source routes in the Internet mail system unnecessary. Many
1426	historical problems with the interpretation of explicit source routes
1427	have made their use undesirable. SMTP clients SHOULD NOT generate
1428	explicit source routes except under unusual circumstances. SMTP
1429	servers MAY decline to act as mail relays or to accept addresses that
1430	specify source routes. When route information is encountered, SMTP
1431	servers MAY ignore the route information and simply send to the final
1432	destination specified as the last element in the route and SHOULD do
1433	so. There has been an invalid practice of using names that do not
1434	appear in the DNS as destination names, with the senders counting on
1435	the intermediate hosts specified in source routing to resolve any
1436	problems. If source routes are stripped, this practice will cause
1437	failures. This is one of several reasons why SMTP clients MUST NOT
1438	generate invalid source routes or depend on serial resolution of
1439	names.
1440
1441	When source routes are not used, the process described in RFC 821 for
1442	constructing a reverse-path from the forward-path is not applicable
1443	and the reverse-path at the time of delivery will simply be the
1444	address that appeared in the MAIL command.
1445
1446	3.6.2. Mail eXchange Records and Relaying
1447
1448	A relay SMTP server is usually the target of a DNS MX record that
1449	designates it, rather than the final delivery system. The relay
1450	server may accept or reject the task of relaying the mail in the same
1451	way it accepts or rejects mail for a local user. If it accepts the
1452	task, it then becomes an SMTP client, establishes a transmission
1453	channel to the next SMTP server specified in the DNS (according to
1454	the rules in Section 5), and sends it the mail. If it declines to
1455
1456
1457
1458	Klensin Standards Track [Page 26]
1459
1460	RFC 5321 SMTP October 2008
1461
1462
1463	relay mail to a particular address for policy reasons, a 550 response
1464	SHOULD be returned.
1465
1466	This specification does not deal with the verification of return
1467	paths for use in delivery notifications. Recent work, such as that
1468	on SPF [29] and DKIM [30] [31], has been done to provide ways to
1469	ascertain that an address is valid or belongs to the person who
1470	actually sent the message. A server MAY attempt to verify the return
1471	path before using its address for delivery notifications, but methods
1472	of doing so are not defined here nor is any particular method
1473	recommended at this time.
1474
1475	3.6.3. Message Submission Servers as Relays
1476
1477	Many mail-sending clients exist, especially in conjunction with
1478	facilities that receive mail via POP3 or IMAP, that have limited
1479	capability to support some of the requirements of this specification,
1480	such as the ability to queue messages for subsequent delivery
1481	attempts. For these clients, it is common practice to make private
1482	arrangements to send all messages to a single server for processing
1483	and subsequent distribution. SMTP, as specified here, is not ideally
1484	suited for this role. A standardized mail submission protocol has
1485	been developed that is gradually superseding practices based on SMTP
1486	(see RFC 4409 [18]). In any event, because these arrangements are
1487	private and fall outside the scope of this specification, they are
1488	not described here.
1489
1490	It is important to note that MX records can point to SMTP servers
1491	that act as gateways into other environments, not just SMTP relays
1492	and final delivery systems; see Sections 3.7 and 5.
1493
1494	If an SMTP server has accepted the task of relaying the mail and
1495	later finds that the destination is incorrect or that the mail cannot
1496	be delivered for some other reason, then it MUST construct an
1497	"undeliverable mail" notification message and send it to the
1498	originator of the undeliverable mail (as indicated by the reverse-
1499	path). Formats specified for non-delivery reports by other standards
1500	(see, for example, RFC 3461 [32] and RFC 3464 [33]) SHOULD be used if
1501	possible.
1502
1503	This notification message must be from the SMTP server at the relay
1504	host or the host that first determines that delivery cannot be
1505	accomplished. Of course, SMTP servers MUST NOT send notification
1506	messages about problems transporting notification messages. One way
1507	to prevent loops in error reporting is to specify a null reverse-path
1508	in the MAIL command of a notification message. When such a message
1509	is transmitted, the reverse-path MUST be set to null (see
1510
1511
1512
1513
1514	Klensin Standards Track [Page 27]
1515
1516	RFC 5321 SMTP October 2008
1517
1518
1519	Section 4.5.5 for additional discussion). A MAIL command with a null
1520	reverse-path appears as follows:
1521
1522	MAIL FROM:<>
1523
1524	As discussed in Section 6.4, a relay SMTP has no need to inspect or
1525	act upon the header section or body of the message data and MUST NOT
1526	do so except to add its own "Received:" header field (Section 4.4)
1527	and, optionally, to attempt to detect looping in the mail system (see
1528	Section 6.3). Of course, this prohibition also applies to any
1529	modifications of these header fields or text (see also Section 7.9).
1530
1531	3.7. Mail Gatewaying
1532
1533	While the relay function discussed above operates within the Internet
1534	SMTP transport service environment, MX records or various forms of
1535	explicit routing may require that an intermediate SMTP server perform
1536	a translation function between one transport service and another. As
1537	discussed in Section 2.3.10, when such a system is at the boundary
1538	between two transport service environments, we refer to it as a
1539	"gateway" or "gateway SMTP".
1540
1541	Gatewaying mail between different mail environments, such as
1542	different mail formats and protocols, is complex and does not easily
1543	yield to standardization. However, some general requirements may be
1544	given for a gateway between the Internet and another mail
1545	environment.
1546
1547	3.7.1. Header Fields in Gatewaying
1548
1549	Header fields MAY be rewritten when necessary as messages are
1550	gatewayed across mail environment boundaries. This may involve
1551	inspecting the message body or interpreting the local-part of the
1552	destination address in spite of the prohibitions in Section 6.4.
1553
1554	Other mail systems gatewayed to the Internet often use a subset of
1555	the RFC 822 header section or provide similar functionality with a
1556	different syntax, but some of these mail systems do not have an
1557	equivalent to the SMTP envelope. Therefore, when a message leaves
1558	the Internet environment, it may be necessary to fold the SMTP
1559	envelope information into the message header section. A possible
1560	solution would be to create new header fields to carry the envelope
1561	information (e.g., "X-SMTP-MAIL:" and "X-SMTP-RCPT:"); however, this
1562	would require changes in mail programs in foreign environments and
1563	might risk disclosure of private information (see Section 7.2).
1564
1565
1566
1567
1568
1569
1570	Klensin Standards Track [Page 28]
1571
1572	RFC 5321 SMTP October 2008
1573
1574
1575	3.7.2. Received Lines in Gatewaying
1576
1577	When forwarding a message into or out of the Internet environment, a
1578	gateway MUST prepend a Received: line, but it MUST NOT alter in any
1579	way a Received: line that is already in the header section.
1580
1581	"Received:" header fields of messages originating from other
1582	environments may not conform exactly to this specification. However,
1583	the most important use of Received: lines is for debugging mail
1584	faults, and this debugging can be severely hampered by well-meaning
1585	gateways that try to "fix" a Received: line. As another consequence
1586	of trace header fields arising in non-SMTP environments, receiving
1587	systems MUST NOT reject mail based on the format of a trace header
1588	field and SHOULD be extremely robust in the light of unexpected
1589	information or formats in those header fields.
1590
1591	The gateway SHOULD indicate the environment and protocol in the "via"
1592	clauses of Received header field(s) that it supplies.
1593
1594	3.7.3. Addresses in Gatewaying
1595
1596	From the Internet side, the gateway SHOULD accept all valid address
1597	formats in SMTP commands and in the RFC 822 header section, and all
1598	valid RFC 822 messages. Addresses and header fields generated by
1599	gateways MUST conform to applicable standards (including this one and
1600	RFC 5322 [4]). Gateways are, of course, subject to the same rules
1601	for handling source routes as those described for other SMTP systems
1602	in Section 3.3.
1603
1604	3.7.4. Other Header Fields in Gatewaying
1605
1606	The gateway MUST ensure that all header fields of a message that it
1607	forwards into the Internet mail environment meet the requirements for
1608	Internet mail. In particular, all addresses in "From:", "To:",
1609	"Cc:", etc., header fields MUST be transformed (if necessary) to
1610	satisfy the standard header syntax of RFC 5322 [4], MUST reference
1611	only fully-qualified domain names, and MUST be effective and useful
1612	for sending replies. The translation algorithm used to convert mail
1613	from the Internet protocols to another environment's protocol SHOULD
1614	ensure that error messages from the foreign mail environment are
1615	delivered to the reverse-path from the SMTP envelope, not to an
1616	address in the "From:", "Sender:", or similar header fields of the
1617	message.
1618
1619
1620
1621
1622
1623
1624
1625
1626	Klensin Standards Track [Page 29]
1627
1628	RFC 5321 SMTP October 2008
1629
1630
1631	3.7.5. Envelopes in Gatewaying
1632
1633	Similarly, when forwarding a message from another environment into
1634	the Internet, the gateway SHOULD set the envelope return path in
1635	accordance with an error message return address, if supplied by the
1636	foreign environment. If the foreign environment has no equivalent
1637	concept, the gateway must select and use a best approximation, with
1638	the message originator's address as the default of last resort.
1639
1640	3.8. Terminating Sessions and Connections
1641
1642	An SMTP connection is terminated when the client sends a QUIT
1643	command. The server responds with a positive reply code, after which
1644	it closes the connection.
1645
1646	An SMTP server MUST NOT intentionally close the connection under
1647	normal operational circumstances (see Section 7.8) except:
1648
1649	o After receiving a QUIT command and responding with a 221 reply.
1650
1651	o After detecting the need to shut down the SMTP service and
1652	returning a 421 response code. This response code can be issued
1653	after the server receives any command or, if necessary,
1654	asynchronously from command receipt (on the assumption that the
1655	client will receive it after the next command is issued).
1656
1657	o After a timeout, as specified in Section 4.5.3.2, occurs waiting
1658	for the client to send a command or data.
1659
1660	In particular, a server that closes connections in response to
1661	commands that are not understood is in violation of this
1662	specification. Servers are expected to be tolerant of unknown
1663	commands, issuing a 500 reply and awaiting further instructions from
1664	the client.
1665
1666	An SMTP server that is forcibly shut down via external means SHOULD
1667	attempt to send a line containing a 421 response code to the SMTP
1668	client before exiting. The SMTP client will normally read the 421
1669	response code after sending its next command.
1670
1671	SMTP clients that experience a connection close, reset, or other
1672	communications failure due to circumstances not under their control
1673	(in violation of the intent of this specification but sometimes
1674	unavoidable) SHOULD, to maintain the robustness of the mail system,
1675	treat the mail transaction as if a 451 response had been received and
1676	act accordingly.
1677
1678
1679
1680
1681
1682	Klensin Standards Track [Page 30]
1683
1684	RFC 5321 SMTP October 2008
1685
1686
1687	3.9. Mailing Lists and Aliases
1688
1689	An SMTP-capable host SHOULD support both the alias and the list
1690	models of address expansion for multiple delivery. When a message is
1691	delivered or forwarded to each address of an expanded list form, the
1692	return address in the envelope ("MAIL FROM:") MUST be changed to be
1693	the address of a person or other entity who administers the list.
1694	However, in this case, the message header section (RFC 5322 [4]) MUST
1695	be left unchanged; in particular, the "From" field of the header
1696	section is unaffected.
1697
1698	An important mail facility is a mechanism for multi-destination
1699	delivery of a single message, by transforming (or "expanding" or
1700	"exploding") a pseudo-mailbox address into a list of destination
1701	mailbox addresses. When a message is sent to such a pseudo-mailbox
1702	(sometimes called an "exploder"), copies are forwarded or
1703	redistributed to each mailbox in the expanded list. Servers SHOULD
1704	simply utilize the addresses on the list; application of heuristics
1705	or other matching rules to eliminate some addresses, such as that of
1706	the originator, is strongly discouraged. We classify such a pseudo-
1707	mailbox as an "alias" or a "list", depending upon the expansion
1708	rules.
1709
1710	3.9.1. Alias
1711
1712	To expand an alias, the recipient mailer simply replaces the pseudo-
1713	mailbox address in the envelope with each of the expanded addresses
1714	in turn; the rest of the envelope and the message body are left
1715	unchanged. The message is then delivered or forwarded to each
1716	expanded address.
1717
1718	3.9.2. List
1719
1720	A mailing list may be said to operate by "redistribution" rather than
1721	by "forwarding". To expand a list, the recipient mailer replaces the
1722	pseudo-mailbox address in the envelope with each of the expanded
1723	addresses in turn. The return (backward-pointing) address in the
1724	envelope is changed so that all error messages generated by the final
1725	deliveries will be returned to a list administrator, not to the
1726	message originator, who generally has no control over the contents of
1727	the list and will typically find error messages annoying. Note that
1728	the key difference between handling aliases (Section 3.9.1) and
1729	forwarding (this subsection) is the change to the backward-pointing
1730	address in this case. When a list constrains its processing to the
1731	very limited set of modifications and actions described here, it is
1732	attempting to emulate an MTA; such lists can be treated as a
1733	continuation in email transit.
1734
1735
1736
1737
1738	Klensin Standards Track [Page 31]
1739
1740	RFC 5321 SMTP October 2008
1741
1742
1743	There exist mailing lists that perform additional, sometimes
1744	extensive, modifications to a message and its envelope. Such mailing
1745	lists need to be viewed as full MUAs, which accept a delivery and
1746	post a new message.
1747
1748	4. The SMTP Specifications
1749
1750	4.1. SMTP Commands
1751
1752	4.1.1. Command Semantics and Syntax
1753
1754	The SMTP commands define the mail transfer or the mail system
1755	function requested by the user. SMTP commands are character strings
1756	terminated by <CRLF>. The commands themselves are alphabetic
1757	characters terminated by <SP> if parameters follow and <CRLF>
1758	otherwise. (In the interest of improved interoperability, SMTP
1759	receivers SHOULD tolerate trailing white space before the terminating
1760	<CRLF>.) The syntax of the local part of a mailbox MUST conform to
1761	receiver site conventions and the syntax specified in Section 4.1.2.
1762	The SMTP commands are discussed below. The SMTP replies are
1763	discussed in Section 4.2.
1764
1765	A mail transaction involves several data objects that are
1766	communicated as arguments to different commands. The reverse-path is
1767	the argument of the MAIL command, the forward-path is the argument of
1768	the RCPT command, and the mail data is the argument of the DATA
1769	command. These arguments or data objects must be transmitted and
1770	held, pending the confirmation communicated by the end of mail data
1771	indication that finalizes the transaction. The model for this is
1772	that distinct buffers are provided to hold the types of data objects;
1773	that is, there is a reverse-path buffer, a forward-path buffer, and a
1774	mail data buffer. Specific commands cause information to be appended
1775	to a specific buffer, or cause one or more buffers to be cleared.
1776
1777	Several commands (RSET, DATA, QUIT) are specified as not permitting
1778	parameters. In the absence of specific extensions offered by the
1779	server and accepted by the client, clients MUST NOT send such
1780	parameters and servers SHOULD reject commands containing them as
1781	having invalid syntax.
1782
1783	4.1.1.1. Extended HELLO (EHLO) or HELLO (HELO)
1784
1785	These commands are used to identify the SMTP client to the SMTP
1786	server. The argument clause contains the fully-qualified domain name
1787	of the SMTP client, if one is available. In situations in which the
1788	SMTP client system does not have a meaningful domain name (e.g., when
1789	its address is dynamically allocated and no reverse mapping record is
1790
1791
1792
1793
1794	Klensin Standards Track [Page 32]
1795
1796	RFC 5321 SMTP October 2008
1797
1798
1799	available), the client SHOULD send an address literal (see
1800	Section 4.1.3).
1801
1802	RFC 2821, and some earlier informal practices, encouraged following
1803	the literal by information that would help to identify the client
1804	system. That convention was not widely supported, and many SMTP
1805	servers considered it an error. In the interest of interoperability,
1806	it is probably wise for servers to be prepared for this string to
1807	occur, but SMTP clients SHOULD NOT send it.
1808
1809	The SMTP server identifies itself to the SMTP client in the
1810	connection greeting reply and in the response to this command.
1811
1812	A client SMTP SHOULD start an SMTP session by issuing the EHLO
1813	command. If the SMTP server supports the SMTP service extensions, it
1814	will give a successful response, a failure response, or an error
1815	response. If the SMTP server, in violation of this specification,
1816	does not support any SMTP service extensions, it will generate an
1817	error response. Older client SMTP systems MAY, as discussed above,
1818	use HELO (as specified in RFC 821) instead of EHLO, and servers MUST
1819	support the HELO command and reply properly to it. In any event, a
1820	client MUST issue HELO or EHLO before starting a mail transaction.
1821
1822	These commands, and a "250 OK" reply to one of them, confirm that
1823	both the SMTP client and the SMTP server are in the initial state,
1824	that is, there is no transaction in progress and all state tables and
1825	buffers are cleared.
1826
1827	Syntax:
1828
1829	ehlo = "EHLO" SP ( Domain / address-literal ) CRLF
1830
1831	helo = "HELO" SP Domain CRLF
1832
1833	Normally, the response to EHLO will be a multiline reply. Each line
1834	of the response contains a keyword and, optionally, one or more
1835	parameters. Following the normal syntax for multiline replies, these
1836	keywords follow the code (250) and a hyphen for all but the last
1837	line, and the code and a space for the last line. The syntax for a
1838	positive response, using the ABNF notation and terminal symbols of
1839	RFC 5234 [7], is:
1840
1841	ehlo-ok-rsp = ( "250" SP Domain [ SP ehlo-greet ] CRLF )
1842	/ ( "250-" Domain [ SP ehlo-greet ] CRLF
1843	*( "250-" ehlo-line CRLF )
1844	"250" SP ehlo-line CRLF )
1845
1846
1847
1848
1849
1850	Klensin Standards Track [Page 33]
1851
1852	RFC 5321 SMTP October 2008
1853
1854
1855	ehlo-greet = 1*(%d0-9 / %d11-12 / %d14-127)
1856	; string of any characters other than CR or LF
1857
1858	ehlo-line = ehlo-keyword *( SP ehlo-param )
1859
1860	ehlo-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
1861	; additional syntax of ehlo-params depends on
1862	; ehlo-keyword
1863
1864	ehlo-param = 1*(%d33-126)
1865	; any CHAR excluding <SP> and all
1866	; control characters (US-ASCII 0-31 and 127
1867	; inclusive)
1868
1869	Although EHLO keywords may be specified in upper, lower, or mixed
1870	case, they MUST always be recognized and processed in a case-
1871	insensitive manner. This is simply an extension of practices
1872	specified in RFC 821 and Section 2.4.
1873
1874	The EHLO response MUST contain keywords (and associated parameters if
1875	required) for all commands not listed as "required" in Section 4.5.1
1876	excepting only private-use commands as described in Section 4.1.5.
1877	Private-use commands MAY be listed.
1878
1879	4.1.1.2. MAIL (MAIL)
1880
1881	This command is used to initiate a mail transaction in which the mail
1882	data is delivered to an SMTP server that may, in turn, deliver it to
1883	one or more mailboxes or pass it on to another system (possibly using
1884	SMTP). The argument clause contains a reverse-path and may contain
1885	optional parameters. In general, the MAIL command may be sent only
1886	when no mail transaction is in progress, see Section 4.1.4.
1887
1888	The reverse-path consists of the sender mailbox. Historically, that
1889	mailbox might optionally have been preceded by a list of hosts, but
1890	that behavior is now deprecated (see Appendix C). In some types of
1891	reporting messages for which a reply is likely to cause a mail loop
1892	(for example, mail delivery and non-delivery notifications), the
1893	reverse-path may be null (see Section 3.6).
1894
1895	This command clears the reverse-path buffer, the forward-path buffer,
1896	and the mail data buffer, and it inserts the reverse-path information
1897	from its argument clause into the reverse-path buffer.
1898
1899	If service extensions were negotiated, the MAIL command may also
1900	carry parameters associated with a particular service extension.
1901
1902
1903
1904
1905
1906	Klensin Standards Track [Page 34]
1907
1908	RFC 5321 SMTP October 2008
1909
1910
1911	Syntax:
1912
1913	mail = "MAIL FROM:" Reverse-path
1914	[SP Mail-parameters] CRLF
1915
1916	4.1.1.3. RECIPIENT (RCPT)
1917
1918	This command is used to identify an individual recipient of the mail
1919	data; multiple recipients are specified by multiple uses of this
1920	command. The argument clause contains a forward-path and may contain
1921	optional parameters.
1922
1923	The forward-path normally consists of the required destination
1924	mailbox. Sending systems SHOULD NOT generate the optional list of
1925	hosts known as a source route. Receiving systems MUST recognize
1926	source route syntax but SHOULD strip off the source route
1927	specification and utilize the domain name associated with the mailbox
1928	as if the source route had not been provided.
1929
1930	Similarly, relay hosts SHOULD strip or ignore source routes, and
1931	names MUST NOT be copied into the reverse-path. When mail reaches
1932	its ultimate destination (the forward-path contains only a
1933	destination mailbox), the SMTP server inserts it into the destination
1934	mailbox in accordance with its host mail conventions.
1935
1936	This command appends its forward-path argument to the forward-path
1937	buffer; it does not change the reverse-path buffer nor the mail data
1938	buffer.
1939
1940	For example, mail received at relay host xyz.com with envelope
1941	commands
1942
1943	MAIL FROM:<userx@y.foo.org>
1944	RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org>
1945
1946	will normally be sent directly on to host d.bar.org with envelope
1947	commands
1948
1949	MAIL FROM:<userx@y.foo.org>
1950	RCPT TO:<userc@d.bar.org>
1951
1952	As provided in Appendix C, xyz.com MAY also choose to relay the
1953	message to hosta.int, using the envelope commands
1954
1955	MAIL FROM:<userx@y.foo.org>
1956	RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org>
1957
1958
1959
1960
1961
1962	Klensin Standards Track [Page 35]
1963
1964	RFC 5321 SMTP October 2008
1965
1966
1967	or to jkl.org, using the envelope commands
1968
1969	MAIL FROM:<userx@y.foo.org>
1970	RCPT TO:<@jkl.org:userc@d.bar.org>
1971
1972	Attempting to use relaying this way is now strongly discouraged.
1973	Since hosts are not required to relay mail at all, xyz.com MAY also
1974	reject the message entirely when the RCPT command is received, using
1975	a 550 code (since this is a "policy reason").
1976
1977	If service extensions were negotiated, the RCPT command may also
1978	carry parameters associated with a particular service extension
1979	offered by the server. The client MUST NOT transmit parameters other
1980	than those associated with a service extension offered by the server
1981	in its EHLO response.
1982
1983	Syntax:
1984
1985	rcpt = "RCPT TO:" ( "<Postmaster@" Domain ">" / "<Postmaster>" /
1986	Forward-path ) [SP Rcpt-parameters] CRLF
1987
1988	Note that, in a departure from the usual rules for
1989	local-parts, the "Postmaster" string shown above is
1990	treated as case-insensitive.
1991
1992	4.1.1.4. DATA (DATA)
1993
1994	The receiver normally sends a 354 response to DATA, and then treats
1995	the lines (strings ending in <CRLF> sequences, as described in
1996	Section 2.3.7) following the command as mail data from the sender.
1997	This command causes the mail data to be appended to the mail data
1998	buffer. The mail data may contain any of the 128 ASCII character
1999	codes, although experience has indicated that use of control
2000	characters other than SP, HT, CR, and LF may cause problems and
2001	SHOULD be avoided when possible.
2002
2003	The mail data are terminated by a line containing only a period, that
2004	is, the character sequence "<CRLF>.<CRLF>", where the first <CRLF> is
2005	actually the terminator of the previous line (see Section 4.5.2).
2006	This is the end of mail data indication. The first <CRLF> of this
2007	terminating sequence is also the <CRLF> that ends the final line of
2008	the data (message text) or, if there was no mail data, ends the DATA
2009	command itself (the "no mail data" case does not conform to this
2010	specification since it would require that neither the trace header
2011	fields required by this specification nor the message header section
2012	required by RFC 5322 [4] be transmitted). An extra <CRLF> MUST NOT
2013	be added, as that would cause an empty line to be added to the
2014	message. The only exception to this rule would arise if the message
2015
2016
2017
2018	Klensin Standards Track [Page 36]
2019
2020	RFC 5321 SMTP October 2008
2021
2022
2023	body were passed to the originating SMTP-sender with a final "line"
2024	that did not end in <CRLF>; in that case, the originating SMTP system
2025	MUST either reject the message as invalid or add <CRLF> in order to
2026	have the receiving SMTP server recognize the "end of data" condition.
2027
2028	The custom of accepting lines ending only in <LF>, as a concession to
2029	non-conforming behavior on the part of some UNIX systems, has proven
2030	to cause more interoperability problems than it solves, and SMTP
2031	server systems MUST NOT do this, even in the name of improved
2032	robustness. In particular, the sequence "<LF>.<LF>" (bare line
2033	feeds, without carriage returns) MUST NOT be treated as equivalent to
2034	<CRLF>.<CRLF> as the end of mail data indication.
2035
2036	Receipt of the end of mail data indication requires the server to
2037	process the stored mail transaction information. This processing
2038	consumes the information in the reverse-path buffer, the forward-path
2039	buffer, and the mail data buffer, and on the completion of this
2040	command these buffers are cleared. If the processing is successful,
2041	the receiver MUST send an OK reply. If the processing fails, the
2042	receiver MUST send a failure reply. The SMTP model does not allow
2043	for partial failures at this point: either the message is accepted by
2044	the server for delivery and a positive response is returned or it is
2045	not accepted and a failure reply is returned. In sending a positive
2046	"250 OK" completion reply to the end of data indication, the receiver
2047	takes full responsibility for the message (see Section 6.1). Errors
2048	that are diagnosed subsequently MUST be reported in a mail message,
2049	as discussed in Section 4.4.
2050
2051	When the SMTP server accepts a message either for relaying or for
2052	final delivery, it inserts a trace record (also referred to
2053	interchangeably as a "time stamp line" or "Received" line) at the top
2054	of the mail data. This trace record indicates the identity of the
2055	host that sent the message, the identity of the host that received
2056	the message (and is inserting this time stamp), and the date and time
2057	the message was received. Relayed messages will have multiple time
2058	stamp lines. Details for formation of these lines, including their
2059	syntax, is specified in Section 4.4.
2060
2061	Additional discussion about the operation of the DATA command appears
2062	in Section 3.3.
2063
2064	Syntax:
2065
2066	data = "DATA" CRLF
2067
2068
2069
2070
2071
2072
2073
2074	Klensin Standards Track [Page 37]
2075
2076	RFC 5321 SMTP October 2008
2077
2078
2079	4.1.1.5. RESET (RSET)
2080
2081	This command specifies that the current mail transaction will be
2082	aborted. Any stored sender, recipients, and mail data MUST be
2083	discarded, and all buffers and state tables cleared. The receiver
2084	MUST send a "250 OK" reply to a RSET command with no arguments. A
2085	reset command may be issued by the client at any time. It is
2086	effectively equivalent to a NOOP (i.e., it has no effect) if issued
2087	immediately after EHLO, before EHLO is issued in the session, after
2088	an end of data indicator has been sent and acknowledged, or
2089	immediately before a QUIT. An SMTP server MUST NOT close the
2090	connection as the result of receiving a RSET; that action is reserved
2091	for QUIT (see Section 4.1.1.10).
2092
2093	Since EHLO implies some additional processing and response by the
2094	server, RSET will normally be more efficient than reissuing that
2095	command, even though the formal semantics are the same.
2096
2097	There are circumstances, contrary to the intent of this
2098	specification, in which an SMTP server may receive an indication that
2099	the underlying TCP connection has been closed or reset. To preserve
2100	the robustness of the mail system, SMTP servers SHOULD be prepared
2101	for this condition and SHOULD treat it as if a QUIT had been received
2102	before the connection disappeared.
2103
2104	Syntax:
2105
2106	rset = "RSET" CRLF
2107
2108	4.1.1.6. VERIFY (VRFY)
2109
2110	This command asks the receiver to confirm that the argument
2111	identifies a user or mailbox. If it is a user name, information is
2112	returned as specified in Section 3.5.
2113
2114	This command has no effect on the reverse-path buffer, the forward-
2115	path buffer, or the mail data buffer.
2116
2117	Syntax:
2118
2119	vrfy = "VRFY" SP String CRLF
2120
2121
2122
2123
2124
2125
2126
2127
2128
2129
2130	Klensin Standards Track [Page 38]
2131
2132	RFC 5321 SMTP October 2008
2133
2134
2135	4.1.1.7. EXPAND (EXPN)
2136
2137	This command asks the receiver to confirm that the argument
2138	identifies a mailing list, and if so, to return the membership of
2139	that list. If the command is successful, a reply is returned
2140	containing information as described in Section 3.5. This reply will
2141	have multiple lines except in the trivial case of a one-member list.
2142
2143	This command has no effect on the reverse-path buffer, the forward-
2144	path buffer, or the mail data buffer, and it may be issued at any
2145	time.
2146
2147	Syntax:
2148
2149	expn = "EXPN" SP String CRLF
2150
2151	4.1.1.8. HELP (HELP)
2152
2153	This command causes the server to send helpful information to the
2154	client. The command MAY take an argument (e.g., any command name)
2155	and return more specific information as a response.
2156
2157	This command has no effect on the reverse-path buffer, the forward-
2158	path buffer, or the mail data buffer, and it may be issued at any
2159	time.
2160
2161	SMTP servers SHOULD support HELP without arguments and MAY support it
2162	with arguments.
2163
2164	Syntax:
2165
2166	help = "HELP" [ SP String ] CRLF
2167
2168
2169
2170
2171
2172
2173
2174
2175
2176
2177
2178
2179
2180
2181
2182
2183
2184
2185
2186	Klensin Standards Track [Page 39]
2187
2188	RFC 5321 SMTP October 2008
2189
2190
2191	4.1.1.9. NOOP (NOOP)
2192
2193	This command does not affect any parameters or previously entered
2194	commands. It specifies no action other than that the receiver send a
2195	"250 OK" reply.
2196
2197	This command has no effect on the reverse-path buffer, the forward-
2198	path buffer, or the mail data buffer, and it may be issued at any
2199	time. If a parameter string is specified, servers SHOULD ignore it.
2200
2201	Syntax:
2202
2203	noop = "NOOP" [ SP String ] CRLF
2204
2205	4.1.1.10. QUIT (QUIT)
2206
2207	This command specifies that the receiver MUST send a "221 OK" reply,
2208	and then close the transmission channel.
2209
2210	The receiver MUST NOT intentionally close the transmission channel
2211	until it receives and replies to a QUIT command (even if there was an
2212	error). The sender MUST NOT intentionally close the transmission
2213	channel until it sends a QUIT command, and it SHOULD wait until it
2214	receives the reply (even if there was an error response to a previous
2215	command). If the connection is closed prematurely due to violations
2216	of the above or system or network failure, the server MUST cancel any
2217	pending transaction, but not undo any previously completed
2218	transaction, and generally MUST act as if the command or transaction
2219	in progress had received a temporary error (i.e., a 4yz response).
2220
2221	The QUIT command may be issued at any time. Any current uncompleted
2222	mail transaction will be aborted.
2223
2224	Syntax:
2225
2226	quit = "QUIT" CRLF
2227
2228	4.1.1.11. Mail-Parameter and Rcpt-Parameter Error Responses
2229
2230	If the server SMTP does not recognize or cannot implement one or more
2231	of the parameters associated with a particular MAIL FROM or RCPT TO
2232	command, it will return code 555.
2233
2234	If, for some reason, the server is temporarily unable to accommodate
2235	one or more of the parameters associated with a MAIL FROM or RCPT TO
2236	command, and if the definition of the specific parameter does not
2237	mandate the use of another code, it should return code 455.
2238
2239
2240
2241
2242	Klensin Standards Track [Page 40]
2243
2244	RFC 5321 SMTP October 2008
2245
2246
2247	Errors specific to particular parameters and their values will be
2248	specified in the parameter's defining RFC.
2249
2250	4.1.2. Command Argument Syntax
2251
2252	The syntax of the argument clauses of the above commands (using the
2253	syntax specified in RFC 5234 [7] where applicable) is given below.
2254	Some of the productions given below are used only in conjunction with
2255	source routes as described in Appendix C. Terminals not defined in
2256	this document, such as ALPHA, DIGIT, SP, CR, LF, CRLF, are as defined
2257	in the "core" syntax in Section 6 of RFC 5234 [7] or in the message
2258	format syntax in RFC 5322 [4].
2259
2260	Reverse-path = Path / "<>"
2261
2262	Forward-path = Path
2263
2264	Path = "<" [ A-d-l ":" ] Mailbox ">"
2265
2266	A-d-l = At-domain *( "," At-domain )
2267	; Note that this form, the so-called "source
2268	; route", MUST BE accepted, SHOULD NOT be
2269	; generated, and SHOULD be ignored.
2270
2271	At-domain = "@" Domain
2272
2273	Mail-parameters = esmtp-param *(SP esmtp-param)
2274
2275	Rcpt-parameters = esmtp-param *(SP esmtp-param)
2276
2277	esmtp-param = esmtp-keyword ["=" esmtp-value]
2278
2279	esmtp-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
2280
2281	esmtp-value = 1*(%d33-60 / %d62-126)
2282	; any CHAR excluding "=", SP, and control
2283	; characters. If this string is an email address,
2284	; i.e., a Mailbox, then the "xtext" syntax [32]
2285	; SHOULD be used.
2286
2287	Keyword = Ldh-str
2288
2289	Argument = Atom
2290
2291	Domain = sub-domain *("." sub-domain)
2292
2293
2294
2295
2296
2297
2298	Klensin Standards Track [Page 41]
2299
2300	RFC 5321 SMTP October 2008
2301
2302
2303	sub-domain = Let-dig [Ldh-str]
2304
2305	Let-dig = ALPHA / DIGIT
2306
2307	Ldh-str = *( ALPHA / DIGIT / "-" ) Let-dig
2308
2309	address-literal = "[" ( IPv4-address-literal /
2310	IPv6-address-literal /
2311	General-address-literal ) "]"
2312	; See Section 4.1.3
2313
2314	Mailbox = Local-part "@" ( Domain / address-literal )
2315
2316	Local-part = Dot-string / Quoted-string
2317	; MAY be case-sensitive
2318
2319
2320	Dot-string = Atom *("." Atom)
2321
2322	Atom = 1*atext
2323
2324	Quoted-string = DQUOTE *QcontentSMTP DQUOTE
2325
2326	QcontentSMTP = qtextSMTP / quoted-pairSMTP
2327
2328	quoted-pairSMTP = %d92 %d32-126
2329	; i.e., backslash followed by any ASCII
2330	; graphic (including itself) or SPace
2331
2332	qtextSMTP = %d32-33 / %d35-91 / %d93-126
2333	; i.e., within a quoted string, any
2334	; ASCII graphic or space is permitted
2335	; without blackslash-quoting except
2336	; double-quote and the backslash itself.
2337
2338	String = Atom / Quoted-string
2339
2340	While the above definition for Local-part is relatively permissive,
2341	for maximum interoperability, a host that expects to receive mail
2342	SHOULD avoid defining mailboxes where the Local-part requires (or
2343	uses) the Quoted-string form or where the Local-part is case-
2344	sensitive. For any purposes that require generating or comparing
2345	Local-parts (e.g., to specific mailbox names), all quoted forms MUST
2346	be treated as equivalent, and the sending system SHOULD transmit the
2347	form that uses the minimum quoting possible.
2348
2349	Systems MUST NOT define mailboxes in such a way as to require the use
2350	in SMTP of non-ASCII characters (octets with the high order bit set
2351
2352
2353
2354	Klensin Standards Track [Page 42]
2355
2356	RFC 5321 SMTP October 2008
2357
2358
2359	to one) or ASCII "control characters" (decimal value 0-31 and 127).
2360	These characters MUST NOT be used in MAIL or RCPT commands or other
2361	commands that require mailbox names.
2362
2363	Note that the backslash, "\", is a quote character, which is used to
2364	indicate that the next character is to be used literally (instead of
2365	its normal interpretation). For example, "Joe\,Smith" indicates a
2366	single nine-character user name string with the comma being the
2367	fourth character of that string.
2368
2369	To promote interoperability and consistent with long-standing
2370	guidance about conservative use of the DNS in naming and applications
2371	(e.g., see Section 2.3.1 of the base DNS document, RFC 1035 [2]),
2372	characters outside the set of alphabetic characters, digits, and
2373	hyphen MUST NOT appear in domain name labels for SMTP clients or
2374	servers. In particular, the underscore character is not permitted.
2375	SMTP servers that receive a command in which invalid character codes
2376	have been employed, and for which there are no other reasons for
2377	rejection, MUST reject that command with a 501 response (this rule,
2378	like others, could be overridden by appropriate SMTP extensions).
2379
2380	4.1.3. Address Literals
2381
2382	Sometimes a host is not known to the domain name system and
2383	communication (and, in particular, communication to report and repair
2384	the error) is blocked. To bypass this barrier, a special literal
2385	form of the address is allowed as an alternative to a domain name.
2386	For IPv4 addresses, this form uses four small decimal integers
2387	separated by dots and enclosed by brackets such as [123.255.37.2],
2388	which indicates an (IPv4) Internet Address in sequence-of-octets
2389	form. For IPv6 and other forms of addressing that might eventually
2390	be standardized, the form consists of a standardized "tag" that
2391	identifies the address syntax, a colon, and the address itself, in a
2392	format specified as part of the relevant standards (i.e., RFC 4291
2393	[8] for IPv6).
2394
2395	Specifically:
2396
2397	IPv4-address-literal = Snum 3("." Snum)
2398
2399	IPv6-address-literal = "IPv6:" IPv6-addr
2400
2401	General-address-literal = Standardized-tag ":" 1*dcontent
2402
2403	Standardized-tag = Ldh-str
2404	; Standardized-tag MUST be specified in a
2405	; Standards-Track RFC and registered with IANA
2406
2407
2408
2409
2410	Klensin Standards Track [Page 43]
2411
2412	RFC 5321 SMTP October 2008
2413
2414
2415	dcontent = %d33-90 / ; Printable US-ASCII
2416	%d94-126 ; excl. "[", "\", "]"
2417
2418	Snum = 1*3DIGIT
2419	; representing a decimal integer
2420	; value in the range 0 through 255
2421
2422	IPv6-addr = IPv6-full / IPv6-comp / IPv6v4-full / IPv6v4-comp
2423
2424	IPv6-hex = 1*4HEXDIG
2425
2426	IPv6-full = IPv6-hex 7(":" IPv6-hex)
2427
2428	IPv6-comp = [IPv6-hex *5(":" IPv6-hex)] "::"
2429	[IPv6-hex *5(":" IPv6-hex)]
2430	; The "::" represents at least 2 16-bit groups of
2431	; zeros. No more than 6 groups in addition to the
2432	; "::" may be present.
2433
2434	IPv6v4-full = IPv6-hex 5(":" IPv6-hex) ":" IPv4-address-literal
2435
2436	IPv6v4-comp = [IPv6-hex *3(":" IPv6-hex)] "::"
2437	[IPv6-hex *3(":" IPv6-hex) ":"]
2438	IPv4-address-literal
2439	; The "::" represents at least 2 16-bit groups of
2440	; zeros. No more than 4 groups in addition to the
2441	; "::" and IPv4-address-literal may be present.
2442
2443	4.1.4. Order of Commands
2444
2445	There are restrictions on the order in which these commands may be
2446	used.
2447
2448	A session that will contain mail transactions MUST first be
2449	initialized by the use of the EHLO command. An SMTP server SHOULD
2450	accept commands for non-mail transactions (e.g., VRFY or EXPN)
2451	without this initialization.
2452
2453	An EHLO command MAY be issued by a client later in the session. If
2454	it is issued after the session begins and the EHLO command is
2455	acceptable to the SMTP server, the SMTP server MUST clear all buffers
2456	and reset the state exactly as if a RSET command had been issued. In
2457	other words, the sequence of RSET followed immediately by EHLO is
2458	redundant, but not harmful other than in the performance cost of
2459	executing unnecessary commands.
2460
2461	If the EHLO command is not acceptable to the SMTP server, 501, 500,
2462	502, or 550 failure replies MUST be returned as appropriate. The
2463
2464
2465
2466	Klensin Standards Track [Page 44]
2467
2468	RFC 5321 SMTP October 2008
2469
2470
2471	SMTP server MUST stay in the same state after transmitting these
2472	replies that it was in before the EHLO was received.
2473
2474	The SMTP client MUST, if possible, ensure that the domain parameter
2475	to the EHLO command is a primary host name as specified for this
2476	command in Section 2.3.5. If this is not possible (e.g., when the
2477	client's address is dynamically assigned and the client does not have
2478	an obvious name), an address literal SHOULD be substituted for the
2479	domain name.
2480
2481	An SMTP server MAY verify that the domain name argument in the EHLO
2482	command actually corresponds to the IP address of the client.
2483	However, if the verification fails, the server MUST NOT refuse to
2484	accept a message on that basis. Information captured in the
2485	verification attempt is for logging and tracing purposes. Note that
2486	this prohibition applies to the matching of the parameter to its IP
2487	address only; see Section 7.9 for a more extensive discussion of
2488	rejecting incoming connections or mail messages.
2489
2490	The NOOP, HELP, EXPN, VRFY, and RSET commands can be used at any time
2491	during a session, or without previously initializing a session. SMTP
2492	servers SHOULD process these normally (that is, not return a 503
2493	code) even if no EHLO command has yet been received; clients SHOULD
2494	open a session with EHLO before sending these commands.
2495
2496	If these rules are followed, the example in RFC 821 that shows "550
2497	access denied to you" in response to an EXPN command is incorrect
2498	unless an EHLO command precedes the EXPN or the denial of access is
2499	based on the client's IP address or other authentication or
2500	authorization-determining mechanisms.
2501
2502	The MAIL command (or the obsolete SEND, SOML, or SAML commands)
2503	begins a mail transaction. Once started, a mail transaction consists
2504	of a transaction beginning command, one or more RCPT commands, and a
2505	DATA command, in that order. A mail transaction may be aborted by
2506	the RSET, a new EHLO, or the QUIT command. There may be zero or more
2507	transactions in a session. MAIL (or SEND, SOML, or SAML) MUST NOT be
2508	sent if a mail transaction is already open, i.e., it should be sent
2509	only if no mail transaction had been started in the session, or if
2510	the previous one successfully concluded with a successful DATA
2511	command, or if the previous one was aborted, e.g., with a RSET or new
2512	EHLO.
2513
2514	If the transaction beginning command argument is not acceptable, a
2515	501 failure reply MUST be returned and the SMTP server MUST stay in
2516	the same state. If the commands in a transaction are out of order to
2517	the degree that they cannot be processed by the server, a 503 failure
2518
2519
2520
2521
2522	Klensin Standards Track [Page 45]
2523
2524	RFC 5321 SMTP October 2008
2525
2526
2527	reply MUST be returned and the SMTP server MUST stay in the same
2528	state.
2529
2530	The last command in a session MUST be the QUIT command. The QUIT
2531	command SHOULD be used by the client SMTP to request connection
2532	closure, even when no session opening command was sent and accepted.
2533
2534	4.1.5. Private-Use Commands
2535
2536	As specified in Section 2.2.2, commands starting in "X" may be used
2537	by bilateral agreement between the client (sending) and server
2538	(receiving) SMTP agents. An SMTP server that does not recognize such
2539	a command is expected to reply with "500 Command not recognized". An
2540	extended SMTP server MAY list the feature names associated with these
2541	private commands in the response to the EHLO command.
2542
2543	Commands sent or accepted by SMTP systems that do not start with "X"
2544	MUST conform to the requirements of Section 2.2.2.
2545
2546	4.2. SMTP Replies
2547
2548	Replies to SMTP commands serve to ensure the synchronization of
2549	requests and actions in the process of mail transfer and to guarantee
2550	that the SMTP client always knows the state of the SMTP server.
2551	Every command MUST generate exactly one reply.
2552
2553	The details of the command-reply sequence are described in
2554	Section 4.3.
2555
2556	An SMTP reply consists of a three digit number (transmitted as three
2557	numeric characters) followed by some text unless specified otherwise
2558	in this document. The number is for use by automata to determine
2559	what state to enter next; the text is for the human user. The three
2560	digits contain enough encoded information that the SMTP client need
2561	not examine the text and may either discard it or pass it on to the
2562	user, as appropriate. Exceptions are as noted elsewhere in this
2563	document. In particular, the 220, 221, 251, 421, and 551 reply codes
2564	are associated with message text that must be parsed and interpreted
2565	by machines. In the general case, the text may be receiver dependent
2566	and context dependent, so there are likely to be varying texts for
2567	each reply code. A discussion of the theory of reply codes is given
2568	in Section 4.2.1. Formally, a reply is defined to be the sequence: a
2569	three-digit code, <SP>, one line of text, and <CRLF>, or a multiline
2570	reply (as defined in the same section). Since, in violation of this
2571	specification, the text is sometimes not sent, clients that do not
2572	receive it SHOULD be prepared to process the code alone (with or
2573	without a trailing space character). Only the EHLO, EXPN, and HELP
2574	commands are expected to result in multiline replies in normal
2575
2576
2577
2578	Klensin Standards Track [Page 46]
2579
2580	RFC 5321 SMTP October 2008
2581
2582
2583	circumstances; however, multiline replies are allowed for any
2584	command.
2585
2586	In ABNF, server responses are:
2587
2588	Greeting = ( "220 " (Domain / address-literal)
2589	[ SP textstring ] CRLF ) /
2590	( "220-" (Domain / address-literal)
2591	[ SP textstring ] CRLF
2592	*( "220-" [ textstring ] CRLF )
2593	"220" [ SP textstring ] CRLF )
2594
2595	textstring = 1*(%d09 / %d32-126) ; HT, SP, Printable US-ASCII
2596
2597	Reply-line = *( Reply-code "-" [ textstring ] CRLF )
2598	Reply-code [ SP textstring ] CRLF
2599
2600	Reply-code = %x32-35 %x30-35 %x30-39
2601
2602	where "Greeting" appears only in the 220 response that announces that
2603	the server is opening its part of the connection. (Other possible
2604	server responses upon connection follow the syntax of Reply-line.)
2605
2606	An SMTP server SHOULD send only the reply codes listed in this
2607	document. An SMTP server SHOULD use the text shown in the examples
2608	whenever appropriate.
2609
2610	An SMTP client MUST determine its actions only by the reply code, not
2611	by the text (except for the "change of address" 251 and 551 and, if
2612	necessary, 220, 221, and 421 replies); in the general case, any text,
2613	including no text at all (although senders SHOULD NOT send bare
2614	codes), MUST be acceptable. The space (blank) following the reply
2615	code is considered part of the text. Whenever possible, a receiver-
2616	SMTP SHOULD test the first digit (severity indication) of the reply
2617	code.
2618
2619	The list of codes that appears below MUST NOT be construed as
2620	permanent. While the addition of new codes should be a rare and
2621	significant activity, with supplemental information in the textual
2622	part of the response being preferred, new codes may be added as the
2623	result of new Standards or Standards-Track specifications.
2624	Consequently, a sender-SMTP MUST be prepared to handle codes not
2625	specified in this document and MUST do so by interpreting the first
2626	digit only.
2627
2628	In the absence of extensions negotiated with the client, SMTP servers
2629	MUST NOT send reply codes whose first digits are other than 2, 3, 4,
2630
2631
2632
2633
2634	Klensin Standards Track [Page 47]
2635
2636	RFC 5321 SMTP October 2008
2637
2638
2639	or 5. Clients that receive such out-of-range codes SHOULD normally
2640	treat them as fatal errors and terminate the mail transaction.
2641
2642	4.2.1. Reply Code Severities and Theory
2643
2644	The three digits of the reply each have a special significance. The
2645	first digit denotes whether the response is good, bad, or incomplete.
2646	An unsophisticated SMTP client, or one that receives an unexpected
2647	code, will be able to determine its next action (proceed as planned,
2648	redo, retrench, etc.) by examining this first digit. An SMTP client
2649	that wants to know approximately what kind of error occurred (e.g.,
2650	mail system error, command syntax error) may examine the second
2651	digit. The third digit and any supplemental information that may be
2652	present is reserved for the finest gradation of information.
2653
2654	There are four values for the first digit of the reply code:
2655
2656	2yz Positive Completion reply
2657	The requested action has been successfully completed. A new
2658	request may be initiated.
2659
2660	3yz Positive Intermediate reply
2661	The command has been accepted, but the requested action is being
2662	held in abeyance, pending receipt of further information. The
2663	SMTP client should send another command specifying this
2664	information. This reply is used in command sequence groups (i.e.,
2665	in DATA).
2666
2667	4yz Transient Negative Completion reply
2668	The command was not accepted, and the requested action did not
2669	occur. However, the error condition is temporary, and the action
2670	may be requested again. The sender should return to the beginning
2671	of the command sequence (if any). It is difficult to assign a
2672	meaning to "transient" when two different sites (receiver- and
2673	sender-SMTP agents) must agree on the interpretation. Each reply
2674	in this category might have a different time value, but the SMTP
2675	client SHOULD try again. A rule of thumb to determine whether a
2676	reply fits into the 4yz or the 5yz category (see below) is that
2677	replies are 4yz if they can be successful if repeated without any
2678	change in command form or in properties of the sender or receiver
2679	(that is, the command is repeated identically and the receiver
2680	does not put up a new implementation).
2681
2682	5yz Permanent Negative Completion reply
2683	The command was not accepted and the requested action did not
2684	occur. The SMTP client SHOULD NOT repeat the exact request (in
2685	the same sequence). Even some "permanent" error conditions can be
2686	corrected, so the human user may want to direct the SMTP client to
2687
2688
2689
2690	Klensin Standards Track [Page 48]
2691
2692	RFC 5321 SMTP October 2008
2693
2694
2695	reinitiate the command sequence by direct action at some point in
2696	the future (e.g., after the spelling has been changed, or the user
2697	has altered the account status).
2698
2699	It is worth noting that the file transfer protocol (FTP) [34] uses a
2700	very similar code architecture and that the SMTP codes are based on
2701	the FTP model. However, SMTP uses a one-command, one-response model
2702	(while FTP is asynchronous) and FTP's 1yz codes are not part of the
2703	SMTP model.
2704
2705	The second digit encodes responses in specific categories:
2706
2707	x0z Syntax: These replies refer to syntax errors, syntactically
2708	correct commands that do not fit any functional category, and
2709	unimplemented or superfluous commands.
2710
2711	x1z Information: These are replies to requests for information, such
2712	as status or help.
2713
2714	x2z Connections: These are replies referring to the transmission
2715	channel.
2716
2717	x3z Unspecified.
2718
2719	x4z Unspecified.
2720
2721	x5z Mail system: These replies indicate the status of the receiver
2722	mail system vis-a-vis the requested transfer or other mail system
2723	action.
2724
2725	The third digit gives a finer gradation of meaning in each category
2726	specified by the second digit. The list of replies illustrates this.
2727	Each reply text is recommended rather than mandatory, and may even
2728	change according to the command with which it is associated. On the
2729	other hand, the reply codes must strictly follow the specifications
2730	in this section. Receiver implementations should not invent new
2731	codes for slightly different situations from the ones described here,
2732	but rather adapt codes already defined.
2733
2734	For example, a command such as NOOP, whose successful execution does
2735	not offer the SMTP client any new information, will return a 250
2736	reply. The reply is 502 when the command requests an unimplemented
2737	non-site-specific action. A refinement of that is the 504 reply for
2738	a command that is implemented, but that requests an unimplemented
2739	parameter.
2740
2741
2742
2743
2744
2745
2746	Klensin Standards Track [Page 49]
2747
2748	RFC 5321 SMTP October 2008
2749
2750
2751	The reply text may be longer than a single line; in these cases the
2752	complete text must be marked so the SMTP client knows when it can
2753	stop reading the reply. This requires a special format to indicate a
2754	multiple line reply.
2755
2756	The format for multiline replies requires that every line, except the
2757	last, begin with the reply code, followed immediately by a hyphen,
2758	"-" (also known as minus), followed by text. The last line will
2759	begin with the reply code, followed immediately by <SP>, optionally
2760	some text, and <CRLF>. As noted above, servers SHOULD send the <SP>
2761	if subsequent text is not sent, but clients MUST be prepared for it
2762	to be omitted.
2763
2764	For example:
2765
2766	250-First line
2767	250-Second line
2768	250-234 Text beginning with numbers
2769	250 The last line
2770
2771	In a multiline reply, the reply code on each of the lines MUST be the
2772	same. It is reasonable for the client to rely on this, so it can
2773	make processing decisions based on the code in any line, assuming
2774	that all others will be the same. In a few cases, there is important
2775	data for the client in the reply "text". The client will be able to
2776	identify these cases from the current context.
2777
2778	4.2.2. Reply Codes by Function Groups
2779
2780	500 Syntax error, command unrecognized (This may include errors such
2781	as command line too long)
2782
2783	501 Syntax error in parameters or arguments
2784
2785	502 Command not implemented (see Section 4.2.4)
2786
2787	503 Bad sequence of commands
2788
2789	504 Command parameter not implemented
2790
2791
2792	211 System status, or system help reply
2793
2794	214 Help message (Information on how to use the receiver or the
2795	meaning of a particular non-standard command; this reply is useful
2796	only to the human user)
2797
2798
2799
2800
2801
2802	Klensin Standards Track [Page 50]
2803
2804	RFC 5321 SMTP October 2008
2805
2806
2807	220 <domain> Service ready
2808
2809	221 <domain> Service closing transmission channel
2810
2811	421 <domain> Service not available, closing transmission channel
2812	(This may be a reply to any command if the service knows it must
2813	shut down)
2814
2815
2816	250 Requested mail action okay, completed
2817
2818	251 User not local; will forward to <forward-path> (See Section 3.4)
2819
2820	252 Cannot VRFY user, but will accept message and attempt delivery
2821	(See Section 3.5.3)
2822
2823	455 Server unable to accommodate parameters
2824
2825	555 MAIL FROM/RCPT TO parameters not recognized or not implemented
2826
2827	450 Requested mail action not taken: mailbox unavailable (e.g.,
2828	mailbox busy or temporarily blocked for policy reasons)
2829
2830	550 Requested action not taken: mailbox unavailable (e.g., mailbox
2831	not found, no access, or command rejected for policy reasons)
2832
2833	451 Requested action aborted: error in processing
2834
2835	551 User not local; please try <forward-path> (See Section 3.4)
2836
2837	452 Requested action not taken: insufficient system storage
2838
2839	552 Requested mail action aborted: exceeded storage allocation
2840
2841	553 Requested action not taken: mailbox name not allowed (e.g.,
2842	mailbox syntax incorrect)
2843
2844	354 Start mail input; end with <CRLF>.<CRLF>
2845
2846	554 Transaction failed (Or, in the case of a connection-opening
2847	response, "No SMTP service here")
2848
2849
2850
2851
2852
2853
2854
2855
2856
2857
2858	Klensin Standards Track [Page 51]
2859
2860	RFC 5321 SMTP October 2008
2861
2862
2863	4.2.3. Reply Codes in Numeric Order
2864
2865	211 System status, or system help reply
2866
2867	214 Help message (Information on how to use the receiver or the
2868	meaning of a particular non-standard command; this reply is useful
2869	only to the human user)
2870
2871	220 <domain> Service ready
2872
2873	221 <domain> Service closing transmission channel
2874
2875	250 Requested mail action okay, completed
2876
2877	251 User not local; will forward to <forward-path> (See Section 3.4)
2878
2879	252 Cannot VRFY user, but will accept message and attempt delivery
2880	(See Section 3.5.3)
2881
2882	354 Start mail input; end with <CRLF>.<CRLF>
2883
2884	421 <domain> Service not available, closing transmission channel
2885	(This may be a reply to any command if the service knows it must
2886	shut down)
2887
2888	450 Requested mail action not taken: mailbox unavailable (e.g.,
2889	mailbox busy or temporarily blocked for policy reasons)
2890
2891	451 Requested action aborted: local error in processing
2892
2893	452 Requested action not taken: insufficient system storage
2894
2895	455 Server unable to accommodate parameters
2896
2897	500 Syntax error, command unrecognized (This may include errors such
2898	as command line too long)
2899
2900	501 Syntax error in parameters or arguments
2901
2902	502 Command not implemented (see Section 4.2.4)
2903
2904	503 Bad sequence of commands
2905
2906	504 Command parameter not implemented
2907
2908	550 Requested action not taken: mailbox unavailable (e.g., mailbox
2909	not found, no access, or command rejected for policy reasons)
2910
2911
2912
2913
2914	Klensin Standards Track [Page 52]
2915
2916	RFC 5321 SMTP October 2008
2917
2918
2919	551 User not local; please try <forward-path> (See Section 3.4)
2920
2921	552 Requested mail action aborted: exceeded storage allocation
2922
2923	553 Requested action not taken: mailbox name not allowed (e.g.,
2924	mailbox syntax incorrect)
2925
2926	554 Transaction failed (Or, in the case of a connection-opening
2927	response, "No SMTP service here")
2928
2929	555 MAIL FROM/RCPT TO parameters not recognized or not implemented
2930
2931	4.2.4. Reply Code 502
2932
2933	Questions have been raised as to when reply code 502 (Command not
2934	implemented) SHOULD be returned in preference to other codes. 502
2935	SHOULD be used when the command is actually recognized by the SMTP
2936	server, but not implemented. If the command is not recognized, code
2937	500 SHOULD be returned. Extended SMTP systems MUST NOT list
2938	capabilities in response to EHLO for which they will return 502 (or
2939	500) replies.
2940
2941	4.2.5. Reply Codes after DATA and the Subsequent <CRLF>.<CRLF>
2942
2943	When an SMTP server returns a positive completion status (2yz code)
2944	after the DATA command is completed with <CRLF>.<CRLF>, it accepts
2945	responsibility for:
2946
2947	o delivering the message (if the recipient mailbox exists), or
2948
2949	o if attempts to deliver the message fail due to transient
2950	conditions, retrying delivery some reasonable number of times at
2951	intervals as specified in Section 4.5.4.
2952
2953	o if attempts to deliver the message fail due to permanent
2954	conditions, or if repeated attempts to deliver the message fail
2955	due to transient conditions, returning appropriate notification to
2956	the sender of the original message (using the address in the SMTP
2957	MAIL command).
2958
2959	When an SMTP server returns a temporary error status (4yz) code after
2960	the DATA command is completed with <CRLF>.<CRLF>, it MUST NOT make a
2961	subsequent attempt to deliver that message. The SMTP client retains
2962	responsibility for the delivery of that message and may either return
2963	it to the user or requeue it for a subsequent attempt (see
2964	Section 4.5.4.1).
2965
2966
2967
2968
2969
2970	Klensin Standards Track [Page 53]
2971
2972	RFC 5321 SMTP October 2008
2973
2974
2975	The user who originated the message SHOULD be able to interpret the
2976	return of a transient failure status (by mail message or otherwise)
2977	as a non-delivery indication, just as a permanent failure would be
2978	interpreted. If the client SMTP successfully handles these
2979	conditions, the user will not receive such a reply.
2980
2981	When an SMTP server returns a permanent error status (5yz) code after
2982	the DATA command is completed with <CRLF>.<CRLF>, it MUST NOT make
2983	any subsequent attempt to deliver the message. As with temporary
2984	error status codes, the SMTP client retains responsibility for the
2985	message, but SHOULD not again attempt delivery to the same server
2986	without user review of the message and response and appropriate
2987	intervention.
2988
2989	4.3. Sequencing of Commands and Replies
2990
2991	4.3.1. Sequencing Overview
2992
2993	The communication between the sender and receiver is an alternating
2994	dialogue, controlled by the sender. As such, the sender issues a
2995	command and the receiver responds with a reply. Unless other
2996	arrangements are negotiated through service extensions, the sender
2997	MUST wait for this response before sending further commands. One
2998	important reply is the connection greeting. Normally, a receiver
2999	will send a 220 "Service ready" reply when the connection is
3000	completed. The sender SHOULD wait for this greeting message before
3001	sending any commands.
3002
3003	Note: all the greeting-type replies have the official name (the
3004	fully-qualified primary domain name) of the server host as the first
3005	word following the reply code. Sometimes the host will have no
3006	meaningful name. See Section 4.1.3 for a discussion of alternatives
3007	in these situations.
3008
3009	For example,
3010
3011	220 ISIF.USC.EDU Service ready
3012
3013	or
3014
3015	220 mail.example.com SuperSMTP v 6.1.2 Service ready
3016
3017	or
3018
3019	220 [10.0.0.1] Clueless host service ready
3020
3021	The table below lists alternative success and failure replies for
3022	each command. These SHOULD be strictly adhered to. A receiver MAY
3023
3024
3025
3026	Klensin Standards Track [Page 54]
3027
3028	RFC 5321 SMTP October 2008
3029
3030
3031	substitute text in the replies, but the meanings and actions implied
3032	by the code numbers and by the specific command reply sequence MUST
3033	be preserved.
3034
3035	4.3.2. Command-Reply Sequences
3036
3037	Each command is listed with its usual possible replies. The prefixes
3038	used before the possible replies are "I" for intermediate, "S" for
3039	success, and "E" for error. Since some servers may generate other
3040	replies under special circumstances, and to allow for future
3041	extension, SMTP clients SHOULD, when possible, interpret only the
3042	first digit of the reply and MUST be prepared to deal with
3043	unrecognized reply codes by interpreting the first digit only.
3044	Unless extended using the mechanisms described in Section 2.2, SMTP
3045	servers MUST NOT transmit reply codes to an SMTP client that are
3046	other than three digits or that do not start in a digit between 2 and
3047	5 inclusive.
3048
3049	These sequencing rules and, in principle, the codes themselves, can
3050	be extended or modified by SMTP extensions offered by the server and
3051	accepted (requested) by the client. However, if the target is more
3052	precise granularity in the codes, rather than codes for completely
3053	new purposes, the system described in RFC 3463 [25] SHOULD be used in
3054	preference to the invention of new codes.
3055
3056	In addition to the codes listed below, any SMTP command can return
3057	any of the following codes if the corresponding unusual circumstances
3058	are encountered:
3059
3060	500 For the "command line too long" case or if the command name was
3061	not recognized. Note that producing a "command not recognized"
3062	error in response to the required subset of these commands is a
3063	violation of this specification. Similarly, producing a "command
3064	too long" message for a command line shorter than 512 characters
3065	would violate the provisions of Section 4.5.3.1.4.
3066
3067	501 Syntax error in command or arguments. In order to provide for
3068	future extensions, commands that are specified in this document as
3069	not accepting arguments (DATA, RSET, QUIT) SHOULD return a 501
3070	message if arguments are supplied in the absence of EHLO-
3071	advertised extensions.
3072
3073	421 Service shutting down and closing transmission channel
3074
3075
3076
3077
3078
3079
3080
3081
3082	Klensin Standards Track [Page 55]
3083
3084	RFC 5321 SMTP October 2008
3085
3086
3087	Specific sequences are:
3088
3089	CONNECTION ESTABLISHMENT
3090
3091	S: 220
3092	E: 554
3093
3094	EHLO or HELO
3095
3096	S: 250
3097	E: 504 (a conforming implementation could return this code only
3098	in fairly obscure cases), 550, 502 (permitted only with an old-
3099	style server that does not support EHLO)
3100
3101	MAIL
3102
3103	S: 250
3104	E: 552, 451, 452, 550, 553, 503, 455, 555
3105
3106	RCPT
3107
3108	S: 250, 251 (but see Section 3.4 for discussion of 251 and 551)
3109	E: 550, 551, 552, 553, 450, 451, 452, 503, 455, 555
3110
3111	DATA
3112
3113	I: 354 -> data -> S: 250
3114
3115	E: 552, 554, 451, 452
3116
3117	E: 450, 550 (rejections for policy reasons)
3118
3119	E: 503, 554
3120
3121	RSET
3122
3123	S: 250
3124
3125	VRFY
3126
3127	S: 250, 251, 252
3128	E: 550, 551, 553, 502, 504
3129
3130	EXPN
3131
3132	S: 250, 252
3133	E: 550, 500, 502, 504
3134
3135
3136
3137
3138	Klensin Standards Track [Page 56]
3139
3140	RFC 5321 SMTP October 2008
3141
3142
3143	HELP
3144
3145	S: 211, 214
3146	E: 502, 504
3147
3148	NOOP
3149
3150	S: 250
3151
3152	QUIT
3153
3154	S: 221
3155
3156	4.4. Trace Information
3157
3158	When an SMTP server receives a message for delivery or further
3159	processing, it MUST insert trace ("time stamp" or "Received")
3160	information at the beginning of the message content, as discussed in
3161	Section 4.1.1.4.
3162
3163	This line MUST be structured as follows:
3164
3165	o The FROM clause, which MUST be supplied in an SMTP environment,
3166	SHOULD contain both (1) the name of the source host as presented
3167	in the EHLO command and (2) an address literal containing the IP
3168	address of the source, determined from the TCP connection.
3169
3170	o The ID clause MAY contain an "@" as suggested in RFC 822, but this
3171	is not required.
3172
3173	o If the FOR clause appears, it MUST contain exactly one <path>
3174	entry, even when multiple RCPT commands have been given. Multiple
3175	<path>s raise some security issues and have been deprecated, see
3176	Section 7.2.
3177
3178	An Internet mail program MUST NOT change or delete a Received: line
3179	that was previously added to the message header section. SMTP
3180	servers MUST prepend Received lines to messages; they MUST NOT change
3181	the order of existing lines or insert Received lines in any other
3182	location.
3183
3184	As the Internet grows, comparability of Received header fields is
3185	important for detecting problems, especially slow relays. SMTP
3186	servers that create Received header fields SHOULD use explicit
3187	offsets in the dates (e.g., -0800), rather than time zone names of
3188	any type. Local time (with an offset) SHOULD be used rather than UT
3189	when feasible. This formulation allows slightly more information
3190	about local circumstances to be specified. If UT is needed, the
3191
3192
3193
3194	Klensin Standards Track [Page 57]
3195
3196	RFC 5321 SMTP October 2008
3197
3198
3199	receiver need merely do some simple arithmetic to convert the values.
3200	Use of UT loses information about the time zone-location of the
3201	server. If it is desired to supply a time zone name, it SHOULD be
3202	included in a comment.
3203
3204	When the delivery SMTP server makes the "final delivery" of a
3205	message, it inserts a return-path line at the beginning of the mail
3206	data. This use of return-path is required; mail systems MUST support
3207	it. The return-path line preserves the information in the <reverse-
3208	path> from the MAIL command. Here, final delivery means the message
3209	has left the SMTP environment. Normally, this would mean it had been
3210	delivered to the destination user or an associated mail drop, but in
3211	some cases it may be further processed and transmitted by another
3212	mail system.
3213
3214	It is possible for the mailbox in the return path to be different
3215	from the actual sender's mailbox, for example, if error responses are
3216	to be delivered to a special error handling mailbox rather than to
3217	the message sender. When mailing lists are involved, this
3218	arrangement is common and useful as a means of directing errors to
3219	the list maintainer rather than the message originator.
3220
3221	The text above implies that the final mail data will begin with a
3222	return path line, followed by one or more time stamp lines. These
3223	lines will be followed by the rest of the mail data: first the
3224	balance of the mail header section and then the body (RFC 5322 [4]).
3225
3226	It is sometimes difficult for an SMTP server to determine whether or
3227	not it is making final delivery since forwarding or other operations
3228	may occur after the message is accepted for delivery. Consequently,
3229	any further (forwarding, gateway, or relay) systems MAY remove the
3230	return path and rebuild the MAIL command as needed to ensure that
3231	exactly one such line appears in a delivered message.
3232
3233	A message-originating SMTP system SHOULD NOT send a message that
3234	already contains a Return-path header field. SMTP servers performing
3235	a relay function MUST NOT inspect the message data, and especially
3236	not to the extent needed to determine if Return-path header fields
3237	are present. SMTP servers making final delivery MAY remove Return-
3238	path header fields before adding their own.
3239
3240	The primary purpose of the Return-path is to designate the address to
3241	which messages indicating non-delivery or other mail system failures
3242	are to be sent. For this to be unambiguous, exactly one return path
3243	SHOULD be present when the message is delivered. Systems using RFC
3244	822 syntax with non-SMTP transports SHOULD designate an unambiguous
3245	address, associated with the transport envelope, to which error
3246	reports (e.g., non-delivery messages) should be sent.
3247
3248
3249
3250	Klensin Standards Track [Page 58]
3251
3252	RFC 5321 SMTP October 2008
3253
3254
3255	Historical note: Text in RFC 822 that appears to contradict the use
3256	of the Return-path header field (or the envelope reverse-path address
3257	from the MAIL command) as the destination for error messages is not
3258	applicable on the Internet. The reverse-path address (as copied into
3259	the Return-path) MUST be used as the target of any mail containing
3260	delivery error messages.
3261
3262	In particular:
3263	o a gateway from SMTP -> elsewhere SHOULD insert a return-path
3264	header field, unless it is known that the "elsewhere" transport
3265	also uses Internet domain addresses and maintains the envelope
3266	sender address separately.
3267
3268	o a gateway from elsewhere -> SMTP SHOULD delete any return-path
3269	header field present in the message, and either copy that
3270	information to the SMTP envelope or combine it with information
3271	present in the envelope of the other transport system to construct
3272	the reverse-path argument to the MAIL command in the SMTP
3273	envelope.
3274
3275	The server must give special treatment to cases in which the
3276	processing following the end of mail data indication is only
3277	partially successful. This could happen if, after accepting several
3278	recipients and the mail data, the SMTP server finds that the mail
3279	data could be successfully delivered to some, but not all, of the
3280	recipients. In such cases, the response to the DATA command MUST be
3281	an OK reply. However, the SMTP server MUST compose and send an
3282	"undeliverable mail" notification message to the originator of the
3283	message.
3284
3285	A single notification listing all of the failed recipients or
3286	separate notification messages MUST be sent for each failed
3287	recipient. For economy of processing by the sender, the former
3288	SHOULD be used when possible. Note that the key difference between
3289	handling aliases (Section 3.9.1) and forwarding (this subsection) is
3290	the change to the backward-pointing address in this case. All
3291	notification messages about undeliverable mail MUST be sent using the
3292	MAIL command (even if they result from processing the obsolete SEND,
3293	SOML, or SAML commands) and MUST use a null return path as discussed
3294	in Section 3.6.
3295
3296	The time stamp line and the return path line are formally defined as
3297	follows (the definitions for "FWS" and "CFWS" appear in RFC 5322
3298	[4]):
3299
3300	Return-path-line = "Return-Path:" FWS Reverse-path <CRLF>
3301
3302	Time-stamp-line = "Received:" FWS Stamp <CRLF>
3303
3304
3305
3306	Klensin Standards Track [Page 59]
3307
3308	RFC 5321 SMTP October 2008
3309
3310
3311	Stamp = From-domain By-domain Opt-info [CFWS] ";"
3312	FWS date-time
3313	; where "date-time" is as defined in RFC 5322 [4]
3314	; but the "obs-" forms, especially two-digit
3315	; years, are prohibited in SMTP and MUST NOT be used.
3316
3317	From-domain = "FROM" FWS Extended-Domain
3318
3319	By-domain = CFWS "BY" FWS Extended-Domain
3320
3321	Extended-Domain = Domain /
3322	( Domain FWS "(" TCP-info ")" ) /
3323	( address-literal FWS "(" TCP-info ")" )
3324
3325	TCP-info = address-literal / ( Domain FWS address-literal )
3326	; Information derived by server from TCP connection
3327	; not client EHLO.
3328
3329	Opt-info = [Via] [With] [ID] [For]
3330	[Additional-Registered-Clauses]
3331
3332	Via = CFWS "VIA" FWS Link
3333
3334	With = CFWS "WITH" FWS Protocol
3335
3336	ID = CFWS "ID" FWS ( Atom / msg-id )
3337	; msg-id is defined in RFC 5322 [4]
3338
3339	For = CFWS "FOR" FWS ( Path / Mailbox )
3340
3341	Additional-Registered-Clauses = CFWS Atom FWS String
3342	; Additional standard clauses may be
3343	added in this
3344	; location by future standards and
3345	registration with
3346	; IANA. SMTP servers SHOULD NOT use
3347	unregistered
3348	; names. See Section 8.
3349
3350	Link = "TCP" / Addtl-Link
3351
3352	Addtl-Link = Atom
3353	; Additional standard names for links are
3354	; registered with the Internet Assigned Numbers
3355	; Authority (IANA). "Via" is primarily of value
3356	; with non-Internet transports. SMTP servers
3357	; SHOULD NOT use unregistered names.
3358
3359
3360
3361
3362	Klensin Standards Track [Page 60]
3363
3364	RFC 5321 SMTP October 2008
3365
3366
3367	Protocol = "ESMTP" / "SMTP" / Attdl-Protocol
3368
3369	Attdl-Protocol = Atom
3370	; Additional standard names for protocols are
3371	; registered with the Internet Assigned Numbers
3372	; Authority (IANA) in the "mail parameters"
3373	; registry [9]. SMTP servers SHOULD NOT
3374	; use unregistered names.
3375
3376	4.5. Additional Implementation Issues
3377
3378	4.5.1. Minimum Implementation
3379
3380	In order to make SMTP workable, the following minimum implementation
3381	MUST be provided by all receivers. The following commands MUST be
3382	supported to conform to this specification:
3383
3384	EHLO
3385	HELO
3386	MAIL
3387	RCPT
3388	DATA
3389	RSET
3390	NOOP
3391	QUIT
3392	VRFY
3393
3394	Any system that includes an SMTP server supporting mail relaying or
3395	delivery MUST support the reserved mailbox "postmaster" as a case-
3396	insensitive local name. This postmaster address is not strictly
3397	necessary if the server always returns 554 on connection opening (as
3398	described in Section 3.1). The requirement to accept mail for
3399	postmaster implies that RCPT commands that specify a mailbox for
3400	postmaster at any of the domains for which the SMTP server provides
3401	mail service, as well as the special case of "RCPT TO:<Postmaster>"
3402	(with no domain specification), MUST be supported.
3403
3404	SMTP systems are expected to make every reasonable effort to accept
3405	mail directed to Postmaster from any other system on the Internet.
3406	In extreme cases -- such as to contain a denial of service attack or
3407	other breach of security -- an SMTP server may block mail directed to
3408	Postmaster. However, such arrangements SHOULD be narrowly tailored
3409	so as to avoid blocking messages that are not part of such attacks.
3410
3411
3412
3413
3414
3415
3416
3417
3418	Klensin Standards Track [Page 61]
3419
3420	RFC 5321 SMTP October 2008
3421
3422
3423	4.5.2. Transparency
3424
3425	Without some provision for data transparency, the character sequence
3426	"<CRLF>.<CRLF>" ends the mail text and cannot be sent by the user.
3427	In general, users are not aware of such "forbidden" sequences. To
3428	allow all user composed text to be transmitted transparently, the
3429	following procedures are used:
3430
3431	o Before sending a line of mail text, the SMTP client checks the
3432	first character of the line. If it is a period, one additional
3433	period is inserted at the beginning of the line.
3434
3435	o When a line of mail text is received by the SMTP server, it checks
3436	the line. If the line is composed of a single period, it is
3437	treated as the end of mail indicator. If the first character is a
3438	period and there are other characters on the line, the first
3439	character is deleted.
3440
3441	The mail data may contain any of the 128 ASCII characters. All
3442	characters are to be delivered to the recipient's mailbox, including
3443	spaces, vertical and horizontal tabs, and other control characters.
3444	If the transmission channel provides an 8-bit byte (octet) data
3445	stream, the 7-bit ASCII codes are transmitted, right justified, in
3446	the octets, with the high-order bits cleared to zero. See
3447	Section 3.6 for special treatment of these conditions in SMTP systems
3448	serving a relay function.
3449
3450	In some systems, it may be necessary to transform the data as it is
3451	received and stored. This may be necessary for hosts that use a
3452	different character set than ASCII as their local character set, that
3453	store data in records rather than strings, or which use special
3454	character sequences as delimiters inside mailboxes. If such
3455	transformations are necessary, they MUST be reversible, especially if
3456	they are applied to mail being relayed.
3457
3458	4.5.3. Sizes and Timeouts
3459
3460	4.5.3.1. Size Limits and Minimums
3461
3462	There are several objects that have required minimum/maximum sizes.
3463	Every implementation MUST be able to receive objects of at least
3464	these sizes. Objects larger than these sizes SHOULD be avoided when
3465	possible. However, some Internet mail constructs such as encoded
3466	X.400 addresses (RFC 2156 [35]) will often require larger objects.
3467	Clients MAY attempt to transmit these, but MUST be prepared for a
3468	server to reject them if they cannot be handled by it. To the
3469	maximum extent possible, implementation techniques that impose no
3470	limits on the length of these objects should be used.
3471
3472
3473
3474	Klensin Standards Track [Page 62]
3475
3476	RFC 5321 SMTP October 2008
3477
3478
3479	Extensions to SMTP may involve the use of characters that occupy more
3480	than a single octet each. This section therefore specifies lengths
3481	in octets where absolute lengths, rather than character counts, are
3482	intended.
3483
3484	4.5.3.1.1. Local-part
3485
3486	The maximum total length of a user name or other local-part is 64
3487	octets.
3488
3489	4.5.3.1.2. Domain
3490
3491	The maximum total length of a domain name or number is 255 octets.
3492
3493	4.5.3.1.3. Path
3494
3495	The maximum total length of a reverse-path or forward-path is 256
3496	octets (including the punctuation and element separators).
3497
3498	4.5.3.1.4. Command Line
3499
3500	The maximum total length of a command line including the command word
3501	and the <CRLF> is 512 octets. SMTP extensions may be used to
3502	increase this limit.
3503
3504	4.5.3.1.5. Reply Line
3505
3506	The maximum total length of a reply line including the reply code and
3507	the <CRLF> is 512 octets. More information may be conveyed through
3508	multiple-line replies.
3509
3510	4.5.3.1.6. Text Line
3511
3512	The maximum total length of a text line including the <CRLF> is 1000
3513	octets (not counting the leading dot duplicated for transparency).
3514	This number may be increased by the use of SMTP Service Extensions.
3515
3516	4.5.3.1.7. Message Content
3517
3518	The maximum total length of a message content (including any message
3519	header section as well as the message body) MUST BE at least 64K
3520	octets. Since the introduction of Internet Standards for multimedia
3521	mail (RFC 2045 [21]), message lengths on the Internet have grown
3522	dramatically, and message size restrictions should be avoided if at
3523	all possible. SMTP server systems that must impose restrictions
3524	SHOULD implement the "SIZE" service extension of RFC 1870 [10], and
3525	SMTP client systems that will send large messages SHOULD utilize it
3526	when possible.
3527
3528
3529
3530	Klensin Standards Track [Page 63]
3531
3532	RFC 5321 SMTP October 2008
3533
3534
3535	4.5.3.1.8. Recipients Buffer
3536
3537	The minimum total number of recipients that MUST be buffered is 100
3538	recipients. Rejection of messages (for excessive recipients) with
3539	fewer than 100 RCPT commands is a violation of this specification.
3540	The general principle that relaying SMTP server MUST NOT, and
3541	delivery SMTP servers SHOULD NOT, perform validation tests on message
3542	header fields suggests that messages SHOULD NOT be rejected based on
3543	the total number of recipients shown in header fields. A server that
3544	imposes a limit on the number of recipients MUST behave in an orderly
3545	fashion, such as rejecting additional addresses over its limit rather
3546	than silently discarding addresses previously accepted. A client
3547	that needs to deliver a message containing over 100 RCPT commands
3548	SHOULD be prepared to transmit in 100-recipient "chunks" if the
3549	server declines to accept more than 100 recipients in a single
3550	message.
3551
3552	4.5.3.1.9. Treatment When Limits Exceeded
3553
3554	Errors due to exceeding these limits may be reported by using the
3555	reply codes. Some examples of reply codes are:
3556
3557	500 Line too long.
3558
3559	or
3560
3561	501 Path too long
3562
3563	or
3564
3565	452 Too many recipients (see below)
3566
3567	or
3568
3569	552 Too much mail data.
3570
3571	4.5.3.1.10. Too Many Recipients Code
3572
3573	RFC 821 [1] incorrectly listed the error where an SMTP server
3574	exhausts its implementation limit on the number of RCPT commands
3575	("too many recipients") as having reply code 552. The correct reply
3576	code for this condition is 452. Clients SHOULD treat a 552 code in
3577	this case as a temporary, rather than permanent, failure so the logic
3578	below works.
3579
3580	When a conforming SMTP server encounters this condition, it has at
3581	least 100 successful RCPT commands in its recipients buffer. If the
3582	server is able to accept the message, then at least these 100
3583
3584
3585
3586	Klensin Standards Track [Page 64]
3587
3588	RFC 5321 SMTP October 2008
3589
3590
3591	addresses will be removed from the SMTP client's queue. When the
3592	client attempts retransmission of those addresses that received 452
3593	responses, at least 100 of these will be able to fit in the SMTP
3594	server's recipients buffer. Each retransmission attempt that is able
3595	to deliver anything will be able to dispose of at least 100 of these
3596	recipients.
3597
3598	If an SMTP server has an implementation limit on the number of RCPT
3599	commands and this limit is exhausted, it MUST use a response code of
3600	452 (but the client SHOULD also be prepared for a 552, as noted
3601	above). If the server has a configured site-policy limitation on the
3602	number of RCPT commands, it MAY instead use a 5yz response code. In
3603	particular, if the intent is to prohibit messages with more than a
3604	site-specified number of recipients, rather than merely limit the
3605	number of recipients in a given mail transaction, it would be
3606	reasonable to return a 503 response to any DATA command received
3607	subsequent to the 452 (or 552) code or to simply return the 503 after
3608	DATA without returning any previous negative response.
3609
3610	4.5.3.2. Timeouts
3611
3612	An SMTP client MUST provide a timeout mechanism. It MUST use per-
3613	command timeouts rather than somehow trying to time the entire mail
3614	transaction. Timeouts SHOULD be easily reconfigurable, preferably
3615	without recompiling the SMTP code. To implement this, a timer is set
3616	for each SMTP command and for each buffer of the data transfer. The
3617	latter means that the overall timeout is inherently proportional to
3618	the size of the message.
3619
3620	Based on extensive experience with busy mail-relay hosts, the minimum
3621	per-command timeout values SHOULD be as follows:
3622
3623	4.5.3.2.1. Initial 220 Message: 5 Minutes
3624
3625	An SMTP client process needs to distinguish between a failed TCP
3626	connection and a delay in receiving the initial 220 greeting message.
3627	Many SMTP servers accept a TCP connection but delay delivery of the
3628	220 message until their system load permits more mail to be
3629	processed.
3630
3631	4.5.3.2.2. MAIL Command: 5 Minutes
3632
3633	4.5.3.2.3. RCPT Command: 5 Minutes
3634
3635	A longer timeout is required if processing of mailing lists and
3636	aliases is not deferred until after the message was accepted.
3637
3638
3639
3640
3641
3642	Klensin Standards Track [Page 65]
3643
3644	RFC 5321 SMTP October 2008
3645
3646
3647	4.5.3.2.4. DATA Initiation: 2 Minutes
3648
3649	This is while awaiting the "354 Start Input" reply to a DATA command.
3650
3651	4.5.3.2.5. Data Block: 3 Minutes
3652
3653	This is while awaiting the completion of each TCP SEND call
3654	transmitting a chunk of data.
3655
3656	4.5.3.2.6. DATA Termination: 10 Minutes.
3657
3658	This is while awaiting the "250 OK" reply. When the receiver gets
3659	the final period terminating the message data, it typically performs
3660	processing to deliver the message to a user mailbox. A spurious
3661	timeout at this point would be very wasteful and would typically
3662	result in delivery of multiple copies of the message, since it has
3663	been successfully sent and the server has accepted responsibility for
3664	delivery. See Section 6.1 for additional discussion.
3665
3666	4.5.3.2.7. Server Timeout: 5 Minutes.
3667
3668	An SMTP server SHOULD have a timeout of at least 5 minutes while it
3669	is awaiting the next command from the sender.
3670
3671	4.5.4. Retry Strategies
3672
3673	The common structure of a host SMTP implementation includes user
3674	mailboxes, one or more areas for queuing messages in transit, and one
3675	or more daemon processes for sending and receiving mail. The exact
3676	structure will vary depending on the needs of the users on the host
3677	and the number and size of mailing lists supported by the host. We
3678	describe several optimizations that have proved helpful, particularly
3679	for mailers supporting high traffic levels.
3680
3681	Any queuing strategy MUST include timeouts on all activities on a
3682	per-command basis. A queuing strategy MUST NOT send error messages
3683	in response to error messages under any circumstances.
3684
3685	4.5.4.1. Sending Strategy
3686
3687	The general model for an SMTP client is one or more processes that
3688	periodically attempt to transmit outgoing mail. In a typical system,
3689	the program that composes a message has some method for requesting
3690	immediate attention for a new piece of outgoing mail, while mail that
3691	cannot be transmitted immediately MUST be queued and periodically
3692	retried by the sender. A mail queue entry will include not only the
3693	message itself but also the envelope information.
3694
3695
3696
3697
3698	Klensin Standards Track [Page 66]
3699
3700	RFC 5321 SMTP October 2008
3701
3702
3703	The sender MUST delay retrying a particular destination after one
3704	attempt has failed. In general, the retry interval SHOULD be at
3705	least 30 minutes; however, more sophisticated and variable strategies
3706	will be beneficial when the SMTP client can determine the reason for
3707	non-delivery.
3708
3709	Retries continue until the message is transmitted or the sender gives
3710	up; the give-up time generally needs to be at least 4-5 days. It MAY
3711	be appropriate to set a shorter maximum number of retries for non-
3712	delivery notifications and equivalent error messages than for
3713	standard messages. The parameters to the retry algorithm MUST be
3714	configurable.
3715
3716	A client SHOULD keep a list of hosts it cannot reach and
3717	corresponding connection timeouts, rather than just retrying queued
3718	mail items.
3719
3720	Experience suggests that failures are typically transient (the target
3721	system or its connection has crashed), favoring a policy of two
3722	connection attempts in the first hour the message is in the queue,
3723	and then backing off to one every two or three hours.
3724
3725	The SMTP client can shorten the queuing delay in cooperation with the
3726	SMTP server. For example, if mail is received from a particular
3727	address, it is likely that mail queued for that host can now be sent.
3728	Application of this principle may, in many cases, eliminate the
3729	requirement for an explicit "send queues now" function such as ETRN,
3730	RFC 1985 [36].
3731
3732	The strategy may be further modified as a result of multiple
3733	addresses per host (see below) to optimize delivery time versus
3734	resource usage.
3735
3736	An SMTP client may have a large queue of messages for each
3737	unavailable destination host. If all of these messages were retried
3738	in every retry cycle, there would be excessive Internet overhead and
3739	the sending system would be blocked for a long period. Note that an
3740	SMTP client can generally determine that a delivery attempt has
3741	failed only after a timeout of several minutes, and even a one-minute
3742	timeout per connection will result in a very large delay if retries
3743	are repeated for dozens, or even hundreds, of queued messages to the
3744	same host.
3745
3746	At the same time, SMTP clients SHOULD use great care in caching
3747	negative responses from servers. In an extreme case, if EHLO is
3748	issued multiple times during the same SMTP connection, different
3749	answers may be returned by the server. More significantly, 5yz
3750	responses to the MAIL command MUST NOT be cached.
3751
3752
3753
3754	Klensin Standards Track [Page 67]
3755
3756	RFC 5321 SMTP October 2008
3757
3758
3759	When a mail message is to be delivered to multiple recipients, and
3760	the SMTP server to which a copy of the message is to be sent is the
3761	same for multiple recipients, then only one copy of the message
3762	SHOULD be transmitted. That is, the SMTP client SHOULD use the
3763	command sequence: MAIL, RCPT, RCPT, ..., RCPT, DATA instead of the
3764	sequence: MAIL, RCPT, DATA, ..., MAIL, RCPT, DATA. However, if there
3765	are very many addresses, a limit on the number of RCPT commands per
3766	MAIL command MAY be imposed. This efficiency feature SHOULD be
3767	implemented.
3768
3769	Similarly, to achieve timely delivery, the SMTP client MAY support
3770	multiple concurrent outgoing mail transactions. However, some limit
3771	may be appropriate to protect the host from devoting all its
3772	resources to mail.
3773
3774	4.5.4.2. Receiving Strategy
3775
3776	The SMTP server SHOULD attempt to keep a pending listen on the SMTP
3777	port (specified by IANA as port 25) at all times. This requires the
3778	support of multiple incoming TCP connections for SMTP. Some limit
3779	MAY be imposed, but servers that cannot handle more than one SMTP
3780	transaction at a time are not in conformance with the intent of this
3781	specification.
3782
3783	As discussed above, when the SMTP server receives mail from a
3784	particular host address, it could activate its own SMTP queuing
3785	mechanisms to retry any mail pending for that host address.
3786
3787	4.5.5. Messages with a Null Reverse-Path
3788
3789	There are several types of notification messages that are required by
3790	existing and proposed Standards to be sent with a null reverse-path,
3791	namely non-delivery notifications as discussed in Section 3.7, other
3792	kinds of Delivery Status Notifications (DSNs, RFC 3461 [32]), and
3793	Message Disposition Notifications (MDNs, RFC 3798 [37]). All of
3794	these kinds of messages are notifications about a previous message,
3795	and they are sent to the reverse-path of the previous mail message.
3796	(If the delivery of such a notification message fails, that usually
3797	indicates a problem with the mail system of the host to which the
3798	notification message is addressed. For this reason, at some hosts
3799	the MTA is set up to forward such failed notification messages to
3800	someone who is able to fix problems with the mail system, e.g., via
3801	the postmaster alias.)
3802
3803	All other types of messages (i.e., any message which is not required
3804	by a Standards-Track RFC to have a null reverse-path) SHOULD be sent
3805	with a valid, non-null reverse-path.
3806
3807
3808
3809
3810	Klensin Standards Track [Page 68]
3811
3812	RFC 5321 SMTP October 2008
3813
3814
3815	Implementers of automated email processors should be careful to make
3816	sure that the various kinds of messages with a null reverse-path are
3817	handled correctly. In particular, such systems SHOULD NOT reply to
3818	messages with a null reverse-path, and they SHOULD NOT add a non-null
3819	reverse-path, or change a null reverse-path to a non-null one, to
3820	such messages when forwarding.
3821
3822	5. Address Resolution and Mail Handling
3823
3824	5.1. Locating the Target Host
3825
3826	Once an SMTP client lexically identifies a domain to which mail will
3827	be delivered for processing (as described in Sections 2.3.5 and 3.6),
3828	a DNS lookup MUST be performed to resolve the domain name (RFC 1035
3829	[2]). The names are expected to be fully-qualified domain names
3830	(FQDNs): mechanisms for inferring FQDNs from partial names or local
3831	aliases are outside of this specification. Due to a history of
3832	problems, SMTP servers used for initial submission of messages SHOULD
3833	NOT make such inferences (Message Submission Servers [18] have
3834	somewhat more flexibility) and intermediate (relay) SMTP servers MUST
3835	NOT make them.
3836
3837	The lookup first attempts to locate an MX record associated with the
3838	name. If a CNAME record is found, the resulting name is processed as
3839	if it were the initial name. If a non-existent domain error is
3840	returned, this situation MUST be reported as an error. If a
3841	temporary error is returned, the message MUST be queued and retried
3842	later (see Section 4.5.4.1). If an empty list of MXs is returned,
3843	the address is treated as if it was associated with an implicit MX
3844	RR, with a preference of 0, pointing to that host. If MX records are
3845	present, but none of them are usable, or the implicit MX is unusable,
3846	this situation MUST be reported as an error.
3847
3848	If one or more MX RRs are found for a given name, SMTP systems MUST
3849	NOT utilize any address RRs associated with that name unless they are
3850	located using the MX RRs; the "implicit MX" rule above applies only
3851	if there are no MX records present. If MX records are present, but
3852	none of them are usable, this situation MUST be reported as an error.
3853
3854	When a domain name associated with an MX RR is looked up and the
3855	associated data field obtained, the data field of that response MUST
3856	contain a domain name. That domain name, when queried, MUST return
3857	at least one address record (e.g., A or AAAA RR) that gives the IP
3858	address of the SMTP server to which the message should be directed.
3859	Any other response, specifically including a value that will return a
3860	CNAME record when queried, lies outside the scope of this Standard.
3861	The prohibition on labels in the data that resolve to CNAMEs is
3862	discussed in more detail in RFC 2181, Section 10.3 [38].
3863
3864
3865
3866	Klensin Standards Track [Page 69]
3867
3868	RFC 5321 SMTP October 2008
3869
3870
3871	When the lookup succeeds, the mapping can result in a list of
3872	alternative delivery addresses rather than a single address, because
3873	of multiple MX records, multihoming, or both. To provide reliable
3874	mail transmission, the SMTP client MUST be able to try (and retry)
3875	each of the relevant addresses in this list in order, until a
3876	delivery attempt succeeds. However, there MAY also be a configurable
3877	limit on the number of alternate addresses that can be tried. In any
3878	case, the SMTP client SHOULD try at least two addresses.
3879
3880	Two types of information are used to rank the host addresses:
3881	multiple MX records, and multihomed hosts.
3882
3883	MX records contain a preference indication that MUST be used in
3884	sorting if more than one such record appears (see below). Lower
3885	numbers are more preferred than higher ones. If there are multiple
3886	destinations with the same preference and there is no clear reason to
3887	favor one (e.g., by recognition of an easily reached address), then
3888	the sender-SMTP MUST randomize them to spread the load across
3889	multiple mail exchangers for a specific organization.
3890
3891	The destination host (perhaps taken from the preferred MX record) may
3892	be multihomed, in which case the domain name resolver will return a
3893	list of alternative IP addresses. It is the responsibility of the
3894	domain name resolver interface to have ordered this list by
3895	decreasing preference if necessary, and the SMTP sender MUST try them
3896	in the order presented.
3897
3898	Although the capability to try multiple alternative addresses is
3899	required, specific installations may want to limit or disable the use
3900	of alternative addresses. The question of whether a sender should
3901	attempt retries using the different addresses of a multihomed host
3902	has been controversial. The main argument for using the multiple
3903	addresses is that it maximizes the probability of timely delivery,
3904	and indeed sometimes the probability of any delivery; the counter-
3905	argument is that it may result in unnecessary resource use. Note
3906	that resource use is also strongly determined by the sending strategy
3907	discussed in Section 4.5.4.1.
3908
3909	If an SMTP server receives a message with a destination for which it
3910	is a designated Mail eXchanger, it MAY relay the message (potentially
3911	after having rewritten the MAIL FROM and/or RCPT TO addresses), make
3912	final delivery of the message, or hand it off using some mechanism
3913	outside the SMTP-provided transport environment. Of course, neither
3914	of the latter require that the list of MX records be examined
3915	further.
3916
3917	If it determines that it should relay the message without rewriting
3918	the address, it MUST sort the MX records to determine candidates for
3919
3920
3921
3922	Klensin Standards Track [Page 70]
3923
3924	RFC 5321 SMTP October 2008
3925
3926
3927	delivery. The records are first ordered by preference, with the
3928	lowest-numbered records being most preferred. The relay host MUST
3929	then inspect the list for any of the names or addresses by which it
3930	might be known in mail transactions. If a matching record is found,
3931	all records at that preference level and higher-numbered ones MUST be
3932	discarded from consideration. If there are no records left at that
3933	point, it is an error condition, and the message MUST be returned as
3934	undeliverable. If records do remain, they SHOULD be tried, best
3935	preference first, as described above.
3936
3937	5.2. IPv6 and MX Records
3938
3939	In the contemporary Internet, SMTP clients and servers may be hosted
3940	on IPv4 systems, IPv6 systems, or dual-stack systems that are
3941	compatible with either version of the Internet Protocol. The host
3942	domains to which MX records point may, consequently, contain "A RR"s
3943	(IPv4), "AAAA RR"s (IPv6), or any combination of them. While RFC
3944	3974 [39] discusses some operational experience in mixed
3945	environments, it was not comprehensive enough to justify
3946	standardization, and some of its recommendations appear to be
3947	inconsistent with this specification. The appropriate actions to be
3948	taken either will depend on local circumstances, such as performance
3949	of the relevant networks and any conversions that might be necessary,
3950	or will be obvious (e.g., an IPv6-only client need not attempt to
3951	look up A RRs or attempt to reach IPv4-only servers). Designers of
3952	SMTP implementations that might run in IPv6 or dual-stack
3953	environments should study the procedures above, especially the
3954	comments about multihomed hosts, and, preferably, provide mechanisms
3955	to facilitate operational tuning and mail interoperability between
3956	IPv4 and IPv6 systems while considering local circumstances.
3957
3958	6. Problem Detection and Handling
3959
3960	6.1. Reliable Delivery and Replies by Email
3961
3962	When the receiver-SMTP accepts a piece of mail (by sending a "250 OK"
3963	message in response to DATA), it is accepting responsibility for
3964	delivering or relaying the message. It must take this responsibility
3965	seriously. It MUST NOT lose the message for frivolous reasons, such
3966	as because the host later crashes or because of a predictable
3967	resource shortage. Some reasons that are not considered frivolous
3968	are discussed in the next subsection and in Section 7.8.
3969
3970	If there is a delivery failure after acceptance of a message, the
3971	receiver-SMTP MUST formulate and mail a notification message. This
3972	notification MUST be sent using a null ("<>") reverse-path in the
3973	envelope. The recipient of this notification MUST be the address
3974	from the envelope return path (or the Return-Path: line). However,
3975
3976
3977
3978	Klensin Standards Track [Page 71]
3979
3980	RFC 5321 SMTP October 2008
3981
3982
3983	if this address is null ("<>"), the receiver-SMTP MUST NOT send a
3984	notification. Obviously, nothing in this section can or should
3985	prohibit local decisions (i.e., as part of the same system
3986	environment as the receiver-SMTP) to log or otherwise transmit
3987	information about null address events locally if that is desired. If
3988	the address is an explicit source route, it MUST be stripped down to
3989	its final hop.
3990
3991	For example, suppose that an error notification must be sent for a
3992	message that arrived with:
3993
3994	MAIL FROM:<@a,@b:user@d>
3995
3996	The notification message MUST be sent using:
3997
3998	RCPT TO:<user@d>
3999
4000	Some delivery failures after the message is accepted by SMTP will be
4001	unavoidable. For example, it may be impossible for the receiving
4002	SMTP server to validate all the delivery addresses in RCPT command(s)
4003	due to a "soft" domain system error, because the target is a mailing
4004	list (see earlier discussion of RCPT), or because the server is
4005	acting as a relay and has no immediate access to the delivering
4006	system.
4007
4008	To avoid receiving duplicate messages as the result of timeouts, a
4009	receiver-SMTP MUST seek to minimize the time required to respond to
4010	the final <CRLF>.<CRLF> end of data indicator. See RFC 1047 [40] for
4011	a discussion of this problem.
4012
4013	6.2. Unwanted, Unsolicited, and "Attack" Messages
4014
4015	Utility and predictability of the Internet mail system requires that
4016	messages that can be delivered should be delivered, regardless of any
4017	syntax or other faults associated with those messages and regardless
4018	of their content. If they cannot be delivered, and cannot be
4019	rejected by the SMTP server during the SMTP transaction, they should
4020	be "bounced" (returned with non-delivery notification messages) as
4021	described above. In today's world, in which many SMTP server
4022	operators have discovered that the quantity of undesirable bulk email
4023	vastly exceeds the quantity of desired mail and in which accepting a
4024	message may trigger additional undesirable traffic by providing
4025	verification of the address, those principles may not be practical.
4026
4027	As discussed in Section 7.8 and Section 7.9 below, dropping mail
4028	without notification of the sender is permitted in practice.
4029	However, it is extremely dangerous and violates a long tradition and
4030	community expectations that mail is either delivered or returned. If
4031
4032
4033
4034	Klensin Standards Track [Page 72]
4035
4036	RFC 5321 SMTP October 2008
4037
4038
4039	silent message-dropping is misused, it could easily undermine
4040	confidence in the reliability of the Internet's mail systems. So
4041	silent dropping of messages should be considered only in those cases
4042	where there is very high confidence that the messages are seriously
4043	fraudulent or otherwise inappropriate.
4044
4045	To stretch the principle of delivery if possible even further, it may
4046	be a rational policy to not deliver mail that has an invalid return
4047	address, although the history of the network is that users are
4048	typically better served by delivering any message that can be
4049	delivered. Reliably determining that a return address is invalid can
4050	be a difficult and time-consuming process, especially if the putative
4051	sending system is not directly accessible or does not fully and
4052	accurately support VRFY and, even if a "drop messages with invalid
4053	return addresses" policy is adopted, it SHOULD be applied only when
4054	there is near-certainty that the return addresses are, in fact,
4055	invalid.
4056
4057	Conversely, if a message is rejected because it is found to contain
4058	hostile content (a decision that is outside the scope of an SMTP
4059	server as defined in this document), rejection ("bounce") messages
4060	SHOULD NOT be sent unless the receiving site is confident that those
4061	messages will be usefully delivered. The preference and default in
4062	these cases is to avoid sending non-delivery messages when the
4063	incoming message is determined to contain hostile content.
4064
4065	6.3. Loop Detection
4066
4067	Simple counting of the number of "Received:" header fields in a
4068	message has proven to be an effective, although rarely optimal,
4069	method of detecting loops in mail systems. SMTP servers using this
4070	technique SHOULD use a large rejection threshold, normally at least
4071	100 Received entries. Whatever mechanisms are used, servers MUST
4072	contain provisions for detecting and stopping trivial loops.
4073
4074	6.4. Compensating for Irregularities
4075
4076	Unfortunately, variations, creative interpretations, and outright
4077	violations of Internet mail protocols do occur; some would suggest
4078	that they occur quite frequently. The debate as to whether a well-
4079	behaved SMTP receiver or relay should reject a malformed message,
4080	attempt to pass it on unchanged, or attempt to repair it to increase
4081	the odds of successful delivery (or subsequent reply) began almost
4082	with the dawn of structured network mail and shows no signs of
4083	abating. Advocates of rejection claim that attempted repairs are
4084	rarely completely adequate and that rejection of bad messages is the
4085	only way to get the offending software repaired. Advocates of
4086	"repair" or "deliver no matter what" argue that users prefer that
4087
4088
4089
4090	Klensin Standards Track [Page 73]
4091
4092	RFC 5321 SMTP October 2008
4093
4094
4095	mail go through it if at all possible and that there are significant
4096	market pressures in that direction. In practice, these market
4097	pressures may be more important to particular vendors than strict
4098	conformance to the standards, regardless of the preference of the
4099	actual developers.
4100
4101	The problems associated with ill-formed messages were exacerbated by
4102	the introduction of the split-UA mail reading protocols (Post Office
4103	Protocol (POP) version 2 [15], Post Office Protocol (POP) version 3
4104	[16], IMAP version 2 [41], and PCMAIL [42]). These protocols
4105	encouraged the use of SMTP as a posting (message submission)
4106	protocol, and SMTP servers as relay systems for these client hosts
4107	(which are often only intermittently connected to the Internet).
4108	Historically, many of those client machines lacked some of the
4109	mechanisms and information assumed by SMTP (and indeed, by the mail
4110	format protocol, RFC 822 [28]). Some could not keep adequate track
4111	of time; others had no concept of time zones; still others could not
4112	identify their own names or addresses; and, of course, none could
4113	satisfy the assumptions that underlay RFC 822's conception of
4114	authenticated addresses.
4115
4116	In response to these weak SMTP clients, many SMTP systems now
4117	complete messages that are delivered to them in incomplete or
4118	incorrect form. This strategy is generally considered appropriate
4119	when the server can identify or authenticate the client, and there
4120	are prior agreements between them. By contrast, there is at best
4121	great concern about fixes applied by a relay or delivery SMTP server
4122	that has little or no knowledge of the user or client machine. Many
4123	of these issues are addressed by using a separate protocol, such as
4124	that defined in RFC 4409 [18], for message submission, rather than
4125	using originating SMTP servers for that purpose.
4126
4127	The following changes to a message being processed MAY be applied
4128	when necessary by an originating SMTP server, or one used as the
4129	target of SMTP as an initial posting (message submission) protocol:
4130
4131	o Addition of a message-id field when none appears
4132
4133	o Addition of a date, time, or time zone when none appears
4134
4135	o Correction of addresses to proper FQDN format
4136
4137	The less information the server has about the client, the less likely
4138	these changes are to be correct and the more caution and conservatism
4139	should be applied when considering whether or not to perform fixes
4140	and how. These changes MUST NOT be applied by an SMTP server that
4141	provides an intermediate relay function.
4142
4143
4144
4145
4146	Klensin Standards Track [Page 74]
4147
4148	RFC 5321 SMTP October 2008
4149
4150
4151	In all cases, properly operating clients supplying correct
4152	information are preferred to corrections by the SMTP server. In all
4153	cases, documentation SHOULD be provided in trace header fields and/or
4154	header field comments for actions performed by the servers.
4155
4156	7. Security Considerations
4157
4158	7.1. Mail Security and Spoofing
4159
4160	SMTP mail is inherently insecure in that it is feasible for even
4161	fairly casual users to negotiate directly with receiving and relaying
4162	SMTP servers and create messages that will trick a naive recipient
4163	into believing that they came from somewhere else. Constructing such
4164	a message so that the "spoofed" behavior cannot be detected by an
4165	expert is somewhat more difficult, but not sufficiently so as to be a
4166	deterrent to someone who is determined and knowledgeable.
4167	Consequently, as knowledge of Internet mail increases, so does the
4168	knowledge that SMTP mail inherently cannot be authenticated, or
4169	integrity checks provided, at the transport level. Real mail
4170	security lies only in end-to-end methods involving the message
4171	bodies, such as those that use digital signatures (see RFC 1847 [43]
4172	and, e.g., Pretty Good Privacy (PGP) in RFC 4880 [44] or Secure/
4173	Multipurpose Internet Mail Extensions (S/MIME) in RFC 3851 [45]).
4174
4175	Various protocol extensions and configuration options that provide
4176	authentication at the transport level (e.g., from an SMTP client to
4177	an SMTP server) improve somewhat on the traditional situation
4178	described above. However, in general, they only authenticate one
4179	server to another rather than a chain of relays and servers, much
4180	less authenticating users or user machines. Consequently, unless
4181	they are accompanied by careful handoffs of responsibility in a
4182	carefully designed trust environment, they remain inherently weaker
4183	than end-to-end mechanisms that use digitally signed messages rather
4184	than depending on the integrity of the transport system.
4185
4186	Efforts to make it more difficult for users to set envelope return
4187	path and header "From" fields to point to valid addresses other than
4188	their own are largely misguided: they frustrate legitimate
4189	applications in which mail is sent by one user on behalf of another,
4190	in which error (or normal) replies should be directed to a special
4191	address, or in which a single message is sent to multiple recipients
4192	on different hosts. (Systems that provide convenient ways for users
4193	to alter these header fields on a per-message basis should attempt to
4194	establish a primary and permanent mailbox address for the user so
4195	that Sender header fields within the message data can be generated
4196	sensibly.)
4197
4198
4199
4200
4201
4202	Klensin Standards Track [Page 75]
4203
4204	RFC 5321 SMTP October 2008
4205
4206
4207	This specification does not further address the authentication issues
4208	associated with SMTP other than to advocate that useful functionality
4209	not be disabled in the hope of providing some small margin of
4210	protection against a user who is trying to fake mail.
4211
4212	7.2. "Blind" Copies
4213
4214	Addresses that do not appear in the message header section may appear
4215	in the RCPT commands to an SMTP server for a number of reasons. The
4216	two most common involve the use of a mailing address as a "list
4217	exploder" (a single address that resolves into multiple addresses)
4218	and the appearance of "blind copies". Especially when more than one
4219	RCPT command is present, and in order to avoid defeating some of the
4220	purpose of these mechanisms, SMTP clients and servers SHOULD NOT copy
4221	the full set of RCPT command arguments into the header section,
4222	either as part of trace header fields or as informational or private-
4223	extension header fields. Since this rule is often violated in
4224	practice, and cannot be enforced, sending SMTP systems that are aware
4225	of "bcc" use MAY find it helpful to send each blind copy as a
4226	separate message transaction containing only a single RCPT command.
4227
4228	There is no inherent relationship between either "reverse" (from
4229	MAIL, SAML, etc., commands) or "forward" (RCPT) addresses in the SMTP
4230	transaction ("envelope") and the addresses in the header section.
4231	Receiving systems SHOULD NOT attempt to deduce such relationships and
4232	use them to alter the header section of the message for delivery.
4233	The popular "Apparently-to" header field is a violation of this
4234	principle as well as a common source of unintended information
4235	disclosure and SHOULD NOT be used.
4236
4237	7.3. VRFY, EXPN, and Security
4238
4239	As discussed in Section 3.5, individual sites may want to disable
4240	either or both of VRFY or EXPN for security reasons (see below). As
4241	a corollary to the above, implementations that permit this MUST NOT
4242	appear to have verified addresses that are not, in fact, verified.
4243	If a site disables these commands for security reasons, the SMTP
4244	server MUST return a 252 response, rather than a code that could be
4245	confused with successful or unsuccessful verification.
4246
4247	Returning a 250 reply code with the address listed in the VRFY
4248	command after having checked it only for syntax violates this rule.
4249	Of course, an implementation that "supports" VRFY by always returning
4250	550 whether or not the address is valid is equally not in
4251	conformance.
4252
4253	On the public Internet, the contents of mailing lists have become
4254	popular as an address information source for so-called "spammers."
4255
4256
4257
4258	Klensin Standards Track [Page 76]
4259
4260	RFC 5321 SMTP October 2008
4261
4262
4263	The use of EXPN to "harvest" addresses has increased as list
4264	administrators have installed protections against inappropriate uses
4265	of the lists themselves. However, VRFY and EXPN are still useful for
4266	authenticated users and within an administrative domain. For
4267	example, VRFY and EXPN are useful for performing internal audits of
4268	how email gets routed to check and to make sure no one is
4269	automatically forwarding sensitive mail outside the organization.
4270	Sites implementing SMTP authentication may choose to make VRFY and
4271	EXPN available only to authenticated requestors. Implementations
4272	SHOULD still provide support for EXPN, but sites SHOULD carefully
4273	evaluate the tradeoffs.
4274
4275	Whether disabling VRFY provides any real marginal security depends on
4276	a series of other conditions. In many cases, RCPT commands can be
4277	used to obtain the same information about address validity. On the
4278	other hand, especially in situations where determination of address
4279	validity for RCPT commands is deferred until after the DATA command
4280	is received, RCPT may return no information at all, while VRFY is
4281	expected to make a serious attempt to determine validity before
4282	generating a response code (see discussion above).
4283
4284	7.4. Mail Rerouting Based on the 251 and 551 Response Codes
4285
4286	Before a client uses the 251 or 551 reply codes from a RCPT command
4287	to automatically update its future behavior (e.g., updating the
4288	user's address book), it should be certain of the server's
4289	authenticity. If it does not, it may be subject to a man in the
4290	middle attack.
4291
4292	7.5. Information Disclosure in Announcements
4293
4294	There has been an ongoing debate about the tradeoffs between the
4295	debugging advantages of announcing server type and version (and,
4296	sometimes, even server domain name) in the greeting response or in
4297	response to the HELP command and the disadvantages of exposing
4298	information that might be useful in a potential hostile attack. The
4299	utility of the debugging information is beyond doubt. Those who
4300	argue for making it available point out that it is far better to
4301	actually secure an SMTP server rather than hope that trying to
4302	conceal known vulnerabilities by hiding the server's precise identity
4303	will provide more protection. Sites are encouraged to evaluate the
4304	tradeoff with that issue in mind; implementations SHOULD minimally
4305	provide for making type and version information available in some way
4306	to other network hosts.
4307
4308
4309
4310
4311
4312
4313
4314	Klensin Standards Track [Page 77]
4315
4316	RFC 5321 SMTP October 2008
4317
4318
4319	7.6. Information Disclosure in Trace Fields
4320
4321	In some circumstances, such as when mail originates from within a LAN
4322	whose hosts are not directly on the public Internet, trace
4323	("Received") header fields produced in conformance with this
4324	specification may disclose host names and similar information that
4325	would not normally be available. This ordinarily does not pose a
4326	problem, but sites with special concerns about name disclosure should
4327	be aware of it. Also, the optional FOR clause should be supplied
4328	with caution or not at all when multiple recipients are involved lest
4329	it inadvertently disclose the identities of "blind copy" recipients
4330	to others.
4331
4332	7.7. Information Disclosure in Message Forwarding
4333
4334	As discussed in Section 3.4, use of the 251 or 551 reply codes to
4335	identify the replacement address associated with a mailbox may
4336	inadvertently disclose sensitive information. Sites that are
4337	concerned about those issues should ensure that they select and
4338	configure servers appropriately.
4339
4340	7.8. Resistance to Attacks
4341
4342	In recent years, there has been an increase of attacks on SMTP
4343	servers, either in conjunction with attempts to discover addresses
4344	for sending unsolicited messages or simply to make the servers
4345	inaccessible to others (i.e., as an application-level denial of
4346	service attack). While the means of doing so are beyond the scope of
4347	this Standard, rational operational behavior requires that servers be
4348	permitted to detect such attacks and take action to defend
4349	themselves. For example, if a server determines that a large number
4350	of RCPT TO commands are being sent, most or all with invalid
4351	addresses, as part of such an attack, it would be reasonable for the
4352	server to close the connection after generating an appropriate number
4353	of 5yz (normally 550) replies.
4354
4355	7.9. Scope of Operation of SMTP Servers
4356
4357	It is a well-established principle that an SMTP server may refuse to
4358	accept mail for any operational or technical reason that makes sense
4359	to the site providing the server. However, cooperation among sites
4360	and installations makes the Internet possible. If sites take
4361	excessive advantage of the right to reject traffic, the ubiquity of
4362	email availability (one of the strengths of the Internet) will be
4363	threatened; considerable care should be taken and balance maintained
4364	if a site decides to be selective about the traffic it will accept
4365	and process.
4366
4367
4368
4369
4370	Klensin Standards Track [Page 78]
4371
4372	RFC 5321 SMTP October 2008
4373
4374
4375	In recent years, use of the relay function through arbitrary sites
4376	has been used as part of hostile efforts to hide the actual origins
4377	of mail. Some sites have decided to limit the use of the relay
4378	function to known or identifiable sources, and implementations SHOULD
4379	provide the capability to perform this type of filtering. When mail
4380	is rejected for these or other policy reasons, a 550 code SHOULD be
4381	used in response to EHLO (or HELO), MAIL, or RCPT as appropriate.
4382
4383	8. IANA Considerations
4384
4385	IANA maintains three registries in support of this specification, all
4386	of which were created for RFC 2821 or earlier. This document expands
4387	the third one as specified below. The registry references listed are
4388	as of the time of publication; IANA does not guarantee the locations
4389	associated with the URLs. The registries are as follows:
4390
4391	o The first, "Simple Mail Transfer Protocol (SMTP) Service
4392	Extensions" [46], consists of SMTP service extensions with the
4393	associated keywords, and, as needed, parameters and verbs. As
4394	specified in Section 2.2.2, no entry may be made in this registry
4395	that starts in an "X". Entries may be made only for service
4396	extensions (and associated keywords, parameters, or verbs) that
4397	are defined in Standards-Track or Experimental RFCs specifically
4398	approved by the IESG for this purpose.
4399
4400	o The second registry, "Address Literal Tags" [47], consists of
4401	"tags" that identify forms of domain literals other than those for
4402	IPv4 addresses (specified in RFC 821 and in this document). The
4403	initial entry in that registry is for IPv6 addresses (specified in
4404	this document). Additional literal types require standardization
4405	before being used; none are anticipated at this time.
4406
4407	o The third, "Mail Transmission Types" [46], established by RFC 821
4408	and renewed by this specification, is a registry of link and
4409	protocol identifiers to be used with the "via" and "with"
4410	subclauses of the time stamp ("Received:" header field) described
4411	in Section 4.4. Link and protocol identifiers in addition to
4412	those specified in this document may be registered only by
4413	standardization or by way of an RFC-documented, IESG-approved,
4414	Experimental protocol extension. This name space is for
4415	identification and not limited in size: the IESG is encouraged to
4416	approve on the basis of clear documentation and a distinct method
4417	rather than preferences about the properties of the method itself.
4418
4419	An additional subsection has been added to the "VIA link types"
4420	and "WITH protocol types" subsections of this registry to contain
4421	registrations of "Additional-registered-clauses" as described
4422	above. The registry will contain clause names, a description, a
4423
4424
4425
4426	Klensin Standards Track [Page 79]
4427
4428	RFC 5321 SMTP October 2008
4429
4430
4431	summary of the syntax of the associated String, and a reference.
4432	As new clauses are defined, they may, in principle, specify
4433	creation of their own registries if the Strings consist of
4434	reserved terms or keywords rather than less restricted strings.
4435	As with link and protocol identifiers, additional clauses may be
4436	registered only by standardization or by way of an RFC-documented,
4437	IESG-approved, Experimental protocol extension. The additional
4438	clause name space is for identification and is not limited in
4439	size: the IESG is encouraged to approve on the basis of clear
4440	documentation, actual use or strong signs that the clause will be
4441	used, and a distinct requirement rather than preferences about the
4442	properties of the clause itself.
4443
4444	In addition, if additional trace header fields (i.e., in addition to
4445	Return-path and Received) are ever created, those trace fields MUST
4446	be added to the IANA registry established by BCP 90 (RFC 3864) [11]
4447	for use with RFC 5322 [4].
4448
4449	9. Acknowledgments
4450
4451	Many people contributed to the development of RFC 2821. That
4452	document should be consulted for those acknowledgments. For the
4453	present document, the editor and the community owe thanks to Dawn
4454	Mann and Tony Hansen who assisted in the very painful process of
4455	editing and converting the internal format of the document from one
4456	system to another.
4457
4458	Neither this document nor RFC 2821 would have been possible without
4459	the many contribution and insights of the late Jon Postel. Those
4460	contributions of course include the original specification of SMTP in
4461	RFC 821. A considerable quantity of text from RFC 821 still appears
4462	in this document as do several of Jon's original examples that have
4463	been updated only as needed to reflect other changes in the
4464	specification.
4465
4466	Many people made comments or suggestions on the mailing list or in
4467	notes to the author. Important corrections or clarifications were
4468	suggested by several people, including Matti Aarnio, Glenn Anderson,
4469	Derek J. Balling, Alex van den Bogaerdt, Stephane Bortzmeyer, Vint
4470	Cerf, Jutta Degener, Steve Dorner, Lisa Dusseault, Frank Ellerman,
4471	Ned Freed, Randy Gellens, Sabahattin Gucukoglu, Philip Guenther, Arnt
4472	Gulbrandsen, Eric Hall, Richard O. Hammer, Tony Hansen, Peter J.
4473	Holzer, Kari Hurtta, Bryon Roche Kain, Valdis Kletnieks, Mathias
4474	Koerber, John Leslie, Bruce Lilly, Jeff Macdonald, Mark E. Mallett,
4475	Mark Martinec, S. Moonesamy, Lyndon Nerenberg, Chris Newman, Douglas
4476	Otis, Pete Resnick, Robert A. Rosenberg, Vince Sabio, Hector Santos,
4477	David F. Skoll, Paul Smith, and Brett Watson.
4478
4479
4480
4481
4482	Klensin Standards Track [Page 80]
4483
4484	RFC 5321 SMTP October 2008
4485
4486
4487	The efforts of the Area Directors -- Lisa Dusseault, Ted Hardie, and
4488	Chris Newman -- to get this effort restarted and keep it moving, and
4489	of an ad hoc committee with the same purpose, are gratefully
4490	acknowledged. The members of that committee were (in alphabetical
4491	order) Dave Crocker, Cyrus Daboo, Tony Finch, Ned Freed, Randall
4492	Gellens, Tony Hansen, the author, and Alexey Melnikov. Tony Hansen
4493	also acted as ad hoc chair on the mailing list reviewing this
4494	document; without his efforts, sense of balance and fairness, and
4495	patience, it clearly would not have been possible.
4496
4497	10. References
4498
4499	10.1. Normative References
4500
4501	[1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
4502	August 1982.
4503
4504	[2] Mockapetris, P., "Domain names - implementation and
4505	specification", STD 13, RFC 1035, November 1987.
4506
4507	[3] Braden, R., "Requirements for Internet Hosts - Application and
4508	Support", STD 3, RFC 1123, October 1989.
4509
4510	[4] Resnick, P., "Internet Message Format", RFC 5322, October 2008.
4511
4512	[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
4513	Levels", BCP 14, RFC 2119, March 1997.
4514
4515	[6] American National Standards Institute (formerly United States
4516	of America Standards Institute), "USA Code for Information
4517	Interchange", ANSI X3.4-1968, 1968.
4518
4519	ANSI X3.4-1968 has been replaced by newer versions with slight
4520	modifications, but the 1968 version remains definitive for the
4521	Internet.
4522
4523	[7] Crocker, D. and P. Overell, "Augmented BNF for Syntax
4524	Specifications: ABNF", STD 68, RFC 5234, January 2008.
4525
4526	[8] Hinden, R. and S. Deering, "IP Version 6 Addressing
4527	Architecture", RFC 4291, February 2006.
4528
4529	[9] Newman, C., "ESMTP and LMTP Transmission Types Registration",
4530	RFC 3848, July 2004.
4531
4532	[10] Klensin, J., Freed, N., and K. Moore, "SMTP Service Extension
4533	for Message Size Declaration", STD 10, RFC 1870, November 1995.
4534
4535
4536
4537
4538	Klensin Standards Track [Page 81]
4539
4540	RFC 5321 SMTP October 2008
4541
4542
4543	[11] Klyne, G., Nottingham, M., and J. Mogul, "Registration
4544	Procedures for Message Header Fields", BCP 90, RFC 3864,
4545	September 2004.
4546
4547	10.2. Informative References
4548
4549	[12] Partridge, C., "Mail routing and the domain system", RFC 974,
4550	January 1986.
4551
4552	[13] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D.
4553	Crocker, "SMTP Service Extensions", STD 10, RFC 1869,
4554	November 1995.
4555
4556	[14] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
4557	April 2001.
4558
4559	[15] Butler, M., Postel, J., Chase, D., Goldberger, J., and J.
4560	Reynolds, "Post Office Protocol: Version 2", RFC 937,
4561	February 1985.
4562
4563	[16] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
4564	STD 53, RFC 1939, May 1996.
4565
4566	[17] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4567	4rev1", RFC 3501, March 2003.
4568
4569	[18] Gellens, R. and J. Klensin, "Message Submission for Mail",
4570	RFC 4409, April 2006.
4571
4572	[19] Freed, N., "SMTP Service Extension for Command Pipelining",
4573	STD 60, RFC 2920, September 2000.
4574
4575	[20] Vaudreuil, G., "SMTP Service Extensions for Transmission of
4576	Large and Binary MIME Messages", RFC 3030, December 2000.
4577
4578	[21] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
4579	Extensions (MIME) Part One: Format of Internet Message Bodies",
4580	RFC 2045, November 1996.
4581
4582	[22] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D.
4583	Crocker, "SMTP Service Extension for 8bit-MIMEtransport",
4584	RFC 1652, July 1994.
4585
4586	[23] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part
4587	Three: Message Header Extensions for Non-ASCII Text", RFC 2047,
4588	November 1996.
4589
4590
4591
4592
4593
4594	Klensin Standards Track [Page 82]
4595
4596	RFC 5321 SMTP October 2008
4597
4598
4599	[24] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word
4600	Extensions: Character Sets, Languages, and Continuations",
4601	RFC 2231, November 1997.
4602
4603	[25] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463,
4604	January 2003.
4605
4606	[26] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced Mail
4607	System Status Codes", BCP 138, RFC 5248, June 2008.
4608
4609	[27] Freed, N., "Behavior of and Requirements for Internet
4610	Firewalls", RFC 2979, October 2000.
4611
4612	[28] Crocker, D., "Standard for the format of ARPA Internet text
4613	messages", STD 11, RFC 822, August 1982.
4614
4615	[29] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) for
4616	Authorizing Use of Domains in E-Mail, Version 1", RFC 4408,
4617	April 2006.
4618
4619	[30] Fenton, J., "Analysis of Threats Motivating DomainKeys
4620	Identified Mail (DKIM)", RFC 4686, September 2006.
4621
4622	[31] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and
4623	M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures",
4624	RFC 4871, May 2007.
4625
4626	[32] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
4627	Extension for Delivery Status Notifications (DSNs)", RFC 3461,
4628	January 2003.
4629
4630	[33] Moore, K. and G. Vaudreuil, "An Extensible Message Format for
4631	Delivery Status Notifications", RFC 3464, January 2003.
4632
4633	[34] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9,
4634	RFC 959, October 1985.
4635
4636	[35] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping
4637	between X.400 and RFC 822/MIME", RFC 2156, January 1998.
4638
4639	[36] De Winter, J., "SMTP Service Extension for Remote Message Queue
4640	Starting", RFC 1985, August 1996.
4641
4642	[37] Hansen, T. and G. Vaudreuil, "Message Disposition
4643	Notification", RFC 3798, May 2004.
4644
4645	[38] Elz, R. and R. Bush, "Clarifications to the DNS Specification",
4646	RFC 2181, July 1997.
4647
4648
4649
4650	Klensin Standards Track [Page 83]
4651
4652	RFC 5321 SMTP October 2008
4653
4654
4655	[39] Nakamura, M. and J. Hagino, "SMTP Operational Experience in
4656	Mixed IPv4/v6 Environments", RFC 3974, January 2005.
4657
4658	[40] Partridge, C., "Duplicate messages and SMTP", RFC 1047,
4659	February 1988.
4660
4661	[41] Crispin, M., "Interactive Mail Access Protocol: Version 2",
4662	RFC 1176, August 1990.
4663
4664	[42] Lambert, M., "PCMAIL: A distributed mail system for personal
4665	computers", RFC 1056, June 1988.
4666
4667	[43] Galvin, J., Murphy, S., Crocker, S., and N. Freed, "Security
4668	Multiparts for MIME: Multipart/Signed and Multipart/Encrypted",
4669	RFC 1847, October 1995.
4670
4671	[44] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
4672	Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
4673
4674	[45] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
4675	(S/MIME) Version 3.1 Message Specification", RFC 3851,
4676	July 2004.
4677
4678	[46] Internet Assigned Number Authority (IANA), "IANA Mail
4679	Parameters", 2007,
4680	<http://www.iana.org/assignments/mail-parameters>.
4681
4682	[47] Internet Assigned Number Authority (IANA), "Address Literal
4683	Tags", 2007,
4684	<http://www.iana.org/assignments/address-literal-tags>.
4685
4686
4687
4688
4689
4690
4691
4692
4693
4694
4695
4696
4697
4698
4699
4700
4701
4702
4703
4704
4705
4706	Klensin Standards Track [Page 84]
4707
4708	RFC 5321 SMTP October 2008
4709
4710
4711	Appendix A. TCP Transport Service
4712
4713	The TCP connection supports the transmission of 8-bit bytes. The
4714	SMTP data is 7-bit ASCII characters. Each character is transmitted
4715	as an 8-bit byte with the high-order bit cleared to zero. Service
4716	extensions may modify this rule to permit transmission of full 8-bit
4717	data bytes as part of the message body, or, if specifically designed
4718	to do so, in SMTP commands or responses.
4719
4720	Appendix B. Generating SMTP Commands from RFC 822 Header Fields
4721
4722	Some systems use an RFC 822 header section (only) in a mail
4723	submission protocol, or otherwise generate SMTP commands from RFC 822
4724	header fields when such a message is handed to an MTA from a UA.
4725	While the MTA-UA protocol is a private matter, not covered by any
4726	Internet Standard, there are problems with this approach. For
4727	example, there have been repeated problems with proper handling of
4728	"bcc" copies and redistribution lists when information that
4729	conceptually belongs to the mail envelope is not separated early in
4730	processing from header field information (and kept separate).
4731
4732	It is recommended that the UA provide its initial ("submission
4733	client") MTA with an envelope separate from the message itself.
4734	However, if the envelope is not supplied, SMTP commands SHOULD be
4735	generated as follows:
4736
4737	1. Each recipient address from a TO, CC, or BCC header field SHOULD
4738	be copied to a RCPT command (generating multiple message copies
4739	if that is required for queuing or delivery). This includes any
4740	addresses listed in a RFC 822 "group". Any BCC header fields
4741	SHOULD then be removed from the header section. Once this
4742	process is completed, the remaining header fields SHOULD be
4743	checked to verify that at least one TO, CC, or BCC header field
4744	remains. If none do, then a BCC header field with no additional
4745	information SHOULD be inserted as specified in [4].
4746
4747	2. The return address in the MAIL command SHOULD, if possible, be
4748	derived from the system's identity for the submitting (local)
4749	user, and the "From:" header field otherwise. If there is a
4750	system identity available, it SHOULD also be copied to the Sender
4751	header field if it is different from the address in the From
4752	header field. (Any Sender header field that was already there
4753	SHOULD be removed.) Systems may provide a way for submitters to
4754	override the envelope return address, but may want to restrict
4755	its use to privileged users. This will not prevent mail forgery,
4756	but may lessen its incidence; see Section 7.1.
4757
4758
4759
4760
4761
4762	Klensin Standards Track [Page 85]
4763
4764	RFC 5321 SMTP October 2008
4765
4766
4767	When an MTA is being used in this way, it bears responsibility for
4768	ensuring that the message being transmitted is valid. The mechanisms
4769	for checking that validity, and for handling (or returning) messages
4770	that are not valid at the time of arrival, are part of the MUA-MTA
4771	interface and not covered by this specification.
4772
4773	A submission protocol based on Standard RFC 822 information alone
4774	MUST NOT be used to gateway a message from a foreign (non-SMTP) mail
4775	system into an SMTP environment. Additional information to construct
4776	an envelope must come from some source in the other environment,
4777	whether supplemental header fields or the foreign system's envelope.
4778
4779	Attempts to gateway messages using only their header "To" and "Cc"
4780	fields have repeatedly caused mail loops and other behavior adverse
4781	to the proper functioning of the Internet mail environment. These
4782	problems have been especially common when the message originates from
4783	an Internet mailing list and is distributed into the foreign
4784	environment using envelope information. When these messages are then
4785	processed by a header-section-only remailer, loops back to the
4786	Internet environment (and the mailing list) are almost inevitable.
4787
4788	Appendix C. Source Routes
4789
4790	Historically, the <reverse-path> was a reverse source routing list of
4791	hosts and a source mailbox. The first host in the <reverse-path> was
4792	historically the host sending the MAIL command; today, source routes
4793	SHOULD NOT appear in the reverse-path. Similarly, the <forward-path>
4794	may be a source routing lists of hosts and a destination mailbox.
4795	However, in general, the <forward-path> SHOULD contain only a mailbox
4796	and domain name, relying on the domain name system to supply routing
4797	information if required. The use of source routes is deprecated (see
4798	Appendix F.2); while servers MUST be prepared to receive and handle
4799	them as discussed in Section 3.3 and Appendix F.2, clients SHOULD NOT
4800	transmit them and this section is included in the current
4801	specification only to provide context. It has been modified somewhat
4802	from the material in RFC 821 to prevent server actions that might
4803	confuse clients or subsequent servers that do not expect a full
4804	source route implementation.
4805
4806	For relay purposes, the forward-path may be a source route of the
4807	form "@ONE,@TWO:JOE@THREE", where ONE, TWO, and THREE MUST be fully-
4808	qualified domain names. This form is used to emphasize the
4809	distinction between an address and a route. The mailbox (here, JOE@
4810	THREE) is an absolute address, and the route is information about how
4811	to get there. The two concepts should not be confused.
4812
4813	If source routes are used, RFC 821 and the text below should be
4814	consulted for the mechanisms for constructing and updating the
4815
4816
4817
4818	Klensin Standards Track [Page 86]
4819
4820	RFC 5321 SMTP October 2008
4821
4822
4823	forward-path. A server that is reached by means of a source route
4824	(e.g., its domain name appears first in the list in the forward-path)
4825	MUST remove its domain name from any forward-paths in which that
4826	domain name appears before forwarding the message and MAY remove all
4827	other source routing information. The reverse-path SHOULD NOT be
4828	updated by servers conforming to this specification.
4829
4830	Notice that the forward-path and reverse-path appear in the SMTP
4831	commands and replies, but not necessarily in the message. That is,
4832	there is no need for these paths and especially this syntax to appear
4833	in the "To:" , "From:", "CC:", etc. fields of the message header
4834	section. Conversely, SMTP servers MUST NOT derive final message
4835	routing information from message header fields.
4836
4837	When the list of hosts is present despite the recommendations above,
4838	it is a "reverse" source route and indicates that the mail was
4839	relayed through each host on the list (the first host in the list was
4840	the most recent relay). This list is used as a source route to
4841	return non-delivery notices to the sender. If, contrary to the
4842	recommendations here, a relay host adds itself to the beginning of
4843	the list, it MUST use its name as known in the transport environment
4844	to which it is relaying the mail rather than that of the transport
4845	environment from which the mail came (if they are different). Note
4846	that a situation could easily arise in which some relay hosts add
4847	their names to the reverse source route and others do not, generating
4848	discontinuities in the routing list. This is another reason why
4849	servers needing to return a message SHOULD ignore the source route
4850	entirely and simply use the domain as specified in the Mailbox.
4851
4852	Appendix D. Scenarios
4853
4854	This section presents complete scenarios of several types of SMTP
4855	sessions. In the examples, "C:" indicates what is said by the SMTP
4856	client, and "S:" indicates what is said by the SMTP server.
4857
4858
4859
4860
4861
4862
4863
4864
4865
4866
4867
4868
4869
4870
4871
4872
4873
4874	Klensin Standards Track [Page 87]
4875
4876	RFC 5321 SMTP October 2008
4877
4878
4879	D.1. A Typical SMTP Transaction Scenario
4880
4881	This SMTP example shows mail sent by Smith at host bar.com, and to
4882	Jones, Green, and Brown at host foo.com. Here we assume that host
4883	bar.com contacts host foo.com directly. The mail is accepted for
4884	Jones and Brown. Green does not have a mailbox at host foo.com.
4885
4886	S: 220 foo.com Simple Mail Transfer Service Ready
4887	C: EHLO bar.com
4888	S: 250-foo.com greets bar.com
4889	S: 250-8BITMIME
4890	S: 250-SIZE
4891	S: 250-DSN
4892	S: 250 HELP
4893	C: MAIL FROM:<Smith@bar.com>
4894	S: 250 OK
4895	C: RCPT TO:<Jones@foo.com>
4896	S: 250 OK
4897	C: RCPT TO:<Green@foo.com>
4898	S: 550 No such user here
4899	C: RCPT TO:<Brown@foo.com>
4900	S: 250 OK
4901	C: DATA
4902	S: 354 Start mail input; end with <CRLF>.<CRLF>
4903	C: Blah blah blah...
4904	C: ...etc. etc. etc.
4905	C: .
4906	S: 250 OK
4907	C: QUIT
4908	S: 221 foo.com Service closing transmission channel
4909
4910
4911
4912
4913
4914
4915
4916
4917
4918
4919
4920
4921
4922
4923
4924
4925
4926
4927
4928
4929
4930	Klensin Standards Track [Page 88]
4931
4932	RFC 5321 SMTP October 2008
4933
4934
4935	D.2. Aborted SMTP Transaction Scenario
4936
4937	S: 220 foo.com Simple Mail Transfer Service Ready
4938	C: EHLO bar.com
4939	S: 250-foo.com greets bar.com
4940	S: 250-8BITMIME
4941	S: 250-SIZE
4942	S: 250-DSN
4943	S: 250 HELP
4944	C: MAIL FROM:<Smith@bar.com>
4945	S: 250 OK
4946	C: RCPT TO:<Jones@foo.com>
4947	S: 250 OK
4948	C: RCPT TO:<Green@foo.com>
4949	S: 550 No such user here
4950	C: RSET
4951	S: 250 OK
4952	C: QUIT
4953	S: 221 foo.com Service closing transmission channel
4954
4955
4956
4957
4958
4959
4960
4961
4962
4963
4964
4965
4966
4967
4968
4969
4970
4971
4972
4973
4974
4975
4976
4977
4978
4979
4980
4981
4982
4983
4984
4985
4986	Klensin Standards Track [Page 89]
4987
4988	RFC 5321 SMTP October 2008
4989
4990
4991	D.3. Relayed Mail Scenario
4992
4993	Step 1 -- Source Host to Relay Host
4994
4995	The source host performs a DNS lookup on XYZ.COM (the destination
4996	address) and finds DNS MX records specifying xyz.com as the best
4997	preference and foo.com as a lower preference. It attempts to open a
4998	connection to xyz.com and fails. It then opens a connection to
4999	foo.com, with the following dialogue:
5000
5001	S: 220 foo.com Simple Mail Transfer Service Ready
5002	C: EHLO bar.com
5003	S: 250-foo.com greets bar.com
5004	S: 250-8BITMIME
5005	S: 250-SIZE
5006	S: 250-DSN
5007	S: 250 HELP
5008	C: MAIL FROM:<JQP@bar.com>
5009	S: 250 OK
5010	C: RCPT TO:<Jones@XYZ.COM>
5011	S: 250 OK
5012	C: DATA
5013	S: 354 Start mail input; end with <CRLF>.<CRLF>
5014	C: Date: Thu, 21 May 1998 05:33:29 -0700
5015	C: From: John Q. Public <JQP@bar.com>
5016	C: Subject: The Next Meeting of the Board
5017	C: To: Jones@xyz.com
5018	C:
5019	C: Bill:
5020	C: The next meeting of the board of directors will be
5021	C: on Tuesday.
5022	C: John.
5023	C: .
5024	S: 250 OK
5025	C: QUIT
5026	S: 221 foo.com Service closing transmission channel
5027
5028
5029
5030
5031
5032
5033
5034
5035
5036
5037
5038
5039
5040
5041
5042	Klensin Standards Track [Page 90]
5043
5044	RFC 5321 SMTP October 2008
5045
5046
5047	Step 2 -- Relay Host to Destination Host
5048
5049	foo.com, having received the message, now does a DNS lookup on
5050	xyz.com. It finds the same set of MX records, but cannot use the one
5051	that points to itself (or to any other host as a worse preference).
5052	It tries to open a connection to xyz.com itself and succeeds. Then
5053	we have:
5054
5055	S: 220 xyz.com Simple Mail Transfer Service Ready
5056	C: EHLO foo.com
5057	S: 250 xyz.com is on the air
5058	C: MAIL FROM:<JQP@bar.com>
5059	S: 250 OK
5060	C: RCPT TO:<Jones@XYZ.COM>
5061	S: 250 OK
5062	C: DATA
5063	S: 354 Start mail input; end with <CRLF>.<CRLF>
5064	C: Received: from bar.com by foo.com ; Thu, 21 May 1998
5065	C: 05:33:29 -0700
5066	C: Date: Thu, 21 May 1998 05:33:22 -0700
5067	C: From: John Q. Public <JQP@bar.com>
5068	C: Subject: The Next Meeting of the Board
5069	C: To: Jones@xyz.com
5070	C:
5071	C: Bill:
5072	C: The next meeting of the board of directors will be
5073	C: on Tuesday.
5074	C: John.
5075	C: .
5076	S: 250 OK
5077	C: QUIT
5078	S: 221 foo.com Service closing transmission channel
5079
5080
5081
5082
5083
5084
5085
5086
5087
5088
5089
5090
5091
5092
5093
5094
5095
5096
5097
5098	Klensin Standards Track [Page 91]
5099
5100	RFC 5321 SMTP October 2008
5101
5102
5103	D.4. Verifying and Sending Scenario
5104
5105	S: 220 foo.com Simple Mail Transfer Service Ready
5106	C: EHLO bar.com
5107	S: 250-foo.com greets bar.com
5108	S: 250-8BITMIME
5109	S: 250-SIZE
5110	S: 250-DSN
5111	S: 250-VRFY
5112	S: 250 HELP
5113	C: VRFY Crispin
5114	S: 250 Mark Crispin <Admin.MRC@foo.com>
5115	C: MAIL FROM:<EAK@bar.com>
5116	S: 250 OK
5117	C: RCPT TO:<Admin.MRC@foo.com>
5118	S: 250 OK
5119	C: DATA
5120	S: 354 Start mail input; end with <CRLF>.<CRLF>
5121	C: Blah blah blah...
5122	C: ...etc. etc. etc.
5123	C: .
5124	S: 250 OK
5125	C: QUIT
5126	S: 221 foo.com Service closing transmission channel
5127
5128	Appendix E. Other Gateway Issues
5129
5130	In general, gateways between the Internet and other mail systems
5131	SHOULD attempt to preserve any layering semantics across the
5132	boundaries between the two mail systems involved. Gateway-
5133	translation approaches that attempt to take shortcuts by mapping
5134	(such as mapping envelope information from one system to the message
5135	header section or body of another) have generally proven to be
5136	inadequate in important ways. Systems translating between
5137	environments that do not support both envelopes and a header section
5138	and Internet mail must be written with the understanding that some
5139	information loss is almost inevitable.
5140
5141
5142
5143
5144
5145
5146
5147
5148
5149
5150
5151
5152
5153
5154	Klensin Standards Track [Page 92]
5155
5156	RFC 5321 SMTP October 2008
5157
5158
5159	Appendix F. Deprecated Features of RFC 821
5160
5161	A few features of RFC 821 have proven to be problematic and SHOULD
5162	NOT be used in Internet mail.
5163
5164	F.1. TURN
5165
5166	This command, described in RFC 821, raises important security issues
5167	since, in the absence of strong authentication of the host requesting
5168	that the client and server switch roles, it can easily be used to
5169	divert mail from its correct destination. Its use is deprecated;
5170	SMTP systems SHOULD NOT use it unless the server can authenticate the
5171	client.
5172
5173	F.2. Source Routing
5174
5175	RFC 821 utilized the concept of explicit source routing to get mail
5176	from one host to another via a series of relays. The requirement to
5177	utilize source routes in regular mail traffic was eliminated by the
5178	introduction of the domain name system "MX" record and the last
5179	significant justification for them was eliminated by the
5180	introduction, in RFC 1123, of a clear requirement that addresses
5181	following an "@" must all be fully-qualified domain names.
5182	Consequently, the only remaining justifications for the use of source
5183	routes are support for very old SMTP clients or MUAs and in mail
5184	system debugging. They can, however, still be useful in the latter
5185	circumstance and for routing mail around serious, but temporary,
5186	problems such as problems with the relevant DNS records.
5187
5188	SMTP servers MUST continue to accept source route syntax as specified
5189	in the main body of this document and in RFC 1123. They MAY, if
5190	necessary, ignore the routes and utilize only the target domain in
5191	the address. If they do utilize the source route, the message MUST
5192	be sent to the first domain shown in the address. In particular, a
5193	server MUST NOT guess at shortcuts within the source route.
5194
5195	Clients SHOULD NOT utilize explicit source routing except under
5196	unusual circumstances, such as debugging or potentially relaying
5197	around firewall or mail system configuration errors.
5198
5199	F.3. HELO
5200
5201	As discussed in Sections 3.1 and 4.1.1, EHLO SHOULD be used rather
5202	than HELO when the server will accept the former. Servers MUST
5203	continue to accept and process HELO in order to support older
5204	clients.
5205
5206
5207
5208
5209
5210	Klensin Standards Track [Page 93]
5211
5212	RFC 5321 SMTP October 2008
5213
5214
5215	F.4. #-literals
5216
5217	RFC 821 provided for specifying an Internet address as a decimal
5218	integer host number prefixed by a pound sign, "#". In practice, that
5219	form has been obsolete since the introduction of TCP/IP. It is
5220	deprecated and MUST NOT be used.
5221
5222	F.5. Dates and Years
5223
5224	When dates are inserted into messages by SMTP clients or servers
5225	(e.g., in trace header fields), four-digit years MUST BE used. Two-
5226	digit years are deprecated; three-digit years were never permitted in
5227	the Internet mail system.
5228
5229	F.6. Sending versus Mailing
5230
5231	In addition to specifying a mechanism for delivering messages to
5232	user's mailboxes, RFC 821 provided additional, optional, commands to
5233	deliver messages directly to the user's terminal screen. These
5234	commands (SEND, SAML, SOML) were rarely implemented, and changes in
5235	workstation technology and the introduction of other protocols may
5236	have rendered them obsolete even where they are implemented.
5237
5238	Clients SHOULD NOT provide SEND, SAML, or SOML as services. Servers
5239	MAY implement them. If they are implemented by servers, the
5240	implementation model specified in RFC 821 MUST be used and the
5241	command names MUST be published in the response to the EHLO command.
5242
5243	Author's Address
5244
5245	John C. Klensin
5246	1770 Massachusetts Ave, Suite 322
5247	Cambridge, MA 02140
5248	USA
5249
5250	EMail: john+smtp@jck.com
5251
5252
5253
5254
5255
5256
5257
5258
5259
5260
5261
5262
5263
5264
5265
5266	Klensin Standards Track [Page 94]
5267
5268	RFC 5321 SMTP October 2008
5269
5270
5271	Full Copyright Statement
5272
5273	Copyright (C) The IETF Trust (2008).
5274
5275	This document is subject to the rights, licenses and restrictions
5276	contained in BCP 78, and except as set forth therein, the authors
5277	retain all their rights.
5278
5279	This document and the information contained herein are provided on an
5280	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
5281	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
5282	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
5283	OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
5284	THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
5285	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
5286
5287	Intellectual Property
5288
5289	The IETF takes no position regarding the validity or scope of any
5290	Intellectual Property Rights or other rights that might be claimed to
5291	pertain to the implementation or use of the technology described in
5292	this document or the extent to which any license under such rights
5293	might or might not be available; nor does it represent that it has
5294	made any independent effort to identify any such rights. Information
5295	on the procedures with respect to rights in RFC documents can be
5296	found in BCP 78 and BCP 79.
5297
5298	Copies of IPR disclosures made to the IETF Secretariat and any
5299	assurances of licenses to be made available, or the result of an
5300	attempt made to obtain a general license or permission for the use of
5301	such proprietary rights by implementers or users of this
5302	specification can be obtained from the IETF on-line IPR repository at
5303	http://www.ietf.org/ipr.
5304
5305	The IETF invites any interested party to bring to its attention any
5306	copyrights, patents or patent applications, or other proprietary
5307	rights that may cover technology that may be required to implement
5308	this standard. Please address the information to the IETF at
5309	ietf-ipr@ietf.org.
5310
5311
5312
5313
5314
5315
5316
5317
5318
5319
5320
5321
5322	Klensin Standards Track [Page 95]
5323