jc@minya.UUCP (John Chambers) (11/24/88)
For several days, my main newsfeed has been disabled, and due to rerouting by other machines, I have been unable to send messages along paths that should have worked. I consider this an object lesson in why rerouting is not a good idea in general. Note that I'm not objecting to routing, just rerouting. That is, if I submit some mail to foo@bar.dom.ain, I expect that mailers will figure out a route for me. But if I send mail to x.uucp!y.bitnet!bar!foo, I prefer that the mailers deliver it along exactly that route, or bounce it back to me. Oh, yes, my example. For several days now, all calls to my main newsfeed (adelie) have failed with the following in the uucp log file: | mail adelie (11/23-4:36:16,6064,0) SUCCEEDED (call to adelie ) | mail adelie (11/23-4:36:21,6064,0) HANDSHAKE FAILED (REMOTE HAS A LCK FILE FOR ME) | mail adelie (11/23-6:36:09,6111,0) SUCCEEDED (call to adelie ) | mail adelie (11/23-6:36:16,6111,0) HANDSHAKE FAILED (REMOTE HAS A LCK FILE FOR ME) | mail adelie (11/23-7:39:14,6136,0) SUCCEEDED (call to adelie ) | mail adelie (11/23-7:39:19,6136,0) HANDSHAKE FAILED (REMOTE HAS A LCK FILE FOR ME) It appears that uucico aborted without freeing the lockfile, and adelie doesn't have one of the recent (hdb) uucps that delete the lockfile if its creating process has died. So until the administrator cleans up, or uucp's garbage collector gets to it, the minya!adelie link is dead. I'd like to send mail to the administrator to tell him about it. Obviously, I can't send mail to adelie!postmaster. I do have several other neighbors, and the uucp maps show several alternative paths. I've tried sending mail along several of them, but you might guess what happens. Right. Each path includes a "smart" mailer that decides it knows a better path--going back here and across minya!adelie. Sigh. Changing the network maps isn't appropriate. The problem will clear up as soon as the lockfile goes away. In fact, I ran my "uunudge" script just before typing "postnews", and while typing this article, a call got through successfully, and the modem's RXD light is lit up solid. So the problem has just now fixed itself. But for several days, the link was down, and alternative paths all failed due to smart re-routing. Dumb mailers would have gotten the job done right. The way I like to think of this is that it's a debugging problem. Routing is fine for "normal" situations. But when things aren't normal, and the software is screwed up somehow, it isn't often correct to depend on the failing software to correct the problem. It's failing, after all. The job of debugging almost always depends on using various backdoors, spies, and out-of-band data paths to poke around in the systems innards. The major use of explicit mail paths is to diagnose and correct mail problems. A few years ago, they worked just fine for uucp. Now they don't. If we can't use them, then we won't generally be able to make email work right. The last few years of widespread smart mailers have provided us with a long list of examples, which my mailer has just extended by one. BTW, I find my "uunudge" script to be a useful debugging tool. What it does is hunt down and remove all the locks and status files blocking a given uucp link, and then starts up a "uucico -r1 -s$1" to force a call. It usually clears up any congestion caused by problems on this end. What would be really handy would be if it were installed at each of my neighbors sites, and I could say something like (uux "x!y!adelie!uunudge 'minya'"). This would have cleared up the problem without my having to contact adelie's administrator (who has better ways to spend his time than babysitting uucp, and anyhow, it's a holiday here in the USA). Unfortunately, with all the various variants of uucp around, I don't know if I could write a general, portable version of this script. Anyone interested in trying to make this a generally-available remote command? -- John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393) [Any errors in the above are due to failures in the logic of the keyboard, not in the fingers that did the typing.]
matt@oddjob.uchicago.edu (Matt Crawford) (11/26/88)
Here's my opinion on uucp path-munching, which may be no better than anyone else's opinion. If pass-through mail has a fully-qualified domain name in the destination bang path, as rutgers!mimsy.umd.edu!elsewhere!eddie.mit.edu!somewhere!user has, then the mailer takes shortcut to the rightmost fully-qualified name. Otherwise it either delivers to the first node on the path, if it is a neighbor, or bounces it if it is not. To the return-path on outgoing mail, I prepend "oddjob!" if there already is a fully-qualified name in the path or "oddjob!oddjob.uchicago.edu!" if there isn't. This seems to work quite well. Matt
lear@NET.BIO.NET (Eliot Lear) (11/26/88)
I don't understand why you didn't contact the site administrator doing the rerouting and tell him that your link was down. -- Eliot Lear [lear@net.bio.net]
vixie@bacchus.pa.dec.com (vixie) (11/26/88)
Another victim of the active rerouters. Sigh. You have my sympathy, but it seems that the decision has been made and since no facts were taken into account originally, I don't see that announcing more facts now is going to change anything. People reroute because they want to, and it seems to give them endless pleasure to see other folks complain about it. There's an ambiguity in your article; I'd like to resolve it: # Note that I'm not objecting to routing, just rerouting. That is, if I # submit some mail to foo@bar.dom.ain, I expect that mailers will figure # out a route for me. But if I send mail to x.uucp!y.bitnet!bar!foo, I # prefer that the mailers deliver it along exactly that route, or bounce # it back to me. I feel that x.uucp is justified in trying to find a route to y.bitnet, but that if y.bitnet (really: the "next hop") is not reachable via routing, the message should be returned. Under no circumstances should a site peek ahead (to "bar", in this example). Well, maybe as matt@oddjob suggests, one could peek ahead to fully qualified domains. But even that I'd tend to argue against (anybody want to? I doubt it...). This is the distinction between "routing" and "rerouting" -- no peeking. One more thing: could you tell me who those neighbors were? The ones that rerouted and sent the fixit request back toward you? I am building a list of rerouters that those who care about such things will be able to mark as "dead" when they build their paths database. The rerouting sites themselves seem largely to want to remain undiscovered, though one of them finally did send me a list of sites. Anyway, anyone who runs or knows of a site who peeks, please send me mail so that my paths database can avoid it. -- Paul Vixie Work: vixie@decwrl.dec.com decwrl!vixie +1 415 853 6600 Play: paul@vixie.sf.ca.us vixie!paul +1 415 864 7013
chip@ateng.ateng.com (Chip Salzenberg) (11/27/88)
According to lear@NET.BIO.NET (Eliot Lear): >I don't understand why [John Chambers] didn't contact the site >administrator doing the rerouting and tell him that [his] link was down. Step back and take a deep breath, Eliot; and think again. If the site in question hadn't been an active rerouter, there would have been no need to contact anyone. And no problem. Active routing loses. Why is this so *hard* for some people to understand?! -- Chip Salzenberg <chip@ateng.com> or <uunet!ateng!chip> A T Engineering Me? Speak for my company? Surely you jest! Beware of programmers carrying screwdrivers.
werner@utastro.UUCP (Werner Uhrig) (11/27/88)
Subject: Why everyone, and especially Postmasters, should have 2 addresses. Summary: was Re: Another example why not to re-route > For several days, my main newsfeed has been disabled, and due to rerouting > by other machines, I have been unable to send messages along paths that > should have worked. I consider this an object lesson in why rerouting > is not a good idea in general. picking up the phone and calling might well be the "obvious" solution ... ...still, John's story of not being able to raise a Postmaster of a site with mail-problems reminds me to, once again, ask that every author of a map-entry include, at least, one alternate and reasonably independent email-address on some other machine, if at all possible (and to check the alternate mailbox(es) for mail !!!) In the research community it is quite common to exchange guest-accounts with "neighboring" site-admins; and while at commercial sites this might not be quite that easy to arrange, it should be easy enough to make an agreement with the admin of a net-neighbor to be named as alternate recipient in the map-entry of your site, and to relay any messages by phone or print-out - if all else fails .... An account on a Public Access or Commercial site, even if long-distance, may well be THE easiest/simplest solution for most ... It's too bad that even those of us with several mail-addresses to offer mostly fail to indicate this in the .signature-file ... -----------------> PREFERED-RETURN-ADDRESS-FOLLOWS <--------------------- (ARPA) werner@rascal.ics.utexas.edu (Internet: 128.83.144.1) (INTERNET) werner%rascal.ics.utexas.edu@cs.utexas.edu (UUCP) ..!utastro!werner or ..!uunet!rascal.ics.utexas.edu!werner -- --------------------> PREFERED-RETURN-ADDRESS-FOLLOWS <--------------------- (ARPA) werner@rascal.ics.utexas.edu (Internet: 128.83.144.1) (INTERNET) werner%rascal.ics.utexas.edu@cs.utexas.edu (UUCP) ..!utastro!werner or ..!uunet!rascal.ics.utexas.edu!werner
rsalz@bbn.com (Rich Salz) (11/28/88)
:For several days, my main newsfeed has been disabled, and due to rerouting :by other machines, I have been unable to send messages along paths that :should have worked. I consider this an object lesson in why rerouting :is not a good idea in general. Unh, err, did you try using your phone without a modem attached? I mean, like, calling? All map entries have contact information, and if you don't keep the maps on-line, you should at least have a name and phone number for everyone listed in your L.sys (Systems) file... /rich $alz -- Please send comp.sources.unix-related mail to rsalz@uunet.uu.net.
romkey@asylum.sf.ca.us (John Romkey) (11/28/88)
I've also been screwed by active rerouting more times than I want to think about. I KNOW what I'm doing when I send a message with a contorted path, and I sometimes send them to test the path, or see what headers I get back. Having an active rerouter in the path makes it impossible for me to test certain routes. There are also still some sites with duplicate site names that aren't registered - for instance, uworld (Unix World) seems to talk to a system called sirius, but it's not the one in the maps. Yes, this is a bad idea, but it's a situation that exists, and I SHOULD still be able to explicitly route a message there. If there's an active rerouter in the path, like my neighbor bionet, I lose. Given these problems, I'm very opposed to active rerouting. If there were a way to force certain messages through, I'd be less opposed to it (perhaps a header field, "X-REROUTE: NO", which the rerouting mailer saw), but there's not. -- - john romkey romkey@asylum.uucp romkey@xx.lcs.mit.edu romkey@asylum.sf.ca.us Find the cost of freedom, buried in the ground Mother Earth will swallow you, lay your body down.
vixie@decwrl.dec.com (Paul A Vixie) (11/29/88)
[Romkey] # Given these problems, I'm very opposed to active rerouting. If there # were a way to force certain messages through, I'd be less opposed to # it (perhaps a header field, "X-REROUTE: NO", which the rerouting # mailer saw), but there's not. John, I agree with everything you say here, and I hope someone among the rerouters will try to answer you. I don't promise not to toast them, but I do promise to be gentler about it than I was last time. One problem with this final suggestion of yours: rerouting _must not_ be the default case. A header that said "X-REROUTE: YES" with the default for all sites being "NO" would be fine. -- Paul Vixie Work: vixie@decwrl.dec.com decwrl!vixie +1 415 853 6600 Play: paul@vixie.sf.ca.us vixie!paul +1 415 864 7013
dtynan@sultra.UUCP (Der Tynan) (11/30/88)
Just a quick thought on the psychology of active-rerouting...
It seems to me, that there are two kinds of rerouters;
a) "That's a pretty poor way to route it, I can do better than that"
b) "Hmm. I don't want to use that link unless I have to"
As for the first case, this is fairly obnoxious, and should be discouraged
at all costs. On the other hand, I can think of fairly valid reasons for
rerouting in the second case. For example, a site connects to UUNET at
300 baud (yeuch!). It also connects to a big machine on the Internet by
local call. In the maps, the site would penalize the UUNET connection.
All mail to UUNET would be through the big neighbour. However, if someone
wants to cost this particular site a lot of money, they could hand-route a
whole pile of large mail directly to UUNET. The 'active' rerouter in this
case, would simply insert an extra component in the bang-path, which
redirected the mail to the Internet site. Comments?
- Der
--
dtynan@zorba.Tynan.COM (Dermot Tynan @ Tynan Computers)
{apple,mips,pyramid,uunet}!Tynan.COM!dtynan
--- If the Law is for the People, then why do we need Lawyers? ---dtynan@sultra.UUCP (Der Tynan) (12/01/88)
In article <VIXIE.88Nov29011054@bacchus.pa.dec.com>, vixie@decwrl.dec.com (Paul A Vixie) writes: > [Romkey] > # Given these problems, I'm very opposed to active rerouting. If there > # were a way to force certain messages through, I'd be less opposed to > # it (perhaps a header field, "X-REROUTE: NO", which the rerouting > # mailer saw), but there's not. > > the default case. A header that said "X-REROUTE: YES" with the default > > Paul Vixie I suggested in the past (and yes, I suggesting it again), that instead of a special purpose header, we use something like: X-OPTIONS: REROUTE. This way, other options could be added without having to change the basic RFC822. Speaking of which, I don't think that the X- should be in front, because if you put that there, people will ignore it. If, on the other hand, you put it as part of '822, then everyone has to sit up and take notice. I mean, the basic idea behind X-ANYTHING, is that the mailer software will ignore it. That's really not what we want. Another example, someone asked me recently, to mail them a copy of a program (>33K in length). Guess what. 'ames' bounced it back to me, complete with a little note about a bad path. It would be great if there was another option something like; OPTIONS: NOBOUNCE which meant that the bouncing site just returned the header. Comments? - Der -- dtynan@zorba.Tynan.COM (Dermot Tynan @ Tynan Computers) {apple,mips,pyramid,uunet}!Tynan.COM!dtynan --- If the Law is for the People, then why do we need Lawyers? ---
chip@ateng.ateng.com (Chip Salzenberg) (12/02/88)
According to dtynan@sultra.UUCP (Der Tynan): >It seems to me, that there are two kinds of rerouters; > a) "That's a pretty poor way to route it, I can do better than that" > b) "Hmm. I don't want to use that link unless I have to" These already have names: a) Active routing b) Passive routing >As for the first case, this is fairly obnoxious, and should be discouraged >at all costs. On the other hand, I can think of fairly valid reasons for >rerouting in the second case. Quite. -- Chip Salzenberg <chip@ateng.com> or <uunet!ateng!chip> A T Engineering Me? Speak for my company? Surely you jest! Beware of programmers carrying screwdrivers.
vixie@decwrl.dec.com (Paul A Vixie) (12/02/88)
[Tynan] # b) "Hmm. I don't want to use that link unless I have to" Simplest solution to this is: don't advertise the path in your map entry. # However, if someone wants to cost this particular site a lot of money, they # could hand-route a whole pile of large mail directly to UUNET. If they knew about the unadvertised link, and if they had dark intentions. If and when this ever happened, I think an active response is better than the passive response of rerouting. Active in what way? Yelling, screaming, complaining, pulling links, public flamage, etc. This assumes that sending the person private e-mail doesn't work. It gets pretty far fetched, but even this contrived example doesn't make a case for limited rerouting. I rerouted "decwrl!ucbvax!foobar.berkeley.edu!user" into the more direct "user@foobar.berkeley.edu" because ucbvax is a Vax 750 and it can route packets more easily than it can route mail messages. I didn't want to advertise decwrl as a domain server to the .berkeley.edu domain, but in fact _any_ directly connected Internet host could be considered such since Berkeley allows external IP traffic to all machines on its internal net. _That_ is an example of limited rerouting to address a specific need. It wasn't a single individual, noone had any dark intentions, and noone came up with a way to tell the world that "decwrl!foobar.berkeley.edu!user" would work without bogusly registering "decwrl .berkeley.edu". -- Paul Vixie Work: vixie@decwrl.dec.com decwrl!vixie +1 415 853 6600 Play: paul@vixie.sf.ca.us vixie!paul +1 415 864 7013
john@jetson.UPMA.MD.US (John Owens) (12/02/88)
In article <2692@sultra.UUCP>, dtynan@sultra.UUCP (Der Tynan) writes: > Just a quick thought on the psychology of active-rerouting... > It seems to me, that there are two kinds of rerouters; > a) "That's a pretty poor way to route it, I can do better than that" > b) "Hmm. I don't want to use that link unless I have to" Ah, but only the first is what we've been calling active rerouting, while the second, which deals only with the *next* link in the path, is what we've been calling "routing", and which most of us have agreed is just fine. To use the terms Paul (I think) introduced recently: the first involves "peeking"; the second doesn't, so it's ok (and isn't "active rerouting"). So, I certainly agree with your conclusion that the first is obnoxious and the second quite reasonable.... -- John Owens john@jetson.UPMA.MD.US uunet!jetson!john +1 301 249 6000 john%jetson.uucp@uunet.uu.net
roy@phri.UUCP (Roy Smith) (12/03/88)
dtynan@sultra.UUCP (Der Tynan) writes: > It would be great if there was another option something like; > OPTIONS: NOBOUNCE > which meant that the bouncing site just returned the header. Absolutely a great idea. A few years ago somebody around here decided to get rn running. I told him to get the source on tape but the turkey decided to go ahead and have somebody halfway across the country email it to him. Well, the other turkey (the guy who mailed it) got our turkey's name wrong so we, of course, bounced the whole friggin' 800 kbytes of it. To make life worse, when it got to the other end, the site that sent it was down for a a few days so the return mail eventually timed out in somebody's uucp queue and came back to us again. Bad enough we paid to mail 800 kbytes in the first place, we also paid to bounce it around the country another two times! I don't remember the details of the path, but it included allegra!ihnp4. I'm sure allegra!mp remembers this one. I think he said that when he did the uucp stats for that month, lowly little phri showed up at the top of the list for non-AT&T sites. Had the various mailers involved only bounce the headers instead of the whole files, a lot of money would have been saved all around. -- Roy Smith, System Administrator Public Health Research Institute {allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net "The connector is the network"
dtynan@sultra.UUCP (Der Tynan) (12/06/88)
Here's some more food for thought. I received a message from a site over the
weekend, which had the following path:
From: uunet!pyramid!mips!original-site!root
What's so interesting about this? My machine talks directly to pyramid.
However, pyramid sent the mail to uunet instead. OK, that's not too fatal,
a common mistake. But Wait! There's More! My machine ALSO talks directly
to mips! The only thing I can surmise is that the original-site hand-routed
the message. However, I don't think it would have been a henious sin on the
part of mips (or pyramid) to dump the rest of the path, and drop the mail onto
my site directly. Comments?
- Der
--
dtynan@zorba.Tynan.COM (Dermot Tynan @ Tynan Computers)
{apple,mips,pyramid,uunet}!Tynan.COM!dtynan
--- If the Law is for the People, then why do we need Lawyers? ---duncan@comp.vuw.ac.nz (Duncan McEwan) (12/08/88)
In article <2703@sultra.UUCP> dtynan@sultra.UUCP (Der Tynan) writes: >However, I don't think it would have been a henious sin on the >part of mips (or pyramid) to dump the rest of the path, and drop the mail onto >my site directly. Comments? I suspect a response from this part of the world will not make it out in time to save Paul Vixie having to repeat the same argument yet again, which will be a pity, 'cause he seems to be getting a fair amount of flaming for saying sensible things! Anyway, once again ... if mail is manually routed to mips!pyramid!uunet!sultra!dtynan neither mips nor pyramid has any right to assume that the final "sultra" is the one registered in the maps, or the one that they talk directly to -- they have to follow the given path to ensure the mail gets to the right site. Duncan
honey@mailrus.cc.umich.edu (peter honeyman) (12/09/88)
the "don't reroute" crowd proposes that the standard interpretation of bang paths be "relative addressing, source routes." this has a certain simplicity and predictability that makes it attractive, not to mention the fact that uucp has worked this way from its inception. peter
w-colinp@microsoft.UUCP (Colin Plumb) (12/09/88)
How does this re-routing rule sound: If you see a domain-style name (even .uucp) in the bang path, it's okay to route to that site. Sites without domains are not necessarily distinct, and should not be routed to, even if they appear before the domain-style name. If this becomes too long, you could accept the null domain, "." as evidence of licence to re-route. If you wanted whatever routing anyone could give you this would add 1 (or 5 if .uucp) characters to each site name - say 4 (20) characters total. Smaller than an Options: field. I am as yet ignorant of the Tao of Mail Routing, but it looks good to me... -- -Colin (uunet!microsof!w-colinp)
zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (12/10/88)
>> It would be great if there was another option something like; >> OPTIONS: NOBOUNCE >> which meant that the bouncing site just returned the header. > > Absolutely a great idea. A few years ago somebody around here In the mean time, you can just bounce the first 100 lines (or whatever) of the message. Small messages are complete, large ones are clipped. -- Jon Zeeff zeeff@b-tech.ann-arbor.mi.us Support ISO 8859/1 zeeff%b-tech.uucp@umix.cc.umich.edu Ann Arbor, MI umix!b-tech!zeeff
lyndon@auvax.uucp (Lyndon Nerenberg) (12/13/88)
In article <38@microsoft.UUCP> w-colinp@microsoft.UUCP (Colin Plumb) writes: >How does this re-routing rule sound: > >If you see a domain-style name (even .uucp) in the bang path, it's okay >to route to that site. Sites without domains are not necessarily distinct, >and should not be routed to, even if they appear before the domain-style name. The purpose of a domain name is to *guarantee* a globally unique name for some entity. This is done through enforced coordination of the domain namespace. The .uucp "domain" has no central organization, therefore you cannot guarantee the existence of one, and ONLY one, foo.uucp. Preaching aside :-), there is a practical reason for this as well. Various pieces of usenet software (Bnews, rn, smail 2.X come to mind) provide a default "domain" of .uucp. Odds are quite good that when a new site comes on the net, the system administrator will not understand the implications of his site name duplicating that of another site. Until he finds out, your scheme guarantees that one of the two sites won't be getting its mail. You CANNOT reliably force a route to anything.uucp inside of a bang path. [ I speak from experience. We have a site here named "aurora" that duplicates a registered site at NASA. Until AU gets a registered domain, I have to carve up the mailers and news software to lie about traffic originating from *our* aurora. ] -- Lyndon Nerenberg -- Computing Services -- Athabasca University {alberta,attvcr,ncc}!auvax!lyndon
batie@agora.UUCP (Alan Batie) (12/13/88)
In article <38@microsoft.UUCP> w-colinp@microsoft.UUCP (Colin Plumb) writes: >How does this re-routing rule sound: > >If you see a domain-style name (even .uucp) in the bang path, it's okay >to route to that site. Sites without domains are not necessarily distinct, >and should not be routed to, even if they appear before the domain-style name. This is, in fact, an option to smail, but I've added a twist that others may find useful: I doubt the powers that be want internal mail to get sent to Competitor.Com because some butterfingers mistyped an address, or was lazy and didn't put a domain on it. Therefore, I use the "JUSTDOMAIN" option on smail 2.5, so that only a domain form will get routed. Since "user@site" is considered a domain form, if the route routine is called, I check to see if there is a dot in the domain part, and if not, "MYDOM" is tacked on to it. Thus, to get outside routing, you *have* to use "user@site.uucp" or "user@site.domain". Mail passing through should have a bang path already and not be affected, unless a bad path is given, which would be routed and converted into an internal form. This is not desirable, but I don't see an alternative. I can't merge the internal sites into the paths file without domains as there are name conflicts that have to be hidden under a domain. This is on a system without sendmail; I'm having enough problems with sendmail on the other half of the gateway... -- Alan Batie +1 503 640-4013 batie@agora.hf.intel.com "He was born on third base... tektronix!tessi!agora!batie and thought he hit a triple"
jep@fantasci.UUCP (Joseph E Poplawski) (12/16/88)
In article <2696@sultra.UUCP> dtynan@sultra.UUCP (Der Tynan) writes: >In article <VIXIE.88Nov29011054@bacchus.pa.dec.com>, vixie@decwrl.dec.com (Paul A Vixie) writes: >> >> the default case. A header that said "X-REROUTE: YES" with the default > >I suggested in the past (and yes, I suggesting it again), that instead of a >special purpose header, we use something like: X-OPTIONS: REROUTE. This >way, other options could be added without having to change the basic RFC822. .. .. >path. It would be great if there was another option something like; > OPTIONS: NOBOUNCE I think the X-REROUTE: or OPTIONS: field should have reroute defaulted as YES so that novices who don't know what they are doing can hope the rerouters and smart mailers can figure out the best way to get it there, while the experts and other proficient mail users can change it if they desire. -Jo ------------------------------------------------------------------------------- | Joseph E Poplawski (Jo) US Mail: 1621 Jackson Street | | Cinnaminson NJ 08077 | | UUCP:..!rutgers!rochester!moscom!telesci!fantasci!jep | | ..!princeton!telesci!fantasci!jep | | ..!pyrnj!telesci!fantasci!jep Phone: +1 609 786-8099 home | -------------------------------------------------------------------------------