I-D (Re: Out of date contact information )

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).


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)

          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).


      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]


   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

   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

   Expires November 1996 [Page 2]


   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)

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).


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