Sender Policy Framework

Does SPF break forwarding?

Yes, but only if the receiver checks SPF without understanding their mail receiving architecture. If receivers are going to check SPF, they should whitelist forwarders that do not rewrite the sender address from SPF checks.

Stuart Gathman's opinion is recorded at http://archives.listbox.com/spf-discuss@v2.listbox.com/200410/0488.html and updated here.

Assuming the recipient does not whitelist forwarders, then the answer is: Yes, it does break forwarding. You (the forwarder) will have to switch from forwarding, where the envelope sender is preserved, to remailing, where the envelope sender is changed. But don't worry, there are SRS plugins for major opensource MTAs. There are also SRS patches in the works for four major opensource MTAs, so that when you upgrade to an SPF-aware version, this problem will be solved also.

If your forwarding runs through a commercial service like pobox.com, you shouldn't have to do anything. They have to change with the times, and perform the above rewriting automatically for you. SRS is a structured standard that helps them adapt.

Workarounds

If you can't use any of the available plugins or patches, the following workarounds will preserve the important functionality for end-users on systems with Procmail.

Suppose you have a .forward file that says foo@bar.com.

If your system uses Procmail...

... you can replace the .forward file with a .procmailrc file that says:

:0
* !^FROM_DAEMON
! foo@bar.com

The !^FROM_DAEMON is just a safety check — if the foo@bar.com address bounces, the bounce won't cause a loop.

If you don't have procmail...

... the .forward file could instead just say:

|/usr/sbin/sendmail -oi -f nobody@intermediate-domain.com foo@bar.com

This would make sure the sender address on bounces is "nobody", so if that bounce bounces, it would be junked. The address "nobody@intermediate-domain.com" should of course exist and be mapped to the bit bucket.

The most advanced solution...

... is to forward bounces unless they contain the "X-Loop" token or the forwarding address. This is better than the first form, which deletes all bounces, whether or not they'd cause a loop.

# loop protection
:0 fw
* !^X-Loop: foo@bar.com
| /usr/bin/formail -A'X-Loop: foo@bar.com'
:0 A
{
    :0
    * !^FROM_DAEMON
    ! foo@bar.com
    :0 B
    * !foo@bar.com
    ! foo@bar.com
}

This can even be combined with the above "-f nobody" solution, although if the forwarding bounced once, there usually isn't much point in trying to forward the resulting bounce again, so delivering locally (at the forwarding site) would then be better... but that assumes that this is possible.