Re: I-D (Re: Out of date contact information )
I would suggest adding "hostmaster" for DNS issues (and suggesting that this be the address listed as the contact in DNS SOA records). -- Stan | Academ Consulting Services |internet: sob@academ.com Olan | For more info on academ, see this |uucp: {mcsun|amdahl}!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.
Below, please find three messages, three replies, and an updated draft.
From: sob@academ.com (Stan Barber)
I would suggest adding "hostmaster" for DNS issues (and suggesting that this be the address listed as the contact in DNS SOA records).
Done.
From: Michael Dillon <michael@memra.com>
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 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Are you sure of this? There is a "list-managers" list somewhere that might be worth checking into to be sure.
I have observed the fact that the convention is becoming less common; we can lament it (see below) but it will remain a fact.
for any given mailing list should be treated as an inconvenience rather than as an error or standards violation.
Fair enough, but perhaps the RFC could "urge" list admins to create a -request form of their list name since it does create a predictable place to send administrivia. Otherwise you end up trying listserv, listproc, majordomo and who knows what else.
That's reasonable. Done.
You might also suggest that sites in a country where English is not the official language should also implement native language aliases for all these terms where possible.
I don't think that's reasonable for something like this. RFC's are published in english. Protocol header names are in english. The assigned numbers RFC is in english. POSTMASTER is in english. I think that if someone wants to address the non-english language problem that this would be a good thing, but that's a separate document and I see no need to mention it here.
Maybe close off the RFC with a sample /etc/aliases file that has all the suggested names aliased to an account named "admin" including some comments for the ones (USENET) that are likely to be needed on other than a mail server. Remember, this RFC will be read by a lot more newbies than most RFC's.
I appreciate your confidence in this document, but it's not an RFC yet. I am reluctant to do as you suggest since it would require making up addresses to be the targets of the well known addresses, or using real addresses that would ultimately be bombarded by the newbies you keep talking about. (Not to mention that Sendmail is not the only mail transport in town and not all newbies will recognize an aliases file or be able to interpret one.)
From: James Aldridge <jhma@EU.net>
[...]
This list should probably also contain `hostmaster' as the contact for DNS-related matters. Although *in principle* this contact information should be obtainable from the SOA RR for the zone, standardising it here should make things easier.
Stan beat you to this suggestion, but thanks just the same. 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 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] hostmaster DNS [RFC1033], [RFC1034], [RFC1035] 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 Expires November 1996 [Page 3] 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 4] INTERNET-DRAFT STD ADDR May 1996 [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 5] INTERNET-DRAFT STD ADDR May 1996 7 - Acknowledgements Thanks to Stan Barber, Michael Dillon, and James Aldridge 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.2 1996/05/03 08:04:37 vixie Exp vixie $ Expires November 1996 [Page 6]
Maybe close off the RFC with a sample /etc/aliases file that has all the suggested names aliased to an account named "admin" including some comments for the ones (USENET) that are likely to be needed on other than a mail server. Remember, this RFC will be read by a lot more newbies than most RFC's.
I appreciate your confidence in this document, but it's not an RFC yet. I am reluctant to do as you suggest since it would require making up addresses to be the targets of the well known addresses, or using real addresses that would ultimately be bombarded by the newbies you keep talking about. (Not to mention that Sendmail is not the only mail transport in town and not all newbies will recognize an aliases file or be able to interpret one.)
You might consider using the domain Example.ORG (sort of the RFC 1918 of domains) if you decide to build some appendixen. You might want to note the prior work done by the NJM working group. --bill
From: bmanning@ISI.EDU
You might consider using the domain Example.ORG (sort of the RFC 1918 of domains) if you decide to build some appendixen.
If a domain example were all I needed, I'd do as you suggest. What I'm trying to avoid is aliases point to either real, or imagined addresses. If I put "root: steve" in the document, some poor Steve somewhere some time is going to get inundated by root's mail and he'll (correctly and justly) blame _me_ for it.
You might want to note the prior work done by the NJM working group.
I would be most happy to do that, but can you give me a more solid ref?
From: bmanning@ISI.EDU
You might consider using the domain Example.ORG (sort of the RFC 1918 of domains) if you decide to build some appendixen.
If a domain example were all I needed, I'd do as you suggest. What I'm trying to avoid is aliases point to either real, or imagined addresses. If I put "root: steve" in the document, some poor Steve somewhere some time is going to get inundated by root's mail and he'll (correctly and justly) blame _me_ for it.
Might be a good time to reflect that using fqdn's in alias files is a good practice; e.g. geek: bmanning is less prefered than geek: bmanning@example.org (Oh, and if volunteer use would be an acceptable alternative, please consider using bmanning as an example :) -- --bill
On Fri, 3 May 1996, Paul A Vixie wrote:
From: bmanning@ISI.EDU You might want to note the prior work done by the NJM working group.
I would be most happy to do that, but can you give me a more solid ref?
Here are pointers to minutes of NJM meetings where I remember us discussing these issues: ftp://ftp.ietf.cnri.reston.va.us/ietf/njm/njm-minutes-91nov.txt ftp://ftp.ietf.cnri.reston.va.us/ietf/njm/njm-minutes-92jul.txt -Chris
I'm cleaning out all my old mail about the "stdaddr" document, which Scott has been reminding me needs to get disposed of.
You might want to note the prior work done by the NJM working group.
I would be most happy to do that, but can you give me a more solid ref?
Here are pointers to minutes of NJM meetings where I remember us discussing these issues:
ftp://ftp.ietf.cnri.reston.va.us/ietf/njm/njm-minutes-91nov.txt
trouble@your.net got it noc@your.net got it noc.your.net out of scope net-trouble@noc.your.net never seen this, don't like it much noc@noc.your.net never seen this, don't like it much
ftp://ftp.ietf.cnri.reston.va.us/ietf/njm/njm-minutes-92jul.txt
- 192.1.1 (a BBN Network) will be discontinued because some vendors of medical equipment ship using it as a default host network. I love stuff like that.
Paul A Vixie wrote:
I would suggest adding "hostmaster" for DNS issues (and suggesting that this be the address listed as the contact in DNS SOA records).
Done.
With ISP's assigning addresses to their customers rather than the Internic, would customer IP address request be included in hostmaster@isp.net or would this warrent a new name. -- +---------------------------------------------------------------+ | Paul Steiger paul@pbi.net \|/ | | Network Engineer --*-- | | Pacific Bell Internet Services /|\ | | 303 2nd Street, Suite 650 | | San Francisco, CA 94107 http://www.pbi.net | +---------------------------------------------------------------+
On Fri, 3 May 1996, Paul Steiger wrote:
Paul A Vixie wrote:
Done.
With ISP's assigning addresses to their customers rather than the Internic, would customer IP address request be included in hostmaster@isp.net or would this warrent a new name.
At CICNet, systems adminstration staff does DNS, and network engineering staff does ip address allocations. Personally, I think this division makes sense as ip address allocation is very much married to the network topology. So I think this should either be something else independent of dns address, like ip-request@isp.net or be folded into the generic routing@isp.net type general purpose address. Just my $0.02 -dorian
Paul Steiger
Paul A Vixie wrote:
I would suggest adding "hostmaster" for DNS issues (and suggesting that this be the address listed as the contact in DNS SOA records).
Done.
With ISP's assigning addresses to their customers rather than the Internic, would customer IP address request be included in hostmaster@isp.net or would this warrent a new name.
anyone for 'ipadmin'? seriously. -brett
anyone for 'ipadmin'? seriously.
I'm against that. I am striving to limit the level of ``invention'' in this document and really just substantially cover the best of current practices. If InterNIC can cope with a single address (HOSTMASTER) for both domain and address allocation issues, I suspect that the rest of us can do the same. I am considering the proposal of a CERT address per domain. While SECURITY and others are more _prevalent_, I'm not sure that they represent the _best_ of current practices. Since "The CERT" has recommended per-domain CERT addresses, I think that the next public draft will recommend a CERT address and relegate SECURITY to "less well known" status. Comments are of course welcome on this change. The "less well known" table is perilously close to overflow already. I have resisted adding everything that anybody knows of or can imagine, since what I really want to do is (a) codify the minimum useful address set, and (b) do some lip service to existing end-user expectations of things I don't think we ought to be recommending. Due to those same concerns, I resisted (mightily, and I won) the temptation to add sections talking about well known whois.<domain> servers, DNS RP RR's, current international and national registry lists, how to use Alta Vista to locate folks, a little ditty about the old (dead?) whois phone book, and so on. If _I_ (of all people!) can resist the temptation to borrow GNU Emacs' "kitchen sink" logo for the first page of the postscript version of this document, then I expect the rest of you (who presumably have better sense and more self control) can also avoid asking this document to expand to the size of the Encyclopaedia Britannica.
participants (7)
-
bmanning@isi.edu
-
brett@tta.com
-
Christopher D. Wheeler
-
Dorian Kim
-
Paul A Vixie
-
Paul Steiger
-
sob@academ.com