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.

Copyright Notice

Copyright (C) The Internet Society (1997). All Rights Reserved.

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.

Table of Contents

1.  RATIONALE AND SCOPE
2.  INVARIANTS
3.  BUSINESS-RELATED MAILBOX NAMES
4.  NETWORK OPERATIONS MAILBOX NAMES
5.  SUPPORT MAILBOX NAMES FOR SPECIFIC INTERNET SERVICES
6.  MAILING LIST ADMINISTRATION MAILBOX
7.  DOMAIN NAME SERVICE ADMINISTRATION MAILBOX
8.  AUTONOMOUS SYSTEM MAILBOX
9.  SECURITY CONSIDERATIONS
10.  REFERENCES (BOILERPLATE)
11.  ACKNOWLEDGEMENTS
12.  AUTHOR'S ADDRESS (BOILERPLATE)
§  References
§  Author's Address
§  Intellectual Property and Copyright Statements

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 [6]), and <WEBMASTER@domain> for HTTP (see [13]). 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 [4]) 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 [6]) 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                [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 [7], [8] and [9]), 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 [10], [11] and [12]).

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 (BOILERPLATE)

This RFC contained boilerplate in this section which has been moved to the RFC2223-compliant unnumbered section "References."

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 (BOILERPLATE)

This RFC contained boilerplate in this section which has been moved to the RFC2223-compliant unnumbered section "Author's Address."

References

Author's Address

Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.

Full Copyright Statement

Copyright (C) The Internet Society (1997). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgment

Funding for the RFC Editor function is currently provided by the Internet Society.