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?
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.
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.
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:
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):
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.
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.
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.