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 . 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 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: 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 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!tron@apple.com tron@veritas.com UUCPnet: {apple,pyramid,uunet}!veritas!tron