ietf-mxcomp
[Top] [All Lists]

Re: path routing

2004-11-21 21:18:02

The receiver is free to take the bounces (e.g. using SRS),
or he can reject my mail with 551.  But he should not say
MAIL FROM:<me> if it's actually MAIL FROM:<@receiver,me>.

Oh, wow, path routes.  There's a quixotic quest.

There are two problems with path routes.  The first is that path
routes never did what you're proposing.  The second is that they were
always a band-aid, not a feature.

If you read page 21 of RFC821, it says that if the sender uses a
source route, as the message is relayed, the hosts are moved from the
forward path to the reverse path, e.g.:

MAIL FROM:<a(_at_)foo>
RCPT TO:<@bar,@cow:@z(_at_)zoo>

MAIL FROM:<@bar:a(_at_)foo>
RCPT TO:<@cow:@z(_at_)zoo>

MAIL FROM:<@cow,@bar:a(_at_)foo>
RCPT TO:<z(_at_)zoo>

It most definitely does NOT say that if one of the relays replaces the
recipient address with a new address that it should hang a reverse path
on the return address.

As I understand it (and I'm sure Dave C will correct me if I'm wrong) the
reason reverse paths appear in 821 is that the DNS was new, and MX records
were far from universal.  The net wasn't (and isn't) fully connected, and
in lacking MX, you just had to know that the only way to get mail to one
host was through another host that happened to have a gateway, with path
routes being a way to force the mail to the gateway host.  Once the
gateways were all documented by MX records, path routes became useless,
which is why they're gone from 2821.

Moreover, even if you did put a route into a return path, what do you
propose to do with it?  Unless forwarding hosts remember every piece
of mail they've ever forwarded, they're not going to be able to tell
virtuous bounces actually returning along a previously used path from
random spam and blowback that happens to have scraped that route from
somewhere.  If you want to validate a route, you have to encode some
sort of signature in them, and I have my doubts about the practicality
even of that.

Yes, RfC 2821 broke it, SPF "-all" fixes it.  BATV is an
alternative, it cures many symptoms of the same problem.

Huh?  BATV does some swell things, but routing is not one of them.



<Prev in Thread] Current Thread [Next in Thread>