Path: utzoo!attcan!uunet!husc6!ncar!woods
From: woods@ncar.ucar.edu (Greg Woods)
Newsgroups: comp.mail.sendmail
Subject: Re: Overlaying smail and mx-sendmail?
Keywords: smail
Message-ID: <818@ncar.ucar.edu>
Date: 6 Oct 88 20:39:22 GMT
References: <8602@shamash.UUCP> <810@ncar.ucar.edu> <118@cwjcc.CWRU.Edu>
Reply-To: woods@handies.UCAR.EDU (Greg Woods)
Organization: Scientific Computing Division/NCAR, Boulder CO
Lines: 55

In article <118@cwjcc.CWRU.Edu> chet@cwjcc.CWRU.EDU (Chet Ramey) writes:
>Even if smail fails totally on resolution, you can have it set up to punt 
>everything either back to sendmail (preserving the non-smail behavior)

....and creating an infinite loop,

>or to a smart host like uunet.

  I don't want to do that (although I could). The problem with doing that,
from my point of view, is that if our name server fails for temporary reasons,
it is normally because we are cut off from the outside world for some reason.
In that case, I won't be able to transmit the mail to a smarter host (if there
is such a thing; my goal is to be a "smart host" myself) until the net comes
back on line anyway. At that point my server query would succeed, but if the
mail is already queued for uunet, then we will have to deliver it there
(and via the slow NSFnet/ARPA gateways, no less) and as a result the mail
will take longer to get to it's destination after the net comes back online
than it would have if it had gotten queued due to a host name lookup failure.

>Well, even a vanilla Internet mail system will behave differently under
>different network states -- for example, a mail delivery system is supposed to
>try all possible MX records for a given host, so if the primary MX forwarder
>for a host is down, the mail will go to the next forwarder in the preference
>list.

  Well, yes, but this "different" behavior doesn't look any different to the
user sending the mail, and THAT is what counts.

>What system do you use that guarantees delivery?

   I do use sendmail and smail both, but not quite in this way. What I have
is a small static table of domains that are in the UUCP maps but either do
not have name servers that I can find or connect to, or else the UUCP route
is better than the MX route (and a third type, actually, which is domains that
we *are* the mail exchanger for). Examples of the second type are pyramid.com,
whose mail exchanger is sun.com to which we have a notoriously bad connection 
(I think they are over on the ARPA side of the ARPA/NSFnet gateways), but the 
UUCP route is ames!pyramid, and we have a direct NASA Science Net link to ames
which is a very GOOD connection, or nbi.com whose mail exchanger is uunet
but we have a direct local phone call link to nbires, their domain gateway host.
If the domain isn't in this table, it gets handed off to the resolver software.
  I am currently engaged in some research to determine just how many domains
(if any) are reachable by UUCP but cannot (for whatever reason) be found
in the domain name system. I will post my results to the net when I get done.
What I am basically doing is taking every line in the pathalias output
database that has a dot in it, stripping off the name (first) field, and
handing that to the name server for MX- and A-record lookups. The shell script
that did this ran for over 17 wall clock hours on a Sun-4 and produced 375
pages (23000 lines) of hared-copy output. This includes all domains and sub-
domains that appear in the UUCP maps. Whether my scheme is a good one or not 
depends a lot on how many domains there are that are unresolvable that can be 
reached by UUCP. My guess is, not many, but I will have more definitive numbers
soon.

--Greg