Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!sdd.hp.com!news.cs.indiana.edu!ux1.cso.uiuc.edu!mp.cs.niu.edu!rickert From: rickert@mp.cs.niu.edu (Neil Rickert) Newsgroups: comp.mail.sendmail Subject: Re: HELP! Sendmail addressing on a local net Message-ID: <1990Dec13.002414.20784@mp.cs.niu.edu> Date: 13 Dec 90 00:24:14 GMT References: <1990Dec12.214505.25144@dirtydog.ima.isc.com> Organization: Northern Illinois University Lines: 89 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 . 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 Northern Illinois Univ. DeKalb, IL 60115. +1-815-753-6940