phil@amdcad.UUCP (01/26/87)
I forgot one more reason autorouting uucp ! format paths is bad:
Such addresses are path relative. That is, decwrl!amdcad!neptune is
different from ihnp4!neptune. ATT has a machine named neptune, AMD has
a (different) machine named neptune, not advertised to the world. If
some "smart" machine decided to do us a "favor" and change
decwrl!amdcad!neptune to ihnp4!neptune, the mail would end up going to
the wrong place.
I realize having non-unique uucp node names is a problem and
everything should be domainized but there ARE duplicates and
autorouting uucp ! format addresses is a good way to mess things up,
with little benefit.
--
Social security is welfare for the elderly.
Phil Ngai +1 408 749 5720
UUCP: {ucbvax,decwrl,hplabs,allegra}!amdcad!phil
ARPA: amdcad!phil@decwrl.dec.comgrr@cbmvax.UUCP (01/26/87)
In article <14481@amdcad.UUCP> phil@amdcad.UUCP (Phil Ngai) writes: > >I forgot one more reason autorouting uucp ! format paths is bad: > >Such addresses are path relative. That is, decwrl!amdcad!neptune is >different from ihnp4!neptune. ATT has a machine named neptune, AMD has >a (different) machine named neptune, not advertised to the world. If >some "smart" machine decided to do us a "favor" and change >decwrl!amdcad!neptune to ihnp4!neptune, the mail would end up going to >the wrong place. > >I realize having non-unique uucp node names is a problem and >everything should be domainized but there ARE duplicates and >autorouting uucp ! format addresses is a good way to mess things up, >with little benefit. True, but this already a fatal problem in the real world. There are unmarked anti-social routers out there that are diverting any external mail to your neptune to the other... These people think that they are doing you/themselves a favor... -- George Robbins - now working for, uucp: {ihnp4|seismo|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@seismo.css.GOV Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
phil@amdcad.UUCP (01/28/87)
In article <1300@cbmvax.cbmvax.cbm.UUCP> (George Robbins) writes: >In article <14481@amdcad.UUCP> phil@amdcad.UUCP (Phil Ngai) writes: >> >>I realize having non-unique uucp node names is a problem and >>everything should be domainized but there ARE duplicates and >>autorouting uucp ! format addresses is a good way to mess things up, >>with little benefit. > >True, but this already a fatal problem in the real world. There are >unmarked anti-social routers out there that are diverting any external >mail to your neptune to the other... You make it sound as though "well, people are doing this (wrong) thing already, so what are you complaining about?" I'm sure that isn't what you meant. -- Paul Slansky: Those who believe that President Reagan had to have known about secret fund diversions to the Contras are overlooking Reagan's hard-won reputation for knowing practically nothing. Phil Ngai +1 408 982 7840 UUCP: {ucbvax,decwrl,hplabs,allegra}!amdcad!phil ARPA: amdcad!phil@decwrl.dec.com
jc@cdx39.UUCP (01/28/87)
> I forgot one more reason autorouting uucp ! format paths is bad: > Such addresses are path relative. That is, decwrl!amdcad!neptune is > different from ihnp4!neptune. > ... > I realize having non-unique uucp node names is a problem and > everything should be domainized ... Actually, while this is a problem for the global email system, it is (from a user's viewpoint) one of the great advantages of uucp mail. Why? Well, because we don't need any kind of central Authority to organize a little uucp exchange. If our company has a cluster of Unix boxes, we can connect them together with null-modem links, give each one a nodename unique within the cluster, and copy files to our hearts' content. This takes maybe 10 minutes to an hour. We don't first have to spend weeks or months getting names and/or network addresses from some distant authority (which all too often means convincing the authority that we need to do what we're doing). Granted, as soon as we make a uucp link out to the external world, and send email across it, there is a problem. But at least we can put off burning that bridge until we come to it. If all we need is a temporary link to copy a few megabytes of files, we can do it and get on with the job without a lot of bureaucratic hassles. Uucp is, after all, used for a lot more than email. Even with intelligent mail routers installed everywhere (which is still not too close to realization), people would still be making little, temporary links and running uucp across it for purposes like downloading binaries and uuxing them. Requiring that users first spend several orders of magnitude more time consulting a name authority is not realistic. -- John M Chambers Phone: 617/364-2000x7304 Email: ...{adelie,bu-cs,harvax,inmet,mcsbos,mit-eddie,mot[bos]}!cdx39!{jc,news,root,usenet,uucp} Smail: Codex Corporation; Mailstop C1-30; 20 Cabot Blvd; Mansfield MA 02048-1193 Clever-Saying: If we can't fix it, it ain't broke.
grr@cbmvax.UUCP (01/29/87)
In article <14511@amdcad.UUCP> phil@amdcad.UUCP (Phil Ngai) writes: >> >>True, but this already a fatal problem in the real world. There are >>unmarked anti-social routers out there that are diverting any external >>mail to your neptune to the other... > >You make it sound as though "well, people are doing this (wrong) thing >already, so what are you complaining about?" > >I'm sure that isn't what you meant. > > Phil Ngai +1 408 982 7840 Silly me - I was just trying to say that there is nothing theoretical or future tense about the duplicate name / auto re-routing problem. One can either start a campaign to make these rerouters correct the errors of their ways, or one can correct the duplicate name situation. Which solution do you have more control over? -- George Robbins - now working for, uucp: {ihnp4|seismo|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@seismo.css.GOV Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
jbuck@epimass.UUCP (01/29/87)
In article <14481@amdcad.UUCP> phil@amdcad.UUCP (Phil Ngai) writes: >>>I realize having non-unique uucp node names is a problem and >>>everything should be domainized but there ARE duplicates and >>>autorouting uucp ! format addresses is a good way to mess things up, >>>with little benefit. In article <1300@cbmvax.cbmvax.cbm.UUCP> (George Robbins) writes: >>True, but this already a fatal problem in the real world. There are >>unmarked anti-social routers out there that are diverting any external >>mail to your neptune to the other... In article <14511@amdcad.UUCP> phil@amdcad.UUCP (Phil Ngai) writes: >You make it sound as though "well, people are doing this (wrong) thing >already, so what are you complaining about?" This started when Phil mentioned that both AMD and AT&T have a machine named neptune. Actually, there's only a name conflict if you call both machines neptune. AMD's machine is neptune.AMD.COM (now that Phil has installed smail), and AT&T's machine is neptune.foo.bar.bletch.ATT.COM. People with vanilla mailers can mail to neptune.AMD.COM by just mailing to ...!amdcad!neptune.AMD.COM!user. Voila, the unique UUCP name problem is gone, because of the magic of smail. On the other hand, people whose mailers reroute my mail through ihnp4 when I've specified a perfectly valid path that avoids it should be shot. Unlike Phil, though, I'm perfectly happy if a router converts an invalid path into a valid one and makes my mail reach its destination. -- - Joe Buck {hplabs,ihnp4,sun,ames}!oliveb!epimass!jbuck HASA (A,S) Entropic Processing, Inc., Cupertino, California
woods@hao.UUCP (01/30/87)
In article <849@epimass.UUCP> jbuck@epimass.UUCP (Joe Buck) writes: >This started when Phil mentioned that both AMD and AT&T have a >machine named neptune. Actually, there's only a name conflict if you >call both machines neptune. AMD's machine is neptune.AMD.COM (now >that Phil has installed smail), and AT&T's machine is >neptune.foo.bar.bletch.ATT.COM. The "magic of smail" also creates some other problems. For example, I just found out the hard way that there are two machines named "solar" (I gather from some comments in some map entries that this has been known for some time, but I just found out today and it bit me BADLY). One is at Stanford, and we have a direct uucp connection to them. Unbeknownst to me, there is also a "solar" at AT&T that has a direct connection to cbosgd, the gateway into some of those foo.bar.bletch.ATT.COM domains you mention. So, when I changed our L.sys file to increase the frequency of our connection to "solar" (due to user demand here), and changed my local map entry accordingly, and regenerated my pathalias output/smail input database, I thought it worked, because people who mailed from here to user@solar.uucp got their message sent over the direct link as desired, as opposed to previously when it went over some convoluted path through seismo (which, it now occurs to me, may very well have ended at the wrong "solar" anyway). Unfortunately, my messages to mark@cbpavo.MIS.OH.ATT.COM got routed to Stanford by smail, and bounced back. In order to fix the problem, I have to edit BY HAND the map files and excise references to the AT&T "solar". Yes, I can still mail to the AT&T one if I send to solar.ATT.COM, so you are right that smail removes ambiguity in DESTINATION host names. However, ambiguous INTERMEDIATE host names becomes a serious problem, because a user can send the mail via the wrong intermediate host and lose the message, despite the fact that a "path" to the destination supposedly exists! And this happens even when the destination host is specified with a domain address! Therefore, I think it is more important than ever to eliminate ALL duplicate host names from uucp, or at least from the map postings, or we're going to see lots of incorrectly routed mail as smail and other domain routers like it become more and more common. As for me, I have no choice but to manually edit the map postings every month, or do something else equally kludgy like running pathalias with the cbosgd!solar link declared DEAD (and then there's no guarantee that mail to other places within AT&T might not get routed to Stanford anyway because of OTHER links that AT&T's solar might have). This is a headache for me, but nearly as serious as the problem that occurs when such duplicate names exist but are not KNOWN about. --Greg -- UUCP: {hplabs, seismo, nbires, noao}!hao!woods CSNET: woods@ncar.csnet ARPA: woods%ncar@CSNET-RELAY.ARPA INTERNET: woods@hao.ucar.edu
phil@amdcad.UUCP (01/30/87)
If you ask me, there are going to be more duplicate uucp names in the
future, not less. I'll leave it to the reader to guess why.
Peter Honeyman was right.
--
Paul Slansky: Those who believe that President Reagan had to have known about
secret fund diversions to the Contras are overlooking Reagan's hard-won
reputation for knowing practically nothing.
Phil Ngai +1 408 982 7840
UUCP: {ucbvax,decwrl,hplabs,allegra}!amdcad!phil
ARPA: amdcad!phil@decwrl.dec.comhenry@utzoo.UUCP (Henry Spencer) (01/31/87)
> Granted, as soon as we make a uucp link out to the external world, > and send email across it, there is a problem. But at least we can > put off burning that bridge until we come to it... Actually, the right approach to that one is to do a bit of work on things like mailers so that your internal cluster looks like one machine to the outside world. It is a crying shame that more sites don't do this. -- Legalize Henry Spencer @ U of Toronto Zoology freedom! {allegra,ihnp4,decvax,pyramid}!utzoo!henry
chris@minnie.UUCP (Chris Grevstad) (02/01/87)
jc@cdx39.UUCP (John Chambers) says: >> ... >> I realize having non-unique uucp node names is a problem and >> everything should be domainized ... > ... > ... >Uucp is, after all, used for a lot more than email. Even with >intelligent mail routers installed everywhere (which is still >not too close to realization), people would still be making >little, temporary links and running uucp across it for purposes >like downloading binaries and uuxing them. Requiring that users >first spend several orders of magnitude more time consulting a >name authority is not realistic. > Of course it is used for more than email. You are making a useless point since the issue of the actual workings of UUCP is not germane to this dis- cussion. UUCP knows nothing about domains and addresses and probably never will. All it knows about is paths. As far as mail is concerned, UUCP is just a transport protocol, ignorant of the application layer's needs and intentions. Mail is the entity that needs to know about domains and addresses (if you are a domainist and if you aren't then this entire discussion is of no interest). -- Chris Grevstad {sdcsvax,hplabs}!sdcrdcf!psivax!nrcvax!chris ihnp4!nrcvax!chris Don't let the sunshine spoil your rain, Just stand up and complain.
jc@cdx39.UUCP (02/03/87)
> >Uucp is, after all, used for a lot more than email. Even with > >intelligent mail routers installed everywhere (which is still > >not too close to realization), people would still be making > >little, temporary links and running uucp across it for purposes > >like downloading binaries and uuxing them. Requiring that users > >first spend several orders of magnitude more time consulting a > >name authority is not realistic. > > Of course it is used for more than email. You are making a useless point > since the issue of the actual workings of UUCP is not germane to this dis- > cussion. UUCP knows nothing about domains and addresses and probably never > will. All it knows about is paths. As far as mail is concerned, UUCP is just > a transport protocol, ignorant of the application layer's needs and intentions. > Well, yes and no. Note, first, that I didn't say anything about the actual workings of UUCP. I was talking about people using it to do a job. And when they set up little local uucp clusters, they very often run mail across it. Why? Well, mail is often more convenient than running uucp directly. Many users know how to use mail better than uucp, and they use what they know. This may not be the "best" from a guru's point of view, but they're not gurus. And as long as they're only passing source files across the links, mail works just fine. Granted, uuto would be better, but people tend to use the tools they know. Every Unix system I've ever seen has a library program called 'mail', and they all work the same. It's a nice little program, for what little it does. I can teach a novice user all about it in 5 minutes, and they can use it without surprises on a local uucp cluster (which regrettably requires a guru to hook up). It's still going to be a while before domainized mailers are so easy for a non-guru to use. The point I've been trying to make is that there are many good uses for temporary clusters of machines. Those who are developing new mailers can rail all they want against such uses of machines, but users aren't likely to listen. Currently, hooking up a cluster via uucp can be done in time measured in fractions of an hour per node. Consulting a name authority is several orders of magnitude slower, and in many cases would take longer than the lifetime of the cluster. This is quite prohibitive. > Mail is the entity that needs to know about domains and addresses (if you are > a domainist and if you aren't then this entire discussion is of no interest). Actually, even if I weren't, I'd still find it interesting. But I can assure you that most of the other users around here find it supremely boring; they leave newsgroups like comp.mail.headers to weirdos like me. -- John M Chambers Phone: 617/364-2000x7304 Email: ...{adelie,bu-cs,harvax,inmet,mcsbos,mit-eddie,mot[bos]}!cdx39!{jc,news,root,usenet,uucp} Smail: Codex Corporation; Mailstop C1-30; 20 Cabot Blvd; Mansfield MA 02048-1193 Clever-Saying: Uucp me out of here, Scotty; there's no AI on this node!