Subject: Re: path routing

From: "John R Levine" <[email-masked]>
Date: 21 Nov 2004 23:18:07 -0500

>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.

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 22 Nov 2004 09:55:19 +0100

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

As far as current Internet Standards are quixotic:

| the reverse-path is a return route (which may be used to
| return a message to the sender when an error occurs with
| a relayed message).

They didn't invent 551 only for the fun of more error codes.

> 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.

It does in 3.1 MAIL:

| It gives the reverse-path which can be used to report errors.
[...]
| The <reverse-path> can contain more than just a mailbox.  The
| <reverse-path> is a reverse source routing list of hosts and
| source mailbox.  The first host in the <reverse-path> should
| be the host sending this command.
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> the DNS was new, and MX records were far from universal.

Sure, and they had no spam and no forged MAIL FROM addresses.

> 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

If you'd say that forwarding from one MX to another unrelated
MX is a waste of resources and bandwidth, then I won't disagree.
 
> Once the gateways were all documented by MX records, path
> routes became useless, which is why they're gone from 2821.

As we see that was a dangerous error, it created the loophole,
now fixed by SPF / RMX / BATV / SES / etc. as far as possible.

> 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 they don't know how to handle it they shouldn't forward the
mail, but reject it with 551 or a simple "user unkown".  It's
the problem of the receiver to get it right.

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

It allows to identify bogus bounces caused by forged MAIL FROM
addresses, doesn't it ?
                       Bye, Frank