Fri Oct 9 14:54:11 EDT 1998 - (Greg A. Woods) woods@planix.com This BETA release of smail fixes yet more of bugs in major changes from the last few betas. If everyone likes this beta as much as I do, then I'm very close to actually calling what's done to date the 3.2.1 release. See the README for what might happen after that! ;-) The 'newaliases' or 'sendmail -bi' invocation of mkaliases now works even better and copies stdout and stderr to the user. Various improvements in mkaliases and its tools should help with debugging problems with alias files. The address routing/resolving bugs people were tripping over (and in particular the emergency .102 patch Jim Mercer helped me with) have been fixed, hopefully for good. Some buggy DEBUG messages in smtprecv.c have hopefully been fixed. Handling of DNS errors has been improved. Runq will no longer fork if given only one message to process, which makes it easier to run under the debugger. Even though I just read the full diffs I've probably missed something else. I finally broke down and added a 'smtp_recipient_no_verify' config variable, which can be a list ala smtp_remote_allow. It completely disables RCPT TO verification for addresses in the list. This obviously also implies mail can be relayed to remote sites from hosts approved by this list (i.e. it extends smtp_remote_allow), so be *careful* with it! This should help some folks stuck with extremely broken MTAs trying to send through a smail gateway (Novell Groupwise comes to mind). In relation to this I've also fixed a bug where smail would continue to accept a DATA command after giving a 450 reply to a RCPT TO. This violates the SMTP protocol, but until Andreas Wrede ran into a Groupwise server that ignored the 450 reply and sent a DATA command anyway, the bug was invisible because every other MTA in the world seemed to obey the 450. Unfortunately Groupwise does take note of the 450 as well as sending the message, which meant that when talking to smail it would result in an infinite number of duplicate deliveries (at least until the 450 was no longer returned!). Some more minor fixes and updates have been made to the documentation (i.e. the manual pages -- the guide still languishes in staleness). I've included in the contrib sub-directory a patch to TCP Wrappers that will allow generic implementation of RBL-style connection filtering. But I cannot find reference to the aforementioned RBL-like map listing many ISP dial-up ports which I claimed existed, though I do have a fairly good list of said IP#s and am thinking of creating such a zone and/or asking Paul Vixie to entertain the idea of doing so for MAPS. (This patch has also been sent to Wietse Venema and to various people who have developed similar but more limited patches.) The most up-to-date version of this patch will be available at the following URL, should I ever find need to update it (one change I'm thinking of is to retrieve the TXT record, if any, and include it in any syslog message, though this is more boring than I thought it would be rather boring for those in rbl.maps.vix.com, and would imply adding some hook in smail to turn on syslog() for hosts_access().). ftp://ftp.weird.com/pub/local/tcp_wrappers-rbl-patch Unfortunately there's no way at the moment (without prying into the innards of libwrap) of distinguishing between an ordinary denial and one that's the result of an RBL-like lookup. I've also included in the contrib directory a copy of Jim Mercer's patch for direct RBL implementation in smail. This gives a much more meaningful reply to the remote sender than the generic TCP Wrappers "You are not permitted to send mail" error, but Jim's patch only allows one RBL-like domain for now, and I'm not sure I want RBL support directly in smail when it can be put in TCP Wrappers (just the same as there's no generic connection blocking support directly in smail). Note that Jim's patch is "reversed", and is based on 3.2.0.101. Jim has sent me one more patch to separate out control of the outgoing socket binding from the 'listen_name' setting to 'sending_name'. This will prevent the system from choosing what it thinks is the most "appropriate" source address for the outgoing connection, which with virtual hosts, firewalls, and all, can be an important issue. This patch is *not* yet included in any fashion (I will be happy to forward it to anyone for the time being), but I'm thinking of integrating it before 3.2.1. Everyone can express their opinions if they'd like.... See the CHANGES file for further information. Note that the anti-relay feature is still not yet compatible with UUCP gateways (this is also mentioned by a warning note in the CHANGES file). As always the ToDo and PROJECTS files list a growing number of things that various people think should be worked on. Patches that eliminate items from these files are always welcome! If you'd like to work on any of the bigger projects just send a note to and let us know so we can help co-ordinate and possibly give you access to the CVS repository. See the README and the file Smail3-devel 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 there's a new manual page for it too.)