7. Security Considerations

7.1 Mail Security and Spoofing

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

   Various protocol extensions and configuration options that provide
   authentication at the transport level (e.g., from an SMTP client to
   an SMTP server) improve somewhat on the traditional situation
   described above.  However, unless they are accompanied by careful
   handoffs of responsibility in a carefully-designed trust environment,
   they remain inherently weaker than end-to-end mechanisms which use
   digitally signed messages rather than depending on the integrity of
   the transport system.

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

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

7.2 "Blind" Copies

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

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

7.3 VRFY, EXPN, and Security

   As discussed in section 3.5, individual sites may want to disable
   either or both of VRFY or EXPN for security reasons.  As a corollary
   to the above, implementations that permit this MUST NOT appear to
   have verified addresses that are not, in fact, verified.  If a site

   disables these commands for security reasons, the SMTP server MUST
   return a 252 response, rather than a code that could be confused with
   successful or unsuccessful verification.

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

   Within the last few years, the contents of mailing lists have become
   popular as an address information source for so-called "spammers."
   The use of EXPN to "harvest" addresses has increased as list
   administrators have installed protections against inappropriate uses
   of the lists themselves.  Implementations SHOULD still provide
   support for EXPN, but sites SHOULD carefully evaluate the tradeoffs.
   As authentication mechanisms are introduced into SMTP, some sites may
   choose to make EXPN available only to authenticated requestors.

7.4 Information Disclosure in Announcements

   There has been an ongoing debate about the tradeoffs between the
   debugging advantages of announcing server type and version (and,
   sometimes, even server domain name) in the greeting response or in
   response to the HELP command and the disadvantages of exposing
   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 are strongly
   encouraged to minimally provide for making type and version
   information available in some way to other network hosts.

7.5 Information Disclosure in Trace Fields

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

7.6 Information Disclosure in Message Forwarding

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

7.7 Scope of Operation of SMTP Servers

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

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

8. IANA Considerations

   IANA will maintain three registries in support of this specification.
   The first consists of SMTP service extensions with the associated
   keywords, and, as needed, parameters and verbs.  As specified in
   section 2.2.2, no entry may be made in this registry that starts in
   an "X".  Entries may be made only for service extensions (and
   associated keywords, parameters, or verbs) that are defined in
   standards-track or experimental RFCs specifically approved by the
   IESG for this purpose.

   The second registry consists of "tags" that identify forms of domain
   literals other than those for IPv4 addresses (specified in RFC 821
   and in this document) and IPv6 addresses (specified in this
   document).  Additional literal types require standardization before
   being used; none are anticipated at this time.

   The third, established by RFC 821 and renewed by this specification,
   is a registry of link and protocol identifiers to be used with the
   "via" and "with" subclauses of the time stamp ("Received: header")

   described in section 4.4.  Link and protocol identifiers in addition
   to those specified in this document may be registered only by
   standardization or by way of an RFC-documented, IESG-approved,
   Experimental protocol extension.

9. References

   [1]  American National Standards Institute (formerly United States of
        America Standards Institute), X3.4, 1968, "USA Code for
        Information Interchange". ANSI X3.4-1968 has been replaced by
        newer versions with slight modifications, but the 1968 version
        remains definitive for the Internet.

   [2]  Braden, R., "Requirements for Internet hosts - application and
        support", STD 3, RFC 1123, October 1989.

   [3]  Butler, M., Chase, D., Goldberger, J., Postel, J. and J.
        Reynolds, "Post Office Protocol - version 2", RFC 937, February
        1985.

   [4]  Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP
        Message Format", RFC 2440, November 1998.

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

   [6]  Crispin, M., "Internet Message Access Protocol - Version 4", RFC
        2060, December 1996.

   [7]  Crocker, D., "Standard for the Format of ARPA Internet Text
        Messages", RFC 822, August 1982.

   [8]  Crocker, D. and P. Overell, Eds., "Augmented BNF for Syntax
        Specifications: ABNF", RFC 2234, November 1997.

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

   [10] Fajman, R., "An Extensible Message Format for Message
        Disposition Notifications", RFC 2298, March 1998.

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

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

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

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

   [15] Gellens, R. and J. Klensin, "Message Submission", RFC 2476,
        December 1998.

   [16] Kille, S., "Mapping between X.400 and RFC822/MIME", RFC 2156,
        January 1998.

   [17] Hinden, R and S. Deering, Eds. "IP Version 6 Addressing
        Architecture", RFC 2373, July 1998.

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

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

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

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

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

        Mockapetris, P., "Domain names - concepts and facilities", STD
        13, RFC 1034, November 1987.

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

   [24] Moore, K., "SMTP Service Extension for Delivery Status
        Notifications", RFC 1891, January 1996.

   [25] Moore, K., and G. Vaudreuil, "An Extensible Message Format for
        Delivery Status Notifications", RFC 1894, January 1996.

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

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

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

   [29] Postel, J., ed., "Transmission Control Protocol - DARPA Internet
        Program Protocol Specification", STD 7, RFC 793, September 1981.

   [30] Postel, J., "Simple Mail Transfer Protocol", RFC 821, August
        1982.

   [31] Ramsdell, B., Ed., "S/MIME Version 3 Message Specification", RFC
        2633, June 1999.

   [32] Resnick, P., Ed., "Internet Message Format", RFC 2822, April
        2001.

   [33] Vaudreuil, G., "SMTP Service Extensions for Transmission of
        Large and Binary MIME Messages", RFC 1830, August 1995.

   [34] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893,
        January 1996.

10. Editor's Address

   John C. Klensin
   AT&T Laboratories
   99 Bedford St
   Boston, MA 02111 USA

   Phone: 617-574-3076
   EMail: klensin@research.att.com

11. Acknowledgments

   Many people worked long and hard on the many iterations of this
   document.  There was wide-ranging debate in the IETF DRUMS Working
   Group, both on its mailing list and in face to face discussions,
   about many technical issues and the role of a revised standard for
   Internet mail transport, and many contributors helped form the
   wording in this specification.  The hundreds of participants in the
   many discussions since RFC 821 was produced are too numerous to
   mention, but they all helped this document become what it is.

APPENDICES

A. TCP Transport Service

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

B. Generating SMTP Commands from RFC 822 Headers

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

   It is recommended that the UA provide its initial ("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 fields SHOULD then
      be removed from the headers.  Once this process is completed, the
      remaining headers SHOULD be checked to verify that at least one
      To:, Cc:, or Bcc: header remains.  If none do, then a bcc: header
      with no additional information SHOULD be inserted as specified in
      [32].

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

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

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

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

C. Source Routes

   Historically, the <reverse-path> was a reverse source routing list of
   hosts and a source mailbox.  The first host in the <reverse-path>
   SHOULD be the host sending the MAIL command.  Similarly, the
   <forward-path> may be a source routing lists of hosts and a
   destination mailbox.  However, in general, the <forward-path> SHOULD
   contain only a mailbox and domain name, relying on the domain name
   system to supply routing information if required.  The use of source
   routes is deprecated; while servers MUST be prepared to receive and
   handle them as discussed in section 3.3 and F.2, clients SHOULD NOT
   transmit them and this section was included only to provide context.

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

   If source routes are used, RFC 821 and the text below should be
   consulted for the mechanisms for constructing and updating the
   forward- and reverse-paths.

   The SMTP server transforms the command arguments by moving its own
   identifier (its domain name or that of any domain for which it is
   acting as a mail exchanger), if it appears, from the forward-path to
   the beginning of the reverse-path.

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

   When the list of hosts is present, it is a "reverse" source route and
   indicates that the mail was relayed through each host on the list
   (the first host in the list was the most recent relay).  This list is
   used as a source route to return non-delivery notices to the sender.
   As each relay host adds itself to the beginning of the list, it MUST
   use its name as known in the transport environment to which it is
   relaying the mail rather than that of the transport environment from
   which the mail came (if they are different).

D. Scenarios

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

D.1 A Typical SMTP Transaction Scenario

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

      S: 220 foo.com Simple Mail Transfer Service Ready
      C: EHLO bar.com
      S: 250-foo.com greets bar.com
      S: 250-8BITMIME
      S: 250-SIZE
      S: 250-DSN
      S: 250 HELP
      C: MAIL FROM:<Smith@bar.com>
      S: 250 OK
      C: RCPT TO:<Jones@foo.com>
      S: 250 OK
      C: RCPT TO:<Green@foo.com>
      S: 550 No such user here
      C: RCPT TO:<Brown@foo.com>

      S: 250 OK
      C: DATA
      S: 354 Start mail input; end with <CRLF>.<CRLF>
      C: Blah blah blah...
      C: ...etc. etc. etc.
      C: .
      S: 250 OK
      C: QUIT
      S: 221 foo.com Service closing transmission channel

D.2 Aborted SMTP Transaction Scenario

      S: 220 foo.com Simple Mail Transfer Service Ready
      C: EHLO bar.com
      S: 250-foo.com greets bar.com
      S: 250-8BITMIME
      S: 250-SIZE
      S: 250-DSN
      S: 250 HELP
      C: MAIL FROM:<Smith@bar.com>
      S: 250 OK
      C: RCPT TO:<Jones@foo.com>
      S: 250 OK
      C: RCPT TO:<Green@foo.com>
      S: 550 No such user here
      C: RSET
      S: 250 OK
      C: QUIT
      S: 221 foo.com Service closing transmission channel

D.3 Relayed Mail Scenario

   Step 1  --  Source Host to Relay Host

      S: 220 foo.com Simple Mail Transfer Service Ready
      C: EHLO bar.com
      S: 250-foo.com greets bar.com
      S: 250-8BITMIME
      S: 250-SIZE
      S: 250-DSN
      S: 250 HELP
      C: MAIL FROM:<JQP@bar.com>
      S: 250 OK
      C: RCPT TO:<@foo.com:Jones@XYZ.COM>
      S: 250 OK
      C: DATA
      S: 354 Start mail input; end with <CRLF>.<CRLF>
      C: Date: Thu, 21 May 1998 05:33:29 -0700

      C: From: John Q. Public <JQP@bar.com>
      C: Subject:  The Next Meeting of the Board
      C: To: Jones@xyz.com
      C:
      C: Bill:
      C: The next meeting of the board of directors will be
      C: on Tuesday.
      C:                         John.
      C: .
      S: 250 OK
      C: QUIT
      S: 221 foo.com Service closing transmission channel

   Step 2  --  Relay Host to Destination Host

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

D.4 Verifying and Sending Scenario

      S: 220 foo.com Simple Mail Transfer Service Ready
      C: EHLO bar.com
      S: 250-foo.com greets bar.com
      S: 250-8BITMIME
      S: 250-SIZE
      S: 250-DSN

      S: 250-VRFY
      S: 250 HELP
      C: VRFY Crispin
      S: 250 Mark Crispin <Admin.MRC@foo.com>
      C: SEND FROM:<EAK@bar.com>
      S: 250 OK
      C: RCPT TO:<Admin.MRC@foo.com>
      S: 250 OK
      C: DATA
      S: 354 Start mail input; end with <CRLF>.<CRLF>
      C: Blah blah blah...
      C: ...etc. etc. etc.
      C: .
      S: 250 OK
      C: QUIT
      S: 221 foo.com Service closing transmission channel

E. Other Gateway Issues

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

F. Deprecated Features of RFC 821

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

F.1 TURN

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

F.2 Source Routing

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

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

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

F.3 HELO

   As discussed in sections 3.1 and 4.1.1, EHLO is strongly preferred to
   HELO when the server will accept the former.  Servers must continue
   to accept and process HELO in order to support older clients.

F.4 #-literals

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

F.5 Dates and Years

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

F.6 Sending versus Mailing

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

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

Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.