Dream 57/Amiga_Dream_57.iso/Linux/Net/smail-3.2.0.103-README.FIRST

Text File | 1998-10-15 | 5KB | 100 lines

Fri Oct  9 14:54:11 EDT 1998 - (Greg A. Woods) [e-mail]

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