Message Submission
RFC 2476

   J.Random.User' in order to hide logon names, and/or to rewrite '
   squeeky.sales.example.net' as 'zyx.example.net' to hide machine names
   and make it easier to move users.

   However, only addresses, local-parts, or domains which match specific
   local MSA configuration settings should be altered.  It would be very
   dangerous for the MSA to apply data-independent rewriting rules, such
   as always deleting the first element of a domain name.  So, for
   example, a rule which strips the left-most element of the domain if
   the complete domain matches '*.foo.example.net' would be acceptable.

9.  Security Considerations

   Separation of submission and relay of messages can allow a site to
   implement different policies for the two types of services, including
   requiring use of additional security mechanisms for one or both.  It
   can do this in a way which is simpler, both technically and
   administratively.  This increases the likelihood that policies will
   be applied correctly.

   Separation also can aid in tracking and preventing unsolicited bulk
   email.

   For example, a site could configure its MSA to require authentication
   before accepting a message, and could configure its MTA to reject all
   RCPT TOs for non-local users.  This can be an important element in a
   site's total email security policy.

   If a site fails to require any form of authorization for message
   submissions (see section 3.3 for discussion), it is allowing open use
   of its resources and name; unsolicited bulk email can be injected
   using its facilities.

10.  Acknowledgments

   This updated memo has been revised in part based on comments and
   discussions which took place on and off the IETF-Submit mailing list.
   The help of those who took the time to review the draft and make
   suggestions is appreciated, especially that of Dave Crocker, Ned
   Freed, Keith Moore, John Myers, and Chris Newman.

   Special thanks to Harald Alvestrand, who got this effort started.

Gellens & Klensin           Standards Track                    [Page 11]
RFC 2476                   Message Submission              December 1998

11.  References

   [521REPLY]        Durand, A. and F. Dupont, "SMTP 521 Reply Code",
                     RFC 1846, September 1995.

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

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

   [CHECKPOINT]      Crocker, D., Freed, N. and A. Cargille, "SMTP
                     Service Extension for Checkpoint/Restart", RFC
                     1845, September 1995.

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

   [CODES-EXTENSION] Freed, N., "SMTP Service Extension for Returning
                     Enhanced Error Codes", RFC 2034, October 1996.

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

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

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

   [HEADERS]         Palme, J., "Common Internet Message Headers", RFC
                     2076, February 1997.

   [IPSEC]           Atkinson, R., "Security Architecture for the
                     Internet Protocol", RFC 1825, August 1995.

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

Gellens & Klensin           Standards Track                    [Page 12]
RFC 2476                   Message Submission              December 1998

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

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

   [PIPELINING]      Freed, N., "SMTP Service Extension for Command
                     Pipelining", RFC 2197, September 1997.

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

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

   [SMTP-AUTH]       Myers, J., "SMTP Service Extension for
                     Authentication", Work in Progress.

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

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

                     Partridge, C., "Mail Routing and the Domain
                     System", STD 14, RFC 974, January 1986.

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

Gellens & Klensin           Standards Track                    [Page 13]
RFC 2476                   Message Submission              December 1998

12.  Authors' Addresses

   Randall Gellens
   QUALCOMM Incorporated
   6455 Lusk Blvd.
   San Diego, CA  92121-2779
   U.S.A.

   Phone: +1 619 651 5115
   Fax:   +1 619 651 5334
   EMail: Randy@Qualcomm.Com

   John C. Klensin
   MCI Telecommunications
   800 Boylston St, 7th floor
   Boston, MA 02199
   USA

   Phone: +1 617 960 1011
   EMail: klensin@mci.net

Gellens & Klensin           Standards Track                    [Page 14]
RFC 2476                   Message Submission              December 1998

13.  Full Copyright Statement

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

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

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

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

Gellens & Klensin           Standards Track                    [Page 15]