sl@van-bc.UUCP (Stuart Lynne) (02/13/88)
In the last week I've noticed a couple of messages sneeking through van-bc destined to: cdl!van-bc!uupc I havn't checked yet, but I guess that if you arn't doing re-routing of absolute addresses, smail doesn't even look if the site it's running on is further on down in the chain. What appears to be happening is that site cdl has been thought to talk to a site somewhere off in the blue yonder (I don't think it actually does though). When the message arrived there, the mail system thoughtfully rerouted via ubc-vision, but keeping the cdl!van-bc!skl so: ...!reed!nscpdc!cdl!van-bc!uupc becomes (approx): ...!reed!nscpdc pyramid!utai!ubc-vision!cdl!van-bc!uupc Now cdl does talk to ubc-vision, but on a very low priority compared to van-bc, so ubc-vision changed it to: van-bc!cdl!van-bc!uupc Which got delivered here, where smail kindly forwarded it to cdl. They of course sent it back for delivery. > From ubc-vision!utai!tektronix!pyramid!cae780.TEK.COM!hplabs!hp-sdd!ucsd!ucrmath!soft21!root Sat Feb 13 00:11:09 1988 remote from van-bc > Received: by van-bc.uucp (smail2.3) > id AA00375; 13 Feb 88 00:11:09 PST (Sat) > Received: by ubc-vision.UUCP id AA01987; Fri, 12 Feb 88 13:52:19 pst > Received: from pyramid by ai.toronto.edu via X.25 with UUCP id AA01742; Fri, 12 Feb 88 11:23:24 EST > Received: by pyramid.UUCP (5.51/OSx4.0b-870424) > id AA15480; Fri, 12 Feb 88 07:45:05 PST > Received: by nsc.NSC.COM; Fri Feb 12 07:17:36 1988 > Received: by reed.UUCP (5.51/5.17) > id AA24588; Thu, 11 Feb 88 07:44:37 PST > Received: by tektronix.TEK.COM (5.51/6.24) > id AA01945; Thu, 11 Feb 88 06:48:23 PST > Received: by cae780.TEK.COM (4.12/6.23) > id AA16853; Thu, 11 Feb 88 06:39:16 pst > Received: from hp-sdd.HP.COM (hp-sdd) by hplabs.HP.COM with SMTP ; Thu, 11 Feb 88 03:58:01 PST > Received: by hp-sdd.HP.COM; Thu, 11 Feb 88 03:58:48 PST > Return-Path: <hp-sdd!ucsd!ucrmath!soft21!root> > Received: by ucsd.edu (5.58/UCSD-1.0) > id AA02474 for hplabs!cae780!tektronix!reed!nscpdc!cdl!van-bc!uupc; Wed, 10 Feb 88 12:05:57 PST > Received: by ucrmath.UUCP (5.51/5.17) > id AA00453; Wed, 10 Feb 88 10:31:42 PST > Received: by soft21.UUCP (smail2.5) > id AA00458; 10 Feb 88 08:54:39 PST (Wed) > To: ucrmath!ucsd!hp-sdd!hplabs!cae780!tektronix!reed!nscpdc!cdl!van-bc!uupc > Subject: New version? > Message-Id: <8802100854.AA00458@soft21.UUCP> > Date: 10 Feb 88 08:54:39 PST (Wed) > From: ubc-vision!tektronix!cae780.TEK.COM!hplabs!hp-sdd!ucsd!ucrmath!soft21!root (John Antypas) > Several points come to mind: Shouldn't smart mailers at least try and look for themselves in the absolute address, even if they don't want to always do re-routing? As a site fairly close to the bottom of the tree, (almost all of the sites I talk to are leaves), should I do re-routing on the grounds that I probably no more about routing than any of them do? -- {ihnp4!alberta!ubc-vision,uunet}!van-bc!Stuart.Lynne Vancouver,BC,604-937-7532
phil@amdcad.AMD.COM (Phil Ngai) (02/16/88)
In article <1671@van-bc.UUCP> sl@van-bc.UUCP (Stuart Lynne) writes: | As a site fairly close to the bottom of the tree, (almost all of the | sites I talk to are leaves), should I do re-routing on the grounds | that I probably no more about routing than any of them do? I think bang style addresses should never be re-routed. What if you are wrong? Then I'm screwed. If I am wrong, I'll get a bounce and use the right address. But if you are wrong, there's nothing I can do. -- I speak for myself, not the company. Phil Ngai, {ucbvax,decwrl,allegra}!amdcad!phil or phil@amd.com
kls@ditka.UUCP (Karl Swartz) (02/17/88)
In article <1671@van-bc.UUCP> sl@van-bc.UUCP (Stuart Lynne) writes: > >In the last week I've noticed a couple of messages sneeking through van-bc >destined to: > > cdl!van-bc!uupc > (guesses about causes deleted) > Shouldn't smart mailers at least try and look for themselves in the > absolute address, even if they don't want to always do re-routing? The problem with doing this is untangling cases of multiple names. For example, if I send mail thru formtek (the main machine at my office) to formtek!earth!user it should go to our subsidiary in Vancouver (your neighbor) who's main machine is named earth. But if I send something to formtek!idis!pitt!allegra!earth!user it should go to an AT&T machine somewhere on the east coast named earth. Ok, it shouldn't be ambiguous because our earth's name isn't known in the real world, and I know that allegra doesn't talk to it, but the real world is imperfect. In the one hop case, such as yours, maybe this is a reasonable optimization, but I wouldn't be surprised if even that managed to screw up somebody, somewhere, somehow. -- Karl Swartz |UUCP decvax!formtek!ditka!kls 1-412/937-4930 office | {floyd,pitt,psuvax1}!idis!formtek!ditka!kls |BIX kswartz "I never let my schooling get in the way of my education." (Twain)
karl@ddsw1.UUCP (Karl Denninger) (02/18/88)
In article <20400@amdcad.AMD.COM> phil@amdcad.UUCP (Phil Ngai) writes: >In article <1671@van-bc.UUCP> sl@van-bc.UUCP (Stuart Lynne) writes: >| As a site fairly close to the bottom of the tree, (almost all of the >| sites I talk to are leaves), should I do re-routing on the grounds >| that I probably no more about routing than any of them do? >I think bang style addresses should never be re-routed. What if you >are wrong? Then I'm screwed. If I am wrong, I'll get a bounce and use >the right address. But if you are wrong, there's nothing I can do. I agree... especially if you regularly communicate with a few people. These people *know* which paths work; they use them all the time! How many of the 10k or so paths in your paths file do you actually *use*; that is, how do you know they are good? Smail already provides for this in that you can specify that mail should not be re-routed if received with a 'bang' path unless the attempt to pass the mail to the next site fails. On our system, if your 'banged' mail gets here, it is delivered as you specify *if we can comply with your request*. If you ask for a next 'hop' to someone we don't talk to then it gets re-routed automatically, providing we can find a way to do so (if not then it 'bounces'). This gives you the best of both worlds. ----- Karl Denninger | Data: +1 312 566-8912 Macro Computer Solutions, Inc. | Voice: +1 312 566-8910 ...ihnp4!ddsw1!karl | "Quality solutions for work or play"