Postfix content filter (spamassassin) get's bypassed

royarisse asked:

Lately we’re receiving a lot of Japanese spam messages, containing weird headers. At least, it looks like a mail is remotely offered, but the mail is handled as if it was sent internally, which bypasses the content filters.

Received: by mail.mydomain.tld (Postfix, from userid 5001)
    id 6B03E49E06C; Fri, 20 Jul 2018 16:11:41 +0200 (CEST)
Received: from mail.mydomain.tld (mail.mydomain.tld [])
    by mail.mydomain.tld (Postfix) with ESMTP id 9D42049E05D
    for <[email protected]>; Fri, 20 Jul 2018 16:11:41 +0200 (CEST)
Received: from (unknown (])
     by with SMTP id 9b2d56fa-9aab-41fd-bf0b-dc1fcc4d8b6b;
     for <[email protected]>;Fri, 20 Jul 2018 22:11:52 +08:00
Received: from (unknown [])
    by mail.mydomain.tld (Postfix) with SMTP id 910DF49E05D
    for <[email protected]>; Fri, 20 Jul 2018 16:11:39 +0200 (CEST)
Received: by mail.mydomain.tld (Postfix)
    id B312049E05F; Fri, 20 Jul 2018 16:11:41 +0200 (CEST)
Return-Path: <[email protected]>
From: =?utf-8?B?6aG+5YWx?= <[email protected]>
To: <[email protected]>
Subject: =?utf-8?B?54aK546rfumdouivleaIkOWKn37opoHpgIHkvaAxODjntrXph5Eg5Yqg?=
Date: Fri, 20 Jul 2018 16:11:52 +0200
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: multipart/alternative;
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQLZY/ijut0x7cMD09Bp+ejCSgrNhw==
Disposition-Notification-To: <[email protected]>

We’re using Postfix 2.9.6 with SpamAssassin 3.3.2. linked using -o content_filter to the smtp process. We’re also running Postfix’s smtps process, also linked to SA using -o content-filter=

I simply can’t find out how the message gets submitted in this manner and why the content-filters get bypassed.

My answer:

I’m surprised you let this message get as far as SpamAssassin. Several of Postfix’s built in restrictions would have rejected this spam long before it got that far.

From my live mail server:

smtpd_helo_required = yes

Some spammers don’t bother with a HELO. This one did, but having this on enables other HELO based checks to work properly and not be trivially bypassed by not sending a HELO.

smtpd_helo_restrictions =
        # other items ...
        # other items ...

The HELO hostname this server sent was invalid. They claimed to be but looking up their IP address gave NXDOMAIN, and looking up gave a different IP address. reject_invalid_helo_hostname and reject_unknown_helo_hostname reject messages from remote hosts who claim to be someone they’re not in the EHLO/HELO message.

smtpd_recipient_restrictions =
        # other items ...
        check_policy_service unix:private/policy-spf,
        # other items ...

The IP address that delivered the mail to you is already on numerous spam blacklists. Consider adding a few to your configuration, to reject the worst spam before it gets anywhere near your servers.

Checking the SPF records would also have caused this mail to be rejected. Install an SPF service such as pypolicyd-spf (used here).

You may also find the Postfix documentation interesting reading.

View the full question and any other answers on Server Fault.

Creative Commons License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.