I sat on this (and KRE's reply) for a month and spoke with Scott and others
in Montreal and I think I am finally ready to reply. There are replies to
two messages here, one to Dave Crocker and one to Robert Elz.
[dcrocker]
It needs to be published... after undergoing two kinds of changes:
As such, this document needs to be published as a full Internet
standard, not merely as a BCP. Instead of simply listing a range of
addresses that exist around the net, it should put the imprimateur of
formal definition -- and formal expection and status -- on important
mailbox names.
No comment. Scott knows what a BCP is and how it differs from an RS or IS,
and he has tried to explain it to me several times, and I never can figure
it out again by the following day. Whatever SOB and MO want to do here is
fine; they have my proxy to the extent that one matters.
a) CERT is a (registered) service mark. Has its use, here, been
authorized by the CERT?
No, but since this is not itself a commercial use, we are safe. If someone
puts CERT(_at_)DOMAIN on a billboard intended to sell internet service, the
breath
mint company who sells CERT may ask their lawyer to write a letter. This is
outside the scope of my effort, just as getting IBM to release their patent
on network printing turned out to be outside of RFC 1602's scope of work.
b) The POSTMASTER address is for all Internet-accessible
destinations, not only for sites running SMTP. The distinction is
important, since many sites do not run SMTP at all, but have highly
mediated access to Internet mail, even though their address appears direct,
via MX records. While the document does cite MX records, elsewhere, it
appears to rely on some fairly subtle comprehension by the reader, to know
that the POSTMASTER support is expected for all sites accessible through
Internet mail. The document needs to make this more explicit.
OK. I forgot that the use RFC 822 doesn't imply the use of RFC 821. Fixed.
c) SUPPORT, HELP, INFO, and SALES are listed in a lower status.
In fact they are extremely important and popular to use of the Internet
today and it would be particularly helpful to stress the role of these
addresses (and consider adding a few more, perhaps) with respect to
user/customer interactions with service and business providers.
On NANOG where this work all began, these were the ones folks mentioned as
having seen in operation somewhere. I chose to limit the amount of new work
since I was really just trying to document current practice. Though as you
point out, I chose a poor title given that goal.
d) What is the requirement for FTP-Admin, redundant with the FTP
mailbox reference?
I never liked FTP-ADMIN anyway, so I've just taken it out.
So,
I suggest a quick round of discussion to hone down and/or build up
the list, attempting to choose rather than merely list requisite addresses
and attempting to get explicit participation from the community in agreeing
to the choices. There has been no discussion at all, perhaps because we've
gone so long without a formal standard. The intent of pursuing formal
standardization is to make explicit the need and desire for open discussion
-- and approval.
I don't think that more discussion would be a good thing. All the hard work
done on this document to date has been in the act of removing things and
keeping ``good ideas'' out. Left to myself, without MO and SOB and Randy
Bush to keep reminding me to KISS, I would have had this thing up over 20
pages by this time. I am quite satisfied with the results of that moderation
and I would consider it a disaster in the making if we started some kind of
working group, even a quickie, for the purpose of complicating things and
making this thing longer than it already is.
All that said, I will defer to MO and SOB on this point.
The goal should be for the document to give network administrators
explicit and formal direction as to the addresses they are expected to
implement, as opposed to the addresses that they merely might consider.
I'm not sure I get this. Someone who implements everything in this document
will never get a complaint about mail to some well known address bouncing.
Someone who implements something less than the totality can reasonably be
expected to be exercising their own judgement, and who are we quibble?
If it will help, I'll offer to pursue this on Paul's behalf. That
is, lead a month or so of discussion; do document modifications as needed;
but no change in authorship. (No idealism here, I just figure that
suggesting more work requires offering to help do it.)
If MO and/or SOB agree that an expanded goal set is appropriate, I will stay
on as document editor (NROFF and TBL are close friends by this time), but I
will not be able to spend the time organizing or participating in a discussion
of how to make this thing longer than it already is. Even if I had time, I
do not have the motivation. More is not better, especially for STDADDR.
[kre]
2. Unfortunately, some of the addresses in the current document do NOT
represent current practise or they have some (minor) problems.
I suspect that it is simply too late now to create some of the addresses
mentioned. Too many e-mail addresses have been allocated already for
too many purposes, and people just aren't going to rewrite all their manuals
to change the addresses because the ones they used have now been defined to
have a special meaning.
True. And that's one of the limits I faced in the original NANOG discussion.
If new standard addresses are to be created, they probably need to be in
a form which is very unlikely to conflict with existing e-mail addresses,
which rules out simple "word" (strings of letters), "word.word", and
"word_word" forms - those are all much too widely used already, in just
about all possible combinations.
At Xerox they append caret (^) to such things. I'm not ruling that out, but
I will say that a lot of the addresses in the current draft are already in
wide use, and just as we can't get Professor Sales to abandon his e-mail
address (though he may want to do that anyway, if we succeed!), we cannot
get all the nets in the world to change TROUBLE to TROUBLE^ (or whatever).
Before anything is standardised in this area we need to discover just how
widely used the names are, and/or how willing people will be to implement
them in the form desired. Personally, I find it hard enough to get people
to make "postmaster" work.
Amen to that last part. (Microsoft could help a lot here.)