1

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 [127.0.0.1])
    by mail.mydomain.tld (Postfix) with ESMTP id 9D42049E05D
    for <MAILER-DAEMON@mail.mydomain.tld>; Fri, 20 Jul 2018 16:11:41 +0200 (CEST)
Received: from uc.cn (unknown (80.223.20.65])
     by uc.cn with SMTP id 9b2d56fa-9aab-41fd-bf0b-dc1fcc4d8b6b;
     for <3511568185@qq.com>;Fri, 20 Jul 2018 22:11:52 +08:00
Received: from uc.cn (unknown [222.185.22.12])
    by mail.mydomain.tld (Postfix) with SMTP id 910DF49E05D
    for <MAILER-DAEMON@mail.mydomain.tld>; 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: <3511568185@qq.com>
From: =?utf-8?B?6aG+5YWx?= <3511568185@qq.com>
To: <MAILER-DAEMON@mail.mydomain.tld>
Subject: =?utf-8?B?54aK546rfumdouivleaIkOWKn37opoHpgIHkvaAxODjntrXph5Eg5Yqg?=
    =?utf-8?B?5oiR5LyB6bmFMjgxMzMzOTc3MSDpooYg6L+e5o6lIDU1NDYzOEMwTSAgICA=?=
    =?utf-8?B?ICAgIA0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQo=?=
    =?utf-8?B?DQogICAgICAgICAgICAgICAgICA=?=
Date: Fri, 20 Jul 2018 16:11:52 +0200
Message-ID: <0cc4d3442fe85281401f36bf39f215c9@qq.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
    boundary="----=_NextPart_000_0E6A_01D42046.4A45B970"
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQLZY/ijut0x7cMD09Bp+ejCSgrNhw==
Disposition-Notification-To: <3511568185@qq.com>

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.

2

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 ...
        reject_invalid_helo_hostname,
        reject_unknown_helo_hostname,
        # other items ...

The HELO hostname this server sent was invalid. They claimed to be uc.cn but looking up their IP address gave NXDOMAIN, and looking up uc.cn 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 ...
        reject_rbl_client bl.spamcop.net,
        reject_rbl_client cbl.abuseat.org,
        reject_rbl_client zen.spamhaus.org,
        reject_rbl_client b.barracudacentral.org,
        reject_rbl_client dnsbl-1.uceprotect.net,
        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.

  • Thanks for the great answer! I actually don't agree with blocking based on blacklists, since bl's are far from perfect (I rather let SA assign some points for bl's). Nonetheless, I find the extra helo checks great! Off-course the smtpd_helo_required was allready set, I've implemented the others immediately. When it fixes the issue, I'll let it know. – royarisse Aug 8 '18 at 15:51
  • Blacklists aren't perfect, but the specific ones here are very conservative, and I haven't seen a false positive from any of them in over a decade. I've dropped many other blacklists for false positives though... – Michael Hampton Aug 8 '18 at 15:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.