Mailbox Names for Common Services, Roles and Functions
The standard set of email addresses for reaching an organisation's people and services.
Crocker, D., "Mailbox Names for Common Services, Roles and Functions", RFC 2142, DOI 10.17487/RFC2142, May 1997, <https://www.rfc-editor.org/info/rfc2142>.
@misc{rfc2142,
series = {Request for Comments},
number = 2142,
howpublished = {RFC 2142},
publisher = {RFC Editor},
doi = {10.17487/RFC2142},
url = {https://www.rfc-editor.org/info/rfc2142},
author = {D. Crocker},
title = {{Mailbox Names for Common Services, Roles and Functions}},
pagetotal = 6,
year = 1997,
month = may,
} RFC text
Contents
Network Working Group D. Crocker
Request for Comments: 2142 Internet Mail Consortium
Category: Standards Track May 1997
MAILBOX NAMES FOR
COMMON SERVICES, ROLES AND FUNCTIONS
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.
ABSTRACT
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.
1. RATIONALE AND SCOPE
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
<TROUBLE@domain>.
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
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
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
Operations addresses are intended to provide recourse for customers,
providers and others who are experiencing difficulties with the
organization's Internet service.
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
For major Internet protocol services, there is a mailbox defined for
receiving queries and reports. (Synonyms are included, here, due to
their extensive installed base.)
MAILBOX SERVICE SPECIFICATIONS
----------- ---------------- ---------------------------
POSTMASTER SMTP [RFC821], [RFC822]
HOSTMASTER DNS [RFC1033-RFC1035]
USENET NNTP [RFC977]
NEWS NNTP Synonym for USENET
WEBMASTER HTTP [RFC 2068]
WWW HTTP Synonym for WEBMASTER
UUCP UUCP [RFC976]
FTP FTP [RFC959]
6. MAILING LIST ADMINISTRATION MAILBOX
Mailing lists have an administrative mailbox name to which add/drop
requests and other meta-queries can be sent.
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
In DNS (see [RFC1033], [RFC1034] and [RFC1035]), the Start Of
Authority record (SOA RR) has a field for specifying the mailbox name
of the zone's administrator.
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
Several Internet registries implement mailing lists for Autonomous
System contacts. So, for example, mail sent to <AS3557@RA.NET> will
at the time of this writing reach the technical contact for
Autonomous System 3557 in the BGP4 (see [RFC1654], [RFC1655] and
[RFC1656]).
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
Denial of service attacks (flooding a mailbox with junk) will be
easier after this document becomes a standard, since more systems
will support the same set of mailbox names.
10. REFERENCES
[RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
821, Information Sciences Institute, August 1982.
[RFC822] Crocker, D., "Standard for the format of ARPA Internet text
messages", STD 11, RFC 822, University of Delaware, August 1982.
[RFC959] Postel, J., and J. Reynolds, "File Transfer Protocol (FTP)",
STD 9, RFC 959, Information Sciences Institute, October 1985.
[RFC974] Partridge, C., "Mail routing and the domain system", STD 14,
RFC 974, CSNET CIC BBN Laboratories Inc, January 1986.
[RFC976] Horton, M., "UUCP mail interchange format standard", RFC
976, Bell Laboratories, February 1986.
[RFC977] Kantor, B., et al, "Network News Transfer Protocol: A
Proposed Standard for the Stream-Based Transmission of News", RFC
977, University of California, February 1986.
[RFC1033] Lottor, M., "Domain administrators operations guide", RFC
1033, SRI International, November 1987.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1035, USC/Information Sciences Institute, November 1987.
[RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specification" STD 13, RFC 1035, USC/Information Sciences Institute,
November 1987.
[RFC1654] Rekhter, Y., et al, "A Border Gateway Protocol 4 (BGP- 4)",
RFC 1654, T.J. Watson Research Center, IBM Corp., July 1994.
[RFC1655] Rekhter, Y., et al, "Application of the Border Gateway
Protocol in the Internet", RFC 1655, T.J. Watson Research Center, IBM
Corp., July 1994.
[RFC1656] Traina, P., "BGP-4 Protocol Document Roadmap and
Implementation Experience", RFC 1656, cisco Systems, July 1994.
[HTTP] Berners-Lee, T., et al, "Hypertext Transfer Protocol --
HTTP/1.0", RFC 1945, May 1996.
11. ACKNOWLEDGEMENTS
This specification derived from an earlier draft written by Paul
Vixie. Thanks to Stan Barber, Michael Dillon, James Aldridge, J. D.
Falk, Peter Kaminski, Brett Watson, Russ Wright, Neal McBurnett, and
Ed Morin for their comments on that draft.
12. AUTHOR'S ADDRESS
Dave Crocker
Internet Mail Consortium
127 Segre Ave.
Santa Cruz, CA
Phone: +1 408 246 8253
EMail: dcrocker@imc.org
ISO Plain Language
On this page
§1Rationale and Scope
Several internet documents had already fixed mailbox names for the operators of a new service. RFC 822 requires a POSTMASTER@domain mailbox on every host that has an SMTP server. Other protocols had de facto standards, such as USENET@domain for NNTP and WEBMASTER@domain for HTTP. Names that belong to no particular protocol also had a custom standard, such as ABUSE@domain and TROUBLE@domain.
The purpose of the document is to gather and specify the basic set of mailbox names that organisations need to support. Most organisations do not need the whole set, because not every organisation offers every service. But if a service is offered, the mailbox name associated with it must be supported, so that delivery reaches a recipient appropriate for that service or role.
A host that does not accept mail directly but does implement a service covered by this document must have an MX RR set, and the mail exchangers named by that set must treat the referenced host's domain name as local for the purpose of accepting mail for the defined mailbox name. This holds even when the advertised domain name differs from the host's own domain name: an NNTP server whose host name is DATA.RAMONA.VIX.COM but which advertises VIX.COM in its Path headers must have mail deliverable both to USENET@VIX.COM and to USENET@DATA.RAMONA.VIX.COM, even if the two reach different final destinations.
The scope of a well known mailbox name is its domain name. Servers that accept mail on behalf of a domain must accept and correctly process mailbox names for that domain, even when the server itself does not support the associated service. An NNTP server that advertises the organisation's top level domain in its Path headers therefore obliges the mail exchangers for that top level domain to accept mail to USENET@domain, even when those exchangers do not themselves serve NNTP.
The document exists because a fixed set of addresses had already spread informally across the internet, one per service and one per job. Putting them in one specification means a stranger can try postmaster@example.com and reach a person who can act.
It also draws a line around responsibility. The mail server that handles mail for a domain is the one that has to accept the address, even if the service behind the address runs on a different machine.
§2Invariants
For well known names that are not tied to a specific protocol, only the organisation's top level domain name has to be valid. If an internet service provider's domain name is COMPANY.COM, then ABUSE@COMPANY.COM must be valid and supported, even though the customers whose activity generates the complaints use hosts with more specific names such as SHELL1.COMPANY.COM. It is valid and encouraged to support mailbox names for sub-domains as well, where appropriate.
Mailbox names must be recognised independently of character case. POSTMASTER, postmaster, Postmaster, PostMaster and even PoStMaStEr are the same name, and delivery goes to the same mailbox.
Implementations of these well known names have to take account of what the senders who use them expect. Sending back an automatic mail acknowledgement is usually helpful, though the document suggests caution about the possibility of duelling mail robots and the resulting mail loops.
Three rules hold everywhere. The name has to work at the top level of the domain, it must not matter how the letters are capitalised, and a reply to it should normally come automatically so the sender knows it arrived.
- Top level domain onlyFor names that belong to no protocol, only the organisation's top level domain has to be valid. Names for sub-domains may be added.
- Case does not matterPOSTMASTER, postmaster, Postmaster and PoStMaStEr are the same name and deliver to the same mailbox.
- Acknowledge automaticallyAn automatic acknowledgement is usually helpful, with care taken over duelling mail robots and mail loops.
§3The Mailbox Name Catalogue
The names for line-of-business activities are grouped first. INFO carries packaged information about the organisation, its products or its services, and is often tied to an autoresponder with a range of standard files available. MARKETING handles product marketing and marketing communications, SALES handles product purchase information, and SUPPORT handles problems with a product or service.
The network operations names provide recourse for customers, providers and others who are having difficulty with the organisation's internet service. ABUSE, in customer relations, deals with inappropriate public behaviour. NOC, in network operations, deals with the network infrastructure. SECURITY, in network security, deals with security bulletins or queries.
Each major internet protocol service has a mailbox for receiving queries and reports. POSTMASTER belongs to SMTP, HOSTMASTER to DNS, USENET to NNTP, WEBMASTER to HTTP, UUCP to UUCP and FTP to FTP. Two synonyms are kept because of their extensive installed base: NEWS is a synonym for USENET, and WWW is a synonym for WEBMASTER.
The catalogue has three groups. Names for business roles, names for network operations, and one name per internet service. The service names are the ones outsiders are most likely to try, and two older spellings are kept as synonyms because so many sites already use them.
| Mailbox | Service | Notes |
|---|---|---|
| POSTMASTER | SMTP | Required by RFC 821 and RFC 822 |
| HOSTMASTER | DNS | The recommended zone administrator address |
| USENET | NNTP | News group administration |
| NEWS | NNTP | Synonym for USENET |
| WEBMASTER | HTTP | Web site administration |
| WWW | HTTP | Synonym for WEBMASTER |
| UUCP | UUCP | UUCP mail transfer |
| FTP | FTP | File transfer service |
§6Mailing List Administration
Mailing lists have an administrative mailbox name where add and drop requests and other meta-queries can be sent. For a mailing list whose submission mailbox name is LIST@DOMAIN, there must be an administrative mailbox name LIST-REQUEST@DOMAIN.
Distribution list management software such as MajorDomo and Listserv also has a single mailbox name associated with the software on that system, usually the name of the software rather than the name of a particular list. Using such a mailbox name requires participants to know what list software the site runs, which the document calls problematic. It therefore states that list-specific -REQUEST mailbox names are required, independent of the availability of the generic list software mailbox names.
A mailing list has to have a second address for administration, next to the one people post to. If the list is LIST@DOMAIN, the administration address is LIST-REQUEST@DOMAIN. That address has to exist even when the site runs software that also offers a single mailbox for all of its lists.
Submission address: <LIST@DOMAIN>
Required admin address: <LIST-REQUEST@DOMAIN>§7The DNS Administrator Mailbox
In DNS, the Start of Authority record has a field for the mailbox name of the zone's administrator. That field must be a simple word without metacharacters such as %, ! 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, the document strongly recommends that the well known mailbox name HOSTMASTER always be used, that is HOSTMASTER@domain.
Every DNS zone records an administrator. The address stored there has to be plain, with no unusual characters, and the recommendation is to make it the standard hostmaster address so that everyone knows where to write.
§8Autonomous System Mailboxes
Several internet registries run mailing lists for Autonomous System contacts. Mail sent to AS3557@RA.NET would, at the time of writing, reach the technical contact for Autonomous System 3557 in BGP4.
Not all Autonomous Systems are registered with all registries, so an undeliverable mailbox name under this scheme should be treated as an inconvenience rather than as an error or a standards violation.
Routing registries keep a contact address for each autonomous system, a network or group of networks with its own routing. Writing to that address reaches the right technical contact, though many such addresses simply do not exist, and the document says that is not a fault.
§9Security Considerations
Denial of service attacks, which flood a mailbox with junk, will be easier once this document becomes a standard, since more systems will support the same set of mailbox names.
Standardising the addresses makes them better known, and that is also the point at which they become easier to flood. The document notes the risk and leaves it there.