⟦4717ebd60⟧

TextFile

This is Smail3.1 Alpha by Ronald S. Karr and Landon Curt Noll.  The
majority of sources under this directory are copyright by the authors,
whereas code under the pd subdirectory is available in the public
domain.

See the file src/COPYING for information on copying restrictions.
This release is being made generally available because of the length
of time being used to generate the Smail3.2 release.  The Smail3.2
release (which will include many bug fixes and architectural changes)
was intended to be the first general release of Smail3.  However, demand
for Smail3 has proven to be very high, and the quality is deemed to
be sufficient as long as users understand its potential problems.


KNOWN PROBLEMS IN THE SMAIL3.1 RELEASE

There are a small number of things that are known to cause problems,
but which have not been addressed in the 3.1 release.  Here is a summary
of the serious problems:

1.  Smail3.1 lacks the ability to limit processing of incoming messages.
    As a result, incoming SMTP traffic can swamp a machine, or use up
    all available VM resources, or file table entries.  The best fix
    for this, in the 3.1 release, is to perform all mail delivery through
    a daemon process rather than at the time mail is received.

2.  Spill-over spool directories don't always work correctly, so don't
    use them.  A spill-over directory is a second directory listed in
    the spool_dirs configuration variable.

3.  Incoming mail with invalid mail headers can sometimes result in mail
    that stays on the input queue until the mail maintainer intervenes.

4.  Smail3.1 does not limit the size of mail messages.  There is a
    configuration parameter for this, but it is currently ignored.

5.  Under some releases of SunOS release 4, programs that use shared
    libraries cannot be executed from Smail.  I have no idea why this
    is (and do not have a Sun floating around to examine the problem).
    Anyone who runs into this problem and can solve it, should send
    mail to me and to the mailing list indicating the solution.

In addition, there are some features that Smail really should have, and
that are intended for a future release.  Some of these are:

1.  The ability to deliver multiple messages per connection to a
    destination host.  The proposed solution for this also involves
    a separate Smail daemon for delivery, similar to the organization
    of the Zmailer program by Rayan Zachariasan (sp?) of the University
    of Toronto.

2.  Smaller mail queuer programs (i.e., rmail, rsmtp), that do not have
    all of Smail linked into them.  This would make smail more palatable
    on smaller systems.

As mentioned in problem 1 above, sites with potentially heavy network
SMTP traffic should not cause mail to be delivered immediately upon
receipt of a message, unless they have a reasonable amount of VM space
and a large number of available file table entries.  To prevent immediate
delivery, use an entry in your /etc/inetd.conf file such as the following:

	smtp	stream	tcp	nowait	root	/usr/lib/sendmail -odq	smtpd

Alternately, to get all possible points of entry for mail, add the following
line to your /usr/lib/smail/config file:

	delivery_mode=queued


FUTURE SMAIL3 RELEASES

Smail development has been on hold for quite a while, because the only
original author still working on the project (Ron Karr <tolsoft!tron>)
has been working very hard at a startup company for about a year.
Significant work has been done on the Smail3.2 release to address all
of the above problems, but the work is not in a releaseable state.

To address the problem of getting the new release in a releasable state,
I have contracted some of the work out to a small number of other
programmers, who started with Smail early in the alpha release program.
Until the results of this new strategy start to come in, I cannot say
when future releases of Smail will be made available.


CONFIGURATION

We recommend that you read through the various man pages before
setting up and installing smail.  To generate the man pages, change to
the man directory and type "make".  This will generate man pages for
the default smail configuration.  Detailed information on smail can be
found in the man pages smail(5) and smail(8).

All run-time configuration files are optional, and the smail program
itself creates anything that it absolutely needs.  Thus in the
simplest example, the installation procedure is simply to setup the
base internal configuration and type the various make commands.

The only file that you must edit is conf/EDITME, which drives the
compilation process for the smail binary and the several accompanying
utilities.  This file describes the locations of various files and
directories, enables or disables various capabilities, and points to a
file describing your architecture and operating system.  It should be
copied from the source file conf/EDITME-dist.  Note that if you generated
the smail man pages, the conf/EDITME file will have already been created
for you, though you should still review and edit it.

Future patches to smail will be applied to conf/EDITME-dist and it will
be your responsibility to make sure that these changes are reflected in
conf/EDITME, as needed.

Some sites may also need to create an operating system description
file.  To do this, change to the conf/os directory and copy the file
"template" to a name descriptive of your operating system.  Then edit
the copy as appropriate.  The basename of this file can then be used
as a value for the OS_TYPE variable in the EDITME file.  If you create
a new operating system description file, please mail it to us so that
we may add it to the distribution.

A simple way to test smail is to set the variable TEST_BASE in the
EDITME file to a test installation directory.  A "make install" will
create a tree under this directory, with all of the smail binaries and
utilities.  Smail can then be tested in this directory without
affecting the operation of any other mailers currently working on your
system, including a previous installation of smail itself.


BUILDING AND INSTALLATION

NOTE:  You should probably do a test build install before installing
       smail onto a live system.  To do this, setup the TEST_BASE
       variable as described above, and go through the steps in this
       section.  Then, to install on to a live system, comment out
       TEST_BASE in the EDITME file and perform these steps again.
       The second time around, it will not be necessary to build the
       makefile dependencies.

When everything is setup, you will need to create the Makefile
dependencies for your system and configuration.  To do this, type:

	make -k depend 2>&1 | tee mkdep.out

If you are a C shell user, try:

	make -k depend |& tee mkdep.out

at the top of the smail source tree.  Scan the output produced by for
any errors.  In particular, watch out for missing include files.  If
any messages about missing include files are generated, please send us
mail describing your operating system and the name of the include file
which was not found.  Please tell us of any similarly named include
files which DO exist, which may be used instead.  Building the
dependencies takes 34 seconds on an unloaded Amdahl 5890, about 6 and a
half minutes on a Sun-3/280, and can it take up to half an hour or more
on smaller machines.

When the dependencies have been generated, build the binaries,
utilities and localized man pages with the command:

	make -k 2>&1 | tee mk.out

or:	make -k |& tee mk.out

This may take a while.  The complete build takes 1 minute and 30
seconds on an unloaded 5890 (with optimizing turned on), and about 15
minutes on a Sun-3/280.  When I build smail on my Symmetric-S/375 I go
off and do something else for a while, and check on it every ten
minutes or so.  The build takes about 2 hours on Fortune 32:16.

If any errors were encountered, please mail them to us.  Please send a
complete copy of the mk.out file, and a copy of your EDITME file.  If
you wrote your own operating system configuration file, please send
that, too.  If you have any comments, or if you have your own fixes,
please send those as well.

When smail builds correctly, install it by typing:

	make install

To install the man pages as well, type:

	make installman

These commands may be typed in any individual directory, as well, to
build or install within a limited context.  Most make command at any
level within the tree will descend to lower levels within the source
hierarchy and execute the same make command.

The following additional make commands can be useful:

	make clean	- to clear out make intermediate files.
	make clobber	- to clean intermediate and target files.
	make names	- to list all source files at or under a source
			  directory.
	make names SRC_PREFIX=`pwd`
			- list all source files with full pathnames.
	make local_depend
			- make dependencies in the local makefile but do
			  not descend into subdirectories.

These commands can also be useful if you keep smail under SCCS control:

	make nuke	- remove all intermediate, target and source
			  files.  Source files which are checked out for
			  editing are not affected.  Makefiles are
			  retrieved from their SCCS files.
	make sources	- create all missing source files from their SCCS
			  files.

If you wish to put smail under SCCS control, we suggest that you do so
immediately after obtaining the distribution.  For those who wish to keep
their sources under RCS control, the command:

	make sources GET=co

will retrieve all sources from the RCS files.


CREATING CONFIGURATION FILES

If you have need of a more complex configuration than can be provided with
the internal defaults, read over the smail(5) man page carefully.  We
believe that the process of writing files is reasonably straightforward,
though if you have any questions, or if you dispute this claim, please
send mail.  Sample configuration files can be found in the directory
samples/.


PATCHES

Patches may be made available in the future.  These will be announced
in comp.mail.uucp and may be made available on uunet.  These patches
will probably not be significant in size or in functionality until the
Smail3.2 release.


THE DESIGN DIRECTORY

The design directory contains the smail3.0 design paper, which was included
because it contains information which is not currently in any other
documentation.  It's accuracy should be considered questionable, and some
of its examples are inconsistent.  This design paper is being phased out,
to be replaced entirely by man pages and the admin/user guides.  Consider
yourself warned that the design documentation should not be treated as
the gospel truth, and that it will not be maintained to reflect changes
in the package.


BUGS AND COMMENTS

Please send bug reports or fixes to:

	bugs-smail@tolerant.com
ARPA:	tolsoft!bugs-smail@Apple.COM
UUCP:	{amdahl,apple,hoptoad,uunet}!tolsoft!bugs-smail

There are two mailing lists that are maintained for discussion and patch
releases.  These are:

	tolsoft!smail-alpha	- patch distribution mailing list
	tolsoft!info-smail	- Smail3 discussion list

Please send questions, comments, mailing list requests, or anything else
that you have to say to the address:

	info-smail-request@tolerant.com
ARPA:	tolsoft!info-smail-request@Apple.COM
UUCP:	{amdahl,apple,hoptoad,uunet}!tolsoft!info-smail-request
--
	Ronald S. Karr		ARPAnet:  tolsoft!tron@apple.com
      tron@tolerant.com		UUCPnet:  {amdahl,apple,hoptoad}!tolsoft!tron
DataMuseum.dk

DKUUG/EUUG Conference tapes

⟦4717ebd60⟧ TextFile

Derivation

TextFile
