Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!sri-unix!hplabs!gatech!cbosgd!mark From: mark@cbosgd.ATT.COM (Mark Horton) Newsgroups: comp.mail.headers Subject: Re: smail Message-ID: <3232@cbosgd.ATT.COM> Date: Thu, 8-Jan-87 16:34:57 EST Article-I.D.: cbosgd.3232 Posted: Thu Jan 8 16:34:57 1987 Date-Received: Fri, 9-Jan-87 04:39:12 EST References: <14227@amdcad.UUCP> Organization: AT&T Bell Laboratories, Columbus, Oh Lines: 54 Keywords: smail Well, I'm sorry that Phil is having problems with smail. It's also unfortunate that, rather than to ask us for help in fixing whatever problems he's run into (or better yet, asking his SA, who understands smail) he's chosen to go public. I don't stay caught up on netnews these days, and it's hard to help out members if we are unaware of the problem. We are contacting AMD to see if we can work out the problems. Smail does not normally reroute mail. It is possible to configure it to do that, but in general we don't recommend that, because it gets in the way of smart users who want to force a particular path. (Rerouting was put there for hosts like ihnp4 that get lots of netnews-path replies sent through them - it saves them considerable money. Gary Murakami is an expert and fully understands the tradeoffs of doing rerouting. We don't recommend that people set REROUTE unless they really know what they are doing, and even then I discourage it.) If people are finding their mail rerouted, then either people are disregarding the warnings, or else there is a bug somewhere we'd like to track down and fix. Telephone calls tend to be about the same cost, no matter how far they go, as long as they stay within the 48 states. Intrastate calls are often more expensive, due to less restrictive local regulation. The hop that goes across the country may seem inefficient, but if pathalias chose it, it's usually pretty reasonable. Of course, direct links should be used, if they are reliable and exist, unless there is good reason not to. Mail is sometimes bounced, due to systems that violate the standards. Since UUCP is a free community with lots of R&D on it, there are always people breaking their mailers. When politely told of the problem, most SA's are very happy to fix it. But it's a fact of life, whether one runs smail or not - mail will be bouned. Within the domain world, I have found mail to be pretty solid, certainly the weakest part is the underlying UUCP connection. Before smail, I had to keep a map of the net in my head, and a lot of my mail bounced. With smail, the system keeps a map for me, and less of my mail bounces. decwrl is primarily on DEC's ENET, and secondarily on the ARPANET. They consider themselves to be only tertiarily on UUCP. Given the complexity of an ENET-ARPANET gateway, I understand their decision. As a result, anything they get for a domain they don't recognize gets sent via the ARPANET, since they have chosen not to be a forwarder between ARPA or ENET and UUCP. Brian Reid and I spent some time a while back tracking down problems with their MX handling (most of which turned out not to be decwrl's fault, but problems elsewhere on the ARPANET) and now mail from DEC to a UUCP domain is forwarded properly, as Phil points out - in his case via Sun. The extra hop should be transparent and quite fast, since it goes over the ARPANET from decwrl to sun. It would be nice if decwrl's software would deliver it directly, but that would be hard to do, and the benefit would be awfully small, so I certainly understand why they aren't devoting the effort to do so. Mark Horton