-$Cambridge: exim/doc/doc-txt/ChangeLog,v 1.416 2006/10/24 15:01:25 ph10 Exp $
+$Cambridge: exim/doc/doc-txt/ChangeLog,v 1.425 2006/11/06 15:50:12 ph10 Exp $
Change log file for Exim from version 4.21
-------------------------------------------
Exim version 4.64
-----------------
+TK/01 Bugzilla #401. Fix DK spooling code so that it can overwrite a
+ leftover -K file (the existence of which was triggered by #402).
+ While we were at it, introduced process PID as part of the -K
+ filename. This should rule out race conditions when creating
+ these files.
+
+TK/02 Bugzilla #402. Apply patch from Simon Arlott, speeding up DK signing
+ processing considerably. Previous code took too long for large mails,
+ triggering a timeout which in turn triggers #401.
+
+TK/03 Introduced HAVE_LINUX_SENDFILE to os.h-Linux. Currently only used
+ in the DK code in transports.c. sendfile() is not really portable,
+ hence the _LINUX specificness.
TF/01 In the add_headers option to the mail command in an Exim filter,
there was a bug that Exim would claim a syntax error in any
headers of the same name were present, leading whitespace was being
removed from all of them, but trailing whitespace was being removed only
from the last one. Now trailing whitespace is removed from each header
- before concatenation.
+ before concatenation. Completely empty headers in a concatenation (as
+ before) are ignored.
PH/28 Fixed bug in backwards-compatibility feature of PH/09 (thanks to John
Jetmore). It would have mis-read ACL variables from pre-4.61 spool files.
+PH/29 [Removed. This was a change that I later backed out, and forgot to
+ correct the ChangeLog entry (that I had efficiently created) before
+ committing the later change.]
+
+PH/30 Exim was sometimes attempting to deliver messages that had suffered
+ address errors (4xx response to RCPT) over the same connection as other
+ messages routed to the same hosts. Such deliveries are always "forced",
+ so retry times are not inspected. This resulted in far too many retries
+ for the affected addresses. The effect occurred only when there were more
+ hosts than the hosts_max_try setting in the smtp transport when it had
+ the 4xx errors. Those hosts that it had tried were not added to the list
+ of hosts for which the message was waiting, so if all were tried, there
+ was no problem. Two fixes have been applied:
+
+ (i) If there are any address or message errors in an SMTP delivery, none
+ of the hosts (tried or untried) are now added to the list of hosts
+ for which the message is waiting, so the message should not be a
+ candidate for sending over the same connection that was used for a
+ successful delivery of some other message. This seems entirely
+ reasonable: after all the message is NOT "waiting for some host".
+ This is so "obvious" that I'm not sure why it wasn't done
+ previously. Hope I haven't missed anything, but it can't do any
+ harm, as the worst effect is to miss an optimization.
+
+ (ii) If, despite (i), such a delivery is accidentally attempted, the
+ routing retry time is respected, so at least it doesn't keep
+ hammering the server.
+
+PH/31 Installed Andrew Findlay's patch to close the writing end of the socket
+ in ${readsocket because some servers need this prod.
+
+PH/32 Added some extra debug output when updating a wait-xxx database.
+
+PH/33 The hint "could be header name not terminated by colon", which has been
+ given for certain expansion errors for a long time, was not being given
+ for the ${if def:h_colon_omitted{... case.
+
+PH/34 The spec says: "With one important exception, whenever a domain list is
+ being scanned, $domain contains the subject domain." There was at least
+ one case where this was not true.
+
+PH/35 The error "getsockname() failed: connection reset by peer" was being
+ written to the panic log as well as the main log, but it isn't really
+ panic-worthy as it just means the connection died rather early on. I have
+ removed the panic log writing for the ECONNRESET error when getsockname()
+ fails.
+
+PH/36 After a 4xx response to a RCPT error, that address was delayed (in queue
+ runs only) independently of the message's sender address. This meant
+ that, if the 4xx error was in fact related to the sender, a different
+ message to the same recipient with a different sender could confuse
+ things. In particualar, this can happen when sending to a greylisting
+ server, but other circumstances could also provoke similar problems.
+ I have changed the default so that the retry time for these errors is now
+ based a combination of the sender and recipient addresses. This change
+ can be overridden by setting address_retry_include_sender=false in the
+ smtp transport.
+
Exim version 4.63
-----------------
git://git.exim.org / users / heiko / exim.git / blobdiff