Movatterモバイル変換

Network Working Group                                        D. CrockerRequest for Comments: 2142                     Internet Mail ConsortiumCategory: Standards Track                                      May 1997MAILBOX NAMES FORCOMMON SERVICES, ROLES AND FUNCTIONSStatus 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.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.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).Crocker                     Standards Track                     [Page 2]

RFC 2142                     Mailbox Names                      May 19973.  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                                      service4.  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 queries5.  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]Crocker                     Standards Track                     [Page 3]

RFC 2142                     Mailbox Names                      May 19976.  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>.Crocker                     Standards Track                     [Page 4]

RFC 2142                     Mailbox Names                      May 19978.  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,RFC821, 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",RFC976, Bell Laboratories, February 1986.   [RFC977] Kantor, B., et al, "Network News Transfer Protocol: A   Proposed Standard for the Stream-Based Transmission of News",RFC977, University of California, February 1986.   [RFC1033] Lottor, M., "Domain administrators operations guide",RFC1033, SRI International, November 1987.   [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",   STD 13,RFC 1035, USC/Information Sciences Institute, November 1987.Crocker                     Standards Track                     [Page 5]

RFC 2142                     Mailbox Names                      May 1997   [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.orgCrocker                     Standards Track                     [Page 6]