Andy Bakun wrote:
Is it actually impossible to resurrect something that
previous RFCs have depreciated? Harder than trying to get
something else/new deployed?
More or less, and yes. For Meng's concept of a "local white
list" you could offer it as an option, if both sides agree to
use it, something like this:
1 - Forwarder accepts MAIL FROM:<me> RCPT TO:<user(_at_)forward>
2 - Forwarder knows that it should relay this mail to say
RCPT TO:<secret(_at_)buddy>
3 - Forwarder knows that the MX @buddy has white listed his
HELO forward, and supports source routes (that could be
stored together with the .forward of user(_at_)forward)
4 - HELO forward MAIL FROM:<@forward:me> RCPT TO:<secret(_at_)buddy>
5 - @buddy recognizes HELO forward and bypasses all further
SPF tests accepting the mail for secret(_at_)buddy
6 - shit happens (e.g. secret(_at_)buddy over quota), now @buddy
returns MAIL FROM:<> RCPT TO:<me> back to MX @forward
7 - @forward recognizes HELO buddy and relays the bounce to
me, all is well
For the last step the white-list has to be mutual. In Meng's
original concept that's unnecessary, because without a reverse
path the bounce would go directly to my MX in step 6. Where
is the advantage of adding a reverse route in this scenario ?
The most important point is always the local white list, the
trust between forwarder and the final resp. next destination.
Bye, Frank