Cathy wrote:
> You know that all this stuff was standardized long ago at an IETF
> working group? The group was called Network Joint Management.
> We all agreed that there should be a trouble mailing list for each NOC
> and I believe we agreed on AS mailing lists as well. It is a shame,
> but I don't believe that that group ever put out an RFC specifying
> this. There was also a group that worked on inter-NOC communications
> and sharing trouble tickets, etc.
Because (a) Randy has taught me that drafts speak louder than words, and
because (b) BIND is eating my face today and I needed a distraction, and
because (c) it's been several hours and bmanning hasn't written a new
draft to cover this conversation, I hereby submit the following.
If it seems like the right approach (that is, all I get back are editorial
nits, "good idea please continue"'s and "you forgot to mention"'s), I will
send this to the Ops A-D's and see what they want to do with it.
Operational Requirements Area Paul Vixie (ISC)
INTERNET-DRAFT May, 1996
<draft-vixie-ops-stdaddr-00.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 recommended standard, since
some of the behaviour it advocates is not prevalent enough to be
called the ``best current practice.''
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>.
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.
3 - Well Known Addresses
3.1. Protocol Related Addresses
Address Protocol Standard(s)
-------------------------------------------
postmaster SMTP [RFC821], [RFC822]
usenet NNTP [RFC977]
webmaster HTTP [HTTP]
uucp UUCP [RFC976]
3.2. Protocol Independent Addresses
Address Operations Area Example Usage
--------------------------------------------------------------
abuse Customer Relations Inappropriate public behaviour
noc Network Operations Network infrastructure problem
trouble Network Operations Synonym for ``noc''
support Customer Support Product or service not working
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 an inconvenience rather
than as an error or standards violation.
Expires November 1996 [Page 3]
INTERNET-DRAFT STD ADDR May 1996
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.
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.
[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.
[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.
Expires November 1996 [Page 4]
INTERNET-DRAFT STD ADDR May 1996
[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>.
7 - Author's Address
Paul Vixie
Internet Software Consortium
Star Route Box 159A
Woodside, CA 94062
+1 415 747 0204
<paul@vix.com>
Expires November 1996 [Page 5]
- - - - - - - - - - - - - - - - -
> You know that all this stuff was standardized long ago at an IETF
> working group? The group was called Network Joint Management.
> We all agreed that there should be a trouble mailing list for each NOC
> and I believe we agreed on AS mailing lists as well. It is a shame,
> but I don't believe that that group ever put out an RFC specifying
> this. There was also a group that worked on inter-NOC communications
> and sharing trouble tickets, etc.
Because (a) Randy has taught me that drafts speak louder than words, and
because (b) BIND is eating my face today and I needed a distraction, and
because (c) it's been several hours and bmanning hasn't written a new
draft to cover this conversation, I hereby submit the following.
If it seems like the right approach (that is, all I get back are editorial
nits, "good idea please continue"'s and "you forgot to mention"'s), I will
send this to the Ops A-D's and see what they want to do with it.
Operational Requirements Area Paul Vixie (ISC)
INTERNET-DRAFT May, 1996
<draft-vixie-ops-stdaddr-00.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 recommended standard, since
some of the behaviour it advocates is not prevalent enough to be
called the ``best current practice.''
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>.
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.
3 - Well Known Addresses
3.1. Protocol Related Addresses
Address Protocol Standard(s)
-------------------------------------------
postmaster SMTP [RFC821], [RFC822]
usenet NNTP [RFC977]
webmaster HTTP [HTTP]
uucp UUCP [RFC976]
3.2. Protocol Independent Addresses
Address Operations Area Example Usage
--------------------------------------------------------------
abuse Customer Relations Inappropriate public behaviour
noc Network Operations Network infrastructure problem
trouble Network Operations Synonym for ``noc''
support Customer Support Product or service not working
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 an inconvenience rather
than as an error or standards violation.
Expires November 1996 [Page 3]
INTERNET-DRAFT STD ADDR May 1996
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.
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.
[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.
[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.
Expires November 1996 [Page 4]
INTERNET-DRAFT STD ADDR May 1996
[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>.
7 - Author's Address
Paul Vixie
Internet Software Consortium
Star Route Box 159A
Woodside, CA 94062
+1 415 747 0204
<paul@vix.com>
Expires November 1996 [Page 5]
- - - - - - - - - - - - - - - - -