Document tunnel command's environment variables
[claws.git] / doc / src / rfc2821.txt
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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 \f
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