Mailbox Names for Common Services, Roles and Functions
RFC 2142

Document Type RFC - Proposed Standard (May 1997; Errata)
Was draft-crocker-stdaddr (individual)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html
Stream Legacy state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 2142 (Proposed Standard)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                        D. Crocker
Request for Comments: 2142                     Internet Mail Consortium
Category: Standards Track                                      May 1997

                             MAILBOX NAMES FOR

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.


   This specification enumerates and describes Internet mail addresses
   (mailbox name @ host reference) to be used when contacting personnel
   at an organization.  Mailbox names are provided for both operations
   and business functions.  Additional mailbox names and aliases are not
   prohibited, but organizations which support email exchanges with the
   Internet are encouraged to support AT LEAST each mailbox name for
   which the associated function exists within the organization.


   Various Internet documents have specified mailbox names to be used
   when reaching the operators of the new service; for example, [RFC822
   6.3, C.6] requires the presence of a <POSTMASTER@domain> mailbox name
   on all hosts that have an SMTP server.  Other protocols have defacto
   standards for well known mailbox names, such as <USENET@domain> for
   NNTP (see [RFC977]), and <WEBMASTER@domain> for HTTP (see [HTTP]).
   Defacto standards also exist for well known mailbox names which have
   nothing to do with a particular protocol, e.g., <ABUSE@domain> and

   The purpose of this memo is to aggregate and specify the basic set of
   mailbox names which organizations need to support.  Most
   organizations do not need to support the full set of mailbox names
   defined here, since not every organization will implement the all of
   the associated services.  However, if a given service is offerred,
   then the associated mailbox name(es) must be supported, resulting in
   delivery to a recipient appropriate for the referenced service or

Crocker                     Standards Track                     [Page 1]
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 [RFC974]) 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 <USENET@VIX.COM> and
   <USENET@DATA.RAMONA.VIX.COM>, 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 [RFC977]) the mail exchangers for that top level domain
   must accept mail to <USENET@domain> even if the mail exchanger hosts
   do not, themselves, serve the NNTP protocol.


   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 <ABUSE@COMPANY.COM> 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

   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
Show full document text