doc: Add RFC documents

1 files changed, 339 insertions, 0 deletions

diff --git a/doc/rfc/rfc2142.txt b/doc/rfc/rfc2142.txt
new file mode 100644
index 0000000..7404f7b
--- /dev/null
+++ b/doc/rfc/rfc2142.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+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.
+
+
+
+
+
+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 1997
+
+
+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]
+
+
+
+
+Crocker                     Standards Track                     [Page 3]
+
+RFC 2142                     Mailbox Names                      May 1997
+
+
+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>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crocker                     Standards Track                     [Page 4]
+
+RFC 2142                     Mailbox Names                      May 1997
+
+
+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.
+
+
+
+
+
+
+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.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crocker                     Standards Track                     [Page 6]
+