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