On Sat, 2004-12-04 at 10:53, Greg Connor wrote:
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
Just to make sure we're on the same page, we're talking about only about
using "reverse source routes" (RSR), which, in the forward direction,
only appear in MAIL FROM, and in the return direction (only for DSN
bounces) appear in the RCPT TO, right? MTAs should continue to not
support/reject mail that has specified source route in the forward
direction taking the position of "routing is determined locally, so as
the sender, you don't get to choose the route the mail will take".
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?)
This would end up being exactly what we have had traditionally, but
specifying the RSR sets the ground work for using it if it exists.
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.
Exactly the traditional setup, yes.
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>?)
This would seem to be the definition of "using the reverse source
route", so yes. :)
If so, does this affect a's ability to check that
it's really a valid return when passing it on?
I would hope it would affect it positively. I was suggesting that if
forwarders gave RSR to the next hop, they would automatically whitelist
that domain for forwarding DSNs only to the <b(_at_)c> address for some fixed
amount of time (as set out by limits in RFC 2821 section 4.5.4 times
some globally accepted "average number of forwarding hops" or something
along those lines). SPF checks could still happen at all points. This
does open up a exploit window IF someone at the sending machine can
craft a DSN from <> and send it to @a for final delivery to <b(_at_)c>, but
that appears to be no more troublesome than per-user whitelists anyway.
SRS has the advantage over RSR (at least how I've described a use of RSR
in this context) that each message path is essentially its own little
whitelist only for that message's DSNs (because of the encoding of the
timestamp). I can't see a way to get that extra information into the
path when RSR is used, without breaking the fact that DSNs should always
come from <>.
Andy.