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

   1
   2    Operational Requirements Area                          Paul Vixie (ISC)
   3    INTERNET-DRAFT                                                May, 1996
   4    <draft-vixie-ops-stdaddr-01.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>, even though these
  96    addresses might be delivered to different final destinations.
  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    2.6. Implementations of these well known addresses ought to take account
 127    of the expectations of the senders who will use them.  Sending back an
 128    automatic e-mail acknowledgement would be a kindness (though we suggest
 129    caution against the possibility of ``duelling mail robots'' and the
 130    resulting mail loops).  Some of these addresses can be satisfied by
 131    same-day problem resolution (for example, FTP and WEBMASTER), whereas
 132    some should be read and handled in real time by a redundant team (for
 133    example, CERT and ABUSE).
 134
 135
 136
 137
 138
 139
 140
 141
 142
 143
 144
 145
 146
 147
 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 - Well Known Addresses
 162
 163    3.1. Protocol Related Addresses
 164
 165       Address      Protocol   Standard(s)
 166       --------------------------------------------------------
 167       POSTMASTER   SMTP       [RFC821], [RFC822]
 168       HOSTMASTER   DNS        [RFC1033], [RFC1034], [RFC1035]
 169       USENET       NNTP       [RFC977]
 170       WEBMASTER    HTTP       [HTTP]
 171       UUCP         UUCP       [RFC976]
 172       FTP          FTP        [RFC959]
 173
 174
 175    3.2. Protocol Independent Addresses
 176
 177       Address    Operations Area      Usage
 178       --------------------------------------------------------------------
 179       ABUSE      Customer Relations   Inappropriate public behaviour
 180       TROUBLE    Operations           General/miscellaneous emergency
 181       ROUTING    Network Operations   Network infrastructure emergency
 182       NOC        Network Operations   Network infrastructure nonemergency
 183       CERT       Network Security     Security emergencies in progress
 184       SECURITY   Network Security     Security bulletins or queries
 185
 186
 187    3.3. Optional, Less Well Known Addresses
 188
 189       Address     Operations Area    Usage
 190       -----------------------------------------------------------------------
 191       NIC         DNS service        Usually a synonym for HOSTMASTER
 192       WWW         HTTP service       Usually a synonym for WEBMASTER
 193       NEWS        NNTP service       Usually a synonym for USENET
 194       FTP-ADMIN   FTP service        Usually a synonym for FTP
 195       LISTOWNER   E-mail service     Add/drop requests (prefer *-REQUEST)
 196       SUPPORT     Customer Service   Product or service not working
 197       HELP        Customer Service   Usually a synonym for SUPPORT
 198       ROOT        Customer Service   Usually a synonym for SUPPORT
 199       INFO        Marketing          Usually an e-mail autoresponder
 200       SALES       Sales              ``Please sign me up for your service.''
 201
 202
 203
 204
 205
 206
 207
 208
 209    Expires November 1996                                           [Page 4]
 210 \f
 211    INTERNET-DRAFT                  STD ADDR                        May 1996
 212
 213
 214    4 - Other Well Known Addresses
 215
 216    4.1. Many mailing lists have an administrative address to which add/drop
 217    requests and other metaqueries can be sent.  For a mailing list whose
 218    submission address is <LIST@DOMAIN>, the usual administrative address is
 219    <LIST-REQUEST@DOMAIN>.  With the advent of list management software such
 220    as MajorDomo, this convention is becoming less common and its absence
 221    for any given mailing list should be treated as a standards violation.
 222    Make sure that your lists each have a *-REQUEST address and complain to
 223    remote POSTMASTERs when you discover remote lists without *-REQUEST
 224    addresses.
 225
 226    4.2. Several Internet registries implement mailing lists for Autonomous
 227    System contacts.  So, for example, mail sent to <AS3557@RA.NET> will at
 228    the time of this writing reach the technical contact for Autonomous
 229    System 3557 in the BGP4 (see [RFC1654], [RFC1655] and [RFC1656]).  Not
 230    all Autonomous Systems are registered with all registries, however, and
 231    so undeliverable addresses under this scheme should be treated as an
 232    inconvenience rather than as an error or a standards violation.
 233
 234    4.3. In DNS (see [RFC1033], [RFC1034] and [RFC1035]), the Start Of
 235    Authority record (SOA RR) has a field for specifying the mail address of
 236    the zone's administrator.  This field should be a simple word without
 237    metacharacters (such as ``%'' or ``!'' or ``::''), and a transport level
 238    alias should be used on the relevant mail exchanger hosts to direct zone
 239    administration mail to the appropriate mailbox.  For simplicity and
 240    regularity, it is hereby recommended that the well known address
 241    HOSTMASTER always be used.
 242
 243    5 - Security Considerations
 244
 245    Denial of service attacks (flooding a mailbox with junk) will be easier
 246    after this document becomes a standard.
 247
 248    6 - References
 249
 250    [RFC821]
 251       J. Postel, "Simple Mail Transfer Protocol", RFC 821, Information
 252       Sciences Institute, 08/01/1982
 253
 254    [RFC822]
 255       D. Crocker, "Standard for the format of ARPA Internet text messages",
 256       RFC 822, University of Delaware, 08/13/1982.
 257
 258
 259
 260
 261
 262    Expires November 1996                                           [Page 5]
 263 \f
 264    INTERNET-DRAFT                  STD ADDR                        May 1996
 265
 266
 267    [RFC959]
 268       J. Postel (et al), "File Transfer Protocol (FTP)", RFC 959,
 269       Information Sciences Institute, October 1985.
 270
 271    [RFC974]
 272       C. Partridge, "Mail routing and the domain system", RFC 974, CSNET
 273       CIC BBN Laboratories Inc, 01/01/1986.
 274
 275    [RFC976]
 276       M. Horton, "UUCP mail interchange format standard", RFC 976, Bell
 277       Laboratories, 02/01/1986.
 278
 279    [RFC977]
 280       B. Kantor (et al), "Network News Transfer Protocol: A Proposed
 281       Standard for the Stream-Based Transmission of News", RFC 977,
 282       University of California, February 1986.
 283
 284    [RFC1033]
 285       M. Lottor, "Domain administrators operations guide", RFC 1033, SRI
 286       International, 11/01/1987.
 287
 288    [RFC1034]
 289       P. Mockapetris, "Domain names - concepts and facilities", RFC 1035,
 290       USC/Information Sciences Institute, 11/01/1987.
 291
 292    [RFC1035]
 293       P. Mockapetris, ``Domain Names - Implementation and Specification,''
 294       RFC 1035, USC/Information Sciences Institute, November 1987.
 295
 296    [RFC1654]
 297       Y. Rekhter (et al), "A Border Gateway Protocol 4 (BGP-4)", RFC 1654,
 298       T.J. Watson Research Center, IBM Corp., 07/21/1994.
 299
 300    [RFC1655]
 301       Y. Rekhter (et al), "Application of the Border Gateway Protocol in
 302       the Internet", RFC 1655, T.J. Watson Research Center, IBM Corp.,
 303       07/21/1994.
 304
 305    [RFC1656]
 306       P. Traina, "BGP-4 Protocol Document Roadmap and Implementation
 307       Experience", RFC 1656, cisco Systems, July 1994.
 308
 309    [HTTP]
 310       T. Berners-Lee (et al), "Hypertext Transfer Protocol -- HTTP/1.0",
 311       <draft-ietf-http-v10-spec-05.txt>, February 19, 1996.
 312
 313
 314
 315    Expires November 1996                                           [Page 6]
 316 \f
 317    INTERNET-DRAFT                  STD ADDR                        May 1996
 318
 319
 320    7 - Acknowledgements
 321
 322    Thanks to Stan Barber, Michael Dillon, James Aldridge, J. D. Falk, Peter
 323    Kaminski, Brett Watson, Russ Wright, Neal McBurnett, and Ed Morin for
 324    their comments on this document.
 325
 326    8 - Author's Address
 327
 328       Paul Vixie
 329          Internet Software Consortium
 330          Star Route Box 159A
 331          Woodside, CA 94062
 332          +1 415 747 0204
 333          <paul@vix.com>
 334
 335
 336    $Id: draft-vixie-ops-stdaddr-01.txt,v 1.1 2004/01/15 16:02:43 pere Exp $
 337
 338
 339
 340
 341
 342
 343
 344
 345
 346
 347
 348
 349
 350
 351
 352
 353
 354
 355
 356
 357
 358
 359
 360
 361
 362
 363
 364
 365
 366
 367
 368    Expires November 1996                                           [Page 7]
 369 \f