On Fri, 2004-12-03 at 22:29, Frank Ellermann wrote:
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.
I'm seeing the advantage of using a reverse source route when forwarding
being that _trust does not need to be established at all_, but this is
also an advantage of SRS. Maintaining whitelists is a hassle, although
I've found that maintaining forwarding is a hassle also. Maintaining
two hassles does not sound appealing.
I find it interesting that SRS essentially implements reverse source
routes encoded in a different format (yes, I know the format chosen has
the advantage of directing those addresses to processes outside of the
MTA without having to modify the MTA to support SRS directly, so this is
a big win).