
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.

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:

Mlocal, P=/usr/local/bin/procmail, F=lsSDFMhPfn, S=10, R=20,
	A=procmail -a $h -d $u

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".

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 -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 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.

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

	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.

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.

				---

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):

'(.+)' '([^@!]+)' '<S=0;C=67,75;F=*;
	/usr/local/bin/procmail -f \\1 -d \\2'

				---

3. Changing the mail spool directory to $HOME for all users
   --------------------------------------------------------

There are many different reasons why more and more sites decide not to
store mail in /usr/spool/mail or /usr/mail anymore.
Some of the obvious advantages when storing mail in the recipient's home
directory are:
	- Mail is automatically subject to the user's quota limitations.
	- Often there is more room on the home partition(s) than on that
	  one /usr/mail partition.

The quota limitations also apply to /usr/spool/mail or /usr/mail if procmail
does the delivery.  These quota limitations often do not work with the
regular /bin/mail since that usually writes the mailbox with root permissions
(eluding the quota restrictions).

However, if you are going to install procmail as the integrated local
delivery agent, and you want mail to be delivered to, say, $HOME/.mail
by default, this is what you have to do:

	Edit the procmail*/config.h file.   Uncomment and possibly change
	the SYSTEM_MBOX define.	 Procmail now delivers there by default.

	In order to make sure that normal mailtools can find the new
	system mailboxes, you should make sure that every user has the
	MAIL environment variable set to be equal to whatever you
	defined SYSTEM_MBOX to be.  Some braindamaged mail programs
	do not pick up the MAIL environment variable, these either
	have to be patched/recompiled or you have to create symbolic
	links in /usr/mail to every person's new mailbox.

				---

4. Security considerations (when installing procmail suid root)
   -------------------------------------------------------------

If in EXPLICIT DELIVERY mode (typically when called from within sendmail)
procmail will ALWAYS change UID and gid to the RECIPIENT's defaults as soon as
it starts reading the recipient's $HOME/.procmailrc file.

If NOT in explicit delivery mode (typically when called from within the
recipient's $HOME/.forward file) procmail will ALWAYS change UID and gid to
the real uid and gid of the INVOKER (effectively losing any suid or sgid
privileges).

These two precautions should effectively eliminate any security holes because
procmail will always have the uid of the person whose commands it is executing.

To summarise, procmail will only behave better if made suid/sgid something, in
fact, making procmail suid/sgid something will *improve* security on systems
which have dynamically linked libraries.

				---
