rsalz@bbn.com (Rich Salz) (07/06/89)
The rule for MX stuff is that once it leaves the Internet, you're on your own. You stuff it back into the Internet, you've got problems. One common problem is possible mail loops. Rewording Paul's article (which is just explaining the same thing that happens with UCAR/Fido, which started this whole chain): ]Decwrl is the MX for KG6KF.AMPR.ORG; it forwards the mail to Vixie for ]delivery. "It creates a path like ] vixie!noe!kg6kf.ampr.org!callsign%callsign" ]If there weren't a direct decwrl->vixie connection, there would be ]problems. (BTW, does it really use a % hack? Ick...) Damn straight. By advertising an MX record you're taking it out of the Internet, but now you're worried about what will happen if you interject it back into the Internet system. >The Moral: don't short-circuit. Wrong. The Moral: don't put full domain names into email paths if they're going through the Internet and you don't want them short-circuited. Hack the path to be something like noe!packet_radio!kg6kf_ampr_org!callsign!callsign >I'd better say it again, several times, since people always mix this up: > if you don't like the paths people use, change the source mailers If you shoot mail into the Internet with a fully-qualified domain name in the address -- yes, Paul, even if it's in the Path line -- than you should expect people to follow it. UUCP host names don't come with an enforceable central naming authority, but domain names do. If you don't want to use them, CHANGE YOUR GATEWAY CODE! /r$ -- Please send comp.sources.unix-related mail to rsalz@uunet.uu.net. Use a domain-based address or give alternate paths, or you may lose out.
jonathan@cs.keele.ac.uk (Jonathan Knight) (07/07/89)
From article <1888@prune.bbn.com>, by rsalz@bbn.com (Rich Salz): > (BTW, does it really use a % hack? Ick...) > > The Moral: don't put full domain names into email paths if > they're going through the Internet and you don't want them short-circuited. > Hack the path to be something like > noe!packet_radio!kg6kf_ampr_org!callsign!callsign Are you serious?!? Good grief this is worse than the % hack you mocked earlier. As I understand it, the argument for re-routing and short-circuiting revolves around the idea that some people feel they know how to route mail better than the people who started the mail off. I thought that the purpose of FQDN's was to get around this problem. So everyone should send their mail to a@b and let the mail software deal with it. The mail software should decide how to get to the next machine and deliver it to the destination or re-write the rule as a%b@d to use 'd' as a mail forwarder. 'd' could do whatever it liked with it as the mail was now SEP (someone elses problem). Sometimes, the mail must go through 2 forwarders. I have a few examples on this machine, one for CSNET. So if someone sends mail to superman@whatever.csnet then my mailer duly decides that the forwarder for that machine is "relay.cs.net". Unfortunately I can't get to that machine and so the mailer has to re-process the address 'relay.cs.net' to find another forwarder. In this case it is 'nsf.ac.uk'. So the route becomes "superman%whatever.csnet%relay.cs.net@nsf.ac.uk" and the mail then leaves here. (actually it would be in GreyBook order to obey the protocol in force here, but I didn't want to confuse anyone so I put it in the order that USA people can easily follow) It is possible that I could have pointed all my .csnet mail to nsf for forwarding, it may know about the .csnet domain. But that is wrong because nsf does not advertise itself as a csnet forwarder, relay.cs.net does that. So my route is correct because I forward mail for the .net domain to a .net forwarder. I then direct mail for the .csnet domain to a .csnet forwarder. If a short-circuiter got hold of the above it may try and send the mail to 'whatever.csnet' which may fail (depending on how the mailer is configured). But what's the point of short-circuiting the route when it is probably going to work perfectly well as it is. If it doesn't then the sys admin at the site which originated it is going to get a bounced mail message which will encourage him or her to fix the problem. I could never understand why people insist on re-routers and short circuiters which are aimed at solving a problem which should not exist and would not exist if mailers bounced mail with an error message every time it goes wrong. Re-routing is very impolite, if I want my mail routed then I won't put a route on it, but if I do put a route on it then I'd be grateful if people would use it. If the sys admins think that they can route mail better than I can, then declare yourselves as forwarders for those domains and I will gladly dump my mail on you for you to route. -- ______ JANET :jonathan@uk.ac.keele.cs Jonathan Knight, / BITNET:jonathan%cs.kl.ac.uk@ukacrl Department of Computer Science / _ __ other :jonathan@cs.keele.ac.uk University of Keele, Keele, (_/ (_) / / UUCP :...!ukc!kl-cs!jonathan Staffordshire. ST5 5BG. U.K.
pcg@aber-cs.UUCP (Piercarlo Grandi) (07/07/89)
In article <1888@prune.bbn.com> rsalz@bbn.com (Rich Salz) writes: >The Moral: don't short-circuit. Wrong. The Moral: don't put full domain names into email paths if they're going through the Internet and you don't want them short-circuited. Hack the path to be something like noe!packet_radio!kg6kf_ampr_org!callsign!callsign Ugh! Ugh! Pain... Fro two reasons: this is a horrible hack, and, and, let me repeat my NHO, this is Internet parochialism. There is nobody that has ever said that domain names are restricted to the Internet. As one regrettable example, the UK NRS uses things that looks suspiciously like Internet domain names, with a reverse order, administered by central authority. The rest of EUnet, a (mostly) UUCP network, also uses domain names (internet style, btw), with aanother central authority (well, almost). >I'd better say it again, several times, since people always mix this up: > if you don't like the paths people use, change the source mailers If you shoot mail into the Internet with a fully-qualified domain name in the address -- yes, Paul, even if it's in the Path line -- than you should expect people to follow it. But damnable Internet sites should NOT expect domain-style names to be Internet names at all, as anybody can write a.b.c! And unfortunately... UUCP host names don't come with an enforceable central naming authority, but domain names do. If you don't want to use them, CHANGE YOUR GATEWAY CODE! ...no gateway code can cope with this, because there is NO way an Internet gateway can transform a non internet name (domainized or not) into an Internet one all of the time, simply because it does not have MX records or maps for all the funny domains out there. -- Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
pcg@aber-cs.UUCP (Piercarlo Grandi) (07/07/89)
In article <656@kl-cs.UUCP> jonathan@cs.keele.ac.uk (Jonathan Knight) writes:
As I understand it, the argument for re-routing and short-circuiting
revolves around the idea that some people feel they know how
to route mail better than the people who started the mail off.
Precisely. And they think that all domain names (saying Fully Qualified is a
bit risky as the domain name space is not really rooted...) are Internet
ones about which they know everything so that they can second guess the
sender.
Re-routing is very impolite, if I want my mail routed then I won't put a
route on it, but if I do put a route on it then I'd be grateful if
people would use it. If the sys admins think that they can route mail
better than I can, then declare yourselves as forwarders for those
domains and I will gladly dump my mail on you for you to route.
Agreed. The net world is much stranger than most people believe, and the
golden net rule "I carry your traffic, you carry my traffic, no questions
asked", is the one that does keep it all together, and rerouting (as opposed
to routing, which is legitimate, when the sender gives an underspecified
route, like a@b) whether wanton or supposedly justified by supposedly all
Internet registered domain names violates it. That's why people feel
strongly about it.
(note: the golden rule of course has one limit: money, i.e. balanced
expense. Everybody praises backbone sites that forward more traffic
than they generate, as anybody dislikes the free riders that try to
do the opposite. Thank goodness the former are many and generous).
Thank you for your arguments supporting this.
--
Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.ukrick@uunet.UU.NET (Rick Adams) (07/08/89)
> In article <656@kl-cs.UUCP> jonathan@cs.keele.ac.uk (Jonathan Knight) writes: > > As I understand it, the argument for re-routing and short-circuiting > revolves around the idea that some people feel they know how > to route mail better than the people who started the mail off. Does anyone seriously claim that this is not true? Ignore the .1% of the people who might know how to route mail. The incredible, overwhelming majority of people (there implicity the overwhelming majority of mail) have absolutely no idea how to route mail. I'm not arguing in favor of rerouting, but I can't conceive of even a tiny fraction of mail be routed optimally to begin with.
woods@ncar.ucar.edu (Greg Woods) (07/08/89)
In article <59767@uunet.UU.NET> rick@uunet.UU.NET (Rick Adams) writes: >> In article <656@kl-cs.UUCP> jonathan@cs.keele.ac.uk (Jonathan Knight) writes: >> route mail better than the people who started the mail off. > >I'm not arguing in favor of rerouting, but I can't conceive of >even a tiny fraction of mail be routed optimally to begin with. The real problem is that in the interest of routing mail "better", it sometimes gets routed "wrong" (where I define "wrong" as "won't get there after rerouting when it would have before"). Do we want mail routing to be optimal or correct? I prefer to err on the side of correctness, so I don't reroute explicitly-specified bang paths. At least that way, if the path turns out to be wrong, it's SEP (Someone Else's Problem) and it won't be MY fault that the mail didn't get there. --Greg
lear@NET.BIO.NET (Eliot Lear) (07/08/89)
BIONET does fairly heavy mailing to the UK system, and I have never had a problem short circuiting a .UK path. I currently do not short circuit for .JANET, but then very few people are sending out .JANET these days anyway, and I had assumed it was going the way of .CSNET, which died some time early last year. There are two instances that short circuiting is a lose: [1] When the domain isn't real. Solution: don't short circuit to unreal domains. Either keep a list of top level domains, or hack the source. I do the latter, and have never had a complaint. [2] When the forwarder reintroduces the message into the system with the same domain name. This is the far more complicated scenerio. Greg Woods and I went several rounds of mail on this one, and there can be no resolution without [a] some fairly hefty processing, and [b] coordination of a large group of system administrators [sort of like a herd of cats]. The issue is with [2]. Bear in mind that because I am an Internet site, if someone is going to be a forwarder and then forward the message through me, I might as well be the forwarder in the first place. I am willing to make an exception to that rule for Greg Woods, because his is a somewhat unique and existing situation. Greg, if you find a loop involving my site, please contact me and I will make appropriate changes. However, I still believe that it is the forwarder's responsibility to [1] get the mail to the destination host, and [2] gain the permission of any intermediaries that might be used. While the Internet does not really restrict UUCP addressing semantics, neither does anyone else. Therefore, I have no problem short circuiting a route. It is a matter of who will be second guessed - the sender or every system administrator between the sender and the destination. I choose the former, as I believe the latter is much more ``evil and rude,'' to quote various preachers of the routing gospel.
lear@NET.BIO.NET (Eliot Lear) (07/08/89)
Re optimizing vs. correctness: Bounced messages are good incentives for updated map entries.
roy@phri.UUCP (Roy Smith) (07/08/89)
In article <3648@ncar.ucar.edu> woods@handies.UCAR.EDU (Greg Woods) writes: > Do we want mail routing to be optimal or correct? I prefer to err on the > side of correctness, so I don't reroute explicitly-specified bang paths. We don't currently reoute uucp mail here except for some minor internal trickery; you can submit a bang path to any of our non-uucp machines and they will forward it via SMTP to our uucp gateway. We run IDA sendmail here, which has all the needed hooks to do pathalias database lookups in the MTA layer, but I still want to provide the option of letting people explicitly route uucp mail if they want. I was thinking of not touching bang paths at all but doing lookups on person@host.UUCP type addresses. Does this seem reasonable? -- Roy Smith, Public Health Research Institute 455 First Avenue, New York, NY 10016 {allegra,philabs,cmcl2,rutgers,hombre}!phri!roy -or- roy@alanine.phri.nyu.edu "The connector is the network"
tanner@ki4pv.uucp (Dr. T. Andrews) (07/08/89)
In article <59767@uunet.UU.NET>, rick@uunet.UU.NET (Rick Adams) writes:
jk-) As I understand it, the argument for re-routing and short-circuiting
jk-) revolves around the idea that some people feel they know how
jk-) to route mail better than the people who started the mail off.
) Does anyone seriously claim that this is not true?
Yes, I would claim that it is not true that a re-router reliably
knows more about mail routing than the person who started the
mail off.
It doesn't take a very bright person to know how to route mail,
after all (comments about management aside); all it takes is a
reasonably intelligent postmaster at the originating site. He
arranges for some useful set of maps to be available and used
automatically, teaches his users to write "name@dest.site", and
voila! the user has learned to route mail.
In order for the re-router to justify his action, he must
demonstrate that his maps are better than those used to route the
mail originally. Further, in order to be considered a good
person, he must assure that his re-routings NEVER cause a problem
which would not exist had he not re-routed.
Judging from the steady stream of complaints about rabid re-
routers, I would guess that re-routers have failed on this second
requirement.
) I'm not arguing in favor of rerouting, but I can't conceive of
) even a tiny fraction of mail be routed optimally to begin with.
Define optimally. Here, to give you a start, is how we define
it. We say that mail is routed optimally if it is routed
according to the published maps, as amended by local wisdom
(local map files). Most if not all mail coming out of here is so
routed, because the mailer takes care of such details.
--
...!bikini.cis.ufl.edu!ki4pv!tanner ...!bpa!cdin-1!ki4pv!tanner
or... {allegra killer gatech!uflorida uunet!cdin-1}!ki4pv!tannerjonathan@cs.keele.ac.uk (Jonathan Knight) (07/08/89)
From article <59767@uunet.UU.NET>, by rick@uunet.UU.NET (Rick Adams): >> In article <656@kl-cs.UUCP> jonathan@cs.keele.ac.uk (Jonathan Knight) writes: >> >> As I understand it, the argument for re-routing and short-circuiting >> revolves around the idea that some people feel they know how >> to route mail better than the people who started the mail off. > > Does anyone seriously claim that this is not true? Ignore the .1% > of the people who might know how to route mail. The incredible, overwhelming > majority of people (there implicity the overwhelming majority of mail) > have absolutely no idea how to route mail. I encourage the users at this site not to route any mail. I tell them to use the address as it is given by the person they are mailing. Ideally this is a domain name, if not the users here put .UUCP or .BITNET on in order to get to the non-domain based networks. The mailer here knows as many advertised forwarders as I can lay my hands on. It then dumps the mail for a domain onto a machine which is advertised as being a forwarder for that domain. Simple, reliable and no need for it to get re-routed. If the mailer doesn't know about a domain then I get the mail as postmaster and I then have to go and research where a forwarder for that domain exists. That way I get to know how email moves around the world and I build up a reliable mailer on this machine. -- ______ JANET :jonathan@uk.ac.keele.cs Jonathan Knight, / BITNET:jonathan%cs.kl.ac.uk@ukacrl Department of Computer Science / _ __ other :jonathan@cs.keele.ac.uk University of Keele, Keele, (_/ (_) / / UUCP :...!ukc!kl-cs!jonathan Staffordshire. ST5 5BG. U.K.
" Maynard) (07/09/89)
In article <7102@ki4pv.uucp> tanner@ki4pv.uucp (Dr. T. Andrews) writes: >In article <59767@uunet.UU.NET>, rick@uunet.UU.NET (Rick Adams) writes: >) I'm not arguing in favor of rerouting, but I can't conceive of >) even a tiny fraction of mail be routed optimally to begin with. >Define optimally. Here, to give you a start, is how we define >it. We say that mail is routed optimally if it is routed >according to the published maps, as amended by local wisdom >(local map files). I'll add one more requirement to 'optimal routing': that it reach its intended destination. I religiously avoid sending non-.edu mail via one particular route out of my site because I know it will get sent to the Black Hole of Rutgers, pass the event horizon, and never be seen again. To me, even though the mail may take an extra hop or two, I am reasonably sure it will get where I intended it to go, and that is optimal. Lost mail is not optimal. -- Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can uucp: uunet!nuchat! (eieio)| adequately be explained by stupidity. {attctc,bellcore}!texbell!splut!jay +---------------------------------------- internet: jay@splut.conmicro.com | Richard Sexton, proud Texan.
lmb7421@ultb.UUCP (L.M. Barstow) (07/10/89)
In article <656@kl-cs.UUCP> jonathan@cs.keele.ac.uk (Jonathan Knight) writes: >As I understand it, the argument for re-routing and short-circuiting >revolves around the idea that some people feel they know how >to route mail better than the people who started the mail off. > >I could never understand why people insist on re-routers and short >circuiters which are aimed at solving a problem which should not >exist and would not exist if mailers bounced mail with an error >message every time it goes wrong. > >Re-routing is very impolite, if I want my mail routed then I won't >put a route on it, but if I do put a route on it then I'd be >grateful if people would use it. If the sys admins think that they >can route mail better than I can, then declare yourselves as forwarders >for those domains and I will gladly dump my mail on you for you to route. We are also currently under the bane of a mail re-router, one popularly known as pathalias :( I don't care if this program has existed for years, it doesn't work like it could...I would much rather pathalias left alone any routing which had specific routing directions still imbedded. (ie, if there were further bang-paths in the routing, send to the next machine in the path...don't try to re-route what is probably a perfectly legal routing...if the person at the mailing end screwed up, sobeit...send *him* the nasty messages...if not, why fix what is already working (probably better than any path that the computer knows)? Our computer is not currently on the UUCP map (entry expired....oops...), and as a result, the pathalias program running on a machine 2 nodes out bounces our mail...(host unknown)...same on outgoing mail to other networks...anything with a .EDU, .COM, etc...will not go. Could people out there with these brilliant ideas to make mail go places they weren't told to go please stop? I can route my own mail, thanks... Last ex...the machine I was on last year was not on the map, but its adjacent machine was...so, the 'intelligent' mail re-router looked up the path to that machine. Next thing I knew, our mail was going through Arizona! (supposed to be routed within NW NY...) on a link which that machine polled once in a blue moon (at best)...all because one machine was not listed in the maps as being connected to it. We knew better, but the rutgers mailer didn't, so our mail was 3 wks late. Sorry, but I've been getting agrivated about these things lately, and was happy to see another post on the same topic. -- Les Barstow |Bitnet: LMB7421@RITVAX| "I can read your mind, Phoenix rising... |UUCP: | and you should be From the ashes of a lost hope,| ...rutgers!rochester!| ashamed of yourself!" To a sky of clear blue. | ritcv!ultb!lmb7421| "Stop reading my mind!"
rsalz@bbn.com (Rich Salz) (07/10/89)
I think Paul Vixie first wrote this: >The Moral: don't short-circuit. Then I replied: > Wrong. The Moral: don't put full domain names into email paths if > they're going through the Internet and you don't want them short-circuited. > Hack the path to be something like > noe!packet_radio!kg6kf_ampr_org!callsign!callsign Then Piercarlo Grandi replied; >Ugh! Ugh! Pain... Fro two reasons: this is a horrible hack, and, and, let me >repeat my NHO, this is Internet parochialism. There is nobody that has ever >said that domain names are restricted to the Internet. I don't have a problem with Piercarlo's point. However, people who read my message CAREFULLY will not that I was only talking about the Internet. I wasn't talking about anyone else. I don't care about anyone else. Please re-read my first quoted sentence again. If you take mail out of the Internet via an MX record, and you then inject it back into the Internet with a domain name, you're asking for trouble. /r$ -- Please send comp.sources.unix-related mail to rsalz@uunet.uu.net. Use a domain-based address or give alternate paths, or you may lose out.
chip@ateng.com (Chip Salzenberg) (07/11/89)
According to lear@NET.BIO.NET (Eliot Lear): >Re optimizing vs. correctness: >Bounced messages are good incentives for updated map entries. Dead pets are good incentives for fenced yards. This fact does not give me the right to run down your pet intentionally. Rabid rerouters litter the airwaves with road kills. -- You may redistribute this article only to those who may freely do likewise. Chip Salzenberg | <chip@ateng.com> or <uunet!ateng!chip> A T Engineering | Me? Speak for my company? Surely you jest!
karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) (07/11/89)
lear@NET.BIO.NET (Eliot Lear): >Re optimizing vs. correctness: >Bounced messages are good incentives for updated map entries. chip@ateng.com writes: Dead pets are good incentives for fenced yards. This fact does not give me the right to run down your pet intentionally. Rabid rerouters litter the airwaves with road kills. I must admit, that's an awfully good analogy. However, I think I can extend it one step further: The road being used is not merely a residential two-laner. It's an airport runway, with aircraft moving through at appropriate speeds. Your pet (named Fido, appropriately enough) doesn't stand a snowball's chance against the landing gear of a 767 landing at 120mph. Fencing your adjacent yard becomes a darn good idea. This is to say, I believe in Internet. There's no standard which requires me to leave a !-path intact, so (to echo one of the recurring themes, I guess) it looks like a religious argument to me. If you take it out of the Internet, leave it out of the Internet. Take a look at it from each side: [a] UUCP road kill against rabid rerouter: If you would respect my carefully constructed !-path, it would deliver just fine...and it WORKED before you mucked with it. [b] Rabid rerouter against UUCP road kill: If you would not try to use Internet FQDN host addressing in !-paths, or at least leave things out of the Internet once they've left it, you wouldn't have to worry about mail loops...and it WORKED before you mucked with such dangerous, unpredictable options at intermediate sites you don't control. The arguments go both ways. I favor [b]. On the plus side of this argument, I heard from David Dodell <ddodell@stjhmc.fidonet.org>, asking if I was having trouble with fidonet.org; I guess he'd heard about the argument but wasn't sure/aware of the details. Anyhow, I asked him how much trouble it would be to set up a set of regional MX's, say 10 of them around the country. I've offered to be both one of the MX hosts as well as to run the nameserver for him. If fidonet.org is fully interconnected, then the problem should be solvable without needing an MX per fido-host, but instead using one MX per region with the FIDONet sites taking care of the remaining routing issues internally once the regional matter was solved. I don't know if anything will come of it, but at least I'm giving it a shot. I'm not inclined merely to moan about a situation I don't like; I'd rather solve it in a palatable way. --Karl
pcg@thor.cs.aber.ac.uk (Piercarlo Grandi) (07/11/89)
In article <1894@prune.bbn.com> rsalz@bbn.com (Rich Salz) writes: I think Paul Vixie first wrote this: >The Moral: don't short-circuit. Then I replied: > Wrong. The Moral: don't put full domain names into email paths if > they're going through the Internet and you don't want them short-circuited. > Hack the path to be something like > noe!packet_radio!kg6kf_ampr_org!callsign!callsign Then Piercarlo Grandi replied; >Ugh! Ugh! Pain... Fro two reasons: this is a horrible hack, and, and, let me >repeat my NHO, this is Internet parochialism. There is nobody that has ever >said that domain names are restricted to the Internet. I don't have a problem with Piercarlo's point. However, people who read my message CAREFULLY will not that I was only talking about the Internet. I wasn't talking about anyone else. Ok, Ok. To excuse my reading of your comments, that evidently has not been careful enough, the whole discussion was about gatewaying and routing within and out the internet..., i.e. a non Internet only discussion. As to routing within the internet, it is mostly a non issue. The internet has its own standards, central administration, etc... Too easy! (this may well be the understatement of the week :->) I don't care about anyone else. But this *is* indeed Internet parochialism :->. On the other hand you admit you don't have a problem with my remark to this effect, so, end of discussion? :-> (a fortiori, as I am not on the internet? :->) Please re-read my first quoted sentence again. If you take mail out of the Internet via an MX record, and you then inject it back into the Internet with a domain name, you're asking for trouble. We have no argument here :-> :-> :->. -- Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
dg@lakart.UUCP (David Goodenough) (07/11/89)
From article <3842@phri.UUCP>, by roy@phri.UUCP (Roy Smith): > I was thinking of not > touching bang paths at all but doing lookups on person@host.UUCP type > addresses. Does this seem reasonable? Fine, but consider the following: lakart!dg from your system is going to need _ROUTING_ since phri doesn't talk to lakart. So, convert user@host.UUCP to host!user, and then route if and _ONLY_ if you don't talk directly to host. For example phri talks to acheron (according to my map data it does), so: user@acheron.UUCP wouldn't need routing, nor would: acheron!lakart!dg However, this second case assumes that acheron can route to lakart .... dg@lakart.UUCP and: lakart!dg both get routed. Paul Vixie - don't read the next bit, it will give you the shivers..... A special hack I have added is that routes that go out via cfisun here _DO_ get _REROUTED_, but that is for my own sanity. 99% of our news comes from cfisun, and it allows me to use the Path: as a route, since somewhere along the way it gets changed to a reasonable path. An interesting concept, (which I have no idea how to do) is to evaluate the "cost" of the supplied path, and the cost of the optimal path (in pathalias terms) and reroute if the supplied cost is twice (three times) or greater the cost of the optimal path. That would generally solve the Path: problem, but only where it was needed. -- dg@lakart.UUCP - David Goodenough +---+ IHS | +-+-+ ....... !harvard!xait!lakart!dg +-+-+ | AKA: dg%lakart.uucp@xait.xerox.com +---+
brent@capmkt.COM (Brent Chapman) (07/12/89)
roy@phri.UUCP (Roy Smith) writes: >In article <3648@ncar.ucar.edu> woods@handies.UCAR.EDU (Greg Woods) writes: >> Do we want mail routing to be optimal or correct? I prefer to err on the >> side of correctness, so I don't reroute explicitly-specified bang paths. I agree. > We don't currently reoute uucp mail here except for some minor >internal trickery; you can submit a bang path to any of our non-uucp >machines and they will forward it via SMTP to our uucp gateway. We run IDA >sendmail here, which has all the needed hooks to do pathalias database >lookups in the MTA layer, but I still want to provide the option of letting >people explicitly route uucp mail if they want. I was thinking of not >touching bang paths at all but doing lookups on person@host.UUCP type >addresses. Does this seem reasonable? Very reasonable. In fact, this is the most reasonable suggestion that I've seen come out of this discussion. Part of the problem is that, despite the valiant and praise-worthy efforts of the UUCP Mapping Project, there's still a lot of bullshit, incomplete, and incorrect information in the maps. By the very nature of the way the maps are maintained and distributed, I don't think they'll ever be able to deal with problems like "Hey folks, <backbone site who is on the 'best path' for lots of other sites> is going to be down for a week while we move to a new machine room", and all the myriad variations of this. I don't think that routing is bad; I think that RErouting when the user has given what he _though_ was a source-route is bad. If I send something to a!b!c!d!user because I know that site e is going to be down all afternoon for maintenance, and some so-called "smart" mailer at a reroutes this to "a!e!d!user" because it "knows" that this is a better route, I'm going to be _REAL_ pissed off... On the other hand, if I send something to "user@d.UUCP", I am _asking_ someone to route it for me, and will take whatever I can get. Now, chances are that if it becomes widely available, then 99% of the time I'll use addresses of the form "user@site.UUCP" and let someone else route for me, but I don't want to lose the _option_ of explicitly routing something when I feel it's necessary. -Brent -- Brent Chapman Capital Market Technology, Inc. Computer Operations Manager 1995 University Ave., Suite 390 brent@capmkt.com Berkeley, CA 94704 {apple,lll-tis,uunet}!capmkt!brent Phone: 415/540-6400
lear@NET.BIO.NET (Eliot Lear) (07/13/89)
Brent, Since the average length of a path after optimization is a smidgen over two, the chances of it getting rerouted to a down host down the path are small, (albeit the possibility exists). The chances of a user knowing that a particular system is down is even smaller (albeit the possibility exists). Eliot -- Eliot Lear [lear@net.bio.net]
tneff@bfmny0.UUCP (Tom Neff) (07/13/89)
Ah'm just a simpul country lawyuh <snuffle>, but isn't the following true? * If I am site X, and site Y is a direct neighbor of mine whom I poll daily or better (maybe better than anyone else if it's worse than daily), but I see a piece of incoming mail of the form a!b!X!c!d!e!Y!f!g, then it's reasonable for me to reroute it as a!b!X!Y!f!g. * If my link to site Y is sick, then I ought to respect the longer path. * If no site in the bang path is a direct neighbor of mine, then I ought to consult pathalias for the link to the site named rightward of mine, and leave the rest of it the hell alone. * In the first case mentioned above, if site Y does not know me by name (i.e., the bang path is not reversible), then I ought to respect the longer supplied path. [I think this is where most mail bounces these days, no?] -- "My God, Thiokol, when do you \\ Tom Neff want me to launch -- next April?" \\ uunet!bfmny0!tneff
jonathan@cs.keele.ac.uk (Jonathan Knight) (07/13/89)
From article <Jul.12.10.54.13.1989.18547@NET.BIO.NET>, by lear@NET.BIO.NET (Eliot Lear): > Since the average length of a path after optimization is a smidgen > over two, the chances of it getting rerouted to a down host down the > path are small, (albeit the possibility exists). Most mail leaving this site does one hop to the destination. (about 90%). Of the remaining stuff that leaves, the path is rarely more that 3. (Not one case of > 3 sites in the path has left here in the last week) > The chances of a > user knowing that a particular system is down is even smaller (albeit > the possibility exists). I'd say that no users here would know about down sites. They don't need to as they are encouraged not to put routing in their mail addresses. That way the mailer sorts out the relevent relay (if one is needed) and passes it on. If the site is down then temporary fixes can be placed in the mailer tables. The users do not need to know about any problems at all. I'm not saying that the mail takes a max of three hops to get to its destination. I just pass the mail on to the next forwarder for the address at the front of the route. That way I don't need to worry about he complexities on other networks, I just need to make sure my mailer knows about the domains in which it is placed and also where all the forwarders for other domains are located. -- ______ JANET :jonathan@uk.ac.keele.cs Jonathan Knight, / BITNET:jonathan%cs.kl.ac.uk@ukacrl Department of Computer Science / _ __ other :jonathan@cs.keele.ac.uk University of Keele, Keele, (_/ (_) / / UUCP :...!ukc!kl-cs!jonathan Staffordshire. ST5 5BG. U.K.
clewis@eci386.uucp (Chris Lewis) (07/13/89)
In article <3842@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: > I was thinking of not >touching bang paths at all but doing lookups on person@host.UUCP type >addresses. Does this seem reasonable? Ignoring Internet, It appears obvious that anyone who uses person@host.UUCP is explicitly asking for the mail system to figure out how to send things. Thus, do the lookup. If there isn't such a "host" in the maps, then you may want to simply bounce it. It also appears obvious that anyone giving an explicit bang path (eg: a!b!c!d) may very well know what they're doing, and it shouldn't be touched. The only exception is where a machine in the path doesn't have a UUCP connect to the next machine in the path. *Then* it makes sense to do a lookup, starting from the rightmost and working back until either a direct UUCP connect or a map entry is found. Eg: don't reroute unless you *know* the path won't work. We'll call this "polite" rerouting... Smail for instance, has a number of options that when set properly implement something close to this. But, for some reason many major sites insist on using full (which we can call "aggressive" or "rabid") rerouting. Which, given the (unavoidable) state of the maps seems downright silly. If I had a penny for every mail message of mine that got black-holed because of X (where X stands for my private hall-of-infamy list of demon-mailer machines from hell, and are marked "dead" in my pathalias runs)... Can you just imagine if two rabid-rerouters thought that the best way to site "foo" was thru each other? Why is this so difficult to understand or implement? Why do people explicitly break it? (I had some trouble turning it on after applying some patches to smail 2.5 and the author of the patches just simply didn't seem to care that he had partially broken polite rerouting) In article <1024@ultb.UUCP> L.M. Barstow (lmb7421@ultb.UUCP) wrote: >We are also currently under the bane of a mail re-router, one popularly >known as pathalias :( I don't care if this program has existed for >years, it doesn't work like it could...I would much rather pathalias >left alone any routing which had specific routing directions still >imbedded. (ie, if there were further bang-paths in the routing, send to >the next machine in the path...don't try to re-route what is probably a >perfectly legal routing... It ain't pathalias that's doing it, it's the ^&@*$) SA who explicitly turned on full (rabid) autorouting in their mailing software (smail, sendmail or whatever). Pathalias merely creates a list of paths to machines from the maps, it doesn't do anything to mail, unless the mailer explicitly chooses to consult the list. On the other hand, MANY times I'm very happy that quite a few machines are doing at least polite rerouting. I run a mailing list, keeping track of just 50 explicit paths is something I'd rather not do. Yes, I do have to tweak some of them - Several paths have a few nodes mentioned in them so as to get to machines not in the map, or where I know that some links in a pathalias-generated path don't work. It works pretty well - the only bounces I get are when either the user or the destination machine disappear. Does *anyone* know what happened to "videovax"? -- Chris Lewis, R.H. Lathwell & Associates: Elegant Communications Inc. UUCP: {uunet!mnetor, utcsri!utzoo}!lsuc!eci386!clewis Phone: (416)-595-5425
woods@ncar.ucar.edu (Greg Woods) (07/14/89)
In article <14467@bfmny0.UUCP> tneff@bfmny0.UUCP (Tom Neff) writes: > * If I am site X, and site Y is a direct neighbor of mine whom I poll > daily or better (maybe better than anyone else if it's worse than daily), > but I see a piece of incoming mail of the form a!b!X!c!d!e!Y!f!g, > then it's reasonable for me to reroute it as a!b!X!Y!f!g. No, it isn't. You can't know for sure that Y isn't an internal site of an organization to which "e" is a gateway. In other words, you can't know for sure that the Y you speak to is the same Y as the one intended. > * If my link to site Y is sick, then I ought to respect the longer path. This means everyone else has to trust you to change your mail configuration whenever your link gets sick. > * If no site in the bang path is a direct neighbor of mine, then I ought > to consult pathalias for the link to the site named rightward of mine, > and leave the rest of it the hell alone. Sure, what else CAN you do in that case? --Greg
steve@polyslo.CalPoly.EDU (Steve DeJarnett) (07/14/89)
In article <14467@bfmny0.UUCP> tneff@bfmny0.UUCP (Tom Neff) writes: >Ah'm just a simpul country lawyuh <snuffle>, but isn't the following true? > > * If I am site X, and site Y is a direct neighbor of mine whom I poll > daily or better (maybe better than anyone else if it's worse than daily), > but I see a piece of incoming mail of the form a!b!X!c!d!e!Y!f!g, > then it's reasonable for me to reroute it as a!b!X!Y!f!g. It would seem that way, but take the following as an example. polyslo (my site) used to talk to a site named 'athena' (at CSU Sacramento, not the more-famous MIT athena). So along comes a message with a path of: polyslo!csun!csustan!athena!joe It would seem reasonable to rewrite this to being simply: athena!joe if I decided that I knew for sure that the athena in question was the one that I talk to directly. However, what happens if 'csustan' actually talks to 'mit-athena', or some other machine named 'athena' (perhaps on their local network). Then I have taken a piece of mail destined for 'csustan!athena!joe' and rerouted it to someplace different. Not good. In your example above, you wonder if rewriting: a!b!X!c!d!e!Y!g -----> a!b!X!Y!f!g is valid. If you're going to do the kind of rewriting you talk about, why even bother with the 'a!b!X' part, when you state that you are machine 'X'?? Why not just short-circuit to 'Y!f!g'?? Again you could have problems (if your system happened to have a common name, such as 'athena') with looking ahead and seeing something that you think is you, but really is not (if you see 'athena' in the path, you could short- circuit to yourself and continue, but what if the 'athena' listed further down the path was really 'csustan!athena', and not yourself. Again, a routing faux-pas :-) My belief is that if you have: a!c!foo.bar.edu!d!e that rewriting this to: e%d@foo.bar.edu makes sense, and SHOULD work (except that we've now seen two weeks worth of religious arguments about why this should or shouldn't be done, especially w.r.t. 'fidonet.org' and their unique problems). > * If my link to site Y is sick, then I ought to respect the longer path. True. > * If no site in the bang path is a direct neighbor of mine, then I ought > to consult pathalias for the link to the site named rightward of mine, > and leave the rest of it the hell alone. Yup. If it's all UUCP !-path stuff (with no FQDN), you probably should never reroute, given the number of sites with conflicting names. ------------------------------------------------------------------------------- | Steve DeJarnett | Smart Mailers -> steve@polyslo.CalPoly.EDU | | Computer Systems Lab | Dumb Mailers -> ..!ucbvax!voder!polyslo!steve | | Cal Poly State Univ. |------------------------------------------------| | San Luis Obispo, CA 93407 | BITNET = Because Idiots Type NETwork | -------------------------------------------------------------------------------
karl@giza.cis.ohio-state.edu (Karl Kleinpaste) (07/14/89)
steve@polyslo.calpoly.edu writes:
My belief is that if you have:
a!c!foo.bar.edu!d!e
that rewriting this to:
e%d@foo.bar.edu
makes sense, and SHOULD work
Not quite. Rewriting to
d!e@foo.bar.edu
should work, because [a] foo.bar.edu will have to be prepared to strip
its name off of either end, but [b] may have (wisely) chosen not to
support %-hacks in any form, whereas [c] the presence of d!e in the
original path implies that foo.bar.edu was expecting at least that much.
This is, of course, modulo fidonet.org-style problems. I have yet to
hear back from the FIDONet person again on my suggestions to him.
--Karledguer@charlie.CES.CWRU.Edu (Aydin Edguer) (07/14/89)
In article <1888@prune.bbn.com> rsalz@bbn.com (Rich Salz) writes: >In article <VIXIE.89Jul5150330@bacchus.pa.dec.com> (Paul Vixie) writes: >>The Moral: don't short-circuit. > >Wrong. The Moral: don't put full domain names into email paths if >they're going through the Internet and you don't want them short-circuited. >Hack the path to be something like > noe!packet_radio!kg6kf_ampr_org!callsign!callsign Wrong. The Moral: if you want to play in the game, don't skip some of the rules. >>I'd better say it again, several times, since people always mix this up: >> if you don't like the paths people use, change the source mailers > >If you shoot mail into the Internet with a fully-qualified domain name >in the address -- yes, Paul, even if it's in the Path line -- than you >should expect people to follow it. That's right :-) I should expect people to follow the path I have given them. Rich, I disagree with you. I refer you specifically to "the rules." According to RFC 822, pages 32-33 ] 6.2.7. EXPLICIT PATH SPECIFICATION ] ] At times, a message originator may wish to indicate the ] transmission path that a message should follow. This is ] called source routing. The normal addressing scheme, used in ] an addr-spec, is carefully separated from such information; ] the <route> portion of a route-addr is provided for such occa- ] sions. It specifies the sequence of hosts and/or transmission ] services that are to be traversed. Both domain-refs and ] domain-literals may be used. This means that if you are given an explicit source route, YOU SHOULD OBEY IT. It's in the rules in black and white (or whatever the colors are on your printer or display). If I hand you a path <@prune.bbn.com,@bacchus.pa.dec.com:edguer@ces.cwru.edu> you should hand it to bacchus.pa.dec.com. To do otherwise is a violation of RFC 822. Period. No looking ahead. No getting smart. I agree it is frowned upon to use source routes: From RFC 822, page 33 ] 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. but if given one you should obey it. The rules for translating between UUCP and the Internet are contained in RFC 976. I quote: RFC 976, page 7 ] 3. Algorithm ] ] The algorithm for delivering a message to an address "user@domain" ] over UUCP links can be summarized as follows: ] ] a. If the address is actually of the form @domain1:user@domain2, ] the "domain" used for the remainder should be "domain1" ] instead of "domain2", and the bang form reads ] domain1!domain2!user. This leads me to believe that there should a direct mapping from "proper" "!" notation to "proper" RFC 822 and back (in the absence of mixed notations). This means that a "proper" Class C host should treat a bang path as a source route and SHOULD NOT MESS WITH IT. I think that if everyone wants to follow the rules then active rerouting should be EXTREMELY frowned upon. Passive rerouting (the UUCP equivalent of an MX record) is good. Aydin Edguer +1 216 368 6123 edguer@alpha.ces.cwru.edu Department of Computer Engineering, Crawford Hall, Case Western Reserve Univ.
roy@phri.UUCP (Roy Smith) (07/14/89)
In article <614@lakart.UUCP> dg@lakart.UUCP (David Goodenough) writes: > Fine, but consider the following: lakart!dg from your system is going > to need _ROUTING_ since phri doesn't talk to lakart. I guess it's a difference of opinion (or maybe a difference in religion) but I would say that my mailer should take lakart!dg and bounce it rather than route it, since we don't talk to lakart. My original premise was that if you want routing, you can use the @host.uucp form; if you write it in bang form, that means you know better than the maps do, or at least think you do and are willing to live with the consequences if you are wrong. -- Roy Smith, Public Health Research Institute 455 First Avenue, New York, NY 10016 {att,philabs,cmcl2,rutgers,hombre}!phri!roy -or- roy@alanine.phri.nyu.edu "The connector is the network"
karl@dinosaur.cis.ohio-state.edu (Karl Kleinpaste) (07/14/89)
Aydin, I'll throw your own argument back at you: If you want to play in the game, don't skip _some_ of the rules. The rules for source routing are explicit in the syntactic definition they must use. !-path routes do not constitute a source route. If you hand me <@here,@there,@everywhere:user@elsewhere>, I'll (probably) obey it. (Right after I clean up the mess I made by tossing my cookies all over my desk, of course.) But if you want respect granted a source route... ...PRESENT IT TO ME AS A SOURCE ROUTE. !-paths don't qualify. -- I think that everyone's brains get scrambled one way or another. --Killashandra Ree
karl@dinosaur.cis.ohio-state.edu (Karl Kleinpaste) (07/14/89)
clewis@eci386.uucp writes: > Ignoring Internet, I think the relevant quote here is approximately: "The Internet is not the entire universe, but it is its center." --attributed to Greg Woods, I believe. In other words, "ignoring Internet" is not a very good thing to do. > It also appears obvious that anyone giving an explicit bang path > (eg: a!b!c!d) may very well know what they're doing, and it shouldn't be > touched. Not so. A random sampling of 263 !-paths which passed through my system earlier this month (I picked a few wholly arbitrary "grep" criteria on /usr/spool/uucp/mail.log) revealed that the average !-path length is more than twice as long as the average length of a path in /usr/lib/uucp/paths. The users do not know what they are doing. They're guessing, and badly so. > Can you just imagine if two rabid-rerouters thought that the best way to > site "foo" was thru each other? The fact that you address the matter as "if" implies that you have never seen this occur. Is this so? I have never seen it occur, either. Therefore, in practice, this is no threat. I have more trouble with 2 mailers in a single organization which think that delivery should occur on the "other system." This is not to say that I agree entirely with GRR (General Rabid Rerouting). I prefer only DARR (Domain Absolutist RR), that is, rightmost domain strip, and only that. But I can see why others do it. -- I think that everyone's brains get scrambled one way or another. --Killashandra Ree
lear@NET.BIO.NET (Eliot Lear) (07/14/89)
In article <1989Jul13.153336.3175@eci386.uucp> clewis@eci386.uucp (Chris Lewis) writes: > It also appears obvious that anyone giving an explicit bang path > (eg: a!b!c!d) may very well know what they're doing, and it shouldn't be > touched. Far from obvious! In some instances, it will be users memorizing paths that they were told. In others, uucp addresses are placed in mailing lists and forgotten. In fact, it is impossible to tell what the intentions of an individual are when they use a UUCP address. -- Eliot Lear [lear@net.bio.net]
scs@itivax.iti.org (Steve C. Simmons) (07/14/89)
A lot of folks seem to be talking past each other here (sigh). A good point is made that internet domainist fixed routing is permitted by the syntax @fq.domain.name,@fq.domain.name,@fq.domain.name,user@fq.domain.name (or something very much like it). Karl replies this is true, but don't give it to me in the form fq.domain.name!fq.domain.name!fq.domain.name!fq.domain.name!user because it's the wrong syntax. Karl, I'd say if a user pumps a uucp message with the first form, it's never gonna get off the first host. A number of folks have made comments about gateway machines between networks should do appropriate reforming of the addresses. Presumably this would mean an Internet/uucp gateway should reform the address (route) exactly as I have done in the above example? (IDA sendmail can in fact be set up to do this.) If we go back to my old question about my wifes email (her address is user@fake_fqdn), I should be able to do something like @iti.org,@lokkur,user@fake_fqdn ^ ^ ^ | | +-- her wierd but real address | +-- uucp node at my house +-- my gateway system and get good delivery even tho fake_fqdn is not a valid internet address. Discussion? -- Steve Simmons scs@vax3.iti.org Industrial Technology Institute Ann Arbor, MI. "Velveeta -- the Spam of Cheeses!" -- Uncle Bonsai
scs@itivax.iti.org (Steve C. Simmons) (07/14/89)
karl@dinosaur.cis.ohio-state.edu (Karl Kleinpaste) writes: >clewis@eci386.uucp writes: >> Can you just imagine if two rabid-rerouters thought that the best way to >> site "foo" was thru each other? >The fact that you address the matter as "if" implies that you have >never seen this occur. Is this so? I have never seen it occur, >either. Therefore, in practice, this is no threat. Regretfully I have seen this occur. Several times. Sites involved included rutgers vs ames and several others. I didn't keep copies (sorry, no proof :-( ) but recall it most vividly. Mind you it only happens once a year or so, but it *has* happened. -- Steve Simmons scs@vax3.iti.org Industrial Technology Institute Ann Arbor, MI. "Velveeta -- the Spam of Cheeses!" -- Uncle Bonsai
edguer@charlie.CES.CWRU.Edu (Aydin Edguer) (07/14/89)
In article <KARL.89Jul13210438@dinosaur.cis.ohio-state.edu> karl@dinosaur.cis.ohio-state.edu (Karl Kleinpaste) writes: >Aydin, I'll throw your own argument back at you: If you want to play >in the game, don't skip _some_ of the rules. Karl, I normally would defer to your excellent judgement but in this case, I think I must stand my ground. I do not think I skipped any rules. I admit there were rules I did not explicitly mention. >The rules for source routing are explicit in the syntactic definition >they must use. !-path routes do not constitute a source route. According to RFC822, you are correct. According to RFC822 however, there is no such thing as a "!" path. RFC822 (only) compliant mailers therefore would be unable to process even a "fully.qualified.domain!user" address. That is the reason I also listed RFC976, the UUCP mail specification. >If you hand me <@here,@there,@everywhere:user@elsewhere>, I'll >(probably) obey it. (Right after I clean up the mess I made by >tossing my cookies all over my desk, of course.) Admittedly ugly. Feel free to lose your lunch even if it is valid. >But if you want respect granted a source route... >...PRESENT IT TO ME AS A SOURCE ROUTE. >!-paths don't qualify. Bang paths do qualify in my opinion because of RFC976. RFC976 says that a gateway should change an RFC822 source route into an RFC976 bang path when sending to the next hop via UUCP. This means that if you receive a bang path via UUCP you may be receiving a valid RFC822 source route from another site that is following the rules. This is why I feel that to properly comply with the mail RFC's you should treat ALL bang paths as valid source routes. No active rerouting. The problem of doing a direct translation of a bang path back into an RFC822 source path that would satisfy your request is that RFC822 requires that all the hosts in the source route be fully qualified domain names! If this were not true I would hand you via NSFnet a valid RFC822 source route rather than a bang path. But I am not allowed to unless I validate each "domain" in the bang path. If you do still do not like the idea of a bang route as a source route then consider it in a different light. According to RFC822, anything to the left of the "@" symbol is defined to be local information. It should not be interpreted except at the "destination." If I give you a bang path via the Internet: b!c!d@a then "b!c!d" is local information to the site "a" (you). You should take then path, strip off your name and process the local information. As a first step you should transform it according to RFC976 back into: c!d@b Now there exists a local part "c!d" and a destination "b". Once again there is local information which you should not touch. You should attempt delivery as best you can to domain b. If you follow the rules (at least in my interpretation) you should treat a bang path as a source route. I see the problem as threefold. If all UUCP sites understood RFC822 notation then we could use bang paths as "this is the path I know, reroute as best you know", and RFC822 source routes as source routes. But not all UUCP sites understand "@". If there was a direct mapping from RFC976 to RFC822 then I would hand you an RFC822 source route instead of a bang path. But there is none and trying to mix notations is a bad idea. If there was a perfect set of maps that was always up to date, knew all private links (and when it was allowed to use them) and all internal hosts behind a UUCP gateway and what machines were down for repair or disposal then I would think rabid rerouters were a good idea. Unfortunately these three problems exist and so I feel that active rerouting is bad. I do agree with passive routing. Aydin Edguer +1 216 368 6123 edguer@alpha.ces.cwru.edu Department of Computer Engineering, Crawford Hall, Case Western Reserve Univ.
karl@giza.cis.ohio-state.edu (Karl Kleinpaste) (07/15/89)
edguer@charlie.ces.cwru.edu writes: > According to RFC822, you are correct. According to RFC822 however, > there is no such thing as a "!" path. True, but there is such a thing as a "local part," with which I am free to do as I please, including a rewrite into @-format. > Bang paths do qualify in my opinion because of RFC976. RFC976 says > that a gateway should change an RFC822 source route into an RFC976 > bang path when sending to the next hop via UUCP. This means that > if you receive a bang path via UUCP you may be receiving a valid > RFC822 source route from another site that is following the rules. > This is why I feel that to properly comply with the mail RFC's you > should treat ALL bang paths as valid source routes. No active rerouting. I see what you're getting at; the point is well taken. But I think there are problems with the interpretation of it. Passive rerouting, when the first specified host in the path is unknown, is a violation of the source-route rules as much as active rerouting. If we're going to attach strict source route rules to !-paths, then we have to obey those rules. Those rules say that, if you give me <@a.b,@c.d,@e.f:u@g.h> then I must hand the mail _directly_ to a.b. It doesn't say that I may find my own best intermediate-hop route to a.b; it says I have to go straight there. On the Internet, this is fine, since one assumes complete interconnectivity. I can't do that in the Land of UUCP, in general. An indirect proof for everyone... [1] Condition: "!-paths" are to be equated with "source routes." [2] Conclusion: Interpretation of source routes according to the RFCs requires that a relay host send directly to the first routed host specified in the source route. [3] In UUCP, a relay host cannot, in general, be counted on to be connected to the first such host. [4] Therefore, the conclusion is false, so the condition must also be false. My, I can feel it getting warmer in here already... --Karl
peter@ficc.uu.net (Peter da Silva) (07/15/89)
In article <KARL.89Jul13215059@dinosaur.cis.ohio-state.edu>, karl@dinosaur.cis.ohio-state.edu (Karl Kleinpaste) writes about two rabid rerouters routing through each other. > The fact that you address the matter as "if" implies that you have > never seen this occur. Is this so? I have never seen it occur, > either. I've had this happen to messages of mine at least once, and possibly twice. I wish I still had the message, but it was some time ago... you'll have to take my word for it. I seem to recall that one of the participants was at athena.mit.edu, and I don't recall where the other was, but it was another university. Most of the time rerouting just breaks a working path and I end up with a bounced message or a vanished one. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: peter@ficc.uu.net, +1 713 274 5180. | Th-th-th-that's all folks... Personal: peter@sugar.hackercorp.com. `-_-' | -- Mel Blanc Quote: Have you hugged your wolf today? 'U` | May 30 1908 - Jul 10 1989
edguer@alpha.ces.cwru.edu (Aydin Edguer) (07/15/89)
In article <KARL.89Jul14145852@giza.cis.ohio-state.edu> karl@giza.cis.ohio-state.edu (Karl Kleinpaste) writes: > My, I can feel it getting warmer in here already... Don't worry, I have the breeze off the lake to keep me cool :-) > Passive rerouting, when the first specified host in the path is > unknown, is a violation of the source-route rules as much as active > rerouting. If we're going to attach strict source route rules to > !-paths, then we have to obey those rules. Those rules say that, if > you give me > <@a.b,@c.d,@e.f:u@g.h> > then I must hand the mail _directly_ to a.b. It doesn't say that I > may find my own best intermediate-hop route to a.b; it says I have to > go straight there. You are quite correct. You should try to deliver the mail directly to a.b or else return a failure, WITH THE EXCEPTION OF AN MX RECORD. However, this just means that your logic example [deleted for brevity] is flawed because the conclusion is correct (not false) and thus the condition is still valid (correctness, we are still debating). This means that if you receive a message to "b!c!d@a", after removing "a" and rewriting using rfc976 (leaving you with "c!d@b"), you must be able to reach site "b". At this point you have three options. All of which I feel are within the rules. Option one is to return an error message if you are unable to get to site "b" directly via UUCP or SMTP. This means that all our User Agents (UA) must be made more intelligent. The Mail Transport Agents (MTA) should not try to do routing. I do not know how well this would agree with most people. Option two is to return an error message if you are unable to get to site "b" directly via UUCP or SMTP and "b" is part of a source route address ("c!d@b")[i.e. it is not a simple address "x@b"]. I think more people would agree with this solution since so many of our UA's depend upon the MTA's to have the smarts for routing simple addresses. Whether this is "GOOD" or not is another debate. Option three is to say that it should try to deliver mail to site "b" using the information available to it, treating pathalias data as just another form of MX record. When looking up a name via the Domain Name Service (DNS) we accept an MX record to be the equivalent of a host record for ALL mail purposes (including source routing). What this option asks us to do is treat a pathalias record as the equivalent of a host record for mail purposes. Notice, this does not imply that we should short circuit (actively reroute) a source-route just because there is an MX (pathalias) record for a host. It should still go to each host along the route. I hold option three to be the best way to go, but I can see the usefulness of any of the three options. Aydin Edguer +1 216 368 6123 edguer@alpha.ces.cwru.edu Department of Computer Engineering, Crawford Hall, Case Western Reserve Univ.
lmb7421@ultb.UUCP (L.M. Barstow) (07/15/89)
In article <KARL.89Jul14145852@giza.cis.ohio-state.edu>, karl@giza.cis.ohio-state.edu (Karl Kleinpaste) writes: > > Passive rerouting, when the first specified host in the path is > unknown, is a violation of the source-route rules as much as active > rerouting. If we're going to attach strict source route rules to > !-paths, then we have to obey those rules. Those rules say that, if > you give me > <@a.b,@c.d,@e.f:u@g.h> > then I must hand the mail _directly_ to a.b. It doesn't say that I > may find my own best intermediate-hop route to a.b; it says I have to > go straight there. Karl, you're scraping for arguments...if you want to throw insensible arguments back and forth, do it in alt.flame - we don't need it here. The rules are set up for INTERNET, not UUCP. When UUCP steps in, you have to interpret a bit. First, if a-b isn't connected directly, but you can find it, re-route...what's wrong with this? Our machine does not run pathalias at all. However, there are several machines downwind which do. It is convenient to send them a partial path so that they can re-route it efficiently. On the other hand, there are a number of connections that pathalias can't find, and thr "rabid rerouter" group bounce these sites. So, if I route a message through pathalias, I want it to put the message where it's going. But if I send an explicit path, I want it to follow my directions. Please, I think you're getting worried that you're running out of valid points, and it doesn't become you. -- Les Barstow |Bitnet: LMB7421@RITVAX| "I can read your mind, Phoenix rising... |UUCP: | and you should be From the ashes of a lost hope,| ...rutgers!rochester!| ashamed of yourself!" To a sky of clear blue. | ritcv!ultb!lmb7421| "Stop reading my mind!"
lmb7421@ultb.UUCP (L.M. Barstow) (07/15/89)
In article <1989Jul13.153336.3175@eci386.uucp> clewis@eci386.UUCP (Chris Lewis) writes: > >Smail for instance, has a number of options that when set properly implement >something close to this. But, for some reason many major sites insist on >using full (which we can call "aggressive" or "rabid") rerouting. Which, >given the (unavoidable) state of the maps seems downright silly. If I >had a penny for every mail message of mine that got black-holed because >of X (where X stands for my private hall-of-infamy list of demon-mailer >machines from hell, and are marked "dead" in my pathalias runs)... > I must admit, this is the most creative, easiest, funniest (to someone who's had the experience), and just plain best way to deal with the situation. Give that man a Kudo for outdoing the rabid mail re-routers from hell! rutgers should be shot for the over-re-routing (yeah, so it's a backbone...unfortunately, about half my mail goes through there, and bounces rather handily....and now rochester's got the same problem, and *all* of my mail goes through there. Great. DisClaymore: Dis Claymore is *my* Claymore...any arguments >;^} -- Les Barstow |Bitnet: LMB7421@RITVAX| "I can read your mind, Phoenix rising... |UUCP: | and you should be From the ashes of a lost hope,| ...rutgers!rochester!| ashamed of yourself!" To a sky of clear blue. | ritcv!ultb!lmb7421| "Stop reading my mind!"
jonathan@cs.keele.ac.uk (Jonathan Knight) (07/15/89)
I can see that the re-routers are unlikely to stop re-routing or
short circuiting so this argument is unlikely to have any useful
effect.
I generally feel that re-routers are treating a symptom and not
the cause of badly routed mail. The cause of badly routed mail
lies with the user or the mailer which originated the mail. So I
propose a solution:
After re-routing the mail, the re-router should send mail to the
orginator of the mail explaining what has happened and
suggesting they see their local postmaster. Something along the
lines of:
" Your mail arrived here using this route a!b!c and was routed
to d!e!f!g. However a more optimum path from your site to site
'f' and user 'g' would have been a!b!j!f!g. Your mail has been
routed j!f!g from here. Please consult your local postmaster
for additional information. "
This will solve the cause of the problem, as users who guessed a
route will become gradually better informed about a better route
and the local postmaster (or whoever looks after the mail) will be
able to better configure his or her mailer. If the problem lies at
another site then the postmaster should be able to deduce where
the problem lies and call up the postmaster at that site.
Hopefully over time the need for re-routing will gradually die
out.
Perhaps those who don't re-route could also generate messages like
the above to educate users about optimum mail paths.
------------------------------------------------------------------
Short circuiting is a little harder to deal with. The problem is
that it is harder to justify. Paths that look like this:
a.b.c.d!e.f.g.h!j.k.l.m!z
don't look good. However paths like this:
z%j.k.l.m%e.f.g.h@a.b.c.d
are justifyable (see my first posting which explains why this is
necessary). No-one can claim that the above is equivalent to
z@j.k.l.m
unless they hold up to date tables (and I MEAN up to date - even
to the point of getting local bulitins of machines that went down
that morning) of all the domains in use in the world today.
Even so, there will be some who think that they can short circuit
without problems, so perhaps they also should generate mail back
to the sender so they can query their postmaster to find a better
way of addressing their mail.
I feel that moves must be made to eradicate badly addresses mail
from the network, rather than trying to patch it up once its on
its way. Sending mail back to the users telling them that they've
done it wrong is a start, it should make people look more closely
at how they address their mail - it might help.
--
______ JANET :jonathan@uk.ac.keele.cs Jonathan Knight,
/ BITNET:jonathan%cs.kl.ac.uk@ukacrl Department of Computer Science
/ _ __ other :jonathan@cs.keele.ac.uk University of Keele, Keele,
(_/ (_) / / UUCP :...!ukc!kl-cs!jonathan Staffordshire. ST5 5BG. U.K.david@ms.uky.edu (David Herron -- One of the vertebrae) (07/17/89)
There's some misinformation running around in this topic thread ..
yes there's lots of places not directly on the internet which
have domain names. But -- assuming they have a proper right
to use the domain name -- it's legit. Even those sites in england
are legit, because .uk was assigned to some authority in england
by the folk at SRI-NIC.
The domain space *IS* rooted, but isn't centrally managed. The
UK folk have their piece just as everybody else does.
Something I've heard said a lot recently is along the lines that
it's somehow evil to have mailers which believe they know more about
routing than the sender does.
I wonder ... how do you know the sender knows *ANYTHING* about routing?
In my environment, most of the users don't care a whit about UUCP
routing, or any other routing style at that. They just want to use
a simple addressing style, user@place is fine, and send it off.
So I configure the mailer here to use pathalias to generate a list
of routes and tell people to specify user@host.uucp, but *they*
don't know anything.
It would please me greatly if there were some better way that I could
tell my mailer to get mail to somewhere else. Even though us map maintainers
do a pretty good job at map maintaining, we're not perfect... Lots
of links are dead/bad/flaky, and just change all the time anyway.
This system of routing is *inherently* incapable of handling the
number of systems attached to it. No person can keep a map of
the network, in its current state, in his/her head.
An interesting alternative routing system is vaguely related to
something that AT&T does internally.
That is, "guidepost" routing system.
In guidepost routing, a message passing through the network has
attached to it some hints about where it's supposed to go. It's
rather like how people find their way around in the real world,
go down main street until you see the green house with chartreuse
shutters then turn left ...
Everybody's familiar with the idea that you can send mail to
att!some-machine!some-user and have it get there, even though
some-machine may be a couple hops away. And 'att' isn't just
one machine, it's many machines spread all over the country.
Well, internally they've taken that farther, with (at least)
an 'arpa' "machine" through which you route mail to send it
out to the TCP/IP network.
At a first guess I think, if "we" adopted a system like that we
could set up names for every city or (other geographical area)
and put out addresses like
lex.ky.us!davids!david
dal.tx.us!killer!wisner
chi.il.us!chinet!...
chi.il.us!bay.ca.us!...
It's similar to the old system of listing your address relative
to some well known site ...
It's silly that the current system encourages that all sites
be listed in the official maps... It makes the maps so unweildy, see,
and isn't necessary for 80-90% of the cases.
--
<- David Herron; an MMDF guy <david@ms.uky.edu>
<- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<-
<- WARNING: Hunting season is now open in West Virginia!david@ms.uky.edu (David Herron -- One of the vertebrae) (07/17/89)
In article <59767@uunet.UU.NET> rick@uunet.UU.NET (Rick Adams) writes: >> In article <656@kl-cs.UUCP> jonathan@cs.keele.ac.uk (Jonathan Knight) writes: >> >> As I understand it, the argument for re-routing and short-circuiting >> revolves around the idea that some people feel they know how >> to route mail better than the people who started the mail off. >Does anyone seriously claim that this is not true? Ignore the .1% I wonder ... how do you know the sender knows *ANYTHING* about routing? In my environment, most of the users don't care a whit about UUCP routing, or any other routing style at that. They just want to use a simple addressing style, user@place is fine, and send it off. So I configure the mailer here to use pathalias to generate a list of routes and tell people to specify user@host.uucp, but *they* don't know anything. It would please me greatly if there were some better way that I could tell my mailer to get mail to somewhere else. Even though us map maintainers do a pretty good job at map maintaining, we're not perfect... Lots of links are dead/bad/flaky, and just change all the time anyway. This system of routing is *inherently* incapable of handling the number of systems attached to it. No person can keep a map of the network, in its current state, in his/her head. An interesting alternative routing system is vaguely related to something that AT&T does internally. That is, "guidepost" routing system. In guidepost routing, a message passing through the network has attached to it some hints about where it's supposed to go. It's rather like how people find their way around in the real world, go down main street until you see the green house with chartreuse shutters then turn left ... Everybody's familiar with the idea that you can send mail to att!some-machine!some-user and have it get there, even though some-machine may be a couple hops away. And 'att' isn't just one machine, it's many machines spread all over the country. Well, internally they've taken that farther, with (at least) an 'arpa' "machine" through which you route mail to send it out to the TCP/IP network. At a first guess I think, if "we" adopted a system like that we could set up names for every city or (other geographical area) and put out addresses like lex.ky.us!davids!david dal.tx.us!killer!wisner chi.il.us!chinet!... chi.il.us!bay.ca.us!... It's similar to the old system of listing your address relative to some well known site ... It's silly that the current system encourages that all sites be listed in the official maps... It makes the maps so unweildy, see, and isn't necessary for 80-90% of the cases. -- <- David Herron; an MMDF guy <david@ms.uky.edu> <- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET <- <- WARNING: Hunting season is now open in West Virginia!
david@ms.uky.edu (David Herron -- One of the vertebrae) (07/17/89)
In article <KARL.89Jul13210438@dinosaur.cis.ohio-state.edu> karl@dinosaur.cis.ohio-state.edu (Karl Kleinpaste) writes: >Aydin, I'll throw your own argument back at you: If you want to play >in the game, don't skip _some_ of the rules. > >The rules for source routing are explicit in the syntactic definition >they must use. !-path routes do not constitute a source route. Karl, what'chu been smokin' boy? !-routes are too source routes! Not within the rfc-822 frame of source routes, but within the rfc-976 frame of view. Just as IP has it's own view of what source routes are, so does UUCP and domain-land. The things that Aydin quoted are very good points by which to live. -- <- David Herron; an MMDF guy <david@ms.uky.edu> <- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET <- <- WARNING: Hunting season is now open in West Virginia!
karl@dinosaur.cis.ohio-state.edu (Karl Kleinpaste) (07/17/89)
lmb7421@ultb.uucp writes:
Pushing things, Karl?
Well...yeah. I mean, of course I am. That's the whole idea. I'm
having entirely too much fun while I'm at it, too. If I'm successful,
I'll push it right over the edge. And I'm not trying to be insensible
at all; I'm just trying to find out how far people (such as Aydin) are
willing to push this !-path/source-route equivalence game.
The rules are set up for INTERNET, not UUCP.
Well, that's kinda how I look at matters, too. But Aydin has
suggested some fairly rigorous applications of Internet rules in the
context of UUCP. First he makes a (rather low-key, off-the-wall)
suggestion that !-paths are source routes. I responded by saying it's
in the wrong format. Aydin came back with RFC support for his
position; points well taken. I attempted to complete the analogy by
finding (what I thought was) an intractable special case. Aydin has
come back again with the further enhancement that pathalias data == MX
records in UUCP context.
[Aydin! MX records?!? Do you realize what you've said? Do you know
how far that takes you? Oh, Aydin - I'm going to have _SUCH_ fun
tomorrow morning after I have a chance to look over my RFCs a while.
I want to make sure my next followup is really as airtight as
possible. :-]
You see, I happen to have a thorough dislike for GRR, preferring the
much less catastrophic DARR instead, because of the "absolute" nature
of FQDNs. But I can see the justification that many people put forth
for their GRR preference. And I don't see that they're doing anything
email-immoral, because I don't think the standards apply; there are
too many differences in what's going on, and Aydin is going to be
sorely disappointed (I think, after I check my RFCs; no copies here at
home) with how far I think things have to be pushed.
So...Yes, I'm pushing things. I'm pushing them a long way, hopefully
right over the edge. Now, I may well be wrong; Aydin may come back
with an RFC-based argument that leaves me gasping for air. But I'm
thoroughly enjoying the intellectual exercise along the way.
Don't take the world too seriously _all_ the time...
Grins,
--Karlscs@itivax.iti.org (Steve C. Simmons) (07/17/89)
karl@dinosaur.cis.ohio-state.edu (Karl Kleinpaste) writes: >lmb7421@ultb.uucp writes: > The rules are set up for INTERNET, not UUCP. >Well, that's kinda how I look at matters, too. But Aydin has >suggested some fairly rigorous applications of Internet rules in the >context of UUCP. First he makes a (rather low-key, off-the-wall) >suggestion that !-paths are source routes. I responded by saying it's >in the wrong format . . . Hmmm...I'll let you RFC experts look this one up: Aren't gateways supposed to handle all the issues of reformatting (which may or may not mean rerouting) addresses when crossing networks? Thus if I send bangist mail thru an internet gateway, shouldn't the gateway reform it from foo!bar!baz!user to @foo,@bar,@baz,@user or something similar? This preserves the uucp routing specified and gets things into a state where rerouting is definately Rude. Re Karls comments about possibly disjoint pairs in routes (ie, bar!baz link doesn't exist, and you are bar) -- it's a sender error. Return to sender. Don't attempt to redeliver, recover, reroute, etc. The sender specified a route that don't work, so return to sender. When you use specified routing, you damned well better get it right. >Don't take the world too seriously _all_ the time... >Grins, Just a quick compliment for you guys: it's a real pleasure to see folks have a serious disagreement without burning down the house. Nice. -- Steve Simmons scs@vax3.iti.org Industrial Technology Institute Ann Arbor, MI. "Velveeta -- the Spam of Cheeses!" -- Uncle Bonsai
lear@NET.BIO.NET (Eliot Lear) (07/18/89)
About gateways, they can do anything they please with your mail. For example, if karl@dinosaur.cis.ohio-state.edu mails to itivax!scs@xyzzy.com, xyzzy deliver to itivax the address, xyzzy!karlWHOOPYdinosaur.cis.ohio-state.edu, and xyzzy will have done its job as a gateway. (And it would have also addressed the issues in RFC976, no mixed mode addresses here!). -- Eliot Lear [lear@net.bio.net]
karl@cheops.cis.ohio-state.edu (Karl Kleinpaste) (07/18/89)
In our ongoing saga of whether full Internet semantics should be applied to !-paths as source routes, edguer@alpha.ces.cwru.edu writes: > You are quite correct. You should try to deliver the mail directly to a.b > or else return a failure, WITH THE EXCEPTION OF AN MX RECORD. > ... > Option three is to say that it should try to deliver mail to site "b" > using the information available to it, treating pathalias data as > just another form of MX record. When looking up a name via the > Domain Name Service (DNS) we accept an MX record to be the equivalent of > a host record for ALL mail purposes (including source routing). > What this option asks us to do is treat a pathalias record as the equivalent > of a host record for mail purposes. You left out an extremely important aspect of MX records and so forth, which is the delivery algorithm, as specified in the RFCs, especially 974: Find the MX records. Delete those MX records which "don't qualify" (worse precedence than self, self-references, etc). Deliver to the best MX host: Find its A record. Open SMTP to it. Deliver. Allowing for the following equivalences... SMTP/DNS UUCP/comp.mail.maps -------- ------------------- A records entries in Systems/L.sys files MX records pathalias data, usually as compiled into /usr/lib/uucp/paths ...I submit that the RFC delivery algorithm requires that active reroute of the first hop must occur at each relay point along the path to the destination. [Ooo! What'd he say? :-] MX records are dealt with before A records. This is _not_ optional. Therefore, one _must_ reroute the first hop. It is accepted that an empty MX list may be found, in which case a one-entry MX list is substituted consisting of the indicated remote system with a maximal preference. This means that either the first hop shows up in one's paths file, or it must be present in one's Systems file, or both. If it is present in one's paths file, whatever path is there takes precedence. (It is a simple matter, of course, to ensure that one's paths for direct UUCP neighbors are one hop long.) Notice, this does not imply that we should short circuit (actively reroute) a source-route just because there is an MX (pathalias) record for a host. It should still go to each host along the route. On the contrary, _if_ you wish to apply such strict Internet semantics, this does indeed imply exactly that. One _must_ accommodate the MX specifications before attempting anything else. If the MX specifications are wrong, then one is free to ignore them in order to route around their errors (see 974's discussion of looping problems and table inconsistencies, and the need to flush caches); but one must accommodate them nonetheless. The mail will still get to each host specified in the path, but it may take quite a number of extra hops to get there. I argue that this is patently silly; that a _requirement_ to reroute actively at each relay is consummately wrong, and hence is to be ignored. Therefore, I conclude that !-paths must not be source routes if source routes require such mechanisms. That is the real goal I have in mind - to demonstrate that Internet standards do not apply to UUCP !-paths except in rather limited fashions, such as those defined by (the extremely short) RFC976. All that 976 does is to say that an Internet source route <@a,@b:c@d> should be converted to a!b!d!c (section 3.a, page 7). It says little more about these sorts of issues, and does not suggest that complete source route semantics apply thereafter. If !-paths are not source routes, then the RFCs do not apply; if they do not apply, then I may do with them as I see fit. Some see fit to perform GRR; I see fit to perform DARR. Neither is email-immoral, but one can now discuss what might be preferable, in the absence of documented standards. --Karl PS- GRR = General Rabid Rerouting; DARR = Domain Absolutist Rabid Rerouting (i.e., strip to rightmost FQDN [fully-qualified domain name]).
chip@ateng.com (Chip Salzenberg) (07/18/89)
According to karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste): >Take a look at it from each side: >[a] UUCP road kill against rabid rerouter: If you would respect my >carefully constructed !-path, it would deliver just fine...and it >WORKED before you mucked with it. >[b] Rabid rerouter against UUCP road kill: If you would not try to use >Internet FQDN host addressing in !-paths, or at least leave things out >of the Internet once they've left it, you wouldn't have to worry about >mail loops...and it WORKED before you mucked with such dangerous, >unpredictable options at intermediate sites you don't control. Argument [b] doesn't hold up. Fully Qualified Domain Name host addressing is not only for Internet hosts; rather, it is the standard way of naming hosts reachable from the Internet. Consider all the domains without Internet connections -- much of EUNet, for example, or Ateng.COM. :-) Must all bang paths be beheaded when they reach the Internet, just because _some_ of their brethren are invalid? IMNO, part of the solution to the bang path problem could be the widespread use of Smail 3.0, which determines the appropriate transport strictly from the hostname, not from the address syntax. For example, <uunet.uu.net!rick> is delivered exactly the same as <rick@uunet.uu.net>. But it's hard to get; it looks to me that Smail 3.0 will end the year still in Alpha test. Sigh. -- You may redistribute this article only to those who may freely do likewise. Chip Salzenberg | <chip@ateng.com> or <uunet!ateng!chip> A T Engineering | Me? Speak for my company? Surely you jest!
chip@ateng.com (Chip Salzenberg) (07/18/89)
According to tneff@bfmny0.UUCP (Tom Neff): >Ah'm just a simpul country lawyuh <snuffle>, but isn't the following true? > > * If I am site X, and site Y is a direct neighbor of mine whom I poll > daily or better (maybe better than anyone else if it's worse than daily), > but I see a piece of incoming mail of the form a!b!X!c!d!e!Y!f!g, > then it's reasonable for me to reroute it as a!b!X!Y!f!g. No. In UUCP land, you have NO guarantee that the Y known by you is the same Y that appears in the bang path. -- You may redistribute this article only to those who may freely do likewise. Chip Salzenberg | <chip@ateng.com> or <uunet!ateng!chip> A T Engineering | Me? Speak for my company? Surely you jest!
kdg@nirvo.UUCP (Kurt Gollhardt) (07/18/89)
Here's my .02 on bang paths as source routes: In preface, let me say that I think any way in which rfc822 et al. can be applied to the uucp world is "a good thing" (as long as it's correct and feasible). Thinking of bang paths as source routes and uucp maps as MX records is, perhaps, a good starting point for thinking about some of the issues; however, there are some problems with these equivalences which must be kept in mind, and which may even make them impossible. As I see it, there are two fundamental problems with bang paths which make them definitely distinct from source routes: 1) Bang paths are not an explicit source routing syntax. While bang paths generated by the user at the source, are IMHO (intended as) source routes, an intermediate site along the path can't know whether a bang path it sees was entered by the user or generated by software. For instance, smail 2.5 will put out bang paths for all destinations, even for FQDNs (at least, as it's configured at my site). The bang path put out by smail *is* intended (by smail) as a route specification, but it was not (necessarily) specified by the user as such, so it should not be considered gospel. On the other hand, smail *does* leave the original form of the address in the To: line; unless, of course, the message had an (arbitrary) To: line in it, which smail then uses instead. It seems to me that To: lines can't be trusted (or, at least, expected; some mailers don't even put them on), which leaves the concatenation of the From_ envelope and the rmail args. But the latter will always be a bang path, so you can't tell if the original user gave !'s or @'s. 2) Nodes in a bang path are not absolute, unique, names. In an internet source route, each system named un-ambiguously refers to a specific site. In the uucp world, there may be two (or many) systems named athena, or hermes, or what-have-you. An internet source route means send this message from *THIS* system via *THAT* system to *THIS OTHER* system. A uucp bang path, if interpreted as a source route, would mean: send this message from this system via *SOME* system named so-and-so to *SOME* system named such-and-such; in the world of the uucp maps, this could be interpreted uniquely, but the world of the maps is not the real world; there are systems out there which aren't on the maps, and they have to be considered, *especially* in the context of source routes. Those, I think, are the (only?) 2 points where bang paths cannot be mapped to the internet source route model. This means that in order to apply the internet routing model to uucp, one of two things must happen. Either the above two "problems" must be "fixed", or the model must be modified (for use in the uucp world) to take these differences into account. The latter is what rfc976 attempts to address, in general, but it doesn't cover this particular issue very much. Of these two items, I think only the first one has any hope of changing in the near future; perhaps through stricter handling of To:, or perhaps through a new header such as Route-Via:. -- ============== ============== # Kurt Gollhardt Nirvonics, Inc. -- Plainfield, NJ # # ...!rutgers!nirvo!kdg Software Design and Consulting # ============== ==============
karl@cheops.cis.ohio-state.edu (Karl Kleinpaste) (07/18/89)
[me:] >[b] Rabid rerouter against UUCP road kill: If you would not try to use >Internet FQDN host addressing in !-paths, or at least leave things out >of the Internet once they've left it, you wouldn't have to worry about >mail loops...and it WORKED before you mucked with such dangerous, >unpredictable options at intermediate sites you don't control. chip@ateng.com writes: Argument [b] doesn't hold up. Fully Qualified Domain Name host addressing is not only for Internet hosts; rather, it is the standard way of naming hosts reachable from the Internet. Consider all the domains without Internet connections -- much of EUNet, for example, or Ateng.COM. :-) On the contrary... If a piece of mail arrives here specifying an envelope some!where!over!the!rainbow!ateng.com!chip my sendmail configuration will slice, dice, and julienne-fry it into chip@ateng.com whereupon sendmail will look up ateng.com, find that the MX is uunet.uu.net, and send it there...just one hop from you, where you routinely expect high-quality, reliable mail transfer service. The fact that you're not on the Internet is irrelevant; assuming that an MX host is "close" to the intended destination (fidonet.org does not currently apply, but I'm working on that), I strip out a lot of intervening, unreliable cruft in order to reach that destination. I tend to think of this as better mail relay service, not an abuse of paths. I've never yet had anyone complain to me about it. Must all bang paths be beheaded when they reach the Internet, just because _some_ of their brethren are invalid? Probably. Their success rate is comparatively low, especially when the path is "long." Too many sites still have news interfaces replying to Path: headers. The success rate of MX'd FQDN destinations is a _great_ deal higher. --Karl
lmb7421@ultb.UUCP (L.M. Barstow) (07/19/89)
In article <12185@s.ms.uky.edu> david@ms.uky.edu (David Herron -- One of the vertebrae) writes: > >Something I've heard said a lot recently is along the lines that >it's somehow evil to have mailers which believe they know more about >routing than the sender does. > >I wonder ... how do you know the sender knows *ANYTHING* about routing? >In my environment, most of the users don't care a whit about UUCP >routing, or any other routing style at that. They just want to use >a simple addressing style, user@place is fine, and send it off. >So I configure the mailer here to use pathalias to generate a list >of routes and tell people to specify user@host.uucp, but *they* >don't know anything The better suggestion is...if they specify a host user@host.UUCP, interpret it for them...but if they specify a path, just send it to the next machine on the list, or bounce it if you can't do that. As for figuring out if the sender *does* know something, if it has a path, assume they person knows something...if not, or if the path is wrong, assume (s)he's stupid (no insult intended). And, yes, after putting up with evil mailers which think they know more than I do about routing my mail, it *is* evil to have such mailers. I hate waiting weeks for my mail, and I hate being told by aa rabid re-router that a site off-net doesn't exist, just because it isn't in the net maps. Is this so hard to understand? If it takes an extra hop or two because I didn't catch some obscure routing, fine...if it doesn't go through because a rabid re-router didn't catch some obscure re-routing, that is *not* fine. I'd rather have slow mail than no mail. SunSinger -- Les Barstow |Bitnet: LMB7421@RITVAX "What about the R.O.U.S's?" |UUCP: ...rutgers!rochester!ritcv!ultb!lmb7421 "The Rodents Of Unusual Size? |ARPA: lmb7421@ultb.isc.rit.edu I don't believe they exist!" - Buttercup and Wesley, _The Princess Bride_
clewis@eci386.uucp (Chris Lewis) (07/19/89)
In article <KARL.89Jul13215059@dinosaur.cis.ohio-state.edu> karl@dinosaur.cis.ohio-state.edu (Karl Kleinpaste) writes: >clewis@eci386.uucp writes: >In other words, "ignoring Internet" is not a very good thing to do. True, but I was refering to UUCP-only situations. >> It also appears obvious that anyone giving an explicit bang path >> (eg: a!b!c!d) may very well know what they're doing, and it shouldn't be >> touched. >Not so. A random sampling of 263 !-paths which passed through my >system earlier this month (I picked a few wholly arbitrary "grep" >criteria on /usr/spool/uucp/mail.log) revealed that the average !-path >length is more than twice as long as the average length of a path in >/usr/lib/uucp/paths. The users do not know what they are doing. >They're guessing, and badly so. That isn't necessarily the right conclusion - it *could* be that the the maps are busted in certain ways not of interest to the net as a whole, but of *extreme* importance to backwaters, and the backwaters have carefully tuned *their* maps to get where they want to go. Or, it could be that your maps are out of date. There's probably a better chance that the route was constructed by pathalias in the first place, by someone who's had to try to get things thru reliable paths. Eg: according to the published maps on our machine, our path to uunet has been variously: - thru a machine in Ottawa 300 miles the other way, that has been dead for months, - thru a machine in Waterloo, who's gateway fires it thru a machine in Toronto that we have a much better route to. - thru a machine in Arizona that advertises a bogus link to ihnp4 (this was a *looong* time ago) - thru munnari.... Not ONCE in recorded history has the published maps pointed to the machine only two hops away that has graciously offered to forward all traffic to uunet. So, in my path.local file, I gave up and said: <gracious-machine> uunet(0) Rabid rerouting completely defeats this. >> Can you just imagine if two rabid-rerouters thought that the best way to >> site "foo" was thru each other? > >The fact that you address the matter as "if" implies that you have >never seen this occur. Is this so? Other people have. I have seen it occur in a different sense - at one time pathalias thought all mail to the USA went via Belgium, Korea, Australia and San Francisco. -- Chris Lewis, R.H. Lathwell & Associates: Elegant Communications Inc. UUCP: {uunet!mnetor, utcsri!utzoo}!lsuc!eci386!clewis Phone: (416)-595-5425
peter@ficc.uu.net (Peter da Silva) (07/19/89)
Assuming all the RFCs are followed, then someone at site A can provide a valid source route which is converted to a bang path. So you have no way of knowing whether a bang path was originally a source route or not. If the intent was that bang paths and source routes were not the same thing, converting one to the other would seem a bad idea. It seems to me that while the letter of the law would not require it, the spirit implies a symmetry between bang paths and source routes. It's impolite to break this symmetry. What do gateways do with bang paths? Convert them to source routes? -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: peter@ficc.uu.net, +1 713 274 5180. | "A char, a short int, and Personal: peter@sugar.hackercorp.com. `-_-' | an int bit-field were walking Quote: Have you hugged your wolf today? 'U` | through the forest..."
edguer@alpha.ces.cwru.edu (Aydin Edguer) (07/20/89)
A while ago I wrote: >> Option three is to say that it should try to deliver mail to site "b" >> using the information available to it, treating pathalias data as >> just another form of MX record. When looking up a name via the >> Domain Name Service (DNS) we accept an MX record to be the equivalent of >> a host record for ALL mail purposes (including source routing). >> What this option asks us to do is treat a pathalias record as the equivalent >> of a host record for mail purposes. In <the previous article> karl@cis.ohio-state.edu (Karl Kleinpaste) writes: [an excellent summary (with one minor mistake) of RFC974 deleted for brevity] > ...I submit that the RFC delivery algorithm requires that active > reroute of the first hop must occur at each relay point along the path > to the destination. Hmm. Yes, the RFC974 algorithm may require a reroute of the first hop at each relay point along the path to the destination. Note, however this is only a reroute of THE FIRST HOP and thus would be the same as passive rerouting, not active (rabid) rerouting. RFC974 does not say to look down the list trying to find known hosts, it merely says to look at the first domain (host) in the path and try to reach it. > I argue that this is patently silly; that a _requirement_ to reroute > actively at each relay is consummately wrong, and hence is to be > ignored. Therefore, I conclude that !-paths must not be source routes > if source routes require such mechanisms. I would agree, if it was a requirement to actively reroute. It is my opinion, however, NOT requiring active rerouting. It is requiring passively rerouting and thus I still conclude that "!" paths are source routes. > Allowing for the following equivalences... > SMTP/DNS UUCP/comp.mail.maps > -------- ------------------- > A records entries in Systems/L.sys files > MX records pathalias data, usually as compiled into /usr/lib/uucp/paths This agrees well with my view of the equivalences but minus one addition I would make. I submit that the pathalias data also contain CNAME RR's (relation records). Aydin Edguer +1 216 368 6123 edguer@alpha.ces.cwru.edu Department of Computer Engineering, Crawford Hall, Case Western Reserve Univ.
karl@cheops.cis.ohio-state.edu (Karl Kleinpaste) (07/20/89)
[Sorry I haven't been able to get you on the phone, Aydin; I've tried 3 times without success...] edguer@alpha.ces.cwru.edu writes: > Hmm. Yes, the RFC974 algorithm may require a reroute of the first > hop at each relay point along the path to the destination. Note, > however this is only a reroute of THE FIRST HOP and thus would be > the same as passive rerouting, not active (rabid) rerouting. > RFC974 does not say to look down the list trying to find known > hosts, it merely says to look at the first domain (host) in the > path and try to reach it. If: I have a connection to system aaaaa; I advertise the connection to aaaaa as _very_ expensive so that it doesn't get used by others as a relay much, in fact, so expensive that my own paths file contains the line aaaaa bbbbb!ccccc!aaaaa!%s I nonetheless expect and accept that the occasional piece of mail bound for aaaaa should still go straight there, because it's known to my Systems file... Then: An incoming piece of mail specifying aaaaa!user will have to be rerouted: bbbbb!ccccc!aaaaa!user because of the requirement, with pathalias as MX, that I reroute the first hop, _before_ a direct attempt. This is morally incorrect. Maintaining the equivalence of Systems = A records and pathalias = MX records (and CNAMEs, agreed), I _must_ reroute that first hop. Making such a reroute into a requirement is Wrong. (Making it optional is my business and no one else's, as the link may be genuinely of high cost.) I have advertised it as expensive for any of a wide variety of reasons; perhaps I just find it politically inconvenient to let people know that I exchange mail with aaaaa. Whatever the reason, I want the connection to be available and used on demand, without most people actually putting it to such use. Say, just for my pals, who are "in the know" about the connection. If someone is truly and honestly bright enough to figure out that the connection from myself to aaaaa is there, and he routes specifically to me for just that reason, I should be allowed to respect it. MXing (first hop rerouting) will prevent that, because it is a requirement. Therefore I still maintain that !-paths are not source routes. --Karl
edguer@alpha.ces.cwru.edu (Aydin Edguer) (07/20/89)
In <Karl's last article> karl@cis.ohio-state.edu (Karl Kleinpaste) writes: >edguer@alpha.ces.cwru.edu writes: >> Hmm. Yes, the RFC974 algorithm may require a reroute of the first >> hop at each relay point along the path to the destination. Note, >> however this is only a reroute of THE FIRST HOP and thus would be >> the same as passive rerouting, not active (rabid) rerouting. >> RFC974 does not say to look down the list trying to find known >> hosts, it merely says to look at the first domain (host) in the >> path and try to reach it. > >If: > I have a connection to system aaaaa; > I advertise the connection to aaaaa as _very_ expensive so > that it doesn't get used by others as a relay much, > in fact, so expensive that my own paths file contains > the line > aaaaa bbbbb!ccccc!aaaaa!%s > I nonetheless expect and accept that the occasional piece of > mail bound for aaaaa should still go straight there, > because it's known to my Systems file... >Then: > An incoming piece of mail specifying > aaaaa!user > will have to be rerouted: > bbbbb!ccccc!aaaaa!user > because of the requirement, with pathalias as MX, that I > reroute the first hop, _before_ a direct attempt. > >This is morally incorrect. Hmm. You have a point, I just don't feel you are addressing it properly. I do not feel that the behavior you described is incorrect (morally or not). I maintain it did exactly what you wanted (or at least what you told it to do). If you wanted mail to go directly to aaaaa rather than bbbbb!ccccc!aaaaa when sent locally, then you should have either: a) Put the system name in brackets in your published map entry to indicate a "terminal link" and that further links are heavily penalized [see pathlias(1)]. Example: <aaaaa> (DEMAND) This will cut down on pass through traffic. OR b) Publish "aaaaa (DEAD)" but put "aaaaa (DEMAND)" in your paths.local file. This will over-ride the higher cost entry when generating your local maps (or any of your friends maps). This will allow you to use it to route to other sites also. OR c) Put "<aaaaa> (DEMAND)" only in your paths.local file and do not list the connection in your published map entry or list it as (DEAD). This will prevent anyone else (who does not know about it) from using the link, but will permit you to use it for direct mail, and help prevent you from generating paths though it. I would hold that resolving hosts in the L.sys file first and then trying to lookup unknown hosts in the pathalias database file (while not preferred) is OK. All you are doing is "fixing" a problem you created yourself (by not making your local map data better). >Making such a reroute into a requirement is Wrong. >(Making it optional is my business and no one else's, as the >link may be genuinely of high cost.) The requirement is only that your local map entries be correct. Thus it is entirely optional and within your control. If someone really WANTS the behavior you have implied is morally right, they CAN do it. If they do not want it, they can avoid it. >Whatever the reason, I want the connection to be available and >used on demand, without most people actually putting it to such use. >Say, just for my pals, who are "in the know" about the connection. If your local map information is correct then the connection is available on demand. The point is that MX records in SMTP land could cause the same problems. What if I wanted to send to mxed.host.domain directly? I can't within a mailer. The rules don't let me and the program won't let me (yes, I know I can telnet directly to the port. I can also directly put a piece of mail in the UUCP mail queue). But I could make a local change to the Domain Name Server (see RFC974)! I continue to see the parallels between "!" paths and source-routes as being very high. But enough beating a dead horse... To be honest, as with all analogies, pathalias records are only like MX records in some ways. One reason why I cannot say that pathalias records are MX records is that (as Karl has pointed out) they are never _specifically_ mentioned in the RFCs we have been discussing. I can only claim that they logically should be included (thanks to RFC976). The second reason why I cannot say that pathalias records are MX records is that in at least one major mailer (IDA-sendmail), MX records and pathalias paths are used in two different parts of the mailer. MX records are used during the delivery phase and do not affect the address. Pathalias records are used during the name resolution phase and do affect the address. None of the RFCs however contain anything to support active rerouting, (i.e. looking beyond the first hop in a chain), and I will continue to call active (rabid) rerouters, impolite, if not broken. Aydin Edguer +1 216 368 6123 edguer@alpha.ces.cwru.edu Department of Computer Engineering, Crawford Hall, Case Western Reserve Univ.
ambar@bloom-beacon.mit.edu (Jean Marie Diaz) (07/29/89)
From: peter@ficc.uu.net (Peter da Silva)
Date: 14 Jul 89 21:22:44 GMT
In article <KARL.89Jul13215059@dinosaur.cis.ohio-state.edu>,
karl@dinosaur.cis.ohio-state.edu (Karl Kleinpaste) writes about two rabid
rerouters routing through each other.
I wish I still had the message, but it was some time ago... you'll have to
take my word for it. I seem to recall that one of the participants was at
athena.mit.edu, and I don't recall where the other was, but it was another
university.
If one of the participants was at athena.mit.edu, then you had a
different problem. athena.mit.edu does not reroute, whether actively or
passively; it does not use pathalias, smail, or homegrown hacks of its
own. In fact, last time I talked to Ron Hoffman, who is
postmaster@athena.mit.edu, it wasn't even running an MX-speaking
sendmail.
bloom-beacon.mit.edu, which is the news server for MIT Project Athena,
DOES passively reroute (given an address of the form user@host.uucp, it
will look up host.uucp in the maps and route it appropriately), but it
is not, and never has been, an active rerouter.
AMBAR
ambar@bloom-beacon.mit.edu {mit-eddie,uunet}!bloom-beacon!ambar