SPF reject of valid mail that has gone through backup MX server.

[rct]

I have an offsite backup MX server to avoid bouncing mail if my connections or gateway are down. The problem is that i think pmg's SPF filter rejects all mail that has been relayed through the backup MX because it isn't part of the sender's SPF record.

So I'm confused about where the problem really is:

Is pmg's SPF checking problematic/too simplistic because it isn't checking the "envelope sender" (SMTP Mail From)" or first received header to determine the sender, rather than what ever relay server connects to PMG's postfix? It seems it has the assumption that mail will never be relayed along the way.

Should I just turn off pmg proxy SPF checking and let SpamAssassin do it? I didn't check if SA SPF checking is enabled by default in PMG, but this seems preferable since mail will be captured and quarantined instead of being rejected?

I think setting any sort of trust/white list for the external backup MX server is the wrong solution since all of the main that comes through it should be considered potential spam.

Thanks for any guidance.

 

[Onslow]

i think pmg's SPF filter rejects all mail that has been relayed through the backup MX because it isn't part of the sender's SPF record.

So I'm confused about where the problem really is:

Is pmg's SPF checking problematic/too simplistic because it isn't checking the "envelope sender" (SMTP Mail From)" or first received header to determine the sender, rather than what ever relay server connects to PMG's postfix?

Hi, @rct
The answers to these questions can probably be deducted from the logs, additionally compared with the headers of the problematic mails.

I'm not asking for posting them because there may be privacy concerns, on the other hand obfuscated logs and headers may be misleading. So first you may try to investigate them yourself.

 

[rct]

Sorry I wasn't clear. I understand what is happening, I'm looking for guidance on the best way of avoiding the problem.

The mail is being rejected because of SPF and the log is including the address of my backup MX host.

postfix/smtpd[653218]: NOQUEUE: reject: RCPT from my-mx-backup.com[66.zzz.yyyy.xxx]: 554 5.7.1 <user@mydomain>: Recipient address rejected: Rejected by SPF: 66.zzz.yyy.zzz is not a designated mailserver for bounce%40email.informeddelivery.usps.com (context mfrom, on pmghost); from=<bounce+foo@email.informeddelivery.usps.com> to=<user@domain>

The SPF reject is happening within Postfix, so I'm pretty sure this is the PMG proxy making the SPF decision. The host/IP address that I obsfucated are for the offsite backup MX server that will accept mail if my gateway isn't reachable.

I've tested that I can turn this behavior off via the GUI Configuration->Mail Proxy-> Options->Use SPF. But is turning off PMG proxy's SPF checking completely the best thing to do here or are there better options?

 

[Onslow]

I don't think that turning off SPF checking is the best solution.

(I'm thinking out loud): is a backup MX really needed nowadays?... What benefit would I gain from it?
When my main MX is unreachable, then a sending machine will queue messages destined for me.
If I have a backup MX, it will accept messages and queue them. In both cases I will not get the messages immediately.
Is the queue lifetime in the backup MX longer than the queue lifetime in any machine sending? Maybe. I don't know.
If I don't bring my main MX back to life before the queue lifetime expires, I will lose the messages anyway.

If you ascertain that you benefit from the MX, then you can ask yourself if it is properly secured against spam.

If yes, you can try to whitelist the backup MX regarding SPF checks.

I don't know if it's possible in the GUI. If you identify the rule responsible for the rejections you observe, you might be able to modify this rule so that it uses an additional "map" (a Postfix term) containing the IP address of the backup MX, so that it "okeys" connections from the backup MX.

Remember to use "templates" [1], not the "ordinary" configuration files. To avoid overwriting your modifications by the system updates.

[1] https://pmg.proxmox.com/pmg-docs/pmg-admin-guide.html#pmgconfig_template_engine