7.  Security Considerations

7.1.  Mail Security and Spoofing

   SMTP mail is inherently insecure in that it is feasible for even
   fairly casual users to negotiate directly with receiving and relaying
   SMTP servers and create messages that will trick a naive recipient
   into believing that they came from somewhere else.  Constructing such
   a message so that the "spoofed" behavior cannot be detected by an
   expert is somewhat more difficult, but not sufficiently so as to be a
   deterrent to someone who is determined and knowledgeable.
   Consequently, as knowledge of Internet mail increases, so does the
   knowledge that SMTP mail inherently cannot be authenticated, or
   integrity checks provided, at the transport level.  Real mail
   security lies only in end-to-end methods involving the message
   bodies, such as those that use digital signatures (see RFC 1847 [43]
   and, e.g., Pretty Good Privacy (PGP) in RFC 4880 [44] or Secure/
   Multipurpose Internet Mail Extensions (S/MIME) in RFC 3851 [45]).

   Various protocol extensions and configuration options that provide
   authentication at the transport level (e.g., from an SMTP client to
   an SMTP server) improve somewhat on the traditional situation
   described above.  However, in general, they only authenticate one
   server to another rather than a chain of relays and servers, much
   less authenticating users or user machines.  Consequently, unless
   they are accompanied by careful handoffs of responsibility in a
   carefully designed trust environment, they remain inherently weaker
   than end-to-end mechanisms that use digitally signed messages rather
   than depending on the integrity of the transport system.

   Efforts to make it more difficult for users to set envelope return
   path and header "From" fields to point to valid addresses other than
   their own are largely misguided: they frustrate legitimate
   applications in which mail is sent by one user on behalf of another,
   in which error (or normal) replies should be directed to a special
   address, or in which a single message is sent to multiple recipients
   on different hosts.  (Systems that provide convenient ways for users
   to alter these header fields on a per-message basis should attempt to
   establish a primary and permanent mailbox address for the user so
   that Sender header fields within the message data can be generated
   sensibly.)

   This specification does not further address the authentication issues
   associated with SMTP other than to advocate that useful functionality
   not be disabled in the hope of providing some small margin of
   protection against a user who is trying to fake mail.

7.2.  "Blind" Copies

   Addresses that do not appear in the message header section may appear
   in the RCPT commands to an SMTP server for a number of reasons.  The
   two most common involve the use of a mailing address as a "list
   exploder" (a single address that resolves into multiple addresses)
   and the appearance of "blind copies".  Especially when more than one
   RCPT command is present, and in order to avoid defeating some of the
   purpose of these mechanisms, SMTP clients and servers SHOULD NOT copy
   the full set of RCPT command arguments into the header section,
   either as part of trace header fields or as informational or private-
   extension header fields.  Since this rule is often violated in
   practice, and cannot be enforced, sending SMTP systems that are aware
   of "bcc" use MAY find it helpful to send each blind copy as a
   separate message transaction containing only a single RCPT command.

   There is no inherent relationship between either "reverse" (from
   MAIL, SAML, etc., commands) or "forward" (RCPT) addresses in the SMTP
   transaction ("envelope") and the addresses in the header section.
   Receiving systems SHOULD NOT attempt to deduce such relationships and
   use them to alter the header section of the message for delivery.
   The popular "Apparently-to" header field is a violation of this
   principle as well as a common source of unintended information
   disclosure and SHOULD NOT be used.

7.3.  VRFY, EXPN, and Security

   As discussed in Section 3.5, individual sites may want to disable
   either or both of VRFY or EXPN for security reasons (see below).  As
   a corollary to the above, implementations that permit this MUST NOT
   appear to have verified addresses that are not, in fact, verified.
   If a site disables these commands for security reasons, the SMTP
   server MUST return a 252 response, rather than a code that could be
   confused with successful or unsuccessful verification.

   Returning a 250 reply code with the address listed in the VRFY
   command after having checked it only for syntax violates this rule.
   Of course, an implementation that "supports" VRFY by always returning
   550 whether or not the address is valid is equally not in
   conformance.

   On the public Internet, the contents of mailing lists have become
   popular as an address information source for so-called "spammers."

   The use of EXPN to "harvest" addresses has increased as list
   administrators have installed protections against inappropriate uses
   of the lists themselves.  However, VRFY and EXPN are still useful for
   authenticated users and within an administrative domain.  For
   example, VRFY and EXPN are useful for performing internal audits of
   how email gets routed to check and to make sure no one is
   automatically forwarding sensitive mail outside the organization.
   Sites implementing SMTP authentication may choose to make VRFY and
   EXPN available only to authenticated requestors.  Implementations
   SHOULD still provide support for EXPN, but sites SHOULD carefully
   evaluate the tradeoffs.

   Whether disabling VRFY provides any real marginal security depends on
   a series of other conditions.  In many cases, RCPT commands can be
   used to obtain the same information about address validity.  On the
   other hand, especially in situations where determination of address
   validity for RCPT commands is deferred until after the DATA command
   is received, RCPT may return no information at all, while VRFY is
   expected to make a serious attempt to determine validity before
   generating a response code (see discussion above).

7.4.  Mail Rerouting Based on the 251 and 551 Response Codes

   Before a client uses the 251 or 551 reply codes from a RCPT command
   to automatically update its future behavior (e.g., updating the
   user's address book), it should be certain of the server's
   authenticity.  If it does not, it may be subject to a man in the
   middle attack.

7.5.  Information Disclosure in Announcements

   There has been an ongoing debate about the tradeoffs between the
   debugging advantages of announcing server type and version (and,
   sometimes, even server domain name) in the greeting response or in
   response to the HELP command and the disadvantages of exposing
   information that might be useful in a potential hostile attack.  The
   utility of the debugging information is beyond doubt.  Those who
   argue for making it available point out that it is far better to
   actually secure an SMTP server rather than hope that trying to
   conceal known vulnerabilities by hiding the server's precise identity
   will provide more protection.  Sites are encouraged to evaluate the
   tradeoff with that issue in mind; implementations SHOULD minimally
   provide for making type and version information available in some way
   to other network hosts.

7.6.  Information Disclosure in Trace Fields

   In some circumstances, such as when mail originates from within a LAN
   whose hosts are not directly on the public Internet, trace
   ("Received") header fields produced in conformance with this
   specification may disclose host names and similar information that
   would not normally be available.  This ordinarily does not pose a
   problem, but sites with special concerns about name disclosure should
   be aware of it.  Also, the optional FOR clause should be supplied
   with caution or not at all when multiple recipients are involved lest
   it inadvertently disclose the identities of "blind copy" recipients
   to others.

7.7.  Information Disclosure in Message Forwarding

   As discussed in Section 3.4, use of the 251 or 551 reply codes to
   identify the replacement address associated with a mailbox may
   inadvertently disclose sensitive information.  Sites that are
   concerned about those issues should ensure that they select and
   configure servers appropriately.

7.8.  Resistance to Attacks

   In recent years, there has been an increase of attacks on SMTP
   servers, either in conjunction with attempts to discover addresses
   for sending unsolicited messages or simply to make the servers
   inaccessible to others (i.e., as an application-level denial of
   service attack).  While the means of doing so are beyond the scope of
   this Standard, rational operational behavior requires that servers be
   permitted to detect such attacks and take action to defend
   themselves.  For example, if a server determines that a large number
   of RCPT TO commands are being sent, most or all with invalid
   addresses, as part of such an attack, it would be reasonable for the
   server to close the connection after generating an appropriate number
   of 5yz (normally 550) replies.

7.9.  Scope of Operation of SMTP Servers

   It is a well-established principle that an SMTP server may refuse to
   accept mail for any operational or technical reason that makes sense
   to the site providing the server.  However, cooperation among sites
   and installations makes the Internet possible.  If sites take
   excessive advantage of the right to reject traffic, the ubiquity of
   email availability (one of the strengths of the Internet) will be
   threatened; considerable care should be taken and balance maintained
   if a site decides to be selective about the traffic it will accept
   and process.

   In recent years, use of the relay function through arbitrary sites
   has been used as part of hostile efforts to hide the actual origins
   of mail.  Some sites have decided to limit the use of the relay
   function to known or identifiable sources, and implementations SHOULD
   provide the capability to perform this type of filtering.  When mail
   is rejected for these or other policy reasons, a 550 code SHOULD be
   used in response to EHLO (or HELO), MAIL, or RCPT as appropriate.

8.  IANA Considerations

   IANA maintains three registries in support of this specification, all
   of which were created for RFC 2821 or earlier.  This document expands
   the third one as specified below.  The registry references listed are
   as of the time of publication; IANA does not guarantee the locations
   associated with the URLs.  The registries are as follows:

   o  The first, "Simple Mail Transfer Protocol (SMTP) Service
      Extensions" [46], consists of SMTP service extensions with the
      associated keywords, and, as needed, parameters and verbs.  As
      specified in Section 2.2.2, no entry may be made in this registry
      that starts in an "X".  Entries may be made only for service
      extensions (and associated keywords, parameters, or verbs) that
      are defined in Standards-Track or Experimental RFCs specifically
      approved by the IESG for this purpose.

   o  The second registry, "Address Literal Tags" [47], consists of
      "tags" that identify forms of domain literals other than those for
      IPv4 addresses (specified in RFC 821 and in this document).  The
      initial entry in that registry is for IPv6 addresses (specified in
      this document).  Additional literal types require standardization
      before being used; none are anticipated at this time.

   o  The third, "Mail Transmission Types" [46], established by RFC 821
      and renewed by this specification, is a registry of link and
      protocol identifiers to be used with the "via" and "with"
      subclauses of the time stamp ("Received:" header field) described
      in Section 4.4.  Link and protocol identifiers in addition to
      those specified in this document may be registered only by
      standardization or by way of an RFC-documented, IESG-approved,
      Experimental protocol extension.  This name space is for
      identification and not limited in size: the IESG is encouraged to
      approve on the basis of clear documentation and a distinct method
      rather than preferences about the properties of the method itself.

      An additional subsection has been added to the "VIA link types"
      and "WITH protocol types" subsections of this registry to contain
      registrations of "Additional-registered-clauses" as described
      above.  The registry will contain clause names, a description, a

      summary of the syntax of the associated String, and a reference.
      As new clauses are defined, they may, in principle, specify
      creation of their own registries if the Strings consist of
      reserved terms or keywords rather than less restricted strings.
      As with link and protocol identifiers, additional clauses may be
      registered only by standardization or by way of an RFC-documented,
      IESG-approved, Experimental protocol extension.  The additional
      clause name space is for identification and is not limited in
      size: the IESG is encouraged to approve on the basis of clear
      documentation, actual use or strong signs that the clause will be
      used, and a distinct requirement rather than preferences about the
      properties of the clause itself.

   In addition, if additional trace header fields (i.e., in addition to
   Return-path and Received) are ever created, those trace fields MUST
   be added to the IANA registry established by BCP 90 (RFC 3864) [11]
   for use with RFC 5322 [4].

9.  Acknowledgments

   Many people contributed to the development of RFC 2821.  That
   document should be consulted for those acknowledgments.  For the
   present document, the editor and the community owe thanks to Dawn
   Mann and Tony Hansen who assisted in the very painful process of
   editing and converting the internal format of the document from one
   system to another.

   Neither this document nor RFC 2821 would have been possible without
   the many contribution and insights of the late Jon Postel.  Those
   contributions of course include the original specification of SMTP in
   RFC 821.  A considerable quantity of text from RFC 821 still appears
   in this document as do several of Jon's original examples that have
   been updated only as needed to reflect other changes in the
   specification.

   Many people made comments or suggestions on the mailing list or in
   notes to the author.  Important corrections or clarifications were
   suggested by several people, including Matti Aarnio, Glenn Anderson,
   Derek J. Balling, Alex van den Bogaerdt, Stephane Bortzmeyer, Vint
   Cerf, Jutta Degener, Steve Dorner, Lisa Dusseault, Frank Ellerman,
   Ned Freed, Randy Gellens, Sabahattin Gucukoglu, Philip Guenther, Arnt
   Gulbrandsen, Eric Hall, Richard O. Hammer, Tony Hansen, Peter J.
   Holzer, Kari Hurtta, Bryon Roche Kain, Valdis Kletnieks, Mathias
   Koerber, John Leslie, Bruce Lilly, Jeff Macdonald, Mark E. Mallett,
   Mark Martinec, S. Moonesamy, Lyndon Nerenberg, Chris Newman, Douglas
   Otis, Pete Resnick, Robert A. Rosenberg, Vince Sabio, Hector Santos,
   David F. Skoll, Paul Smith, and Brett Watson.

   The efforts of the Area Directors -- Lisa Dusseault, Ted Hardie, and
   Chris Newman -- to get this effort restarted and keep it moving, and
   of an ad hoc committee with the same purpose, are gratefully
   acknowledged.  The members of that committee were (in alphabetical
   order) Dave Crocker, Cyrus Daboo, Tony Finch, Ned Freed, Randall
   Gellens, Tony Hansen, the author, and Alexey Melnikov.  Tony Hansen
   also acted as ad hoc chair on the mailing list reviewing this
   document; without his efforts, sense of balance and fairness, and
   patience, it clearly would not have been possible.

10.  References

10.1.  Normative References

   [1]   Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
         August 1982.

   [2]   Mockapetris, P., "Domain names - implementation and
         specification", STD 13, RFC 1035, November 1987.

   [3]   Braden, R., "Requirements for Internet Hosts - Application and
         Support", STD 3, RFC 1123, October 1989.

   [4]   Resnick, P., "Internet Message Format", RFC 5322, October 2008.

   [5]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [6]   American National Standards Institute (formerly United States
         of America Standards Institute), "USA Code for Information
         Interchange", ANSI X3.4-1968, 1968.

         ANSI X3.4-1968 has been replaced by newer versions with slight
         modifications, but the 1968 version remains definitive for the
         Internet.

   [7]   Crocker, D. and P. Overell, "Augmented BNF for Syntax
         Specifications: ABNF", STD 68, RFC 5234, January 2008.

   [8]   Hinden, R. and S. Deering, "IP Version 6 Addressing
         Architecture", RFC 4291, February 2006.

   [9]   Newman, C., "ESMTP and LMTP Transmission Types Registration",
         RFC 3848, July 2004.

   [10]  Klensin, J., Freed, N., and K. Moore, "SMTP Service Extension
         for Message Size Declaration", STD 10, RFC 1870, November 1995.

   [11]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
         Procedures for Message Header Fields", BCP 90, RFC 3864,
         September 2004.

10.2.  Informative References

   [12]  Partridge, C., "Mail routing and the domain system", RFC 974,
         January 1986.

   [13]  Klensin, J., Freed, N., Rose, M., Stefferud, E., and D.
         Crocker, "SMTP Service Extensions", STD 10, RFC 1869,
         November 1995.

   [14]  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
         April 2001.

   [15]  Butler, M., Postel, J., Chase, D., Goldberger, J., and J.
         Reynolds, "Post Office Protocol: Version 2", RFC 937,
         February 1985.

   [16]  Myers, J. and M. Rose, "Post Office Protocol - Version 3",
         STD 53, RFC 1939, May 1996.

   [17]  Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
         4rev1", RFC 3501, March 2003.

   [18]  Gellens, R. and J. Klensin, "Message Submission for Mail",
         RFC 4409, April 2006.

   [19]  Freed, N., "SMTP Service Extension for Command Pipelining",
         STD 60, RFC 2920, September 2000.

   [20]  Vaudreuil, G., "SMTP Service Extensions for Transmission of
         Large and Binary MIME Messages", RFC 3030, December 2000.

   [21]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
         Extensions (MIME) Part One: Format of Internet Message Bodies",
         RFC 2045, November 1996.

   [22]  Klensin, J., Freed, N., Rose, M., Stefferud, E., and D.
         Crocker, "SMTP Service Extension for 8bit-MIMEtransport",
         RFC 1652, July 1994.

   [23]  Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part
         Three: Message Header Extensions for Non-ASCII Text", RFC 2047,
         November 1996.

   [24]  Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word
         Extensions: Character Sets, Languages, and Continuations",
         RFC 2231, November 1997.

   [25]  Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463,
         January 2003.

   [26]  Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced Mail
         System Status Codes", BCP 138, RFC 5248, June 2008.

   [27]  Freed, N., "Behavior of and Requirements for Internet
         Firewalls", RFC 2979, October 2000.

   [28]  Crocker, D., "Standard for the format of ARPA Internet text
         messages", STD 11, RFC 822, August 1982.

   [29]  Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) for
         Authorizing Use of Domains in E-Mail, Version 1", RFC 4408,
         April 2006.

   [30]  Fenton, J., "Analysis of Threats Motivating DomainKeys
         Identified Mail (DKIM)", RFC 4686, September 2006.

   [31]  Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and
         M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures",
         RFC 4871, May 2007.

   [32]  Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
         Extension for Delivery Status Notifications (DSNs)", RFC 3461,
         January 2003.

   [33]  Moore, K. and G. Vaudreuil, "An Extensible Message Format for
         Delivery Status Notifications", RFC 3464, January 2003.

   [34]  Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9,
         RFC 959, October 1985.

   [35]  Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping
         between X.400 and RFC 822/MIME", RFC 2156, January 1998.

   [36]  De Winter, J., "SMTP Service Extension for Remote Message Queue
         Starting", RFC 1985, August 1996.

   [37]  Hansen, T. and G. Vaudreuil, "Message Disposition
         Notification", RFC 3798, May 2004.

   [38]  Elz, R. and R. Bush, "Clarifications to the DNS Specification",
         RFC 2181, July 1997.

   [39]  Nakamura, M. and J. Hagino, "SMTP Operational Experience in
         Mixed IPv4/v6 Environments", RFC 3974, January 2005.

   [40]  Partridge, C., "Duplicate messages and SMTP", RFC 1047,
         February 1988.

   [41]  Crispin, M., "Interactive Mail Access Protocol: Version 2",
         RFC 1176, August 1990.

   [42]  Lambert, M., "PCMAIL: A distributed mail system for personal
         computers", RFC 1056, June 1988.

   [43]  Galvin, J., Murphy, S., Crocker, S., and N. Freed, "Security
         Multiparts for MIME: Multipart/Signed and Multipart/Encrypted",
         RFC 1847, October 1995.

   [44]  Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
         Thayer, "OpenPGP Message Format", RFC 4880, November 2007.

   [45]  Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
         (S/MIME) Version 3.1 Message Specification", RFC 3851,
         July 2004.

   [46]  Internet Assigned Number Authority (IANA), "IANA Mail
         Parameters", 2007,
         <http://www.iana.org/assignments/mail-parameters>.

   [47]  Internet Assigned Number Authority (IANA), "Address Literal
         Tags", 2007,
         <http://www.iana.org/assignments/address-literal-tags>.

Appendix A.  TCP Transport Service

   The TCP connection supports the transmission of 8-bit bytes.  The
   SMTP data is 7-bit ASCII characters.  Each character is transmitted
   as an 8-bit byte with the high-order bit cleared to zero.  Service
   extensions may modify this rule to permit transmission of full 8-bit
   data bytes as part of the message body, or, if specifically designed
   to do so, in SMTP commands or responses.

Appendix B.  Generating SMTP Commands from RFC 822 Header Fields

   Some systems use an RFC 822 header section (only) in a mail
   submission protocol, or otherwise generate SMTP commands from RFC 822
   header fields when such a message is handed to an MTA from a UA.
   While the MTA-UA protocol is a private matter, not covered by any
   Internet Standard, there are problems with this approach.  For
   example, there have been repeated problems with proper handling of
   "bcc" copies and redistribution lists when information that
   conceptually belongs to the mail envelope is not separated early in
   processing from header field information (and kept separate).

   It is recommended that the UA provide its initial ("submission
   client") MTA with an envelope separate from the message itself.
   However, if the envelope is not supplied, SMTP commands SHOULD be
   generated as follows:

   1.  Each recipient address from a TO, CC, or BCC header field SHOULD
       be copied to a RCPT command (generating multiple message copies
       if that is required for queuing or delivery).  This includes any
       addresses listed in a RFC 822 "group".  Any BCC header fields
       SHOULD then be removed from the header section.  Once this
       process is completed, the remaining header fields SHOULD be
       checked to verify that at least one TO, CC, or BCC header field
       remains.  If none do, then a BCC header field with no additional
       information SHOULD be inserted as specified in [4].

   2.  The return address in the MAIL command SHOULD, if possible, be
       derived from the system's identity for the submitting (local)
       user, and the "From:" header field otherwise.  If there is a
       system identity available, it SHOULD also be copied to the Sender
       header field if it is different from the address in the From
       header field.  (Any Sender header field that was already there
       SHOULD be removed.)  Systems may provide a way for submitters to
       override the envelope return address, but may want to restrict
       its use to privileged users.  This will not prevent mail forgery,
       but may lessen its incidence; see Section 7.1.

   When an MTA is being used in this way, it bears responsibility for
   ensuring that the message being transmitted is valid.  The mechanisms
   for checking that validity, and for handling (or returning) messages
   that are not valid at the time of arrival, are part of the MUA-MTA
   interface and not covered by this specification.

   A submission protocol based on Standard RFC 822 information alone
   MUST NOT be used to gateway a message from a foreign (non-SMTP) mail
   system into an SMTP environment.  Additional information to construct
   an envelope must come from some source in the other environment,
   whether supplemental header fields or the foreign system's envelope.

   Attempts to gateway messages using only their header "To" and "Cc"
   fields have repeatedly caused mail loops and other behavior adverse
   to the proper functioning of the Internet mail environment.  These
   problems have been especially common when the message originates from
   an Internet mailing list and is distributed into the foreign
   environment using envelope information.  When these messages are then
   processed by a header-section-only remailer, loops back to the
   Internet environment (and the mailing list) are almost inevitable.

Appendix C.  Source Routes

   Historically, the <reverse-path> was a reverse source routing list of
   hosts and a source mailbox.  The first host in the <reverse-path> was
   historically the host sending the MAIL command; today, source routes
   SHOULD NOT appear in the reverse-path.  Similarly, the <forward-path>
   may be a source routing lists of hosts and a destination mailbox.
   However, in general, the <forward-path> SHOULD contain only a mailbox
   and domain name, relying on the domain name system to supply routing
   information if required.  The use of source routes is deprecated (see
   Appendix F.2); while servers MUST be prepared to receive and handle
   them as discussed in Section 3.3 and Appendix F.2, clients SHOULD NOT
   transmit them and this section is included in the current
   specification only to provide context.  It has been modified somewhat
   from the material in RFC 821 to prevent server actions that might
   confuse clients or subsequent servers that do not expect a full
   source route implementation.

   For relay purposes, the forward-path may be a source route of the
   form "@ONE,@TWO:JOE@THREE", where ONE, TWO, and THREE MUST be fully-
   qualified domain names.  This form is used to emphasize the
   distinction between an address and a route.  The mailbox (here, JOE@
   THREE) is an absolute address, and the route is information about how
   to get there.  The two concepts should not be confused.

   If source routes are used, RFC 821 and the text below should be
   consulted for the mechanisms for constructing and updating the

   forward-path.  A server that is reached by means of a source route
   (e.g., its domain name appears first in the list in the forward-path)
   MUST remove its domain name from any forward-paths in which that
   domain name appears before forwarding the message and MAY remove all
   other source routing information.  The reverse-path SHOULD NOT be
   updated by servers conforming to this specification.

   Notice that the forward-path and reverse-path appear in the SMTP
   commands and replies, but not necessarily in the message.  That is,
   there is no need for these paths and especially this syntax to appear
   in the "To:" , "From:", "CC:", etc. fields of the message header
   section.  Conversely, SMTP servers MUST NOT derive final message
   routing information from message header fields.

   When the list of hosts is present despite the recommendations above,
   it is a "reverse" source route and indicates that the mail was
   relayed through each host on the list (the first host in the list was
   the most recent relay).  This list is used as a source route to
   return non-delivery notices to the sender.  If, contrary to the
   recommendations here, a relay host adds itself to the beginning of
   the list, it MUST use its name as known in the transport environment
   to which it is relaying the mail rather than that of the transport
   environment from which the mail came (if they are different).  Note
   that a situation could easily arise in which some relay hosts add
   their names to the reverse source route and others do not, generating
   discontinuities in the routing list.  This is another reason why
   servers needing to return a message SHOULD ignore the source route
   entirely and simply use the domain as specified in the Mailbox.

Appendix D.  Scenarios

   This section presents complete scenarios of several types of SMTP
   sessions.  In the examples, "C:" indicates what is said by the SMTP
   client, and "S:" indicates what is said by the SMTP server.

D.1.  A Typical SMTP Transaction Scenario

   This SMTP example shows mail sent by Smith at host bar.com, and to
   Jones, Green, and Brown at host foo.com.  Here we assume that host
   bar.com contacts host foo.com directly.  The mail is accepted for
   Jones and Brown.  Green does not have a mailbox at host foo.com.

      S: 220 foo.com Simple Mail Transfer Service Ready
      C: EHLO bar.com
      S: 250-foo.com greets bar.com
      S: 250-8BITMIME
      S: 250-SIZE
      S: 250-DSN
      S: 250 HELP
      C: MAIL FROM:<Smith@bar.com>
      S: 250 OK
      C: RCPT TO:<Jones@foo.com>
      S: 250 OK
      C: RCPT TO:<Green@foo.com>
      S: 550 No such user here
      C: RCPT TO:<Brown@foo.com>
      S: 250 OK
      C: DATA
      S: 354 Start mail input; end with <CRLF>.<CRLF>
      C: Blah blah blah...
      C: ...etc. etc. etc.
      C: .
      S: 250 OK
      C: QUIT
      S: 221 foo.com Service closing transmission channel

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

   The source host performs a DNS lookup on XYZ.COM (the destination
   address) and finds DNS MX records specifying xyz.com as the best
   preference and foo.com as a lower preference.  It attempts to open a
   connection to xyz.com and fails.  It then opens a connection to
   foo.com, with the following dialogue:

      S: 220 foo.com Simple Mail Transfer Service Ready
      C: EHLO bar.com
      S: 250-foo.com greets bar.com
      S: 250-8BITMIME
      S: 250-SIZE
      S: 250-DSN
      S: 250 HELP
      C: MAIL FROM:<JQP@bar.com>
      S: 250 OK
      C: RCPT TO:<Jones@XYZ.COM>
      S: 250 OK
      C: DATA
      S: 354 Start mail input; end with <CRLF>.<CRLF>
      C: Date: Thu, 21 May 1998 05:33:29 -0700
      C: From: John Q. Public <JQP@bar.com>
      C: Subject: The Next Meeting of the Board
      C: To: Jones@xyz.com
      C:
      C: Bill:
      C: The next meeting of the board of directors will be
      C: on Tuesday.
      C: John.
      C: .
      S: 250 OK
      C: QUIT
      S: 221 foo.com Service closing transmission channel

   Step 2 -- Relay Host to Destination Host

   foo.com, having received the message, now does a DNS lookup on
   xyz.com.  It finds the same set of MX records, but cannot use the one
   that points to itself (or to any other host as a worse preference).
   It tries to open a connection to xyz.com itself and succeeds.  Then
   we have:

           S: 220 xyz.com Simple Mail Transfer Service Ready
           C: EHLO foo.com
           S: 250 xyz.com is on the air
           C: MAIL FROM:<JQP@bar.com>
           S: 250 OK
           C: RCPT TO:<Jones@XYZ.COM>
           S: 250 OK
           C: DATA
           S: 354 Start mail input; end with <CRLF>.<CRLF>
           C: Received: from bar.com by foo.com ; Thu, 21 May 1998
           C:     05:33:29 -0700
           C: Date: Thu, 21 May 1998 05:33:22 -0700
           C: From: John Q. Public <JQP@bar.com>
           C: Subject:  The Next Meeting of the Board
           C: To: Jones@xyz.com
           C:
           C: Bill:
           C: The next meeting of the board of directors will be
           C: on Tuesday.
           C:                         John.
           C: .
           S: 250 OK
           C: QUIT
           S: 221 foo.com Service closing transmission channel

D.4.  Verifying and Sending Scenario

      S: 220 foo.com Simple Mail Transfer Service Ready
      C: EHLO bar.com
      S: 250-foo.com greets bar.com
      S: 250-8BITMIME
      S: 250-SIZE
      S: 250-DSN
      S: 250-VRFY
      S: 250 HELP
      C: VRFY Crispin
      S: 250 Mark Crispin <Admin.MRC@foo.com>
      C: MAIL FROM:<EAK@bar.com>
      S: 250 OK
      C: RCPT TO:<Admin.MRC@foo.com>
      S: 250 OK
      C: DATA
      S: 354 Start mail input; end with <CRLF>.<CRLF>
      C: Blah blah blah...
      C: ...etc. etc. etc.
      C: .
      S: 250 OK
      C: QUIT
      S: 221 foo.com Service closing transmission channel

Appendix E.  Other Gateway Issues

   In general, gateways between the Internet and other mail systems
   SHOULD attempt to preserve any layering semantics across the
   boundaries between the two mail systems involved.  Gateway-
   translation approaches that attempt to take shortcuts by mapping
   (such as mapping envelope information from one system to the message
   header section or body of another) have generally proven to be
   inadequate in important ways.  Systems translating between
   environments that do not support both envelopes and a header section
   and Internet mail must be written with the understanding that some
   information loss is almost inevitable.

Appendix F.  Deprecated Features of RFC 821

   A few features of RFC 821 have proven to be problematic and SHOULD
   NOT be used in Internet mail.

F.1.  TURN

   This command, described in RFC 821, raises important security issues
   since, in the absence of strong authentication of the host requesting
   that the client and server switch roles, it can easily be used to
   divert mail from its correct destination.  Its use is deprecated;
   SMTP systems SHOULD NOT use it unless the server can authenticate the
   client.

F.2.  Source Routing

   RFC 821 utilized the concept of explicit source routing to get mail
   from one host to another via a series of relays.  The requirement to
   utilize source routes in regular mail traffic was eliminated by the
   introduction of the domain name system "MX" record and the last
   significant justification for them was eliminated by the
   introduction, in RFC 1123, of a clear requirement that addresses
   following an "@" must all be fully-qualified domain names.
   Consequently, the only remaining justifications for the use of source
   routes are support for very old SMTP clients or MUAs and in mail
   system debugging.  They can, however, still be useful in the latter
   circumstance and for routing mail around serious, but temporary,
   problems such as problems with the relevant DNS records.

   SMTP servers MUST continue to accept source route syntax as specified
   in the main body of this document and in RFC 1123.  They MAY, if
   necessary, ignore the routes and utilize only the target domain in
   the address.  If they do utilize the source route, the message MUST
   be sent to the first domain shown in the address.  In particular, a
   server MUST NOT guess at shortcuts within the source route.

   Clients SHOULD NOT utilize explicit source routing except under
   unusual circumstances, such as debugging or potentially relaying
   around firewall or mail system configuration errors.

F.3.  HELO

   As discussed in Sections 3.1 and 4.1.1, EHLO SHOULD be used rather
   than HELO when the server will accept the former.  Servers MUST
   continue to accept and process HELO in order to support older
   clients.

F.4.  #-literals

   RFC 821 provided for specifying an Internet address as a decimal
   integer host number prefixed by a pound sign, "#".  In practice, that
   form has been obsolete since the introduction of TCP/IP.  It is
   deprecated and MUST NOT be used.

F.5.  Dates and Years

   When dates are inserted into messages by SMTP clients or servers
   (e.g., in trace header fields), four-digit years MUST BE used.  Two-
   digit years are deprecated; three-digit years were never permitted in
   the Internet mail system.

F.6.  Sending versus Mailing

   In addition to specifying a mechanism for delivering messages to
   user's mailboxes, RFC 821 provided additional, optional, commands to
   deliver messages directly to the user's terminal screen.  These
   commands (SEND, SAML, SOML) were rarely implemented, and changes in
   workstation technology and the introduction of other protocols may
   have rendered them obsolete even where they are implemented.

   Clients SHOULD NOT provide SEND, SAML, or SOML as services.  Servers
   MAY implement them.  If they are implemented by servers, the
   implementation model specified in RFC 821 MUST be used and the
   command names MUST be published in the response to the EHLO command.

Author's Address

   John C. Klensin
   1770 Massachusetts Ave, Suite 322
   Cambridge, MA  02140
   USA

   EMail: john+smtp@jck.com

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.