4.64 TK/01-03
[exim.git] / doc / doc-txt / ChangeLog
index e1fdcff03d81d70c993d16e6ddbce4d5bfe85687..08e7d48378e1f2371ee07fd1478cce1a464e61f7 100644 (file)
@@ -1,10 +1,23 @@
-$Cambridge: exim/doc/doc-txt/ChangeLog,v 1.415 2006/10/24 14:32:49 ph10 Exp $
+$Cambridge: exim/doc/doc-txt/ChangeLog,v 1.418 2006/10/30 22:22:50 tom 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
@@ -170,7 +183,41 @@ PH/27 In a string expansion for a processed (not raw) header when multiple
       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 After an address error (typically a 4xx response from a server), Exim
+      always tries the failing address if it appears in a new message, but
+      respects the retry time otherwise. This was implemented by checking for
+      being in a queue run, which isn't quite right. Now it checks the
+      "first_delivery" flag instead.
+
+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.
 
 
 Exim version 4.63