SPF Softfail rejecting mail

Asked by James B. Byrne

OS CentOS-6.5 (centos)
Postfix-2.11.1 (in house)
pypolicyd-spf.noarch-1.2-3.el6 epel

We are seeing this in our maillog:

NOQUEUE: reject: RCPT from STCTON10-1176245516.sdsl.bell.ca[70.28.21.12]: 550 5.7.1 <email address hidden>: Recipient address rejected: Received-SPF: Softfail (domain owner discourages use of this host) identity=helo; client-ip=70.28.21.12; helo=remote.henryofpelham.com; <email address hidden>; <email address hidden> ; from=<email address hidden> to=<email address hidden> proto=ESMTP helo=<remote.henryofpelham.com>

Our config file has these settings:

HELO_reject = SPF_Not_Pass

# HELO pass restriction policy.
# HELO_pass_restriction = helo_passed_spf - Apply the given restriction when
# the HELO checking result is Pass. The given restriction must be an
# action as defined for a Postfix SMTP server access table access(5).
#HELO_pass_restriction

# Mail From rejection policy. Options are:
# Mail_From_reject = SPF_Not_Pass - Reject if result not Pass/None/Tempfail.
# Mail_From_reject = Softfail - Reject if result Softfail and Fail
# Mail_From_reject = Fail - Reject on Mail From Fail (default)
# Mail_From_reject = False - Never reject/defer on Mail From, append header only
# Mail_From_reject = No_Check - Never check Mail From/Return Path.
Mail_From_reject = Fail

The sender's SPF looks like this:

remote.henryofpelham.com. 14400 IN TXT "v=spf1 mx ptr mx:remote.henryofpelham.com ~all"

As far as I can see a softfail should not reject this mail. Why is it doing so?

Question information

Language:
English Edit question
Status:
Solved
For:
pypolicyd-spf Edit question
Assignee:
No assignee Edit question
Solved by:
James B. Byrne
Solved:
Last query:
Last reply:
Revision history for this message
James B. Byrne (byrnejb) said :
#1

Never mind. I think I see the problem:

HELO_reject = SPF_Not_Pass

s/b

HELO_reject = Fail

Revision history for this message
James B. Byrne (byrnejb) said :
#2

That was it

Revision history for this message
Scott Kitterman (kitterman) said :
#3

If that's a problem, then they have a bad setup, so you may want to contact them. HELO should never be anything other than pass/none.

Revision history for this message
akirk (q-launchpad-p) said :
#4

I was running into this too. I am not sure why HELO_reject = SPF_Not_Pass is the default as it rejects mail when it shouldn't.

Also the openspf.org/Why page states for such a case: "The domain xy.com has declared using SPF that it does not send mail through 1.2.3.4. However, the domain is still testing its SPF policy, so the message should not have been rejected."

So in my opinion the default should be changed to: HELO_reject = Fail

Revision history for this message
Scott Kitterman (kitterman) said :
#5

The failure cases referred to in the FAQ aren't generally relevant to HELO testing. That's been the default for about 7 years and I only recall one other case where it was an issue. Since a record being used for the HELO identity should only refer to one host, it's very rarely wrong. I understand your point, but it seems to work for most people as is.

Revision history for this message
James B. Byrne (byrnejb) said :
#6

Well, seven years ago the number of large organisations using SPF was rather less than today. And large organisations tend not to respond quickly to request for changes to their DNS zone files. For one example we have been trying to get the LCBO (Liquor Licensing Board of Ontario) to fix their spf record since May 20. And LCBO is just one of several large organsations that we have to whitelist through because of poorly configured spf records that these entities seem unable or unwilling to fix.

Revision history for this message
Scott Kitterman (kitterman) said :
#7

Are there others you're whitelisting due to HELO related issues? For Mail From, that doesn't particularly surprise me.

Revision history for this message
James B. Byrne (byrnejb) said :
#8

Yes, there is one other HELO problem child that has mobile users. We cannot get them to fix their spf record either as they claim support is done by a third party provider whom they will not name.

Revision history for this message
Scott Kitterman (kitterman) said :
#9

OK. Thanks. Let me think about it.