eli@ima.isc.com (Elias Israel) (12/13/90)
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_
rickert@mp.cs.niu.edu (Neil Rickert) (12/13/90)
In article <1990Dec12.214505.25144@dirtydog.ima.isc.com> eli@ima.isc.com writes: >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>. I am assuming that you have examined the obvious options of an NFS mounted mail spool directory which is shared over the complete network, or a YP network shared alias map. Assuming these won't work, there are some other options possible. The key to any reasonable approach is to have a machine address which is distinct from your global namespace address. Thus 'user@your.domain' might be the generic global namespace format, while 'user@machine.your.domain' would be specific to one machine, and always be recognized as local there. This use of distinct addresses will also turn out to be useful when someone has a login on two or more machines, and wants to send himself mail from one machine to the other as a simple file transfer mechanism for small files. With this approach you could make sure that 'user' is treated as if 'user@your.domain' and possibly sent off to your mail gateway, while 'user@machine.your.domain' is not modified and remains always on your machine (or is sent directly to another machine, depending on the machine explicitely named). >"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." >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 This is actually not a bad approach at all. What you need to do is make sure that local entries in your aliases file are fully qualified. For example, in your aliases file (or .forward) don't use: local-mailgroup: "|/some/command" Instead, use: local-mailgroup: "|/some/command"@machine.your.domain The same kind of full qualification can be used for mailing to files. That ensures that program and file mail will stay on your machine. If you pick up the IDA versions of sendmail you will find there are additional options available to you. You might want to look at the 'qi' network database that University of Illinois uses (check the ftp archives at uxc.cso.uiuc.edu). >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? > Sendmail was designed on the principle that the code cannot know everything about an address, so interpretation should be left up to the configuration file. If the '.cf' file selects the local mailer, then the code knows that special characters such as '|' have the appropriate local interpretation as a local address. After all someone may invent some forms of email addresses that look to the code like programs, but really are not. (Have you looked at those X.400 addresses which look remarkably similar to Unix file names). -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115. +1-815-753-6940
fwp1@CC.MsState.Edu (Frank Peters) (12/13/90)
To:
In article <1990Dec12.214505.25144@dirtydog.ima.isc.com> eli@ima.isc.com (Elias Israel) writes:
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>.
Hmmm..have you considered sharing your mail spool file across
machines? We have done so almost since day one of our connection to
the internet and have experienced no problems that weren't
attributable to systems manager error.
Here is how we have mail arranged here. We have a single system
designated as our mail hub. All of the other machines are mail
clients.
The clients have a sendmail.cf file that basically passes everything
on to the central mail server (even mail that would normally be local
like a message from user 'joe' to user 'sally'). If you don't want to
share your mail spool you can have the machine deliver everything
except mail with the fully qualified local host name to the server.
Mail is passed to the server with the address exactly as it appeared
locally (for example mail from joe to sally is given to the server
with a source of joe and a destination of sally...no local host name
is appended. This has two effects. First, the cf file is trivially
simple and requires no maintenance for new address formats (since
those are interpreted by the server) and the server can see mail with
two 'local' addresses and treat them as if they were sent locally.
Now, you have arranged for all of your mail to be sent to a single
machine. This machine has a full blown cf file and delivers non-local
mail to its ultimate destination. And the address in the From: header
and such is <userid@server.host.name> for EVERYONE no matter which
local host the mail originated. And of course you can do things like
hide the host name and just use the domain portion.
In our case local mail is then delivered locally in the usual way and
all hosts see it via NFS. If you don't elect to do this you would
have a single aliases file on the server that has the fully qualified
hostname of the actual 'home machine' for the recipient. The client
then deliveres mail with its full domain name locally.
This all sounds much more complicated than it is. The clients all
have an identical sendmail.cf file (except for the definition of the
local host name). And the server's sendmail.cf file is full featured
but otherwise nothing particularly special. All mail for local users
can be sent to a single hostname and is passed out from there and
(very important IMHO) the address put in all outgoing mail is the one
you want to have (so that the reply key on the other end is useful).
If you would like a more detailed explanation of our mail system
please feel free to let me know. I'll be glad to discuss it with you,
give some sendmail.cf file examples and such.
Oh, by the way. Sun sendmail has an option that can be used to have
the client forward mail to the mail server. Avoid using this. I
never got it to really work right (and have heard many others with the
same complaint). Doing it in the rewriting rules is much neater and
more portable.
Regards,
FWP
--
--
Frank Peters Internet: fwp1@CC.MsState.Edu Bitnet: FWP1@MsState
Phone: (601)325-2942 FAX: (601)325-8921