It seems to me that there are only two choices to "Solve" the forwarding
problem relative to checking the return-path with SPF:
1. Bounces go directly back to the originator (don't change the
return-path).
To avoid return-path failures in this scenario, the forwarder has to be
whitelisted. The question is how to do that most reliably.
2. Bounces go back to the forwarder (forwarder changes the return-path).
Here, the forwarder can either accept and process the bounces locally or
forward them back to the actual originator as in SRS.
No one seems to be that excited about rewriting return-path, so we turn to
the idea of SUBMITTER (or some other process) to aid whitelisting.
The Processed-By proposal would seem to require that I trust the remote
processor (forwarder) and believe that it's characterization of the previous
path of the message is correct. If I trust the forwarder not to lie about
where it got the message, why can't I just whitelist an SPF classic checking
forwarder that I trust and be done with it.
I think finding a way to build a 2821 based SUBMITTER that projects an
appropriate identity into 2822 (the opposite of the MS PRA proposal) is a
good way to aid whitelisting. I'm not sure what Processed-By would add in
terms of actionable information.
Scott Kitterman