doc: Add RFC documents

1 files changed, 5323 insertions, 0 deletions

diff --git a/doc/rfc/rfc5321.txt b/doc/rfc/rfc5321.txt
new file mode 100644
index 0000000..4c33ddd
--- /dev/null
+++ b/doc/rfc/rfc5321.txt
@@ -0,0 +1,5323 @@
+
+
+
+
+
+
+Network Working Group                                         J. Klensin
+Request for Comments: 5321                                  October 2008
+Obsoletes: 2821
+Updates: 1123
+Category: Standards Track
+
+
+                     Simple Mail Transfer Protocol
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Abstract
+
+   This document is a specification of the basic protocol for Internet
+   electronic mail transport.  It consolidates, updates, and clarifies
+   several previous documents, making all or parts of most of them
+   obsolete.  It covers the SMTP extension mechanisms and best practices
+   for the contemporary Internet, but does not provide details about
+   particular extensions.  Although SMTP was designed as a mail
+   transport and delivery protocol, this specification also contains
+   information that is important to its use as a "mail submission"
+   protocol for "split-UA" (User Agent) mail reading systems and mobile
+   environments.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klensin                     Standards Track                     [Page 1]
+
+RFC 5321                          SMTP                      October 2008
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
+     1.1.  Transport of Electronic Mail . . . . . . . . . . . . . . .  5
+     1.2.  History and Context for This Document  . . . . . . . . . .  5
+     1.3.  Document Conventions . . . . . . . . . . . . . . . . . . .  6
+   2.  The SMTP Model . . . . . . . . . . . . . . . . . . . . . . . .  7
+     2.1.  Basic Structure  . . . . . . . . . . . . . . . . . . . . .  7
+     2.2.  The Extension Model  . . . . . . . . . . . . . . . . . . .  9
+       2.2.1.  Background . . . . . . . . . . . . . . . . . . . . . .  9
+       2.2.2.  Definition and Registration of Extensions  . . . . . . 10
+       2.2.3.  Special Issues with Extensions . . . . . . . . . . . . 11
+     2.3.  SMTP Terminology . . . . . . . . . . . . . . . . . . . . . 11
+       2.3.1.  Mail Objects . . . . . . . . . . . . . . . . . . . . . 11
+       2.3.2.  Senders and Receivers  . . . . . . . . . . . . . . . . 12
+       2.3.3.  Mail Agents and Message Stores . . . . . . . . . . . . 12
+       2.3.4.  Host . . . . . . . . . . . . . . . . . . . . . . . . . 13
+       2.3.5.  Domain Names . . . . . . . . . . . . . . . . . . . . . 13
+       2.3.6.  Buffer and State Table . . . . . . . . . . . . . . . . 14
+       2.3.7.  Commands and Replies . . . . . . . . . . . . . . . . . 14
+       2.3.8.  Lines  . . . . . . . . . . . . . . . . . . . . . . . . 14
+       2.3.9.  Message Content and Mail Data  . . . . . . . . . . . . 15
+       2.3.10. Originator, Delivery, Relay, and Gateway Systems . . . 15
+       2.3.11. Mailbox and Address  . . . . . . . . . . . . . . . . . 15
+     2.4.  General Syntax Principles and Transaction Model  . . . . . 16
+   3.  The SMTP Procedures: An Overview . . . . . . . . . . . . . . . 17
+     3.1.  Session Initiation . . . . . . . . . . . . . . . . . . . . 18
+     3.2.  Client Initiation  . . . . . . . . . . . . . . . . . . . . 18
+     3.3.  Mail Transactions  . . . . . . . . . . . . . . . . . . . . 19
+     3.4.  Forwarding for Address Correction or Updating  . . . . . . 21
+     3.5.  Commands for Debugging Addresses . . . . . . . . . . . . . 22
+       3.5.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . 22
+       3.5.2.  VRFY Normal Response . . . . . . . . . . . . . . . . . 24
+       3.5.3.  Meaning of VRFY or EXPN Success Response . . . . . . . 25
+       3.5.4.  Semantics and Applications of EXPN . . . . . . . . . . 26
+     3.6.  Relaying and Mail Routing  . . . . . . . . . . . . . . . . 26
+       3.6.1.  Source Routes and Relaying . . . . . . . . . . . . . . 26
+       3.6.2.  Mail eXchange Records and Relaying . . . . . . . . . . 26
+       3.6.3.  Message Submission Servers as Relays . . . . . . . . . 27
+     3.7.  Mail Gatewaying  . . . . . . . . . . . . . . . . . . . . . 28
+       3.7.1.  Header Fields in Gatewaying  . . . . . . . . . . . . . 28
+       3.7.2.  Received Lines in Gatewaying . . . . . . . . . . . . . 29
+       3.7.3.  Addresses in Gatewaying  . . . . . . . . . . . . . . . 29
+       3.7.4.  Other Header Fields in Gatewaying  . . . . . . . . . . 29
+       3.7.5.  Envelopes in Gatewaying  . . . . . . . . . . . . . . . 30
+     3.8.  Terminating Sessions and Connections . . . . . . . . . . . 30
+     3.9.  Mailing Lists and Aliases  . . . . . . . . . . . . . . . . 31
+       3.9.1.  Alias  . . . . . . . . . . . . . . . . . . . . . . . . 31
+
+
+
+Klensin                     Standards Track                     [Page 2]
+
+RFC 5321                          SMTP                      October 2008
+
+
+       3.9.2.  List . . . . . . . . . . . . . . . . . . . . . . . . . 31
+   4.  The SMTP Specifications  . . . . . . . . . . . . . . . . . . . 32
+     4.1.  SMTP Commands  . . . . . . . . . . . . . . . . . . . . . . 32
+       4.1.1.  Command Semantics and Syntax . . . . . . . . . . . . . 32
+       4.1.2.  Command Argument Syntax  . . . . . . . . . . . . . . . 41
+       4.1.3.  Address Literals . . . . . . . . . . . . . . . . . . . 43
+       4.1.4.  Order of Commands  . . . . . . . . . . . . . . . . . . 44
+       4.1.5.  Private-Use Commands . . . . . . . . . . . . . . . . . 46
+     4.2.  SMTP Replies . . . . . . . . . . . . . . . . . . . . . . . 46
+       4.2.1.  Reply Code Severities and Theory . . . . . . . . . . . 48
+       4.2.2.  Reply Codes by Function Groups . . . . . . . . . . . . 50
+       4.2.3.  Reply Codes in Numeric Order . . . . . . . . . . . . . 52
+       4.2.4.  Reply Code 502 . . . . . . . . . . . . . . . . . . . . 53
+       4.2.5.  Reply Codes after DATA and the Subsequent
+               <CRLF>.<CRLF>  . . . . . . . . . . . . . . . . . . . . 53
+     4.3.  Sequencing of Commands and Replies . . . . . . . . . . . . 54
+       4.3.1.  Sequencing Overview  . . . . . . . . . . . . . . . . . 54
+       4.3.2.  Command-Reply Sequences  . . . . . . . . . . . . . . . 55
+     4.4.  Trace Information  . . . . . . . . . . . . . . . . . . . . 57
+     4.5.  Additional Implementation Issues . . . . . . . . . . . . . 61
+       4.5.1.  Minimum Implementation . . . . . . . . . . . . . . . . 61
+       4.5.2.  Transparency . . . . . . . . . . . . . . . . . . . . . 62
+       4.5.3.  Sizes and Timeouts . . . . . . . . . . . . . . . . . . 62
+         4.5.3.1.  Size Limits and Minimums . . . . . . . . . . . . . 62
+           4.5.3.1.1.  Local-part . . . . . . . . . . . . . . . . . . 63
+           4.5.3.1.2.  Domain . . . . . . . . . . . . . . . . . . . . 63
+           4.5.3.1.3.  Path . . . . . . . . . . . . . . . . . . . . . 63
+           4.5.3.1.4.  Command Line . . . . . . . . . . . . . . . . . 63
+           4.5.3.1.5.  Reply Line . . . . . . . . . . . . . . . . . . 63
+           4.5.3.1.6.  Text Line  . . . . . . . . . . . . . . . . . . 63
+           4.5.3.1.7.  Message Content  . . . . . . . . . . . . . . . 63
+           4.5.3.1.8.  Recipients Buffer  . . . . . . . . . . . . . . 64
+           4.5.3.1.9.  Treatment When Limits Exceeded . . . . . . . . 64
+           4.5.3.1.10. Too Many Recipients Code . . . . . . . . . . . 64
+         4.5.3.2.  Timeouts . . . . . . . . . . . . . . . . . . . . . 65
+           4.5.3.2.1.  Initial 220 Message: 5 Minutes . . . . . . . . 65
+           4.5.3.2.2.  MAIL Command: 5 Minutes  . . . . . . . . . . . 65
+           4.5.3.2.3.  RCPT Command: 5 Minutes  . . . . . . . . . . . 65
+           4.5.3.2.4.  DATA Initiation: 2 Minutes . . . . . . . . . . 66
+           4.5.3.2.5.  Data Block: 3 Minutes  . . . . . . . . . . . . 66
+           4.5.3.2.6.  DATA Termination: 10 Minutes.  . . . . . . . . 66
+           4.5.3.2.7.  Server Timeout: 5 Minutes. . . . . . . . . . . 66
+       4.5.4.  Retry Strategies . . . . . . . . . . . . . . . . . . . 66
+       4.5.5.  Messages with a Null Reverse-Path  . . . . . . . . . . 68
+   5.  Address Resolution and Mail Handling . . . . . . . . . . . . . 69
+     5.1.  Locating the Target Host . . . . . . . . . . . . . . . . . 69
+     5.2.  IPv6 and MX Records  . . . . . . . . . . . . . . . . . . . 71
+   6.  Problem Detection and Handling . . . . . . . . . . . . . . . . 71
+
+
+
+Klensin                     Standards Track                     [Page 3]
+
+RFC 5321                          SMTP                      October 2008
+
+
+     6.1.  Reliable Delivery and Replies by Email . . . . . . . . . . 71
+     6.2.  Unwanted, Unsolicited, and "Attack" Messages . . . . . . . 72
+     6.3.  Loop Detection . . . . . . . . . . . . . . . . . . . . . . 73
+     6.4.  Compensating for Irregularities  . . . . . . . . . . . . . 73
+   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 75
+     7.1.  Mail Security and Spoofing . . . . . . . . . . . . . . . . 75
+     7.2.  "Blind" Copies . . . . . . . . . . . . . . . . . . . . . . 76
+     7.3.  VRFY, EXPN, and Security . . . . . . . . . . . . . . . . . 76
+     7.4.  Mail Rerouting Based on the 251 and 551 Response Codes . . 77
+     7.5.  Information Disclosure in Announcements  . . . . . . . . . 77
+     7.6.  Information Disclosure in Trace Fields . . . . . . . . . . 78
+     7.7.  Information Disclosure in Message Forwarding . . . . . . . 78
+     7.8.  Resistance to Attacks  . . . . . . . . . . . . . . . . . . 78
+     7.9.  Scope of Operation of SMTP Servers . . . . . . . . . . . . 78
+   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 79
+   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 80
+   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 81
+     10.1. Normative References . . . . . . . . . . . . . . . . . . . 81
+     10.2. Informative References . . . . . . . . . . . . . . . . . . 82
+   Appendix A.  TCP Transport Service . . . . . . . . . . . . . . . . 85
+   Appendix B.  Generating SMTP Commands from RFC 822 Header
+                Fields  . . . . . . . . . . . . . . . . . . . . . . . 85
+   Appendix C.  Source Routes . . . . . . . . . . . . . . . . . . . . 86
+   Appendix D.  Scenarios . . . . . . . . . . . . . . . . . . . . . . 87
+     D.1.  A Typical SMTP Transaction Scenario  . . . . . . . . . . . 88
+     D.2.  Aborted SMTP Transaction Scenario  . . . . . . . . . . . . 89
+     D.3.  Relayed Mail Scenario  . . . . . . . . . . . . . . . . . . 90
+     D.4.  Verifying and Sending Scenario . . . . . . . . . . . . . . 92
+   Appendix E.  Other Gateway Issues  . . . . . . . . . . . . . . . . 92
+   Appendix F.  Deprecated Features of RFC 821  . . . . . . . . . . . 93
+     F.1.  TURN . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
+     F.2.  Source Routing . . . . . . . . . . . . . . . . . . . . . . 93
+     F.3.  HELO . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
+     F.4.  #-literals . . . . . . . . . . . . . . . . . . . . . . . . 94
+     F.5.  Dates and Years  . . . . . . . . . . . . . . . . . . . . . 94
+     F.6.  Sending versus Mailing . . . . . . . . . . . . . . . . . . 94
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klensin                     Standards Track                     [Page 4]
+
+RFC 5321                          SMTP                      October 2008
+
+
+1.  Introduction
+
+1.1.  Transport of Electronic Mail
+
+   The objective of the Simple Mail Transfer Protocol (SMTP) is to
+   transfer mail reliably and efficiently.
+
+   SMTP is independent of the particular transmission subsystem and
+   requires only a reliable ordered data stream channel.  While this
+   document specifically discusses transport over TCP, other transports
+   are possible.  Appendices to RFC 821 [1] describe some of them.
+
+   An important feature of SMTP is its capability to transport mail
+   across multiple networks, usually referred to as "SMTP mail relaying"
+   (see Section 3.6).  A network consists of the mutually-TCP-accessible
+   hosts on the public Internet, the mutually-TCP-accessible hosts on a
+   firewall-isolated TCP/IP Intranet, or hosts in some other LAN or WAN
+   environment utilizing a non-TCP transport-level protocol.  Using
+   SMTP, a process can transfer mail to another process on the same
+   network or to some other network via a relay or gateway process
+   accessible to both networks.
+
+   In this way, a mail message may pass through a number of intermediate
+   relay or gateway hosts on its path from sender to ultimate recipient.
+   The Mail eXchanger mechanisms of the domain name system (RFC 1035
+   [2], RFC 974 [12], and Section 5 of this document) are used to
+   identify the appropriate next-hop destination for a message being
+   transported.
+
+1.2.  History and Context for This Document
+
+   This document is a specification of the basic protocol for the
+   Internet electronic mail transport.  It consolidates, updates and
+   clarifies, but does not add new or change existing functionality of
+   the following:
+
+   o  the original SMTP (Simple Mail Transfer Protocol) specification of
+      RFC 821 [1],
+
+   o  domain name system requirements and implications for mail
+      transport from RFC 1035 [2] and RFC 974 [12],
+
+   o  the clarifications and applicability statements in RFC 1123 [3],
+      and
+
+   o  material drawn from the SMTP Extension mechanisms in RFC 1869
+      [13].
+
+
+
+
+Klensin                     Standards Track                     [Page 5]
+
+RFC 5321                          SMTP                      October 2008
+
+
+   o  Editorial and clarification changes to RFC 2821 [14] to bring that
+      specification to Draft Standard.
+
+   It obsoletes RFC 821, RFC 974, RFC 1869, and RFC 2821 and updates RFC
+   1123 (replacing the mail transport materials of RFC 1123).  However,
+   RFC 821 specifies some features that were not in significant use in
+   the Internet by the mid-1990s and (in appendices) some additional
+   transport models.  Those sections are omitted here in the interest of
+   clarity and brevity; readers needing them should refer to RFC 821.
+
+   It also includes some additional material from RFC 1123 that required
+   amplification.  This material has been identified in multiple ways,
+   mostly by tracking flaming on various lists and newsgroups and
+   problems of unusual readings or interpretations that have appeared as
+   the SMTP extensions have been deployed.  Where this specification
+   moves beyond consolidation and actually differs from earlier
+   documents, it supersedes them technically as well as textually.
+
+   Although SMTP was designed as a mail transport and delivery protocol,
+   this specification also contains information that is important to its
+   use as a "mail submission" protocol, as recommended for Post Office
+   Protocol (POP) (RFC 937 [15], RFC 1939 [16]) and IMAP (RFC 3501
+   [17]).  In general, the separate mail submission protocol specified
+   in RFC 4409 [18] is now preferred to direct use of SMTP; more
+   discussion of that subject appears in that document.
+
+   Section 2.3 provides definitions of terms specific to this document.
+   Except when the historical terminology is necessary for clarity, this
+   document uses the current 'client' and 'server' terminology to
+   identify the sending and receiving SMTP processes, respectively.
+
+   A companion document, RFC 5322 [4], discusses message header sections
+   and bodies and specifies formats and structures for them.
+
+1.3.  Document Conventions
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [5].  As each
+   of these terms was intentionally and carefully chosen to improve the
+   interoperability of email, each use of these terms is to be treated
+   as a conformance requirement.
+
+   Because this document has a long history and to avoid the risk of
+   various errors and of confusing readers and documents that point to
+   this one, most examples and the domain names they contain are
+   preserved from RFC 2821.  Readers are cautioned that these are
+
+
+
+
+Klensin                     Standards Track                     [Page 6]
+
+RFC 5321                          SMTP                      October 2008
+
+
+   illustrative examples that should not actually be used in either code
+   or configuration files.
+
+2.  The SMTP Model
+
+2.1.  Basic Structure
+
+   The SMTP design can be pictured as:
+
+                  +----------+                +----------+
+      +------+    |          |                |          |
+      | User |<-->|          |      SMTP      |          |
+      +------+    |  Client- |Commands/Replies| Server-  |
+      +------+    |   SMTP   |<-------------->|    SMTP  |    +------+
+      | File |<-->|          |    and Mail    |          |<-->| File |
+      |System|    |          |                |          |    |System|
+      +------+    +----------+                +----------+    +------+
+                   SMTP client                SMTP server
+
+   When an SMTP client has a message to transmit, it establishes a two-
+   way transmission channel to an SMTP server.  The responsibility of an
+   SMTP client is to transfer mail messages to one or more SMTP servers,
+   or report its failure to do so.
+
+   The means by which a mail message is presented to an SMTP client, and
+   how that client determines the identifier(s) ("names") of the
+   domain(s) to which mail messages are to be transferred, is a local
+   matter, and is not addressed by this document.  In some cases, the
+   designated domain(s), or those determined by an SMTP client, will
+   identify the final destination(s) of the mail message.  In other
+   cases, common with SMTP clients associated with implementations of
+   the POP (RFC 937 [15], RFC 1939 [16]) or IMAP (RFC 3501 [17])
+   protocols, or when the SMTP client is inside an isolated transport
+   service environment, the domain determined will identify an
+   intermediate destination through which all mail messages are to be
+   relayed.  SMTP clients that transfer all traffic regardless of the
+   target domains associated with the individual messages, or that do
+   not maintain queues for retrying message transmissions that initially
+   cannot be completed, may otherwise conform to this specification but
+   are not considered fully-capable.  Fully-capable SMTP
+   implementations, including the relays used by these less capable
+   ones, and their destinations, are expected to support all of the
+   queuing, retrying, and alternate address functions discussed in this
+   specification.  In many situations and configurations, the less-
+   capable clients discussed above SHOULD be using the message
+   submission protocol (RFC 4409 [18]) rather than SMTP.
+
+
+
+
+
+Klensin                     Standards Track                     [Page 7]
+
+RFC 5321                          SMTP                      October 2008
+
+
+   The means by which an SMTP client, once it has determined a target
+   domain, determines the identity of an SMTP server to which a copy of
+   a message is to be transferred, and then performs that transfer, is
+   covered by this document.  To effect a mail transfer to an SMTP
+   server, an SMTP client establishes a two-way transmission channel to
+   that SMTP server.  An SMTP client determines the address of an
+   appropriate host running an SMTP server by resolving a destination
+   domain name to either an intermediate Mail eXchanger host or a final
+   target host.
+
+   An SMTP server may be either the ultimate destination or an
+   intermediate "relay" (that is, it may assume the role of an SMTP
+   client after receiving the message) or "gateway" (that is, it may
+   transport the message further using some protocol other than SMTP).
+   SMTP commands are generated by the SMTP client and sent to the SMTP
+   server.  SMTP replies are sent from the SMTP server to the SMTP
+   client in response to the commands.
+
+   In other words, message transfer can occur in a single connection
+   between the original SMTP-sender and the final SMTP-recipient, or can
+   occur in a series of hops through intermediary systems.  In either
+   case, once the server has issued a success response at the end of the
+   mail data, a formal handoff of responsibility for the message occurs:
+   the protocol requires that a server MUST accept responsibility for
+   either delivering the message or properly reporting the failure to do
+   so (see Sections 6.1, 6.2, and 7.8, below).
+
+   Once the transmission channel is established and initial handshaking
+   is completed, the SMTP client normally initiates a mail transaction.
+   Such a transaction consists of a series of commands to specify the
+   originator and destination of the mail and transmission of the
+   message content (including any lines in the header section or other
+   structure) itself.  When the same message is sent to multiple
+   recipients, this protocol encourages the transmission of only one
+   copy of the data for all recipients at the same destination (or
+   intermediate relay) host.
+
+   The server responds to each command with a reply; replies may
+   indicate that the command was accepted, that additional commands are
+   expected, or that a temporary or permanent error condition exists.
+   Commands specifying the sender or recipients may include server-
+   permitted SMTP service extension requests, as discussed in
+   Section 2.2.  The dialog is purposely lock-step, one-at-a-time,
+   although this can be modified by mutually agreed upon extension
+   requests such as command pipelining (RFC 2920 [19]).
+
+   Once a given mail message has been transmitted, the client may either
+   request that the connection be shut down or may initiate other mail
+
+
+
+Klensin                     Standards Track                     [Page 8]
+
+RFC 5321                          SMTP                      October 2008
+
+
+   transactions.  In addition, an SMTP client may use a connection to an
+   SMTP server for ancillary services such as verification of email
+   addresses or retrieval of mailing list subscriber addresses.
+
+   As suggested above, this protocol provides mechanisms for the
+   transmission of mail.  Historically, this transmission normally
+   occurred directly from the sending user's host to the receiving
+   user's host when the two hosts are connected to the same transport
+   service.  When they are not connected to the same transport service,
+   transmission occurs via one or more relay SMTP servers.  A very
+   common case in the Internet today involves submission of the original
+   message to an intermediate, "message submission" server, which is
+   similar to a relay but has some additional properties; such servers
+   are discussed in Section 2.3.10 and at some length in RFC 4409 [18].
+   An intermediate host that acts as either an SMTP relay or as a
+   gateway into some other transmission environment is usually selected
+   through the use of the domain name service (DNS) Mail eXchanger
+   mechanism.
+
+   Usually, intermediate hosts are determined via the DNS MX record, not
+   by explicit "source" routing (see Section 5 and Appendix C and
+   Appendix F.2).
+
+2.2.  The Extension Model
+
+2.2.1.  Background
+
+   In an effort that started in 1990, approximately a decade after RFC
+   821 was completed, the protocol was modified with a "service
+   extensions" model that permits the client and server to agree to
+   utilize shared functionality beyond the original SMTP requirements.
+   The SMTP extension mechanism defines a means whereby an extended SMTP
+   client and server may recognize each other, and the server can inform
+   the client as to the service extensions that it supports.
+
+   Contemporary SMTP implementations MUST support the basic extension
+   mechanisms.  For instance, servers MUST support the EHLO command even
+   if they do not implement any specific extensions and clients SHOULD
+   preferentially utilize EHLO rather than HELO.  (However, for
+   compatibility with older conforming implementations, SMTP clients and
+   servers MUST support the original HELO mechanisms as a fallback.)
+   Unless the different characteristics of HELO must be identified for
+   interoperability purposes, this document discusses only EHLO.
+
+   SMTP is widely deployed and high-quality implementations have proven
+   to be very robust.  However, the Internet community now considers
+   some services to be important that were not anticipated when the
+   protocol was first designed.  If support for those services is to be
+
+
+
+Klensin                     Standards Track                     [Page 9]
+
+RFC 5321                          SMTP                      October 2008
+
+
+   added, it must be done in a way that permits older implementations to
+   continue working acceptably.  The extension framework consists of:
+
+   o  The SMTP command EHLO, superseding the earlier HELO,
+
+   o  a registry of SMTP service extensions,
+
+   o  additional parameters to the SMTP MAIL and RCPT commands, and
+
+   o  optional replacements for commands defined in this protocol, such
+      as for DATA in non-ASCII transmissions (RFC 3030 [20]).
+
+   SMTP's strength comes primarily from its simplicity.  Experience with
+   many protocols has shown that protocols with few options tend towards
+   ubiquity, whereas protocols with many options tend towards obscurity.
+
+   Each and every extension, regardless of its benefits, must be
+   carefully scrutinized with respect to its implementation, deployment,
+   and interoperability costs.  In many cases, the cost of extending the
+   SMTP service will likely outweigh the benefit.
+
+2.2.2.  Definition and Registration of Extensions
+
+   The IANA maintains a registry of SMTP service extensions.  A
+   corresponding EHLO keyword value is associated with each extension.
+   Each service extension registered with the IANA must be defined in a
+   formal Standards-Track or IESG-approved Experimental protocol
+   document.  The definition must include:
+
+   o  the textual name of the SMTP service extension;
+
+   o  the EHLO keyword value associated with the extension;
+
+   o  the syntax and possible values of parameters associated with the
+      EHLO keyword value;
+
+   o  any additional SMTP verbs associated with the extension
+      (additional verbs will usually be, but are not required to be, the
+      same as the EHLO keyword value);
+
+   o  any new parameters the extension associates with the MAIL or RCPT
+      verbs;
+
+   o  a description of how support for the extension affects the
+      behavior of a server and client SMTP; and
+
+
+
+
+
+
+Klensin                     Standards Track                    [Page 10]
+
+RFC 5321                          SMTP                      October 2008
+
+
+   o  the increment by which the extension is increasing the maximum
+      length of the commands MAIL and/or RCPT, over that specified in
+      this Standard.
+
+   In addition, any EHLO keyword value starting with an upper or lower
+   case "X" refers to a local SMTP service extension used exclusively
+   through bilateral agreement.  Keywords beginning with "X" MUST NOT be
+   used in a registered service extension.  Conversely, keyword values
+   presented in the EHLO response that do not begin with "X" MUST
+   correspond to a Standard, Standards-Track, or IESG-approved
+   Experimental SMTP service extension registered with IANA.  A
+   conforming server MUST NOT offer non-"X"-prefixed keyword values that
+   are not described in a registered extension.
+
+   Additional verbs and parameter names are bound by the same rules as
+   EHLO keywords; specifically, verbs beginning with "X" are local
+   extensions that may not be registered or standardized.  Conversely,
+   verbs not beginning with "X" must always be registered.
+
+2.2.3.  Special Issues with Extensions
+
+   Extensions that change fairly basic properties of SMTP operation are
+   permitted.  The text in other sections of this document must be
+   understood in that context.  In particular, extensions can change the
+   minimum limits specified in Section 4.5.3, can change the ASCII
+   character set requirement as mentioned above, or can introduce some
+   optional modes of message handling.
+
+   In particular, if an extension implies that the delivery path
+   normally supports special features of that extension, and an
+   intermediate SMTP system finds a next hop that does not support the
+   required extension, it MAY choose, based on the specific extension
+   and circumstances, to requeue the message and try later and/or try an
+   alternate MX host.  If this strategy is employed, the timeout to fall
+   back to an unextended format (if one is available) SHOULD be less
+   than the normal timeout for bouncing as undeliverable (e.g., if
+   normal timeout is three days, the requeue timeout before attempting
+   to transmit the mail without the extension might be one day).
+
+2.3.  SMTP Terminology
+
+2.3.1.  Mail Objects
+
+   SMTP transports a mail object.  A mail object contains an envelope
+   and content.
+
+   The SMTP envelope is sent as a series of SMTP protocol units
+   (described in Section 3).  It consists of an originator address (to
+
+
+
+Klensin                     Standards Track                    [Page 11]
+
+RFC 5321                          SMTP                      October 2008
+
+
+   which error reports should be directed), one or more recipient
+   addresses, and optional protocol extension material.  Historically,
+   variations on the reverse-path (originator) address specification
+   command (MAIL) could be used to specify alternate delivery modes,
+   such as immediate display; those variations have now been deprecated
+   (see Appendix F and Appendix F.6).
+
+   The SMTP content is sent in the SMTP DATA protocol unit and has two
+   parts: the header section and the body.  If the content conforms to
+   other contemporary standards, the header section consists of a
+   collection of header fields, each consisting of a header name, a
+   colon, and data, structured as in the message format specification
+   (RFC 5322 [4]); the body, if structured, is defined according to MIME
+   (RFC 2045 [21]).  The content is textual in nature, expressed using
+   the US-ASCII repertoire [6].  Although SMTP extensions (such as
+   "8BITMIME", RFC 1652 [22]) may relax this restriction for the content
+   body, the content header fields are always encoded using the US-ASCII
+   repertoire.  Two MIME extensions (RFC 2047 [23] and RFC 2231 [24])
+   define an algorithm for representing header values outside the US-
+   ASCII repertoire, while still encoding them using the US-ASCII
+   repertoire.
+
+2.3.2.  Senders and Receivers
+
+   In RFC 821, the two hosts participating in an SMTP transaction were
+   described as the "SMTP-sender" and "SMTP-receiver".  This document
+   has been changed to reflect current industry terminology and hence
+   refers to them as the "SMTP client" (or sometimes just "the client")
+   and "SMTP server" (or just "the server"), respectively.  Since a
+   given host may act both as server and client in a relay situation,
+   "receiver" and "sender" terminology is still used where needed for
+   clarity.
+
+2.3.3.  Mail Agents and Message Stores
+
+   Additional mail system terminology became common after RFC 821 was
+   published and, where convenient, is used in this specification.  In
+   particular, SMTP servers and clients provide a mail transport service
+   and therefore act as "Mail Transfer Agents" (MTAs).  "Mail User
+   Agents" (MUAs or UAs) are normally thought of as the sources and
+   targets of mail.  At the source, an MUA might collect mail to be
+   transmitted from a user and hand it off to an MTA; the final
+   ("delivery") MTA would be thought of as handing the mail off to an
+   MUA (or at least transferring responsibility to it, e.g., by
+   depositing the message in a "message store").  However, while these
+   terms are used with at least the appearance of great precision in
+   other environments, the implied boundaries between MUAs and MTAs
+   often do not accurately match common, and conforming, practices with
+
+
+
+Klensin                     Standards Track                    [Page 12]
+
+RFC 5321                          SMTP                      October 2008
+
+
+   Internet mail.  Hence, the reader should be cautious about inferring
+   the strong relationships and responsibilities that might be implied
+   if these terms were used elsewhere.
+
+2.3.4.  Host
+
+   For the purposes of this specification, a host is a computer system
+   attached to the Internet (or, in some cases, to a private TCP/IP
+   network) and supporting the SMTP protocol.  Hosts are known by names
+   (see the next section); they SHOULD NOT be identified by numerical
+   addresses, i.e., by address literals as described in Section 4.1.2.
+
+2.3.5.  Domain Names
+
+   A domain name (or often just a "domain") consists of one or more
+   components, separated by dots if more than one appears.  In the case
+   of a top-level domain used by itself in an email address, a single
+   string is used without any dots.  This makes the requirement,
+   described in more detail below, that only fully-qualified domain
+   names appear in SMTP transactions on the public Internet,
+   particularly important where top-level domains are involved.  These
+   components ("labels" in DNS terminology, RFC 1035 [2]) are restricted
+   for SMTP purposes to consist of a sequence of letters, digits, and
+   hyphens drawn from the ASCII character set [6].  Domain names are
+   used as names of hosts and of other entities in the domain name
+   hierarchy.  For example, a domain may refer to an alias (label of a
+   CNAME RR) or the label of Mail eXchanger records to be used to
+   deliver mail instead of representing a host name.  See RFC 1035 [2]
+   and Section 5 of this specification.
+
+   The domain name, as described in this document and in RFC 1035 [2],
+   is the entire, fully-qualified name (often referred to as an "FQDN").
+   A domain name that is not in FQDN form is no more than a local alias.
+   Local aliases MUST NOT appear in any SMTP transaction.
+
+   Only resolvable, fully-qualified domain names (FQDNs) are permitted
+   when domain names are used in SMTP.  In other words, names that can
+   be resolved to MX RRs or address (i.e., A or AAAA) RRs (as discussed
+   in Section 5) are permitted, as are CNAME RRs whose targets can be
+   resolved, in turn, to MX or address RRs.  Local nicknames or
+   unqualified names MUST NOT be used.  There are two exceptions to the
+   rule requiring FQDNs:
+
+   o  The domain name given in the EHLO command MUST be either a primary
+      host name (a domain name that resolves to an address RR) or, if
+      the host has no name, an address literal, as described in
+      Section 4.1.3 and discussed further in the EHLO discussion of
+      Section 4.1.4.
+
+
+
+Klensin                     Standards Track                    [Page 13]
+
+RFC 5321                          SMTP                      October 2008
+
+
+   o  The reserved mailbox name "postmaster" may be used in a RCPT
+      command without domain qualification (see Section 4.1.1.3) and
+      MUST be accepted if so used.
+
+2.3.6.  Buffer and State Table
+
+   SMTP sessions are stateful, with both parties carefully maintaining a
+   common view of the current state.  In this document, we model this
+   state by a virtual "buffer" and a "state table" on the server that
+   may be used by the client to, for example, "clear the buffer" or
+   "reset the state table", causing the information in the buffer to be
+   discarded and the state to be returned to some previous state.
+
+2.3.7.  Commands and Replies
+
+   SMTP commands and, unless altered by a service extension, message
+   data, are transmitted from the sender to the receiver via the
+   transmission channel in "lines".
+
+   An SMTP reply is an acknowledgment (positive or negative) sent in
+   "lines" from receiver to sender via the transmission channel in
+   response to a command.  The general form of a reply is a numeric
+   completion code (indicating failure or success) usually followed by a
+   text string.  The codes are for use by programs and the text is
+   usually intended for human users.  RFC 3463 [25], specifies further
+   structuring of the reply strings, including the use of supplemental
+   and more specific completion codes (see also RFC 5248 [26]).
+
+2.3.8.  Lines
+
+   Lines consist of zero or more data characters terminated by the
+   sequence ASCII character "CR" (hex value 0D) followed immediately by
+   ASCII character "LF" (hex value 0A).  This termination sequence is
+   denoted as <CRLF> in this document.  Conforming implementations MUST
+   NOT recognize or generate any other character or character sequence
+   as a line terminator.  Limits MAY be imposed on line lengths by
+   servers (see Section 4).
+
+   In addition, the appearance of "bare" "CR" or "LF" characters in text
+   (i.e., either without the other) has a long history of causing
+   problems in mail implementations and applications that use the mail
+   system as a tool.  SMTP client implementations MUST NOT transmit
+   these characters except when they are intended as line terminators
+   and then MUST, as indicated above, transmit them only as a <CRLF>
+   sequence.
+
+
+
+
+
+
+Klensin                     Standards Track                    [Page 14]
+
+RFC 5321                          SMTP                      October 2008
+
+
+2.3.9.  Message Content and Mail Data
+
+   The terms "message content" and "mail data" are used interchangeably
+   in this document to describe the material transmitted after the DATA
+   command is accepted and before the end of data indication is
+   transmitted.  Message content includes the message header section and
+   the possibly structured message body.  The MIME specification (RFC
+   2045 [21]) provides the standard mechanisms for structured message
+   bodies.
+
+2.3.10.  Originator, Delivery, Relay, and Gateway Systems
+
+   This specification makes a distinction among four types of SMTP
+   systems, based on the role those systems play in transmitting
+   electronic mail.  An "originating" system (sometimes called an SMTP
+   originator) introduces mail into the Internet or, more generally,
+   into a transport service environment.  A "delivery" SMTP system is
+   one that receives mail from a transport service environment and
+   passes it to a mail user agent or deposits it in a message store that
+   a mail user agent is expected to subsequently access.  A "relay" SMTP
+   system (usually referred to just as a "relay") receives mail from an
+   SMTP client and transmits it, without modification to the message
+   data other than adding trace information, to another SMTP server for
+   further relaying or for delivery.
+
+   A "gateway" SMTP system (usually referred to just as a "gateway")
+   receives mail from a client system in one transport environment and
+   transmits it to a server system in another transport environment.
+   Differences in protocols or message semantics between the transport
+   environments on either side of a gateway may require that the gateway
+   system perform transformations to the message that are not permitted
+   to SMTP relay systems.  For the purposes of this specification,
+   firewalls that rewrite addresses should be considered as gateways,
+   even if SMTP is used on both sides of them (see RFC 2979 [27]).
+
+2.3.11.  Mailbox and Address
+
+   As used in this specification, an "address" is a character string
+   that identifies a user to whom mail will be sent or a location into
+   which mail will be deposited.  The term "mailbox" refers to that
+   depository.  The two terms are typically used interchangeably unless
+   the distinction between the location in which mail is placed (the
+   mailbox) and a reference to it (the address) is important.  An
+   address normally consists of user and domain specifications.  The
+   standard mailbox naming convention is defined to be
+   "local-part@domain"; contemporary usage permits a much broader set of
+   applications than simple "user names".  Consequently, and due to a
+   long history of problems when intermediate hosts have attempted to
+
+
+
+Klensin                     Standards Track                    [Page 15]
+
+RFC 5321                          SMTP                      October 2008
+
+
+   optimize transport by modifying them, the local-part MUST be
+   interpreted and assigned semantics only by the host specified in the
+   domain part of the address.
+
+2.4.  General Syntax Principles and Transaction Model
+
+   SMTP commands and replies have a rigid syntax.  All commands begin
+   with a command verb.  All replies begin with a three digit numeric
+   code.  In some commands and replies, arguments are required following
+   the verb or reply code.  Some commands do not accept arguments (after
+   the verb), and some reply codes are followed, sometimes optionally,
+   by free form text.  In both cases, where text appears, it is
+   separated from the verb or reply code by a space character.  Complete
+   definitions of commands and replies appear in Section 4.
+
+   Verbs and argument values (e.g., "TO:" or "to:" in the RCPT command
+   and extension name keywords) are not case sensitive, with the sole
+   exception in this specification of a mailbox local-part (SMTP
+   Extensions may explicitly specify case-sensitive elements).  That is,
+   a command verb, an argument value other than a mailbox local-part,
+   and free form text MAY be encoded in upper case, lower case, or any
+   mixture of upper and lower case with no impact on its meaning.  The
+   local-part of a mailbox MUST BE treated as case sensitive.
+   Therefore, SMTP implementations MUST take care to preserve the case
+   of mailbox local-parts.  In particular, for some hosts, the user
+   "smith" is different from the user "Smith".  However, exploiting the
+   case sensitivity of mailbox local-parts impedes interoperability and
+   is discouraged.  Mailbox domains follow normal DNS rules and are
+   hence not case sensitive.
+
+   A few SMTP servers, in violation of this specification (and RFC 821)
+   require that command verbs be encoded by clients in upper case.
+   Implementations MAY wish to employ this encoding to accommodate those
+   servers.
+
+   The argument clause consists of a variable-length character string
+   ending with the end of the line, i.e., with the character sequence
+   <CRLF>.  The receiver will take no action until this sequence is
+   received.
+
+   The syntax for each command is shown with the discussion of that
+   command.  Common elements and parameters are shown in Section 4.1.2.
+
+   Commands and replies are composed of characters from the ASCII
+   character set [6].  When the transport service provides an 8-bit byte
+   (octet) transmission channel, each 7-bit character is transmitted,
+   right justified, in an octet with the high-order bit cleared to zero.
+   More specifically, the unextended SMTP service provides 7-bit
+
+
+
+Klensin                     Standards Track                    [Page 16]
+
+RFC 5321                          SMTP                      October 2008
+
+
+   transport only.  An originating SMTP client that has not successfully
+   negotiated an appropriate extension with a particular server (see the
+   next paragraph) MUST NOT transmit messages with information in the
+   high-order bit of octets.  If such messages are transmitted in
+   violation of this rule, receiving SMTP servers MAY clear the high-
+   order bit or reject the message as invalid.  In general, a relay SMTP
+   SHOULD assume that the message content it has received is valid and,
+   assuming that the envelope permits doing so, relay it without
+   inspecting that content.  Of course, if the content is mislabeled and
+   the data path cannot accept the actual content, this may result in
+   the ultimate delivery of a severely garbled message to the recipient.
+   Delivery SMTP systems MAY reject such messages, or return them as
+   undeliverable, rather than deliver them.  In the absence of a server-
+   offered extension explicitly permitting it, a sending SMTP system is
+   not permitted to send envelope commands in any character set other
+   than US-ASCII.  Receiving systems SHOULD reject such commands,
+   normally using "500 syntax error - invalid character" replies.
+
+   8-bit message content transmission MAY be requested of the server by
+   a client using extended SMTP facilities, notably the "8BITMIME"
+   extension, RFC 1652 [22]. 8BITMIME SHOULD be supported by SMTP
+   servers.  However, it MUST NOT be construed as authorization to
+   transmit unrestricted 8-bit material, nor does 8BITMIME authorize
+   transmission of any envelope material in other than ASCII. 8BITMIME
+   MUST NOT be requested by senders for material with the high bit on
+   that is not in MIME format with an appropriate content-transfer
+   encoding; servers MAY reject such messages.
+
+   The metalinguistic notation used in this document corresponds to the
+   "Augmented BNF" used in other Internet mail system documents.  The
+   reader who is not familiar with that syntax should consult the ABNF
+   specification in RFC 5234 [7].  Metalanguage terms used in running
+   text are surrounded by pointed brackets (e.g., <CRLF>) for clarity.
+   The reader is cautioned that the grammar expressed in the
+   metalanguage is not comprehensive.  There are many instances in which
+   provisions in the text constrain or otherwise modify the syntax or
+   semantics implied by the grammar.
+
+3.  The SMTP Procedures: An Overview
+
+   This section contains descriptions of the procedures used in SMTP:
+   session initiation, mail transaction, forwarding mail, verifying
+   mailbox names and expanding mailing lists, and opening and closing
+   exchanges.  Comments on relaying, a note on mail domains, and a
+   discussion of changing roles are included at the end of this section.
+   Several complete scenarios are presented in Appendix D.
+
+
+
+
+
+Klensin                     Standards Track                    [Page 17]
+
+RFC 5321                          SMTP                      October 2008
+
+
+3.1.  Session Initiation
+
+   An SMTP session is initiated when a client opens a connection to a
+   server and the server responds with an opening message.
+
+   SMTP server implementations MAY include identification of their
+   software and version information in the connection greeting reply
+   after the 220 code, a practice that permits more efficient isolation
+   and repair of any problems.  Implementations MAY make provision for
+   SMTP servers to disable the software and version announcement where
+   it causes security concerns.  While some systems also identify their
+   contact point for mail problems, this is not a substitute for
+   maintaining the required "postmaster" address (see Section 4).
+
+   The SMTP protocol allows a server to formally reject a mail session
+   while still allowing the initial connection as follows: a 554
+   response MAY be given in the initial connection opening message
+   instead of the 220.  A server taking this approach MUST still wait
+   for the client to send a QUIT (see Section 4.1.1.10) before closing
+   the connection and SHOULD respond to any intervening commands with
+   "503 bad sequence of commands".  Since an attempt to make an SMTP
+   connection to such a system is probably in error, a server returning
+   a 554 response on connection opening SHOULD provide enough
+   information in the reply text to facilitate debugging of the sending
+   system.
+
+3.2.  Client Initiation
+
+   Once the server has sent the greeting (welcoming) message and the
+   client has received it, the client normally sends the EHLO command to
+   the server, indicating the client's identity.  In addition to opening
+   the session, use of EHLO indicates that the client is able to process
+   service extensions and requests that the server provide a list of the
+   extensions it supports.  Older SMTP systems that are unable to
+   support service extensions, and contemporary clients that do not
+   require service extensions in the mail session being initiated, MAY
+   use HELO instead of EHLO.  Servers MUST NOT return the extended EHLO-
+   style response to a HELO command.  For a particular connection
+   attempt, if the server returns a "command not recognized" response to
+   EHLO, the client SHOULD be able to fall back and send HELO.
+
+   In the EHLO command, the host sending the command identifies itself;
+   the command may be interpreted as saying "Hello, I am <domain>" (and,
+   in the case of EHLO, "and I support service extension requests").
+
+
+
+
+
+
+
+Klensin                     Standards Track                    [Page 18]
+
+RFC 5321                          SMTP                      October 2008
+
+
+3.3.  Mail Transactions
+
+   There are three steps to SMTP mail transactions.  The transaction
+   starts with a MAIL command that gives the sender identification.  (In
+   general, the MAIL command may be sent only when no mail transaction
+   is in progress; see Section 4.1.4.)  A series of one or more RCPT
+   commands follows, giving the receiver information.  Then, a DATA
+   command initiates transfer of the mail data and is terminated by the
+   "end of mail" data indicator, which also confirms the transaction.
+
+   The first step in the procedure is the MAIL command.
+
+      MAIL FROM:<reverse-path> [SP <mail-parameters> ] <CRLF>
+
+   This command tells the SMTP-receiver that a new mail transaction is
+   starting and to reset all its state tables and buffers, including any
+   recipients or mail data.  The <reverse-path> portion of the first or
+   only argument contains the source mailbox (between "<" and ">"
+   brackets), which can be used to report errors (see Section 4.2 for a
+   discussion of error reporting).  If accepted, the SMTP server returns
+   a "250 OK" reply.  If the mailbox specification is not acceptable for
+   some reason, the server MUST return a reply indicating whether the
+   failure is permanent (i.e., will occur again if the client tries to
+   send the same address again) or temporary (i.e., the address might be
+   accepted if the client tries again later).  Despite the apparent
+   scope of this requirement, there are circumstances in which the
+   acceptability of the reverse-path may not be determined until one or
+   more forward-paths (in RCPT commands) can be examined.  In those
+   cases, the server MAY reasonably accept the reverse-path (with a 250
+   reply) and then report problems after the forward-paths are received
+   and examined.  Normally, failures produce 550 or 553 replies.
+
+   Historically, the <reverse-path> was permitted to contain more than
+   just a mailbox; however, contemporary systems SHOULD NOT use source
+   routing (see Appendix C).
+
+   The optional <mail-parameters> are associated with negotiated SMTP
+   service extensions (see Section 2.2).
+
+   The second step in the procedure is the RCPT command.  This step of
+   the procedure can be repeated any number of times.
+
+      RCPT TO:<forward-path> [ SP <rcpt-parameters> ] <CRLF>
+
+   The first or only argument to this command includes a forward-path
+   (normally a mailbox and domain, always surrounded by "<" and ">"
+   brackets) identifying one recipient.  If accepted, the SMTP server
+   returns a "250 OK" reply and stores the forward-path.  If the
+
+
+
+Klensin                     Standards Track                    [Page 19]
+
+RFC 5321                          SMTP                      October 2008
+
+
+   recipient is known not to be a deliverable address, the SMTP server
+   returns a 550 reply, typically with a string such as "no such user -
+   " and the mailbox name (other circumstances and reply codes are
+   possible).
+
+   The <forward-path> can contain more than just a mailbox.
+   Historically, the <forward-path> was permitted to contain a source
+   routing list of hosts and the destination mailbox; however,
+   contemporary SMTP clients SHOULD NOT utilize source routes (see
+   Appendix C).  Servers MUST be prepared to encounter a list of source
+   routes in the forward-path, but they SHOULD ignore the routes or MAY
+   decline to support the relaying they imply.  Similarly, servers MAY
+   decline to accept mail that is destined for other hosts or systems.
+   These restrictions make a server useless as a relay for clients that
+   do not support full SMTP functionality.  Consequently, restricted-
+   capability clients MUST NOT assume that any SMTP server on the
+   Internet can be used as their mail processing (relaying) site.  If a
+   RCPT command appears without a previous MAIL command, the server MUST
+   return a 503 "Bad sequence of commands" response.  The optional
+   <rcpt-parameters> are associated with negotiated SMTP service
+   extensions (see Section 2.2).
+
+   Since it has been a common source of errors, it is worth noting that
+   spaces are not permitted on either side of the colon following FROM
+   in the MAIL command or TO in the RCPT command.  The syntax is exactly
+   as given above.
+
+   The third step in the procedure is the DATA command (or some
+   alternative specified in a service extension).
+
+      DATA <CRLF>
+
+   If accepted, the SMTP server returns a 354 Intermediate reply and
+   considers all succeeding lines up to but not including the end of
+   mail data indicator to be the message text.  When the end of text is
+   successfully received and stored, the SMTP-receiver sends a "250 OK"
+   reply.
+
+   Since the mail data is sent on the transmission channel, the end of
+   mail data must be indicated so that the command and reply dialog can
+   be resumed.  SMTP indicates the end of the mail data by sending a
+   line containing only a "." (period or full stop).  A transparency
+   procedure is used to prevent this from interfering with the user's
+   text (see Section 4.5.2).
+
+   The end of mail data indicator also confirms the mail transaction and
+   tells the SMTP server to now process the stored recipients and mail
+
+
+
+
+Klensin                     Standards Track                    [Page 20]
+
+RFC 5321                          SMTP                      October 2008
+
+
+   data.  If accepted, the SMTP server returns a "250 OK" reply.  The
+   DATA command can fail at only two points in the protocol exchange:
+
+   If there was no MAIL, or no RCPT, command, or all such commands were
+   rejected, the server MAY return a "command out of sequence" (503) or
+   "no valid recipients" (554) reply in response to the DATA command.
+   If one of those replies (or any other 5yz reply) is received, the
+   client MUST NOT send the message data; more generally, message data
+   MUST NOT be sent unless a 354 reply is received.
+
+   If the verb is initially accepted and the 354 reply issued, the DATA
+   command should fail only if the mail transaction was incomplete (for
+   example, no recipients), if resources were unavailable (including, of
+   course, the server unexpectedly becoming unavailable), or if the
+   server determines that the message should be rejected for policy or
+   other reasons.
+
+   However, in practice, some servers do not perform recipient
+   verification until after the message text is received.  These servers
+   SHOULD treat a failure for one or more recipients as a "subsequent
+   failure" and return a mail message as discussed in Section 6 and, in
+   particular, in Section 6.1.  Using a "550 mailbox not found" (or
+   equivalent) reply code after the data are accepted makes it difficult
+   or impossible for the client to determine which recipients failed.
+
+   When the RFC 822 format ([28], [4]) is being used, the mail data
+   include the header fields such as those named Date, Subject, To, Cc,
+   and From.  Server SMTP systems SHOULD NOT reject messages based on
+   perceived defects in the RFC 822 or MIME (RFC 2045 [21]) message
+   header section or message body.  In particular, they MUST NOT reject
+   messages in which the numbers of Resent-header fields do not match or
+   Resent-to appears without Resent-from and/or Resent-date.
+
+   Mail transaction commands MUST be used in the order discussed above.
+
+3.4.  Forwarding for Address Correction or Updating
+
+   Forwarding support is most often required to consolidate and simplify
+   addresses within, or relative to, some enterprise and less frequently
+   to establish addresses to link a person's prior address with a
+   current one.  Silent forwarding of messages (without server
+   notification to the sender), for security or non-disclosure purposes,
+   is common in the contemporary Internet.
+
+   In both the enterprise and the "new address" cases, information
+   hiding (and sometimes security) considerations argue against exposure
+   of the "final" address through the SMTP protocol as a side effect of
+   the forwarding activity.  This may be especially important when the
+
+
+
+Klensin                     Standards Track                    [Page 21]
+
+RFC 5321                          SMTP                      October 2008
+
+
+   final address may not even be reachable by the sender.  Consequently,
+   the "forwarding" mechanisms described in Section 3.2 of RFC 821, and
+   especially the 251 (corrected destination) and 551 reply codes from
+   RCPT must be evaluated carefully by implementers and, when they are
+   available, by those configuring systems (see also Section 7.4).
+
+   In particular:
+
+   o  Servers MAY forward messages when they are aware of an address
+      change.  When they do so, they MAY either provide address-updating
+      information with a 251 code, or may forward "silently" and return
+      a 250 code.  However, if a 251 code is used, they MUST NOT assume
+      that the client will actually update address information or even
+      return that information to the user.
+
+   Alternately,
+
+   o  Servers MAY reject messages or return them as non-deliverable when
+      they cannot be delivered precisely as addressed.  When they do so,
+      they MAY either provide address-updating information with a 551
+      code, or may reject the message as undeliverable with a 550 code
+      and no address-specific information.  However, if a 551 code is
+      used, they MUST NOT assume that the client will actually update
+      address information or even return that information to the user.
+
+   SMTP server implementations that support the 251 and/or 551 reply
+   codes SHOULD provide configuration mechanisms so that sites that
+   conclude that they would undesirably disclose information can disable
+   or restrict their use.
+
+3.5.  Commands for Debugging Addresses
+
+3.5.1.  Overview
+
+   SMTP provides commands to verify a user name or obtain the content of
+   a mailing list.  This is done with the VRFY and EXPN commands, which
+   have character string arguments.  Implementations SHOULD support VRFY
+   and EXPN (however, see Section 3.5.2 and Section 7.3).
+
+   For the VRFY command, the string is a user name or a user name and
+   domain (see below).  If a normal (i.e., 250) response is returned,
+   the response MAY include the full name of the user and MUST include
+   the mailbox of the user.  It MUST be in either of the following
+   forms:
+
+      User Name <local-part@domain>
+      local-part@domain
+
+
+
+
+Klensin                     Standards Track                    [Page 22]
+
+RFC 5321                          SMTP                      October 2008
+
+
+   When a name that is the argument to VRFY could identify more than one
+   mailbox, the server MAY either note the ambiguity or identify the
+   alternatives.  In other words, any of the following are legitimate
+   responses to VRFY:
+
+      553 User ambiguous
+
+   or
+
+      553- Ambiguous; Possibilities are
+      553-Joe Smith <jsmith@foo.com>
+      553-Harry Smith <hsmith@foo.com>
+      553 Melvin Smith <dweep@foo.com>
+
+   or
+
+      553-Ambiguous; Possibilities
+      553- <jsmith@foo.com>
+      553- <hsmith@foo.com>
+      553 <dweep@foo.com>
+
+   Under normal circumstances, a client receiving a 553 reply would be
+   expected to expose the result to the user.  Use of exactly the forms
+   given, and the "user ambiguous" or "ambiguous" keywords, possibly
+   supplemented by extended reply codes, such as those described in RFC
+   3463 [25], will facilitate automated translation into other languages
+   as needed.  Of course, a client that was highly automated or that was
+   operating in another language than English might choose to try to
+   translate the response to return some other indication to the user
+   than the literal text of the reply, or to take some automated action
+   such as consulting a directory service for additional information
+   before reporting to the user.
+
+   For the EXPN command, the string identifies a mailing list, and the
+   successful (i.e., 250) multiline response MAY include the full name
+   of the users and MUST give the mailboxes on the mailing list.
+
+   In some hosts, the distinction between a mailing list and an alias
+   for a single mailbox is a bit fuzzy, since a common data structure
+   may hold both types of entries, and it is possible to have mailing
+   lists containing only one mailbox.  If a request is made to apply
+   VRFY to a mailing list, a positive response MAY be given if a message
+   so addressed would be delivered to everyone on the list, otherwise an
+   error SHOULD be reported (e.g., "550 That is a mailing list, not a
+   user" or "252 Unable to verify members of mailing list").  If a
+   request is made to expand a user name, the server MAY return a
+
+
+
+
+
+Klensin                     Standards Track                    [Page 23]
+
+RFC 5321                          SMTP                      October 2008
+
+
+   positive response consisting of a list containing one name, or an
+   error MAY be reported (e.g., "550 That is a user name, not a mailing
+   list").
+
+   In the case of a successful multiline reply (normal for EXPN),
+   exactly one mailbox is to be specified on each line of the reply.
+   The case of an ambiguous request is discussed above.
+
+   "User name" is a fuzzy term and has been used deliberately.  An
+   implementation of the VRFY or EXPN commands MUST include at least
+   recognition of local mailboxes as "user names".  However, since
+   current Internet practice often results in a single host handling
+   mail for multiple domains, hosts, especially hosts that provide this
+   functionality, SHOULD accept the "local-part@domain" form as a "user
+   name"; hosts MAY also choose to recognize other strings as "user
+   names".
+
+   The case of expanding a mailbox list requires a multiline reply, such
+   as:
+
+      C: EXPN Example-People
+      S: 250-Jon Postel <Postel@isi.edu>
+      S: 250-Fred Fonebone <Fonebone@physics.foo-u.edu>
+      S: 250 Sam Q. Smith <SQSmith@specific.generic.com>
+
+   or
+
+      C: EXPN Executive-Washroom-List
+      S: 550 Access Denied to You.
+
+   The character string arguments of the VRFY and EXPN commands cannot
+   be further restricted due to the variety of implementations of the
+   user name and mailbox list concepts.  On some systems, it may be
+   appropriate for the argument of the EXPN command to be a file name
+   for a file containing a mailing list, but again there are a variety
+   of file naming conventions in the Internet.  Similarly, historical
+   variations in what is returned by these commands are such that the
+   response SHOULD be interpreted very carefully, if at all, and SHOULD
+   generally only be used for diagnostic purposes.
+
+3.5.2.  VRFY Normal Response
+
+   When normal (2yz or 551) responses are returned from a VRFY or EXPN
+   request, the reply MUST include the <Mailbox> name using a
+   "<local-part@domain>" construction, where "domain" is a fully-
+   qualified domain name.  In circumstances exceptional enough to
+   justify violating the intent of this specification, free-form text
+   MAY be returned.  In order to facilitate parsing by both computers
+
+
+
+Klensin                     Standards Track                    [Page 24]
+
+RFC 5321                          SMTP                      October 2008
+
+
+   and people, addresses SHOULD appear in pointed brackets.  When
+   addresses, rather than free-form debugging information, are returned,
+   EXPN and VRFY MUST return only valid domain addresses that are usable
+   in SMTP RCPT commands.  Consequently, if an address implies delivery
+   to a program or other system, the mailbox name used to reach that
+   target MUST be given.  Paths (explicit source routes) MUST NOT be
+   returned by VRFY or EXPN.
+
+   Server implementations SHOULD support both VRFY and EXPN.  For
+   security reasons, implementations MAY provide local installations a
+   way to disable either or both of these commands through configuration
+   options or the equivalent (see Section 7.3).  When these commands are
+   supported, they are not required to work across relays when relaying
+   is supported.  Since they were both optional in RFC 821, but VRFY was
+   made mandatory in RFC 1123 [3], if EXPN is supported, it MUST be
+   listed as a service extension in an EHLO response.  VRFY MAY be
+   listed as a convenience but, since support for it is required, SMTP
+   clients are not required to check for its presence on the extension
+   list before using it.
+
+3.5.3.  Meaning of VRFY or EXPN Success Response
+
+   A server MUST NOT return a 250 code in response to a VRFY or EXPN
+   command unless it has actually verified the address.  In particular,
+   a server MUST NOT return 250 if all it has done is to verify that the
+   syntax given is valid.  In that case, 502 (Command not implemented)
+   or 500 (Syntax error, command unrecognized) SHOULD be returned.  As
+   stated elsewhere, implementation (in the sense of actually validating
+   addresses and returning information) of VRFY and EXPN are strongly
+   recommended.  Hence, implementations that return 500 or 502 for VRFY
+   are not in full compliance with this specification.
+
+   There may be circumstances where an address appears to be valid but
+   cannot reasonably be verified in real time, particularly when a
+   server is acting as a mail exchanger for another server or domain.
+   "Apparent validity", in this case, would normally involve at least
+   syntax checking and might involve verification that any domains
+   specified were ones to which the host expected to be able to relay
+   mail.  In these situations, reply code 252 SHOULD be returned.  These
+   cases parallel the discussion of RCPT verification in Section 2.1.
+   Similarly, the discussion in Section 3.4 applies to the use of reply
+   codes 251 and 551 with VRFY (and EXPN) to indicate addresses that are
+   recognized but that would be forwarded or rejected were mail received
+   for them.  Implementations generally SHOULD be more aggressive about
+   address verification in the case of VRFY than in the case of RCPT,
+   even if it takes a little longer to do so.
+
+
+
+
+
+Klensin                     Standards Track                    [Page 25]
+
+RFC 5321                          SMTP                      October 2008
+
+
+3.5.4.  Semantics and Applications of EXPN
+
+   EXPN is often very useful in debugging and understanding problems
+   with mailing lists and multiple-target-address aliases.  Some systems
+   have attempted to use source expansion of mailing lists as a means of
+   eliminating duplicates.  The propagation of aliasing systems with
+   mail on the Internet for hosts (typically with MX and CNAME DNS
+   records), for mailboxes (various types of local host aliases), and in
+   various proxying arrangements has made it nearly impossible for these
+   strategies to work consistently, and mail systems SHOULD NOT attempt
+   them.
+
+3.6.  Relaying and Mail Routing
+
+3.6.1.  Source Routes and Relaying
+
+   In general, the availability of Mail eXchanger records in the domain
+   name system (RFC 1035 [2], RFC 974 [12]) makes the use of explicit
+   source routes in the Internet mail system unnecessary.  Many
+   historical problems with the interpretation of explicit source routes
+   have made their use undesirable.  SMTP clients SHOULD NOT generate
+   explicit source routes except under unusual circumstances.  SMTP
+   servers MAY decline to act as mail relays or to accept addresses that
+   specify source routes.  When route information is encountered, SMTP
+   servers MAY ignore the route information and simply send to the final
+   destination specified as the last element in the route and SHOULD do
+   so.  There has been an invalid practice of using names that do not
+   appear in the DNS as destination names, with the senders counting on
+   the intermediate hosts specified in source routing to resolve any
+   problems.  If source routes are stripped, this practice will cause
+   failures.  This is one of several reasons why SMTP clients MUST NOT
+   generate invalid source routes or depend on serial resolution of
+   names.
+
+   When source routes are not used, the process described in RFC 821 for
+   constructing a reverse-path from the forward-path is not applicable
+   and the reverse-path at the time of delivery will simply be the
+   address that appeared in the MAIL command.
+
+3.6.2.  Mail eXchange Records and Relaying
+
+   A relay SMTP server is usually the target of a DNS MX record that
+   designates it, rather than the final delivery system.  The relay
+   server may accept or reject the task of relaying the mail in the same
+   way it accepts or rejects mail for a local user.  If it accepts the
+   task, it then becomes an SMTP client, establishes a transmission
+   channel to the next SMTP server specified in the DNS (according to
+   the rules in Section 5), and sends it the mail.  If it declines to
+
+
+
+Klensin                     Standards Track                    [Page 26]
+
+RFC 5321                          SMTP                      October 2008
+
+
+   relay mail to a particular address for policy reasons, a 550 response
+   SHOULD be returned.
+
+   This specification does not deal with the verification of return
+   paths for use in delivery notifications.  Recent work, such as that
+   on SPF [29] and DKIM [30] [31], has been done to provide ways to
+   ascertain that an address is valid or belongs to the person who
+   actually sent the message.  A server MAY attempt to verify the return
+   path before using its address for delivery notifications, but methods
+   of doing so are not defined here nor is any particular method
+   recommended at this time.
+
+3.6.3.  Message Submission Servers as Relays
+
+   Many mail-sending clients exist, especially in conjunction with
+   facilities that receive mail via POP3 or IMAP, that have limited
+   capability to support some of the requirements of this specification,
+   such as the ability to queue messages for subsequent delivery
+   attempts.  For these clients, it is common practice to make private
+   arrangements to send all messages to a single server for processing
+   and subsequent distribution.  SMTP, as specified here, is not ideally
+   suited for this role.  A standardized mail submission protocol has
+   been developed that is gradually superseding practices based on SMTP
+   (see RFC 4409 [18]).  In any event, because these arrangements are
+   private and fall outside the scope of this specification, they are
+   not described here.
+
+   It is important to note that MX records can point to SMTP servers
+   that act as gateways into other environments, not just SMTP relays
+   and final delivery systems; see Sections 3.7 and 5.
+
+   If an SMTP server has accepted the task of relaying the mail and
+   later finds that the destination is incorrect or that the mail cannot
+   be delivered for some other reason, then it MUST construct an
+   "undeliverable mail" notification message and send it to the
+   originator of the undeliverable mail (as indicated by the reverse-
+   path).  Formats specified for non-delivery reports by other standards
+   (see, for example, RFC 3461 [32] and RFC 3464 [33]) SHOULD be used if
+   possible.
+
+   This notification message must be from the SMTP server at the relay
+   host or the host that first determines that delivery cannot be
+   accomplished.  Of course, SMTP servers MUST NOT send notification
+   messages about problems transporting notification messages.  One way
+   to prevent loops in error reporting is to specify a null reverse-path
+   in the MAIL command of a notification message.  When such a message
+   is transmitted, the reverse-path MUST be set to null (see
+
+
+
+
+Klensin                     Standards Track                    [Page 27]
+
+RFC 5321                          SMTP                      October 2008
+
+
+   Section 4.5.5 for additional discussion).  A MAIL command with a null
+   reverse-path appears as follows:
+
+      MAIL FROM:<>
+
+   As discussed in Section 6.4, a relay SMTP has no need to inspect or
+   act upon the header section or body of the message data and MUST NOT
+   do so except to add its own "Received:" header field (Section 4.4)
+   and, optionally, to attempt to detect looping in the mail system (see
+   Section 6.3).  Of course, this prohibition also applies to any
+   modifications of these header fields or text (see also Section 7.9).
+
+3.7.  Mail Gatewaying
+
+   While the relay function discussed above operates within the Internet
+   SMTP transport service environment, MX records or various forms of
+   explicit routing may require that an intermediate SMTP server perform
+   a translation function between one transport service and another.  As
+   discussed in Section 2.3.10, when such a system is at the boundary
+   between two transport service environments, we refer to it as a
+   "gateway" or "gateway SMTP".
+
+   Gatewaying mail between different mail environments, such as
+   different mail formats and protocols, is complex and does not easily
+   yield to standardization.  However, some general requirements may be
+   given for a gateway between the Internet and another mail
+   environment.
+
+3.7.1.  Header Fields in Gatewaying
+
+   Header fields MAY be rewritten when necessary as messages are
+   gatewayed across mail environment boundaries.  This may involve
+   inspecting the message body or interpreting the local-part of the
+   destination address in spite of the prohibitions in Section 6.4.
+
+   Other mail systems gatewayed to the Internet often use a subset of
+   the RFC 822 header section or provide similar functionality with a
+   different syntax, but some of these mail systems do not have an
+   equivalent to the SMTP envelope.  Therefore, when a message leaves
+   the Internet environment, it may be necessary to fold the SMTP
+   envelope information into the message header section.  A possible
+   solution would be to create new header fields to carry the envelope
+   information (e.g., "X-SMTP-MAIL:" and "X-SMTP-RCPT:"); however, this
+   would require changes in mail programs in foreign environments and
+   might risk disclosure of private information (see Section 7.2).
+
+
+
+
+
+
+Klensin                     Standards Track                    [Page 28]
+
+RFC 5321                          SMTP                      October 2008
+
+
+3.7.2.  Received Lines in Gatewaying
+
+   When forwarding a message into or out of the Internet environment, a
+   gateway MUST prepend a Received: line, but it MUST NOT alter in any
+   way a Received: line that is already in the header section.
+
+   "Received:" header fields of messages originating from other
+   environments may not conform exactly to this specification.  However,
+   the most important use of Received: lines is for debugging mail
+   faults, and this debugging can be severely hampered by well-meaning
+   gateways that try to "fix" a Received: line.  As another consequence
+   of trace header fields arising in non-SMTP environments, receiving
+   systems MUST NOT reject mail based on the format of a trace header
+   field and SHOULD be extremely robust in the light of unexpected
+   information or formats in those header fields.
+
+   The gateway SHOULD indicate the environment and protocol in the "via"
+   clauses of Received header field(s) that it supplies.
+
+3.7.3.  Addresses in Gatewaying
+
+   From the Internet side, the gateway SHOULD accept all valid address
+   formats in SMTP commands and in the RFC 822 header section, and all
+   valid RFC 822 messages.  Addresses and header fields generated by
+   gateways MUST conform to applicable standards (including this one and
+   RFC 5322 [4]).  Gateways are, of course, subject to the same rules
+   for handling source routes as those described for other SMTP systems
+   in Section 3.3.
+
+3.7.4.  Other Header Fields in Gatewaying
+
+   The gateway MUST ensure that all header fields of a message that it
+   forwards into the Internet mail environment meet the requirements for
+   Internet mail.  In particular, all addresses in "From:", "To:",
+   "Cc:", etc., header fields MUST be transformed (if necessary) to
+   satisfy the standard header syntax of RFC 5322 [4], MUST reference
+   only fully-qualified domain names, and MUST be effective and useful
+   for sending replies.  The translation algorithm used to convert mail
+   from the Internet protocols to another environment's protocol SHOULD
+   ensure that error messages from the foreign mail environment are
+   delivered to the reverse-path from the SMTP envelope, not to an
+   address in the "From:", "Sender:", or similar header fields of the
+   message.
+
+
+
+
+
+
+
+
+Klensin                     Standards Track                    [Page 29]
+
+RFC 5321                          SMTP                      October 2008
+
+
+3.7.5.  Envelopes in Gatewaying
+
+   Similarly, when forwarding a message from another environment into
+   the Internet, the gateway SHOULD set the envelope return path in
+   accordance with an error message return address, if supplied by the
+   foreign environment.  If the foreign environment has no equivalent
+   concept, the gateway must select and use a best approximation, with
+   the message originator's address as the default of last resort.
+
+3.8.  Terminating Sessions and Connections
+
+   An SMTP connection is terminated when the client sends a QUIT
+   command.  The server responds with a positive reply code, after which
+   it closes the connection.
+
+   An SMTP server MUST NOT intentionally close the connection under
+   normal operational circumstances (see Section 7.8) except:
+
+   o  After receiving a QUIT command and responding with a 221 reply.
+
+   o  After detecting the need to shut down the SMTP service and
+      returning a 421 response code.  This response code can be issued
+      after the server receives any command or, if necessary,
+      asynchronously from command receipt (on the assumption that the
+      client will receive it after the next command is issued).
+
+   o  After a timeout, as specified in Section 4.5.3.2, occurs waiting
+      for the client to send a command or data.
+
+   In particular, a server that closes connections in response to
+   commands that are not understood is in violation of this
+   specification.  Servers are expected to be tolerant of unknown
+   commands, issuing a 500 reply and awaiting further instructions from
+   the client.
+
+   An SMTP server that is forcibly shut down via external means SHOULD
+   attempt to send a line containing a 421 response code to the SMTP
+   client before exiting.  The SMTP client will normally read the 421
+   response code after sending its next command.
+
+   SMTP clients that experience a connection close, reset, or other
+   communications failure due to circumstances not under their control
+   (in violation of the intent of this specification but sometimes
+   unavoidable) SHOULD, to maintain the robustness of the mail system,
+   treat the mail transaction as if a 451 response had been received and
+   act accordingly.
+
+
+
+
+
+Klensin                     Standards Track                    [Page 30]
+
+RFC 5321                          SMTP                      October 2008
+
+
+3.9.  Mailing Lists and Aliases
+
+   An SMTP-capable host SHOULD support both the alias and the list
+   models of address expansion for multiple delivery.  When a message is
+   delivered or forwarded to each address of an expanded list form, the
+   return address in the envelope ("MAIL FROM:") MUST be changed to be
+   the address of a person or other entity who administers the list.
+   However, in this case, the message header section (RFC 5322 [4]) MUST
+   be left unchanged; in particular, the "From" field of the header
+   section is unaffected.
+
+   An important mail facility is a mechanism for multi-destination
+   delivery of a single message, by transforming (or "expanding" or
+   "exploding") a pseudo-mailbox address into a list of destination
+   mailbox addresses.  When a message is sent to such a pseudo-mailbox
+   (sometimes called an "exploder"), copies are forwarded or
+   redistributed to each mailbox in the expanded list.  Servers SHOULD
+   simply utilize the addresses on the list; application of heuristics
+   or other matching rules to eliminate some addresses, such as that of
+   the originator, is strongly discouraged.  We classify such a pseudo-
+   mailbox as an "alias" or a "list", depending upon the expansion
+   rules.
+
+3.9.1.  Alias
+
+   To expand an alias, the recipient mailer simply replaces the pseudo-
+   mailbox address in the envelope with each of the expanded addresses
+   in turn; the rest of the envelope and the message body are left
+   unchanged.  The message is then delivered or forwarded to each
+   expanded address.
+
+3.9.2.  List
+
+   A mailing list may be said to operate by "redistribution" rather than
+   by "forwarding".  To expand a list, the recipient mailer replaces the
+   pseudo-mailbox address in the envelope with each of the expanded
+   addresses in turn.  The return (backward-pointing) address in the
+   envelope is changed so that all error messages generated by the final
+   deliveries will be returned to a list administrator, not to the
+   message originator, who generally has no control over the contents of
+   the list and will typically find error messages annoying.  Note that
+   the key difference between handling aliases (Section 3.9.1) and
+   forwarding (this subsection) is the change to the backward-pointing
+   address in this case.  When a list constrains its processing to the
+   very limited set of modifications and actions described here, it is
+   attempting to emulate an MTA; such lists can be treated as a
+   continuation in email transit.
+
+
+
+
+Klensin                     Standards Track                    [Page 31]
+
+RFC 5321                          SMTP                      October 2008
+
+
+   There exist mailing lists that perform additional, sometimes
+   extensive, modifications to a message and its envelope.  Such mailing
+   lists need to be viewed as full MUAs, which accept a delivery and
+   post a new message.
+
+4.  The SMTP Specifications
+
+4.1.  SMTP Commands
+
+4.1.1.  Command Semantics and Syntax
+
+   The SMTP commands define the mail transfer or the mail system
+   function requested by the user.  SMTP commands are character strings
+   terminated by <CRLF>.  The commands themselves are alphabetic
+   characters terminated by <SP> if parameters follow and <CRLF>
+   otherwise.  (In the interest of improved interoperability, SMTP
+   receivers SHOULD tolerate trailing white space before the terminating
+   <CRLF>.)  The syntax of the local part of a mailbox MUST conform to
+   receiver site conventions and the syntax specified in Section 4.1.2.
+   The SMTP commands are discussed below.  The SMTP replies are
+   discussed in Section 4.2.
+
+   A mail transaction involves several data objects that are
+   communicated as arguments to different commands.  The reverse-path is
+   the argument of the MAIL command, the forward-path is the argument of
+   the RCPT command, and the mail data is the argument of the DATA
+   command.  These arguments or data objects must be transmitted and
+   held, pending the confirmation communicated by the end of mail data
+   indication that finalizes the transaction.  The model for this is
+   that distinct buffers are provided to hold the types of data objects;
+   that is, there is a reverse-path buffer, a forward-path buffer, and a
+   mail data buffer.  Specific commands cause information to be appended
+   to a specific buffer, or cause one or more buffers to be cleared.
+
+   Several commands (RSET, DATA, QUIT) are specified as not permitting
+   parameters.  In the absence of specific extensions offered by the
+   server and accepted by the client, clients MUST NOT send such
+   parameters and servers SHOULD reject commands containing them as
+   having invalid syntax.
+
+4.1.1.1.  Extended HELLO (EHLO) or HELLO (HELO)
+
+   These commands are used to identify the SMTP client to the SMTP
+   server.  The argument clause contains the fully-qualified domain name
+   of the SMTP client, if one is available.  In situations in which the
+   SMTP client system does not have a meaningful domain name (e.g., when
+   its address is dynamically allocated and no reverse mapping record is
+
+
+
+
+Klensin                     Standards Track                    [Page 32]
+
+RFC 5321                          SMTP                      October 2008
+
+
+   available), the client SHOULD send an address literal (see
+   Section 4.1.3).
+
+   RFC 2821, and some earlier informal practices, encouraged following
+   the literal by information that would help to identify the client
+   system.  That convention was not widely supported, and many SMTP
+   servers considered it an error.  In the interest of interoperability,
+   it is probably wise for servers to be prepared for this string to
+   occur, but SMTP clients SHOULD NOT send it.
+
+   The SMTP server identifies itself to the SMTP client in the
+   connection greeting reply and in the response to this command.
+
+   A client SMTP SHOULD start an SMTP session by issuing the EHLO
+   command.  If the SMTP server supports the SMTP service extensions, it
+   will give a successful response, a failure response, or an error
+   response.  If the SMTP server, in violation of this specification,
+   does not support any SMTP service extensions, it will generate an
+   error response.  Older client SMTP systems MAY, as discussed above,
+   use HELO (as specified in RFC 821) instead of EHLO, and servers MUST
+   support the HELO command and reply properly to it.  In any event, a
+   client MUST issue HELO or EHLO before starting a mail transaction.
+
+   These commands, and a "250 OK" reply to one of them, confirm that
+   both the SMTP client and the SMTP server are in the initial state,
+   that is, there is no transaction in progress and all state tables and
+   buffers are cleared.
+
+   Syntax:
+
+   ehlo           = "EHLO" SP ( Domain / address-literal ) CRLF
+
+   helo           = "HELO" SP Domain CRLF
+
+   Normally, the response to EHLO will be a multiline reply.  Each line
+   of the response contains a keyword and, optionally, one or more
+   parameters.  Following the normal syntax for multiline replies, these
+   keywords follow the code (250) and a hyphen for all but the last
+   line, and the code and a space for the last line.  The syntax for a
+   positive response, using the ABNF notation and terminal symbols of
+   RFC 5234 [7], is:
+
+   ehlo-ok-rsp    = ( "250" SP Domain [ SP ehlo-greet ] CRLF )
+                    / ( "250-" Domain [ SP ehlo-greet ] CRLF
+                    *( "250-" ehlo-line CRLF )
+                    "250" SP ehlo-line CRLF )
+
+
+
+
+
+Klensin                     Standards Track                    [Page 33]
+
+RFC 5321                          SMTP                      October 2008
+
+
+   ehlo-greet     = 1*(%d0-9 / %d11-12 / %d14-127)
+                    ; string of any characters other than CR or LF
+
+   ehlo-line      = ehlo-keyword *( SP ehlo-param )
+
+   ehlo-keyword   = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
+                    ; additional syntax of ehlo-params depends on
+                    ; ehlo-keyword
+
+   ehlo-param     = 1*(%d33-126)
+                    ; any CHAR excluding <SP> and all
+                    ; control characters (US-ASCII 0-31 and 127
+                    ; inclusive)
+
+   Although EHLO keywords may be specified in upper, lower, or mixed
+   case, they MUST always be recognized and processed in a case-
+   insensitive manner.  This is simply an extension of practices
+   specified in RFC 821 and Section 2.4.
+
+   The EHLO response MUST contain keywords (and associated parameters if
+   required) for all commands not listed as "required" in Section 4.5.1
+   excepting only private-use commands as described in Section 4.1.5.
+   Private-use commands MAY be listed.
+
+4.1.1.2.  MAIL (MAIL)
+
+   This command is used to initiate a mail transaction in which the mail
+   data is delivered to an SMTP server that may, in turn, deliver it to
+   one or more mailboxes or pass it on to another system (possibly using
+   SMTP).  The argument clause contains a reverse-path and may contain
+   optional parameters.  In general, the MAIL command may be sent only
+   when no mail transaction is in progress, see Section 4.1.4.
+
+   The reverse-path consists of the sender mailbox.  Historically, that
+   mailbox might optionally have been preceded by a list of hosts, but
+   that behavior is now deprecated (see Appendix C).  In some types of
+   reporting messages for which a reply is likely to cause a mail loop
+   (for example, mail delivery and non-delivery notifications), the
+   reverse-path may be null (see Section 3.6).
+
+   This command clears the reverse-path buffer, the forward-path buffer,
+   and the mail data buffer, and it inserts the reverse-path information
+   from its argument clause into the reverse-path buffer.
+
+   If service extensions were negotiated, the MAIL command may also
+   carry parameters associated with a particular service extension.
+
+
+
+
+
+Klensin                     Standards Track                    [Page 34]
+
+RFC 5321                          SMTP                      October 2008
+
+
+   Syntax:
+
+   mail = "MAIL FROM:" Reverse-path
+                                       [SP Mail-parameters] CRLF
+
+4.1.1.3.  RECIPIENT (RCPT)
+
+   This command is used to identify an individual recipient of the mail
+   data; multiple recipients are specified by multiple uses of this
+   command.  The argument clause contains a forward-path and may contain
+   optional parameters.
+
+   The forward-path normally consists of the required destination
+   mailbox.  Sending systems SHOULD NOT generate the optional list of
+   hosts known as a source route.  Receiving systems MUST recognize
+   source route syntax but SHOULD strip off the source route
+   specification and utilize the domain name associated with the mailbox
+   as if the source route had not been provided.
+
+   Similarly, relay hosts SHOULD strip or ignore source routes, and
+   names MUST NOT be copied into the reverse-path.  When mail reaches
+   its ultimate destination (the forward-path contains only a
+   destination mailbox), the SMTP server inserts it into the destination
+   mailbox in accordance with its host mail conventions.
+
+   This command appends its forward-path argument to the forward-path
+   buffer; it does not change the reverse-path buffer nor the mail data
+   buffer.
+
+   For example, mail received at relay host xyz.com with envelope
+   commands
+
+      MAIL FROM:<userx@y.foo.org>
+      RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org>
+
+   will normally be sent directly on to host d.bar.org with envelope
+   commands
+
+      MAIL FROM:<userx@y.foo.org>
+      RCPT TO:<userc@d.bar.org>
+
+   As provided in Appendix C, xyz.com MAY also choose to relay the
+   message to hosta.int, using the envelope commands
+
+      MAIL FROM:<userx@y.foo.org>
+      RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org>
+
+
+
+
+
+Klensin                     Standards Track                    [Page 35]
+
+RFC 5321                          SMTP                      October 2008
+
+
+   or to jkl.org, using the envelope commands
+
+      MAIL FROM:<userx@y.foo.org>
+      RCPT TO:<@jkl.org:userc@d.bar.org>
+
+   Attempting to use relaying this way is now strongly discouraged.
+   Since hosts are not required to relay mail at all, xyz.com MAY also
+   reject the message entirely when the RCPT command is received, using
+   a 550 code (since this is a "policy reason").
+
+   If service extensions were negotiated, the RCPT command may also
+   carry parameters associated with a particular service extension
+   offered by the server.  The client MUST NOT transmit parameters other
+   than those associated with a service extension offered by the server
+   in its EHLO response.
+
+   Syntax:
+
+      rcpt = "RCPT TO:" ( "<Postmaster@" Domain ">" / "<Postmaster>" /
+                  Forward-path ) [SP Rcpt-parameters] CRLF
+
+                  Note that, in a departure from the usual rules for
+                  local-parts, the "Postmaster" string shown above is
+                  treated as case-insensitive.
+
+4.1.1.4.  DATA (DATA)
+
+   The receiver normally sends a 354 response to DATA, and then treats
+   the lines (strings ending in <CRLF> sequences, as described in
+   Section 2.3.7) following the command as mail data from the sender.
+   This command causes the mail data to be appended to the mail data
+   buffer.  The mail data may contain any of the 128 ASCII character
+   codes, although experience has indicated that use of control
+   characters other than SP, HT, CR, and LF may cause problems and
+   SHOULD be avoided when possible.
+
+   The mail data are terminated by a line containing only a period, that
+   is, the character sequence "<CRLF>.<CRLF>", where the first <CRLF> is
+   actually the terminator of the previous line (see Section 4.5.2).
+   This is the end of mail data indication.  The first <CRLF> of this
+   terminating sequence is also the <CRLF> that ends the final line of
+   the data (message text) or, if there was no mail data, ends the DATA
+   command itself (the "no mail data" case does not conform to this
+   specification since it would require that neither the trace header
+   fields required by this specification nor the message header section
+   required by RFC 5322 [4] be transmitted).  An extra <CRLF> MUST NOT
+   be added, as that would cause an empty line to be added to the
+   message.  The only exception to this rule would arise if the message
+
+
+
+Klensin                     Standards Track                    [Page 36]
+
+RFC 5321                          SMTP                      October 2008
+
+
+   body were passed to the originating SMTP-sender with a final "line"
+   that did not end in <CRLF>; in that case, the originating SMTP system
+   MUST either reject the message as invalid or add <CRLF> in order to
+   have the receiving SMTP server recognize the "end of data" condition.
+
+   The custom of accepting lines ending only in <LF>, as a concession to
+   non-conforming behavior on the part of some UNIX systems, has proven
+   to cause more interoperability problems than it solves, and SMTP
+   server systems MUST NOT do this, even in the name of improved
+   robustness.  In particular, the sequence "<LF>.<LF>" (bare line
+   feeds, without carriage returns) MUST NOT be treated as equivalent to
+   <CRLF>.<CRLF> as the end of mail data indication.
+
+   Receipt of the end of mail data indication requires the server to
+   process the stored mail transaction information.  This processing
+   consumes the information in the reverse-path buffer, the forward-path
+   buffer, and the mail data buffer, and on the completion of this
+   command these buffers are cleared.  If the processing is successful,
+   the receiver MUST send an OK reply.  If the processing fails, the
+   receiver MUST send a failure reply.  The SMTP model does not allow
+   for partial failures at this point: either the message is accepted by
+   the server for delivery and a positive response is returned or it is
+   not accepted and a failure reply is returned.  In sending a positive
+   "250 OK" completion reply to the end of data indication, the receiver
+   takes full responsibility for the message (see Section 6.1).  Errors
+   that are diagnosed subsequently MUST be reported in a mail message,
+   as discussed in Section 4.4.
+
+   When the SMTP server accepts a message either for relaying or for
+   final delivery, it inserts a trace record (also referred to
+   interchangeably as a "time stamp line" or "Received" line) at the top
+   of the mail data.  This trace record indicates the identity of the
+   host that sent the message, the identity of the host that received
+   the message (and is inserting this time stamp), and the date and time
+   the message was received.  Relayed messages will have multiple time
+   stamp lines.  Details for formation of these lines, including their
+   syntax, is specified in Section 4.4.
+
+   Additional discussion about the operation of the DATA command appears
+   in Section 3.3.
+
+   Syntax:
+
+      data = "DATA" CRLF
+
+
+
+
+
+
+
+Klensin                     Standards Track                    [Page 37]
+
+RFC 5321                          SMTP                      October 2008
+
+
+4.1.1.5.  RESET (RSET)
+
+   This command specifies that the current mail transaction will be
+   aborted.  Any stored sender, recipients, and mail data MUST be
+   discarded, and all buffers and state tables cleared.  The receiver
+   MUST send a "250 OK" reply to a RSET command with no arguments.  A
+   reset command may be issued by the client at any time.  It is
+   effectively equivalent to a NOOP (i.e., it has no effect) if issued
+   immediately after EHLO, before EHLO is issued in the session, after
+   an end of data indicator has been sent and acknowledged, or
+   immediately before a QUIT.  An SMTP server MUST NOT close the
+   connection as the result of receiving a RSET; that action is reserved
+   for QUIT (see Section 4.1.1.10).
+
+   Since EHLO implies some additional processing and response by the
+   server, RSET will normally be more efficient than reissuing that
+   command, even though the formal semantics are the same.
+
+   There are circumstances, contrary to the intent of this
+   specification, in which an SMTP server may receive an indication that
+   the underlying TCP connection has been closed or reset.  To preserve
+   the robustness of the mail system, SMTP servers SHOULD be prepared
+   for this condition and SHOULD treat it as if a QUIT had been received
+   before the connection disappeared.
+
+   Syntax:
+
+      rset = "RSET" CRLF
+
+4.1.1.6.  VERIFY (VRFY)
+
+   This command asks the receiver to confirm that the argument
+   identifies a user or mailbox.  If it is a user name, information is
+   returned as specified in Section 3.5.
+
+   This command has no effect on the reverse-path buffer, the forward-
+   path buffer, or the mail data buffer.
+
+   Syntax:
+
+      vrfy = "VRFY" SP String CRLF
+
+
+
+
+
+
+
+
+
+
+Klensin                     Standards Track                    [Page 38]
+
+RFC 5321                          SMTP                      October 2008
+
+
+4.1.1.7.  EXPAND (EXPN)
+
+   This command asks the receiver to confirm that the argument
+   identifies a mailing list, and if so, to return the membership of
+   that list.  If the command is successful, a reply is returned
+   containing information as described in Section 3.5.  This reply will
+   have multiple lines except in the trivial case of a one-member list.
+
+   This command has no effect on the reverse-path buffer, the forward-
+   path buffer, or the mail data buffer, and it may be issued at any
+   time.
+
+   Syntax:
+
+      expn = "EXPN" SP String CRLF
+
+4.1.1.8.  HELP (HELP)
+
+   This command causes the server to send helpful information to the
+   client.  The command MAY take an argument (e.g., any command name)
+   and return more specific information as a response.
+
+   This command has no effect on the reverse-path buffer, the forward-
+   path buffer, or the mail data buffer, and it may be issued at any
+   time.
+
+   SMTP servers SHOULD support HELP without arguments and MAY support it
+   with arguments.
+
+   Syntax:
+
+      help = "HELP" [ SP String ] CRLF
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klensin                     Standards Track                    [Page 39]
+
+RFC 5321                          SMTP                      October 2008
+
+
+4.1.1.9.  NOOP (NOOP)
+
+   This command does not affect any parameters or previously entered
+   commands.  It specifies no action other than that the receiver send a
+   "250 OK" reply.
+
+   This command has no effect on the reverse-path buffer, the forward-
+   path buffer, or the mail data buffer, and it may be issued at any
+   time.  If a parameter string is specified, servers SHOULD ignore it.
+
+   Syntax:
+
+      noop = "NOOP" [ SP String ] CRLF
+
+4.1.1.10.  QUIT (QUIT)
+
+   This command specifies that the receiver MUST send a "221 OK" reply,
+   and then close the transmission channel.
+
+   The receiver MUST NOT intentionally close the transmission channel
+   until it receives and replies to a QUIT command (even if there was an
+   error).  The sender MUST NOT intentionally close the transmission
+   channel until it sends a QUIT command, and it SHOULD wait until it
+   receives the reply (even if there was an error response to a previous
+   command).  If the connection is closed prematurely due to violations
+   of the above or system or network failure, the server MUST cancel any
+   pending transaction, but not undo any previously completed
+   transaction, and generally MUST act as if the command or transaction
+   in progress had received a temporary error (i.e., a 4yz response).
+
+   The QUIT command may be issued at any time.  Any current uncompleted
+   mail transaction will be aborted.
+
+   Syntax:
+
+      quit = "QUIT" CRLF
+
+4.1.1.11.  Mail-Parameter and Rcpt-Parameter Error Responses
+
+   If the server SMTP does not recognize or cannot implement one or more
+   of the parameters associated with a particular MAIL FROM or RCPT TO
+   command, it will return code 555.
+
+   If, for some reason, the server is temporarily unable to accommodate
+   one or more of the parameters associated with a MAIL FROM or RCPT TO
+   command, and if the definition of the specific parameter does not
+   mandate the use of another code, it should return code 455.
+
+
+
+
+Klensin                     Standards Track                    [Page 40]
+
+RFC 5321                          SMTP                      October 2008
+
+
+   Errors specific to particular parameters and their values will be
+   specified in the parameter's defining RFC.
+
+4.1.2.  Command Argument Syntax
+
+   The syntax of the argument clauses of the above commands (using the
+   syntax specified in RFC 5234 [7] where applicable) is given below.
+   Some of the productions given below are used only in conjunction with
+   source routes as described in Appendix C.  Terminals not defined in
+   this document, such as ALPHA, DIGIT, SP, CR, LF, CRLF, are as defined
+   in the "core" syntax in Section 6 of RFC 5234 [7] or in the message
+   format syntax in RFC 5322 [4].
+
+   Reverse-path   = Path / "<>"
+
+   Forward-path   = Path
+
+   Path           = "<" [ A-d-l ":" ] Mailbox ">"
+
+   A-d-l          = At-domain *( "," At-domain )
+                  ; Note that this form, the so-called "source
+                  ; route", MUST BE accepted, SHOULD NOT be
+                  ; generated, and SHOULD be ignored.
+
+   At-domain      = "@" Domain
+
+   Mail-parameters  = esmtp-param *(SP esmtp-param)
+
+   Rcpt-parameters  = esmtp-param *(SP esmtp-param)
+
+   esmtp-param    = esmtp-keyword ["=" esmtp-value]
+
+   esmtp-keyword  = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
+
+   esmtp-value    = 1*(%d33-60 / %d62-126)
+                  ; any CHAR excluding "=", SP, and control
+                  ; characters.  If this string is an email address,
+                  ; i.e., a Mailbox, then the "xtext" syntax [32]
+                  ; SHOULD be used.
+
+   Keyword        = Ldh-str
+
+   Argument       = Atom
+
+   Domain         = sub-domain *("." sub-domain)
+
+
+
+
+
+
+Klensin                     Standards Track                    [Page 41]
+
+RFC 5321                          SMTP                      October 2008
+
+
+   sub-domain     = Let-dig [Ldh-str]
+
+   Let-dig        = ALPHA / DIGIT
+
+   Ldh-str        = *( ALPHA / DIGIT / "-" ) Let-dig
+
+   address-literal  = "[" ( IPv4-address-literal /
+                    IPv6-address-literal /
+                    General-address-literal ) "]"
+                    ; See Section 4.1.3
+
+   Mailbox        = Local-part "@" ( Domain / address-literal )
+
+   Local-part     = Dot-string / Quoted-string
+                  ; MAY be case-sensitive
+
+
+   Dot-string     = Atom *("."  Atom)
+
+   Atom           = 1*atext
+
+   Quoted-string  = DQUOTE *QcontentSMTP DQUOTE
+
+   QcontentSMTP   = qtextSMTP / quoted-pairSMTP
+
+   quoted-pairSMTP  = %d92 %d32-126
+                    ; i.e., backslash followed by any ASCII
+                    ; graphic (including itself) or SPace
+
+   qtextSMTP      = %d32-33 / %d35-91 / %d93-126
+                  ; i.e., within a quoted string, any
+                  ; ASCII graphic or space is permitted
+                  ; without blackslash-quoting except
+                  ; double-quote and the backslash itself.
+
+   String         = Atom / Quoted-string
+
+   While the above definition for Local-part is relatively permissive,
+   for maximum interoperability, a host that expects to receive mail
+   SHOULD avoid defining mailboxes where the Local-part requires (or
+   uses) the Quoted-string form or where the Local-part is case-
+   sensitive.  For any purposes that require generating or comparing
+   Local-parts (e.g., to specific mailbox names), all quoted forms MUST
+   be treated as equivalent, and the sending system SHOULD transmit the
+   form that uses the minimum quoting possible.
+
+   Systems MUST NOT define mailboxes in such a way as to require the use
+   in SMTP of non-ASCII characters (octets with the high order bit set
+
+
+
+Klensin                     Standards Track                    [Page 42]
+
+RFC 5321                          SMTP                      October 2008
+
+
+   to one) or ASCII "control characters" (decimal value 0-31 and 127).
+   These characters MUST NOT be used in MAIL or RCPT commands or other
+   commands that require mailbox names.
+
+   Note that the backslash, "\", is a quote character, which is used to
+   indicate that the next character is to be used literally (instead of
+   its normal interpretation).  For example, "Joe\,Smith" indicates a
+   single nine-character user name string with the comma being the
+   fourth character of that string.
+
+   To promote interoperability and consistent with long-standing
+   guidance about conservative use of the DNS in naming and applications
+   (e.g., see Section 2.3.1 of the base DNS document, RFC 1035 [2]),
+   characters outside the set of alphabetic characters, digits, and
+   hyphen MUST NOT appear in domain name labels for SMTP clients or
+   servers.  In particular, the underscore character is not permitted.
+   SMTP servers that receive a command in which invalid character codes
+   have been employed, and for which there are no other reasons for
+   rejection, MUST reject that command with a 501 response (this rule,
+   like others, could be overridden by appropriate SMTP extensions).
+
+4.1.3.  Address Literals
+
+   Sometimes a host is not known to the domain name system and
+   communication (and, in particular, communication to report and repair
+   the error) is blocked.  To bypass this barrier, a special literal
+   form of the address is allowed as an alternative to a domain name.
+   For IPv4 addresses, this form uses four small decimal integers
+   separated by dots and enclosed by brackets such as [123.255.37.2],
+   which indicates an (IPv4) Internet Address in sequence-of-octets
+   form.  For IPv6 and other forms of addressing that might eventually
+   be standardized, the form consists of a standardized "tag" that
+   identifies the address syntax, a colon, and the address itself, in a
+   format specified as part of the relevant standards (i.e., RFC 4291
+   [8] for IPv6).
+
+   Specifically:
+
+   IPv4-address-literal  = Snum 3("."  Snum)
+
+   IPv6-address-literal  = "IPv6:" IPv6-addr
+
+   General-address-literal  = Standardized-tag ":" 1*dcontent
+
+   Standardized-tag  = Ldh-str
+                     ; Standardized-tag MUST be specified in a
+                     ; Standards-Track RFC and registered with IANA
+
+
+
+
+Klensin                     Standards Track                    [Page 43]
+
+RFC 5321                          SMTP                      October 2008
+
+
+   dcontent       = %d33-90 / ; Printable US-ASCII
+                  %d94-126 ; excl. "[", "\", "]"
+
+   Snum           = 1*3DIGIT
+                  ; representing a decimal integer
+                  ; value in the range 0 through 255
+
+   IPv6-addr      = IPv6-full / IPv6-comp / IPv6v4-full / IPv6v4-comp
+
+   IPv6-hex       = 1*4HEXDIG
+
+   IPv6-full      = IPv6-hex 7(":" IPv6-hex)
+
+   IPv6-comp      = [IPv6-hex *5(":" IPv6-hex)] "::"
+                  [IPv6-hex *5(":" IPv6-hex)]
+                  ; The "::" represents at least 2 16-bit groups of
+                  ; zeros.  No more than 6 groups in addition to the
+                  ; "::" may be present.
+
+   IPv6v4-full    = IPv6-hex 5(":" IPv6-hex) ":" IPv4-address-literal
+
+   IPv6v4-comp    = [IPv6-hex *3(":" IPv6-hex)] "::"
+                  [IPv6-hex *3(":" IPv6-hex) ":"]
+                  IPv4-address-literal
+                  ; The "::" represents at least 2 16-bit groups of
+                  ; zeros.  No more than 4 groups in addition to the
+                  ; "::" and IPv4-address-literal may be present.
+
+4.1.4.  Order of Commands
+
+   There are restrictions on the order in which these commands may be
+   used.
+
+   A session that will contain mail transactions MUST first be
+   initialized by the use of the EHLO command.  An SMTP server SHOULD
+   accept commands for non-mail transactions (e.g., VRFY or EXPN)
+   without this initialization.
+
+   An EHLO command MAY be issued by a client later in the session.  If
+   it is issued after the session begins and the EHLO command is
+   acceptable to the SMTP server, the SMTP server MUST clear all buffers
+   and reset the state exactly as if a RSET command had been issued.  In
+   other words, the sequence of RSET followed immediately by EHLO is
+   redundant, but not harmful other than in the performance cost of
+   executing unnecessary commands.
+
+   If the EHLO command is not acceptable to the SMTP server, 501, 500,
+   502, or 550 failure replies MUST be returned as appropriate.  The
+
+
+
+Klensin                     Standards Track                    [Page 44]
+
+RFC 5321                          SMTP                      October 2008
+
+
+   SMTP server MUST stay in the same state after transmitting these
+   replies that it was in before the EHLO was received.
+
+   The SMTP client MUST, if possible, ensure that the domain parameter
+   to the EHLO command is a primary host name as specified for this
+   command in Section 2.3.5.  If this is not possible (e.g., when the
+   client's address is dynamically assigned and the client does not have
+   an obvious name), an address literal SHOULD be substituted for the
+   domain name.
+
+   An SMTP server MAY verify that the domain name argument in the EHLO
+   command actually corresponds to the IP address of the client.
+   However, if the verification fails, the server MUST NOT refuse to
+   accept a message on that basis.  Information captured in the
+   verification attempt is for logging and tracing purposes.  Note that
+   this prohibition applies to the matching of the parameter to its IP
+   address only; see Section 7.9 for a more extensive discussion of
+   rejecting incoming connections or mail messages.
+
+   The NOOP, HELP, EXPN, VRFY, and RSET commands can be used at any time
+   during a session, or without previously initializing a session.  SMTP
+   servers SHOULD process these normally (that is, not return a 503
+   code) even if no EHLO command has yet been received; clients SHOULD
+   open a session with EHLO before sending these commands.
+
+   If these rules are followed, the example in RFC 821 that shows "550
+   access denied to you" in response to an EXPN command is incorrect
+   unless an EHLO command precedes the EXPN or the denial of access is
+   based on the client's IP address or other authentication or
+   authorization-determining mechanisms.
+
+   The MAIL command (or the obsolete SEND, SOML, or SAML commands)
+   begins a mail transaction.  Once started, a mail transaction consists
+   of a transaction beginning command, one or more RCPT commands, and a
+   DATA command, in that order.  A mail transaction may be aborted by
+   the RSET, a new EHLO, or the QUIT command.  There may be zero or more
+   transactions in a session.  MAIL (or SEND, SOML, or SAML) MUST NOT be
+   sent if a mail transaction is already open, i.e., it should be sent
+   only if no mail transaction had been started in the session, or if
+   the previous one successfully concluded with a successful DATA
+   command, or if the previous one was aborted, e.g., with a RSET or new
+   EHLO.
+
+   If the transaction beginning command argument is not acceptable, a
+   501 failure reply MUST be returned and the SMTP server MUST stay in
+   the same state.  If the commands in a transaction are out of order to
+   the degree that they cannot be processed by the server, a 503 failure
+
+
+
+
+Klensin                     Standards Track                    [Page 45]
+
+RFC 5321                          SMTP                      October 2008
+
+
+   reply MUST be returned and the SMTP server MUST stay in the same
+   state.
+
+   The last command in a session MUST be the QUIT command.  The QUIT
+   command SHOULD be used by the client SMTP to request connection
+   closure, even when no session opening command was sent and accepted.
+
+4.1.5.  Private-Use Commands
+
+   As specified in Section 2.2.2, commands starting in "X" may be used
+   by bilateral agreement between the client (sending) and server
+   (receiving) SMTP agents.  An SMTP server that does not recognize such
+   a command is expected to reply with "500 Command not recognized".  An
+   extended SMTP server MAY list the feature names associated with these
+   private commands in the response to the EHLO command.
+
+   Commands sent or accepted by SMTP systems that do not start with "X"
+   MUST conform to the requirements of Section 2.2.2.
+
+4.2.  SMTP Replies
+
+   Replies to SMTP commands serve to ensure the synchronization of
+   requests and actions in the process of mail transfer and to guarantee
+   that the SMTP client always knows the state of the SMTP server.
+   Every command MUST generate exactly one reply.
+
+   The details of the command-reply sequence are described in
+   Section 4.3.
+
+   An SMTP reply consists of a three digit number (transmitted as three
+   numeric characters) followed by some text unless specified otherwise
+   in this document.  The number is for use by automata to determine
+   what state to enter next; the text is for the human user.  The three
+   digits contain enough encoded information that the SMTP client need
+   not examine the text and may either discard it or pass it on to the
+   user, as appropriate.  Exceptions are as noted elsewhere in this
+   document.  In particular, the 220, 221, 251, 421, and 551 reply codes
+   are associated with message text that must be parsed and interpreted
+   by machines.  In the general case, the text may be receiver dependent
+   and context dependent, so there are likely to be varying texts for
+   each reply code.  A discussion of the theory of reply codes is given
+   in Section 4.2.1.  Formally, a reply is defined to be the sequence: a
+   three-digit code, <SP>, one line of text, and <CRLF>, or a multiline
+   reply (as defined in the same section).  Since, in violation of this
+   specification, the text is sometimes not sent, clients that do not
+   receive it SHOULD be prepared to process the code alone (with or
+   without a trailing space character).  Only the EHLO, EXPN, and HELP
+   commands are expected to result in multiline replies in normal
+
+
+
+Klensin                     Standards Track                    [Page 46]
+
+RFC 5321                          SMTP                      October 2008
+
+
+   circumstances; however, multiline replies are allowed for any
+   command.
+
+   In ABNF, server responses are:
+
+   Greeting       = ( "220 " (Domain / address-literal)
+                  [ SP textstring ] CRLF ) /
+                  ( "220-" (Domain / address-literal)
+                  [ SP textstring ] CRLF
+                  *( "220-" [ textstring ] CRLF )
+                  "220" [ SP textstring ] CRLF )
+
+   textstring     = 1*(%d09 / %d32-126) ; HT, SP, Printable US-ASCII
+
+   Reply-line     = *( Reply-code "-" [ textstring ] CRLF )
+                  Reply-code [ SP textstring ] CRLF
+
+   Reply-code     = %x32-35 %x30-35 %x30-39
+
+   where "Greeting" appears only in the 220 response that announces that
+   the server is opening its part of the connection.  (Other possible
+   server responses upon connection follow the syntax of Reply-line.)
+
+   An SMTP server SHOULD send only the reply codes listed in this
+   document.  An SMTP server SHOULD use the text shown in the examples
+   whenever appropriate.
+
+   An SMTP client MUST determine its actions only by the reply code, not
+   by the text (except for the "change of address" 251 and 551 and, if
+   necessary, 220, 221, and 421 replies); in the general case, any text,
+   including no text at all (although senders SHOULD NOT send bare
+   codes), MUST be acceptable.  The space (blank) following the reply
+   code is considered part of the text.  Whenever possible, a receiver-
+   SMTP SHOULD test the first digit (severity indication) of the reply
+   code.
+
+   The list of codes that appears below MUST NOT be construed as
+   permanent.  While the addition of new codes should be a rare and
+   significant activity, with supplemental information in the textual
+   part of the response being preferred, new codes may be added as the
+   result of new Standards or Standards-Track specifications.
+   Consequently, a sender-SMTP MUST be prepared to handle codes not
+   specified in this document and MUST do so by interpreting the first
+   digit only.
+
+   In the absence of extensions negotiated with the client, SMTP servers
+   MUST NOT send reply codes whose first digits are other than 2, 3, 4,
+
+
+
+
+Klensin                     Standards Track                    [Page 47]
+
+RFC 5321                          SMTP                      October 2008
+
+
+   or 5.  Clients that receive such out-of-range codes SHOULD normally
+   treat them as fatal errors and terminate the mail transaction.
+
+4.2.1.  Reply Code Severities and Theory
+
+   The three digits of the reply each have a special significance.  The
+   first digit denotes whether the response is good, bad, or incomplete.
+   An unsophisticated SMTP client, or one that receives an unexpected
+   code, will be able to determine its next action (proceed as planned,
+   redo, retrench, etc.) by examining this first digit.  An SMTP client
+   that wants to know approximately what kind of error occurred (e.g.,
+   mail system error, command syntax error) may examine the second
+   digit.  The third digit and any supplemental information that may be
+   present is reserved for the finest gradation of information.
+
+   There are four values for the first digit of the reply code:
+
+   2yz  Positive Completion reply
+      The requested action has been successfully completed.  A new
+      request may be initiated.
+
+   3yz  Positive Intermediate reply
+      The command has been accepted, but the requested action is being
+      held in abeyance, pending receipt of further information.  The
+      SMTP client should send another command specifying this
+      information.  This reply is used in command sequence groups (i.e.,
+      in DATA).
+
+   4yz  Transient Negative Completion reply
+      The command was not accepted, and the requested action did not
+      occur.  However, the error condition is temporary, and the action
+      may be requested again.  The sender should return to the beginning
+      of the command sequence (if any).  It is difficult to assign a
+      meaning to "transient" when two different sites (receiver- and
+      sender-SMTP agents) must agree on the interpretation.  Each reply
+      in this category might have a different time value, but the SMTP
+      client SHOULD try again.  A rule of thumb to determine whether a
+      reply fits into the 4yz or the 5yz category (see below) is that
+      replies are 4yz if they can be successful if repeated without any
+      change in command form or in properties of the sender or receiver
+      (that is, the command is repeated identically and the receiver
+      does not put up a new implementation).
+
+   5yz  Permanent Negative Completion reply
+      The command was not accepted and the requested action did not
+      occur.  The SMTP client SHOULD NOT repeat the exact request (in
+      the same sequence).  Even some "permanent" error conditions can be
+      corrected, so the human user may want to direct the SMTP client to
+
+
+
+Klensin                     Standards Track                    [Page 48]
+
+RFC 5321                          SMTP                      October 2008
+
+
+      reinitiate the command sequence by direct action at some point in
+      the future (e.g., after the spelling has been changed, or the user
+      has altered the account status).
+
+   It is worth noting that the file transfer protocol (FTP) [34] uses a
+   very similar code architecture and that the SMTP codes are based on
+   the FTP model.  However, SMTP uses a one-command, one-response model
+   (while FTP is asynchronous) and FTP's 1yz codes are not part of the
+   SMTP model.
+
+   The second digit encodes responses in specific categories:
+
+   x0z  Syntax: These replies refer to syntax errors, syntactically
+      correct commands that do not fit any functional category, and
+      unimplemented or superfluous commands.
+
+   x1z  Information: These are replies to requests for information, such
+      as status or help.
+
+   x2z  Connections: These are replies referring to the transmission
+      channel.
+
+   x3z  Unspecified.
+
+   x4z  Unspecified.
+
+   x5z  Mail system: These replies indicate the status of the receiver
+      mail system vis-a-vis the requested transfer or other mail system
+      action.
+
+   The third digit gives a finer gradation of meaning in each category
+   specified by the second digit.  The list of replies illustrates this.
+   Each reply text is recommended rather than mandatory, and may even
+   change according to the command with which it is associated.  On the
+   other hand, the reply codes must strictly follow the specifications
+   in this section.  Receiver implementations should not invent new
+   codes for slightly different situations from the ones described here,
+   but rather adapt codes already defined.
+
+   For example, a command such as NOOP, whose successful execution does
+   not offer the SMTP client any new information, will return a 250
+   reply.  The reply is 502 when the command requests an unimplemented
+   non-site-specific action.  A refinement of that is the 504 reply for
+   a command that is implemented, but that requests an unimplemented
+   parameter.
+
+
+
+
+
+
+Klensin                     Standards Track                    [Page 49]
+
+RFC 5321                          SMTP                      October 2008
+
+
+   The reply text may be longer than a single line; in these cases the
+   complete text must be marked so the SMTP client knows when it can
+   stop reading the reply.  This requires a special format to indicate a
+   multiple line reply.
+
+   The format for multiline replies requires that every line, except the
+   last, begin with the reply code, followed immediately by a hyphen,
+   "-" (also known as minus), followed by text.  The last line will
+   begin with the reply code, followed immediately by <SP>, optionally
+   some text, and <CRLF>.  As noted above, servers SHOULD send the <SP>
+   if subsequent text is not sent, but clients MUST be prepared for it
+   to be omitted.
+
+   For example:
+
+      250-First line
+      250-Second line
+      250-234 Text beginning with numbers
+      250 The last line
+
+   In a multiline reply, the reply code on each of the lines MUST be the
+   same.  It is reasonable for the client to rely on this, so it can
+   make processing decisions based on the code in any line, assuming
+   that all others will be the same.  In a few cases, there is important
+   data for the client in the reply "text".  The client will be able to
+   identify these cases from the current context.
+
+4.2.2.  Reply Codes by Function Groups
+
+   500  Syntax error, command unrecognized (This may include errors such
+      as command line too long)
+
+   501  Syntax error in parameters or arguments
+
+   502  Command not implemented (see Section 4.2.4)
+
+   503  Bad sequence of commands
+
+   504  Command parameter not implemented
+
+
+   211  System status, or system help reply
+
+   214  Help message (Information on how to use the receiver or the
+      meaning of a particular non-standard command; this reply is useful
+      only to the human user)
+
+
+
+
+
+Klensin                     Standards Track                    [Page 50]
+
+RFC 5321                          SMTP                      October 2008
+
+
+   220  <domain> Service ready
+
+   221  <domain> Service closing transmission channel
+
+   421  <domain> Service not available, closing transmission channel
+      (This may be a reply to any command if the service knows it must
+      shut down)
+
+
+   250  Requested mail action okay, completed
+
+   251  User not local; will forward to <forward-path> (See Section 3.4)
+
+   252  Cannot VRFY user, but will accept message and attempt delivery
+      (See Section 3.5.3)
+
+   455  Server unable to accommodate parameters
+
+   555  MAIL FROM/RCPT TO parameters not recognized or not implemented
+
+   450  Requested mail action not taken: mailbox unavailable (e.g.,
+      mailbox busy or temporarily blocked for policy reasons)
+
+   550  Requested action not taken: mailbox unavailable (e.g., mailbox
+      not found, no access, or command rejected for policy reasons)
+
+   451  Requested action aborted: error in processing
+
+   551  User not local; please try <forward-path> (See Section 3.4)
+
+   452  Requested action not taken: insufficient system storage
+
+   552  Requested mail action aborted: exceeded storage allocation
+
+   553  Requested action not taken: mailbox name not allowed (e.g.,
+      mailbox syntax incorrect)
+
+   354  Start mail input; end with <CRLF>.<CRLF>
+
+   554  Transaction failed (Or, in the case of a connection-opening
+      response, "No SMTP service here")
+
+
+
+
+
+
+
+
+
+
+Klensin                     Standards Track                    [Page 51]
+
+RFC 5321                          SMTP                      October 2008
+
+
+4.2.3.  Reply Codes in Numeric Order
+
+   211  System status, or system help reply
+
+   214  Help message (Information on how to use the receiver or the
+      meaning of a particular non-standard command; this reply is useful
+      only to the human user)
+
+   220  <domain> Service ready
+
+   221  <domain> Service closing transmission channel
+
+   250  Requested mail action okay, completed
+
+   251  User not local; will forward to <forward-path> (See Section 3.4)
+
+   252  Cannot VRFY user, but will accept message and attempt delivery
+      (See Section 3.5.3)
+
+   354  Start mail input; end with <CRLF>.<CRLF>
+
+   421  <domain> Service not available, closing transmission channel
+      (This may be a reply to any command if the service knows it must
+      shut down)
+
+   450  Requested mail action not taken: mailbox unavailable (e.g.,
+      mailbox busy or temporarily blocked for policy reasons)
+
+   451  Requested action aborted: local error in processing
+
+   452  Requested action not taken: insufficient system storage
+
+   455  Server unable to accommodate parameters
+
+   500  Syntax error, command unrecognized (This may include errors such
+      as command line too long)
+
+   501  Syntax error in parameters or arguments
+
+   502  Command not implemented (see Section 4.2.4)
+
+   503  Bad sequence of commands
+
+   504  Command parameter not implemented
+
+   550  Requested action not taken: mailbox unavailable (e.g., mailbox
+      not found, no access, or command rejected for policy reasons)
+
+
+
+
+Klensin                     Standards Track                    [Page 52]
+
+RFC 5321                          SMTP                      October 2008
+
+
+   551  User not local; please try <forward-path> (See Section 3.4)
+
+   552  Requested mail action aborted: exceeded storage allocation
+
+   553  Requested action not taken: mailbox name not allowed (e.g.,
+      mailbox syntax incorrect)
+
+   554  Transaction failed (Or, in the case of a connection-opening
+      response, "No SMTP service here")
+
+   555  MAIL FROM/RCPT TO parameters not recognized or not implemented
+
+4.2.4.  Reply Code 502
+
+   Questions have been raised as to when reply code 502 (Command not
+   implemented) SHOULD be returned in preference to other codes. 502
+   SHOULD be used when the command is actually recognized by the SMTP
+   server, but not implemented.  If the command is not recognized, code
+   500 SHOULD be returned.  Extended SMTP systems MUST NOT list
+   capabilities in response to EHLO for which they will return 502 (or
+   500) replies.
+
+4.2.5.  Reply Codes after DATA and the Subsequent <CRLF>.<CRLF>
+
+   When an SMTP server returns a positive completion status (2yz code)
+   after the DATA command is completed with <CRLF>.<CRLF>, it accepts
+   responsibility for:
+
+   o  delivering the message (if the recipient mailbox exists), or
+
+   o  if attempts to deliver the message fail due to transient
+      conditions, retrying delivery some reasonable number of times at
+      intervals as specified in Section 4.5.4.
+
+   o  if attempts to deliver the message fail due to permanent
+      conditions, or if repeated attempts to deliver the message fail
+      due to transient conditions, returning appropriate notification to
+      the sender of the original message (using the address in the SMTP
+      MAIL command).
+
+   When an SMTP server returns a temporary error status (4yz) code after
+   the DATA command is completed with <CRLF>.<CRLF>, it MUST NOT make a
+   subsequent attempt to deliver that message.  The SMTP client retains
+   responsibility for the delivery of that message and may either return
+   it to the user or requeue it for a subsequent attempt (see
+   Section 4.5.4.1).
+
+
+
+
+
+Klensin                     Standards Track                    [Page 53]
+
+RFC 5321                          SMTP                      October 2008
+
+
+   The user who originated the message SHOULD be able to interpret the
+   return of a transient failure status (by mail message or otherwise)
+   as a non-delivery indication, just as a permanent failure would be
+   interpreted.  If the client SMTP successfully handles these
+   conditions, the user will not receive such a reply.
+
+   When an SMTP server returns a permanent error status (5yz) code after
+   the DATA command is completed with <CRLF>.<CRLF>, it MUST NOT make
+   any subsequent attempt to deliver the message.  As with temporary
+   error status codes, the SMTP client retains responsibility for the
+   message, but SHOULD not again attempt delivery to the same server
+   without user review of the message and response and appropriate
+   intervention.
+
+4.3.  Sequencing of Commands and Replies
+
+4.3.1.  Sequencing Overview
+
+   The communication between the sender and receiver is an alternating
+   dialogue, controlled by the sender.  As such, the sender issues a
+   command and the receiver responds with a reply.  Unless other
+   arrangements are negotiated through service extensions, the sender
+   MUST wait for this response before sending further commands.  One
+   important reply is the connection greeting.  Normally, a receiver
+   will send a 220 "Service ready" reply when the connection is
+   completed.  The sender SHOULD wait for this greeting message before
+   sending any commands.
+
+   Note: all the greeting-type replies have the official name (the
+   fully-qualified primary domain name) of the server host as the first
+   word following the reply code.  Sometimes the host will have no
+   meaningful name.  See Section 4.1.3 for a discussion of alternatives
+   in these situations.
+
+   For example,
+
+      220 ISIF.USC.EDU Service ready
+
+   or
+
+      220 mail.example.com SuperSMTP v 6.1.2 Service ready
+
+   or
+
+      220 [10.0.0.1] Clueless host service ready
+
+   The table below lists alternative success and failure replies for
+   each command.  These SHOULD be strictly adhered to.  A receiver MAY
+
+
+
+Klensin                     Standards Track                    [Page 54]
+
+RFC 5321                          SMTP                      October 2008
+
+
+   substitute text in the replies, but the meanings and actions implied
+   by the code numbers and by the specific command reply sequence MUST
+   be preserved.
+
+4.3.2.  Command-Reply Sequences
+
+   Each command is listed with its usual possible replies.  The prefixes
+   used before the possible replies are "I" for intermediate, "S" for
+   success, and "E" for error.  Since some servers may generate other
+   replies under special circumstances, and to allow for future
+   extension, SMTP clients SHOULD, when possible, interpret only the
+   first digit of the reply and MUST be prepared to deal with
+   unrecognized reply codes by interpreting the first digit only.
+   Unless extended using the mechanisms described in Section 2.2, SMTP
+   servers MUST NOT transmit reply codes to an SMTP client that are
+   other than three digits or that do not start in a digit between 2 and
+   5 inclusive.
+
+   These sequencing rules and, in principle, the codes themselves, can
+   be extended or modified by SMTP extensions offered by the server and
+   accepted (requested) by the client.  However, if the target is more
+   precise granularity in the codes, rather than codes for completely
+   new purposes, the system described in RFC 3463 [25] SHOULD be used in
+   preference to the invention of new codes.
+
+   In addition to the codes listed below, any SMTP command can return
+   any of the following codes if the corresponding unusual circumstances
+   are encountered:
+
+   500  For the "command line too long" case or if the command name was
+      not recognized.  Note that producing a "command not recognized"
+      error in response to the required subset of these commands is a
+      violation of this specification.  Similarly, producing a "command
+      too long" message for a command line shorter than 512 characters
+      would violate the provisions of Section 4.5.3.1.4.
+
+   501  Syntax error in command or arguments.  In order to provide for
+      future extensions, commands that are specified in this document as
+      not accepting arguments (DATA, RSET, QUIT) SHOULD return a 501
+      message if arguments are supplied in the absence of EHLO-
+      advertised extensions.
+
+   421  Service shutting down and closing transmission channel
+
+
+
+
+
+
+
+
+Klensin                     Standards Track                    [Page 55]
+
+RFC 5321                          SMTP                      October 2008
+
+
+   Specific sequences are:
+
+      CONNECTION ESTABLISHMENT
+
+         S: 220
+         E: 554
+
+      EHLO or HELO
+
+         S: 250
+         E: 504 (a conforming implementation could return this code only
+         in fairly obscure cases), 550, 502 (permitted only with an old-
+         style server that does not support EHLO)
+
+      MAIL
+
+         S: 250
+         E: 552, 451, 452, 550, 553, 503, 455, 555
+
+      RCPT
+
+         S: 250, 251 (but see Section 3.4 for discussion of 251 and 551)
+         E: 550, 551, 552, 553, 450, 451, 452, 503, 455, 555
+
+      DATA
+
+         I: 354 -> data -> S: 250
+
+                           E: 552, 554, 451, 452
+
+                           E: 450, 550 (rejections for policy reasons)
+
+         E: 503, 554
+
+      RSET
+
+         S: 250
+
+      VRFY
+
+         S: 250, 251, 252
+         E: 550, 551, 553, 502, 504
+
+      EXPN
+
+         S: 250, 252
+         E: 550, 500, 502, 504
+
+
+
+
+Klensin                     Standards Track                    [Page 56]
+
+RFC 5321                          SMTP                      October 2008
+
+
+      HELP
+
+         S: 211, 214
+         E: 502, 504
+
+      NOOP
+
+         S: 250
+
+      QUIT
+
+         S: 221
+
+4.4.  Trace Information
+
+   When an SMTP server receives a message for delivery or further
+   processing, it MUST insert trace ("time stamp" or "Received")
+   information at the beginning of the message content, as discussed in
+   Section 4.1.1.4.
+
+   This line MUST be structured as follows:
+
+   o  The FROM clause, which MUST be supplied in an SMTP environment,
+      SHOULD contain both (1) the name of the source host as presented
+      in the EHLO command and (2) an address literal containing the IP
+      address of the source, determined from the TCP connection.
+
+   o  The ID clause MAY contain an "@" as suggested in RFC 822, but this
+      is not required.
+
+   o  If the FOR clause appears, it MUST contain exactly one <path>
+      entry, even when multiple RCPT commands have been given.  Multiple
+      <path>s raise some security issues and have been deprecated, see
+      Section 7.2.
+
+   An Internet mail program MUST NOT change or delete a Received: line
+   that was previously added to the message header section.  SMTP
+   servers MUST prepend Received lines to messages; they MUST NOT change
+   the order of existing lines or insert Received lines in any other
+   location.
+
+   As the Internet grows, comparability of Received header fields is
+   important for detecting problems, especially slow relays.  SMTP
+   servers that create Received header fields SHOULD use explicit
+   offsets in the dates (e.g., -0800), rather than time zone names of
+   any type.  Local time (with an offset) SHOULD be used rather than UT
+   when feasible.  This formulation allows slightly more information
+   about local circumstances to be specified.  If UT is needed, the
+
+
+
+Klensin                     Standards Track                    [Page 57]
+
+RFC 5321                          SMTP                      October 2008
+
+
+   receiver need merely do some simple arithmetic to convert the values.
+   Use of UT loses information about the time zone-location of the
+   server.  If it is desired to supply a time zone name, it SHOULD be
+   included in a comment.
+
+   When the delivery SMTP server makes the "final delivery" of a
+   message, it inserts a return-path line at the beginning of the mail
+   data.  This use of return-path is required; mail systems MUST support
+   it.  The return-path line preserves the information in the <reverse-
+   path> from the MAIL command.  Here, final delivery means the message
+   has left the SMTP environment.  Normally, this would mean it had been
+   delivered to the destination user or an associated mail drop, but in
+   some cases it may be further processed and transmitted by another
+   mail system.
+
+   It is possible for the mailbox in the return path to be different
+   from the actual sender's mailbox, for example, if error responses are
+   to be delivered to a special error handling mailbox rather than to
+   the message sender.  When mailing lists are involved, this
+   arrangement is common and useful as a means of directing errors to
+   the list maintainer rather than the message originator.
+
+   The text above implies that the final mail data will begin with a
+   return path line, followed by one or more time stamp lines.  These
+   lines will be followed by the rest of the mail data: first the
+   balance of the mail header section and then the body (RFC 5322 [4]).
+
+   It is sometimes difficult for an SMTP server to determine whether or
+   not it is making final delivery since forwarding or other operations
+   may occur after the message is accepted for delivery.  Consequently,
+   any further (forwarding, gateway, or relay) systems MAY remove the
+   return path and rebuild the MAIL command as needed to ensure that
+   exactly one such line appears in a delivered message.
+
+   A message-originating SMTP system SHOULD NOT send a message that
+   already contains a Return-path header field.  SMTP servers performing
+   a relay function MUST NOT inspect the message data, and especially
+   not to the extent needed to determine if Return-path header fields
+   are present.  SMTP servers making final delivery MAY remove Return-
+   path header fields before adding their own.
+
+   The primary purpose of the Return-path is to designate the address to
+   which messages indicating non-delivery or other mail system failures
+   are to be sent.  For this to be unambiguous, exactly one return path
+   SHOULD be present when the message is delivered.  Systems using RFC
+   822 syntax with non-SMTP transports SHOULD designate an unambiguous
+   address, associated with the transport envelope, to which error
+   reports (e.g., non-delivery messages) should be sent.
+
+
+
+Klensin                     Standards Track                    [Page 58]
+
+RFC 5321                          SMTP                      October 2008
+
+
+   Historical note: Text in RFC 822 that appears to contradict the use
+   of the Return-path header field (or the envelope reverse-path address
+   from the MAIL command) as the destination for error messages is not
+   applicable on the Internet.  The reverse-path address (as copied into
+   the Return-path) MUST be used as the target of any mail containing
+   delivery error messages.
+
+   In particular:
+   o  a gateway from SMTP -> elsewhere SHOULD insert a return-path
+      header field, unless it is known that the "elsewhere" transport
+      also uses Internet domain addresses and maintains the envelope
+      sender address separately.
+
+   o  a gateway from elsewhere -> SMTP SHOULD delete any return-path
+      header field present in the message, and either copy that
+      information to the SMTP envelope or combine it with information
+      present in the envelope of the other transport system to construct
+      the reverse-path argument to the MAIL command in the SMTP
+      envelope.
+
+   The server must give special treatment to cases in which the
+   processing following the end of mail data indication is only
+   partially successful.  This could happen if, after accepting several
+   recipients and the mail data, the SMTP server finds that the mail
+   data could be successfully delivered to some, but not all, of the
+   recipients.  In such cases, the response to the DATA command MUST be
+   an OK reply.  However, the SMTP server MUST compose and send an
+   "undeliverable mail" notification message to the originator of the
+   message.
+
+   A single notification listing all of the failed recipients or
+   separate notification messages MUST be sent for each failed
+   recipient.  For economy of processing by the sender, the former
+   SHOULD be used when possible.  Note that the key difference between
+   handling aliases (Section 3.9.1) and forwarding (this subsection) is
+   the change to the backward-pointing address in this case.  All
+   notification messages about undeliverable mail MUST be sent using the
+   MAIL command (even if they result from processing the obsolete SEND,
+   SOML, or SAML commands) and MUST use a null return path as discussed
+   in Section 3.6.
+
+   The time stamp line and the return path line are formally defined as
+   follows (the definitions for "FWS" and "CFWS" appear in RFC 5322
+   [4]):
+
+   Return-path-line  = "Return-Path:" FWS Reverse-path <CRLF>
+
+   Time-stamp-line  = "Received:" FWS Stamp <CRLF>
+
+
+
+Klensin                     Standards Track                    [Page 59]
+
+RFC 5321                          SMTP                      October 2008
+
+
+   Stamp          = From-domain By-domain Opt-info [CFWS] ";"
+                  FWS date-time
+                  ; where "date-time" is as defined in RFC 5322 [4]
+                  ; but the "obs-" forms, especially two-digit
+                  ; years, are prohibited in SMTP and MUST NOT be used.
+
+   From-domain    = "FROM" FWS Extended-Domain
+
+   By-domain      = CFWS "BY" FWS Extended-Domain
+
+   Extended-Domain  = Domain /
+                    ( Domain FWS "(" TCP-info ")" ) /
+                    ( address-literal FWS "(" TCP-info ")" )
+
+   TCP-info       = address-literal / ( Domain FWS address-literal )
+                  ; Information derived by server from TCP connection
+                  ; not client EHLO.
+
+   Opt-info       = [Via] [With] [ID] [For]
+                  [Additional-Registered-Clauses]
+
+   Via            = CFWS "VIA" FWS Link
+
+   With           = CFWS "WITH" FWS Protocol
+
+   ID             = CFWS "ID" FWS ( Atom / msg-id )
+                  ; msg-id is defined in RFC 5322 [4]
+
+   For            = CFWS "FOR" FWS ( Path / Mailbox )
+
+   Additional-Registered-Clauses  = CFWS Atom FWS String
+                                  ; Additional standard clauses may be
+                                  added in this
+                                  ; location by future standards and
+                                  registration with
+                                  ; IANA.  SMTP servers SHOULD NOT use
+                                  unregistered
+                                  ; names.  See Section 8.
+
+   Link           = "TCP" / Addtl-Link
+
+   Addtl-Link     = Atom
+                  ; Additional standard names for links are
+                  ; registered with the Internet Assigned Numbers
+                  ; Authority (IANA).  "Via" is primarily of value
+                  ; with non-Internet transports.  SMTP servers
+                  ; SHOULD NOT use unregistered names.
+
+
+
+
+Klensin                     Standards Track                    [Page 60]
+
+RFC 5321                          SMTP                      October 2008
+
+
+   Protocol       = "ESMTP" / "SMTP" / Attdl-Protocol
+
+   Attdl-Protocol = Atom
+                  ; Additional standard names for protocols are
+                  ; registered with the Internet Assigned Numbers
+                  ; Authority (IANA) in the "mail parameters"
+                  ; registry [9].  SMTP servers SHOULD NOT
+                  ; use unregistered names.
+
+4.5.  Additional Implementation Issues
+
+4.5.1.  Minimum Implementation
+
+   In order to make SMTP workable, the following minimum implementation
+   MUST be provided by all receivers.  The following commands MUST be
+   supported to conform to this specification:
+
+      EHLO
+      HELO
+      MAIL
+      RCPT
+      DATA
+      RSET
+      NOOP
+      QUIT
+      VRFY
+
+   Any system that includes an SMTP server supporting mail relaying or
+   delivery MUST support the reserved mailbox "postmaster" as a case-
+   insensitive local name.  This postmaster address is not strictly
+   necessary if the server always returns 554 on connection opening (as
+   described in Section 3.1).  The requirement to accept mail for
+   postmaster implies that RCPT commands that specify a mailbox for
+   postmaster at any of the domains for which the SMTP server provides
+   mail service, as well as the special case of "RCPT TO:<Postmaster>"
+   (with no domain specification), MUST be supported.
+
+   SMTP systems are expected to make every reasonable effort to accept
+   mail directed to Postmaster from any other system on the Internet.
+   In extreme cases -- such as to contain a denial of service attack or
+   other breach of security -- an SMTP server may block mail directed to
+   Postmaster.  However, such arrangements SHOULD be narrowly tailored
+   so as to avoid blocking messages that are not part of such attacks.
+
+
+
+
+
+
+
+
+Klensin                     Standards Track                    [Page 61]
+
+RFC 5321                          SMTP                      October 2008
+
+
+4.5.2.  Transparency
+
+   Without some provision for data transparency, the character sequence
+   "<CRLF>.<CRLF>" ends the mail text and cannot be sent by the user.
+   In general, users are not aware of such "forbidden" sequences.  To
+   allow all user composed text to be transmitted transparently, the
+   following procedures are used:
+
+   o  Before sending a line of mail text, the SMTP client checks the
+      first character of the line.  If it is a period, one additional
+      period is inserted at the beginning of the line.
+
+   o  When a line of mail text is received by the SMTP server, it checks
+      the line.  If the line is composed of a single period, it is
+      treated as the end of mail indicator.  If the first character is a
+      period and there are other characters on the line, the first
+      character is deleted.
+
+   The mail data may contain any of the 128 ASCII characters.  All
+   characters are to be delivered to the recipient's mailbox, including
+   spaces, vertical and horizontal tabs, and other control characters.
+   If the transmission channel provides an 8-bit byte (octet) data
+   stream, the 7-bit ASCII codes are transmitted, right justified, in
+   the octets, with the high-order bits cleared to zero.  See
+   Section 3.6 for special treatment of these conditions in SMTP systems
+   serving a relay function.
+
+   In some systems, it may be necessary to transform the data as it is
+   received and stored.  This may be necessary for hosts that use a
+   different character set than ASCII as their local character set, that
+   store data in records rather than strings, or which use special
+   character sequences as delimiters inside mailboxes.  If such
+   transformations are necessary, they MUST be reversible, especially if
+   they are applied to mail being relayed.
+
+4.5.3.  Sizes and Timeouts
+
+4.5.3.1.  Size Limits and Minimums
+
+   There are several objects that have required minimum/maximum sizes.
+   Every implementation MUST be able to receive objects of at least
+   these sizes.  Objects larger than these sizes SHOULD be avoided when
+   possible.  However, some Internet mail constructs such as encoded
+   X.400 addresses (RFC 2156 [35]) will often require larger objects.
+   Clients MAY attempt to transmit these, but MUST be prepared for a
+   server to reject them if they cannot be handled by it.  To the
+   maximum extent possible, implementation techniques that impose no
+   limits on the length of these objects should be used.
+
+
+
+Klensin                     Standards Track                    [Page 62]
+
+RFC 5321                          SMTP                      October 2008
+
+
+   Extensions to SMTP may involve the use of characters that occupy more
+   than a single octet each.  This section therefore specifies lengths
+   in octets where absolute lengths, rather than character counts, are
+   intended.
+
+4.5.3.1.1.  Local-part
+
+   The maximum total length of a user name or other local-part is 64
+   octets.
+
+4.5.3.1.2.  Domain
+
+   The maximum total length of a domain name or number is 255 octets.
+
+4.5.3.1.3.  Path
+
+   The maximum total length of a reverse-path or forward-path is 256
+   octets (including the punctuation and element separators).
+
+4.5.3.1.4.  Command Line
+
+   The maximum total length of a command line including the command word
+   and the <CRLF> is 512 octets.  SMTP extensions may be used to
+   increase this limit.
+
+4.5.3.1.5.  Reply Line
+
+   The maximum total length of a reply line including the reply code and
+   the <CRLF> is 512 octets.  More information may be conveyed through
+   multiple-line replies.
+
+4.5.3.1.6.  Text Line
+
+   The maximum total length of a text line including the <CRLF> is 1000
+   octets (not counting the leading dot duplicated for transparency).
+   This number may be increased by the use of SMTP Service Extensions.
+
+4.5.3.1.7.  Message Content
+
+   The maximum total length of a message content (including any message
+   header section as well as the message body) MUST BE at least 64K
+   octets.  Since the introduction of Internet Standards for multimedia
+   mail (RFC 2045 [21]), message lengths on the Internet have grown
+   dramatically, and message size restrictions should be avoided if at
+   all possible.  SMTP server systems that must impose restrictions
+   SHOULD implement the "SIZE" service extension of RFC 1870 [10], and
+   SMTP client systems that will send large messages SHOULD utilize it
+   when possible.
+
+
+
+Klensin                     Standards Track                    [Page 63]
+
+RFC 5321                          SMTP                      October 2008
+
+
+4.5.3.1.8.  Recipients Buffer
+
+   The minimum total number of recipients that MUST be buffered is 100
+   recipients.  Rejection of messages (for excessive recipients) with
+   fewer than 100 RCPT commands is a violation of this specification.
+   The general principle that relaying SMTP server MUST NOT, and
+   delivery SMTP servers SHOULD NOT, perform validation tests on message
+   header fields suggests that messages SHOULD NOT be rejected based on
+   the total number of recipients shown in header fields.  A server that
+   imposes a limit on the number of recipients MUST behave in an orderly
+   fashion, such as rejecting additional addresses over its limit rather
+   than silently discarding addresses previously accepted.  A client
+   that needs to deliver a message containing over 100 RCPT commands
+   SHOULD be prepared to transmit in 100-recipient "chunks" if the
+   server declines to accept more than 100 recipients in a single
+   message.
+
+4.5.3.1.9.  Treatment When Limits Exceeded
+
+   Errors due to exceeding these limits may be reported by using the
+   reply codes.  Some examples of reply codes are:
+
+      500 Line too long.
+
+   or
+
+      501 Path too long
+
+   or
+
+      452 Too many recipients (see below)
+
+   or
+
+      552 Too much mail data.
+
+4.5.3.1.10.  Too Many Recipients Code
+
+   RFC 821 [1] incorrectly listed the error where an SMTP server
+   exhausts its implementation limit on the number of RCPT commands
+   ("too many recipients") as having reply code 552.  The correct reply
+   code for this condition is 452.  Clients SHOULD treat a 552 code in
+   this case as a temporary, rather than permanent, failure so the logic
+   below works.
+
+   When a conforming SMTP server encounters this condition, it has at
+   least 100 successful RCPT commands in its recipients buffer.  If the
+   server is able to accept the message, then at least these 100
+
+
+
+Klensin                     Standards Track                    [Page 64]
+
+RFC 5321                          SMTP                      October 2008
+
+
+   addresses will be removed from the SMTP client's queue.  When the
+   client attempts retransmission of those addresses that received 452
+   responses, at least 100 of these will be able to fit in the SMTP
+   server's recipients buffer.  Each retransmission attempt that is able
+   to deliver anything will be able to dispose of at least 100 of these
+   recipients.
+
+   If an SMTP server has an implementation limit on the number of RCPT
+   commands and this limit is exhausted, it MUST use a response code of
+   452 (but the client SHOULD also be prepared for a 552, as noted
+   above).  If the server has a configured site-policy limitation on the
+   number of RCPT commands, it MAY instead use a 5yz response code.  In
+   particular, if the intent is to prohibit messages with more than a
+   site-specified number of recipients, rather than merely limit the
+   number of recipients in a given mail transaction, it would be
+   reasonable to return a 503 response to any DATA command received
+   subsequent to the 452 (or 552) code or to simply return the 503 after
+   DATA without returning any previous negative response.
+
+4.5.3.2.  Timeouts
+
+   An SMTP client MUST provide a timeout mechanism.  It MUST use per-
+   command timeouts rather than somehow trying to time the entire mail
+   transaction.  Timeouts SHOULD be easily reconfigurable, preferably
+   without recompiling the SMTP code.  To implement this, a timer is set
+   for each SMTP command and for each buffer of the data transfer.  The
+   latter means that the overall timeout is inherently proportional to
+   the size of the message.
+
+   Based on extensive experience with busy mail-relay hosts, the minimum
+   per-command timeout values SHOULD be as follows:
+
+4.5.3.2.1.  Initial 220 Message: 5 Minutes
+
+   An SMTP client process needs to distinguish between a failed TCP
+   connection and a delay in receiving the initial 220 greeting message.
+   Many SMTP servers accept a TCP connection but delay delivery of the
+   220 message until their system load permits more mail to be
+   processed.
+
+4.5.3.2.2.  MAIL Command: 5 Minutes
+
+4.5.3.2.3.  RCPT Command: 5 Minutes
+
+   A longer timeout is required if processing of mailing lists and
+   aliases is not deferred until after the message was accepted.
+
+
+
+
+
+Klensin                     Standards Track                    [Page 65]
+
+RFC 5321                          SMTP                      October 2008
+
+
+4.5.3.2.4.  DATA Initiation: 2 Minutes
+
+   This is while awaiting the "354 Start Input" reply to a DATA command.
+
+4.5.3.2.5.  Data Block: 3 Minutes
+
+   This is while awaiting the completion of each TCP SEND call
+   transmitting a chunk of data.
+
+4.5.3.2.6.  DATA Termination: 10 Minutes.
+
+   This is while awaiting the "250 OK" reply.  When the receiver gets
+   the final period terminating the message data, it typically performs
+   processing to deliver the message to a user mailbox.  A spurious
+   timeout at this point would be very wasteful and would typically
+   result in delivery of multiple copies of the message, since it has
+   been successfully sent and the server has accepted responsibility for
+   delivery.  See Section 6.1 for additional discussion.
+
+4.5.3.2.7.  Server Timeout: 5 Minutes.
+
+   An SMTP server SHOULD have a timeout of at least 5 minutes while it
+   is awaiting the next command from the sender.
+
+4.5.4.  Retry Strategies
+
+   The common structure of a host SMTP implementation includes user
+   mailboxes, one or more areas for queuing messages in transit, and one
+   or more daemon processes for sending and receiving mail.  The exact
+   structure will vary depending on the needs of the users on the host
+   and the number and size of mailing lists supported by the host.  We
+   describe several optimizations that have proved helpful, particularly
+   for mailers supporting high traffic levels.
+
+   Any queuing strategy MUST include timeouts on all activities on a
+   per-command basis.  A queuing strategy MUST NOT send error messages
+   in response to error messages under any circumstances.
+
+4.5.4.1.  Sending Strategy
+
+   The general model for an SMTP client is one or more processes that
+   periodically attempt to transmit outgoing mail.  In a typical system,
+   the program that composes a message has some method for requesting
+   immediate attention for a new piece of outgoing mail, while mail that
+   cannot be transmitted immediately MUST be queued and periodically
+   retried by the sender.  A mail queue entry will include not only the
+   message itself but also the envelope information.
+
+
+
+
+Klensin                     Standards Track                    [Page 66]
+
+RFC 5321                          SMTP                      October 2008
+
+
+   The sender MUST delay retrying a particular destination after one
+   attempt has failed.  In general, the retry interval SHOULD be at
+   least 30 minutes; however, more sophisticated and variable strategies
+   will be beneficial when the SMTP client can determine the reason for
+   non-delivery.
+
+   Retries continue until the message is transmitted or the sender gives
+   up; the give-up time generally needs to be at least 4-5 days.  It MAY
+   be appropriate to set a shorter maximum number of retries for non-
+   delivery notifications and equivalent error messages than for
+   standard messages.  The parameters to the retry algorithm MUST be
+   configurable.
+
+   A client SHOULD keep a list of hosts it cannot reach and
+   corresponding connection timeouts, rather than just retrying queued
+   mail items.
+
+   Experience suggests that failures are typically transient (the target
+   system or its connection has crashed), favoring a policy of two
+   connection attempts in the first hour the message is in the queue,
+   and then backing off to one every two or three hours.
+
+   The SMTP client can shorten the queuing delay in cooperation with the
+   SMTP server.  For example, if mail is received from a particular
+   address, it is likely that mail queued for that host can now be sent.
+   Application of this principle may, in many cases, eliminate the
+   requirement for an explicit "send queues now" function such as ETRN,
+   RFC 1985 [36].
+
+   The strategy may be further modified as a result of multiple
+   addresses per host (see below) to optimize delivery time versus
+   resource usage.
+
+   An SMTP client may have a large queue of messages for each
+   unavailable destination host.  If all of these messages were retried
+   in every retry cycle, there would be excessive Internet overhead and
+   the sending system would be blocked for a long period.  Note that an
+   SMTP client can generally determine that a delivery attempt has
+   failed only after a timeout of several minutes, and even a one-minute
+   timeout per connection will result in a very large delay if retries
+   are repeated for dozens, or even hundreds, of queued messages to the
+   same host.
+
+   At the same time, SMTP clients SHOULD use great care in caching
+   negative responses from servers.  In an extreme case, if EHLO is
+   issued multiple times during the same SMTP connection, different
+   answers may be returned by the server.  More significantly, 5yz
+   responses to the MAIL command MUST NOT be cached.
+
+
+
+Klensin                     Standards Track                    [Page 67]
+
+RFC 5321                          SMTP                      October 2008
+
+
+   When a mail message is to be delivered to multiple recipients, and
+   the SMTP server to which a copy of the message is to be sent is the
+   same for multiple recipients, then only one copy of the message
+   SHOULD be transmitted.  That is, the SMTP client SHOULD use the
+   command sequence: MAIL, RCPT, RCPT, ..., RCPT, DATA instead of the
+   sequence: MAIL, RCPT, DATA, ..., MAIL, RCPT, DATA.  However, if there
+   are very many addresses, a limit on the number of RCPT commands per
+   MAIL command MAY be imposed.  This efficiency feature SHOULD be
+   implemented.
+
+   Similarly, to achieve timely delivery, the SMTP client MAY support
+   multiple concurrent outgoing mail transactions.  However, some limit
+   may be appropriate to protect the host from devoting all its
+   resources to mail.
+
+4.5.4.2.  Receiving Strategy
+
+   The SMTP server SHOULD attempt to keep a pending listen on the SMTP
+   port (specified by IANA as port 25) at all times.  This requires the
+   support of multiple incoming TCP connections for SMTP.  Some limit
+   MAY be imposed, but servers that cannot handle more than one SMTP
+   transaction at a time are not in conformance with the intent of this
+   specification.
+
+   As discussed above, when the SMTP server receives mail from a
+   particular host address, it could activate its own SMTP queuing
+   mechanisms to retry any mail pending for that host address.
+
+4.5.5.  Messages with a Null Reverse-Path
+
+   There are several types of notification messages that are required by
+   existing and proposed Standards to be sent with a null reverse-path,
+   namely non-delivery notifications as discussed in Section 3.7, other
+   kinds of Delivery Status Notifications (DSNs, RFC 3461 [32]), and
+   Message Disposition Notifications (MDNs, RFC 3798 [37]).  All of
+   these kinds of messages are notifications about a previous message,
+   and they are sent to the reverse-path of the previous mail message.
+   (If the delivery of such a notification message fails, that usually
+   indicates a problem with the mail system of the host to which the
+   notification message is addressed.  For this reason, at some hosts
+   the MTA is set up to forward such failed notification messages to
+   someone who is able to fix problems with the mail system, e.g., via
+   the postmaster alias.)
+
+   All other types of messages (i.e., any message which is not required
+   by a Standards-Track RFC to have a null reverse-path) SHOULD be sent
+   with a valid, non-null reverse-path.
+
+
+
+
+Klensin                     Standards Track                    [Page 68]
+
+RFC 5321                          SMTP                      October 2008
+
+
+   Implementers of automated email processors should be careful to make
+   sure that the various kinds of messages with a null reverse-path are
+   handled correctly.  In particular, such systems SHOULD NOT reply to
+   messages with a null reverse-path, and they SHOULD NOT add a non-null
+   reverse-path, or change a null reverse-path to a non-null one, to
+   such messages when forwarding.
+
+5.  Address Resolution and Mail Handling
+
+5.1.  Locating the Target Host
+
+   Once an SMTP client lexically identifies a domain to which mail will
+   be delivered for processing (as described in Sections 2.3.5 and 3.6),
+   a DNS lookup MUST be performed to resolve the domain name (RFC 1035
+   [2]).  The names are expected to be fully-qualified domain names
+   (FQDNs): mechanisms for inferring FQDNs from partial names or local
+   aliases are outside of this specification.  Due to a history of
+   problems, SMTP servers used for initial submission of messages SHOULD
+   NOT make such inferences (Message Submission Servers [18] have
+   somewhat more flexibility) and intermediate (relay) SMTP servers MUST
+   NOT make them.
+
+   The lookup first attempts to locate an MX record associated with the
+   name.  If a CNAME record is found, the resulting name is processed as
+   if it were the initial name.  If a non-existent domain error is
+   returned, this situation MUST be reported as an error.  If a
+   temporary error is returned, the message MUST be queued and retried
+   later (see Section 4.5.4.1).  If an empty list of MXs is returned,
+   the address is treated as if it was associated with an implicit MX
+   RR, with a preference of 0, pointing to that host.  If MX records are
+   present, but none of them are usable, or the implicit MX is unusable,
+   this situation MUST be reported as an error.
+
+   If one or more MX RRs are found for a given name, SMTP systems MUST
+   NOT utilize any address RRs associated with that name unless they are
+   located using the MX RRs; the "implicit MX" rule above applies only
+   if there are no MX records present.  If MX records are present, but
+   none of them are usable, this situation MUST be reported as an error.
+
+   When a domain name associated with an MX RR is looked up and the
+   associated data field obtained, the data field of that response MUST
+   contain a domain name.  That domain name, when queried, MUST return
+   at least one address record (e.g., A or AAAA RR) that gives the IP
+   address of the SMTP server to which the message should be directed.
+   Any other response, specifically including a value that will return a
+   CNAME record when queried, lies outside the scope of this Standard.
+   The prohibition on labels in the data that resolve to CNAMEs is
+   discussed in more detail in RFC 2181, Section 10.3 [38].
+
+
+
+Klensin                     Standards Track                    [Page 69]
+
+RFC 5321                          SMTP                      October 2008
+
+
+   When the lookup succeeds, the mapping can result in a list of
+   alternative delivery addresses rather than a single address, because
+   of multiple MX records, multihoming, or both.  To provide reliable
+   mail transmission, the SMTP client MUST be able to try (and retry)
+   each of the relevant addresses in this list in order, until a
+   delivery attempt succeeds.  However, there MAY also be a configurable
+   limit on the number of alternate addresses that can be tried.  In any
+   case, the SMTP client SHOULD try at least two addresses.
+
+   Two types of information are used to rank the host addresses:
+   multiple MX records, and multihomed hosts.
+
+   MX records contain a preference indication that MUST be used in
+   sorting if more than one such record appears (see below).  Lower
+   numbers are more preferred than higher ones.  If there are multiple
+   destinations with the same preference and there is no clear reason to
+   favor one (e.g., by recognition of an easily reached address), then
+   the sender-SMTP MUST randomize them to spread the load across
+   multiple mail exchangers for a specific organization.
+
+   The destination host (perhaps taken from the preferred MX record) may
+   be multihomed, in which case the domain name resolver will return a
+   list of alternative IP addresses.  It is the responsibility of the
+   domain name resolver interface to have ordered this list by
+   decreasing preference if necessary, and the SMTP sender MUST try them
+   in the order presented.
+
+   Although the capability to try multiple alternative addresses is
+   required, specific installations may want to limit or disable the use
+   of alternative addresses.  The question of whether a sender should
+   attempt retries using the different addresses of a multihomed host
+   has been controversial.  The main argument for using the multiple
+   addresses is that it maximizes the probability of timely delivery,
+   and indeed sometimes the probability of any delivery; the counter-
+   argument is that it may result in unnecessary resource use.  Note
+   that resource use is also strongly determined by the sending strategy
+   discussed in Section 4.5.4.1.
+
+   If an SMTP server receives a message with a destination for which it
+   is a designated Mail eXchanger, it MAY relay the message (potentially
+   after having rewritten the MAIL FROM and/or RCPT TO addresses), make
+   final delivery of the message, or hand it off using some mechanism
+   outside the SMTP-provided transport environment.  Of course, neither
+   of the latter require that the list of MX records be examined
+   further.
+
+   If it determines that it should relay the message without rewriting
+   the address, it MUST sort the MX records to determine candidates for
+
+
+
+Klensin                     Standards Track                    [Page 70]
+
+RFC 5321                          SMTP                      October 2008
+
+
+   delivery.  The records are first ordered by preference, with the
+   lowest-numbered records being most preferred.  The relay host MUST
+   then inspect the list for any of the names or addresses by which it
+   might be known in mail transactions.  If a matching record is found,
+   all records at that preference level and higher-numbered ones MUST be
+   discarded from consideration.  If there are no records left at that
+   point, it is an error condition, and the message MUST be returned as
+   undeliverable.  If records do remain, they SHOULD be tried, best
+   preference first, as described above.
+
+5.2.  IPv6 and MX Records
+
+   In the contemporary Internet, SMTP clients and servers may be hosted
+   on IPv4 systems, IPv6 systems, or dual-stack systems that are
+   compatible with either version of the Internet Protocol.  The host
+   domains to which MX records point may, consequently, contain "A RR"s
+   (IPv4), "AAAA RR"s (IPv6), or any combination of them.  While RFC
+   3974 [39] discusses some operational experience in mixed
+   environments, it was not comprehensive enough to justify
+   standardization, and some of its recommendations appear to be
+   inconsistent with this specification.  The appropriate actions to be
+   taken either will depend on local circumstances, such as performance
+   of the relevant networks and any conversions that might be necessary,
+   or will be obvious (e.g., an IPv6-only client need not attempt to
+   look up A RRs or attempt to reach IPv4-only servers).  Designers of
+   SMTP implementations that might run in IPv6 or dual-stack
+   environments should study the procedures above, especially the
+   comments about multihomed hosts, and, preferably, provide mechanisms
+   to facilitate operational tuning and mail interoperability between
+   IPv4 and IPv6 systems while considering local circumstances.
+
+6.  Problem Detection and Handling
+
+6.1.  Reliable Delivery and Replies by Email
+
+   When the receiver-SMTP accepts a piece of mail (by sending a "250 OK"
+   message in response to DATA), it is accepting responsibility for
+   delivering or relaying the message.  It must take this responsibility
+   seriously.  It MUST NOT lose the message for frivolous reasons, such
+   as because the host later crashes or because of a predictable
+   resource shortage.  Some reasons that are not considered frivolous
+   are discussed in the next subsection and in Section 7.8.
+
+   If there is a delivery failure after acceptance of a message, the
+   receiver-SMTP MUST formulate and mail a notification message.  This
+   notification MUST be sent using a null ("<>") reverse-path in the
+   envelope.  The recipient of this notification MUST be the address
+   from the envelope return path (or the Return-Path: line).  However,
+
+
+
+Klensin                     Standards Track                    [Page 71]
+
+RFC 5321                          SMTP                      October 2008
+
+
+   if this address is null ("<>"), the receiver-SMTP MUST NOT send a
+   notification.  Obviously, nothing in this section can or should
+   prohibit local decisions (i.e., as part of the same system
+   environment as the receiver-SMTP) to log or otherwise transmit
+   information about null address events locally if that is desired.  If
+   the address is an explicit source route, it MUST be stripped down to
+   its final hop.
+
+   For example, suppose that an error notification must be sent for a
+   message that arrived with:
+
+      MAIL FROM:<@a,@b:user@d>
+
+   The notification message MUST be sent using:
+
+      RCPT TO:<user@d>
+
+   Some delivery failures after the message is accepted by SMTP will be
+   unavoidable.  For example, it may be impossible for the receiving
+   SMTP server to validate all the delivery addresses in RCPT command(s)
+   due to a "soft" domain system error, because the target is a mailing
+   list (see earlier discussion of RCPT), or because the server is
+   acting as a relay and has no immediate access to the delivering
+   system.
+
+   To avoid receiving duplicate messages as the result of timeouts, a
+   receiver-SMTP MUST seek to minimize the time required to respond to
+   the final <CRLF>.<CRLF> end of data indicator.  See RFC 1047 [40] for
+   a discussion of this problem.
+
+6.2.  Unwanted, Unsolicited, and "Attack" Messages
+
+   Utility and predictability of the Internet mail system requires that
+   messages that can be delivered should be delivered, regardless of any
+   syntax or other faults associated with those messages and regardless
+   of their content.  If they cannot be delivered, and cannot be
+   rejected by the SMTP server during the SMTP transaction, they should
+   be "bounced" (returned with non-delivery notification messages) as
+   described above.  In today's world, in which many SMTP server
+   operators have discovered that the quantity of undesirable bulk email
+   vastly exceeds the quantity of desired mail and in which accepting a
+   message may trigger additional undesirable traffic by providing
+   verification of the address, those principles may not be practical.
+
+   As discussed in Section 7.8 and Section 7.9 below, dropping mail
+   without notification of the sender is permitted in practice.
+   However, it is extremely dangerous and violates a long tradition and
+   community expectations that mail is either delivered or returned.  If
+
+
+
+Klensin                     Standards Track                    [Page 72]
+
+RFC 5321                          SMTP                      October 2008
+
+
+   silent message-dropping is misused, it could easily undermine
+   confidence in the reliability of the Internet's mail systems.  So
+   silent dropping of messages should be considered only in those cases
+   where there is very high confidence that the messages are seriously
+   fraudulent or otherwise inappropriate.
+
+   To stretch the principle of delivery if possible even further, it may
+   be a rational policy to not deliver mail that has an invalid return
+   address, although the history of the network is that users are
+   typically better served by delivering any message that can be
+   delivered.  Reliably determining that a return address is invalid can
+   be a difficult and time-consuming process, especially if the putative
+   sending system is not directly accessible or does not fully and
+   accurately support VRFY and, even if a "drop messages with invalid
+   return addresses" policy is adopted, it SHOULD be applied only when
+   there is near-certainty that the return addresses are, in fact,
+   invalid.
+
+   Conversely, if a message is rejected because it is found to contain
+   hostile content (a decision that is outside the scope of an SMTP
+   server as defined in this document), rejection ("bounce") messages
+   SHOULD NOT be sent unless the receiving site is confident that those
+   messages will be usefully delivered.  The preference and default in
+   these cases is to avoid sending non-delivery messages when the
+   incoming message is determined to contain hostile content.
+
+6.3.  Loop Detection
+
+   Simple counting of the number of "Received:" header fields in a
+   message has proven to be an effective, although rarely optimal,
+   method of detecting loops in mail systems.  SMTP servers using this
+   technique SHOULD use a large rejection threshold, normally at least
+   100 Received entries.  Whatever mechanisms are used, servers MUST
+   contain provisions for detecting and stopping trivial loops.
+
+6.4.  Compensating for Irregularities
+
+   Unfortunately, variations, creative interpretations, and outright
+   violations of Internet mail protocols do occur; some would suggest
+   that they occur quite frequently.  The debate as to whether a well-
+   behaved SMTP receiver or relay should reject a malformed message,
+   attempt to pass it on unchanged, or attempt to repair it to increase
+   the odds of successful delivery (or subsequent reply) began almost
+   with the dawn of structured network mail and shows no signs of
+   abating.  Advocates of rejection claim that attempted repairs are
+   rarely completely adequate and that rejection of bad messages is the
+   only way to get the offending software repaired.  Advocates of
+   "repair" or "deliver no matter what" argue that users prefer that
+
+
+
+Klensin                     Standards Track                    [Page 73]
+
+RFC 5321                          SMTP                      October 2008
+
+
+   mail go through it if at all possible and that there are significant
+   market pressures in that direction.  In practice, these market
+   pressures may be more important to particular vendors than strict
+   conformance to the standards, regardless of the preference of the
+   actual developers.
+
+   The problems associated with ill-formed messages were exacerbated by
+   the introduction of the split-UA mail reading protocols (Post Office
+   Protocol (POP) version 2 [15], Post Office Protocol (POP) version 3
+   [16], IMAP version 2 [41], and PCMAIL [42]).  These protocols
+   encouraged the use of SMTP as a posting (message submission)
+   protocol, and SMTP servers as relay systems for these client hosts
+   (which are often only intermittently connected to the Internet).
+   Historically, many of those client machines lacked some of the
+   mechanisms and information assumed by SMTP (and indeed, by the mail
+   format protocol, RFC 822 [28]).  Some could not keep adequate track
+   of time; others had no concept of time zones; still others could not
+   identify their own names or addresses; and, of course, none could
+   satisfy the assumptions that underlay RFC 822's conception of
+   authenticated addresses.
+
+   In response to these weak SMTP clients, many SMTP systems now
+   complete messages that are delivered to them in incomplete or
+   incorrect form.  This strategy is generally considered appropriate
+   when the server can identify or authenticate the client, and there
+   are prior agreements between them.  By contrast, there is at best
+   great concern about fixes applied by a relay or delivery SMTP server
+   that has little or no knowledge of the user or client machine.  Many
+   of these issues are addressed by using a separate protocol, such as
+   that defined in RFC 4409 [18], for message submission, rather than
+   using originating SMTP servers for that purpose.
+
+   The following changes to a message being processed MAY be applied
+   when necessary by an originating SMTP server, or one used as the
+   target of SMTP as an initial posting (message submission) protocol:
+
+   o  Addition of a message-id field when none appears
+
+   o  Addition of a date, time, or time zone when none appears
+
+   o  Correction of addresses to proper FQDN format
+
+   The less information the server has about the client, the less likely
+   these changes are to be correct and the more caution and conservatism
+   should be applied when considering whether or not to perform fixes
+   and how.  These changes MUST NOT be applied by an SMTP server that
+   provides an intermediate relay function.
+
+
+
+
+Klensin                     Standards Track                    [Page 74]
+
+RFC 5321                          SMTP                      October 2008
+
+
+   In all cases, properly operating clients supplying correct
+   information are preferred to corrections by the SMTP server.  In all
+   cases, documentation SHOULD be provided in trace header fields and/or
+   header field comments for actions performed by the servers.
+
+7.  Security Considerations
+
+7.1.  Mail Security and Spoofing
+
+   SMTP mail is inherently insecure in that it is feasible for even
+   fairly casual users to negotiate directly with receiving and relaying
+   SMTP servers and create messages that will trick a naive recipient
+   into believing that they came from somewhere else.  Constructing such
+   a message so that the "spoofed" behavior cannot be detected by an
+   expert is somewhat more difficult, but not sufficiently so as to be a
+   deterrent to someone who is determined and knowledgeable.
+   Consequently, as knowledge of Internet mail increases, so does the
+   knowledge that SMTP mail inherently cannot be authenticated, or
+   integrity checks provided, at the transport level.  Real mail
+   security lies only in end-to-end methods involving the message
+   bodies, such as those that use digital signatures (see RFC 1847 [43]
+   and, e.g., Pretty Good Privacy (PGP) in RFC 4880 [44] or Secure/
+   Multipurpose Internet Mail Extensions (S/MIME) in RFC 3851 [45]).
+
+   Various protocol extensions and configuration options that provide
+   authentication at the transport level (e.g., from an SMTP client to
+   an SMTP server) improve somewhat on the traditional situation
+   described above.  However, in general, they only authenticate one
+   server to another rather than a chain of relays and servers, much
+   less authenticating users or user machines.  Consequently, unless
+   they are accompanied by careful handoffs of responsibility in a
+   carefully designed trust environment, they remain inherently weaker
+   than end-to-end mechanisms that use digitally signed messages rather
+   than depending on the integrity of the transport system.
+
+   Efforts to make it more difficult for users to set envelope return
+   path and header "From" fields to point to valid addresses other than
+   their own are largely misguided: they frustrate legitimate
+   applications in which mail is sent by one user on behalf of another,
+   in which error (or normal) replies should be directed to a special
+   address, or in which a single message is sent to multiple recipients
+   on different hosts.  (Systems that provide convenient ways for users
+   to alter these header fields on a per-message basis should attempt to
+   establish a primary and permanent mailbox address for the user so
+   that Sender header fields within the message data can be generated
+   sensibly.)
+
+
+
+
+
+Klensin                     Standards Track                    [Page 75]
+
+RFC 5321                          SMTP                      October 2008
+
+
+   This specification does not further address the authentication issues
+   associated with SMTP other than to advocate that useful functionality
+   not be disabled in the hope of providing some small margin of
+   protection against a user who is trying to fake mail.
+
+7.2.  "Blind" Copies
+
+   Addresses that do not appear in the message header section may appear
+   in the RCPT commands to an SMTP server for a number of reasons.  The
+   two most common involve the use of a mailing address as a "list
+   exploder" (a single address that resolves into multiple addresses)
+   and the appearance of "blind copies".  Especially when more than one
+   RCPT command is present, and in order to avoid defeating some of the
+   purpose of these mechanisms, SMTP clients and servers SHOULD NOT copy
+   the full set of RCPT command arguments into the header section,
+   either as part of trace header fields or as informational or private-
+   extension header fields.  Since this rule is often violated in
+   practice, and cannot be enforced, sending SMTP systems that are aware
+   of "bcc" use MAY find it helpful to send each blind copy as a
+   separate message transaction containing only a single RCPT command.
+
+   There is no inherent relationship between either "reverse" (from
+   MAIL, SAML, etc., commands) or "forward" (RCPT) addresses in the SMTP
+   transaction ("envelope") and the addresses in the header section.
+   Receiving systems SHOULD NOT attempt to deduce such relationships and
+   use them to alter the header section of the message for delivery.
+   The popular "Apparently-to" header field is a violation of this
+   principle as well as a common source of unintended information
+   disclosure and SHOULD NOT be used.
+
+7.3.  VRFY, EXPN, and Security
+
+   As discussed in Section 3.5, individual sites may want to disable
+   either or both of VRFY or EXPN for security reasons (see below).  As
+   a corollary to the above, implementations that permit this MUST NOT
+   appear to have verified addresses that are not, in fact, verified.
+   If a site disables these commands for security reasons, the SMTP
+   server MUST return a 252 response, rather than a code that could be
+   confused with successful or unsuccessful verification.
+
+   Returning a 250 reply code with the address listed in the VRFY
+   command after having checked it only for syntax violates this rule.
+   Of course, an implementation that "supports" VRFY by always returning
+   550 whether or not the address is valid is equally not in
+   conformance.
+
+   On the public Internet, the contents of mailing lists have become
+   popular as an address information source for so-called "spammers."
+
+
+
+Klensin                     Standards Track                    [Page 76]
+
+RFC 5321                          SMTP                      October 2008
+
+
+   The use of EXPN to "harvest" addresses has increased as list
+   administrators have installed protections against inappropriate uses
+   of the lists themselves.  However, VRFY and EXPN are still useful for
+   authenticated users and within an administrative domain.  For
+   example, VRFY and EXPN are useful for performing internal audits of
+   how email gets routed to check and to make sure no one is
+   automatically forwarding sensitive mail outside the organization.
+   Sites implementing SMTP authentication may choose to make VRFY and
+   EXPN available only to authenticated requestors.  Implementations
+   SHOULD still provide support for EXPN, but sites SHOULD carefully
+   evaluate the tradeoffs.
+
+   Whether disabling VRFY provides any real marginal security depends on
+   a series of other conditions.  In many cases, RCPT commands can be
+   used to obtain the same information about address validity.  On the
+   other hand, especially in situations where determination of address
+   validity for RCPT commands is deferred until after the DATA command
+   is received, RCPT may return no information at all, while VRFY is
+   expected to make a serious attempt to determine validity before
+   generating a response code (see discussion above).
+
+7.4.  Mail Rerouting Based on the 251 and 551 Response Codes
+
+   Before a client uses the 251 or 551 reply codes from a RCPT command
+   to automatically update its future behavior (e.g., updating the
+   user's address book), it should be certain of the server's
+   authenticity.  If it does not, it may be subject to a man in the
+   middle attack.
+
+7.5.  Information Disclosure in Announcements
+
+   There has been an ongoing debate about the tradeoffs between the
+   debugging advantages of announcing server type and version (and,
+   sometimes, even server domain name) in the greeting response or in
+   response to the HELP command and the disadvantages of exposing
+   information that might be useful in a potential hostile attack.  The
+   utility of the debugging information is beyond doubt.  Those who
+   argue for making it available point out that it is far better to
+   actually secure an SMTP server rather than hope that trying to
+   conceal known vulnerabilities by hiding the server's precise identity
+   will provide more protection.  Sites are encouraged to evaluate the
+   tradeoff with that issue in mind; implementations SHOULD minimally
+   provide for making type and version information available in some way
+   to other network hosts.
+
+
+
+
+
+
+
+Klensin                     Standards Track                    [Page 77]
+
+RFC 5321                          SMTP                      October 2008
+
+
+7.6.  Information Disclosure in Trace Fields
+
+   In some circumstances, such as when mail originates from within a LAN
+   whose hosts are not directly on the public Internet, trace
+   ("Received") header fields produced in conformance with this
+   specification may disclose host names and similar information that
+   would not normally be available.  This ordinarily does not pose a
+   problem, but sites with special concerns about name disclosure should
+   be aware of it.  Also, the optional FOR clause should be supplied
+   with caution or not at all when multiple recipients are involved lest
+   it inadvertently disclose the identities of "blind copy" recipients
+   to others.
+
+7.7.  Information Disclosure in Message Forwarding
+
+   As discussed in Section 3.4, use of the 251 or 551 reply codes to
+   identify the replacement address associated with a mailbox may
+   inadvertently disclose sensitive information.  Sites that are
+   concerned about those issues should ensure that they select and
+   configure servers appropriately.
+
+7.8.  Resistance to Attacks
+
+   In recent years, there has been an increase of attacks on SMTP
+   servers, either in conjunction with attempts to discover addresses
+   for sending unsolicited messages or simply to make the servers
+   inaccessible to others (i.e., as an application-level denial of
+   service attack).  While the means of doing so are beyond the scope of
+   this Standard, rational operational behavior requires that servers be
+   permitted to detect such attacks and take action to defend
+   themselves.  For example, if a server determines that a large number
+   of RCPT TO commands are being sent, most or all with invalid
+   addresses, as part of such an attack, it would be reasonable for the
+   server to close the connection after generating an appropriate number
+   of 5yz (normally 550) replies.
+
+7.9.  Scope of Operation of SMTP Servers
+
+   It is a well-established principle that an SMTP server may refuse to
+   accept mail for any operational or technical reason that makes sense
+   to the site providing the server.  However, cooperation among sites
+   and installations makes the Internet possible.  If sites take
+   excessive advantage of the right to reject traffic, the ubiquity of
+   email availability (one of the strengths of the Internet) will be
+   threatened; considerable care should be taken and balance maintained
+   if a site decides to be selective about the traffic it will accept
+   and process.
+
+
+
+
+Klensin                     Standards Track                    [Page 78]
+
+RFC 5321                          SMTP                      October 2008
+
+
+   In recent years, use of the relay function through arbitrary sites
+   has been used as part of hostile efforts to hide the actual origins
+   of mail.  Some sites have decided to limit the use of the relay
+   function to known or identifiable sources, and implementations SHOULD
+   provide the capability to perform this type of filtering.  When mail
+   is rejected for these or other policy reasons, a 550 code SHOULD be
+   used in response to EHLO (or HELO), MAIL, or RCPT as appropriate.
+
+8.  IANA Considerations
+
+   IANA maintains three registries in support of this specification, all
+   of which were created for RFC 2821 or earlier.  This document expands
+   the third one as specified below.  The registry references listed are
+   as of the time of publication; IANA does not guarantee the locations
+   associated with the URLs.  The registries are as follows:
+
+   o  The first, "Simple Mail Transfer Protocol (SMTP) Service
+      Extensions" [46], consists of SMTP service extensions with the
+      associated keywords, and, as needed, parameters and verbs.  As
+      specified in Section 2.2.2, no entry may be made in this registry
+      that starts in an "X".  Entries may be made only for service
+      extensions (and associated keywords, parameters, or verbs) that
+      are defined in Standards-Track or Experimental RFCs specifically
+      approved by the IESG for this purpose.
+
+   o  The second registry, "Address Literal Tags" [47], consists of
+      "tags" that identify forms of domain literals other than those for
+      IPv4 addresses (specified in RFC 821 and in this document).  The
+      initial entry in that registry is for IPv6 addresses (specified in
+      this document).  Additional literal types require standardization
+      before being used; none are anticipated at this time.
+
+   o  The third, "Mail Transmission Types" [46], established by RFC 821
+      and renewed by this specification, is a registry of link and
+      protocol identifiers to be used with the "via" and "with"
+      subclauses of the time stamp ("Received:" header field) described
+      in Section 4.4.  Link and protocol identifiers in addition to
+      those specified in this document may be registered only by
+      standardization or by way of an RFC-documented, IESG-approved,
+      Experimental protocol extension.  This name space is for
+      identification and not limited in size: the IESG is encouraged to
+      approve on the basis of clear documentation and a distinct method
+      rather than preferences about the properties of the method itself.
+
+      An additional subsection has been added to the "VIA link types"
+      and "WITH protocol types" subsections of this registry to contain
+      registrations of "Additional-registered-clauses" as described
+      above.  The registry will contain clause names, a description, a
+
+
+
+Klensin                     Standards Track                    [Page 79]
+
+RFC 5321                          SMTP                      October 2008
+
+
+      summary of the syntax of the associated String, and a reference.
+      As new clauses are defined, they may, in principle, specify
+      creation of their own registries if the Strings consist of
+      reserved terms or keywords rather than less restricted strings.
+      As with link and protocol identifiers, additional clauses may be
+      registered only by standardization or by way of an RFC-documented,
+      IESG-approved, Experimental protocol extension.  The additional
+      clause name space is for identification and is not limited in
+      size: the IESG is encouraged to approve on the basis of clear
+      documentation, actual use or strong signs that the clause will be
+      used, and a distinct requirement rather than preferences about the
+      properties of the clause itself.
+
+   In addition, if additional trace header fields (i.e., in addition to
+   Return-path and Received) are ever created, those trace fields MUST
+   be added to the IANA registry established by BCP 90 (RFC 3864) [11]
+   for use with RFC 5322 [4].
+
+9.  Acknowledgments
+
+   Many people contributed to the development of RFC 2821.  That
+   document should be consulted for those acknowledgments.  For the
+   present document, the editor and the community owe thanks to Dawn
+   Mann and Tony Hansen who assisted in the very painful process of
+   editing and converting the internal format of the document from one
+   system to another.
+
+   Neither this document nor RFC 2821 would have been possible without
+   the many contribution and insights of the late Jon Postel.  Those
+   contributions of course include the original specification of SMTP in
+   RFC 821.  A considerable quantity of text from RFC 821 still appears
+   in this document as do several of Jon's original examples that have
+   been updated only as needed to reflect other changes in the
+   specification.
+
+   Many people made comments or suggestions on the mailing list or in
+   notes to the author.  Important corrections or clarifications were
+   suggested by several people, including Matti Aarnio, Glenn Anderson,
+   Derek J. Balling, Alex van den Bogaerdt, Stephane Bortzmeyer, Vint
+   Cerf, Jutta Degener, Steve Dorner, Lisa Dusseault, Frank Ellerman,
+   Ned Freed, Randy Gellens, Sabahattin Gucukoglu, Philip Guenther, Arnt
+   Gulbrandsen, Eric Hall, Richard O. Hammer, Tony Hansen, Peter J.
+   Holzer, Kari Hurtta, Bryon Roche Kain, Valdis Kletnieks, Mathias
+   Koerber, John Leslie, Bruce Lilly, Jeff Macdonald, Mark E. Mallett,
+   Mark Martinec, S. Moonesamy, Lyndon Nerenberg, Chris Newman, Douglas
+   Otis, Pete Resnick, Robert A. Rosenberg, Vince Sabio, Hector Santos,
+   David F. Skoll, Paul Smith, and Brett Watson.
+
+
+
+
+Klensin                     Standards Track                    [Page 80]
+
+RFC 5321                          SMTP                      October 2008
+
+
+   The efforts of the Area Directors -- Lisa Dusseault, Ted Hardie, and
+   Chris Newman -- to get this effort restarted and keep it moving, and
+   of an ad hoc committee with the same purpose, are gratefully
+   acknowledged.  The members of that committee were (in alphabetical
+   order) Dave Crocker, Cyrus Daboo, Tony Finch, Ned Freed, Randall
+   Gellens, Tony Hansen, the author, and Alexey Melnikov.  Tony Hansen
+   also acted as ad hoc chair on the mailing list reviewing this
+   document; without his efforts, sense of balance and fairness, and
+   patience, it clearly would not have been possible.
+
+10.  References
+
+10.1.  Normative References
+
+   [1]   Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
+         August 1982.
+
+   [2]   Mockapetris, P., "Domain names - implementation and
+         specification", STD 13, RFC 1035, November 1987.
+
+   [3]   Braden, R., "Requirements for Internet Hosts - Application and
+         Support", STD 3, RFC 1123, October 1989.
+
+   [4]   Resnick, P., "Internet Message Format", RFC 5322, October 2008.
+
+   [5]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
+         Levels", BCP 14, RFC 2119, March 1997.
+
+   [6]   American National Standards Institute (formerly United States
+         of America Standards Institute), "USA Code for Information
+         Interchange", ANSI X3.4-1968, 1968.
+
+         ANSI X3.4-1968 has been replaced by newer versions with slight
+         modifications, but the 1968 version remains definitive for the
+         Internet.
+
+   [7]   Crocker, D. and P. Overell, "Augmented BNF for Syntax
+         Specifications: ABNF", STD 68, RFC 5234, January 2008.
+
+   [8]   Hinden, R. and S. Deering, "IP Version 6 Addressing
+         Architecture", RFC 4291, February 2006.
+
+   [9]   Newman, C., "ESMTP and LMTP Transmission Types Registration",
+         RFC 3848, July 2004.
+
+   [10]  Klensin, J., Freed, N., and K. Moore, "SMTP Service Extension
+         for Message Size Declaration", STD 10, RFC 1870, November 1995.
+
+
+
+
+Klensin                     Standards Track                    [Page 81]
+
+RFC 5321                          SMTP                      October 2008
+
+
+   [11]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
+         Procedures for Message Header Fields", BCP 90, RFC 3864,
+         September 2004.
+
+10.2.  Informative References
+
+   [12]  Partridge, C., "Mail routing and the domain system", RFC 974,
+         January 1986.
+
+   [13]  Klensin, J., Freed, N., Rose, M., Stefferud, E., and D.
+         Crocker, "SMTP Service Extensions", STD 10, RFC 1869,
+         November 1995.
+
+   [14]  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
+         April 2001.
+
+   [15]  Butler, M., Postel, J., Chase, D., Goldberger, J., and J.
+         Reynolds, "Post Office Protocol: Version 2", RFC 937,
+         February 1985.
+
+   [16]  Myers, J. and M. Rose, "Post Office Protocol - Version 3",
+         STD 53, RFC 1939, May 1996.
+
+   [17]  Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
+         4rev1", RFC 3501, March 2003.
+
+   [18]  Gellens, R. and J. Klensin, "Message Submission for Mail",
+         RFC 4409, April 2006.
+
+   [19]  Freed, N., "SMTP Service Extension for Command Pipelining",
+         STD 60, RFC 2920, September 2000.
+
+   [20]  Vaudreuil, G., "SMTP Service Extensions for Transmission of
+         Large and Binary MIME Messages", RFC 3030, December 2000.
+
+   [21]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+         Extensions (MIME) Part One: Format of Internet Message Bodies",
+         RFC 2045, November 1996.
+
+   [22]  Klensin, J., Freed, N., Rose, M., Stefferud, E., and D.
+         Crocker, "SMTP Service Extension for 8bit-MIMEtransport",
+         RFC 1652, July 1994.
+
+   [23]  Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part
+         Three: Message Header Extensions for Non-ASCII Text", RFC 2047,
+         November 1996.
+
+
+
+
+
+Klensin                     Standards Track                    [Page 82]
+
+RFC 5321                          SMTP                      October 2008
+
+
+   [24]  Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word
+         Extensions: Character Sets, Languages, and Continuations",
+         RFC 2231, November 1997.
+
+   [25]  Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463,
+         January 2003.
+
+   [26]  Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced Mail
+         System Status Codes", BCP 138, RFC 5248, June 2008.
+
+   [27]  Freed, N., "Behavior of and Requirements for Internet
+         Firewalls", RFC 2979, October 2000.
+
+   [28]  Crocker, D., "Standard for the format of ARPA Internet text
+         messages", STD 11, RFC 822, August 1982.
+
+   [29]  Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) for
+         Authorizing Use of Domains in E-Mail, Version 1", RFC 4408,
+         April 2006.
+
+   [30]  Fenton, J., "Analysis of Threats Motivating DomainKeys
+         Identified Mail (DKIM)", RFC 4686, September 2006.
+
+   [31]  Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and
+         M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures",
+         RFC 4871, May 2007.
+
+   [32]  Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
+         Extension for Delivery Status Notifications (DSNs)", RFC 3461,
+         January 2003.
+
+   [33]  Moore, K. and G. Vaudreuil, "An Extensible Message Format for
+         Delivery Status Notifications", RFC 3464, January 2003.
+
+   [34]  Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9,
+         RFC 959, October 1985.
+
+   [35]  Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping
+         between X.400 and RFC 822/MIME", RFC 2156, January 1998.
+
+   [36]  De Winter, J., "SMTP Service Extension for Remote Message Queue
+         Starting", RFC 1985, August 1996.
+
+   [37]  Hansen, T. and G. Vaudreuil, "Message Disposition
+         Notification", RFC 3798, May 2004.
+
+   [38]  Elz, R. and R. Bush, "Clarifications to the DNS Specification",
+         RFC 2181, July 1997.
+
+
+
+Klensin                     Standards Track                    [Page 83]
+
+RFC 5321                          SMTP                      October 2008
+
+
+   [39]  Nakamura, M. and J. Hagino, "SMTP Operational Experience in
+         Mixed IPv4/v6 Environments", RFC 3974, January 2005.
+
+   [40]  Partridge, C., "Duplicate messages and SMTP", RFC 1047,
+         February 1988.
+
+   [41]  Crispin, M., "Interactive Mail Access Protocol: Version 2",
+         RFC 1176, August 1990.
+
+   [42]  Lambert, M., "PCMAIL: A distributed mail system for personal
+         computers", RFC 1056, June 1988.
+
+   [43]  Galvin, J., Murphy, S., Crocker, S., and N. Freed, "Security
+         Multiparts for MIME: Multipart/Signed and Multipart/Encrypted",
+         RFC 1847, October 1995.
+
+   [44]  Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
+         Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
+
+   [45]  Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
+         (S/MIME) Version 3.1 Message Specification", RFC 3851,
+         July 2004.
+
+   [46]  Internet Assigned Number Authority (IANA), "IANA Mail
+         Parameters", 2007,
+         <http://www.iana.org/assignments/mail-parameters>.
+
+   [47]  Internet Assigned Number Authority (IANA), "Address Literal
+         Tags", 2007,
+         <http://www.iana.org/assignments/address-literal-tags>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klensin                     Standards Track                    [Page 84]
+
+RFC 5321                          SMTP                      October 2008
+
+
+Appendix A.  TCP Transport Service
+
+   The TCP connection supports the transmission of 8-bit bytes.  The
+   SMTP data is 7-bit ASCII characters.  Each character is transmitted
+   as an 8-bit byte with the high-order bit cleared to zero.  Service
+   extensions may modify this rule to permit transmission of full 8-bit
+   data bytes as part of the message body, or, if specifically designed
+   to do so, in SMTP commands or responses.
+
+Appendix B.  Generating SMTP Commands from RFC 822 Header Fields
+
+   Some systems use an RFC 822 header section (only) in a mail
+   submission protocol, or otherwise generate SMTP commands from RFC 822
+   header fields when such a message is handed to an MTA from a UA.
+   While the MTA-UA protocol is a private matter, not covered by any
+   Internet Standard, there are problems with this approach.  For
+   example, there have been repeated problems with proper handling of
+   "bcc" copies and redistribution lists when information that
+   conceptually belongs to the mail envelope is not separated early in
+   processing from header field information (and kept separate).
+
+   It is recommended that the UA provide its initial ("submission
+   client") MTA with an envelope separate from the message itself.
+   However, if the envelope is not supplied, SMTP commands SHOULD be
+   generated as follows:
+
+   1.  Each recipient address from a TO, CC, or BCC header field SHOULD
+       be copied to a RCPT command (generating multiple message copies
+       if that is required for queuing or delivery).  This includes any
+       addresses listed in a RFC 822 "group".  Any BCC header fields
+       SHOULD then be removed from the header section.  Once this
+       process is completed, the remaining header fields SHOULD be
+       checked to verify that at least one TO, CC, or BCC header field
+       remains.  If none do, then a BCC header field with no additional
+       information SHOULD be inserted as specified in [4].
+
+   2.  The return address in the MAIL command SHOULD, if possible, be
+       derived from the system's identity for the submitting (local)
+       user, and the "From:" header field otherwise.  If there is a
+       system identity available, it SHOULD also be copied to the Sender
+       header field if it is different from the address in the From
+       header field.  (Any Sender header field that was already there
+       SHOULD be removed.)  Systems may provide a way for submitters to
+       override the envelope return address, but may want to restrict
+       its use to privileged users.  This will not prevent mail forgery,
+       but may lessen its incidence; see Section 7.1.
+
+
+
+
+
+Klensin                     Standards Track                    [Page 85]
+
+RFC 5321                          SMTP                      October 2008
+
+
+   When an MTA is being used in this way, it bears responsibility for
+   ensuring that the message being transmitted is valid.  The mechanisms
+   for checking that validity, and for handling (or returning) messages
+   that are not valid at the time of arrival, are part of the MUA-MTA
+   interface and not covered by this specification.
+
+   A submission protocol based on Standard RFC 822 information alone
+   MUST NOT be used to gateway a message from a foreign (non-SMTP) mail
+   system into an SMTP environment.  Additional information to construct
+   an envelope must come from some source in the other environment,
+   whether supplemental header fields or the foreign system's envelope.
+
+   Attempts to gateway messages using only their header "To" and "Cc"
+   fields have repeatedly caused mail loops and other behavior adverse
+   to the proper functioning of the Internet mail environment.  These
+   problems have been especially common when the message originates from
+   an Internet mailing list and is distributed into the foreign
+   environment using envelope information.  When these messages are then
+   processed by a header-section-only remailer, loops back to the
+   Internet environment (and the mailing list) are almost inevitable.
+
+Appendix C.  Source Routes
+
+   Historically, the <reverse-path> was a reverse source routing list of
+   hosts and a source mailbox.  The first host in the <reverse-path> was
+   historically the host sending the MAIL command; today, source routes
+   SHOULD NOT appear in the reverse-path.  Similarly, the <forward-path>
+   may be a source routing lists of hosts and a destination mailbox.
+   However, in general, the <forward-path> SHOULD contain only a mailbox
+   and domain name, relying on the domain name system to supply routing
+   information if required.  The use of source routes is deprecated (see
+   Appendix F.2); while servers MUST be prepared to receive and handle
+   them as discussed in Section 3.3 and Appendix F.2, clients SHOULD NOT
+   transmit them and this section is included in the current
+   specification only to provide context.  It has been modified somewhat
+   from the material in RFC 821 to prevent server actions that might
+   confuse clients or subsequent servers that do not expect a full
+   source route implementation.
+
+   For relay purposes, the forward-path may be a source route of the
+   form "@ONE,@TWO:JOE@THREE", where ONE, TWO, and THREE MUST be fully-
+   qualified domain names.  This form is used to emphasize the
+   distinction between an address and a route.  The mailbox (here, JOE@
+   THREE) is an absolute address, and the route is information about how
+   to get there.  The two concepts should not be confused.
+
+   If source routes are used, RFC 821 and the text below should be
+   consulted for the mechanisms for constructing and updating the
+
+
+
+Klensin                     Standards Track                    [Page 86]
+
+RFC 5321                          SMTP                      October 2008
+
+
+   forward-path.  A server that is reached by means of a source route
+   (e.g., its domain name appears first in the list in the forward-path)
+   MUST remove its domain name from any forward-paths in which that
+   domain name appears before forwarding the message and MAY remove all
+   other source routing information.  The reverse-path SHOULD NOT be
+   updated by servers conforming to this specification.
+
+   Notice that the forward-path and reverse-path appear in the SMTP
+   commands and replies, but not necessarily in the message.  That is,
+   there is no need for these paths and especially this syntax to appear
+   in the "To:" , "From:", "CC:", etc. fields of the message header
+   section.  Conversely, SMTP servers MUST NOT derive final message
+   routing information from message header fields.
+
+   When the list of hosts is present despite the recommendations above,
+   it is a "reverse" source route and indicates that the mail was
+   relayed through each host on the list (the first host in the list was
+   the most recent relay).  This list is used as a source route to
+   return non-delivery notices to the sender.  If, contrary to the
+   recommendations here, a relay host adds itself to the beginning of
+   the list, it MUST use its name as known in the transport environment
+   to which it is relaying the mail rather than that of the transport
+   environment from which the mail came (if they are different).  Note
+   that a situation could easily arise in which some relay hosts add
+   their names to the reverse source route and others do not, generating
+   discontinuities in the routing list.  This is another reason why
+   servers needing to return a message SHOULD ignore the source route
+   entirely and simply use the domain as specified in the Mailbox.
+
+Appendix D.  Scenarios
+
+   This section presents complete scenarios of several types of SMTP
+   sessions.  In the examples, "C:" indicates what is said by the SMTP
+   client, and "S:" indicates what is said by the SMTP server.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klensin                     Standards Track                    [Page 87]
+
+RFC 5321                          SMTP                      October 2008
+
+
+D.1.  A Typical SMTP Transaction Scenario
+
+   This SMTP example shows mail sent by Smith at host bar.com, and to
+   Jones, Green, and Brown at host foo.com.  Here we assume that host
+   bar.com contacts host foo.com directly.  The mail is accepted for
+   Jones and Brown.  Green does not have a mailbox at host foo.com.
+
+      S: 220 foo.com Simple Mail Transfer Service Ready
+      C: EHLO bar.com
+      S: 250-foo.com greets bar.com
+      S: 250-8BITMIME
+      S: 250-SIZE
+      S: 250-DSN
+      S: 250 HELP
+      C: MAIL FROM:<Smith@bar.com>
+      S: 250 OK
+      C: RCPT TO:<Jones@foo.com>
+      S: 250 OK
+      C: RCPT TO:<Green@foo.com>
+      S: 550 No such user here
+      C: RCPT TO:<Brown@foo.com>
+      S: 250 OK
+      C: DATA
+      S: 354 Start mail input; end with <CRLF>.<CRLF>
+      C: Blah blah blah...
+      C: ...etc. etc. etc.
+      C: .
+      S: 250 OK
+      C: QUIT
+      S: 221 foo.com Service closing transmission channel
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klensin                     Standards Track                    [Page 88]
+
+RFC 5321                          SMTP                      October 2008
+
+
+D.2.  Aborted SMTP Transaction Scenario
+
+      S: 220 foo.com Simple Mail Transfer Service Ready
+      C: EHLO bar.com
+      S: 250-foo.com greets bar.com
+      S: 250-8BITMIME
+      S: 250-SIZE
+      S: 250-DSN
+      S: 250 HELP
+      C: MAIL FROM:<Smith@bar.com>
+      S: 250 OK
+      C: RCPT TO:<Jones@foo.com>
+      S: 250 OK
+      C: RCPT TO:<Green@foo.com>
+      S: 550 No such user here
+      C: RSET
+      S: 250 OK
+      C: QUIT
+      S: 221 foo.com Service closing transmission channel
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klensin                     Standards Track                    [Page 89]
+
+RFC 5321                          SMTP                      October 2008
+
+
+D.3.  Relayed Mail Scenario
+
+   Step 1 -- Source Host to Relay Host
+
+   The source host performs a DNS lookup on XYZ.COM (the destination
+   address) and finds DNS MX records specifying xyz.com as the best
+   preference and foo.com as a lower preference.  It attempts to open a
+   connection to xyz.com and fails.  It then opens a connection to
+   foo.com, with the following dialogue:
+
+      S: 220 foo.com Simple Mail Transfer Service Ready
+      C: EHLO bar.com
+      S: 250-foo.com greets bar.com
+      S: 250-8BITMIME
+      S: 250-SIZE
+      S: 250-DSN
+      S: 250 HELP
+      C: MAIL FROM:<JQP@bar.com>
+      S: 250 OK
+      C: RCPT TO:<Jones@XYZ.COM>
+      S: 250 OK
+      C: DATA
+      S: 354 Start mail input; end with <CRLF>.<CRLF>
+      C: Date: Thu, 21 May 1998 05:33:29 -0700
+      C: From: John Q. Public <JQP@bar.com>
+      C: Subject: The Next Meeting of the Board
+      C: To: Jones@xyz.com
+      C:
+      C: Bill:
+      C: The next meeting of the board of directors will be
+      C: on Tuesday.
+      C: John.
+      C: .
+      S: 250 OK
+      C: QUIT
+      S: 221 foo.com Service closing transmission channel
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klensin                     Standards Track                    [Page 90]
+
+RFC 5321                          SMTP                      October 2008
+
+
+   Step 2 -- Relay Host to Destination Host
+
+   foo.com, having received the message, now does a DNS lookup on
+   xyz.com.  It finds the same set of MX records, but cannot use the one
+   that points to itself (or to any other host as a worse preference).
+   It tries to open a connection to xyz.com itself and succeeds.  Then
+   we have:
+
+           S: 220 xyz.com Simple Mail Transfer Service Ready
+           C: EHLO foo.com
+           S: 250 xyz.com is on the air
+           C: MAIL FROM:<JQP@bar.com>
+           S: 250 OK
+           C: RCPT TO:<Jones@XYZ.COM>
+           S: 250 OK
+           C: DATA
+           S: 354 Start mail input; end with <CRLF>.<CRLF>
+           C: Received: from bar.com by foo.com ; Thu, 21 May 1998
+           C:     05:33:29 -0700
+           C: Date: Thu, 21 May 1998 05:33:22 -0700
+           C: From: John Q. Public <JQP@bar.com>
+           C: Subject:  The Next Meeting of the Board
+           C: To: Jones@xyz.com
+           C:
+           C: Bill:
+           C: The next meeting of the board of directors will be
+           C: on Tuesday.
+           C:                         John.
+           C: .
+           S: 250 OK
+           C: QUIT
+           S: 221 foo.com Service closing transmission channel
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klensin                     Standards Track                    [Page 91]
+
+RFC 5321                          SMTP                      October 2008
+
+
+D.4.  Verifying and Sending Scenario
+
+      S: 220 foo.com Simple Mail Transfer Service Ready
+      C: EHLO bar.com
+      S: 250-foo.com greets bar.com
+      S: 250-8BITMIME
+      S: 250-SIZE
+      S: 250-DSN
+      S: 250-VRFY
+      S: 250 HELP
+      C: VRFY Crispin
+      S: 250 Mark Crispin <Admin.MRC@foo.com>
+      C: MAIL FROM:<EAK@bar.com>
+      S: 250 OK
+      C: RCPT TO:<Admin.MRC@foo.com>
+      S: 250 OK
+      C: DATA
+      S: 354 Start mail input; end with <CRLF>.<CRLF>
+      C: Blah blah blah...
+      C: ...etc. etc. etc.
+      C: .
+      S: 250 OK
+      C: QUIT
+      S: 221 foo.com Service closing transmission channel
+
+Appendix E.  Other Gateway Issues
+
+   In general, gateways between the Internet and other mail systems
+   SHOULD attempt to preserve any layering semantics across the
+   boundaries between the two mail systems involved.  Gateway-
+   translation approaches that attempt to take shortcuts by mapping
+   (such as mapping envelope information from one system to the message
+   header section or body of another) have generally proven to be
+   inadequate in important ways.  Systems translating between
+   environments that do not support both envelopes and a header section
+   and Internet mail must be written with the understanding that some
+   information loss is almost inevitable.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klensin                     Standards Track                    [Page 92]
+
+RFC 5321                          SMTP                      October 2008
+
+
+Appendix F.  Deprecated Features of RFC 821
+
+   A few features of RFC 821 have proven to be problematic and SHOULD
+   NOT be used in Internet mail.
+
+F.1.  TURN
+
+   This command, described in RFC 821, raises important security issues
+   since, in the absence of strong authentication of the host requesting
+   that the client and server switch roles, it can easily be used to
+   divert mail from its correct destination.  Its use is deprecated;
+   SMTP systems SHOULD NOT use it unless the server can authenticate the
+   client.
+
+F.2.  Source Routing
+
+   RFC 821 utilized the concept of explicit source routing to get mail
+   from one host to another via a series of relays.  The requirement to
+   utilize source routes in regular mail traffic was eliminated by the
+   introduction of the domain name system "MX" record and the last
+   significant justification for them was eliminated by the
+   introduction, in RFC 1123, of a clear requirement that addresses
+   following an "@" must all be fully-qualified domain names.
+   Consequently, the only remaining justifications for the use of source
+   routes are support for very old SMTP clients or MUAs and in mail
+   system debugging.  They can, however, still be useful in the latter
+   circumstance and for routing mail around serious, but temporary,
+   problems such as problems with the relevant DNS records.
+
+   SMTP servers MUST continue to accept source route syntax as specified
+   in the main body of this document and in RFC 1123.  They MAY, if
+   necessary, ignore the routes and utilize only the target domain in
+   the address.  If they do utilize the source route, the message MUST
+   be sent to the first domain shown in the address.  In particular, a
+   server MUST NOT guess at shortcuts within the source route.
+
+   Clients SHOULD NOT utilize explicit source routing except under
+   unusual circumstances, such as debugging or potentially relaying
+   around firewall or mail system configuration errors.
+
+F.3.  HELO
+
+   As discussed in Sections 3.1 and 4.1.1, EHLO SHOULD be used rather
+   than HELO when the server will accept the former.  Servers MUST
+   continue to accept and process HELO in order to support older
+   clients.
+
+
+
+
+
+Klensin                     Standards Track                    [Page 93]
+
+RFC 5321                          SMTP                      October 2008
+
+
+F.4.  #-literals
+
+   RFC 821 provided for specifying an Internet address as a decimal
+   integer host number prefixed by a pound sign, "#".  In practice, that
+   form has been obsolete since the introduction of TCP/IP.  It is
+   deprecated and MUST NOT be used.
+
+F.5.  Dates and Years
+
+   When dates are inserted into messages by SMTP clients or servers
+   (e.g., in trace header fields), four-digit years MUST BE used.  Two-
+   digit years are deprecated; three-digit years were never permitted in
+   the Internet mail system.
+
+F.6.  Sending versus Mailing
+
+   In addition to specifying a mechanism for delivering messages to
+   user's mailboxes, RFC 821 provided additional, optional, commands to
+   deliver messages directly to the user's terminal screen.  These
+   commands (SEND, SAML, SOML) were rarely implemented, and changes in
+   workstation technology and the introduction of other protocols may
+   have rendered them obsolete even where they are implemented.
+
+   Clients SHOULD NOT provide SEND, SAML, or SOML as services.  Servers
+   MAY implement them.  If they are implemented by servers, the
+   implementation model specified in RFC 821 MUST be used and the
+   command names MUST be published in the response to the EHLO command.
+
+Author's Address
+
+   John C. Klensin
+   1770 Massachusetts Ave, Suite 322
+   Cambridge, MA  02140
+   USA
+
+   EMail: john+smtp@jck.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klensin                     Standards Track                    [Page 94]
+
+RFC 5321                          SMTP                      October 2008
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2008).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+Klensin                     Standards Track                    [Page 95]
+