X-Git-Url: https://git.exim.org/users/jgh/exim.git/blobdiff_plain/929ba01ccb7fafbe89e4fa60e93ab2b5f4aab1df..30dba1e609d941013dc8421de5104dad387ac5b1:/doc/doc-txt/NewStuff

diff --git a/doc/doc-txt/NewStuff b/doc/doc-txt/NewStuff
index 7627fb7f9..04fedd633 100644
--- a/doc/doc-txt/NewStuff
+++ b/doc/doc-txt/NewStuff
@@ -1,4 +1,4 @@
-$Cambridge: exim/doc/doc-txt/NewStuff,v 1.88 2006/02/21 16:24:19 ph10 Exp $
+$Cambridge: exim/doc/doc-txt/NewStuff,v 1.91 2006/02/28 11:25:40 ph10 Exp $
 
 New Features in Exim
 --------------------
@@ -69,6 +69,35 @@ PH/10 When compiled on FreeBSD, NetBSD, or BSD/OS, the pipe transport has a new
       uid under which the pipe is to run are obtained from the login class
       database.
 
+PH/11 If retry_interval_max is set greater than 24 hours, it is quietly reset
+      to 24 hours. This avoids potential overflow problems when processing G
+      and H retry rules, and it seems reasonable to require a retry at least
+      once a day.
+
+PH/12 When the plaintext authenticator is running as a client, the server
+      challenges are now checked to ensure they are valid base64 strings. The
+      default action on failure is to abort the authentication. However, if
+      client_ignore_invalid_base64 is set true, invalid responses are ignored.
+
+PH/13 When the plaintext authenticator is running as a client, the challenges
+      from the server are placed in $auth1, $auth2, etc. as they are received.
+      Thus, the challege that is received in response to sending the first
+      string (with the AUTH command) can be used in the expansion of the second
+      string, and so on. Currently, up to 3 challenge strings are available in
+      this way. If an invalid base64 string is received when client_ignore_
+      invalid_base64 is set, an empty string is put in the $auth<n> variable.
+
+PH/14 Messages created by the autoreply transport now contain a References:
+      header. This is constructed in accordance with rules that are described
+      in section 3.64 of RFC 2822, which states that replies should contain
+      such a header line, and section 3.14 of RFC 3834, which states that
+      automatic responses are not different in this respect. However, because
+      some mail processing software does not cope well with very long header
+      lines, no more than 12 message IDs are copied from the References: header
+      line in the incoming message. If there are more than 12, the first one
+      and then the final 11 are copied, before adding the message ID of the
+      incoming message.
+
 
 Version 4.60
 ------------