interface_policy and postfix

Wed Dec 30 23:36:06 CET 2015

Hi Alex,

* Alex <mysqlstudent at gmail.com>:
> Hi,
> 
> On Mon, Dec 28, 2015 at 1:48 AM, Patrick Ben Koetter <p at sys4.de> wrote:
> > * Alex <mysqlstudent at gmail.com>:
> >> Hi,
> >>
> >> I'm using amavisd-new-2.10.1 and postfix-3.0.3 on fc22. I have a bunch
> >> of IPs that I need to effectively whitelist to allow all mail to skip
> >> being processed by amavisd.
> >>
> >> I'm trying to understand how to use the %interface_policy capability,
> >> and whether that's a better option than to just add the IPs to a
> >> $policy_bank.
> >
> > Interface policies are triggered by the interface/port via which mail enters
> > the amavis framework. This requires logic on the sending side (here: Postfix)
> > and on the receiving side. The sending side must know to via which interface
> > it should route messages to amavis. amavis on the receiving side must provide
> > interfaces and policies as required.
> >
> > I suggest you use an approach that requires no logic on the Postfix side. Use
> > @client_ipaddr_policy in amavis to identify specific IPs/IP ranges and map
> > them to policies.
> 
> That's what I thought, and overnight, I read a ton more docs about
> interface_policy, and just couldn't get it to work. I'm actually doing
> it using client_ipaddr_policy with postfix already, but wasn't sure it
> was the right way for what I was trying to do.
> 
> When people spoke about bypassing amavisd, I was thinking they were
> bypassing amavisd altogether, when they were really talking about just
> the bypass_* options in the policy banks, which is what I was already
> doing.

You can do both and obviously it requires less resources if you bypass amavis
at all. But then - at least by my personal standards - I always scan for
viruses/malware. I may exempt senders or recipients from spam checks, phishing
etc. but not from malware detection.

> I realize you can actually bypass amavisd altogether, but it's messy
> and appears to require an additional IP.

You could also do something like:

192.168.2.1         PREPEND Content-Inspection: PASS

Then check for the header with header_checks and define an action that routes
the message to amavis if does NOT contain the "Content-Inspection: PASS" as
header:

!/^Content-Inspection: PASS$/       FILTER smtp-amavis:[127.0.0.1]:10024

But this feels clumsy and error prone.

> > We're using MILTER to connect Postfix and amavis. You are using content_filter
> > to hand mail over to amavis. You're log line may vary. The approach to use
> > @client_ipaddr_policy remains the same.
> 
> Can you explain this further? You're not using something like
> "content_filter = smtp-amavis:[127.0.0.1]:10024" with postfix?

We are not using content_filter. We use MILTERs whenever possible.

First of all, because we run our servers in Germany and Germany requires us to
either reject a message before we queue it or deliver it to the recipient, we
do pre-queue filtering.

Within the domain of pre-queue filtering we could use smtpd_proxy_filter or
the MILTER API to connect a content filter (framework) such as amavis with
Postfix.

Why prefer MILTERs over smtpd_proxy_filter?
A few qualities come to mind:

Variety
    There are many MILTERs out there to choose from when we build a mail
    platform. The have been tested well.

Speed
    Most milters are fast. By definition a MILTER runs in memory only.

Log
    With content_... or ...-proxy_filter logging becomes ugly. One message
    passing back and forth between several message processing applications may
    generate many queue ID - each time it (re)enters the Postfix mail server.
    With MILTER log entries keep in sequence. No new queue IDs. Reading log is
    simple. Parsing log is simple. I love it. ;)

> I'm actually thinking of also implementing MIMEdefang, and believe you
> need to use a MILTER to do that, but wasn't sure how that would be
> done.

Sooner or later you probably also want to implement DMARC. Then you will have
to use OpenDKIM and OpenDMARC - both MILTERs.

How to implement:

Postfix uses smtpd_milters or non_smtpd_milters to intergrate MILTERS into the
Postfix message flow. Postfix connects to a MILTER either via a UNIX domain
socket or via a TCP socket. If the MILTER doesn't reside on the same machine
as Postfix use stunnel to protect the unencrypted MILTER TCP socket.

amavis does not implement a MILTER API. In order to use it via a MILTER you
need to use amavisd-milter as bridge. Towards Postfix it offes a MILTER API
and towards amavisd-new it uses the AM.PDP (amavis policy delegation
protocol).

A config sketch could be:

###
# main.cf

# Where should the smtpd server meet milters?
smtpd_milters =
    # Opendkim
    unix:milter/dkim
    # Opendmarc
    unix:milter/dmarc
    # amavis via milter
    inet:localhost:10024

###
# master.cf

# notification channel for amavis
127.0.0.1:10025 inet n  -       n       -       -       smtpd
    -o syslog_name=postfix-reentry
    -o smtpd_banner=$smtpd_reentry_banner
    -o content_filter=
    -o smtpd_milters=unix:milter/dkim
    -o milter_macro_daemon_name=DKIMSign
    -o local_recipient_maps=
    -o relay_recipient_maps=
    -o smtpd_delay_reject=no
    -o smtpd_restriction_classes=
    -o smtpd_client_restrictions=
    -o smtpd_helo_restrictions=
    -o smtpd_sender_restrictions=
    -o smtpd_recipient_restrictions=
    -o smtpd_data_restrictions=reject_unauth_pipelining
    -o smtpd_end_of_data_restrictions=
    -o smtpd_relay_restrictions=permit_mynetworks,reject
    -o mynetworks=127.0.0.0/8
    -o smtpd_error_sleep_time=0
    -o smtpd_soft_error_limit=1001
    -o smtpd_hard_error_limit=1000
    -o smtpd_client_connection_count_limit=0
    -o smtpd_client_connection_rate_limit=0
    -o receive_override_options=no_header_body_checks,no_unknown_recipient_checks

### This is on Gentoo
# /etc/conf.d/amavisd-milter

# Unix domain socket locations
SOCKET="inet:10024 at 127.0.0.1"

AM_SOCKET="/var/amavis/amavisd.sock"

# Working directory
AM_TMP="/var/amavis/tmp"

# Pid file location
PIDFILE="/var/amavis/amavisd-milter.pid"

# Maximum connections
MAX_CON="20"

DOPTIONS="-s $SOCKET -p $PIDFILE -S $AM_SOCKET -w $AM_TMP -m $MAX_CON -B"

And finally in amavis:

#############################################################################
## SERVER
#

$max_servers = 16;

# Where to listen for incoming connections?
@listen_sockets = ( 
    # Release
    '[::1]:9998', 
    # Post-Queue, Submission
    '[::1]:10026', 
    # Pre-Queue, MTA to MTA
    "$MYHOME/amavisd.sock" 
    );

That's about it. Once you have tweaked it to fit your setup bringing in the
@client_ipaddr_policy should be fairly simple.

p at rick

-- 
[*] sys4 AG

https://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein