## 2 Building the Package ¶

This chapter contains a detailed list of steps you need to undertake in order to configure and build the package.

1. Make sure you have the necessary software installed.

   To build `mailfromd` you will need to have following packages on your machine:

   1. GNU mailutils version 3.3 or newer.

      GNU mailutils is a general-purpose library for handling electronic mail. It is available from http://mailutils.org.

   2. GNU adns library, version 1.5.1 or newer.

      GNU adns is an advanced DNS client library. The recent version can be downloaded from http://www.chiark.greenend.org.uk/~ian/adns/adns.tar.gz. Visit http://www.gnu.org/software/adns, for more information.

   3. A DBM library. `Mailfromd` is able to link with any flavor of DBM supported by GNU mailutils. As of version 9.1 it will refuse to build without DBM. By default, `configure` will try to find the best implementation installed on your machine (preference is given to Berkeley DB) and will use it. You can, however, explicitly specify which implementation you want to use. To do so, use the `--with-dbm` configure option. Its argument specifies the type of database to use. It must be one of the types supported by GNU mailutils. At the time of this writing, these are:
      bdb

        Berkeley DB (versions 2 to 6).

      gdbm

        GNU DBM.

      kc

        Kyoto Cabinet

      tc

        Tokyo Cabinet

      ndbm

        NDBM

      To check what database types are supported by your version of mailutils, run the following command:

          $ mailutils dbd gdbm kc tc ndbm

      For backward compatibility, `configure` accepts the following two options:

      `--with-gdbm`

        Same as `--with-dbm=gdbm`.

      `--with-berkeley-db`

        Same as `--with-dbm=bdb`.

      For `Sendmail` users, it often makes sense to configure `mailfromd` to use the same database flavor as `sendmail`. The following table will help you do that. The column ‘`DB type`’ lists types of DBM databases supported by `mailfromd`. The column ‘`confMAPDEF`’ lists the value of `confMAPDEF` Sendmail configuration macro corresponding to that database type. The column ‘`configure option`’ contains the corresponding option to configure.

      DB type | confMAPDEF | configure option
      --- | --- | ---
      NDBM | `-NNDBM` | `--with-dbm=ndbm`
      Berkeley DB | `-NNEWDB` | `--with-dbm=bdb`
      GDBM | N/A | `--with-dbm=gdbm`

2. Decide what user privileges will be used to run `mailfromd`

   After startup, the program drops root privileges. By default, it switches to the privileges of user ‘`mail`’, group ‘`mail`’. If there is no such user on your system, or you wish to use another user account for this purpose, override it using DEFAULT_USER environment variable. For example for `mailfromd` to run as user ‘`nobody`’, use

       ./configure DEFAULT_USER=nobody

   The user name can also be changed at run-time (see --user).

3. Decide where to install `mailfromd` and where its filter script and data files will be located.

   As usual, the default value for the installation prefix is `/usr/local`. If it does not suit you, specify another location using `--prefix` option, e.g.: ‘`--prefix=/usr`’.

   During installation phase, the build system will install several files. These files are:

   `prefix/sbin/mailfromd`

     Main daemon. See mailfromd.

   `prefix/etc/mailfromd.mfl`

     Default main filter script file. It is installed only if it is not already there. Thus, if you are upgrading to a newer version of `mailfromd`, your old script file will be preserved with all your changes.

     See Mail Filtering Language, for a description of the mail filtering language.

   `prefix/share/mailfromd/9.1/*.mfl`

     MFL modules. See Modules.

   `prefix/share/mailfromd/9.1/include/pp-setup`

     Default preprocessor setup file. See MFL Preprocessor.

   `prefix/info/mailfromd.info*`

     Documentation files.

   `prefix/bin/mtasim`

     MTA simulator program for testing `mailfromd` scripts. See `mtasim` — a testing tool.

   `prefix/sbin/pmult`

     Pmilter multiplexor for `MeTA1`. See Pmilter multiplexer program.. It is build only if `MeTA1` version ‘`PreAlpha29.0`’ or newer is installed on the system. You may disable it by using the `--disable-pmilter` command line option.

     When testing for `MeTA1` presence, `configure` assumes its default location. If it is not found there, inform `configure` about its actual location by using the following option:

         --enable-pmilter=prefix

     where prefix stands for the `MeTA1` installation prefix.

   It is advisable to use the same settings for file name prefixes as those you used when configuring `mailutils`. In particular, try to use the same `--sysconfdir`, since it will facilitate configuring the whole system.

   Another important point is location of local state directory, i.e. a directory where `mailfromd` keeps its data files (e.g. communication socket, PID-file and database files). By default, its full name is `localstatedir/mailfromd`. You can change it by setting `DEFAULT_STATE_DIR` configuration variable. This value can be changed at run-time using the `state-directory` configuration statement (see state-directory). To inspect the actual value of the local state directory, run

       mailfromd --no-config --show-defaults | grep '^statedir:'

   See Examining Default Values, for information about the `--show-defaults` option.

4. Select default communication socket. This is the socket used to communicate with MTA, in the usual `Milter` port notation (see milter port specification). If the socket name does not begin with a protocol or directory separator, it is assumed to be a UNIX socket, located in the local state directory. The default value is `mailfrom`, which is equivalent to `unix:localstatedir/mailfromd/mailfrom`.

   To alter this, use `DEFAULT_SOCKET` environment variable, e.g.:

       ./configure DEFAULT_SOCKET=inet:999@localhost

   The communication socket can be changed at run time using `--port` command line option (see --port) or the `listen` configuration statement (see listen).

5. Select default expiration interval. Expiration interval defines the period of time during which a record in the `mailfromd` database is considered valid. It is described in more detail in Databases. The default value is 86400 seconds, i.e. 24 hours. It is OK for most sites. If, however, you wish to change it, use DEFAULT_EXPIRE_INTERVAL environment variable.

   The `DEFAULT_EXPIRE_RATES_INTERVAL` variable sets default expiration time for mail rate database (see Rate limiting functions).

   Expiration settings can be changed at run time using `database` statement in the `mailfromd` configuration file (see Database Configuration).

6. Select a `syslog` implementation to use.

   `Mailfromd` uses `syslog` for diagnostics output. The default `syslog` implementation on most systems (most notably, on GNU/Linux) uses blocking `AF_UNIX SOCK_DGRAM` sockets. As a result, when an application calls `syslog()`, and `syslogd` is not responding and the socket buffers get full, the application will hang.

   For `mailfromd`, as for any daemon, it is more important that it continue to run, than that it continue to log. For this purpose, `mailfromd` is shipped with a non-blocking `syslog` implementation by Simon Kelley. This implementation, instead of blocking, buffers log lines in memory. When the buffer log overflows, some lines are lost, but the daemon continues to run. When lines are lost, this fact is logged with a message of the form:

          async_syslog overflow: 5 log entries lost

   To enable this implementation, configure the package with `--enable-syslog-async` option, e.g.:

       ./configure --enable-syslog-async

   Additionally, you can instruct `mailfromd` to use asynchronous syslog by default. To do so, set `DEFAULT_SYSLOG_ASYNC` to 1, as shown in example below:

       ./configure --enable-syslog-async DEFAULT_SYSLOG_ASYNC=1

   You will be able to override these defaults at run-time by using the `--logger` command line option (see Logging and Debugging).

7. Run `configure` with all the desired options.

   For example, the following command:

       ./configure DEFAULT_SOCKET=inet:999@localhost --with-berkeley-db=3

   will configure the package to use Berkeley DB database, version 2, and ‘`inet:999@localhost`’ as the default communication socket.

   At the end of its run `configure` will print a concise summary of its configuration settings. It looks like that (with the long lines being split for readability):

       *******************************************************************
       Mailfromd configured with the following settings:

       Mailutils version......................... 3.15
       External preprocessor..................... /usr/bin/m4 -s
       DBM version............................... Berkeley DB v. 3
       Default user.............................. mail
       State directory...........................
                  $(localstatedir)/$(PACKAGE)
       Socket.................................... mailfrom
       Expiration interval....................... 86400
       Compile asynchronous syslog............... no
       Readline (for mtasim)..................... yes
       Documentation rendition type.............. PROOF
       Enable pmilter support.................... no
       Enable GeoIP2 support..................... no
       Enable DKIM support....................... yes
       IPv6 support.............................. yes
       *******************************************************************

   Make sure these settings satisfy your needs. If they do not, reconfigure the package with the right options.

8. Run `make`.
9. Run `make` install.
10. Make sure `localstatedir/mailfromd` has the right owner and mode.
11. Examine filter script file (`sysconfdir/mailfromd.mfl`) and edit it, if necessary.
12. If you are upgrading from an earlier release of Mailfromd, refer to Upgrading, for detailed instructions.