Date: Mon, 11 Aug 1997 13:02:29 +0800 From: Peter Wemm <peter@spinner.dialix.com.au> To: Poul-Henning Kamp <phk@critter.dk.tfs.com> Cc: Bill Fenner <fenner@parc.xerox.com>, Wolfram Schneider <wosch@apfel.de>, "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com>, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, cvs-etc@FreeBSD.ORG Subject: Re: cvs commit: src/etc aliases Message-ID: <199708110502.NAA15054@spinner.dialix.com.au> In-Reply-To: Your message of "Sun, 10 Aug 1997 11:01:28 %2B0200." <1521.871203688@critter.dk.tfs.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Poul-Henning Kamp wrote:
> In message <97Aug10.014925pdt.177512@crevenia.parc.xerox.com>, Bill Fenner wr
it
> es:
> >Poul-Henning Kamp <phk@critter.dk.tfs.com> wrote:
> >>Yes, I'm still contemplating deleting that second part, it seems positively
> >>bogus to me...
> >
> >I'm confused - why are three of the aliases from RFC2142 good enough to
> >have by default, and the rest are too bogus to have in the file at all?
>
> Either they are there pointing to something, or they should be taken out
> lock stock or barrel. Comments will not do anyone any good...
RFC2146 (a standards track document) is very explicit. Here are some
sections of it:
[..] Most
organizations do not need to support the full set of mailbox names
defined here, since not every organization will implement the all of
the associated services. However, if a given service is offerred,
then the associated mailbox name(es) must be supported, resulting in
delivery to a recipient appropriate for the referenced service or
role.
The key there is: If you support the service, you MUST have the
corresponding aliases or mailboxes. Bouncing is not acceptable according
to the doc.
If a host is not configured to accept mail directly, but it
implements a service for which this specification defines a mailbox
name, that host must have an MX RR set (see [RFC974]) and the mail
exchangers specified by this RR set must recognize the referenced
host's domain name as "local" for the purpose of accepting mail bound
for the defined mailbox name. 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>, even though these addresses might be
delivered to different final destinations.
ie: If you have a web server that doesn't accept mail itself, mail to
your webserver's full address for the standard aliases MUST be accepted by
something.
For well known names that are not related to specific protocols, only
the organization's top level domain name are required to be valid.
For example, if an Internet service provider's domain name is
COMPANY.COM, then the <ABUSE@COMPANY.COM> address must be valid and
supported, even though the customers whose activity generates
complaints use hosts with more specific domain names like
SHELL1.COMPANY.COM. Note, however, that it is valid and encouraged
to support mailbox names for sub-domains, as appropriate.
Here, we don't HAVE to have abuse@everything working, but the document
encourages it.
Anyway, the service based list is:
MAILBOX SERVICE SPECIFICATIONS
----------- ---------------- ---------------------------
POSTMASTER SMTP [RFC821], [RFC822]
HOSTMASTER DNS [RFC1033-RFC1035]
USENET NNTP [RFC977]
NEWS NNTP Synonym for USENET
WEBMASTER HTTP [RFC 2068]
WWW HTTP Synonym for WEBMASTER
UUCP UUCP [RFC976]
FTP FTP [RFC959]
Of course, if someone wants to get clever and activate or deactivate the
aliases as a result of turning on or off named in /etc/rc.conf, it would
comply. Leaving them on by default also complies. Having them off by
default does not. What we do on some of our systems is have a standard
top-level aliases file with the individual aliases set to pipe into a
script which checks the per-host configuration to see who to forward it to
or whether to reject it with an error message and an EX_NOUSER exit code.
The other non-protocol based aliases (info, marketing, sales, support, noc,
abuse, security) are not partocularly host specific, but I am stronly in
favour of at least abuse and security being on each system by default.
Cheers,
-Peter
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708110502.NAA15054>