rfc2476.txt

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

Network Working Group                                        R. Gellens
Request for Comments: 2476                                     QUALCOMM
Category: Standards Track                                    J. Klensin
                                                                    MCI
                                                          December 1998


                           Message Submission

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

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

Table of Contents

    1.  Abstract . . . . . . . . . . . . . . . . . . . . . . . . . .  2
    2.  Document Information  . . . . . . . . . . . . . . . . . . .   3
      2.1.  Definitions of Terms Used in this Memo . . . . . . . . .  3
      2.2.  Conventions Used in this Document . . . . . . . . . . .   4
    3.  Message Submission . . . . . . . . . . . . . . . . . . . . .  4
      3.1.  Submission Identification . . . . . . . . . . . . . . .   4
      3.2.  Message Rejection and Bouncing . . . . . . . . . . . . .  4
      3.3.  Authorized Submission . . . . . . . . . . . . . . . . .   5
      3.4.  Enhanced Status Codes  . . . . . . . . . . . . . . . . .  6
    4.  Mandatory Actions . . . . . . . . . . . . . . . . . . . . .   6
      4.1.  General Submission Rejection Code  . . . . . . . . . . .  6
      4.2.  Ensure All Domains are Fully-Qualified  . . . . . . . .   6
    5.  Recommended Actions  . . . . . . . . . . . . . . . . . . . .  7
      5.1.  Enforce Address Syntax  . . . . . . . . . . . . . . . .   7
      5.2.  Log Errors . . . . . . . . . . . . . . . . . . . . . . .  7
    6.  Optional Actions  . . . . . . . . . . . . . . . . . . . . .   7
      6.1.  Enforce Submission Rights  . . . . . . . . . . . . . . .  7
      6.2.  Require Authentication  . . . . . . . . . . . . . . . .   8
      6.3.  Enforce Permissions  . . . . . . . . . . . . . . . . . .  8
      6.4.  Check Message Data  . . . . . . . . . . . . . . . . . .   8
    7.  Interaction with SMTP Extensions . . . . . . . . . . . . . .  8
    8.  Message Modifications . . . . . . . . . . . . . . . . . . .   9
      8.1.  Add 'Sender' . . . . . . . . . . . . . . . . . . . . . .  9
      8.2.  Add 'Date'  . . . . . . . . . . . . . . . . . . . . . .  10
      8.3.  Add 'Message-ID' . . . . . . . . . . . . . . . . . . . . 10



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


      8.4.  Transfer Encode . . . . . . . . . . . . . . . . . . . .  10
      8.5.  Sign the Message . . . . . . . . . . . . . . . . . . . . 10
      8.6.  Encrypt the Message . . . . . . . . . . . . . . . . . .  10
      8.7.  Resolve Aliases  . . . . . . . . . . . . . . . . . . . . 10
      8.8.  Header Rewriting  . . . . . . . . . . . . . . . . . . .  10
    9.  Security Considerations  . . . . . . . . . . . . . . . . . . 11
   10.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . .  11
   11.  References . . . . . . . . . . . . . . . . . . . . . . . . . 12
   12.  Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14
   13.  Full Copyright Statement  . . . . . . . . . . . . . . . . .  15

1.  Abstract

   SMTP was defined as a message *transfer* protocol, that is, a means
   to route (if needed) and deliver finished (complete) messages.
   Message Transfer Agents (MTAs) are not supposed to alter the message
   text, except to add 'Received', 'Return-Path', and other header
   fields as required by [SMTP-MTA].

   However, SMTP is now also widely used as a message *submission*
   protocol, that is, a means for message user agents (MUAs) to
   introduce new messages into the MTA routing network.  The process
   which accepts message submissions from MUAs is termed a Message
   Submission Agent (MSA).

   Messages being submitted are in some cases finished (complete)
   messages, and in other cases are unfinished (incomplete) in some
   aspect or other.  Unfinished messages need to be completed to ensure
   they conform to [MESSAGE-FORMAT], and later requirements.  For
   example, the message may lack a proper 'Date' header field, and
   domains might not be fully qualified.  In some cases, the MUA may be
   unable to generate finished messages (for example, it might not know
   its time zone).  Even when submitted messages are complete, local
   site policy may dictate that the message text be examined or modified
   in some way.  Such completions or modifications have been shown to
   cause harm when performed by downstream MTAs -- that is, MTAs after
   the first-hop submission MTA -- and are in general considered to be
   outside the province of standardized MTA functionality.

   Separating messages into submissions and transfers allows developers
   and network administrators to more easily:

   *   Implement security policies and guard against unauthorized mail
       relaying or injection of unsolicited bulk mail

   *   Implement authenticated submission, including off-site submission
       by authorized users such as travelers




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


   *   Separate the relevant software code differences, thereby making
       each code base more straightforward and allowing for different
       programs for relay and submission

   *   Detect configuration problems with a site's mail clients

   *   Provide a basis for adding enhanced submission services in the
       future

   This memo describes a low cost, deterministic means for messages to
   be identified as submissions, and specifies what actions are to be
   taken by a submission server.

   Public comments should be sent to the IETF Submit mailing list,
   <[e-mail]>.  To subscribe, send a message containing
   SUBSCRIBE to <[e-mail]>.  Private comments may be
   sent to the authors.

2.  Document Information

2.1.  Definitions of Terms Used in this Memo

   Fully-Qualified

   Containing or consisting of a domain which can be globally resolved
   using the global Domain Name Service; that is, not a local alias or
   partial specification.

   Message Submission Agent (MSA)

   A process which conforms to this specification, which acts as a
   submission server to accept messages from MUAs, and either delivers
   them or acts as an SMTP client to relay them to an MTA.

   Message Transfer Agent (MTA)

   A process which conforms to [SMTP-MTA], which acts as an SMTP server
   to accept messages from an MSA or another MTA, and either delivers
   them or acts as an SMTP client to relay them to another MTA.

   Message User Agent (MUA)

   A process which acts (usually on behalf of a user) to compose and
   submit new messages, and process delivered messages.  In the split-
   MUA model, POP or IMAP is used to access delivered messages.






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


2.2.  Conventions Used in this Document

   In examples, "C:" is used to indicate lines sent by the client, and
   "S:" indicates those sent by the server.  Line breaks within a
   command example are for editorial purposes only.

   Examples use the 'example.net' domain.

   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
   in this document are to be interpreted as defined in [KEYWORDS].

3.  Message Submission

3.1.  Submission Identification

   Port 587 is reserved for email message submission as specified in
   this document.  Messages received on this port are defined to be
   submissions.  The protocol used is ESMTP [SMTP-MTA, ESMTP], with
   additional restrictions as specified here.

   While most email clients and servers can be configured to use port
   587 instead of 25, there are cases where this is not possible or
   convenient.  A site MAY choose to use port 25 for message submission,
   by designating some hosts to be MSAs and others to be MTAs.

3.2.  Message Rejection and Bouncing

   MTAs and MSAs MAY implement message rejection rules that rely in part
   on whether the message is a submission or a relay.

   For example, some sites might configure their MTA to reject all RCPT
   TOs for messages that do not reference local users, and configure
   their MSA to reject all message submissions that do not come from
   authorized users, based on IP address, or authenticated identity.

   NOTE:  It is better to reject a message than to risk sending one that
   is damaged.  This is especially true for problems that are
   correctable by the MUA, for example, an invalid 'From' field.

   If an MSA is not able to determine a return path to the submitting
   user, from a valid MAIL FROM, a valid source IP address, or based on
   authenticated identity, then the MSA SHOULD immediately reject the
   message.  A message can be immediately rejected by returning a 550
   code to the MAIL FROM command.







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


   Note that a null return path, that is, MAIL FROM:<>, is permitted
   and MUST be accepted. (MUAs need to generate null return-path
   messages for a variety of reasons, including disposition
   notifications.)

   Except in the case where the MSA is unable to determine a valid
   return path for the message being submitted, text in this
   specification which instructs an MSA to issue a rejection code MAY be
   complied with by accepting the message and subsequently generating a
   bounce message. (That is, if the MSA is going to reject a message for
   any reason except being unable to determine a return path, it can
   optionally do an immediate rejection or accept the message and then
   mail a bounce.)

   NOTE:  In the normal case of message submission, immediately
   rejecting the message is preferred, as it gives the user and MUA
   direct feedback.  To properly handle delayed bounces the client MUA
   must maintain a queue of messages it has submitted, and match bounces
   to them.

3.3.  Authorized Submission

   Numerous methods have been used to ensure that only authorized users
   are able to submit messages.  These methods include authenticated
   SMTP, IP address restrictions, secure IP, and prior POP
   authentication.

   Authenticated SMTP [SMTP-AUTH] has been proposed.  It allows the MSA
   to determine an authorization identity for the message submission,
   which is not tied to other protocols.

   IP address restrictions are very widely implemented, but do not allow
   for travellers and similar situations, and can be spoofed.

   Secure IP [IPSEC] can also be used, and provides additional benefits
   of protection against eavesdropping and traffic analysis.

   Requiring a POP [POP3] authentication (from the same IP address)
   within some amount of time (for example, 20 minutes) prior to the
   start of a message submission session has also been used, but this
   does impose restrictions on clients as well as servers which may
   cause difficulties.  Specifically, the client must do a POP
   authentication before an SMTP submission session, and not all clients
   are capable and configured for this.  Also, the MSA must coordinate
   with the POP server, which may be difficult.  There is also a window
   during which an unauthorized user can submit messages and appear to
   be a prior authorized user.




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


3.4.  Enhanced Status Codes

   This memo suggests several enhanced status codes [SMTP-CODES] for
   submission-specific rejections.  The specific codes used are:

    5.6.0  Bad content.  The content of the header or text is
           improper.

    5.6.2  Bad domain or address.  Invalid or improper domain or address
           in MAIL FROM, RCPT TO, or DATA.

    5.7.1  Not allowed.  The address in MAIL FROM appears to have
           insufficient submission rights, or is invalid, or is not
           authorized with the authentication used; the address in a
           RCPT TO command is inconsistent with the permissions given to
           the user; the message data is rejected based on the
           submitting user.

    5.7.0  Site policy.  The message appears to violate site policy in
           some way.

4.  Mandatory Actions

   An MSA MUST do all of the following:

4.1.  General Submission Rejection Code

   Unless covered by a more precise response code, response code 554 is
   to be used to reject a MAIL FROM, RCPT TO, or DATA command that
   contains something improper.  Enhanced status code 5.6.0 is to be
   used if no other code is more specific.

4.2.  Ensure All Domains are Fully-Qualified

   The MSA MUST ensure that all domains in the envelope are fully-
   qualified.

   If the MSA examines or alters the message text in way, except to add
   trace header fields [SMTP-MTA], it MUST ensure that all domains in
   address header fields are fully-qualified.

   Reply code 554 is to be used to reject a MAIL FROM, RCPT TO, or DATA
   command which contains improper domain references.

   NOTE:  A frequent local convention is to accept single-level domains
   (for example, 'sales') and then to expand the reference by adding the
   remaining portion of the domain name (for example, to




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


   'sales.example.net').  Local conventions that permit single-level
   domains SHOULD reject, rather than expand, incomplete multi-level
   domains, since such expansion is particularly risky.

5.  Recommended Actions

   The MSA SHOULD do all of the following:

5.1.  Enforce Address Syntax

   An MSA SHOULD reject messages with illegal syntax in a sender or
   recipient envelope address.

   If the MSA examines or alters the message text in way, except to add
   trace header fields, it SHOULD reject messages with illegal address
   syntax in address header fields.

   Reply code 501 is to be used to reject a MAIL FROM or RCPT TO command
   that contains a detectably improper address.

   When addresses are resolved after submission of the message body,
   reply code 554 with enhanced status code 5.6.2 is to be used after
   end-of-data, if the message contains invalid addresses in the header.

5.2.  Log Errors

   The MSA SHOULD log message errors, especially apparent
   misconfigurations of client software.

   Note:  It can be very helpful to notify the administrator when
   problems are detected with local mail clients.  This is another
   advantage of distinguishing submission from relay: system
   administrators might be interested in local configuration problems,
   but not in client problems at other sites.

6.  Optional Actions

   The MSA MAY do any of the following:

6.1.  Enforce Submission Rights

   The MSA MAY issue an error response to the MAIL FROM command if the
   address in MAIL FROM appears to have insufficient submission rights,
   or is not authorized with the authentication used (if the session has
   been authenticated).

   Reply code 550 with enhanced status code 5.7.1 is used for this
   purpose.



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


6.2.  Require Authentication

   The MSA MAY issue an error response to the MAIL FROM command if the
   session has not been authenticated.

   Section 3.3 discusses authentication mechanisms.

   Reply code 530 [SMTP-AUTH] is used for this purpose.

6.3.  Enforce Permissions

   The MSA MAY issue an error response to the RCPT TO command if
   inconsistent with the permissions given to the user (if the session
   has been authenticated).

   Reply code 550 with enhanced status code 5.7.1 is used for this
   purpose.

6.4.  Check Message Data

   The MSA MAY issue an error response to the DATA command or send a
   failure result after end-of-data if the submitted message is
   syntactically invalid, or seems inconsistent with permissions given
   to the user (if known), or violates site policy in some way.