rfc2476.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 844 行 · 第 1/3 页


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.

   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