| Current Path : /proc/2/root/usr/share/doc/procmail-3.22/examples/ |
| Current File : //proc/2/root/usr/share/doc/procmail-3.22/examples/advanced |
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)
NOTE: This file refers to the procmail binary being located in
/usr/bin. Some systems may place procmail in other locations such as
/usr/local/bin. Talk with your sysadmin if you are not sure.
---
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/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/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/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/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/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/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/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/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/bin/procmail /bin/lmail")
ii.Make sure the following macro is defined in src/defs.h:
#define LMAIL(frm,sys) "/usr/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/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/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 /var/spool/mail or /var/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 /var/mail partition.
The quota limitations also apply to /var/spool/mail or /var/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 /var/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.
---
Copyright 2K16 - 2K18 Indonesian Hacker Rulez
;?>)