rfc2821.txt

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

      553- Ambiguous;  Possibilities are
      553-Joe Smith <[e-mail]>
      553-Harry Smith <[e-mail]>
      553 Melvin Smith <[e-mail]>

   or

      553-Ambiguous;  Possibilities
      553- <[e-mail]>
      553- <[e-mail]>
      553 <[e-mail]>

   Under normal circumstances, a client receiving a 553 reply would be
   expected to expose the result to the user.  Use of exactly the forms
   given, and the "user ambiguous" or "ambiguous" keywords, possibly
   supplemented by extended reply codes such as those described in [34],
   will facilitate automated translation into other languages as needed.
   Of course, a client that was highly automated or that was operating
   in another language than English, might choose to try to translate
   the response, to return some other indication to the user than the




Klensin                     Standards Track                    [Page 20]

RFC 2821             Simple Mail Transfer Protocol            April 2001


   literal text of the reply, or to take some automated action such as
   consulting a directory service for additional information before
   reporting to the user.

   For the EXPN command, the string identifies a mailing list, and the
   successful (i.e., 250) multiline response MAY include the full name
   of the users and MUST give the mailboxes on the mailing list.

   In some hosts the distinction between a mailing list and an alias for
   a single mailbox is a bit fuzzy, since a common data structure may
   hold both types of entries, and it is possible to have mailing lists
   containing only one mailbox.  If a request is made to apply VRFY to a
   mailing list, a positive response MAY be given if a message so
   addressed would be delivered to everyone on the list, otherwise an
   error SHOULD be reported (e.g., "550 That is a mailing list, not a
   user" or "252 Unable to verify members of mailing list").  If a
   request is made to expand a user name, the server MAY return a
   positive response consisting of a list containing one name, or an
   error MAY be reported (e.g., "550 That is a user name, not a mailing
   list").

   In the case of a successful multiline reply (normal for EXPN) exactly
   one mailbox is to be specified on each line of the reply.  The case
   of an ambiguous request is discussed above.

   "User name" is a fuzzy term and has been used deliberately.  An
   implementation of the VRFY or EXPN commands MUST include at least
   recognition of local mailboxes as "user names".  However, since
   current Internet practice often results in a single host handling
   mail for multiple domains, hosts, especially hosts that provide this
   functionality, SHOULD accept the "local-part@domain" form as a "user
   name"; hosts MAY also choose to recognize other strings as "user
   names".

   The case of expanding a mailbox list requires a multiline reply, such
   as:

      C: EXPN Example-People
      S: 250-Jon Postel <[e-mail]>
      S: 250-Fred Fonebone <[e-mail]>
      S: 250 Sam Q. Smith <[e-mail]>

   or

      C: EXPN Executive-Washroom-List
      S: 550 Access Denied to You.





Klensin                     Standards Track                    [Page 21]

RFC 2821             Simple Mail Transfer Protocol            April 2001


   The character string arguments of the VRFY and EXPN commands cannot
   be further restricted due to the variety of implementations of the
   user name and mailbox list concepts.  On some systems it may be
   appropriate for the argument of the EXPN command to be a file name
   for a file containing a mailing list, but again there are a variety
   of file naming conventions in the Internet.  Similarly, historical
   variations in what is returned by these commands are such that the
   response SHOULD be interpreted very carefully, if at all, and SHOULD
   generally only be used for diagnostic purposes.

3.5.2 VRFY Normal Response

   When normal (2yz or 551) responses are returned from a VRFY or EXPN
   request, the reply normally includes the mailbox name, i.e.,
   "<local-part@domain>", where "domain" is a fully qualified domain
   name, MUST appear in the syntax.  In circumstances exceptional enough
   to justify violating the intent of this specification, free-form text
   MAY be returned.  In order to facilitate parsing by both computers
   and people, addresses SHOULD appear in pointed brackets.  When
   addresses, rather than free-form debugging information, are returned,
   EXPN and VRFY MUST return only valid domain addresses that are usable
   in SMTP RCPT commands.  Consequently, if an address implies delivery
   to a program or other system, the mailbox name used to reach that
   target MUST be given.  Paths (explicit source routes) MUST NOT be
   returned by VRFY or EXPN.

   Server implementations SHOULD support both VRFY and EXPN.  For
   security reasons, implementations MAY provide local installations a
   way to disable either or both of these commands through configuration
   options or the equivalent.  When these commands are supported, they
   are not required to work across relays when relaying is supported.
   Since they were both optional in RFC 821, they MUST be listed as
   service extensions in an EHLO response, if they are supported.

3.5.3 Meaning of VRFY or EXPN Success Response

   A server MUST NOT return a 250 code in response to a VRFY or EXPN
   command unless it has actually verified the address.  In particular,
   a server MUST NOT return 250 if all it has done is to verify that the
   syntax given is valid.  In that case, 502 (Command not implemented)
   or 500 (Syntax error, command unrecognized) SHOULD be returned.  As
   stated elsewhere, implementation (in the sense of actually validating
   addresses and returning information) of VRFY and EXPN are strongly
   recommended.  Hence, implementations that return 500 or 502 for VRFY
   are not in full compliance with this specification.






Klensin                     Standards Track                    [Page 22]

RFC 2821             Simple Mail Transfer Protocol            April 2001


   There may be circumstances where an address appears to be valid but
   cannot reasonably be verified in real time, particularly when a
   server is acting as a mail exchanger for another server or domain.
   "Apparent validity" in this case would normally involve at least
   syntax checking and might involve verification that any domains
   specified were ones to which the host expected to be able to relay
   mail.  In these situations, reply code 252 SHOULD be returned.  These
   cases parallel the discussion of RCPT verification discussed in
   section 2.1.  Similarly, the discussion in section 3.4 applies to the
   use of reply codes 251 and 551 with VRFY (and EXPN) to indicate
   addresses that are recognized but that would be forwarded or bounced
   were mail received for them.  Implementations generally SHOULD be
   more aggressive about address verification in the case of VRFY than
   in the case of RCPT, even if it takes a little longer to do so.

3.5.4 Semantics and Applications of EXPN

   EXPN is often very useful in debugging and understanding problems
   with mailing lists and multiple-target-address aliases.  Some systems
   have attempted to use source expansion of mailing lists as a means of
   eliminating duplicates.  The propagation of aliasing systems with
   mail on the Internet, for hosts (typically with MX and CNAME DNS
   records), for mailboxes (various types of local host aliases), and in
   various proxying arrangements, has made it nearly impossible for
   these strategies to work consistently, and mail systems SHOULD NOT
   attempt them.

3.6 Domains

   Only resolvable, fully-qualified, domain names (FQDNs) are permitted
   when domain names are used in SMTP.  In other words, names that can
   be resolved to MX RRs or A RRs (as discussed in section 5) are
   permitted, as are CNAME RRs whose targets can be resolved, in turn,
   to MX or A RRs.  Local nicknames or unqualified names MUST NOT be
   used.  There are two exceptions to the rule requiring FQDNs:

   -  The domain name given in the EHLO command MUST BE either a primary
      host name (a domain name that resolves to an A RR) or, if the host
      has no name, an address literal as described in section 4.1.1.1.

   -  The reserved mailbox name "postmaster" may be used in a RCPT
      command without domain qualification (see section 4.1.1.3) and
      MUST be accepted if so used.








Klensin                     Standards Track                    [Page 23]

RFC 2821             Simple Mail Transfer Protocol            April 2001


3.7 Relaying

   In general, the availability of Mail eXchanger records in the domain
   name system [22, 27] makes the use of explicit source routes in the
   Internet mail system unnecessary.  Many historical problems with
   their interpretation have made their use undesirable.  SMTP clients
   SHOULD NOT generate explicit source routes except under unusual
   circumstances.  SMTP servers MAY decline to act as mail relays or to
   accept addresses that specify source routes.  When route information
   is encountered, SMTP servers are also permitted to ignore the route
   information and simply send to the final destination specified as the
   last element in the route and SHOULD do so.  There has been an
   invalid practice of using names that do not appear in the DNS as
   destination names, with the senders counting on the intermediate
   hosts specified in source routing to resolve any problems.  If source
   routes are stripped, this practice will cause failures.  This is one
   of several reasons why SMTP clients MUST NOT generate invalid source
   routes or depend on serial resolution of names.

   When source routes are not used, the process described in RFC 821 for
   constructing a reverse-path from the forward-path is not applicable
   and the reverse-path at the time of delivery will simply be the
   address that appeared in the MAIL command.

   A relay SMTP server is usually the target of a DNS MX record that
   designates it, rather than the final delivery system.  The relay
   server may accept or reject the task of relaying the mail in the same
   way it accepts or rejects mail for a local user.  If it accepts the
   task, it then becomes an SMTP client, establishes a transmission
   channel to the next SMTP server specified in the DNS (according to
   the rules in section 5), and sends it the mail.  If it declines to
   relay mail to a particular address for policy reasons, a 550 response
   SHOULD be returned.

   Many mail-sending clients exist, especially in conjunction with
   facilities that receive mail via POP3 or IMAP, that have limited
   capability to support some of the requirements of this specification,
   such as the ability to queue messages for subsequent delivery
   attempts.  For these clients, it is common practice to make private
   arrangements to send all messages to a single server for processing
   and subsequent distribution.  SMTP, as specified here, is not ideally
   suited for this role, and work is underway on standardized mail
   submission protocols that might eventually supercede the current
   practices.  In any event, because these arrangements are private and
   fall outside the scope of this specification, they are not described
   here.





Klensin                     Standards Track                    [Page 24]

RFC 2821             Simple Mail Transfer Protocol            April 2001


   It is important to note that MX records can point to SMTP servers
   which act as gateways into other environments, not just SMTP relays
   and final delivery systems; see sections 3.8 and 5.

   If an SMTP server has accepted the task of relaying the mail and
   later finds that the destination is incorrect or that the mail cannot
   be delivered for some other reason, then it MUST construct an
   "undeliverable mail" notification message and send it to the
   originator of the undeliverable mail (as indicated by the reverse-
   path).  Formats specified for non-delivery reports by other standards
   (see, for example, [24, 25]) SHOULD be used if possible.

   This notification message must be from the SMTP server at the relay
   host or the host that first determines that delivery cannot be
   accomplished.  Of course, SMTP servers MUST NOT send notification
   messages about problems