#ident	"@(#)smail:RELEASE-3_2_0_120:README,v 1.29 2004/03/26 09:27:41 woods Exp"


       This is Smail (RELEASE-3_2_0_120) by the Smail development group.


INTRODUCTION

Smail-3 is a Mail Transport Agent, i.e. a program used for sending and
receiving electronic mail.

Its job is to accept mail messages from sources on the local machine, or
from remote hosts, and deliver those messages to the appropriate
destinations, be they to remote hosts or to files or programs on the
local machine.  It is not intended to be a user interface for reading
and submitting mail.

One of the primary goals of Smail's design and implementation is
security.  Smail currently runs as root but every effort has been made
to design and implement it what are considered the best known ways for
designing and implementing privileged programs.  Part of security is the
issue of dealing with complexity.  Smail attempts to address complexity
both by making it easy to configure itself and by making it diffucult
for complex error prone configurations to be created.  Smail's
configuration is perhaps not simple and easy in the grand scheme of
things, but it is nearly trivial compared to mailers that came before
it.  For the most part Smail should work for most small leaf-node sites
out-of-the-box with very little localisation required.  See the ToDo
file for a discussion on making Smail run without root privileges
wherever possible.

This release of Smail is based entirely on Smail-3.1 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.  Code in the ./contrib/ directory is
owned by the contributing authors, who should be consulted if you have
any questions about distribution or usage restrictions.

See the file COPYING for information on copying restrictions that apply
to all files in the release other than files in the contrib and pd
directories.

See the file INSTALL for information on how to configure and install the
Smail software.  PLEASE CHECK ALL THE SECTIONS OF THE INSTALL FILE.  In
particular, some later sections describe system and environment specific
configuration details that you should be aware of, if they apply to your
situation.

Users of all previous releases really _must_ review the CHANGES file to
see what has changed or to see if some previously encountered problems
have been fixed.  You _will_ have to re-write your conf/EDITME files if
you last used a pre-3.2 release.

This document talks about development and releases; problems; mailing
lists; how to to send bug reports, change requests, patches, etc.; and
of course gives some of the many acknowledgments for, and history of,
Smail.


TESTING

One of the most critical and most common problems faced by Smail users,
especially after upgrades, is testing.


The following shell script fragment makes an excellent addition to your
~/.profile or $ENV file:

    MAILLOG=/var/log/smail/logfile
    export MAILLOG
    maillog ()
    {
        less -en -p ': \[[0-9]+\] (\[.+\] )?remote[A-Z ]*:' +G $MAILLOG
    }

OBTAINING NEW VERSIONS OF SMAIL

The official distribution can be obtained from ftp.planix.com with FTP
using the following URL:

	      ftp://ftp.planix.com/pub/Smail/

Patch releases and new beta release can also be retreived from this same
directory.


CHANGES TO SMAIL DEVELOPMENT PROCESS

In June 1994, Ronald S Karr, who had almost single handedly run the
Smail-3 development up to that time, decided that he was unable to keep
up with the work required to keep smail development going.  An ad-hoc
development team was subsequently set up, initially with the task of
getting a smail 3.1.29 release built which fixes the security problems
found in smail 3.1.28, and to continue future Smail-3 development.  It
was also intended that a group will work on development of further fixes
and changes for Smail-3 and hopefully, eventually, a re-write.

Since the release of smail 3.1.29, Nigel Metheringham was responsible
for a great deal of work in creating many development releases, and
incorporating numerous changes and fixes from the ad-hoc team.

With the release of Smail-3.2, a new group is being formed, made up of
past participants and new, who will all have direct access to the
official Smail-3 sources repository.  Please see the section below
regarding bugs and patches for further information.

This development group is intended to be small enough to work quickly,
and large enough that the work can be spread out to prevent single
person overload.  If you are interested in joining the group then please
contact the bugs address given below.  We are always interested in
receiving bug fixes and/or new features patches whether or not you are a
member of the development group -- again see below for how to do this.

Note that a complete re-write of Smail is probably never going to
happen.  There is now one new work-alike mailer (Exim) available, and
there are several well-admired alernative mailers too (Postfix, ZMailer,
qmail).  Postfix is a very high-performance mailer that was actually
designed with security first in mind.  ZMailer also has good support for
inter-network gatewaying and is highly configurable and extensible.


KNOWN PROBLEMS IN SMAIL RELEASE-3_2_0_120

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

 *  Spill-over/alternate 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.

  * Locking of mailboxes over NFS, even with LOCK_BY_NAME=TRUE, will not
    work because of bad interactions between NFS attribute caching and
    the order of operations performed by smail.  The work-around is to
    turn off attribute caching.  There's a comment in the appendfile
    driver source that says how it should be done in order to make it at
    least possible for NFS locking to work.

Please consult the ToDo file for a list of other known minor problems.

Please also consult the PROJECTS file for a list of other important
things that Smail could benefit from.


FUTURE SMAIL RELEASES

If anybody would like to take on the large task of making Smail a
leaner, cleaner, and more adaptable program, please let us know.  If
nobody ever comes forward, then we will probably have to consider the
full rewrite dead, and continue hacking on the current sources.

I am interested in volunteers for large, and medium-sized tasks.  If you
are interested, please send us e-mail.

The next major release of of Smail (if there is one! ;-) will have been
converted to use the GNU Autoconf (and Automake) utilities for system
configuration.

Smail will no doubt be popularly known as Smail-3 for a long time to
come.  However it is expected that Smail will follow the Berkeley CSRG
version numbering scheme for future releases.  We will increment the
third number (3.7, 3.7.1, 3.7.2, etc) whenever we generate a release of
bug fixes (what might traditionally be also known as a "patch" release),
and increment the second number, or the minor release number, (3.7, 3.8)
whenever we add any new features or make other user-visible changes, and
lastly we'll increment the first number, or the major release number,
(3.9, 4.1) whenever we make major or architectural changes.  We'll also
throw in a smattering of GNU-isms too -- the alpha- and beta-test
releases of upcoming proper releases will have a ".80" or ".90"
(respectively) appended to the current release number (3.7.1.80,
3.7.1.81, 3.7.1.90, 3.7.2; or 4.1.80, 4.1.81, 4.1.82, 4.1.90, 4.1.91,
4.2).  You'll note this effectively caps the maximum patch level, or
minor release number, ceiling at ".79", and limits the number of alpha
releases to 10.  Unfortunately it does not limit the number of beta
releases!  ;-)  If you see "-Pre" appended to the release number then
you're seeing an intermediate development release.


GENERAL ACKNOWLEDGEMENTS

The Smail-3.2 release now exists, thanks to the efforts of Chip
Salzenberg, Nigel Metheringham, Greg A. Woods, and a cast of others.

These original Smail-3.1 acknowledgments from Ronald S. Karr:

	Some smail3 users go back quite a ways and have provided
	invaluable help, patches, and comments over the years.  Here's a
	few that I can remember: Andy Beals, Mark H. Coburn, Karl
	Denninger, Mark Hartman, Shane McCaran, Tim Mitchell, Gordon
	Moffett, Lyndon Nerenberg, Dave Rand, Andy Rundquist, Chip
	Salzenberg, Johan Vromans, Lauren Weinstein, Syd Weinstein, Bill
	Wisner, and Jon Zeeff.

	A special thanks to Landon Curt Noll <chongo@toad.com> who
	started me on the road of post-college life and caused me to
	write Smail in the process.  He also helped design and implement
	the first several versions.  Without him, Smail3.1 certainly
	would never have been written.

	A special thanks also to Larry Auton, who wrote Smail2.5.
	Without him, Smail3.1 would have, at the very least, been called
	something else.  He also provided valuable encouragement and
	comment during the earlier phases of smail design and
	development.


BUGS, COMMENTS, AND PATCH SUBMISSION

Please generate and send bug reports and/or fixes by using the smailbug
utility (a customised version of GNATS send-pr) included with Smail.

A list of PRs that have not yet been closed can be obtained by sending
e-mail to this address:

	smail3-query-pr@planix.com

with a subject line consisting of the string "query-pr -qx".  Other
options to query-pr(1) can also be used to refine the query, or to
obtain the full text of a PR.  Please see the GNATS documentation for
more information about the query-pr command.

There are now two discussion lists, originally started by Lyndon
Nerenberg:  smail3-users and smail3-wizards.

To subscribe to either of these lists send mail to either:

	smail3-users-request@athabascau.ca

and/or to:

	smail3-wizards-request@athabascau.ca

I do not have any connection with these lists, other than the fact that
I maintain the software they discuss.  So, please don't send list change
requests to me.

Please send questions, comments, or anything else you have to say either
to me, or to the discussion groups.

I vastly prefer receiving bug fixes and enhancements that are clearly
differentiated.  I don't always know what to do with large patches that
contain many bugs and enhances folded into the same context diffs.
Please try and keep it to one fix or enhancement per patch.  If your
change modifies the external interface of smail -- i.e. more config
options, command-line switches, new programs, etc., then please also
include patches for the manual pages and documentation.  Patches should
ideally be in context or unidiff format, and should have "Index:" lines
to specify the file to be patched.  Finally, *please* include ChangeLog
style entries to describe your changes.  Incomplete patches will greatly
lower their priority for consideration.  Remember too the best way to
submit patches is by using the smailbug utility.

[ Again, generating patches with your local changes is quite easy if you
employ CVS as a source control tool. ]

If you are a past Smail-3 maintainer, and/or you've recently supplied a
number of good patches, and you are willing to volunteer some time to
help with the future maintenance of Smail-3, your application can be
considered for membership in the Smail-3 developers group.  This
membership will allow you access to the master CVS source repository and
our GNATS bugs database.  Please see the charter for the development
group in the file ./Smail3-devel.

-- 
						Greg A. Woods
