SSL CTXs should be created after the SSL library initialization, and be
kept until program termination.
Also, TLS version 1.1 and 1.2 are now supported for secure connections.
The serial number of the certificates is checked together with the
issuer, since some certificates have the same subject and issuer but a
different serial number.
Also, the certificate subject, issuer and serial number are also written
to the certificates file just before the certificate itself, in order to
make it easier to distinguish each certificate in the file.
At least one server, returns a continuation response to the APPEND
request, even if the APPEND request then finally fails (because the
mailbox doesn't exist). Anticipate such an occurrence, and try to
create the mailbox and retry the APPEND, as is done normally.
The namespace of the selected mailbox was not properly applied after
recovery, CRAM-MD5 authentication during the recovery would fail, and
searching after recovery could fail in some cases.
Some servers send responses that are not standards compliant, but
contain extra SPACE, CR or LF characters, and by ignoring those
characters it might be possible to parse their responses.
A persistent failure that could lead to a session not being able to be
recovered, or a failure during the login process (which is not covered
by the recovery function), would normally cause the process to
terminate. This is expected when the configuration is run once, but not
desirable when running in daemon mode.
And thus just after the process has become a daemon, a session that
could not be restored, either because the connection to the server could
not be established or the login and its related negotiations failed, is
now disabled temporarily, and a recoqnection is attempted at the
beginning of the next daemon loop iteration.
There is one exception to that, and that is when there is an
authentication error, for example when a wrong username or password has
been supplied, and in this case the process terminates and a relevant
error is printed.
The login and logout requests are not candidates for recovery, but the return
values of all the network functions that are called from inside them, should be
checked thorougly.
Previously only network errors could cause a restoration of a session,
but now a BYE response sent by the server can also trigger it.
An option has been also added to control if and when the recover
function will be called.
This disables the sending of the "close notify" shutdown alert, only
after a network failure took place, and not during normal closing of a
connection.
When a "Connection reset by peer" error was caused while reading through SSL, a
restoration of the session should have taken place after all the connection
related structures were resetted. But instead a silent, unexpected and
unaccountable exit was the end result. This was caused by the underlying
socket being closed while trying to shutdown the SSL session.
Some of the functionality that was repeated in many places, regarding checks
and printing of informational messages, was replaced with common functions.
The session and selected variables should be reset if there has been a
connection problem or other failure.
The ifcore module methods that rely on the session should only be called
if there is a valid session variable defined.
It's better not to continuesly try to create a mailbox, when the server
continues to report TRYCREATE.
When appending messages it failed to create a mailbox when the mailbox
didn't exist and the server responded with TRYCREATE.
