Mailfromd Manual (split by node): Section: Back: 1.5 SPF Forward: 3. Tutorial Chapter: FastBack: 1. Introduction to mailfromd Up: Mailfromd FastForward: 3. Tutorial Doc: Contents: Table of Contents Index: Concept Index   ?

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 2.0 or newer.

      It is available from http://www.gnu.org/software/mailutils.

    2. A DBM library. Mailfromd is able to link with two flavors of DBM libraries: Berkeley DB or gdbm. 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.

      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. It is here because it is usually wise to configure mailfromd to use the same database type as your Sendmail installation. Of course, this column is irrelevant if you use MeTA1 or Postfix. Finally, the column ‘configure option’ lists the option you should give to configure to enable using this database. ‘N/A’ in any column means there is no support for this database in Sendmail or mailfromd.

      DB type confMAPDEF configure option
      NDBM ‘-NNDBM’ N/A
      Berkeley DB ‘-NNEWDB’ ‘--with-berkeley-db’
      GDBM N/A ‘--with-gdbm’

      The ‘--with-berkeley-db’ option needs a special note. By default it will try to determine the version of Berkeley DB installed on your machine. If, however, this autodetection fails, you can explicitly specify the version or the library name to use as the argument to the option. Unless the argument begins with a digit, it is taken as a library name, without the ‘lib’ prefix and library type suffix, so that

       
      ./configure --with-berkeley-db=db-3.1

      instructs configure to use the library ‘libdb-3.1.so’ (or ‘libdb-3.1.a’). Otherwise, if the argument begins with a digit, it is understood as a version number of the library to link to. In this case configure assumes a Slackware-like installation layout. Thus, the option

       
        --with-berkeley-db=3.1

      tells configure to use the library ‘libdb-3.1.so’ (or ‘libdb-3.1.a’) and the header file ‘/usr/include/db31/db.h’.

  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 section mailfromd.

    ‘prefix/etc/mailfromd.mf’

    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 section Mail Filtering Language, for a description of the mail filtering language.

    ‘prefix/share/mailfromd/6.0/*.mf’

    MFL modules. See section Modules.

    ‘prefix/info/mailfromd.info*’

    Documentation files.

    ‘prefix/bin/mtasim’

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

    ‘prefix/sbin/smap’

    Socket map for MeTA1. See section Using mailfromd with MeTA1..

    ‘prefix/sbin/pmult’

    Pmilter multiplexor for MeTA1. See section 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 section state-directory).

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

    There are also two variables that allow to control particular expiration intervals: DEFAULT_DNS_NEGATIVE_EXPIRE_INTERVAL sets expiration time for cached negative DNS answers (see DNS Cache Management) (default 3600 seconds) and DEFAULT_EXPIRE_RATES_INTERVAL sets default expiration time for mail rate database (see section Rate limiting functions).

    Expiration settings can be changed at run time using database statement in the mailfromd configuration file (see section 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 ‘--syslog-async’ or ‘--no-syslog-async’ command line options (see section 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:

External preprocessor..................... /usr/bin/m4 -s
DBM version............................... Berkeley DB v. 3
Default user.............................. mail
State directory...........................
           $(localstatedir)/$(PACKAGE)
Socket.................................... mailfrom
Expiration interval....................... 86400
Negative DNS answer expiration interval... 3600
Rates expire interval..................... 300
Default syslog implementation............. blocking
Readline (for mtasim)..................... yes
Documentation rendition type.............. PROOF
Enable pmilter support.................... no
Enable GeoIP support...................... no
*******************************************************************

    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.mf’) and edit it, if necessary.
  12. Upgrading If you are upgrading from an earlier release of Mailfromd, refer to Upgrading, for detailed instructions.
Mailfromd Manual (split by node): Section: Back: 1.5 SPF Forward: 3. Tutorial Chapter: FastBack: 1. Introduction to mailfromd Up: Mailfromd FastForward: 3. Tutorial Doc: Contents: Table of Contents Index: Concept Index   ?
This document was generated by Sergey Poznyakoff on December, 12 2009 using texi2html 1.78.

Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.