peter@ficc.ferranti.com (Peter da Silva) (07/06/90)
Just what are the differences between smail 2.5 and 3.x? I have got the impression somehow that smail 3.x is really a different program with a different set of goals than smail 2.5. That it fits into a slightly different place in the mail system, and requires different support. What's the skinny? Oh yes, and where can you get the bloody thing? -- Peter da Silva. `-_-' +1 713 274 5180. <peter@ficc.ferranti.com>
tneff@bfmny0.BFM.COM (Tom Neff) (07/06/90)
"Smail 3" is really GNU sendmail in all but name. Its only relationship to smail 2.5 seems to be naming coincidence and/or someone's intention that it be a logical successor. All the code is new, and it's huuuge. My impression, shared with others judging from mailed comments, is that UUCP leaf sites don't need smail 3 -- smail 2.5 plus Deliver give total flexibility and functionality at a fraction of the code size and complexity. Networked sites and domain servers can probably make full use of Smail 3's features. The latest smail 3.1 was announced a while ago for FTP, I forget where; but UUNET's archives will probably get it shortly -- look at pub/smail3.tar.Z in the ls-lR and see if it's the July release. -- "DO NOT, repeat, DO NOT blow the hatch!" /)\ Tom Neff "Roger....hatch blown!" \(/ tneff@bfmny0.BFM.COM
lyndon@cs.AthabascaU.CA (Lyndon Nerenberg) (07/07/90)
tneff@bfmny0.BFM.COM (Tom Neff) writes: >"Smail 3" is really GNU sendmail in all but name. Its only relationship >to smail 2.5 seems to be naming coincidence and/or someone's intention >that it be a logical successor. All the code is new, and it's huuuge. Smail3.1 has nothing to do with the GNU project (yet). Plans are to offer it to the FSF at some future date. Yes, it's big. That's what happens when you write software with comments and documentation :-) >My impression, shared with others judging from mailed comments, is that >UUCP leaf sites don't need smail 3 -- smail 2.5 plus Deliver give total >flexibility and functionality at a fraction of the code size and >complexity. Networked sites and domain servers can probably make full >use of Smail 3's features. Leaf sites don't need it, but I recommend it for System V sites that are leaf nodes, if only so that they will get some proper headers inserted into their mail. Smail3.1 is basically a drop in replacement for sendmail. Unlike sendmail, you talk to it in a way that bears a much closer resemblance to english that .cf files do. It provides great flexability in choosing how, when, and where to route your mail. It also runs on a very large number of UNIX platforms. (I've run it under Ultrix {1.2,2.3}, SunOS {3.5,4.0.3}, System V Release 3.2.2 on 3b2's and 6386E's (both with Wollongong TCP), and CTIX 3.20 and 5.23.) The code is still in ALPHA test, although it is reliable enough to run as a production MTA. The code is being made available now due to the number of requests the authors have been receiving. A more stable BETA release (smail3.2) will be released later this year, probably via one of the comp.sources groups. >The latest smail 3.1 was announced a while ago for FTP, I forget where; >but UUNET's archives will probably get it shortly -- look at >pub/smail3.tar.Z in the ls-lR and see if it's the July release. Yes, it's on uunet, but I'm not sure where. You could also try the following: From: lyndon@cs.AthabascaU.CA (Lyndon Nerenberg) Newsgroups: can.uucp,can.general Subject: smail 3.1 availability Date: 28 Jun 90 20:58:25 GMT For those of you who attended the smail3.1 BOF at the NET90 conference, the source code is now available for anonymous ftp/uucp access from van-bc. The compressed tar archive is 902701 bytes. To ftp it, connect to van-bc.wimsey.bc.ca [128.189.233.155] using login anonymous, password guest, and take a copy of /pub/mail/smail3.1.19.Z in BINARY mode. For uucp access, request the file van-bc!~ftp/pub/mail/smail3.1.19.Z using one of the following: PEP: +1 604 939 4782 login: nuucp password: nuucp 2400/1200 +1 604 939 4756 login: nuucp password: nuucp Sites with uucp connections to aunro or atha can uucp the file from ...!~/smail3.1.19.Z. If you cannot use the above methods, I'm willing to cut tapes in the following formats: Sun 1/4 inch cart (60 or 150 MB) 1/2 inch 9 track (1600 or 6250 BPI) Exabyte 8mm 3b2/1000 1/4 inch cart To get the distribution on magnetic media, send a blank tape of your choice with a cover letter indicating the format you require to me at the address listed below. Please include an email address or daytime telephone number where you can be reached. Don't forget to include a return postal address, or your tape will be added to my archive collection. I'm also thinking of starting an smail3.1 users list. If you're interested in participating, please let me know. Finally, to those of you waiting for direct email information, I will be sending you detailed information next week. I apologize for they delay. Things have been a wee bit busy since I returned, and I'm in the process of moving ... :-( Lyndon Nerenberg Computing Services Athabasca University Box 10,000 Athabasca, Alberta T0G 2R0 -- Lyndon Nerenberg VE6BBM / Computing Services / Athabasca University {alberta,cbmvax,mips}!atha!lyndon || lyndon@cs.athabascau.ca Practice Safe Government Use Kingdoms
les@chinet.chi.il.us (Leslie Mikesell) (07/08/90)
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? Smail 2.5 does simple aliasing and path routing, decides which addresses are local and remote, then hands everything off to another program to deliver. Smail 3.1 also handles the delivery to files, other programs, or via SMTP. It is much more complex, mostly due to the design which provides generalized low-level routines for database lookups (linear, binary search, and dbm) and delivery methods (append-to-file, pipe, smtp, etc) and allows either compiled-in defaults or runtime configuration files to specify the details of when and how to use them. The default configuration will allow you to specify multiple names to be accepted as the local host, and allows aliases to expand to the same thing as the address that produced it, in which case it moves on to the next step in the delivery. This lets you share an alias file file among several machines (the expansion to user@local-machine is accepted), and you can include your own name in a .forward file along with other addresses (the next step in delivery would be to your mailbox). Expansions that are different from the address that produces them are handled from the top and thus may refer to other aliases or remote addresses to be routed. Files and pipes to programs may be specified in the alias and forward files with an assortment of security options to control execution. There are provisions for mailing lists and delivery may be configured for foreground, background, or queued (a scheduled or daemon process delivers 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. Les Mikesell les@chinet.chi.il.us
cluther@supernet.UUCP (Clay Luther) (07/08/90)
All very well and good, but were can one find smail 3.1?
--
Clay Luther ..uunet!iex!supernet!cluther
Usenet Administrator supernet!cluther%iex.uucp@dept.csci.unt.edu
Harris Adacom Corp, Dallas, Tx cluther@supernet.UUCP
iex!supernet!cluther@uunet.UU.NETbob@pds3 (Robert A. Earl) (07/08/90)
In article <1985@aurora.cs.athabascau.ca> lyndon@cs.AthabascaU.CA (Lyndon Nerenberg) writes: >Yes, it's on uunet, but I'm not sure where. It is in /usr/spool/ftp/mail/smail3.1.19.Z -- ============== Robert A. Earl uunet!pds3!bob
tron@tolerant.com (Ron Karr) (07/10/90)
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