Exclude Backup MX hosts from SPF validation checks

This originated in a discussion with cPanel representatives in cPanel ticket#5426895.

Case:

We have two backup MX hosts and they're specified as such in the Exim

Configuration > access lists > backup MX hosts. We also have

"Reject SPF failures" On. When an email from a domain with strict SPF

ruleset (policy ending in -all) is relayed from either backup MX host, it

is rejected with a line like (real examples censored):

2014-09-05 06:57:28 H=BACKUP_MAILSERVER.OUR_DOMAIN.TLD [OUR_IP_ADDRESS]:30988

F=<USERNAME@REMOTE_DOMAIN.TLD> rejected RCPT <USERNAME@OUR_DOMAIN.TLD>:

SPF: OUR_IP_ADDRESS is not allowed to send mail from REMOTE_DOMAIN.TLD

This is unacceptable. The SPF check should have already occurred at the backup MX host to verify that the message is legitimate OR the SPF check should occur after it has been delivered by the backup MX host - the original delivery information should be used when the SPF check occurs. In either case, the point is to cut out the SPF check that occurs when transferring from backup to primary MX. When the backup MX host goes to deliver it to the primary MX, the SPF needs to be excluded, otherwise, it will never pass (because the remote host has no way to give permission to our backup MX, or all cPanel backup MX servers, to deliver mail on their behalf).

Why will it never pass? Because a remote host will NEVER have the destination host's IP explicitly set in their SPF rule. Why? Because there are millions of possibilities for remote hosts. No one is going to manually whitelist the entire internet. That's what SPF is used to simplify.

Why can't you disable SPF checks? SPF checking is extremely necessary for domain ownership validation when sending mail and vital to fighting spam. Removing it should only be done when it is blocking messages en masse, due to a bug or misconfiguration. Also, it cannot be disabled on a per-domain or per-email address basis.

Can't you implement SRS to fix this problem? SRS is used to fix a bug with SPF when forwarding messages from one domain to another. This is a different situation that applies to a more transparent, local handoff of the message.

Why can't you just whitelist your backup MX server in some configuration? Spammers often target backup MX servers directly because they know that they have less security on them. Thus, in some conditions, excluding the backup MX servers from checks will allow spam.

Possible workarounds have been given, but no solution is possible without cPanel coding intervention. cPanel representatives suggested all of the following (these are quotes from cPanel reps):

• This page lists some options, although installing third party options might cause problems. http://www.tldp.org/HOWTO/Spam-Filtering-for-MX/exim-spf.html
• The second option here seems the best, although I have not tested it:
• You would list the hosts that are forwarding to the backup MX in
  sender_domains and then edit the final ACL statement to disregard SPF if
  the host matches:
  http://www.exim.org/exim-html-current/doc/html/spec_html/ch-access_control_lists.html#SECTaclconditions
• You might want to use this to make sure the changes are permanent:
  http://documentation.cpanel.net/display/ALD/The+Exim+Advanced+Editor
• Would it be possible to include the Backup MX IPs in your SPF record for
  the affected domain? You could add [your IP address] to the SPF record
  which would then allow emails to come from that IP for that domain.
• The only other option would be to disable 'Reject SPF failures'. This
  however would apply to all email/domain globally for the server. You can
  do this by going to your WHM panel: WHM >> Service Configuration >> Exim Configuration Manager -- and under the ACL Options tab you'll see this option.
• ...add the [remote] host to the Trusted SMTP IP
  addresses list.
• The other option I thought of was, which may require a bit more work,
  would be to create a custom Exim filter on the destination server which
  would check the host and if it matched an IP in a given list Exim could
  then skip just the SPF check for that piece of incoming mail. That sort
  of solution would be custom though and something you'd have to put
  together from your end.