ietf-822
[Top] [All Lists]

Re: [stdaddr] Re: Last Call: Standard Electronic Mail Addresses For ...

1996-08-04 16:05:50
From your draft (the html version...)

   Defacto standards also exist for well known addresses which have
   nothing to do with a particular protocol, e.g., <ABUSE(_at_)domain>
   and <TROUBLE(_at_)domain>. 

These must be de facto standards I've never heard of - but the
main point here is that "trouble" has gone from the rest of the
doc and should probably go from that sentence as well.

"trouble" seems to have any of a dozen different meanings.
When it was first set up here it was to receive outage reports
from NSI  (we were connected to NSI at the time).  Even then the
information was usually of marginal, at best, relevance (some US
institution was going to lose connectivity via NSI for 5 minutes
at XXX).

These days this stuff still comes - it is of no relevance at all
(well, I guess that knowing that some site is expected to be
unavailable may be slightly relevant, but knowing only about NSI
sites doesn't help).   Consequently trouble(_at_)munnari(_dot_)oz(_dot_)au is 
now
exactly the same as /dev/null(_at_)munnari(_dot_)oz(_dot_)au (if that would 
work).

Does this mean the address is supported?   (Were it one of the
addresses required later in the draft).

    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(_at_)VIX(_dot_)COM> and 
<USENET(_at_)DATA(_dot_)RAMONA(_dot_)VIX(_dot_)COM>, even though these addresses
    might be delivered to different final destinations.

I think requiring the addresses to the full path is more than
you can require.   DATA.RAMONA.VIX.COM may not accept mail at
all, no matter what address you give.

This is the problem that has been faced when trying to figure out
just where "postmaster" is supposed to be valid.   So far the only
good answer to that seems to be "I know it when I see it", but
that is kind of hard to write down.   None of the proposed
statements have ever seemed quite right.

For postmaster, the aim is generally "all things that accept mail"
though there is no way a priori to determine what those are.

Here though you're going further...

    For example, if an Internet service provider's domain name is
    COMPANY.COM, then the <ABUSE(_at_)COMPANY(_dot_)COM> address must be valid
    and supported,

Last I heard there was no requirement that anything @company.com
must be valid and supported.   company.com may have, in the DNS
only SOA and NS records, no A, no MX.   Are you now going to
require that all "organisation" level domains have MX records?

    Most organizations do not need the full set of standard addresses, since 
not every organization
    will implement the services associated with all the standard addresses. If 
a given service is offerred,
    then the associated standard address(es) must be supported, resulting in 
delivery to a recipient
    associated with the references service or role.

This makes little sense.   Either the addresses are required (as
in tghe above quote), or they're hints, or they're useless.   For
any particular address you can't have it both ways.   What if
company.com (above) decides that it doesn't implement abuse?
(None of its people will ever abuse anyone ...)

    HOSTMASTER   DNS                  [RFC1033-RFC1035] 
    NIC          DNS                  Synonym for HOSTMASTER

The synonym is silly.   You already say that aliases are OK.
The only point of a doc like this is to tell people what they
can expect to work.   One address to be able to expect to work
is OK.

(Same for webmaster & www).

    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 ``::''),

Why?   The DNS can cope.   822 & 821 can cope.  Why the restriction?
(on the other hand advising that simple names are easier to use
and get right may be a good idea).

    it is hereby recommended that the well known address
    HOSTMASTER always be used.

Then why bother with the address in the SOA.rname ?  That's a
place where it is possible to specify an address for people to
use, and for the people to be able to find out what it is.
When zone admins (hostmasters) actually bother putting a working
address in there it works just fine as it is.

As above, there's no guarantee that <address>@zone-name works
for any address - which means that often the e-mail addresses
for many zones are all at the same host (domain part).   But
it is by no means certain that all zones will be maintained by
the same people - so just one address "hostmaster" for this is
wrong.

Leave SOA records as they are, they work just fine now (or would
if implemented properly, but that is a totally different problem).

I'm afraid that I don't understand the bit about the AS* mailboxes
well enough to comment.   Elsewhere you seem to be requiring systems
to implement a bunch of mailboxes they didn't have before.  OK,
thats' what standards are all about.   But the AS paragraph seems
to just say "this address might or might not exist, suck it and see".

It seems out of context - but maybe I misunderstood.

kre