--Andy Bakun <spf(_at_)leave-it-to-grace(_dot_)com> wrote:
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.
This is the hard part of course. In theory, it's OK to bring something
back, but then you get to the "in practice" part.
What we would need in order to move forward is to determine how many
mailers:
- fully support source routes (i.e. accept them and actually use the route)
- accept source routes but don't use the route
- simply reject mail using source routes
For our purposes, is it enough to accept the mail but ignore the route when
the time comes? (i.e. to take <@a:b(_at_)c> and deliver it to <b(_at_)c> directly?)
If this is true, then "c" has no way of knowing if this was a legitimate
forward done by someone else or a spam/virus for b(_at_)c masquerading as a
return.
Even if the source route is used, does the sending machine rearrange the
destination address? (i.e. does it take <@a:b(_at_)c> and deliver it to a, but
with RCPT TO: <b(_at_)c>?) If so, does this affect a's ability to check that
it's really a valid return when passing it on?
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>