vixie@decwrl.dec.com (Paul Vixie) (09/25/88)
I'm still working on my reply to the original "considered GOOD" article, and so far it looks long and hot. Stay tuned. But meanwhile, Der Tynan says: # a lot of times I haven't got the foggiest idea how to get mail to a given # site, and would appreciate a relay along the way cleaning up my routing I think I'll build a list of frequently said things so I can quote myself. I am probably Usenet's most voiciferous opponent of what I've been calling "active rerouting", yet you must believe me when I say (again) that I see a very definite need for the service you describe. I call it "passive rerouting". "Active" vs. "passive": the distinction is very important. Sorry to burden you all with another set of terms, but I had to describe this crucial distinction somehow. Passive routing means that you have to know only two things: 1. the user name and the name of the host/domain where she receives her mail. this is usually on a business card or a .signature file, and if various sites on the net would fix their header rewriting code, it would be in the headers of messages you receive from her. 2. a path from your host to a host that has two attributes: -- practices "passive rerouting" -- is likely to know how to reach the "final host" Knowing this, you can send the mail with an explicit route from where you are to the passive rerouter, and then to the final destination AS THOUGH THE FINAL DESTINATION WERE A DIRECT NEIGHBOR OF THE PASSIVE REROUTER. So, for example, if you are "ireland!der", and you UUCP to "france" who UUCPs to "england" who runs a passive rerouter; if you know that "england" will know how to reach "california" even though you have no idea what path (or mechanism; carrier pigeons aren't impossible) will be used; given these facts, you can send mail to france!england!california!fresno!friend You are actually _counting_ on "england" to reroute (or just "route", really) the message. You don't know and probably don't care what route will be used. You are also counting on "california" knowing how to reach "fresno" if it is not a direct UUCP neighbor (or within carrier pigeon range, or whatever). So what's the ever-so-crucial distinction? Why call it "passive" and praise it? Because of something "england" will not do: IT WILL NOT TRY TO FIND A ROUTE TO "fresno" "england" doesn't know about "fresno". There may be a machine on "england"'s ethernet called "fresno" which it is willing to reach via "!"-notation out of convenience; there may be a machine at a lab member's home called "fresno" which noone wants to map because it will be back in the lab next week; there are many good reasons to only do what you have been asked to do, which in this case, means: send it to "california" and let it puzzle out the rest. So you see, hopefully, that I am much in favor of _PASSIVE_ (re-)routing. I use this kind of thing constantly; I have passive routers one hop away from decwrl in each of several directions. (Brian Reid won't let me run a router here, not yet anyway.) I will be repeating this again in my reply to the original "considered GOOD" article, but here's my small list of useful and unrefuted assertions: the map is not the territory. there is no problem solved by active rerouting which cannot be solved another way; there are problems _caused_ by active rerouting which cannot be solved at all. Good day, all. -- Paul Vixie Work: vixie@decwrl.dec.com decwrl!vixie +1 415 853 6600 Play: paul@vixie.sf.ca.us vixie!paul +1 415 864 7013
rpw3@amdcad.AMD.COM (Rob Warnock) (10/05/88)
I *almost* agree completely with Paul Vixie,... except that overly-"helpful"
passive rerouting can still cause problems. Or to say it another way, there's
two kinds of passive routing: (1) the "next host" in the path is a plain UUCP
name, e.g. "a!b!c", and you don't talk to "a". These should be returned with
error, so the sender can fix his/her routing table. But if (2) the "next host"
is a fully-qualified domain, e.g. "foo.bar.baz.ca.us!b!c", *then* I think that
it's reasonable to try to route it, as the sender is obviously referring to
a physical UUCP connection (though "foo.bar.baz.ca.us" may be my UUCP neighbor).
So, I say:
Active routing? NEVER.
Passive routing of UUCP names? Please, no. (But some may disagree.)
Passive routing of domains? Please, by all means! (...if you think you
understand the domain.)
Note that you can always request site "bar" to attempt routing of a plain
UUCP name "baz" by writing it as "foo!bar!baz.uucp!b!c", since routes for
the ".uucp" pseudo-domain are what's in the published maps.
Rob Warnock
Systems Architecture Consultant
UUCP: {amdcad,fortune,sun}!redwood!rpw3
ATTmail: !rpw3
DDD: (415)572-2607
USPS: 627 26th Ave, San Mateo, CA 94403page@swan.ulowell.edu (Bob Page) (10/05/88)
[I think there are about 12 people still reading this thread] rpw3@amdcad.UUCP (Rob Warnock) wrote: >name, e.g. "a!b!c", and you don't talk to "a". These should be returned with >error, so the sender can fix his/her routing table. It should be a local decision, and all your neighbors need to know about it. I have one host in all of the university that has routing tables on it. Everybody else sends to that host with somehost!user as an address. This works great, and saves me a lot of work on all the other hosts (as well as supporting the other departments). I also have at least a dozen UUCP connections outside the university that rely on this behaviour. ..Bob -- Bob Page, U of Lowell CS Dept. page@swan.ulowell.edu ulowell!page
chip@ateng.ateng.com (Chip Salzenberg) (10/07/88)
According to rpw3@amdcad.AMD.COM (Rob Warnock), passive routing should be done only on domain names (with ".uucp" considered a domain). I suggest that this approach is too conservative, since it means that passive rerouting becomes a requested service instead of a _default_ service. After all, part of the beauty of passive routing is that it kicks in *automatically*, but *only when needed*. -- Chip Salzenberg <chip@ateng.com> or <uunet!ateng!chip> A T Engineering Me? Speak for my company? Surely you jest! Beware of programmers carrying screwdrivers.
vixie@decwrl.dec.com (Paul Vixie) (10/07/88)
In article <23130@amdcad.AMD.COM> rpw3@amdcad.UUCP (Rob Warnock) writes:
# [...] the "next host" in the path is a plain UUCP name, e.g. "a!b!c", and
# you don't talk to "a". These should be returned with error, so the sender
# can fix his/her routing table. [...]
If I thought I could get <neighbor!faraway.uucp!person> to appear on the
neighbor as <faraway.uucp!person> instead of the truncated <faraway!person>
then I might agree with you. It would be great to have a signal of some
kind to tell a passive rerouter to do its stuff, and at first glance, a
domainized name looks like a good way to get that to happen.
But there are many sites worth sending mail to that do not have and will
never have a domain name; they are reachable by a dotless UUCP name, and I
need to be able to tell a passive rerouter to find a route to it, and I
can't use .UUCP reliably because so many MTA's strip it out (including
my own).
Therefore: bouncing <a!b!c> because "a" is not a neighbor is probably the
wrong thing to do, since if "a" is reachable via a pathalias-located route,
you are probably asking the passive rerouter to find the route for you.
--
Paul Vixie
Work: vixie@decwrl.dec.com decwrl!vixie +1 415 853 6600
Play: paul@vixie.sf.ca.us vixie!paul +1 415 864 7013jordan@zooks.ads.com (Jordan Hayes) (10/08/88)
Paul Vixie <vixie@decwrl.dec.com> writes:
But there are many sites worth sending mail to that do not have
and will never have a domain name; they are reachable by a
dotless UUCP name, and I need to be able to tell a passive
rerouter to find a route to it, and I can't use .UUCP reliably
because so many MTA's strip it out (including my own).
Very well. They need not ever see a domain-ized version of their
address. However, it should become their responsibility to speak the
correct language if they wish to interoperate with me. There are
plenty of mailing systems out there that have no idea who they are
talking to -- they need to have a gateway do the correct translations
for them, if they are unable to do them by themselves.
Machine foobar gets themselves a domain, administered by
sales.big-co.com, and has a uucp link (transport issues, of course, are
beyond this note -- it could as easily be any other kind of mail
system) to them. When they get a message from foobar!user that's
headed into the outside world, they change it to read From:
user@foobar.stubborn.com and they provide MX service for them as well.
When stuff comes in for them, the reverse is applied.
Last I heard, this is called "gatewaying" and it's useful.
When will the rest of the sane world be finished paying for the sins of
those sites who are unwilling (unable?) to speak Italian in Rome?
/jordan