Path: utzoo!utgpu!watserv1!watmath!att!rutgers!mit-eddie!snorkelwacker!usc!sdd.hp.com!decwrl!orc!oliveb!tolsoft!tron
From: tron@tolerant.com (Ron Karr)
Newsgroups: comp.mail.uucp
Subject: Re: differences between smail 2.5 and smail 3.x
Message-ID: <1990Jul10.025337.16623@tolerant.com>
Date: 10 Jul 90 02:53:37 GMT
References: <2690C7F4.A40@tct.uucp> <1990Jul4.221134.15621@tolerant.com> <:MG4LEG@xds13.ferranti.com> <1990Jul7.210214.3130@chinet.chi.il.us>
Reply-To: tron@tolsoft.UUCP (Ron Karr,,439,)
Organization: Tolerant Software
Lines: 25

In article <1990Jul7.210214.3130@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes:
 >In article <:MG4LEG@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes:
 >>Just what are the differences between smail 2.5 and 3.x?
 >
 >later).  It appears to be able to be interrupted in the middle of delivery
 >to a list and be restarted later without duplication or omissions, something
 >that would be difficult to do with multi-process mail handling.

The trick is that it keeps mail in a spool directory that can be
reevaluated at intervals.  This can be done easily in many multi-process
mail handers as well, but cannot be done directly with Smail2.5.

One thing that Smail3.1 does handle, in this respect, that many other
mailers do not is that it can handle situations (such as with YP or
DNS) where some information is available and some other information is
not.  An attempt is made to deliver addresses that can be resolved,
while addresses that cannot be resolved right now are resolved later.

The utility of this is somewhat limited, though, since a network being
down generally delays delivery of all mail, since it cannot always
be determined until the network is up which addresses are resolved
through the network and which are not.
-- 
	tron  |-<=>-|		ARPAnet:  tolsoft!tron@apple.com
      tron@tolerant.com		UUCPnet:  {amdahl,apple,hoptoad}!tolsoft!tron