Re: path routing
"John R Levine" <[email protected]>
| Newsgroups | gmane.ietf.mxcomp |
|---|---|
| Message-ID | <[email protected]> |
>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@foo> RCPT TO:<@bar,@cow:@z@zoo> MAIL FROM:<@bar:a@foo> RCPT TO:<@cow:@z@zoo> MAIL FROM:<@cow,@bar:a@foo> RCPT TO:<z@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.