9.1 Using mailfromd with Sendmail. ¶

This chapter assumes you are familiar with Sendmail configuration in general and with Milter configuration directives in particular. It concentrates only on issues, specific for mailfromd.

To prepare Sendmail to communicate with mailfromd you need first to set up the milter port. This is done with INPUT_MAIL_FILTER statement in your Sendmail file:

INPUT_MAIL_FILTER(`mailfrom', `S=unix:/usr/local/var/mailfromd/mailfrom')

Make sure that the value of ‘S’ matches the value of listen statement in your mailfromd.conf file (see listen). Notice, however, that they may not be literally the same, because listen allows to specify socket address in various formats, whereas Sendmail’s ‘S’ accepts only milter format.

If you prefer to fiddle directly with sendmail.cf file, use this statement instead:

Xmailfrom, S=unix:/usr/local/var/mailfromd/mailfrom

If you are using Sendmail version 8.14.0 or newer, you may skip to the end of this section. These versions implement newer Milter protocol that enables mailfromd to negotiate with the MTA the macros it needs for each state.

Older versions of Sendmail do not offer this feature. For Sendmail versions prior to 8.14.0, you need to manually configure Sendmail to export macros you need in your mailfromd.mfl file. The simplest way to do so is using rc.mailfromd script, introduced in the previous chapter. Run it with macros command line argument and copy its output to your sendmail.mc configuration file:

$ rc.mailfromd macros

If you prefer to work with sendmail.cf directly, use -c (--cf) command line option:

$ rc.mailfromd macros -c

Finally, if you use other mailfromd script file than that already installed (for example, you are preparing a new configuration while the old one is still being used in production environment), give its name in the command line:

$ rc.mailfromd macros newscript.mfl
# or:
$ rc.mailfromd macros -c newscript.mfl

If you use this method, you can skip the rest of this chapter. However, if you are a daring sort of person and prefer to do everything manually, follow the instructions below.

First of all you need to build a list of macros used by handlers in your mailfromd.mfl file. You can obtain it running mailfromd --dump-macros. This will display all macros used in your handlers, grouped by handler name, for example:

envfrom i, f, {client_addr}
envrcpt f, {client_addr}, {rcpt_addr}

Now, modify confMILTER_MACROS_handler macros in your mc file. Here, handler means the uppercase name of the mailfromd handler you want to export macros to, i.e. the first word on each line of the above mailfromd --dump-macros output. Notice, that in addition to these macros, you should also export the macro i for the very first handler (rc.mailfromd macros takes care of it automatically, but you preferred to do everything yourself...) It is necessary in order for mailfromd to include ‘Message-ID’ in its log messages (see Message-ID).

For example, given the above macros listing, which corresponds to our sample configuration (see Example of a Filter Script File), the sendmail.mc snippet will contain:

define(`confMILTER_MACROS_ENVFROM',dnl
confMILTER_MACROS_ENVFROM `, i, f, {client_addr}')
define(`confMILTER_MACROS_ENVRCPT',dnl
confMILTER_MACROS_ENVRCPT `, f, {client_addr}, {rcpt_addr}')

Special attention should be paid to s macro (‘HELO’ domain name). In Sendmail versions up to 8.13.7 (at least) it is available only to helo handler. If you wish to make it available elsewhere you will need to use the method described in HELO Domain

Now, if you are a really daring person and prefer to do everything manually and to hack your sendmail.cf file directly, you certainly don’t need any advices. Nonetheless, here’s how the two statements above could look in this case:

O Milter.macros.envfrom=i, {auth_type}, {auth_authen}, \
   {auth_ssf}, {auth_author}, {mail_mailer}, {mail_host}, \
   {mail_addr} ,{mail_addr}, {client_addr}, f
O Milter.macros.envrcpt={rcpt_mailer}, {rcpt_host}, \
   {rcpt_addr} ,i, f, {client_addr}

9.2 Using mailfromd with MeTA1. ¶

MeTA1 (http://www.meta1.org) is an MTA of next generation which is designed to provide the following main features:

• Security
• Reliability
• Efficiency
• Configurability
• Extendibility

Instead of using Sendmail-compatible Milter protocol, it implements a new protocol, called policy milter, therefore an additional program is required to communicate with mailfromd. This program is a Pmilter–Milter multiplexer pmult, which is part of the ‘Mailfromd’ distribution. See Pmilter multiplexer program., for a detailed description of its configuration.

The configuration of ‘Meta1--Mailfromf’ interaction can be subdivided into three tasks.

1. Configure mailfromd

   This was already covered in previous chapters. No special ‘MeTA1’-dependent configuration is needed.

2. Configure pmult to communicate with mailfromd

   This is described in detail in Pmilter multiplexer program..

3. Set up MeTA1 to communicate with pmult

   The MeTA1 configuration file is located in /etc/meta1/meta1.conf. Configure the smtps component, by adding the following section:

   policy_milter {
       socket {
           type = type;
           address = addr;
           [path = path;]
           [port = port-no;]
       };
       [timeout = interval;]
       [flags = { flag };]
   };
   

   Statements in square brackets are optional. The meaning of each instruction is as follows:

   type = type

   Set the type of the socket to communicate with pmult. Allowed values for type are:

   inet

   Use INET socket. The socket address and port number are set using the address and port statements (see below).

   unix

   Use UNIX socket. The socket path is given by the path statement (see below).

   Notice, that depending on the type setting you have to set up either address/port or path, but not both.

   address = addr

   Configure the socket address for type = inet. Addr is the IP address on which pmult is listening (see listen statement).

   port = port-no

   Port number pmult is listening on (see listen statement).

   path = socket-file

   Full pathname of the socket file, if type = unix.

   timeout = interval

   Sets the maximum amount of time to wait for a reply from pmult.

   The behavior of smtps in case of time out depends on the flags settings:

   flags = { flag }

   Flag is one of the following:

   abort

   If pmult does not respond, abort the current SMTP session with a ‘421’ error.

   accept_but_reconnect

   If pmult does not respond, continue the current session but try to reconnect for the next session.

For example, if the pmult configuration has:

listen inet://127.0.0.1:3333;

then the corresponding part in /etc/meta1/meta1.conf will be

smtps {
    policy_milter {
        socket {
            type = inet;
            address = 127.0.0.1;
            port = 3333;
        };
        ...
    };
    ...
};

Similarly, if the pmult configuration has:

listen unix:///var/spool/meta1/pmult/socket;

then the /etc/meta1/meta1.conf should have:

smtps {
    policy_milter {
        socket {
            type = unix;
            path = /var/spool/meta1/pmult/socket;
        };
        ...
    };
    ...
};

9.3 Using mailfromd with Postfix ¶

To configure postfix to work with your filter, you need to inform it about the socket your filter is listening on. The smtpd_milters (or non_smtpd_milters) statement in /etc/postfix/main.cf serves this purpose. If the filter is to handle mail that arrives via SMTP, use smtpd_milters. If it is to handle mail submitted locally to the queue, use non_smtpd_milters. In both cases, the value is a whitespace-separated list of socket addresses. Note, that Postfix syntax for socket addresses differs from that used by Sendmail and mailfromd. The differences are summarized in the following table:

For example, if your mailfromd listens on ‘inet://127.0.0.1:4111’, add the following to /etc/postfix/main.cf:

smtpd_milters = inet:127.0.0.1:4111

Mailfromd uses Milter protocol version 6. Postfix, starting from version 2.6 uses the same version. Older versions of Postfix use Milter protocol 2 by default. Normally, it should not be a problem, as mailfromd tries to detect what version the server is speaking. If, however, it fails to select the proper version, you will have to instruct Postfix what version to use. To do so, add the following statement to /etc/postfix/main.cf:

milter_protocol = 6

The way Postfix handles macros differs from that of Sendmail. Postfix emulates a limited subset of Sendmail macros, and not all of them are are available when you would expect them to. In particular, the ‘i’ macro is not available before the ‘DATA’ stage, which brings two consequences. First, mailfromd log messages will not include message ID until the ‘DATA’ stage is reached. Secondly, you cannot use ‘i’ in handlers ‘connect’, ‘helo’, ‘envfrom’ and ‘envrcpt’,

If you wish to tailor Postfix defaults to export the actual macros used by your filter, run mailfromd --dump-macros and filter its output through the postfix-macros.sed filter, which is installed to the prefix/share/mailfromd directory, e.g.:

$ mailfromd --dump-macros | \
  sed -f /usr/share/mailfromd/postfix-macros.sed
milter_helo_macros = {s}
milter_mail_macros = {client_addr} {s} {f}
milter_rcpt_macros = {rcpt_addr} {f} {client_addr}
milter_end_of_data_macros = {i}

Cut and paste its output to your /etc/postfix/main.cf.

For more details regarding Postfix interaction with Milter and available Postfix configuration options, see Postfix before-queue Milter support.