                                  Requirements

  • gcc that supports at least C++17 (http://www.gnu.org/software/gcc/)
  • GDBM/DB - optional.
  • The PCRE2 library (http:/www.pcre.org) is required.
  • The Courier Unicode Library (https://www.courier-mta.org/unicode) must be
    installed first.
  • The libidn2 library is required.
  • Courier Authentication Library - optional, for LDAP, MySQL, or PostgreSQL
    support.

    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 https://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 -d flag
    >      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/authdaemon by 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 maildroprc file), 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.

    > NOTE:

    > When using the option to have maildrop invoked as root, an additional
    > option to automatically create a new account's home directory becomes
    > possible.

    > This uses the AUTH_MKHOMEDIR_SKEL environment variable. If this
    > environment variable is set, it must point to a template directory such as
    > /etc/skel. If the environment variable is set, and the authenticated
    > account's home directory does not exist, the contents of the template
    > directory get recursively copied into the new home directory. The
    > permissions of AUTH_MKHOMEDIR_SKEL and its contents are preserved, and the
    > owner userid and groupid is set to the authenticated account's userid and
    > groupid.

    > Consult your mail server's documentation for more information on how to
    > initialize the mail delivery agent's environment variables.

                              Installing maildrop

rpm and deb packages

These are not the same packages as the ones from various distributions'
repositories. These packages carry a higher internal revision level in order to
prevent them from getting upgraded by the distribution packaging, and their
installation layout may differ from the distributions' preferred package
installation layout. This packaging exists in order to have a convenient way of
updating after a release without waiting for the distribution's package to get
built, and to have a better correspondence with the documentation.

NOTE: If a distribution package is already installed it should be removed
completely before switching to the upstream version (dnf remove or apt purge).
Preserve any existing configuration files, beforehand, in order to restore it
after switching packages. This applies to all Courier packages. A switch to this
maildrop package requires switching the courier-unicode package (and possibility
courier-authlib package) too.

NOTE: These packages use their own, generic, installation layout that may
deviate slightly from the package installation conventions preferred by the
distributions.

rpm

Run dnf install rpm-build if it's not installed already, then:

rpmbuild -ta maildrop-VERSION.tar.bz2

If this fails due to any missing dependencies, install them.

  Rocky/RHEL 8/9 notes

Courier packages require C++17 support, but the default version of gcc does not
fully support it, and a newer gcc is needed:

dnf install --enablerepo=crb -y gcc-toolset-14
scl enable gcc-toolset-14 "rpmbuild -ta maildrop-VERSION.tar.bz2"

deb

Run "apt install devscripts debhelper", if they're not installed already. Create
an empty directory and copy/move the tarball into it:

$ mkdir tmp
$ mv maildrop-VERSION.tar.bz2 tmp
$ cd tmp

Unpack the tarball and cd into the unpacked subdirectory:

$ tar xvf maildrop-VERSION.tar.bz2
$ cd maildrop-VERSION

Run the courier-debuild script, this is a wrapper for debuild, and it forwards
its parameters to it:

$ ./courier-debuild -us -uc

NOTE: the above steps must be followed strictly. The courier-debuild script
expects the distributed tarball in its parent directory.

NOTE: if the courier-debuild script stops with an error complaining about
missing dependencies, then use "apt install" to install them, then try again.

$ DEBGCC=10 ./courier-debuild -us -uc

Setting the DEBGCC environment variable selects a non-default gcc version.

NOTE: All Courier packages should be built with the same version of gcc, which
is selected by the DEBGCC environment variable before running courier-debuild.
See courier-unicode's INSTALL for more information.

  Ubuntu and Debian

Courier packages require C++17 support, but the default version of gcc on Ubuntu
does not fully support it, and a newer gcc is needed:

$ sudo apt install -y gcc-10 g++-10
$ DEBGCC=10 ./courier-debuild -us -uc

make check requires both the ISO-8859-1 based en_US locale in addition to the
default en_US.UTF-8, on all versions of Ubuntu and Debian.

Maintainer Mode (see README in the git repository to set up)

make rpm or make deb, as appropriate, will:

 1. Increment an internal release number.

 2. Run make dist.

 3. Proceed and build a new release, creating the native packages in the rpm or
    deb subdirectory.

Manual installation

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:

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

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

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

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.

  • The makegdbm utility has been renamed as makedat, to better reflect the fact
    that it can be compiled with DB as well as GDBM database support.

  • Config scripts from earlier versions usually created a Makefile that
    automatically gzipped all manual pages during installation. This code has
    been taken out. make install now installs uncompressed manual pages only. If
    you do a make install, you'll need to go in and manually remove gzipped
    manual pages from the previous version of maildrop.

  • You will need to have Perl 5 available to complete the compilation and
    installation process.

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.
  • Unlike other mail transport agents, most sendmails completely discard error
    messages from the local delivery agent. Therefore, you should use the
    --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.

  • Interactive or background delivery mode. Usually the default sendmail
    delivery mode is i - interactive, or b - background. It appears that some
    versions of sendmail have a minor conflict with 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.

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

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.
 

  • --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.
See the manual page for maildropfilter for more information on these variables.
  • --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-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.

    CAUTION: the default configuration script installs 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.

    The trusted groups feature has been implemented in order to add additional
    flexibility in setting up a secure 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.

  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:
 

  • All users' mailboxes usually are stored in a single directory, and the name
    of the mailbox is the user name. On systems with many mailboxes, the mailbox
    directory can be partitioned into a hierarchical tree, based upon the
    initial letters of the user name. For example, the mailbox for the user
    jtomas is /var/mail/j/jt/jthomas; mail for sjones is stored in
    /var/mail/s/sj/sjones.

  • Instead of storing mail in a separate directory, the system may store
    incoming mail in each user's home directory.

  • Instead of storing mail in a traditional mailbox file, the system may
    implement a directory based format called maildir, that was introduced in
    the Qmail mail server. With maildrop as your local delivery agent you may
    implement the maildir format without having to use Qmail itself. Maildir is
    a much more efficient mail storage format which requires far less overhead.
    No locking of any kind is needed; multiple instances of maildrop can dump
    mail into the same maildir at the same time.

  • When mail is saved in a traditional mailbox file, only one program may
    access the file at the same time. In order to synchronize access to the
    mailbox file, the traditional mechanism uses a separate dot-lock file. Newer
    systems may also use the 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.

  • Traditionally, the directory where system mailboxes reside has the sticky
    bit set; all individual files are owned by their respective users, with
    read/write permissions set for the user only, and dot-locking is used to
    lock the mailbox. An alternative arrangement is to remove the sticky bit
    from the directory, the directory has the mail group ownership, and each
    mailbox is owned by the user, and the mail group, with read/write privileges
    given to the owner. The mail delivery agent runs under the user id, and the
    mail group id. This allows the mail delivery agent to create new mailboxes,
    and have the write permission on the user's mailbox. The flock() function is
    used to lock an individual mailbox.
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 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 and RESET_GID

Here are the required setting in two of the most common mailbox environments:
 
  • Mailbox spool directory has the sticky bit set, mailboxes are readable and
    writable by the user only - set MAILBOX_MODE to 0600, and RESET_GID to 1.

  • Mailbox spool directory does not have the sticky bit set, is writable by the
    mail group ID, mailboxes are readable and writable by the user ID - set
    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).

    TRUSTED_USERS

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

  • The mail transport agent runs with root privileges. To deliver mail to a
    local user, the mail transport agent runs maildrop after changing the user
    id to the local user. In this case the -d option is not needed.

  • The mail transport agent runs as a non-privileged user. To deliver mail to a
    local user, the mail transport agent runs the mail delivery agent and
    specifies the user name with the -d option. The mail delivery agent is
    expected to be a program with root privileges, and it immediately must
    change its userid to the one specified by the -d option. If this is the
    case, you must include the mail transport agent's userid in the
    TRUSTED_USERS variable.
If --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.

  Other configuration variables

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

    DEFAULT_PATH

This variable in "autoconf.h" sets the initial contents of the PATH variable,
which is the initial system search path for commands invoked by maildrop as
child processes.

    SENDMAIL_DEF

This variable in "autoconf.h" sets the initial contents of the 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.

    Other variables in autoconf.h

All the other variables are self explanatory, and rarely need to be changed.

Using maildrop with sendmail

Maildrop can be easily used as sendmail's local delivery agent, instead of
procmail. Here is the suggested entry for sendmail.cf, courtesy of Eric J.
Schwertfeger <ejs@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 $u

You may also consider including the D, F, and M flags as well.

The -f option to maildrop

The -f option is new to version 0.55. The -f option sets the initial value of
the 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.

  Maildirs

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.

  Maildir folder extension

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.

  Maildir quota extension

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.
