Exim version 4.12
-----------------

 1. Update to change 4.11/82: for the max number of processes, set
    RLIM_INFINITY if it is defined.

 2. An expansion ${run{xxx}} where xxx was a successful command that produced
    no output caused Exim to crash.

 3. Some artificial delays of 1 second existed when running in the test
    harness, to ensure repeatability of debugging output. Now that we have
    the millisleep() function, these can be shorter.

 4. Change 4.11/30 below overlooked the case when an address gets a 4xx
    response from a server. Because this isn't a host problem, the host does
    not get delayed, and it gets tried every time the address is OK'd for
    routing, with the same reponse. However, if hosts_max_try is set, because
    not all the hosts were tried, the address does not time out. I've changed
    things so that if there is a 4xx response to a RCPT command, the host in
    question does not count towards hosts_max_try if the message is older than
    the host's maximum retry time. This means that other hosts are always tried
    in this circumstance; if the address gets 4xx errors from all of them, it
    will eventually time out.

 5. If a retry rule for a host had no actual retry times specified, it could
    cause a crash when checking the ultimate address timeout. (Very old bug,
    spotted in passing, so probably never bothered anybody.)

 6. Change 135 below broke the following scripts when a list of configuration
    files was given: exicyclog, exim_checkaccess, eximon, exinext, and exiwhat.
    In practice, if exim_path was not specified in the configuration file (a
    common case), things would probably work OK. However, the use of
    CONFIGURE_FILE_USE_NODE definitely did not work. These scripts have now
    been updated to fix this problem. They now search for the configuration
    file in the same way Exim itself does: for each name in the list, the
    "noded" file is tried first, then the unsuffixed file.

 7. If a WARN verb in an ACL did not specify an explicit "message" modifier,
    and was triggered by a failing sender or recipient verification, the
    response that would have been sent as an SMTP message for a DENY verb was
    incorrectly being added to the message's headers.

 8. I screwed up change 4.11/155. For lookup types whose names were prefixes of
    other lookup types (e.g. nis and nisplus, dbm and dbmnz), the new search
    function didn't do the correct comparison, meaning that the wrong lookup
    type could be found.

 9. Solaris seems to be one of the LDAPs that doesn't have the lud_scheme
    member of the LDAPURLDesc structure. Since the check that is made on it
    is only to double check that a path is given for ldapi, I've just removed
    the test in the Solaris case.

10. The modified TextPop.c source in the Exim monitor had declarations of errno
    and sys_nerr which never were actually referenced. The second of these
    caused trouble on Darwin, so I've removed both of them. Why were they
    there? Who knows? This is ancient X code...

11. The DEFER ACL verb crashed if no "message" modifier was set.

12. The check on incoming messages that gives the error "too many non-mail
    commands" was too strict. In the case of Exim sending to Exim, when the
    client has queued messages for the server and is using TLS, it will close
    and re-initialize TLS between messages (because the client has to hand the
    SMTP connection to a new process). STARTTLS was being counted as a non-mail
    command, and therefore could cause the limit to be hit. The revised code
    now allows for one RSET, one HELO or EHLO, and one STARTTLS between each
    message without counting them as non-mail commands. (One RSET was
    previously allowed - I *had* spotted that case.)

13. Some log lines for rejections by ACL were putting ident values in
    parentheses instead of using U= after H=. (There are some other lines that
    do use parens, typically when the host name appears without H= within a
    message. This whole area could perhaps do with tidying up.)

14. When processing a redirection file happens in a subprocess (typically so
    that a .forward file is processed as the user), Exim was assuming that a
    call to wait() would always reap the subprocess, and it was failing to
    check the result. In theory, a signal of some sort occurring at the wrong
    time could break this assumption - the process was then left unreaped, and
    could possibly be picked up later during deliveries, thus confusing that
    code ("processes got out of step"). This is conjecture - I haven't got a
    definite test of this. However, I have fixed the code to repeat the wait
    after a signal.

15. When Exim was waiting for a remote delivery subprocess, and the waitpid()
    call found a process that was not in the list of remote delivery processes,
    Exim gave up waiting for remote processes. It is probably better just to
    ignore the unexpected process (though, of course, write to the main and
    panic logs) and to wait for another process, and so that is what now
    happens. If the error situation is caused by failed waiting logic for
    routing or local delivery processes, this approach will minimize bad
    behaviour, I hope.

****