rfc2476.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   Reply code 554 is used for syntactic problems in the data.  Reply
   code 501 is used if the command itself is not syntactically valid.
   Reply code 550 with enhanced status code 5.7.1 is used to reject
   based on the submitting user.  Reply code 550 with enhanced status
   code 5.7.0 is used if the message violates site policy.

7.  Interaction with SMTP Extensions

   The following table lists the current standards-track and
   Experimental SMTP extensions.  Listed are the RFC, name, an
   indication as to the use of the extension on the submit port, and a
   reference:

   RFC   Name             Submission  Reference
   ----  ---------------  ----------  ------------------
   2197  Pipelining         SHOULD    [PIPELINING]
   2034  Error Codes        SHOULD    [CODES-EXTENSION]
   1985  ETRN              MUST NOT   [ETRN]
   1893  Extended Codes     SHOULD    [SMTP-CODES]
   1891  DSN                SHOULD    [DSN]
   1870  Size                MAY      [SIZE]
   1846  521               MUST NOT   [521REPLY]
   1845  Checkpoint          MAY      [Checkpoint]



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


   1830  Binary              MAY      [CHUNKING]
   1652  8-bit MIME         SHOULD    [8BITMIME]
   ----  Authentication     ------    [SMTP-AUTH]

   Future SMTP extensions should explicitly specify if they are valid on
   the Submission port.

   Some SMTP extensions are especially useful for message submission:

   Extended Status Codes [SMTP-CODES], SHOULD be supported and used
   according to [CODES-EXTENSION].  This permits the MSA to notify the
   client of specific configuration or other problems in more detail
   than the response codes listed in this memo.  Because some rejections
   are related to a site's security policy, care should be used not to
   expose more detail than is needed to correct the problem.

   [PIPELINING] SHOULD be supported by the MSA.

   [SMTP-AUTH] allows the MSA to validate the authority and determine
   the identity of the submitting user.

   Any references to the DATA command in this memo also refer to any
   substitutes for DATA, such as the BDAT command used with [CHUNKING].

8.  Message Modifications

   Sites MAY modify submissions to ensure compliance with standards and
   site policy.  This section describes a number of such modifications
   that are often considered useful.

   NOTE:  As a matter of guidance for local decisions to implement
   message modification, a paramount rule is to limit such actions to
   remedies for specific problems that have clear solutions.  This is
   especially true with address elements.  For example, indiscriminately
   appending a domain to an address or element which lacks one typically
   results in more broken addresses.  An unqualified address must be
   verified to be a valid local part in the domain before the domain can
   be safely added.

8.1.  Add 'Sender'

   The MSA MAY add or replace the 'Sender' field, if the identity of the
   sender is known and this is not given in the 'From' field.

   The MSA MUST ensure that any address it places in a 'Sender' field is
   in fact a valid mail address.





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


8.2.  Add 'Date'

   The MSA MAY add a 'Date' field to the submitted message, if it lacks
   it, or correct the 'Date' field if it does not conform to [MESSAGE-
   FORMAT] syntax.

8.3.  Add 'Message-ID'

   The MSA MAY add or replace the 'Message-ID' field, if it lacks it, or
   it is not valid syntax (as defined by [MESSAGE-FORMAT]).

8.4.  Transfer Encode

   The MSA MAY apply transfer encoding to the message according to MIME
   conventions, if needed and not harmful to the MIME type.

8.5.  Sign the Message

   The MSA MAY (digitally) sign or otherwise add authentication
   information to the message.

8.6.  Encrypt the Message

   The MSA MAY encrypt the message for transport to reflect
   organizational policies.

   NOTE:  To be useful, the addition of a signature and/or encryption by
   the MSA generally implies that the connection between the MUA and MSA
   must itself be secured in some other way, e.g., by operating inside
   of a secure environment, by securing the submission connection at the
   transport layer, or by using an [SMTP-AUTH] mechanism that provides
   for session integrity.

8.7.  Resolve Aliases

   The MSA MAY resolve aliases (CNAME records) for domain names, in the
   envelope and optionally in address fields of the header, subject to
   local policy.

   NOTE:  Unconditionally resolving aliases could be harmful.  For
   example, if www.example.net and ftp.example.net are both aliases for
   mail.example.net, rewriting them could lose useful information.

8.8.  Header Rewriting

   The MSA MAY rewrite local parts and/or domains, in the envelope and
   optionally in address fields of the header, according to local
   policy.  For example, a site may prefer to rewrite 'JRU' as '



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


   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: [phone]
   Fax:   [phone]
   EMail: [e-mail]


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

   Phone: [phone]
   EMail: [e-mail]






























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]