Discusses: 1. One home directory, several machine architectures 2. Procmail as an integrated local mail delivery agent 2a.Special directions for sites with sendmail 2b.Special directions for sites with ZMailer 2c.Special directions for sites with smail 2d.Special directions for sites with SysV /etc/mail/mailsurr 3. Changing the mail spool directory to $HOME for all users 4. Security considerations (when installing procmail suid root) --- 1. One home directory, several machine architectures ------------------------------------------------- For users that have the very same home directory on machines with differing architectures (i.e. you need different executables), and they have to explicitly use (i.e. the system administrator did not arrange, for example, /usr/local/bin/procmail to have exactly the right contents depending on from which machine it is called) two executables of procmail, I have the following suggestion to use as a .forward file (examples are for sparc and sun3 architectures): "|IFS=' ';if /usr/bin/sparc;then exec /home/berg/bin.sun4/procmail;else exec /home/berg/bin.sun3/procmail;fi ||exit 75 #YOUR_USERNAME" or alternatively: "|IFS=' ' && export IFS && exec /home/berg/bin.`/usr/bin/arch`/procmail || exit 75 #YOUR_USERNAME" Please note, in the .forward file there can NOT be any newlines between the doublequotes, i.e. the former example *has* to be typed in as one long line. If, on the other hand, you have to log in to every machine to read mail arrived for you on that machine, a different solution might be more appropriate. If you have sendmail v6.xx and later, you simply create two .forward files. In the .forward file you put: YOUR_LOGIN_NAME@your.favourite.machine And, in a second file named .forward.your.favourite.machine you put: "|exec /usr/local/bin/procmail #YOUR_USERNAME" If you have an older sendmail, you could put something like the following two lines in your .forward file: YOUR_LOGIN_NAME@your.favourite.machine "|IFS=' ';test .`/bin/uname -n` != .your.favourite.machine || exec /usr/local/bin/procmail #YOUR_USERNAME" The leading dots are important. Check what `/bin/uname -n` returns on your.favourite.machine, and substitute that for your.favourite.machine in the sample .forward file. If your system does not have /bin/uname, check if there is a /bin/hostname. With some sendmails, the last suggestion causes you to get a superfluous copy in the system mailfolder. If that is the case, you'll have to change your .forward to something like: "|IFS=' ';if test .`/bin/uname -n` = .your.favourite.machine ; then exec /usr/local/bin/procmail; else exec /usr/lib/sendmail -oi YOUR_LOGIN_NAME@your.favourite.machine; fi" --- 2. Procmail as an integrated local mail delivery agent --------------------------------------------------- Completely integrating procmail in the mail delivery means that mail is delivered as normal, unless a .procmailrc file is present in the home directory of the recipient. This will be completely independent of the fact if a .forward file is present. This will not break anything, it just makes the use of procmail easier because people are not required to start up procmail from within their .forward files. Creation of a .procmailrc file will suffice. N.B. If you *are* installing it as the local delivery agent, and users on your system have dormant .procmailrc files without corresponding .forward file. Then, after the installation, these dormant .procmailrc files will be automagically activated/used (so you might want to rename any dormant .procmailrc files out of the way and notify the users; do be careful, since some users might invoke procmail through other means (cron or login) and might be surprised if it stops working). The generic way to accomplish this (works with sendmail, smail and any other mail system that uses a local mail delivery program that takes the mail- to-be-delivered on stdin and the recipient(s) on the command line, with or without the "-d" option) is this: Move your current local mail delivery agent (e.g. /bin/mail, /bin/lmail, /usr/lib/mail/mail.local, etc.) out of the way, and create a (symbolic or hard) link from there to procmail, as in "ln /usr/local/bin/procmail /bin/lmail". Beware, however, that if you are using this method, /bin/mail can *only* be used to deliver mail. On many systems /bin/mail has several uses (also to read mail or check for mail). So, it would definitely be preferred if you could edit the invocation of /bin/mail from within your mail transport agent to invoke procmail instead (with appropriate flags, if needed). Special directions detailing this process for some of the more popular MTAs are included in subsections below. In addition to needing root privileges upon startup, on some systems procmail needs to be sgid to daemon or mail. One way to check is by looking at the current mail delivery agent (usually /bin/mail) and to mimic its permissions, owner and group. If you're not quite sure, just type "make recommend" and some suitable recommendations will be made for your particular environment. The same might apply to the "lockfile" program, in order for it to be able to create and unlink lockfiles in the mail spool directory it might need to be sgid to daemon or mail, not to worry however, "lockfile" will not enable users to abuse the sgid/suid-ness. --- 2a.Special directions for sites with sendmail ------------------------------------------ The following lines should take the place of the standard Mlocal definition in your sendmail.cf (as for the fields "S=10, R=20": if your system uses others or none on the current Mlocal definition, use those *instead* of "S=10, R=20"): If you're using a sendmail 8.6.x or older: Mlocal, P=/usr/local/bin/procmail, F=lsSDFMhPfn, S=10, R=20, A=procmail -Y -a $h -d $u If you're using sendmail 8.7 or newer: In your *.mc file, insert FEATURE(local_procmail) or edit the sendmail.cf file and change the Mlocal definition to match: Mlocal, P=/usr/bin/procmail, F=SAw5:|/@glDFMPhsfn, S=10/30, R=20/40, T=DNS/RFC822/X-Unix, A=procmail -Y -a $h -d $u In case you were wondering why there is no 'm' flag on this definition, you can add it if you want, but I recommend omitting it (it would enhance performance very slightly, however, if one of the multiple recipients causes mail to bounce, it will bounce for all recipients (since there is only one exitcode)). To impose a 2MB limit on mails, you could add a `Maxsize=' field like in: Mlocal, P=/usr/local/bin/procmail, F=lsSDFMhPfn, S=10, R=20, M=2000000, A=procmail -Y -a $h -d $u In order to take advantage of the optional meta argument that can be passed to procmail you'd have to change the sendmail.cf file to add a $#local mailer rule to set the $@ host name (which will be substituted for $h in the mailer definition). There is nothing forcing you to do this, but if you do, you'll gain functionality. If you are using sendmail 8.7.* or newer, and are using the standard FEATURE(local_procmail), then the support for this meta argument is already present. For example: Make sure that the definition of operators in the sendmail.cf file includes the + sign (simply tack a + to the end of the "Do" definition, unless it already contains one). Now look for ruleset zero (S0), skip to the end of it. There usually is a rule there that takes care of local delivery, something like: R$+ $#local $:$1 local names Don't change that rule, leave it there. But, right BEFORE this rule, create a new one similar to: R$++$* $#local $@$2 $:$1 local argument Depending on the actual contents of your sendmail.cf file, there still might be some other $#local rule(s) you need to precede with a corresponding +-handling rule, e.g. in some files you also find: R$+ < $+ @ $+ > $#local $: $1 Preceed that with: R$+ + $* < $+ @ $+ > $#local $@ $2 $: $1 (The spaces are not significant, the tabs are!) Now, if someone sends mail to fred+pizza@your.domain, procmail will be called to deliver the mail as: procmail -a pizza -d fred In the .procmailrc file, you can now do an assignment like: ARGUMENT=$1 which will expand to ARGUMENT=pizza. N.B. that if you do *not* have sendmail v6.* or older, or IDA-sendmail, and would like to make use of the meta-argument, you'll have to drop the 'l' flag on the Mlocal definition and make sure that *every* $#local invocation carries a (possibly empty) $@ host definition. Since you are editing the sendmail.cf file now anyway, you might as well setup an extra `procmail' mailer. This Mprocmail can then be used as a general mail filter. For more information, see the EXAMPLES section the procmail(1) man page. N.B. Do NOT create the extra rules mentioned in the EXAMPLES section of the procmail(1) man page, unless you already have an application demanding those. Only create the completely optional Mprocmail mailer. After having edited the sendmail.cf file you'll have to kill (terminate) the running sendmail daemon. Then restart it. It will *not* suffice to send sendmail a SIGHUP (unless you are running sendmail 8.7.* or newer and started it with an absolute path). --- 2b.Special directions for sites with ZMailer ----------------------------------------- The following line should be inserted into (or take the place of any previous local definition in) your sm.conf file for the Transport Agent: local sSPfn /usr/local/bin/procmail procmail -a $h -d $u --- 2c.Special directions for sites with smail --------------------------------------- For smail 2.x users there are two options: i. Move the current local-mail-delivery program (probably /bin/lmail) out of the way, make a symbolic or hard link from procmail to the name of that program (e.g. "ln /usr/local/bin/procmail /bin/lmail") ii.Make sure the following macro is defined in src/defs.h: #define LMAIL(frm,sys) "/usr/local/bin/procmail -d" For smail 3.x users there are also two options: i. The same solution as for smail 2.x (however, method ii is preferred) ii.Replace any existing "local"-entry in the /usr/lib/smail/transports file (create one, if need be) with the following two lines: local: return_path, local, from, driver=pipe; user=root, cmd="/usr/local/bin/procmail -d $($user$)" --- 2d.Special directions for sites with SysV /etc/mail/mailsurr --------------------------------------------------------- Some systems use a SysV /bin/mail that supports mailsurr. To interface procmail with mailsurr the following two lines should be inserted in the /etc/mail/mailsurr file (preferably at the bottom): '(.+)' '([^@!]+)' '