Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!think.com!mintaka!spdcc!ima!dirtydog!ima.isc.com!eli
From: eli@ima.isc.com (Elias Israel)
Newsgroups: comp.mail.sendmail
Subject: HELP! Sendmail addressing on a local net
Message-ID: <1990Dec12.214505.25144@dirtydog.ima.isc.com>
Date: 12 Dec 90 21:45:05 GMT
Sender: news@dirtydog.ima.isc.com (NEWS ADMIN)
Reply-To: eli@ima.isc.com
Organization: Interactive Systems, Cambridge, MA 02138
Lines: 89

Here's a puzzler that should be a little more interesting than the
run-of-the-mill sendmail questions:

You see, we used to have a big ol' mainframe on which everyone read
their mail. Over the last year or so, we've migrated mail slowly to a
more workstation-based model where everyone reads their mail on a
separate machine. Whereas on the old system we could just send mail to
any old user and trust that it would get into their mail box properly,
we can't do that anymore. We'd like to continue to have this sort of
"mainframe" name space, where you can just use a local user's login id
and know that the mail will get to their mailbox without having to
know where that mailbox might be. To support that behavior now, we're
faced with either replicating the /usr/lib/aliases file on every
machine or having to remember to say <user@our-domain>.

Replicating the alias file is undesirable because maintenance is a
pain and the To: lines in mail sent this way use the address
<user@source-machine> instead of <user@destination-machine>. (If I
send mail for user "fred" on my machine "alpha" and fred's alias has
sendmail send it to machine "beta", the To: line on the final mail
will say "To: fred@alpha", when we'd really like it to say
"To: fred@beta", or better "To: fred@our-domain")

Remembering to use <user@our-domain> is doable (heck, it's what we're
doing now) but it's not exactly optimal. Some of our users keep the
whole mess in their personal alias files, but that's just another case
of replicating the master alias files in miniature.

"No problem," I said to myself a couple of days ago. "I'll just make a
new class in my sendmail.cf that contains all of the names of users
who get mail on the local machine (this list would be nice and small
and local and easy to maintain) and test all single-token addresses
against it in the end of ruleset 0. Those addresses that don't fall
into the class I'll resolve to the tcpld mailer and send them to our
local Internet mail gateway machine which maintains the master alias
file."

I define the class like this:
 
	# class of all people who get mail ON THIS MACHINE
	FL/usr/lib/sm-localusers

At the end of ruleset 0, I use this class by putting this rule just
before the rule that resolves remaining names to be local.

	R$~L		$#tcpld$@$D$:$1<@$D>

This rule says: If the address consists of a single token that does
not fall into the 'L' class, resolve to the local SMTP mailer, using
our domain ($D) as the host and setting the address as user<@our-domain>.

This new class and the new rule go into every sendmail.cf on every
machine (except for the gateway machine).

Well, that works OK, except that there are single tokens that get
parsed by the sendmail rules that aren't addresses. Specifically, when
I get a token that looks like this "|/some/command" my rule doesn't
work. It tries looking for  "|/some/command" in the 'L' class, fails
and tries to send the mail to our master mailer with the address
"|/some/command"<@our-domain>.

Bogus.

I have poked around, but I can't find a way to write a rule that can
tell the difference between a real user name (i.e. a valid address)
and a single token that is just a prog (i.e. a bogus address).

Is it possible to tell them apart or are rules basically unable to
make this distinction?

If rules are unable to tell these two apart, why does sendmail try to
parse these things in the first place? If you can't tell them apart,
the rules must always return exactly what they were passed. If this is
the case, why not just recognize progs and not try to parse them, but
simply send them directly to the prog mailer?

Is there any way to do this that doesn't involve a shared database of
some kind? I don't mind small *local* files that don't have to change
much, but the maintenance hassles of keeping lots of files in sync
over our entire network is just to much (rdist-ing /usr/lib/aliases is
right out).

Can anyone help?

Elias Israel		   | "Justice, n. A commodity which in more or
Interactive Systems Corp.  | less adulterated condition the State sells
Boston, MA		   | to the citizen as a reward for his allegiance,
eli@ima.isc.com  	   | taxes, and personal service."
eli@village.boston.ma.us   |     -- Ambrose Bierce, _The Devil's Dictionary_