Email forwarding is a problem no matter which way you handle it. The problem arises from the increasingly widespread use of SPF. SPF is supposed to be optional, but an email forwarder that doesn't do anything about SPF can still run afoul of it.
I have set up a few addresses that forward from domains I own, to addresses at gmail.com or yahoo.com or wherever. I have set them up using Postfix virtual domains. My Postfix server receives and accepts the email, then turns around and resends it along to (for the sake of example) yahoo.com. The message headers and SMTP envelope remain unchanged except for the addition of a "Received:" header.
When yahoo.com receives the message, it will do an SPF lookup on the SMTP envelope-from domain to find out whether the connecting SMTP server (my server) is allowed by the sender's SPF policy. If the sender does not publish SPF, then the test would be assumed to pass. However, if the sender publishes an SPF policy, it's not likely to include my server, and therefore yahoo.com may recognise an SPF fail situation.
For the sake of simplicity, consider two messages: A legitimate one from somebody at sender.com, and a spam message with a forged header from somebody at forged.com.
|Legitimate message from sender.com (without SPF)||Message accepted with no adverse effects.|
|Legitimate message from sender.com (with SPF)||Message fails SPF test, possibly rejected.|
|Spam message apparently from forged.com (without SPF)||Message accepted, but yahoo.com filters the message as spam and my server is marked as a spam source.|
|Spam message apparently from forged.com (with SPF)||Message fails SPF test, my server is marked as a spam source.|
This state of affairs doesn't look so good for me, the guy stuck in the middle. This has been a long standing problem, and Sender Rewriting Scheme (SRS) is supposed to be a way to fix it. Under SRS, my forwarding server would change the SMTP envelope-from to a (specially constructed) address under my own domain. In general, this would ultimately cause yahoo.com to not process an SPF fail on messages forwarded from my server, since the SPF test would be run using my own domain's SPF record. However:
|Legitimate message from sender.com||Message accepted with no adverse effects.|
|Spam message apparently from forged.com||Message accepted, but my server is marked as a spam source. Also, since my server has accepted some responsibility for the message by using SRS, my domain may be tagged as a spam source too. There's nothing in SRS that says spammers can't forge it too, as far as the receiver is concerned.|
Using SRS makes the situation where a legitimate sender.com publishes an SPF record, not so bad for me as the forwarder. This of course is the situation for which SRS was designed. However, in the case of a forged-sender spam message, it's a lose-lose situation. SRS does not help in this case. The only thing I can do is only forward legitimate mail, and block all spam mail. If I could do that automatically and reliably ... well, I can't.
The above situation is not hypothetical. My mail server currently has trouble sending to yahoo.com (messages can be delayed for hours), because there has apparently been enough spam relayed through my server in the direction of yahoo.com for them to mark my server as a spam source. The only thing I can do is try to implement stronger automatic spam-blocking on forwarded email. If you run a mail forwarder and you forward spam, you're screwed.