Requirements

Installing maildrop

The typical sequence of commands to install maildrop is as follows. You will likely need to use the GNU version of make. Other makes may not work. See below for definition of various options to the 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:

MAKE=gmake ./configure [options]

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.

WHAT GETS INSTALLED

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

These are the default directories. The defaults can be changed using the standard autoconf options, run ./configure --help for more information.

UPGRADING

From version 1.1 or earlier.

Read UPGRADE for some important notes. The default installation directory/layout has changed.

From version 0.70 or earlier.

The --with-gdbm option has been renamed to --with-db. Its functionality remains the same. The name change is due to some internal housekeeping.

From version 0.65, or earlier.

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.

Operating system specific notes

This section will list any platform-depended issues.

Solaris

This problem has been reported for Solaris 2.6. Other Solaris versions or related platforms can be affected. Symptom - trying to run 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.

  1. If you can configure your mail transport agent to set the correct user and group IDs before running 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.

  2. Create a soft link from /usr/lib/localto /usr/local/lib, and add /usr/lib/local to the LD_LIBRARY_PATH environment variable.

  3. Create a soft link to libstdc++ from /usr/libto /usr/local/lib

Any sendmail platform

There are two quirks that anyone installing maildrop on a sendmail-based system should be aware of.

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.

Any AFS platform

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)

Options to configure

Although most configuration is done as described in the following section, I am migrating them to the configure script. Currently, configure support the following options:
  Most systems invoke the mail delivery agent and specify the account to which the message is addressed. The mail delivery agent is a program that's owned by root, and has the set-user-id bit set. The mail delivery agent then immediately resets its userid to whomever the message is addressed to.

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.
 

See the manual page for maildropfilter for more information on these variables.

Selecting an alternate C++ compiler

maildrop is written in C++. Some systems may have more than one C++ compiler available. If the default C++ compiler that's selected by the 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.

Configuring the location of the system mailbox

When maildrop has a message to deliver to a user, maildrop must know where user's mailbox is. Different systems use different places to store E-mail, and different mechanisms to access it. And even on the same operating system you may have variations due to different mail software.

Here are just some of the possible scenarios that may exist that maildrop knows how to handle:
 

As you can see, there is a lot of variation in possible mail setups. It is important that maildrop is configured to match your existing mail setup.  The 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_DEF

This variable specifies the initial setting for the 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 qee 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.

  • --enable-maildirquota - enables optional support for maildir quotas. See below for more information. This is considered an experimental new feature.

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

  • --enable-userdb - enables optional support for the userdb database. See the enclosed HTML and man page documentation for the makeuserdb and userdb commands for additional information. This is considered an experimental new feature.
  • Selecting an alternate C++ compiler

    maildrop is written in C++. Some systems may have more than one C++ compiler available. If the default C++ compiler that's selected by the 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.

    Configuring the location of the system mailbox

    When maildrop has a message to deliver to a user, maildrop must know where user's mailbox is. Different systems use different places to store E-mail, and different mechanisms to access it. And even on the same operating system you may have variations due to different mail software.

    Here are just some of the possible scenarios that may exist that maildrop knows how to handle:
     

    As you can see, there is a lot of variation in possible mail setups. It is important that maildrop is configured to match your existing mail setup.  The 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_DEF

    This variable specifies the initial setting for the 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 qee 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.

  • --enable-maildirquota - enables optional support for maildir quotas. See below for more information. This is considered an experimental new feature.

  • --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 blow