Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 alpha 4/15/85; site fear.UUCP Path: utzoo!watmath!clyde!cbosgd!ukma!psuvm.bitnet!psuvax1!burdvax!sdcrdcf!sdcsvax!dcdwest!ittatc!decvax!decwrl!pyramid!pesnta!amd!amdcad!cae780!weitek!fear!robert From: robert@fear.UUCP (Robert Plamondon) Newsgroups: net.mail Subject: Re: Mail problem, ihnp4 -> tektronix Message-ID: <313@fear.UUCP> Date: Tue, 17-Dec-85 20:03:39 EST Article-I.D.: fear.313 Posted: Tue Dec 17 20:03:39 1985 Date-Received: Sat, 21-Dec-85 01:11:38 EST References: <17623@styx.UUCP> <3080@sun.uucp> Distribution: net Organization: Weitek Corp. Sunnyvale Ca. Lines: 47 Summary: If it works, don't fix it >> The appended message was sent to me by philabs, indicating a >> problem sending a message to tektronix. I can't tell from the header >> why it was routed to philabs from ihnp4, since it doesn't appear in >> the path. In article <3080@sun.uucp>, chuq@sun.uucp (Chuq Von Rospach) writes: > ihnp4 uses pathalias (or a variant of it) to do routing. > Unfortunately, they seem to be getting more and more confused over > time, with innnacurate or inefficient routes being generated. Every > so often, ihnp4 used to believe that the fastest route to nsc was > ihnp4!cbosgd!nsc even though nsc talked directly to them. Now, from > my mail, it seems to think that ihnp4!cbosgd!sun is the fastest route > to sun, even though sun talks to ihnp4... sigh. The main problem here is a failure on the part of ihnp4's mail administration to appreciate the rule, "If it ain't broke, don't fix it." They set up their mail software to take a perfectly acceptable, efficient mail route, and perform a series of changes on it that made it undeliverable. Why? While I sympathize with ihnp4's mail volume, and the perceived need to optimize the ridiculous return paths generated by news, their implementation is crude and excessive. Besides keeping their pathalias files up to date, I would suggest that sites that like to play with other people's routings adhere to guidelines like this: 1. If the path is less than five hops long, don't optimize it. 2. If the "cost" from pathalias isn't at least twice as good as the original path, don't optimize it. This way, users who know what they're doing can avoid being screwed over by so-called "smart" mailers. On the WEITEK machines, we don't have the volume problems that ihnp4 has, so we just run uumail as posted on the net. The beauty of uumail is that it only looks for the optimum path to the first hop in the address, so when presented with a complete path, it does no optimization at all. -- Robert Plamondon UUCP: {turtlevax, resonex, cae780}!weitek!robert FidoNet: 10/624 robert plamondon Relay-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site sdcrdcf.UUCP Posting-Version: version B 2.10.3 alpha 4/15/85; site fear.UUCP Path: sdcrdcf!sdcsvax!dcdwest!ittatc!decvax!decwrl!pyramid!pesnta!amd!amdcad!cae780!weitek!fear!robert From: robert@fear.UUCP (Robert Plamondon) Newsgroups: net.mail Subject: Re: Mail problem, ihnp4 -> tektronix Message-ID: <313@fear.UUCP> Date: 18 Dec 85 01:03:39 GMT Date-Received: 19 Dec 85 10:10:38 GMT References: <17623@styx.UUCP> <3080@sun.uucp> Distribution: net Organization: Weitek Corp. Sunnyvale Ca. Lines: 47 Summary: If it works, don't fix it >> The appended message was sent to me by philabs, indicating a >> problem sending a message to tektronix. I can't tell from the header >> why it was routed to philabs from ihnp4, since it doesn't appear in >> the path. In article <3080@sun.uucp>, chuq@sun.uucp (Chuq Von Rospach) writes: > ihnp4 uses pathalias (or a variant of it) to do routing. > Unfortunately, they seem to be getting more and more confused over > time, with innnacurate or inefficient routes being generated. Every > so often, ihnp4 used to believe that the fastest route to nsc was > ihnp4!cbosgd!nsc even though nsc talked directly to them. Now, from > my mail, it seems to think that ihnp4!cbosgd!sun is the fastest route > to sun, even though sun talks to ihnp4... sigh. The main problem here is a failure on the part of ihnp4's mail administration to appreciate the rule, "If it ain't broke, don't fix it." They set up their mail software to take a perfectly acceptable, efficient mail route, and perform a series of changes on it that made it undeliverable. Why? While I sympathize with ihnp4's mail volume, and the perceived need to optimize the ridiculous return paths generated by news, their implementation is crude and excessive. Besides keeping their pathalias files up to date, I would suggest that sites that like to play with other people's routings adhere to guidelines like this: 1. If the path is less than five hops long, don't optimize it. 2. If the "cost" from pathalias isn't at least twice as good as the original path, don't optimize it. This way, users who know what they're doing can avoid being screwed over by so-called "smart" mailers. On the WEITEK machines, we don't have the volume problems that ihnp4 has, so we just run uumail as posted on the net. The beauty of uumail is that it only looks for the optimum path to the first hop in the address, so when presented with a complete path, it does no optimization at all. -- Robert Plamondon UUCP: {turtlevax, resonex, cae780}!weitek!robert FidoNet: 10/624 robert plamondon