from the fine documentation
When Exim has been built with TLS support, it advertises the
availability of the STARTTLS command to client hosts that match
tls_advertise_hosts, but not to any others. The default value of
this option is unset, which means that STARTTLS is not advertised
at all. This default is chosen because you need to set some other
options in order to make TLS available, and also it is sensible
for systems that want to use TLS only as a client.
from README.UPDATING about #4.87
<void>
from doc/Changelog
JH/18 Bug 1709: When built with TLS support, the tls_advertise_hosts
option now defaults to "*" (all hosts). The variable is now
available when not built with TLS, default unset, mainly to enable
keeping the testuite sane.
If a server certificate is not supplied (via tls_certificate) an
error is logged, and clients will find TLS connections fail on
startup. Presumably they will retry in-clear. Packagers of Exim
are strongly encouraged to create a server certificate at
installation time.
- From my logfile (see, I read all sorts of things)
Warning: No server certificate defined; TLS connections will fail.
Suggested action: either install a certificate or change
tls_advertise_hosts option
and from a Yahoo account of mine talking to my server which I have just
updated to #4.87
Warning: could not send message for past 4 hours
...
Deferred: 403 4.7.0 TLS handshake failed
I can find nothing in RFC3207 saying that Yahoo's behaviour is incorrect
and much in RFC5321 to say it is entirely correct.
So my question is:
on exactly what specification or belief is the statement
"Presumably they will retry in-clear" based ??
(because if it's Yahoo's error I have some influence there) ...
At the very least BTW there should be something in README.UPDATING about
changes that impact existing configurations :-(
- --
richard Richard Clayton
Those who would give up essential Liberty, to purchase a Benjamin
little temporary Safety, deserve neither Liberty nor Safety. Franklin
