|
Yes, but only if the receiver checks SPF without understanding their mail receiving architecture. If receivers are going to check SPF, they should whitelist non-SRS forwarders from SPF checks.
| | 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.
|
|
Assuming the recipient does *not* whitelist forwarders, then the answer is: Yes, it does. 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|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.
| | 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|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.
| | 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.
| | 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 <code>.forward</code> file that says <code>foo@bar.com</code> |
| | Suppose you have a <code>.forward</code> file that says <code>foo@bar.com</code>.
|
| |
|
| If your system uses Procmail, you can replace the .forward with a .procmailrc that says:
| | ==== If your system uses Procmail...
... you can replace the <tt>.forward</tt> file with a <tt>.procmailrc</tt> file that says:
|
| |
|
| | > <pre>:0
* !^FROM_DAEMON
! foo@bar.com</pre>
The <code>!^FROM_DAEMON</code> is just a safety check --- if the <code>foo@bar.com</code> address bounces, the bounce won't cause a loop.
==== If you don't have procmail...
... the <tt>.forward</tt> file could instead just say:
> <pre>|/usr/sbin/sendmail -oi -f nobody@intermediate-domain.com foo@bar.com</pre>
This would make sure the sender address on bounces is "<code>nobody</code>", so if that bounce bounces, it would be junked. The address "<code>nobody@intermediate-domain.com</code>" should of course exist and be mapped to the bit bucket.
==== The most advanced solution...
... is to forward bounces unless they contain the "<code>X-Loop</code>" token or the forwarding address. This is better than the first form, which deletes all bounces, whether or not they'd cause a loop.
> <pre># loop protection
:0 fw
* !^X-Loop: foo@bar.com
| /usr/bin/formail -A'X-Loop: foo@bar.com'
:0 A
{
|
:0
| | :0
|
|
! foo@bar.com
| | ! foo@bar.com
|
| | :0 B
|
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 could instead just say "|/usr/sbin/sendmail -oi -f nobody@intermediate-domain.com foo@bar.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. |
| | ! foo@bar.com
}</pre>
This can even be combined with the above "<code>-f nobody</code>" 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.
|
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.
