
   Operational Requirements Area                          Paul Vixie (ISC)
   INTERNET-DRAFT                                                May, 1996
   <draft-vixie-ops-stdaddr-01.txt>


          Standard Electronic Mail Addresses For Internet Operations


   Status of this Memo

      This document is an Internet-Draft.  Internet-Drafts are working
      documents of the Internet Engineering Task Force (IETF), its areas,
      and its working groups.  Note that other groups may also distribute
      working documents as Internet-Drafts.

      Internet-Drafts are draft documents valid for a maximum of six months
      and may be updated, replaced, or obsoleted by other documents at any
      time.  It is inappropriate to use Internet-Drafts as reference
      material or to cite them other than as ``work in progress.''

      To learn the current status of any Internet-Draft, please check the
      ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
      Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
      munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
      ftp.isi.edu (US West Coast).


   Abstract

      This draft enumerates and describes standard electronic mail
      addresses to be used when contacting the operations personnel of an
      arbitrary domain.

      As an operational standard, the recommendations herein pertain to
      vendors only inasmuch as their end user documentation should
      recommend that these mail addresses be aliased to appropriate end
      user personnel.

      This document should be advanced as a Best Current Practice, since it
      describes what the current practice is and should be.








   Expires November 1996                                           [Page 1]

   INTERNET-DRAFT                  STD ADDR                        May 1996


   1 - Rationale and Scope

   1.1. Several previous RFC documents have specified electronic mail
   addresses 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> address on all hosts that have an SMTP server.

   1.2. Other protocols have defacto standards for well known addresses,
   such as <USENET@domain> for NNTP (see [RFC977]), and <WEBMASTER@domain>
   for HTTP (see [HTTP]).

   1.3. Defacto standards also exist for well known addresses which have
   nothing to do with a particular protocol, e.g., <ABUSE@domain> and
   <TROUBLE@domain>.

   1.4. The purpose of this draft is to collect all of these well known
   addresses in one place, add a few new ones, and ultimately recommend
   that IANA carry these addresses in future editions of its Defined
   Numbers periodical.

   2 - Definitions and Invariants

   2.1. The scope of a well known mail address is its domain name.  Thus,
   the mail exchangers (see [RFC974]) for a domain must handle well known
   addresses even though some of these addresses might pertain to services
   not offered by the mail exchanger hosts.  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 serve the NNTP protocol.

   2.2. A host is not required to run its own SMTP server, but every host
   that implements a protocol covered by a well known mail address should
   have an MX RRset (see [RFC974]) and the mail exchangers specified by
   this RRset should recognize this host's domain name as ``local'' for the
   purpose of accepting mail bound for a well known address.  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.






   Expires November 1996                                           [Page 2]

   INTERNET-DRAFT                  STD ADDR                        May 1996


   2.3. For well known addresses that are not related to protocols, only
   the organization's top level domain name need be valid.  For example, if
   an Internet service provider's domain name is NETCOM.COM, then the
   <ABUSE@NETCOM.COM> address must be deliverable, even though the
   customers whose activity generates complaints use hosts with more
   specific domain names like SHELL1.NETCOM.COM.

   2.4. Well known addresses ought to be recognized independent of
   character case.  For example, POSTMASTER, postmaster, Postmaster,
   PostMaster, and even PoStMaStEr should all be deliverable and should all
   be delivered to the same mailbox.

   2.5. Most domains do not need the full set of well known addresses,
   since not every domain will implement the protocols or offer the service
   described by every well known address.  If a given service is offerred,
   then the relevant well known address(es) ought to be deliverable at all
   advertised domain names.

   2.6. Implementations of these well known addresses ought to take account
   of the expectations of the senders who will use them.  Sending back an
   automatic e-mail acknowledgement would be a kindness (though we suggest
   caution against the possibility of ``duelling mail robots'' and the
   resulting mail loops).  Some of these addresses can be satisfied by
   same-day problem resolution (for example, FTP and WEBMASTER), whereas
   some should be read and handled in real time by a redundant team (for
   example, CERT and ABUSE).






















   Expires November 1996                                           [Page 3]

   INTERNET-DRAFT                  STD ADDR                        May 1996


   3 - Well Known Addresses

   3.1. Protocol Related Addresses

      Address      Protocol   Standard(s)
      --------------------------------------------------------
      POSTMASTER   SMTP       [RFC821], [RFC822]
      HOSTMASTER   DNS        [RFC1033], [RFC1034], [RFC1035]
      USENET       NNTP       [RFC977]
      WEBMASTER    HTTP       [HTTP]
      UUCP         UUCP       [RFC976]
      FTP          FTP        [RFC959]


   3.2. Protocol Independent Addresses

      Address    Operations Area      Usage
      --------------------------------------------------------------------
      ABUSE      Customer Relations   Inappropriate public behaviour
      TROUBLE    Operations           General/miscellaneous emergency
      ROUTING    Network Operations   Network infrastructure emergency
      NOC        Network Operations   Network infrastructure nonemergency
      CERT       Network Security     Security emergencies in progress
      SECURITY   Network Security     Security bulletins or queries


   3.3. Optional, Less Well Known Addresses

      Address     Operations Area    Usage
      -----------------------------------------------------------------------
      NIC         DNS service        Usually a synonym for HOSTMASTER
      WWW         HTTP service       Usually a synonym for WEBMASTER
      NEWS        NNTP service       Usually a synonym for USENET
      FTP-ADMIN   FTP service        Usually a synonym for FTP
      LISTOWNER   E-mail service     Add/drop requests (prefer *-REQUEST)
      SUPPORT     Customer Service   Product or service not working
      HELP        Customer Service   Usually a synonym for SUPPORT
      ROOT        Customer Service   Usually a synonym for SUPPORT
      INFO        Marketing          Usually an e-mail autoresponder
      SALES       Sales              ``Please sign me up for your service.''








   Expires November 1996                                           [Page 4]

   INTERNET-DRAFT                  STD ADDR                        May 1996


   4 - Other Well Known Addresses

   4.1. Many mailing lists have an administrative address to which add/drop
   requests and other metaqueries can be sent.  For a mailing list whose
   submission address is <LIST@DOMAIN>, the usual administrative address is
   <LIST-REQUEST@DOMAIN>.  With the advent of list management software such
   as MajorDomo, this convention is becoming less common and its absence
   for any given mailing list should be treated as a standards violation.
   Make sure that your lists each have a *-REQUEST address and complain to
   remote POSTMASTERs when you discover remote lists without *-REQUEST
   addresses.

   4.2. 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 addresses under this scheme should be treated as an
   inconvenience rather than as an error or a standards violation.

   4.3. In DNS (see [RFC1033], [RFC1034] and [RFC1035]), the Start Of
   Authority record (SOA RR) has a field for specifying the mail address of
   the zone's administrator.  This field should be a simple word without
   metacharacters (such as ``%'' or ``!'' or ``::''), and a transport level
   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 hereby recommended that the well known address
   HOSTMASTER always be used.

   5 - Security Considerations

   Denial of service attacks (flooding a mailbox with junk) will be easier
   after this document becomes a standard.

   6 - References

   [RFC821]
      J. Postel, "Simple Mail Transfer Protocol", RFC 821, Information
      Sciences Institute, 08/01/1982

   [RFC822]
      D. Crocker, "Standard for the format of ARPA Internet text messages",
      RFC 822, University of Delaware, 08/13/1982.





   Expires November 1996                                           [Page 5]

   INTERNET-DRAFT                  STD ADDR                        May 1996


   [RFC959]
      J. Postel (et al), "File Transfer Protocol (FTP)", RFC 959,
      Information Sciences Institute, October 1985.

   [RFC974]
      C. Partridge, "Mail routing and the domain system", RFC 974, CSNET
      CIC BBN Laboratories Inc, 01/01/1986.

   [RFC976]
      M. Horton, "UUCP mail interchange format standard", RFC 976, Bell
      Laboratories, 02/01/1986.

   [RFC977]
      B. Kantor (et al), "Network News Transfer Protocol: A Proposed
      Standard for the Stream-Based Transmission of News", RFC 977,
      University of California, February 1986.

   [RFC1033]
      M. Lottor, "Domain administrators operations guide", RFC 1033, SRI
      International, 11/01/1987.

   [RFC1034]
      P. Mockapetris, "Domain names - concepts and facilities", RFC 1035,
      USC/Information Sciences Institute, 11/01/1987.

   [RFC1035]
      P. Mockapetris, ``Domain Names - Implementation and Specification,''
      RFC 1035, USC/Information Sciences Institute, November 1987.

   [RFC1654]
      Y. Rekhter (et al), "A Border Gateway Protocol 4 (BGP-4)", RFC 1654,
      T.J. Watson Research Center, IBM Corp., 07/21/1994.

   [RFC1655]
      Y. Rekhter (et al), "Application of the Border Gateway Protocol in
      the Internet", RFC 1655, T.J. Watson Research Center, IBM Corp.,
      07/21/1994.

   [RFC1656]
      P. Traina, "BGP-4 Protocol Document Roadmap and Implementation
      Experience", RFC 1656, cisco Systems, July 1994.

   [HTTP]
      T. Berners-Lee (et al), "Hypertext Transfer Protocol -- HTTP/1.0",
      <draft-ietf-http-v10-spec-05.txt>, February 19, 1996.



   Expires November 1996                                           [Page 6]

   INTERNET-DRAFT                  STD ADDR                        May 1996


   7 - Acknowledgements

   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 this document.

   8 - Author's Address

      Paul Vixie
         Internet Software Consortium
         Star Route Box 159A
         Woodside, CA 94062
         +1 415 747 0204
         <paul@vix.com>


   $Id: stdaddr.txt,v 1.5 1996/05/07 07:26:29 vixie Exp vixie $































   Expires November 1996                                           [Page 7]

