-$Cambridge: exim/doc/doc-txt/ChangeLog,v 1.418 2006/10/30 22:22:50 tom 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
-------------------------------------------
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/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
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 / exim.git / blobdiff