vixie@palo-alto.DEC.COM (Paul Vixie) (08/09/88)
brisco@pilot.njin.net (Thomas Paul Brisco) writes:
# What I mean by "all my routing" is all my routing. I only
# have to say "rutgers!foo!user" and let the rutgers mail look
# up the path to site foo. So, it literally does *all my routing*. (I
# don't know how else to say it).
This is only a demonstration of _passive routing_, which is a Good Thing
according to me and is quite different from what Rutgers actually does.
If I send mail to rutgers!foobar!user, knowing full well that "foobar" is
not a neighbor of Rutgers but that Rutgers will find a route, this is all
very nice and very convenient and NOT what I am yelling about.
What Rutgers actually does is _RErouting_. Not _passive routing_.
Passive routing is where you always look for a way to send the mail to the
next hop in the path as you see it -- and it means finding a route IFF that
"next hop" is not a direct UUCP neighbor or an alias for a directly
reachable internet site.
Rutgers, on the other hand, will find a route to just about anything it can
find in the path, starting from the RIGHT. From the END. Therefore if I
send a piece of mail to ...!rutgers!foo!bar!baz!user, knowing full well that
"foo" is a directly reachable neighbor of Rutgers, I have no guarantee at
all that Rutgers will actually send to "foo". It will look first for a way
to get to "baz", then to "bar", then to "foo", then finally give up if it
cannot find any of the above. THIS IS WRONG.
It's an option in Smail, and I wish they'd never have included it. The only
possible justification is for replies along news paths, which are very long
and usually circuitous. However, if you have a mailer smart enough to look
something up in a routing database, you should be using the "From:" or the
"Reply-To:", not the "Path:". RN and readnews both have this option available.
If you have neighbors who reply using the "Path:", then you gain yourself
nothing by rerouting the mail -- the message is coming through your system
no matter which direction is leaves. If you want to do your neighbors a
favor, tell them to make you their "smart-host" in their smail/pathalias
database and reconfigure their RN or readnews software to use "From:". This
way, the replies will come to your system more-or-less _asking_ you to find
a route for them.
I'll say it again: rerouting an explicitly routed piece of mail is rude; the
practice always causes more confusion and anguish in the long run than any
of its doubtful benefits ever pay anyone back for.
--
Paul Vixie
Digital Equipment Corporation Work: vixie@dec.com Play: paul@vixie.UUCP
Western Research Laboratory uunet!decwrl!vixie uunet!vixie!paul
Palo Alto, California, USA +1 415 853 6600 +1 415 864 7013emv@mailrus.cc.umich.edu (Edward Vielmetti) (08/09/88)
In article <3732@palo-alto.DEC.COM> vixie@palo-alto.DEC.COM (Paul Vixie) writes: > >This is only a demonstration of _passive routing_, which is a Good Thing >according to me and is quite different from what Rutgers actually does. I dunno, Paul. When rutgers sends me mail, I know that it's going to get to the intended site, and they're not going to give me crap that's a reply to a news path article. You know, the 25-hop monsters that start in Denver Colorado and wend their way through 10 backbone sites (including yours) on their eventual way to some poor fool in Ohio. When rutgers routes mail through mailrus, I'm almost positive it will get to its intended recipient. Hey, someone's got to keep the maps sane, right? There's much more confusion and anguish to be had by having your mail end up on someone's small private workstation in Italy that happens to have the same name as your node, let me tell you. (peter, do you want to let loose pathparse on the unsuspecting? mailrus might not be a bad candidate.) --Ed
allbery@ncoast.UUCP (Brandon S. Allbery) (08/10/88)
As quoted from <622@mailrus.cc.umich.edu> by emv@mailrus.cc.umich.edu (Edward Vielmetti): +--------------- | In article <3732@palo-alto.DEC.COM> vixie@palo-alto.DEC.COM (Paul Vixie) writes: | >This is only a demonstration of _passive routing_, which is a Good Thing | >according to me and is quite different from what Rutgers actually does. | | Hey, someone's got to keep the maps sane, right? There's | much more confusion and anguish to be had by having your | mail end up on someone's small private workstation in Italy | that happens to have the same name as your node, let me | tell you. +--------------- I hate to say it, Ed, but you just argued against active rerouting. You see, if the little box in Italy is on the maps but yours isn't, rutgers will ignore the explicit path directing it to your system, in the name of active rerouting, and send the bugger to Italy! In a passive rerouting system, this can only happen when the path to your little box isn't specified. In active rerouting, it will *always* happen; the site in the maps gets highest priority and unregistered sites that have the same name as registered sites are unreachable even if a path is explicitly specified. ++Brandon -- Brandon S. Allbery, uunet!marque!ncoast!allbery DELPHI: ALLBERY For comp.sources.misc send mail to ncoast!sources-misc
honey@umix.cc.umich.edu (Peter Honeyman) (08/11/88)
Edward Vielmetti writes: >peter, do you want to let loose pathparse on the unsuspecting? ed, not really. you can take it from ~honey/down/src/pathparse on citi, but my experience with pathparse was 1) too much administrative overhead maintaining the database, and 2) i don't trust the data enough to wire pathparse into an mta in rerouting mode. (from this, you can infer my opinion of agressive routing in an mta using pathalias.) i used pathparse in my ua for a few years (motf has hooks for both pathparse and pathalias), but find that pathalias suffices and is easier to maintain. but go ahead and experiment. peter ps: made for a nice paper, though ...
cik@l.cc.purdue.edu (Herman Rubin) (08/11/88)
In article <3732@palo-alto.DEC.COM>, vixie@palo-alto.DEC.COM (Paul Vixie) writes: < brisco@pilot.njin.net (Thomas Paul Brisco) writes: < # What I mean by "all my routing" is all my routing. I only < # have to say "rutgers!foo!user" and let the rutgers mail look < # up the path to site foo. So, it literally does *all my routing*. (I < # don't know how else to say it). < > This is only a demonstration of _passive routing_, which is a Good Thing > according to me and is quite different from what Rutgers actually does. > > If I send mail to rutgers!foobar!user, knowing full well that "foobar" is > not a neighbor of Rutgers but that Rutgers will find a route, this is all > very nice and very convenient and NOT what I am yelling about. > > What Rutgers actually does is _RErouting_. Not _passive routing_. > > Passive routing is where you always look for a way to send the mail to the > next hop in the path as you see it -- and it means finding a route IFF that > "next hop" is not a direct UUCP neighbor or an alias for a directly > reachable internet site. > > Rutgers, on the other hand, will find a route to just about anything it can > find in the path, starting from the RIGHT. From the END. Therefore if I > send a piece of mail to ...!rutgers!foo!bar!baz!user, knowing full well that > "foo" is a directly reachable neighbor of Rutgers, I have no guarantee at > all that Rutgers will actually send to "foo". It will look first for a way > to get to "baz", then to "bar", then to "foo", then finally give up if it > cannot find any of the above. THIS IS WRONG. > > It's an option in Smail, and I wish they'd never have included it. The only > possible justification is for replies along news paths, which are very long > and usually circuitous. However, if you have a mailer smart enough to look > something up in a routing database, you should be using the "From:" or the > "Reply-To:", not the "Path:". RN and readnews both have this option available. > > If you have neighbors who reply using the "Path:", then you gain yourself > nothing by rerouting the mail -- the message is coming through your system > no matter which direction is leaves. If you want to do your neighbors a > favor, tell them to make you their "smart-host" in their smail/pathalias > database and reconfigure their RN or readnews software to use "From:". This > way, the replies will come to your system more-or-less _asking_ you to find > a route for them. > > I'll say it again: rerouting an explicitly routed piece of mail is rude; the > practice always causes more confusion and anguish in the long run than any > of its doubtful benefits ever pay anyone back for. > -- > Paul Vixie > Digital Equipment Corporation Work: vixie@dec.com Play: paul@vixie.UUCP > Western Research Laboratory uunet!decwrl!vixie uunet!vixie!paul > Palo Alto, California, USA +1 415 853 6600 +1 415 864 7013 I use email a fair amount, both directly and in replying to news articles. Each network has its idiosyncracies, and they are incompatible. Also, I am not a systems person, and I feel I should not have to work so hard to send and receive mail. As it is, I have to edit the To: lines of most of the replies to news articles (all uucp addresses, due to a local mailing situation). Some of the time, I do not know if an address is uucp or inet; I must treat them differently. I have had quite a bit of mail bounce. Paul is absolutely right about "smart" mailers. Others posting responses to this article have complained, and rightly so, about taking a uucp ! path and affixing an inet @ site to it. Such a path cannot correctly get out of a uucp site. So what is the answer? An answer which has been proposed before is the use of parentheses, or some such equivalent. Only the site facing a ( is allowed to look into the parenthetical expression. Thus Paul could enclose the tail of his path, which he does want Rutgers to break into, in parentheses. An inet site could put the uucp ! path into parentheses, and I could use it directly for a return address without having to mung it. There was a situation in which my wife, mainly using a different machine, wished to make a direct reply. This was worked around. With parentheses, it would have been trivial. A hierarchical address scheme, with each level operating independently without any knowledge of the structure of the other levels, should be implementable and has the additional property that if someone comes up with xyznet with its peculiar addressing scheme, nothing has to be changed. One level need only get the message to the gateway to the next level; it does not have to read what goes on at the next level, and if it is supplied with the return to the previous host, so mail can be returned if necessary, it does not need to know what went before. Is there any attempt to implement something reasonable like this? -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet, UUCP)
lear@NET.BIO.NET (Eliot Lear) (08/12/88)
My final words on the subject....
Note: The use of source routing is discouraged. Unless the
sender has special need of path restriction, the choice
of transmission route should be left to the mail tran-
sport service.
[RFC-822: Section 6.7.2, Page 32]
...and they are somebody else's.
--
Eliot Lear
[lear@net.bio.net]kre@munnari.oz (Robert Elz) (08/12/88)
In article <866@l.cc.purdue.edu>, cik@l.cc.purdue.edu (Herman Rubin) writes: > So what is the answer? An answer which has been proposed before is the use > of parentheses, or some such equivalent. That will never work .. all it could ever do is create more incompatabilities, which is what it would be nice to do away with. In any case, for the current problem it wouldn't help at all. There would be a set of sites that obey the restrictions you want the parentheses to imply (which would be much the same as the set of sites that look only at the first host in a bang path, and route to that one), and a set of sites that ignore your parentheses, look at what's inside, and "know" that they can find a better route than the one you gave. The problem that parentheses might fix (if it was rationally possible to change anything this darmatically) is the ! @ incompatability (which should be used). That's not at all relevant to the current discussion. kre
kre@munnari.oz (Robert Elz) (08/12/88)
Rutgers (and a few other hosts) policy of "active rerouting" is finally exposed as the wrong thing to do in this article from Ron Natalie ... Article <Aug.11.16.57.31.1988.21678@topaz.rutgers.edu>, ron@topaz.rutgers.edu: > The machine, being much more intelligent > (and closely coupled to the map database, which is maintained there as > well) than your average random UUCP site, Superficially this seems to say "we have the best routing info available, so we should make use of it" and it seems to be a defence of Rutgers' policy. However, what it really says is "we have different routing info from everyone else", which in any distributed routing scheme (which is what uucp routing is in the presence of active routers) is a recipe for disaster. Eg: consider routing to the fictional site "baz", and assume that its stable routing info (from some time in the past) is ...!rutgers!a!b!c!d!baz!user Now suppose rutgers learns that there's a much better route available ... ...!rutgers!foo!bar!baz!user However, unfortunately, "foo" hasn't learned this yet, Rutgers is using its private, very recent, new map info, which will be posted sometime tonight, and actually installed in foo's pathalias database at some unknown future time. "foo" still sees the best bath to "baz" as "...!rutgers!a!b!c!d!baz!user", and also being an active rerouter, rewrites the path that way. A few iterations of this and the mail ends up being bounced... Clearly, if Rutgers is given "baz!user" it should route it via "foo!bar!baz" and "foo" should just send the mail to "bar", whatever it thinks the best route is. However, if the mail appears at Rutgers addressed to "a!b!c!d!baz!user" Rutgers *must* send it to "a" if they have any desire at all to handle uucp mail rationally. Ron goes on ... > None of our clients (ether our UUCP/NEWS neighbors or members of the > Rutgers community) have complained. Ignoring Bob Webber for the minute (which is sensible at any time), I can understand this, they aren't the people who are having problems. The problems come from sites much further away, both those whose mail is being rerouted into a black whole, and those whose routing is being ignored. Earlier Ron had said ... > I would like to make is that as Associate Directory here responsible > for the expenditures on this machine, if you don't like the way it > runs, you can feel free to route your mail elsewhere. Exactly! That's why all pathalias & map users should add "-d rutgers" to their pathalias command scripts. I've been doing that (actually I think I have -a rutgers, the effect is the same in all relevant cases to me) for at least a year now. Nb: this will remain true forever .. even if Rutgers' tactic does have the effect of getting every uucp site in the world to register with the map project, and all the data is accurate, distribution of the resulting maps will never be quick enough to allow active rerouting to be used, anywhere. kre
zeeff@b-tech.UUCP (Jon Zeeff) (08/12/88)
In article <Aug.11.16.57.31.1988.21678@topaz.rutgers.edu> ron@topaz.rutgers.edu (Ron Natalie) writes: >feel compelled to make an answer. The machine Rutgers (Rutgers.EDU >actually) handles a lot of passthrough mail as well as being a USENET >backbone site and a main feed point for machines in New Jersey. We've I have to agree that rutgers has been generous in providing usenet with alot of services. It is appreciated. >for the expenditures on this machine, if you don't like the way it >runs, you can feel free to route your mail elsewhere. > That's part of the problem - I can try and avoid rutgers (or any other site), but with active rerouters out there, someone may change my paths avoiding site xxx to go through xxx. Active rerouting, which rutgers does, makes it impossible to do what you suggest. >well) than your average random UUCP site, needs the facility to optimally >route mail rather than constraining it to follow the news paths (which >are less richly connected than the mail feeds). The alternative to >doing rerouting is to drop mail transiting through Rutgers that isn't >using a path that specifies the correct next hop (or giving up on Depending on what you meant by "correct next hop", I believe that you missed one alternative, the one that most sites have decided is the best one. How about only actively rerouting when the next hop is a site you don't talk to directly. If using news return paths are really the problem, you might consider some method of attempting to identify them - something like "this path is *really* bad, I'm going to reroute it" or "this looks like a news reply via the path line". >forwarding mail for people entirely such as ihnp4 has done). Allowing >us to reroute makes it feasible for us to provide this service at all. Note that running an active rerouting site may reduce traffic for some of the sites you talk to, but it does not reduce your traffic. -- Jon Zeeff Branch Technology, uunet!umix!b-tech!zeeff zeeff%b-tech.uucp@umix.cc.umich.edu
vixie@decwrl.dec.com (Paul Vixie) (08/13/88)
In article <22608@amdcad.AMD.COM> phil@amdcad.UUCP (Phil Ngai) writes:
# That is what I think should be done. If you get a uucp bang route and
# the next hop is incorrect, bounce it back. Bang routes are presumably
# used because the sender knew the route he wanted. If you get an @
# address, then that is eligible for routing.
Hmmm. I don't think that will work - it's hard to get @'s to appear in
the address another site sees for forwarding. It is fairly easy to get
it to see !'s, though, so mail to smarthost!someplaceelse!somebody is
safer. Granted, there's no way to tell on smarthost whether the sender
wants autorouting or whether they just typed the route wrong -- which is
why I'm so hot on only routing to the first host in the path rather than
stripping hosts off the way Rutgers does. Do the minimum, etc.
--
Paul Vixie
Digital Equipment Corporation Work: vixie@dec.com Play: paul@vixie.UUCP
Western Research Laboratory uunet!decwrl!vixie uunet!vixie!paul
Palo Alto, California, USA +1 415 853 6600 +1 415 864 7013vixie@decwrl.dec.com (Paul Vixie) (08/13/88)
In article <4695@b-tech.UUCP> zeeff@b-tech.UUCP (Jon Zeeff) writes:
# [...] If using news return paths are really
# the problem, you might consider some method of attempting to identify
# them - something like "this path is *really* bad, I'm going to
# reroute it" or "this looks like a news reply via the path line".
Please don't!
If you see a lot of replies using news paths, try to identify the sites which
originate them and try to get them to fix their news software. NetNews and
RN both suggest in their documentation that you use the "From:" line for
replies rather than the "Path:" line, and sites which don't do this should
be educated. NetNews (vnews/readnews) will use /usr/lib/news/mailpaths,
which can be pointed at a smart host (i.e., which does routing on the next-hop
if they don't speak to it directly); the generic solution is to use smail,
which can also be trivially configured to use a smart-host. (RN would need
smail, sadly). Smail is freely available, check the comp.unix.sources
archives.
--
Paul Vixie
Digital Equipment Corporation Work: vixie@dec.com Play: paul@vixie.UUCP
Western Research Laboratory uunet!decwrl!vixie uunet!vixie!paul
Palo Alto, California, USA +1 415 853 6600 +1 415 864 7013allbery@ncoast.UUCP (Brandon S. Allbery) (08/15/88)
In article <Aug.11.20.43.05.1988.26993@NET.BIO.NET>, lear@NET.BIO.NET (Eliot Lear) writes: +--------------- | Note: The use of source routing is discouraged. Unless the | sender has special need of path restriction, the choice | of transmission route should be left to the mail tran- | sport service. | | [RFC-822: Section 6.7.2, Page 32] +--------------- Which was great, when the network(s) covered by RFC822 could propagate changes to the routing in an hour or so. With UUCP, the corresponding time can be measured in months in some cases. Quite aside from the fact that RFC822 insists that all sites named in an address be known; many small UUCP sites feel they have no need to register with the NIC. RFC822 is a bit naive. ++Brandon -- Brandon S. Allbery, uunet!marque!ncoast!allbery DELPHI: ALLBERY For comp.sources.misc send mail to ncoast!sources-misc
lear@NET.BIO.NET (Eliot Lear) (08/15/88)
My point was that users should leave the routing of mail to computers, like they do everything else. -- Eliot Lear [lear@net.bio.net]
vixie@decwrl.dec.com (Paul Vixie) (08/16/88)
In <Aug.14.22.18.45.1988.9347@NET.BIO.NET> lear@NET.BIO.NET (Eliot Lear) says: # My point was that users should leave the routing of mail to computers, # like they do everything else. And a very good point that is. But it's not what we're talking about. If my computer selects a route, your computer should respect it. -- Paul Vixie Digital Equipment Corporation Work: vixie@dec.com Play: paul@vixie.UUCP Western Research Laboratory uunet!decwrl!vixie uunet!vixie!paul Palo Alto, California, USA +1 415 853 6600 +1 415 864 7013