From: davidf@golem.waterloo.on.ca (David J. Fiander)
Newsgroups: biz.sco.general
Subject: What "host hiding" means, and why you want to do it
Summary: big people do this
Keywords: MMDF, administrative domain, tutorial
Date: 18 Dec 92 23:01:50 GMT
Organization: None visible

I am running MMDF on my home machine (golem.waterloo.on.ca).  I
don't do host hiding.  We are running sendmail at work (which
shall remain nameless, for a variety of reason, not the least
is that we run sendmail).  There we do the equivalent of host
hiding.

Most universities don't hide hosts (or at least not much),
which is why one ends up with addresses like
<postmaster@a.cs.okstate.edu>, but most large companies do,
which is why my address used to be <david@sco.com>.

First some terminology:  an "administrative domain" is a
collection of machines within which all the user names are
guaranteed to be unique (I was the only "david" at SCO, but
there were plenty of "david*"s, and I often got mail for them).
Host hiding only works within an administrative domain[1] -- if
it is possible for different people to have the same user name,
then how do you know to which <david@sco.com> a message should
be delivered?

Hiding local hosts has two advantages:  it is easier to
remember user's addresses (if you really wanted to, you could
have sent mail to <david@dybbuk.scocan.sco.com>); and it gives
the "domain" flexibility in assigning computing resources.  If
every internal transfer involved changing your e-mail address,
it could get pretty expensive replacing your business cards,
and you'd spend more time informing all your business
correspondents of your new address than you would actually
working on the new project.

There are drawbacks to hiding local host names.  Using the MMDF
system, local host names never appear in messages, so when I
send mail to another person in the same domain, I just type

	$ mail johnm

As you can see, this looks like a local address, so MMDF will
want to deliver it to johnm's mailbox on my computer (dybbuk,
if you've been paying attention), unless I do something
special.  This is fine if John and I are both working on the
same machine, but if we're not (he lived on the machine troch),
then he might never know that I sent him mail.  Every machine
in an administrative domain has to known how to redirect mail
for all the users in the domain to the correct home machines.
This is commonly done by having an alias table which redirects
mail for all the users in the domain.  As you can imagine, this
file can get pretty hefty, especially for a company the size of
SCO.  At SCO Canada, we had an alias table for just our office,
and all the others were passed via the "badusers" channel to a
smarter machine which had the company-wide database.

Hiding host names only ensures that the mail headers that
"matter" only show the hidden name (sco.com as opposed to
dybbuk.scocan.sco.com).  The headers that matter are the From,
To, Cc, Reply-To, and Sender (there might be others, but these
are the biggies).  Headers that _don't_ matter, which commonly
contain the full local host name are Message-Id (which has to,
to ensure the uniqueness required by standards), Received
(which is used for tracking down network problems), and
Return-Path (which generally contains a complete path of the
machines through with the message passed).  So, if you see a
local host name in one of these, "Don't worry, have a homebrew"
(oops, wrong newsgroup), nothing uses them.

[1] Which is why universities don't often do it; each faculty
(or department) computing services department is commonly
responsible for assigning user names for the users of its
machines, and there is usually little coordination.  So,
technically, a university is commonly a collection of
administrative domains, all within the top level domain of the
university.
Newsgroups: biz.sco.general