MAILBOX NAMES FOR COMMON SERVICES, ROLES AND FUNCTIONS

Status of this Memo

ABSTRACT

CONTENTS

1.  RATIONALE AND SCOPE

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 role.

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.
 

2.  INVARIANTS

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).
 

3.  BUSINESS-RELATED MAILBOX NAMES

These names are related to an organization's line-of-business activities.  The INFO name is often tied to an autoresponder, with a range of standard files available.

MAILBOX        AREA                USAGE
-----------    ----------------    ---------------------------
INFO           Marketing           Packaged information about the
                                   organization, products, and/or
                                   services, as appropriate
MARKETING      Marketing           Product marketing and
                                   marketing communications
SALES          Sales               Product purchase information
SUPPORT        Customer Service    Problems with product or
                                   service
 
 

4.  NETWORK OPERATIONS MAILBOX NAMES

MAILBOX        AREA                USAGE
-----------    ----------------    ---------------------------
ABUSE          Customer Relations  Inappropriate public behaviour
NOC            Network Operations  Network infrastructure
SECURITY       Network Security    Security bulletins or queries
 
 

5.  SUPPORT MAILBOX NAMES FOR SPECIFIC INTERNET SERVICES

MAILBOX        SERVICE             SPECIFICATIONS
-----------    ----------------    ---------------------------
POSTMASTER     SMTP                [RFC821], [RFC822]
HOSTMASTER     DNS                 [RFC1033-RFC1035]
USENET         NNTP                [RFC977]
NEWS           NNTP                Synonym for USENET
WEBMASTER      HTTP                [RFC2068]
WWW            HTTP                Synonym for WEBMASTER
UUCP           UUCP                [RFC976]
FTP            FTP                 [RFC959]
 

6.  MAILING LIST ADMINISTRATION MAILBOX

For a mailing list whose submission mailbox name is:

   <LIST@DOMAIN>

there MUST be the administrative mailbox name:

   <LIST-REQUEST@DOMAIN>

Distribution List management software, such as MajorDomo and Listserv, also have a single mailbox name associated with the software on that system -- usually the name of the software -- rather than a particular list on that system.  Use of such mailbox names requires participants to know the type of list software employed at the site.  This is problematic.  Consequently:

   LIST-SPECIFIC (-REQUEST) MAILBOX NAMES ARE REQUIRED,
   INDEPENDENT OF THE AVAILABILITY OF GENERIC LIST SOFTWARE
   MAILBOX NAMES.
 

7.  DOMAIN NAME SERVICE ADMINISTRATION MAILBOX

This field must be a simple word without metacharacters (such as "%" or "!" or "::"), and a mail alias should be used on the relevant mail exchanger hosts to direct zone administration mail to the appropriate mailbox.

For simplicity and regularity, it is strongly recommended that the well known mailbox name HOSTMASTER always be used <HOSTMASTER@domain>.
 
 

8.  AUTONOMOUS SYSTEM MAILBOX

Not all Autonomous Systems are registered with all registries, however, and so undeliverable mailbox names under this scheme should be treated as an inconvenience rather than as an error or a standards violation.
 

9.  SECURITY CONSIDERATIONS

10. REFERENCES

11. ACKNOWLEDGEMENTS

12. AUTHOR'S ADDRESS

Phone: +1 408 246 8253
EMail: dcrocker@imc.org