On Fri, 2004-12-03 at 18:20, wayne wrote:
Why did we stop exploring reverse source routing as a "solution" to
forwarding?
Mostly because the language in RFC2821 basically says that source
routes SHOULD NOT be created and the routing they imply SHOULD be
ignored. So, the use of source routes instead of SRS-like encoding is
in violation of RFC2821. It's use will be unreliable, at best.
Well, yes. But note the use of SHOULD [NOT] -- this is both the bane
and the advantage of using reverse source routes in this context. The
bane because it's unreliable. The advantage because it is something
that many people already understand.
Is it actually impossible to resurrect something that previous RFCs have
depreciated? Harder than trying to get something else/new deployed?
Could a new RFC depreciate the depreciation (partial resurrection, with
something along the lines of what I outlined for when proper use of
reverse source routes are allowed (from null, HELO passes SPF checks,
internal database of recently forwarded sender-receiver pairs) and would
that be easier for people to accept than something completely new.
The paragraphs you quote talk about the problems with source routes used
for forward routing -- the sender being able to specify the route mail
takes, which is useless in the context of MX records -- and thus why
it's suggested not to use it. But do the problems of source routes
translate accurate to reverse source routes? Really, the same thing,
with the same syntax, but used in two different ways and constructed
using two different methods.
Really, the biggest problem is deployment -- supporting reverse source
routes is not site-independent. Unlike SRS, which is largely a change
made only by those who are actively performing forwarding. Although,
for sites that are forwarding, where forwarding is a single hop, the
only party that needs to support reverse source routing is the
forwarding system. The sender still using a bare, no source routes
address, and the receiver ignoring (because of the SHOULD) any routes in
the return path and send any DSNs directly to the sender (using it's own
HELO and FROM <> and thereby also pass SPF). SPF checking systems
should check the most recent hop when there are multiple hops in the
reverse source route. This would give us EXACTLY what we have today (in
terms of world-wide deployment of authorization checks), but would lay
the ground work for, once more MTAs are updated, sending DSNs back
through the full reverse source route with full SPF checks and
rejections of DSNs for non-forwarded mail. Once there is wider
deployment the MUST in the last sentence in the second paragraph of RFC
2821 section 6.1 can be relaxed.
I know someone posted to this list, a long while ago, the average number
of hops forwarded email takes before finally appearing in a mailbox --
but the value escapes me and I can't find the reference. If it's any
more than about 1.1 or 1.2, an easy deployment of using reverse source
routes for forwarding might be difficult. But because of the SHOULD, it
is something that dedicated forwarders might be able to implement and
deploy sooner and independent of everyone else. It could even be as
reliable as "if delivery is attempted with a reverse source route in
MAIL FROM gets rejected, retry without the reverse source route" before
generating a bounce (although one could argue that this violates section
4.5.4 and other "retries in the face of permanent failures"
limitations). This will also help detect the systems and MTAs that need
more attention to get minimal reverse source route support.
Andy.