General-Purpose Mail Filter

10.1 Calloutd Configuration

Main configuration file /etc/mailfromd.conf is used
(see Mailfromd Configuration). The configuration statements are
basically the same as for mailfromd.

The address to listen on is defined in the server statement.
Basically, it is the only statement the configuration file is required
to have. The minimal configuration can look like:

program calloutd {
server {
listen inet://198.51.100.1:3535;
}
}

To instruct the mailfromd daemon to use this server, the
following statement should be added to the /etc/mailfromd.conf
file:

program mailfromd {
callout-url inet://198.51.100.1:3535;
}

The server statement differs a little from the similar
statement for mailfromd. This and another
calloutd-specific statements are described in detail in the
subsections that follow. The rest of statements is shared with
mailfromd. The following table lists all supported
configuration statements along with cross-references to the
correspondent descriptions:

Define a server. Optional label may follow the server
keyword. The label is ignored.

The substatements in the server block provide parameters for
configuring this server.

server: idname

Assign an identifier to this server. This identifier is used as
a suffix to syslog tag (see syslog tag) in messages related to
this server. For example, if a server block had the following
statement in it:

id main;

then all messages related to this server will be marked with tag
‘calloutd#main’.

Configures the size of the queue of pending connections. Default
value is 8.

server: max-instancesnumber

Sets the maximum number of instances allowed for this server.

server: single-processbool

When set to ‘yes’, this server will run in single-process
mode, i.e. it will not fork sub-processes to serve requests. This
option is meant exclusively to assist in debugging
calloutd. Don’t use it for anything else but for
debugging!

server: reuseaddrbool

When set to ‘yes’, calloutd will attempt to reuse
existing socket addresses. This is the default behavior.

If the global ACL is defined as well, an incoming connection is
checked against both lists: first the per-server ACL, then the global
one. The connection will be permitted only if it passes both checks.