dhp@ihlpa.UUCP (Douglas H. Price) (06/05/86)
As usual, ihnp4 has been having some problems. It tossed its cookies a couple of times this week, culminating with the truncation of the Systems file from M to Z yesterday (Weds). We only detected the problem at noon on Thursday, so mail destined for sites whose names begin with M through Z may have had their mail dropped on the floor. Sorry, but due to funding confusion with ihnp4, it is becoming more diffcult to maintain service. We're trying, though..... -- Douglas H. Price Analysts International Corp. @ AT&T Bell Laboratories ..!ihnp4!ihlpa!dhp
gds@sri-spam.ARPA (The lost Bostonian) (08/27/86)
I would like to thank Mr. Uhrig for his concern over the situation. This problem has come up before, but no one seemed to be concerned. Now that it is revealed to be serious, perhaps a new policy for uucp mail should be set. In article <3880@ut-ngp.UUCP>, werner@ut-ngp.UUCP (Werner Uhrig) writes: > 1) given that we have "smart mailers" these days, that do auto-routing > where the user does NOT determine the path of the message, the > question begs: > > HOW CAN THE AVERAGE USER AVOID IHNP4? > > IS ANYONE DOING ANYTHING TO UPGRADE THE TABLES TO AVOID IHNP4? I have held, ever since I found out that certain sites were munging my headers to make my messages go elsewhere, that uucp mail autorouting is a no-no, because no site should be using static tables to determine routing. I don't want to get into an argument about "real networks" here (hi, henry!) but as a person who has had some experience with routing protocols, routing based on static, and possibly out-of-date information is bound to get you into trouble. If I specify a full-path source to destination address (I use address here as meaning the To: line, please lets not start an argument about addresses vs. routes), which has a high confidence of success, there is no need for an intermediate to provide a different, perhaps less reliable route for me. I feel the only acceptable rerouting of such paths would be if the next hop was not a neighbor, then the routing tables should be consulted for the most likely hop which will get you to your destination. If one particular link is lossy, the mail should be queued until the link is good, if the time for the link being good is exceeded, the mail should be returned, or dropped. If uucp routing could be done more dynamically, perhaps autorouting would be acceptable, because the finding of reliable routes would be much more timely. In answer to the first question, because of the presence of smart mailers, there's not much you can do if their tables are configured to route through ihnp4 even if the path is complete. Best thing to do is find a complete path to your destination that you know works (if your destination can only be reached through ihnp4 you are out of luck), and hope that your mail won't be rerouted. In answer to the second question, perhaps an ihnp4 map update would be in order. In the meantime, sites which poll, or are polled by ihnp4 can set their value for ihnp4 to something greater than DEMAND. * begin philosophical mode * Two things might be done to alleviate this problem in the future. One would be to add a header to each message saying something like Routing: level where level 0 indicates the path should be interpreted as a strict source route. Failure to deliver the mail over a uucp link should result in dropping or returning the mail. Higher levels could accomodate various types of rerouting, the highest being "do whatever you think is necessary to get the mail to its destination". Of course, sendmail will have to be modified to interpret the header and do the appropriate modification (or non-modification) of the To: line. The other thing would be to take pathalias-generated routes out of sendmail, unless the next hop in the To: line is not a uucp neighbor. I consider it somewhat presumptuous for sites to reroute mail based upon what they think an appropriate route to a destination is, if a full path has been specified. I can understand the needs of certain sites to cut costs and so forth, but if they do not wish to communicate with certain neighbors, they should not advertise map entries for them, or they should return or drop mail addressed to certain places. * end philosophical mode * This should not be considered as a knock on ihnp4's or anyone else's uucp service -- the fact that they dedicate their machines to the passing of other companies' mail is laudable. However I don't feel it is in certain sites' best interests to reroute mail, and it is certainly not in the sender of mail's best interests for it to be rerouted. Autorouting has possibly caused more problems for sites like ihnp4 in that they take on a lot of mail which was not intended for them. They have enough problems handling the mail that is. --gregbo
gds@sri-spam.ARPA (The lost Bostonian) (08/29/86)
I did some additional thinking and research about the problem. There is an acceptable rerouting scheme I failed to mention earlier -- path optimization. Example: To: a!b!c!d!e!user passes through a and b ok, arrives at c. c has both d and e as neighbors. It is acceptable for c to send the mail direct to e. If the originating machine has tables that show c has links to d and e, it is conceivable that a might rewrite the To: line to a!b!c!e!user, but questionable that it should (after all, this is based on possibly old data). However, it is not OK for b to deliver to something like f!g!e!user, because c!d!e is fully specified. I believe this is the problem we are discussing. By the way, I read RFC 976 to see if it sheds any light on these scenarios. It makes no specific comments on whether a fully-specified To: line should be rerouted, however To: lines with domain forms in them can (and probably are) being rerouted. I don't have a copy of smail, but I am assuming that it works according to RFC 976. [RFC 976 -- UUCP Mail Interchange Standard, written by Mark Horton] --gregbo
dianeh@ism780c.UUCP (Diane Holt) (08/30/86)
In article <6571@sri-spam.ARPA> gds@sri-spam.ARPA (The lost Bostonian) writes:
[Very sensible presentation suggesting that autorouting by "smart
mailers" should either be reconsidered or allow for a way of
overriding.]
I agree wholeheartedly. I just experienced my first toss-my-message-across-
the-country--hold-it-trying-to-contact-an-uncontactable-machine--toss-a-
message-back-across-the-country-telling-me-it-can't-go-through--and-do-it-
all-again game. Now, I knew my message's destination was only about 300
miles north of here, so I specifically looked for a full path routing that
would keep it in CA. When I got a message from ihnp4 telling me it couldn't
contact wb2, my first reaction was "How the hell did my message end up at
ihnp4?", so I did some checking around and found out about autorouting
("optimizing"). It is difficult for me to imagine that sending my message
from the West coast to the East coast and then a message back to me
(actually, it happened twice, because the first time it happened I figured
I'd just try to resend it with the same routing and hope for the best)
doesn't seem like much of an "optimization" to me -- and when I found out I
*couldn't* override it, I was incensed...there should NEVER be an
"automation" that can't be manually overridden -- GPs! Well, I finally found
a routing that would avoid the machine (sdcrdcf) that was autorouting, but
the whole process of getting my message from Santa Monica, CA to Palo Alto,
CA took two weeks!
Now, I'm not against autorouting per se, but for it to be truly efficient
it should either 1) guarantee that it's rerouting will in fact be the most
optimal (and a successful) path (which seems unlikely due to the maintenance
overhead of the database it uses), or 2) it should allow for users to
*override* it. I vote for #2 in any case.
P.S. I used to offer a return mail path in my signature that included ihnp4;
I don't think I'll be doing that from now on, now that I know about the
problems that inhp4 is having. That information should be made more generally
available.
Diane Holt
Interactive Systems Corp.
Santa Monica, CA
decwrl!sequent!ism780c!dianeh
"You depend on it for so much, but are any of you really its master?"
(Originally said in reference to language, but the way things are going it
looks like it could start being applied to technology.)rogerh@megaron.UUCP (09/02/86)
Ihnp4 may be overloaded, but they are trying to provide service; I just got a nice note from ihnp4!mail warning me that it couldn't contact the next site on the specified route and that my mail would be dropped after a few more days. Better service than I ever expected from uucp...
gjm@packard.UUCP (Gary J. Murakami) (09/03/86)
Folks, I'm sorry that I no longer have physical access to the hardware and consoles of ihnp4 and its communication equipment. I've done some poking around on ihnp4. Part of the problem is that the old data PBX system at Indian Hill was retired recently. This removed 8 inbound lines (AT&T use) and about 8 outbound lines (including our 2400 bps dialers). So the remaining inbound ports are more congested than ever. There is also a possibility of a flow control problem on the new outbound lines. I've made a few phone calls to try to get the current configuration examined... -Gary
henry@utzoo.UUCP (Henry Spencer) (09/04/86)
> To: a!b!c!d!e!user > > passes through a and b ok, arrives at c. c has both d and e as > neighbors. It is acceptable for c to send the mail direct to e... Not necessarily. Life would be much simpler if all links were of equivalent quality -- certainly pathalias wouldn't have to work so hard -- but that's not the way it is. It's not uncommon for the c!d!e path to be *much* better than the c!e path, so large or time-critical mail might not want to be gratuitously rerouted through a poorer link. If one must reroute, the right criterion is that the c!e route should be at least as fast and, if the mail is large, that it should have comparable bandwidth. It would be nice to factor some measure of reliability into this as well, but getting the data for that is hard. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,decvax,pyramid}!utzoo!henry