-$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.106 2005/03/29 15:53:12 ph10 Exp $
Change log file for Exim from version 4.21
-------------------------------------------
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=".
+
A note about Exim versions 4.44 and 4.50
----------------------------------------
git://git.exim.org / users / heiko / exim.git / blobdiff