If the configure script detects that the Courier
Authentication Library is installed, support for courier-authlib gets
automatically compiled. Use the --disable-authlib option to
manually disable courier-authlib support.
When courier-authlib support is enabled, the -d option to
maildrop will look up the account using the Courier Authentication
Library, making it possible to store mail account configuration in an
LDAP, MySQL, or a PostgreSQL database. See the courier-authlib
documentation for more information.
See http://www.courier-mta.org/authlib/ for more information.
NOTE:
When using the standalone maildrop build with courier-authlib, one of the following configurations must be used:
- Your mail server must invoke maildrop as the root user (the
-dflag reads the mail account's uid and gid, then drops root) .- Manually change the permissions on the maildrop binary to be setuid root.
- Manually change the permissions on the courier-authlib's socket directory (
/usr/local/var/spool/authdaemonby default) to be globally readable or executable.The default permissions on courier-authlib's socket directory blocks world-access to the filesystem socket connected to courier-authlib's authentication daemon process. In order for maildrop to connect to the authentication library, maildrop must either have root privileges (which will be temporary, as soon as maildrop determines the account's userid and groupid, it will drop root, before reading the
maildroprcfile), or courier-authlib's socket directory must have world read and execute permission.Note that if the permissions on the socket directory are changed, anyone on the system can connect and obtain any account's password!
It is the system administrator's responsibility to choose the appropriate security policy when using the Courier Authentication Library.
configure script:
./configure [options]
make
make install-strip
make install-man
If the make command stops with syntax error in any Makefile, you probably
have an older make utility. See if you have a gmake command
available. If so, rerun configure as follows:
./configure [options] MAKE=gmake
Then execute the remaining commands, replacing make with
gmake every time.
If make install-strip fails, try make
install.
The configure script creates Makefile, and
config.h. After running configure, you may want to edit
xconfig.h, and config.h in order to make minor
adjustments to the configuration.
Some versions of make may have problems handling the
Makefile. If your make gives you errors, try using the
gmake command instead - the GNU make.
NOTE: configure attempts to automatically configure the following options for maildrop according to your specific system. After running configure, you should review these options and make any necessary adjustments.
If you're upgrading, read UPGRADING below.
The following assumes that the default options are used. The usual GNU
toolchain options can be used to relocate files from their default locations
(run ./configure --help for more information).
/usr/local/bin - A number of binaries will be installed
here, starting with the main binary, maildrop, as well as
additional utilities: dotlock, maildirmake,
makemime, reformail, and
reformime. If certain options are selected, some additional
binaries may be installed here as well./usr/local/man - manual pages./usr/local/include - C header files, for development, if
the --with-devel option is specified to the
configure script./usr/local/lib - C libraries, for development, if the
--with-devel option is specified to the
configure script./usr/local/share/maildrop/html - HTML versions of manual
pages installed in /usr/local/man.These are the default directories. The defaults can be changed using the
standard autoconf options, run ./configure --help
for more information.
Read UPGRADE for some important notes. The default installation directory/layout has changed.
The --with-gdbm option has been renamed to --with-db. Its functionality remains the same. The name change is due to some internal housekeeping.
If possible, use a prebuilt package on platforms with a package manager (rpm on Red Hat and derived distributions, deb on Debian, etc). If you've been compiling and instaling maildrop manually, be aware of the following changes when upgrading from 0.65 or earlier.
maildrop results in an error message saying that libstdc++
cannot be opened.
Solaris's run time linker has a problem running C++ applications which
have the setuid or setgid bit set. On Solaris, libstdc++ (the runtime C++
library) is installed in /usr/local/lib. Solaris's runtime
linker will only open shared libraries in /usr/lib for programs
with the setuid or setgid bit set.
Maildrop is installed with the setuid and setgid bits set, so
that maildrop can change to the recipient's userid and group id.
There are three easy workarounds.
maildrop, maildrop
will not need the setuid and setgid privileges. After running make
install-strip, go ahead and manually turn these bits off for the
maildrop, dotlock, and
reformail./usr/lib/localto
/usr/local/lib, and add /usr/lib/local to the
LD_LIBRARY_PATH environment variable./usr/libto
/usr/local/libmaildrop on a
sendmail-based system should be aware of.
--enable-syslog=1 flag to configure on
systems running sendmail, unless you are very familiar with
maildrop. Without this flag, if you have any problems and
maildrop is not installed correctly, you will end up with a bunch of
deferred mail, and absolutely nothing to indicate why. Although
maildrop will report an error message, sendmail will discard
the message without recording it anywhere. With the
--enable-syslog=1 option enabled, you at least get to see
the error messages in your syslog. However, please note that syslog will
now show any fatal maildrop errors resulting from botched user recipe
files.maildrop's
default security level. The conflict arises in a situation where a local
user sends a message to another local user. It appears that at least some
versions of sendmail invoke maildrop with the userid set to
the sender, and the -d option specifying the recipient. The default
maildrop configuration allows only certain "trusted" users
to use the -d option. What will happen is that maildrop will
report an error, and return an exit code to sendmail indicating a
temporary error. The message will be deferred, and on the next queue run,
sendmail will attempt to re-deliver it. But now, sendmail will do a queue
run as root, and root is allowed to use the -d option, so the message is
delivered.Note that this applies ONLY if you have maildrop defined as
the local delivery agent in sendmail.cf. This will happen if
maildrop is invoked from a .forward file. There are
three possible solutions: do nothing, since no real harm is done, local mail
simply gets delivered with some delay; you can change the default queueing
method (in sendmail.cf) to queue messages; or, you can specify
--enable-restrict-trusted=0 option to configure,
and lift the restriction on the -d option. However, keep in mind that the
--enable-restrict-trusted=0 option allows a malicious user use
the -d option to mailbomb another local user's mailbox. This is why the
option is enabled by default. Of course, the same can also be accomplished by
funneling the mailbomb through sendmail, instead of running
maildrop directly. However, I can only tighten things up on my
end; I presume that throttling mechanisms are in place in sendmail to block
that avenue of attack.
If you're using AFS, it is possible that daemon processes will not even
have the read privileges on their effective userid's home directory. maildrop
likes to keep its temporary files in $HOME/.tmp, instead of
creating them in a shared public directory. You will need to specify the
--disable-tempdir flag when running configure, which configures maildrop to
use /tmp or /var/tmp for temporary file storage. (NOTE - this is already a
default option effective with maildrop 1.1)
--enable-DEBUG - specifying this parameter to configure
enables some debugging code. Used only by those who know how to use it.
:-)--without-db - do not compile support for GDBM or DB
databases. Because supporting GDBM/DB databases significantly increases
the size of maildrop, GDBM/DB support can be omitted. If you do
not have GDBM/DB libraries, configure automatically disables
GDBM/DB support. Specifying --without-db disables the
gdbmopen, gdbmclose, gdbmfetch,
and gdbmstore functions, and does not compile or install the
maildrop.makedat utility.--with-db=db - use the Berkeley DB library instead of
GDBM. This option will transparently use libdb.a instead of libgdbm.a.
The gdbmopen, gdbmclose,
gdbmfetch, and gdbmstore functions work exactly
the same, but they will use libdb instead of libgdbm.--with-etcdir=directory - use the specified
directory instead of /etc, which is where maildrop
expects to find some configuration files and directories.--enable-syslog=1 - if specified, maildrop will log all
fatal errors to syslog(3). This is recommended for sendmail, which does
not log error messages for delivery agents.--enable-maildrop-uid=root and
--enable-maildrop-gid=mail - sets the userid and the
groupid for the maildrop, maildirmake, and
dotlock programs. If not specified, they default to "root"
and "mail" respectively. See MAILBOX_MODE and
RESET_GID below for more information.--with-devel - install development libraries and include
files. This option causes make install to copy over and
install libraries, include files, and manual pages, that are used by
maildrop to parse and process E-mail messages.Some mail systems run the delivery agent without specifying the recipient on the command line. The user id is set by the mail system before running the mail delivery agent. In this case, root privileges are not required, and you may manually remove the set-user-id bit after installing maildrop.
Some mail systems may use group privileges in order to write to the system
mailbox directory. maildrop is installed with the set-group-id bit set
as well, and the mail group is assumed to be 'mail'. If a mail group other
than 'mail' is used, specify it via the --enable-maildrop-gid
option. You will also need to set the RESET_GID variable to 0 (see
below). If RESET_GID is left alone to its default value of 1, maildrop
will drop any acquired group ID right away, so its not necessary to remove
the setgid bit. maildrop attempts to detect if this is the case, but
you always need to confirm this.
--enable-sendmail=program - sets the initial value
for the SENDMAIL environment variable for maildrop recipes.
This is the pathname to the default mail delivery agent. If this option
is not specified, configure will try to find it itself.--enable-lockext-def=extension - sets the initial
value for the LOCKEXT environment variable in maildrop. This
is the filename extension of dotlock files. The default is ".lock".--enable-locksleep-def=seconds - sets the initial
value for the LOCKSLEEP environment variable. This is how
long maildrop waits before trying to create a dotlock file again,
if the dotlock file already exists. The default is 5 seconds.--enable-locktimeout-def=seconds - sets the initial
value for the LOCKTIMEOUT environment variable. This is how
long maildrop waits before removing a stale dotlock file. The
default is 60 seconds.--enable-lockrefresh-def=seconds- sets the initial
value for the LOCKREFRESH environment variable. This is how
often maildrop refreshes its own dotlock files, to keep them from
going stale. The default is 15 seconds.--enable-tempdir=directory - sets the name of a
subdirectory in each user's home directory where maildrop writes
temporary files. maildrop will create this directory, if missing.
The default is .tmp.--disable-tempdir - do not use a subdirectory, instead
create temporary files in a shared /tmp or /var/tmp directory. May be
required on systems where daemon processes execute without privileges to
access shared filesystems. This is now the default option starting with
maildrop 1.1.--enable-smallmsg=bytes - sets the size of a
message, in bytes, before maildrop saves the message in a
temporary file. Smaller messages are read in memory, and filtered and
delivered directly from memory. In order to avoid consuming excessive
amounts of expensive RAM, maildrop saves larger messages in a
temporary file. If the standard input to maildrop is a file, a
temporary file is not necessary. The default is 8192 bytes.--enable-global-timeout=seconds - sets numbers of
seconds that maildrop is willing to spend in order to deliver a
single message. This value becomes a hard coded limit. When the time
expires, maildrop terminates with an EX_TEMPFAIL
error code. This is intended to stop runaway mail filters. The default is
300 seconds (five minutes).--enable-crlf-term=flag - if set to 1,
maildrop saves messages in the mailbox with each line terminated
by a carriage return/line feed sequence. When set to 0, lines will be
terminated by the linefeed character only. The default value is 0.--enable-restrict-trusted=flag - if set to 1,
maildrop permits only certain "trusted" user or group IDs to use
the -d option. Setting this variable to 0 allows anyone to use the -d
option (provided that maildrop has set-userid-to-root privileges). This
allows certain denial-of-service attacks, so this setting is not
recommended. The default value is 1.--enable-keep-fromline=flag - if set to 1, when
maildrop saves a message to a mailbox file, it will use the same
From_line address which was present in the original message.
If the original message lacked a From_ line, maildrop
will use the name of the user running maildrop. If set to 0,
maildrop will keep the original From_ line address
only if invoked by root, and reset it otherwise. The default value of
this option is the value of the --enable-restrict-trusted
option. Note that this option is new to maildrop version 0.54b.
The logic in the previous version of maildrop was always the same
as if this option was 0. Therefore, depending upon the value of the
--enable-restrict-trusted flag, you may find that
maildrop behavior changes with version 0.54b. This option also
controls the semantics of the -f option to maildrop
(see below).--enable-trusted-users='...' - sets the list of
users allowed to use the -d option if
--enable-restrict-trusted is set to 1. If
--enable-restrict-trusted is set to 0, this option is not
used. Put a list of user IDs allowed to use the -d option between the
apostrophes, separated by single spaces. If your mail transport agent
uses maildrop as the local delivery agent this list must include
the userid that the mail transport agent runs as. If this option is not
specified, maildrop attempts to put together a list including
common mail system user ids.--enable-trusted-groups='...' - this is similar to
the --enable-trusted-users option, but specifies a list of
group IDs instead of user IDs. If --enable-restrict-trusted
option is used, the -d option will be permitted only if the
real userid, of whoever's invoking maildrop, is included in
the trusted users list, OR if the real groupid is included in the trusted
groups list, OR if the effective groupid is included in the trusted
groups list.maildrop
with the set group ID bit set, so that the effective groupid will always
be the same in the default maildrop configuration. If this group ID is
included in the trusted groups list, this effectively will allow everyone
to use the -d option.maildrop
environment. If the --enable-trusted-groups option is not
used, the trusted groups list is empty, so that the semantics of the
trusted users option remains the same as with previous versions of
maildrop.--enable-use-flock=flag - if this option is set to
1, maildrop will use either the flock(), the
lockf(), or the fcntl() system call to lock a
mailbox file when delivering a message. On most systems, all three use
compatible locking mechanisms. In some very isolated cases,
flock(), lockf(), and fcntl(), are
different, incompatible, locking mechanisms. maildrop must use
the same locking mechanism as any mail reading programs. The
configuration script will run some tests to determine what locking
function calls are available, and will choose one by itself. The
--with-locking-method can be used to manually choose the
locking function call to use.
--with-locking-method=name - manually select a
locking function call. name is either "fcntl", "flock", or
"lockf". Otherwise the configuration script will pick one by itself.--enable-use-dotlock=flag - if this option is set
to 1, maildrop will create .lock files in order to
gain access to the system mailbox file. If this option is set to 0,
maildrop will not use .lock files automatically. However,
the dotlock command can still be used to manually create
.lock files. The default value for this option is 1, unless
maildrop detects that the system mailbox directory does not
have the sticky bit set (set below), in which case the default option
is 0. maildrop attempts to figure out what the locking
mechanism is used by the mail reading programs. A mail reading program
can only create dotlock files in the system mailbox directory if the
sticky bit is set. Note, it is possible for both
--enable-use-flockand --enable-use-dotlock to
be set to 1, in which case both locking mechanisms are used
simultaneously.--with-trashquota - include deleted messages, and the
Trash folder, in the estimated quota usage for maildirs. This should be
used if related packages (SqWebMail, Courier-IMAP) were also compiled
with the --with-trashquota option.--with-dirsync - after delivering a new message to a
maildir explicitly sync the maildir's directory directory.
There's a school of thought which believes that the Linux ext2 filesystem
requires the parent directory to be synced, in addition to the new
message file that's just been written to disk. There's another school of
thought that thinks that this issue is completely blown out of
proportion, and is really nothing more than a tempest in a teapot.
However -- to accomodate the former school of thought -- this option adds
a little bit of extra code to sync the parent directory.configure script doesn't work, you may try an alternate C++
compiler. First, you must extract the tarball again, into a different
directory. Then, before running ./configure, set the
CXX environment variable to the C++ compiler to be used. For
example, to select the CC compiler:
$ CXX=CC $ export CXX $ ./configure [options]Then proceed as usual. The
CXXFLAGS environment variable can
also be used to override compiler flags that configure selects.
Here are just some of the possible scenarios that may exist that
maildrop knows how to handle:
/var/mail/j/jt/jthomas; mail for sjones is
stored in /var/mail/s/sj/sjones.flock() function on the
mailbox file itself. maildrop, by default, uses both mechanisms,
except in one case (see the --enable-use-dotlock
option to configure, above), but one or the other can always be selected
to be used exclusively.flock() function is used to lock an
individual mailbox.configure script tries to automatically figure out
the correct settings, but you MUST always verify the output file,
config.h, to make sure that the settings are correct.
Description of each variable defined in config.hfollows. In
addition, there are certain variables defined in a different file,
xconfig.h. These are settings that config.h cannot
automatically determine.
DEFAULT
variable in maildrop, which should be the location of the system
default mailbox. If DEFAULT_DEF begins with a slash, it should
refer to a directory, and maildrop will automatically append the
user's name.
If it doesn't begin with a slash, maildrop will prepend the user's
home directory to DEFAULT_DEF. To use maildrop with qmail, which normally delivers to
$HOME/Mailbox, set DEFAULT_DEF to
./Mailbox.
The '=' character in DEFAULT_DEF gets replaced by progressive characters
from the user name of the user whose mail is being delivered. For example, if
mail to the user name "john" is delivered to /var/mail/j/jo/john
and mail to user "root" is delivered to /var/mail/r/ro/root,
DEFAULT_DEF should be set to /var/mail/=/==
(maildrop automatically appends the full user name as the last
component).
If the DEFAULT_DEF/DEFAULT variable refers to a directory,
maildrop assumes that it is delivering the message to a maildir,
otherwise maildrop will deliver mail to a mailbox file, creating a new
file if necessary. maildrop does not deliver mail to flat
directory, like procmail. If you need to save messages in a directory, use
the included program, maildirmake, to create a maildir
directory.
MAILBOX_MODE to 0600,
and RESET_GID to 1.MAILBOX_MODE to 0600, and RESET_GID to
0.MAILBOX_MODE are the permissions maildrop uses to create new
mailbox files. If a mailbox file already exists, maildrop is not going to
change its permissions.
RESET_GID indicates whether maildrop should
immediately drop any set-group-id privileges. maildrop is installed
with the set-group-id bit set with maildrop's group id set to the mail
group. If system mailbox files have read/write access by both the user and
the mail group, set RESET_GID to 0 to keep the mail group ID,
and specify the mail groupusing the --enable-maildrop-gid
flag to configure (see above).
--enable-restrict-trusted option given to the
configure script is set to 1 (this is the default),
maildrop allows only the users listed in this environment variable to
use the -d option. See the online documentation for the description of the -d
option.
Mail can be delivered in two different ways:
TRUSTED_USERS variable.--enable-restrict-trusted option given to the
configure script is set to 0, anyone can use the -d option. That
is not recommended, it leaves open a possibility for certain
denial-of-service attacks.
configure script also sets the following variables in
autoconf.h. After running the configure script, you
may need to make some adjustments to these variables also.
PATH variable, which is the initial system search path for
commands invoked by maildrop as child processes.
SENDMAIL variable, which is the local mail transport agent.
maildrop runs this program when instructed to deliver mail to a
mailbox whose name begins with the forwarding "!" character.
@bfd.com>:
Mlocal, P=/usr/local/bin/maildrop, F=lsAw5:/|@SPfhn, S=10/30, R=20/40, T=DNS/RFC822/X-Unix, A=maildrop -d $uYou may also consider including the D, F, and M flags as well.
FROM variable. If no -f option is given, maildrop
looks at any From_ line in the message being delivered,
otherwise it defaults to the name of the user who invoked maildrop.
If the --enable-keep-fromline option is set to 0, anyone may
use the -f option. If --enable-keep-fromline is set to 1, only
"trusted" users (as defined by --enable-trusted-users) may use the -f option
(ignored for everyone else).
The initial value of the FROM variable is also used in the
From_ line for the message when maildrop saves it in a
mailbox file. Although a recipe may change the contents of the
FROM variable, only the initial value gets saved in the
From_ line.
maildrop supports an alternative mail storage format called "maildir". Unlike regular mailboxes, maildirs do not require locking, and are much faster to use. Support for maildirs is not universal, but the number of software packages that understands maildirs is constantly growing.
A maildir is a specially formatted directory, where messages are stored as
individual files, according to certain conventions. Use the
maildirmake command to create a maildir, with its structure and
permissions properly set:
maildirmake ./Maildir
This creates a subdirectory in the current directory called "Maildir", which is then prepared to store E-mail messages.
This version of maildrop supports two extensions to the traditional maidlir format: folders and quotas. The standard maildir format does not support any kind of a folder hierarchy, and depends on the underlying filesystem to enforce maximum usage quotas.
It is important to note that at this time not all maildir software supports these extensions. Support is implemented mainly in other Courier packages. Descriptions of these extension are freely available, hopefully other software packages will add support for these extensions too.
Names of folders are limited by the maximum filename size of your filesystem, and the names may not start with a period. Use the -f option to maildirmake to create a new folder:
maildirmake -f Important ./Maildir
"./Maildir" must already be an existing maildir. The -f flag
creates a folder inside an existing maildir. A folder is just a subdirectory
within a maildir that is itself a maildir. The name of the subdirectory is
the folder name prefixed by a period. Also, the folder subdirectory contains
a zero-length file called "maildirfolder".
Maildrop can deliver to folders just like to regular maildirs:
to "./Maildir/.Important"
Anywhere maildrop can deliver to a maildir, it can also deliver to a maildir folder.
See the manual page for maildirmake for more information.
The quota extension allows maximum maildir quotas to be enforced where
filesystem-based quotas are not available, or cannot be used. This quota
mechanism has a number of limitations which are discussed in the manual page
for maildirquota, which contains more information.
Quota enforcement can be implemented by setting the
MAILDIRQUOTA variable in maildrop, as described in the
maildirquota manual page.
Of course, quotas will be enforced only when maildrop is used to deliver mail. Other applications, that do not understand the quota enhancement, will not enforce any quotas. Mail delivered to a maildir by other applications will not figure in quota calculation for some period of time. Eventually, a regularly scheduled quota recalculation will pick them up and include them in the current maildir quota.