**** VERY IMPORTANT NOTICE! This release has unfortunately had several **** unofficial appearances. Any copy dated earlier than 2005/11/17 is **** invalid. A heap-based buffer overflow has been discovered in the nether regions of Smail -- it's in some "be liberal in what you accept" code that's been hanging about unchanged since before 1992. The problem was reported to BUGTRAQ and has now made the rounds at many software security sites. http://www.securityfocus.com/archive/1/394286 Initially I didn't think it could be exploited, but I didn't realize just how easy it is to foil free() in some systems, to the point of being able to convince it to overwrite any address with as much as four bytes of user-supplied data, and this particular overflow was directly in line with another buffer and an imminent free() call. A limited exploit has also been released -- it only affects platforms using the "Doug Lea" Malloc, such as most GNU/Linux platforms, and it only works as released on i386 systems, and only on systems with executable heaps, and only for those with enough skills and knowledge about the target environment to discover the exact addresses and alignments needed to drive the exploit. http://www.securityfocus.com/archive/1/394413 In theory it is possible to exploit the PHK malloc() used in *BSD systems, but that's a very _much_ more complex problem for the attacker to solve. (Apparently the SysV malloc(), i.e. the one in Solaris and modern IRIX, should also be exploitable, perhaps even as easily as implementations based on Doug Lea's malloc().) The fixes included in this release not only terminate the unterminated buffer that allowed the overflow, but also adds further protection against allowing arbitrary binary data from remote clients -- only ASCII, as per RFC [2]821 (except the NUL), will be accepted in SMTP commands from now on! This release also cleans up a few other minor bugs and issues from the past few test releases. I've eliminated the linear search through all user accounts entries just to do a case-insensitive comparision. Those who want case-insensitive e-mail addresses to work will just have to live with the fact that system usernames will have to be all lower-case. If you don't want all-lowercase usernames then you _MUST_ have exact case-matched mailboxes. Period. This is especially critical on systems which use, or even may use, remote databases for user accounts since even the possibility often results in a system call (e.g. even a stat("/etc/nsswitch.conf")) between every getpwent() call. The former "smtp_hello_reject_dns_paranoid" config flag (which was first introduced in the 3.2.0.112 release) has been renamed to now be called "smtp_hello_reject_broken_ptr" in hopes of better reflecting its true meaning (check your paniclog after testing to look for warnings about deprecated config attributes, etc.). The logic for handling the greeting name verification has been reworked as well to avoid unnecessary DNS lookups if possible. See the smailconf(5) manual for further details. Address local parts are now properly validated for strict RFC-2822 compliance so that Smail doesn't have to end up bouncing messages that the likes of Cyrus IMAP won't accept as valid. Domain-parts are also more strictly and consistently validated. Bounce messages that were missing a From: header now use an empty group instead of filling in thus hopefully accepting less blame for other people's errors. The old "apparently-to:" nonsense is also gone -- sendmail changed it's default way of handling missing "to:" headers some time ago. Several other places where an un-qualified "MAILER-DAEMON" was being abused are also corrected. Signal handling has been modernized -- SIGHUP actually reloads the config files by restarting the daemon process the next time it goes round its main loop (which will normally be immediately as even when waiting for new connections the current system call will be interrupted and return EINTR) and tells all the child processes to only finish the immediate processing stage they are in (e.g. sets queue_only for incoming messages); and SIGTERM now properly kills all the child processes immediately, but safely. Message input is also now robust against accidental failure (requiring resend) on EINTR, and empty messages (no headers even) are properly handled too. A serious bug in SMTP RSET handling has been fixed, and in the process of working out the correct fix I discovered that many PC virus checkers will send RSET instead of NOOP every five seconds or so while they scan outbound messages. Many log messages (especially warnings and errors during SMTP processing) are now much more consistent in the syntax used to identify the remote client. The oddities of ${strip: are better documented and it is no longer used in default command-line settings. (It should be ${make_filename: or similar as that's really what it does.) True 95'th (and 99'th) percentile calculations are now done in logsumm for message sizes since the distribution of sizes on the average machine never comes even close to matching a normal bell-shaped Gaussian curve and thus the estimated 95'th percentile was always way off. The estimate is still shown for comparison. DNS blacklists that take too long to resolve will now be logged in the paniclog file. There's also a new command-line mode to test them: "smail -v9 -bD smtp_rbl_domains 127.0.0.2" (using a domain name instead of an IP address of course for domain-based lists). An experimental feature similar to the new "sleep" restriction parameter in Postfix-2.3, and the "greet_pause" feature new in Sendmail-8.13 has been implemented to reduce the common abuse by nasty worms, viruses, and spambots which don't wait for the 220 (or whatever) greeting banner. The trusted_users and trusted_groups attributes can now be used to restrict command-line sender addresses. Getting this working revealed numerous minor bugs hidden away in old and new code, such as an off-by-one error that was clobbering the opening '!' in the in-core copy of a spool file (and thus also damaging the stored local_sender value). The SMTP MAIL and RCPT commands now identically validate their parameters and ESMTP options, and they will properly reject commands with unsolicited options too. (Some mailers were sending DSN options even though Smail doesn't advertise ESMTP DSN support. The RFCs say such transgressions should result in rejecting the transaction.) It is now more difficult than ever to accientally get Smail running with an empty $primary_name. Empty entries are ignored in the hostnames and domains lists, and whitespace at the beginning and end of entries is stripped off before comparing values. The return_path_field config attribute is now deprecated -- the RFCs don't give enough leniency on it's valut to make it worth being configurable. A new $return_addr expansion variable is introduced to make available the same envelope address in pipe commands, etc. that would be used in SMTP connections, etc., and presentation of the return address had been made more uniform so that the *_xform flags have the same effect in hopefully all the right places. Fewer silly user-generated bounces are copied to the postmaster. Bogus (empty) message-id fields are deleted (and logged) to make Cyrus happy. A full ChangeLog of all CVS commit messages since the 3.2.0.120 release is included in the distribution for your entertainment and amazement. :-) The best way to find out just the user-visible changes in this or any other release might be to read the CHANGES file from the version you're using now and then read the new CHANGES file and see what's different (an actual "diff", even with '-b', may not work very well because of paragraph re-formatting, but it may give you a head start on where to actually read for the differences). Before installing the new version in a production system you should also first dump the full run-time configuration from and compare that to your existing installation's configuration. (i.e. save the output from "src/smail -v -bP all" and visually compare that to the same output from the existing installation -- if you want to use "diff" you may have to edit one or the other and re-sort both to give them the same format and ordering) If you're upgrading a pre-3.2.0.116 installation you may want to flush your input queue and clean out your error queue before installing. This is because the per-message log format changed in the previous release. The old format won't break anything, though bounce messages from any eventually undeliverable old messages may not include all the right details. As always be very careful to test the new release in your environment before committing to it! Once again this release has been very carefully and extensively tested in a variety of busy environments. It is expected that with only minor fixes and portability adjustments it will very soon become the next new full official release (which will be known as 3.3). However more testing and experience in different environments is always welcome, so if you can possibly install and use this beta release and report your results then that will help us make an even better official release. One thing's for certain, the release process is getting easier (see the mkRelease.sh script), and of course it's always less arduous the less there is that has changed since the last release, so provided there's new code to release, releases of some sort will hopefully be more frequent in the future. Note for users of pkgsrc/ports/openpkg style systems: There's a pkgsrc module for the latest available here: ftp://ftp.weird.com/pub/local/smail/smail-pkgsrc.shar ftp://ftp.planix.com/pub/Smail/smail-pkgsrc.shar It will be udated to include any critical bug fix patches if and when necessary -- i.e. before a proper release including the same fixes is available. Watch the smail3-users list for notices about such updates. As always the ToDo and PROJECTS files list an ever-growing number of things that various people think should be worked on. Patches that eliminate items from these files are always welcome! If you would like to work on any of the bigger projects just send a note to the developers at and let us know so we can help co-ordinate. See the README and the file Smail3-devel for more information. If you need help with configuration issues, or you'd like to discuss some feature or bug, etc., please subscribe to the Smail-3 User's Mailing list . To subscribe to this list send your request to . Note I do not have any direct connection with this list, other than the fact that I maintain the software discussed on it. See the README file for more information. Remember to use the "smailbug" utility to submit patches, change requests, bug reports and other stuff that needs to be recorded so it won't get lost or forgotten! (There's now a symlink installed in the smail_bin_dir to make it easier to access this script, and of course there's a manual page for it too.) For further information please visit the Smail world-wide web page: