reports/rfc/draft-vixie-ops-stdaddr-00.txt

   1
   2    Operational Requirements Area                          Paul Vixie (ISC)
   3    INTERNET-DRAFT                                                May, 1996
   4    <draft-vixie-ops-stdaddr-00.txt>
   5
   6
   7           Standard Electronic Mail Addresses For Internet Operations
   8
   9
  10    Status of this Memo
  11
  12       This document is an Internet-Draft.  Internet-Drafts are working
  13       documents of the Internet Engineering Task Force (IETF), its areas,
  14       and its working groups.  Note that other groups may also distribute
  15       working documents as Internet-Drafts.
  16
  17       Internet-Drafts are draft documents valid for a maximum of six months
  18       and may be updated, replaced, or obsoleted by other documents at any
  19       time.  It is inappropriate to use Internet-Drafts as reference
  20       material or to cite them other than as ``work in progress.''
  21
  22       To learn the current status of any Internet-Draft, please check the
  23       ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
  24       Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  25       munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  26       ftp.isi.edu (US West Coast).
  27
  28
  29    Abstract
  30
  31       This draft enumerates and describes standard electronic mail
  32       addresses to be used when contacting the operations personnel of an
  33       arbitrary domain.
  34
  35       As an operational standard, the recommendations herein pertain to
  36       vendors only inasmuch as their end user documentation should
  37       recommend that these mail addresses be aliased to appropriate end
  38       user personnel.
  39
  40       This document should be advanced as a Best Current Practice, since it
  41       describes what the current practice is and should be.
  42
  43
  44
  45
  46
  47
  48
  49
  50    Expires November 1996                                           [Page 1]
  51 \f
  52    INTERNET-DRAFT                  STD ADDR                        May 1996
  53
  54
  55    1 - Rationale and Scope
  56
  57    1.1. Several previous RFC documents have specified electronic mail
  58    addresses to be used when reaching the operators of the new service; for
  59    example, [RFC822 6.3, C.6] requires the presence of a
  60    <POSTMASTER@domain> address on all hosts that have an SMTP server.
  61
  62    1.2. Other protocols have defacto standards for well known addresses,
  63    such as <USENET@domain> for NNTP (see [RFC977]), and <WEBMASTER@domain>
  64    for HTTP (see [HTTP]).
  65
  66    1.3. Defacto standards also exist for well known addresses which have
  67    nothing to do with a particular protocol, e.g., <ABUSE@domain> and
  68    <TROUBLE@domain>.
  69
  70    1.4. The purpose of this draft is to collect all of these well known
  71    addresses in one place, add a few new ones, and ultimately recommend
  72    that IANA carry these addresses in future editions of its Defined
  73    Numbers periodical.
  74
  75    2 - Definitions and Invariants
  76
  77    2.1. The scope of a well known mail address is its domain name.  Thus,
  78    the mail exchangers (see [RFC974]) for a domain must handle well known
  79    addresses even though some of these addresses might pertain to services
  80    not offered by the mail exchanger hosts.  So, for example, if an NNTP
  81    server advertises the organization's top level domain in ``Path:''
  82    headers (see [RFC977]), the mail exchangers for that top level domain
  83    must accept mail to <USENET@domain> even if the mail exchanger hosts do
  84    not serve the NNTP protocol.
  85
  86    2.2. A host is not required to run its own SMTP server, but every host
  87    that implements a protocol covered by a well known mail address should
  88    have an MX RRset (see [RFC974]) and the mail exchangers specified by
  89    this RRset should recognize this host's domain name as ``local'' for the
  90    purpose of accepting mail bound for a well known address.  Note that
  91    this is true even if the advertised domain name is not the same as the
  92    host's domain name; for example, if an NNTP server's host name is
  93    DATA.RAMONA.VIX.COM yet it advertises the domain name VIX.COM in its
  94    ``Path:'' headers, then mail must be deliverable to both
  95    <USENET@VIX.COM> and <USENET@DATA.RAMONA.VIX.COM>.
  96
  97
  98
  99
 100
 101
 102
 103    Expires November 1996                                           [Page 2]
 104 \f
 105    INTERNET-DRAFT                  STD ADDR                        May 1996
 106
 107
 108    2.3. For well known addresses that are not related to protocols, only
 109    the organization's top level domain name need be valid.  For example, if
 110    an Internet service provider's domain name is NETCOM.COM, then the
 111    <ABUSE@NETCOM.COM> address must be deliverable, even though the
 112    customers whose activity generates complaints use hosts with more
 113    specific domain names like SHELL1.NETCOM.COM.
 114
 115    2.4. Well known addresses ought to be recognized independent of
 116    character case.  For example, POSTMASTER, postmaster, Postmaster,
 117    PostMaster, and even PoStMaStEr should all be deliverable and should all
 118    be delivered to the same mailbox.
 119
 120    2.5. Most domains do not need the full set of well known addresses,
 121    since not every domain will implement the protocols or offer the service
 122    described by every well known address.  If a given service is offerred,
 123    then the relevant well known address(es) ought to be deliverable at all
 124    advertised domain names.
 125
 126    3 - Well Known Addresses
 127
 128    3.1. Protocol Related Addresses
 129
 130       Address      Protocol   Standard(s)
 131       --------------------------------------------------------
 132       POSTMASTER   SMTP       [RFC821], [RFC822]
 133       HOSTMASTER   DNS        [RFC1033], [RFC1034], [RFC1035]
 134       USENET       NNTP       [RFC977]
 135       WEBMASTER    HTTP       [HTTP]
 136       UUCP         UUCP       [RFC976]
 137       FTP          FTP        [RFC959]
 138
 139
 140    3.2. Protocol Independent Addresses
 141
 142       Address    Operations Area      Example Usage
 143       ---------------------------------------------------------------
 144       ABUSE      Customer Relations   Inappropriate public behaviour
 145       NOC        Network Operations   Network infrastructure problem
 146       SUPPORT    Customer Support     Product or service not working
 147       SECURITY   Network Security     Security bulletins or queries
 148
 149
 150
 151
 152
 153
 154
 155
 156    Expires November 1996                                           [Page 3]
 157 \f
 158    INTERNET-DRAFT                  STD ADDR                        May 1996
 159
 160
 161    3.3. Optional, Less Well Known Addresses
 162
 163       Address     Purpose
 164       --------------------------------------------------------------
 165       NIC         DNS service (usually a synonym for HOSTMASTER)
 166       WWW         HTTP service (usually a synonym for WEBMASTER)
 167       NEWS        NNTP service (usually a synonym for USENET)
 168       FTP-ADMIN   FTP service (usually a synonym for FTP)
 169       LISTOWNER   Mailing list administration (prefer *-REQUEST)
 170       TROUBLE     Network operations (usually a synonym for NOC)
 171       ROUTING     Network operations (usually a synonym for NOC)
 172       HELP        Customer service (usually a synonym for SUPPORT)
 173       ROOT        Customer service (usually a synonym for SUPPORT)
 174
 175
 176    4 - Other Well Known Addresses
 177
 178    4.1. Many mailing lists have an administrative address to which add/drop
 179    requests and other metaqueries can be sent.  For a mailing list whose
 180    submission address is <LIST@DOMAIN>, the usual administrative address is
 181    <LIST-REQUEST@DOMAIN>.  With the advent of list management software such
 182    as MajorDomo, this convention is becoming less common and its absence
 183    for any given mailing list should be treated as a standards violation.
 184    Make sure that your lists each have a *-REQUEST address and complain to
 185    remote POSTMASTERs when you discover remote lists without *-REQUEST
 186    addresses.
 187
 188    4.2. Several Internet registries implement mailing lists for Autonomous
 189    System contacts.  So, for example, mail sent to <AS3557@RA.NET> will at
 190    the time of this writing reach the technical contact for Autonomous
 191    System 3557 in the BGP4 (see [RFC1654], [RFC1655] and [RFC1656]).  Not
 192    all Autonomous Systems are registered with all registries, however, and
 193    so undeliverable addresses under this scheme should be treated as an
 194    inconvenience rather than as an error or a standards violation.
 195
 196    4.3. In DNS (see [RFC1033], [RFC1034] and [RFC1035]), the Start Of
 197    Authority record (SOA RR) has a field for specifying the mail address of
 198    the zone's administrator.  This field should be a simple word without
 199    metacharacters (such as ``%'' or ``!'' or ``::''), and a transport level
 200    alias should be used on the relevant mail exchanger hosts to direct zone
 201    administration mail to the appropriate mailbox.  For simplicity and
 202    regularity, it is hereby recommended that the well known address
 203    HOSTMASTER always be used.
 204
 205
 206
 207
 208
 209    Expires November 1996                                           [Page 4]
 210 \f
 211    INTERNET-DRAFT                  STD ADDR                        May 1996
 212
 213
 214    5 - Security Considerations
 215
 216    Denial of service attacks (flooding a mailbox with junk) will be easier
 217    after this document becomes a standard.
 218
 219    6 - References
 220
 221    [RFC821]
 222       J. Postel, "Simple Mail Transfer Protocol", RFC 821, Information
 223       Sciences Institute, 08/01/1982
 224
 225    [RFC822]
 226       D. Crocker, "Standard for the format of ARPA Internet text messages",
 227       RFC 822, University of Delaware, 08/13/1982.
 228
 229    [RFC959]
 230       J. Postel (et al), "File Transfer Protocol (FTP)", RFC 959,
 231       Information Sciences Institute, October 1985.
 232
 233    [RFC974]
 234       C. Partridge, "Mail routing and the domain system", RFC 974, CSNET
 235       CIC BBN Laboratories Inc, 01/01/1986.
 236
 237    [RFC976]
 238       M. Horton, "UUCP mail interchange format standard", RFC 976, Bell
 239       Laboratories, 02/01/1986.
 240
 241    [RFC977]
 242       B. Kantor (et al), "Network News Transfer Protocol: A Proposed
 243       Standard for the Stream-Based Transmission of News", RFC 977,
 244       University of California, February 1986.
 245
 246    [RFC1033]
 247       M. Lottor, "Domain administrators operations guide", RFC 1033, SRI
 248       International, 11/01/1987.
 249
 250    [RFC1034]
 251       P. Mockapetris, "Domain names - concepts and facilities", RFC 1035,
 252       USC/Information Sciences Institute, 11/01/1987.
 253
 254    [RFC1035]
 255       P. Mockapetris, ``Domain Names - Implementation and Specification,''
 256       RFC 1035, USC/Information Sciences Institute, November 1987.
 257
 258
 259
 260
 261
 262    Expires November 1996                                           [Page 5]
 263 \f
 264    INTERNET-DRAFT                  STD ADDR                        May 1996
 265
 266
 267    [RFC1654]
 268       Y. Rekhter (et al), "A Border Gateway Protocol 4 (BGP-4)", RFC 1654,
 269       T.J. Watson Research Center, IBM Corp., 07/21/1994.
 270
 271    [RFC1655]
 272       Y. Rekhter (et al), "Application of the Border Gateway Protocol in
 273       the Internet", RFC 1655, T.J. Watson Research Center, IBM Corp.,
 274       07/21/1994.
 275
 276    [RFC1656]
 277       P. Traina, "BGP-4 Protocol Document Roadmap and Implementation
 278       Experience", RFC 1656, cisco Systems, July 1994.
 279
 280    [HTTP]
 281       T. Berners-Lee (et al), "Hypertext Transfer Protocol -- HTTP/1.0",
 282       <draft-ietf-http-v10-spec-05.txt>, February 19, 1996.
 283
 284    7 - Acknowledgements
 285
 286    Thanks to Stan Barber, Michael Dillon, James Aldridge, J. D. Falk, Peter
 287    Kaminski, and Brett Watson for their comments on this document.
 288
 289    8 - Author's Address
 290
 291       Paul Vixie
 292          Internet Software Consortium
 293          Star Route Box 159A
 294          Woodside, CA 94062
 295          +1 415 747 0204
 296          <paul@vix.com>
 297
 298
 299    $Id: draft-vixie-ops-stdaddr-00.txt,v 1.1 2004/01/15 16:02:43 pere Exp $
 300
 301
 302
 303
 304
 305
 306
 307
 308
 309
 310
 311
 312
 313
 314
 315    Expires November 1996                                           [Page 6]
 316 \f
 317