But even if *I* don't use forwarding, one of my customers may. For example, if I need to email a customer of mine who is using, say, ieee.org forwarding, and it is redirecting to AOL, my SPF records will cause AOL to reject my message to my customer. The email recipient really has no control over any of the SPF records, since he owns none of the domains in question. I publish SPF records because we're forged constantly.
True, but I'd argue this situation is a problem with AOL's implementation of SPF checks, and it's something the AOL subscriber is going to have a lot of trouble with until it's fixed.
Eventualy the person using forwarding is not going to be able to get *any* email via the forwarder, at which point he's going to have to ask AOL to put ieee's forwarder on their exception list. Ether that or put it on a list of "trusted forwarding relays" so it knows to check the next Received: header back.
Really, for sites which implement SPF blocking, this is going to be a problem they WILL have to deal with. I'm quite sure you and your customer aren't going to be the only users in the world with the problem. Checkers will end up with implementation tweaks to avoid problems with this.
Worst case you could add ieee's forwarding servers to your SPF record on a temporary basis so you can send the guy an email telling him that AOL has issues with his forward and ask him to complain.
