PC-Online 1996 May/PCOnline_05_1996.bin/linux/source/contrib/smail/smail-3.1/smail-3/smail-3.1.28/README

Text File | 1992-09-20 | 20KB | 480 lines

This is Smail3.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.

PLEASE CHECK ALL THE SECTIONS OF THIS 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 earlier Smail3.1 releases should review the CHANGES file, to
see what has changed or to see if some previously encountered problems
have been fixed.


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:

 *  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.

 *  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:

 *  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.

 *  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.


SYSTEM-SPECIFIC CAVEATS

 *  On mips systems, and possibily on other dual-universe systems, be sure
    to set the BSD and System V timezones to the same value.  For mips
    systems, the System V timezone is in /etc/TIMEZONE.  The timezone value
    used by BSD routines is stored in the kernel and is set by the date
    command.  For example, if you are in the Pacific timezone, set
    /etc/TIMEZONE to:

    TZ=PST8PDT
    export TZ

    and set the kernel timezone with:

    date -t 480

    At least one user was surprised to find smail using a different timezone
    than some other commands.


GENERAL COMPILATION NOTES

On Interactive, and probably on other systems as well, if you don't
use an using an ANSI C compiler you will get the following messages
while compiling:

    ../../util/dbm_compat.h: 13: bad include syntax
    ../../util/dbm_compat.h: 22: bad include syntax

Ignore these messages.  They result from an #ifdef'd out:

    #include DBM_INCLUDE

where the C compiler does not allow macros to name include files.
This does cause any problems when compiling on Interactive, beyond the
generation of the above messages.  If your compiler really bombs out,
remove the offending lines from util/dbm_compat.h.


SUPPORT FOR JANET MAIL

Smail now contains limited support for JANET mail (the reverse-order
domain system used in the United Kingdom).  Complete support is
available from Philip Hazel <[e-mail]>.  The smail3
distribution provides only those hooks that must be in the smail
binary itself.  Send mail to Philip for more information.  If you
are not in the UK, please ignore this paragraph: you don't want to
know.


FUTURE SMAIL3 RELEASES

A preliminary version of the much-mentioned (in the past) Smail3.2
release now exists, thanks to the efforts of Chip Salzenberg.  However,
it has a lot of work to go.  If anybody would like to take on the large
task of making smail a leaner, cleaner, and more adaptable program,
please let me know.  If nobody ever comes forward, then I will probably
have to consider the 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 mail.


GENERAL ACKNOWLEDGEMENTS

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 <[e-mail]> 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.


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 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.  The compiled-in configuration can be found in samples/generic.


SMAIL ON THE INTERNET (VERY IMPORTANT FOR INTERNET USERS)

Users on the Internet should configure smail to use the Domain Name
Service for routing on the Intenet.  The compiled-in default routers
for smail define the use of the gethostbyname library call, which
does not support MX records.  To use the DNs, you will have to have
the bind resolver library, and you will have to tell smail that you
have it.  For some systems, these are configured into smail by
default.   For other systems, you will need to configure in the bind
router driver by modifying the EDITME file.  This involves setting
DRIVER_CONFIGURATION=arpa-network, and adding BIND to the HAVE list.
See the EDITME file in the conf directory for more details.

The compiled-in routers list does not define use of the bind router
driver, even if you configure it in from the EDITME file.  To actually
use the bind router driver, you will need to create a routers file and
change the inet_hosts router to use the bind router driver, rather
than the gethostbyname router driver.  Start by copying the file
samples/generic/routers to the /usr/lib/smail directory and modify it
by commenting out the first inet_hosts router definition, and
uncommenting the second one (which defines use of the bind router
driver).  See the routers file for more information.

It is likely that you will also want the various smtp transports to
use the bind resolver library, for smtp references matched by method
files, or through any means other than use of the bind version of the
inet_hosts router.  To do this, copy samples/generic/transports to the
/usr/lib/smail directory and enable the use_bind attribute for all of
the tcpsmtp-based transports, as suggested at the top of the file.


SMAIL AND SYSTEM V

System V systems typically have a /bin/mail program that both delivers
mail and reads mail.  Smail provides a replacement for the /bin/mail
program, in pd/binmail, that uses the old /bin/mail for reading mail,
and smail for delivering mail.  To use the replacement /bin/mail, you
will need to define the LMAIL variable in conf/EDITME.  See
conf/EDITME for more instructions.

The System V mailx utility will need to be updated to know how to find
smail.  Presuming that smail is installed as /usr/lib/sendmail, you
will need to add the following line to the file /usr/lib/mailx/mailx.rc:

    set sendmail=/usr/lib/sendmail


SMAIL AND SCO UNIX

Smail under SCO UNIX should be installed as both /bin/mail and
/usr/lib/mail/execmail.  To do this, set OTHER_SMAIL_NAMES in the
EDITME file to "/bin/rmail:/usr/lib/mail/execmail".  You will also
need to use the /bin/mail replacement in pd/binmail, just as in
System V.  Some newer SCO UNIX systems also have a /usr/bin/rmail, as
a link to /usr/bin/mailx.  This file should be deleted.

Some versions of SCO UNIX store mail messages in /usr/spool/mail,
while others use /usr/mail, like System V.  If your system uses
/usr/spool/mail, you will need to add the following line to the
conf/EDITME file:

    MAILBOX_DIR=/usr/spool/mail

Current SCO releases use MMDF mailbox file formats.  Many users prefer
to use public domain mail readers, such as elm or mush, that can be
configured to use regular UNIX mailbox files.  Users that wish to be
compatible with the MMDF mailbox file format must create a transports
file that configures a prefix of "\1\1\1\1" to insert before each
message stored in mailbox files.  Copy the file
samples/generic/transports to the /usr/lib/smail directory, and modify
it as suggested at the top of the file.

The SCO MMDF version of mailx supplies its own From: line using a
hostname taken from an MMDF configuration file.  I have no idea why
they decided it was a good idea to hard-code the hostname in a
configuration file, but they did.  Thus, if you change your hostname,
your From: lines won't change until you change the MMDF configuration
file.  To correct the From: line change the MLDOMAIN and MLNAME
definitions in /usr/mmdf/mmdftailor.

To get the MMDF-ified SCO to call smail from /bin/mail and mailx,
add the line:

    set execmail

to the file /usr/lib/mail/mailrc.


SMAIL AND SYSTEM V RELEASE 4

The SVR4 mailbox file format defines a Content-Length field that
indicates the length of each message, in bytes.  This obviates the
need for inserting > before lines beginning with "From" (and indeed,
there are some problems with the AT&T-supplied version of mailx
concerning message splitting, if you don't use Content-Length).  Smail
can be configured to generated Content-Length fields (and Content-Type
fields).  However, the compiled-in transports cannot do this.  To
configure generation of these fields, copy the file
samples/generic/transports to the /usr/lib/smail directory, and modify
it as suggested at the top of the file.

In the SVR4 uux command, message grades are supplied using long names,
which differs from older versions of HoneyDanBer UUCP, where message
grades were a single character.  Smail does not support these longer
names.  Fortunately, you can configure SVR4 to support single
character message grades.  To make SVR4 compatible with smail, add the
following lines to your /etc/uucp/Grades file:

9    9    Any    User    Any
A    A    Any    User    Any
C    C    Any    User    Any
a    a    Any    User    Any
n    n    Any    User    Any

This list is sufficient for the default list of Precedence header
field values supported by smail.

It is possible to configure an SVR4 system to call smail by replacing
the file /etc/mail/mailsurr with the line:

    '(.+)'    '(.+)'    '< /usr/local/smail/bin/smail -em -i \\2'

This works, but it has the annoying side effect of invoking smail
multiple times for each address given as an argument to /bin/mail or
/bin/rmail.  It is preferable to replace /bin/rmail with smail, and to
replace /bin/mail with the mail program supplied in pd/binmail.

To configure SVR4 to use smail for handling SMTP, move the file
/etc/rc2.d/S88smtpd to /etc/rc2.d/no-S88smtpd, move the file
/etc/rc0.d/K74smtpd to /etc/rc0.d/no-S74smtpd, and then add a new file
/etc/rc2.d/S88smail containing:

    /usr/lib/sendmail -bd -q30m

Then, kill any existing smtpd program and start smail by executing the
above command.

To convert an SVR4.2 system create the same file above, remove the
smtpd entry in /etc/inetd.conf, then execute the following commands:

    sacadm -k -p inetd
    sacadm -s -p inetd
    /usr/lib/sendmail -bd -q30m


SMAIL AND 4.3BSD OR ULTRIX

Some versions of Ultrix, plus stock 4.3BSD, have had problems in
recent releases with some shell scripts supplied with smail.  I have
made some attempts to simplify the offending shell scripts to avoid
problems.  However, if errors are still encountered with /bin/sh, then
use a different shell, such as ksh, pdksh, or bash, by compiling and
installing smail with commands like:

    make SHELL=/bin/ksh depend
    make SHELL=/bin/ksh all
    make SHELL=/bin/ksh install

Some problems have also been reported with /bin/sh on Xenix.  I don't
know if there is an alternate shell available on Xenix.  However,
pdksh should compile and run there.  I realize that it seems absurd
that regular /bin/sh cannot be used on some systems.  Hopefully the
specific problems encountered can be found and remedied for future
releases.


PATCHES

Patches may be made available in the future.  These will be announced
in comp.mail.uucp, and in the various mailing lists.  Patches will be
made available on uunet, and on other archive sites, which are announced
along with each patch.


BUGS AND COMMENTS

Please send bug reports or fixes to:

    [e-mail]
ARPA:    veritas![e-mail]
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:

    [e-mail]

There are now two discussion lists maintained by Lyndon Nerenberg,
[e-mail]: smail3-users and smail3-wizards.  To
subscribe send mail to:

    [e-mail]

I do not have any connection with this list, other than the fact that
I maintain the software that it discusses.  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.  Of
course, most patches that I send out are 100K or more, so perhaps I
shouldn't complain too much.
--
       Ronald S. Karr        ARPAnet:  veritas![e-mail]
      [e-mail]        UUCPnet:  {apple,pyramid,uunet}!veritas!tron