R_SPF_FAIL for valid SPF

From what we can see, it appears that rspamd checks are run against our own mailserver’s IP address, not against the actual origin.
I would expect the sending email server’s IP address to be evaluated and not our own.
This would explain why SPF rules are evaluated as invalid when they are not.
We have also seen SPF being treated as invalid for emails from domains that do not specify and SPF rules (as the domain in the following screen):

Joining in here, working at the same company as @onurb .
From the above record, we can see both an R_SPF_FAIL and a VIOLATED_DIRECT_SPF.
However, the domain in question does not provide any SPF:

kwisatz@thufir:~$ dig +short TXT projectbike.lu
"1|www.projectbike.lu"
kwisatz@thufir:~$ dig +short SPF projectbike.lu
kwisatz@thufir:~$ 

How can we get more verbose logs on SPF evaluation to see why, in this case, a non-existing record leads to those results?

Bumping this once more with additional information and a new example:

Here’s an email where SPF should have failed but it didn’t. Full headers with truncated recipient/faked sender:

Received: from vm3315861.24ssd.had.wf (localhost [127.0.0.1])
	by vm3315861.24ssd.had.wf (8.14.7/8.14.7) with ESMTP id 228I1YpU028785
	for <$USER@mga.lu>; Tue, 8 Mar 2022 20:01:34 +0200
Received: (from root@localhost)
	by vm3315861.24ssd.had.wf (8.14.7/8.14.7/Submit) id 228I1Ysc028765;
	Tue, 8 Mar 2022 20:01:34 +0200
Received: from mail.mymx.lu ([172.22.1.253])
	by 21ac8f7e1993 with LMTP
	id SMCnHQSaJ2LgZQAAlX/YNQ
	(envelope-from <root@vm3315861.24ssd.had.wf>)
	for <$USER@mga.lu>; Tue, 08 Mar 2022 19:01:40 +0100
Received: from vm3315861.24ssd.had.wf (vm3315861.24ssd.had.wf [80.89.229.175])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by mail.mymx.lu (Postcow) with ESMTPS id A8964305628
	for <$USER@mga.lu>; Tue,  8 Mar 2022 19:01:39 +0100 (CET)
From: "fax@mga.lu" <$USER@mga.lu>
To: <$USER@mga.lu>
Subject: =?UTF-8?Q?=E2=9C=85_Notification:_You_have_receive?=
	=?UTF-8?Q?d_a_new_fax_document_-_4_page=28s=29?=
Date: Tue, 8 Mar 2022 19:01:34 +0100
Message-ID: <202203081801.228I1Ysc028765@vm3315861.24ssd.had.wf>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0076_01D833C1.FEAD8900"
X-Last-TLS-Session-Version: TLSv1.2
X-Rspamd-Queue-Id: A8964305628
Authentication-Results: mail.mymx.lu;
	dkim=none;
	dmarc=none;
	spf=none (mail.mymx.lu: domain of root@vm3315861.24ssd.had.wf has no SPF policy when checking 80.89.229.175) smtp.mailfrom=root@vm3315861.24ssd.had.wf
X-Spamd-Result: default: False [7.33 / 15.00];
	BAYES_SPAM(4.50)[99.99%];
	NEURAL_HAM_LONG(-4.00)[-1.000];
	MX_MISSING(3.50)[];
	FORGED_W_BAD_POLICY(3.00)[];
	NEURAL_HAM_SHORT(-2.00)[-1.000];
	AUTH_NA(1.00)[];
	MV_CASE(0.50)[];
	MX_INVALID(0.50)[];
	MIME_HTML_ONLY(0.20)[];
	MIME_BASE64_TEXT(0.10)[];
	IP_REPUTATION_SPAM(0.03)[asn: 204601(0.00), country: NL(0.01), ip: 80.89.229.175(0.00)];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[$USER@mga.lu];
	MAILCOW_DOMAIN_HEADER_FROM(0.00)[mga.lu];
	RCPT_COUNT_ONE(0.00)[1];
	DMARC_NA(0.00)[mga.lu];
	R_SPF_NA(0.00)[no SPF record];
	FROM_HAS_DN(0.00)[];
	BCC(0.00)[];
	ASN(0.00)[asn:204601, ipnet:80.89.228.0/23, country:NL];
	ARC_NA(0.00)[];
	RCVD_COUNT_THREE(0.00)[3];
	FORGED_SENDER(0.00)[$USER@mga.lu,root@vm3315861.24ssd.had.wf];
	ARC_SIGNED(0.00)[mga.lu:s=dkim:i=1];
	TO_DN_NONE(0.00)[];
	HAS_DATA_URI(0.00)[];
	RCPT_MAILCOW_DOMAIN(0.00)[mga.lu];
	R_DKIM_NA(0.00)[];
	FROM_NEQ_ENVFROM(0.00)[$USER@mga.lu,root@vm3315861.24ssd.had.wf];
	RCVD_TLS_LAST(0.00)[];
	MIME_TRACE(0.00)[0:~];
	TO_EQ_FROM(0.00)[];
	GREYLIST(0.00)[pass,body]
Thread-Index: AQEJErZWwdpC62BIOKr5a7IHKqfbBg==

This is a multipart message in MIME format.

The most interesting part here is this one:

Authentication-Results: mail.mymx.lu;
	dkim=none;
	dmarc=none;
	spf=none (mail.mymx.lu: domain of root@vm3315861.24ssd.had.wf has no SPF policy when checking 80.89.229.175) smtp.mailfrom=root@vm3315861.24ssd.had.wf

There is no other mention of SPF. So here, only the originating server/envelope from was checked for SPF, but not the header from server which should IMHO at least also have been checked (If not, SPF is useless).

For mga.lu, an SPF record exists:

kwisatz@thufir:~$ dig +short TXT mga.lu
"v=spf1 a mx ~all"

Is this a configuration problem on our or mailcow’s side or is it an rspamd bug?

kwisatz SPF is checked on the return-path (aka envelope from), not the friendly from. Hence it’s checked against root@vm3315861.24ssd.had.wf NOT <$USER@mga.lu>. The former doesn’t have any SPF records, therefore R_SPF_NA(0.00)[no SPF record];

Hi faisal

Yes, indeed, I ignored that SPF was running against envelope-from. I didn’t know it was actually that useless in a way.

I also kept looking into the initial problem, and indeed, when I checked yesterday, the IP for that particular mailchimp server was not part of their SPF. Which is also astonishing.

kwisatz The creators realized that and subsequently created DKIM and DMARC, which when used together do prevent spoofing.