Lot's of spam messages after upgrading to v0.52

#1

Since upgrading to v0.52, almost all the mails that are sent from my box via smtp on port 25 are marked as spam. They all contain a AR with spf=fail and dmarc=fail. This was not happening with v0.51 and before.

I must say that this is only happening for e-mails sent from domains other than the one my box is running from. Mails sent from this domain are not seen as spam. And do not have these fail headers.

How can I prevent these headers from being included (as was before v0.52) or, even better, what should I do to make these headers to show pass?

#2

SPF and DMARC authentication results are not headers added by MiaB to a message being sent out. They should only be added to messages that are received.

Maybe someone else can chime in, but without more data I don’t know how to troubleshoot a problem with authentication results on receiving headers other than to read them and then evaluate the SPF and DMARC records for your domain.

#3

Here is an example of a mail with these headers:

Return-Path: noreply@t3-platform.net
Delivered-To: hein@betanine.be
Received: from box.betanine.be ([127.0.0.1])
by box.betanine.be with LMTP id 6ARsKfesJmBUXQAAhc0L4w
for hein@betanine.be; Fri, 12 Feb 2021 17:29:43 +0100
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on box.betanine.be
X-Spam-Flag: YES
X-Spam-Level: ***********
X-Spam-Status: Yes, score=11.6 required=5.0 tests=BAYES_50,
DMARC_FAIL_QUARANTINE,FSL_HELO_NON_FQDN_1,HELO_NO_DOMAIN,RDNS_NONE,
SPF_FAIL,TO_EQ_FM_DOM_SPF_FAIL autolearn=no autolearn_force=no
version=3.4.2
X-Spam-Report:
* 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60%
* [score: 0.5000]
* 0.0 FSL_HELO_NON_FQDN_1 No description available.
* 5.0 SPF_FAIL SPF check failed
* 5.0 DMARC_FAIL_QUARANTINE DMARC check failed (p=quarantine)
* 0.8 RDNS_NONE Delivered to internal network by a host with no rDNS
* 0.0 HELO_NO_DOMAIN Relay reports its domain incorrectly
* 0.0 TO_EQ_FM_DOM_SPF_FAIL To domain == From domain and external SPF
* failed
X-Spam-Score: 11.6
Received: from prod-admin-server-1 (unknown [85.88.34.171])
by box.betanine.be (Postfix) with ESMTP id 8673E3FA03
for support@t3-platform.net; Fri, 12 Feb 2021 17:29:43 +0100 (CET)
Authentication-Results: box.betanine.be; dmarc=fail (p=quarantine dis=none) header.from=t3-platform.net
Authentication-Results: box.betanine.be; spf=fail smtp.mailfrom=noreply@t3-platform.net
Authentication-Results: box.betanine.be; dkim=none; dkim-atps=neutral

I hoope that helps.

#4

Are you using an external DNS? Are the spf and dmarc records published correctly?

I’m assuming you’re not sending email between domains on the MIAB which might suggest a different problem.

#5

You appear to be some kind of relay/proxy/spam server @ IP 85.88.34.171, or you are sending your email from t3-platform.net but through somekind of relay or server without authentication.

Share another message header if possible so we can diagnose.

refer to SPF fail on all incoming messages after upgrade 0.51 -> 0.52

#6

We can see:

and:

dig txt t3-platform.net +short
"v=spf1 mx -all"
dig mx t3-platform.net +short
10 box.betanine.be.

So you need to update your SPF record to include the different sending server if you want to correct this problem.

#7

First of all thank you all for looking into this!

Let me explain the situation. We have a MIAB server (box.betanine.be) running on a DO droplet for many years. This instance is used mail and DNS server for multiple domains including (of course) betanine.be but also t3-platform.net.

t3-platform.net is a track&trace platform that we host from our own servers in a datacenter in Brussels. All services run on tens of LXD containers and all use box.betanine.be to send out mails.

This is a situation that exists for many years, and so far all mails came through normally. But since the upgrade to v0.52, they are all marked as spam, and I see these headers in the mails that were not there before:

Authentication-Results: box.betanine.be; dmarc=fail (p=quarantine dis=none) header.from=t3-platform.net
Authentication-Results: box.betanine.be; spf=fail smtp.mailfrom=noreply@t3-platform.net
Authentication-Results: box.betanine.be; dkim=none; dkim-atps=neutral

What I would like to know is where these headers suddenly come from, and of course how I can avoid them. I don’t think that adding all my containers to the SPF string is the solution.

I also used mxtoolbox.com to check and I don’t see anything wrong with the DNS configuration for the domains.

The mails that have these headers are sent via a Java client and the service is defined the following (an example as there are many of these):

<SMTP name=“mail” subject="[T3 GIS Server] - Report" to=“t3-error@beta9.be” from="noreply@t3-platform.net"
smtpHost=“box.betanine.be” smtpPort=“25” bufferSize=“100” smtpUsername=“error-reporting@betanine.be”
smtpPassword=“xxxxxx”>
<PatternLayout pattern="%d{yyyy-MM-dd HH:mm:ss} %p: %x - %m%n"/>
</SMTP>

#8

I’m not quite clear on your situation. I assume you are talking about outgoing mail from MIAB. Then the receiving server (not your server) is marking mail items as spam, possibly because of SPF examination. Therefore I suggested checking the SPF records your system publishes are correct. As I understand it, the receiving server checks your published SPF record. That record proposes mail be quarantined if it does not match the expected sending server (i.e. your MIAB domain) header. So, it should not be MIAB adding these spam scores.

For incoming mail the situation is reversed. In that case MIAB would be adding the spam scores you mention. There was a potentially relevant change in release 0.52 in that case. From the change log:

  • 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.
#9

Digging into this a bit more and perhaps the setup is not quite a simple as I described.

It may be that OpenDKIM is being used to sign the outgoing mail by adding to the mail header, in which case my statement above is misleading.

I’m looking at the setup scripts changed in 0.52 to better understand the configuration.

setup/dkim.sh
setup/spamassassin.sh

Lines 67-92 and 70-119 respectively.

See also Domain Policy Records

May be worth getting on the slack channel or raising on Github to reach people with better knowledge.

#10

In this case the outgoing and incoming server are the same. The mails sent are from our domain t3-platform.net to our main domain betanine.be. But they are both hosted on the same MIAB instance running on box.betanine.be.

What I noticed is that not all mails are considered spam, and it seems that the ones that aren’t don’t have the Authentication-Results: headers. They are sent from a different mail client though (in Elixir and Smalltalk not Java). But they also use port 25 and a username/password to send the mail via box.betanine.be.

#11

The SPF and DMARC checks are performed by opendmarc and DKIM checks are performed by opendkim. These checks are performed on every email the server receives. If you are finding emails that aren’t being checked, were they received after the upgrade to .52? Because that would be interesting.

These checks are performed as per the RFCs, so if your mail is not passing it is not an MiaB issue, it is a sending issue. Anyone else receiving these emails on a different server that performs the same checks will experience the same results as MiaB (e.g., Google, Yahoo!, Microsoft, etc.).

Authenticated users are not “sending” mail in the same sense that a server is sending mail - that is why using a MUA via a residential ISP doesn’t generate all of the issues associating with sending mail from a residential ISP.

If creating an SPF record with all of your severs is not a reasonable solution for you (though do note that the include directive means to include the referenced SPF record, which is powerful option for subdomains used by a lot of the big mailers), another option is to use the login option for sending mail, though consider creating a different email address for each server so that in the event one of the servers is compromised you can easily know which one to shut down.

1 Like