After upgrading to 0.52 I’m seeing SpamAssassin throwing SPF failures on almost all incoming messages. Here’s a header snippet showing the SpamAssassin results for a recent message from this forum. I’ve verified that this was not happening just before the upgrade. Is anyone esle seeing this behavior?
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on my.ictech.email
X-Spam-Level: **
X-Spam-Status: No, score=2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,DMARC_PASS,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,
SPF_FAIL,SPF_HELO_NONE autolearn=no autolearn_force=no version=3.4.2
X-Spam-Report:
* -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
* [score: 0.0000]
* -0.1 DMARC_PASS DMARC check passed
* 5.0 SPF_FAIL SPF check failed
* -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/,
* low trust
* [5.79.86.42 listed in list.dnswl.org]
* 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
* 0.0 HTML_MESSAGE BODY: HTML included in message
* 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily
* valid
* -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
* -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
* author's domain
X-Spam-Score: 2.2
Received: from smtp.techsecure.com (unknown [10.132.169.75])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
(No client certificate requested)
by my.ictech.email (Postfix) with ESMTPS id A609EFC2B8
for <lww@ictech.net>; Mon, 8 Feb 2021 22:47:18 -0500 (EST)
Authentication-Results: my.ictech.email; dmarc=pass (p=quarantine dis=none) header.from=discourse.mailinabox.email
Authentication-Results: my.ictech.email; spf=fail smtp.mailfrom=notifications@discourse.mailinabox.email
Authentication-Results: my.ictech.email;
dkim=pass (2048-bit key; secure) header.d=discourse.mailinabox.email header.i=@discourse.mailinabox.email header.b="GTYc7gvO";
dkim-atps=neutral
This is strange because MX record of discourse.mailinabox.email is box.occams.info. My emails from this forum is also via this server. Following is the record from one of my mails.
Received: from authenticated-user (box.occams.info [94.76.202.152])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
(No client certificate requested)
by box.occams.info (Postfix) with ESMTPSA id 35DD92A3EA
Did you do some email forwarding/redirecting from techsecure? You are behind spamexperts.net or antispamcloud or some antispam facility behind your box? Your mx record doesn’t seems to have pointed to your mailinabox setup directly.
You may not have noticed this but the new version has higher spam score for fail SPF, which means you may not detected the failed SPF previously. Hence, if you relay your email through the spam service, then your SPF will likely fail for all your mails ( settings compatibility issues)
Incoming emails with SPF/DKIM/DMARC failures now get a higher spam score, and these messages are more likely to appear in the junk folder, since they are often spam/phishing.
Incoming email passes through an external spam filter service before being relayed to the mailinabox system. However, this has always been the setup and hasn’t changed.
Yes, I did see the spam score change item in the release notes, but that’s not the problem, at least not directly, because this isn’t really a SpamAssassin issue, and there was no failure flagged by SpamAssassin before v0.52. The real culprit is that mailinabox is now inserting a new Authentication-Results header:
I don’t see any Authentication-Results headers generated by mailinabox for SPF in messages received prior to the 0.52 upgrade. DMARC & DKIM headers, yes, but not SPF. There is already an SPF pass Authentication-Results header generated by the MTA at the filter service:
So, I guess what I’m looking for is how to get back to the pre-0.52 behavior. Basically I don’t need an SPF check at the time mailinabox receives the message, as that has already been done.
I’ve created a workaround by editing /etc/mail/spamassassin/miab_spf_dmarc.cf to have SpamAssassin use the antispamcloud.com generated header for SPF scoring:
great if it works for you, remember to book mark this page, when the next update comes and this get overwritten, you may need to remind yourself to change the settings again.
alternatively since you already have a spam filter at your door, sudo service spamassassin stop and save some memory if you don’t need it.
So it appears this is expected behavior and is Spamassassin. If this truly affecting “almost all incoming messages”, then you have some sort of configuration that is not following the RFCs and my recommendation would be to evaluate this.
Yes, it’s the expected behavior of SpamAssassin given the config changes made in 0.52, but it’s not what I want to happen. My incoming messages already have an SPF Authentication-Results header, so I don’t need or want a new SPF check.
My final solution is to leave /etc/mail/spamassassin/miab_spf_dmarc.cf alone. Instead I am just removing ‘SPFIgnoreResults true’ from /etc/opendmarc.conf like so:
--- opendmarc.conf.miab 2021-02-03 15:07:50.273240749 -0500
+++ opendmarc.conf 2021-02-09 11:09:41.858936353 -0500
@@ -113,5 +113,4 @@
## the named userid unless an alternate group is specified.
#
UserID opendmarc
-SPFIgnoreResults true
SPFSelfValidate true
This restores the default value of ‘false’ for ‘SPFIgnoreResults’, eliminates the redundant SPF check, which always fails, and gets me back to pre-0.52 behavior with minimal customization.