Cloudron SPF record does not permit IP

[girish]

@jaschaezra It shouldn't affect mail delivery, afaik. As @ccfu said, the check is carried out by the receiving mail server and as such the added meta headers have no effect. But it's not desired to add the Client IP, that I agree. You can check this by sending mails to https://www.mail-tester.com/

[ccfu]

@matix131997
Interesting. I still can't get my head around why the recipient mailserver is incorrectly evaluating the client IP and not the server IP in the SPF record though. The mail is not being sent to the recipient by the client but by the SMTP server.

[matix131997]

@girish This is the result:

[girish]

@matix131997 Yup, so the SPF is valid. The email header is only the results of Haraka/Cloudron mail server. This is not considered by the destination server.

[RoundHouse1924]

I have the exact same problem --- only since updating Cloudron to v7.4.1 from v7.3.6.
So, this has clearly been introduced by v7.4.x.

SPF is more important than @staff are making out above.

Fundamentally, the point is that the SENDING Haraka/Cloudron is guilty of injecting the wrong header SPF details into OUTGOING emails.

This needs a rapid solution, as domain and server reputation is at stake!

[ccfu]

@RoundHouse1924

Nobody seems to be suggesting that SPF is not important but the SPF details are not injected by Cloudron or Haraka at all. These details are set in the domain's DNS records and can be checked by the receiving SMTP server when processing incoming email.

If a receiving mailserver is checking the wrong headers then it is misconfigured. Alternatively, the SPF record may be incorrect.

[RoundHouse1924]

@ccfu said in Cloudron SPF record does not permit IP:

SPF details are not injected by Cloudron or Haraka at all

If so, then how come I can trace the origin of this problem to the Cloudron update to v7.4.1 from v7.3.6 ?

[ccfu]

What exactly has changed? Are mailservers suddenly rejecting emails you are sending to them? If so, from which mail clients?

[girish]

Yes, this is indeed some new information @RoundHouse1924 . What exactly has changed between 7.3.6 and 7.4.1 for you? Are mails getting reported as Spam now?

SPF is more important than @staff are making out above.

SPF is very important. I think you have misread the messages/posts. The "it" in many places is referring to the header in the email message. This header is not used for SPF validation.

[RoundHouse1924]

@girish
None of my outgoing mail is being rejected, but headers contain the following (first example sending from Thunderbird on Linux; second example sending from FairEmail on Android):-

received-SPF: Fail (my.sharona.cloud: domain of groveland.place does not designate 138.199.6.239 as permitted sender) receiver=my.sharona.cloud; identity=mailfrom; client-ip=138.199.6.239 

Authentication-Results: my.sharona.cloud;
	auth=pass (plain);
	spf=fail smtp.mailfrom=groveland.place

Received-SPF: Fail (my.sharona.cloud: domain of citharas.org does not designate 86.15.69.112 as permitted sender) receiver=my.sharona.cloud; identity=mailfrom; client-ip=86.15.69.112 

Authentication-Results: my.sharona.cloud;
	auth=pass (login);
	spf=fail smtp.mailfrom=citharas.org

In both cases, the IP addresses belong to the sending mail client, not the server.

One of the 3 domains hosted uses an external relay, the other 2 use the internal SMTP.

Also, each domain's SPF record uses minus all, not tilde all --- so any rejection is not just a softfail:-

TXT 	v=spf1 a:my.sharona.cloud -all

Although nothing is rejected by the receiving server, receiving clients show:-

FairEmail shows a waving flag, as per its FAQ:-
"...FairEmail can show a small red warning flag when DKIM, SPF or DMARC authentication failed on the receiving server. You can enable/disable authentication verification in the display settings"
https://github.com/M66B/FairEmail/blob/master/FAQ.md

The DKIM Verifier Thunderbird extension shows "SPF: fail"
https://addons.thunderbird.net/en-GB/thunderbird/addon/dkim-verifier/

So, the bottom line of all this is that the headers incorrectly show that the mail client is the authorised sender. Clearly, as the message passes through the Cloudron mail server (since v7.4.x), something is processed in a manner to cause this.

Hope all this makes sense!

[girish]

@RoundHouse1924 Thanks for the detailed write up, let me investigate further.

[ccfu]

@RoundHouse1924

That definitely isn't normal or correct behaviour. However: my.sharona.cloud is your sending mailserver, correct? The SPF fail shown is not a result of a check the receiving server is making then.

I noticed something similar in a mail I just sent as a test from Outlook to a Gmail address. An SPF fail was also present in the headers (checked by Haraka using the IP of the Outlook client) but there is also (as expected) an SPF pass for the server IP, as that is what was checked by the receiving SMTP server. In other words I don't see a risk that mail delivery will fail due to SPF checks, but it would still be important to identify why Haraka is doing this.

[panthrosrevenge]

I would also like to add that I have been seeing this behavior as well. I am getting SPF failures for IP mismatch as the header is showing the IP of whatever client is sending email, not the SMTP server.

[ccfu]

@panthrosrevenge

SPF fails reported by your own server though, right?

[panthrosrevenge]

@ccfu I'm seeing the sending clients IP address in the headers instead of the cloudron SMTP server. This causes an SPF failure as the client IP isn't an authorized sender for the domain.

[ccfu]

@panthrosrevenge

Yes, I get that, but which server is failing it? Your mailserver or the recipient's? Look again at the header and you will most likely see two SPF checks - one by your mailserver, which fails (that is the problem described in this thread) and one by the receiving mailserver which should be checking your server IP and should therefore pass.

[panthrosrevenge]

@ccfu It's the recipient's server that's showing the sending client's IP in the header. Mail is going through ok besides getting a soft fail on SPF and raising spam score

[ccfu]

@panthrosrevenge

Yes, but the incoming mail would show the header anyway if it is being sent by your server. Sorry to ask again, but are you sure the sending client IP is really being checked by the recipient SMTP server? That would mean that either your mailserver is not even sending the server IP when it connects, which I find hard to believe and would be concerning, or the recipient's mailserver is misconfigured.

On the line in the header showing the softfail, which of the following appears?:

1. received-SPF: SoftFail (**YOUR MAILSERVER**: domain of **yourdomain.tld** does not designate **IP** as permitted sender) receiver=**YOUR MAILSERVER**

or

2. received-SPF: SoftFail (**RECIPIENT MAILSERVER**: domain of **yourdomain.tld** does not designate **IP** as permitted sender) receiver =**RECIPIENT MAILSERVER**

[panthrosrevenge]

Here's my header showing the SPF failure. I'm using mxtoolbox.com for testing. I'm also using Sendgrid as an SMTP relay with an API key. Sending domain is different than the MX domain as I have a couple different domains I send email from.

Received: (Haraka outbound); Sun, 07 May 2023 15:40:12 +0000
Authentication-Results: mymxdomain.com;
auth=pass (plain);
spf=softfail smtp.mailfrom=sendingdomain.com
Received-SPF: SoftFail (mymxdomain.com: domain of sendingdomain.com does not designate sending client public IP as permitted sender) receiver=mymxdomain.com; identity=mailfrom; client-ip=sending client public IP helo=[LAN IP]; envelope-from=<mailbox@sendingdomain>
Received: from [LAN IP] ([sending client public IP])
by mymxdomain.com (Haraka/3.0.1) with ESMTPSA id 6F7C9FA2-9E4D-4C74-932F-D177277F2FCC.1
envelope-from <mailbox@sendingdomain.com>
tls TLS_AES_256_GCM_SHA384 (authenticated bits=0);
Sun, 07 May 2023 15:40:12 +0000

[ccfu]

@panthrosrevenge

As I suspected, that is Haraka on your own server softfailing the client IP. The recipient SMTP server should only be checking the Sendgrid IP and passing it as long as it is included in the SPF record for the domain in question.