RFC 2142 (rfc2142) - Page 2 of 6


Mailbox Names for Common Services, Roles and Functions



Alternative Format: Original Text Document



RFC 2142                     Mailbox Names                      May 1997


   If a host is not configured to accept mail directly, but it
   implements a service for which this specification defines a mailbox
   name, that host must have an MX RR set (see [RFC 974]) and the mail
   exchangers specified by this RR set must recognize the referenced
   host's domain name as "local" for the purpose of accepting mail bound
   for the defined mailbox name.  Note that this is true even if the
   advertised domain name is not the same as the host's domain name; for
   example, if an NNTP server's host name is DATA.RAMONA.VIX.COM yet it
   advertises the domain name VIX.COM in its "Path:" headers, then mail
   must be deliverable to both [email protected]> and
   [email protected]>, even though these addresses might be
   delivered to different final destinations.

   The scope of a well known mailbox name is its domain name.  Servers
   accepting mail on behalf of a domain must accept and correctly
   process mailbox names for that domain, even if the server, itself,
   does not support the associated service.  So, for example, if an NNTP
   server advertises the organization's top level domain in "Path:"
   headers (see [RFC 977]) the mail exchangers for that top level domain
   must accept mail to  even if the mail exchanger hosts
   do not, themselves, serve the NNTP protocol.

2.  INVARIANTS

   For well known names that are not related to specific protocols, only
   the organization's top level domain name are required to be valid.
   For example, if an Internet service provider's domain name is
   COMPANY.COM, then the [email protected]> address must be valid and
   supported, even though the customers whose activity generates
   complaints use hosts with more specific domain names like
   SHELL1.COMPANY.COM.  Note, however, that it is valid and encouraged
   to support mailbox names for sub-domains, as appropriate.

   Mailbox names must be recognized independent of character case.  For
   example, POSTMASTER, postmaster, Postmaster, PostMaster, and even
   PoStMaStEr are to be treated the same, with delivery to the same
   mailbox.

   Implementations of these well known names need to take account of the
   expectations of the senders who will use them.  Sending back an
   automatic mail acknowledgement is usually helpful (though we suggest
   caution against the possibility of "duelling mail robots" and the
   resulting mail loops).








Crocker                     Standards Track