Discusses:
		1. Getting the lot to compile
		2. IMPORTANT info for people with remote filesystems (like NFS)
		3. DEBUGGING AID
		4. Setting up the environment
		5. Extra options if you are a system administrator

				---

1. Getting the lot to compile
   --------------------------

To install procmail, lockfile and formail: edit Makefile & config.h accordingly
and type 'make install'.
Intended configurable options in Makefile are:
	the install-destinations (primarily BASENAME) and the
	LOCKINGTEST directories (you can optionally use something like
	'make BASENAME=$HOME install' instead).
Intended configurable options in config.h are:
	MMDF support, standard environment presettings including PATH,
	trusted userids, whether each user has their own group.

If an older version of procmail is currently installed, you should
review all the entries in the HISTORY file between that revision and
this one.

'make install' will:
      - implicitly do a 'make init', which will check your basic utilities for
	POSIX compliance, and generates correcting Makefiles accordingly
      - execute autoconf (a shell script that repeatedly calls the C compiler
	to determine if certain features/symbols are supported), which will
	create a file named autoconf.h
      - create three stripped binaries, a shell script and five man pages in
	the new/ subdirectory (all that is needed to install):
	procmail, lockfile, formail, mailstat, procmail.1, lockfile.1,
	formail.1, procmailrc.5, procmailsc.5, procmailex.5
      - copy these binaries and mailstat to $(BINDIR)
      - copy the man pages to $(MAN1DIR) and $(MAN5DIR)
      - BEWARE: the installation obeys the current umask setting.  If you
	want the files to be available to anyone, correct your umask first.

'make deinstall' will:
      - remove the just installed files in $(BINDIR)
      - remove the just installed files in $(MAN1DIR) and $(MAN5DIR)


Minimal requirements (for regular uses):

procmail must be installed.

Optional files (depending on your requirements):

lockfile only needs to be installed if you plan to read several mailboxes
	with one of the standard mailers that doesn't support lockfiles.
formail only needs to be installed if mail sometimes arrives in nonstandard
	mailbox format (or if you want to generate auto replies, split up
	mailboxes/digests etc., see the man page of formail for more info).
mailstat is an "example" shell script that can be used as is to produce
	summaries of the procmail generated logfiles; it is not needed by
	procmail itself in any way.

procmail, lockfile, formail and mailstat are all *standalone* programs, i.e.
they do *not* use any compiled-in paths or files that need to be there, they
all can be used and installed independently without the need to install the
others.

If things don't compile automagically, I suggest you take a look at:
src/autoconf, autoconf.h, config.h, src/includes.h

For autoconf to work as intended, your compiler should either be fully ANSI
compliant, or you should NOT turn off all warnings; enabling all warnings
shouldn't hurt.	 In most cases the default options in the Makefile will do.

The sources are supposed to be fully ANSI, K&R and POSIX compliant.

N.B. If you encounter any difficulty at all in installing procmail (e.g. if you
     had to change Makefile or config.h in unpredicted ways, or a simple
     "make install" doesn't work), I'd very much like to hear about it; who
     knows, next time you might be able to simply "make install" as well.

				---

2. IMPORTANT info for people with remote filesystems (like NFS)
   ------------------------------------------------------------

The autoconf script tries to determine what kernel locking functions are
available *and* reliable on your system.  In order to do this it exercises
all the available locking methods (fcntl(), lockf() and flock()) on some
sample files extensively.

These tests produce results which depend on the filesystem which is
being used to perform the tests.  If you haven't changed the definition
of LOCKINGTEST in the Makefile (you can include as many directories as
you want) autoconf will prompt you to enter any additional directories
(preferably on distinct filesystems) you want it to run the tests on.

When specifying directories to test, it would probably be advisable to
pick exactly those directories which belong to a unique fileserver-fileclient
pair.  I.e. one local file system will suffice.	 Only if you have remote
filesystems, you might have to specify several.
This makes sure that the locking tests will properly reflect the (lowest common
denominator) locking capabilities on all filesystems available.

If you have a very heterogenous environment (like several OS versions
on machines (perhaps even from different vendors) that have NFS mounted file
systems all over each other), then it could happen that some tests which
are reliable with one remote filesystem, turn out to be unreliable across
another (it all depends on the OS versions of clients and servers).

If do not want to perform the locking tests on all those filesystems, but
if you know what locking methods are unreliable anyway, then you can edit
some defines in the config.h file (NO_fcntl_LOCK, NO_lockf_LOCK and
NO_flock_LOCK).	 These can be uncommented by hand to prevent procmail
from using them.

The most typical case would be if you happen to be using NFS.  Autoconf
normally is very well capable of finding out if your lockd is reliable enough.
In a very heterogenous environment (many different servers, many different
lockd's (of perhaps different version and patchlevel)) however, it might
be hard to determine if all the lockd's are equally reliable.  In such a
case (typically on SunOS :-), you might consider uncommenting both
NO_fcntl_LOCK and NO_lockf_LOCK (NO_flock_LOCK normally doesn't rely on the
infamous lockd, so you can leave it commented out).  But, only do so if you
think you know it better than autoconf.

				---

3. DEBUGGING AID
   -------------

Since procmail is intended to run completely independent of any terminals, you
will typically have difficulties seeing it display error messages on the stderr
output.	 It is recommended, especially during debugging, to specify a LOGFILE
(see the procmailrc(5) man page) in the rcfile or on the command line.
Procmail will log all serious problems it encounters.  Of course, instead of a
regular file, one could also specify a terminal as the default logfile.

Also, procmail can be persuaded to be a lot more verbose by inserting the
following assignment at the top of your rcfile:

	VERBOSE=on

Therefore a suggested command line for your first trial run (no rcfiles
needed) would be:

	procmail VERBOSE=on

(now type in a pseudo mail-message)

If all else fails, you can try uncommenting the "#define console" entry
in the config.h file.  This will provide you with the most verbose procmail
you can make.  It is of course a good idea to comment out this line again
after your troubles have been solved.

If you run procmail by hand and pipe in some sample mail, then make
sure that if you kill procmail, you use "kill pid" and NOT "kill -9 pid".
Should procmail seem to hang, check if any lockfiles are still present.
If you kill procmail with "kill pid" it will clean up any lockfiles it created
itself.

				---

4. Setting up the environment
   --------------------------

Every user that wants to use procmail should have a .forward and a
.procmailrc file in his HOME directory.	 For starters, you can look
at the supplied example files in "examples" or the NOTES section in
the procmail(1) man page.
BTW, be sure to make .forward *world* readable.
MMDF users should note that they need a .maildelivery file *instead* of the
.forward file (see the procmail(1) man page for more information).

				---

5. Extra options if you are a system administrator
   -----------------------------------------------

If you are a system administrator you can decide to install procmail
globally (i.e. as a more robust drop-in replacement for the local-
maildelivery-capabilities of /bin/mail, this also gets rid of the known
security holes in some /bin/mails), this has the advantage that users do
not need to have a .forward file anymore that calls up procmail.  Simply
having a .procmailrc file in the HOME directory will suffice.  Operation is
transparent in this case (i.e. if no .procmailrc file is present in the HOME
directory, mail will be delivered as usual and procmail behaves like a faster
and more reliable /bin/mail substitute).

For direct examples on how to do this, look at the examples/advanced file.

*******************************************************************************
HIGHLY RECOMMENDED: install "procmail" suid root (and/or sgid maildaemon)
		    install "lockfile" sgid maildaemon

To obtain specific instructions on the best installation, type "make recommend"
*******************************************************************************

				---

For more info about the program, see the man pages or the FAQ list.
