This chapter contains a detailed list of steps you need to undertake in order to configure and build the package.
To build mailfromd you will need to have following
packages on your machine:
GNU mailutils is a general-purpose library for handling electronic mail. It is available from http://mailutils.org.
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.
Mailfromd is able to link with any flavor of
DBM supported by GNU mailutils. As of version
9.0 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:
Berkeley DB (versions 2 to 6).
GNU DBM.
Kyoto Cabinet
Tokyo Cabinet
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:
Same as --with-dbm=gdbm.
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 |
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).
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:
Main daemon. See mailfromd.
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 MFL, for a description of the mail filtering language.
MFL modules. See Modules.
Default preprocessor setup file. See Preprocessor.
Documentation files.
MTA simulator program for testing mailfromd
scripts. See mtasim.
Pmilter multiplexor for MeTA1. See pmult.
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 Defaults, for information about the --show-defaults option.
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).
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 conf-database).
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).
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.
make.
make install.