save load to RFC 2821

7 files changed, 23387 insertions, 0 deletions

diff --git a/Documentation/en/I-D/draft-ietf-drums-smtpupd-06.txt b/Documentation/en/I-D/draft-ietf-drums-smtpupd-06.txt
new file mode 100644
index 00000000..80b62634
--- /dev/null
+++ b/Documentation/en/I-D/draft-ietf-drums-smtpupd-06.txt
@@ -0,0 +1,4053 @@
+
+INTERNET-DRAFT                                John C. Klensin, Editor
+Expires in six months                         Dawn P. Mann, Co-Editor
+                                                        July 30, 1997
+                                                        
+
+                  Simple Mail Transfer Protocol 
+
+                 draft-ietf-drums-smtpupd-06.txt
+
+                     Status of this Memo
+
+This document is an Internet-Draft.  Internet-Drafts are working
+documents of the Internet Engineering Task Force (IETF), its areas,
+and its working groups. Note that other groups may also distribute
+working documents as Internet-Drafts.
+
+Internet-Drafts are draft documents valid for a maximum of six
+months.  Internet-Drafts may be updated, replaced, or obsoleted by
+other documents at any time.  It is not appropriate to use
+Internet-Drafts as reference material or to cite them other than as a
+"working draft" or "work in progress".
+
+To learn the current status of any Internet-Draft, please check the
+1id-abstracts.txt listing contained in the Internet-Drafts Shadow
+Directories on ds.internic.net (US East Coast), nic.nordu.net
+(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
+
+If consensus is reached on this document, it will be forwarded to the
+IESG with the recommendation that it be processed onto the Standards
+track. 
+
+[[Sections marked with doubled brackets (e.g., "<<") are explicit
+placeholders or known major loose ends.  The marking ## is a note in
+the draft to recheck a section number and should be ignored.]]
+
+[[As discussed in the WG, most of the syntax and examples have not
+been changed from 821 -- those changes are a last- step item, after
+the ABNF document completely stabilizes and differences with 822bis
+have been resolved.  Similarly, the numbers of appendices will be
+rationalized (and Appendix X removed) before the document is
+submitted to the IESG.  Please check appendix X.2 for additional
+problems of which the editor is already painfully aware before
+complaining about things that are missing.]]
+
+
+                           TABLE OF CONTENTS
+   0.  ABSTRACT
+
+   1.  INTRODUCTION
+
+   2.  THE SMTP MODEL
+
+      2.1 Basic structure
+      2.2 The extension model
+      2.3 Other terminology
+      2.4 Syntax Principles
+
+
+   3.  THE SMTP PROCEDURES: AN OVERVIEW
+      
+      3.1  Session initiation
+      3.2  Client initiation
+      3.3  Mail transactions
+      3.4  Forwarding for Address Correction or Updating
+      3.5  Commands for Debugging Addresses
+      3.6  Domains 
+      3.7  Relaying
+      3.8  Mail Gatewaying
+      3.9  Terminating sessions and connections
+      3.10  Mailing lists and Aliases
+
+
+   4.  THE SMTP SPECIFICATIONS
+
+      4.1.  SMTP Commands
+      4.1.1.  Command Semantics and Syntax
+      4.1.2.  Lower-level Syntax
+      4.1.3.  Address literals
+      4.1.4.  Order of commands
+      4.1.5.  Private-use commands
+      4.2.  SMTP Replies
+      4.2.1.  Reply Code Severities and Theory
+      4.2.2.  Reply Codes by Function Group
+      4.2.3.  Reply Codes in Numeric Order 
+      4.2.4.  Reply code 502
+      4.2.5  Reply codes after DATA and the subsequent CRLF.CRLF.
+      4.3.  Sequencing of Commands and Replies
+      4.4   Trace information
+      4.5.  Details
+      4.5.1.  Minimum Implementation
+      4.5.2.  Transparency
+      4.5.3.  Sizes and Timeouts
+      4.5.4   SMTP Queuing Strategies
+
+   5. Address resolution and mail handling
+
+   6. Problem detection and handling
+      6.1 Reliable delivery and replies by email
+      6.2 Loop detection
+      6.3 Compensating for irregularities
+
+   7. Security Considerations
+      7.1 Mail security and spoofing
+      7.2 "Blind" copies
+      7.3 VRFY, EXPN, and security
+      7.4 Information disclosure
+      7.5 Scope of operation of SMTP servers
+
+   8. IANA Considerations
+
+   9. References
+
+   10. Editor's addresses
+
+   11. Acknowledgments
+
+   APPENDIX A:  TCP
+   APPENDIX B:  Generating SMTP commands from RFC 822 headers
+   APPENDIX C:  Source routes
+   APPENDIX F:  Scenarios
+   APPENDIX G:  Other gateway issues.
+   APPENDIX I:  Deprecated features of RFC 821
+   APPENDIX X:  Change summary and Loose ends (temporary)
+
+
+
+
+
+0.  Abstract
+
+This document is a self-contained specification of the basic protocol
+for the Internet electronic mail transport, consolidating and
+updating 
+
+ * the original SMTP specification of RFC 821 [RFC-821],
+ * Domain name system requirements and implications for mail
+   transport from RFC 1035 [RFC-DNS] and RFC 974 [RFC974],
+ * the clarifications and applicability statements in 
+     RFC 1123 [RFC-1123], and
+ * material drawn from the SMTP Extension mechanisms [SMTPEXT].
+
+It replaces RFC 821, RFC 974, and the mail transport materials of RFC
+1123.  However, RFC 821 specifies some features that are not in
+significant use in the Internet of 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 the header-people list [HEADER-PEOPLE]
+and problems of unusual readings or interpretations that have turned
+up 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 posting' protocol, as recommended for POP [RFC-POP2,
+RFC-POP3] and IMAP [RFC-IMAP4].
+
+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 discusses message bodies and formats RFC 822,
+MIME, and their relationship - [MSGFMT].
+
+1.  INTRODUCTION
+
+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 describe some of them.  
+
+An important feature of SMTP is its capability to transport mail
+across transport service environments, usually referred to as "mail
+gatewaying" (see section 3.8).  A transport service environment might
+consist of the mutually-TCP-accessible hosts on the public Internet,
+a firewall-isolated private TCP/IP LAN, or a LAN or WAN environment
+utilizing an entirely different transport-level protocol.  It is
+important to realize that "transport systems" are one-to-one with
+usual definitions of "networks".  A process can communicate directly
+with another process, and transport mail using this protocol, through
+any mutually known transport layer.  Conversely, mail can be relayed
+(actually gatewayed) between hosts on different transport systems by
+a host on both transport systems.  The Mail eXchanger mechanisms of
+the domain name system [RFC-DNS, and section ##5 of this document]
+usually permit relaying and gatewaying to occur invisibly to the user.
+
+
+2.  THE SMTP MODEL
+
+2.1 Basic structure
+
+The SMTP design is based on the following model of communication: as
+the result of a user mail request (or transfer from a mail user agent
+(see section ##2.3)), the SMTP client establishes a two-way
+transmission channel to an SMTP server. A fully-capable SMTP client
+determines the address of an appropriate host running an SMTP server
+by resolving the domain name given in the SMTP request to either an
+intermediate mail exchanger host or a final target host. In other
+cases, common with clients associated with implementations of the POP
+[RFC-POP2, RFC-POP3] or IMAP [RFC-IMAP4] protocols, or when the
+client is inside an isolated transport service environment, the SMTP
+client may send all of its traffic to a single SMTP server which, in
+turn, relays the mail to final (or other intermediate) destinations.
+The relay and those destinations are expected to support all of the
+queuing, retrying, and alternate address functions discussed in this
+specification. 
+
+The SMTP server may be either the ultimate destination or an
+intermediate "relay" (i.e., may assume the role of an SMTP client
+after receiving the message).  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. 
+
+Once the transmission channel is established and initial handshaking
+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 headers 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 extension requests
+(e.g., [RFC-Pipeline]).
+
+Once a given mail message has been transmitted, the client may either
+request that the connection be shut down or may initiate other mail
+transactions. 
+
+     -------------------------------------------------------------
+
+   
+               +----------+                +----------+
+   +------+    |          |                |          |
+   | User |<-->|          |      SMTP      |          |
+   +------+    |  Sender- |Commands/Replies| Receiver-|
+   +------+    |   SMTP   |<-------------->|    SMTP  |    +------+
+   | File |<-->|          |    and Mail    |          |<-->| File |
+   |System|    |          |                |          |    |System|
+   +------+    +----------+                +----------+    +------+
+   
+
+                SMTP client                SMTP server
+
+                           Model for SMTP Use
+
+                                Figure 1
+
+     -------------------------------------------------------------
+
+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.  This transmission normally occurs 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.  An intermediate host that acts
+as either an SMTP relay or as a gateway into some other transmission
+environment may also be selected through the use of the domain name
+service (DNS) Mail eXchanger mechanism.
+
+To provide relay capability, the SMTP server is supplied with the
+name of the ultimate destination host as well as the destination
+mailbox name.  Usually, intermediate hosts are determined via the DNS
+MX record, not by explicit "source" routing (see Appendices ##C and
+##I).
+
+
+
+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 permitting the client and server to agree to
+utilize shared functionality beyond the original SMTP requirements.
+Contemporary SMTP implementations MUST support the basic extension
+mechanisms (see below for details), i.e., servers MUST support the
+EHLO command even if they do not implement any specific extensions
+and clients MUST 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 and 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 added, it must be done in a way that permits older
+implementations to continue working acceptably. 
+
+In an effort that started in 1990, approximately a decade after RFC
+821 was completed, the protocol was modified with a "service
+extensions" model permitting 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.
+
+The extension framework consists of:
+
+ (1)   The SMTP command EHLO, superseding the earlier HELO,
+
+ (2)   a registry of SMTP service extensions, 
+
+ (3)   additional parameters to the SMTP MAIL FROM and RCPT TO
+       commands, and
+
+ (4)   optional replacements for verbs defined in this protocol,
+       such as for DATA (e.g., see [RFC-BDAT]).
+
+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.
+
+Contemporary SMTP implementations MUST support the basic extension
+mechanism (see below for details), i.e., servers MUST support the
+EHLO command even if they do not implement any specific extensions
+and clients MUST preferentially utilize EHLO rather than HELO.
+
+
+
+
+
+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
+aformal standards-track or IESG-approved experimental protocol
+document.  The definition must include:
+
+ (1)   the textual name of the SMTP service extension;
+
+ (2)   the EHLO keyword value associated with the extension;
+
+ (3)   the syntax and possible values of parameters associated with
+       the EHLO keyword value; 
+
+ (4)   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);
+
+ (5)   any new parameters the extension associates with the
+       MAIL FROM or RCPT TO verbs;
+
+ (6)   a description of how support for the extension affects the 
+       behavior of a server and client SMTP; and,
+
+ (7)   the increment by which the extension is increasing the
+       maximum length of the commands MAIL FROM and/or RCPT TO, over
+	   that specified in RFC 821.
+
+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" may 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.3 Terminology
+
+Most of the terminology in this document is common in the Internet at
+the time of its writing.  However, the following terms and concepts
+are used in special ways here, or represent differences in
+terminology between RFC 821 and this document, and should be
+understood before reading further.  These definitions are normative,
+i.e., they contain specifications to which SMTP implementations are
+required to conform.
+
+2.3.1 Mail objects
+
+SMTP transports a mail object containing an envelope and content.
+
+ (1)   The SMTP envelope is straightforward, and is sent as a
+       series of SMTP protocol units (described in section ##3): it
+       consists of an originator address (to which error reports
+       should be directed); a delivery mode (e.g., deliver to
+       recipient mailboxes); one or more recipient addresses; and
+       optional protocol extension material.
+
+ (2)   The SMTP content is sent in the SMTP DATA protocol unit and
+       has two parts: the headers and the body. The headers form a
+	   collection of field/value pairs structured as described in
+	   [MSGFMT]; the body, if structured, is defined according to
+	   MIME [RFC-MIME]. The content is textual in nature, expressed
+	   using the US ASCII repertoire[1]. Although extensions (such as
+	   MIME) may relax this restriction for the content body, the
+	   content headers are always encoded using the US ASCII
+	   repertoire. The algorithm defined in [RFC-INTLHDR] is used to
+	   represent 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
+
+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).  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 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 "domain"); identifying them by numerical address is discouraged.
+
+2.3.5 domain
+
+The name of a host (often referred to as a "fully-qualified domain
+name" or "FQDN"), or some entry in the domain name hierarchy, usually
+referred to as a "subdomain", that may contain many hosts.  A domain,
+or domain name, may also refer to an alias (label of a CNAME RR) or
+name the label of Mail eXchanger records to be used to deliver mail.
+See [RFC-DNS] and section ##5.  
+
+The domain name, as described in this document and in [RFC-DNS], is
+the entire, fully-qualified name, and an apparent host name that is
+not in FQDN form is no more than a local alias.  Local aliases MUST
+NOT appear in any SMTP transaction.
+
+
+In other works, if ab.cd.ef is the fully-qualified name of a host (or 
+label for an MX record), then it is obviously a "domain".  However,
+"cd.ef" may be only a domain name; it is possible for it to not refer 
+to any host.
+
+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 which
+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 lines
+
+SMTP commands and, unless altered by a service extension, message
+data, are transmitted in "lines".  Lines consist of zero or more data
+characters terminated by the ASCII sequence "CR" followed immediately
+by "LF".  Conforming implementations MUST NOT recognize or generate
+any other character or character sequence as a line terminator. 
+
+2.3.8 Gateway, relay, originator, and delivery system
+
+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 hands it
+to a mail user agent or deposits it in a maildrop which 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.
+
+
+2.3.9 Message content and message body
+
+The terms "message content" and "mail data" are used interchangably
+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 message headers and the
+possibly-structured message body.  The MIME specification [RFC-MIME]
+provides the Standard mechanisms for structured message bodies See
+##2.3.1.
+
+2.3.10 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" and, consequently, the
+local-part is interpreted and assigned semantics only by the host
+specified in the domain part of the address.
+
+
+2.3.11. reply
+
+An SMTP reply is an acknowledgment (positive or negative) sent from
+receiver to sender via the transmission channel in response to a
+command.  The general form of a reply is a numeric completion code
+(indicating failure or success) followed by a text string.  The codes
+are for use by programs and the text is usually intended for human
+users.
+
+
+
+2.4 Syntax Principles
+
+
+2.4.1 General syntax and transaction model
+
+The mail commands and replies have a rigid syntax.  Replies also have
+a numeric code. Complete lists of commands and replies appear in
+Section ##4 "The SMTP Specification".
+
+Commands and replies are not case sensitive.  That is, a command or
+reply word MAY be upper case, lower case, or any mixture of upper and
+lower case.  Note that this is NOT true of mailbox user names.  For
+some hosts the user name is case sensitive (this practice impedes
+interoperability and is discouraged), therefore, SMTP implementations
+MUST take care to preserve the case of user names as they appear in
+mailbox arguments.  Domain names are not case sensitive.
+
+Commands and replies are composed of characters from the ASCII
+character set [1]. 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 seven bit
+transport only.  Originating SMTP clients 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 mislabelled and the data path cannot accept the actual content,
+this may result in ultimate delivery of a severely garbled message to
+the recipient.  Delivery SMTP systems MAY reject ("bounce") such
+messages rather than deliver them.  No sending SMTP system is
+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.
+
+Eight-bit message content transmission MAY be requested of the server
+by a client using extended SMTP facilities, notably the "8BITMIME"
+extension [8BITMIME].  8BITMIME SHOULD be supported by SMTP servers.
+However, it MUST not be construed as authorization to transmit
+unrestricted eight bit material.  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 and 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 [ABNF].
+Metalanguage terms used in running text and examples are surrounded
+by pointed brackets (e.g., <CRLF>) for clarity.
+
+
+2.4.2 Command and reply syntax
+
+The commands consist of a command code followed by an argument field.
+Command codes are four alphabetic characters and are case insensitive.
+
+This also applies to any symbols representing parameter values, such
+as "TO" or "to" for the forward-path.  Command codes and the argument
+fields are separated by one or more spaces.  However, case is
+important in the local-part within the reverse-path and forward-path
+arguments.  In particular, in some hosts the user "smith" is
+different from the user "Smith".
+
+A few SMTP receiver systems, in violation of this specification (and
+RFC 821) require that a particular case be transmitted by clients.
+Implementations MAY wish to make provision to accommodate those
+systems.
+
+The argument field consists of a variable length character string
+ending 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.
+
+
+
+3.  THE SMTP PROCEDURES: AN OVERVIEW
+
+This section contains descriptions of the procedures used in SMTP:
+session initiation, the mail transaction, forwarding mail, verifying
+mailbox names and expanding mailing lists, and the opening and
+closing exchanges.  Comments on relaying, a note on mail domains, and
+a discussion of changing roles are included at the end of this
+section.  Examples of partial command and reply sequences are used
+throughout; several complete scenarios are presented in Appendix ##F.
+
+
+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 (see section ##7.4), 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
+[MSGFMT]). 
+
+The SMTP protocol allows a server to formally reject a transaction
+  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.
+
+Once the server has sent the welcoming message and the client has
+received it, the client then 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, unable to support
+service extensions, MAY use HELO instead of EHLO.  Servers SHOULD NOT
+return the extended EHLO-style response to a HELO command.
+
+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").
+
+   -------------------------------------------------------------
+   |
+   |              Example of Connection Opening
+   |
+   |  S: 220 UNIX.BBN.COM SMTP Ready - trashmail 1.99.a
+   |  C: EHLO ISIF.ISI.EDU
+   |  S: 250-UNIX.BBN.COM
+   |  S: 250 EXPN
+   |
+   |                        Example 1   |
+   -------------------------------------------------------------
+
+   -------------------------------------------------------------
+   |
+   |              Example of Connection Closing
+   |
+   |  S: QUIT
+   |  R: 221 UNIX.BBN.COM Service closing transmission channel
+   |
+   |                        Example 2
+   |
+   -------------------------------------------------------------
+
+
+3.3.  Mail Transactions
+
+There are three steps to SMTP mail transactions.  The transaction
+starts with a MAIL command which gives the sender identification.  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 <SP> 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> contains
+   the source mailbox, 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).  See section ##4.2.1.  Normally,
+   failures produce 550 or 553 replies. 
+
+   Historically, the <reverse-path> can 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.
+
+      RCPT <SP> TO:<forward-path> [<SP> <rcpt-parameters>] <CRLF>
+
+   This command gives a forward-path (normally a mailbox and domain)
+   identifying one recipient.  If accepted, the SMTP server returns a
+   250 OK reply and stores the forward-path.  If the 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).  This step of the procedure can be repeated any number
+   of times.  The <forward-path> can contain more than just a
+   mailbox.  Historically, the <forward-path> can be 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 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 RCPT TO appears without a previous MAIL FROM, the server
+   MUST return a 503 "Bad sequence of commands" response. The
+   optional <mail-parameters> are associated with negotiated SMTP
+   service extensions (see section ##2.2). 
+
+   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 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 indicator 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 data.  If accepted, the SMTP server returns a 250 OK reply.
+   The DATA command can fail in only two ways:
+
+      o If there was no MAIL FROM, or no RCPT TO, command, or all
+    	such commands were rejected, the server MAY return a "command
+		out of sequence" (503) reply.   If that 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.
+
+      o 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), or if resources were
+        unavailable.  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.   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 RFC 822 format is being used, the mail data include the memo
+header items such as Date, Subject, To, Cc, From [MSGFMT].  Server
+SMTP systems SHOULD NOT reject messages based on perceived defects in
+the RFC 822 or MIME [RFC-MIME] message header or message body.  In
+particular, they MUST NOT reject messages in which the numbers of 
+Resent- 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.
+Example 3 (below) illustrates the use of these commands in a mail
+transaction.
+
+
+      -------------------------------------------------------------
+      |
+      |              Example of the SMTP Mail Transaction Procedure
+      |
+      |  This SMTP example shows mail sent by Smith at host Alpha.foo,
+      |  to Jones, Green, and Brown at host Beta.org.  Here we assume
+      |  that host Alpha contacts host Beta directly.
+      |
+      |     C: MAIL FROM:<Smith@Alpha.foo
+      |     S: 250 OK
+      |
+      |     C: RCPT TO:<Jones@Beta.org
+      |     S: 250 OK
+      |
+      |     C: RCPT TO:<Green@Beta.org
+      |     S: 550 No such user here
+      |
+      |     C: RCPT TO:<Brown@Beta.org
+      |     S: 250 OK
+      |
+      |     C: DATA
+      |     S: 354 Start mail input; end with <CRLF>.<CRLF>
+      |     C: Blah blah blah...<CRLF>
+      |     C: ...etc. etc. etc.
+      |     C: <CRLF>.<CRLF>
+      |     S: 250 OK
+      |
+      |  The mail has now been accepted for Jones and Brown.  Green did
+      |  not have a mailbox at domain Beta.org
+      |
+      |                        Example 3
+      |
+      -------------------------------------------------------------
+
+
+
+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-effectof
+the forwarding activity.  This may be especially important when the
+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) reply code from RCPT TO
+are deprecated: Servers SHOULD NOT provide that service or return
+that code.
+
+
+
+3.5.  Commands for Debugging Addresses
+
+3.5.1 Overview
+
+SMTP provides commands to verify a user name or expand a mailing
+list.  This is done with the VRFY and EXPN commands, which have
+character string arguments.  Implementations MUST support VRFY and
+SHOULD support EXPN (however, see section ##3.5.2 and ##7.3). 
+
+For the VRFY command, the string is a user name or a user name and
+domain (see below). The response MAYinclude the full name of the user
+and MUST include the mailbox of the user, e.g., it MUST be in either
+    User Name <mailbox@domain> 
+or
+    mailbox@domain 
+form.
+
+
+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, either of the following are legitimate
+response to VRFY:
+
+        553 User ambiguous
+   or
+        553- Ambiguous;  Possibilities are
+        553-Joe Smith <jsmith@somedomain>
+        553-Harry Smith <hsmith@somedomain>
+        553 Melvin Smith <dweep@somedomain>
+  or
+		553-Ambiguous;  Possibilities 
+		553- <jsmith@somedomain>
+		553- <hsmith@somedomain>
+		553 <dweep@somedomain>
+
+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 as described in [RFC-REPLY],
+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
+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
+of one mailbox.  If a request is made to verify a mailing list, a
+positive response can 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").  If a
+request is made to expand a user name, the server MAY return a
+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 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 "user@domain" form as a "user name";
+hosts MAY also choose to recognize other strings as "user names".
+
+
+
+The case of verifying a user name is straightforward as shown in
+example 4.
+
+
+  -----------------------------------------------------------------
+  |
+  |           Example of Verifying a User Name
+  |
+  | Either
+  |
+  |   C: VRFY Smith
+  |   S: 250 Fred Smith <Smith@F.ISI.EDU >
+  |
+  | Or
+  |
+  |   C: VRFY Jones
+  |   S: 550 String does not match anything.
+  |
+  | Or
+  |
+  |   C: VRFY Jones
+  |   S: 551 User not local; please try <Jones@ ISIQ.ISI.EDU>
+  |
+  | Or
+  |
+  |   C: VRFY Gourzenkyinplatz
+  |   S: 553 User ambiguous.
+  |
+  | Or
+  |
+  |   C: VRFY fizzle
+  |   S: 252-Cannot VRFY fizzle, but will accept message and 
+  |   S: 252 attempt delivery
+  |
+  |                      Example 4
+  |
+  -----------------------------------------------------------------
+
+      The case of expanding a mailbox list requires a multiline reply
+	  as shown in example 5.
+
+  -------------------------------------------------------------
+  |
+  |           Example of Expanding a Mailing List
+  |
+  |  Either
+  |
+  |     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>>
+  |     S: 250-Quincy Smith <Q-Smith@VAXA.EDU
+  |     S: 250-<joe@totalitarian.org>
+  |     S: 250 <xyz@dominance.universal.int>
+  |
+  |  Or
+  |
+  |     C EXPN Executive-Washroom-List
+  |     S: 550 Access Denied to You.
+  |
+  |                        Example 5
+  |
+  -------------------------------------------------------------
+
+      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. 
+
+
+3.5.2  VRFY normal response.
+
+When normal (2yz or 551) responses are returned from a VRFY or EXPN
+request, the reply should normally include the mailbox name, e.g.,
+"<foo@bar>" (where "bar" is a fully qualified domain name) must
+appear in the syntax.  In exceptional circumstances, free-form text
+MAY be returned.  In order to facilitate parsing by both computers
+and people, addresses SHOULD appear in pointed brackets.  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 MUST support VRFY and SHOULD support 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.  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, they MUST,
+if supported, be listed in the response to EHLO if service extensions
+are supported.
+
+
+3.5.3 Meaning of VRFY or EXPN success response.
+
+A server MUST NOT return a 220 code in response to a VRFY or EXPN
+command unless it has actually verified the address.  In particular,
+a server MUST NOT return 220 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 of VRFY is required and EXPN is
+strongly recommended.  Hence, except as provided in section ##7.3,
+implementations that return 500 or 502 for VRFY are not in 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 discussed in
+section ##2.1 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.
+
+
+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--both for hosts (typically with MX and CNAME DNS
+records) and for mailboxes (various types of local host aliases)--has
+made it nearly impossible for these strategies to work, and mail
+systems SHOULD NOT attempt them.
+
+
+
+3.6.  Domains
+
+
+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 A RRs (as discussed in section ##5) are
+permitted, as are CNAME RRs whose targets can be resolved, in turn,
+to MX or A RRs.  Local nicknames or unqualified names MUST NOT be
+used.  There are two exceptions to this rule: (i) The domain name
+given in the EHLO command MUST BE either a primary host name (a
+domain name that resolves to an A RR) or, if the host has no name, an
+address literal as described in section ##4.1.1.1 and (ii) The
+reserved mailbox name "postmaster" may be used in a RCPT TO command
+without domain qualification (see section ##4.1.1.3).
+
+
+
+3.7.  RELAYING
+
+In general, the availability of Mail eXchanger records in the domain
+name system [RFC-DNS] makes the use of explicit source routes in the
+Internet mail system unnecessary.  Many historical problems with
+their interpretation 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.  They are also permitted
+to ignore the route information and simply send to the final
+destination specified as the last element in the route . 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 -- 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.
+
+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 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 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 beset to null.  A MAIL command
+with a null reverse-path appears as follows:
+
+   MAIL FROM:<>
+
+An undeliverable mail notification message is shown in example 6.
+This notification is in response to a message originated by JOE at
+xyz.somecollege.edu and sent to a user on HOSTY.org 
+
+      -------------------------------------------------------------
+      |
+      |     Example Undeliverable Mail Notification Message
+      |
+      |  C: MAIL FROM:<>
+      |  S: 250 ok
+      |  C: RCPT TO:< JOE@xyz.somecollege.edu>
+      |  S: 250 ok
+      |  C: DATA
+      |  S: 354 send the mail data, end with .
+      |  C: Date: 23 Oct 81 11:22:33
+      |  C: From: SMTP@HOSTY.org
+      |  C: To: JOE@xyz.somecollege.edu
+      |  C: Subject: Mail System Problem
+      |  C:
+<<replace with NOTARY format >>
+      |  C: .
+      |  S: 250 ok
+      |
+      |                        Example 6
+      |
+
+As discussed in section ##2.4.1, a relay SMTP has no need to inspect
+or act upon the headers or body of the message data and MUST NOT do
+so.
+
+
+
+
+3.8  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.8, 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, i.e., 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.8.1  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 ##2.4.1 
+
+Other mail systems gatewayed to the Internet often use a subset of
+RFC-822 headers 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.  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.
+
+
+3.8.2 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. 
+
+Received: 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
+fields arising in non-SMTP environments, receiving systems MUST NOT
+reject mail based on the format of a trace field and SHOULD be
+extremely robust in the light of unexpected information or formats in
+those fields.
+
+The gateway SHOULD indicate the environment and protocol in the "via"
+clauses of Received field(s) that it supplies.
+
+
+3.8.3 From the Internet side, the gateway SHOULD accept all valid
+address formats in SMTP commands and in RFC-822 headers, and all
+valid RFC-822 messages.  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.8.4 The gateway MUST ensure that all header fields of a message
+that it forwards into the Internet meet the requirements for Internet
+mail.  In particular, all addresses in "From:", "To:", "Cc:", etc.,
+fields MUSTbe transformed (if necessary) to satisfy RFC-822 syntax,
+MUST reference only fully-qualified domain names, and MUSTbe
+effective and useful for sending replies.  3.8.5 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 return path from the
+SMTP envelope, not to the sender listed in the "From:" field (or
+other fields) of the RFC-822 message. 
+
+3.8.6 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.9.  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 except: 
+
+   o After receiving a QUIT command and responding with a 221 reply. 
+
+   o After detecting the need to shutdown the SMTP service and
+     returning a message with a 451 response code.  This response
+	 code can be issued after the server receives any command or, if
+	 necessary, asynchronously from command receipt (on the
+	 assumption that the client will receive it after the next
+	 command is issued).
+
+In particular, a server that closes connections in response to
+commands 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 which is forcibly shut down via external means SHOULD
+attempt to send a line containing 451 response code to the SMTP
+client before exiting.  The SMTP client will normally read the 451
+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.
+
+
+
+
+
+3.10  Mailing Lists and Aliases
+
+An SMTP-capable host SHOULD support both the alias and the list form
+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 but
+the message header MUST be left unchanged; in particular, the "From"
+field of the message is unaffected.
+
+An important mail facility is a mechanism for multi-destination
+delivery of a single message, by transforming or "expanding" 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.  We classify such a pseudo-mailbox as an "alias"
+or a "list", depending upon the expansion rules.
+
+
+3.10.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.10.11 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 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.
+
+
+
+
+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 command codes themselves are alphabetic
+characters terminated by <SP> if parameters follow and <CRLF>
+otherwise.  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 which 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 which 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.
+
+
+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 field 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
+available), the client should send an address literal (see section
+##4.1.3), optionally followed by information that will help to
+identify the client system.
+
+The SMTP server identifies itself to the SMTP client in the
+connection greeting reply and in the response to this command.
+
+A client SMTP SHOULD start an SMTP session by issuing the EHLO
+command. If the SMTP server supports the SMTP service extensions it
+will give a successful response, a failure response, or an error
+response. If the SMTP server, in violation of this specification,
+does not support any SMTP service extensions it will generate an
+error response.  Older client SMTP systems MAY, as discussed above,
+use HELO (as specified in RFC 821) instead of EHLO and servers MUST
+support the HELO command and reply properly to it.
+
+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.
+
+Normally, the response to EHLO will be a multiline reply.  Each line
+of the response contains a keyword and, optionally, one or more
+parameters.  The syntax for a positive response, using the ABNF
+notation and low-level terminals of [ABNF], is:
+
+     ehlo-ok-rsp  ::=      "250"    domain [ SP greeting ] CR LF
+                    / (    "250-"   domain [ SP greeting ] CR LF
+                        *( "250-"      ehlo-line           CR LF )
+                           "250"    SP ehlo-line           CR LF   )
+
+     greeting     ::= 1*<any character other than CR or LF>
+
+     ehlo-line    ::= ehlo-keyword *( SP ehlo-param )
+
+     ehlo-keyword ::= (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
+
+                  ; syntax and values depend on ehlo-keyword
+     ehlo-param   ::= 1*<any CHAR excluding SP and all
+                         control characters (US ASCII 0-31
+                         inclusive)>
+
+[[xxx     ALPHA        ::= <any one of the 52 alphabetic characters
+                       (A through Z in upper case, and,
+                        a through z in lower case)>
+     DIGIT        ::= <any one of the 10 numeric characters
+                       (0 through 9)>
+
+     CR           ::= <the carriage-return character
+                       (ASCII decimal code 13)>
+     LF           ::= <the line-feed character
+                       (ASCII decimal code 10)>
+     SP           ::= <the space character
+                       (ASCII decimal code 32)>    /xxx]]
+
+Although EHLO keywords may be specified in upper, lower, or mixed
+case, they must always be recognized and processed in a
+case-insensitive manner. This is simply an extension of practices
+specified in RFC 821 and section ##2.4.1.
+
+
+4.1.1.2 MAIL (MAIL)
+
+This command is used to initiate a mail transaction in which the mail
+data is delivered to one or more mailboxes.  The argument field
+contains a reverse-path.
+
+The reverse-path consists of the sender mailbox or a list of hosts as
+described in Appendix C.  In some types of reporting messages for
+which a reply is likely to cause a mail loop (for example, mail
+delivery and nondelivery notifications), the reverse-path may be null
+(see section ##3.7).
+
+This command clears the reverse-path buffer, the forward-path buffer,
+and the mail data buffer; and inserts the reverse-path information
+from this command into the reverse-path buffer.
+
+If service extensions were negotiated, the MAIL command may also
+carry parameters associated with a particular service extension. 
+
+Syntax: "MAIL FROM:" Reverse-path  [ SP Mail-parameters ]
+                             or
+        "MAIL FROM:<>"
+
+
+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 use of this
+command.
+
+The forward-path normally consists of the required destination
+mailbox(es).  Sending systems SHOULD not generate the optimal list of
+hosts known as a source route.  Receiving systems MUST recognize
+source route syntax but SHOULD strip off the source route
+specification and utilize the domain name associated with the mailbox
+as if the source route had not been provided.
+
+Similarly, relay hosts SHOULD strip or ignore source routes, and
+names MUST NOT be copied into the reverse-path. When mail reaches its
+ultimate destination (the forward-path contains only a destination
+mailbox), the SMTP server inserts it into the destination mailbox in
+accordance with its host mail conventions.
+
+
+For example, mail received at relay host A with envelope commands
+
+      MAIL FROM:<USERX@Y.foo.org
+      RCPT TO:<@HOSTA.INT,@HOSTB.INT:USERC@D.bar.org>
+
+will normally be sent directly on to host D.bar.org with envelope
+commands
+
+      MAIL FROM:<USERX@foo.org>
+      RCPT TO:<USERC@D.bar.org>
+
+as provided in Appendix C, HostA MAY also choose to relay the message
+to HostB, using the envelope commands
+
+      MAIL FROM:<USERX@HOSTY.ARPA>
+      RCPT TO:<@HOSTB.int:USERC@D. BAR.ORG>
+
+Of course, since hosts are not required to relay mail at all, HostA
+may also reject the message entirely when the RCPT TO command is
+received, using a 550 code (since this is a "policy reason").
+
+If service extensions were negotiated, the RCPT TO command may also
+carry parameters associated with a particular service extension
+offered by the server.  The client MUST NOT transmit parameters other
+than those associated with a service extension offered by the server
+in its EHLO response.
+
+Syntax: "RCPT TO:" Forward-path  [ SP Rcpt-parameters ]
+                     or
+        "RCPT TO:<Postmaster>" [ SP Rcpt-parameters ]
+
+
+4.1.1.4 DATA (DATA)
+
+The receiver treats the lines (strings ending in CRLF sequences, see
+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 is terminated by a line containing only a period, that
+is, the character sequence "<CRLF>.<CRLF>" (see Section ##4.5.2 on
+Transparency).  This is the end of mail data indication.  Note that
+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
+data, ends the DATA command itself.  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 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.  Errors that are diagnosed
+subsequently MUST be reported in a mail message, as discussed in
+section ##4.4 In sending a positive completion reply to the end of
+data indication, the receiver takes full responsibility for the
+message (see section ##6.1).
+
+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.
+
+
+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.  A reset command may be issued by the
+client at any time.  It is effectively equivalent to a NOOP if issued
+immediately after EHLO, or before either of those commands are
+issued.  In other situations, it restores the state to that
+immediately after the most recent EHLO.  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, below).
+
+Since EHLO imply some additional processing and response by the
+server, RSET will normally be more efficient than reissuing those
+commands, 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 RSET, followed by a
+QUIT, had been received before the connection disappeared.
+
+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" SP String
+
+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 multiline reply is
+returned containing information as described in section ##3.5.
+
+This command has no effect on the reverse-path buffer, the
+forward-path buffer, or the mail data buffer.
+
+Syntax: "EXPN" SP String
+
+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.
+
+SMTP servers SHOULD support HELP without arguments and MAY support it
+with arguments.
+
+Syntax: "HELP" [ SP String ]
+
+
+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
+an OK reply.
+
+This command has no effect on the reverse-path buffer, the
+forward-path buffer, or the mail data buffer.
+
+Syntax: "NOOP" [SP String]
+
+4.1.1.10 QUIT (QUIT)
+
+This command specifies that the receiver must send an 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 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 act as if a RSET command
+had been received (canceling any pending transaction, but not undoing
+any previously completed transaction) and the client MUST act as if
+the command or transaction in progress had received a temporary error
+(4xx).
+
+Syntax:  "QUIT"
+
+
+4.1.2.  LOWER-LEVEL SYNTAX
+
+The syntax of the argument fields of the above commands (using the
+syntax specified in [ABNF] where applicable) is given below.  Some of
+the productions given below are used only in conjunction with source
+routes as described in Appendix C.
+
+   Reverse-path ::= Path
+
+   Forward-path ::= Path
+
+   Path ::= "<" [ A-d-l ":" ] <mailbox> ">"
+
+   A-d-l ::= At-domain *( "," A-d-l )
+
+   At-domain ::= "@" Domain
+
+   Mail-parameters ::= *( SP Keyword "=" Argument )
+
+   Rcpt-parameters ::=  *( SP Keyword "=" Argument )
+
+   Keyword  ::= String <<>>???
+   Argument ::= String <<>>???
+
+   Domain ::= sub-domain 1*("." sub-domain) | address-literal
+
+   sub-domain ::= let-dig *(ldh-str)
+   address-literal ::= "[" IPv4-address-literal | 
+                  IPv6-address-literal | General-address-literal "]"
+   IPv4-address-literal ::= snum 3("." snum)
+   IPv6-address-literal ::= "IPv6" SP <<what did we finally decide on?>>
+   General-address-literal ::= Standardized-tag SP String
+   Standardized-tag ::= String (Specified in a standards-track RFC
+                                and registered with IANA)
+   snum = one, two, or three digits representing a decimal
+     integer value in the range 0 through 255
+   let-dig = Alpha / Digit
+   ldh-str = *( Alpha / Digit / "-" ) let-dig
+
+<< Placeholder: the following are not right, and the "alpha" one
+<<may need separate rules for case-sensitive and case-insensitive.
+<<Waiting for ABNF to stabilize. >>
+
+   Alpha = ASCII character in the range A-Z or a-z.  As specified in
+     the domain name system definition [RFC-DNS], case is not
+     significant in domain strings.  
+   Digit = 0 - 9
+
+   Mailbox ::= Local-part "@" Domain
+
+   Local-part ::= Dot-string | 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
+of non-ASCII characters (octets with the high order bit set to one)
+or ASCII "control characters" (decimal value 0-31 and 127).  These
+characters MUST NOT be used in MAIL FROM or RCPT TO commands or other
+commands that require mailbox names.
+
+
+<<?>>   <string> ::= <char> | <char> <string>
+
+<<?>>   <quoted-string> ::=  """ <qtext> """
+
+<<?>>   <qtext> ::=  "\" <x> | "\" <x> <qtext> | <q> | <q> <qtext>
+
+   <char> ::= <c> | "\" <x>
+
+   <number> ::= <d> | <d> <number>
+
+   <CRLF> ::= <CR> <LF>
+
+   <CR> ::= the carriage return character (ASCII code 13)
+
+   <LF> ::= the line feed character (ASCII code 10)
+
+   <SP> ::= the space character (ASCII code 32)
+
+   <a> ::= any one of the 52 alphabetic characters A through Z
+             in upper case and a through z in lower case
+
+   <c> ::= any one of the 128 ASCII characters, but not any
+             <special> or <SP>
+
+   <d> ::= any one of the ten digits 0 through 9
+
+   <q> ::= any one of the 128 ASCII characters except <CR>,
+             <LF>, quote ("), or backslash (\)
+
+   <x> ::= any one of the 128 ASCII characters (no exceptions)
+
+   <special> ::= "<" | ">" | "(" | ")" | "[" | "]" | "\" | "."
+             | "," | ";" | ":" | "@"  """ | the control
+             characters (ASCII codes 0 through 31 inclusive and
+             127)
+
+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 field with the comma being the fourth
+character of the field.
+
+Characters outside the set of alphas, digits, and hyphen MUST NOT
+appear in domain names.  In particular, the underscore character is
+not permitted.
+
+            
+
+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 or more small decimal integers
+separated by dots and enclosed by brackets, e.g., [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 space, and the address itself, in a
+format specified elsewhere. (where?)<<IPv6 reference?? >>
+
+
+
+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, 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,
+or 502 failure replies MUST be returned as appropriate.  The 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 ensure that the domain parameter to the EHLO
+command is a valid principal host name (not a CNAME or MX name) for
+its host.  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
+and supplemental information provided that will assist in identifying
+the client.
+
+An SMTP server MAY verify that the domain name parameter in the EHLO
+command actually corresponds to the IP address of the client.
+However, the server MUST NOT refuse to accept a message if the
+verification fails -- the information about verification failure is
+for logging and tracing only.
+
+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 (i.e., 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. 
+
+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 commands, one or more RCPT commands, and a
+DATA command, in that order.  A mail transaction may be aborted by
+the RSET (or a new EHLO) command.  There may be zero or more
+transactions in a session.
+
+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
+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 cannot be used at any other time in a session, but SHOULD be
+used by the client SMTP to request connection closure, even when no
+session opening command was sent and accepted. 
+
+
+
+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) SMTPs.  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, above. 
+
+
+
+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 on Sequencing.
+
+An SMTP reply consists of a three digit number (transmitted as three
+alphanumeric characters) followed by some text.  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 insection
+##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 insection ##4.2.1).  Only the EXPN and HELP
+commands are expected to result in multiline replies in normal
+circumstances, however, multiline replies are allowed for any command.
+
+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.
+
+A client SMTP MUST determine its actions only by the reply code, not
+by the text (except for 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), MUSTbe acceptable.
+The space (blank) following the reply code is considered part of the
+text.  Whenever possible, a sender-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.
+
+
+
+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 five values for the first digit of the reply code:
+
+  1yz   Positive Preliminary reply
+
+     The command has been accepted, but the requested action
+     is being held in abeyance, pending confirmation of the
+     information in this reply.  The SMTP client should send
+     another command specifying whether to continue or abort
+     the action.
+
+        [Note: unextended SMTP does not have any commands that allow
+		this type of reply, and so does not have continue or abort
+		commands.] 
+
+  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- SMTPs) must agree on the interpretation.
+	 Each reply in this category might have a different time value,
+	 but the SMTP client is encouraged to 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
+	 repeated without any change in command form or in properties of
+	 the sender or receiver.  (E.g., 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 is discouraged from repeating 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 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). 
+
+The second digit encodes responses in specific categories:
+
+  x0z   Syntax -- These replies refer to syntax errors,
+        syntactically correct commands that don't fit any
+        functional category, and unimplemented or superfluous
+        commands.
+
+  x1z   Information --  These are replies to requests for
+        information, such as status or help.
+
+  x2z   Connections -- These are replies referring to the
+        transmission channel.
+
+  x3z   Unspecified as yet.
+
+  x4z   Unspecified as yet.
+
+  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.
+
+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, clients SHOULD send the <SP>
+if subsequent text is not sent, but servers MUST be prepared for it
+to be omitted.
+
+  For example:
+                      123-First line
+                      123-Second line
+                      123-234 text beginning with numbers
+                      123 The last line
+
+In many cases the SMTP client then simply needs to search for the
+reply code followed by <SP> at the beginning of a line, and ignore
+all preceding lines.  In a few cases, there is important data for the
+sender in the reply "text".  The sender 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.3)
+   503 Bad sequence of commands
+   504 Command parameter not implemented
+
+   211 System status, or system help reply
+   214 Help message
+      [Information on how to use the receiver or the meaning of a
+      particular non-standard command; this reply is useful only
+      to the human user]
+
+   220 <domain> Service ready
+   221 <domain> Service closing transmission channel
+   421 <domain> Service not available,
+       closing transmission channel
+      [This may be a reply to any command if the service knows it
+      must shut down]
+
+   250 Requested mail action okay, completed
+   251 User not local; will forward to <forward-path>
+      [See section ##3.4]
+   252 Cannot VRFY user, but will accept message and attempt 
+       delivery
+      [See section ##3.5.3]
+   450 Requested mail action not taken: mailbox unavailable
+      [E.g., mailbox busy]
+   550 Requested action not taken: mailbox unavailable
+      [E.g., mailbox not found, no access, or command rejected
+      for policy reasons]
+   451 Requested action aborted: error in processing
+   551 User not local; please try <forward-path>
+      [See section ##3.4]
+   452 Requested action not taken: insufficient system storage
+   552 Requested mail action aborted: exceeded storage allocation
+   553 Requested action not taken: mailbox name not allowed
+      [E.g., mailbox syntax incorrect]
+   354 Start mail input; end with <CRLF>.<CRLF>
+   554 Transaction failed [Or, in the case of a connection-opening
+       response, "No SMTP service here"]
+
+
+4.2.3.  NUMERIC ORDER LIST OF REPLY CODES
+
+   211 System status, or system help reply
+   214 Help message
+      [Information on how to use the receiver or the meaning of a
+      particular non-standard command; this reply is useful only
+      to the human user]
+   220 <domain> Service ready
+   221 <domain> Service closing transmission channel
+   250 Requested mail action okay, completed
+   251 User not local; will forward to <forward-path>
+      [See section ##3.4]
+   252 Cannot VRFY user, but will accept message and attempt 
+      delivery
+      [See section ##3.5.3]
+
+   354 Start mail input; end with <CRLF>.<CRLF>
+
+   421 <domain> Service not available,
+       closing transmission channel
+      [This may be a reply to any command if the service knows it
+      must shut down]
+   450 Requested mail action not taken: mailbox unavailable
+      [E.g., mailbox busy]
+   451 Requested action aborted: local error in processing
+   452 Requested action not taken: insufficient system storage
+
+   500 Syntax error, command unrecognized
+      [This may include errors such as command line too long]
+   501 Syntax error in parameters or arguments
+   502 Command not implemented
+   503 Bad sequence of commands
+   504 Command parameter not implemented
+   550 Requested action not taken: mailbox unavailable
+      [E.g., mailbox not found, no access, or command rejected
+      for policy reasons]
+   551 User not local; please try <forward-path>
+      [See section ##3.4]
+   552 Requested mail action aborted: exceeded storage allocation
+   553 Requested action not taken: mailbox name not allowed
+      [E.g., mailbox syntax incorrect]
+   554 Transaction failed  [Or, in the case of a connection-opening
+       response, "No SMTP service here"]
+         
+
+4.2.4.  Reply code 502
+
+Questions have 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.2.6.
+
+ 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 FROM command). 
+
+
+When an SMTP server returns a transient error completion status (4yz)
+code after the DATA command is completed with <CRLF>.<CRLF>, it MUST
+NOT make any further attempt to deliver that message.  The SMTP
+client retains responsibility for 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).  The sending user should be able to
+interpret the return of a transient or permanent failure status as a
+non-delivery indication.
+
+
+
+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 (i.e., 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 ##4.1.3 for a discussion of alternatives in
+these situations.
+
+      For example,
+
+         220 ISIF.USC.EDU Service ready
+      or
+
+         220 LOSER.BOGUS.COM Trashmail v 6.1.2 Service ready
+
+The table below lists alternative success and failure replies for
+each command.  These SHOULD be strictly adhered to; a receiver may
+substitute text in the replies, but the meaning and action implied by
+the code numbers and by the specific command reply sequence cannot be
+altered.
+
+4.3.2 Command-Reply Sequences
+
+Each command is listed with its usual possible replies.  The prefixes
+used before the possible replies are "P" for preliminary (not used in
+SMTP), "I" for intermediate, "S" for success, "F" for failure, and
+"E" for error.  The 421 reply (service not available, closing
+transmission channel) may be given to any command if the SMTP
+receiver knows it must shut down.  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.  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.
+
+      CONNECTION ESTABLISHMENT
+         S: 220
+         F: 421, 554
+      EHLO             (or HELO)
+         S: 250
+         E: 500*, 501, 504, 421, 550
+      MAIL
+         S: 250
+         F: 552, 451, 452
+         E: 500*, 501, 421, 550, 553
+      RCPT
+         S: 250, 251 (but see section ##3.4 for discussion of 251)
+         F: 550, 551, 552, 553, 450, 451, 452
+         E: 500*, 501, 503, 421, 550
+      DATA
+         I: 354 -> data -> S: 250
+                           F: 552, 554, 451, 452
+         F: 451, 554
+         E: 500*, 501, 503, 421
+      RSET
+         S: 250
+         E: 500*, 501, 504, 421
+      SEND
+         S: 250
+         F: 552, 451, 452
+         E: 500, 501, 502, 421
+      SOML
+         S: 250
+         F: 552, 451, 452
+         E: 500, 501, 502, 421
+      SAML
+         S: 250
+         F: 552, 451, 452
+         E: 500, 501, 502, 421
+      VRFY
+         S: 250, 251, 252
+         F: 550, 551, 553
+         E: 500*, 501, 502, 504, 421
+      EXPN
+         S: 250, 252
+         F: 550
+         E: 500, 501, 502, 504, 421
+      HELP
+         S: 211, 214
+         E: 500, 501, 502, 504, 421
+      NOOP
+         S: 250
+         E: 500*, 421
+      QUIT
+         S: 221
+         E: 500*
+      TURN
+         S: 250
+         F: 502
+         E: 500, 503
+
+      * Since support of this command is required, returning
+        this reply code as part of an "unrecognized command"
+        status places an implementation out of conformance with
+        this specification.
+
+
+
+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
+under the DATA command in section ##4.1.1.4.
+
+This line must be structured as follows:
+
+   *    The FROM field SHOULD contain both (1) the name of the
+        source host as presented in the EHLO command and (2) an
+		address literal containing the IP address of the source,
+        determined from the TCP connection.
+
+   *    The ID field MAY contain an "@" as suggested in RFC-822,
+        but this is not required.
+
+   *    The FOR field MAY contain a list of <path> entries when
+        multiple RCPT commands have been given.
+
+An Internet mail program MUST NOT change a Received: line that was
+previously added to the message header.  SMTP servers MUST prepend
+Received lines to messages; they MUST NOT change the order of
+existing lines or insert Received lines in any other location. 
+
+As the Internet grows, comparability of Received fields is important
+for detecting problems, especially slow relays.  SMTP servers that
+create Received fields SHOULD use explicit offsets in the dates
+(e.g., -0800), rather than time zone names of any type.  Local time
+(with an offset) is preferred to UT when feasible.  If a time zone
+name is used, 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 world.  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 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 mail data headers and body [RFC822]. 
+
+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 FROM 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.  SMTP servers performing a
+relay function MUST NOT inspect the message data, and especially not
+to the extent needed to determine if Return-path headers are present.
+SMTP servers making final delivery MAY remove Return-path headers
+before adding their own. 
+
+The primary purpose of the Return-path is to designate the address to
+which messages indicating non-delivery or other mail system failures
+are to be sent.  For this to be unambigious, 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.
+
+   Historical note: Text in RFC 822 that appears to contradict the
+   use of Return-path (or the envelope MAIL FROM address) as the
+   destination for error messages is not applicable on the Internet.
+   The MAIL FROM address (as copied into the Return-path) MUST be
+   used as the target of any mail containing delivery error messages.
+   << Probably should take this out if [MSGFMT] adequately
+   clarifies that point --Ed.>>
+
+In particular,
+
+(i) a gateway from SMTP->elsewhere SHOULD insert a return-path
+header, unless it is known that the "elsewhere" transport also uses
+Internet domain addresses and maintains the envelope sender address
+separately.
+
+(ii)  a gateway from elsewhere->SMTP SHOULD delete any
+return-path header present in the message, and either copy
+that information to the SMTP envelope or combine it with
+information present in the envelope of the other transport
+system to construct the MAIL FROM part of 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 is
+preferred when possible.  All undeliverable mail notification
+messages are sent using the MAIL command (even if they result from
+processing the obsolete SEND, SOML, or SAML commands) and use a null
+return path as discussed in section ##3.7.
+
+ <<The following section is incomplete in this draft >>>
+
+The time stamp line and the return path line are formally defined as
+follows:
+
+<return-path-line> ::= "Return-Path:" <SP><reverse-path><CRLF>
+
+<time-stamp-line> ::= "Received:" <SP> <stamp> <CRLF>
+
+<stamp> ::= <from-domain> <by-domain> <opt-info> ";"
+          <daytime>
+
+<from-domain> ::= "FROM" <SP> <domain> <SP>
+
+<by-domain> ::= "BY" <SP> <domain> <SP>
+
+<opt-info> ::= [<via>] [<with>] [<id>] [<for>]
+
+<via> ::= "VIA" <SP> <link> <SP>
+
+<with> ::= "WITH" <SP> <protocol> <SP>
+
+<id> ::= "ID" <SP> <string> <SP>
+
+<for> ::= "FOR" <SP> <path> <SP>
+
+<< FOR and <link> need to be nailed down.>>
+
+   <link> ::= The standard names for links are registered with
+             the Internet Assigned Numbers Authority (IANA).
+
+   <protocol> ::= The standard names for protocols are
+             registered with the Internet Assigned Numbers Authority
+             (IANA). 
+
+   <daytime> ::= <SP> <date> <SP> <time>
+
+   Date ::= Dd SP Mon SP YYYY
+
+       Note that the earlier form, which permits two-digit years, has
+       been deprecated.  SMTP systems MUST use four-digit years.
+
+   <time> ::= <hh> ":" <mm> ":" <ss> <SP> <zone>
+
+   Dd ::= the one or two decimal integer day of the month in
+             the range 1 to 31.
+
+   Mon ::= "JAN" | "FEB" | "MAR" | "APR" | "MAY" | "JUN" |
+             "JUL" | "AUG" | "SEP" | "OCT" | "NOV" | "DEC"
+
+   YYYY ::= the four decimal integer year in the range 0000 to
+             9999. 
+
+   <hh> ::= the two decimal integer hour of the day in the
+             range 00 to 24.
+
+   <mm> ::= the two decimal integer minute of the hour in the
+             range 00 to 59.
+
+   <ss> ::= the two decimal integer second of the minute in the
+             range 00 to 59.
+
+   <zone> ::= A four digit, signed time zone offset, such as -0600 for
+             US Eastern Standard Time.  This may be supplemented by a
+             time zone name in parentheses, e.g., "-0800 (PDT)".  See
+             ##___ for additional discussion.
+
+          Note that there is no default; time zone information
+          is required and MUST be supplied.
+
+
+
+
+-------------------------------------------------------------
+|
+|  Example of Return Path and Received Time Stamps
+|
+| Return-Path: <@GHI.ARPA,@DEF.ARPA,@ABC.ARPA:JOE@ABC.ARPA>   
+| Received: from GHI.ARPA by JKL.ARPA ; 27 Oct 81 15:27:39 -0800
+| Received: from DEF.ARPA by GHI.ARPA ; 27 Oct 81 15:15:13 -0800
+| Received: from ABC.ARPA by DEF.ARPA ; 27 Oct 81 15:01:59 -0800
+| Date: 27 Oct 81 15:01:01 -0800 (PST)
+| From: JOE@ABC.ARPA                                          
+| Subject: Improved Mailing System Installed                  
+| To: SAM@JKL.ARPA                                            
+|
+| This is to inform you that ...                              
+|
+|                      Example 8
+|
+-------------------------------------------------------------
+
+
+
+
+
+4.5.  DETAILS
+
+4.5.1.  MINIMUM IMPLEMENTATION
+
+In order to make SMTP workable, the following minimum
+implementation is required for all receivers:
+
+   COMMANDS -- HELO
+               VRFY
+               MAIL
+               RCPT
+               DATA
+               RSET
+               NOOP
+               QUIT
+
+Any system that includes an SMTP server supporting mail relaying
+or delivery, i.e., the RCPT command, 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 TO
+commands which 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.
+
+EHLO SHOULD be supported if possible.
+
+
+
+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.
+
+   1. 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.
+
+   2. 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
+format effectors and other control characters.  If the transmission
+channel provides an 8-bit byte (octets) data stream, the 7-bit ASCII
+codes are transmitted right justified in the octets, with the high
+order bits cleared to zero.  See ##3.7 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 or
+store data in records rather than strings.  If such transformationss
+are necessary, they must be reversible -- especially if such
+transformationss are applied to mail being relayed.
+
+
+4.5.3.  SIZES AND TIMEOUTS
+
+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, e.g., encoded
+X.400 addresses [RFC-X400] 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 WHICH IMPOSE NO LIMITS ON THE LENGTH *
+*  OF THESE OBJECTS SHOULD BE USED.                *
+*                                                  *
+****************************************************
+
+local-part
+
+   The maximum total length of a user name or other local-part
+
+is 64 characters.
+
+domain
+
+   The maximum total length of a domain name or number is 255
+   characters.
+
+path
+
+   The maximum total length of a reverse-path or
+   forward-path is 256 characters (including the punctuation
+   and element separators).
+
+command line
+
+   The maximum total length of a command line including the
+   command word and the <CRLF> is 512 characters.
+
+reply line
+
+   The maximum total length of a reply line including the reply code
+   and the <CRLF> is 512 characters.  More information may be
+   conveyed through multiple-line replies. 
+
+
+text line
+
+   The maximum total length of a text line including the <CRLF> is
+   1000 characters (not counting the leading dot duplicated for
+   transparency).  This number may be increased by the use of SMTP
+   Service Extensions. 
+
+message content
+
+   The maximum total length of a message content (including any
+   message headers as well as the message body) MUST BE at least 64K 
+   octets. Since the introduction of multimedia mail [RFC-MIME],
+   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 ([RFC-SIZE]), and SMTP client systems
+   that will send large messages SHOULD utilize it when possible.
+
+recipients buffer
+
+   The minimum total number of recipients that must be buffered is
+   100 recipients. Rejection of messages (for excessive recipients)
+   with fewer than 100 RCPT TO commands is a violation of this
+   specification.  The general principle that relaying SMTP servers
+   MUST NOT, and delivery SMTP servers SHOULD NOT, perform validation
+   tests on message headers suggests that rejecting a message based
+   on the total number of recipients shown in header fields is to be
+   discouraged.  A server which imposes a limit on the number of
+   recipients MUST behave in an orderly fashion, e.g., reject
+   additional addresses over its limit rather than silently
+   discarding addresses previously accepted.  A client that needs to
+   deliver a message containing over 100 RCPT TO commands SHOULD be
+   prepared to transmit in 100-recipient "chunks" if the server
+   declines to accept more than 100 recipients in a single message. 
+
+
+****************************************************
+*                                                  *
+*  TO THE MAXIMUM EXTENT POSSIBLE, IMPLEMENTATION  *
+*  TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH *
+*  OF THESE OBJECTS SHOULD BE USED.                *
+*                                                  *
+****************************************************
+
+Errors due to exceeding these limits may be reported by using the
+reply codes, for example:
+
+500 Line too long.
+
+501 Path too long
+
+552 Too many recipients.
+
+<< Note in draft: Should this be 452?>>
+
+552 Too much mail data.
+
+
+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: 
+
+o    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. 
+
+o    MAIL Command: 5 minutes
+
+
+o    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.
+
+o    DATA Initiation: 2 minutes
+
+     This is while awaiting the "354 Start Input" reply to a
+     DATA command.
+
+o    Data Block: 3 minutes
+
+     This is while awaiting the completion of each TCP SEND call
+	 transmitting a chunk of data. 
+
+o    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. 
+
+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   Queuing Strategies
+
+The common structure of a host SMTP implementation includes user
+mailboxes, one or more areas for queueing 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 queueing strategy MUST include:
+
+o    Timeouts on all activities on a per-command basis.
+
+o    Never sending error messages in response to error messages.
+
+
+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.
+
+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.  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 that
+discussed in [RFC-ETRN].
+
+The strategy may be further modified as a result of multiple
+addresses per host (see below) to optimize delivery time vs.
+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 MAIL FROM MUST NOT be cached.
+
+When the same message will be delivered to several users on the same
+host, only one copy of the message SHOULD be transmitted.  That is,
+the SMTP client SHOULD use the command sequence: RCPT, RCPT,... RCPT,
+DATA instead of the sequence: RCPT, DATA, ..., RCPT, DATA, ... RCPT,
+DATA.  Implementation of this efficiency feature is strongly
+encouraged.
+
+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 at all times.  This requires the support of multiple incoming
+TCP connections for SMTP.  Some limit MAY be imposed.
+
+As discussed above, when the SMTP server receives mail from a
+particular host address, it could notify the SMTP client to retry any
+mail pending for that host address.
+
+
+
+5. Address resolution and mail handling
+
+Once an SMTP client lexically identifies a domain to which mail will
+be delivered for processing (as described in sections ##3.6 and
+##3.7), a DNS lookup is performed to resolve the domain name (see
+[RFC-DNS]).  The lookup first attempts to locate an MX record
+associated with the name.  If a CNAME record is found instead, the
+resulting name is processed as if it were the initial name.  If no MX
+records are found, but an A RR is found, the A RR is treated as if it
+was associated with an implicit MX RR, with a preference of 0,
+pointing to that host.  If one or more MX RRs are found for a given
+name, SMTP systems MUST NOT utilize an A RRs associated with that
+name unless they are located using the MX RRs; i.e., the "implicit
+MX" rule above applies only if there are no MX records present.  If
+MX records are present, but none of them are usable, this situation
+MUST be reported as an error.
+
+When the lookup succeeds, the mapping can result in a list of
+alternative delivery addresses rather than a single address, because
+of (a) multiple MX records, (b) 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, a host SHOULD try at least two addresses.
+
+The following information is used to rank the host addresses:
+
+ (1)  Multiple MX Records -- these contain a preference indication
+    that should be used in sorting (see below).  Lower numbers are
+	more preferred than higher ones.  If there are multiple
+	destinations with the same preference and there is no clear
+	reason to favor one (e.g., by recognition of an easily-reached
+	address), then the sender-SMTP SHOULD pick one at random to
+	spread the load across multiple mail exchangers for a specific
+	organization.
+
+ (2)  Multihomed host -- The destination host (perhaps taken from the
+    preferred MX record) may be multihomed, in which case the domain
+	name resolver will return a list of alternative IP addresses.  It
+	is the responsibility of the domain name resolver interface to
+	have ordered this list by decreasing preference if necessary, and
+	SMTP MUST try them in the order presented.
+
+    Although the capability to try multiple alternative addresses is
+	required, specific installations may want to limit or disable the
+	use of alternative addresses.  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 counterargument 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 a host receives a message with a destination for which it is a
+designated Mail eXchanger, it MAY relay the message (potentially
+after having rewritten the addresses), make final delivery of the
+message, or hand it off using some mechanism outside the
+SMTP-provided transport environment.
+
+If it determines that it should relay the message without rewriting
+the address, it must sort the MX records to determine candidates for
+delivery. The records are first ordered by preference, with the
+lowest-numbered records being most preferred.  The relay host must
+then inspect the list for any of the names or addresses by which it
+might be known in mail transactions.  If a matching record is found,
+all records at that preference level and higher-numbered ones MUST BE
+discarded from consideration.  If there are no records left at that
+point, it is an error condition, and the message must be returned as
+undeliverable.  If records do remain, they should be tried, best
+preference first, as described above.
+
+
+6. 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, i.e., it MUST NOT lose the message for frivolous reasons,
+e.g., because the host later crashes or because of a predictable
+resource shortage.
+
+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 SHOULD be the address
+from the envelope return path (or the Return-Path: line).  However,
+if this address is null ("<>"), the receiver-SMTP MUST NOT send a
+notification.  If the address is an explicit source route, it MUST be
+stripped down to its final hop.
+
+DISCUSSION:
+     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 should 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
+[RFC1047] for a discussion of this problem.
+
+
+6.2 Loop detection
+
+Simple counting of the number of Received lines 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.3 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
+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 [RFC-POP2,
+RFC-POP3, RFC-IMAP2, RFC-PCMAIL These protocols have encouraged the
+use of SMTP as a posting 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]).  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.
+
+The following changes to a message being processed MAY be applied by
+an originating SMTP server, or one used as the target of SMTP as an
+initial posting protocol, when necessary.  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.
+
+    - Addition of a message-id field when none appears
+
+    - Addition of a date, time or time zone when none appears
+
+    - Correction of addresses to proper FQDN format
+
+In all cases, properly-operating clients supplying correct
+information are preferred to corrections by the SMTP server. In all
+cases, documentation of actions performed by the servers (in trace
+fields and/or header comments) is strongly encouraged.
+
+
+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, e.g., those that can be provided in the MOSS
+framework [RFC-MOSS].
+
+Efforts to make it more difficult for users to set envelope MAIL FROM
+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 or in which error
+(or normal) replies should be directed to a special address. (Systems
+that provide convenient ways for users to alter these fields on a
+per-message basis should attempt to establish a primary and permanent
+mailbox address for the user so that Sender fields within the message
+data can be generated sensibly.)
+
+
+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 an ignorant user who is trying to fake mail.
+
+
+
+7.2 "Blind" copies.
+
+Addresses that do not appear in the message headers may appear in the
+RCPT TO 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".  In order to avoid defeating some of
+the purpose of these mechanisms, SMTP clients and servers SHOULD NOT
+copy the full set of RCPT TO command arguments into the headers, even
+as informational or private-extension headers.  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 TO command.
+
+There is no inherent relationship between either "reverse" (MAIL
+FROM, SAML FROM, etc.) or "forward" (RCPT TO) addresses in the SMTP
+transaction ("envelope") and the addresses in the headers.  Receiving
+systems SHOULD NOT attempt to deduce such relationships and use them
+to alter the headers of the message for delivery.  The popular
+"Apparently-to" header is a violation of this principle and SHOULD
+NOT be used.
+
+
+7.3  VRFY, EXPN, and security.
+
+As discussed in section ##3.5, individual sites may want to disable
+one or both VRFY or EXPN for security reasons.  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.
+
+Within the last four years, the contents of mailing lists have become
+popular as an address information source for so-called "spammers."
+The use of EXPN to "harvest" addresses has increased as list
+administrators have installed protections against inappropriate uses
+of the lists themselves.  Implementations SHOULD still provide
+support for EXPN, but sites should carefully evaluate the tradeoffs..
+As authentication mechanisms are introduced into SMTP, some sites may
+choose to make EXPN available only to authenticated requestors.
+
+
+7.4.  Information Disclosure
+
+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 useful
+information to 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 vunerabilities
+by hiding the server's precise identity will provide more protection.
+Sites are encouraged to evaluate the tradeoff with that issue in
+mind; implementations are strongly encouraged to minimally provide
+for making type and version information available in some way to
+other network hosts. 
+
+
+7.5.  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.
+
+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, MAIL FROM, or RCPT TO as appropriate.
+
+
+8. IANA Considerations
+
+IANA is [[requested]] to set up two registries.  The first 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 IESG for this purpose.
+
+The second registry consists of "tags" that identify forms of domain
+literals other than those for IPv4 addresses (specified in RFC 821
+and in this document) and IPv6 addresses (specified in this
+document).  Additional literal types require standardization before
+being used; none are anticipated at this time.
+
+
+9.  REFERENCES
+
+[1]  ASCII
+
+   ASCII, "USA Code for Information Interchange", United States of
+   America Standards Institute (now American National Standards
+   Institute), X3.4, 1968.  ANSI X3.4-1968 has been replaced by
+   newer versions with slight modifications, but the 1968
+   version remains definitive for the Internet.
+
+[RFC822]
+   Crocker, D., "Standard for the Format of ARPA Internet Text
+   Messages", RFC 822, Department of Electrical Engineering,
+   University of Delaware, August 1982.
+
+[3]  TCP
+   Postel, J., ed., "Transmission Control Protocol - DARPA Internet
+   Program Protocol Specification", RFC 793, USC/Information Sciences
+   Institute, NTIS AD Number A111091, September 1981.
+
+[HEADER-PEOPLE]
+
+[RFC-DNS] P. Mockapetris, "Domain names - implementation and
+      specification", RFC 1035 and P. Mockapetris, "Domain names -
+      concepts and facilities", RFC 1034.  (STD 13)
+
+[RFC974] C. Partridge, "Mail routing and the domain system", RFC
+      974, 01/01/1986
+
+[RFC1047] C. Partridge, "Duplicate messages and SMTP", RFC 1047,
+      02/01/1988.
+
+[RFC-SIZE]  J. Klensin, N. Freed, K. Moore, "SMTP Service Extension
+      for Message Size Declaration", RFC 1870, 11/06/1995.  (STD 10)
+
+[RFC-MIME] N. Freed, N. Borenstein, "Multipurpose Internet Mail 
+      Extensions  (MIME) Part One:  Format of Internet Message
+	  Bodies", RFC 2045, 12/02/1996. 
+
+[RFC-INTLHDR] K. Moore, "MIME (Multipurpose Internet Mail Extensions) 
+      Part Three:  Message Header Extensions for Non-ASCII Text", 
+	  RFC 2047, 12/02/1996. 
+
+[8BITMIME]  J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker,
+      "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652,
+      07/18/1994. 
+
+[SMTPEX]  J. Klensin, N. Freed, M. Rose, E. Stefferud, D.
+      Crocker, "SMTP Service Extensions", RFC-1869, 11/06/1995.
+
+[RFC-1123] R. Braden, "Requirements for Internet hosts -
+   application and support", 10/01/1989 
+
+[RFC-MOSS]  S. Crocker, N. Freed, J. Galvin, S. Murphy, "MIME Object
+   Security Services", RFC 1848, 10/03/1995.
+
+[RFC-POP2] M. Butler, D. Chase, J. Goldberger, J. Postel, J.
+     Reynolds, "Post Office Protocol - version 2", RFC 937,
+     02/01/1985
+
+[RFC-IMAP2]  M. Crispin, "Interactive Mail Access Protocol - Version
+     2", RFC 1176, 08/20/1990.
+
+[RFC-PCMAIL]  M. Lambert, "PCMAIL: A distributed mail system for
+     personal computers", RFC 1056, 06/01/1988.
+
+[RFC-POP3]  J. Myers, M. Rose, "Post Office Protocol - Version 3",
+   RFC 1930, 5/14/96 (Std 53).
+
+[RFC-IMAP4] M. Crispin, "Internet Message Access Protocol
+   - Version 4", RFC 2060, 12/04/1996.
+
+[RFC-X400]  S. Hardcastle-Kille, "Mapping between X.400(1988) /
+   ISO 10021 and RFC 822", RFC 1327, 05/18/1992.
+
+[RFC-ETRN] J. De Winter, "SMTP Service Extension for Remote
+   Message Queue Starting", RFC 1985, 08/14/1996.
+
+[RFC-BDAT] G. Vaudreuil, "SMTP Service Extensions for
+   Transmission of Large and Binary MIME Messages", RFC 1830,
+   08/16/1995. 
+
+[RFC-PIPELINE] N. Freed, A. Cargille, "SMTP Service Extension
+   for Command Pipelining", RFC 1854, 10/04/1995.
+
+[RFC-NOTARY1] K. Moore, "SMTP Service Extension for Delivery
+   Status Notifications", RFC 1891, 01/15/1996.
+
+[RFC-NOTARY2] K. Moore, G. Vaudreuil, "An Extensible Message
+   Format for Delivery Status Notifications", RFC 1894,
+   01/15/1996. 
+
+[RFC-REPLY] G. Vaudreuil, "Enhanced Mail System Status Codes",
+   RFC 1893, 01/15/1996.
+
+[ABNF] Crocker, D., "Augmented BNF for Syntax Specifications: ABNF",
+   (in progress -- draft-ietf-drums-abnf-03.txt)
+
+[MSGFMT]  P. Resnick, Work in progress,
+      draft-ietf-drums-msg-fmt-02.txt, June 1997.
+
+
+9. Editor's Addresses
+
+ John C. Klensin
+ MCI Communications
+ 800 Boylston St., 7th floor
+ Boston, MA 02199
+ USA
+   Email: Klensin@mci.net
+   Phone: +1 617 960 1011
+   Fax:   +1 617 960 1009
+
+Dawn P. Mann
+Microsoft Corporation
+1 Microsoft Way
+Redmond, WA 98052-6399
+USA
+   Email: dawnm@microsoft.com
+   Tel: +1 425 936 5475
+
+
+
+10. Acknowledgments
+
+<<>>to be supplied>> 
+
+
+
+APPENDIX A
+
+TCP Transport service
+
+The Transmission Control Protocol [3] is used in the Internet, and in
+any network following the Internet standards for internetwork protocols.
+
+Connection Establishment
+
+   The SMTP transmission channel is a TCP connection established
+   between the sender process port U and the receiver process port
+   L.  This single full duplex connection is used as the
+   transmission channel.  This protocol is assigned the service
+   port 25 (31 octal), that is L=25.
+
+Data Transfer
+
+   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, but not in SMTP commands or responses.
+
+
+
+APPENDIX B
+
+Generating SMTP commands from RFC 822 headers
+ 
+Some systems use RFC 822 headers (only) in a mail submission
+protocol, or otherwise generate SMTP commands from RFC 822 headers
+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 a
+mail envelopes is not separated early in processing from header
+information (and kept separate).  
+
+It is recommended that the UA provide its initial MTA with an
+envelope separate from the message itself.  However, if the envelope
+is not supplied, SMTP commands should be generated as follows:
+
+(i) each recipient address from a TO, CC, or BCC header field
+should be copied to a RCPT command (generating multiple message
+copies if that is required for queuing or delivery).  This includes
+any addresses listed in a RFC 822 "group".  Any BCC fields should
+then be removed from the headers.  Once this process is completed,
+the remaining headers should be checked to verify that at least one
+To:, Cc:, or Bcc: header remains.  If none do, then a bcc: header
+with no additional information SHOULD be inserted as specified in
+[MSGFMT].
+
+(ii) the return address in the MAIL command should, if possible, be
+derived from the system's identity for the submitting (local) user.
+And the From header field otherwise.  If there is a system identity
+available, it should also be copied to the Sender header field if it
+is different from the address in the From header field.  (Any Sender
+field that was already there should be removed.)  Systems may provide
+a way for submitters to override the envelope return address, but may
+want to restrict its use to privileged users.  (This will not prevent
+mail forgery, but may lessen its incidence -- see section 7.1.)
+
+When an MTA is being used in this way, it bears responsibility for
+ensuring that the message being transmitted is valid.  The mechanisms
+for checking that validity, and for handling (or returning) messages
+that are not valid at the time of arrival, are part of the MUA-MTA
+interface and not covered by this specification.
+
+A submission protocol based on Standard RFC 822 information alone
+MUST NOT be used to gateway a message from a foreign (non-SMTP) mail
+system into an SMTP environment.  Additional information to construct
+an envelope must come from some source in the other environment,
+whether supplemental headers or the foreign system's envelope.
+
+Attempts to gateway messages using only their header "to" and "cc"
+fields, have repeatedly caused mail loops and other behavior adverse
+to the proper functioning of the Internet mail environment.  These
+problems have been especially common when the message originates from
+an Internet mailing list and is distributed into the foreign
+environment using envelope information.  When these messages are then
+processed by a header-only remailer, loops back to the Internet
+environment (and the mailing list) are almost inevitable.
+
+
+APPENDIX C
+
+Source routes.
+
+The <reverse-path> is a reverse source routing list of hosts and a
+source mailbox.  The first host in the <reverse-path> should be the
+host sending the MAIL FROM command.  Similarly, the <forward-path>
+may be a source routing lists of hosts and a destination mailbox.
+However, in general, the <forward-path> should contain only a mailbox
+and domain name, relying on the domain name system to supply routing
+information if required.   The use of source routes is deprecated;
+while servers MUST be prepared to receive and handle them as
+discussed in section ##3.3 and below, clients SHOULD NOT transmit
+them. 
+
+For relay purposes, the forward-path may be a source route of the
+form "@ONE,@TWO:JOE@THREE", where ONE, TWO, and THREE MUST BE
+fully-qualified domain names.  This form is used to emphasize the
+distinction between an address and a route.  The mailbox is an
+absolute address, and the route is information about how to get
+there.  The two concepts should not be confused.
+
+If source routes are used, RFC 821 and the text below should be
+consulted for the mechanisms for constructing and updating the
+forward- and reverse-paths.
+
+The SMTP server transforms the command arguments by moving its own
+identifier (its domain name or that of any domain for which it is
+acting as a mail exchanger), if it appears, from the forward-path to
+the beginning of the reverse-path.  
+
+Notice that the forward-path and reverse-path appear in the SMTP
+commands and replies, but not necessarily in the message.  That is,
+there is no need for these paths and especially this syntax to appear
+in the "To:" , "From:", "CC:", etc. fields of the message header.
+Conversely, SMTP servers MUST NOT derive final message delivery
+information from message header fields.
+
+ When the list of hosts is present, it is a "reverse" source route
+and indicates that the mail was relayed through each host on the list
+(the first host in the list was the most recent relay).  This list is
+used as a source route to return non-delivery notices to the sender.
+As each relay host adds itself to the beginning of the list, it must
+use its name as known in the transport environment to which it is
+relaying the mail rather than that of the transport environment from
+which the mail came (if they are different). 
+
+
+
+
+APPENDIX F
+
+Scenarios
+
+This section presents complete scenarios of several types of SMTP
+sessions.
+
+A Typical SMTP Transaction Scenario
+
+This SMTP example shows mail sent by Smith at host USC-ISIF, to
+Jones, Green, and Brown at host BBN-UNIX.  Here we assume that host
+USC-ISIF contacts host BBN-UNIX directly.  The mail is accepted for
+Jones and Brown.  Green does not have a mailbox at host BBN-UNIX.
+
+-------------------------------------------------------------
+
+   R: 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready
+   S: HELO USC-ISIF.ARPA
+   R: 250 BBN-UNIX.ARPA
+
+   S: MAIL FROM:<Smith@USC-ISIF.ARPA>
+   R: 250 OK
+
+   S: RCPT TO:<Jones@BBN-UNIX.ARPA>
+   R: 250 OK
+
+   S: RCPT TO:<Green@BBN-UNIX.ARPA>
+   R: 550 No such user here
+
+   S: RCPT TO:<Brown@BBN-UNIX.ARPA>
+   R: 250 OK
+
+   S: DATA
+   R: 354 Start mail input; end with <CRLF>.<CRLF>
+   S: Blah blah blah...
+   S: ...etc. etc. etc.
+   S: .
+   R: 250 OK
+
+   S: QUIT
+   R: 221 BBN-UNIX.ARPA Service closing transmission channel
+
+                         Scenario 1
+
+-------------------------------------------------------------
+
+
+
+
+
+Aborted SMTP Transaction Scenario
+
+-------------------------------------------------------------
+
+   R: 220 MIT-Multics.ARPA Simple Mail Transfer Service Ready
+   S: HELO ISI-VAXA.ARPA
+   R: 250 MIT-Multics.ARPA
+
+   S: MAIL FROM:<Smith@ISI-VAXA.ARPA>
+   R: 250 OK
+
+   S: RCPT TO:<Jones@MIT-Multics.ARPA>
+   R: 250 OK
+
+   S: RCPT TO:<Green@MIT-Multics.ARPA>
+   R: 550 No such user here
+
+   S: RSET
+   R: 250 OK
+
+   S: QUIT
+   R: 221 MIT-Multics.ARPA Service closing transmission channel
+
+                         Scenario 2
+
+-------------------------------------------------------------
+
+
+
+Relayed Mail Scenario
+
+-------------------------------------------------------------
+
+   Step 1  --  Source Host to Relay Host
+
+      R: 220 USC-ISIE.ARPA Simple Mail Transfer Service Ready
+      S: HELO MIT-AI.ARPA
+      R: 250 USC-ISIE.ARPA
+
+      S: MAIL FROM:<JQP@MIT-AI.ARPA>
+      R: 250 OK
+
+      S: RCPT TO:<@USC-ISIE.ARPA:Jones@BBN-VAX.ARPA>
+      R: 250 OK
+
+      S: DATA
+      R: 354 Start mail input; end with <CRLF>.<CRLF>
+      S: Date: 2 Nov 81 22:33:44
+      S: From: John Q. Public <JQP@MIT-AI.ARPA>
+      S: Subject:  The Next Meeting of the Board
+      S: To: Jones@BBN-Vax.ARPA
+      S:
+      S: Bill:
+      S: The next meeting of the board of directors will be
+      S: on Tuesday.
+      S:                                              John.
+      S: .
+      R: 250 OK
+
+      S: QUIT
+      R: 221 USC-ISIE.ARPA Service closing transmission channel
+
+
+   Step 2  --  Relay Host to Destination Host
+
+      R: 220 BBN-VAX.ARPA Simple Mail Transfer Service Ready
+      S: HELO USC-ISIE.ARPA
+      R: 250 BBN-VAX.ARPA
+
+      S: MAIL FROM:<@USC-ISIE.ARPA:JQP@MIT-AI.ARPA>
+      R: 250 OK
+
+      S: RCPT TO:<Jones@BBN-VAX.ARPA>
+      R: 250 OK
+
+      S: DATA
+      R: 354 Start mail input; end with <CRLF>.<CRLF>
+      S: Received: from MIT-AI.ARPA by USC-ISIE.ARPA ;
+         2 Nov 81 22:40:10 UT
+      S: Date: 2 Nov 81 22:33:44
+      S: From: John Q. Public <JQP@MIT-AI.ARPA>
+      S: Subject:  The Next Meeting of the Board
+      S: To: Jones@BBN-Vax.ARPA
+      S:
+      S: Bill:
+      S: The next meeting of the board of directors will be
+      S: on Tuesday.
+      S:                                              John.
+      S: .
+      R: 250 OK
+
+      S: QUIT
+      R: 221 USC-ISIE.ARPA Service closing transmission channel
+
+                         Scenario 3
+
+-------------------------------------------------------------
+
+
+
+
+Verifying and Sending Scenario
+
+-------------------------------------------------------------
+
+   R: 220 SU-SCORE.ARPA Simple Mail Transfer Service Ready
+   S: HELO MIT-MC.ARPA
+   R: 250 SU-SCORE.ARPA
+
+   S: VRFY Crispin
+   R: 250 Mark Crispin <Admin.MRC@SU-SCORE.ARPA>
+
+   S: SEND FROM:<EAK@MIT-MC.ARPA>
+   R: 250 OK
+
+   S: RCPT TO:<Admin.MRC@SU-SCORE.ARPA>
+   R: 250 OK
+
+   S: DATA
+   R: 354 Start mail input; end with <CRLF>.<CRLF>
+   S: Blah blah blah...
+   S: ...etc. etc. etc.
+   S: .
+   R: 250 OK
+
+   S: QUIT
+   R: 221 SU-SCORE.ARPA Service closing transmission channel
+
+                         Scenario 4
+
+-------------------------------------------------------------
+
+
+
+
+Mailing List Scenario
+
+First each of two mailing lists are expanded in separate sessions
+with different hosts.  Then the message is sent to everyone that
+appeared on either list (but no duplicates) via a relay host.
+
+-------------------------------------------------------------
+
+   Step 1  --  Expanding the First List
+
+      R: 220 MIT-AI.ARPA Simple Mail Transfer Service Ready
+      S: HELO SU-SCORE.ARPA
+      R: 250 MIT-AI.ARPA
+
+      S: EXPN Example-People
+      R: 250-<ABC@MIT-MC.ARPA>
+      R: 250-Fred Fonebone <Fonebone@USC-ISIQ.ARPA>
+      R: 250-Xenon Y. Zither <XYZ@MIT-AI.ARPA>
+      R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA>
+      R: 250-<joe@foo-unix.ARPA>
+      R: 250 <xyz@bar-unix.ARPA>
+
+      S: QUIT
+      R: 221 MIT-AI.ARPA Service closing transmission channel
+
+
+   Step 2  --  Expanding the Second List
+
+      R: 220 MIT-MC.ARPA Simple Mail Transfer Service Ready
+      S: HELO SU-SCORE.ARPA
+      R: 250 MIT-MC.ARPA
+
+      S: EXPN Interested-Parties
+      R: 250-Al Calico <ABC@MIT-MC.ARPA>
+      R: 250-<XYZ@MIT-AI.ARPA>
+      R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA>
+      R: 250-<fred@BBN-UNIX.ARPA>
+      R: 250 <xyz@bar-unix.ARPA>
+
+      S: QUIT
+      R: 221 MIT-MC.ARPA Service closing transmission channel
+
+
+   Step 3  --  Mailing to All via a Relay Host
+
+      R: 220 USC-ISIE.ARPA Simple Mail Transfer Service Ready
+      S: HELO SU-SCORE.ARPA
+      R: 250 USC-ISIE.ARPA
+
+      S: MAIL FROM:<Account.Person@SU-SCORE.ARPA>
+      R: 250 OK
+      S: RCPT TO:<@USC-ISIE.ARPA:ABC@MIT-MC.ARPA>
+      R: 250 OK
+      S: RCPT TO:<@USC-ISIE.ARPA:Fonebone@USC-ISIQA.ARPA>
+      R: 250 OK
+      S: RCPT TO:<@USC-ISIE.ARPA:XYZ@MIT-AI.ARPA>
+      R: 250 OK
+      S: RCPT
+          TO:<@USC-ISIE.ARPA,@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA>
+      R: 250 OK
+      S: RCPT TO:<@USC-ISIE.ARPA:joe@FOO-UNIX.ARPA>
+      R: 250 OK
+      S: RCPT TO:<@USC-ISIE.ARPA:xyz@BAR-UNIX.ARPA>
+      R: 250 OK
+      S: RCPT TO:<@USC-ISIE.ARPA:fred@BBN-UNIX.ARPA>
+      R: 250 OK
+
+      S: DATA
+      R: 354 Start mail input; end with <CRLF>.<CRLF>
+      S: Blah blah blah...
+      S: ...etc. etc. etc.
+      S: .
+      R: 250 OK
+
+      S: QUIT
+      R: 221 USC-ISIE.ARPA Service closing transmission channel
+
+                         Scenario 7
+
+-------------------------------------------------------------
+
+
+
+Too Many Recipients Scenario
+
+-------------------------------------------------------------
+
+   R: 220 BERKELEY.ARPA Simple Mail Transfer Service Ready
+   S: HELO USC-ISIF.ARPA
+   R: 250 BERKELEY.ARPA
+
+   S: MAIL FROM:<Postel@USC-ISIF.ARPA>
+   R: 250 OK
+
+   S: RCPT TO:<fabry@BERKELEY.ARPA>
+   R: 250 OK
+
+   S: RCPT TO:<eric@BERKELEY.ARPA>
+   R: 552 Recipient storage full, try again in another transaction
+
+   S: DATA
+   R: 354 Start mail input; end with <CRLF>.<CRLF>
+   S: Blah blah blah...
+   S: ...etc. etc. etc.
+   S: .
+   R: 250 OK
+
+   S: MAIL FROM:<Postel@USC-ISIF.ARPA>
+   R: 250 OK
+
+   S: RCPT TO:<eric@BERKELEY.ARPA>
+   R: 250 OK
+
+   S: DATA
+   R: 354 Start mail input; end with <CRLF>.<CRLF>
+   S: Blah blah blah...
+   S: ...etc. etc. etc.
+   S: .
+   R: 250 OK
+
+   S: QUIT
+   R: 221 BERKELEY.ARPA Service closing transmission channel
+
+                        Scenario 10
+
+-------------------------------------------------------------
+
+Note that a real implementation must handle many recipients as
+specified in Section ##4.5.3.
+
+
+
+APPENDIX G  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,
+e.g., envelope information from one system to the message headers or
+body of another have generally proven to be inadequate in important
+ways.  Systems translating between environments that do not support
+both envelopes and headers and Internet mail must be written with the
+understanding that some information loss is almost inevitable.
+
+
+
+APPENDIX I: Deprecated features of RFC 821
+
+A few features of RFC 821 have proven to be problematic and should
+not be used in Internet mail.  These are:
+
+(1) TURN
+
+This command, described in RFC 821, raises important security issues
+(described in RFC 1123).  Its use is deprecated; SMTP systems SHOULD
+NOT use it unless the server can authenticate the client. 
+
+(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.  
+
+(3) HELO
+
+As discussed in sections ##3.1 and ##4.1.1, EHLO is strongly
+preferred to HELO when the server will accept the former.  Servers
+must continue to accept and process HELO in order to support older
+clients.
+
+
+(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.
+
+(5) Dates and years
+
+When dates are inserted into messages by SMTP clients or servers
+(e.g., in trace fields), four-digit years MUST BE used.  Two-digit
+years are deprecated; three-digit years were never permitted in the
+Internet mail system.
+
+(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.
+
+
+
+APPENDIX X: Change summary and Loose ends (temporary)
+
+X.1 Change summary
+
+X.1.1 Substantive changes between draft-ietf-drums-smtpupd-00.txt and
+draft-ietf-drums-smtpupd-01.txt 
+
+(i) Slightly clarified the discussions of rejection and failure of
+VRFY requests and the associated response codes.
+
+(ii) Slightly clarified the discussion of deferred address
+validation. 
+
+(iii) Removed the IPCE terminology and modified the text in section
+##4.1.1.2 to explicitly introduce the "mail gateway" terminology and
+to begin to distinguish a mail gateway from a conventional relay.
+
+(iv) Explicitly noted that SMTP clients for things like POP and IMAP
+may send everything to a single relay for further processing, rather
+than resolving final domain names.
+
+(v) Tightened the RSET discussion.
+
+(vi) Deprecation of 251 only for RCPT (still ok for VRFY)
+
+
+
+X.1.2.  Substantive changes between draft-ietf-drums-smtpupd-01.txt
+and draft-ietf-drums-smtpupd-02.txt.
+
+Incorporated additional RFC 1123 material; reorganized several
+sections for clarity.  Added definitions and other previous "loose
+end" material.
+
+
+X.1.3.  Substantive changes between draft-ietf-drums-smtpupd-02.txt
+and draft-ietf-drums-smtpupd-03.txt.
+
+(i) Eliminated a number of placeholders and tightened some of the
+definitions in section 2.  Added a few new placeholders for
+consistency checking against other documents.
+
+(ii) Removed the state diagrams, per direction at IETF Montreal.
+
+(iii) Added new section 6.3, an attempt to summarize WG discussions
+on the "posting" versus "delivery" versus "relay" functions of SMTP
+and on whether "fixups" are appropriate in different cases.
+
+(iv) Inserted section 6.1, a minor rewrite of section 5.3.3 of
+RFC1123. 
+
+(v) Added new text to 3.5.5 to discuss the spammer - EXPN
+relationship. 
+
+(vi) The "ASCII requirement" in 4.1.1.4 has been tightened somewhat.
+
+(v) The remaining miscellaneous changes agreed to in Montreal have
+been incorporated except as noted below.
+
+
+X.1.4.  Substantive changes between draft-ietf-drums-smtpupd-03.txt
+and draft-ietf-drums-smtpupd-04.txt.
+
+Many small changes have been made between these two versions; the
+list that follows is not exhaustive.
+
+(i) To clarify some of the text, definitions have been introduced to
+distinguish among originating, delivery, relay, and gateway SMTP
+systems. 
+
+(ii) The role of LF-terminated lines has been clarified.
+
+(iii) Several changes have been made to clarify the principle
+that, no matter what originating and final delivery systems
+might do, relay systems are not permitted to tamper with message
+content, even to "fix" headers that are determined to be
+invalid.  If they deem message content to be seriously
+unacceptable, they are encouraged to reject the messages in
+preference to trying to fix them up, but, in general, the theme
+is "don't look/ don't tell".
+
+(iv) A few more definitions have been added to the terminology
+section, and the separate glossary has been eliminated.
+
+(v) I have taken a shot at text to address some of the controversies
+that have raged on the WG mailing list (e.g., sections 7.4 and 7.5).
+Since there was no consensus on most of those topics, I expect that
+the inserted text will satisfy no one except, perhaps, for agreement
+that saying nothing would have been worse.  As a mechanism for moving
+forward, the text in these controversial areas that now appears will
+be considered "base"; alterations will be made only if clear
+consensus emerges.
+
+(vi) Per discussion in Los Angeles, source routes have been further
+deprecated. 
+
+(vii) Some of the VRFY/EXPN materials have been moved to "security
+considerations", where they appear to belong, some text has been
+added, and the conformance statements adjusted to reflect what I
+perceive to be WG consensus.
+
+(viii) New MX resolution material has been added to section 5.  While
+most of this material is from RFC974, the rules have been further
+tightened to reflect current practice and experience (974 is written
+in a somewhat speculative fashion for a standard).  In particular,
+the behavior of trying the target host's A RR when MXs existed but
+all of them were eliminated is now prohibited, which seems necessary
+if another of other ideas being recommended or considered are to be
+feasible. 
+
+
+X.1.5.  Substantive changes between draft-ietf-drums-smtpupd-04.txt
+and draft-ietf-drums-smtpupd-05.txt.
+
+(i) All normative references to RFC 1123 have been removed from the
+main body of the text (some still appear in the appendices where they
+will remain).
+
+(ii) Section 3.5 has been renamed slightly to distinguish between
+"debuging of SMTP implementations" and "debugging of addresses".
+Better terminology would be welcome.
+
+(iii) Error conditions resulting from the DATA command have been
+clarified. 
+
+(iv) Section 4.2 (SMTP replies) has been revised and tightened to
+reflect reality and recent discussion on the list.
+
+(v) Appendix E has been revised a bit and moved into section 4.2.1.
+Given the importance of the "check only first digit" rule, it has to
+be there.
+
+(vi) Added new text for "no SMTP service supported" to sections
+3.1, 4.2.2, 4.2.3, and 4.3.2.  As noted in 3.1, I'd rather add 521
+(which would work perfectly with the model) rather than overloading
+554.  
+
+(vii) The Return-path language in section 4.4 has been cleaned up a
+bit. 
+
+(viii) Tightened the "postmaster" language in 4.5.1, requiring a
+small change to 4.1.1.3.
+
+(ix) I have unilaterally (with a little help from my friends),
+increased some of the size limits.  64 was much too short for a
+domain name, and the DNS limit of 255 (?) has now been inserted.
+That leaves the return path much too short, but I haven't fixed it
+(maybe that will cause us to get rid of them).  We still have a 64
+character limit on the local-part, which is also *much* too short.
+Votes for 128 or longer limits accepted.  See X.1.6(I)
+
+(x) The text on the "recipients buffer" has been rewritten so that (I
+hope) it makes sense and gives some explicit guidance for how clients
+and servers should proceed if limits are imposed.
+
+
+X.1.6.  Substantive changes between draft-ietf-drums-smtpupd-05.txt
+and draft-ietf-drums-smtpupd-06.txt.
+
+Most of the changes in this revision have been editorial rather than 
+substantive.  Major substantive changes include:
+
+(i)  The language about maximum sizes of SMTP command lines has been 
+reworked, per WG mailing list discussion.
+
+(ii)  Several instances of  "Should" have been promoted to "Must" when the 
+reasons for the weaker rule seemed to have disappeared.   In
+particular, the requirement that an SMTP implementation support
+timeouts has become a MUST.  Also, conformance to this specification
+requires support of EHLO.  Older systems should claim conformance to
+the [to-be-historical] 821, not this specification.
+
+
+
+X.2 Loose ends
+
+(i) The 822 BNF -> ABNF transition is not yet complete, and most of
+what has been done needs checking.
+
+(ii) Most examples are not yet revised, overview and grammar are
+still to be merged. 
+
+(iii) We have agreed that all of the definition of trace ("Received:")
+fields should be moved to this document from the message format one.
+That work is not yet complete, partially because I’m still waiting on 
+ABNF.  There are also several unanswered questions about exactly what
+should be said.
+
+(iv) The Appendices have not yet been numbered consecutively.  Note
+that Appendix X is temporary and is not expected to appear in any
+final publication.
+
+(v) See X.1.5(ix), above.
+
+See also Chris Newman's "Drums open issues" list.
diff --git a/Documentation/en/I-D/draft-ietf-drums-smtpupd-07.txt b/Documentation/en/I-D/draft-ietf-drums-smtpupd-07.txt
new file mode 100644
index 00000000..c3363caa
--- /dev/null
+++ b/Documentation/en/I-D/draft-ietf-drums-smtpupd-07.txt
@@ -0,0 +1,4053 @@
+
+
+INTERNET-DRAFT                                John C. Klensin, Editor
+Expires in six months                         Dawn P. Mann, Co-Editor
+                                                         May 20, 1998
+                                                        
+
+                  Simple Mail Transfer Protocol 
+
+                 draft-ietf-drums-smtpupd-07.txt
+
+
+Status of this Memo
+
+
+This document is an Internet-Draft.  Internet-Drafts are working
+documents of the Internet Engineering Task Force (IETF), its
+areas, and its working groups.  Note that other groups may also
+distribute working documents as Internet-Drafts.
+
+Internet-Drafts are draft documents valid for a maximum of six
+months and may be updated, replaced, or obsoleted by other
+documents at any time.  It is inappropriate to use Internet-
+Drafts as reference material or to cite them other than as
+"work in progress."
+
+To view the entire list of current Internet-Drafts, please check
+the "1id-abstracts.txt" listing contained in the Internet-Drafts
+Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
+(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
+(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
+(US West Coast).
+
+If consensus is reached on this document, it will be forwarded to the
+IESG with the recommendation that it be processed onto the Standards
+track. 
+
+[[Sections marked with doubled brackets (e.g., "<<") are explicit
+placeholders or known major loose ends.  The marking ## is a note in
+the draft to recheck a section number and should be ignored.]]
+
+[[As discussed in the WG, most of the syntax and examples have not
+been changed from 821 -- those changes are a last- step item, after
+the ABNF document completely stabilizes and differences with 822bis
+have been resolved.  Similarly, the numbers of appendices will be
+rationalized (and Appendix X removed) before the document is
+submitted to the IESG.  Please check appendix X.2 for additional
+problems of which the editor is already painfully aware before
+complaining about things that are missing.]]
+
+
+                           TABLE OF CONTENTS
+   0.  ABSTRACT
+
+   1.  INTRODUCTION
+
+   2.  THE SMTP MODEL
+
+      2.1 Basic structure
+      2.2 The extension model
+      2.3 Other terminology
+      2.4 Syntax Principles
+
+
+   3.  THE SMTP PROCEDURES: AN OVERVIEW
+      
+      3.1  Session initiation
+      3.2  Client initiation
+      3.3  Mail transactions
+      3.4  Forwarding for Address Correction or Updating
+      3.5  Commands for Debugging Addresses
+      3.6  Domains 
+      3.7  Relaying
+      3.8  Mail Gatewaying
+      3.9  Terminating sessions and connections
+      3.10  Mailing lists and Aliases
+
+
+   4.  THE SMTP SPECIFICATIONS
+
+      4.1.  SMTP Commands
+      4.1.1.  Command Semantics and Syntax
+      4.1.2.  Lower-level Syntax
+      4.1.3.  Address literals
+      4.1.4.  Order of commands
+      4.1.5.  Private-use commands
+      4.2.  SMTP Replies
+      4.2.1.  Reply Code Severities and Theory
+      4.2.2.  Reply Codes by Function Group
+      4.2.3.  Reply Codes in Numeric Order 
+      4.2.4.  Reply code 502
+      4.2.5  Reply codes after DATA and the subsequent CRLF.CRLF.
+      4.3.  Sequencing of Commands and Replies
+      4.4   Trace information
+      4.5.  Details
+      4.5.1.  Minimum Implementation
+      4.5.2.  Transparency
+      4.5.3.  Sizes and Timeouts
+      4.5.4   SMTP Queuing Strategies
+
+   5. Address resolution and mail handling
+
+   6. Problem detection and handling
+      6.1 Reliable delivery and replies by email
+      6.2 Loop detection
+      6.3 Compensating for irregularities
+
+   7. Security Considerations
+      7.1 Mail security and spoofing
+      7.2 "Blind" copies
+      7.3 VRFY, EXPN, and security
+      7.4 Information disclosure
+      7.5 Scope of operation of SMTP servers
+
+   8. IANA Considerations
+
+   9. References
+
+   10. Editor's addresses
+
+   11. Acknowledgments
+
+   APPENDIX A:  TCP
+   APPENDIX B:  Generating SMTP commands from RFC 822 headers
+   APPENDIX C:  Source routes
+   APPENDIX F:  Scenarios
+   APPENDIX G:  Other gateway issues.
+   APPENDIX I:  Deprecated features of RFC 821
+   APPENDIX X:  Change summary and Loose ends (temporary)
+
+
+
+
+
+0.  Abstract
+
+This document is a self-contained specification of the basic protocol
+for the Internet electronic mail transport, consolidating and
+updating 
+
+ * the original SMTP specification of RFC 821 [RFC-821],
+ * Domain name system requirements and implications for mail
+   transport from RFC 1035 [RFC-DNS] and RFC 974 [RFC974],
+ * the clarifications and applicability statements in 
+     RFC 1123 [RFC-1123], and
+ * material drawn from the SMTP Extension mechanisms [SMTPEXT].
+
+It replaces RFC 821, RFC 974, and the mail transport materials of RFC
+1123.  However, RFC 821 specifies some features that are not in
+significant use in the Internet of 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 the header-people list [HEADER-PEOPLE]
+and problems of unusual readings or interpretations that have turned
+up 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 posting" protocol, as recommended for POP [RFC-POP2,
+RFC-POP3] and IMAP [RFC-IMAP4].
+
+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 discusses message bodies and formats RFC 822,
+MIME, and their relationship - [MSGFMT].
+
+1.  INTRODUCTION
+
+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 describe some of them.  
+
+An important feature of SMTP is its capability to transport mail
+across transport service environments, usually referred to as "mail
+gatewaying" (see section 3.8).  A transport service environment might
+consist of the mutually-TCP-accessible hosts on the public Internet,
+a firewall-isolated private TCP/IP LAN, or a LAN or WAN environment
+utilizing an entirely different transport-level protocol.  It is
+important to realize that "transport systems" are one-to-one with
+usual definitions of "networks".  A process can communicate directly
+with another process, and transport mail using this protocol, through
+any mutually known transport layer.  Conversely, mail can be relayed
+(actually gatewayed) between hosts on different transport systems by
+a host on both transport systems.  The Mail eXchanger mechanisms of
+the domain name system [RFC-DNS, and section ##5 of this document]
+usually permit relaying and gatewaying to occur invisibly to the user.
+
+
+2.  THE SMTP MODEL
+
+2.1 Basic structure
+
+The SMTP design is based on the following model of communication: as
+the result of a user mail request (or transfer from a mail user agent
+(see section ##2.3)), the SMTP client establishes a two-way
+transmission channel to an SMTP server. A fully-capable SMTP client
+determines the address of an appropriate host running an SMTP server
+by resolving the domain name given in the SMTP request to either an
+intermediate mail exchanger host or a final target host. In other
+cases, common with clients associated with implementations of the POP
+[RFC-POP2, RFC-POP3] or IMAP [RFC-IMAP4] protocols, or when the
+client is inside an isolated transport service environment, the SMTP
+client may send all of its traffic to a single SMTP server which, in
+turn, relays the mail to final (or other intermediate) destinations.
+The relay and those destinations are expected to support all of the
+queuing, retrying, and alternate address functions discussed in this
+specification. 
+
+The SMTP server may be either the ultimate destination or an
+intermediate "relay" (i.e., may assume the role of an SMTP client
+after receiving the message).  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. 
+
+Once the transmission channel is established and initial handshaking
+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 headers 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 extension requests
+(e.g., [RFC-Pipeline]).
+
+Once a given mail message has been transmitted, the client may either
+request that the connection be shut down or may initiate other mail
+transactions. 
+
+     -------------------------------------------------------------
+
+   
+               +----------+                +----------+
+   +------+    |          |                |          |
+   | User |<-->|          |      SMTP      |          |
+   +------+    |  Sender- |Commands/Replies| Receiver-|
+   +------+    |   SMTP   |<-------------->|    SMTP  |    +------+
+   | File |<-->|          |    and Mail    |          |<-->| File |
+   |System|    |          |                |          |    |System|
+   +------+    +----------+                +----------+    +------+
+   
+
+                SMTP client                SMTP server
+
+                           Model for SMTP Use
+
+                                Figure 1
+
+     -------------------------------------------------------------
+
+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.  This transmission normally occurs 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.  An intermediate host that acts
+as either an SMTP relay or as a gateway into some other transmission
+environment may also be selected through the use of the domain name
+service (DNS) Mail eXchanger mechanism.
+
+To provide relay capability, the SMTP server is supplied with the
+name of the ultimate destination host as well as the destination
+mailbox name.  Usually, intermediate hosts are determined via the DNS
+MX record, not by explicit "source" routing (see Appendices ##C and
+##I).
+
+
+
+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 permitting the client and server to agree to
+utilize shared functionality beyond the original SMTP requirements.
+Contemporary SMTP implementations MUST support the basic extension
+mechanisms (see below for details), i.e., servers MUST support the
+EHLO command even if they do not implement any specific extensions
+and clients MUST 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 and 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 added, it must be done in a way that permits older
+implementations to continue working acceptably. 
+
+In an effort that started in 1990, approximately a decade after RFC
+821 was completed, the protocol was modified with a "service
+extensions" model permitting 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.
+
+The extension framework consists of:
+
+ (1)   The SMTP command EHLO, superseding the earlier HELO,
+
+ (2)   a registry of SMTP service extensions, 
+
+ (3)   additional parameters to the SMTP MAIL FROM and RCPT TO
+       commands, and
+
+ (4)   optional replacements for verbs defined in this protocol,
+       such as for DATA (e.g., see [RFC-BDAT]).
+
+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.
+
+Contemporary SMTP implementations MUST support the basic extension
+mechanism (see below for details), i.e., servers MUST support the
+EHLO command even if they do not implement any specific extensions
+and clients MUST preferentially utilize EHLO rather than HELO.
+
+
+
+
+
+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
+aformal standards-track or IESG-approved experimental protocol
+document.  The definition must include:
+
+ (1)   the textual name of the SMTP service extension;
+
+ (2)   the EHLO keyword value associated with the extension;
+
+ (3)   the syntax and possible values of parameters associated with
+       the EHLO keyword value; 
+
+ (4)   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);
+
+ (5)   any new parameters the extension associates with the
+       MAIL FROM or RCPT TO verbs;
+
+ (6)   a description of how support for the extension affects the 
+       behavior of a server and client SMTP; and,
+
+ (7)   the increment by which the extension is increasing the
+       maximum length of the commands MAIL FROM and/or RCPT TO, over
+	   that specified in RFC 821.
+
+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" may 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.3 Terminology
+
+Most of the terminology in this document is common in the Internet at
+the time of its writing.  However, the following terms and concepts
+are used in special ways here, or represent differences in
+terminology between RFC 821 and this document, and should be
+understood before reading further.  These definitions are normative,
+i.e., they contain specifications to which SMTP implementations are
+required to conform.
+
+2.3.1 Mail objects
+
+SMTP transports a mail object containing an envelope and content.
+
+ (1)   The SMTP envelope is straightforward, and is sent as a
+       series of SMTP protocol units (described in section ##3): it
+       consists of an originator address (to which error reports
+       should be directed); a delivery mode (e.g., deliver to
+       recipient mailboxes); one or more recipient addresses; and
+       optional protocol extension material.
+
+ (2)   The SMTP content is sent in the SMTP DATA protocol unit and
+       has two parts: the headers and the body. The headers form a
+	   collection of field/value pairs structured as described in
+	   [MSGFMT]; the body, if structured, is defined according to
+	   MIME [RFC-MIME]. The content is textual in nature, expressed
+	   using the US ASCII repertoire[1]. Although extensions (such as
+	   MIME) may relax this restriction for the content body, the
+	   content headers are always encoded using the US ASCII
+	   repertoire. The algorithm defined in [RFC-INTLHDR] is used to
+	   represent 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
+
+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).  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 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 "domain"); identifying them by numerical address is discouraged.
+
+2.3.5 domain
+
+The name of a host (often referred to as a "fully-qualified domain
+name" or "FQDN"), or some entry in the domain name hierarchy, usually
+referred to as a "subdomain", that may contain many hosts.  A domain,
+or domain name, may also refer to an alias (label of a CNAME RR) or
+name the label of Mail eXchanger records to be used to deliver mail.
+See [RFC-DNS] and section ##5.  
+
+The domain name, as described in this document and in [RFC-DNS], is
+the entire, fully-qualified name, and an apparent host name that is
+not in FQDN form is no more than a local alias.  Local aliases MUST
+NOT appear in any SMTP transaction.
+
+
+In other works, if ab.cd.ef is the fully-qualified name of a host (or 
+label for an MX record), then it is obviously a "domain".  However,
+"cd.ef" may be only a domain name; it is possible for it to not refer 
+to any host.
+
+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 which
+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 lines
+
+SMTP commands and, unless altered by a service extension, message
+data, are transmitted in "lines".  Lines consist of zero or more data
+characters terminated by the ASCII sequence "CR" followed immediately
+by "LF".  Conforming implementations MUST NOT recognize or generate
+any other character or character sequence as a line terminator. 
+
+2.3.8 Gateway, relay, originator, and delivery system
+
+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 hands it
+to a mail user agent or deposits it in a maildrop which 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.
+
+
+2.3.9 Message content and message body
+
+The terms "message content" and "mail data" are used interchangably
+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 message headers and the
+possibly-structured message body.  The MIME specification [RFC-MIME]
+provides the Standard mechanisms for structured message bodies See
+##2.3.1.
+
+2.3.10 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" and, consequently, the
+local-part is interpreted and assigned semantics only by the host
+specified in the domain part of the address.
+
+
+2.3.11. reply
+
+An SMTP reply is an acknowledgment (positive or negative) sent from
+receiver to sender via the transmission channel in response to a
+command.  The general form of a reply is a numeric completion code
+(indicating failure or success) followed by a text string.  The codes
+are for use by programs and the text is usually intended for human
+users.
+
+
+
+2.4 Syntax Principles
+
+
+2.4.1 General syntax and transaction model
+
+The mail commands and replies have a rigid syntax.  Replies also have
+a numeric code. Complete lists of commands and replies appear in
+Section ##4 "The SMTP Specification".
+
+Commands and replies are not case sensitive.  That is, a command or
+reply word MAY be upper case, lower case, or any mixture of upper and
+lower case.  Note that this is NOT true of mailbox user names.  For
+some hosts the user name is case sensitive (this practice impedes
+interoperability and is discouraged), therefore, SMTP implementations
+MUST take care to preserve the case of user names as they appear in
+mailbox arguments.  Domain names are not case sensitive.
+
+Commands and replies are composed of characters from the ASCII
+character set [1]. 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 seven bit
+transport only.  Originating SMTP clients 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 mislabelled and the data path cannot accept the actual content,
+this may result in ultimate delivery of a severely garbled message to
+the recipient.  Delivery SMTP systems MAY reject ("bounce") such
+messages rather than deliver them.  No sending SMTP system is
+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.
+
+Eight-bit message content transmission MAY be requested of the server
+by a client using extended SMTP facilities, notably the "8BITMIME"
+extension [8BITMIME].  8BITMIME SHOULD be supported by SMTP servers.
+However, it MUST not be construed as authorization to transmit
+unrestricted eight bit material.  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 and 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 [ABNF].
+Metalanguage terms used in running text are surrounded by pointed
+brackets (e.g., <CRLF>) for clarity.
+
+
+2.4.2 Command and reply syntax
+
+The commands consist of a command code followed by an argument field.
+Command codes are four alphabetic characters and are case insensitive.
+
+This also applies to any symbols representing parameter values, such
+as "TO" or "to" for the forward-path.  Command codes and the argument
+fields are separated by one or more spaces.  However, case is
+important in the local-part within the reverse-path and forward-path
+arguments.  In particular, in some hosts the user "smith" is
+different from the user "Smith".
+
+A few SMTP receiver systems, in violation of this specification (and
+RFC 821) require that a particular case be transmitted by clients.
+Implementations MAY wish to make provision to accommodate those
+systems.
+
+The argument field consists of a variable length character string
+ending 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.
+
+
+
+3.  THE SMTP PROCEDURES: AN OVERVIEW
+
+This section contains descriptions of the procedures used in SMTP:
+session initiation, the mail transaction, forwarding mail, verifying
+mailbox names and expanding mailing lists, and the opening and
+closing exchanges.  Comments on relaying, a note on mail domains, and
+a discussion of changing roles are included at the end of this
+section.  Several complete scenarios are presented in Appendix ##F.
+
+
+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 (see section ##7.4), 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
+[MSGFMT]). 
+
+The SMTP protocol allows a server to formally reject a transaction
+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.
+
+Once the server has sent the welcoming message and the client has
+received it, the client then 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, unable to support
+service extensions, MAY use HELO instead of EHLO.  Servers MUST NOT
+return the extended EHLO-style response to a HELO command.
+
+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").
+
+
+3.3.  Mail Transactions
+
+There are three steps to SMTP mail transactions.  The transaction
+starts with a MAIL command which gives the sender identification.  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 <SP> 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> contains
+   the source mailbox, 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).  See section ##4.2.1.  Normally,
+   failures produce 550 or 553 replies. 
+
+   Historically, the <reverse-path> can 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.
+
+      RCPT <SP> TO:<forward-path> [<SP> <rcpt-parameters>] <CRLF>
+
+   This command gives a forward-path (normally a mailbox and domain)
+   identifying one recipient.  If accepted, the SMTP server returns a
+   250 OK reply and stores the forward-path.  If the 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).  This step of the procedure can be repeated any number
+   of times.  The <forward-path> can contain more than just a
+   mailbox.  Historically, the <forward-path> can be 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 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 RCPT TO appears without a previous MAIL FROM, the server
+   MUST return a 503 "Bad sequence of commands" response. The
+   optional <mail-parameters> are associated with negotiated SMTP
+   service extensions (see section ##2.2). 
+
+   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 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 indicator 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 data.  If accepted, the SMTP server returns a 250 OK reply.
+   The DATA command can fail in only two ways:
+
+      o If there was no MAIL FROM, or no RCPT TO, command, or all
+    	such commands were rejected, the server MAY return a "command
+		out of sequence" (503) reply.   If that 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.
+
+      o 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), or if resources were
+        unavailable.  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.   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 RFC 822 format is being used, the mail data include the memo
+header items such as Date, Subject, To, Cc, From [MSGFMT].  Server
+SMTP systems SHOULD NOT reject messages based on perceived defects in
+the RFC 822 or MIME [RFC-MIME] message header or message body.  In
+particular, they MUST NOT reject messages in which the numbers of 
+Resent- 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-effectof
+the forwarding activity.  This may be especially important when the
+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) reply code from RCPT TO
+are deprecated: Servers SHOULD NOT provide that service or return
+that code.
+
+
+
+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 MUST support VRFY
+and SHOULD support EXPN (however, see section ##3.5.2 and ##7.3). 
+
+For the VRFY command, the string is a user name or a user name and
+domain (see below). The response MAY include the full name of the user
+and MUST include the mailbox of the user, e.g., it MUST be in either
+    User Name <mailbox@domain> 
+or
+    mailbox@domain 
+form.
+
+
+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, either of the following are legitimate
+response to VRFY:
+
+        553 User ambiguous
+   or
+        553- Ambiguous;  Possibilities are
+        553-Joe Smith <jsmith@somedomain>
+        553-Harry Smith <hsmith@somedomain>
+        553 Melvin Smith <dweep@somedomain>
+  or
+		553-Ambiguous;  Possibilities 
+		553- <jsmith@somedomain>
+		553- <hsmith@somedomain>
+		553 <dweep@somedomain>
+
+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 as described in [RFC-REPLY],
+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
+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
+of one mailbox.  If a request is made to verify a mailing list, a
+positive response can 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").  If a
+request is made to expand a user name, the server MAY return a
+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 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 "user@domain" form as a "user name";
+hosts MAY also choose to recognize other strings as "user names".
+
+
+
+The case of verifying a user name is straightforward as shown in
+example ##4.
+
+
+  -----------------------------------------------------------------
+  |
+  |           Example of Verifying a User Name
+  |
+  | Either
+  |
+  |   C: VRFY Smith
+  |   S: 250 Fred Smith <Smith@F.ISI.EDU>
+  |
+  | Or
+  |
+  |   C: VRFY Jones
+  |   S: 550 String does not match anything.
+  |
+  | Or
+  |
+  |   C: VRFY Jones
+  |   S: 551 User not local; please try <Jones@ ISIQ.ISI.EDU>
+  |
+  | Or
+  |
+  |   C: VRFY Gourzenkyinplatz
+  |   S: 553 User ambiguous.
+  |
+  | Or
+  |
+  |   C: VRFY fizzle
+  |   S: 252-Cannot VRFY fizzle, but will accept message and 
+  |   S: 252 attempt delivery
+  |
+  |                      Example 4
+  |
+  -----------------------------------------------------------------
+
+      The case of expanding a mailbox list requires a multiline reply
+	  as shown in example ##5.
+
+  -------------------------------------------------------------
+  |
+  |           Example of Expanding a Mailing List
+  |
+  |  Either
+  |
+  |     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>>
+  |     S: 250-Quincy Smith <Q-Smith@VAXA.EDU>
+  |     S: 250-<joe@totalitarian.org>
+  |     S: 250 <xyz@dominance.universal.int>
+  |
+  |  Or
+  |
+  |     C EXPN Executive-Washroom-List
+  |     S: 550 Access Denied to You.
+  |
+  |                        Example 5
+  |
+  -------------------------------------------------------------
+
+      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. 
+
+
+3.5.2  VRFY normal response.
+
+When normal (2yz or 551) responses are returned from a VRFY or EXPN
+request, the reply SHOULD normally include the mailbox name, e.g.,
+"<foo@bar>" (where "bar" is a fully qualified domain name) must
+appear in the syntax.  In exceptional circumstances, free-form text
+MAY be returned.  In order to facilitate parsing by both computers
+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 MUST support VRFY and SHOULD support 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.  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, they MUST,
+if supported, be listed in the response to EHLO if service extensions
+are supported.
+
+
+3.5.3 Meaning of VRFY or EXPN success response.
+
+A server MUST NOT return a 220 code in response to a VRFY or EXPN
+command unless it has actually verified the address.  In particular,
+a server MUST NOT return 220 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 of VRFY is required and EXPN is
+strongly recommended.  Hence, except as provided in section ##7.3,
+implementations that return 500 or 502 for VRFY are not in 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 discussed in
+section ##2.1 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.
+
+
+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--both for hosts (typically with MX and CNAME DNS
+records) and for mailboxes (various types of local host aliases)--has
+made it nearly impossible for these strategies to work, and mail
+systems SHOULD NOT attempt them.
+
+
+
+3.6.  Domains
+
+
+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 A RRs (as discussed in section ##5) are
+permitted, as are CNAME RRs whose targets can be resolved, in turn,
+to MX or A RRs.  Local nicknames or unqualified names MUST NOT be
+used.  There are two exceptions to this rule: (i) The domain name
+given in the EHLO command MUST BE either a primary host name (a
+domain name that resolves to an A RR) or, if the host has no name, an
+address literal as described in section ##4.1.1.1 and (ii) The
+reserved mailbox name "postmaster" may be used in a RCPT TO command
+without domain qualification (see section ##4.1.1.3).
+
+
+
+3.7.  RELAYING
+
+In general, the availability of Mail eXchanger records in the domain
+name system [RFC-DNS] makes the use of explicit source routes in the
+Internet mail system unnecessary.  Many historical problems with
+their interpretation 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.  They are also permitted
+to ignore the route information and simply send to the final
+destination specified as the last element in the route . 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 -- 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.
+
+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 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 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.  A MAIL command
+with a null reverse-path appears as follows:
+
+   MAIL FROM:<>
+
+An undeliverable mail notification message is shown in example 6.
+This notification is in response to a message originated by JOE at
+xyz.somecollege.edu and sent to a user on HOSTY.org 
+
+      -------------------------------------------------------------
+      |
+      |     Example Undeliverable Mail Notification Message
+      |
+      |  C: MAIL FROM:<>
+      |  S: 250 ok
+      |  C: RCPT TO:< JOE@xyz.somecollege.edu>
+      |  S: 250 ok
+      |  C: DATA
+      |  S: 354 send the mail data, end with .
+      |  C: Date: 23 Oct 81 11:22:33
+      |  C: From: SMTP@HOSTY.org
+      |  C: To: JOE@xyz.somecollege.edu
+      |  C: Subject: Mail System Problem
+      |  C:
+<<replace with NOTARY format >>
+      |  C: .
+      |  S: 250 ok
+      |
+      |                        Example 6
+      |
+
+As discussed in section ##2.4.1, a relay SMTP has no need to inspect
+or act upon the headers or body of the message data and MUST NOT do
+so.
+
+
+
+
+3.8  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.8, 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, i.e., 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.8.1  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 ##2.4.1 
+
+Other mail systems gatewayed to the Internet often use a subset of
+RFC-822 headers 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.  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.
+
+
+3.8.2 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. 
+
+Received: 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
+fields arising in non-SMTP environments, receiving systems MUST NOT
+reject mail based on the format of a trace field and SHOULD be
+extremely robust in the light of unexpected information or formats in
+those fields.
+
+The gateway SHOULD indicate the environment and protocol in the "via"
+clauses of Received field(s) that it supplies.
+
+
+3.8.3 From the Internet side, the gateway SHOULD accept all valid
+address formats in SMTP commands and in RFC-822 headers, and all
+valid RFC-822 messages.  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.8.4 The gateway MUST ensure that all header fields of a message
+that it forwards into the Internet meet the requirements for Internet
+mail.  In particular, all addresses in "From:", "To:", "Cc:", etc.,
+fields MUSTbe transformed (if necessary) to satisfy RFC-822 syntax,
+MUST reference only fully-qualified domain names, and MUSTbe
+effective and useful for sending replies.  3.8.5 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 return path from the
+SMTP envelope, not to the sender listed in the "From:" field (or
+other fields) of the RFC-822 message. 
+
+3.8.6 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.9.  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 except: 
+
+   o After receiving a QUIT command and responding with a 221 reply. 
+
+   o After detecting the need to shutdown the SMTP service and
+     returning a message with a 451 response code.  This response
+	 code can be issued after the server receives any command or, if
+	 necessary, asynchronously from command receipt (on the
+	 assumption that the client will receive it after the next
+	 command is issued).
+
+In particular, a server that closes connections in response to
+commands 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 which is forcibly shut down via external means SHOULD
+attempt to send a line containing 451 response code to the SMTP
+client before exiting.  The SMTP client will normally read the 451
+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.

+
+
+
+
+
+
+
+3.10  Mailing Lists and Aliases
+
+An SMTP-capable host SHOULD support both the alias and the list form
+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 but
+the message header MUST be left unchanged; in particular, the "From"
+field of the message is unaffected.
+
+An important mail facility is a mechanism for multi-destination
+delivery of a single message, by transforming or "expanding" 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.  We classify such a pseudo-mailbox as an "alias"
+or a "list", depending upon the expansion rules.
+
+
+3.10.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.10.11 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 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.
+
+
+
+
+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 command codes themselves are alphabetic
+characters terminated by <SP> if parameters follow and <CRLF>
+otherwise.  (In the interest of improved interoperability, SMTP
+receivers are encouraged to tolerate trailing white space before the
+terminating <CRLF>.)  The syntax of the local part of a mailbox must
+conform to receiver site conventions and the syntax specified in
+section ##4.1.2.  The SMTP commands are discussed below.  The SMTP
+replies are discussed in Section ##4.2.
+
+A mail transaction involves several data objects which 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 which 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.
+
+
+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 field 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
+available), the client should send an address literal (see section
+##4.1.3), optionally followed by information that will help to
+identify the client system.
+
+The SMTP server identifies itself to the SMTP client in the
+connection greeting reply and in the response to this command.
+
+A client SMTP SHOULD start an SMTP session by issuing the EHLO
+command. If the SMTP server supports the SMTP service extensions it
+will give a successful response, a failure response, or an error
+response. If the SMTP server, in violation of this specification,
+does not support any SMTP service extensions it will generate an
+error response.  Older client SMTP systems MAY, as discussed above,
+use HELO (as specified in RFC 821) instead of EHLO, and servers MUST
+support the HELO command and reply properly to it.  In any event, a
+client MUST issue HELO or EHLO before starting a mail transaction.
+
+These commands, and a "250 OK" reply to one of them, confirm that
+both the SMTP client and the SMTP server are in the initial state,
+that is, there is no transaction in progress and all state tables and
+buffers are cleared.
+
+Normally, the response to EHLO will be a multiline reply.  Each line
+of the response contains a keyword and, optionally, one or more
+parameters.  The syntax for a positive response, using the ABNF
+notation and low-level terminals of [ABNF], is:
+
+     ehlo-ok-rsp  ::=      "250"    domain [ SP greeting ] CRLF
+                    / (    "250-"   domain [ SP greeting ] CRLF
+                        *( "250-"      ehlo-line           CRLF )
+                           "250"    SP ehlo-line           CRLF   )
+
+     greeting     ::= 1*<any character other than CR or LF>
+
+     ehlo-line    ::= ehlo-keyword *( SP ehlo-param )
+
+     ehlo-keyword ::= (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
+
+                  ; syntax and values depend on ehlo-keyword
+     ehlo-param   ::= 1*<any CHAR excluding SP and all
+                         control characters (US ASCII 0-31
+                         inclusive)>
+
+[[xxx     ALPHA        ::= <any one of the 52 alphabetic characters
+                       (A through Z in upper case, and,
+                        a through z in lower case)>
+
+
+Although EHLO keywords may be specified in upper, lower, or mixed
+case, they must always be recognized and processed in a
+case-insensitive manner. This is simply an extension of practices
+specified in RFC 821 and section ##2.4.1.
+
+
+4.1.1.2 MAIL (MAIL)
+
+This command is used to initiate a mail transaction in which the mail
+data is delivered to one or more mailboxes.  The argument field
+contains a reverse-path.
+
+The reverse-path consists of the sender mailbox or a list of hosts as
+described in Appendix C.  In some types of reporting messages for
+which a reply is likely to cause a mail loop (for example, mail
+delivery and nondelivery notifications), the reverse-path may be null
+(see section ##3.7).
+
+This command clears the reverse-path buffer, the forward-path buffer,
+and the mail data buffer; and inserts the reverse-path information
+from this command into the reverse-path buffer.
+
+If service extensions were negotiated, the MAIL command may also
+carry parameters associated with a particular service extension. 
+
+Syntax: "MAIL FROM:" Reverse-path  [ SP Mail-parameters ]
+                             or
+        "MAIL FROM:<>" [ SP Mail-parameters ]
+
+
+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 use of this
+command.
+
+The forward-path normally consists of the required destination
+mailbox(es).  Sending systems SHOULD not generate the optimal list of
+hosts known as a source route.  Receiving systems MUST recognize
+source route syntax but SHOULD strip off the source route
+specification and utilize the domain name associated with the mailbox
+as if the source route had not been provided.
+
+Similarly, relay hosts SHOULD strip or ignore source routes, and
+names MUST NOT be copied into the reverse-path. When mail reaches its
+ultimate destination (the forward-path contains only a destination
+mailbox), the SMTP server inserts it into the destination mailbox in
+accordance with its host mail conventions.
+
+
+For example, mail received at relay host A with envelope commands
+
+      MAIL FROM:<USERX@Y.foo.org>
+      RCPT TO:<@HOSTA.INT,@HOSTB.INT: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, HostA MAY also choose to relay the message
+to HostB, using the envelope commands
+
+      MAIL FROM:<USERX@HOSTY.ARPA>
+      RCPT TO:<@HOSTB.int:USERC@D. BAR.ORG>
+
+Of course, since hosts are not required to relay mail at all, HostA
+may also reject the message entirely when the RCPT TO command is
+received, using a 550 code (since this is a "policy reason").
+
+If service extensions were negotiated, the RCPT TO command may also
+carry parameters associated with a particular service extension
+offered by the server.  The client MUST NOT transmit parameters other
+than those associated with a service extension offered by the server
+in its EHLO response.
+
+Syntax: "RCPT TO:" Forward-path  [ SP Rcpt-parameters ]
+                     or
+        "RCPT TO:<Postmaster>" [ SP Rcpt-parameters ]
+
+
+4.1.1.4 DATA (DATA)
+
+The receiver treats the lines (strings ending in CRLF sequences, see
+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 is terminated by a line containing only a period, that
+is, the character sequence "<CRLF>.<CRLF>" (see Section ##4.5.2 on
+Transparency).  This is the end of mail data indication.  Note that
+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
+data, ends the DATA command itself.  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 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.  Errors that are diagnosed
+subsequently MUST be reported in a mail message, as discussed in
+section ##4.4 In sending a positive completion reply to the end of
+data indication, the receiver takes full responsibility for the
+message (see section ##6.1).
+
+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.
+
+
+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 if issued immediately after EHLO,
+before EHLO is issued in the session, or immediately before a QUIT.
+In other situations, it restores the state to that immediately after
+the most recent EHLO.  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, below).
+
+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
+
+
+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" SP String
+
+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 multiline reply is
+returned containing information as described in section ##3.5.
+
+This command has no effect on the reverse-path buffer, the
+forward-path buffer, or the mail data buffer.
+
+Syntax: "EXPN" SP String
+
+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.
+
+SMTP servers SHOULD support HELP without arguments and MAY support it
+with arguments.
+
+Syntax: "HELP" [ SP String ]
+
+
+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
+an OK reply.
+
+This command has no effect on the reverse-path buffer, the
+forward-path buffer, or the mail data buffer.
+
+Syntax: "NOOP" [SP String]
+
+4.1.1.10 QUIT (QUIT)
+
+This command specifies that the receiver must send an 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 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).
+
+Syntax:  "QUIT"
+
+
+4.1.2.  LOWER-LEVEL SYNTAX
+
+The syntax of the argument fields of the above commands (using the
+syntax specified in [ABNF] 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, i.e., ALPHA, DIGIT, SP, CR, LF, CRLF, are as defined in the
+"core" syntax (section 6) of [ABNF].
+
+<<Note in draft: it appears stupid, contrary to the reason RFC 2234
+<<was created, and risk-prone to reproduce the definitions of
+<<Quoted-string and Atom here.  But, if I leave them out, the reader of
+<<this document will need a lap or virtual desktop large enough to
+<<simultaneously accomodate this spec, [msgfmt], and RFC 2234
+<<([ABNF]).  Similarly, it would be nice to use the same definition of
+<< <special> and <FWS> here as in 822bis, but the traditional 821
+<< definition of <special> excludes *all* control characters.
+<<Please advise >>
+
+   Reverse-path = Path
+
+   Forward-path = Path
+
+   Path = "<" [ A-d-l ":" ] Mailbox ">"
+
+   A-d-l = At-domain *( "," A-d-l )    ; Note that this form, the
+                                 so-called "source route", MUST BE
+								 accepted, SHOULD NOT be generated,
+								 and SHOULD be ignored.
+
+   At-domain = "@" Domain
+
+   Mail-parameters = *( SP Keyword "=" Argument )
+
+   Rcpt-parameters =  *( SP Keyword "=" Argument )
+
+   Keyword  = Ldh-str
+   Argument = Atom
+
+   Domain = sub-domain 1*("." sub-domain) / address-literal
+
+   sub-domain = let-dig *(ldh-str)
+   address-literal = "[" IPv4-address-literal / 
+                  IPv6-address-literal / General-address-literal "]"
+   IPv4-address-literal = snum 3*3("." snum)
+   IPv6-address-literal = "IPv6" SP IPv6-addr-string
+   IPv6-addr-string = String         ; IPv6 address in standard form
+                                       [IPv6AddrSpec].  Since this
+									   form uses colon characters,
+									   the String will actually need
+									   to be quoted in all cases.
+   General-address-literal = Standardized-tag SP String
+   Standardized-tag = Ldh-str        ; Specified in a
+                                       standards-track RFC 
+                                       and registered with IANA
+   snum = 1*3Digit                   ; representing a decimal integer
+                                       value in the range 0 through 255 
+   let-dig = Alpha / Digit
+   ldh-str = *( Alpha / Digit / "-" ) let-dig
+
+   Mailbox = Local-part "@" Domain
+
+   Local-part = Dot-string / 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
+of non-ASCII characters (octets with the high order bit set to one)
+or ASCII "control characters" (decimal value 0-31 and 127).  These
+characters MUST NOT be used in MAIL FROM or RCPT TO commands or other
+commands that require mailbox names.
+
+
+   String = Atom / Quoted-string
+
+   special = <<Msg-fmt-special>> /     [[placeholder, see above]]
+             the control characters (ASCII codes 0 through 31
+			 inclusive and 127)
+
+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 field with the comma being the fourth
+character of the field.
+
+Characters outside the set of alphas, digits, and hyphen MUST NOT
+appear in domain names.  In particular, the underscore character is
+not permitted.
+
+            
+
+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 or more small decimal integers
+separated by dots and enclosed by brackets, e.g., [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 space, and the address itself, in a
+format specified as part of the IPv6 standards [IPv6AddrString].
+
+
+
+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, 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,
+or 502 failure replies MUST be returned as appropriate.  The 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 ensure that the domain parameter to the EHLO
+command is a valid principal host name (not a CNAME or MX name) for
+its host.  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
+and supplemental information provided that will assist in identifying
+the client.
+
+An SMTP server MAY verify that the domain name parameter in the EHLO
+command actually corresponds to the IP address of the client.
+However, the server MUST NOT refuse to accept a message if the
+verification fails -- the information about verification failure is
+for logging and tracing only.
+
+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 (i.e., 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. 
+
+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 commands, one or more RCPT commands, and a
+DATA command, in that order.  A mail transaction may be aborted by
+the RSET (or a new EHLO) command.  There may be zero or more
+transactions in a session.
+
+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
+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 cannot be used at any other time in a session, but SHOULD be
+used by the client SMTP to request connection closure, even when no
+session opening command was sent and accepted. 
+
+
+
+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) SMTPs.  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, above. 
+
+
+
+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 on Sequencing.
+
+An SMTP reply consists of a three digit number (transmitted as three
+alphanumeric characters) followed by some text.  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 insection
+##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 insection ##4.2.1).  Only the EXPN and HELP
+commands are expected to result in multiline replies in normal
+circumstances, however, multiline replies are allowed for any command.
+
+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.
+
+A client SMTP MUST determine its actions only by the reply code, not
+by the text (except for 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), MUSTbe acceptable.
+The space (blank) following the reply code is considered part of the
+text.  Whenever possible, a sender-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.
+
+
+
+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 five values for the first digit of the reply code:
+
+  1yz   Positive Preliminary reply
+
+     The command has been accepted, but the requested action
+     is being held in abeyance, pending confirmation of the
+     information in this reply.  The SMTP client should send
+     another command specifying whether to continue or abort
+     the action.
+
+        [Note: unextended SMTP does not have any commands that allow
+		this type of reply, and so does not have continue or abort
+		commands.] 
+
+  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- SMTPs) must agree on the interpretation.
+	 Each reply in this category might have a different time value,
+	 but the SMTP client is encouraged to 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
+	 repeated without any change in command form or in properties of
+	 the sender or receiver.  (E.g., 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 is discouraged from repeating 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 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). 
+
+The second digit encodes responses in specific categories:
+
+  x0z   Syntax -- These replies refer to syntax errors,
+        syntactically correct commands that don't fit any
+        functional category, and unimplemented or superfluous
+        commands.
+
+  x1z   Information --  These are replies to requests for
+        information, such as status or help.
+
+  x2z   Connections -- These are replies referring to the
+        transmission channel.
+
+  x3z   Unspecified as yet.
+
+  x4z   Unspecified as yet.
+
+  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.
+
+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:
+                      123-First line
+                      123-Second line
+                      123-234 text beginning with numbers
+                      123 The last line
+
+In many cases the SMTP client then simply needs to search for the
+reply code followed by <SP> at the beginning of a line, and ignore
+all preceding lines.  In a few cases, there is important data for the
+sender in the reply "text".  The sender 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.3)
+   503 Bad sequence of commands
+   504 Command parameter not implemented
+
+   211 System status, or system help reply
+   214 Help message
+      [Information on how to use the receiver or the meaning of a
+      particular non-standard command; this reply is useful only
+      to the human user]
+
+   220 <domain> Service ready
+   221 <domain> Service closing transmission channel
+   421 <domain> Service not available,
+       closing transmission channel
+      [This may be a reply to any command if the service knows it
+      must shut down]
+
+   250 Requested mail action okay, completed
+   251 User not local; will forward to <forward-path>
+      [See section ##3.4]
+   252 Cannot VRFY user, but will accept message and attempt 
+       delivery
+      [See section ##3.5.3]
+   450 Requested mail action not taken: mailbox unavailable
+      [E.g., mailbox busy]
+   550 Requested action not taken: mailbox unavailable
+      [E.g., mailbox not found, no access, or command rejected
+      for policy reasons]
+   451 Requested action aborted: error in processing
+   551 User not local; please try <forward-path>
+      [See section ##3.4]
+   452 Requested action not taken: insufficient system storage
+   552 Requested mail action aborted: exceeded storage allocation
+   553 Requested action not taken: mailbox name not allowed
+      [E.g., mailbox syntax incorrect]
+   354 Start mail input; end with <CRLF>.<CRLF>
+   554 Transaction failed [Or, in the case of a connection-opening
+       response, "No SMTP service here"]
+
+
+4.2.3.  NUMERIC ORDER LIST OF REPLY CODES
+
+   211 System status, or system help reply
+   214 Help message
+      [Information on how to use the receiver or the meaning of a
+      particular non-standard command; this reply is useful only
+      to the human user]
+   220 <domain> Service ready
+   221 <domain> Service closing transmission channel
+   250 Requested mail action okay, completed
+   251 User not local; will forward to <forward-path>
+      [See section ##3.4]
+   252 Cannot VRFY user, but will accept message and attempt 
+      delivery
+      [See section ##3.5.3]
+
+   354 Start mail input; end with <CRLF>.<CRLF>
+
+   421 <domain> Service not available,
+       closing transmission channel
+      [This may be a reply to any command if the service knows it
+      must shut down]
+   450 Requested mail action not taken: mailbox unavailable
+      [E.g., mailbox busy]
+   451 Requested action aborted: local error in processing
+   452 Requested action not taken: insufficient system storage
+
+   500 Syntax error, command unrecognized
+      [This may include errors such as command line too long]
+   501 Syntax error in parameters or arguments
+   502 Command not implemented
+   503 Bad sequence of commands
+   504 Command parameter not implemented
+   550 Requested action not taken: mailbox unavailable
+      [E.g., mailbox not found, no access, or command rejected
+      for policy reasons]
+   551 User not local; please try <forward-path>
+      [See section ##3.4]
+   552 Requested mail action aborted: exceeded storage allocation
+   553 Requested action not taken: mailbox name not allowed
+      [E.g., mailbox syntax incorrect]
+   554 Transaction failed  [Or, in the case of a connection-opening
+       response, "No SMTP service here"]
+         
+
+4.2.4.  Reply code 502
+
+Questions have 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.2.6.
+
+ 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 FROM command). 
+
+
+When an SMTP server returns a transient error completion status (4yz)
+code after the DATA command is completed with <CRLF>.<CRLF>, it MUST
+NOT make any further attempt to deliver that message.  The SMTP
+client retains responsibility for 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).  The sending user should be able to
+interpret the return of a transient or permanent failure status as a
+non-delivery indication.
+
+
+
+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 (i.e., 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 ##4.1.3 for a discussion of alternatives in
+these situations.
+
+      For example,
+
+         220 ISIF.USC.EDU Service ready
+      or
+         220 LOSER.BOGUS.COM Trashmail 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
+substitute text in the replies, but the meaning and action implied by
+the code numbers and by the specific command reply sequence cannot be
+altered.
+
+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.  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.
+
+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 "commmand not
+		 recognized" error in response to the required subset of
+		 these commands is a violation of this specification.
+    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, NOOP, RSET)
+		 SHOULD return a 501 message if arguments are supplied in the
+		 absence of EHLO-advertised extensions.
+    421  Service shutting down and closing transmission channel
+
+
+Specific sequences are:
+
+      CONNECTION ESTABLISHMENT
+         S: 220
+         E: 554
+      EHLO             (or HELO)
+         S: 250
+         E: 504, 550
+      MAIL
+         S: 250
+         E: 552, 451, 452, 550, 553
+      RCPT
+         S: 250, 251 (but see section ##3.4 for discussion of 251)
+         E: 550, 551, 552, 553, 450, 451, 452, 503, 550
+      DATA
+         I: 354 -> data -> S: 250
+                           E: 552, 554, 451, 452
+         E: 451, 554, 503
+      RSET
+         S: 250
+      VRFY
+         S: 250, 251, 252
+         E: 550, 551, 553, 502, 504
+      EXPN
+         S: 250, 252
+         E: 550, 500, 502, 504
+      HELP
+         S: 211, 214
+         E: 502, 504
+      NOOP
+         S: 250
+      QUIT
+         S: 221
+
+
+
+4.4 Trace information
+
+When an SMTP server receives a message for delivery or further
+processing, it MUST insert trace ("time stamp" or "Received")
+information at the beginning of the message content, as discussed
+under the DATA command in section ##4.1.1.4.
+
+This line must be structured as follows:
+
+   *    The FROM field, which MUST be supplied in an SMTP
+        environment, SHOULD contain both (1) the name of the source
+		host as presented in the EHLO command and (2) an address
+		literal containing the IP address of the source, determined
+		from the TCP connection. 
+
+   *    The ID field MAY contain an "@" as suggested in RFC-822,
+        but this is not required.
+
+   *    The FOR field MAY contain a list of <path> entries when
+        multiple RCPT commands have been given.  This may raise 
+        some security issues and is usually not desirable; see
+		section ##7.2.
+
+An Internet mail program MUST NOT change a Received: line that was
+previously added to the message header.  SMTP servers MUST prepend
+Received lines to messages; they MUST NOT change the order of
+existing lines or insert Received lines in any other location. 
+
+As the Internet grows, comparability of Received fields is important
+for detecting problems, especially slow relays.  SMTP servers that
+create Received fields SHOULD use explicit offsets in the dates
+(e.g., -0800), rather than time zone names of any type.  Local time
+(with an offset) is preferred to UT when feasible.  If a time zone
+name is used, 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 world.  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 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 mail data headers and body [RFC822]. 
+
+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 FROM 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.  SMTP servers performing a
+relay function MUST NOT inspect the message data, and especially not
+to the extent needed to determine if Return-path headers are present.
+SMTP servers making final delivery MAY remove Return-path headers
+before adding their own. 
+
+The primary purpose of the Return-path is to designate the address to
+which messages indicating non-delivery or other mail system failures
+are to be sent.  For this to be unambigious, 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.
+
+   Historical note: Text in RFC 822 that appears to contradict the
+   use of Return-path (or the envelope MAIL FROM address) as the
+   destination for error messages is not applicable on the Internet.
+   The MAIL FROM address (as copied into the Return-path) MUST be
+   used as the target of any mail containing delivery error messages.
+
+In particular,
+
+(i) a gateway from SMTP->elsewhere SHOULD insert a return-path
+header, unless it is known that the "elsewhere" transport also uses
+Internet domain addresses and maintains the envelope sender address
+separately.
+
+(ii)  a gateway from elsewhere->SMTP SHOULD delete any
+return-path header present in the message, and either copy
+that information to the SMTP envelope or combine it with
+information present in the envelope of the other transport
+system to construct the MAIL FROM part of 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 is
+preferred when possible.  All undeliverable mail notification
+messages are sent using the MAIL command (even if they result from
+processing the obsolete SEND, SOML, or SAML commands) and use a null
+return path as discussed in section ##3.7.
+
+The time stamp line and the return path line are formally defined as
+follows:
+ 
+Return-path-line = "Return-Path:" FWS Reverse-path CRLF
+
+Time-stamp-line = "Received:" FWS Stamp CRLF
+
+Stamp = From-domain By-domain Opt-info ";"
+          Daytime
+
+From-domain = "FROM" FWS Extended-Domain FWS 
+
+By-domain = "BY" FWS Extended-Domain FWS
+
+Extended-Domain = Domain / 
+           ( Domain FWS "(" Address-literal ")" ) /
+           Address-literal
+
+Opt-info = [Via] [With] [ID] [For]
+
+Via = "VIA" FWS Link FWS 
+
+With = "WITH" FWS Protocol FWS 
+
+ID = "ID" FWS String FWS 
+
+For = "FOR" FWS Path FWS 
+
+Link = <<>> / Addtl-Link
+Addtl-Link = Atom       ; Additional standard names for links are
+						  registered with the Internet Assigned
+						  Numbers Authority (IANA).
+						  SMTP servers SHOULD NOT use unregistered
+						  names. 
+Protocol = "ESMTP" / "SMTP" / Attdl-Protocol
+Attdl-Protocol = Atom    ; Additional standard names for protocols
+                           are registered with the Internet Assigned
+						   Numbers Authority (IANA).  SMTP servers
+						   SHOULD NOT use unregistered names.
+
+Daytime =  FWS Date FWS Time
+
+Date = DD FWS Mon FWS YYYY
+
+       Note that the earlier form, which permits two-digit years, has
+       been deprecated.  SMTP systems MUST use four-digit years.
+
+Time = HH ":" MM ":" SS  FWS  Zone
+
+DD = 1*2Digit           ; the one or two decimal integer day of the
+					      month in the range 1 to 31.
+
+Mon = "JAN" | "FEB" | "MAR" | "APR" | "MAY" | "JUN" |
+             "JUL" | "AUG" | "SEP" | "OCT" | "NOV" | "DEC"
+
+YYYY = 4*4Digit         ; the four decimal integer year in the range
+                          0000 to 9999. 
+
+HH = 2*2Digit           ; the two decimal integer hour of the day in
+                          the range 00 to 24.
+
+MM = 2*2Digit            ; the two decimal integer minute of the hour
+                           in the range 00 to 59.
+
+SS = 2*2Digit ["." 1*Digit]
+                         ; the two decimal integer second of the
+						   minute in the range 00 to 59, with
+						   optional fractional seconds.
+
+Zone = ( "+" / "-" ) 4*4Digit [ SP "(" String ")" ]
+                         ; A four digit, signed time zone offset,
+						   such as -0600 for US Eastern Standard
+						   Time.  This may be supplemented by a time
+						   zone name in parentheses, e.g., "-0800
+						   (PDT)".  See  ##___ for additional
+						   discussion. 
+
+          Note that there is no default; time zone information
+          is required and MUST be supplied.
+
+
+
+
+		                       
+4.5.  DETAILS
+
+4.5.1.  MINIMUM IMPLEMENTATION
+
+In order to make SMTP workable, the following minimum
+implementation is required for all receivers:
+
+   COMMANDS -- HELO
+               VRFY
+               MAIL
+               RCPT
+               DATA
+               RSET
+               NOOP
+               QUIT
+
+Any system that includes an SMTP server supporting mail relaying
+or delivery, i.e., the RCPT command, 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 TO
+commands which 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.
+
+EHLO SHOULD be supported if possible.
+
+
+
+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.
+
+   1. 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.
+
+   2. 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
+format effectors and other control characters.  If the transmission
+channel provides an 8-bit byte (octets) data stream, the 7-bit ASCII
+codes are transmitted right justified in the octets, with the high
+order bits cleared to zero.  See ##3.7 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 or
+store data in records rather than strings.  If such transformationss
+are necessary, they must be reversible -- especially if such
+transformationss are applied to mail being relayed.
+
+
+4.5.3.  SIZES AND TIMEOUTS
+
+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, e.g., encoded
+X.400 addresses [RFC-X400] 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 WHICH IMPOSE NO LIMITS ON THE LENGTH *
+*  OF THESE OBJECTS SHOULD BE USED.                *
+*                                                  *
+****************************************************
+
+local-part
+
+   The maximum total length of a user name or other local-part
+
+is 64 characters.
+
+domain
+
+   The maximum total length of a domain name or number is 255
+   characters.
+
+path
+
+   The maximum total length of a reverse-path or
+   forward-path is 256 characters (including the punctuation
+   and element separators).
+
+command line
+
+   The maximum total length of a command line including the
+   command word and the <CRLF> is 512 characters.  SMTP extensions
+   may be used to increase this limit.
+
+reply line
+
+   The maximum total length of a reply line including the reply code
+   and the <CRLF> is 512 characters.  More information may be
+   conveyed through multiple-line replies. 
+
+
+text line
+
+   The maximum total length of a text line including the <CRLF> is
+   1000 characters (not counting the leading dot duplicated for
+   transparency).  This number may be increased by the use of SMTP
+   Service Extensions. 
+
+message content
+
+   The maximum total length of a message content (including any
+   message headers as well as the message body) MUST BE at least 64K 
+   octets. Since the introduction of multimedia mail [RFC-MIME],
+   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 ([RFC-SIZE]), and SMTP client systems
+   that will send large messages SHOULD utilize it when possible.
+
+recipients buffer
+
+   The minimum total number of recipients that must be buffered is
+   100 recipients. Rejection of messages (for excessive recipients)
+   with fewer than 100 RCPT TO commands is a violation of this
+   specification.  The general principle that relaying SMTP servers
+   MUST NOT, and delivery SMTP servers SHOULD NOT, perform validation
+   tests on message headers suggests that rejecting a message based
+   on the total number of recipients shown in header fields is to be
+   discouraged.  A server which imposes a limit on the number of
+   recipients MUST behave in an orderly fashion, e.g., reject
+   additional addresses over its limit rather than silently
+   discarding addresses previously accepted.  A client that needs to
+   deliver a message containing over 100 RCPT TO commands SHOULD be
+   prepared to transmit in 100-recipient "chunks" if the server
+   declines to accept more than 100 recipients in a single message. 
+
+
+****************************************************
+*                                                  *
+*  TO THE MAXIMUM EXTENT POSSIBLE, IMPLEMENTATION  *
+*  TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH *
+*  OF THESE OBJECTS SHOULD BE USED.                *
+*                                                  *
+****************************************************
+
+Errors due to exceeding these limits may be reported by using the
+reply codes, for example:
+
+500 Line too long.
+
+501 Path too long
+
+452 Too many recipients  (see below)
+
+552 Too much mail data.
+
+[RFC-821] incorrectly listed the error where an SMTP server exhausts
+its implementation limit on the number of RCPT TO commands ("too many
+recipients") as having reply code 552.  The correct reply code for
+this condition is 452.
+
+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 messsage, then at least these 100
+addresses will be removed from the SMTP client's queue.  When the
+client attempts retransmission of those addresses which recieved 452
+responses, at least 100 of these will be able to fit in the SMTP
+server's recipients buffer.  Each retransmission attempt which 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
+TO commands and this limit is exhausted, it MUST use a response code
+of 452.  If the server has an configured site-policy limitation on
+the number of RCPT TO commands, it MAY instead use a 5XX response
+code.
+
+In order to interoperate with SMTP servers implementing an older
+version of the protocol, SMTP clients MAY treat a 552 code obtained
+in response to an RCPT command as if it were a 452 response code.
+
+
+
+
+
+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: 
+
+o    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. 
+
+o    MAIL Command: 5 minutes
+
+
+o    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.
+
+o    DATA Initiation: 2 minutes
+
+     This is while awaiting the "354 Start Input" reply to a
+     DATA command.
+
+o    Data Block: 3 minutes
+
+     This is while awaiting the completion of each TCP SEND call
+	 transmitting a chunk of data. 
+
+o    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. 
+
+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   Queuing Strategies
+
+The common structure of a host SMTP implementation includes user
+mailboxes, one or more areas for queueing 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 queueing strategy MUST include:
+
+o    Timeouts on all activities on a per-command basis.
+
+o    Never sending error messages in response to error messages.
+
+
+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.
+
+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.  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 that
+discussed in [RFC-ETRN].
+
+The strategy may be further modified as a result of multiple
+addresses per host (see below) to optimize delivery time vs.
+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 MAIL FROM MUST NOT be cached.
+
+When the same message will be delivered to several users on the same
+host, only one copy of the message SHOULD be transmitted.  That is,
+the SMTP client SHOULD use the command sequence: RCPT, RCPT,... RCPT,
+DATA instead of the sequence: RCPT, DATA, ..., RCPT, DATA, ... RCPT,
+DATA.  Implementation of this efficiency feature is strongly
+encouraged.
+
+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 at all times.  This requires the support of multiple incoming
+TCP connections for SMTP.  Some limit MAY be imposed.
+
+As discussed above, when the SMTP server receives mail from a
+particular host address, it could notify the SMTP client to retry any
+mail pending for that host address.
+
+
+
+5. Address resolution and mail handling
+
+Once an SMTP client lexically identifies a domain to which mail will
+be delivered for processing (as described in sections ##3.6 and
+##3.7), a DNS lookup is performed to resolve the domain name (see
+[RFC-DNS]).  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 and, due to a history
+of problems, are generally discouraged.  The lookup first attempts to locate an MX record
+associated with the name.  If a CNAME record is found instead, the
+resulting name is processed as if it were the initial name.  If no MX
+records are found, but an A RR is found, the A RR is treated as if it
+was associated with an implicit MX RR, with a preference of 0,
+pointing to that host.  If one or more MX RRs are found for a given
+name, SMTP systems MUST NOT utilize an A RRs associated with that
+name unless they are located using the MX RRs; i.e., the "implicit
+MX" rule above applies only if there are no MX records present.  If
+MX records are present, but none of them are usable, this situation
+MUST be reported as an error.
+
+When the lookup succeeds, the mapping can result in a list of
+alternative delivery addresses rather than a single address, because
+of (a) multiple MX records, (b) 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, a host SHOULD try at least two addresses.
+
+The following information is used to rank the host addresses:
+
+ (1)  Multiple MX Records -- these contain a preference indication
+    that should be used in sorting (see below).  Lower numbers are
+	more preferred than higher ones.  If there are multiple
+	destinations with the same preference and there 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.
+
+ (2)  Multihomed host -- The destination host (perhaps taken from the
+    preferred MX record) may be multihomed, in which case the domain
+	name resolver will return a list of alternative IP addresses.  It
+	is the responsibility of the domain name resolver interface to
+	have ordered this list by decreasing preference if necessary, and
+	SMTP MUST try them in the order presented.
+
+    Although the capability to try multiple alternative addresses is
+	required, specific installations may want to limit or disable the
+	use of alternative addresses.  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 counterargument 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 a host receives a message with a destination for which it is a
+designated Mail eXchanger, it MAY relay the message (potentially
+after having rewritten the addresses), make final delivery of the
+message, or hand it off using some mechanism outside the
+SMTP-provided transport environment.
+
+If it determines that it should relay the message without rewriting
+the address, it must sort the MX records to determine candidates for
+delivery. The records are first ordered by preference, with the
+lowest-numbered records being most preferred.  The relay host must
+then inspect the list for any of the names or addresses by which it
+might be known in mail transactions.  If a matching record is found,
+all records at that preference level and higher-numbered ones MUST BE
+discarded from consideration.  If there are no records left at that
+point, it is an error condition, and the message must be returned as
+undeliverable.  If records do remain, they should be tried, best
+preference first, as described above.
+
+
+6. 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, i.e., it MUST NOT lose the message for frivolous reasons,
+e.g., because the host later crashes or because of a predictable
+resource shortage.
+
+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 SHOULD be the address
+from the envelope return path (or the Return-Path: line).  However,
+if this address is null ("<>"), the receiver-SMTP MUST NOT send a
+notification.  If the address is an explicit source route, it MUST be
+stripped down to its final hop.
+
+DISCUSSION:
+     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 should 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
+[RFC1047] for a discussion of this problem.
+
+
+6.2 Loop detection
+
+Simple counting of the number of Received lines 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.3 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
+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 [RFC-POP2,
+RFC-POP3, RFC-IMAP2, RFC-PCMAIL These protocols have encouraged the
+use of SMTP as a posting 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]).  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.
+
+The following changes to a message being processed MAY be applied by
+an originating SMTP server, or one used as the target of SMTP as an
+initial posting protocol, when necessary.  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.
+
+    - Addition of a message-id field when none appears
+
+    - Addition of a date, time or time zone when none appears
+
+    - Correction of addresses to proper FQDN format
+
+In all cases, properly-operating clients supplying correct
+information are preferred to corrections by the SMTP server. In all
+cases, documentation of actions performed by the servers (in trace
+fields and/or header comments) is strongly encouraged.
+
+
+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, e.g., those that can be provided in the MOSS
+framework [RFC-MOSS].
+
+Efforts to make it more difficult for users to set envelope MAIL FROM
+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 or in which error
+(or normal) replies should be directed to a special address. (Systems
+that provide convenient ways for users to alter these fields on a
+per-message basis should attempt to establish a primary and permanent
+mailbox address for the user so that Sender fields within the message
+data can be generated sensibly.)
+
+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 an ignorant user who is trying to fake mail.
+
+
+
+7.2 "Blind" copies.
+
+Addresses that do not appear in the message headers may appear in the
+RCPT TO 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".  In order to avoid defeating some of
+the purpose of these mechanisms, SMTP clients and servers SHOULD NOT
+copy the full set of RCPT TO command arguments into the headers,
+either as part of trace headers or as informational or
+private-extension headers.  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 TO command.
+
+There is no inherent relationship between either "reverse" (MAIL
+FROM, SAML FROM, etc.) or "forward" (RCPT TO) addresses in the SMTP
+transaction ("envelope") and the addresses in the headers.  Receiving
+systems SHOULD NOT attempt to deduce such relationships and use them
+to alter the headers of the message for delivery.  The popular
+"Apparently-to" header is a violation of this principle and SHOULD
+NOT be used.
+
+
+7.3  VRFY, EXPN, and security.
+
+As discussed in section ##3.5, individual sites may want to disable
+one or both VRFY or EXPN for security reasons.  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.
+
+Within the last few years, the contents of mailing lists have become
+popular as an address information source for so-called "spammers."
+The use of EXPN to "harvest" addresses has increased as list
+administrators have installed protections against inappropriate uses
+of the lists themselves.  Implementations SHOULD still provide
+support for EXPN, but sites should carefully evaluate the tradeoffs..
+As authentication mechanisms are introduced into SMTP, some sites may
+choose to make EXPN available only to authenticated requestors.
+
+
+7.4.  Information Disclosure
+
+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 useful
+information to 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 vunerabilities
+by hiding the server's precise identity will provide more protection.
+Sites are encouraged to evaluate the tradeoff with that issue in
+mind; implementations are strongly encouraged to minimally provide
+for making type and version information available in some way to
+other network hosts. 
+
+
+7.5.  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.
+
+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, MAIL FROM, or RCPT TO as appropriate.
+
+
+8. IANA Considerations
+
+IANA is [[requested]] to set up three registries.  The first 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 IESG for this purpose.
+
+The second registry consists of "tags" that identify forms of domain
+literals other than those for IPv4 addresses (specified in RFC 821
+and in this document) and IPv6 addresses (specified in this
+document).  Additional literal types require standardization before
+being used; none are anticipated at this time.
+
+The third, 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")
+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.
+
+
+
+9.  REFERENCES
+
+[1]  ASCII
+
+   ASCII, "USA Code for Information Interchange", United States of
+   America Standards Institute (now American National Standards
+   Institute), X3.4, 1968.  ANSI X3.4-1968 has been replaced by
+   newer versions with slight modifications, but the 1968
+   version remains definitive for the Internet.
+
+[RFC822]
+   Crocker, D., "Standard for the Format of ARPA Internet Text
+   Messages", RFC 822, Department of Electrical Engineering,
+   University of Delaware, August 1982.
+
+[3]  TCP
+   Postel, J., ed., "Transmission Control Protocol - DARPA Internet
+   Program Protocol Specification", RFC 793, USC/Information Sciences
+   Institute, NTIS AD Number A111091, September 1981.
+
+[HEADER-PEOPLE]
+
+[IPv6AddrString] Hinden,R and S. Deering, Eds. "IP Version 6
+      Addressing Architecture", RFC 1884, December 1995.
+
+[RFC-DNS] P. Mockapetris, "Domain names - implementation and
+      specification", RFC 1035 and P. Mockapetris, "Domain names -
+      concepts and facilities", RFC 1034.  (STD 13)
+
+[RFC974] C. Partridge, "Mail routing and the domain system", RFC
+      974, 01/01/1986
+
+[RFC1047] C. Partridge, "Duplicate messages and SMTP", RFC 1047,
+      02/01/1988.
+
+[RFC-SIZE]  J. Klensin, N. Freed, K. Moore, "SMTP Service Extension
+      for Message Size Declaration", RFC 1870, 11/06/1995.  (STD 10)
+
+[RFC-MIME] N. Freed, N. Borenstein, "Multipurpose Internet Mail 
+      Extensions  (MIME) Part One:  Format of Internet Message
+	  Bodies", RFC 2045, 12/02/1996. 
+
+[RFC-INTLHDR] K. Moore, "MIME (Multipurpose Internet Mail Extensions) 
+      Part Three:  Message Header Extensions for Non-ASCII Text", 
+	  RFC 2047, 12/02/1996. 
+
+[8BITMIME]  J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker,
+      "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652,
+      07/18/1994. 
+
+[SMTPEX]  J. Klensin, N. Freed, M. Rose, E. Stefferud, D.
+      Crocker, "SMTP Service Extensions", RFC-1869, 11/06/1995. (STD
+	  10)  
+
+[RFC-1123] R. Braden, "Requirements for Internet hosts -
+   application and support", 10/01/1989 
+
+[RFC-MOSS]  S. Crocker, N. Freed, J. Galvin, S. Murphy, "MIME Object
+   Security Services", RFC 1848, 10/03/1995.
+
+[RFC-POP2] M. Butler, D. Chase, J. Goldberger, J. Postel, J.
+     Reynolds, "Post Office Protocol - version 2", RFC 937,
+     02/01/1985
+
+[RFC-IMAP2]  M. Crispin, "Interactive Mail Access Protocol - Version
+     2", RFC 1176, 08/20/1990.
+
+[RFC-PCMAIL]  M. Lambert, "PCMAIL: A distributed mail system for
+     personal computers", RFC 1056, 06/01/1988.
+
+[RFC-POP3]  J. Myers, M. Rose, "Post Office Protocol - Version 3",
+   RFC 1930, 5/14/96 (Std 53).
+
+[RFC-IMAP4] M. Crispin, "Internet Message Access Protocol
+   - Version 4", RFC 2060, 12/04/1996.
+
+[RFC-X400]  S. Hardcastle-Kille, "Mapping between X.400(1988) /
+   ISO 10021 and RFC 822", RFC 1327, 05/18/1992.
+
+[RFC-ETRN] J. De Winter, "SMTP Service Extension for Remote
+   Message Queue Starting", RFC 1985, 08/14/1996.
+
+[RFC-BDAT] G. Vaudreuil, "SMTP Service Extensions for
+   Transmission of Large and Binary MIME Messages", RFC 1830,
+   08/16/1995. 
+
+[RFC-PIPELINE] N. Freed, A. Cargille, "SMTP Service Extension
+   for Command Pipelining", RFC 1854, 10/04/1995.
+
+[RFC-NOTARY1] K. Moore, "SMTP Service Extension for Delivery
+   Status Notifications", RFC 1891, 01/15/1996.
+
+[RFC-NOTARY2] K. Moore, G. Vaudreuil, "An Extensible Message
+   Format for Delivery Status Notifications", RFC 1894,
+   01/15/1996. 
+
+[RFC-REPLY] G. Vaudreuil, "Enhanced Mail System Status Codes",
+   RFC 1893, 01/15/1996.
+
+[ABNF] Crocker, D., P. Overell, Eds., "Augmented BNF for Syntax
+     Specifications: ABNF", RFC 2234, November 1997.
+
+[MSGFMT]  P. Resnick, Work in progress,
+      draft-ietf-drums-msg-fmt-04.txt, March 13, 1998
+
+
+9. Editor's Addresses
+
+ John C. Klensin
+ MCI Communications
+ 800 Boylston St., 7th floor
+ Boston, MA 02199
+ USA
+   Email: Klensin@mci.net
+   Phone: +1 617 960 1011
+   Fax:   +1 617 960 1009
+
+Dawn P. Mann
+Microsoft Corporation
+1 Microsoft Way
+Redmond, WA 98052-6399
+USA
+   Email: dawnm@microsoft.com
+   Tel: +1 425 936 5475
+
+
+
+10. Acknowledgments
+
+<<>>to be supplied>> 
+
+
+
+APPENDIX A
+
+TCP Transport service
+
+The Transmission Control Protocol [3] is used in the Internet, and in
+any network following the Internet standards for internetwork protocols.
+
+Connection Establishment
+
+   The SMTP transmission channel is a TCP connection established
+   between the sender process port U and the receiver process port
+   L.  This single full duplex connection is used as the
+   transmission channel.  This protocol is assigned the service
+   port 25 (31 octal), that is L=25.
+
+Data Transfer
+
+   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, but not in SMTP commands or responses.
+
+
+
+APPENDIX B
+
+Generating SMTP commands from RFC 822 headers
+ 
+Some systems use RFC 822 headers (only) in a mail submission
+protocol, or otherwise generate SMTP commands from RFC 822 headers
+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 a
+mail envelopes is not separated early in processing from header
+information (and kept separate).  
+
+It is recommended that the UA provide its initial MTA with an
+envelope separate from the message itself.  However, if the envelope
+is not supplied, SMTP commands should be generated as follows:
+
+(i) each recipient address from a TO, CC, or BCC header field
+should be copied to a RCPT command (generating multiple message
+copies if that is required for queuing or delivery).  This includes
+any addresses listed in a RFC 822 "group".  Any BCC fields should
+then be removed from the headers.  Once this process is completed,
+the remaining headers should be checked to verify that at least one
+To:, Cc:, or Bcc: header remains.  If none do, then a bcc: header
+with no additional information SHOULD be inserted as specified in
+[MSGFMT].
+
+(ii) the return address in the MAIL command should, if possible, be
+derived from the system's identity for the submitting (local) user.
+And the From header field otherwise.  If there is a system identity
+available, it should also be copied to the Sender header field if it
+is different from the address in the From header field.  (Any Sender
+field that was already there should be removed.)  Systems may provide
+a way for submitters to override the envelope return address, but may
+want to restrict its use to privileged users.  (This will not prevent
+mail forgery, but may lessen its incidence -- see section 7.1.)
+
+When an MTA is being used in this way, it bears responsibility for
+ensuring that the message being transmitted is valid.  The mechanisms
+for checking that validity, and for handling (or returning) messages
+that are not valid at the time of arrival, are part of the MUA-MTA
+interface and not covered by this specification.
+
+A submission protocol based on Standard RFC 822 information alone
+MUST NOT be used to gateway a message from a foreign (non-SMTP) mail
+system into an SMTP environment.  Additional information to construct
+an envelope must come from some source in the other environment,
+whether supplemental headers or the foreign system's envelope.
+
+Attempts to gateway messages using only their header "to" and "cc"
+fields, have repeatedly caused mail loops and other behavior adverse
+to the proper functioning of the Internet mail environment.  These
+problems have been especially common when the message originates from
+an Internet mailing list and is distributed into the foreign
+environment using envelope information.  When these messages are then
+processed by a header-only remailer, loops back to the Internet
+environment (and the mailing list) are almost inevitable.
+
+
+APPENDIX C
+
+Source routes.
+
+The <reverse-path> is a reverse source routing list of hosts and a
+source mailbox.  The first host in the <reverse-path> should be the
+host sending the MAIL FROM command.  Similarly, the <forward-path>
+may be a source routing lists of hosts and a destination mailbox.
+However, in general, the <forward-path> should contain only a mailbox
+and domain name, relying on the domain name system to supply routing
+information if required.   The use of source routes is deprecated;
+while servers MUST be prepared to receive and handle them as
+discussed in section ##3.3 and below, clients SHOULD NOT transmit
+them. 
+
+For relay purposes, the forward-path may be a source route of the
+form "@ONE,@TWO:JOE@THREE", where ONE, TWO, and THREE MUST BE
+fully-qualified domain names.  This form is used to emphasize the
+distinction between an address and a route.  The mailbox is an
+absolute address, and the route is information about how to get
+there.  The two concepts should not be confused.
+
+If source routes are used, RFC 821 and the text below should be
+consulted for the mechanisms for constructing and updating the
+forward- and reverse-paths.
+
+The SMTP server transforms the command arguments by moving its own
+identifier (its domain name or that of any domain for which it is
+acting as a mail exchanger), if it appears, from the forward-path to
+the beginning of the reverse-path.  
+
+Notice that the forward-path and reverse-path appear in the SMTP
+commands and replies, but not necessarily in the message.  That is,
+there is no need for these paths and especially this syntax to appear
+in the "To:" , "From:", "CC:", etc. fields of the message header.
+Conversely, SMTP servers MUST NOT derive final message delivery
+information from message header fields.
+
+ When the list of hosts is present, it is a "reverse" source route
+and indicates that the mail was relayed through each host on the list
+(the first host in the list was the most recent relay).  This list is
+used as a source route to return non-delivery notices to the sender.
+As each relay host adds itself to the beginning of the list, it must
+use its name as known in the transport environment to which it is
+relaying the mail rather than that of the transport environment from
+which the mail came (if they are different). 
+
+
+
+
+APPENDIX F
+
+Scenarios
+
+This section presents complete scenarios of several types of SMTP
+sessions.
+
+A Typical SMTP Transaction Scenario
+
+This SMTP example shows mail sent by Smith at host USC-ISIF, to
+Jones, Green, and Brown at host BBN-UNIX.  Here we assume that host
+USC-ISIF contacts host BBN-UNIX directly.  The mail is accepted for
+Jones and Brown.  Green does not have a mailbox at host BBN-UNIX.
+
+-------------------------------------------------------------
+
+   R: 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready
+   S: HELO USC-ISIF.ARPA
+   R: 250 BBN-UNIX.ARPA
+
+   S: MAIL FROM:<Smith@USC-ISIF.ARPA>
+   R: 250 OK
+
+   S: RCPT TO:<Jones@BBN-UNIX.ARPA>
+   R: 250 OK
+
+   S: RCPT TO:<Green@BBN-UNIX.ARPA>
+   R: 550 No such user here
+
+   S: RCPT TO:<Brown@BBN-UNIX.ARPA>
+   R: 250 OK
+
+   S: DATA
+   R: 354 Start mail input; end with <CRLF>.<CRLF>
+   S: Blah blah blah...
+   S: ...etc. etc. etc.
+   S: .
+   R: 250 OK
+
+   S: QUIT
+   R: 221 BBN-UNIX.ARPA Service closing transmission channel
+
+                         Scenario 1
+
+-------------------------------------------------------------
+
+
+
+
+
+Aborted SMTP Transaction Scenario
+
+-------------------------------------------------------------
+
+   R: 220 MIT-Multics.ARPA Simple Mail Transfer Service Ready
+   S: HELO ISI-VAXA.ARPA
+   R: 250 MIT-Multics.ARPA
+
+   S: MAIL FROM:<Smith@ISI-VAXA.ARPA>
+   R: 250 OK
+
+   S: RCPT TO:<Jones@MIT-Multics.ARPA>
+   R: 250 OK
+
+   S: RCPT TO:<Green@MIT-Multics.ARPA>
+   R: 550 No such user here
+
+   S: RSET
+   R: 250 OK
+
+   S: QUIT
+   R: 221 MIT-Multics.ARPA Service closing transmission channel
+
+                         Scenario 2
+
+-------------------------------------------------------------
+
+
+
+Relayed Mail Scenario
+
+-------------------------------------------------------------
+
+   Step 1  --  Source Host to Relay Host
+
+      R: 220 USC-ISIE.ARPA Simple Mail Transfer Service Ready
+      S: HELO MIT-AI.ARPA
+      R: 250 USC-ISIE.ARPA
+
+      S: MAIL FROM:<JQP@MIT-AI.ARPA>
+      R: 250 OK
+
+      S: RCPT TO:<@USC-ISIE.ARPA:Jones@BBN-VAX.ARPA>
+      R: 250 OK
+
+      S: DATA
+      R: 354 Start mail input; end with <CRLF>.<CRLF>
+      S: Date: 2 Nov 81 22:33:44
+      S: From: John Q. Public <JQP@MIT-AI.ARPA>
+      S: Subject:  The Next Meeting of the Board
+      S: To: Jones@BBN-Vax.ARPA
+      S:
+      S: Bill:
+      S: The next meeting of the board of directors will be
+      S: on Tuesday.
+      S:                                              John.
+      S: .
+      R: 250 OK
+
+      S: QUIT
+      R: 221 USC-ISIE.ARPA Service closing transmission channel
+
+
+   Step 2  --  Relay Host to Destination Host
+
+      R: 220 BBN-VAX.ARPA Simple Mail Transfer Service Ready
+      S: HELO USC-ISIE.ARPA
+      R: 250 BBN-VAX.ARPA
+
+      S: MAIL FROM:<@USC-ISIE.ARPA:JQP@MIT-AI.ARPA>
+      R: 250 OK
+
+      S: RCPT TO:<Jones@BBN-VAX.ARPA>
+      R: 250 OK
+
+      S: DATA
+      R: 354 Start mail input; end with <CRLF>.<CRLF>
+      S: Received: from MIT-AI.ARPA by USC-ISIE.ARPA ;
+         2 Nov 81 22:40:10 UT
+      S: Date: 2 Nov 81 22:33:44
+      S: From: John Q. Public <JQP@MIT-AI.ARPA>
+      S: Subject:  The Next Meeting of the Board
+      S: To: Jones@BBN-Vax.ARPA
+      S:
+      S: Bill:
+      S: The next meeting of the board of directors will be
+      S: on Tuesday.
+      S:                                              John.
+      S: .
+      R: 250 OK
+
+      S: QUIT
+      R: 221 USC-ISIE.ARPA Service closing transmission channel
+
+                         Scenario 3
+
+-------------------------------------------------------------
+
+
+
+
+Verifying and Sending Scenario
+
+-------------------------------------------------------------
+
+   R: 220 SU-SCORE.ARPA Simple Mail Transfer Service Ready
+   S: HELO MIT-MC.ARPA
+   R: 250 SU-SCORE.ARPA
+
+   S: VRFY Crispin
+   R: 250 Mark Crispin <Admin.MRC@SU-SCORE.ARPA>
+
+   S: SEND FROM:<EAK@MIT-MC.ARPA>
+   R: 250 OK
+
+   S: RCPT TO:<Admin.MRC@SU-SCORE.ARPA>
+   R: 250 OK
+
+   S: DATA
+   R: 354 Start mail input; end with <CRLF>.<CRLF>
+   S: Blah blah blah...
+   S: ...etc. etc. etc.
+   S: .
+   R: 250 OK
+
+   S: QUIT
+   R: 221 SU-SCORE.ARPA Service closing transmission channel
+
+                         Scenario 4
+
+-------------------------------------------------------------
+
+
+
+
+Mailing List Scenario
+
+First each of two mailing lists are expanded in separate sessions
+with different hosts.  Then the message is sent to everyone that
+appeared on either list (but no duplicates) via a relay host.
+
+-------------------------------------------------------------
+
+   Step 1  --  Expanding the First List
+
+      R: 220 MIT-AI.ARPA Simple Mail Transfer Service Ready
+      S: HELO SU-SCORE.ARPA
+      R: 250 MIT-AI.ARPA
+
+      S: EXPN Example-People
+      R: 250-<ABC@MIT-MC.ARPA>
+      R: 250-Fred Fonebone <Fonebone@USC-ISIQ.ARPA>
+      R: 250-Xenon Y. Zither <XYZ@MIT-AI.ARPA>
+      R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA>
+      R: 250-<joe@foo-unix.ARPA>
+      R: 250 <xyz@bar-unix.ARPA>
+
+      S: QUIT
+      R: 221 MIT-AI.ARPA Service closing transmission channel
+
+
+   Step 2  --  Expanding the Second List
+
+      R: 220 MIT-MC.ARPA Simple Mail Transfer Service Ready
+      S: HELO SU-SCORE.ARPA
+      R: 250 MIT-MC.ARPA
+
+      S: EXPN Interested-Parties
+      R: 250-Al Calico <ABC@MIT-MC.ARPA>
+      R: 250-<XYZ@MIT-AI.ARPA>
+      R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA>
+      R: 250-<fred@BBN-UNIX.ARPA>
+      R: 250 <xyz@bar-unix.ARPA>
+
+      S: QUIT
+      R: 221 MIT-MC.ARPA Service closing transmission channel
+
+
+   Step 3  --  Mailing to All via a Relay Host
+
+      R: 220 USC-ISIE.ARPA Simple Mail Transfer Service Ready
+      S: HELO SU-SCORE.ARPA
+      R: 250 USC-ISIE.ARPA
+
+      S: MAIL FROM:<Account.Person@SU-SCORE.ARPA>
+      R: 250 OK
+      S: RCPT TO:<@USC-ISIE.ARPA:ABC@MIT-MC.ARPA>
+      R: 250 OK
+      S: RCPT TO:<@USC-ISIE.ARPA:Fonebone@USC-ISIQA.ARPA>
+      R: 250 OK
+      S: RCPT TO:<@USC-ISIE.ARPA:XYZ@MIT-AI.ARPA>
+      R: 250 OK
+      S: RCPT
+          TO:<@USC-ISIE.ARPA,@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA>
+      R: 250 OK
+      S: RCPT TO:<@USC-ISIE.ARPA:joe@FOO-UNIX.ARPA>
+      R: 250 OK
+      S: RCPT TO:<@USC-ISIE.ARPA:xyz@BAR-UNIX.ARPA>
+      R: 250 OK
+      S: RCPT TO:<@USC-ISIE.ARPA:fred@BBN-UNIX.ARPA>
+      R: 250 OK
+
+      S: DATA
+      R: 354 Start mail input; end with <CRLF>.<CRLF>
+      S: Blah blah blah...
+      S: ...etc. etc. etc.
+      S: .
+      R: 250 OK
+
+      S: QUIT
+      R: 221 USC-ISIE.ARPA Service closing transmission channel
+
+                         Scenario 7
+
+-------------------------------------------------------------
+
+
+
+Too Many Recipients Scenario
+
+-------------------------------------------------------------
+
+   R: 220 BERKELEY.ARPA Simple Mail Transfer Service Ready
+   S: HELO USC-ISIF.ARPA
+   R: 250 BERKELEY.ARPA
+
+   S: MAIL FROM:<Postel@USC-ISIF.ARPA>
+   R: 250 OK
+
+   S: RCPT TO:<fabry@BERKELEY.ARPA>
+   R: 250 OK
+
+   S: RCPT TO:<eric@BERKELEY.ARPA>
+   R: 552 Recipient storage full, try again in another transaction
+
+   S: DATA
+   R: 354 Start mail input; end with <CRLF>.<CRLF>
+   S: Blah blah blah...
+   S: ...etc. etc. etc.
+   S: .
+   R: 250 OK
+
+   S: MAIL FROM:<Postel@USC-ISIF.ARPA>
+   R: 250 OK
+
+   S: RCPT TO:<eric@BERKELEY.ARPA>
+   R: 250 OK
+
+   S: DATA
+   R: 354 Start mail input; end with <CRLF>.<CRLF>
+   S: Blah blah blah...
+   S: ...etc. etc. etc.
+   S: .
+   R: 250 OK
+
+   S: QUIT
+   R: 221 BERKELEY.ARPA Service closing transmission channel
+
+                        Scenario 10
+
+-------------------------------------------------------------
+
+Note that a real implementation must handle many recipients as
+specified in Section ##4.5.3.
+
+
+
+APPENDIX G  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,
+e.g., envelope information from one system to the message headers or
+body of another have generally proven to be inadequate in important
+ways.  Systems translating between environments that do not support
+both envelopes and headers and Internet mail must be written with the
+understanding that some information loss is almost inevitable.
+
+
+
+APPENDIX I: Deprecated features of RFC 821
+
+A few features of RFC 821 have proven to be problematic and should
+not be used in Internet mail.  These are:
+
+(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. 
+
+
+(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.  
+
+(3) HELO
+
+As discussed in sections ##3.1 and ##4.1.1, EHLO is strongly
+preferred to HELO when the server will accept the former.  Servers
+must continue to accept and process HELO in order to support older
+clients.
+
+
+(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.
+
+(5) Dates and years
+
+When dates are inserted into messages by SMTP clients or servers
+(e.g., in trace fields), four-digit years MUST BE used.  Two-digit
+years are deprecated; three-digit years were never permitted in the
+Internet mail system.
+
+(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.
+
+
+
+APPENDIX X: Change summary and Loose ends (temporary)
+
+X.1 Change summary
+
+X.1.1 Substantive changes between draft-ietf-drums-smtpupd-00.txt and
+draft-ietf-drums-smtpupd-01.txt 
+
+(i) Slightly clarified the discussions of rejection and failure of
+VRFY requests and the associated response codes.
+
+(ii) Slightly clarified the discussion of deferred address
+validation. 
+
+(iii) Removed the IPCE terminology and modified the text in section
+##4.1.1.2 to explicitly introduce the "mail gateway" terminology and
+to begin to distinguish a mail gateway from a conventional relay.
+
+(iv) Explicitly noted that SMTP clients for things like POP and IMAP
+may send everything to a single relay for further processing, rather
+than resolving final domain names.
+
+(v) Tightened the RSET discussion.
+
+(vi) Deprecation of 251 only for RCPT (still ok for VRFY)
+
+
+
+X.1.2.  Substantive changes between draft-ietf-drums-smtpupd-01.txt
+and draft-ietf-drums-smtpupd-02.txt.
+
+Incorporated additional RFC 1123 material; reorganized several
+sections for clarity.  Added definitions and other previous "loose
+end" material.
+
+
+X.1.3.  Substantive changes between draft-ietf-drums-smtpupd-02.txt
+and draft-ietf-drums-smtpupd-03.txt.
+
+(i) Eliminated a number of placeholders and tightened some of the
+definitions in section 2.  Added a few new placeholders for
+consistency checking against other documents.
+
+(ii) Removed the state diagrams, per direction at IETF Montreal.
+
+(iii) Added new section 6.3, an attempt to summarize WG discussions
+on the "posting" versus "delivery" versus "relay" functions of SMTP
+and on whether "fixups" are appropriate in different cases.
+
+(iv) Inserted section 6.1, a minor rewrite of section 5.3.3 of
+RFC1123. 
+
+(v) Added new text to 3.5.5 to discuss the spammer - EXPN
+relationship. 
+
+(vi) The "ASCII requirement" in 4.1.1.4 has been tightened somewhat.
+
+(v) The remaining miscellaneous changes agreed to in Montreal have
+been incorporated except as noted below.
+
+
+X.1.4.  Substantive changes between draft-ietf-drums-smtpupd-03.txt
+and draft-ietf-drums-smtpupd-04.txt.
+
+Many small changes have been made between these two versions; the
+list that follows is not exhaustive.
+
+(i) To clarify some of the text, definitions have been introduced to
+distinguish among originating, delivery, relay, and gateway SMTP
+systems. 
+
+(ii) The role of LF-terminated lines has been clarified.
+
+(iii) Several changes have been made to clarify the principle
+that, no matter what originating and final delivery systems
+might do, relay systems are not permitted to tamper with message
+content, even to "fix" headers that are determined to be
+invalid.  If they deem message content to be seriously
+unacceptable, they are encouraged to reject the messages in
+preference to trying to fix them up, but, in general, the theme
+is "don't look/ don't tell".
+
+(iv) A few more definitions have been added to the terminology
+section, and the separate glossary has been eliminated.
+
+(v) I have taken a shot at text to address some of the controversies
+that have raged on the WG mailing list (e.g., sections 7.4 and 7.5).
+Since there was no consensus on most of those topics, I expect that
+the inserted text will satisfy no one except, perhaps, for agreement
+that saying nothing would have been worse.  As a mechanism for moving
+forward, the text in these controversial areas that now appears will
+be considered "base"; alterations will be made only if clear
+consensus emerges.
+
+(vi) Per discussion in Los Angeles, source routes have been further
+deprecated. 
+
+(vii) Some of the VRFY/EXPN materials have been moved to "security
+considerations", where they appear to belong, some text has been
+added, and the conformance statements adjusted to reflect what I
+perceive to be WG consensus.
+
+(viii) New MX resolution material has been added to section 5.  While
+most of this material is from RFC974, the rules have been further
+tightened to reflect current practice and experience (974 is written
+in a somewhat speculative fashion for a standard).  In particular,
+the behavior of trying the target host's A RR when MXs existed but
+all of them were eliminated is now prohibited, which seems necessary
+if another of other ideas being recommended or considered are to be
+feasible. 
+
+
+X.1.5.  Substantive changes between draft-ietf-drums-smtpupd-04.txt
+and draft-ietf-drums-smtpupd-05.txt.
+
+(i) All normative references to RFC 1123 have been removed from the
+main body of the text (some still appear in the appendices where they
+will remain).
+
+(ii) Section 3.5 has been renamed slightly to distinguish between
+"debuging of SMTP implementations" and "debugging of addresses".
+Better terminology would be welcome.
+
+(iii) Error conditions resulting from the DATA command have been
+clarified. 
+
+(iv) Section 4.2 (SMTP replies) has been revised and tightened to
+reflect reality and recent discussion on the list.
+
+(v) Appendix E has been revised a bit and moved into section 4.2.1.
+Given the importance of the "check only first digit" rule, it has to
+be there.
+
+(vi) Added new text for "no SMTP service supported" to sections
+3.1, 4.2.2, 4.2.3, and 4.3.2.  As noted in 3.1, I'd rather add 521
+(which would work perfectly with the model) rather than overloading
+554.  
+
+(vii) The Return-path language in section 4.4 has been cleaned up a
+bit. 
+
+(viii) Tightened the "postmaster" language in 4.5.1, requiring a
+small change to 4.1.1.3.
+
+(ix) I have unilaterally (with a little help from my friends),
+increased some of the size limits.  64 was much too short for a
+domain name, and the DNS limit of 255 (?) has now been inserted.
+That leaves the return path much too short, but I haven't fixed it
+(maybe that will cause us to get rid of them).  We still have a 64
+character limit on the local-part, which is also *much* too short.
+Votes for 128 or longer limits accepted.  See X.1.6(I)
+
+(x) The text on the "recipients buffer" has been rewritten so that (I
+hope) it makes sense and gives some explicit guidance for how clients
+and servers should proceed if limits are imposed.
+
+
+X.1.6.  Substantive changes between draft-ietf-drums-smtpupd-05.txt
+and draft-ietf-drums-smtpupd-06.txt.
+
+Most of the changes in this revision have been editorial rather than 
+substantive.  Major substantive changes include:
+
+(i)  The language about maximum sizes of SMTP command lines has been 
+reworked, per WG mailing list discussion.
+
+(ii)  Several instances of  "Should" have been promoted to "Must" when the 
+reasons for the weaker rule seemed to have disappeared.   In
+particular, the requirement that an SMTP implementation support
+timeouts has become a MUST.  Also, conformance to this specification
+requires support of EHLO.  Older systems should claim conformance to
+the [to-be-historical] 821, not this specification.
+
+
+X.1.7.    Substantive changes between draft-ietf-drums-smtpupd-06.txt
+and draft-ietf-drums-smtpupd-07.txt.
+
+(i) Removed "implied RSET" text associated with QUIT, as specified
+at the December 1997 IETF
+
+(ii) Required that servers support EHLO, as specified at the December
+1997 IETF
+
+
+X.1.8. Substantive changes between draft-ietf-drums-smtpupd-07.txt
+and draft-ietf-drums-smtpupd-08.txt.
+
+This version involves mostly editorial work and cleanup of loose
+ends. 
+
+(i) Error code presentation has been restructured.
+
+(ii) ABNF conversion done
+
+(iii) IPv6 address format inserted per RFC 1884, since we could not
+get clear agreement on an alternative.
+
+(iv) Trivial, silly, examples removed.  Others not yet renumbered.
+
+(v) 3.5.2 and 4.1.1 altered slightly per Eric Allman's notes.  Eric
+may not like the way I've done either of these change very much: the
+first now makes the distinction between returning an address and
+returning other stuff (which was permitted by -06, but the text
+wasn't as clear as it should have been): if it looks like an address,
+it needs to be an address.  Similarly, with 4.1.1, Eric wanted to
+explicitly permit/legitimize "DATA <SP> <CRLF>".  I see several
+disadvantages to doing that, so have inserted language that
+encourages receivers to tolerate trailing white space, which may have
+the same practical effect.
+
+
+
+
+
+X.2 Loose ends
+
+(i) The 821 BNF -> ABNF transition needs careful checking.
+
+(ii) Most remaining examples are not yet revised, overview and
+grammar are still to be merged.  Examples need to be renumbered and
+cross references need to be checked.
+
+(iii) Trace field discussion should be checked carefully,
+particularly since the syntax given is slightly different from 821.
+Provision has been made, reflecting some current practice, for
+(optional) fractional seconds in time stamps.
+
+(iv) The Appendices have not yet been numbered consecutively.  Note
+that Appendix X is temporary and is not expected to appear in any
+final publication.
+
+(v) See X.1.5(ix), above.
+
+(vi) Remaining syntax differences and redundancies wrt 822bis (see
+note on section 4.1.2).  Note that the use of "Atom" for extension
+parameter keywords is slightly different from the specification in
+RFC 1869.
+
+(vii) We don't have a satisfactory definition for "link" as in
+"Received:.. via <link>" and, if there is a registry, I can't find
+it.  Needs to be fixed somehow.
diff --git a/Documentation/en/I-D/draft-ietf-drums-smtpupd-08.txt b/Documentation/en/I-D/draft-ietf-drums-smtpupd-08.txt
new file mode 100644
index 00000000..8124c110
--- /dev/null
+++ b/Documentation/en/I-D/draft-ietf-drums-smtpupd-08.txt
@@ -0,0 +1,3574 @@
+INTERNET-DRAFT                                John C. Klensin, Editor
+Expires in six months                         
+August 4, 1998
+                                                        
+
+                  Simple Mail Transfer Protocol 
+
+                 draft-ietf-drums-smtpupd-08.txt
+
+Status of this Memo
+
+This document is an Internet-Draft.  Internet-Drafts are working documents
+of the Internet Engineering Task Force (IETF), its areas, and its working
+groups.  Note that other groups may also distribute working documents as
+Internet-Drafts.
+
+Internet-Drafts are draft documents valid for a maximum of six months and
+may be updated, replaced, or obsoleted by other documents at any time.  It
+is inappropriate to use Internet- Drafts as reference material or to cite
+them other than as "work in progress."
+
+To view the entire list of current Internet-Drafts, please check the
+"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
+Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe),
+ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim),
+ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
+
+[[Sections marked with doubled brackets (e.g., "<<") are explicit
+placeholders or known major loose ends. Please review these ASAP. The
+sections with these placeholders are 4.1.1.1, 4.1.2, 4.4, 8, and X.2.]]
+
+[[Appendix X will be removed before the document is submitted to the
+IESG.]]
+
+[[If consensus is reached on this document, it will be forwarded to the
+IESG with the recommendation that it be processed onto the Standards
+track.]]
+
+Copyright Notice
+
+Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+                           Table of Contents
+
+0. Abstract
+
+1. Introduction
+
+2. The SMTP Model
+2.1 Basic Structure
+2.2 The Extension Model
+2.2.1 Background
+2.2.2 Definition and Registration of Extensions
+2.3 Terminology
+2.3.1 Mail Objects
+2.3.2 Senders and Receivers
+2.3.3 Mail Agents
+2.3.4 Host
+2.3.5 Domain
+2.3.6 Buffer and State Table
+2.3.7 Lines
+2.3.8 Originator, Delivery, Relay, and Gateway Systems
+2.3.9 Message Content and Mail Data
+2.3.10 Mailbox and Address
+2.3.11 Reply
+2.4 Syntax Principles
+2.4.1 General Syntax and Transaction Model
+2.4.2 Command and Reply Syntax
+
+3. The SMTP Procedures: An Overview
+3.1 Session Initiation
+3.2 Client Initiation
+3.3 Mail Transactions
+3.4 Forwarding for Address Correction or Updating
+3.5 Commands for Debugging Addresses
+3.5.1 Overview
+3.5.2 VRFY Normal Response
+3.5.3 Meaning of VRFY or EXPN Success Response
+3.5.4 Semantics and Applications of EXPN
+3.6 Domains
+3.7 Relaying
+3.8 Mail Gatewaying
+3.8.1 Header Fields in Gatewaying
+3.8.2 Received Lines in Gatewaying
+3.8.3 Addresses in Gatewaying
+3.8.4 Other Header Fields in Gatewaying
+3.8.5 Envelopes in Gatewaying
+3.9 Terminating Sessions and Connections
+3.10 Mailing Lists and Aliases
+3.10.1 Alias
+3.10.2 List
+
+4. The SMTP Specifications
+4.1 SMTP Commands
+4.1.1 Command Semantics and Syntax
+4.1.1.1  Extended HELLO (EHLO) or HELLO (HELO)
+4.1.1.2 MAIL (MAIL)
+4.1.1.3 RECIPIENT (RCPT)
+4.1.1.4 DATA (DATA)
+4.1.1.5 RESET (RSET)
+4.1.1.6 VERIFY (VRFY)
+4.1.1.7 EXPAND (EXPN)
+4.1.1.8 HELP (HELP)
+4.1.1.9 NOOP (NOOP)
+4.1.1.10 QUIT (QUIT)
+4.1.2 Lower-level Syntax
+4.1.3 Address Literals
+4.1.4 Order of Commands
+4.1.5 Private-use Commands
+4.2  SMTP Replies
+4.2.1 Reply Code Severities and Theory
+4.2.2 Reply Codes by Function Groups
+4.2.3  Reply Codes in Numeric Order
+4.2.4 Reply Code 502
+4.2.5 Reply Codes After DATA and the Subsequent <CRLF>.<CRLF>
+4.3 Sequencing of Commands and Replies
+4.3.1 Sequencing Overview
+4.3.2 Command-Reply Sequences
+4.4 Trace Information
+4.5 Additional Implementation Issues
+4.5.1 Minimum Implementation
+4.5.2 Transparency
+4.5.3 Sizes and Timeouts
+4.5.4 Queuing Strategies
+4.5.4.1 Sending Strategy
+4.5.4.2 Receiving Strategy
+
+5. Address Resolution and Mail Handling
+
+6. Problem Detection and Handling
+6.1 Reliable Delivery and Replies by Email
+6.2 Loop Detection
+6.3 Compensating for Irregularities
+
+7. Security Considerations
+7.1 Mail Security and Spoofing
+7.2 "Blind" Copies
+7.3 VRFY, EXPN, and Security
+7.4 Information Disclosure in Announcements
+7.5 Information Disclosure in Trace Fields
+7.6 Scope of Operation of SMTP Servers
+
+8. IANA Considerations
+
+9. References
+
+10. Editors' Addresses
+
+11. Acknowledgments
+
+A. TCP Transport Service
+B. Generating SMTP Commands from RFC 822 Headers 
+C. Source Routes
+D. Scenarios
+E. Other Gateway Issues
+F. Deprecated Features of RFC 821
+X. Change Summary and Loose Ends (Temporary)
+
+
+0. Abstract
+
+This document is a self-contained specification of the basic protocol for
+the Internet electronic mail transport, consolidating and updating:
+
+ - the original SMTP specification of RFC 821 [RFC-821],
+
+ - domain name system requirements and implications for mail transport from
+   RFC 1035 [RFC-DNS] and RFC 974 [RFC-974],
+
+ - the clarifications and applicability statements in RFC 1123 [RFC-1123],
+   and
+
+ - material drawn from the SMTP Extension mechanisms [SMTPEXT].
+
+It replaces RFC 821, RFC 974, and the mail transport materials of RFC 1123.
+However, RFC 821 specifies some features that are not in significant use in
+the Internet of 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 turned up 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 posting" protocol, as recommended for POP [RFC-POP2, RFC-POP3] and
+IMAP [RFC-IMAP4].
+
+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 discusses message headers, message bodies and formats
+and structures for them, and their relationship - [MSGFMT].
+
+
+1. Introduction
+
+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 describe some of them.
+
+An important feature of SMTP is its capability to transport mail across
+transport service environments, usually referred to as "SMTP mail relaying"
+(see section 3.8).  A transport service  environment might consist of the
+mutually-TCP-accessible hosts on  the public Internet, the
+mutually-TCP-accessible hosts on a firewall-isolated private TCP/IP
+Intranet, or hosts in some other LAN or WAN environment utilizing a
+different transport-level protocol.  It is important to realize that
+"transport service environments" are one-to-one with usual definitions of
+"networks".  A process can communicate directly with another process, and
+transport mail using this protocol, through any mutually known and
+connected transport service. Conversely, mail can be relayed or gatewayed
+between processes in two different transport service environments by a
+process known and connected to each of the two transport service
+environments. The Mail eXchanger mechanisms of the domain name system
+[RFC-DNS, and section 5 of this document] allows the identity of hosts
+supporting SMTP relay and gateway processes to be specified.
+
+
+2. The SMTP Model
+
+2.1 Basic Structure
+
+The SMTP design can be pictured as:
+
+               +----------+                +----------+
+   +------+    |          |                |          |
+   | User |<-->|          |      SMTP      |          |
+   +------+    |  Sender- |Commands/Replies| Receiver-|
+   +------+    |   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 role 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 transferred to an SMTP client, and how
+that client determines the domain name(s) to which mail messages are to be
+transferred is a local matter, and is not addressed by this document. In
+some cases, the domain name(s) transferred to, or 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-POP2, RFC-POP3] or IMAP [RFC-IMAP4] protocols, or when the SMTP client
+is inside an isolated transport service environment, the domain name
+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 domain names 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.
+
+The means by which an SMTP client, once it has determined a target domain
+name, 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.
+
+Once the transmission channel is established and initial handshaking
+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 headers 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 extension
+requests such as in [RFC-Pipeline].
+
+Once a given mail message has been transmitted, the client may either
+request that the connection be shut down or may initiate other mail
+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.  This transmission normally occurs 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.
+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.
+
+To provide relay capability, the SMTP server is supplied with the name of
+the ultimate destination host as well as the destination mailbox name.
+Usually, intermediate hosts are determined via the DNS MX record, not by
+explicit "source" routing (see appendices C and 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 added, it must be done in
+a way that permits older implementations to continue working acceptably.
+The extension framework consists of:
+
+ - The SMTP command EHLO, superseding the earlier HELO,
+
+ - a registry of SMTP service extensions,
+
+ - additional parameters to the SMTP MAIL FROM and RCPT TO commands, and
+
+ - optional replacements for verbs defined in this protocol, such as for
+   DATA (see [RFC-BDAT]).
+
+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:
+
+ - the textual name of the SMTP service extension;
+
+ - the EHLO keyword value associated with the extension;
+
+ - the syntax and possible values of parameters associated with the
+   EHLO keyword value;
+
+ - any additional SMTP verbs associated with the extension (additional
+   verbs will usually be, but are not required to be, the same as the
+   EHLO keyword value);
+
+ - any new parameters the extension associates with the MAIL FROM or
+   RCPT TO verbs;
+
+ - a description of how support for the extension affects the behavior
+   of a server and client SMTP; and,
+
+ - the increment by which the extension is increasing the maximum
+   length of the commands MAIL FROM and/or RCPT TO, over that specified
+   in RFC 821.
+
+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.3 Terminology
+
+Most of the terminology in this document is common in the Internet at the
+time of its writing.  However, the following terms and concepts are used in
+special ways here, or represent differences in terminology between RFC 821
+and this document, and should be understood before reading further.  These
+definitions are normative, that is, they contain specifications to which
+SMTP implementations are required to conform.
+
+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 which error reports
+should be directed); a delivery mode (e.g., deliver to recipient
+mailboxes); one or more recipient addresses; and optional protocol
+extension material.
+
+The SMTP content is sent in the SMTP DATA protocol unit and has two parts:
+the headers and the body. If the content conforms to existing standards,
+the headers form a collection of field/value pairs structured as described
+in [MSGFMT]; the body, if structured, is defined according to MIME
+[RFC-MIME]. The content is textual in nature, expressed using the US-ASCII
+repertoire [US-ASCII]. Although SMTP extensions (such as [8BitMIME]) may
+relax this restriction for the content body, the content headers are always
+encoded using the US-ASCII repertoire. The algorithm defined in
+[RFC-INTLHDR] is used to represent 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
+
+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).
+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
+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 "domain");
+identifying them by numerical address is discouraged.
+
+2.3.5 Domain
+
+A domain (or domain name) consists of one or more dot-separated components,
+each consisting of a sequence of letters, digits, and hyphens.  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-DNS] and section 5.
+
+The domain name, as described in this document and in [RFC-DNS], 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.
+
+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 which 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 Lines
+
+SMTP commands and, unless altered by a service extension, message data, are
+transmitted in "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.
+
+2.3.8 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 hands it to a mail user agent or deposits it in a message
+store which 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.
+
+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 message headers and the possibly-structured message body.
+The MIME specification [RFC-MIME] provides the Standard mechanisms for
+structured message bodies.
+
+2.3.10 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" and, consequently, the local-part is
+interpreted and assigned semantics only by the host specified in the domain
+part of the address.
+
+2.3.11 Reply
+
+An SMTP reply is an acknowledgment (positive or negative) sent from
+receiver to sender via the transmission channel in response to a command.
+The general form of a reply is a numeric completion code (indicating
+failure or success) followed by a text string.  The codes are for use by
+programs and the text is usually intended for human users.
+
+2.4 Syntax Principles
+
+2.4.1 General Syntax and Transaction Model
+
+SMTP commands and replies have a rigid syntax. All commands begin with a
+four letter command verb. All Replies begin with a three digit numeric
+code. In some commands and replies, arguments MUST follow 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
+<SP>. Complete definitions of commands and replies appear in section 4.
+
+Verbs and argument values are not case sensitive, with the sole exception
+of a mailbox local-part. 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.  This is NOT true of a mailbox local-part. 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.  Mailbox
+domains are not case sensitive.  However, exploiting the case sensitivity
+of mailbox local-parts impedes interoperability and is discouraged.
+
+Commands and replies are composed of characters from the ASCII character
+set [US-ASCII]. 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 seven bit transport only.  An originating
+SMTP client which has not successfully negotiated an appropriate extension
+with a particular server 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 ultimate delivery of a severely garbled message
+to the recipient.  Delivery SMTP systems MAY reject ("bounce") such
+messages rather than deliver them.  No sending SMTP system is 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.
+
+Eight-bit message content transmission MAY be requested of the server by a
+client using extended SMTP facilities, notably the "8BITMIME" extension
+[8BITMIME].  8BITMIME SHOULD be supported by SMTP servers. However, it MUST
+not be construed as authorization to transmit unrestricted eight bit
+material.  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 [ABNF]. Metalanguage
+terms used in running text are surrounded by pointed brackets (e.g.,
+<CRLF>) for clarity.
+
+2.4.2 Command and Reply Syntax
+
+The commands consist of a command verb followed by an argument field.
+Command verbs are four alphabetic characters and are case insensitive.
+
+This also applies to any symbols representing parameter values, such as
+"TO" or "to" for the forward-path.  Command verbs and the argument fields
+are separated by one or more spaces.  However, case is important in the
+local-part within the reverse-path and forward-path arguments.  In
+particular, for some hosts the user "smith" is different from the user
+"Smith".
+
+A few SMTP servers, in violation of this specification (and RFC 821)
+require that command verbs and certain argument text (such as the
+forward-path and reverse-path in RCPT and MAIL commands) be encoded by
+clients in upper case. Implementations MAY wish to employ this encoding to
+accommodate those servers.
+
+The argument field consists of a variable length character string ending
+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.
+
+
+3. The SMTP Procedures: An Overview
+
+This section contains descriptions of the procedures used in SMTP: session
+initiation, the mail transaction, forwarding mail, verifying mailbox names
+and expanding mailing lists, and the opening and closing exchanges.
+Comments on relaying, a note on mail domains, and a discussion of changing
+roles are included at the end of this section.  Several complete scenarios
+are presented in appendix D.
+
+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 [MSGFMT]).
+
+The SMTP protocol allows a server to formally reject a transaction 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 welcoming message and the client has received
+it, the client then 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, unable to support service extensions, MAY use HELO
+instead of EHLO.  Servers MUST NOT return the extended EHLO-style response
+to a HELO command.
+
+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").
+
+3.3 Mail Transactions
+
+There are three steps to SMTP mail transactions.  The transaction starts
+with a MAIL command which gives the sender identification.  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 <SP> 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> contains the source mailbox,
+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> can 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.
+
+   RCPT <SP> TO:<forward-path> [ <SP> <rcpt-parameters> ] <CRLF>
+
+This command gives a forward-path (normally a mailbox and domain)
+identifying one recipient.  If accepted, the SMTP server returns a 250 OK
+reply and stores the forward-path.  If the 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).  This step of the procedure can be repeated
+any number of times.
+
+The <forward-path> can contain more than just a mailbox.  Historically, the
+<forward-path> can be 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 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 RCPT TO appears without a
+previous MAIL FROM, 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).
+
+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 data.  If
+accepted, the SMTP server returns a 250 OK reply. The DATA command can fail
+in only two ways:
+
+ - If there was no MAIL FROM, or no RCPT TO, command, or all such commands
+   were rejected, the server MAY return a "command out of sequence" (503)
+   reply.  If that 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), or if resources were unavailable.
+
+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.  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 RFC 822 format is being used, the mail data include the memo header
+items such as Date, Subject, To, Cc, From [MSGFMT].  Server SMTP systems
+SHOULD NOT reject messages based on perceived defects in the RFC 822 or
+MIME [RFC-MIME] message header or message body.  In particular, they MUST
+NOT reject messages in which the numbers of Resent- 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 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
+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) reply code from RCPT TO
+are deprecated: Servers SHOULD NOT provide that service or return
+that code.
+
+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 MUST support VRFY and SHOULD
+support EXPN (however, see section 3.5.2 and 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
+
+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
+response 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 as described in [RFC-REPLY], 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 of one mailbox.
+If a request is made to verify 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 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 normally include the mailbox name.
+"<local-part@domain>", where "domain" is a fully qualified domain name,
+MUST appear in the syntax.  In exceptional circumstances, free-form text
+MAY be returned.  In order to facilitate parsing by both computers 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 MUST support VRFY and SHOULD support 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.  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, they MUST be listed as service extensions in an EHLO
+response, if they are supported.
+
+3.5.3 Meaning of VRFY or EXPN Success Response
+
+A server MUST NOT return a 220 code in response to a VRFY or EXPN command
+unless it has actually verified the address.  In particular, a server MUST
+NOT return 220 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 of VRFY is required and EXPN is strongly recommended.
+Hence, implementations that return 500 or 502 for VRFY are not in
+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 discussed in section 2.1 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.
+
+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, both for hosts (typically with MX and CNAME DNS records) and
+for mailboxes (various types of local host aliases), has made it nearly
+impossible for these strategies to work, and mail systems SHOULD NOT
+attempt them.
+
+3.6 Domains
+
+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 A RRs (as discussed in section 5) are permitted, as are CNAME
+RRs whose targets can be resolved, in turn, to MX or A RRs.  Local
+nicknames or unqualified names MUST NOT be used.  There are two exceptions
+to the rule requiring FQDNs:
+
+ - The domain name given in the EHLO command MUST BE either a primary host
+   name (a domain name that resolves to an A RR) or, if the host has no
+   name, an address literal as described in section 4.1.1.1.
+
+ - The reserved mailbox name "postmaster" may be used in a RCPT TO command
+   without domain qualification (see section 4.1.1.3) and MUST be accepted
+   if so used.
+
+3.7 Relaying
+
+In general, the availability of Mail eXchanger records in the domain name
+system [RFC-DNS] makes the use of explicit source routes in the Internet
+mail system unnecessary.  Many historical problems with their
+interpretation 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, they are
+also permitted to 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.
+
+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 relay mail to a particular address for policy
+reasons, a 571 response MAY be returned.
+
+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-NOTARY1]) 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.  A MAIL command with a null reverse-path appears as
+follows:
+
+   MAIL FROM:<>
+
+As discussed in section 2.4.1, a relay SMTP has no need to inspect or act
+upon the headers or body of the message data and MUST NOT do so except
+to add its own "Received:" header (section 4.4) and to perform simple
+counting of the number of "Received:" headers in a message (section 6.2).
+
+3.8 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.8, 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.8.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 2.4.1
+
+Other mail systems gatewayed to the Internet often use a subset of RFC-822
+headers 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.  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).
+
+3.8.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.
+
+Received: 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 fields arising in non-SMTP
+environments, receiving systems MUST NOT reject mail based on the format of
+a trace field and SHOULD be extremely robust in the light of unexpected
+information or formats in those fields.
+
+The gateway SHOULD indicate the environment and protocol in the "via"
+clauses of Received field(s) that it supplies.
+
+3.8.3 Addresses in Gatewaying
+
+>From the Internet side, the gateway SHOULD accept all valid address formats
+in SMTP commands and in RFC-822 headers, and all valid RFC-822 messages.
+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.8.4 Other Header Fields in Gatewaying
+
+The gateway MUST ensure that all header fields of a message that it
+forwards into the Internet meet the requirements for Internet mail.  In
+particular, all addresses in "From:", "To:", "Cc:", etc., fields MUST be
+transformed (if necessary) to satisfy RFC-822 syntax, MUST reference only
+fully-qualified domain names, and MUST be effective and useful for sending
+replies.  3.8.5 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
+return path from the SMTP envelope, not to the sender listed in the "From:"
+field (or other fields) of the RFC-822 message.
+
+3.8.5 Envelopes in Gatewaying
+
+Similarly, when forwarding a message from another environment into the
+Internet, the gateway SHOULD set the envelope return path 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.9 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 except:
+
+ - After receiving a QUIT command and responding with a 221 reply.
+
+ - After detecting the need to shutdown the SMTP service and returning a
+   421 response code.  This response code can be issued after the server
+   receives any command or, if necessary, asynchronously from command
+   receipt (on the assumption that the client will receive it after the
+   next command is issued).
+
+In particular, a server that closes connections in response to commands
+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 which 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.
+
+3.10 Mailing Lists and Aliases
+
+An SMTP-capable host SHOULD support both the alias and the list form 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 (see [MSGFMT]) MUST be left unchanged; in particular, the
+"From" field of the message header is unaffected.
+
+An important mail facility is a mechanism for multi-destination delivery of
+a single message, by transforming or "expanding" 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.  We
+classify such a pseudo-mailbox as an "alias" or a "list", depending upon
+the expansion rules.
+
+3.10.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.10.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 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.
+
+
+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 are encouraged to tolerate
+trailing white space before the terminating <CRLF>.)  The syntax of the
+local part of a mailbox must conform to receiver site conventions and the
+syntax specified in section 4.1.2.  The SMTP commands are discussed below.
+The SMTP replies are discussed in section 4.2.
+
+A mail transaction involves several data objects which 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 which 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.
+
+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 field 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 available), the
+client SHOULD send an address literal (see section 4.1.3), optionally
+followed by information that will help to identify the client system.
+
+The SMTP server identifies itself to the SMTP client in the connection
+greeting reply and in the response to this command.
+
+A client SMTP SHOULD start an SMTP session by issuing the EHLO command. If
+the SMTP server supports the SMTP service extensions it will give a
+successful response, a failure response, or an error response. If the SMTP
+server, in violation of this specification, does not support any SMTP
+service extensions it will generate an error response.  Older client SMTP
+systems MAY, as discussed above, use HELO (as specified in RFC 821) instead
+of EHLO, and servers MUST support the HELO command and reply properly to
+it.  In any event, a client MUST issue HELO or EHLO before starting a mail
+transaction.
+
+These commands, and a "250 OK" reply to one of them, confirm that both the
+SMTP client and the SMTP server are in the initial state, that is, there is
+no transaction in progress and all state tables and buffers are cleared.
+
+Normally, the response to EHLO will be a multiline reply.  Each line of the
+response contains a keyword and, optionally, one or more parameters.  The
+syntax for a positive response, using the ABNF notation and low-level
+terminals of [ABNF], is:
+
+   ehlo-ok-rsp  ::=      "250"    domain [ <SP> greeting ] <CRLF>
+                  / (    "250-"   domain [ <SP> greeting ] <CRLF>
+                      *( "250-"   ehlo-line                <CRLF> )
+                         "250"    <SP> ehlo-line           <CRLF>    )
+   
+   greeting     ::= 1*<any character other than CR or LF>
+   
+   ehlo-line    ::= ehlo-keyword *( <SP> ehlo-param )
+   
+   ehlo-keyword ::= (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
+                ; syntax and values depend on ehlo-keyword
+
+   ehlo-param   ::= 1*<any CHAR excluding <SP> and all
+                       control characters (US-ASCII 0-31
+                       inclusive)>
+   
+   <<xxx  ALPHA        ::= <any one of the 52 alphabetic characters >>
+   <<                  (A through Z in upper case, and,             >>
+   <<                   a through z in lower case)                  >>
+
+Although EHLO keywords may be specified in upper, lower, or mixed case,
+they MUST always be recognized and processed in a case-insensitive manner.
+This is simply an extension of practices specified in RFC 821 and section
+2.4.1.
+
+4.1.1.2 MAIL (MAIL)
+
+This command is used to initiate a mail transaction in which the mail data
+is delivered to one or more mailboxes.  The argument field contains a
+reverse-path.
+
+The reverse-path consists of the sender mailbox or a list of hosts.  In
+some types of reporting messages for which a reply is likely to cause a
+mail loop (for example, mail delivery and nondelivery notifications), the
+reverse-path may be null (see section 3.7).
+
+This command clears the reverse-path buffer, the forward-path buffer, and
+the mail data buffer; and inserts the reverse-path information from this
+command into the reverse-path buffer.
+
+If service extensions were negotiated, the MAIL command may also carry
+parameters associated with a particular service extension.
+
+Syntax:
+   "MAIL FROM:" Reverse-path  [ <SP> Mail-parameters ]
+or
+   "MAIL FROM:<>" [ <SP> Mail-parameters ]
+
+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 use of this command.
+
+The forward-path normally consists of the required destination mailbox or
+mailboxes.  Sending systems SHOULD not generate the optional list of hosts
+known as a source route.  Receiving systems MUST recognize source route
+syntax but SHOULD strip off the source route specification and utilize the
+domain name associated with the mailbox as if the source route had not been
+provided.
+
+Similarly, relay hosts SHOULD strip or ignore source routes, and names MUST
+NOT be copied into the reverse-path. When mail reaches its ultimate
+destination (the forward-path contains only a destination mailbox), the
+SMTP server inserts it into the destination mailbox in accordance with its
+host mail conventions.
+
+For example, mail received at relay host xyz.com with envelope commands
+
+   MAIL FROM:<userx@y.foo.org>
+   RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org>
+
+will normally be sent directly on to host d.bar.org with envelope commands
+
+   MAIL FROM:<userx@y.foo.org>
+   RCPT TO:<USERC@D.bar.org>
+
+As provided in appendix C, xyz.com MAY also choose to relay the message to
+jkl.org, using the envelope commands
+
+   MAIL FROM:<userx@y.foo.org>
+   RCPT TO:<@jkl.org:userc@d.bar.org>
+
+Of course, since hosts are not required to relay mail at all, xyz.com may
+also reject the message entirely when the RCPT TO command is received,
+using a 550 code (since this is a "policy reason").
+
+If service extensions were negotiated, the RCPT TO command may also carry
+parameters associated with a particular service extension offered by the
+server.  The client MUST NOT transmit parameters other than those
+associated with a service extension offered by the server in its EHLO
+response.
+
+Syntax:
+   "RCPT TO:" Forward-path  [ <SP> Rcpt-parameters ]
+or
+   "RCPT TO:<Postmaster>" [ <SP> Rcpt-parameters ]
+
+4.1.1.4 DATA (DATA)
+
+The receiver 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 (especially the ASCII "Null" character) may cause
+problems and SHOULD be avoided when possible.
+
+The mail data is terminated by a line containing only a period, that is,
+the character sequence "<CRLF>.<CRLF>" (see section 4.5.2).  This is the
+end of mail data indication.  Note that 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 data, ends the DATA command itself.
+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 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.  Errors
+that are diagnosed subsequently MUST be reported in a mail message, as
+discussed in section 4.4 In sending a positive completion reply to the end
+of data indication, the receiver takes full responsibility for the message
+(see section 6.1).
+
+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.
+
+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 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. In other situations, it restores the state to that immediately
+after the most recent EHLO.  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"
+
+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" <SP> String
+
+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.
+
+Syntax:
+   "EXPN" <SP> String
+
+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.
+
+SMTP servers SHOULD support HELP without arguments and MAY support it with
+arguments.
+
+Syntax:
+   "HELP" [ <SP> String ]
+
+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 an OK reply.
+
+This command has no effect on the reverse-path buffer, the forward-path
+buffer, or the mail data buffer.
+
+Syntax:
+   "NOOP" [ <SP> String ]
+
+4.1.1.10 QUIT (QUIT)
+
+This command specifies that the receiver MUST send an 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 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).
+
+Syntax: 
+   "QUIT"
+
+4.1.2 Lower-level Syntax
+
+The syntax of the argument fields of the above commands (using the syntax
+specified in [ABNF] 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
+(section 6) of [ABNF] or in the syntax of [MSGFMT].
+
+   Reverse-path = Path
+
+   Forward-path = Path
+
+   Path = "<" [ A-d-l ":" ] Mailbox ">"
+
+   A-d-l = At-domain *( "," A-d-l )    ; Note that this form, the
+                                 so-called "source route", MUST BE
+                                 accepted, SHOULD NOT be generated,
+                                 and SHOULD be ignored.
+
+   At-domain = "@" Domain
+
+   Mail-parameters = *( <SP> Keyword "=" Argument )
+
+   Rcpt-parameters =  *( <SP> Keyword "=" Argument )
+
+   Keyword  = Ldh-str
+   Argument = Atom
+
+   Domain = sub-domain 1*("." sub-domain) / address-literal
+
+   sub-domain = let-dig *(Ldh-str)
+   address-literal = "[" IPv4-address-literal / 
+                  IPv6-address-literal / General-address-literal "]"
+   IPv4-address-literal = snum 3*3("." snum)
+   IPv6-address-literal = "IPv6" <SP> IPv6-addr-string
+   IPv6-addr-string = String         ; IPv6 address in standard form
+                                       [IPv6AddrSpec].  Since this
+                                       form uses colon characters,
+                                       the String will actually need
+                                       to be quoted in all cases.
+   General-address-literal = Standardized-tag <SP> String
+   Standardized-tag = Ldh-str        ; Specified in a
+                                       standards-track RFC 
+                                       and registered with IANA
+   snum = 1*3Digit                   ; representing a decimal integer
+                                       value in the range 0 through 255 
+   let-dig = Alpha / Digit
+   ldh-str = *( Alpha / Digit / "-" ) let-dig
+
+   Mailbox = Local-part "@" Domain
+
+   Local-part = Dot-string / Quoted-string
+
+   Dot-string = Atom [ "." Atom ]
+
+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 of
+non-ASCII characters (octets with the high order bit set to one) or ASCII
+"control characters" (decimal value 0-31 and 127).  These characters MUST
+NOT be used in MAIL FROM or RCPT TO commands or other commands that require
+mailbox names.
+
+   String = Atom / Quoted-string
+
+   special = <<Msg-fmt-special>> /     [[placeholder, see above]]
+             the control characters (ASCII codes 0 through 31
+             inclusive and 127)
+
+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 field with the comma being the fourth character of the
+field.
+
+Characters outside the set of alphas, digits, and hyphen MUST NOT appear in
+domain names.  In particular, the underscore character is not permitted.
+SMTP servers that receive a command in which illegal character codes have
+been employed, and for which there are no other reasons for rejection, MUST
+reject that command with a 501 response.
+
+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 space, and the address itself, in a format
+specified as part of the IPv6 standards [IPv6AddrString].
+
+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, 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, or 502
+failure replies MUST be returned as appropriate.  The 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 ensure that the domain parameter to the EHLO command
+is a valid principal host name (not a CNAME or MX name) for its host.  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 and supplemental information
+provided that will assist in identifying the client.
+
+An SMTP server MAY verify that the domain name parameter in the EHLO
+command actually corresponds to the IP address of the client. However, the
+server MUST NOT refuse to accept a message if the verification fails: the
+information about verification failure is for logging and tracing only.
+
+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 (or
+a new EHLO) command.  There may be zero or more transactions in a session.
+
+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 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
+cannot be used at any other time in a session, but SHOULD be used by the
+client SMTP to request connection closure, even when no session opening
+command was sent and accepted.
+
+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
+alphanumeric characters) followed by some text.  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 section
+4.2.1).  Only the EHLO, EXPN, and HELP commands are expected to result in
+multiline replies in normal circumstances, however, multiline replies are
+allowed for any command.
+
+In ABNF, server responses are:
+
+  Greeting = "220 " Domain [ SP text ] CRLF
+  Reply-line = Reply-code [ SP text ] CRLF 
+
+where "Greeting" appears only in the 220 response that announces that the
+server is opening its part of the connection.
+
+An SMTP server SHOULD send only the reply codes listed in this document.
+An SMTP server SHOULD use the text shown in the examples whenever
+appropriate.
+
+An SMTP client MUST determine its actions only by the reply code, not by
+the text (except for 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 sender-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.
+
+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 five values for the first digit of the reply code:
+
+1yz   Positive Preliminary reply
+   The command has been accepted, but the requested action is being held in
+   abeyance, pending confirmation of the information in this reply.  The
+   SMTP client should send another command specifying whether to continue
+   or abort the action. Note: unextended SMTP does not have any commands
+   that allow this type of reply, and so does not have continue or abort
+   commands.
+
+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 is encouraged to 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 is discouraged from repeating 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
+   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).
+
+The second digit encodes responses in specific categories:
+
+x0z   Syntax: These replies refer to syntax errors, syntactically correct
+   commands that don't fit any functional category, and unimplemented or
+   superfluous commands.
+
+x1z   Information:  These are replies to requests for information, 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.
+
+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:
+   123-First line
+   123-Second line
+   123-234 text beginning with numbers
+   123 The last line
+
+In many cases the SMTP client then simply needs to search for the reply
+code followed by <SP> at the beginning of a line, and ignore all preceding
+lines.  In a few cases, there is important data for the sender in the reply
+"text".  The sender 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)
+
+   220 <domain> Service ready
+   221 <domain> Service closing transmission channel
+   421 <domain> Service not available, closing transmission channel
+      (This may be a reply to any command if the service knows it
+      must shut down)
+
+   250 Requested mail action okay, completed
+   251 User not local; will forward to <forward-path>
+      (See section 3.4)
+   252 Cannot VRFY user, but will accept message and attempt 
+       delivery
+      (See section 3.5.3)
+   450 Requested mail action not taken: mailbox unavailable
+      (e.g., mailbox busy)
+   550 Requested action not taken: mailbox unavailable
+      (e.g., mailbox not found, no access, or command rejected
+      for policy reasons)
+   451 Requested action aborted: error in processing
+   551 User not local; please try <forward-path>
+      (See section 3.4)
+   452 Requested action not taken: insufficient system storage
+   552 Requested mail action aborted: exceeded storage allocation
+   553 Requested action not taken: mailbox name not allowed
+      (e.g., mailbox syntax incorrect)  
+   571 Address not accepted for policy reasons
+   354 Start mail input; end with <CRLF>.<CRLF>
+   554 Transaction failed (Or, in the case of a connection-opening
+       response, "No SMTP service here")
+
+4.2.3  Reply Codes in Numeric Order
+
+   211 System status, or system help reply
+   214 Help message
+      (Information on how to use the receiver or the meaning of a
+      particular non-standard command; this reply is useful only
+      to the human user)
+   220 <domain> Service ready
+   221 <domain> Service closing transmission channel
+   250 Requested mail action okay, completed
+   251 User not local; will forward to <forward-path>
+      (See section 3.4)
+   252 Cannot VRFY user, but will accept message and attempt 
+      delivery
+      (See section 3.5.3)
+
+   354 Start mail input; end with <CRLF>.<CRLF>
+
+   421 <domain> Service not available, closing transmission channel
+      (This may be a reply to any command if the service knows it
+      must shut down)
+   450 Requested mail action not taken: mailbox unavailable
+      (e.g., mailbox busy)
+   451 Requested action aborted: local error in processing
+   452 Requested action not taken: insufficient system storage
+
+   500 Syntax error, command unrecognized
+      (This may include errors such as command line too long)
+   501 Syntax error in parameters or arguments
+   502 Command not implemented (see section 4.2.4)
+   503 Bad sequence of commands
+   504 Command parameter not implemented
+   550 Requested action not taken: mailbox unavailable
+      (e.g., mailbox not found, no access, or command rejected
+      for policy reasons)
+   551 User not local; please try <forward-path>
+      (See section 3.4)
+   552 Requested mail action aborted: exceeded storage allocation
+   553 Requested action not taken: mailbox name not allowed
+      (e.g., mailbox syntax incorrect)
+   554 Transaction failed  (Or, in the case of a connection-opening
+       response, "No SMTP service here")
+   571 Address not accepted for policy reasons
+
+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:
+
+ - delivering the message (if the recipient mailbox exists), or
+
+ - if attempts to deliver the message fail due to transient conditions,
+   retrying delivery some reasonable number of times at intervals as
+   specified in section 4.5.4.
+
+ - if attempts to deliver the message fail due to permanent conditions, or
+   if repeated attempts to deliver the message fail due to transient
+   conditions, returning appropriate notification to the sender of the
+   original message (using the address in the SMTP MAIL FROM command).
+
+When an SMTP server returns a transient error completion status (4yz) code
+after the DATA command is completed with <CRLF>.<CRLF>, it MUST NOT make
+any further attempt to deliver that message.  The SMTP client retains
+responsibility for 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).  The
+sending user SHOULD be able to interpret the return of a transient or
+permanent failure status as a non-delivery indication.
+
+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 4.1.3 for a discussion of alternatives in these situations.
+
+For example,
+   220 ISIF.USC.EDU Service ready
+or
+   220 mail.foo.com SuperSMTP v 6.1.2 Service ready
+or
+   220 [10.0.0.1] Clueless host service ready
+
+The table below lists alternative success and failure replies for each
+command.  These SHOULD be strictly adhered to: a receiver may substitute
+text in the replies, but the meaning and action implied by the code numbers
+and by the specific command reply sequence cannot be altered.
+
+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.
+
+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.
+
+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, NOOP, RSET) SHOULD return a 501 message if
+   arguments are supplied in the absence of EHLO-advertised extensions.
+
+421  Service shutting down and closing transmission channel
+
+Specific sequences are:
+
+CONNECTION ESTABLISHMENT
+   S: 220
+   E: 554
+EHLO or HELO
+   S: 250
+   E: 504, 550
+MAIL
+   S: 250
+   E: 552, 451, 452, 550, 553
+RCPT
+   S: 250, 251 (but see section 3.4 for discussion of 251)
+   E: 550, 551, 552, 553, 450, 451, 452, 503, 550
+DATA
+   I: 354 -> data -> S: 250
+                     E: 552, 554, 451, 452
+   E: 451, 554, 503
+RSET
+   S: 250
+VRFY
+   S: 250, 251, 252
+   E: 550, 551, 553, 502, 504
+EXPN
+   S: 250, 252
+   E: 550, 500, 502, 504
+HELP
+   S: 211, 214
+   E: 502, 504
+NOOP
+   S: 250
+QUIT
+   S: 221
+
+4.4 Trace Information
+
+When an SMTP server receives a message for delivery or further processing,
+it MUST insert trace ("time stamp" or "Received") information at the
+beginning of the message content, as discussed in section 4.1.1.4.
+
+This line MUST be structured as follows:
+
+ - The FROM field, which MUST be supplied in an SMTP environment, SHOULD
+   contain both (1) the name of the source host as presented in the EHLO
+   command and (2) an address literal containing the IP address of the
+   source, determined from the TCP connection.
+
+ - The ID field MAY contain an "@" as suggested in RFC-822, but this is not
+   required.
+
+ - The FOR field MAY contain a list of <path> entries when multiple RCPT
+   commands have been given.  This may raise some security issues and is
+   usually not desirable; see section 7.2.
+
+An Internet mail program MUST NOT change a Received: line that was
+previously added to the message header.  SMTP servers MUST prepend Received
+lines to messages; they MUST NOT change the order of existing lines or
+insert Received lines in any other location.
+
+As the Internet grows, comparability of Received fields is important for
+detecting problems, especially slow relays.  SMTP servers that create
+Received fields SHOULD use explicit offsets in the dates (e.g., -0800),
+rather than time zone names of any type.  Local time (with an offset) is
+preferred to UT when feasible.  This formulation allows slightly more
+information about local circumstances to be specified.  If UT is needed,
+the receiver need merely do some simple arithmetic to convert the values.
+Use of UT loses information about the time zone-location of the server.  If
+a time zone name is used, 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 world.  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 mail data headers and body [RFC-822].
+
+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 FROM 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.  SMTP servers performing a relay function
+MUST NOT inspect the message data, and especially not to the extent needed
+to determine if Return-path headers are present. SMTP servers making final
+delivery MAY remove Return-path headers before adding their own.
+
+The primary purpose of the Return-path is to designate the address to which
+messages indicating non-delivery or other mail system failures are to be
+sent.  For this to be unambiguous, exactly one return path SHOULD be
+present when the message is delivered.  Systems using RFC 822 syntax with
+non-SMTP transports SHOULD designate an unambiguous address, associated
+with the transport envelope, to which error reports (e.g., non-delivery
+messages) should be sent.
+
+Historical note: Text in RFC 822 that appears to contradict the use of the
+Return-path header (or the envelope MAIL FROM address) as the destination
+for error messages is not applicable on the Internet. The MAIL FROM address
+(as copied into the Return-path) MUST be used as the target of any mail
+containing delivery error messages.
+
+In particular:
+
+ - a gateway from SMTP->elsewhere SHOULD insert a return-path header,
+   unless it is known that the "elsewhere" transport also uses Internet
+   domain addresses and maintains the envelope sender address separately.
+
+ - a gateway from elsewhere->SMTP SHOULD delete any return-path header
+   present in the message, and either copy that information to the SMTP
+   envelope or combine it with information present in the envelope of the
+   other transport system to construct the MAIL FROM part of 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 is preferred when possible.  All
+undeliverable mail notification messages are sent using the MAIL command
+(even if they result from processing the obsolete SEND, SOML, or SAML
+commands) and use a null return path as discussed in section 3.7.
+
+The time stamp line and the return path line are formally defined as
+follows:
+ 
+   Return-path-line = "Return-Path:" FWS Reverse-path <CRLF>
+   
+   Time-stamp-line = "Received:" FWS Stamp <CRLF>
+   
+   Stamp = From-domain By-domain Opt-info ";"  FWS Daytime
+   
+   From-domain = "FROM" FWS Extended-Domain CFWS 
+   
+   By-domain = "BY" FWS Extended-Domain CFWS
+   
+   Extended-Domain = Domain / 
+              ( Domain FWS "(" TCP-info ")" ) /
+              ( Address-literal FWS "(" TCP-info ")"
+    TCP-info = Address-literal / ( Domain FWS Address-literal )
+                   ; Information derived by server from TCP connection, not client EHLO.
+
+   Opt-info = [Via] [With] [ID] [For]
+   
+   Via = "VIA" FWS Link CFWS 
+   
+   With = "WITH" FWS Protocol CFWS 
+   
+   ID = "ID" FWS String / msg-id CFWS 
+   
+   For = "FOR" FWS 1*( Path / Mailbox ) CFWS 
+   
+   Link = <<>> / Addtl-Link
+   Addtl-Link = Atom       ; Additional standard names for links are
+                             registered with the Internet Assigned
+                             Numbers Authority (IANA).
+                             SMTP servers SHOULD NOT use unregistered
+                             names. 
+   Protocol = "ESMTP" / "SMTP" / Attdl-Protocol
+   Attdl-Protocol = Atom    ; Additional standard names for protocols
+                              are registered with the Internet Assigned
+                              Numbers Authority (IANA).  SMTP servers
+                              SHOULD NOT use unregistered names.
+   
+   Daytime =  FWS [ day-of-week "," FWS ] Date FWS Time
+   
+   Date = DD FWS Mon FWS YYYY
+          ; Note that the earlier form, which permits two-digit years, has
+            been deprecated.  SMTP systems MUST use four-digit years.
+   
+   Time = HH ":" MM ":" SS  FWS  Zone
+   
+   DD = 1*2Digit           ; the one or two digit integer day of the
+                             month in the range 1 to 31.
+   
+   Mon = "JAN" | "FEB" | "MAR" | "APR" | "MAY" | "JUN" |
+                "JUL" | "AUG" | "SEP" | "OCT" | "NOV" | "DEC"
+   
+   YYYY = 4*4Digit         ; the four decimal integer year in the range
+                             0000 to 9999. 
+   
+   HH = 2*2Digit           ; the two decimal digit hour of the day in
+                             the range 00 to 24.
+   
+   MM = 2*2Digit            ; the two decimal digit integer minute of the hour
+                              in the range 00 to 59.
+   
+   SS = 2*2Digit [ "." 1*Digit ]
+                            ; the two decimal digit integer second of the
+                              minute in the range 00 to 59, with
+                              optional fractional seconds.
+   
+   Zone = ( "+" / "-" ) 4*4Digit [ <SP> "(" String ")" ]
+                            ; A four digit, signed time zone offset,
+                              such as -0500 for US Eastern Standard
+                              Time.  This may be supplemented by a time
+                              zone name in parentheses, e.g., "-0800
+                              (PDT)". Note that there is no default;
+                              time zone information is required and
+                              MUST be supplied.
+                               
+4.5 Additional Implementation Issues
+
+4.5.1 Minimum Implementation
+
+In order to make SMTP workable, the following minimum implementation is
+required for all receivers. The following commands MUST be supported to
+conform to this specification:
+   EHLO
+   HELO
+   VRFY
+   MAIL
+   RCPT
+   DATA
+   RSET
+   NOOP
+   QUIT
+
+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 TO commands which 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.  This requirement does not imply that SMTP systems must
+deliver Postmaster mail in particular cases (e.g., problematic origin
+addresses) in which they have substantive reasons for not doing so.
+
+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:
+
+ - Before sending a line of mail text, the SMTP client checks the first
+   character of the line.  If it is a period, one additional period is
+   inserted at the beginning of the line.
+
+ - When a line of mail text is received by the SMTP server, it checks the
+   line.  If the line is composed of a single period, it is treated as the
+   end of mail indicator.  If the first character is a period and there are
+   other characters on the line, the first character is deleted.
+
+The mail data may contain any of the 128 ASCII characters.  All characters
+are to be delivered to the recipient's mailbox, including spaces, vertical
+and horizontal tabs, and other control characters.  If the transmission
+channel provides an 8-bit byte (octets) data stream, the 7-bit ASCII codes
+are transmitted right justified in the octets, with the high order bits
+cleared to zero.  See 3.7 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 or store data in records rather
+than strings.  If such transformations are necessary, they MUST be
+reversible, especially if such transformations are applied to mail being
+relayed.
+
+4.5.3 Sizes and Timeouts
+
+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-X400]
+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 which
+impose no limits on the length of these objects should be used.
+
+local-part
+   The maximum total length of a user name or other local-part is 64
+   characters.
+
+domain
+   The maximum total length of a domain name or number is 255 characters.
+
+path
+   The maximum total length of a reverse-path or forward-path is 256
+   characters (including the punctuation and element separators).
+
+command line
+   The maximum total length of a command line including the command word
+   and the <CRLF> is 512 characters.  SMTP extensions may be used to
+   increase this limit.
+
+reply line
+   The maximum total length of a reply line including the reply code and
+   the <CRLF> is 512 characters.  More information may be conveyed through
+   multiple-line replies.
+
+text line
+   The maximum total length of a text line including the <CRLF> is 1000
+   characters (not counting the leading dot duplicated for transparency).
+   This number may be increased by the use of SMTP Service Extensions.
+
+message content
+   The maximum total length of a message content (including any message
+   headers as well as the message body) MUST BE at least 64K octets. Since
+   the introduction of multimedia mail [RFC-MIME], 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 ([RFC-SIZE]),
+   and SMTP client systems that will send large messages SHOULD utilize it
+   when possible.
+
+recipients buffer
+   The minimum total number of recipients that must be buffered is 100
+   recipients. Rejection of messages (for excessive recipients) with fewer
+   than 100 RCPT TO commands is a violation of this specification.  The
+   general principle that relaying SMTP servers MUST NOT, and delivery SMTP
+   servers SHOULD NOT, perform validation tests on message headers suggests
+   that rejecting a message based on the total number of recipients shown
+   in header fields is to be discouraged.  A server which imposes a limit
+   on the number of recipients MUST behave in an orderly fashion,  such as
+   to reject additional addresses over its limit rather than silently
+   discarding addresses previously accepted.  A client that needs to
+   deliver a message containing over 100 RCPT TO commands SHOULD be
+   prepared to transmit in 100-recipient "chunks" if the server declines to
+   accept more than 100 recipients in a single message.
+
+Errors 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.
+
+[RFC-821] incorrectly listed the error where an SMTP server exhausts its
+implementation limit on the number of RCPT TO 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 addresses will be
+removed from the SMTP client's queue.  When the client attempts
+retransmission of those addresses which received 452 responses, at least
+100 of these will be able to fit in the SMTP server's recipients buffer.
+Each retransmission attempt which 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 TO
+commands and this limit is exhausted, it MUST use a response code of 452.
+If the server has a configured site-policy limitation on the number of RCPT
+TO commands, it MAY instead use a 5XX response code.
+
+In order to interoperate with SMTP servers implementing an older version of
+the protocol, SMTP clients MAY treat a 552 code obtained in response to an
+RCPT command as if it were a 452 response code, especially after some RCPT
+commands have already been accepted in the same mail transaction.
+
+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:
+
+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.
+
+MAIL Command: 5 minutes
+
+RCPT Command: 5 minutes
+   A longer timeout is required if processing of mailing lists and aliases
+   is not deferred until after the message was accepted.
+
+DATA Initiation: 2 minutes
+   This is while awaiting the "354 Start Input" reply to a DATA command.
+
+Data Block: 3 minutes
+   This is while awaiting the completion of each TCP SEND call transmitting
+   a chunk of data.
+
+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.
+
+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 Queuing 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 never send error messages in
+response to error messages.
+
+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.
+
+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.  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 that discussed in [RFC-ETRN].
+
+The strategy may be further modified as a result of multiple addresses per
+host (see below) to optimize delivery time vs. 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 MAIL FROM MUST NOT be
+cached.
+
+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.
+Implementation of this efficiency feature is strongly encouraged.
+
+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 at
+all times.  This requires the support of multiple incoming TCP connections
+for SMTP.  Some limit MAY be imposed.
+
+As discussed above, when the SMTP server receives mail from a particular
+host address, it could notify the SMTP client to retry any mail pending for
+that host address.
+
+
+5. Address Resolution and Mail Handling
+
+Once an SMTP client lexically identifies a domain to which mail will be
+delivered for processing (as described in sections 3.6 and 3.7), a DNS
+lookup is performed to resolve the domain name (see [RFC-DNS]).  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 and, due to a history of problems, are generally discouraged.
+The lookup first attempts to locate an MX record associated with the name.
+If a CNAME record is found instead, the resulting name is processed as if
+it were the initial name.  If no MX records are found, but an A RR is
+found, the A RR is treated as if it was associated with an implicit MX RR,
+with a preference of 0, pointing to that host.  If one or more MX RRs are
+found for a given name, SMTP systems MUST NOT utilize any A RRs associated
+with that name unless they are located using the MX RRs; the "implicit MX"
+rule above applies only if there are no MX records present.  If MX records
+are present, but none of them are usable, this situation MUST be reported
+as an error.
+
+When the lookup succeeds, the mapping can result in a list of alternative
+delivery addresses rather than a single address, because of multiple MX
+records, multihoming, or both.  To provide reliable mail transmission, the
+SMTP client MUST be able to try (and retry) each of the relevant addresses
+in this list in order, until a delivery attempt succeeds. However, there
+MAY also be a configurable limit on the number of alternate addresses that
+can be tried.  In any case, a host SHOULD try at least two addresses.
+
+Two types of information is used to rank the host addresses: multiple MX
+records, and multihomed hosts.
+
+Multiple MX records contain a preference indication that SHOULD be used in
+sorting (see below).  Lower numbers are more preferred than higher ones.
+If there are multiple destinations with the same preference and there 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 SMTP MUST try them in the order presented.
+
+Although the capability to try multiple alternative addresses is required,
+specific installations may want to limit or disable the use of alternative
+addresses.  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 a host receives a message with a destination for which it is a
+designated Mail eXchanger, it MAY relay the message (potentially after
+having rewritten the addresses), make final delivery of the message, or
+hand it off using some mechanism outside the SMTP-provided transport
+environment.
+
+If it determines that it should relay the message without rewriting the
+address, it MUST sort the MX records to determine candidates for delivery.
+The records are first ordered by preference, with the lowest-numbered
+records being most preferred.  The relay host MUST then inspect the list
+for any of the names or addresses by which it might be known in mail
+transactions.  If a matching record is found, all records at that
+preference level and higher-numbered ones MUST be discarded from
+consideration.  If there are no records left at that point, it is an error
+condition, and the message MUST be returned as undeliverable.  If records
+do remain, they SHOULD be tried, best preference first, as described above.
+
+
+6. 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.
+
+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 SHOULD be the address from the envelope
+return path (or the Return-Path: line).  However, 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 SHOULD 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 [RFC-1047] for a
+discussion of this problem.
+
+6.2 Loop Detection
+
+Simple counting of the number of "Received:" headers 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.3 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 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 [RFC-POP2, RFC-POP3,
+RFC-IMAP2, RFC-PCMAIL]. These protocols have encouraged the use of SMTP as
+a posting 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]).  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.
+
+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 protocol:
+
+ - Addition of a message-id field when none appears
+
+ - Addition of a date, time or time zone when none appears
+
+ - Correction of addresses to proper FQDN format
+
+The less 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.
+
+In all cases, properly-operating clients supplying correct information are
+preferred to corrections by the SMTP server. In all cases, documentation of
+actions performed by the servers (in trace fields and/or header comments)
+is strongly encouraged.
+
+
+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 can be provided in the MOSS framework [RFC-MOSS].
+
+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, unless they are accompanied by careful handoffs of responsibility
+in a carefully-designed trust environment, they remain inherently weaker
+than end-to-end mechanisms which 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 MAIL FROM 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 or in which error (or normal) replies
+should be directed to a special address. (Systems that provide convenient
+ways for users to alter these fields on a per-message basis should attempt
+to establish a primary and permanent mailbox address for the user so that
+Sender fields within the message data can be generated sensibly.)
+
+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 an ignorant user who is trying to fake mail.
+
+7.2 "Blind" Copies
+
+Addresses that do not appear in the message headers may appear in the RCPT
+TO 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 TO command
+arguments into the headers, either as part of trace headers or as
+informational or private-extension headers.  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 TO command.
+
+There is no inherent relationship between either "reverse" (MAIL FROM, SAML
+FROM, etc.) or "forward" (RCPT TO) addresses in the SMTP transaction
+("envelope") and the addresses in the headers.  Receiving systems SHOULD
+NOT attempt to deduce such relationships and use them to alter the headers
+of the message for delivery.  The popular "Apparently-to" header is a
+violation of this principle and SHOULD NOT be used.
+
+7.3 VRFY, EXPN, and Security
+
+As discussed in section 3.5, individual sites may want to disable one or
+both VRFY or EXPN for security reasons.  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.
+
+Within the last few years, the contents of mailing lists have become
+popular as an address information source for so-called "spammers." The use
+of EXPN to "harvest" addresses has increased as list administrators have
+installed protections against inappropriate uses of the lists themselves.
+Implementations SHOULD still provide support for EXPN, but sites SHOULD
+carefully evaluate the tradeoffs. As authentication mechanisms are
+introduced into SMTP, some sites may choose to make EXPN available only to
+authenticated requestors.
+
+7.4 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 useful information to 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 are strongly encouraged to minimally provide
+for making type and version information available in some way to other
+network hosts.
+
+7.5 Information Disclosure in Trace Fields
+
+In some circumstances, such as when mail originates from within a LAN whose
+hosts are not directly from the public Internet, trace ("Received") 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.6 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.
+
+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, MAIL FROM,
+or RCPT TO as appropriate.
+
+
+8. IANA Considerations
+
+IANA is <<requested>> to set up three registries.  The first 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.
+
+The second registry consists of "tags" that identify forms of domain
+literals other than those for IPv4 addresses (specified in RFC 821 and in
+this document) and IPv6 addresses (specified in this document).  Additional
+literal types require standardization before being used; none are
+anticipated at this time.
+
+The third, 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") 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.
+
+
+9. References
+
+[8BITMIME] J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker, "SMTP
+Service Extension for 8bit-MIMEtransport", RFC 1652, 07/18/1994.
+
+[ABNF] Crocker, D., P. Overell, Eds., "Augmented BNF for Syntax
+Specifications: ABNF", RFC 2234, November 1997.
+
+[IPv6AddrString] Hinden, R and S. Deering, Eds. "IP Version 6 Addressing
+Architecture", RFC 1884, December 1995.
+
+[MSGFMT] P. Resnick, Work in progress, draft-ietf-drums-msg-fmt-05.txt,
+August, 1998
+
+[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text
+Messages", RFC 822, Department of Electrical Engineering, University of
+Delaware, August 1982.
+
+[RFC-974] C. Partridge, "Mail routing and the domain system", RFC 974,
+01/01/1986
+
+[RFC-1047] C. Partridge, "Duplicate messages and SMTP", RFC 1047,
+02/01/1988.
+
+[RFC-1123] R. Braden, "Requirements for Internet hosts - application and
+support", 10/01/1989
+
+[RFC-BDAT] G. Vaudreuil, "SMTP Service Extensions for Transmission of Large
+and Binary MIME Messages", RFC 1830, 08/16/1995.
+
+[RFC-DNS] P. Mockapetris, "Domain names - implementation and
+specification", RFC 1035 and P. Mockapetris, "Domain names - concepts and
+facilities", RFC 1034. (STD 13)
+
+[RFC-ETRN] J. De Winter, "SMTP Service Extension for Remote Message Queue
+Starting", RFC 1985, 08/14/1996.
+
+[RFC-IMAP2] M. Crispin, "Interactive Mail Access Protocol - Version 2", RFC
+1176, 08/20/1990.
+
+[RFC-IMAP4] M. Crispin, "Internet Message Access Protocol - Version 4", RFC
+2060, 12/04/1996.
+
+[RFC-INTLHDR] K. Moore, "MIME (Multipurpose Internet Mail Extensions) Part
+Three: Message Header Extensions for Non-ASCII Text", RFC 2047, 12/02/1996.
+
+[RFC-MIME] N. Freed, N. Borenstein, "Multipurpose Internet Mail Extensions
+(MIME) Part One: Format of Internet Message Bodies", RFC 2045, 12/02/1996.
+
+[RFC-MOSS] S. Crocker, N. Freed, J. Galvin, S. Murphy, "MIME Object
+Security Services", RFC 1848, 10/03/1995.
+
+[RFC-NOTARY1] K. Moore, "SMTP Service Extension for Delivery Status
+Notifications", RFC 1891, 01/15/1996.
+
+[RFC-NOTARY2] K. Moore, G. Vaudreuil, "An Extensible Message Format for
+Delivery Status Notifications", RFC 1894, 01/15/1996.
+
+[RFC-PCMAIL] M. Lambert, "PCMAIL: A distributed mail system for personal
+computers", RFC 1056, 06/01/1988.
+
+[RFC-PIPELINE] N. Freed, A. Cargille, "SMTP Service Extension for Command
+Pipelining", RFC 1854, 10/04/1995.
+
+[RFC-POP2] M. Butler, D. Chase, J. Goldberger, J. Postel, J. Reynolds,
+"Post Office Protocol - version 2", RFC 937, 02/01/1985
+
+[RFC-POP3] J. Myers, M. Rose, "Post Office Protocol - Version 3", RFC 1930,
+5/14/96 (Std 53).
+
+[RFC-REPLY] G. Vaudreuil, "Enhanced Mail System Status Codes", RFC 1893,
+01/15/1996.
+
+[RFC-SIZE] J. Klensin, N. Freed, K. Moore, "SMTP Service Extension for
+Message Size Declaration", RFC 1870, 11/06/1995. (STD 10)
+
+[RFC-X400] S. Hardcastle-Kille, "Mapping between X.400(1988) / ISO 10021
+and RFC 822", RFC 1327, 05/18/1992.
+
+[SMTPEX] J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker, "SMTP
+Service Extensions", RFC-1869, 11/06/1995. (STD 10)
+
+[TCP] Postel, J., ed., "Transmission Control Protocol - DARPA Internet
+Program Protocol Specification", RFC 793, USC/Information Sciences
+Institute, NTIS AD Number A111091, September 1981.
+
+[US-ASCII] United States of America Standards Institute (now American
+National Standards Institute), X3.4, 1968, "USA Code for Information
+Interchange". ANSI X3.4-1968 has been replaced by newer versions with
+slight modifications, but the 1968 version remains definitive for the
+Internet.
+
+
+10. Editor's Address
+
+John C. Klensin
+MCI Communications
+800 Boylston St., 7th floor
+Boston, MA 02199
+USA
+Email: Klensin@mci.net
+Phone: +1 617 960 1011
+Fax:   +1 617 960 1009
+
+
+11. Acknowledgments
+
+Many people worked long and hard on the many iterations of this document.
+There was wide-ranging debate on the mailing list about many technical
+issues, and many contributors helped form the wording in this
+specification. The hundreds of participants in the many discussions since
+RFC 821 was produced are too numerous to mention, but they all helped this
+document become what it is.
+
+
+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, but not in SMTP commands or responses.
+
+
+B. Generating SMTP Commands from RFC 822 Headers
+ 
+Some systems use RFC 822 headers (only) in a mail submission protocol, or
+otherwise generate SMTP commands from RFC 822 headers 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 a mail envelopes is not separated early in
+processing from header information (and kept separate).
+
+It is recommended that the UA provide its initial 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 fields SHOULD then be removed from the
+   headers.  Once this process is completed, the remaining headers SHOULD
+   be checked to verify that at least one To:, Cc:, or Bcc: header remains.
+   If none do, then a bcc: header with no additional information SHOULD be
+   inserted as specified in [MSGFMT].
+
+2. The return address in the MAIL command SHOULD, if possible, be derived
+   from the system's identity for the submitting (local) user. And the From
+   header field otherwise.  If there is a system identity available, it
+   SHOULD also be copied to the Sender header field if it is different from
+   the address in the From header field.  (Any Sender field that was
+   already there SHOULD be removed.)  Systems may provide a way for
+   submitters to override the envelope return address, but may want to
+   restrict its use to privileged users.  This will not prevent mail
+   forgery, but may lessen its incidence; see section 7.1.
+
+When an MTA is being used in this way, it bears responsibility for ensuring
+that the message being transmitted is valid.  The mechanisms for checking
+that validity, and for handling (or returning) messages that are not valid
+at the time of arrival, are part of the MUA-MTA interface and not covered
+by this specification.
+
+A submission protocol based on Standard RFC 822 information alone MUST NOT
+be used to gateway a message from a foreign (non-SMTP) mail system into an
+SMTP environment.  Additional information to construct an envelope must
+come from some source in the other environment, whether supplemental
+headers or the foreign system's envelope.
+
+Attempts to gateway messages using only their header "to" and "cc" fields,
+have repeatedly caused mail loops and other behavior adverse to the proper
+functioning of the Internet mail environment.  These problems have been
+especially common when the message originates from an Internet mailing list
+and is distributed into the foreign environment using envelope information.
+When these messages are then processed by a header-only remailer, loops
+back to the Internet environment (and the mailing list) are almost
+inevitable.
+
+
+C. Source Routes
+
+The <reverse-path> is a reverse source routing list of hosts and a source
+mailbox.  The first host in the <reverse-path> SHOULD be the host sending
+the MAIL FROM command.  Similarly, the <forward-path> may be a source
+routing lists of hosts and a destination mailbox. However, in general, the
+<forward-path> SHOULD contain only a mailbox and domain name, relying on
+the domain name system to supply routing information if required.  The use
+of source routes is deprecated; while servers MUST be prepared to receive
+and handle them as discussed in section 3.3 and F.2, clients SHOULD NOT
+transmit them.
+
+For relay purposes, the forward-path may be a source route of the form
+"@ONE,@TWO:JOE@THREE", where ONE, TWO, and THREE MUST BE fully-qualified
+domain names.  This form is used to emphasize the distinction between an
+address and a route.  The mailbox is an absolute address, and the route is
+information about how to get there.  The two concepts should not be
+confused.
+
+If source routes are used, RFC 821 and the text below should be consulted
+for the mechanisms for constructing and updating the forward- and
+reverse-paths.
+
+The SMTP server transforms the command arguments by moving its own
+identifier (its domain name or that of any domain for which it is acting as
+a mail exchanger), if it appears, from the forward-path to the beginning of
+the reverse-path.
+
+Notice that the forward-path and reverse-path appear in the SMTP commands
+and replies, but not necessarily in the message.  That is, there is no need
+for these paths and especially this syntax to appear in the "To:" ,
+"From:", "CC:", etc. fields of the message header. Conversely, SMTP servers
+MUST NOT derive final message delivery information from message header
+fields.
+
+When the list of hosts is present, it is a "reverse" source route and
+indicates that the mail was relayed through each host on the list (the
+first host in the list was the most recent relay).  This list is used as a
+source route to return non-delivery notices to the sender. As each relay
+host adds itself to the beginning of the list, it MUST use its name as
+known in the transport environment to which it is relaying the mail rather
+than that of the transport environment from which the mail came (if they
+are different).
+
+
+D. Scenarios
+
+This section presents complete scenarios of several types of SMTP sessions.
+In the examples, "C:" indicates what is said by the SMTP client, and "S:"
+indicates what is said by the SMTP server.
+
+D.1 A Typical SMTP Transaction Scenario
+
+This SMTP example shows mail sent by Smith at host bar.com, to Jones,
+Green, and Brown at host foo.com.  Here we assume that host bar.com
+contacts host foo.com directly.  The mail is accepted for Jones and Brown.
+Green does not have a mailbox at host foo.com.
+
+   S: 220 foo.com Simple Mail Transfer Service Ready
+   C: EHLO bar.com
+   S: 250-foo.com greets bar.com
+   S: 250-8BITMIME
+   S: 250-SIZE
+   S: 250-DSN
+   S: 250 HELP
+   C: MAIL FROM:<Smith@bar.com>
+   S: 250 OK
+   C: RCPT TO:<Jones@foo.com>
+   S: 250 OK
+   C: RCPT TO:<Green@foo.com>
+   S: 550 No such user here
+   C: RCPT TO:<Brown@foo.com>
+   S: 250 OK
+   C: DATA
+   S: 354 Start mail input; end with <CRLF>.<CRLF>
+   C: Blah blah blah...
+   C: ...etc. etc. etc.
+   C: .
+   S: 250 OK
+   C: QUIT
+   S: 221 foo.com Service closing transmission channel
+
+D.2 Aborted SMTP Transaction Scenario
+
+   S: 220 foo.com Simple Mail Transfer Service Ready
+   C: EHLO bar.com
+   S: 250-foo.com greets bar.com
+   S: 250-8BITMIME
+   S: 250-SIZE
+   S: 250-DSN
+   S: 250 HELP
+   C: MAIL FROM:<Smith@bar.com>
+   S: 250 OK
+   C: RCPT TO:<Jones@foo.com>
+   S: 250 OK
+   C: RCPT TO:<Green@foo.com>
+   S: 550 No such user here
+   C: RSET
+   S: 250 OK
+   C: QUIT
+   S: 221 foo.com Service closing transmission channel
+
+D.3 Relayed Mail Scenario
+
+Step 1  --  Source Host to Relay Host
+
+   S: 220 foo.com Simple Mail Transfer Service Ready
+   C: EHLO bar.com
+   S: 250-foo.com greets bar.com
+   S: 250-8BITMIME
+   S: 250-SIZE
+   S: 250-DSN
+   S: 250 HELP
+   C: MAIL FROM:<JQP@bar.com>
+   S: 250 OK
+   C: RCPT TO:<@foo.com:Jones@XYZ.COM>
+   S: 250 OK
+   C: DATA
+   S: 354 Start mail input; end with <CRLF>.<CRLF>
+   C: Date: Thu, 21 May 1998 05:33:29 -0700
+   C: From: John Q. Public <JQP@bar.com>
+   C: Subject:  The Next Meeting of the Board
+   C: To: Jones@xyz.com
+   C:
+   C: Bill:
+   C: The next meeting of the board of directors will be
+   C: on Tuesday.
+   C:                         John.
+   C: .
+   S: 250 OK
+   C: QUIT
+   S: 221 foo.com Service closing transmission channel
+
+Step 2  --  Relay Host to Destination Host
+
+   S: 220 xyz.com Simple Mail Transfer Service Ready
+   C: EHLO foo.com
+   S: 250 xyz.com is on the air
+   C: MAIL FROM:<@foo.com:JQP@bar.com>
+   S: 250 OK
+   C: RCPT TO:<Jones@XYZ.COM>
+   S: 250 OK
+   C: DATA
+   S: 354 Start mail input; end with <CRLF>.<CRLF>
+   C: Received: from bar.com by foo.com ; Thu, 21 May 1998 05:33:29 -0700
+   C: Date: Thu, 21 May 1998 05:33:22 -0700
+   C: From: John Q. Public <JQP@bar.com>
+   C: Subject:  The Next Meeting of the Board
+   C: To: Jones@xyz.com
+   C:
+   C: Bill:
+   C: The next meeting of the board of directors will be
+   C: on Tuesday.
+   C:                         John.
+   C: .
+   S: 250 OK
+
+   C: QUIT
+   S: 221 foo.com Service closing transmission channel
+
+D.4 Verifying and Sending Scenario
+
+   S: 220 foo.com Simple Mail Transfer Service Ready
+   C: EHLO bar.com
+   S: 250-foo.com greets bar.com
+   S: 250-8BITMIME
+   S: 250-SIZE
+   S: 250-DSN
+   S: 250 HELP
+   C: VRFY Crispin
+   S: 250 Mark Crispin <Admin.MRC@foo.com>
+   C: SEND FROM:<EAK@bar.com>
+   S: 250 OK
+   C: RCPT TO:<Admin.MRC@foo.com>
+   S: 250 OK
+   C: DATA
+   S: 354 Start mail input; end with <CRLF>.<CRLF>
+   C: Blah blah blah...
+   C: ...etc. etc. etc.
+   C: .
+   S: 250 OK
+   C: QUIT
+   S: 221 foo.com Service closing transmission channel
+
+
+E. Other Gateway Issues
+
+In general, gateways between the Internet and other mail systems SHOULD
+attempt to preserve any layering semantics across the boundaries between
+the two mail systems involved.  Gateway- translation approaches that
+attempt to take shortcuts by mapping, (such as envelope information from
+one system to the message headers or body of another) have generally proven
+to be inadequate in important ways.  Systems translating between
+environments that do not support both envelopes and headers and Internet
+mail must be written with the understanding that some information loss is
+almost inevitable.
+
+
+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 is strongly preferred to HELO
+when the server will accept the former.  Servers must continue to accept
+and process HELO in order to support older clients.
+
+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 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.
+
+
+X. Change Summary and Loose Ends (Temporary)
+
+X.1 Change summary
+
+X.1.1 Substantive changes between draft-ietf-drums-smtpupd-00.txt and
+draft-ietf-drums-smtpupd-01.txt
+
+(i) Slightly clarified the discussions of rejection and failure of VRFY
+requests and the associated response codes.
+
+(ii) Slightly clarified the discussion of deferred address validation.
+
+(iii) Removed the IPCE terminology and modified the text in section 4.1.1.2
+to explicitly introduce the "mail gateway" terminology and to begin to
+distinguish a mail gateway from a conventional relay.
+
+(iv) Explicitly noted that SMTP clients for things like POP and IMAP may
+send everything to a single relay for further processing, rather than
+resolving final domain names.
+
+(v) Tightened the RSET discussion.
+
+(vi) Deprecation of 251 only for RCPT (still ok for VRFY)
+
+X.1.2.  Substantive changes between draft-ietf-drums-smtpupd-01.txt and
+draft-ietf-drums-smtpupd-02.txt.
+
+Incorporated additional RFC 1123 material; reorganized several sections for
+clarity.  Added definitions and other previous "loose end" material.
+
+X.1.3.  Substantive changes between draft-ietf-drums-smtpupd-02.txt and
+draft-ietf-drums-smtpupd-03.txt.
+
+(i) Eliminated a number of placeholders and tightened some of the
+definitions in section 2.  Added a few new placeholders for consistency
+checking against other documents.
+
+(ii) Removed the state diagrams, per direction at IETF Montreal.
+
+(iii) Added new section 6.3, an attempt to summarize WG discussions on the
+"posting" versus "delivery" versus "relay" functions of SMTP and on whether
+"fixups" are appropriate in different cases.
+
+(iv) Inserted section 6.1, a minor rewrite of section 5.3.3 of RFC1123.
+
+(v) Added new text to 3.5.5 to discuss the spammer - EXPN relationship.
+
+(vi) The "ASCII requirement" in 4.1.1.4 has been tightened somewhat.
+
+(v) The remaining miscellaneous changes agreed to in Montreal have been
+incorporated except as noted below.
+
+X.1.4.  Substantive changes between draft-ietf-drums-smtpupd-03.txt and
+draft-ietf-drums-smtpupd-04.txt.
+
+Many small changes have been made between these two versions; the list that
+follows is not exhaustive.
+
+(i) To clarify some of the text, definitions have been introduced to
+distinguish among originating, delivery, relay, and gateway SMTP systems.
+
+(ii) The role of LF-terminated lines has been clarified.
+
+(iii) Several changes have been made to clarify the principle that, no
+matter what originating and final delivery systems might do, relay systems
+are not permitted to tamper with message content, even to "fix" headers
+that are determined to be invalid.  If they deem message content to be
+seriously unacceptable, they are encouraged to reject the messages in
+preference to trying to fix them up, but, in general, the theme is "don't
+look/ don't tell".
+
+(iv) A few more definitions have been added to the terminology section, and
+the separate glossary has been eliminated.
+
+(v) I have taken a shot at text to address some of the controversies that
+have raged on the WG mailing list (e.g., sections 7.4 and 7.5). Since there
+was no consensus on most of those topics, I expect that the inserted text
+will satisfy no one except, perhaps, for agreement that saying nothing
+would have been worse.  As a mechanism for moving forward, the text in
+these controversial areas that now appears will be considered "base";
+alterations will be made only if clear consensus emerges.
+
+(vi) Per discussion in Los Angeles, source routes have been further
+deprecated.
+
+(vii) Some of the VRFY/EXPN materials have been moved to "security
+considerations", where they appear to belong, some text has been added, and
+the conformance statements adjusted to reflect what I perceive to be WG
+consensus.
+
+(viii) New MX resolution material has been added to section 5.  While most
+of this material is from RFC974, the rules have been further tightened to
+reflect current practice and experience (974 is written in a somewhat
+speculative fashion for a standard).  In particular, the behavior of trying
+the target host's A RR when MXs existed but all of them were eliminated is
+now prohibited, which seems necessary if another of other ideas being
+recommended or considered are to be feasible.
+
+X.1.5.  Substantive changes between draft-ietf-drums-smtpupd-04.txt and
+draft-ietf-drums-smtpupd-05.txt.
+
+(i) All normative references to RFC 1123 have been removed from the main
+body of the text (some still appear in the appendices where they will
+remain).
+
+(ii) Section 3.5 has been renamed slightly to distinguish between
+"debugging of SMTP implementations" and "debugging of addresses". Better
+terminology would be welcome.
+
+(iii) Error conditions resulting from the DATA command have been clarified.
+
+(iv) Section 4.2 (SMTP replies) has been revised and tightened to reflect
+reality and recent discussion on the list.
+
+(v) Appendix E has been revised a bit and moved into section 4.2.1. Given
+the importance of the "check only first digit" rule, it has to be there.
+
+(vi) Added new text for "no SMTP service supported" to sections 3.1, 4.2.2,
+4.2.3, and 4.3.2.  As noted in 3.1, I'd rather add 521 (which would work
+perfectly with the model) rather than overloading 554.
+
+(vii) The Return-path language in section 4.4 has been cleaned up a bit.
+
+(viii) Tightened the "postmaster" language in 4.5.1, requiring a small
+change to 4.1.1.3.
+
+(ix) I have unilaterally (with a little help from my friends), increased
+some of the size limits.  64 was much too short for a domain name, and the
+DNS limit of 255 (?) has now been inserted. That leaves the return path
+much too short, but I haven't fixed it (maybe that will cause us to get rid
+of them).  We still have a 64 character limit on the local-part, which is
+also *much* too short. Votes for 128 or longer limits accepted.  See
+X.1.6(I)
+
+(x) The text on the "recipients buffer" has been rewritten so that (I hope)
+it makes sense and gives some explicit guidance for how clients and servers
+should proceed if limits are imposed.
+
+X.1.6.  Substantive changes between draft-ietf-drums-smtpupd-05.txt and
+draft-ietf-drums-smtpupd-06.txt.
+
+Most of the changes in this revision have been editorial rather than
+substantive.  Major substantive changes include:
+
+(i)  The language about maximum sizes of SMTP command lines has been
+reworked, per WG mailing list discussion.
+
+(ii)  Several instances of  "Should" have been promoted to "Must" when the
+reasons for the weaker rule seemed to have disappeared.  In particular, the
+requirement that an SMTP implementation support timeouts has become a MUST.
+Also, conformance to this specification requires support of EHLO.  Older
+systems should claim conformance to the [to-be-historical] 821, not this
+specification.
+
+X.1.7.  Substantive changes between draft-ietf-drums-smtpupd-06.txt and
+draft-ietf-drums-smtpupd-07.txt.
+
+(i) Removed "implied RSET" text associated with QUIT, as specified at the
+December 1997 IETF
+
+(ii) Required that servers support EHLO, as specified at the December 1997
+IETF
+
+X.1.8. Substantive changes between draft-ietf-drums-smtpupd-07.txt and
+draft-ietf-drums-smtpupd-08.txt.
+
+This version involves mostly editorial work and cleanup of loose ends.
+
+(iii) Error code presentation has been restructured.
+
+(iv) ABNF conversion done
+
+(v) IPv6 address format inserted per RFC 1884, since we could not get clear
+agreement on an alternative.
+
+(vi) Trivial, silly, examples removed.  Others not yet renumbered.
+
+(vii) 3.5.2 and 4.1.1 altered slightly per Eric Allman's notes.  Eric may
+not like the way I've done either of these change very much: the first now
+makes the distinction between returning an address and returning other
+stuff (which was permitted by -06, but the text wasn't as clear as it
+should have been): if it looks like an address, it needs to be an address.
+Similarly, with 4.1.1, Eric wanted to explicitly permit/legitimize "DATA
+<SP> <CRLF>".  I see several disadvantages to doing that, so have inserted
+language that encourages receivers to tolerate trailing white space, which
+may have the same practical effect.
+
+X.1.8.  Substantive changes between draft-ietf-drums-smtpupd-04.txt and
+draft-ietf-drums-smtpupd-05.txt.
+
+This version is substantially a cleanup, with several clarifications.  In
+addition
+
+(i) New 7.5 added (old one renumbered) to discuss info disclosure through
+Received fields.
+
+(ii) Some character set and minor syntax issues clarified.
+
+(iii) Material on code 571 added (thought this had been done long ago;
+slipped through the cracks)
+
+(iv) Many clarifications added as the result of list discussions and
+suggestions. (v) First serious attempt at putting the syntax into ABNF
+form.  Still not complete.
+
+X.2 Loose ends
+
+<< All issues in this section are still open.>>
+
+(i) The 821 BNF -> ABNF transition needs careful checking.
+
+(ii) Trace field discussion should be checked carefully, particularly since
+the syntax given is slightly different from 821. Provision has been made,
+reflecting some current practice, for (optional) fractional seconds in time
+stamps.
+
+(iii) Remaining syntax differences and redundancies with respect to 822bis
+(see note on section 4.1.2).  Note that the use of "Atom" for extension
+parameter keywords is slightly different from the specification in RFC
+1869.
+
+(vi) We don't have a satisfactory definition for "link" as in "Received:..
+via <link>" and, if there is a registry, I can't find it.  Needs to be
+fixed somehow.
+
+Z.  Full Copyright Statement
+
+Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+This document and translations of it may be copied and furnished to others,
+and derivative works that comment on or otherwise explain it or assist in
+its implementation may be prepared, copied, published and distributed, in
+whole or in part, without restriction of any kind, provided that the above
+copyright notice and this paragraph are included on all such copies and
+derivative works.  However, this document itself may not be modified in any
+way, such as by removing the copyright notice or references to the Internet
+Society or other Internet organizations, except as needed for the purpose
+of developing Internet standards in which case the procedures for
+copyrights defined in the Internet Standards process must be followed, or
+as required to translate it into languages other than English.
+
+The limited permissions granted above are perpetual and will not be revoked
+by the Internet Society or its successors or assigns.
+
+This document and the information contained herein is provided on an "AS
+IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE
+DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
+ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY
+RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
+PARTICULAR PURPOSE.
+
+
+
diff --git a/Documentation/en/I-D/draft-ietf-drums-smtpupd-09.txt b/Documentation/en/I-D/draft-ietf-drums-smtpupd-09.txt
new file mode 100644
index 00000000..8f7aa50b
--- /dev/null
+++ b/Documentation/en/I-D/draft-ietf-drums-smtpupd-09.txt
@@ -0,0 +1,3734 @@
+INTERNET-DRAFT                                John C. Klensin, Editor
+Expires June 1999                         
+December 29, 1998
+                                                        
+
+                  Simple Mail Transfer Protocol 
+
+                 draft-ietf-drums-smtpupd-09.txt
+
+Status of this Memo
+
+This document is an Internet-Draft.  Internet-Drafts are working documents
+of the Internet Engineering Task Force (IETF), its areas, and its working
+groups.  Note that other groups may also distribute working documents as
+Internet-Drafts.
+
+Internet-Drafts are draft documents valid for a maximum of six months and
+may be updated, replaced, or obsoleted by other documents at any time.  It
+is inappropriate to use Internet- Drafts as reference material or to cite
+them other than as "work in progress."
+
+To view the entire list of current Internet-Drafts, please check the
+"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
+Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe),
+ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim),
+ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
+
+[[Sections marked with doubled brackets (e.g., "<<") are explicit
+placeholders or known major loose ends. Please review these ASAP. The
+sections with these placeholders are 4.1.2, 4.4, and X.2.]]
+
+[[Appendix X will be removed before the document is submitted to the
+IESG.]]
+
+[[If consensus is reached on this document, it will be forwarded to the
+IESG with the recommendation that it be processed onto the Standards
+track.]]
+
+Copyright Notice
+
+Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+                           Table of Contents
+
+0. Abstract
+
+1. Introduction
+
+2. The SMTP Model
+2.1 Basic Structure
+2.2 The Extension Model
+2.2.1 Background
+2.2.2 Definition and Registration of Extensions
+2.3 Terminology
+2.3.1 Mail Objects
+2.3.2 Senders and Receivers
+2.3.3 Mail Agents
+2.3.4 Host
+2.3.5 Domain
+2.3.6 Buffer and State Table
+2.3.7 Lines
+2.3.8 Originator, Delivery, Relay, and Gateway Systems
+2.3.9 Message Content and Mail Data
+2.3.10 Mailbox and Address
+2.3.11 Reply
+2.4 Syntax Principles
+2.4.1 General Syntax and Transaction Model
+2.4.2 Command and Reply Syntax
+
+3. The SMTP Procedures: An Overview
+3.1 Session Initiation
+3.2 Client Initiation
+3.3 Mail Transactions
+3.4 Forwarding for Address Correction or Updating
+3.5 Commands for Debugging Addresses
+3.5.1 Overview
+3.5.2 VRFY Normal Response
+3.5.3 Meaning of VRFY or EXPN Success Response
+3.5.4 Semantics and Applications of EXPN
+3.6 Domains
+3.7 Relaying
+3.8 Mail Gatewaying
+3.8.1 Header Fields in Gatewaying
+3.8.2 Received Lines in Gatewaying
+3.8.3 Addresses in Gatewaying
+3.8.4 Other Header Fields in Gatewaying
+3.8.5 Envelopes in Gatewaying
+3.9 Terminating Sessions and Connections
+3.10 Mailing Lists and Aliases
+3.10.1 Alias
+3.10.2 List
+
+4. The SMTP Specifications
+4.1 SMTP Commands
+4.1.1 Command Semantics and Syntax
+4.1.1.1  Extended HELLO (EHLO) or HELLO (HELO)
+4.1.1.2 MAIL (MAIL)
+4.1.1.3 RECIPIENT (RCPT)
+4.1.1.4 DATA (DATA)
+4.1.1.5 RESET (RSET)
+4.1.1.6 VERIFY (VRFY)
+4.1.1.7 EXPAND (EXPN)
+4.1.1.8 HELP (HELP)
+4.1.1.9 NOOP (NOOP)
+4.1.1.10 QUIT (QUIT)
+4.1.2 Lower-level Syntax
+4.1.3 Address Literals
+4.1.4 Order of Commands
+4.1.5 Private-use Commands
+4.2  SMTP Replies
+4.2.1 Reply Code Severities and Theory
+4.2.2 Reply Codes by Function Groups
+4.2.3  Reply Codes in Numeric Order
+4.2.4 Reply Code 502
+4.2.5 Reply Codes After DATA and the Subsequent <CRLF>.<CRLF>
+4.3 Sequencing of Commands and Replies
+4.3.1 Sequencing Overview
+4.3.2 Command-Reply Sequences
+4.4 Trace Information
+4.5 Additional Implementation Issues
+4.5.1 Minimum Implementation
+4.5.2 Transparency
+4.5.3 Sizes and Timeouts
+4.5.4 Queuing Strategies
+4.5.4.1 Sending Strategy
+4.5.4.2 Receiving Strategy
+4.5.5 Messages with a null reverse-path
+
+5. Address Resolution and Mail Handling
+
+6. Problem Detection and Handling
+6.1 Reliable Delivery and Replies by Email
+6.2 Loop Detection
+6.3 Compensating for Irregularities
+
+7. Security Considerations
+7.1 Mail Security and Spoofing
+7.2 "Blind" Copies
+7.3 VRFY, EXPN, and Security
+7.4 Information Disclosure in Announcements
+7.5 Information Disclosure in Trace Fields
+7.6 Scope of Operation of SMTP Servers
+
+8. IANA Considerations
+
+9. References
+
+10. Editors' Addresses
+
+11. Acknowledgments
+
+A. TCP Transport Service
+B. Generating SMTP Commands from RFC 822 Headers 
+C. Source Routes
+D. Scenarios
+E. Other Gateway Issues
+F. Deprecated Features of RFC 821
+X. Change Summary and Loose Ends (Temporary)
+
+
+0. Abstract
+
+This document is a self-contained specification of the basic protocol for
+the Internet electronic mail transport, consolidating and updating:
+
+ - the original SMTP specification of RFC 821 [RFC-821],
+
+ - domain name system requirements and implications for mail transport from
+   RFC 1035 [RFC-DNS] and RFC 974 [RFC-974],
+
+ - the clarifications and applicability statements in RFC 1123 [RFC-1123],
+   and
+
+ - material drawn from the SMTP Extension mechanisms [SMTPEXT].
+
+It replaces RFC 821, RFC 974, and the mail transport materials of RFC 1123.
+However, RFC 821 specifies some features that are not in significant use in
+the Internet of 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 turned up 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 posting' protocol, as recommended for POP [RFC-POP2, RFC-POP3] and
+IMAP [RFC-IMAP4].
+
+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 discusses message headers, message bodies and formats
+and structures for them, and their relationship - [MSGFMT].
+
+
+1. Introduction
+
+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 describe some of them.
+
+An important feature of SMTP is its capability to transport mail across
+transport service environments, usually referred to as "SMTP mail relaying"
+(see section 3.8).  A transport service  environment might consist of the
+mutually-TCP-accessible hosts on  the public Internet, the
+mutually-TCP-accessible hosts on a firewall-isolated private TCP/IP
+Intranet, or hosts in some other LAN or WAN environment utilizing a
+different transport-level protocol.  It is important to realize that
+"transport service environments" are one-to-one with usual definitions of
+"networks".  A process can communicate directly with another process, and
+transport mail using this protocol, through any mutually known and
+connected transport service. Conversely, mail can be relayed or gatewayed
+between processes in two different transport service environments by a
+process known and connected to each of the two transport service
+environments. The Mail eXchanger mechanisms of the domain name system
+[RFC-DNS, and section 5 of this document] allows the identity of hosts
+supporting SMTP relay and gateway processes to be specified.
+
+
+2. The SMTP Model
+
+2.1 Basic Structure
+
+The SMTP design can be pictured as:
+
+               +----------+                +----------+
+   +------+    |          |                |          |
+   | User |<-->|          |      SMTP      |          |
+   +------+    |  Sender- |Commands/Replies| Receiver-|
+   +------+    |   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 role 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 transferred to an SMTP client, and how
+that client determines the domain name(s) to which mail messages are to be
+transferred is a local matter, and is not addressed by this document. In
+some cases, the domain name(s) transferred to, or 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-POP2, RFC-POP3] or IMAP [RFC-IMAP4] protocols, or when the SMTP client
+is inside an isolated transport service environment, the domain name
+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 domain names 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.
+
+The means by which an SMTP client, once it has determined a target domain
+name, 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.
+
+Once the transmission channel is established and initial handshaking
+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 headers 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 extension
+requests such as in [RFC-Pipeline].
+
+Once a given mail message has been transmitted, the client may either
+request that the connection be shut down or may initiate other mail
+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.  This transmission normally occurs 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.
+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.
+
+To provide relay capability, the SMTP server is supplied with the name of
+the ultimate destination host as well as the destination mailbox name.
+Usually, intermediate hosts are determined via the DNS MX record, not by
+explicit "source" routing (see appendices C and 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 added, it must be done in
+a way that permits older implementations to continue working acceptably.
+The extension framework consists of:
+
+ - The SMTP command EHLO, superseding the earlier HELO,
+
+ - a registry of SMTP service extensions,
+
+ - additional parameters to the SMTP MAIL FROM and RCPT TO commands, and
+
+ - optional replacements for verbs defined in this protocol, such as for
+   DATA (see [RFC-BDAT]).
+
+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:
+
+ - the textual name of the SMTP service extension;
+
+ - the EHLO keyword value associated with the extension;
+
+ - the syntax and possible values of parameters associated with the
+   EHLO keyword value;
+
+ - any additional SMTP verbs associated with the extension (additional
+   verbs will usually be, but are not required to be, the same as the
+   EHLO keyword value);
+
+ - any new parameters the extension associates with the MAIL FROM or
+   RCPT TO verbs;
+
+ - a description of how support for the extension affects the behavior
+   of a server and client SMTP; and,
+
+ - the increment by which the extension is increasing the maximum
+   length of the commands MAIL FROM and/or RCPT TO, 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.3 Terminology
+
+Most of the terminology in this document is common in the Internet at the
+time of its writing.  However, the following terms and concepts are used
+in special ways here, or represent differences in terminology between RFC
+821 and this document, and should be understood before reading further.
+These definitions are normative, that is, they contain specifications to
+which SMTP implementations are required to conform.
+
+The terms "MUST" and "SHOULD" (and "MUST NOT" and "SHOULD NOT") are used
+in the same general sense here as in the Host Requirements Standards
+[RFC-1123].  Specifically, "MUST" or "MUST NOT" identify absolute
+requirements for conformance to this specification.  Implementations that
+do not conform to them lie outside the scope of this specification and
+often will not interoperate properly with SMTP implementations that do
+conform.  Implementations that are fully conforming also adhere to all
+"SHOULD" and "SHOULD NOT" requirements.  Implementations that adhere to
+all "MUST" ("MUST NOT") but not to all of these are considered to be
+partially conforming.  Such implementations may interoperate properly with
+fully conforming ones and with each other, but this will typically be the
+case only if great care is taken.  Consequently, an implementation should
+violation "SHOULD" ("SHOULD NOT") requirements only under exceptional and
+well-understood circumstances. "SHOULD" (and sometimes "MUST")
+requirements are often imposed by this specification when experience has
+shown that following such requirements or restrictions leads, in practice,
+to better interoperation, or smoother operation of the Internet email
+infrastructure. As a consequence, some of these statements constitute
+recommended practices, rather than the statistically most common practice
+at the time of this writing.  Statements using "MAY" describe features or
+styles of doing things that may be followed, or not, at the discretion of
+the implementation, normally without causing significant interoperability
+problems.  
+
+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 which error reports
+should be directed); a delivery mode (e.g., deliver to recipient
+mailboxes); one or more recipient addresses; and optional protocol
+extension material.
+
+The SMTP content is sent in the SMTP DATA protocol unit and has two parts:
+the headers and the body. If the content conforms to existing standards,
+the headers form a collection of field/value pairs structured as described
+in [MSGFMT]; the body, if structured, is defined according to MIME
+[RFC-MIME]. The content is textual in nature, expressed using the US-ASCII
+repertoire [US-ASCII]. Although SMTP extensions (such as [8BitMIME]) may
+relax this restriction for the content body, the content headers are always
+encoded using the US-ASCII repertoire. The algorithm defined in
+[RFC-INTLHDR] is used to represent 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
+
+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).
+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
+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 "domain");
+identifying them by numerical address is discouraged.
+
+2.3.5 Domain
+
+A domain (or domain name) consists of one or more dot-separated components,
+each consisting of a sequence of letters, digits, and hyphens.  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-DNS] and section 5.
+
+The domain name, as described in this document and in [RFC-DNS], 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.
+
+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 which 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 Lines
+
+SMTP commands and, unless altered by a service extension, message data, are
+transmitted in "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.
+
+2.3.8 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 hands it to a mail user agent or deposits it in a message
+store which 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.
+
+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 message headers and the possibly-structured message body.
+The MIME specification [RFC-MIME] provides the Standard mechanisms for
+structured message bodies.
+
+2.3.10 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" and, consequently, the local-part is
+interpreted and assigned semantics only by the host specified in the domain
+part of the address.
+
+2.3.11 Reply
+
+An SMTP reply is an acknowledgment (positive or negative) sent from
+receiver to sender 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.
+
+2.4 Syntax Principles
+
+2.4.1 General Syntax and Transaction Model
+
+SMTP commands and replies have a rigid syntax. All commands begin with a
+four letter command verb. All Replies begin with a three digit numeric
+code. In some commands and replies, arguments MUST follow 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
+<SP>. Complete definitions of commands and replies appear in section 4.
+
+Verbs and argument values 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.  This is NOT
+true of a mailbox local-part. 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.  Mailbox domains are
+not case sensitive.  However, exploiting the case sensitivity of
+mailbox local-parts impedes interoperability and is discouraged.
+
+Commands and replies are composed of characters from the ASCII character
+set [US-ASCII]. 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 seven bit transport only.  An originating
+SMTP client which has not successfully negotiated an appropriate extension
+with a particular server 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 ultimate delivery of a severely garbled message
+to the recipient.  Delivery SMTP systems MAY reject ("bounce") such
+messages rather than deliver them.  No sending SMTP system is 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.
+
+Eight-bit message content transmission MAY be requested of the server by a
+client using extended SMTP facilities, notably the "8BITMIME" extension
+[8BITMIME].  8BITMIME SHOULD be supported by SMTP servers. However, it MUST
+not be construed as authorization to transmit unrestricted eight bit
+material.  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 [ABNF]. Metalanguage
+terms used in running text are surrounded by pointed brackets (e.g.,
+<CRLF>) for clarity.
+
+2.4.2 Command and Reply Syntax
+
+The commands consist of a command verb followed by an argument field.
+Command verbs are four alphabetic characters and are case insensitive.
+
+This also applies to any symbols representing parameter values, such as
+"TO" or "to" for the forward-path.  Command verbs and the argument fields
+are separated by one or more spaces.  However, case is important in the
+local-part within the reverse-path and forward-path arguments.  In
+particular, for some hosts the user "smith" is different from the user
+"Smith".
+
+A few SMTP servers, in violation of this specification (and RFC 821)
+require that command verbs and certain argument text (such as the
+forward-path and reverse-path in RCPT and MAIL commands) be encoded by
+clients in upper case. Implementations MAY wish to employ this encoding to
+accommodate those servers.
+
+The argument field consists of a variable length character string ending
+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.
+
+
+3. The SMTP Procedures: An Overview
+
+This section contains descriptions of the procedures used in SMTP: session
+initiation, the mail transaction, forwarding mail, verifying mailbox names
+and expanding mailing lists, and the opening and closing exchanges.
+Comments on relaying, a note on mail domains, and a discussion of changing
+roles are included at the end of this section.  Several complete scenarios
+are presented in appendix D.
+
+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.5.1).
+
+The SMTP protocol allows a server to formally reject a transaction 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 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 which are unable to support service extensions and
+contemporary clients which 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.
+
+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").
+
+3.3 Mail Transactions
+
+There are three steps to SMTP mail transactions.  The transaction starts
+with a MAIL command which gives the sender identification.  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> [ <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> 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> can 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.
+
+   RCPT TO:<forward-path> [ <SP> <rcpt-parameters> ] <CRLF>
+
+This command gives 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 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).  This step of the procedure can be repeated
+any number of times.
+
+The <forward-path> can contain more than just a mailbox.  Historically, the
+<forward-path> can be 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 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 RCPT TO appears without a
+previous MAIL FROM, 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).
+
+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 data.  If
+accepted, the SMTP server returns a 250 OK reply. The DATA command can fail
+in only two ways:
+
+ - If there was no MAIL FROM, or no RCPT TO, command, or all such commands
+   were rejected, the server MAY return a "command out of sequence" (503)
+   reply.  If that 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), or if resources were 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.  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 RFC 822 format is being used, the mail data include the memo header
+items such as Date, Subject, To, Cc, From [MSGFMT].  Server SMTP systems
+SHOULD NOT reject messages based on perceived defects in the RFC 822 or
+MIME [RFC-MIME] message header or message body.  In particular, they MUST
+NOT reject messages in which the numbers of Resent- 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 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 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) reply code from RCPT TO are
+deprecated: Servers SHOULD NOT provide that service or return that code.
+
+
+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 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
+
+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
+response 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-REPLY], 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 of one mailbox.
+If a request is made to verify 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 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 normally include the mailbox name.
+"<local-part@domain>", where "domain" is a fully qualified domain name,
+MUST appear in the syntax.  In exceptional circumstances, free-form text
+MAY be returned.  In order to facilitate parsing by both computers 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.  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, they MUST be listed as service extensions in an EHLO
+response, if they are supported.
+
+3.5.3 Meaning of VRFY or EXPN Success Response
+
+A server MUST NOT return a 220 code in response to a VRFY or EXPN command
+unless it has actually verified the address.  In particular, a server MUST
+NOT return 220 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 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 discussed in section 2.1.  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.
+
+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,
+and mail systems SHOULD NOT attempt them.
+
+3.6 Domains
+
+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 A RRs (as discussed in section 5) are permitted, as are CNAME
+RRs whose targets can be resolved, in turn, to MX or A RRs.  Local
+nicknames or unqualified names MUST NOT be used.  There are two exceptions
+to the rule requiring FQDNs:
+
+ - The domain name given in the EHLO command MUST BE either a primary host
+   name (a domain name that resolves to an A RR) or, if the host has no
+   name, an address literal as described in section 4.1.1.1.
+
+ - The reserved mailbox name "postmaster" may be used in a RCPT TO command
+   without domain qualification (see section 4.1.1.3) and MUST be accepted
+   if so used.
+
+3.7 Relaying
+
+In general, the availability of Mail eXchanger records in the domain name
+system [RFC-DNS] makes the use of explicit source routes in the Internet
+mail system unnecessary.  Many historical problems with their
+interpretation 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, they are
+also permitted to 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.
+
+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 relay mail to a particular address for policy
+reasons, a 550 response SHOULD be returned.
+
+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-NOTARY1]) 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 section 4.5.5 for additional discussion).  A MAIL
+command with a null reverse-path appears as follows:
+
+   MAIL FROM:<>
+
+As discussed in section 2.4.1, a relay SMTP has no need to inspect or act
+upon the headers or body of the message data and MUST NOT do so except
+to add its own "Received:" header (section 4.4) and to perform simple
+counting of the number of "Received:" headers in a message (section 6.2).
+
+3.8 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.8, 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.8.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 2.4.1
+
+Other mail systems gatewayed to the Internet often use a subset of RFC-822
+headers 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.  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).
+
+3.8.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.
+
+Received: 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 fields arising in non-SMTP
+environments, receiving systems MUST NOT reject mail based on the format of
+a trace field and SHOULD be extremely robust in the light of unexpected
+information or formats in those fields.
+
+The gateway SHOULD indicate the environment and protocol in the "via"
+clauses of Received field(s) that it supplies.
+
+3.8.3 Addresses in Gatewaying
+
+>From the Internet side, the gateway SHOULD accept all valid address formats
+in SMTP commands and in RFC-822 headers, and all valid RFC-822 messages.
+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.8.4 Other Header Fields in Gatewaying
+
+The gateway MUST ensure that all header fields of a message that it
+forwards into the Internet meet the requirements for Internet mail.  In
+particular, all addresses in "From:", "To:", "Cc:", etc., fields MUST be
+transformed (if necessary) to satisfy RFC-822 syntax, MUST reference only
+fully-qualified domain names, and MUST be effective and useful for sending
+replies.  3.8.5 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
+return path from the SMTP envelope, not to the sender listed in the "From:"
+field (or other fields) of the RFC-822 message.
+
+3.8.5 Envelopes in Gatewaying
+
+Similarly, when forwarding a message from another environment into the
+Internet, the gateway SHOULD set the envelope return path 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.9 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 except:
+
+ - After receiving a QUIT command and responding with a 221 reply.
+
+ - After detecting the need to shutdown the SMTP service and returning a
+   421 response code.  This response code can be issued after the server
+   receives any command or, if necessary, asynchronously from command
+   receipt (on the assumption that the client will receive it after the
+   next command is issued).
+
+In particular, a server that closes connections in response to commands
+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 which 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.
+
+3.10 Mailing Lists and Aliases
+
+An SMTP-capable host SHOULD support both the alias and the list models of
+address expansion for multiple delivery.  When a message is delivered or
+forwarded to each address of an expanded list 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 (see [MSGFMT]) MUST be left unchanged; in particular, the
+"From" field of the message header 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.10.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.10.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 all of the expanded
+addresses.  The return 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.
+
+
+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 are encouraged to tolerate
+trailing white space before the terminating <CRLF>.)  The syntax of the
+local part of a mailbox must conform to receiver site conventions and the
+syntax specified in section 4.1.2.  The SMTP commands are discussed below.
+The SMTP replies are discussed in section 4.2.
+
+A mail transaction involves several data objects which 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 which 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 field 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 available), the
+client SHOULD send an address literal (see section 4.1.3), optionally
+followed by information that will help to identify the client system.
+
+The SMTP server identifies itself to the SMTP client in the connection
+greeting reply and in the response to this command.
+
+A client SMTP SHOULD start an SMTP session by issuing the EHLO command. If
+the SMTP server supports the SMTP service extensions it will give a
+successful response, a failure response, or an error response. If the SMTP
+server, in violation of this specification, does not support any SMTP
+service extensions it will generate an error response.  Older client SMTP
+systems MAY, as discussed above, use HELO (as specified in RFC 821) instead
+of EHLO, and servers MUST support the HELO command and reply properly to
+it.  In any event, a client MUST issue HELO or EHLO before starting a mail
+transaction.
+
+These commands, and a "250 OK" reply to one of them, confirm that both the
+SMTP client and the SMTP server are in the initial state, that is, there is
+no transaction in progress and all state tables and buffers are cleared.
+
+Normally, the response to EHLO will be a multiline reply.  Each line of the
+response contains a keyword and, optionally, one or more parameters.  The
+syntax for a positive response, using the ABNF notation and low-level
+terminals of [ABNF], is:
+
+   ehlo-ok-rsp  ::=      "250"    domain [ <SP> greeting ] <CRLF>
+                  / (    "250-"   domain [ <SP> greeting ] <CRLF>
+                      *( "250-"   ehlo-line                <CRLF> )
+                         "250"    <SP> ehlo-line           <CRLF>    )
+   
+   greeting     ::= 1*<any character other than CR or LF>
+   
+   ehlo-line    ::= ehlo-keyword *( <SP> ehlo-param )
+   
+   ehlo-keyword ::= (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
+                ; syntax and values depend on ehlo-keyword
+
+   ehlo-param   ::= 1*<any CHAR excluding <SP> and all
+                       control characters (US-ASCII 0-31
+                       inclusive)>
+   
+   ALPHA        ::= any one of the 52 alphabetic characters, i.e.,
+                    (A through Z in upper case, and, a through z in lower
+					case) 
+
+Although EHLO keywords may be specified in upper, lower, or mixed case,
+they MUST always be recognized and processed in a case-insensitive manner.
+This is simply an extension of practices specified in RFC 821 and section
+2.4.1.
+
+4.1.1.2 MAIL (MAIL)
+
+This command is used to initiate a mail transaction in which the mail data
+is delivered to one or more mailboxes.  The argument field contains a
+reverse-path.  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 or a list of hosts.  In
+some types of reporting messages for which a reply is likely to cause a
+mail loop (for example, mail delivery and nondelivery notifications), the
+reverse-path may be null (see section 3.7).
+
+This command clears the reverse-path buffer, the forward-path buffer, and
+the mail data buffer; and inserts the reverse-path information from this
+command into the reverse-path buffer.
+
+If service extensions were negotiated, the MAIL command may also carry
+parameters associated with a particular service extension.
+
+Syntax:
+
+   "MAIL FROM:" Reverse-path  [ <SP> Mail-parameters ]
+
+or
+   "MAIL FROM:<>" [ <SP> Mail-parameters ] 
+
+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 use of this command.
+
+The forward-path normally consists of the required destination mailbox or
+mailboxes.  Sending systems SHOULD not generate the optional list of hosts
+known as a source route.  Receiving systems MUST recognize source route
+syntax but SHOULD strip off the source route specification and utilize the
+domain name associated with the mailbox as if the source route had not been
+provided.
+
+Similarly, relay hosts SHOULD strip or ignore source routes, and names MUST
+NOT be copied into the reverse-path. When mail reaches its ultimate
+destination (the forward-path contains only a destination mailbox), the
+SMTP server inserts it into the destination mailbox in accordance with its
+host mail conventions.
+
+For example, mail received at relay host xyz.com with envelope commands
+
+   MAIL FROM:<userx@y.foo.org>
+   RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org>
+
+will normally be sent directly on to host d.bar.org with envelope commands
+
+   MAIL FROM:<userx@y.foo.org>
+   RCPT TO:<USERC@D.bar.org>
+
+As provided in appendix C, xyz.com MAY also choose to relay the message to
+jkl.org, using the envelope commands
+
+   MAIL FROM:<userx@y.foo.org>
+   RCPT TO:<@jkl.org:userc@d.bar.org>
+
+Of course, since hosts are not required to relay mail at all, xyz.com may
+also reject the message entirely when the RCPT TO command is received,
+using a 550 code (since this is a "policy reason").
+
+If service extensions were negotiated, the RCPT TO command may also carry
+parameters associated with a particular service extension offered by the
+server.  The client MUST NOT transmit parameters other than those
+associated with a service extension offered by the server in its EHLO
+response.
+
+Syntax:
+   "RCPT TO:" Forward-path  [ <SP> Rcpt-parameters ]
+or
+   "RCPT TO:<Postmaster>" [ <SP> Rcpt-parameters ]
+
+4.1.1.4 DATA (DATA)
+
+The receiver 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 (especially the ASCII "Null" character) may cause
+problems and SHOULD be avoided when possible.
+
+The mail data is terminated by a line containing only a period, that is,
+the character sequence "<CRLF>.<CRLF>" (see section 4.5.2).  This is the
+end of mail data indication.  Note that 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 data, ends the DATA command itself.
+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 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.  Errors
+that are diagnosed subsequently MUST be reported in a mail message, as
+discussed in section 4.4 In sending a positive completion reply to the end
+of data indication, the receiver takes full responsibility for the message
+(see section 6.1).
+
+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.
+
+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 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. In other situations, it restores the state to that immediately
+after the most recent EHLO.  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"
+
+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" <SP> String
+
+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.
+
+Syntax:
+   "EXPN" <SP> String
+
+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.
+
+SMTP servers SHOULD support HELP without arguments and MAY support it with
+arguments.
+
+Syntax:
+   "HELP" [ <SP> String ]
+
+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 an OK reply.
+
+This command has no effect on the reverse-path buffer, the forward-path
+buffer, or the mail data buffer.  If a parameter string is specified,
+servers SHOULD ignore it.
+
+Syntax:
+   "NOOP" [ <SP> String ]
+
+
+4.1.1.10 QUIT (QUIT)
+
+This command specifies that the receiver MUST send an 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 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).
+
+Syntax: 
+   "QUIT"
+
+4.1.2 Lower-level Syntax
+
+The syntax of the argument fields of the above commands (using the syntax
+specified in [ABNF] 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
+(section 6) of [ABNF] or in the syntax of [MSGFMT].
+
+   Reverse-path = Path
+
+   Forward-path = Path
+
+   Path = "<" [ A-d-l ":" ] Mailbox ">"
+
+   A-d-l = At-domain *( "," A-d-l )    ; Note that this form, the
+                                 so-called "source route", MUST BE
+                                 accepted, SHOULD NOT be generated,
+                                 and SHOULD be ignored.
+
+   At-domain = "@" Domain
+
+   Mail-parameters = *( <SP> Keyword "=" Argument )
+
+   Rcpt-parameters =  *( <SP> Keyword "=" Argument )
+
+   Keyword  = Ldh-str
+   Argument = Atom
+
+   Domain = sub-domain 1*("." sub-domain) / address-literal
+
+   sub-domain = let-dig *(Ldh-str)
+   address-literal = "[" IPv4-address-literal / 
+                  IPv6-address-literal / General-address-literal "]"
+   IPv4-address-literal = snum 3*3("." snum)
+   IPv6-address-literal = "IPv6 " IPv6-addr-string
+   IPv6-addr-string = String         ; IPv6 address in standard form
+                                       [IPv6AddrSpec].  Since this
+                                       form uses colon characters,
+                                       the String will actually need
+                                       to be quoted in all cases.
+   General-address-literal = Standardized-tag <SP> String
+   Standardized-tag = Ldh-str        ; Specified in a
+                                       standards-track RFC 
+                                       and registered with IANA
+   snum = 1*3Digit                   ; representing a decimal integer
+                                       value in the range 0 through 255 
+   let-dig = Alpha / Digit
+   ldh-str = *( Alpha / Digit / "-" ) let-dig
+
+   Mailbox = Local-part "@" Domain
+
+   Local-part = Dot-string / Quoted-string
+
+   Dot-string = Atom [ "." Atom ]
+
+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 of
+non-ASCII characters (octets with the high order bit set to one) or ASCII
+"control characters" (decimal value 0-31 and 127).  These characters MUST
+NOT be used in MAIL FROM or RCPT TO commands or other commands that require
+mailbox names.
+
+   String = Atom / Quoted-string
+
+   special = <<Msg-fmt-special>> /     [[placeholder, see above]]
+             the control characters (ASCII codes 0 through 31
+             inclusive and 127)
+
+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 field with the comma being the fourth character of the
+field.
+
+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-1015]), characters outside the
+set of alphas, digits, and hyphen MUST NOT appear in domain name labels
+for SMTP clients or servers.  In particular, the underscore character is
+not permitted.  SMTP servers that receive a command in which illegal
+character codes have been employed, and for which there are no other
+reasons for rejection, MUST reject that command with a 501 response.
+
+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 space, and the address itself, in a format
+specified as part of the IPv6 standards [IPv6AddrString].
+
+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, 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, or 502
+failure replies MUST be returned as appropriate.  The 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 ensure that the domain parameter to the EHLO command
+is a valid principal host name (not a CNAME or MX name) for its host.  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 and supplemental information
+provided that will assist in identifying the client.
+
+An SMTP server MAY verify that the domain name parameter in the EHLO
+command actually corresponds to the IP address of the client. However, the
+server MUST NOT refuse to accept a message if the verification fails: the
+information about verification failure is for logging and tracing only.
+
+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 (or
+a new EHLO) 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 it the previous one successfully concluded with
+a successful DATA command, or if the previous one was aborted with a RSET.
+
+If the transaction beginning command argument 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 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
+cannot be used at any other time in a session, but SHOULD be used by the
+client SMTP to request connection closure, even when no session opening
+command was sent and accepted.
+
+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
+alphanumeric 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 section 4.2.1).  Since, in
+violation of this specification, the text is sometimes not sent, clients
+which 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
+circumstances, however, multiline replies are allowed for any command.
+
+In ABNF, server responses are:
+
+  Greeting = "220 " Domain [ SP text ] CRLF
+  Reply-line = Reply-code [ SP text ] CRLF 
+
+where "Greeting" appears only in the 220 response that announces that the
+server is opening its part of the connection.
+
+An SMTP server SHOULD send only the reply codes listed in this document.
+An SMTP server SHOULD use the text shown in the examples whenever
+appropriate.
+
+An SMTP client MUST determine its actions only by the reply code, not by
+the text (except for 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.
+
+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 five values for the first digit of the reply code:
+
+1yz   Positive Preliminary reply
+   The command has been accepted, but the requested action is being held in
+   abeyance, pending confirmation of the information in this reply.  The
+   SMTP client should send another command specifying whether to continue
+   or abort the action. Note: unextended SMTP does not have any commands
+   that allow this type of reply, and so does not have continue or abort
+   commands.
+
+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 is encouraged to 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 is discouraged from repeating 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
+   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).
+
+The second digit encodes responses in specific categories:
+
+x0z   Syntax: These replies refer to syntax errors, syntactically correct
+   commands that don't fit any functional category, and unimplemented or
+   superfluous commands.
+
+x1z   Information:  These are replies to requests for information, 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.
+
+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:
+   123-First line
+   123-Second line
+   123-234 text beginning with numbers
+   123 The last line
+
+In many cases the SMTP client then simply needs to search for the reply
+code followed by <SP> at the beginning of a line, and ignore all preceding
+lines.  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)
+
+   220 <domain> Service ready
+   221 <domain> Service closing transmission channel
+   421 <domain> Service not available, closing transmission channel
+      (This may be a reply to any command if the service knows it
+      must shut down)
+
+   250 Requested mail action okay, completed
+   251 User not local; will forward to <forward-path>
+      (See section 3.4)
+   252 Cannot VRFY user, but will accept message and attempt 
+       delivery
+      (See section 3.5.3)
+   450 Requested mail action not taken: mailbox unavailable
+      (e.g., mailbox busy)
+   550 Requested action not taken: mailbox unavailable
+      (e.g., mailbox not found, no access, or command rejected
+      for policy reasons)
+   451 Requested action aborted: error in processing
+   551 User not local; please try <forward-path>
+      (See section 3.4)
+   452 Requested action not taken: insufficient system storage
+   552 Requested mail action aborted: exceeded storage allocation
+   553 Requested action not taken: mailbox name not allowed
+      (e.g., mailbox syntax incorrect)  
+   354 Start mail input; end with <CRLF>.<CRLF>
+   554 Transaction failed (Or, in the case of a connection-opening
+       response, "No SMTP service here")
+
+4.2.3  Reply Codes in Numeric Order
+
+   211 System status, or system help reply
+   214 Help message
+      (Information on how to use the receiver or the meaning of a
+      particular non-standard command; this reply is useful only
+      to the human user)
+   220 <domain> Service ready
+   221 <domain> Service closing transmission channel
+   250 Requested mail action okay, completed
+   251 User not local; will forward to <forward-path>
+      (See section 3.4)
+   252 Cannot VRFY user, but will accept message and attempt 
+      delivery
+      (See section 3.5.3)
+
+   354 Start mail input; end with <CRLF>.<CRLF>
+
+   421 <domain> Service not available, closing transmission channel
+      (This may be a reply to any command if the service knows it
+      must shut down)
+   450 Requested mail action not taken: mailbox unavailable
+      (e.g., mailbox busy)
+   451 Requested action aborted: local error in processing
+   452 Requested action not taken: insufficient system storage
+
+   500 Syntax error, command unrecognized
+      (This may include errors such as command line too long)
+   501 Syntax error in parameters or arguments
+   502 Command not implemented (see section 4.2.4)
+   503 Bad sequence of commands
+   504 Command parameter not implemented
+   550 Requested action not taken: mailbox unavailable
+      (e.g., mailbox not found, no access, or command rejected
+      for policy reasons)
+   551 User not local; please try <forward-path>
+      (See section 3.4)
+   552 Requested mail action aborted: exceeded storage allocation
+   553 Requested action not taken: mailbox name not allowed
+      (e.g., mailbox syntax incorrect)
+   554 Transaction failed  (Or, in the case of a connection-opening
+       response, "No SMTP service here")
+
+4.2.4 Reply Code 502
+
+Questions have 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:
+
+ - delivering the message (if the recipient mailbox exists), or
+
+ - if attempts to deliver the message fail due to transient conditions,
+   retrying delivery some reasonable number of times at intervals as
+   specified in section 4.5.4.
+
+ - if attempts to deliver the message fail due to permanent conditions, or
+   if repeated attempts to deliver the message fail due to transient
+   conditions, returning appropriate notification to the sender of the
+   original message (using the address in the SMTP MAIL FROM command).
+
+When an SMTP server returns a transient error completion status (4yz) code
+after the DATA command is completed with <CRLF>.<CRLF>, it MUST NOT make
+any further attempt to deliver that message.  The SMTP client retains
+responsibility for 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).  The
+sending user SHOULD be able to interpret the return of a transient or
+permanent failure status as a non-delivery indication.
+
+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 4.1.3 for a discussion of alternatives in these situations.
+
+For example,
+   220 ISIF.USC.EDU Service ready
+or
+   220 mail.foo.com SuperSMTP v 6.1.2 Service ready
+or
+   220 [10.0.0.1] Clueless host service ready
+
+The table below lists alternative success and failure replies for each
+command.  These SHOULD be strictly adhered to: a receiver may substitute
+text in the replies, but the meaning and action implied by the code numbers
+and by the specific command reply sequence cannot be altered.
+
+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.
+
+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.
+
+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
+
+Specific sequences are:
+
+CONNECTION ESTABLISHMENT
+   S: 220
+   E: 554
+EHLO or HELO
+   S: 250
+   E: 504, 550
+MAIL
+   S: 250
+   E: 552, 451, 452, 550, 553, 503
+RCPT
+   S: 250, 251 (but see section 3.4 for discussion of 251)
+   E: 550, 551, 552, 553, 450, 451, 452, 503, 550
+DATA
+   I: 354 -> data -> S: 250
+                     E: 552, 554, 451, 452
+   E: 451, 554, 503
+RSET
+   S: 250
+VRFY
+   S: 250, 251, 252
+   E: 550, 551, 553, 502, 504
+EXPN
+   S: 250, 252
+   E: 550, 500, 502, 504
+HELP
+   S: 211, 214
+   E: 502, 504
+NOOP
+   S: 250
+QUIT
+   S: 221
+
+4.4 Trace Information
+
+When an SMTP server receives a message for delivery or further processing,
+it MUST insert trace ("time stamp" or "Received") information at the
+beginning of the message content, as discussed in section 4.1.1.4.
+
+This line MUST be structured as follows:
+
+ - The FROM field, which MUST be supplied in an SMTP environment, SHOULD
+   contain both (1) the name of the source host as presented in the EHLO
+   command and (2) an address literal containing the IP address of the
+   source, determined from the TCP connection.
+
+ - The ID field MAY contain an "@" as suggested in RFC-822, but this is not
+   required.
+
+ - The FOR field MAY contain a list of <path> entries when multiple RCPT
+   commands have been given.  This may raise some security issues and is
+   usually not desirable; see section 7.2.
+
+An Internet mail program MUST NOT change a Received: line that was
+previously added to the message header.  SMTP servers MUST prepend Received
+lines to messages; they MUST NOT change the order of existing lines or
+insert Received lines in any other location.
+
+As the Internet grows, comparability of Received fields is important for
+detecting problems, especially slow relays.  SMTP servers that create
+Received fields SHOULD use explicit offsets in the dates (e.g., -0800),
+rather than time zone names of any type.  Local time (with an offset) is
+preferred to UT when feasible.  This formulation allows slightly more
+information about local circumstances to be specified.  If UT is needed,
+the receiver need merely do some simple arithmetic to convert the values.
+Use of UT loses information about the time zone-location of the server.  If
+a time zone name is used, 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
+enviroment.  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 mail data headers and body [MSGFMT].
+
+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 FROM 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.  SMTP servers performing a relay function
+MUST NOT inspect the message data, and especially not to the extent needed
+to determine if Return-path headers are present. SMTP servers making final
+delivery MAY remove Return-path headers before adding their own.
+
+The primary purpose of the Return-path is to designate the address to which
+messages indicating non-delivery or other mail system failures are to be
+sent.  For this to be unambiguous, exactly one return path SHOULD be
+present when the message is delivered.  Systems using RFC 822 syntax with
+non-SMTP transports SHOULD designate an unambiguous address, associated
+with the transport envelope, to which error reports (e.g., non-delivery
+messages) should be sent.
+
+Historical note: Text in RFC 822 that appears to contradict the use of the
+Return-path header (or the envelope MAIL FROM address) as the destination
+for error messages is not applicable on the Internet. The MAIL FROM address
+(as copied into the Return-path) MUST be used as the target of any mail
+containing delivery error messages.
+
+In particular:
+
+ - a gateway from SMTP->elsewhere SHOULD insert a return-path header,
+   unless it is known that the "elsewhere" transport also uses Internet
+   domain addresses and maintains the envelope sender address separately.
+
+ - a gateway from elsewhere->SMTP SHOULD delete any return-path header
+   present in the message, and either copy that information to the SMTP
+   envelope or combine it with information present in the envelope of the
+   other transport system to construct the MAIL FROM part of 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 is preferred when possible.  All
+undeliverable mail notification messages are sent using the MAIL command
+(even if they result from processing the obsolete SEND, SOML, or SAML
+commands) and use a null return path as discussed in section 3.7.
+
+The time stamp line and the return path line are formally defined as
+follows:
+ 
+   Return-path-line = "Return-Path:" FWS Reverse-path <CRLF>
+   
+   Time-stamp-line = "Received:" FWS Stamp <CRLF>
+   
+   Stamp = From-domain By-domain Opt-info ";"  FWS Daytime
+   
+   From-domain = "FROM" FWS Extended-Domain CFWS 
+   
+   By-domain = "BY" FWS Extended-Domain CFWS
+   
+   Extended-Domain = Domain / 
+              ( Domain FWS "(" TCP-info ")" ) /
+              ( Address-literal FWS "(" TCP-info ")"
+    TCP-info = Address-literal / ( Domain FWS Address-literal )
+                   ; Information derived by server from TCP connection,
+ 				     not client EHLO. 
+
+   Opt-info = [Via] [With] [ID] [For]
+   
+   Via = "VIA" FWS Link CFWS 
+   
+   With = "WITH" FWS Protocol CFWS 
+   
+   ID = "ID" FWS String / msg-id CFWS 
+   
+   For = "FOR" FWS 1*( Path / Mailbox ) CFWS 
+   
+   Link = "TCP" / Addtl-Link
+   Addtl-Link = Atom       ; Additional standard names for links are
+                             registered with the Internet Assigned
+                             Numbers Authority (IANA).  "Via" is
+							 primarily of value with non-Internet
+							 transports.
+                             SMTP servers SHOULD NOT use unregistered
+                             names. 
+   Protocol = "ESMTP" / "SMTP" / Attdl-Protocol
+   Attdl-Protocol = Atom    ; Additional standard names for protocols
+                              are registered with the Internet Assigned
+                              Numbers Authority (IANA).  SMTP servers
+                              SHOULD NOT use unregistered names.
+   
+   Daytime =  FWS [ day-of-week "," FWS ] Date FWS Time
+   
+   Date = DD FWS Mon FWS YYYY
+          ; Note that the earlier form, which permits two-digit years, has
+            been deprecated.  SMTP systems MUST use four-digit years.
+   
+   Time = HH ":" MM ":" SS  FWS  Zone
+   
+   DD = 1*2Digit           ; the one or two digit integer day of the
+                             month in the range 1 to 31.
+   
+   Mon = "JAN" | "FEB" | "MAR" | "APR" | "MAY" | "JUN" |
+                "JUL" | "AUG" | "SEP" | "OCT" | "NOV" | "DEC"
+   
+   YYYY = 4*4Digit         ; the four decimal integer year in the range
+                             0000 to 9999. 
+   
+   HH = 2*2Digit           ; the two decimal digit hour of the day in
+                             the range 00 to 24.
+   
+   MM = 2*2Digit            ; the two decimal digit integer minute of the hour
+                              in the range 00 to 59.
+   
+   SS = 2*2Digit [ "." 1*Digit ]
+                            ; the two decimal digit integer second of the
+                              minute in the range 00 to 59, with
+                              optional fractional seconds.
+   
+   Zone = ( "+" / "-" ) 4*4Digit [ <SP> "(" String ")" ]
+                            ; A four digit, signed time zone offset,
+                              such as -0500 for US Eastern Standard
+                              Time.  This may be supplemented by a time
+                              zone name in parentheses, e.g., "-0800
+                              (PDT)". Note that there is no default;
+                              time zone information is required and
+                              MUST be supplied.
+                               
+4.5 Additional Implementation Issues
+
+4.5.1 Minimum Implementation
+
+In order to make SMTP workable, the following minimum implementation is
+required for all receivers. The following commands MUST be supported to
+conform to this specification:
+   EHLO
+   HELO
+   MAIL
+   RCPT
+   DATA
+   RSET
+   NOOP
+   QUIT
+
+VRFY, required by RFC 1123 [RFC-1123], is no longer required by this
+specification.   However, since it was required earlier, servers are
+strongly encouraged to at least recognize the syntax and provide pro-forma
+support.
+
+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 TO commands which 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.  This requirement does not imply that SMTP systems must
+deliver Postmaster mail in particular cases (e.g., problematic origin
+addresses) in which they have substantive reasons for not doing so.
+
+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:
+
+ - Before sending a line of mail text, the SMTP client checks the first
+   character of the line.  If it is a period, one additional period is
+   inserted at the beginning of the line.
+
+ - When a line of mail text is received by the SMTP server, it checks the
+   line.  If the line is composed of a single period, it is treated as the
+   end of mail indicator.  If the first character is a period and there are
+   other characters on the line, the first character is deleted.
+
+The mail data may contain any of the 128 ASCII characters.  All characters
+are to be delivered to the recipient's mailbox, including spaces, vertical
+and horizontal tabs, and other control characters.  If the transmission
+channel provides an 8-bit byte (octets) data stream, the 7-bit ASCII codes
+are transmitted right justified in the octets, with the high order bits
+cleared to zero.  See 3.7 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 or store data in records rather
+than strings.  If such transformations are necessary, they MUST be
+reversible, especially if such transformations are applied to mail being
+relayed.
+
+4.5.3 Sizes and Timeouts
+
+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-X400]
+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 which
+impose no limits on the length of these objects should be used.
+
+local-part
+   The maximum total length of a user name or other local-part is 64
+   characters.
+
+domain
+   The maximum total length of a domain name or number is 255 characters.
+
+path
+   The maximum total length of a reverse-path or forward-path is 256
+   characters (including the punctuation and element separators).
+
+command line
+   The maximum total length of a command line including the command word
+   and the <CRLF> is 512 characters.  SMTP extensions may be used to
+   increase this limit.
+
+reply line
+   The maximum total length of a reply line including the reply code and
+   the <CRLF> is 512 characters.  More information may be conveyed through
+   multiple-line replies.
+
+text line
+   The maximum total length of a text line including the <CRLF> is 1000
+   characters (not counting the leading dot duplicated for transparency).
+   This number may be increased by the use of SMTP Service Extensions.
+
+message content
+   The maximum total length of a message content (including any message
+   headers as well as the message body) MUST BE at least 64K octets. Since
+   the introduction of multimedia mail [RFC-MIME], 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 ([RFC-SIZE]),
+   and SMTP client systems that will send large messages SHOULD utilize it
+   when possible.
+
+recipients buffer
+   The minimum total number of recipients that must be buffered is 100
+   recipients. Rejection of messages (for excessive recipients) with fewer
+   than 100 RCPT TO commands is a violation of this specification.  The
+   general principle that relaying SMTP servers MUST NOT, and delivery SMTP
+   servers SHOULD NOT, perform validation tests on message headers suggests
+   that rejecting a message based on the total number of recipients shown
+   in header fields is to be discouraged.  A server which imposes a limit
+   on the number of recipients MUST behave in an orderly fashion,  such as
+   to reject additional addresses over its limit rather than silently
+   discarding addresses previously accepted.  A client that needs to
+   deliver a message containing over 100 RCPT TO commands SHOULD be
+   prepared to transmit in 100-recipient "chunks" if the server declines to
+   accept more than 100 recipients in a single message.
+
+Errors 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.
+
+[RFC-821] incorrectly listed the error where an SMTP server exhausts its
+implementation limit on the number of RCPT TO 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 addresses will be
+removed from the SMTP client's queue.  When the client attempts
+retransmission of those addresses which received 452 responses, at least
+100 of these will be able to fit in the SMTP server's recipients buffer.
+Each retransmission attempt which 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 TO
+commands and this limit is exhausted, it MUST use a response code of 452.
+If the server has a configured site-policy limitation on the number of RCPT
+TO commands, it MAY instead use a 5XX response code.
+
+In order to interoperate with SMTP servers implementing an older version of
+the protocol, SMTP clients MAY treat a 552 code obtained in response to an
+RCPT command as if it were a 452 response code, especially after some RCPT
+commands have already been accepted in the same mail transaction.
+
+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:
+
+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.
+
+MAIL Command: 5 minutes
+
+RCPT Command: 5 minutes
+   A longer timeout is required if processing of mailing lists and aliases
+   is not deferred until after the message was accepted.
+
+DATA Initiation: 2 minutes
+   This is while awaiting the "354 Start Input" reply to a DATA command.
+
+Data Block: 3 minutes
+   This is while awaiting the completion of each TCP SEND call transmitting
+   a chunk of data.
+
+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.
+
+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 Queuing 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.
+
+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.  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 that discussed in [RFC-ETRN].
+
+The strategy may be further modified as a result of multiple addresses per
+host (see below) to optimize delivery time vs. 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 MAIL FROM MUST NOT be
+cached.
+
+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.
+Implementation of this efficiency feature is strongly encouraged.
+
+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 at
+all times.  This requires the support of multiple incoming TCP connections
+for SMTP.  Some limit MAY be imposed.
+
+As discussed above, when the SMTP server receives mail from a particular
+host address, it could notify the SMTP client 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 which 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, see [RFC 1894]) and also Message
+Disposition Notifications (MDNs, see [RFC 2298]). 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 with
+a valid, non-null reverse-path.
+
+Implementors of automated email processors should be careful to make sure
+that the various kinds of messages with null reverse-path are handled
+correctly, in particular such systems SHOULD NOT reply to messages with
+null reverse-path. 
+
+
+
+
+5. Address Resolution and Mail Handling
+
+Once an SMTP client lexically identifies a domain to which mail will be
+delivered for processing (as described in sections 3.6 and 3.7), a DNS
+lookup is performed to resolve the domain name (see [RFC-DNS]).  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 and, due to a history of problems, are generally discouraged.
+The lookup first attempts to locate an MX record associated with the name.
+If a CNAME record is found instead, the resulting name is processed as if
+it were the initial name.  If no MX records are found, but an A RR is
+found, the A RR is treated as if it was associated with an implicit MX RR,
+with a preference of 0, pointing to that host.  If one or more MX RRs are
+found for a given name, SMTP systems MUST NOT utilize any A RRs associated
+with that name unless they are located using the MX RRs; the "implicit MX"
+rule above applies only if there are no MX records present.  If MX records
+are present, but none of them are usable, this situation MUST be reported
+as an error.
+
+When the lookup succeeds, the mapping can result in a list of alternative
+delivery addresses rather than a single address, because of multiple MX
+records, multihoming, or both.  To provide reliable mail transmission, the
+SMTP client MUST be able to try (and retry) each of the relevant addresses
+in this list in order, until a delivery attempt succeeds. However, there
+MAY also be a configurable limit on the number of alternate addresses that
+can be tried.  In any case, a host SHOULD try at least two addresses.
+
+Two types of information is used to rank the host addresses: multiple MX
+records, and multihomed hosts.
+
+Multiple MX records contain a preference indication that MUST be used in
+sorting (see below).  Lower numbers are more preferred than higher ones.
+If there are multiple destinations with the same preference and there 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 SMTP MUST try them in the order presented.
+
+Although the capability to try multiple alternative addresses is required,
+specific installations may want to limit or disable the use of alternative
+addresses.  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 a host receives a message with a destination for which it is a
+designated Mail eXchanger, it MAY relay the message (potentially after
+having rewritten the addresses), make final delivery of the message, or
+hand it off using some mechanism outside the SMTP-provided transport
+environment.
+
+If it determines that it should relay the message without rewriting the
+address, it MUST sort the MX records to determine candidates for delivery.
+The records are first ordered by preference, with the lowest-numbered
+records being most preferred.  The relay host MUST then inspect the list
+for any of the names or addresses by which it might be known in mail
+transactions.  If a matching record is found, all records at that
+preference level and higher-numbered ones MUST be discarded from
+consideration.  If there are no records left at that point, it is an error
+condition, and the message MUST be returned as undeliverable.  If records
+do remain, they SHOULD be tried, best preference first, as described above.
+
+
+6. 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.
+
+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 SHOULD be the address from the envelope
+return path (or the Return-Path: line).  However, 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 SHOULD 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 [RFC-1047] for a
+discussion of this problem.
+
+6.2 Loop Detection
+
+Simple counting of the number of "Received:" headers 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.3 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 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 [RFC-POP2, RFC-POP3,
+RFC-IMAP2, RFC-PCMAIL]. These protocols have encouraged the use of SMTP as
+a posting 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]).  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.
+
+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 protocol:
+
+ - Addition of a message-id field when none appears
+
+ - Addition of a date, time or time zone when none appears
+
+ - Correction of addresses to proper FQDN format
+
+The less 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.
+
+In all cases, properly-operating clients supplying correct information are
+preferred to corrections by the SMTP server. In all cases, documentation of
+actions performed by the servers (in trace fields and/or header comments)
+is strongly encouraged.
+
+
+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 can be provided in the MOSS framework [RFC-MOSS].
+
+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, unless they are accompanied by careful handoffs of responsibility
+in a carefully-designed trust environment, they remain inherently weaker
+than end-to-end mechanisms which 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 MAIL FROM 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 or in which error (or normal) replies
+should be directed to a special address. (Systems that provide convenient
+ways for users to alter these fields on a per-message basis should attempt
+to establish a primary and permanent mailbox address for the user so that
+Sender fields within the message data can be generated sensibly.)
+
+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 an ignorant user who is trying to fake mail.
+
+7.2 "Blind" Copies
+
+Addresses that do not appear in the message headers may appear in the RCPT
+TO 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 TO command
+arguments into the headers, either as part of trace headers or as
+informational or private-extension headers.  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 TO command.
+
+There is no inherent relationship between either "reverse" (MAIL FROM, SAML
+FROM, etc.) or "forward" (RCPT TO) addresses in the SMTP transaction
+("envelope") and the addresses in the headers.  Receiving systems SHOULD
+NOT attempt to deduce such relationships and use them to alter the headers
+of the message for delivery.  The popular "Apparently-to" header is a
+violation of this principle and SHOULD NOT be used.
+
+7.3 VRFY, EXPN, and Security
+
+As discussed in section 3.5, individual sites may want to disable one or
+both VRFY or EXPN for security reasons.  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.
+
+Within the last few years, the contents of mailing lists have become
+popular as an address information source for so-called "spammers." The use
+of EXPN to "harvest" addresses has increased as list administrators have
+installed protections against inappropriate uses of the lists themselves.
+Implementations SHOULD still provide support for EXPN, but sites SHOULD
+carefully evaluate the tradeoffs. As authentication mechanisms are
+introduced into SMTP, some sites may choose to make EXPN available only to
+authenticated requestors.
+
+7.4 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 useful information to 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 are strongly encouraged to minimally provide
+for making type and version information available in some way to other
+network hosts.
+
+7.5 Information Disclosure in Trace Fields
+
+In some circumstances, such as when mail originates from within a LAN whose
+hosts are not directly from the public Internet, trace ("Received") 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.6 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.
+
+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, MAIL FROM,
+or RCPT TO as appropriate.
+
+
+8. IANA Considerations
+
+IANA will maintain three registries in support of this specification.  The
+first 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.
+
+The second registry consists of "tags" that identify forms of domain
+literals other than those for IPv4 addresses (specified in RFC 821 and in
+this document) and IPv6 addresses (specified in this document).  Additional
+literal types require standardization before being used; none are
+anticipated at this time.
+
+The third, 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") 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.
+
+
+9. References
+
+[8BITMIME] J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker, "SMTP
+Service Extension for 8bit-MIMEtransport", RFC 1652, 07/18/1994.
+
+[ABNF] Crocker, D., P. Overell, Eds., "Augmented BNF for Syntax
+Specifications: ABNF", RFC 2234, November 1997.
+
+[IPv6AddrString] Hinden, R and S. Deering, Eds. "IP Version 6 Addressing
+Architecture", RFC 1884, December 1995.
+
+[MSGFMT] P. Resnick, Work in progress, draft-ietf-drums-msg-fmt-05.txt,
+August, 1998
+
+[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text
+Messages", RFC 822, Department of Electrical Engineering, University of
+Delaware, August 1982.
+
+[RFC-974] C. Partridge, "Mail routing and the domain system", RFC 974,
+01/01/1986
+
+[RFC-1047] C. Partridge, "Duplicate messages and SMTP", RFC 1047,
+02/01/1988.
+
+[RFC-1123] R. Braden, "Requirements for Internet hosts - application and
+support", 10/01/1989
+
+[RFC-BDAT] G. Vaudreuil, "SMTP Service Extensions for Transmission of Large
+and Binary MIME Messages", RFC 1830, 08/16/1995.
+
+[RFC-DNS] P. Mockapetris, "Domain names - implementation and
+specification", RFC 1035 and P. Mockapetris, "Domain names - concepts and
+facilities", RFC 1034. (STD 13)
+
+[RFC-ETRN] J. De Winter, "SMTP Service Extension for Remote Message Queue
+Starting", RFC 1985, 08/14/1996.
+
+[RFC-IMAP2] M. Crispin, "Interactive Mail Access Protocol - Version 2", RFC
+1176, 08/20/1990.
+
+[RFC-IMAP4] M. Crispin, "Internet Message Access Protocol - Version 4", RFC
+2060, 12/04/1996.
+
+[RFC-INTLHDR] K. Moore, "MIME (Multipurpose Internet Mail Extensions) Part
+Three: Message Header Extensions for Non-ASCII Text", RFC 2047, 12/02/1996.
+
+[RFC-MIME] N. Freed, N. Borenstein, "Multipurpose Internet Mail Extensions
+(MIME) Part One: Format of Internet Message Bodies", RFC 2045, 12/02/1996.
+
+[RFC-MOSS] S. Crocker, N. Freed, J. Galvin, S. Murphy, "MIME Object
+Security Services", RFC 1848, 10/03/1995.
+
+[RFC-NOTARY1] K. Moore, "SMTP Service Extension for Delivery Status
+Notifications", RFC 1891, 01/15/1996.
+
+[RFC-NOTARY2] K. Moore, G. Vaudreuil, "An Extensible Message Format for
+Delivery Status Notifications", RFC 1894, 01/15/1996.
+
+[RFC-PCMAIL] M. Lambert, "PCMAIL: A distributed mail system for personal
+computers", RFC 1056, 06/01/1988.
+
+[RFC-PIPELINE] N. Freed, A. Cargille, "SMTP Service Extension for Command
+Pipelining", RFC 1854, 10/04/1995.
+
+[RFC-POP2] M. Butler, D. Chase, J. Goldberger, J. Postel, J. Reynolds,
+"Post Office Protocol - version 2", RFC 937, 02/01/1985
+
+[RFC-POP3] J. Myers, M. Rose, "Post Office Protocol - Version 3", RFC 1930,
+5/14/96 (Std 53).
+
+[RFC-REPLY] G. Vaudreuil, "Enhanced Mail System Status Codes", RFC 1893,
+01/15/1996.
+
+[RFC-SIZE] J. Klensin, N. Freed, K. Moore, "SMTP Service Extension for
+Message Size Declaration", RFC 1870, 11/06/1995. (STD 10)
+
+[RFC-X400] S. Hardcastle-Kille, "Mapping between X.400(1988) / ISO 10021
+and RFC 822", RFC 1327, 05/18/1992.
+
+[SMTPEX] J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker, "SMTP
+Service Extensions", RFC-1869, 11/06/1995. (STD 10)
+
+[TCP] Postel, J., ed., "Transmission Control Protocol - DARPA Internet
+Program Protocol Specification", RFC 793, USC/Information Sciences
+Institute, NTIS AD Number A111091, September 1981.
+
+[US-ASCII] United States of America Standards Institute (now American
+National Standards Institute), X3.4, 1968, "USA Code for Information
+Interchange". ANSI X3.4-1968 has been replaced by newer versions with
+slight modifications, but the 1968 version remains definitive for the
+Internet.
+
+
+10. Editor's Address
+
+John C. Klensin
+MCI Communications
+800 Boylston St., 7th floor
+Boston, MA 02199
+USA
+Email: Klensin@mci.net
+Phone: +1 617 960 1011
+Fax:   +1 617 960 1009
+
+
+11. Acknowledgments
+
+Many people worked long and hard on the many iterations of this document.
+There was wide-ranging debate on the mailing list about many technical
+issues, and many contributors helped form the wording in this
+specification. The hundreds of participants in the many discussions since
+RFC 821 was produced are too numerous to mention, but they all helped this
+document become what it is.
+
+
+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, but not in SMTP commands or responses.
+
+
+B. Generating SMTP Commands from RFC 822 Headers
+ 
+Some systems use RFC 822 headers (only) in a mail submission protocol, or
+otherwise generate SMTP commands from RFC 822 headers 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 a mail envelopes is not separated early in
+processing from header information (and kept separate).
+
+It is recommended that the UA provide its initial 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 fields SHOULD then be removed from the
+   headers.  Once this process is completed, the remaining headers SHOULD
+   be checked to verify that at least one To:, Cc:, or Bcc: header remains.
+   If none do, then a bcc: header with no additional information SHOULD be
+   inserted as specified in [MSGFMT].
+
+2. The return address in the MAIL command SHOULD, if possible, be derived
+   from the system's identity for the submitting (local) user, and the From
+   header field otherwise.  If there is a system identity available, it
+   SHOULD also be copied to the Sender header field if it is different from
+   the address in the From header field.  (Any Sender field that was
+   already there SHOULD be removed.)  Systems may provide a way for
+   submitters to override the envelope return address, but may want to
+   restrict its use to privileged users.  This will not prevent mail
+   forgery, but may lessen its incidence; see section 7.1.
+
+When an MTA is being used in this way, it bears responsibility for ensuring
+that the message being transmitted is valid.  The mechanisms for checking
+that validity, and for handling (or returning) messages that are not valid
+at the time of arrival, are part of the MUA-MTA interface and not covered
+by this specification.
+
+A submission protocol based on Standard RFC 822 information alone MUST NOT
+be used to gateway a message from a foreign (non-SMTP) mail system into an
+SMTP environment.  Additional information to construct an envelope must
+come from some source in the other environment, whether supplemental
+headers or the foreign system's envelope.
+
+Attempts to gateway messages using only their header "to" and "cc" fields,
+have repeatedly caused mail loops and other behavior adverse to the proper
+functioning of the Internet mail environment.  These problems have been
+especially common when the message originates from an Internet mailing list
+and is distributed into the foreign environment using envelope information.
+When these messages are then processed by a header-only remailer, loops
+back to the Internet environment (and the mailing list) are almost
+inevitable.
+
+
+C. Source Routes
+
+The <reverse-path> is a reverse source routing list of hosts and a source
+mailbox.  The first host in the <reverse-path> SHOULD be the host sending
+the MAIL FROM command.  Similarly, the <forward-path> may be a source
+routing lists of hosts and a destination mailbox. However, in general, the
+<forward-path> SHOULD contain only a mailbox and domain name, relying on
+the domain name system to supply routing information if required.  The use
+of source routes is deprecated; while servers MUST be prepared to receive
+and handle them as discussed in section 3.3 and F.2, clients SHOULD NOT
+transmit them.
+
+For relay purposes, the forward-path may be a source route of the form
+"@ONE,@TWO:JOE@THREE", where ONE, TWO, and THREE MUST BE fully-qualified
+domain names.  This form is used to emphasize the distinction between an
+address and a route.  The mailbox is an absolute address, and the route is
+information about how to get there.  The two concepts should not be
+confused.
+
+If source routes are used, RFC 821 and the text below should be consulted
+for the mechanisms for constructing and updating the forward- and
+reverse-paths.
+
+The SMTP server transforms the command arguments by moving its own
+identifier (its domain name or that of any domain for which it is acting as
+a mail exchanger), if it appears, from the forward-path to the beginning of
+the reverse-path.
+
+Notice that the forward-path and reverse-path appear in the SMTP commands
+and replies, but not necessarily in the message.  That is, there is no need
+for these paths and especially this syntax to appear in the "To:" ,
+"From:", "CC:", etc. fields of the message header. Conversely, SMTP servers
+MUST NOT derive final message delivery information from message header
+fields.
+
+When the list of hosts is present, it is a "reverse" source route and
+indicates that the mail was relayed through each host on the list (the
+first host in the list was the most recent relay).  This list is used as a
+source route to return non-delivery notices to the sender. As each relay
+host adds itself to the beginning of the list, it MUST use its name as
+known in the transport environment to which it is relaying the mail rather
+than that of the transport environment from which the mail came (if they
+are different).
+
+
+D. Scenarios
+
+This section presents complete scenarios of several types of SMTP sessions.
+In the examples, "C:" indicates what is said by the SMTP client, and "S:"
+indicates what is said by the SMTP server.
+
+D.1 A Typical SMTP Transaction Scenario
+
+This SMTP example shows mail sent by Smith at host bar.com, to Jones,
+Green, and Brown at host foo.com.  Here we assume that host bar.com
+contacts host foo.com directly.  The mail is accepted for Jones and Brown.
+Green does not have a mailbox at host foo.com.
+
+   S: 220 foo.com Simple Mail Transfer Service Ready
+   C: EHLO bar.com
+   S: 250-foo.com greets bar.com
+   S: 250-8BITMIME
+   S: 250-SIZE
+   S: 250-DSN
+   S: 250 HELP
+   C: MAIL FROM:<Smith@bar.com>
+   S: 250 OK
+   C: RCPT TO:<Jones@foo.com>
+   S: 250 OK
+   C: RCPT TO:<Green@foo.com>
+   S: 550 No such user here
+   C: RCPT TO:<Brown@foo.com>
+   S: 250 OK
+   C: DATA
+   S: 354 Start mail input; end with <CRLF>.<CRLF>
+   C: Blah blah blah...
+   C: ...etc. etc. etc.
+   C: .
+   S: 250 OK
+   C: QUIT
+   S: 221 foo.com Service closing transmission channel
+
+D.2 Aborted SMTP Transaction Scenario
+
+   S: 220 foo.com Simple Mail Transfer Service Ready
+   C: EHLO bar.com
+   S: 250-foo.com greets bar.com
+   S: 250-8BITMIME
+   S: 250-SIZE
+   S: 250-DSN
+   S: 250 HELP
+   C: MAIL FROM:<Smith@bar.com>
+   S: 250 OK
+   C: RCPT TO:<Jones@foo.com>
+   S: 250 OK
+   C: RCPT TO:<Green@foo.com>
+   S: 550 No such user here
+   C: RSET
+   S: 250 OK
+   C: QUIT
+   S: 221 foo.com Service closing transmission channel
+
+D.3 Relayed Mail Scenario
+
+Step 1  --  Source Host to Relay Host
+
+   S: 220 foo.com Simple Mail Transfer Service Ready
+   C: EHLO bar.com
+   S: 250-foo.com greets bar.com
+   S: 250-8BITMIME
+   S: 250-SIZE
+   S: 250-DSN
+   S: 250 HELP
+   C: MAIL FROM:<JQP@bar.com>
+   S: 250 OK
+   C: RCPT TO:<@foo.com:Jones@XYZ.COM>
+   S: 250 OK
+   C: DATA
+   S: 354 Start mail input; end with <CRLF>.<CRLF>
+   C: Date: Thu, 21 May 1998 05:33:29 -0700
+   C: From: John Q. Public <JQP@bar.com>
+   C: Subject:  The Next Meeting of the Board
+   C: To: Jones@xyz.com
+   C:
+   C: Bill:
+   C: The next meeting of the board of directors will be
+   C: on Tuesday.
+   C:                         John.
+   C: .
+   S: 250 OK
+   C: QUIT
+   S: 221 foo.com Service closing transmission channel
+
+Step 2  --  Relay Host to Destination Host
+
+   S: 220 xyz.com Simple Mail Transfer Service Ready
+   C: EHLO foo.com
+   S: 250 xyz.com is on the air
+   C: MAIL FROM:<@foo.com:JQP@bar.com>
+   S: 250 OK
+   C: RCPT TO:<Jones@XYZ.COM>
+   S: 250 OK
+   C: DATA
+   S: 354 Start mail input; end with <CRLF>.<CRLF>
+   C: Received: from bar.com by foo.com ; Thu, 21 May 1998 05:33:29 -0700
+   C: Date: Thu, 21 May 1998 05:33:22 -0700
+   C: From: John Q. Public <JQP@bar.com>
+   C: Subject:  The Next Meeting of the Board
+   C: To: Jones@xyz.com
+   C:
+   C: Bill:
+   C: The next meeting of the board of directors will be
+   C: on Tuesday.
+   C:                         John.
+   C: .
+   S: 250 OK
+
+   C: QUIT
+   S: 221 foo.com Service closing transmission channel
+
+D.4 Verifying and Sending Scenario
+
+   S: 220 foo.com Simple Mail Transfer Service Ready
+   C: EHLO bar.com
+   S: 250-foo.com greets bar.com
+   S: 250-8BITMIME
+   S: 250-SIZE
+   S: 250-DSN
+   S: 250 HELP
+   C: VRFY Crispin
+   S: 250 Mark Crispin <Admin.MRC@foo.com>
+   C: SEND FROM:<EAK@bar.com>
+   S: 250 OK
+   C: RCPT TO:<Admin.MRC@foo.com>
+   S: 250 OK
+   C: DATA
+   S: 354 Start mail input; end with <CRLF>.<CRLF>
+   C: Blah blah blah...
+   C: ...etc. etc. etc.
+   C: .
+   S: 250 OK
+   C: QUIT
+   S: 221 foo.com Service closing transmission channel
+
+
+E. Other Gateway Issues
+
+In general, gateways between the Internet and other mail systems SHOULD
+attempt to preserve any layering semantics across the boundaries between
+the two mail systems involved.  Gateway- translation approaches that
+attempt to take shortcuts by mapping, (such as envelope information from
+one system to the message headers or body of another) have generally proven
+to be inadequate in important ways.  Systems translating between
+environments that do not support both envelopes and headers and Internet
+mail must be written with the understanding that some information loss is
+almost inevitable.
+
+
+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 is strongly preferred to HELO
+when the server will accept the former.  Servers must continue to accept
+and process HELO in order to support older clients.
+
+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 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.
+
+
+X. Change Summary and Loose Ends (Temporary)
+
+X.1 Change summary
+
+X.1.1 Substantive changes between draft-ietf-drums-smtpupd-00.txt and
+draft-ietf-drums-smtpupd-01.txt
+
+(i) Slightly clarified the discussions of rejection and failure of VRFY
+requests and the associated response codes.
+
+(ii) Slightly clarified the discussion of deferred address validation.
+
+(iii) Removed the IPCE terminology and modified the text in section 4.1.1.2
+to explicitly introduce the "mail gateway" terminology and to begin to
+distinguish a mail gateway from a conventional relay.
+
+(iv) Explicitly noted that SMTP clients for things like POP and IMAP may
+send everything to a single relay for further processing, rather than
+resolving final domain names.
+
+(v) Tightened the RSET discussion.
+
+(vi) Deprecation of 251 only for RCPT (still ok for VRFY)
+
+X.1.2.  Substantive changes between draft-ietf-drums-smtpupd-01.txt and
+draft-ietf-drums-smtpupd-02.txt.
+
+Incorporated additional RFC 1123 material; reorganized several sections for
+clarity.  Added definitions and other previous "loose end" material.
+
+X.1.3.  Substantive changes between draft-ietf-drums-smtpupd-02.txt and
+draft-ietf-drums-smtpupd-03.txt.
+
+(i) Eliminated a number of placeholders and tightened some of the
+definitions in section 2.  Added a few new placeholders for consistency
+checking against other documents.
+
+(ii) Removed the state diagrams, per direction at IETF Montreal.
+
+(iii) Added new section 6.3, an attempt to summarize WG discussions on the
+"posting" versus "delivery" versus "relay" functions of SMTP and on whether
+"fixups" are appropriate in different cases.
+
+(iv) Inserted section 6.1, a minor rewrite of section 5.3.3 of RFC1123.
+
+(v) Added new text to 3.5.5 to discuss the spammer - EXPN relationship.
+
+(vi) The "ASCII requirement" in 4.1.1.4 has been tightened somewhat.
+
+(v) The remaining miscellaneous changes agreed to in Montreal have been
+incorporated except as noted below.
+
+X.1.4.  Substantive changes between draft-ietf-drums-smtpupd-03.txt and
+draft-ietf-drums-smtpupd-04.txt.
+
+Many small changes have been made between these two versions; the list that
+follows is not exhaustive.
+
+(i) To clarify some of the text, definitions have been introduced to
+distinguish among originating, delivery, relay, and gateway SMTP systems.
+
+(ii) The role of LF-terminated lines has been clarified.
+
+(iii) Several changes have been made to clarify the principle that, no
+matter what originating and final delivery systems might do, relay systems
+are not permitted to tamper with message content, even to "fix" headers
+that are determined to be invalid.  If they deem message content to be
+seriously unacceptable, they are encouraged to reject the messages in
+preference to trying to fix them up, but, in general, the theme is "don't
+look/ don't tell".
+
+(iv) A few more definitions have been added to the terminology section, and
+the separate glossary has been eliminated.
+
+(v) I have taken a shot at text to address some of the controversies that
+have raged on the WG mailing list (e.g., sections 7.4 and 7.5). Since there
+was no consensus on most of those topics, I expect that the inserted text
+will satisfy no one except, perhaps, for agreement that saying nothing
+would have been worse.  As a mechanism for moving forward, the text in
+these controversial areas that now appears will be considered "base";
+alterations will be made only if clear consensus emerges.
+
+(vi) Per discussion in Los Angeles, source routes have been further
+deprecated.
+
+(vii) Some of the VRFY/EXPN materials have been moved to "security
+considerations", where they appear to belong, some text has been added, and
+the conformance statements adjusted to reflect what I perceive to be WG
+consensus.
+
+(viii) New MX resolution material has been added to section 5.  While most
+of this material is from RFC974, the rules have been further tightened to
+reflect current practice and experience (974 is written in a somewhat
+speculative fashion for a standard).  In particular, the behavior of trying
+the target host's A RR when MXs existed but all of them were eliminated is
+now prohibited, which seems necessary if another of other ideas being
+recommended or considered are to be feasible.
+
+X.1.5.  Substantive changes between draft-ietf-drums-smtpupd-04.txt and
+draft-ietf-drums-smtpupd-05.txt.
+
+(i) All normative references to RFC 1123 have been removed from the main
+body of the text (some still appear in the appendices where they will
+remain).
+
+(ii) Section 3.5 has been renamed slightly to distinguish between
+"debugging of SMTP implementations" and "debugging of addresses". Better
+terminology would be welcome.
+
+(iii) Error conditions resulting from the DATA command have been clarified.
+
+(iv) Section 4.2 (SMTP replies) has been revised and tightened to reflect
+reality and recent discussion on the list.
+
+(v) Appendix E has been revised a bit and moved into section 4.2.1. Given
+the importance of the "check only first digit" rule, it has to be there.
+
+(vi) Added new text for "no SMTP service supported" to sections 3.1, 4.2.2,
+4.2.3, and 4.3.2.  As noted in 3.1, I'd rather add 521 (which would work
+perfectly with the model) rather than overloading 554.
+
+(vii) The Return-path language in section 4.4 has been cleaned up a bit.
+
+(viii) Tightened the "postmaster" language in 4.5.1, requiring a small
+change to 4.1.1.3.
+
+(ix) I have unilaterally (with a little help from my friends), increased
+some of the size limits.  64 was much too short for a domain name, and the
+DNS limit of 255 (?) has now been inserted. That leaves the return path
+much too short, but I haven't fixed it (maybe that will cause us to get rid
+of them).  We still have a 64 character limit on the local-part, which is
+also *much* too short. Votes for 128 or longer limits accepted.  See
+X.1.6(I)
+
+(x) The text on the "recipients buffer" has been rewritten so that (I hope)
+it makes sense and gives some explicit guidance for how clients and servers
+should proceed if limits are imposed.
+
+X.1.6.  Substantive changes between draft-ietf-drums-smtpupd-05.txt and
+draft-ietf-drums-smtpupd-06.txt.
+
+Most of the changes in this revision have been editorial rather than
+substantive.  Major substantive changes include:
+
+(i)  The language about maximum sizes of SMTP command lines has been
+reworked, per WG mailing list discussion.
+
+(ii)  Several instances of  "Should" have been promoted to "Must" when the
+reasons for the weaker rule seemed to have disappeared.  In particular, the
+requirement that an SMTP implementation support timeouts has become a MUST.
+Also, conformance to this specification requires support of EHLO.  Older
+systems should claim conformance to the [to-be-historical] 821, not this
+specification.
+
+X.1.7.  Substantive changes between draft-ietf-drums-smtpupd-06.txt and
+draft-ietf-drums-smtpupd-07.txt.
+
+(i) Removed "implied RSET" text associated with QUIT, as specified at the
+December 1997 IETF
+
+(ii) Required that servers support EHLO, as specified at the December 1997
+IETF
+
+X.1.8. Substantive changes between draft-ietf-drums-smtpupd-07.txt and
+draft-ietf-drums-smtpupd-08.txt.
+
+This version involves mostly editorial work and cleanup of loose ends.
+
+(i) New 7.5 added (old one renumbered) to discuss info disclosure through
+Received fields.
+
+(ii) Some character set and minor syntax issues clarified.
+
+(iii) Material on code 571 added (thought this had been done long ago;
+slipped through the cracks)
+
+(iv) Many clarifications added as the result of list discussions and
+suggestions.
+
+(v) Error code presentation has been restructured.
+
+(vi) ABNF conversion done
+
+(vii) IPv6 address format inserted per RFC 1884, since we could not get
+clear agreement on an alternative.
+
+(viii) Trivial, silly, examples removed.  Others not yet renumbered.
+
+(ix) 3.5.2 and 4.1.1 altered slightly per Eric Allman's notes.  Eric may
+not like the way I've done either of these change very much: the first now
+makes the distinction between returning an address and returning other
+stuff (which was permitted by -06, but the text wasn't as clear as it
+should have been): if it looks like an address, it needs to be an address.
+Similarly, with 4.1.1, Eric wanted to explicitly permit/legitimize "DATA
+<SP> <CRLF>".  I see several disadvantages to doing that, so have inserted
+language that encourages receivers to tolerate trailing white space, which
+may have the same practical effect.
+
+
+X.1.9. Substantive changes between draft-ietf-drums-smtpupd-08.txt and
+draft-ietf-drums-smtpupd-09.txt.
+
+The first ten of these reflect, in order, minuted items from the Chicago
+IETF (IETF 42).
+
+(i) Clarification of "MUST", etc., in the context of this document
+(section 2.3).
+
+(ii) Altered VRFY text to make implementation a SHOULD (section 3.5.1) and
+removed VRFY from the mandatory to implement list (section 4.5.1), per
+42nd IETF (Chicago).
+
+(iii) Clarified that exploders are expected to not purge sender addresses
+from lists (section 3.10).  Note that the Chicago conclusion was that this
+should be a "MUST".  I could not figure out how to do that without
+absolutely prohibiting removing addresses to prevent loops, to guard
+against spammers, or for similar legitimate purposes.  So I have written
+this as a "SHOULD", with additional "strongly discouraged" words.   If
+someone still wants a MUST, suggest text.
+
+(iv) Altered text to permit clients that sometimes, or even always,
+initiate sessions with HELO, rather than EHLO, to be fully-conforming
+(section 3.2).  [[ Editor's note: I continue to believe that a client that
+does not have any service extension support, even to the extent of being
+able to send EHLO and parse the response without doing anything about it,
+should not be considered fully-conforming to this spec (as distinct from
+821).   Consequently, the new text in 3.2 stops well short of encouraging
+clients that don't need service extensions from preferentially using HELO,
+and the text in 2.2.1 (which specifies that the extension mechanisms must
+be supported) has not been changed.
+
+(v) Per Chicago discussions, the text requiring that QUIT be sent has not
+been changed.  The text in 4.1.1.10 requiring that the server wait for
+QUIT has been changed to a SHOULD.  However, the text in 4.1.1.5,
+prohibiting close on receipt of RSET and that elsewhere prohibiting close
+as a normal response, has not been changed.
+
+(vi) Text has been inserted in 4.1.1 and the text in 4.3.2 altered
+slightly to clarify the handling of parameters to RSET, DATA, and QUIT and
+to 4.1.1.9 specify semantics for parameters to NOOP.  I have followed the
+minutes on this although I personally agree with kre's mailing list
+comments that the "servers SHOULD reject" decision leads to silly states.
+I recommend that the WG review this.
+
+(vii) Per discussion in Chicago, no substantive change has been made to
+the specification about underscore characters in domain names (section
+4.1.2).  However, the text has been altered to more accurately reflect
+discussion on the mailing list and the source of the requirement.
+
+(viii) Per discussion in Chicago, no change has been made to the
+preference for local time in Received headers.
+
+(ix) Per discussion in Chicago, code 571 has been removed and policy
+rejection is now reflected i a 550 code (section 3.7 and the response code
+lists).
+
+(x)  Per discussion in Chicago, no change has been made to the
+specification of use of raw CR or LF.
+
+(xi) In section 4.3, the text has been changed, per comments from Dan
+Bernstein and others, to require that clients be able to handle replies
+that do not contain text strings. A few other places patched to match.
+
+(xii) In sections 4.1.1.1 and 8, the placeholders have been removed.
+
+(xiii) Per discussion on the mailing list (and specifically James
+Berriman's concerns), the text has been clarified (sections 4.1.1.2 and
+4.1.4) to prohibit MAIL unless no mail transaction is open.  This is a
+MUST NOT prohibition -- SHOULD NOT makes no sense if this is the direction
+we are going to go.  503 has also been added to the list of valid
+responses for "MAIL" in 4.3.1 - it can't be issued before EHLO/HELO in any
+event.  While it is clear that something should be said, this may not be
+the desired outcome (I selected it because it was conservative and easy
+given the text that was there already); the WG should check that the text
+is as intended.
+
+(xiv) Per discussion on the mailing list, a new section 4.5.5 has been
+added to describe null return paths and their handling (forward pointer
+from 3.7).  The text in 4.5.5 is substantially that suggested by Norbert
+Bollow.   As with (xiii), there is now clear text, but it may not be what
+the WG desires.  Please check.
+
+[9b] Text lost in upload process restored.
+
+(xv) "all addresses" substituted for "each...in turn" in 3.10.2.
+
+(xvi) Requirement for "<" and ">" around paths clarified in section 3.3
+(syntax productions were clear and correct, but not this overview
+material).
+
+[9c]
+
+(xvii) Clarified text in 3.3 to permit post-DATA bounces on policy
+matters. 
+
+
+
+Z.  Full Copyright Statement
+
+Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+This document and translations of it may be copied and furnished to others,
+and derivative works that comment on or otherwise explain it or assist in
+its implementation may be prepared, copied, published and distributed, in
+whole or in part, without restriction of any kind, provided that the above
+copyright notice and this paragraph are included on all such copies and
+derivative works.  However, this document itself may not be modified in any
+way, such as by removing the copyright notice or references to the Internet
+Society or other Internet organizations, except as needed for the purpose
+of developing Internet standards in which case the procedures for
+copyrights defined in the Internet Standards process must be followed, or
+as required to translate it into languages other than English.
+
+The limited permissions granted above are perpetual and will not be revoked
+by the Internet Society or its successors or assigns.
+
+This document and the information contained herein is provided on an "AS
+IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE
+DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
+ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY
+RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
+PARTICULAR PURPOSE.
+
+Expires June 1999
diff --git a/Documentation/en/I-D/draft-ietf-drums-smtpupd-10.txt b/Documentation/en/I-D/draft-ietf-drums-smtpupd-10.txt
new file mode 100644
index 00000000..32e7799d
--- /dev/null
+++ b/Documentation/en/I-D/draft-ietf-drums-smtpupd-10.txt
@@ -0,0 +1,3796 @@
+INTERNET-DRAFT                                John C. Klensin, Editor
+Expires July 1999                         
+February 26, 1999
+                                                        
+
+                  Simple Mail Transfer Protocol 
+
+                 draft-ietf-drums-smtpupd-10.txt
+
+Status of this Memo
+
+This document is an Internet-Draft and is in full conformance with
+all provisions of Section 10 of RFC2026.
+
+Internet-Drafts are working documents of the Internet Engineering
+Task Force (IETF), its areas, and its working groups.  Note that
+other groups may also distribute working documents as Internet-Drafts.
+
+Internet-Drafts are draft documents valid for a maximum of six months
+and may be updated, replaced, or obsoleted by other documents at any
+time.  It is inappropriate to use Internet- Drafts as reference
+material or to cite them other than as "work in progress."
+
+To view the list Internet-Draft Shadow Directories, see
+http://www.ietf.org/shadow.html.
+
+[[Appendix X will be removed before the document is submitted to the
+IESG.]]
+
+[[If consensus is reached on this document, it will be forwarded to the
+IESG with the recommendation that it be processed onto the Standards
+track.]]
+
+Copyright Notice
+
+Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+                           Table of Contents
+
+0. Abstract
+
+1. Introduction
+
+2. The SMTP Model
+2.1 Basic Structure
+2.2 The Extension Model
+2.2.1 Background
+2.2.2 Definition and Registration of Extensions
+2.3 Terminology
+2.3.1 Mail Objects
+2.3.2 Senders and Receivers
+2.3.3 Mail Agents
+2.3.4 Host
+2.3.5 Domain
+2.3.6 Buffer and State Table
+2.3.7 Lines
+2.3.8 Originator, Delivery, Relay, and Gateway Systems
+2.3.9 Message Content and Mail Data
+2.3.10 Mailbox and Address
+2.3.11 Reply
+2.4 Syntax Principles
+2.4.1 General Syntax and Transaction Model
+2.4.2 Command and Reply Syntax
+
+3. The SMTP Procedures: An Overview
+3.1 Session Initiation
+3.2 Client Initiation
+3.3 Mail Transactions
+3.4 Forwarding for Address Correction or Updating
+3.5 Commands for Debugging Addresses
+3.5.1 Overview
+3.5.2 VRFY Normal Response
+3.5.3 Meaning of VRFY or EXPN Success Response
+3.5.4 Semantics and Applications of EXPN
+3.6 Domains
+3.7 Relaying
+3.8 Mail Gatewaying
+3.8.1 Header Fields in Gatewaying
+3.8.2 Received Lines in Gatewaying
+3.8.3 Addresses in Gatewaying
+3.8.4 Other Header Fields in Gatewaying
+3.8.5 Envelopes in Gatewaying
+3.9 Terminating Sessions and Connections
+3.10 Mailing Lists and Aliases
+3.10.1 Alias
+3.10.2 List
+
+4. The SMTP Specifications
+4.1 SMTP Commands
+4.1.1 Command Semantics and Syntax
+4.1.1.1  Extended HELLO (EHLO) or HELLO (HELO)
+4.1.1.2 MAIL (MAIL)
+4.1.1.3 RECIPIENT (RCPT)
+4.1.1.4 DATA (DATA)
+4.1.1.5 RESET (RSET)
+4.1.1.6 VERIFY (VRFY)
+4.1.1.7 EXPAND (EXPN)
+4.1.1.8 HELP (HELP)
+4.1.1.9 NOOP (NOOP)
+4.1.1.10 QUIT (QUIT)
+4.1.2 Lower-level Syntax
+4.1.3 Address Literals
+4.1.4 Order of Commands
+4.1.5 Private-use Commands
+4.2  SMTP Replies
+4.2.1 Reply Code Severities and Theory
+4.2.2 Reply Codes by Function Groups
+4.2.3  Reply Codes in Numeric Order
+4.2.4 Reply Code 502
+4.2.5 Reply Codes After DATA and the Subsequent <CRLF>.<CRLF>
+4.3 Sequencing of Commands and Replies
+4.3.1 Sequencing Overview
+4.3.2 Command-Reply Sequences
+4.4 Trace Information
+4.5 Additional Implementation Issues
+4.5.1 Minimum Implementation
+4.5.2 Transparency
+4.5.3 Sizes and Timeouts
+4.5.4 Queuing Strategies
+4.5.4.1 Sending Strategy
+4.5.4.2 Receiving Strategy
+4.5.5 Messages with a null reverse-path
+
+5. Address Resolution and Mail Handling
+
+6. Problem Detection and Handling
+6.1 Reliable Delivery and Replies by Email
+6.2 Loop Detection
+6.3 Compensating for Irregularities
+
+7. Security Considerations
+7.1 Mail Security and Spoofing
+7.2 "Blind" Copies
+7.3 VRFY, EXPN, and Security
+7.4 Information Disclosure in Announcements
+7.5 Information Disclosure in Trace Fields
+7.6 Scope of Operation of SMTP Servers
+
+8. IANA Considerations
+
+9. References
+
+10. Editors' Addresses
+
+11. Acknowledgments
+
+A. TCP Transport Service
+B. Generating SMTP Commands from RFC 822 Headers 
+C. Source Routes
+D. Scenarios
+E. Other Gateway Issues
+F. Deprecated Features of RFC 821
+X. Change Summary and Loose Ends (Temporary)
+
+
+0. Abstract
+
+This document is a self-contained specification of the basic protocol for
+the Internet electronic mail transport, consolidating and updating:
+
+ - the original SMTP specification of RFC 821 [RFC-821],
+
+ - domain name system requirements and implications for mail transport from
+   RFC 1035 [RFC-DNS] and RFC 974 [RFC-974],
+
+ - the clarifications and applicability statements in RFC 1123 [RFC-1123],
+   and
+
+ - material drawn from the SMTP Extension mechanisms [SMTPEXT].
+
+It replaces RFC 821, RFC 974, and 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 turned up 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 posting' protocol, as recommended for POP [RFC-POP2, RFC-POP3] and
+IMAP [RFC-IMAP4].
+
+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 discusses message headers, message bodies and formats
+and structures for them, and their relationship - [MSGFMT].
+
+
+1. Introduction
+
+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 describe some of them.
+
+An important feature of SMTP is its capability to transport mail across
+transport service environments, usually referred to as "SMTP mail relaying"
+(see section 3.8).  A transport service  environment might consist of the
+mutually-TCP-accessible hosts on  the public Internet, the
+mutually-TCP-accessible hosts on a firewall-isolated private TCP/IP
+Intranet, or hosts in some other LAN or WAN environment utilizing a
+different transport-level protocol.  It is important to realize that
+"transport service environments" are one-to-one with usual definitions of
+"networks".  A process can communicate directly with another process, and
+transport mail using this protocol, through any mutually known and
+connected transport service. Conversely, mail can be relayed or gatewayed
+between processes in two different transport service environments by a
+process known and connected to each of the two transport service
+environments. The Mail eXchanger mechanisms of the domain name system
+[RFC-DNS, and section 5 of this document] allows the identity of hosts
+supporting SMTP relay and gateway processes to be specified.
+
+
+2. The SMTP Model
+
+2.1 Basic Structure
+
+The SMTP design can be pictured as:
+
+               +----------+                +----------+
+   +------+    |          |                |          |
+   | User |<-->|          |      SMTP      |          |
+   +------+    |  Sender- |Commands/Replies| Receiver-|
+   +------+    |   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 role 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 transferred to an SMTP client, and how
+that client determines the domain name(s) to which mail messages are to be
+transferred is a local matter, and is not addressed by this document. In
+some cases, the domain name(s) transferred to, or 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-POP2, RFC-POP3] or IMAP [RFC-IMAP4] protocols, or when the SMTP client
+is inside an isolated transport service environment, the domain name
+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 domain names 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.
+
+The means by which an SMTP client, once it has determined a target domain
+name, 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.
+
+Once the transmission channel is established and initial handshaking
+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 headers 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 extension
+requests such as in [RFC-Pipeline].
+
+Once a given mail message has been transmitted, the client may either
+request that the connection be shut down or may initiate other mail
+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.  This transmission normally occurs 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.
+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.
+
+To provide relay capability, the SMTP server is supplied with the name of
+the ultimate destination host as well as the destination mailbox name.
+Usually, intermediate hosts are determined via the DNS MX record, not by
+explicit "source" routing (see section 5 and appendices C and F.2).
+
+2.2 The Extension Model
+
+2.2.1 Background
+
+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 added, it must be done in
+a way that permits older implementations to continue working acceptably.
+The extension framework consists of:
+
+ - The SMTP command EHLO, superseding the earlier HELO,
+
+ - a registry of SMTP service extensions,
+
+ - additional parameters to the SMTP MAIL FROM and RCPT TO commands, and
+
+ - optional replacements for verbs defined in this protocol, such as for
+   DATA (see [RFC-BDAT]).
+
+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:
+
+ - the textual name of the SMTP service extension;
+
+ - the EHLO keyword value associated with the extension;
+
+ - the syntax and possible values of parameters associated with the
+   EHLO keyword value;
+
+ - any additional SMTP verbs associated with the extension (additional
+   verbs will usually be, but are not required to be, the same as the
+   EHLO keyword value);
+
+ - any new parameters the extension associates with the MAIL FROM or
+   RCPT TO verbs;
+
+ - a description of how support for the extension affects the behavior
+   of a server and client SMTP; and,
+
+ - the increment by which the extension is increasing the maximum
+   length of the commands MAIL FROM and/or RCPT TO, 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.3 Terminology
+
+Most of the terminology in this document is common in the Internet at the
+time of its writing.  However, the following terms and concepts are used
+in special ways here, or represent differences in terminology between RFC
+821 and this document, and should be understood before reading further.
+These definitions are normative, that is, they contain specifications to
+which SMTP implementations are required to conform.
+
+The terms "MUST" and "SHOULD" (and "MUST NOT" and "SHOULD NOT") are used
+in the same general sense here as in the Host Requirements Standards
+[RFC-1123].  Specifically, "MUST" or "MUST NOT" identify absolute
+requirements for conformance to this specification.  Implementations that
+do not conform to them lie outside the scope of this specification and
+often will not interoperate properly with SMTP implementations that do
+conform.  Implementations that are fully conforming also adhere to all
+"SHOULD" and "SHOULD NOT" requirements.  Implementations that adhere to
+all "MUST" ("MUST NOT") but not to all of these are considered to be
+partially conforming.  Such implementations may interoperate properly with
+fully conforming ones and with each other, but this will typically be the
+case only if great care is taken.  Consequently, an implementation should
+violate "SHOULD" ("SHOULD NOT") requirements only under exceptional and
+well-understood circumstances. "SHOULD" (and sometimes "MUST")
+requirements are often imposed by this specification when experience has
+shown that following such requirements or restrictions leads, in practice,
+to better interoperation, or smoother operation of the Internet email
+infrastructure. As a consequence, some of these statements constitute
+recommended practices, rather than the statistically most common practice
+at the time of this writing.  Statements using "MAY" describe features or
+styles of doing things that may be followed, or not, at the discretion of
+the implementation, normally without causing significant interoperability
+problems.  
+
+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 which error reports
+should be directed); a delivery mode (e.g., deliver to recipient
+mailboxes); one or more recipient addresses; and optional protocol
+extension material.
+
+The SMTP content is sent in the SMTP DATA protocol unit and has two parts:
+the headers and the body. If the content conforms to existing standards,
+the headers form a collection of field/value pairs structured as described
+in [MSGFMT]; the body, if structured, is defined according to MIME
+[RFC-MIME]. The content is textual in nature, expressed using the US-ASCII
+repertoire [US-ASCII]. Although SMTP extensions (such as [8BitMIME]) may
+relax this restriction for the content body, the content headers are always
+encoded using the US-ASCII repertoire. The algorithm defined in
+[RFC-INTLHDR] is used to represent 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
+
+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).
+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
+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 "domain");
+identifying them by numerical address is discouraged.
+
+2.3.5 Domain
+
+A domain (or domain name) consists of one or more dot-separated components,
+each consisting of a sequence of letters, digits, and hyphens.  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-DNS] and section 5.
+
+The domain name, as described in this document and in [RFC-DNS], 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.
+
+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 which 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 Lines
+
+SMTP commands and, unless altered by a service extension, message data, are
+transmitted in "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.
+
+2.3.8 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 hands it to a mail user agent or deposits it in a message
+store which 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.
+
+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 message headers and the possibly-structured message body.
+The MIME specification [RFC-MIME] provides the Standard mechanisms for
+structured message bodies.
+
+2.3.10 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" and, consequently, the local-part is
+interpreted and assigned semantics only by the host specified in the domain
+part of the address.
+
+2.3.11 Reply
+
+An SMTP reply is an acknowledgment (positive or negative) sent from
+receiver to sender 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.
+
+2.4 Syntax Principles
+
+2.4.1 General Syntax and Transaction Model
+
+SMTP commands and replies have a rigid syntax. All commands begin with a
+four letter command verb. All Replies begin with a three digit numeric
+code. In some commands and replies, arguments MUST follow 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
+<SP>. Complete definitions of commands and replies appear in section 4.
+
+Verbs and argument values 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.  This is NOT
+true of a mailbox local-part. 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.  Mailbox domains are
+not case sensitive.  However, exploiting the case sensitivity of
+mailbox local-parts impedes interoperability and is discouraged.
+
+Commands and replies are composed of characters from the ASCII character
+set [US-ASCII]. 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 seven bit transport only.  An originating
+SMTP client which has not successfully negotiated an appropriate extension
+with a particular server 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 ultimate delivery of a severely garbled message
+to the recipient.  Delivery SMTP systems MAY reject ("bounce") such
+messages rather than deliver them.  No sending SMTP system is 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.
+
+Eight-bit message content transmission MAY be requested of the server by a
+client using extended SMTP facilities, notably the "8BITMIME" extension
+[8BITMIME].  8BITMIME SHOULD be supported by SMTP servers. However, it MUST
+not be construed as authorization to transmit unrestricted eight bit
+material.  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 [ABNF]. Metalanguage
+terms used in running text are surrounded by pointed brackets (e.g.,
+<CRLF>) for clarity.
+
+2.4.2 Command and Reply Syntax
+
+The commands consist of a command verb followed by an argument field.
+Command verbs are four alphabetic characters and are case insensitive.
+
+This also applies to any symbols representing parameter values, such as
+"TO" or "to" for the forward-path.  Command verbs and the argument fields
+are separated by one or more spaces.  However, case is important in the
+local-part within the reverse-path and forward-path arguments.  In
+particular, for some hosts the user "smith" is different from the user
+"Smith".
+
+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 field consists of a variable length character string ending
+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.
+
+
+3. The SMTP Procedures: An Overview
+
+This section contains descriptions of the procedures used in SMTP: session
+initiation, the mail transaction, forwarding mail, verifying mailbox names
+and expanding mailing lists, and the opening and closing exchanges.
+Comments on relaying, a note on mail domains, and a discussion of changing
+roles are included at the end of this section.  Several complete scenarios
+are presented in appendix D.
+
+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.5.1).
+
+The SMTP protocol allows a server to formally reject a transaction 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 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 which are unable to support service extensions and
+contemporary clients which 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.
+
+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").
+
+3.3 Mail Transactions
+
+There are three steps to SMTP mail transactions.  The transaction starts
+with a MAIL command which gives the sender identification.  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> 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> can 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.
+
+   RCPT TO:<forward-path> [ <SP> <rcpt-parameters> ] <CRLF>
+
+This command gives 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 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).  This step of the procedure can be repeated
+any number of times.
+
+The <forward-path> can contain more than just a mailbox.  Historically, the
+<forward-path> can be 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 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 RCPT TO appears without a
+previous MAIL FROM, 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).
+
+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 data.  If
+accepted, the SMTP server returns a 250 OK reply. The DATA command can fail
+in only two ways:
+
+ - If there was no MAIL FROM, or no RCPT TO, command, or all such commands
+   were rejected, the server MAY return a "command out of sequence" (503)
+   reply.  If that 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), or if resources were 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.  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 RFC 822 format is being used, the mail data include the memo header
+items such as Date, Subject, To, Cc, From [MSGFMT].  Server SMTP systems
+SHOULD NOT reject messages based on perceived defects in the RFC 822 or
+MIME [RFC-MIME] message header or message body.  In particular, they MUST
+NOT reject messages in which the numbers of Resent- 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 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 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) reply code from RCPT TO are
+deprecated: Servers SHOULD NOT provide that service or return that code.
+
+
+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 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
+
+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
+response 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-REPLY], 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 of one mailbox.
+If a request is made to verify 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 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 normally include the mailbox name.
+"<local-part@domain>", where "domain" is a fully qualified domain name,
+MUST appear in the syntax.  In exceptional circumstances, free-form text
+MAY be returned.  In order to facilitate parsing by both computers 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.  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, they MUST be listed as service extensions in an EHLO
+response, if they are supported.
+
+3.5.3 Meaning of VRFY or EXPN Success Response
+
+A server MUST NOT return a 220 code in response to a VRFY or EXPN command
+unless it has actually verified the address.  In particular, a server MUST
+NOT return 220 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 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 discussed in section 2.1.  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.
+
+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,
+and mail systems SHOULD NOT attempt them.
+
+3.6 Domains
+
+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 A RRs (as discussed in section 5) are permitted, as are CNAME
+RRs whose targets can be resolved, in turn, to MX or A RRs.  Local
+nicknames or unqualified names MUST NOT be used.  There are two exceptions
+to the rule requiring FQDNs:
+
+ - The domain name given in the EHLO command MUST BE either a primary host
+   name (a domain name that resolves to an A RR) or, if the host has no
+   name, an address literal as described in section 4.1.1.1.
+
+ - The reserved mailbox name "postmaster" may be used in a RCPT TO command
+   without domain qualification (see section 4.1.1.3) and MUST be accepted
+   if so used.
+
+3.7 Relaying
+
+In general, the availability of Mail eXchanger records in the domain name
+system [RFC-DNS] makes the use of explicit source routes in the Internet
+mail system unnecessary.  Many historical problems with their
+interpretation 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 are also permitted to 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.
+
+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 relay mail to a particular address for policy
+reasons, a 550 response SHOULD be returned.
+
+A relay SMTP server may be encountered in one additional circumstance: by
+private agreement between an originating client SMTP and an associated
+SMTP relay, the client MAY be configured to send all mail to that relay
+for further processing.  In conformance with this specification and other
+Internet Standards and guidelines, the relay SMTP SHOULD be configured
+into a client of this type by name (rather than by IP address), and the
+name SHOULD be processed as described in section 5.   Clients of this sort
+will rarely be fully-conformant to this specification since, in most
+cases, the use of a single relay for all outgoing mail traffic is used as
+an alternative to such requirements as the one to retry mail delivery on
+connection failures (see section 5 and elsewhere).
+
+It is important to note that MX records can point to SMTP servers which
+act as gateways into other environments, not just SMTP relays and final
+delivery systems; see sections 3.8 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-NOTARY1]) 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 section 4.5.5 for additional discussion).  A MAIL
+command with a null reverse-path appears as follows:
+
+   MAIL FROM:<>
+
+As discussed in section 2.4.1, a relay SMTP has no need to inspect or act
+upon the headers or body of the message data and MUST NOT do so except
+to add its own "Received:" header (section 4.4) and to perform simple
+counting of the number of "Received:" headers in a message (section 6.2).
+
+3.8 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.8, 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.8.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 2.4.1
+
+Other mail systems gatewayed to the Internet often use a subset of RFC-822
+headers 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.  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).
+
+3.8.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.
+
+Received: 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 fields arising in non-SMTP
+environments, receiving systems MUST NOT reject mail based on the format of
+a trace field and SHOULD be extremely robust in the light of unexpected
+information or formats in those fields.
+
+The gateway SHOULD indicate the environment and protocol in the "via"
+clauses of Received field(s) that it supplies.
+
+3.8.3 Addresses in Gatewaying
+
+>From the Internet side, the gateway SHOULD accept all valid address formats
+in SMTP commands and in RFC-822 headers, and all valid RFC-822 messages.
+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.8.4 Other Header Fields in Gatewaying
+
+The gateway MUST ensure that all header fields of a message that it
+forwards into the Internet meet the requirements for Internet mail.  In
+particular, all addresses in "From:", "To:", "Cc:", etc., fields MUST be
+transformed (if necessary) to satisfy RFC-822 syntax, MUST reference only
+fully-qualified domain names, and MUST be effective and useful for sending
+replies.  The translation algorithm used to convert mail from the
+Internet protocols to another environment's protocol SHOULD ensure that
+error messages from the foreign mail environment are delivered to the
+return path from the SMTP envelope, not to the sender listed in the "From:"
+field (or other fields) of the RFC-822 message.
+
+3.8.5 Envelopes in Gatewaying
+
+Similarly, when forwarding a message from another environment into the
+Internet, the gateway SHOULD set the envelope return path 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.9 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 except:
+
+ - After receiving a QUIT command and responding with a 221 reply.
+
+ - After detecting the need to shutdown the SMTP service and returning a
+   421 response code.  This response code can be issued after the server
+   receives any command or, if necessary, asynchronously from command
+   receipt (on the assumption that the client will receive it after the
+   next command is issued).
+
+In particular, a server that closes connections in response to commands
+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 which 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.
+
+3.10 Mailing Lists and Aliases
+
+An SMTP-capable host SHOULD support both the alias and the list models of
+address expansion for multiple delivery.  When a message is delivered or
+forwarded to each address of an expanded list 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 (see [MSGFMT]) MUST be left unchanged; in particular, the
+"From" field of the message header 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.10.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.10.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 all of the expanded
+addresses.  The return 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.
+
+
+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 are encouraged to tolerate
+trailing white space before the terminating <CRLF>.)  The syntax of the
+local part of a mailbox must conform to receiver site conventions and the
+syntax specified in section 4.1.2.  The SMTP commands are discussed below.
+The SMTP replies are discussed in section 4.2.
+
+A mail transaction involves several data objects which 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 which 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 field 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 available), the
+client SHOULD send an address literal (see section 4.1.3), optionally
+followed by information that will help to identify the client system.
+
+The SMTP server identifies itself to the SMTP client in the connection
+greeting reply and in the response to this command.
+
+A client SMTP SHOULD start an SMTP session by issuing the EHLO command. If
+the SMTP server supports the SMTP service extensions it will give a
+successful response, a failure response, or an error response. If the SMTP
+server, in violation of this specification, does not support any SMTP
+service extensions it will generate an error response.  Older client SMTP
+systems MAY, as discussed above, use HELO (as specified in RFC 821) instead
+of EHLO, and servers MUST support the HELO command and reply properly to
+it.  In any event, a client MUST issue HELO or EHLO before starting a mail
+transaction.
+
+These commands, and a "250 OK" reply to one of them, confirm that both the
+SMTP client and the SMTP server are in the initial state, that is, there is
+no transaction in progress and all state tables and buffers are cleared.
+
+Normally, the response to EHLO will be a multiline reply.  Each line of the
+response contains a keyword and, optionally, one or more parameters.  The
+syntax for a positive response, using the ABNF notation and low-level
+terminals of [ABNF], is:
+
+   ehlo-ok-rsp  ::=      "250"    domain [ <SP> greeting ] <CRLF>
+                  / (    "250-"   domain [ <SP> greeting ] <CRLF>
+                      *( "250-"   ehlo-line                <CRLF> )
+                         "250"    <SP> ehlo-line           <CRLF>    )
+   
+   greeting     ::= 1*<any character other than CR or LF>
+   
+   ehlo-line    ::= ehlo-keyword *( <SP> ehlo-param )
+   
+   ehlo-keyword ::= (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
+                ; syntax and values depend on ehlo-keyword
+
+   ehlo-param   ::= 1*<any CHAR excluding <SP> and all
+                       control characters (US-ASCII 0-31
+                       inclusive)>
+
+Although EHLO keywords may be specified in upper, lower, or mixed case,
+they MUST always be recognized and processed in a case-insensitive manner.
+This is simply an extension of practices specified in RFC 821 and section
+2.4.1.
+
+4.1.1.2 MAIL (MAIL)
+
+This command is used to initiate a mail transaction in which the mail
+data is delivered to an SMTP server which may, in turn, deliver it to
+one or more mailboxes or pass it on to another system (possibly using
+SMTP).  The argument field contains a reverse-path and may contain
+optional parameters.  In general, the MAIL command may be sent only
+when no mail transaction is in progress, see section 4.1.4.
+
+The reverse-path consists of the sender mailbox.  Historically, that
+mailbox might optionally have been preceeded by a list of hosts, but
+that behavior.  In some types of reporting messages for which a reply
+is likely to cause a mail loop (for example, mail delivery and
+nondelivery notifications), the reverse-path may be null (see section
+3.7).
+
+This command clears the reverse-path buffer, the forward-path buffer, and
+the mail data buffer; and inserts the reverse-path information from this
+command into the reverse-path buffer.
+
+If service extensions were negotiated, the MAIL command may also carry
+parameters associated with a particular service extension.
+
+Syntax:
+
+   "MAIL FROM:" Reverse-path  [ <SP> Mail-parameters ]
+
+or
+   "MAIL FROM:<>" [ <SP> Mail-parameters ] 
+
+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 use of this command.
+The argument field contains a forward-path and may contain optional
+parameters. 
+
+The forward-path normally consists of the required destination
+mailbox.  Sending systems SHOULD not generate the optional list of hosts
+known as a source route.  Receiving systems MUST recognize source route
+syntax but SHOULD strip off the source route specification and utilize the
+domain name associated with the mailbox as if the source route had not been
+provided.
+
+Similarly, relay hosts SHOULD strip or ignore source routes, and names MUST
+NOT be copied into the reverse-path. When mail reaches its ultimate
+destination (the forward-path contains only a destination mailbox), the
+SMTP server inserts it into the destination mailbox in accordance with its
+host mail conventions.
+
+For example, mail received at relay host xyz.com with envelope commands
+
+   MAIL FROM:<userx@y.foo.org>
+   RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org>
+
+will normally be sent directly on to host d.bar.org with envelope commands
+
+   MAIL FROM:<userx@y.foo.org>
+   RCPT TO:<userc@d.bar.org>
+
+As provided in appendix C, xyz.com MAY also choose to relay the
+message to hosta.int, using the envelope commands 
+
+   MAIL FROM:<userx@y.foo.org>
+   RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org>
+
+or to jkl.org, using the envelope commands
+
+   MAIL FROM:<userx@y.foo.org>
+   RCPT TO:<@jkl.org:userc@d.bar.org>
+
+Of course, since hosts are not required to relay mail at all, xyz.com
+may also reject the message entirely when the RCPT command is
+received, using a 550 code (since this is a "policy reason").
+
+If service extensions were negotiated, the RCPT TO command may also carry
+parameters associated with a particular service extension offered by the
+server.  The client MUST NOT transmit parameters other than those
+associated with a service extension offered by the server in its EHLO
+response.
+
+Syntax:
+   "RCPT TO:" Forward-path  [ <SP> Rcpt-parameters ]
+or
+   "RCPT TO:<Postmaster>" [ <SP> Rcpt-parameters ]
+
+4.1.1.4 DATA (DATA)
+
+The receiver 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 (especially the ASCII "Null" character) may cause
+problems and SHOULD be avoided when possible.
+
+The mail data is terminated by a line containing only a period, that is,
+the character sequence "<CRLF>.<CRLF>" (see section 4.5.2).  This is the
+end of mail data indication.  Note that 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 data, ends the DATA command itself.
+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 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.  Errors
+that are diagnosed subsequently MUST be reported in a mail message, as
+discussed in section 4.4 In sending a positive completion reply to the end
+of data indication, the receiver takes full responsibility for the message
+(see section 6.1).
+
+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.
+
+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 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. In other situations, it restores the state to that immediately
+after the most recent EHLO.  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"
+
+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" <SP> String
+
+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.
+
+Syntax:
+   "EXPN" <SP> String
+
+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.
+
+SMTP servers SHOULD support HELP without arguments and MAY support it with
+arguments.
+
+Syntax:
+   "HELP" [ <SP> String ]
+
+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 an OK reply.
+
+This command has no effect on the reverse-path buffer, the forward-path
+buffer, or the mail data buffer.  If a parameter string is specified,
+servers SHOULD ignore it.
+
+Syntax:
+   "NOOP" [ <SP> String ]
+
+
+4.1.1.10 QUIT (QUIT)
+
+This command specifies that the receiver MUST send an 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 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).
+
+Syntax: 
+   "QUIT"
+
+4.1.2 Lower-level Syntax
+
+The syntax of the argument fields of the above commands (using the syntax
+specified in [ABNF] 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
+(section 6) of [ABNF] or in the syntax of [MSGFMT].
+
+   Reverse-path = Path
+
+   Forward-path = Path
+
+   Path = "<" [ A-d-l ":" ] Mailbox ">"
+
+   A-d-l = At-domain *( "," A-d-l )    ; Note that this form, the
+                                 so-called "source route", MUST BE
+                                 accepted, SHOULD NOT be generated,
+                                 and SHOULD be ignored.
+
+   At-domain = "@" Domain
+
+   Mail-parameters = *( <SP> Keyword "=" Argument )
+
+   Rcpt-parameters =  *( <SP> Keyword "=" Argument )
+
+   Keyword  = Ldh-str
+   Argument = Atom
+
+   Domain = sub-domain 1*("." sub-domain) / address-literal
+
+   sub-domain = let-dig *(Ldh-str)
+   address-literal = "[" IPv4-address-literal / 
+                  IPv6-address-literal / General-address-literal "]"
+   IPv4-address-literal = snum 3*3("." snum)
+   IPv6-address-literal = "IPv6 " IPv6-addr-string
+   IPv6-addr-string = String         ; IPv6 address in standard form
+                                       [IPv6AddrSpec].  Since this
+                                       form uses colon characters,
+                                       the String will actually need
+                                       to be quoted in all cases.
+   General-address-literal = Standardized-tag <SP> String
+   Standardized-tag = Ldh-str        ; Specified in a
+                                       standards-track RFC 
+                                       and registered with IANA
+   snum = 1*3Digit                   ; representing a decimal integer
+                                       value in the range 0 through 255 
+   let-dig = Alpha / Digit
+   ldh-str = *( Alpha / Digit / "-" ) let-dig
+
+   Mailbox = Local-part "@" Domain
+
+   Local-part = Dot-string / Quoted-string
+
+   Dot-string = Atom [ "." Atom ]
+
+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 of
+non-ASCII characters (octets with the high order bit set to one) or ASCII
+"control characters" (decimal value 0-31 and 127).  These characters MUST
+NOT be used in MAIL FROM or RCPT TO commands or other commands that require
+mailbox names.
+
+   String = Atom / Quoted-string
+
+   special = <<Msg-fmt-special>> /     [[placeholder, see above]]
+             the control characters (ASCII codes 0 through 31
+             inclusive and 127)
+
+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 field with the comma being the fourth character of the
+field.
+
+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-1015]), characters outside the
+set of alphas, digits, and hyphen MUST NOT appear in domain name labels
+for SMTP clients or servers.  In particular, the underscore character is
+not permitted.  SMTP servers that receive a command in which illegal
+character codes have been employed, and for which there are no other
+reasons for rejection, MUST reject that command with a 501 response.
+
+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 space, and the address itself, in a format
+specified as part of the IPv6 standards [IPv6AddrSpec].
+
+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, 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, or 502
+failure replies MUST be returned as appropriate.  The 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 valid principal host name (not a CNAME or MX name) for
+its host.  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 and supplemental
+information provided that will assist in identifying the client.
+
+An SMTP server MAY verify that the domain name parameter in the EHLO
+command actually corresponds to the IP address of the client. However, the
+server MUST NOT refuse to accept a message for this reason if the
+verification fails: the information about verification failure is for
+logging and tracing only.
+
+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 (or
+a new EHLO) 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 it the previous one successfully concluded with
+a successful DATA command, or if the previous one was aborted with a RSET.
+
+If the transaction beginning command argument 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 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
+cannot be used at any other time in a session, but SHOULD be used by the
+client SMTP to request connection closure, even when no session opening
+command was sent and accepted.
+
+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
+alphanumeric 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 section 4.2.1).  Since, in
+violation of this specification, the text is sometimes not sent, clients
+which 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
+circumstances, however, multiline replies are allowed for any command.
+
+In ABNF, server responses are:
+
+  Greeting = "220 " Domain [ SP text ] CRLF
+  Reply-line = Reply-code [ SP text ] CRLF 
+
+where "Greeting" appears only in the 220 response that announces that the
+server is opening its part of the connection.
+
+An SMTP server SHOULD send only the reply codes listed in this document.
+An SMTP server SHOULD use the text shown in the examples whenever
+appropriate.
+
+An SMTP client MUST determine its actions only by the reply code, not by
+the text (except for 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.
+
+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 five values for the first digit of the reply code:
+
+1yz   Positive Preliminary reply
+   The command has been accepted, but the requested action is being held in
+   abeyance, pending confirmation of the information in this reply.  The
+   SMTP client should send another command specifying whether to continue
+   or abort the action. Note: unextended SMTP does not have any commands
+   that allow this type of reply, and so does not have continue or abort
+   commands.
+
+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 is encouraged to 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 is discouraged from repeating 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
+   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).
+
+The second digit encodes responses in specific categories:
+
+x0z   Syntax: These replies refer to syntax errors, syntactically correct
+   commands that don't fit any functional category, and unimplemented or
+   superfluous commands.
+
+x1z   Information:  These are replies to requests for information, 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.
+
+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:
+   123-First line
+   123-Second line
+   123-234 text beginning with numbers
+   123 The last line
+
+In many cases the SMTP client then simply needs to search for the reply
+code followed by <SP> at the beginning of a line, and ignore all preceding
+lines.  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)
+
+   220 <domain> Service ready
+   221 <domain> Service closing transmission channel
+   421 <domain> Service not available, closing transmission channel
+      (This may be a reply to any command if the service knows it
+      must shut down)
+
+   250 Requested mail action okay, completed
+   251 User not local; will forward to <forward-path>
+      (See section 3.4)
+   252 Cannot VRFY user, but will accept message and attempt 
+       delivery
+      (See section 3.5.3)
+   450 Requested mail action not taken: mailbox unavailable
+      (e.g., mailbox busy)
+   550 Requested action not taken: mailbox unavailable
+      (e.g., mailbox not found, no access, or command rejected
+      for policy reasons)
+   451 Requested action aborted: error in processing
+   551 User not local; please try <forward-path>
+      (See section 3.4)
+   452 Requested action not taken: insufficient system storage
+   552 Requested mail action aborted: exceeded storage allocation
+   553 Requested action not taken: mailbox name not allowed
+      (e.g., mailbox syntax incorrect)  
+   354 Start mail input; end with <CRLF>.<CRLF>
+   554 Transaction failed (Or, in the case of a connection-opening
+       response, "No SMTP service here")
+
+4.2.3  Reply Codes in Numeric Order
+
+   211 System status, or system help reply
+   214 Help message
+      (Information on how to use the receiver or the meaning of a
+      particular non-standard command; this reply is useful only
+      to the human user)
+   220 <domain> Service ready
+   221 <domain> Service closing transmission channel
+   250 Requested mail action okay, completed
+   251 User not local; will forward to <forward-path>
+      (See section 3.4)
+   252 Cannot VRFY user, but will accept message and attempt 
+      delivery
+      (See section 3.5.3)
+
+   354 Start mail input; end with <CRLF>.<CRLF>
+
+   421 <domain> Service not available, closing transmission channel
+      (This may be a reply to any command if the service knows it
+      must shut down)
+   450 Requested mail action not taken: mailbox unavailable
+      (e.g., mailbox busy)
+   451 Requested action aborted: local error in processing
+   452 Requested action not taken: insufficient system storage
+
+   500 Syntax error, command unrecognized
+      (This may include errors such as command line too long)
+   501 Syntax error in parameters or arguments
+   502 Command not implemented (see section 4.2.4)
+   503 Bad sequence of commands
+   504 Command parameter not implemented
+   550 Requested action not taken: mailbox unavailable
+      (e.g., mailbox not found, no access, or command rejected
+      for policy reasons)
+   551 User not local; please try <forward-path>
+      (See section 3.4)
+   552 Requested mail action aborted: exceeded storage allocation
+   553 Requested action not taken: mailbox name not allowed
+      (e.g., mailbox syntax incorrect)
+   554 Transaction failed  (Or, in the case of a connection-opening
+       response, "No SMTP service here")
+
+4.2.4 Reply Code 502
+
+Questions have 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:
+
+ - delivering the message (if the recipient mailbox exists), or
+
+ - if attempts to deliver the message fail due to transient conditions,
+   retrying delivery some reasonable number of times at intervals as
+   specified in section 4.5.4.
+
+ - if attempts to deliver the message fail due to permanent conditions, or
+   if repeated attempts to deliver the message fail due to transient
+   conditions, returning appropriate notification to the sender of the
+   original message (using the address in the SMTP MAIL FROM command).
+
+When an SMTP server returns a transient error completion status (4yz) code
+after the DATA command is completed with <CRLF>.<CRLF>, it MUST NOT make
+any further attempt to deliver that message.  The SMTP client retains
+responsibility for 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).  The
+sending user SHOULD be able to interpret the return of a transient or
+permanent failure status as a non-delivery indication.
+
+When an SMTP server returns a permanent error status (5yz) code after
+the DATA command is completely with <CRLF>.<CRLF>, it MUST NOT make
+any further 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 and intervention of the message.
+
+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 4.1.3 for a discussion of alternatives in these situations.
+
+For example,
+   220 ISIF.USC.EDU Service ready
+or
+   220 mail.foo.com SuperSMTP v 6.1.2 Service ready
+or
+   220 [10.0.0.1] Clueless host service ready
+
+The table below lists alternative success and failure replies for each
+command.  These SHOULD be strictly adhered to: a receiver may substitute
+text in the replies, but the meaning and action implied by the code numbers
+and by the specific command reply sequence cannot be altered.
+
+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.
+
+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.
+
+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
+
+Specific sequences are:
+
+CONNECTION ESTABLISHMENT
+   S: 220
+   E: 554
+EHLO or HELO
+   S: 250
+   E: 504, 550
+MAIL
+   S: 250
+   E: 552, 451, 452, 550, 553, 503
+RCPT
+   S: 250, 251 (but see section 3.4 for discussion of 251)
+   E: 550, 551, 552, 553, 450, 451, 452, 503, 550
+DATA
+   I: 354 -> data -> S: 250
+                     E: 552, 554, 451, 452
+   E: 451, 554, 503
+RSET
+   S: 250
+VRFY
+   S: 250, 251, 252
+   E: 550, 551, 553, 502, 504
+EXPN
+   S: 250, 252
+   E: 550, 500, 502, 504
+HELP
+   S: 211, 214
+   E: 502, 504
+NOOP
+   S: 250
+QUIT
+   S: 221
+
+4.4 Trace Information
+
+When an SMTP server receives a message for delivery or further processing,
+it MUST insert trace ("time stamp" or "Received") information at the
+beginning of the message content, as discussed in section 4.1.1.4.
+
+This line MUST be structured as follows:
+
+ - The FROM field, which MUST be supplied in an SMTP environment, SHOULD
+   contain both (1) the name of the source host as presented in the EHLO
+   command and (2) an address literal containing the IP address of the
+   source, determined from the TCP connection.
+
+ - The ID field MAY contain an "@" as suggested in RFC-822, but this is not
+   required.
+
+ - The FOR field MAY contain a list of <path> entries when multiple RCPT
+   commands have been given.  This may raise some security issues and is
+   usually not desirable; see section 7.2.
+
+An Internet mail program MUST NOT change a Received: line that was
+previously added to the message header.  SMTP servers MUST prepend Received
+lines to messages; they MUST NOT change the order of existing lines or
+insert Received lines in any other location.
+
+As the Internet grows, comparability of Received fields is important for
+detecting problems, especially slow relays.  SMTP servers that create
+Received fields SHOULD use explicit offsets in the dates (e.g., -0800),
+rather than time zone names of any type.  Local time (with an offset) is
+preferred to UT when feasible.  This formulation allows slightly more
+information about local circumstances to be specified.  If UT is needed,
+the receiver need merely do some simple arithmetic to convert the values.
+Use of UT loses information about the time zone-location of the server.  If
+a time zone name is used, 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
+enviroment.  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 mail data headers and body [MSGFMT].
+
+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 FROM 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.  SMTP servers performing a relay function
+MUST NOT inspect the message data, and especially not to the extent needed
+to determine if Return-path headers are present. SMTP servers making final
+delivery MAY remove Return-path headers before adding their own.
+
+The primary purpose of the Return-path is to designate the address to which
+messages indicating non-delivery or other mail system failures are to be
+sent.  For this to be unambiguous, exactly one return path SHOULD be
+present when the message is delivered.  Systems using RFC 822 syntax with
+non-SMTP transports SHOULD designate an unambiguous address, associated
+with the transport envelope, to which error reports (e.g., non-delivery
+messages) should be sent.
+
+Historical note: Text in RFC 822 that appears to contradict the use of the
+Return-path header (or the envelope MAIL FROM address) as the destination
+for error messages is not applicable on the Internet. The MAIL FROM address
+(as copied into the Return-path) MUST be used as the target of any mail
+containing delivery error messages.
+
+In particular:
+
+ - a gateway from SMTP->elsewhere SHOULD insert a return-path header,
+   unless it is known that the "elsewhere" transport also uses Internet
+   domain addresses and maintains the envelope sender address separately.
+
+ - a gateway from elsewhere->SMTP SHOULD delete any return-path header
+   present in the message, and either copy that information to the SMTP
+   envelope or combine it with information present in the envelope of the
+   other transport system to construct the MAIL FROM part of 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 is preferred when possible.  All
+undeliverable mail notification messages are sent using the MAIL command
+(even if they result from processing the obsolete SEND, SOML, or SAML
+commands) and use a null return path as discussed in section 3.7.
+
+The time stamp line and the return path line are formally defined as
+follows:
+ 
+   Return-path-line = "Return-Path:" FWS Reverse-path <CRLF>
+   
+   Time-stamp-line = "Received:" FWS Stamp <CRLF>
+   
+   Stamp = From-domain By-domain Opt-info ";"  FWS Daytime
+   
+   From-domain = "FROM" FWS Extended-Domain CFWS 
+   
+   By-domain = "BY" FWS Extended-Domain CFWS
+   
+   Extended-Domain = Domain / 
+              ( Domain FWS "(" TCP-info ")" ) /
+              ( Address-literal FWS "(" TCP-info ")"
+    TCP-info = Address-literal / ( Domain FWS Address-literal )
+                   ; Information derived by server from TCP connection,
+ 				     not client EHLO. 
+
+   Opt-info = [Via] [With] [ID] [For]
+   
+   Via = "VIA" FWS Link CFWS 
+   
+   With = "WITH" FWS Protocol CFWS 
+   
+   ID = "ID" FWS String / msg-id CFWS 
+   
+   For = "FOR" FWS 1*( Path / Mailbox ) CFWS 
+   
+   Link = "TCP" / Addtl-Link
+   Addtl-Link = Atom       ; Additional standard names for links are
+                             registered with the Internet Assigned
+                             Numbers Authority (IANA).  "Via" is
+							 primarily of value with non-Internet
+							 transports.
+                             SMTP servers SHOULD NOT use unregistered
+                             names. 
+   Protocol = "ESMTP" / "SMTP" / Attdl-Protocol
+   Attdl-Protocol = Atom    ; Additional standard names for protocols
+                              are registered with the Internet Assigned
+                              Numbers Authority (IANA).  SMTP servers
+                              SHOULD NOT use unregistered names.
+   
+   Daytime =  FWS [ day-of-week "," FWS ] Date FWS Time
+   
+   Date = DD FWS Mon FWS YYYY
+          ; Note that the earlier form, which permits two-digit years, has
+            been deprecated.  SMTP systems MUST use four-digit years.
+   
+   Time = HH ":" MM ":" SS  FWS  Zone
+   
+   DD = 1*2Digit           ; the one or two digit integer day of the
+                             month in the range 1 to 31.
+   
+   Mon = "JAN" | "FEB" | "MAR" | "APR" | "MAY" | "JUN" |
+                "JUL" | "AUG" | "SEP" | "OCT" | "NOV" | "DEC"
+   
+   YYYY = 4*4Digit         ; the four decimal integer year in the range
+                             0000 to 9999. 
+   
+   HH = 2*2Digit           ; the two decimal digit hour of the day in
+                             the range 00 to 24.
+   
+   MM = 2*2Digit            ; the two decimal digit integer minute of the hour
+                              in the range 00 to 59.
+   
+   SS = 2*2Digit [ "." 1*Digit ]
+                            ; the two decimal digit integer second of the
+                              minute in the range 00 to 60 (to allow
+							  for leap seconds), with optional
+							  fractional seconds. 
+   
+   Zone = ( "+" / "-" ) 4*4Digit [ <SP> "(" String ")" ]
+                            ; A four digit, signed time zone offset,
+                              such as -0500 for US Eastern Standard
+                              Time.  This may be supplemented by a time
+                              zone name in parentheses, e.g., "-0800
+                              (PDT)". Note that there is no default;
+                              time zone information is required and
+                              MUST be supplied.
+                               
+4.5 Additional Implementation Issues
+
+4.5.1 Minimum Implementation
+
+In order to make SMTP workable, the following minimum implementation is
+required for 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 TO commands which 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.  This requirement does not imply that SMTP systems must
+deliver Postmaster mail in particular cases (e.g., problematic origin
+addresses) in which they have substantive reasons for not doing so.
+
+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:
+
+ - Before sending a line of mail text, the SMTP client checks the first
+   character of the line.  If it is a period, one additional period is
+   inserted at the beginning of the line.
+
+ - When a line of mail text is received by the SMTP server, it checks the
+   line.  If the line is composed of a single period, it is treated as the
+   end of mail indicator.  If the first character is a period and there are
+   other characters on the line, the first character is deleted.
+
+The mail data may contain any of the 128 ASCII characters.  All characters
+are to be delivered to the recipient's mailbox, including spaces, vertical
+and horizontal tabs, and other control characters.  If the transmission
+channel provides an 8-bit byte (octets) data stream, the 7-bit ASCII codes
+are transmitted right justified in the octets, with the high order bits
+cleared to zero.  See 3.7 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 or store data in records rather
+than strings.  If such transformations are necessary, they MUST be
+reversible, especially if such transformations are applied to mail being
+relayed.
+
+4.5.3 Sizes and Timeouts
+
+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-X400]
+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 which
+impose no limits on the length of these objects should be used.
+
+local-part
+   The maximum total length of a user name or other local-part is 64
+   characters.
+
+domain
+   The maximum total length of a domain name or number is 255 characters.
+
+path
+   The maximum total length of a reverse-path or forward-path is 256
+   characters (including the punctuation and element separators).
+
+command line
+   The maximum total length of a command line including the command word
+   and the <CRLF> is 512 characters.  SMTP extensions may be used to
+   increase this limit.
+
+reply line
+   The maximum total length of a reply line including the reply code and
+   the <CRLF> is 512 characters.  More information may be conveyed through
+   multiple-line replies.
+
+text line
+   The maximum total length of a text line including the <CRLF> is 1000
+   characters (not counting the leading dot duplicated for transparency).
+   This number may be increased by the use of SMTP Service Extensions.
+
+message content
+   The maximum total length of a message content (including any message
+   headers as well as the message body) MUST BE at least 64K octets. Since
+   the introduction of multimedia mail [RFC-MIME], 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 ([RFC-SIZE]),
+   and SMTP client systems that will send large messages SHOULD utilize it
+   when possible.
+
+recipients buffer
+   The minimum total number of recipients that must be buffered is 100
+   recipients. Rejection of messages (for excessive recipients) with fewer
+   than 100 RCPT TO commands is a violation of this specification.  The
+   general principle that relaying SMTP servers MUST NOT, and delivery SMTP
+   servers SHOULD NOT, perform validation tests on message headers suggests
+   that rejecting a message based on the total number of recipients shown
+   in header fields is to be discouraged.  A server which imposes a limit
+   on the number of recipients MUST behave in an orderly fashion,  such as
+   to reject additional addresses over its limit rather than silently
+   discarding addresses previously accepted.  A client that needs to
+   deliver a message containing over 100 RCPT TO commands SHOULD be
+   prepared to transmit in 100-recipient "chunks" if the server declines to
+   accept more than 100 recipients in a single message.
+
+Errors 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.
+
+[RFC-821] incorrectly listed the error where an SMTP server exhausts its
+implementation limit on the number of RCPT TO 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 addresses will be
+removed from the SMTP client's queue.  When the client attempts
+retransmission of those addresses which received 452 responses, at least
+100 of these will be able to fit in the SMTP server's recipients buffer.
+Each retransmission attempt which 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 TO
+commands and this limit is exhausted, it MUST use a response code of 452.
+If the server has a configured site-policy limitation on the number of RCPT
+TO commands, it MAY instead use a 5XX response code.
+
+In order to interoperate with SMTP servers implementing an older version of
+the protocol, SMTP clients MAY treat a 552 code obtained in response to an
+RCPT command as if it were a 452 response code, especially after some RCPT
+commands have already been accepted in the same mail transaction.
+
+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:
+
+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.
+
+MAIL Command: 5 minutes
+
+RCPT Command: 5 minutes
+   A longer timeout is required if processing of mailing lists and aliases
+   is not deferred until after the message was accepted.
+
+DATA Initiation: 2 minutes
+   This is while awaiting the "354 Start Input" reply to a DATA command.
+
+Data Block: 3 minutes
+   This is while awaiting the completion of each TCP SEND call transmitting
+   a chunk of data.
+
+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.
+
+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 Queuing 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.
+
+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.  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 that discussed in [RFC-ETRN].
+
+The strategy may be further modified as a result of multiple addresses per
+host (see below) to optimize delivery time vs. 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 MAIL FROM MUST NOT be
+cached.
+
+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.
+Implementation of this efficiency feature is strongly encouraged.
+
+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 at
+all times.  This requires the support of multiple incoming TCP connections
+for SMTP.  Some limit MAY be imposed.
+
+As discussed above, when the SMTP server receives mail from a particular
+host address, it could notify the SMTP client 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 which 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, see [RFC 1894]) and also Message
+Disposition Notifications (MDNs, see [RFC 2298]). 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 with
+a valid, non-null reverse-path.
+
+Implementors of automated email processors should be careful to make sure
+that the various kinds of messages with null reverse-path are handled
+correctly, in particular such systems SHOULD NOT reply to messages with
+null reverse-path. 
+
+
+
+5. Address Resolution and Mail Handling
+
+Once an SMTP client lexically identifies a domain to which mail will be
+delivered for processing (as described in sections 3.6 and 3.7), a DNS
+lookup MUST be performed to resolve the domain name (see [RFC-DNS]).  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 and, due to a history of problems, are generally
+discouraged.  The lookup first attempts to locate an MX record associated
+with the name.  If a CNAME record is found instead, the resulting name is
+processed as if it were the initial name.  If no MX records are found, but
+an A RR is found, the A RR is treated as if it was associated with an
+implicit MX RR, with a preference of 0, pointing to that host.  If one or
+more MX RRs are found for a given name, SMTP systems MUST NOT utilize any
+A RRs associated with that name unless they are located using the MX RRs;
+the "implicit MX" rule above applies only if there are no MX records
+present.  If MX records are present, but none of them are usable, this
+situation MUST be reported as an error.
+
+When the lookup succeeds, the mapping can result in a list of alternative
+delivery addresses rather than a single address, because of multiple MX
+records, multihoming, or both.  To provide reliable mail transmission, the
+SMTP client MUST be able to try (and retry) each of the relevant addresses
+in this list in order, until a delivery attempt succeeds. However, there
+MAY also be a configurable limit on the number of alternate addresses that
+can be tried.  In any case, a host SHOULD try at least two addresses.
+
+Two types of information is used to rank the host addresses: multiple MX
+records, and multihomed hosts.
+
+Multiple MX records contain a preference indication that MUST be used in
+sorting (see below).  Lower numbers are more preferred than higher ones.
+If there are multiple destinations with the same preference and there 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 SMTP MUST try them in the order presented.
+
+Although the capability to try multiple alternative addresses is required,
+specific installations may want to limit or disable the use of alternative
+addresses.  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 a host receives a message with a destination for which it is a
+designated Mail eXchanger, it MAY relay the message (potentially after
+having rewritten the 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 delivery.
+The records are first ordered by preference, with the lowest-numbered
+records being most preferred.  The relay host MUST then inspect the list
+for any of the names or addresses by which it might be known in mail
+transactions.  If a matching record is found, all records at that
+preference level and higher-numbered ones MUST be discarded from
+consideration.  If there are no records left at that point, it is an error
+condition, and the message MUST be returned as undeliverable.  If records
+do remain, they SHOULD be tried, best preference first, as described above.
+
+
+6. 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.
+
+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, 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 SHOULD 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 [RFC-1047] for a
+discussion of this problem.
+
+6.2 Loop Detection
+
+Simple counting of the number of "Received:" headers 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.3 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 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 [RFC-POP2, RFC-POP3,
+RFC-IMAP2, RFC-PCMAIL]. These protocols have encouraged the use of SMTP as
+a posting 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]).  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.
+
+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 protocol:
+
+ - Addition of a message-id field when none appears
+
+ - Addition of a date, time or time zone when none appears
+
+ - Correction of addresses to proper FQDN format
+
+The less 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.
+
+In all cases, properly-operating clients supplying correct information are
+preferred to corrections by the SMTP server. In all cases, documentation of
+actions performed by the servers (in trace fields and/or header comments)
+is strongly encouraged.
+
+
+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 can be provided in the MOSS framework [RFC-MOSS].
+
+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, unless they are accompanied by careful handoffs of responsibility
+in a carefully-designed trust environment, they remain inherently weaker
+than end-to-end mechanisms which 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 MAIL FROM 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 or in which error (or normal) replies
+should be directed to a special address. (Systems that provide convenient
+ways for users to alter these fields on a per-message basis should attempt
+to establish a primary and permanent mailbox address for the user so that
+Sender fields within the message data can be generated sensibly.)
+
+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 an ignorant user who is trying to fake mail.
+
+7.2 "Blind" Copies
+
+Addresses that do not appear in the message headers may appear in the RCPT
+TO 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 TO command
+arguments into the headers, either as part of trace headers or as
+informational or private-extension headers.  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 TO command.
+
+There is no inherent relationship between either "reverse" (MAIL FROM, SAML
+FROM, etc.) or "forward" (RCPT TO) addresses in the SMTP transaction
+("envelope") and the addresses in the headers.  Receiving systems SHOULD
+NOT attempt to deduce such relationships and use them to alter the headers
+of the message for delivery.  The popular "Apparently-to" header is a
+violation of this principle and SHOULD NOT be used.
+
+7.3 VRFY, EXPN, and Security
+
+As discussed in section 3.5, individual sites may want to disable one or
+both VRFY or EXPN for security reasons.  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.
+
+Within the last few years, the contents of mailing lists have become
+popular as an address information source for so-called "spammers." The use
+of EXPN to "harvest" addresses has increased as list administrators have
+installed protections against inappropriate uses of the lists themselves.
+Implementations SHOULD still provide support for EXPN, but sites SHOULD
+carefully evaluate the tradeoffs. As authentication mechanisms are
+introduced into SMTP, some sites may choose to make EXPN available only to
+authenticated requestors.
+
+7.4 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 useful information to 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 are strongly encouraged to minimally provide
+for making type and version information available in some way to other
+network hosts.
+
+7.5 Information Disclosure in Trace Fields
+
+In some circumstances, such as when mail originates from within a LAN whose
+hosts are not directly from the public Internet, trace ("Received") 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.6 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.
+
+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, MAIL FROM,
+or RCPT TO as appropriate.
+
+
+8. IANA Considerations
+
+IANA will maintain three registries in support of this specification.  The
+first 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.
+
+The second registry consists of "tags" that identify forms of domain
+literals other than those for IPv4 addresses (specified in RFC 821 and in
+this document) and IPv6 addresses (specified in this document).  Additional
+literal types require standardization before being used; none are
+anticipated at this time.
+
+The third, 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") 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.
+
+
+9. References
+
+[8BITMIME] J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker, "SMTP
+Service Extension for 8bit-MIMEtransport", RFC 1652, 07/18/1994.
+
+[ABNF] Crocker, D., P. Overell, Eds., "Augmented BNF for Syntax
+Specifications: ABNF", RFC 2234, November 1997.
+
+[IPv6AddrSpec] Hinden, R and S. Deering, Eds. "IP Version 6 Addressing
+Architecture", RFC 1884, December 1995.
+
+[MSGFMT] P. Resnick, Work in progress, draft-ietf-drums-msg-fmt-05.txt,
+August, 1998
+
+[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text
+Messages", RFC 822, Department of Electrical Engineering, University of
+Delaware, August 1982.
+
+[RFC-974] C. Partridge, "Mail routing and the domain system", RFC 974,
+01/01/1986
+
+[RFC-1047] C. Partridge, "Duplicate messages and SMTP", RFC 1047,
+02/01/1988.
+
+[RFC-1123] R. Braden, "Requirements for Internet hosts - application and
+support", 10/01/1989
+
+[RFC-BDAT] G. Vaudreuil, "SMTP Service Extensions for Transmission of Large
+and Binary MIME Messages", RFC 1830, 08/16/1995.
+
+[RFC-DNS] P. Mockapetris, "Domain names - implementation and
+specification", RFC 1035 and P. Mockapetris, "Domain names - concepts and
+facilities", RFC 1034. (STD 13)
+
+[RFC-ETRN] J. De Winter, "SMTP Service Extension for Remote Message Queue
+Starting", RFC 1985, 08/14/1996.
+
+[RFC-IMAP2] M. Crispin, "Interactive Mail Access Protocol - Version 2", RFC
+1176, 08/20/1990.
+
+[RFC-IMAP4] M. Crispin, "Internet Message Access Protocol - Version 4", RFC
+2060, 12/04/1996.
+
+[RFC-INTLHDR] K. Moore, "MIME (Multipurpose Internet Mail Extensions) Part
+Three: Message Header Extensions for Non-ASCII Text", RFC 2047, 12/02/1996.
+
+[RFC-MIME] N. Freed, N. Borenstein, "Multipurpose Internet Mail Extensions
+(MIME) Part One: Format of Internet Message Bodies", RFC 2045, 12/02/1996.
+
+[RFC-MOSS] S. Crocker, N. Freed, J. Galvin, S. Murphy, "MIME Object
+Security Services", RFC 1848, 10/03/1995.
+
+[RFC-NOTARY1] K. Moore, "SMTP Service Extension for Delivery Status
+Notifications", RFC 1891, 01/15/1996.
+
+[RFC-NOTARY2] K. Moore, G. Vaudreuil, "An Extensible Message Format for
+Delivery Status Notifications", RFC 1894, 01/15/1996.
+
+[RFC-PCMAIL] M. Lambert, "PCMAIL: A distributed mail system for personal
+computers", RFC 1056, 06/01/1988.
+
+[RFC-PIPELINE] N. Freed, A. Cargille, "SMTP Service Extension for Command
+Pipelining", RFC 1854, 10/04/1995.
+
+[RFC-POP2] M. Butler, D. Chase, J. Goldberger, J. Postel, J. Reynolds,
+"Post Office Protocol - version 2", RFC 937, 02/01/1985
+
+[RFC-POP3] J. Myers, M. Rose, "Post Office Protocol - Version 3", RFC 1930,
+5/14/96 (Std 53).
+
+[RFC-REPLY] G. Vaudreuil, "Enhanced Mail System Status Codes", RFC 1893,
+01/15/1996.
+
+[RFC-SIZE] J. Klensin, N. Freed, K. Moore, "SMTP Service Extension for
+Message Size Declaration", RFC 1870, 11/06/1995. (STD 10)
+
+[RFC-X400] S. Hardcastle-Kille, "Mapping between X.400(1988) / ISO 10021
+and RFC 822", RFC 1327, 05/18/1992.
+
+[SMTPEXT] J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker, "SMTP
+Service Extensions", RFC-1869, 11/06/1995. (STD 10)
+
+[TCP] Postel, J., ed., "Transmission Control Protocol - DARPA Internet
+Program Protocol Specification", RFC 793, USC/Information Sciences
+Institute, NTIS AD Number A111091, September 1981.
+
+[US-ASCII] United States of America Standards Institute (now American
+National Standards Institute), X3.4, 1968, "USA Code for Information
+Interchange". ANSI X3.4-1968 has been replaced by newer versions with
+slight modifications, but the 1968 version remains definitive for the
+Internet.
+
+
+10. Editor's Address
+
+John C. Klensin
+MCI Communications
+800 Boylston St., 7th floor
+Boston, MA 02199
+USA
+Email: Klensin@mci.net
+Phone: +1 617 960 1011
+Fax:   +1 617 960 1009
+
+
+11. Acknowledgments
+
+Many people worked long and hard on the many iterations of this document.
+There was wide-ranging debate on the mailing list about many technical
+issues, and many contributors helped form the wording in this
+specification. The hundreds of participants in the many discussions since
+RFC 821 was produced are too numerous to mention, but they all helped this
+document become what it is.
+
+
+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, but not in SMTP commands or responses.
+
+
+B. Generating SMTP Commands from RFC 822 Headers
+ 
+Some systems use RFC 822 headers (only) in a mail submission protocol, or
+otherwise generate SMTP commands from RFC 822 headers 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 a mail envelopes is not separated early in
+processing from header information (and kept separate).
+
+It is recommended that the UA provide its initial 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 fields SHOULD then be removed from the
+   headers.  Once this process is completed, the remaining headers SHOULD
+   be checked to verify that at least one To:, Cc:, or Bcc: header remains.
+   If none do, then a bcc: header with no additional information SHOULD be
+   inserted as specified in [MSGFMT].
+
+2. The return address in the MAIL command SHOULD, if possible, be derived
+   from the system's identity for the submitting (local) user, and the From
+   header field otherwise.  If there is a system identity available, it
+   SHOULD also be copied to the Sender header field if it is different from
+   the address in the From header field.  (Any Sender field that was
+   already there SHOULD be removed.)  Systems may provide a way for
+   submitters to override the envelope return address, but may want to
+   restrict its use to privileged users.  This will not prevent mail
+   forgery, but may lessen its incidence; see section 7.1.
+
+When an MTA is being used in this way, it bears responsibility for ensuring
+that the message being transmitted is valid.  The mechanisms for checking
+that validity, and for handling (or returning) messages that are not valid
+at the time of arrival, are part of the MUA-MTA interface and not covered
+by this specification.
+
+A submission protocol based on Standard RFC 822 information alone MUST NOT
+be used to gateway a message from a foreign (non-SMTP) mail system into an
+SMTP environment.  Additional information to construct an envelope must
+come from some source in the other environment, whether supplemental
+headers or the foreign system's envelope.
+
+Attempts to gateway messages using only their header "to" and "cc" fields,
+have repeatedly caused mail loops and other behavior adverse to the proper
+functioning of the Internet mail environment.  These problems have been
+especially common when the message originates from an Internet mailing list
+and is distributed into the foreign environment using envelope information.
+When these messages are then processed by a header-only remailer, loops
+back to the Internet environment (and the mailing list) are almost
+inevitable.
+
+
+C. Source Routes
+
+The <reverse-path> is a reverse source routing list of hosts and a source
+mailbox.  The first host in the <reverse-path> SHOULD be the host sending
+the MAIL FROM command.  Similarly, the <forward-path> may be a source
+routing lists of hosts and a destination mailbox. However, in general, the
+<forward-path> SHOULD contain only a mailbox and domain name, relying on
+the domain name system to supply routing information if required.  The use
+of source routes is deprecated; while servers MUST be prepared to receive
+and handle them as discussed in section 3.3 and F.2, clients SHOULD NOT
+transmit them.
+
+For relay purposes, the forward-path may be a source route of the form
+"@ONE,@TWO:JOE@THREE", where ONE, TWO, and THREE MUST BE fully-qualified
+domain names.  This form is used to emphasize the distinction between an
+address and a route.  The mailbox is an absolute address, and the route is
+information about how to get there.  The two concepts should not be
+confused.
+
+If source routes are used, RFC 821 and the text below should be consulted
+for the mechanisms for constructing and updating the forward- and
+reverse-paths.
+
+The SMTP server transforms the command arguments by moving its own
+identifier (its domain name or that of any domain for which it is acting as
+a mail exchanger), if it appears, from the forward-path to the beginning of
+the reverse-path.
+
+Notice that the forward-path and reverse-path appear in the SMTP commands
+and replies, but not necessarily in the message.  That is, there is no need
+for these paths and especially this syntax to appear in the "To:" ,
+"From:", "CC:", etc. fields of the message header. Conversely, SMTP servers
+MUST NOT derive final message delivery information from message header
+fields.
+
+When the list of hosts is present, it is a "reverse" source route and
+indicates that the mail was relayed through each host on the list (the
+first host in the list was the most recent relay).  This list is used as a
+source route to return non-delivery notices to the sender. As each relay
+host adds itself to the beginning of the list, it MUST use its name as
+known in the transport environment to which it is relaying the mail rather
+than that of the transport environment from which the mail came (if they
+are different).
+
+
+D. Scenarios
+
+This section presents complete scenarios of several types of SMTP sessions.
+In the examples, "C:" indicates what is said by the SMTP client, and "S:"
+indicates what is said by the SMTP server.
+
+D.1 A Typical SMTP Transaction Scenario
+
+This SMTP example shows mail sent by Smith at host bar.com, to Jones,
+Green, and Brown at host foo.com.  Here we assume that host bar.com
+contacts host foo.com directly.  The mail is accepted for Jones and Brown.
+Green does not have a mailbox at host foo.com.
+
+   S: 220 foo.com Simple Mail Transfer Service Ready
+   C: EHLO bar.com
+   S: 250-foo.com greets bar.com
+   S: 250-8BITMIME
+   S: 250-SIZE
+   S: 250-DSN
+   S: 250 HELP
+   C: MAIL FROM:<Smith@bar.com>
+   S: 250 OK
+   C: RCPT TO:<Jones@foo.com>
+   S: 250 OK
+   C: RCPT TO:<Green@foo.com>
+   S: 550 No such user here
+   C: RCPT TO:<Brown@foo.com>
+   S: 250 OK
+   C: DATA
+   S: 354 Start mail input; end with <CRLF>.<CRLF>
+   C: Blah blah blah...
+   C: ...etc. etc. etc.
+   C: .
+   S: 250 OK
+   C: QUIT
+   S: 221 foo.com Service closing transmission channel
+
+D.2 Aborted SMTP Transaction Scenario
+
+   S: 220 foo.com Simple Mail Transfer Service Ready
+   C: EHLO bar.com
+   S: 250-foo.com greets bar.com
+   S: 250-8BITMIME
+   S: 250-SIZE
+   S: 250-DSN
+   S: 250 HELP
+   C: MAIL FROM:<Smith@bar.com>
+   S: 250 OK
+   C: RCPT TO:<Jones@foo.com>
+   S: 250 OK
+   C: RCPT TO:<Green@foo.com>
+   S: 550 No such user here
+   C: RSET
+   S: 250 OK
+   C: QUIT
+   S: 221 foo.com Service closing transmission channel
+
+D.3 Relayed Mail Scenario
+
+Step 1  --  Source Host to Relay Host
+
+   S: 220 foo.com Simple Mail Transfer Service Ready
+   C: EHLO bar.com
+   S: 250-foo.com greets bar.com
+   S: 250-8BITMIME
+   S: 250-SIZE
+   S: 250-DSN
+   S: 250 HELP
+   C: MAIL FROM:<JQP@bar.com>
+   S: 250 OK
+   C: RCPT TO:<@foo.com:Jones@XYZ.COM>
+   S: 250 OK
+   C: DATA
+   S: 354 Start mail input; end with <CRLF>.<CRLF>
+   C: Date: Thu, 21 May 1998 05:33:29 -0700
+   C: From: John Q. Public <JQP@bar.com>
+   C: Subject:  The Next Meeting of the Board
+   C: To: Jones@xyz.com
+   C:
+   C: Bill:
+   C: The next meeting of the board of directors will be
+   C: on Tuesday.
+   C:                         John.
+   C: .
+   S: 250 OK
+   C: QUIT
+   S: 221 foo.com Service closing transmission channel
+
+Step 2  --  Relay Host to Destination Host
+
+   S: 220 xyz.com Simple Mail Transfer Service Ready
+   C: EHLO foo.com
+   S: 250 xyz.com is on the air
+   C: MAIL FROM:<@foo.com:JQP@bar.com>
+   S: 250 OK
+   C: RCPT TO:<Jones@XYZ.COM>
+   S: 250 OK
+   C: DATA
+   S: 354 Start mail input; end with <CRLF>.<CRLF>
+   C: Received: from bar.com by foo.com ; Thu, 21 May 1998 05:33:29 -0700
+   C: Date: Thu, 21 May 1998 05:33:22 -0700
+   C: From: John Q. Public <JQP@bar.com>
+   C: Subject:  The Next Meeting of the Board
+   C: To: Jones@xyz.com
+   C:
+   C: Bill:
+   C: The next meeting of the board of directors will be
+   C: on Tuesday.
+   C:                         John.
+   C: .
+   S: 250 OK
+
+   C: QUIT
+   S: 221 foo.com Service closing transmission channel
+
+D.4 Verifying and Sending Scenario
+
+   S: 220 foo.com Simple Mail Transfer Service Ready
+   C: EHLO bar.com
+   S: 250-foo.com greets bar.com
+   S: 250-8BITMIME
+   S: 250-SIZE
+   S: 250-DSN
+   S: 250 HELP
+   C: VRFY Crispin
+   S: 250 Mark Crispin <Admin.MRC@foo.com>
+   C: SEND FROM:<EAK@bar.com>
+   S: 250 OK
+   C: RCPT TO:<Admin.MRC@foo.com>
+   S: 250 OK
+   C: DATA
+   S: 354 Start mail input; end with <CRLF>.<CRLF>
+   C: Blah blah blah...
+   C: ...etc. etc. etc.
+   C: .
+   S: 250 OK
+   C: QUIT
+   S: 221 foo.com Service closing transmission channel
+
+
+E. Other Gateway Issues
+
+In general, gateways between the Internet and other mail systems SHOULD
+attempt to preserve any layering semantics across the boundaries between
+the two mail systems involved.  Gateway- translation approaches that
+attempt to take shortcuts by mapping, (such as envelope information from
+one system to the message headers or body of another) have generally proven
+to be inadequate in important ways.  Systems translating between
+environments that do not support both envelopes and headers and Internet
+mail must be written with the understanding that some information loss is
+almost inevitable.
+
+
+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 is strongly preferred to HELO
+when the server will accept the former.  Servers must continue to accept
+and process HELO in order to support older clients.
+
+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 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.
+
+
+X. Change Summary and Loose Ends (Temporary)
+
+X.1 Change summary
+
+X.1.1 Substantive changes between draft-ietf-drums-smtpupd-00.txt and
+draft-ietf-drums-smtpupd-01.txt
+
+(i) Slightly clarified the discussions of rejection and failure of VRFY
+requests and the associated response codes.
+
+(ii) Slightly clarified the discussion of deferred address validation.
+
+(iii) Removed the IPCE terminology and modified the text in section 4.1.1.2
+to explicitly introduce the "mail gateway" terminology and to begin to
+distinguish a mail gateway from a conventional relay.
+
+(iv) Explicitly noted that SMTP clients for things like POP and IMAP may
+send everything to a single relay for further processing, rather than
+resolving final domain names.
+
+(v) Tightened the RSET discussion.
+
+(vi) Deprecation of 251 only for RCPT (still ok for VRFY)
+
+X.1.2.  Substantive changes between draft-ietf-drums-smtpupd-01.txt and
+draft-ietf-drums-smtpupd-02.txt.
+
+Incorporated additional RFC 1123 material; reorganized several sections for
+clarity.  Added definitions and other previous "loose end" material.
+
+X.1.3.  Substantive changes between draft-ietf-drums-smtpupd-02.txt and
+draft-ietf-drums-smtpupd-03.txt.
+
+(i) Eliminated a number of placeholders and tightened some of the
+definitions in section 2.  Added a few new placeholders for consistency
+checking against other documents.
+
+(ii) Removed the state diagrams, per direction at IETF Montreal.
+
+(iii) Added new section 6.3, an attempt to summarize WG discussions on the
+"posting" versus "delivery" versus "relay" functions of SMTP and on whether
+"fixups" are appropriate in different cases.
+
+(iv) Inserted section 6.1, a minor rewrite of section 5.3.3 of RFC1123.
+
+(v) Added new text to 3.5.5 to discuss the spammer - EXPN relationship.
+
+(vi) The "ASCII requirement" in 4.1.1.4 has been tightened somewhat.
+
+(v) The remaining miscellaneous changes agreed to in Montreal have been
+incorporated except as noted below.
+
+X.1.4.  Substantive changes between draft-ietf-drums-smtpupd-03.txt and
+draft-ietf-drums-smtpupd-04.txt.
+
+Many small changes have been made between these two versions; the list that
+follows is not exhaustive.
+
+(i) To clarify some of the text, definitions have been introduced to
+distinguish among originating, delivery, relay, and gateway SMTP systems.
+
+(ii) The role of LF-terminated lines has been clarified.
+
+(iii) Several changes have been made to clarify the principle that, no
+matter what originating and final delivery systems might do, relay systems
+are not permitted to tamper with message content, even to "fix" headers
+that are determined to be invalid.  If they deem message content to be
+seriously unacceptable, they are encouraged to reject the messages in
+preference to trying to fix them up, but, in general, the theme is "don't
+look/ don't tell".
+
+(iv) A few more definitions have been added to the terminology section, and
+the separate glossary has been eliminated.
+
+(v) I have taken a shot at text to address some of the controversies that
+have raged on the WG mailing list (e.g., sections 7.4 and 7.5). Since there
+was no consensus on most of those topics, I expect that the inserted text
+will satisfy no one except, perhaps, for agreement that saying nothing
+would have been worse.  As a mechanism for moving forward, the text in
+these controversial areas that now appears will be considered "base";
+alterations will be made only if clear consensus emerges.
+
+(vi) Per discussion in Los Angeles, source routes have been further
+deprecated.
+
+(vii) Some of the VRFY/EXPN materials have been moved to "security
+considerations", where they appear to belong, some text has been added, and
+the conformance statements adjusted to reflect what I perceive to be WG
+consensus.
+
+(viii) New MX resolution material has been added to section 5.  While most
+of this material is from RFC974, the rules have been further tightened to
+reflect current practice and experience (974 is written in a somewhat
+speculative fashion for a standard).  In particular, the behavior of trying
+the target host's A RR when MXs existed but all of them were eliminated is
+now prohibited, which seems necessary if another of other ideas being
+recommended or considered are to be feasible.
+
+X.1.5.  Substantive changes between draft-ietf-drums-smtpupd-04.txt and
+draft-ietf-drums-smtpupd-05.txt.
+
+(i) All normative references to RFC 1123 have been removed from the main
+body of the text (some still appear in the appendices where they will
+remain).
+
+(ii) Section 3.5 has been renamed slightly to distinguish between
+"debugging of SMTP implementations" and "debugging of addresses". Better
+terminology would be welcome.
+
+(iii) Error conditions resulting from the DATA command have been clarified.
+
+(iv) Section 4.2 (SMTP replies) has been revised and tightened to reflect
+reality and recent discussion on the list.
+
+(v) Appendix E has been revised a bit and moved into section 4.2.1. Given
+the importance of the "check only first digit" rule, it has to be there.
+
+(vi) Added new text for "no SMTP service supported" to sections 3.1, 4.2.2,
+4.2.3, and 4.3.2.  As noted in 3.1, I'd rather add 521 (which would work
+perfectly with the model) rather than overloading 554.
+
+(vii) The Return-path language in section 4.4 has been cleaned up a bit.
+
+(viii) Tightened the "postmaster" language in 4.5.1, requiring a small
+change to 4.1.1.3.
+
+(ix) I have unilaterally (with a little help from my friends), increased
+some of the size limits.  64 was much too short for a domain name, and the
+DNS limit of 255 (?) has now been inserted. That leaves the return path
+much too short, but I haven't fixed it (maybe that will cause us to get rid
+of them).  We still have a 64 character limit on the local-part, which is
+also *much* too short. Votes for 128 or longer limits accepted.  See
+X.1.6(I)
+
+(x) The text on the "recipients buffer" has been rewritten so that (I hope)
+it makes sense and gives some explicit guidance for how clients and servers
+should proceed if limits are imposed.
+
+X.1.6.  Substantive changes between draft-ietf-drums-smtpupd-05.txt and
+draft-ietf-drums-smtpupd-06.txt.
+
+Most of the changes in this revision have been editorial rather than
+substantive.  Major substantive changes include:
+
+(i)  The language about maximum sizes of SMTP command lines has been
+reworked, per WG mailing list discussion.
+
+(ii)  Several instances of  "Should" have been promoted to "Must" when the
+reasons for the weaker rule seemed to have disappeared.  In particular, the
+requirement that an SMTP implementation support timeouts has become a MUST.
+Also, conformance to this specification requires support of EHLO.  Older
+systems should claim conformance to the [to-be-historical] 821, not this
+specification.
+
+X.1.7.  Substantive changes between draft-ietf-drums-smtpupd-06.txt and
+draft-ietf-drums-smtpupd-07.txt.
+
+(i) Removed "implied RSET" text associated with QUIT, as specified at the
+December 1997 IETF
+
+(ii) Required that servers support EHLO, as specified at the December 1997
+IETF
+
+X.1.8. Substantive changes between draft-ietf-drums-smtpupd-07.txt and
+draft-ietf-drums-smtpupd-08.txt.
+
+This version involves mostly editorial work and cleanup of loose ends.
+
+(i) New 7.5 added (old one renumbered) to discuss info disclosure through
+Received fields.
+
+(ii) Some character set and minor syntax issues clarified.
+
+(iii) Material on code 571 added (thought this had been done long ago;
+slipped through the cracks)
+
+(iv) Many clarifications added as the result of list discussions and
+suggestions.
+
+(v) Error code presentation has been restructured.
+
+(vi) ABNF conversion done
+
+(vii) IPv6 address format inserted per RFC 1884, since we could not get
+clear agreement on an alternative.
+
+(viii) Trivial, silly, examples removed.  Others not yet renumbered.
+
+(ix) 3.5.2 and 4.1.1 altered slightly per Eric Allman's notes.  Eric may
+not like the way I've done either of these change very much: the first now
+makes the distinction between returning an address and returning other
+stuff (which was permitted by -06, but the text wasn't as clear as it
+should have been): if it looks like an address, it needs to be an address.
+Similarly, with 4.1.1, Eric wanted to explicitly permit/legitimize "DATA
+<SP> <CRLF>".  I see several disadvantages to doing that, so have inserted
+language that encourages receivers to tolerate trailing white space, which
+may have the same practical effect.
+
+
+X.1.9. Substantive changes between draft-ietf-drums-smtpupd-08.txt and
+draft-ietf-drums-smtpupd-09.txt.
+
+The first ten of these reflect, in order, minuted items from the Chicago
+IETF (IETF 42).
+
+(i) Clarification of "MUST", etc., in the context of this document
+(section 2.3).
+
+(ii) Altered VRFY text to make implementation a SHOULD (section 3.5.1) and
+removed VRFY from the mandatory to implement list (section 4.5.1), per
+42nd IETF (Chicago).
+
+(iii) Clarified that exploders are expected to not purge sender addresses
+from lists (section 3.10).  Note that the Chicago conclusion was that this
+should be a "MUST".  I could not figure out how to do that without
+absolutely prohibiting removing addresses to prevent loops, to guard
+against spammers, or for similar legitimate purposes.  So I have written
+this as a "SHOULD", with additional "strongly discouraged" words.   If
+someone still wants a MUST, suggest text.
+
+(iv) Altered text to permit clients that sometimes, or even always,
+initiate sessions with HELO, rather than EHLO, to be fully-conforming
+(section 3.2).  [[ Editor's note: I continue to believe that a client that
+does not have any service extension support, even to the extent of being
+able to send EHLO and parse the response without doing anything about it,
+should not be considered fully-conforming to this spec (as distinct from
+821).   Consequently, the new text in 3.2 stops well short of encouraging
+clients that don't need service extensions from preferentially using HELO,
+and the text in 2.2.1 (which specifies that the extension mechanisms must
+be supported) has not been changed.
+
+(v) Per Chicago discussions, the text requiring that QUIT be sent has not
+been changed.  The text in 4.1.1.10 requiring that the server wait for
+QUIT has been changed to a SHOULD.  However, the text in 4.1.1.5,
+prohibiting close on receipt of RSET and that elsewhere prohibiting close
+as a normal response, has not been changed.
+
+(vi) Text has been inserted in 4.1.1 and the text in 4.3.2 altered
+slightly to clarify the handling of parameters to RSET, DATA, and QUIT and
+to 4.1.1.9 specify semantics for parameters to NOOP.  I have followed the
+minutes on this although I personally agree with kre's mailing list
+comments that the "servers SHOULD reject" decision leads to silly states.
+I recommend that the WG review this.
+
+(vii) Per discussion in Chicago, no substantive change has been made to
+the specification about underscore characters in domain names (section
+4.1.2).  However, the text has been altered to more accurately reflect
+discussion on the mailing list and the source of the requirement.
+
+(viii) Per discussion in Chicago, no change has been made to the
+preference for local time in Received headers.
+
+(ix) Per discussion in Chicago, code 571 has been removed and policy
+rejection is now reflected i a 550 code (section 3.7 and the response code
+lists).
+
+(x)  Per discussion in Chicago, no change has been made to the
+specification of use of raw CR or LF.
+
+(xi) In section 4.3, the text has been changed, per comments from Dan
+Bernstein and others, to require that clients be able to handle replies
+that do not contain text strings. A few other places patched to match.
+
+(xii) In sections 4.1.1.1 and 8, the placeholders have been removed.
+
+(xiii) Per discussion on the mailing list (and specifically James
+Berriman's concerns), the text has been clarified (sections 4.1.1.2 and
+4.1.4) to prohibit MAIL unless no mail transaction is open.  This is a
+MUST NOT prohibition -- SHOULD NOT makes no sense if this is the direction
+we are going to go.  503 has also been added to the list of valid
+responses for "MAIL" in 4.3.1 - it can't be issued before EHLO/HELO in any
+event.  While it is clear that something should be said, this may not be
+the desired outcome (I selected it because it was conservative and easy
+given the text that was there already); the WG should check that the text
+is as intended.
+
+(xiv) Per discussion on the mailing list, a new section 4.5.5 has been
+added to describe null return paths and their handling (forward pointer
+from 3.7).  The text in 4.5.5 is substantially that suggested by Norbert
+Bollow.   As with (xiii), there is now clear text, but it may not be what
+the WG desires.  Please check.
+
+(xv) "all addresses" substituted for "each...in turn" in 3.10.2.
+
+(xvi) Requirement for "<" and ">" around paths clarified in section 3.3
+(syntax productions were clear and correct, but not this overview
+material).
+
+(xvii) Clarified text in 3.3 to permit post-DATA bounces on policy
+matters. 
+
+
+X.1.10. Substantive changes between draft-ietf-drums-smtpupd-09.txt
+and draft-ietf-drums-smtpupd-10.txt.
+
+(i) A large series of typos, most of them caught by Philip Hazel,
+corrected. 
+
+(ii) Residual problems with references to mailboxes, forward, and
+reverse paths in 4.1.1.2 and 4.1.1.3 corrected and some text, I hope,
+clarified.
+
+(iii) Text added to 4.2.5 to talk about 5yz errors after DATA.  This
+text should be checked carefully -- it is a proposal and may or may
+not reflect WG consensus.
+
+(iv) Upper bound on "seconds" has been changed to 60 (not 61), per
+list discussion.  Years are still four-digits and will stay that way
+unless the list discussion converges on something else.  The increase
+to 60 seconds includes an explicit note about leap seconds.
+
+(v) Text has been inserted to reflect the Orlando consensus about "QUIT",
+i.e., the client MUST send a QUIT command and SHOULD wait for the results
+before closing the connection.  Servers are still not permitted to close
+without receiving a QUIT and sending a 221 response (except, of course,
+under the usual "unavoidable circumstances", in which case they should get
+off a 451 if that is feasible).
+
+(vi) The EHLO response specification has been changed back to reflect
+non-advertisement of VRFY and some text implying that VRFY was optional to
+support has been removed (WG consensus seemed to be moving in that
+direction at one point, and the editor reacted prematurely).  This makes
+the text compatible with RFC1869 and restores VRFY to its RFC1123 status.
+
+(vii) The text in section 5 has been clarified with regard to what a relay
+that receives a message because of its designation as an MX can do and 3.7
+has been slightly modified to point to it.
+
+(viii) New text has been added to 3.7 to clarify the use of "SMTP server"
+relays in "dumb" originating clients.
+
+(viii) Small wording changes inserted into 4.1.4 (e.g., insertion of ", if
+possible," into the first sentence of the fifth paragraph to eliminate the
+apparent conflict with the second sentence).
+
+
+Z.  Full Copyright Statement
+
+Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+This document and translations of it may be copied and furnished to others,
+and derivative works that comment on or otherwise explain it or assist in
+its implementation may be prepared, copied, published and distributed, in
+whole or in part, without restriction of any kind, provided that the above
+copyright notice and this paragraph are included on all such copies and
+derivative works.  However, this document itself may not be modified in any
+way, such as by removing the copyright notice or references to the Internet
+Society or other Internet organizations, except as needed for the purpose
+of developing Internet standards in which case the procedures for
+copyrights defined in the Internet Standards process must be followed, or
+as required to translate it into languages other than English.
+
+The limited permissions granted above are perpetual and will not be revoked
+by the Internet Society or its successors or assigns.
+
+This document and the information contained herein is provided on an "AS
+IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE
+DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
+ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY
+RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
+PARTICULAR PURPOSE.
+
+Expires July 1999
diff --git a/Documentation/en/I-D/draft-ietf-drums-smtpupd-12.txt b/Documentation/en/I-D/draft-ietf-drums-smtpupd-12.txt
new file mode 100644
index 00000000..e57ab185
--- /dev/null
+++ b/Documentation/en/I-D/draft-ietf-drums-smtpupd-12.txt
@@ -0,0 +1,4076 @@
+INTERNET-DRAFT                                John C. Klensin, Editor
+Expires December 2000
+July 10, 2000
+
+
+                  Simple Mail Transfer Protocol
+
+                 draft-ietf-drums-smtpupd-12.txt
+
+Status of this Memo
+
+This document is an Internet-Draft and is in full conformance with
+all provisions of Section 10 of RFC2026.
+
+Internet-Drafts are working documents of the Internet Engineering
+Task Force (IETF), its areas, and its working groups.  Note that
+other groups may also distribute working documents as Internet-Drafts.
+
+Internet-Drafts are draft documents valid for a maximum of six months
+and may be updated, replaced, or obsoleted by other documents at any
+time.  It is inappropriate to use Internet-Drafts as reference
+material or to cite them other than as "work in progress."
+
+The list of current Internet-Drafts can be accessed at
+http://www.ietf.org/ietf/1id-abstracts.txt
+
+The list of Internet-Draft Shadow Directories can be accessed at
+http://www.ietf.org/shadow.html.
+
+[[Appendix X will be removed before the document is submitted to the
+IESG.]]
+
+[[If consensus is reached on this document, it will be forwarded to the
+IESG with the recommendation that it be processed onto the Standards
+track.]]
+
+Copyright Notice
+
+Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+                           Table of Contents
+
+0. Abstract
+
+1. Introduction
+
+2. The SMTP Model
+2.1 Basic Structure
+2.2 The Extension Model
+2.2.1 Background
+2.2.2 Definition and Registration of Extensions
+2.3 Terminology
+2.3.1 Mail Objects
+2.3.2 Senders and Receivers
+2.3.3 Mail Agents and Message Stores
+2.3.4 Host
+2.3.5 Domain
+2.3.6 Buffer and State Table
+2.3.7 Lines
+2.3.8 Originator, Delivery, Relay, and Gateway Systems
+2.3.9 Message Content and Mail Data
+2.3.10 Mailbox and Address
+2.3.11 Reply
+2.4 General Syntax Principles and Transaction Model
+
+3. The SMTP Procedures: An Overview
+3.1 Session Initiation
+3.2 Client Initiation
+3.3 Mail Transactions
+3.4 Forwarding for Address Correction or Updating
+3.5 Commands for Debugging Addresses
+3.5.1 Overview
+3.5.2 VRFY Normal Response
+3.5.3 Meaning of VRFY or EXPN Success Response
+3.5.4 Semantics and Applications of EXPN
+3.6 Domains
+3.7 Relaying
+3.8 Mail Gatewaying
+3.8.1 Header Fields in Gatewaying
+3.8.2 Received Lines in Gatewaying
+3.8.3 Addresses in Gatewaying
+3.8.4 Other Header Fields in Gatewaying
+3.8.5 Envelopes in Gatewaying
+3.9 Terminating Sessions and Connections
+3.10 Mailing Lists and Aliases
+3.10.1 Alias
+3.10.2 List
+
+4. The SMTP Specifications
+4.1 SMTP Commands
+4.1.1 Command Semantics and Syntax
+4.1.1.1  Extended HELLO (EHLO) or HELLO (HELO)
+4.1.1.2 MAIL (MAIL)
+4.1.1.3 RECIPIENT (RCPT)
+4.1.1.4 DATA (DATA)
+4.1.1.5 RESET (RSET)
+4.1.1.6 VERIFY (VRFY)
+4.1.1.7 EXPAND (EXPN)
+4.1.1.8 HELP (HELP)
+4.1.1.9 NOOP (NOOP)
+4.1.1.10 QUIT (QUIT)
+4.1.2 Command Argument Syntax
+4.1.3 Address Literals
+4.1.4 Order of Commands
+4.1.5 Private-use Commands
+4.2  SMTP Replies
+4.2.1 Reply Code Severities and Theory
+4.2.2 Reply Codes by Function Groups
+4.2.3  Reply Codes in Numeric Order
+4.2.4 Reply Code 502
+4.2.5 Reply Codes After DATA and the Subsequent <CRLF>.<CRLF>
+4.3 Sequencing of Commands and Replies
+4.3.1 Sequencing Overview
+4.3.2 Command-Reply Sequences
+4.4 Trace Information
+4.5 Additional Implementation Issues
+4.5.1 Minimum Implementation
+4.5.2 Transparency
+4.5.3 Sizes and Timeouts
+4.5.3.1 Size limits and minimums
+4.5.3.2 Timeouts
+4.5.4 Retry Strategies
+4.5.4.1 Sending Strategy
+4.5.4.2 Receiving Strategy
+4.5.5 Messages with a null reverse-path
+
+5. Address Resolution and Mail Handling
+
+6. Problem Detection and Handling
+6.1 Reliable Delivery and Replies by Email
+6.2 Loop Detection
+6.3 Compensating for Irregularities
+
+7. Security Considerations
+7.1 Mail Security and Spoofing
+7.2 "Blind" Copies
+7.3 VRFY, EXPN, and Security
+7.4 Information Disclosure in Announcements
+7.5 Information Disclosure in Trace Fields
+7.6 Information Disclosure in Message Forwarding
+7.7 Scope of Operation of SMTP Servers
+
+8. IANA Considerations
+
+9. References
+
+10. Editors' Addresses
+
+11. Acknowledgments
+
+Appendices
+A. TCP Transport Service
+B. Generating SMTP Commands from RFC 822 Headers
+C. Source Routes
+D. Scenarios
+E. Other Gateway Issues
+F. Deprecated Features of RFC 821
+X. Change Summary and Loose Ends (Temporary)
+
+
+0. Abstract
+
+This document is a self-contained specification of the basic protocol for
+the Internet electronic mail transport, consolidating and updating:
+
+ - the original SMTP specification of RFC 821 [RFC-821],
+
+ - domain name system requirements and implications for mail transport from
+   RFC 1035 [RFC-DNS] and RFC 974 [RFC-974],
+
+ - the clarifications and applicability statements in RFC 1123 [RFC-1123],
+   and
+
+ - material drawn from the SMTP Extension mechanisms [SMTPEXT].
+
+It replaces RFC 821, RFC 974, and 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 turned up 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 POP [RFC-POP2, RFC-POP3]
+and IMAP [RFC-IMAP4].  Additional submission issues are discussed in RFC
+2476 [SUBMIT].
+
+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 [MSGFMT] discusses message headers, message bodies
+and formats and structures for them, and their relationship.
+
+Comments on this draft should be addressed to the IETF DRUMS Working
+Group:
+	 General Discussion:drums@cs.utk.edu
+	 To Subscribe: drums-request@cs.utk.edu
+	 Archive: ftp://cs.utk.edu/pub/drums/mail-archive/
+
+
+
+1. Introduction
+
+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 describe some of them.
+
+An important feature of SMTP is its capability to transport mail across
+networks, usually referred to as "SMTP mail relaying" (see section 3.8).
+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-DNS, and
+section 5 of this document] are used to identify the appropriate next-hop
+destination for a message being transported.
+
+
+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 domain name(s) to which mail messages are to be
+transferred is a local matter, and is not addressed by this document. In
+some cases, the domain name(s) transferred to, or 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-POP2, RFC-POP3] or IMAP [RFC-IMAP4] protocols, or when the SMTP client
+is inside an isolated transport service environment, the domain name
+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 domain names 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.
+
+The means by which an SMTP client, once it has determined a target domain
+name, 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, a formal
+handoff of responsibility for the message occurs: the protocol requires
+that a server accept responsibility for either delivering a message or
+properly reporting the failure to do so.
+
+Once the transmission channel is established and initial handshaking
+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 headers 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 extension
+requests such as in [RFC-Pipeline].
+
+Once a given mail message has been transmitted, the client may either
+request that the connection be shut down or may initiate other mail
+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.  This transmission normally occurs 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.
+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 appendices C and 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 added, it must be done in
+a way that permits older implementations to continue working acceptably.
+The extension framework consists of:
+
+ - The SMTP command EHLO, superseding the earlier HELO,
+
+ - a registry of SMTP service extensions,
+
+ - additional parameters to the SMTP MAIL and RCPT commands, and
+
+ - optional replacements for commands defined in this protocol, such as for
+   DATA (see [RFC-BDAT]).
+
+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:
+
+ - the textual name of the SMTP service extension;
+
+ - the EHLO keyword value associated with the extension;
+
+ - the syntax and possible values of parameters associated with the
+   EHLO keyword value;
+
+ - any additional SMTP verbs associated with the extension (additional
+   verbs will usually be, but are not required to be, the same as the
+   EHLO keyword value);
+
+ - any new parameters the extension associates with the MAIL or RCPT
+   verbs;
+
+ - a description of how support for the extension affects the behavior
+   of a server and client SMTP; and,
+
+ - the increment by which the extension is increasing the maximum
+   length of the commands MAIL and/or RCPT, over that specified
+   in this standard.
+
+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.3 Terminology
+
+Most of the terminology in this document is common in the Internet at the
+time of its writing.  However, the following terms and concepts are used
+in special ways here, or represent differences in terminology between RFC
+821 and this document, and should be understood before reading further.
+These definitions are normative, that is, they contain specifications to
+which SMTP implementations are required to conform.
+
+The terms "MUST" and "SHOULD" (and "MUST NOT" and "SHOULD NOT") are
+used in the same general sense here as in the Host Requirements
+Standards [RFC-1123].  Specifically, "MUST" or "MUST NOT" identify
+absolute requirements for conformance to this specification.
+Implementations that do not conform to them lie outside the scope of
+this specification and often will not interoperate properly with SMTP
+implementations that do conform.  Implementations that are fully
+conforming also adhere to all "SHOULD" and "SHOULD NOT" requirements.
+Implementations that adhere to all "MUST" ("MUST NOT") but not to all
+of these are considered to be partially conforming.  Such
+implementations may interoperate properly with fully conforming ones
+and with each other, but this will typically be the case only if great
+care is taken.  Consequently, an implementation should violate "SHOULD"
+("SHOULD NOT") requirements only under exceptional and well-understood
+circumstances. "SHOULD" (and sometimes "MUST") requirements are often
+imposed by this specification when experience has shown that following
+such requirements or restrictions leads, in practice, to better
+interoperation, or smoother operation of the Internet email
+infrastructure. As a consequence, some of these statements constitute
+recommended practices, rather than the statistically most common
+practice at the time of this writing.  Statements using "MAY" describe
+features or styles of doing things that may be followed, or not, at the
+discretion of the implementation, normally without causing significant
+interoperability problems.
+
+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 which error
+reports should be directed); one or more recipient addresses; and optional
+protocol extension material.  Historically, variations on the recipient
+address specification command (RCPT TO) could be used to specify alternate
+delivery modes, such as immediate display; those variations have now been
+deprecated (see appendix F, section F.6).
+
+The SMTP content is sent in the SMTP DATA protocol unit and has two
+parts: the headers and the body. If the content conforms to other
+contemporary standards, the headers form a collection of field/value
+pairs structured as described in [MSGFMT]; the body, if structured, is
+defined according to MIME [RFC-MIME]. The content is textual in nature,
+expressed using the US-ASCII repertoire [US-ASCII]. Although SMTP
+extensions (such as [8BitMIME]) may relax this restriction for the
+content body, the content headers are always encoded using the US-ASCII
+repertoire. The algorithm defined in [RFC-INTLHDR] is used to represent
+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 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 "domain"); identifying them by numerical address is discouraged.
+
+2.3.5 Domain
+
+A domain (or domain name) consists of one or more dot-separated
+components.  These components ("labels" in DNS terminology [RFC-DNS]
+are restricted for SMTP purposes to consist of a sequence of letters,
+digits, and hyphens drawn from the ASCII character set [US-ASCII].
+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-DNS] and
+section 5.
+
+The domain name, as described in this document and in [RFC-DNS], 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.
+
+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 which 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 Lines
+
+SMTP commands and, unless altered by a service extension, message data,
+are transmitted in "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.5.3).
+
+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.
+
+2.3.8 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 which 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 [IAB-Firewalls].)
+
+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 message headers and the
+possibly-structured message body.  The MIME specification [RFC-MIME]
+provides the standard mechanisms for structured message bodies.
+
+2.3.10 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 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.3.11 Reply
+
+An SMTP reply is an acknowledgment (positive or negative) sent 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.  Recent work [RFC-Reply] has specified further structuring
+of the reply strings, including the use of supplemental and more
+specific completion codes.
+
+2.4 General Syntax Principles and Transaction Model
+
+SMTP commands and replies have a rigid syntax. All commands begin with
+a four letter command verb. All Replies begin with a three digit
+numeric code. In some commands and replies, arguments MUST follow 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 MAIL 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.  This is NOT
+true of a mailbox local-part.  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.  Mailbox domains are
+not case sensitive.  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.
+
+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 field 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 [US-ASCII]. 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 seven bit
+transport only.  An originating SMTP client which has not successfully
+negotiated an appropriate extension with a particular server 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 ultimate delivery of a severely garbled message to the
+recipient.  Delivery SMTP systems MAY reject ("bounce") such messages
+rather than deliver them.  No sending SMTP system is 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.
+
+Eight-bit message content transmission MAY be requested of the server
+by a client using extended SMTP facilities, notably the "8BITMIME"
+extension [8BITMIME].  8BITMIME SHOULD be supported by SMTP servers.
+However, it MUST not be construed as authorization to transmit
+unrestricted eight bit material.  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 [ABNF].
+Metalanguage terms used in running text are surrounded by pointed
+brackets (e.g., <CRLF>) for clarity.
+
+
+3. The SMTP Procedures: An Overview
+
+This section contains descriptions of the procedures used in SMTP:
+session initiation, the mail transaction, forwarding mail, verifying
+mailbox names and expanding mailing lists, and the opening and closing
+exchanges.  Comments on relaying, a note on mail domains, and a
+discussion of changing roles are included at the end of this section.
+Several complete scenarios are presented in appendix D.
+
+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.5.1).
+
+The SMTP protocol allows a server to formally reject a transaction
+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 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 which are unable to support
+service extensions and contemporary clients which 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").
+
+3.3 Mail Transactions
+
+There are three steps to SMTP mail transactions.  The transaction
+starts with a MAIL command which gives the sender identification.  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> can 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.
+
+   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 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).  This
+step of the procedure can be repeated any number of times.
+
+The <forward-path> can contain more than just a mailbox.  Historically,
+the <forward-path> can be 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 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).
+
+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
+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), or 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.  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 RFC 822 format is being used, the mail data include the memo
+header items such as Date, Subject, To, Cc, From [MSGFMT].  Server SMTP
+systems SHOULD NOT reject messages based on perceived defects in the
+RFC 822 or MIME [RFC-MIME] message header or message body.  In
+particular, they MUST NOT reject messages in which the numbers of
+Resent- 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 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 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.
+
+In particular:
+
+* 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.  But,
+  if a 251 code is used, they MUST NOT assume that the client will actually
+  update address information or even return that information to the user.
+
+Alternately,
+
+* Servers MAY reject or bounce messages when they are not deliverable when
+  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.  But, if a 551 code
+  is used, they MUST NOT assume that the client will actually update
+  address information or even return that information to the user.
+
+SMTP server implementations that support the 251 and/or 551 reply codes are
+strongly encouraged to provide configuration mechanisms so that sites which
+conclude 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 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
+
+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
+response 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-REPLY], 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 of one
+mailbox.  If a request is made to verify 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 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 normally includes the mailbox name, i.e.,
+"<local-part@domain>", where "domain" is a fully qualified domain name,
+MUST appear in the syntax.  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 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.  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, they MUST be listed as service
+extensions in an EHLO response, if they are supported.
+
+3.5.3 Meaning of VRFY or EXPN Success Response
+
+A server MUST NOT return a 220 code in response to a VRFY or EXPN
+command unless it has actually verified the address.  In particular, a
+server MUST NOT return 220 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 discussed 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 bounced 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.
+
+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, and mail systems SHOULD NOT attempt them.
+
+3.6 Domains
+
+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 A RRs (as discussed in section 5) are permitted,
+as are CNAME RRs whose targets can be resolved, in turn, to MX or A
+RRs.  Local nicknames or unqualified names MUST NOT be used.  There are
+two exceptions to the rule requiring FQDNs:
+
+ - The domain name given in the EHLO command MUST BE either a primary
+   host name (a domain name that resolves to an A RR) or, if the host
+   has no name, an address literal as described in section 4.1.1.1.
+
+ - The reserved mailbox name "postmaster" may be used in a RCPT command
+   without domain qualification (see section 4.1.1.3) and MUST be
+   accepted if so used.
+
+3.7 Relaying
+
+In general, the availability of Mail eXchanger records in the domain
+name system [RFC-DNS, RFC-974] makes the use of explicit source routes
+in the Internet mail system unnecessary.  Many historical problems with
+their interpretation 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 are also permitted to 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.
+
+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 relay mail to a
+particular address for policy reasons, a 550 response SHOULD be
+returned.
+
+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, and work is underway on standardized mail submission protocols
+that might eventually supercede the current practices.  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 which
+act as gateways into other environments, not just SMTP relays and final
+delivery systems; see sections 3.8 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-NOTARY1]) 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 section 4.5.5 for
+additional discussion).  A MAIL command with a null reverse-path
+appears as follows:
+
+   MAIL FROM:<>
+
+As discussed in section 2.4.1, a relay SMTP has no need to inspect or
+act upon the headers or body of the message data and MUST NOT do so
+except to add its own "Received:" header (section 4.4) and, optionally,
+to attempt to detect looping in the mail system (see section 6.2).
+
+3.8 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.8, 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.8.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 2.4.1
+
+Other mail systems gatewayed to the Internet often use a subset of
+RFC-822 headers 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.  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).
+
+3.8.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.
+
+"Received:" 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 fields arising in
+non-SMTP environments, receiving systems MUST NOT reject mail based on
+the format of a trace field and SHOULD be extremely robust in the light
+of unexpected information or formats in those fields.
+
+The gateway SHOULD indicate the environment and protocol in the "via"
+clauses of Received field(s) that it supplies.
+
+3.8.3 Addresses in Gatewaying
+
+>From the Internet side, the gateway SHOULD accept all valid address
+formats in SMTP commands and in RFC-822 headers, and all valid RFC-822
+messages.  Addresses and headers generated by gateways MUST conform to
+applicable Internet standards (including this one and RFC-822).
+Gateways are, of course, subject to the same rules for handling source
+routes as those described for other SMTP systems in section 3.3.
+
+3.8.4 Other Header Fields in Gatewaying
+
+The gateway MUST ensure that all header fields of a message that it
+forwards into the Internet mail environment meet the requirements for
+Internet mail.  In particular, all addresses in "From:", "To:",
+"Cc:", etc., fields MUST be transformed (if necessary) to satisfy
+RFC-822 syntax, MUST reference only fully-qualified domain names, and
+MUST be effective and useful for sending replies.  The translation
+algorithm used to convert mail from the Internet protocols to another
+environment's protocol SHOULD ensure that error messages from the
+foreign mail environment are delivered to the return path from the
+SMTP envelope, not to the sender listed in the "From:" field (or
+other fields) of the RFC-822 message.
+
+3.8.5 Envelopes in Gatewaying
+
+Similarly, when forwarding a message from another environment into the
+Internet, the gateway SHOULD set the envelope return path 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.9 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 except:
+
+ - After receiving a QUIT command and responding with a 221 reply.
+
+ - After detecting the need to shutdown the SMTP service and returning
+   a 421 response code.  This response code can be issued after the
+   server receives any command or, if necessary, asynchronously from
+   command receipt (on the assumption that the client will receive it
+   after the next command is issued).
+
+In particular, a server that closes connections in response to commands
+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 which 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.
+
+3.10 Mailing Lists and Aliases
+
+An SMTP-capable host SHOULD support both the alias and the list models
+of address expansion for multiple delivery.  When a message is
+delivered or forwarded to each address of an expanded list 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 (see [MSGFMT]) MUST be left unchanged;
+in particular, the "From" field of the message header 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.10.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.10.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 all of the expanded
+addresses.  The return 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.
+
+
+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 are encouraged to
+tolerate trailing white space before the terminating <CRLF>.)  The
+syntax of the local part of a mailbox must conform to receiver site
+conventions and the syntax specified in section 4.1.2.  The SMTP
+commands are discussed below.  The SMTP replies are discussed in
+section 4.2.
+
+A mail transaction involves several data objects which 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 which
+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 field 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 available),
+the client SHOULD send an address literal (see section 4.1.3),
+optionally followed by information that will help to identify the
+client system.
+
+The SMTP server identifies itself to the SMTP client in the connection
+greeting reply and in the response to this command.
+
+A client SMTP SHOULD start an SMTP session by issuing the EHLO command.
+If the SMTP server supports the SMTP service extensions it will give a
+successful response, a failure response, or an error response. If the
+SMTP server, in violation of this specification, does not support any
+SMTP service extensions it will generate an error response.  Older
+client SMTP systems MAY, as discussed above, use HELO (as specified in
+RFC 821) instead of EHLO, and servers MUST support the HELO command and
+reply properly to it.  In any event, a client MUST issue HELO or EHLO
+before starting a mail transaction.
+
+These commands, and a "250 OK" reply to one of them, confirm that both
+the SMTP client and the SMTP server are in the initial state, that is,
+there is no transaction in progress and all state tables and buffers
+are cleared.
+
+Syntax:
+  ehlo            = "EHLO" SP Domain CRLF
+  helo            = "HELO" SP Domain CRLF
+
+Normally, the response to EHLO will be a multiline reply.  Each line
+of the response contains a keyword and, optionally, one or more
+parameters.  Following the normal syntax for multiline replies, these
+keyworks 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
+[ABNF], is:
+
+   ehlo-ok-rsp  =    ( "250"    domain [ SP ehlo-greet ] CRLF )
+                / (    "250-"   domain [ SP ehlo-greet ] CRLF
+                    *( "250-"   ehlo-line                CRLF )
+                       "250"    SP ehlo-line             CRLF  )
+
+   ehlo-greet   = 1*(%d0-9 / %d11-12 / %d14-127)
+                ; string of any characters other than CR or LF
+
+   ehlo-line    = ehlo-keyword *( SP ehlo-param )
+
+   ehlo-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
+                ; additional syntax of ehlo-params depends on
+				; ehlo-keyword
+
+   ehlo-param   = 1*(%d33-127)
+                ; any CHAR excluding <SP> and all
+                ; control characters (US-ASCII 0-31 inclusive)
+
+Although EHLO keywords may be specified in upper, lower, or mixed case,
+they MUST always be recognized and processed in a case-insensitive
+manner.  This is simply an extension of practices specified in RFC 821
+and section 2.4.1.
+
+4.1.1.2 MAIL (MAIL)
+
+This command is used to initiate a mail transaction in which the mail
+data is delivered to an SMTP server which may, in turn, deliver it to
+one or more mailboxes or pass it on to another system (possibly using
+SMTP).  The argument field contains a reverse-path and may contain
+optional parameters.  In general, the MAIL command may be sent only
+when no mail transaction is in progress, see section 4.1.4.
+
+The reverse-path consists of the sender mailbox.  Historically, that
+mailbox might optionally have been preceeded by a list of hosts, but that
+behavior is now deprecated (see appendix C).  In some types of reporting
+messages for which a reply is likely to cause a mail loop (for example,
+mail delivery and nondelivery notifications), the reverse-path may be null
+(see section 3.7).
+
+This command clears the reverse-path buffer, the forward-path buffer,
+and the mail data buffer; and inserts the reverse-path information from
+this command into the reverse-path buffer.
+
+If service extensions were negotiated, the MAIL command may also carry
+parameters associated with a particular service extension.
+
+Syntax:
+
+   "MAIL FROM:" ("<>" / Reverse-Path)
+                    [SP Mail-parameters] CRLF
+
+4.1.1.3 RECIPIENT (RCPT)
+
+This command is used to identify an individual recipient of the mail
+data; multiple recipients are specified by multiple use of this
+command.  The argument field contains a forward-path and may contain
+optional parameters.
+
+The forward-path normally consists of the required destination mailbox.
+Sending systems SHOULD not generate the optional list of hosts known as
+a source route.  Receiving systems MUST recognize source route syntax
+but SHOULD strip off the source route specification and utilize the
+domain name associated with the mailbox as if the source route had not
+been provided.
+
+Similarly, relay hosts SHOULD strip or ignore source routes, and names
+MUST NOT be copied into the reverse-path. When mail reaches its
+ultimate destination (the forward-path contains only a destination
+mailbox), the SMTP server inserts it into the destination mailbox in
+accordance with its host mail conventions.
+
+For example, mail received at relay host xyz.com with envelope commands
+
+   MAIL FROM:<userx@y.foo.org>
+   RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org>
+
+will normally be sent directly on to host d.bar.org with envelope
+commands
+
+   MAIL FROM:<userx@y.foo.org>
+   RCPT TO:<userc@d.bar.org>
+
+As provided in appendix C, xyz.com MAY also choose to relay the message
+to hosta.int, using the envelope commands
+
+   MAIL FROM:<userx@y.foo.org>
+   RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org>
+
+or to jkl.org, using the envelope commands
+
+   MAIL FROM:<userx@y.foo.org>
+   RCPT TO:<@jkl.org:userc@d.bar.org>
+
+Of course, since hosts are not required to relay mail at all, xyz.com
+may also reject the message entirely when the RCPT command is received,
+using a 550 code (since this is a "policy reason").
+
+If service extensions were negotiated, the RCPT command may also carry
+parameters associated with a particular service extension offered by
+the server.  The client MUST NOT transmit parameters other than those
+associated with a service extension offered by the server in its EHLO
+response.
+
+Syntax:
+   "RCPT TO:" ("<Postmaster@" domain ">" / "<Postmaster>" / Forward-Path)
+                    [SP Rcpt-parameters] CRLF
+
+4.1.1.4 DATA (DATA)
+
+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 is terminated by a line containing only a period, that
+is, the character sequence "<CRLF>.<CRLF>" (see section 4.5.2).  This
+is the end of mail data indication.  Note that 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 data, ends the DATA command
+itself.  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 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 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" CRLF
+
+
+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., if 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. In other situations, it restores the state to
+that immediately after the most recent EHLO.  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" 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" SP String CRLF
+
+4.1.1.7 EXPAND (EXPN)
+
+This command asks the receiver to confirm that the argument identifies
+a mailing list, and if 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 may be issued at any time.
+
+Syntax:
+   "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 may be issued at any time.
+
+SMTP servers SHOULD support HELP without arguments and MAY support it
+with arguments.
+
+Syntax:
+   "HELP" [ SP String ] CRLF
+
+4.1.1.9 NOOP (NOOP)
+
+This command does not affect any parameters or previously entered
+commands.  It specifies no action other than that the receiver send an
+OK reply.
+
+This command has no effect on the reverse-path buffer, the forward-path
+buffer, or the mail data buffer and may be issued at any time.  If a
+parameter string is specified, servers SHOULD ignore it.
+
+Syntax:
+   "NOOP" [ SP String ] CRLF
+
+
+4.1.1.10 QUIT (QUIT)
+
+This command specifies that the receiver MUST send an 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 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.
+
+Syntax:
+   "QUIT" CRLF
+
+
+4.1.2 Command Argument Syntax
+
+The syntax of the argument fields of the above commands (using the
+syntax specified in [ABNF] 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 (section 6) of [ABNF] or in the syntax of [MSGFMT].
+
+   Reverse-path = Path
+   Forward-path = Path
+   Path = "<" [ A-d-l ":" ] Mailbox ">"
+   A-d-l = At-domain *( "," A-d-l )
+         ; Note that this form, the so-called "source route",
+         ; MUST BE accepted, SHOULD NOT be generated, and SHOULD be
+		 ; ignored.
+   At-domain = "@" domain
+   Mail-parameters = esmtp-param *(SP esmtp-param)
+   Rcpt-parameters = esmtp-param *(SP esmtp-param)
+   esmtp-param     = esmtp-keyword ["=" esmtp-value]
+   esmtp-keyword   = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
+   esmtp-value     = 1*(%d33-60 / %d62-127)
+                     ; any CHAR excluding "=", SP, and control
+					 ; characters
+   Keyword  = Ldh-str
+   Argument = Atom
+   Domain = (sub-domain 1*("." sub-domain)) / address-literal
+   sub-domain = Let-dig [Ldh-str]
+
+   address-literal = "[" IPv4-address-literal /
+                         IPv6-address-literal /
+                         General-address-literal "]"
+                 ; See section 4.1.3
+
+   Mailbox = Local-part "@" Domain
+
+   Local-part = Dot-string / Quoted-string
+              ; MAY be case-sensitive
+
+   Dot-string = Atom *("." Atom)
+
+   Atom = 1*atext
+
+   Quoted-string = DQUOTE *qcontent DQUOTE
+
+   String = Atom / Quoted-string
+
+
+While the 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 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 field with the comma being the fourth
+character of the field.
+
+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-1015]), characters outside
+the set of alphas, digits, and hyphen MUST NOT appear in domain name
+labels for SMTP clients or servers.  In particular, the underscore
+character is not permitted.  SMTP servers that receive a command 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.
+
+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
+space, and the address itself, in a format specified as part of the
+IPv6 standards [IPv6AddrSpec].
+
+Specifically:
+
+   IPv4-address-literal = Snum 3("." Snum)
+   IPv6-address-literal = "IPv6:" IPv6-addr
+   General-address-literal = Standardized-tag ":" 1*dcontent
+   Standardized-tag = Ldh-str
+                    ; MUST be specified in a standards-track RFC 
+                    ; and registered with IANA
+
+   Snum = 1*3DIGIT  ; representing a decimal integer
+                    ; value in the range 0 through 255
+   Let-dig = ALPHA / DIGIT
+   Ldh-str = *( ALPHA / DIGIT / "-" ) Let-dig
+
+   IPv6-addr = IPv6-full / IPv6-comp / IPv6v4-full / IPv6v4-comp
+   IPv6-hex  = 1*4HEXDIG
+   IPv6-full = IPv6-hex 7(":" IPv6-hex)
+   IPv6-comp = [IPv6-hex *5(":" IPv6-hex)] "::" [IPv6-hex *5(":"
+              IPv6-hex)]
+            ; The "::" represents at least 2 16-bit groups of zeros
+            ; No more than 6 groups in addition to the "::" may be
+			; present
+   IPv6v4-full = IPv6-hex 5(":" IPv6-hex) ":" IPv4-address-literal
+   IPv6v4-comp = [IPv6-hex *3(":" IPv6-hex)] "::"
+                [IPv6-hex *3(":" IPv6-hex) ":"] IPv4-address-literal
+            ; The "::" represents at least 2 16-bit groups of zeros
+            ; No more than 4 groups in addition to the "::" and
+            ; IPv4-address-literal may be present
+
+
+4.1.4 Order of Commands
+
+There are restrictions on the order in which these commands may be used.
+
+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, 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, or
+502 failure replies MUST be returned as appropriate.  The 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 valid principal host name (not a CNAME or MX
+name) for its host.  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 and
+supplemental information provided that will assist in identifying the
+client.
+
+An SMTP server MAY verify that the domain name parameter in the EHLO
+command actually corresponds to the IP address of the client. However,
+the server MUST NOT refuse to accept a message for this reason if the
+verification fails: the information about verification failure is for
+logging and tracing only.
+
+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
+(or a new EHLO) 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 it the previous one
+successfully concluded with a successful DATA command, or if the
+previous one was aborted with a RSET.
+
+If the transaction beginning command argument 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 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 cannot be used at any other time in a session, but SHOULD be
+used by the client SMTP to request connection closure, even when no
+session opening command was sent and accepted.
+
+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 section 4.2.1).  Since, in violation of this
+specification, the text is sometimes not sent, clients which 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 circumstances, however, multiline
+replies are allowed for any command.
+
+In ABNF, server responses are:
+
+  Greeting = "220 " Domain [ SP text ] CRLF
+  Reply-line = Reply-code [ SP text ] CRLF
+
+where "Greeting" appears only in the 220 response that announces that
+the server is opening its part of the connection.
+
+An SMTP server SHOULD send only the reply codes listed in this
+document.  An SMTP server SHOULD use the text shown in the examples
+whenever appropriate.
+
+An SMTP client MUST determine its actions only by the reply code, not by
+the text (except for the "change of address" 251 and 551 and, if necessary,
+220, 221, and 421 replies); in 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.
+
+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 five values for the first digit of the reply code:
+
+1yz   Positive Preliminary reply
+   The command has been accepted, but the requested action is being
+   held in abeyance, pending confirmation of the information in this
+   reply.  The SMTP client should send another command specifying
+   whether to continue or abort the action. Note: unextended SMTP does
+   not have any commands that allow this type of reply, and so does not
+   have continue or abort commands.
+
+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 is
+   encouraged to 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 is discouraged from repeating 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
+   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).
+
+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.
+
+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:
+   123-First line
+   123-Second line
+   123-234 text beginning with numbers
+   123 The last line
+
+In many cases the SMTP client then simply needs to search for the reply
+code followed by <SP> at the beginning of a line, and ignore all
+preceding lines.  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)
+
+   220 <domain> Service ready
+   221 <domain> Service closing transmission channel
+   421 <domain> Service not available, closing transmission channel
+      (This may be a reply to any command if the service knows it
+      must shut down)
+
+   250 Requested mail action okay, completed
+   251 User not local; will forward to <forward-path>
+      (See section 3.4)
+   252 Cannot VRFY user, but will accept message and attempt
+       delivery
+      (See section 3.5.3)
+   450 Requested mail action not taken: mailbox unavailable
+      (e.g., mailbox busy)
+   550 Requested action not taken: mailbox unavailable
+      (e.g., mailbox not found, no access, or command rejected
+      for policy reasons)
+   451 Requested action aborted: error in processing
+   551 User not local; please try <forward-path>
+      (See section 3.4)
+   452 Requested action not taken: insufficient system storage
+   552 Requested mail action aborted: exceeded storage allocation
+   553 Requested action not taken: mailbox name not allowed
+      (e.g., mailbox syntax incorrect)
+   354 Start mail input; end with <CRLF>.<CRLF>
+   554 Transaction failed (Or, in the case of a connection-opening
+       response, "No SMTP service here")
+
+4.2.3  Reply Codes in Numeric Order
+
+   211 System status, or system help reply
+   214 Help message
+      (Information on how to use the receiver or the meaning of a
+      particular non-standard command; this reply is useful only
+      to the human user)
+   220 <domain> Service ready
+   221 <domain> Service closing transmission channel
+   250 Requested mail action okay, completed
+   251 User not local; will forward to <forward-path>
+      (See section 3.4)
+   252 Cannot VRFY user, but will accept message and attempt
+      delivery
+      (See section 3.5.3)
+
+   354 Start mail input; end with <CRLF>.<CRLF>
+
+   421 <domain> Service not available, closing transmission channel
+      (This may be a reply to any command if the service knows it
+      must shut down)
+   450 Requested mail action not taken: mailbox unavailable
+      (e.g., mailbox busy)
+   451 Requested action aborted: local error in processing
+   452 Requested action not taken: insufficient system storage
+
+   500 Syntax error, command unrecognized
+      (This may include errors such as command line too long)
+   501 Syntax error in parameters or arguments
+   502 Command not implemented (see section 4.2.4)
+   503 Bad sequence of commands
+   504 Command parameter not implemented
+   550 Requested action not taken: mailbox unavailable
+      (e.g., mailbox not found, no access, or command rejected
+      for policy reasons)
+   551 User not local; please try <forward-path>
+      (See section 3.4)
+   552 Requested mail action aborted: exceeded storage allocation
+   553 Requested action not taken: mailbox name not allowed
+      (e.g., mailbox syntax incorrect)
+   554 Transaction failed  (Or, in the case of a connection-opening
+       response, "No SMTP service here")
+
+4.2.4 Reply Code 502
+
+Questions have 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:
+
+ - delivering the message (if the recipient mailbox exists), or
+
+ - if attempts to deliver the message fail due to transient conditions,
+   retrying delivery some reasonable number of times at intervals as
+   specified in section 4.5.4.
+
+ - if attempts to deliver the message fail due to permanent conditions,
+   or if repeated attempts to deliver the message fail due to transient
+   conditions, returning appropriate notification to the sender of the
+   original message (using the address in the SMTP MAIL command).
+
+When an SMTP server returns a transient error completion status (4yz) code
+after the DATA command is completed with <CRLF>.<CRLF>, it MUST NOT make
+any subsequent attempt to deliver that message.  The SMTP client retains
+responsibility for 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).
+
+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.
+I.e., 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 completely 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 and
+intervention of the message.
+
+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 4.1.3 for a discussion of alternatives in these
+situations.
+
+For example,
+   220 ISIF.USC.EDU Service ready
+or
+   220 mail.foo.com SuperSMTP v 6.1.2 Service ready
+or
+   220 [10.0.0.1] Clueless host service ready
+
+The table below lists alternative success and failure replies for each
+command.  These SHOULD be strictly adhered to: a receiver may
+substitute text in the replies, but the meaning and action implied by
+the code numbers and by the specific command reply sequence cannot be
+altered.
+
+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.
+
+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.
+
+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
+
+Specific sequences are:
+
+CONNECTION ESTABLISHMENT
+   S: 220
+   E: 554
+EHLO or HELO
+   S: 250
+   E: 504, 550
+MAIL
+   S: 250
+   E: 552, 451, 452, 550, 553, 503
+RCPT
+   S: 250, 251 (but see section 3.4 for discussion of 251 and 551)
+   E: 550, 551, 552, 553, 450, 451, 452, 503, 550
+DATA
+   I: 354 -> data -> S: 250
+                     E: 552, 554, 451, 452
+   E: 451, 554, 503
+RSET
+   S: 250
+VRFY
+   S: 250, 251, 252
+   E: 550, 551, 553, 502, 504
+EXPN
+   S: 250, 252
+   E: 550, 500, 502, 504
+HELP
+   S: 211, 214
+   E: 502, 504
+NOOP
+   S: 250
+QUIT
+   S: 221
+
+4.4 Trace Information
+
+When an SMTP server receives a message for delivery or further
+processing, it MUST insert trace ("time stamp" or "Received")
+information at the beginning of the message content, as discussed in
+section 4.1.1.4.
+
+This line MUST be structured as follows:
+
+ - The FROM field, which MUST be supplied in an SMTP environment,
+   SHOULD contain both (1) the name of the source host as presented in
+   the EHLO command and (2) an address literal containing the IP
+   address of the source, determined from the TCP connection.
+
+ - The ID field MAY contain an "@" as suggested in RFC-822, but this is
+   not required.
+
+ - The FOR field MAY contain a list of <path> entries when multiple
+   RCPT commands have been given.  This may raise some security issues
+   and is usually not desirable; see section 7.2.
+
+An Internet mail program MUST NOT change a Received: line that was
+previously added to the message header.  SMTP servers MUST prepend
+Received lines to messages; they MUST NOT change the order of existing
+lines or insert Received lines in any other location.
+
+As the Internet grows, comparability of Received fields is important
+for detecting problems, especially slow relays.  SMTP servers that
+create Received fields SHOULD use explicit offsets in the dates (e.g.,
+-0800), rather than time zone names of any type.  Local time (with an
+offset) is preferred to UT when feasible.  This formulation allows
+slightly more information about local circumstances to be specified.
+If UT is needed, the receiver need merely do some simple arithmetic to
+convert the values.  Use of UT loses information about the time
+zone-location of the server.  If a time zone name is used, 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 enviroment.  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 mail data headers and body [MSGFMT].
+
+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.  SMTP servers performing a relay
+function MUST NOT inspect the message data, and especially not to the
+extent needed to determine if Return-path headers are present. SMTP
+servers making final delivery MAY remove Return-path headers before
+adding their own.
+
+The primary purpose of the Return-path is to designate the address to
+which messages indicating non-delivery or other mail system failures
+are to be sent.  For this to be unambiguous, exactly one return path
+SHOULD be present when the message is delivered.  Systems using RFC 822
+syntax with non-SMTP transports SHOULD designate an unambiguous
+address, associated with the transport envelope, to which error reports
+(e.g., non-delivery messages) should be sent.
+
+Historical note: Text in RFC 822 that appears to contradict the use of
+the Return-path header (or the envelope reverse path address from the
+MAIL command) as the destination for error messages is not applicable
+on the Internet. The reverse path address (as copied into the
+Return-path) MUST be used as the target of any mail containing delivery
+error messages.
+
+In particular:
+
+ - a gateway from SMTP->elsewhere SHOULD insert a return-path header,
+   unless it is known that the "elsewhere" transport also uses Internet
+   domain addresses and maintains the envelope sender address
+   separately.
+
+ - a gateway from elsewhere->SMTP SHOULD delete any return-path header
+   present in the message, and either copy that information to the SMTP
+   envelope or combine it with information present in the envelope of
+   the other transport system to construct the reverse path argument to
+   the MAIL command in the SMTP envelope.
+
+The server must give special treatment to cases in which the processing
+following the end of mail data indication is only partially successful.
+This could happen if, after accepting several recipients and the mail
+data, the SMTP server finds that the mail data could be successfully
+delivered to some, but not all, of the recipients.  In such cases, the
+response to the DATA command MUST be an OK reply.  However, the SMTP
+server MUST compose and send an "undeliverable mail" notification
+message to the originator of the message.
+
+A single notification listing all of the failed recipients or separate
+notification messages MUST be sent for each failed recipient.  For
+economy of processing by the sender, the former is preferred when
+possible.  All undeliverable mail notification messages are sent using
+the MAIL command (even if they result from processing the obsolete
+SEND, SOML, or SAML commands) and use a null return path as discussed
+in section 3.7.
+
+The time stamp line and the return path line are formally defined as
+follows:
+
+   Return-path-line = "Return-Path:" FWS Reverse-path <CRLF>
+
+   Time-stamp-line = "Received:" FWS Stamp <CRLF>
+
+   Stamp = From-domain By-domain Opt-info ";"  FWS date-time
+
+                        ; where "date-time" is as defined in [MSGFMT]
+						but the "obs-" forms, especially two-digit
+						years, are prohibited in SMTP and MUST NOT be
+						used.
+
+   From-domain = "FROM" FWS Extended-Domain CFWS
+
+   By-domain = "BY" FWS Extended-Domain CFWS
+
+   Extended-Domain = Domain /
+              ( Domain FWS "(" TCP-info ")" ) /
+              ( Address-literal FWS "(" TCP-info ")"
+    TCP-info = Address-literal / ( Domain FWS Address-literal )
+                   ; Information derived by server from TCP connection
+ 				     not client EHLO.
+
+   Opt-info = [Via] [With] [ID] [For]
+
+   Via = "VIA" FWS Link CFWS
+
+   With = "WITH" FWS Protocol CFWS
+
+   ID = "ID" FWS String / msg-id CFWS
+
+   For = "FOR" FWS 1*( Path / Mailbox ) CFWS
+
+   Link = "TCP" / Addtl-Link
+   Addtl-Link = Atom       ; Additional standard names for links are
+                             registered with the Internet Assigned
+                             Numbers Authority (IANA).  "Via" is
+							 primarily of value with non-Internet
+							 transports.
+                             SMTP servers SHOULD NOT use unregistered
+                             names.
+   Protocol = "ESMTP" / "SMTP" / Attdl-Protocol
+   Attdl-Protocol = Atom    ; Additional standard names for protocols
+                              are registered with the Internet Assigned
+                              Numbers Authority (IANA).  SMTP servers
+                              SHOULD NOT use unregistered names.
+
+
+4.5 Additional Implementation Issues
+
+4.5.1 Minimum Implementation
+
+In order to make SMTP workable, the following minimum implementation is
+required for 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 which specify a mailbox for postmaster at any of
+the domains for which the SMTP s erver 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 which are not part of such attacks.
+
+
+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:
+
+ - Before sending a line of mail text, the SMTP client checks the first
+   character of the line.  If it is a period, one additional period is
+   inserted at the beginning of the line.
+
+ - When a line of mail text is received by the SMTP server, it checks
+   the line.  If the line is composed of a single period, it is treated
+   as the end of mail indicator.  If the first character is a period
+   and there are other characters on the line, the first character is
+   deleted.
+
+The mail data may contain any of the 128 ASCII characters.  All characters
+are to be delivered to the recipient's mailbox, including spaces, vertical
+and horizontal tabs, and other control characters.  If the transmission
+channel provides an 8-bit byte (octets) data stream, the 7-bit ASCII codes
+are transmitted right justified in the octets, with the high order bits
+cleared to zero.  See 3.7 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-X400] 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 which impose no limits on the length of these
+objects should be used.
+
+local-part
+   The maximum total length of a user name or other local-part is 64
+   characters.
+
+domain
+   The maximum total length of a domain name or number is 255
+   characters.
+
+path
+   The maximum total length of a reverse-path or forward-path is 256
+   characters (including the punctuation and element separators).
+
+command line
+   The maximum total length of a command line including the command
+   word and the <CRLF> is 512 characters.  SMTP extensions may be used
+   to increase this limit.
+
+reply line
+   The maximum total length of a reply line including the reply code
+   and the <CRLF> is 512 characters.  More information may be conveyed
+   through multiple-line replies.
+
+text line
+   The maximum total length of a text line including the <CRLF> is 1000
+   characters (not counting the leading dot duplicated for
+   transparency). This number may be increased by the use of SMTP
+   Service Extensions.
+
+message content
+   The maximum total length of a message content (including any message
+   headers as well as the message body) MUST BE at least 64K octets.
+   Since the introduction of multimedia mail [RFC-MIME], 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 ([RFC-SIZE]), and SMTP client systems that will
+   send large messages SHOULD utilize it when possible.
+
+recipients buffer
+   The minimum total number of recipients that must be buffered is 100
+   recipients. Rejection of messages (for excessive recipients) with
+   fewer than 100 RCPT commands is a violation of this specification.
+   The general principle that relaying SMTP servers MUST NOT, and
+   delivery SMTP servers SHOULD NOT, perform validation tests on
+   message headers suggests that rejecting a message based on the total
+   number of recipients shown in header fields is to be discouraged.  A
+   server which imposes a limit on the number of recipients MUST behave
+   in an orderly fashion,  such as to reject 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.
+
+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.
+
+[RFC-821] 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 addresses
+will be removed from the SMTP client's queue.  When the client attempts
+retransmission of those addresses which received 452 responses, at
+least 100 of these will be able to fit in the SMTP server's recipients
+buffer.  Each retransmission attempt which 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 5XX response code.  This would be most
+appropriate if the policy limitation was intended to apply if the total
+recipient count for a particular message body were enforced even if that
+message body was sent in multiple mail transactions.
+
+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:
+
+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.
+
+MAIL Command: 5 minutes
+
+RCPT Command: 5 minutes
+   A longer timeout is required if processing of mailing lists and
+   aliases is not deferred until after the message was accepted.
+
+DATA Initiation: 2 minutes
+   This is while awaiting the "354 Start Input" reply to a DATA command.
+
+Data Block: 3 minutes
+   This is while awaiting the completion of each TCP SEND call
+   transmitting a chunk of data.
+
+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.
+
+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.
+
+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.  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 that
+discussed in [RFC-ETRN].
+
+The strategy may be further modified as a result of multiple addresses
+per host (see below) to optimize delivery time vs. 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.
+
+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.  Implementation of this efficiency feature is strongly
+encouraged.
+
+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 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 notify the SMTP client 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 which 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, see [RFC 1894]) and also
+Message Disposition Notifications (MDNs, see [RFC 2298]). 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
+with a valid, non-null reverse-path.
+
+Implementors of automated email processors should be careful to make
+sure that the various kinds of messages with null reverse-path are
+handled correctly, in particular such systems SHOULD NOT reply to
+messages with null reverse-path.
+
+
+
+5. Address Resolution and Mail Handling
+
+Once an SMTP client lexically identifies a domain to which mail will be
+delivered for processing (as described in sections 3.6 and 3.7), a DNS
+lookup MUST be performed to resolve the domain name (see [RFC-DNS]).
+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 and, due to a history of problems, are
+generally discouraged.  The lookup first attempts to locate an MX
+record associated with the name.  If a CNAME record is found instead,
+the resulting name is processed as if it were the initial name.  If no
+MX records are found, but an A RR is found, the A RR is treated as if
+it was associated with an implicit MX RR, with a preference of 0,
+pointing to that host.  If one or more MX RRs are found for a given
+name, SMTP systems MUST NOT utilize any A RRs associated with that name
+unless they are located using the MX RRs; the "implicit MX" rule above
+applies only if there are no MX records present.  If MX records are
+present, but none of them are usable, this situation MUST be reported
+as an error.
+
+When the lookup succeeds, the mapping can result in a list of alternative
+delivery addresses rather than a single address, because of multiple MX
+records, multihoming, or both.  To provide reliable mail transmission, the
+SMTP client MUST be able to try (and retry) each of the relevant addresses
+in this list in order, until a delivery attempt succeeds. However, there
+MAY also be a configurable limit on the number of alternate addresses that
+can be tried.  In any case, the SMTP client SHOULD try at least two
+addresses.
+
+Two types of information is used to rank the host addresses: multiple
+MX records, and multihomed hosts.
+
+Multiple MX records contain a preference indication that MUST be used
+in sorting (see below).  Lower numbers are more preferred than higher
+ones.  If there are multiple destinations with the same preference and
+there 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 SMTP MUST try them in the order presented.
+
+Although the capability to try multiple alternative addresses is
+required, specific installations may want to limit or disable the use
+of alternative addresses.  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
+delivery.  The records are first ordered by preference, with the
+lowest-numbered records being most preferred.  The relay host MUST then
+inspect the list for any of the names or addresses by which it might be
+known in mail transactions.  If a matching record is found, all records
+at that preference level and higher-numbered ones MUST be discarded
+from consideration.  If there are no records left at that point, it is
+an error condition, and the message MUST be returned as undeliverable.
+If records do remain, they SHOULD be tried, best preference first, as
+described above.
+
+
+6. 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.
+
+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, 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 [RFC-1047] for
+a discussion of this problem.
+
+6.2 Loop Detection
+
+Simple counting of the number of "Received:" headers 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.3 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 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 [RFC-POP2,
+RFC-POP3, RFC-IMAP2, RFC-PCMAIL]. These protocols have encouraged the
+use of SMTP as a posting 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]).  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.
+
+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 protocol:
+
+ - Addition of a message-id field when none appears
+
+ - Addition of a date, time or time zone when none appears
+
+ - Correction of addresses to proper FQDN format
+
+The less 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.
+
+In all cases, properly-operating clients supplying correct information
+are preferred to corrections by the SMTP server. In all cases,
+documentation of actions performed by the servers (in trace fields
+and/or header comments) is strongly encouraged.
+
+
+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 which use
+digital signatures (see [RFC-1847] and, e.g., [RFC-PGP] or [RFC-SMIME]).
+
+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, unless they are accompanied by careful handoffs of
+responsibility in a carefully-designed trust environment, they remain
+inherently weaker than end-to-end mechanisms which 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 or in which error
+(or normal) replies should be directed to a special address. (Systems
+that provide convenient ways for users to alter these fields on a
+per-message basis should attempt to establish a primary and permanent
+mailbox address for the user so that Sender fields within the message
+data can be generated sensibly.)
+
+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 an ignorant user who is trying to fake mail.
+
+7.2 "Blind" Copies
+
+Addresses that do not appear in the message headers 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 headers, either as part of trace
+headers or as informational or private-extension headers.  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 headers.  Receiving
+systems SHOULD NOT attempt to deduce such relationships and use them to
+alter the headers of the message for delivery.  The popular
+"Apparently-to" header 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 one
+or both VRFY or EXPN for security reasons.  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.
+
+Within the last few years, the contents of mailing lists have become
+popular as an address information source for so-called "spammers." The
+use of EXPN to "harvest" addresses has increased as list administrators
+have installed protections against inappropriate uses of the lists
+themselves.  Implementations SHOULD still provide support for EXPN, but
+sites SHOULD carefully evaluate the tradeoffs. As authentication
+mechanisms are introduced into SMTP, some sites may choose to make EXPN
+available only to authenticated requestors.
+
+7.4 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 useful
+information to 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 are strongly encouraged to minimally provide for making
+type and version information available in some way to other network
+hosts.
+
+7.5 Information Disclosure in Trace Fields
+
+In some circumstances, such as when mail originates from within a LAN
+whose hosts are not directly from the public Internet, trace
+("Received") 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.6 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.7 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.
+
+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, MAIL, or RCPT as appropriate.
+
+
+8. IANA Considerations
+
+IANA will maintain three registries in support of this specification.
+The first 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.
+
+The second registry consists of "tags" that identify forms of domain
+literals other than those for IPv4 addresses (specified in RFC 821 and
+in this document) and IPv6 addresses (specified in this document).
+Additional literal types require standardization before being used;
+none are anticipated at this time.
+
+The third, 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") 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.
+
+
+9. References
+
+[US-ASCII] American National Standards Institute (formerly United States of
+America Standards Institute), X3.4, 1968, "USA Code for Information
+Interchange". ANSI X3.4-1968 has been replaced by newer versions with
+slight modifications, but the 1968 version remains definitive for the
+Internet.
+
+[RFC-1123] Braden, R., "Requirements for Internet hosts - application and
+support", 10/01/1989
+
+[RFC-POP2] Butler, M., D. Chase, J. Goldberger, J. Postel, J. Reynolds,
+"Post Office Protocol - version 2", RFC 937, 02/01/1985
+
+[RFC-PGP] Callas, J., L. Donnerhacke, H. Finney, R. Thayer, "OpenPGP
+Message Format", RFC 2440, November 1998.
+
+[RFC-IMAP2] Crispin, M., "Interactive Mail Access Protocol - Version 2", RFC
+1176, 08/20/1990.
+
+[RFC-IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4", RFC
+2060, 12/04/1996.
+
+[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text
+Messages", RFC 822, Department of Electrical Engineering, University of
+Delaware, August 1982.
+
+[ABNF] Crocker, D., P. Overell, Eds., "Augmented BNF for Syntax
+Specifications: ABNF", RFC 2234, November 1997.
+
+[RFC-ETRN] De Winter, J., "SMTP Service Extension for Remote Message Queue
+Starting", RFC 1985, 08/14/1996.
+
+[IAB-Firewalls] Freed, N, ed., "Behavior of and Requirements for
+Internet Firewalls", Work in progress, draft-iab-firewall-req-02.txt,
+June 2000.
+
+[RFC-MIME] Freed, N., N. Borenstein, "Multipurpose Internet Mail Extensions
+(MIME) Part One: Format of Internet Message Bodies", RFC 2045, 12/02/1996.
+
+[RFC-PIPELINE] N. Freed, A. Cargille, "SMTP Service Extension for Command
+Pipelining", RFC 1854, 10/04/1995.
+
+[RFC-1847] Galvin, J., S. Murphy, S. Crocker, N. Freed. "Security
+Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847,
+October 1995.
+
+[SUBMIT] R. Gellens, J. Klensin, "Message Submission", RFC 2476, December
+1998.
+
+[RFC-X400] S. Hardcastle-Kille, "Mapping between X.400(1988) / ISO 10021
+and RFC 822", RFC 1327, 05/18/1992.
+
+[IPv6AddrSpec] Hinden, R and S. Deering, Eds. "IP Version 6 Addressing
+Architecture", RFC 1884, December 1995.
+
+[RFC-SIZE] J. Klensin, N. Freed, K. Moore, "SMTP Service Extension for
+Message Size Declaration", RFC 1870, 11/06/1995. (STD 10)
+
+[SMTPEXT] J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker, "SMTP
+Service Extensions", RFC-1869, 11/06/1995. (STD 10)
+
+[8BITMIME] J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker, "SMTP
+Service Extension for 8bit-MIMEtransport", RFC 1652, 07/18/1994.
+
+[RFC-PCMAIL] M. Lambert, "PCMAIL: A distributed mail system for personal
+computers", RFC 1056, 06/01/1988.
+
+[RFC-DNS] Mockapetris, P., "Domain names - implementation and
+specification", RFC 1035 and P. Mockapetris, "Domain names - concepts and
+facilities", RFC 1034. (STD 13)
+
+[RFC-INTLHDR] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part
+Three: Message Header Extensions for Non-ASCII Text", RFC 2047, 12/02/1996.
+
+[RFC-NOTARY1] Moore, K., "SMTP Service Extension for Delivery Status
+Notifications", RFC 1891, 01/15/1996.
+
+[RFC-NOTARY2] Moore, K., G. Vaudreuil, "An Extensible Message Format for
+Delivery Status Notifications", RFC 1894, 01/15/1996.
+
+[RFC-POP3] Myers, J., M. Rose, "Post Office Protocol - Version 3", RFC 1930,
+5/14/96 (Std 53).
+
+[RFC-974] Partridge, C., "Mail routing and the domain system", RFC 974,
+01/01/1986
+
+[RFC-1047] Partridge, C., "Duplicate messages and SMTP", RFC 1047,
+02/01/1988.
+
+[TCP] Postel, J., ed., "Transmission Control Protocol - DARPA Internet
+Program Protocol Specification", RFC 793, USC/Information Sciences
+Institute, NTIS AD Number A111091, September 1981.
+
+[RFC-821] Postel, J., "Simple Mail Transfer Protocol", RFC 821, August 1,
+1982.
+
+[RFC-SMIME] Ramsdell, B., Ed., "S/MIME Version 3 Message Specification", RFC
+2633, June 1999.
+
+[MSGFMT] Resnick, P., Work in progress, draft-ietf-drums-msg-fmt-08.txt,
+January 2000.
+
+[RFC-BDAT] Vaudreuil, G., "SMTP Service Extensions for Transmission of Large
+and Binary MIME Messages", RFC 1830, 08/16/1995.
+
+[RFC-REPLY] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893,
+01/15/1996.
+
+
+10. Editor's Address
+
+John C. Klensin
+AT&T Laboratories
+Tel: 617-574-3076
+email: klensin@research.att.com
+
+
+
+11. Acknowledgments
+
+Many people worked long and hard on the many iterations of this document.
+There was wide-ranging debate on the mailing list about many technical
+issues, and many contributors helped form the wording in this
+specification. The hundreds of participants in the many discussions since
+RFC 821 was produced are too numerous to mention, but they all helped this
+document become what it is.
+
+
+
+
+							   APPENDICES
+
+A. TCP Transport Service
+
+The TCP connection supports the transmission of 8-bit bytes. The SMTP
+data is 7-bit ASCII characters.  Each character is 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, but not in SMTP commands or responses.
+
+
+B. Generating SMTP Commands from RFC 822 Headers
+
+Some systems use RFC 822 headers (only) in a mail submission protocol,
+or otherwise generate SMTP commands from RFC 822 headers 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 a mail envelopes is not
+separated early in processing from header information (and kept
+separate).
+
+It is recommended that the UA provide its initial 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 fields SHOULD then be removed
+   from the headers.  Once this process is completed, the remaining
+   headers SHOULD be checked to verify that at least one To:, Cc:, or
+   Bcc: header remains. If none do, then a bcc: header with no
+   additional information SHOULD be inserted as specified in [MSGFMT].
+
+2. The return address in the MAIL command SHOULD, if possible, be
+   derived from the system's identity for the submitting (local) user,
+   and the "From:" header field otherwise.  If there is a system
+   identity available, it SHOULD also be copied to the Sender header
+   field if it is different from the address in the From header field.
+   (Any Sender field that was already there SHOULD be removed.)
+   Systems may provide a way for submitters to override the envelope
+   return address, but may want to restrict its use to privileged
+   users.  This will not prevent mail forgery, but may lessen its
+   incidence; see section 7.1.
+
+When an MTA is being used in this way, it bears responsibility for
+ensuring that the message being transmitted is valid.  The mechanisms
+for checking that validity, and for handling (or returning) messages
+that are not valid at the time of arrival, are part of the MUA-MTA
+interface and not covered by this specification.
+
+A submission protocol based on Standard RFC 822 information alone MUST
+NOT be used to gateway a message from a foreign (non-SMTP) mail system
+into an SMTP environment.  Additional information to construct an
+envelope must come from some source in the other environment, whether
+supplemental headers or the foreign system's envelope.
+
+Attempts to gateway messages using only their header "to" and "cc"
+fields have repeatedly caused mail loops and other behavior adverse to
+the proper functioning of the Internet mail environment.  These
+problems have been especially common when the message originates from
+an Internet mailing list and is distributed into the foreign
+environment using envelope information.  When these messages are then
+processed by a header-only remailer, loops back to the Internet
+environment (and the mailing list) are almost inevitable.
+
+
+C. Source Routes
+
+The <reverse-path> is a reverse source routing list of hosts and a
+source mailbox.  The first host in the <reverse-path> SHOULD be the
+host sending the MAIL command.  Similarly, the <forward-path> may be a
+source routing lists of hosts and a destination mailbox. However, in
+general, the <forward-path> SHOULD contain only a mailbox and domain
+name, relying on the domain name system to supply routing information
+if required.  The use of source routes is deprecated; while servers
+MUST be prepared to receive and handle them as discussed in section 3.3
+and F.2, clients SHOULD NOT transmit them.
+
+For relay purposes, the forward-path may be a source route of the form
+"@ONE,@TWO:JOE@THREE", where ONE, TWO, and THREE MUST BE
+fully-qualified domain names.  This form is used to emphasize the
+distinction between an address and a route.  The mailbox is an absolute
+address, and the route is information about how to get there.  The two
+concepts should not be confused.
+
+If source routes are used, RFC 821 and the text below should be
+consulted for the mechanisms for constructing and updating the forward-
+and reverse-paths.
+
+The SMTP server transforms the command arguments by moving its own
+identifier (its domain name or that of any domain for which it is
+acting as a mail exchanger), if it appears, from the forward-path to
+the beginning of the reverse-path.
+
+Notice that the forward-path and reverse-path appear in the SMTP
+commands and replies, but not necessarily in the message.  That is,
+there is no need for these paths and especially this syntax to appear
+in the "To:" , "From:", "CC:", etc. fields of the message header.
+Conversely, SMTP servers MUST NOT derive final message delivery
+information from message header fields.
+
+When the list of hosts is present, it is a "reverse" source route and
+indicates that the mail was relayed through each host on the list (the
+first host in the list was the most recent relay).  This list is used
+as a source route to return non-delivery notices to the sender. As each
+relay host adds itself to the beginning of the list, it MUST use its
+name as known in the transport environment to which it is relaying the
+mail rather than that of the transport environment from which the mail
+came (if they are different).
+
+
+D. Scenarios
+
+This section presents complete scenarios of several types of SMTP
+sessions.  In the examples, "C:" indicates what is said by the SMTP
+client, and "S:" indicates what is said by the SMTP server.
+
+D.1 A Typical SMTP Transaction Scenario
+
+This SMTP example shows mail sent by Smith at host bar.com, to Jones,
+Green, and Brown at host foo.com.  Here we assume that host bar.com
+contacts host foo.com directly.  The mail is accepted for Jones and
+Brown.  Green does not have a mailbox at host foo.com.
+
+   S: 220 foo.com Simple Mail Transfer Service Ready
+   C: EHLO bar.com
+   S: 250-foo.com greets bar.com
+   S: 250-8BITMIME
+   S: 250-SIZE
+   S: 250-DSN
+   S: 250 HELP
+   C: MAIL FROM:<Smith@bar.com>
+   S: 250 OK
+   C: RCPT TO:<Jones@foo.com>
+   S: 250 OK
+   C: RCPT TO:<Green@foo.com>
+   S: 550 No such user here
+   C: RCPT TO:<Brown@foo.com>
+   S: 250 OK
+   C: DATA
+   S: 354 Start mail input; end with <CRLF>.<CRLF>
+   C: Blah blah blah...
+   C: ...etc. etc. etc.
+   C: .
+   S: 250 OK
+   C: QUIT
+   S: 221 foo.com Service closing transmission channel
+
+D.2 Aborted SMTP Transaction Scenario
+
+   S: 220 foo.com Simple Mail Transfer Service Ready
+   C: EHLO bar.com
+   S: 250-foo.com greets bar.com
+   S: 250-8BITMIME
+   S: 250-SIZE
+   S: 250-DSN
+   S: 250 HELP
+   C: MAIL FROM:<Smith@bar.com>
+   S: 250 OK
+   C: RCPT TO:<Jones@foo.com>
+   S: 250 OK
+   C: RCPT TO:<Green@foo.com>
+   S: 550 No such user here
+   C: RSET
+   S: 250 OK
+   C: QUIT
+   S: 221 foo.com Service closing transmission channel
+
+D.3 Relayed Mail Scenario
+
+Step 1  --  Source Host to Relay Host
+
+   S: 220 foo.com Simple Mail Transfer Service Ready
+   C: EHLO bar.com
+   S: 250-foo.com greets bar.com
+   S: 250-8BITMIME
+   S: 250-SIZE
+   S: 250-DSN
+   S: 250 HELP
+   C: MAIL FROM:<JQP@bar.com>
+   S: 250 OK
+   C: RCPT TO:<@foo.com:Jones@XYZ.COM>
+   S: 250 OK
+   C: DATA
+   S: 354 Start mail input; end with <CRLF>.<CRLF>
+   C: Date: Thu, 21 May 1998 05:33:29 -0700
+   C: From: John Q. Public <JQP@bar.com>
+   C: Subject:  The Next Meeting of the Board
+   C: To: Jones@xyz.com
+   C:
+   C: Bill:
+   C: The next meeting of the board of directors will be
+   C: on Tuesday.
+   C:                         John.
+   C: .
+   S: 250 OK
+   C: QUIT
+   S: 221 foo.com Service closing transmission channel
+
+Step 2  --  Relay Host to Destination Host
+
+   S: 220 xyz.com Simple Mail Transfer Service Ready
+   C: EHLO foo.com
+   S: 250 xyz.com is on the air
+   C: MAIL FROM:<@foo.com:JQP@bar.com>
+   S: 250 OK
+   C: RCPT TO:<Jones@XYZ.COM>
+   S: 250 OK
+   C: DATA
+   S: 354 Start mail input; end with <CRLF>.<CRLF>
+   C: Received: from bar.com by foo.com ; Thu, 21 May 1998
+   C:     05:33:29 -0700
+   C: Date: Thu, 21 May 1998 05:33:22 -0700
+   C: From: John Q. Public <JQP@bar.com>
+   C: Subject:  The Next Meeting of the Board
+   C: To: Jones@xyz.com
+   C:
+   C: Bill:
+   C: The next meeting of the board of directors will be
+   C: on Tuesday.
+   C:                         John.
+   C: .
+   S: 250 OK
+
+   C: QUIT
+   S: 221 foo.com Service closing transmission channel
+
+D.4 Verifying and Sending Scenario
+
+   S: 220 foo.com Simple Mail Transfer Service Ready
+   C: EHLO bar.com
+   S: 250-foo.com greets bar.com
+   S: 250-8BITMIME
+   S: 250-SIZE
+   S: 250-DSN
+   S: 250 HELP
+   C: VRFY Crispin
+   S: 250 Mark Crispin <Admin.MRC@foo.com>
+   C: SEND FROM:<EAK@bar.com>
+   S: 250 OK
+   C: RCPT TO:<Admin.MRC@foo.com>
+   S: 250 OK
+   C: DATA
+   S: 354 Start mail input; end with <CRLF>.<CRLF>
+   C: Blah blah blah...
+   C: ...etc. etc. etc.
+   C: .
+   S: 250 OK
+   C: QUIT
+   S: 221 foo.com Service closing transmission channel
+
+
+E. Other Gateway Issues
+
+In general, gateways between the Internet and other mail systems SHOULD
+attempt to preserve any layering semantics across the boundaries
+between the two mail systems involved.  Gateway-translation approaches
+that attempt to take shortcuts by mapping, (such as envelope
+information from one system to the message headers or body of another)
+have generally proven to be inadequate in important ways.  Systems
+translating between environments that do not support both envelopes and
+headers and Internet mail must be written with the understanding that
+some information loss is almost inevitable.
+
+
+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 is strongly preferred to
+HELO when the server will accept the former.  Servers must continue to
+accept and process HELO in order to support older clients.
+
+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 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.
+
+
+X. Change Summary and Loose Ends (Temporary)
+
+X.1 Change summary
+
+X.1.1 Substantive changes between draft-ietf-drums-smtpupd-00.txt and
+draft-ietf-drums-smtpupd-01.txt
+
+(i) Slightly clarified the discussions of rejection and failure of VRFY
+requests and the associated response codes.
+
+(ii) Slightly clarified the discussion of deferred address validation.
+
+(iii) Removed the IPCE terminology and modified the text in section
+4.1.1.2 to explicitly introduce the "mail gateway" terminology and to
+begin to distinguish a mail gateway from a conventional relay.
+
+(iv) Explicitly noted that SMTP clients for things like POP and IMAP
+may send everything to a single relay for further processing, rather
+than resolving final domain names.
+
+(v) Tightened the RSET discussion.
+
+(vi) Deprecation of 251 only for RCPT (still ok for VRFY)
+
+X.1.2.  Substantive changes between draft-ietf-drums-smtpupd-01.txt and
+draft-ietf-drums-smtpupd-02.txt.
+
+Incorporated additional RFC 1123 material; reorganized several sections
+for clarity.  Added definitions and other previous "loose end" material.
+
+X.1.3.  Substantive changes between draft-ietf-drums-smtpupd-02.txt and
+draft-ietf-drums-smtpupd-03.txt.
+
+(i) Eliminated a number of placeholders and tightened some of the
+definitions in section 2.  Added a few new placeholders for consistency
+checking against other documents.
+
+(ii) Removed the state diagrams, per direction at IETF Montreal.
+
+(iii) Added new section 6.3, an attempt to summarize WG discussions on
+the "posting" versus "delivery" versus "relay" functions of SMTP and on
+whether "fixups" are appropriate in different cases.
+
+(iv) Inserted section 6.1, a minor rewrite of section 5.3.3 of RFC1123.
+
+(v) Added new text to 3.5.5 to discuss the spammer - EXPN relationship.
+
+(vi) The "ASCII requirement" in 4.1.1.4 has been tightened somewhat.
+
+(v) The remaining miscellaneous changes agreed to in Montreal have been
+incorporated except as noted below.
+
+X.1.4.  Substantive changes between draft-ietf-drums-smtpupd-03.txt and
+draft-ietf-drums-smtpupd-04.txt.
+
+Many small changes have been made between these two versions; the list
+that follows is not exhaustive.
+
+(i) To clarify some of the text, definitions have been introduced to
+distinguish among originating, delivery, relay, and gateway SMTP
+systems.
+
+(ii) The role of LF-terminated lines has been clarified.
+
+(iii) Several changes have been made to clarify the principle that, no
+matter what originating and final delivery systems might do, relay
+systems are not permitted to tamper with message content, even to "fix"
+headers that are determined to be invalid.  If they deem message
+content to be seriously unacceptable, they are encouraged to reject the
+messages in preference to trying to fix them up, but, in general, the
+theme is "don't look/ don't tell".
+
+(iv) A few more definitions have been added to the terminology section,
+and the separate glossary has been eliminated.
+
+(v) I have taken a shot at text to address some of the controversies
+that have raged on the WG mailing list (e.g., sections 7.4 and 7.5).
+Since there was no consensus on most of those topics, I expect that the
+inserted text will satisfy no one except, perhaps, for agreement that
+saying nothing would have been worse.  As a mechanism for moving
+forward, the text in these controversial areas that now appears will be
+considered "base"; alterations will be made only if clear consensus
+emerges.
+
+(vi) Per discussion in Los Angeles, source routes have been further
+deprecated.
+
+(vii) Some of the VRFY/EXPN materials have been moved to "security
+considerations", where they appear to belong, some text has been added,
+and the conformance statements adjusted to reflect what I perceive to
+be WG consensus.
+
+(viii) New MX resolution material has been added to section 5.  While
+most of this material is from RFC974, the rules have been further
+tightened to reflect current practice and experience (974 is written in
+a somewhat speculative fashion for a standard).  In particular, the
+behavior of trying the target host's A RR when MXs existed but all of
+them were eliminated is now prohibited, which seems necessary if
+another of other ideas being recommended or considered are to be
+feasible.
+
+X.1.5.  Substantive changes between draft-ietf-drums-smtpupd-04.txt and
+draft-ietf-drums-smtpupd-05.txt.
+
+(i) All normative references to RFC 1123 have been removed from the
+main body of the text (some still appear in the appendices where they
+will remain).
+
+(ii) Section 3.5 has been renamed slightly to distinguish between
+"debugging of SMTP implementations" and "debugging of addresses".
+Better terminology would be welcome.
+
+(iii) Error conditions resulting from the DATA command have been
+clarified.
+
+(iv) Section 4.2 (SMTP replies) has been revised and tightened to
+reflect reality and recent discussion on the list.
+
+(v) Appendix E has been revised a bit and moved into section 4.2.1.
+Given the importance of the "check only first digit" rule, it has to be
+there.
+
+(vi) Added new text for "no SMTP service supported" to sections 3.1,
+4.2.2, 4.2.3, and 4.3.2.  As noted in 3.1, I'd rather add 521 (which
+would work perfectly with the model) rather than overloading 554.
+
+(vii) The Return-path language in section 4.4 has been cleaned up a bit.
+
+(viii) Tightened the "postmaster" language in 4.5.1, requiring a small
+change to 4.1.1.3.
+
+(ix) I have unilaterally (with a little help from my friends),
+increased some of the size limits.  64 was much too short for a domain
+name, and the DNS limit of 255 (?) has now been inserted. That leaves
+the return path much too short, but I haven't fixed it (maybe that will
+cause us to get rid of them).  We still have a 64 character limit on
+the local-part, which is also *much* too short. Votes for 128 or longer
+limits accepted.  See X.1.6(I)
+
+(x) The text on the "recipients buffer" has been rewritten so that (I
+hope) it makes sense and gives some explicit guidance for how clients
+and servers should proceed if limits are imposed.
+
+X.1.6.  Substantive changes between draft-ietf-drums-smtpupd-05.txt and
+draft-ietf-drums-smtpupd-06.txt.
+
+Most of the changes in this revision have been editorial rather than
+substantive.  Major substantive changes include:
+
+(i) The language about maximum sizes of SMTP command lines has been
+reworked, per WG mailing list discussion.
+
+(ii) Several instances of "SHOULD" have been promoted to "MUST" when
+the reasons for the weaker rule seemed to have disappeared.  In
+particular, the requirement that an SMTP implementation support
+timeouts has become a MUST.  Also, conformance to this specification
+requires support of EHLO.  Older systems should claim conformance to
+the [to-be-historical] 821, not this specification.
+
+X.1.7.  Substantive changes between draft-ietf-drums-smtpupd-06.txt and
+draft-ietf-drums-smtpupd-07.txt.
+
+(i) Removed "implied RSET" text associated with QUIT, as specified at
+the December 1997 IETF.
+
+(ii) Required that servers support EHLO, as specified at the December
+1997 IETF.
+
+X.1.8. Substantive changes between draft-ietf-drums-smtpupd-07.txt and
+draft-ietf-drums-smtpupd-08.txt.
+
+This version involves mostly editorial work and cleanup of loose ends.
+
+(i) New 7.5 added (old one renumbered) to discuss info disclosure
+through Received fields.
+
+(ii) Some character set and minor syntax issues clarified.
+
+(iii) Material on code 571 added (thought this had been done long ago;
+slipped through the cracks)
+
+(iv) Many clarifications added as the result of list discussions and
+suggestions.
+
+(v) Error code presentation has been restructured.
+
+(vi) ABNF conversion done
+
+(vii) IPv6 address format inserted per RFC 1884, since we could not get
+clear agreement on an alternative.
+
+(viii) Trivial, silly, examples removed.  Others not yet renumbered.
+
+(ix) 3.5.2 and 4.1.1 altered slightly per Eric Allman's notes.  Eric
+may not like the way I've done either of these change very much: the
+first now makes the distinction between returning an address and
+returning other stuff (which was permitted by -06, but the text wasn't
+as clear as it should have been): if it looks like an address, it needs
+to be an address.  Similarly, with 4.1.1, Eric wanted to explicitly
+permit/legitimize "DATA <SP> <CRLF>".  I see several disadvantages to
+doing that, so have inserted language that encourages receivers to
+tolerate trailing white space, which may have the same practical effect.
+
+
+X.1.9. Substantive changes between draft-ietf-drums-smtpupd-08.txt and
+draft-ietf-drums-smtpupd-09.txt.
+
+The first ten of these reflect, in order, minuted items from the
+Chicago IETF (IETF 42).
+
+(i) Clarification of "MUST", etc., in the context of this document
+(section 2.3).
+
+(ii) Altered VRFY text to make implementation a SHOULD (section 3.5.1)
+and removed VRFY from the mandatory to implement list (section 4.5.1),
+per 42nd IETF (Chicago).
+
+(iii) Clarified that exploders are expected to not purge sender
+addresses from lists (section 3.10).  Note that the Chicago conclusion
+was that this should be a "MUST".  I could not figure out how to do
+that without absolutely prohibiting removing addresses to prevent
+loops, to guard against spammers, or for similar legitimate purposes.
+So I have written this as a "SHOULD", with additional "strongly
+discouraged" words.  If someone still wants a MUST, suggest text.
+
+(iv) Altered text to permit clients that sometimes, or even always,
+initiate sessions with HELO, rather than EHLO, to be fully-conforming
+(section 3.2).  [[ Editor's note: I continue to believe that a client
+that does not have any service extension support, even to the extent of
+being able to send EHLO and parse the response without doing anything
+about it, should not be considered fully-conforming to this spec (as
+distinct from 821).  Consequently, the new text in 3.2 stops well short
+of encouraging clients that don't need service extensions from
+preferentially using HELO, and the text in 2.2.1 (which specifies that
+the extension mechanisms must be supported) has not been changed.
+
+(v) Per Chicago discussions, the text requiring that QUIT be sent has
+not been changed.  The text in 4.1.1.10 requiring that the server wait
+for QUIT has been changed to a SHOULD.  However, the text in 4.1.1.5,
+prohibiting close on receipt of RSET and that elsewhere prohibiting
+close as a normal response, has not been changed.
+
+(vi) Text has been inserted in 4.1.1 and the text in 4.3.2 altered
+slightly to clarify the handling of parameters to RSET, DATA, and QUIT
+and to 4.1.1.9 specify semantics for parameters to NOOP.  I have
+followed the minutes on this although I personally agree with kre's
+mailing list comments that the "servers SHOULD reject" decision leads
+to silly states.  I recommend that the WG review this.
+
+(vii) Per discussion in Chicago, no substantive change has been made to
+the specification about underscore characters in domain names (section
+4.1.2).  However, the text has been altered to more accurately reflect
+discussion on the mailing list and the source of the requirement.
+
+(viii) Per discussion in Chicago, no change has been made to the
+preference for local time in Received headers.
+
+(ix) Per discussion in Chicago, code 571 has been removed and policy
+rejection is now reflected i a 550 code (section 3.7 and the response
+code lists).
+
+(x) Per discussion in Chicago, no change has been made to the
+specification of use of raw CR or LF.
+
+(xi) In section 4.3, the text has been changed, per comments from Dan
+Bernstein and others, to require that clients be able to handle replies
+that do not contain text strings. A few other places patched to match.
+
+(xii) In sections 4.1.1.1 and 8, the placeholders have been removed.
+
+(xiii) Per discussion on the mailing list (and specifically James
+Berriman's concerns), the text has been clarified (sections 4.1.1.2 and
+4.1.4) to prohibit MAIL unless no mail transaction is open.  This is a
+MUST NOT prohibition -- SHOULD NOT makes no sense if this is the
+direction we are going to go.  503 has also been added to the list of
+valid responses for "MAIL" in 4.3.1 - it can't be issued before
+EHLO/HELO in any event.  While it is clear that something should be
+said, this may not be the desired outcome (I selected it because it was
+conservative and easy given the text that was there already); the WG
+should check that the text is as intended.
+
+(xiv) Per discussion on the mailing list, a new section 4.5.5 has been
+added to describe null return paths and their handling (forward pointer
+from 3.7).  The text in 4.5.5 is substantially that suggested by
+Norbert Bollow.  As with (xiii), there is now clear text, but it may
+not be what the WG desires.  Please check.
+
+(xv) "all addresses" substituted for "each...in turn" in 3.10.2.
+
+(xvi) Requirement for "<" and ">" around paths clarified in section 3.3
+(syntax productions were clear and correct, but not this overview
+material).
+
+(xvii) Clarified text in 3.3 to permit post-DATA bounces on policy
+matters.
+
+
+X.1.10. Substantive changes between draft-ietf-drums-smtpupd-09.txt and
+draft-ietf-drums-smtpupd-10.txt.
+
+(i) A large series of typos, most of them caught by Philip Hazel,
+corrected.
+
+(ii) Residual problems with references to mailboxes, forward, and
+reverse paths in 4.1.1.2 and 4.1.1.3 corrected and some text, I hope,
+clarified.
+
+(iii) Text added to 4.2.5 to talk about 5yz errors after DATA.  This
+text should be checked carefully -- it is a proposal and may or may not
+reflect WG consensus.
+
+(iv) Upper bound on "seconds" has been changed to 60 (not 61), per list
+discussion.  Years are still four-digits and will stay that way unless
+the list discussion converges on something else.  The increase to 60
+seconds includes an explicit note about leap seconds.
+
+(v) Text has been inserted to reflect the Orlando consensus about
+"QUIT", i.e., the client MUST send a QUIT command and SHOULD wait for
+the results before closing the connection.  Servers are still not
+permitted to close without receiving a QUIT and sending a 221 response
+(except, of course, under the usual "unavoidable circumstances", in
+which case they should get off a 451 if that is feasible).
+
+(vi) The EHLO response specification has been changed back to reflect
+non-advertisement of VRFY and some text implying that VRFY was optional
+to support has been removed (WG consensus seemed to be moving in that
+direction at one point, and the editor reacted prematurely).  This
+makes the text compatible with RFC1869 and restores VRFY to its RFC1123
+status.
+
+(vii) The text in section 5 has been clarified with regard to what a
+relay that receives a message because of its designation as an MX can
+do and 3.7 has been slightly modified to point to it.
+
+(viii) New text has been added to 3.7 to clarify the use of "SMTP
+server" relays in "dumb" originating clients.
+
+(viii) Small wording changes inserted into 4.1.4 (e.g., insertion of ",
+if possible," into the first sentence of the fifth paragraph to
+eliminate the apparent conflict with the second sentence).
+
+
+X.1.11. Substantive changes between draft-ietf-drums-smtpupd-10.txt and
+draft-ietf-drums-smtpupd-11.txt.  Note that the most significant change
+is the insertion of RFC 2234-conforming ABNF throughout.  That material
+should be checked carefully.
+
+(i) Dumb client text revised again, as discussed on the list and using
+the text agreed to there.  New text simply notes that the submission
+issues are outside the scope of the spec/standard.
+
+(ii) ABNF updated and replaced (thanks, Chris).  Some possible issues/
+questions:
+
+  (ii.1) RFC 1869 permits a NUL octet in the greeting (ehlo-greet in
+       the syntax).  Chris proposes to remove that capability on the
+	   grounds that it has no obvious value and will probably not
+	   work with many servers anyway.
+
+  (ii.2) Previous drafts have assumed that the tag to indicate what
+       is coming in a non-IPv4 address literal will be separated by
+	   the address itself by a space.  Chris proposes to change it to
+	   a colon, on the theory that this will cause fewer parsing
+	   problems with existing MTAs and MUAs.
+
+  (ii.3) The full IPv6 address syntax has been transposed from
+       the prose of RFC2373 into ABNF.  It can be left out and 2373
+	   cited if the WG prefers.
+
+(iii) Added firewall clarification to section 2.3.8.
+
+(iv) Small clarifications and tightenings in several sections, notably
+the end of 3.7, 3.8.3, 4.5.4.2, 7.2, clarifying editorial changes
+elsewhere, slightly improved crossreferences, and some redundant
+sections stripped out.  Many thanks to Graham Klyne for extensive
+and specific comments in these areas.
+
+(v) The "TO:" in "RCPT TO:" is part of an argument, not part of the
+command.  Similarly for "FROM:" in "MAIL FROM:".  All of these are
+believed to be fixed.
+
+(vi)Section 2.3.5 has been changed to make it clear that restrictions
+on the syntax and character set of domain names are part of the mail
+system, not an intrinsic limit of the DNS itself.   This, and some
+other text, are not going to be popular with those working to
+internationalize the DNS, but I believe it is important to lay down a
+clear baseline and then start making modifications or extensions,
+rather than trying to delude ourselves with a DNS equivalent of "just
+send 8".
+
+(vii) Clarified the EHLO-> HELO fallback requirement in 3.2.  I think
+this is consistent with what the WG wanted; if not, I'm sure I'll hear
+about it.
+
+
+X.1.12. Substantive changes between draft-ietf-drums-smtpupd-11.txt and
+draft-ietf-drums-smtpupd-12.txt.
+
+(i) DATA failure text in section 3.3 has been corrected and clarified.
+
+(ii) "Daytime" and supporting productions removed and replaced by a
+reference to 822bis.  The new text prohibits use of the "obs-" forms in
+822bis, which have been deprecated in SMTP since RFC1123.  Note that
+this change creates what I think is the first substantive normative
+reference between the two documents in order to gain consistency.  We
+had earlier tried to not bind the two of them together in this way, but
+probably it is worth it.
+
+(iii) Conditions under which mail to Postmaster may be dropped or bounced
+have been clarified in section 4.5.1.
+
+(iv) Revised the treatment of 251 and 551. Both are now permitted (again),
+but the text has been revised to clarify the restritions and clarifications
+on using them.  See section 3.4.
+
+(v) A lot of small editorial improvements have been made, including
+changing of some section titles for clarity and removal of a few more
+redundant paragraphs.
+
+
+Z.  Full Copyright Statement
+
+Copyright (C) The Internet Society (1998-2000).  All Rights Reserved.
+
+This document and translations of it may be copied and furnished to
+others, and derivative works that comment on or otherwise explain it or
+assist in its implementation may be prepared, copied, published and
+distributed, in whole or in part, without restriction of any kind,
+provided that the above copyright notice and this paragraph are
+included on all such copies and derivative works.  However, this
+document itself may not be modified in any way, such as by removing the
+copyright notice or references to the Internet Society or other
+Internet organizations, except as needed for the purpose of developing
+Internet standards in which case the procedures for copyrights defined
+in the Internet Standards process must be followed, or as required to
+translate it into languages other than English.
+
+The limited permissions granted above are perpetual and will not be
+revoked by the Internet Society or its successors or assigns.
+
+This document and the information contained herein is provided on an
+"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
+NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
+NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
+FITNESS FOR A PARTICULAR PURPOSE.
+
+Expires December 2000.
diff --git a/Documentation/en/I-D/draft-ietf-drums-smtpupd-13.txt b/Documentation/en/I-D/draft-ietf-drums-smtpupd-13.txt
new file mode 100644
index 00000000..e1b6fd11
--- /dev/null
+++ b/Documentation/en/I-D/draft-ietf-drums-smtpupd-13.txt
@@ -0,0 +1,101 @@
+

+A new Request for Comments is now available in online RFC libraries.

+

+

+        RFC 2821

+

+        Title:      Simple Mail Transfer Protocol

+        Author(s):  J. Klensin, Editor

+        Status:     Standards Track

+        Date:       April 2001

+        Mailbox:    klensin@research.att.com

+        Pages:      79

+        Characters: 192504

+        Updates:    1123

+        Obsoletes:  821, 974

+

+        I-D Tag:    draft-ietf-drums-smtpupd-13.txt

+

+        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc2821.txt

+

+

+This document is a self-contained specification of the basic protocol

+for the Internet electronic mail transport.  It consolidates, updates

+and clarifies, but doesn't add new or change existing functionality of

+the following:

+ 

+-  the original SMTP (Simple Mail Transfer Protocol) specification of

+   RFC 821,

+ 

+-  domain name system requirements and implications for mail

+   transport from RFC 1035 and RFC 974,

+ 

+-  the clarifications and applicability statements in RFC 1123,

+   and

+ 

+-  material drawn from the SMTP Extension mechanisms.

+ 

+It obsoletes RFC 821, RFC 974, and updates RFC 1123 (replaces 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 POP and IMAP. 

+

+Additional submission issues are discussed in RFC 2476.

+ 

+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 discusses message headers, message bodies

+and formats and structures for them, and their relationship.

+

+This document is a product of the Detailed Revision/Update of Message

+Standards Working Group of the IETF.

+

+This is now a Proposed Standard Protocol.

+

+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.

+

+This announcement is sent to the IETF list and the RFC-DIST list.

+Requests to be added to or deleted from the IETF distribution list

+should be sent to IETF-REQUEST@IETF.ORG.  Requests to be

+added to or deleted from the RFC-DIST distribution list should

+be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.

+

+Details on obtaining RFCs via FTP or EMAIL may be obtained by sending

+an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body 

+help: ways_to_get_rfcs.  For example:

+

+        To: rfc-info@RFC-EDITOR.ORG

+        Subject: getting rfcs

+

+        help: ways_to_get_rfcs

+

+Requests for special distribution should be addressed to either the

+author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG.  Unless

+specifically noted otherwise on the RFC itself, all RFCs are for

+unlimited distribution.echo 

+Submissions for Requests for Comments should be sent to

+RFC-EDITOR@RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC

+Authors, for further information.