This is the README for smail3.1.20.s.tar.gz [Download] [Browse] [Up]
This is Smail3.1 Beta 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 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. Smail3.1 does not limit the size of mail messages. There is a
configuration parameter for this, but it is currently ignored.
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
CHANGES IN THE 3.1.20 RELEASE
Release 3.1.20 is the first truly new release to come along in quite
some time. The past two releases, 3.1.18 and 3.1.19 involved very
little work. The 3.1.18 release fixed one bug, the 3.1.19 release was
merely a re-release of 3.1.18 with some new sample files added.
Some changes in 3.1.20 are:
1. The scripts for managing operating system configuration files have
changed substantially. The new system is more generalized, and
allows for much simpler addition of new parameters, as well as the
ability to override os-file parameters in the EDITME file.
However, older conf/os files are no longer compatible, and will
need to be rewritten.
2. Support for SVR4.0 and POSIX. Smail now compiles under SVR4.0,
and it also has some generic posix support, which the SVR4.0 and
SunOS4.1 conf/os files use a base.
3. I put smail under a new source control system. The new system is
SCCS-based, like the old one, but I was forced to reset the
SCCS-ID sequence for all source files. Thus, all files are
different, at least in their SCCS ID.
4. It should now be possible to compile smail with gcc, since the CC
attribute is now tunable in the EDITME file.
5. Smail can now be used as the execmail program for SCO Xenix.
6. The LOGNAME and USER variables can now be supported. See the
sender_env_variable attribute in the smail(5) man page.
7. The forwardfile driver now allows uid ranges to be specified, for
the caution and unsecure attributes. This allows greater
security, by forcing all low-numbered (1-10, though it is
configurable) user-IDs to be handled through the "nobody" id.
Some bugs that were fixed:
1. Outgoing SMTP messages will no longer generate the malformed
address @user@host.
2. Invalid headers should no longer cause smail to abort and leave
messages queued forever.
3. The bind router now includes resolv.h using the right path (at
least on all systems I know about).
4. Smail should now run correctly under SunOS4.1. Previously, smail
tried to reserve unlimited data and stack space (to prevent low
limits from impacting smail's ability to operate). However, this
prevented linking of shared libraries, for programs executed from
smail. Smail now has a configurable limit which is less than
unlimited for SunOS4.1 and SVR4.0.
5. A bug was fixed that several people reported, where long TZ
strings could cause smail to dump core.
6. A bug was fixed where smail would try to free the sender variable
in the SMTP code, even though the sender variable was not always
allocated with malloc. This caused random core dumps on some
machines. The sender variable is always allocated now.
7. The hashing functions were modified so they no longer require that
a cast yield an lvalue.
8. Some compiler errors on the RS6000, relating to enums being used
before being defined, should be fixed.
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 <veritas!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@veritas.com
ARPA: veritas!bugs-smail@Apple.COM
UUCP: {amdahl,apple,hoptoad,uunet}!veritas!bugs-smail
There is a mailing list, that I use for sending out patches, and patch
notices. To subscribe, send mail to:
smail-alpha-request@veritas.com
There are now two discussion lists maintained by Lyndon Nerenberg,
lyndon@cs.athabascau.ca: smail3-users and smail3-wizards. To
subscribe send mail to:
smail3-users-request@cs.athabascau.ca
Please send questions, comments, or anything else you have to say
either to me, or to the discussion groups.
--
Ronald S. Karr ARPAnet: veritas!tron@apple.com
tron@veritas.com UUCPnet: {amdahl,apple,pyramid}!veritas!tron
These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Netfuture.ch.