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