## 9 Using `mailfromd` with Various MTAs ¶

The following sections describe how to configure various Milter-capable MTAs to work with `mailfromd`.

### 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:

Sendmail | Mailfromd | Postfix
--- | --- | ---
inet:port@host | inet://host:port | inet:host:port
unix:file | unix://file | unix:file

Table 9.1: Socket addresses in various formats

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.