X-Git-Url: https://git.exim.org/users/jgh/exim.git/blobdiff_plain/17af4a1772521e9a4174c37cc6aaa311003ad7cd..2d2b05f476c12d85519b3bf8997585c8631004da:/doc/doc-txt/ChangeLog?ds=sidebyside

diff --git a/doc/doc-txt/ChangeLog b/doc/doc-txt/ChangeLog
index 67a455b22..99e28d07a 100644
--- a/doc/doc-txt/ChangeLog
+++ b/doc/doc-txt/ChangeLog
@@ -1,4 +1,4 @@
-$Cambridge: exim/doc/doc-txt/ChangeLog,v 1.419 2006/10/31 09:50:09 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
 -------------------------------------------
@@ -217,6 +217,36 @@ PH/30 Exim was sometimes attempting to deliver messages that had suffered
            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
 -----------------