X-Git-Url: https://git.exim.org/users/heiko/exim.git/blobdiff_plain/8c8415232d289e3dcef4b06bc9a69b704813494f..c5ddb310a1f89a0560eea67879921570b046b179:/doc/doc-txt/ChangeLog diff --git a/doc/doc-txt/ChangeLog b/doc/doc-txt/ChangeLog index 496ba5943..d5c658131 100644 --- a/doc/doc-txt/ChangeLog +++ b/doc/doc-txt/ChangeLog @@ -1,4 +1,4 @@ -$Cambridge: exim/doc/doc-txt/ChangeLog,v 1.102 2005/03/29 11:01:32 ph10 Exp $ +$Cambridge: exim/doc/doc-txt/ChangeLog,v 1.110 2005/04/05 14:33:27 ph10 Exp $ Change log file for Exim from version 4.21 ------------------------------------------- @@ -90,6 +90,66 @@ PH/15 Further to TK/02 and TK/03 above, tidied up the tables of what conditions PH/16 Installed updated OS/os.c-cygwin from the Cygwin maintainer. +PH/17 The API for radiusclient changed at release 0.4.0. Unfortunately, the + header file does not have a version number, so I've had to invent a new + value for RADIUS_LIB_TYPE, namely "RADIUSCLIENTNEW" to request the new + API. The code is untested by me (my Linux distribution still has 0.3.2 of + radiusclient), but it was contributed by a Radius user. + +PH/18 Installed Lars Mainka's patch for the support of CRL collections in + files or directories, for OpenSSL. + +PH/19 When an Exim process that is running as root has to create an Exim log + file, it does so in a subprocess that runs as exim:exim so as to get the + ownership right at creation (otherwise, other Exim processes might see + the file with the wrong ownership). There was no test for failure of this + fork() call, which would lead to the process getting stuck as it waited + for a non-existent subprocess. Forks do occasionally fail when resources + run out. I reviewed all the other calls to fork(); they all seem to check + for failure. + +PH/20 When checking for unexpected SMTP input at connect time (before writing + the banner), Exim was not dealing correctly with a non-positive return + from the read() function. If the client had disconnected by this time, + the result was a log entry for a synchronization error with an empty + string after "input=" when read() returned zero. If read() returned -1 + (an event I could not check), uninitialized data bytes were printed. + There were reports of junk text (parts of files, etc) appearing after + "input=". + +PH/21 Added acl_not_smtp_mime to allow for MIME scanning for non-SMTP messages. + +PH/22 Added support for macro redefinition, and (re)definition in between + driver and ACL definitions. + +PH/23 The cyrus_sasl authenticator was expanding server_hostname, but then + forgetting to use the resulting value; it was using the unexpanded value. + +PH/24 The cyrus_sasl authenticator was advertising mechanisms for which it + hadn't been configured. The fix is from Juergen Kreileder, who + understands it better than I do: + + "Here's what I see happening with three configured cyrus_sasl + authenticators configured (plain, login, cram-md5): + + On startup auth_cyrus_sasl_init() gets called for each of these. + This means three calls to sasl_listmech() without a specified mech_list. + => SASL tests which mechs of all available mechs actually work + => three warnings about OTP not working + => the returned list contains: plain, login, cram-md5, digest-md5, ... + + With the patch, sasl_listmech() also gets called three times. But now + SASL's mech_list option is set to the server_mech specified in the the + authenticator. Or in other words, the answer from sasl_listmech() + gets limited to just the mech you're testing for (which is different + for each call.) + => the return list contains just 'plain' or 'login', 'cram-md5' or + nothing depending on the value of ob->server_mech. + + I've just tested the patch: Authentication still works fine, + unavailable mechs specified in the exim configuration are still + caught, and the auth.log warnings about OTP are gone." + A note about Exim versions 4.44 and 4.50 ----------------------------------------