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 <[email protected]>; Fri, 20 Jul 2018 16:11:41 +0200 (CEST) Received: from uc.cn (unknown (220.127.116.11]) by uc.cn with SMTP id 9b2d56fa-9aab-41fd-bf0b-dc1fcc4d8b6b; for <[email protected]>;Fri, 20 Jul 2018 22:11:52 +08:00 Received: from uc.cn (unknown [18.104.22.168]) 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?= =?utf-8?B?5oiR5LyB6bmFMjgxMzMzOTc3MSDpooYg6L+e5o6lIDU1NDYzOEMwTSAgICA=?= =?utf-8?B?ICAgIA0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQo=?= =?utf-8?B?DQogICAgICAgICAgICAgICAgICA=?= Date: Fri, 20 Jul 2018 16:11:52 +0200 Message-ID: <[email protected]> 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: <[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
I simply can’t find out how the message gets submitted in this manner and why the content-filters get bypassed.
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_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.
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.