pypolicyd-spf

SPF Fail with valid MX Record

Asked by Karl Gustaff

Let's assume a multi-domain server with one mailserver - all of them with the same IP address.

mail.example.com as mailserver, and example.org as one example domain.

DNS (of example.org) looks like:
@ IN A ipv4
@ IN AAAA ipv6
@ IN MX 10 mail.example.com.
@ IN TXT "v=spf1 mx -all"

With my understanding, the SPF entry is valid and mails should not be rejected, because mx is allowed to send mails with domain example.org. The helo in SMTP is "mail.example.com".

By now, policyd-spf rejects mail with "Recipient address rejected: Message rejected due to: SPF fail - not authorized." while other mail servers (gmail) accepts messages and spf-checks on the internet accepts this SPF entry.

What is wrong? The SPF entry or is it a bug in the software (helo check before MX check)?

Question information

Language:
English Edit question
Status:
Solved
For:
pypolicyd-spf Edit question
Assignee:
No assignee Edit question
Solved by:
Scott Kitterman
Solved:
Last query:
Last reply:
Revision history for this message
Scott Kitterman (kitterman) said : 		#1

It's very difficult to answer without knowing the domain and the configuration you're using.

Please provide both the domain that was rejected (mail log entries preferred) and the configuration file for the policy server when it did the rejecting. I'll be glad to investigate.

If you don't want these things to be public, then use the Launchpad "contact this user" function to provide it to me directly.

Scott K

Revision history for this message
Karl Gustaff (gustaff) said : 		#2

Logs send.

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

Thanks for the logs. That clears it up.

The configuration is set to reject on SPF HELO fail, which is the result in this case.

If you look up the SPF record for the HELO name, it's:

v=spf1 mx:example.com -all

There is no mx record, so the record is effectively (See RFC 7208 paragraph 5.4 - the implicit MX rule does not apply to SPF):

v=spf1 -all

So it correctly fails.

Even if the implicit MX rule did apply, it would still fail.

Since this is an IPv6 connection (per the logs), a AAAA lookup would be done. The IPv6 address returned by that lookup is different than the connect IPv6 address, so fail is correct.

This could be resolved a few ways:

1. If you have control over DNS for the host sending the mail, you can update the SPF record. First, change from using mx: to using ip4: and ip6: for the sending host. Once you do that, you still have to deal with the IPv6 address mismatch. It is not unusual for hosts to use multiple IPv6 addresses. You could add a CIDR length to the ip6 mechanism to cover the range of possibilities (you will have to determine that).

2. If you don't have control over DNS for that domain, you can add the HELO hostname to the SPF HELO WHITELIST in your configuration file for the policy server, e.g. HELO_Whitelist = example.com.

I will send more details with domain names and addresses directly.

Scott K

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

Sorry. Looked again and the addresses do match, so the no MX record problem is the issue.

Revision history for this message
Karl Gustaff (gustaff) said : 		#5

A big thank you!

In my DNS configuration of example.com MX for subdomain was missing.

Before:
example.com IN MX 10 mail

After:
example.com IN MX 10 mail
mail IN MX 10 mail

Revision history for this message
Karl Gustaff (gustaff) said : 		#6

Thanks Scott Kitterman, that solved my question.