3.  The SMTP Procedures: An Overview

   This section contains descriptions of the procedures used in SMTP:
   session initiation, mail transaction, forwarding mail, verifying
   mailbox names and expanding mailing lists, and opening and closing
   exchanges.  Comments on relaying, a note on mail domains, and a
   discussion of changing roles are included at the end of this section.
   Several complete scenarios are presented in Appendix D.

3.1.  Session Initiation

   An SMTP session is initiated when a client opens a connection to a
   server and the server responds with an opening message.

   SMTP server implementations MAY include identification of their
   software and version information in the connection greeting reply
   after the 220 code, a practice that permits more efficient isolation
   and repair of any problems.  Implementations MAY make provision for
   SMTP servers to disable the software and version announcement where
   it causes security concerns.  While some systems also identify their
   contact point for mail problems, this is not a substitute for
   maintaining the required "postmaster" address (see Section 4).

   The SMTP protocol allows a server to formally reject a mail session
   while still allowing the initial connection as follows: a 554
   response MAY be given in the initial connection opening message
   instead of the 220.  A server taking this approach MUST still wait
   for the client to send a QUIT (see Section 4.1.1.10) before closing
   the connection and SHOULD respond to any intervening commands with
   "503 bad sequence of commands".  Since an attempt to make an SMTP
   connection to such a system is probably in error, a server returning
   a 554 response on connection opening SHOULD provide enough
   information in the reply text to facilitate debugging of the sending
   system.

3.2.  Client Initiation

   Once the server has sent the greeting (welcoming) message and the
   client has received it, the client normally sends the EHLO command to
   the server, indicating the client's identity.  In addition to opening
   the session, use of EHLO indicates that the client is able to process
   service extensions and requests that the server provide a list of the
   extensions it supports.  Older SMTP systems that are unable to
   support service extensions, and contemporary clients that do not
   require service extensions in the mail session being initiated, MAY
   use HELO instead of EHLO.  Servers MUST NOT return the extended EHLO-
   style response to a HELO command.  For a particular connection
   attempt, if the server returns a "command not recognized" response to
   EHLO, the client SHOULD be able to fall back and send HELO.

   In the EHLO command, the host sending the command identifies itself;
   the command may be interpreted as saying "Hello, I am <domain>" (and,
   in the case of EHLO, "and I support service extension requests").

3.3.  Mail Transactions

   There are three steps to SMTP mail transactions.  The transaction
   starts with a MAIL command that gives the sender identification.  (In
   general, the MAIL command may be sent only when no mail transaction
   is in progress; see Section 4.1.4.)  A series of one or more RCPT
   commands follows, giving the receiver information.  Then, a DATA
   command initiates transfer of the mail data and is terminated by the
   "end of mail" data indicator, which also confirms the transaction.

   The first step in the procedure is the MAIL command.

      MAIL FROM:<reverse-path> [SP <mail-parameters> ] <CRLF>

   This command tells the SMTP-receiver that a new mail transaction is
   starting and to reset all its state tables and buffers, including any
   recipients or mail data.  The <reverse-path> portion of the first or
   only argument contains the source mailbox (between "<" and ">"
   brackets), which can be used to report errors (see Section 4.2 for a
   discussion of error reporting).  If accepted, the SMTP server returns
   a "250 OK" reply.  If the mailbox specification is not acceptable for
   some reason, the server MUST return a reply indicating whether the
   failure is permanent (i.e., will occur again if the client tries to
   send the same address again) or temporary (i.e., the address might be
   accepted if the client tries again later).  Despite the apparent
   scope of this requirement, there are circumstances in which the
   acceptability of the reverse-path may not be determined until one or
   more forward-paths (in RCPT commands) can be examined.  In those
   cases, the server MAY reasonably accept the reverse-path (with a 250
   reply) and then report problems after the forward-paths are received
   and examined.  Normally, failures produce 550 or 553 replies.

   Historically, the <reverse-path> was permitted to contain more than
   just a mailbox; however, contemporary systems SHOULD NOT use source
   routing (see Appendix C).

   The optional <mail-parameters> are associated with negotiated SMTP
   service extensions (see Section 2.2).

   The second step in the procedure is the RCPT command.  This step of
   the procedure can be repeated any number of times.

      RCPT TO:<forward-path> [ SP <rcpt-parameters> ] <CRLF>

   The first or only argument to this command includes a forward-path
   (normally a mailbox and domain, always surrounded by "<" and ">"
   brackets) identifying one recipient.  If accepted, the SMTP server
   returns a "250 OK" reply and stores the forward-path.  If the

   recipient is known not to be a deliverable address, the SMTP server
   returns a 550 reply, typically with a string such as "no such user -
   " and the mailbox name (other circumstances and reply codes are
   possible).

   The <forward-path> can contain more than just a mailbox.
   Historically, the <forward-path> was permitted to contain a source
   routing list of hosts and the destination mailbox; however,
   contemporary SMTP clients SHOULD NOT utilize source routes (see
   Appendix C).  Servers MUST be prepared to encounter a list of source
   routes in the forward-path, but they SHOULD ignore the routes or MAY
   decline to support the relaying they imply.  Similarly, servers MAY
   decline to accept mail that is destined for other hosts or systems.
   These restrictions make a server useless as a relay for clients that
   do not support full SMTP functionality.  Consequently, restricted-
   capability clients MUST NOT assume that any SMTP server on the
   Internet can be used as their mail processing (relaying) site.  If a
   RCPT command appears without a previous MAIL command, the server MUST
   return a 503 "Bad sequence of commands" response.  The optional
   <rcpt-parameters> are associated with negotiated SMTP service
   extensions (see Section 2.2).

   Since it has been a common source of errors, it is worth noting that
   spaces are not permitted on either side of the colon following FROM
   in the MAIL command or TO in the RCPT command.  The syntax is exactly
   as given above.

   The third step in the procedure is the DATA command (or some
   alternative specified in a service extension).

      DATA <CRLF>

   If accepted, the SMTP server returns a 354 Intermediate reply and
   considers all succeeding lines up to but not including the end of
   mail data indicator to be the message text.  When the end of text is
   successfully received and stored, the SMTP-receiver sends a "250 OK"
   reply.

   Since the mail data is sent on the transmission channel, the end of
   mail data must be indicated so that the command and reply dialog can
   be resumed.  SMTP indicates the end of the mail data by sending a
   line containing only a "." (period or full stop).  A transparency
   procedure is used to prevent this from interfering with the user's
   text (see Section 4.5.2).

   The end of mail data indicator also confirms the mail transaction and
   tells the SMTP server to now process the stored recipients and mail

   data.  If accepted, the SMTP server returns a "250 OK" reply.  The
   DATA command can fail at only two points in the protocol exchange:

   If there was no MAIL, or no RCPT, command, or all such commands were
   rejected, the server MAY return a "command out of sequence" (503) or
   "no valid recipients" (554) reply in response to the DATA command.
   If one of those replies (or any other 5yz reply) is received, the
   client MUST NOT send the message data; more generally, message data
   MUST NOT be sent unless a 354 reply is received.

   If the verb is initially accepted and the 354 reply issued, the DATA
   command should fail only if the mail transaction was incomplete (for
   example, no recipients), if resources were unavailable (including, of
   course, the server unexpectedly becoming unavailable), or if the
   server determines that the message should be rejected for policy or
   other reasons.

   However, in practice, some servers do not perform recipient
   verification until after the message text is received.  These servers
   SHOULD treat a failure for one or more recipients as a "subsequent
   failure" and return a mail message as discussed in Section 6 and, in
   particular, in Section 6.1.  Using a "550 mailbox not found" (or
   equivalent) reply code after the data are accepted makes it difficult
   or impossible for the client to determine which recipients failed.

   When the RFC 822 format ([28], [4]) is being used, the mail data
   include the header fields such as those named Date, Subject, To, Cc,
   and From.  Server SMTP systems SHOULD NOT reject messages based on
   perceived defects in the RFC 822 or MIME (RFC 2045 [21]) message
   header section or message body.  In particular, they MUST NOT reject
   messages in which the numbers of Resent-header fields do not match or
   Resent-to appears without Resent-from and/or Resent-date.

   Mail transaction commands MUST be used in the order discussed above.

3.4.  Forwarding for Address Correction or Updating

   Forwarding support is most often required to consolidate and simplify
   addresses within, or relative to, some enterprise and less frequently
   to establish addresses to link a person's prior address with a
   current one.  Silent forwarding of messages (without server
   notification to the sender), for security or non-disclosure purposes,
   is common in the contemporary Internet.

   In both the enterprise and the "new address" cases, information
   hiding (and sometimes security) considerations argue against exposure
   of the "final" address through the SMTP protocol as a side effect of
   the forwarding activity.  This may be especially important when the

   final address may not even be reachable by the sender.  Consequently,
   the "forwarding" mechanisms described in Section 3.2 of RFC 821, and
   especially the 251 (corrected destination) and 551 reply codes from
   RCPT must be evaluated carefully by implementers and, when they are
   available, by those configuring systems (see also Section 7.4).

   In particular:

   o  Servers MAY forward messages when they are aware of an address
      change.  When they do so, they MAY either provide address-updating
      information with a 251 code, or may forward "silently" and return
      a 250 code.  However, if a 251 code is used, they MUST NOT assume
      that the client will actually update address information or even
      return that information to the user.

   Alternately,

   o  Servers MAY reject messages or return them as non-deliverable when
      they cannot be delivered precisely as addressed.  When they do so,
      they MAY either provide address-updating information with a 551
      code, or may reject the message as undeliverable with a 550 code
      and no address-specific information.  However, if a 551 code is
      used, they MUST NOT assume that the client will actually update
      address information or even return that information to the user.

   SMTP server implementations that support the 251 and/or 551 reply
   codes SHOULD provide configuration mechanisms so that sites that
   conclude that they would undesirably disclose information can disable
   or restrict their use.

3.5.  Commands for Debugging Addresses

3.5.1.  Overview

   SMTP provides commands to verify a user name or obtain the content of
   a mailing list.  This is done with the VRFY and EXPN commands, which
   have character string arguments.  Implementations SHOULD support VRFY
   and EXPN (however, see Section 3.5.2 and Section 7.3).

   For the VRFY command, the string is a user name or a user name and
   domain (see below).  If a normal (i.e., 250) response is returned,
   the response MAY include the full name of the user and MUST include
   the mailbox of the user.  It MUST be in either of the following
   forms:

      User Name <local-part@domain>
      local-part@domain

   When a name that is the argument to VRFY could identify more than one
   mailbox, the server MAY either note the ambiguity or identify the
   alternatives.  In other words, any of the following are legitimate
   responses to VRFY:

      553 User ambiguous

   or

      553- Ambiguous; Possibilities are
      553-Joe Smith <jsmith@foo.com>
      553-Harry Smith <hsmith@foo.com>
      553 Melvin Smith <dweep@foo.com>

   or

      553-Ambiguous; Possibilities
      553- <jsmith@foo.com>
      553- <hsmith@foo.com>
      553 <dweep@foo.com>

   Under normal circumstances, a client receiving a 553 reply would be
   expected to expose the result to the user.  Use of exactly the forms
   given, and the "user ambiguous" or "ambiguous" keywords, possibly
   supplemented by extended reply codes, such as those described in RFC
   3463 [25], will facilitate automated translation into other languages
   as needed.  Of course, a client that was highly automated or that was
   operating in another language than English might choose to try to
   translate the response to return some other indication to the user
   than the literal text of the reply, or to take some automated action
   such as consulting a directory service for additional information
   before reporting to the user.

   For the EXPN command, the string identifies a mailing list, and the
   successful (i.e., 250) multiline response MAY include the full name
   of the users and MUST give the mailboxes on the mailing list.

   In some hosts, the distinction between a mailing list and an alias
   for a single mailbox is a bit fuzzy, since a common data structure
   may hold both types of entries, and it is possible to have mailing
   lists containing only one mailbox.  If a request is made to apply
   VRFY to a mailing list, a positive response MAY be given if a message
   so addressed would be delivered to everyone on the list, otherwise an
   error SHOULD be reported (e.g., "550 That is a mailing list, not a
   user" or "252 Unable to verify members of mailing list").  If a
   request is made to expand a user name, the server MAY return a

   positive response consisting of a list containing one name, or an
   error MAY be reported (e.g., "550 That is a user name, not a mailing
   list").

   In the case of a successful multiline reply (normal for EXPN),
   exactly one mailbox is to be specified on each line of the reply.
   The case of an ambiguous request is discussed above.

   "User name" is a fuzzy term and has been used deliberately.  An
   implementation of the VRFY or EXPN commands MUST include at least
   recognition of local mailboxes as "user names".  However, since
   current Internet practice often results in a single host handling
   mail for multiple domains, hosts, especially hosts that provide this
   functionality, SHOULD accept the "local-part@domain" form as a "user
   name"; hosts MAY also choose to recognize other strings as "user
   names".

   The case of expanding a mailbox list requires a multiline reply, such
   as:

      C: EXPN Example-People
      S: 250-Jon Postel <Postel@isi.edu>
      S: 250-Fred Fonebone <Fonebone@physics.foo-u.edu>
      S: 250 Sam Q. Smith <SQSmith@specific.generic.com>

   or

      C: EXPN Executive-Washroom-List
      S: 550 Access Denied to You.

   The character string arguments of the VRFY and EXPN commands cannot
   be further restricted due to the variety of implementations of the
   user name and mailbox list concepts.  On some systems, it may be
   appropriate for the argument of the EXPN command to be a file name
   for a file containing a mailing list, but again there are a variety
   of file naming conventions in the Internet.  Similarly, historical
   variations in what is returned by these commands are such that the
   response SHOULD be interpreted very carefully, if at all, and SHOULD
   generally only be used for diagnostic purposes.

3.5.2.  VRFY Normal Response

   When normal (2yz or 551) responses are returned from a VRFY or EXPN
   request, the reply MUST include the <Mailbox> name using a
   "<local-part@domain>" construction, where "domain" is a fully-
   qualified domain name.  In circumstances exceptional enough to
   justify violating the intent of this specification, free-form text
   MAY be returned.  In order to facilitate parsing by both computers

   and people, addresses SHOULD appear in pointed brackets.  When
   addresses, rather than free-form debugging information, are returned,
   EXPN and VRFY MUST return only valid domain addresses that are usable
   in SMTP RCPT commands.  Consequently, if an address implies delivery
   to a program or other system, the mailbox name used to reach that
   target MUST be given.  Paths (explicit source routes) MUST NOT be
   returned by VRFY or EXPN.

   Server implementations SHOULD support both VRFY and EXPN.  For
   security reasons, implementations MAY provide local installations a
   way to disable either or both of these commands through configuration
   options or the equivalent (see Section 7.3).  When these commands are
   supported, they are not required to work across relays when relaying
   is supported.  Since they were both optional in RFC 821, but VRFY was
   made mandatory in RFC 1123 [3], if EXPN is supported, it MUST be
   listed as a service extension in an EHLO response.  VRFY MAY be
   listed as a convenience but, since support for it is required, SMTP
   clients are not required to check for its presence on the extension
   list before using it.

3.5.3.  Meaning of VRFY or EXPN Success Response

   A server MUST NOT return a 250 code in response to a VRFY or EXPN
   command unless it has actually verified the address.  In particular,
   a server MUST NOT return 250 if all it has done is to verify that the
   syntax given is valid.  In that case, 502 (Command not implemented)
   or 500 (Syntax error, command unrecognized) SHOULD be returned.  As
   stated elsewhere, implementation (in the sense of actually validating
   addresses and returning information) of VRFY and EXPN are strongly
   recommended.  Hence, implementations that return 500 or 502 for VRFY
   are not in full compliance with this specification.

   There may be circumstances where an address appears to be valid but
   cannot reasonably be verified in real time, particularly when a
   server is acting as a mail exchanger for another server or domain.
   "Apparent validity", in this case, would normally involve at least
   syntax checking and might involve verification that any domains
   specified were ones to which the host expected to be able to relay
   mail.  In these situations, reply code 252 SHOULD be returned.  These
   cases parallel the discussion of RCPT verification in Section 2.1.
   Similarly, the discussion in Section 3.4 applies to the use of reply
   codes 251 and 551 with VRFY (and EXPN) to indicate addresses that are
   recognized but that would be forwarded or rejected were mail received
   for them.  Implementations generally SHOULD be more aggressive about
   address verification in the case of VRFY than in the case of RCPT,
   even if it takes a little longer to do so.

3.5.4.  Semantics and Applications of EXPN

   EXPN is often very useful in debugging and understanding problems
   with mailing lists and multiple-target-address aliases.  Some systems
   have attempted to use source expansion of mailing lists as a means of
   eliminating duplicates.  The propagation of aliasing systems with
   mail on the Internet for hosts (typically with MX and CNAME DNS
   records), for mailboxes (various types of local host aliases), and in
   various proxying arrangements has made it nearly impossible for these
   strategies to work consistently, and mail systems SHOULD NOT attempt
   them.

3.6.  Relaying and Mail Routing

3.6.1.  Source Routes and Relaying

   In general, the availability of Mail eXchanger records in the domain
   name system (RFC 1035 [2], RFC 974 [12]) makes the use of explicit
   source routes in the Internet mail system unnecessary.  Many
   historical problems with the interpretation of explicit source routes
   have made their use undesirable.  SMTP clients SHOULD NOT generate
   explicit source routes except under unusual circumstances.  SMTP
   servers MAY decline to act as mail relays or to accept addresses that
   specify source routes.  When route information is encountered, SMTP
   servers MAY ignore the route information and simply send to the final
   destination specified as the last element in the route and SHOULD do
   so.  There has been an invalid practice of using names that do not
   appear in the DNS as destination names, with the senders counting on
   the intermediate hosts specified in source routing to resolve any
   problems.  If source routes are stripped, this practice will cause
   failures.  This is one of several reasons why SMTP clients MUST NOT
   generate invalid source routes or depend on serial resolution of
   names.

   When source routes are not used, the process described in RFC 821 for
   constructing a reverse-path from the forward-path is not applicable
   and the reverse-path at the time of delivery will simply be the
   address that appeared in the MAIL command.

3.6.2.  Mail eXchange Records and Relaying

   A relay SMTP server is usually the target of a DNS MX record that
   designates it, rather than the final delivery system.  The relay
   server may accept or reject the task of relaying the mail in the same
   way it accepts or rejects mail for a local user.  If it accepts the
   task, it then becomes an SMTP client, establishes a transmission
   channel to the next SMTP server specified in the DNS (according to
   the rules in Section 5), and sends it the mail.  If it declines to

   relay mail to a particular address for policy reasons, a 550 response
   SHOULD be returned.

   This specification does not deal with the verification of return
   paths for use in delivery notifications.  Recent work, such as that
   on SPF [29] and DKIM [30] [31], has been done to provide ways to
   ascertain that an address is valid or belongs to the person who
   actually sent the message.  A server MAY attempt to verify the return
   path before using its address for delivery notifications, but methods
   of doing so are not defined here nor is any particular method
   recommended at this time.

3.6.3.  Message Submission Servers as Relays

   Many mail-sending clients exist, especially in conjunction with
   facilities that receive mail via POP3 or IMAP, that have limited
   capability to support some of the requirements of this specification,
   such as the ability to queue messages for subsequent delivery
   attempts.  For these clients, it is common practice to make private
   arrangements to send all messages to a single server for processing
   and subsequent distribution.  SMTP, as specified here, is not ideally
   suited for this role.  A standardized mail submission protocol has
   been developed that is gradually superseding practices based on SMTP
   (see RFC 4409 [18]).  In any event, because these arrangements are
   private and fall outside the scope of this specification, they are
   not described here.

   It is important to note that MX records can point to SMTP servers
   that act as gateways into other environments, not just SMTP relays
   and final delivery systems; see Sections 3.7 and 5.

   If an SMTP server has accepted the task of relaying the mail and
   later finds that the destination is incorrect or that the mail cannot
   be delivered for some other reason, then it MUST construct an
   "undeliverable mail" notification message and send it to the
   originator of the undeliverable mail (as indicated by the reverse-
   path).  Formats specified for non-delivery reports by other standards
   (see, for example, RFC 3461 [32] and RFC 3464 [33]) SHOULD be used if
   possible.

   This notification message must be from the SMTP server at the relay
   host or the host that first determines that delivery cannot be
   accomplished.  Of course, SMTP servers MUST NOT send notification
   messages about problems transporting notification messages.  One way
   to prevent loops in error reporting is to specify a null reverse-path
   in the MAIL command of a notification message.  When such a message
   is transmitted, the reverse-path MUST be set to null (see

   Section 4.5.5 for additional discussion).  A MAIL command with a null
   reverse-path appears as follows:

      MAIL FROM:<>

   As discussed in Section 6.4, a relay SMTP has no need to inspect or
   act upon the header section or body of the message data and MUST NOT
   do so except to add its own "Received:" header field (Section 4.4)
   and, optionally, to attempt to detect looping in the mail system (see
   Section 6.3).  Of course, this prohibition also applies to any
   modifications of these header fields or text (see also Section 7.9).

3.7.  Mail Gatewaying

   While the relay function discussed above operates within the Internet
   SMTP transport service environment, MX records or various forms of
   explicit routing may require that an intermediate SMTP server perform
   a translation function between one transport service and another.  As
   discussed in Section 2.3.10, when such a system is at the boundary
   between two transport service environments, we refer to it as a
   "gateway" or "gateway SMTP".

   Gatewaying mail between different mail environments, such as
   different mail formats and protocols, is complex and does not easily
   yield to standardization.  However, some general requirements may be
   given for a gateway between the Internet and another mail
   environment.

3.7.1.  Header Fields in Gatewaying

   Header fields MAY be rewritten when necessary as messages are
   gatewayed across mail environment boundaries.  This may involve
   inspecting the message body or interpreting the local-part of the
   destination address in spite of the prohibitions in Section 6.4.

   Other mail systems gatewayed to the Internet often use a subset of
   the RFC 822 header section or provide similar functionality with a
   different syntax, but some of these mail systems do not have an
   equivalent to the SMTP envelope.  Therefore, when a message leaves
   the Internet environment, it may be necessary to fold the SMTP
   envelope information into the message header section.  A possible
   solution would be to create new header fields to carry the envelope
   information (e.g., "X-SMTP-MAIL:" and "X-SMTP-RCPT:"); however, this
   would require changes in mail programs in foreign environments and
   might risk disclosure of private information (see Section 7.2).

3.7.2.  Received Lines in Gatewaying

   When forwarding a message into or out of the Internet environment, a
   gateway MUST prepend a Received: line, but it MUST NOT alter in any
   way a Received: line that is already in the header section.

   "Received:" header fields of messages originating from other
   environments may not conform exactly to this specification.  However,
   the most important use of Received: lines is for debugging mail
   faults, and this debugging can be severely hampered by well-meaning
   gateways that try to "fix" a Received: line.  As another consequence
   of trace header fields arising in non-SMTP environments, receiving
   systems MUST NOT reject mail based on the format of a trace header
   field and SHOULD be extremely robust in the light of unexpected
   information or formats in those header fields.

   The gateway SHOULD indicate the environment and protocol in the "via"
   clauses of Received header field(s) that it supplies.

3.7.3.  Addresses in Gatewaying

   From the Internet side, the gateway SHOULD accept all valid address
   formats in SMTP commands and in the RFC 822 header section, and all
   valid RFC 822 messages.  Addresses and header fields generated by
   gateways MUST conform to applicable standards (including this one and
   RFC 5322 [4]).  Gateways are, of course, subject to the same rules
   for handling source routes as those described for other SMTP systems
   in Section 3.3.

3.7.4.  Other Header Fields in Gatewaying

   The gateway MUST ensure that all header fields of a message that it
   forwards into the Internet mail environment meet the requirements for
   Internet mail.  In particular, all addresses in "From:", "To:",
   "Cc:", etc., header fields MUST be transformed (if necessary) to
   satisfy the standard header syntax of RFC 5322 [4], MUST reference
   only fully-qualified domain names, and MUST be effective and useful
   for sending replies.  The translation algorithm used to convert mail
   from the Internet protocols to another environment's protocol SHOULD
   ensure that error messages from the foreign mail environment are
   delivered to the reverse-path from the SMTP envelope, not to an
   address in the "From:", "Sender:", or similar header fields of the
   message.

3.7.5.  Envelopes in Gatewaying

   Similarly, when forwarding a message from another environment into
   the Internet, the gateway SHOULD set the envelope return path in
   accordance with an error message return address, if supplied by the
   foreign environment.  If the foreign environment has no equivalent
   concept, the gateway must select and use a best approximation, with
   the message originator's address as the default of last resort.

3.8.  Terminating Sessions and Connections

   An SMTP connection is terminated when the client sends a QUIT
   command.  The server responds with a positive reply code, after which
   it closes the connection.

   An SMTP server MUST NOT intentionally close the connection under
   normal operational circumstances (see Section 7.8) except:

   o  After receiving a QUIT command and responding with a 221 reply.

   o  After detecting the need to shut down the SMTP service and
      returning a 421 response code.  This response code can be issued
      after the server receives any command or, if necessary,
      asynchronously from command receipt (on the assumption that the
      client will receive it after the next command is issued).

   o  After a timeout, as specified in Section 4.5.3.2, occurs waiting
      for the client to send a command or data.

   In particular, a server that closes connections in response to
   commands that are not understood is in violation of this
   specification.  Servers are expected to be tolerant of unknown
   commands, issuing a 500 reply and awaiting further instructions from
   the client.

   An SMTP server that is forcibly shut down via external means SHOULD
   attempt to send a line containing a 421 response code to the SMTP
   client before exiting.  The SMTP client will normally read the 421
   response code after sending its next command.

   SMTP clients that experience a connection close, reset, or other
   communications failure due to circumstances not under their control
   (in violation of the intent of this specification but sometimes
   unavoidable) SHOULD, to maintain the robustness of the mail system,
   treat the mail transaction as if a 451 response had been received and
   act accordingly.

3.9.  Mailing Lists and Aliases

   An SMTP-capable host SHOULD support both the alias and the list
   models of address expansion for multiple delivery.  When a message is
   delivered or forwarded to each address of an expanded list form, the
   return address in the envelope ("MAIL FROM:") MUST be changed to be
   the address of a person or other entity who administers the list.
   However, in this case, the message header section (RFC 5322 [4]) MUST
   be left unchanged; in particular, the "From" field of the header
   section is unaffected.

   An important mail facility is a mechanism for multi-destination
   delivery of a single message, by transforming (or "expanding" or
   "exploding") a pseudo-mailbox address into a list of destination
   mailbox addresses.  When a message is sent to such a pseudo-mailbox
   (sometimes called an "exploder"), copies are forwarded or
   redistributed to each mailbox in the expanded list.  Servers SHOULD
   simply utilize the addresses on the list; application of heuristics
   or other matching rules to eliminate some addresses, such as that of
   the originator, is strongly discouraged.  We classify such a pseudo-
   mailbox as an "alias" or a "list", depending upon the expansion
   rules.

3.9.1.  Alias

   To expand an alias, the recipient mailer simply replaces the pseudo-
   mailbox address in the envelope with each of the expanded addresses
   in turn; the rest of the envelope and the message body are left
   unchanged.  The message is then delivered or forwarded to each
   expanded address.

3.9.2.  List

   A mailing list may be said to operate by "redistribution" rather than
   by "forwarding".  To expand a list, the recipient mailer replaces the
   pseudo-mailbox address in the envelope with each of the expanded
   addresses in turn.  The return (backward-pointing) address in the
   envelope is changed so that all error messages generated by the final
   deliveries will be returned to a list administrator, not to the
   message originator, who generally has no control over the contents of
   the list and will typically find error messages annoying.  Note that
   the key difference between handling aliases (Section 3.9.1) and
   forwarding (this subsection) is the change to the backward-pointing
   address in this case.  When a list constrains its processing to the
   very limited set of modifications and actions described here, it is
   attempting to emulate an MTA; such lists can be treated as a
   continuation in email transit.

   There exist mailing lists that perform additional, sometimes
   extensive, modifications to a message and its envelope.  Such mailing
   lists need to be viewed as full MUAs, which accept a delivery and
   post a new message.

4.  The SMTP Specifications

4.1.  SMTP Commands

4.1.1.  Command Semantics and Syntax

   The SMTP commands define the mail transfer or the mail system
   function requested by the user.  SMTP commands are character strings
   terminated by <CRLF>.  The commands themselves are alphabetic
   characters terminated by <SP> if parameters follow and <CRLF>
   otherwise.  (In the interest of improved interoperability, SMTP
   receivers SHOULD tolerate trailing white space before the terminating
   <CRLF>.)  The syntax of the local part of a mailbox MUST conform to
   receiver site conventions and the syntax specified in Section 4.1.2.
   The SMTP commands are discussed below.  The SMTP replies are
   discussed in Section 4.2.

   A mail transaction involves several data objects that are
   communicated as arguments to different commands.  The reverse-path is
   the argument of the MAIL command, the forward-path is the argument of
   the RCPT command, and the mail data is the argument of the DATA
   command.  These arguments or data objects must be transmitted and
   held, pending the confirmation communicated by the end of mail data
   indication that finalizes the transaction.  The model for this is
   that distinct buffers are provided to hold the types of data objects;
   that is, there is a reverse-path buffer, a forward-path buffer, and a
   mail data buffer.  Specific commands cause information to be appended
   to a specific buffer, or cause one or more buffers to be cleared.

   Several commands (RSET, DATA, QUIT) are specified as not permitting
   parameters.  In the absence of specific extensions offered by the
   server and accepted by the client, clients MUST NOT send such
   parameters and servers SHOULD reject commands containing them as
   having invalid syntax.

4.1.1.1.  Extended HELLO (EHLO) or HELLO (HELO)

   These commands are used to identify the SMTP client to the SMTP
   server.  The argument clause contains the fully-qualified domain name
   of the SMTP client, if one is available.  In situations in which the
   SMTP client system does not have a meaningful domain name (e.g., when
   its address is dynamically allocated and no reverse mapping record is

   available), the client SHOULD send an address literal (see
   Section 4.1.3).

   RFC 2821, and some earlier informal practices, encouraged following
   the literal by information that would help to identify the client
   system.  That convention was not widely supported, and many SMTP
   servers considered it an error.  In the interest of interoperability,
   it is probably wise for servers to be prepared for this string to
   occur, but SMTP clients SHOULD NOT send it.

   The SMTP server identifies itself to the SMTP client in the
   connection greeting reply and in the response to this command.

   A client SMTP SHOULD start an SMTP session by issuing the EHLO
   command.  If the SMTP server supports the SMTP service extensions, it
   will give a successful response, a failure response, or an error
   response.  If the SMTP server, in violation of this specification,
   does not support any SMTP service extensions, it will generate an
   error response.  Older client SMTP systems MAY, as discussed above,
   use HELO (as specified in RFC 821) instead of EHLO, and servers MUST
   support the HELO command and reply properly to it.  In any event, a
   client MUST issue HELO or EHLO before starting a mail transaction.

   These commands, and a "250 OK" reply to one of them, confirm that
   both the SMTP client and the SMTP server are in the initial state,
   that is, there is no transaction in progress and all state tables and
   buffers are cleared.

   Syntax:

   ehlo           = "EHLO" SP ( Domain / address-literal ) CRLF

   helo           = "HELO" SP Domain CRLF

   Normally, the response to EHLO will be a multiline reply.  Each line
   of the response contains a keyword and, optionally, one or more
   parameters.  Following the normal syntax for multiline replies, these
   keywords follow the code (250) and a hyphen for all but the last
   line, and the code and a space for the last line.  The syntax for a
   positive response, using the ABNF notation and terminal symbols of
   RFC 5234 [7], is:

   ehlo-ok-rsp    = ( "250" SP Domain [ SP ehlo-greet ] CRLF )
                    / ( "250-" Domain [ SP ehlo-greet ] CRLF
                    *( "250-" ehlo-line CRLF )
                    "250" SP ehlo-line CRLF )

   ehlo-greet     = 1*(%d0-9 / %d11-12 / %d14-127)
                    ; string of any characters other than CR or LF

   ehlo-line      = ehlo-keyword *( SP ehlo-param )

   ehlo-keyword   = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
                    ; additional syntax of ehlo-params depends on
                    ; ehlo-keyword

   ehlo-param     = 1*(%d33-126)
                    ; any CHAR excluding <SP> and all
                    ; control characters (US-ASCII 0-31 and 127
                    ; inclusive)

   Although EHLO keywords may be specified in upper, lower, or mixed
   case, they MUST always be recognized and processed in a case-
   insensitive manner.  This is simply an extension of practices
   specified in RFC 821 and Section 2.4.

   The EHLO response MUST contain keywords (and associated parameters if
   required) for all commands not listed as "required" in Section 4.5.1
   excepting only private-use commands as described in Section 4.1.5.
   Private-use commands MAY be listed.

4.1.1.2.  MAIL (MAIL)

   This command is used to initiate a mail transaction in which the mail
   data is delivered to an SMTP server that may, in turn, deliver it to
   one or more mailboxes or pass it on to another system (possibly using
   SMTP).  The argument clause contains a reverse-path and may contain
   optional parameters.  In general, the MAIL command may be sent only
   when no mail transaction is in progress, see Section 4.1.4.

   The reverse-path consists of the sender mailbox.  Historically, that
   mailbox might optionally have been preceded by a list of hosts, but
   that behavior is now deprecated (see Appendix C).  In some types of
   reporting messages for which a reply is likely to cause a mail loop
   (for example, mail delivery and non-delivery notifications), the
   reverse-path may be null (see Section 3.6).

   This command clears the reverse-path buffer, the forward-path buffer,
   and the mail data buffer, and it inserts the reverse-path information
   from its argument clause into the reverse-path buffer.

   If service extensions were negotiated, the MAIL command may also
   carry parameters associated with a particular service extension.

   Syntax:

   mail = "MAIL FROM:" Reverse-path
                                       [SP Mail-parameters] CRLF

4.1.1.3.  RECIPIENT (RCPT)

   This command is used to identify an individual recipient of the mail
   data; multiple recipients are specified by multiple uses of this
   command.  The argument clause contains a forward-path and may contain
   optional parameters.

   The forward-path normally consists of the required destination
   mailbox.  Sending systems SHOULD NOT generate the optional list of
   hosts known as a source route.  Receiving systems MUST recognize
   source route syntax but SHOULD strip off the source route
   specification and utilize the domain name associated with the mailbox
   as if the source route had not been provided.

   Similarly, relay hosts SHOULD strip or ignore source routes, and
   names MUST NOT be copied into the reverse-path.  When mail reaches
   its ultimate destination (the forward-path contains only a
   destination mailbox), the SMTP server inserts it into the destination
   mailbox in accordance with its host mail conventions.

   This command appends its forward-path argument to the forward-path
   buffer; it does not change the reverse-path buffer nor the mail data
   buffer.

   For example, mail received at relay host xyz.com with envelope
   commands

      MAIL FROM:<userx@y.foo.org>
      RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org>

   will normally be sent directly on to host d.bar.org with envelope
   commands

      MAIL FROM:<userx@y.foo.org>
      RCPT TO:<userc@d.bar.org>

   As provided in Appendix C, xyz.com MAY also choose to relay the
   message to hosta.int, using the envelope commands

      MAIL FROM:<userx@y.foo.org>
      RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org>

   or to jkl.org, using the envelope commands

      MAIL FROM:<userx@y.foo.org>
      RCPT TO:<@jkl.org:userc@d.bar.org>

   Attempting to use relaying this way is now strongly discouraged.
   Since hosts are not required to relay mail at all, xyz.com MAY also
   reject the message entirely when the RCPT command is received, using
   a 550 code (since this is a "policy reason").

   If service extensions were negotiated, the RCPT command may also
   carry parameters associated with a particular service extension
   offered by the server.  The client MUST NOT transmit parameters other
   than those associated with a service extension offered by the server
   in its EHLO response.

   Syntax:

      rcpt = "RCPT TO:" ( "<Postmaster@" Domain ">" / "<Postmaster>" /
                  Forward-path ) [SP Rcpt-parameters] CRLF

                  Note that, in a departure from the usual rules for
                  local-parts, the "Postmaster" string shown above is
                  treated as case-insensitive.

4.1.1.4.  DATA (DATA)

   The receiver normally sends a 354 response to DATA, and then treats
   the lines (strings ending in <CRLF> sequences, as described in
   Section 2.3.7) following the command as mail data from the sender.
   This command causes the mail data to be appended to the mail data
   buffer.  The mail data may contain any of the 128 ASCII character
   codes, although experience has indicated that use of control
   characters other than SP, HT, CR, and LF may cause problems and
   SHOULD be avoided when possible.

   The mail data are terminated by a line containing only a period, that
   is, the character sequence "<CRLF>.<CRLF>", where the first <CRLF> is
   actually the terminator of the previous line (see Section 4.5.2).
   This is the end of mail data indication.  The first <CRLF> of this
   terminating sequence is also the <CRLF> that ends the final line of
   the data (message text) or, if there was no mail data, ends the DATA
   command itself (the "no mail data" case does not conform to this
   specification since it would require that neither the trace header
   fields required by this specification nor the message header section
   required by RFC 5322 [4] be transmitted).  An extra <CRLF> MUST NOT
   be added, as that would cause an empty line to be added to the
   message.  The only exception to this rule would arise if the message

   body were passed to the originating SMTP-sender with a final "line"
   that did not end in <CRLF>; in that case, the originating SMTP system
   MUST either reject the message as invalid or add <CRLF> in order to
   have the receiving SMTP server recognize the "end of data" condition.

   The custom of accepting lines ending only in <LF>, as a concession to
   non-conforming behavior on the part of some UNIX systems, has proven
   to cause more interoperability problems than it solves, and SMTP
   server systems MUST NOT do this, even in the name of improved
   robustness.  In particular, the sequence "<LF>.<LF>" (bare line
   feeds, without carriage returns) MUST NOT be treated as equivalent to
   <CRLF>.<CRLF> as the end of mail data indication.

   Receipt of the end of mail data indication requires the server to
   process the stored mail transaction information.  This processing
   consumes the information in the reverse-path buffer, the forward-path
   buffer, and the mail data buffer, and on the completion of this
   command these buffers are cleared.  If the processing is successful,
   the receiver MUST send an OK reply.  If the processing fails, the
   receiver MUST send a failure reply.  The SMTP model does not allow
   for partial failures at this point: either the message is accepted by
   the server for delivery and a positive response is returned or it is
   not accepted and a failure reply is returned.  In sending a positive
   "250 OK" completion reply to the end of data indication, the receiver
   takes full responsibility for the message (see Section 6.1).  Errors
   that are diagnosed subsequently MUST be reported in a mail message,
   as discussed in Section 4.4.

   When the SMTP server accepts a message either for relaying or for
   final delivery, it inserts a trace record (also referred to
   interchangeably as a "time stamp line" or "Received" line) at the top
   of the mail data.  This trace record indicates the identity of the
   host that sent the message, the identity of the host that received
   the message (and is inserting this time stamp), and the date and time
   the message was received.  Relayed messages will have multiple time
   stamp lines.  Details for formation of these lines, including their
   syntax, is specified in Section 4.4.

   Additional discussion about the operation of the DATA command appears
   in Section 3.3.

   Syntax:

      data = "DATA" CRLF

4.1.1.5.  RESET (RSET)

   This command specifies that the current mail transaction will be
   aborted.  Any stored sender, recipients, and mail data MUST be
   discarded, and all buffers and state tables cleared.  The receiver
   MUST send a "250 OK" reply to a RSET command with no arguments.  A
   reset command may be issued by the client at any time.  It is
   effectively equivalent to a NOOP (i.e., it has no effect) if issued
   immediately after EHLO, before EHLO is issued in the session, after
   an end of data indicator has been sent and acknowledged, or
   immediately before a QUIT.  An SMTP server MUST NOT close the
   connection as the result of receiving a RSET; that action is reserved
   for QUIT (see Section 4.1.1.10).

   Since EHLO implies some additional processing and response by the
   server, RSET will normally be more efficient than reissuing that
   command, even though the formal semantics are the same.

   There are circumstances, contrary to the intent of this
   specification, in which an SMTP server may receive an indication that
   the underlying TCP connection has been closed or reset.  To preserve
   the robustness of the mail system, SMTP servers SHOULD be prepared
   for this condition and SHOULD treat it as if a QUIT had been received
   before the connection disappeared.

   Syntax:

      rset = "RSET" CRLF

4.1.1.6.  VERIFY (VRFY)

   This command asks the receiver to confirm that the argument
   identifies a user or mailbox.  If it is a user name, information is
   returned as specified in Section 3.5.

   This command has no effect on the reverse-path buffer, the forward-
   path buffer, or the mail data buffer.

   Syntax:

      vrfy = "VRFY" SP String CRLF

4.1.1.7.  EXPAND (EXPN)

   This command asks the receiver to confirm that the argument
   identifies a mailing list, and if so, to return the membership of
   that list.  If the command is successful, a reply is returned
   containing information as described in Section 3.5.  This reply will
   have multiple lines except in the trivial case of a one-member list.

   This command has no effect on the reverse-path buffer, the forward-
   path buffer, or the mail data buffer, and it may be issued at any
   time.

   Syntax:

      expn = "EXPN" SP String CRLF

4.1.1.8.  HELP (HELP)

   This command causes the server to send helpful information to the
   client.  The command MAY take an argument (e.g., any command name)
   and return more specific information as a response.

   This command has no effect on the reverse-path buffer, the forward-
   path buffer, or the mail data buffer, and it may be issued at any
   time.

   SMTP servers SHOULD support HELP without arguments and MAY support it
   with arguments.

   Syntax:

      help = "HELP" [ SP String ] CRLF

4.1.1.9.  NOOP (NOOP)

   This command does not affect any parameters or previously entered
   commands.  It specifies no action other than that the receiver send a
   "250 OK" reply.

   This command has no effect on the reverse-path buffer, the forward-
   path buffer, or the mail data buffer, and it may be issued at any
   time.  If a parameter string is specified, servers SHOULD ignore it.

   Syntax:

      noop = "NOOP" [ SP String ] CRLF

4.1.1.10.  QUIT (QUIT)

   This command specifies that the receiver MUST send a "221 OK" reply,
   and then close the transmission channel.

   The receiver MUST NOT intentionally close the transmission channel
   until it receives and replies to a QUIT command (even if there was an
   error).  The sender MUST NOT intentionally close the transmission
   channel until it sends a QUIT command, and it SHOULD wait until it
   receives the reply (even if there was an error response to a previous
   command).  If the connection is closed prematurely due to violations
   of the above or system or network failure, the server MUST cancel any
   pending transaction, but not undo any previously completed
   transaction, and generally MUST act as if the command or transaction
   in progress had received a temporary error (i.e., a 4yz response).

   The QUIT command may be issued at any time.  Any current uncompleted
   mail transaction will be aborted.

   Syntax:

      quit = "QUIT" CRLF

4.1.1.11.  Mail-Parameter and Rcpt-Parameter Error Responses

   If the server SMTP does not recognize or cannot implement one or more
   of the parameters associated with a particular MAIL FROM or RCPT TO
   command, it will return code 555.

   If, for some reason, the server is temporarily unable to accommodate
   one or more of the parameters associated with a MAIL FROM or RCPT TO
   command, and if the definition of the specific parameter does not
   mandate the use of another code, it should return code 455.

   Errors specific to particular parameters and their values will be
   specified in the parameter's defining RFC.

4.1.2.  Command Argument Syntax

   The syntax of the argument clauses of the above commands (using the
   syntax specified in RFC 5234 [7] where applicable) is given below.
   Some of the productions given below are used only in conjunction with
   source routes as described in Appendix C.  Terminals not defined in
   this document, such as ALPHA, DIGIT, SP, CR, LF, CRLF, are as defined
   in the "core" syntax in Section 6 of RFC 5234 [7] or in the message
   format syntax in RFC 5322 [4].

   Reverse-path   = Path / "<>"

   Forward-path   = Path

   Path           = "<" [ A-d-l ":" ] Mailbox ">"

   A-d-l          = At-domain *( "," At-domain )
                  ; Note that this form, the so-called "source
                  ; route", MUST BE accepted, SHOULD NOT be
                  ; generated, and SHOULD be ignored.

   At-domain      = "@" Domain

   Mail-parameters  = esmtp-param *(SP esmtp-param)

   Rcpt-parameters  = esmtp-param *(SP esmtp-param)

   esmtp-param    = esmtp-keyword ["=" esmtp-value]

   esmtp-keyword  = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")

   esmtp-value    = 1*(%d33-60 / %d62-126)
                  ; any CHAR excluding "=", SP, and control
                  ; characters.  If this string is an email address,
                  ; i.e., a Mailbox, then the "xtext" syntax [32]
                  ; SHOULD be used.

   Keyword        = Ldh-str

   Argument       = Atom

   Domain         = sub-domain *("." sub-domain)

   sub-domain     = Let-dig [Ldh-str]

   Let-dig        = ALPHA / DIGIT

   Ldh-str        = *( ALPHA / DIGIT / "-" ) Let-dig

   address-literal  = "[" ( IPv4-address-literal /
                    IPv6-address-literal /
                    General-address-literal ) "]"
                    ; See Section 4.1.3

   Mailbox        = Local-part "@" ( Domain / address-literal )

   Local-part     = Dot-string / Quoted-string
                  ; MAY be case-sensitive


   Dot-string     = Atom *("."  Atom)

   Atom           = 1*atext

   Quoted-string  = DQUOTE *QcontentSMTP DQUOTE

   QcontentSMTP   = qtextSMTP / quoted-pairSMTP

   quoted-pairSMTP  = %d92 %d32-126
                    ; i.e., backslash followed by any ASCII
                    ; graphic (including itself) or SPace

   qtextSMTP      = %d32-33 / %d35-91 / %d93-126
                  ; i.e., within a quoted string, any
                  ; ASCII graphic or space is permitted
                  ; without blackslash-quoting except
                  ; double-quote and the backslash itself.

   String         = Atom / Quoted-string

   While the above definition for Local-part is relatively permissive,
   for maximum interoperability, a host that expects to receive mail
   SHOULD avoid defining mailboxes where the Local-part requires (or
   uses) the Quoted-string form or where the Local-part is case-
   sensitive.  For any purposes that require generating or comparing
   Local-parts (e.g., to specific mailbox names), all quoted forms MUST
   be treated as equivalent, and the sending system SHOULD transmit the
   form that uses the minimum quoting possible.

   Systems MUST NOT define mailboxes in such a way as to require the use
   in SMTP of non-ASCII characters (octets with the high order bit set

   to one) or ASCII "control characters" (decimal value 0-31 and 127).
   These characters MUST NOT be used in MAIL or RCPT commands or other
   commands that require mailbox names.

   Note that the backslash, "\", is a quote character, which is used to
   indicate that the next character is to be used literally (instead of
   its normal interpretation).  For example, "Joe\,Smith" indicates a
   single nine-character user name string with the comma being the
   fourth character of that string.

   To promote interoperability and consistent with long-standing
   guidance about conservative use of the DNS in naming and applications
   (e.g., see Section 2.3.1 of the base DNS document, RFC 1035 [2]),
   characters outside the set of alphabetic characters, digits, and
   hyphen MUST NOT appear in domain name labels for SMTP clients or
   servers.  In particular, the underscore character is not permitted.
   SMTP servers that receive a command in which invalid character codes
   have been employed, and for which there are no other reasons for
   rejection, MUST reject that command with a 501 response (this rule,
   like others, could be overridden by appropriate SMTP extensions).

4.1.3.  Address Literals

   Sometimes a host is not known to the domain name system and
   communication (and, in particular, communication to report and repair
   the error) is blocked.  To bypass this barrier, a special literal
   form of the address is allowed as an alternative to a domain name.
   For IPv4 addresses, this form uses four small decimal integers
   separated by dots and enclosed by brackets such as [123.255.37.2],
   which indicates an (IPv4) Internet Address in sequence-of-octets
   form.  For IPv6 and other forms of addressing that might eventually
   be standardized, the form consists of a standardized "tag" that
   identifies the address syntax, a colon, and the address itself, in a
   format specified as part of the relevant standards (i.e., RFC 4291
   [8] for IPv6).

   Specifically:

   IPv4-address-literal  = Snum 3("."  Snum)

   IPv6-address-literal  = "IPv6:" IPv6-addr

   General-address-literal  = Standardized-tag ":" 1*dcontent

   Standardized-tag  = Ldh-str
                     ; Standardized-tag MUST be specified in a
                     ; Standards-Track RFC and registered with IANA

   dcontent       = %d33-90 / ; Printable US-ASCII
                  %d94-126 ; excl. "[", "\", "]"

   Snum           = 1*3DIGIT
                  ; representing a decimal integer
                  ; value in the range 0 through 255

   IPv6-addr      = IPv6-full / IPv6-comp / IPv6v4-full / IPv6v4-comp

   IPv6-hex       = 1*4HEXDIG

   IPv6-full      = IPv6-hex 7(":" IPv6-hex)

   IPv6-comp      = [IPv6-hex *5(":" IPv6-hex)] "::"
                  [IPv6-hex *5(":" IPv6-hex)]
                  ; The "::" represents at least 2 16-bit groups of
                  ; zeros.  No more than 6 groups in addition to the
                  ; "::" may be present.

   IPv6v4-full    = IPv6-hex 5(":" IPv6-hex) ":" IPv4-address-literal

   IPv6v4-comp    = [IPv6-hex *3(":" IPv6-hex)] "::"
                  [IPv6-hex *3(":" IPv6-hex) ":"]
                  IPv4-address-literal
                  ; The "::" represents at least 2 16-bit groups of
                  ; zeros.  No more than 4 groups in addition to the
                  ; "::" and IPv4-address-literal may be present.

4.1.4.  Order of Commands

   There are restrictions on the order in which these commands may be
   used.

   A session that will contain mail transactions MUST first be
   initialized by the use of the EHLO command.  An SMTP server SHOULD
   accept commands for non-mail transactions (e.g., VRFY or EXPN)
   without this initialization.

   An EHLO command MAY be issued by a client later in the session.  If
   it is issued after the session begins and the EHLO command is
   acceptable to the SMTP server, the SMTP server MUST clear all buffers
   and reset the state exactly as if a RSET command had been issued.  In
   other words, the sequence of RSET followed immediately by EHLO is
   redundant, but not harmful other than in the performance cost of
   executing unnecessary commands.

   If the EHLO command is not acceptable to the SMTP server, 501, 500,
   502, or 550 failure replies MUST be returned as appropriate.  The

   SMTP server MUST stay in the same state after transmitting these
   replies that it was in before the EHLO was received.

   The SMTP client MUST, if possible, ensure that the domain parameter
   to the EHLO command is a primary host name as specified for this
   command in Section 2.3.5.  If this is not possible (e.g., when the
   client's address is dynamically assigned and the client does not have
   an obvious name), an address literal SHOULD be substituted for the
   domain name.

   An SMTP server MAY verify that the domain name argument in the EHLO
   command actually corresponds to the IP address of the client.
   However, if the verification fails, the server MUST NOT refuse to
   accept a message on that basis.  Information captured in the
   verification attempt is for logging and tracing purposes.  Note that
   this prohibition applies to the matching of the parameter to its IP
   address only; see Section 7.9 for a more extensive discussion of
   rejecting incoming connections or mail messages.

   The NOOP, HELP, EXPN, VRFY, and RSET commands can be used at any time
   during a session, or without previously initializing a session.  SMTP
   servers SHOULD process these normally (that is, not return a 503
   code) even if no EHLO command has yet been received; clients SHOULD
   open a session with EHLO before sending these commands.

   If these rules are followed, the example in RFC 821 that shows "550
   access denied to you" in response to an EXPN command is incorrect
   unless an EHLO command precedes the EXPN or the denial of access is
   based on the client's IP address or other authentication or
   authorization-determining mechanisms.

   The MAIL command (or the obsolete SEND, SOML, or SAML commands)
   begins a mail transaction.  Once started, a mail transaction consists
   of a transaction beginning command, one or more RCPT commands, and a
   DATA command, in that order.  A mail transaction may be aborted by
   the RSET, a new EHLO, or the QUIT command.  There may be zero or more
   transactions in a session.  MAIL (or SEND, SOML, or SAML) MUST NOT be
   sent if a mail transaction is already open, i.e., it should be sent
   only if no mail transaction had been started in the session, or if
   the previous one successfully concluded with a successful DATA
   command, or if the previous one was aborted, e.g., with a RSET or new
   EHLO.

   If the transaction beginning command argument is not acceptable, a
   501 failure reply MUST be returned and the SMTP server MUST stay in
   the same state.  If the commands in a transaction are out of order to
   the degree that they cannot be processed by the server, a 503 failure

   reply MUST be returned and the SMTP server MUST stay in the same
   state.

   The last command in a session MUST be the QUIT command.  The QUIT
   command SHOULD be used by the client SMTP to request connection
   closure, even when no session opening command was sent and accepted.

4.1.5.  Private-Use Commands

   As specified in Section 2.2.2, commands starting in "X" may be used
   by bilateral agreement between the client (sending) and server
   (receiving) SMTP agents.  An SMTP server that does not recognize such
   a command is expected to reply with "500 Command not recognized".  An
   extended SMTP server MAY list the feature names associated with these
   private commands in the response to the EHLO command.

   Commands sent or accepted by SMTP systems that do not start with "X"
   MUST conform to the requirements of Section 2.2.2.