Should This Be SPF Fail?

[gix0970]

Looking into this email header, why SPF_PASS?
The sending IP address 117.131.83.161 is not authorized for njcb.com.cn and cupdapp.com doesn't have SPF record

Return-Path: <[email protected]>
Delivered-To: real_recipient+spam@my_domain.com
Received: from my_server.my_domain.com
by my_server.my_domain.com with LMTP
id PKI/JPRUsWJaSQAAK+L+Iw
(envelope-from <[email protected]>)
for <real_recipient+spam@my_domain.com>; Tue, 21 Jun 2022 13:19:48 +0800
Return-path: <[email protected]>
Envelope-to: real_recipient@my_domain.com
Delivery-date: Tue, 21 Jun 2022 13:19:48 +0800
Received: from [117.131.83.161] (port=38472 helo=stmt.cupdapp.com)
by my_server.my_domain.com with esmtp (Exim 4.94.2)
(envelope-from <[email protected]>)
id 1o3WIi-0004rv-LO
for real_recipient@my_domain.com; Tue, 21 Jun 2022 13:19:48 +0800
Message-ID: <1-0424-20220621-121002-2167800014>
From: =?utf-8?B?5Y2X5Lqs6ZO26KGM5L+h55So5Y2h?= <[email protected]>
To: <real_recipient@my_domain.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="1-0424-20220621-121002-2167800014"
Content-Disposition: inline
Date: Tue, 21 Jun 2022 13:19:02 +0800 (CST)
X-Spam-Status: Yes, score=5.5
X-Spam-Score: 55
X-Spam-Bar: +++++
X-Spam-Report: Spam detection software, running on the system "my_server.my_domain.com",
has identified this incoming email as possible spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
root\@localhost for details.
Content preview: 万事达 尊敬的 王延安 女士 ，您好！ 以下是您的南京银行标准信用卡账户06月电子账单，登录手机银行或者微信银行皆可查询更多账单信息。
账 单 日 2022-06-2 [...]
Content analysis details: (5.5 points, 5.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60%
[score: 0.5000]
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 HTML_MESSAGE BODY: HTML included in message
1.5 BASE64_LENGTH_79_INF BODY: base64 encoded email part uses line
length greater than 79 characters
0.0 T_TVD_MIME_NO_HEADERS BODY: No description available.
2.0 RDNS_NONE Delivered to internal network by a host with no rDNS
0.6 INVALID_MSGID Message-Id is not valid, according to RFC 2822
-0.0 T_SCC_BODY_TEXT_LINE No description available.
0.7 LONG_INVISIBLE_TEXT Long block of hidden text - bayes poison?
X-Spam-Flag: YES
Subject: ***SPAM*** =?utf-8?B?5Y2X5Lqs6ZO26KGM5qCH5YeG5L+h55So5Y2h6LSm5oi355S15a2Q6LSm5Y2V?=

 

[ejsolutions]

Good question!

njcb.com.cn SPF record: v=spf1 ip4:221.226.46.160/27 ip4:58.240.77.160/28 ip4:222.190.247.0/24 ip4:153.3.162.0/24 ip4:36.152.55.0/24 -all

 

[cPRex]

As @ejsolutions mentioned, I'm not seeing anything wrong with the SPF record as your domain passes all tests. Since that isn't the IP of the domain itself nor any of the IP addresses listed in the record, I wouldn't expect that to pass. Was that a cPanel Exim mail log you posted?

 

[sparek-3]

The SPF record for message.njcb.com.cn has two includes:

message.njcb.com.cn. 3600 IN TXT "v=spf1 include:stmtspf.cupddns.com include:stmtspf.cupddns.net -all"

Neither SPF record for stmtspf.cupddns.com or stmtspf.cupddns.net has a definition for all. Perhaps that's why it's passing?

 

[ejsolutions]

Neither SPF record .. has a definition for all. Perhaps that's why it's passing?

Good find; that's piqued my curiosity.
I'm sure that I've seen a tool (mxtoobox?) that does SPF "expansion" i.e. concatenates the includes as one record, as seen by mail servers. I have always assumed that the "all" statement at the end would provide full termination, even with includes.

 

[cPRex]

I'm not seeing any examples here where they show multiple "all" handlers for each included URL.

 

[ejsolutions]

Agreed and it indicates that my assumption is correct, in that the top level (above the includes) is parsed with no need for "-all" in the includes. (If that makes some sense.)

For example, evaluating a "-all" directive in the referenced
record does not terminate the overall processing and does not
necessarily result in an overall "fail".