Requirements

• C++ compiler - A C++ compiler is required.
• make - The GNU make is recommended. Solaris's make is to be avoided. xBSD already has a gmake port, install it and use it (use gmake everywhere this document refers to make).
• GDBM/DB - optional.
• The PCRE library (http:/www.pcre.org) 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 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 -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.

Installing maildrop

 
   ./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, such as deliverquota.
  
  
• /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.
  
  
• Two new features can be optionally enabled via the configure script: maildir quotas, and the virtual user database. See below for more information.

Operating system specific notes

Solaris

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

• 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

• --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.
  
  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.
  
  
• --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-IM.d 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-IM.d 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-IM.d 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-IM.d 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-IM.d 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-IM.d 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-IM.d 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-IM.d 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-IM.d 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-IM.d 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-IM.d 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-IM.d 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-IM.d 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-IM.d 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-IM.d 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-IM.d 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-IM.d 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-IM.d 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-IM.d 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-IM.d 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-IM.d 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-IM.d 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-IM.d 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-IM.d 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-IM.d 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-IM.d 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-IM.d 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-IM.d 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-IM.d 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-IM.d 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-IM.d 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-IM.d 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-IM.d 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-IM.d 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-IM.d 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-IM.d 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-IM.d 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-IM.d 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-IM.d 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-IM.d 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-IM.d 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-IM.d 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-IM.d 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-IM.d 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-IM.d 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-IM.d 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-IM.d 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-IM.d 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-IM.d 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-IM.d 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-IM.d 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-IM.d 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-IM.d 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-IM.d 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-IM.d 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-IM.d 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-IM.d 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-IM.d 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-IM.d 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-IM.d an experimental new feature.
  
  
• --with-trashquota - include deleted mess