Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!emory!utkcs2!betelgeuse!moore From: moore@betelgeuse.cs.utk.edu (Keith Moore) Newsgroups: comp.mail.sendmail Subject: Re: Help with remote-mounted spool directory Message-ID: <1990Sep21.110535.11480@cs.utk.edu> Date: 21 Sep 90 11:05:35 GMT References: <9566@ur-cc.UUCP> Sender: news@cs.utk.edu (USENET News System) Reply-To: moore@cs.utk.edu (Keith Moore) Organization: CS Dept -- University of TN, Knoxville Lines: 208 In article <9566@ur-cc.UUCP> Mark Sirota writes: >I realize that this is discussed all the time, but I've never paid attention >before because it was never an issue for me... But now I want to start >remote-mounting /usr/spool/mail for a cluster of diskless Sun workstations >currently running SunOS 4.0.3. Good idea. >Currently I use my own sendmail.cf, which is exactly the same for all >machines on our network. It does all delivery itself, rather than >forwarding on to a central mailhost. Now, for this new setup, I'm going to >want all local delivery to be done by the server, so that multiple machines >don't all go writing into the same file at the same time, right? Right. >I'm told I need to use the 'R' option for this. The manual is pretty >useless on this, it says "Remote mode. Deliver through remote SMTP server. >Default is location of /var/spool/mail." > >What does this *really* do? (I don't have sources.) Can I just add this >option with the name of the fileserver, or do I need to completely rework my >sendmail.cf to forward all local mail on to the server? If you were running a network of all Suns, with essentially unmodified Sun-supplied sendmail config files, and had everything set up the way they expect -- mail forwarding done by the aliases YP map, etc., then you would probably do well to just enable the R option and let it go at that. But if you are maintaining your own config files, you might well prefer to do without the R option, precisely because it's poorly documented and will frustrate you. You might not want it anyway, because it bypasses all of the output channel processing (like mailer-specific rewrite rules). Basically, it's an ugly hack. At any rate, it's not necessary -- you can do this without lots of changes to your existing config file. An added win is that this will work with other than Sun machines. Here's one way to do it: (based on diffs between my standalone config file and my client config file) MODS TO MAIL CLIENT'S CONFIG FILE: 1. Define a macro that evaluates to the domain name of your mail server, and another macro that evaluates to the domain name of your mail cluster. The first one is an actual machine name (i.e. it must have an IP address and a name server A record); the second is the name of your domain (it may have an A record or one or more MX records). The two may be the same if that's the way you have it set up. # NFS mail server (where /{usr,var}/spool/mail is mounted) DSmail-server.cs.utk.edu # mail cluster domain (common mail domain for all machines) DRcs.utk.edu 2. Typically, somewhere usually in ruleset 3 or ruleset 0, a config file has code recognize "local" domains and strip off the domain part. It might look something like this: R$*<@$j>$* $1<@>$2 strip off local domain Add a line here to recognize the "cluster" domain also, since they will end up at the same place. R$*<@$R>$* $1<@>$2 strip off cluster domain 3. Now, change whatever code calls the "local" mailer to instead call a different mailer. I use the name "server". The name "local" has some special connotations to sendmail -- it does alias expansion on names sent to this mailer (via /etc/aliases or the YP map), processes .forward files, recognizes special kinds of addresses (those starting with "/" or "|" or ":include:"), handles errors differently (many "permanent" errors to the local mailer are treated as temporary), looks up the user's full name, saves failed mail in dead.letter, and bounces mail if the user's name isn't in /etc/passwd or the YP passwd database. (Mostly because it fails trying to look at the user's .forward file -- else it would just let the delivery program return the error). Whew! Anyway, most of this processing is undesirable: you don't want aliasing or forwarding to take place because of all of the additional failure modes that crop up -- e.g. sendmail often doesn't handle either YP or NFS server failures correctly. Also, think about the case where you have a heterogeneous network and a user has his .forward file piping mail to a program in his/her private bin directory, which is compiled for a particular architecture...but if you only do this processing on the mail server, behavior is more predictable. Enough on why you shouldn't use the "local" mailer. BTW, you still need to have a mailer named "local", even though it will never be used. The last line in my ruleset zero looks like this: R$+ $# server $@ $S $: $1 4. I defined the "server" mailer as follows: Mserver, P=[IPC], F=AmnDMuXI, S=10, R=10, A=IPC $h, E=\r\n S10 # if the message is from root at the local domain, leave it alone # (Actually class T is a list of "daemon" user names that send out # logging messages -- it is helpful to be able to tell at a glance # which machine is complaining about something.) R$=T@$j $@$1@$j # if message from someone else is from local domain, change it to # the cluster domain R$*@$j $@$1@$R # otherwise, if it contains an '@' it's already fully qualified. R$*@$* $@$1@$2 # handle simple names (without '@') here # if from root, append our local domain name (not cluster name) R$=T $@$1@$j # otherwise, append cluster domain R$* $@$1@$R S20 # if it contains '@' assume it's already qualified R$*@$* $@$1@$2 # if it's to root, append local domain (not cluster) R$=T $@$1@$j # otherwise append cluster domain R$* $@$1@$R The main idea of the rewrite rules is to encourage everyone to send all mail to the domain associated with the "cluster", not of any individual machine. Otherwise you'll have to deal with the problem of how to handle mail to a machine whose name no longer exists. So while we *accept* mail for user@specific.machine, we rewrite outgoing mail as from user@cluster.domain, and the same is true for recipient addresses in message headers. Then replies will naturally be sent to the cluster domain, and people will get used to the idea that that's where your users get mail. On the other hand, if "root" on some machine sends a message to the sysadmin complaining about something that happened last night during a cron job, it's useful if the From: header tells you what machine it happened on. So we don't do this kind of processing for users like "root", "daemon", and "uucp". The "server" mailer desription doesn't have the 'F' flag set, and therefore will not generate a From: header if one was not supplied by the user agent. Fear not -- the mail server's sendmail will add one, and since it will recognize the mail as from a local user, it will do the passwd lookup and insert the user's full name. This produces headers like "From: Keith Moore " instead of "From: moore@cs.utk.edu". Many user agents do supply from headers, in which case the setting of the 'F' flag is irrelevant. I also left off the 'p' flag, because I want the envelope from address to be and not <@client.machine:moore@some.domain> I used to just send bare usernames to the "server" mailer, rather than qualifying them on the client (I think the Sun sendmail 'R' option does this), but it turned out to be easier to get everything right when the client machine presents a fully-qualified address to the server. 5. I added similar code to rewrite local user names in the tcp mailer's rewrite rules (also in the mail client's config file). MODS TO THE MAIL SERVER'S CONFIG FILE: 6. Now, the server needs some way to recognize all incoming mail. At my site, all of our addresses are of the form something.cs.utk.edu, but not all possible something's are mail clients. So I have a list of the something's in a file called /etc/MAIL-CLIENTS, and I define a class using that file: Fw/etc/MAIL-CLIENTS 7. Ruleset zero of the server config file has code to recognize mail to clients and treat it accordingly, along with mail to the server machine itself, and mail to the cluster domain: R$*<@$=w.$D>$* $1<@>$2 recognize mail to client domain R$*<@$R> $1<@>$2 recognize mail to cluster domain R$*<@$j> $1<@>$2 recognize mail to us ... R$*<@> $@$>0$1 retry after stripping @domain R<@>:$* $@$>0$1 retry after stripping @domain ... R$*<@$*>$* $# tcp $@ $2 $:$1$3 mail to other domains R$+ $# local $: $1 mail to local mailboxes 8. The server's rewrite rules for outgoing mail also make sure to rewrite local addresses as being at the cluster domain, not that of the server machine's domain name. (In our case, they are the same) 9. If your mail server is also the NFS file server for all of your users' home directories, that's about all you need to do. Otherwise you need to mount the home directories via either amd or automount, and replace your local, prog, and file mailers on the server with programs that can cope with unavailable file systems and return an exit status of EX_TEMPFAIL. My local mailer is just a shell script that makes a few sanity checks before calling /bin/mail. In practice it works quite well, but I will probably write a C version for the sake of efficiency. I'll send the complete set of sendmail config files (client, server, and standalone) along with the local mailer script, if you want them. Beware: they aren't as well commented as this message. Good luck, Keith Moore Internet: moore@cs.utk.edu University of Tenn. CS Dept. BITNET: moore@utkvx 107 Ayres Hall, UT Campus Telephone: +1 615 974 0822 Knoxville Tennessee 37996-1301 ``Friends don't let friends use YP (or NIS)''