> On Apr 25, 2016, at 11:31 AM, Richard Clayton <richard@???> wrote:
>
> 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) ...
There is no requirement for fallback to cleartext when STARTTLS is
advertised, but fails. Some MTAs do perform such a fallback. In
particular Exim and Postfix (possibly after trying other MX hosts
and requeueing) send in cleartext. Sendmail does not, and it seems
Yahoo does not.
The Postfix behaviour when server-side TLS is administratively
enabled, but no certificate is configured is to log warnings and
not advertise STARTTLS. Advertising STARTTLS when it is sure to
fail is not ideal.
I can understand the implementation rationale. Exim likely does
not attempt to load the certificates until the STARTTLS command
actually arrives, and so does not know that none are available
until that happens. Postfix preloads the certificate chain, but
each SMTP server processes a limited number of client connections
and exits, so "stale" certificates are not a problem.
IIRC, the Exim SMTP server runs indefinitely, and so preloading
the cert is not as attractive, since it will get stale. The
cert file would have to be checked each time a client sends
EHLO when deciding whether to include STARTTLS in the response.
An alternative is to generate a self-signed cert on the fly and
use that if the cert file is not usable. Or do that in the
start script, so that the certificate is never missing.
--
Viktor.
P.S. FWIW:
In Postfix, I've opted for providing a script that generates
and configures the cert/key and leaving the decision of enabling
inbound TLS by default to O/S distributions. They provide the
code that installs and activates Postfix, so are in a better
position to work with the user to enable or not enable TLS.
This seems to be "working" in the sense that some O/S distributions
have noticed the new script and have started using it in their
package delivery code.
