home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / rfc / 3 / rfc2142.txt < prev    next >
Encoding:
Text File  |  2003-06-11  |  11.9 KB  |  340 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                        D. Crocker
  8. Request for Comments: 2142                     Internet Mail Consortium
  9. Cateogry: Standards Track                                      May 1997
  10.  
  11.  
  12.                              MAILBOX NAMES FOR
  13.                    COMMON SERVICES, ROLES AND FUNCTIONS
  14.  
  15. Status of this Memo
  16.  
  17.    This document specifies an Internet standards track protocol for the
  18.    Internet community, and requests discussion and suggestions for
  19.    improvements.  Please refer to the current edition of the "Internet
  20.    Official Protocol Standards" (STD 1) for the standardization state
  21.    and status of this protocol.  Distribution of this memo is unlimited.
  22.  
  23. ABSTRACT
  24.  
  25.    This specification enumerates and describes Internet mail addresses
  26.    (mailbox name @ host reference) to be used when contacting personnel
  27.    at an organization.  Mailbox names are provided for both operations
  28.    and business functions.  Additional mailbox names and aliases are not
  29.    prohibited, but organizations which support email exchanges with the
  30.    Internet are encouraged to support AT LEAST each mailbox name for
  31.    which the associated function exists within the organization.
  32.  
  33. 1.  RATIONALE AND SCOPE
  34.  
  35.    Various Internet documents have specified mailbox names to be used
  36.    when reaching the operators of the new service; for example, [RFC822
  37.    6.3, C.6] requires the presence of a <POSTMASTER@domain> mailbox name
  38.    on all hosts that have an SMTP server.  Other protocols have defacto
  39.    standards for well known mailbox names, such as <USENET@domain> for
  40.    NNTP (see [RFC977]), and <WEBMASTER@domain> for HTTP (see [HTTP]).
  41.    Defacto standards also exist for well known mailbox names which have
  42.    nothing to do with a particular protocol, e.g., <ABUSE@domain> and
  43.    <TROUBLE@domain>.
  44.  
  45.    The purpose of this memo is to aggregate and specify the basic set of
  46.    mailbox names which organizations need to support.  Most
  47.    organizations do not need to support the full set of mailbox names
  48.    defined here, since not every organization will implement the all of
  49.    the associated services.  However, if a given service is offerred,
  50.    then the associated mailbox name(es) must be supported, resulting in
  51.    delivery to a recipient appropriate for the referenced service or
  52.    role.
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Crocker                     Standards Track                     [Page 1]
  59.  
  60. RFC 2142                     Mailbox Names                      May 1997
  61.  
  62.  
  63.    If a host is not configured to accept mail directly, but it
  64.    implements a service for which this specification defines a mailbox
  65.    name, that host must have an MX RR set (see [RFC974]) and the mail
  66.    exchangers specified by this RR set must recognize the referenced
  67.    host's domain name as "local" for the purpose of accepting mail bound
  68.    for the defined mailbox name.  Note that this is true even if the
  69.    advertised domain name is not the same as the host's domain name; for
  70.    example, if an NNTP server's host name is DATA.RAMONA.VIX.COM yet it
  71.    advertises the domain name VIX.COM in its "Path:" headers, then mail
  72.    must be deliverable to both <USENET@VIX.COM> and
  73.    <USENET@DATA.RAMONA.VIX.COM>, even though these addresses might be
  74.    delivered to different final destinations.
  75.  
  76.    The scope of a well known mailbox name is its domain name.  Servers
  77.    accepting mail on behalf of a domain must accept and correctly
  78.    process mailbox names for that domain, even if the server, itself,
  79.    does not support the associated service.  So, for example, if an NNTP
  80.    server advertises the organization's top level domain in "Path:"
  81.    headers (see [RFC977]) the mail exchangers for that top level domain
  82.    must accept mail to <USENET@domain> even if the mail exchanger hosts
  83.    do not, themselves, serve the NNTP protocol.
  84.  
  85. 2.  INVARIANTS
  86.  
  87.    For well known names that are not related to specific protocols, only
  88.    the organization's top level domain name are required to be valid.
  89.    For example, if an Internet service provider's domain name is
  90.    COMPANY.COM, then the <ABUSE@COMPANY.COM> address must be valid and
  91.    supported, even though the customers whose activity generates
  92.    complaints use hosts with more specific domain names like
  93.    SHELL1.COMPANY.COM.  Note, however, that it is valid and encouraged
  94.    to support mailbox names for sub-domains, as appropriate.
  95.  
  96.    Mailbox names must be recognized independent of character case.  For
  97.    example, POSTMASTER, postmaster, Postmaster, PostMaster, and even
  98.    PoStMaStEr are to be treated the same, with delivery to the same
  99.    mailbox.
  100.  
  101.    Implementations of these well known names need to take account of the
  102.    expectations of the senders who will use them.  Sending back an
  103.    automatic mail acknowledgement is usually helpful (though we suggest
  104.    caution against the possibility of "duelling mail robots" and the
  105.    resulting mail loops).
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Crocker                     Standards Track                     [Page 2]
  115.  
  116. RFC 2142                     Mailbox Names                      May 1997
  117.  
  118.  
  119. 3.  BUSINESS-RELATED MAILBOX NAMES
  120.  
  121.    These names are related to an organization's line-of-business
  122.    activities.  The INFO name is often tied to an autoresponder, with a
  123.    range of standard files available.
  124.  
  125.    MAILBOX        AREA                USAGE
  126.    -----------    ----------------    ---------------------------
  127.    INFO           Marketing           Packaged information about the
  128.                                       organization, products, and/or
  129.                                       services, as appropriate
  130.    MARKETING      Marketing           Product marketing and
  131.                                       marketing communications
  132.    SALES          Sales               Product purchase information
  133.    SUPPORT        Customer Service    Problems with product or
  134.                                       service
  135.  
  136.  
  137. 4.  NETWORK OPERATIONS MAILBOX NAMES
  138.  
  139.    Operations addresses are intended to provide recourse for customers,
  140.    providers and others who are experiencing difficulties with the
  141.    organization's Internet service.
  142.  
  143.    MAILBOX        AREA                USAGE
  144.    -----------    ----------------    ---------------------------
  145.    ABUSE          Customer Relations  Inappropriate public behaviour
  146.    NOC            Network Operations  Network infrastructure
  147.    SECURITY       Network Security    Security bulletins or queries
  148.  
  149.  
  150. 5.  SUPPORT MAILBOX NAMES FOR SPECIFIC INTERNET SERVICES
  151.  
  152.    For major Internet protocol services, there is a mailbox defined for
  153.    receiving queries and reports.  (Synonyms are included, here, due to
  154.    their extensive installed base.)
  155.  
  156.    MAILBOX        SERVICE             SPECIFICATIONS
  157.    -----------    ----------------    ---------------------------
  158.    POSTMASTER     SMTP                [RFC821], [RFC822]
  159.    HOSTMASTER     DNS                 [RFC1033-RFC1035]
  160.    USENET         NNTP                [RFC977]
  161.    NEWS           NNTP                Synonym for USENET
  162.    WEBMASTER      HTTP                [RFC 2068]
  163.    WWW            HTTP                Synonym for WEBMASTER
  164.    UUCP           UUCP                [RFC976]
  165.    FTP            FTP                 [RFC959]
  166.  
  167.  
  168.  
  169.  
  170. Crocker                     Standards Track                     [Page 3]
  171.  
  172. RFC 2142                     Mailbox Names                      May 1997
  173.  
  174.  
  175. 6.  MAILING LIST ADMINISTRATION MAILBOX
  176.  
  177.    Mailing lists have an administrative mailbox name to which add/drop
  178.    requests and other meta-queries can be sent.
  179.  
  180.    For a mailing list whose submission mailbox name is:
  181.  
  182.       <LIST@DOMAIN>
  183.  
  184.    there MUST be the administrative mailbox name:
  185.  
  186.       <LIST-REQUEST@DOMAIN>
  187.  
  188.    Distribution List management software, such as MajorDomo and
  189.    Listserv, also have a single mailbox name associated with the
  190.    software on that system -- usually the name of the software -- rather
  191.    than a particular list on that system.  Use of such mailbox names
  192.    requires participants to know the type of list software employed at
  193.    the site.  This is problematic.  Consequently:
  194.  
  195.       LIST-SPECIFIC (-REQUEST) MAILBOX NAMES ARE REQUIRED,
  196.       INDEPENDENT OF THE AVAILABILITY OF GENERIC LIST SOFTWARE
  197.       MAILBOX NAMES.
  198.  
  199. 7.  DOMAIN NAME SERVICE ADMINISTRATION MAILBOX
  200.  
  201.    In DNS (see [RFC1033], [RFC1034] and [RFC1035]), the Start Of
  202.    Authority record (SOA RR) has a field for specifying the mailbox name
  203.    of the zone's administrator.
  204.  
  205.    This field must be a simple word without metacharacters (such as "%"
  206.    or "!" or "::"), and a mail alias should be used on the relevant mail
  207.    exchanger hosts to direct zone administration mail to the appropriate
  208.    mailbox.
  209.  
  210.    For simplicity and regularity, it is strongly recommended that the
  211.    well known mailbox name HOSTMASTER always be used
  212.    <HOSTMASTER@domain>.
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Crocker                     Standards Track                     [Page 4]
  227.  
  228. RFC 2142                     Mailbox Names                      May 1997
  229.  
  230.  
  231. 8.  AUTONOMOUS SYSTEM MAILBOX
  232.  
  233.    Several Internet registries implement mailing lists for Autonomous
  234.    System contacts.  So, for example, mail sent to <AS3557@RA.NET> will
  235.    at the time of this writing reach the technical contact for
  236.    Autonomous System 3557 in the BGP4 (see [RFC1654], [RFC1655] and
  237.    [RFC1656]).
  238.  
  239.    Not all Autonomous Systems are registered with all registries,
  240.    however, and so undeliverable mailbox names under this scheme should
  241.    be treated as an inconvenience rather than as an error or a standards
  242.    violation.
  243.  
  244. 9.  SECURITY CONSIDERATIONS
  245.  
  246.    Denial of service attacks (flooding a mailbox with junk) will be
  247.    easier after this document becomes a standard, since more systems
  248.    will support the same set of mailbox names.
  249.  
  250. 10. REFERENCES
  251.  
  252.    [RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
  253.    821, Information Sciences Institute, August 1982.
  254.  
  255.    [RFC822] Crocker, D., "Standard for the format of ARPA Internet text
  256.    messages", STD 11, RFC 822, University of Delaware, August 1982.
  257.  
  258.    [RFC959] Postel, J., and J. Reynolds, "File Transfer Protocol (FTP)",
  259.    STD 9, RFC 959, Information Sciences Institute, October 1985.
  260.  
  261.    [RFC974] Partridge, C., "Mail routing and the domain system", STD 14,
  262.    RFC 974, CSNET CIC BBN Laboratories Inc, January 1986.
  263.  
  264.    [RFC976] Horton, M., "UUCP mail interchange format standard", RFC
  265.    976, Bell Laboratories, February 1986.
  266.  
  267.    [RFC977] Kantor, B., et al, "Network News Transfer Protocol: A
  268.    Proposed Standard for the Stream-Based Transmission of News", RFC
  269.    977, University of California, February 1986.
  270.  
  271.    [RFC1033] Lottor, M., "Domain administrators operations guide", RFC
  272.    1033, SRI International, November 1987.
  273.  
  274.    [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
  275.    STD 13, RFC 1035, USC/Information Sciences Institute, November 1987.
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Crocker                     Standards Track                     [Page 5]
  283.  
  284. RFC 2142                     Mailbox Names                      May 1997
  285.  
  286.  
  287.    [RFC1035] Mockapetris, P., "Domain Names - Implementation and
  288.    Specification" STD 13, RFC 1035, USC/Information Sciences Institute,
  289.    November 1987.
  290.  
  291.    [RFC1654] Rekhter, Y., et al, "A Border Gateway Protocol 4 (BGP- 4)",
  292.    RFC 1654, T.J. Watson Research Center, IBM Corp., July 1994.
  293.  
  294.    [RFC1655] Rekhter, Y., et al, "Application of the Border Gateway
  295.    Protocol in the Internet", RFC 1655, T.J. Watson Research Center, IBM
  296.    Corp., July 1994.
  297.  
  298.    [RFC1656] Traina, P., "BGP-4 Protocol Document Roadmap and
  299.    Implementation Experience", RFC 1656, cisco Systems, July 1994.
  300.  
  301.    [HTTP] Berners-Lee, T., et al, "Hypertext Transfer Protocol --
  302.    HTTP/1.0", RFC 1945, May 1996.
  303.  
  304. 11. ACKNOWLEDGEMENTS
  305.  
  306.    This specification derived from an earlier draft written by Paul
  307.    Vixie.  Thanks to Stan Barber, Michael Dillon, James Aldridge, J.  D.
  308.    Falk, Peter Kaminski, Brett Watson, Russ Wright, Neal McBurnett, and
  309.    Ed Morin for their comments on that draft.
  310.  
  311. 12. AUTHOR'S ADDRESS
  312.  
  313.    Dave Crocker
  314.    Internet Mail Consortium
  315.    127 Segre Ave.
  316.    Santa Cruz, CA
  317.  
  318.    Phone: +1 408 246 8253
  319.    EMail: dcrocker@imc.org
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Crocker                     Standards Track                     [Page 6]
  339.  
  340.