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.
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.
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 $u
You 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.