On 2015-06-24 at 14:06 -0700, Carl Byington wrote: > Does Exim (immediately or delayed) retry that connection and > (temporarily or permanently) ignore the offer of STARTTLS?
Depends upon the configuration. Assuming defaults, "yes". http://www.exim.org/exim-html-current/doc/html/spec_html/ch-encrypted_smtp_connections_using_tlsssl.html See under "9. Configuring an Exim client to use TLS" ----------------------------8< cut here >8------------------------------ When the server host is not in hosts_require_tls, Exim may try to deliver the message unencrypted. It always does this if the response to STARTTLS is a 5xx code. For a temporary error code, or for a failure to negotiate a TLS session after a success response code, what happens is controlled by the tls_tempfail_tryclear option of the smtp transport. If it is false, delivery to this host is deferred, and other hosts (if available) are tried. If it is true, Exim attempts to deliver unencrypted after a 4xx response to STARTTLS, and if STARTTLS is accepted, but the subsequent TLS negotiation fails, Exim closes the current connection (because it is in an unknown state), opens a new one to the same host, and then tries the delivery unencrypted. ----------------------------8< cut here >8------------------------------ The default setting of `tls_tempfail_tryclear` is `true`. > What is the "correct" behavior in this case? The recipient is offering > an encrypted channel that we cannot (well, will not) use. RFC 7435 "Opportunistic Security: Some Protection Most of the Time" Section 4, "Example: Opportunistic TLS in SMTP": ----------------------------8< cut here >8------------------------------ Various MTAs that advertise STARTTLS exhibit interoperability problems in their implementations. As a work-around, it is common for a client MTA to fall back to cleartext when the TLS handshake fails, or when TLS fails during message transmission. This is a reasonable trade-off, since STARTTLS only protects against passive attacks. In the absence of an active attack, TLS failures are generally one of the known interoperability problems. ----------------------------8< cut here >8------------------------------ If you want remote servers to refuse to downgrade to cleartext when talking to you, DANE is the way to go. See also: https://datatracker.ietf.org/doc/draft-ietf-dane-smtp-with-dane/ FWIW, I think it's reasonable to use a TLSA RRset in insecure DNS as a signal to not fall back to cleartext. I think that I talked about it with Viktor and he had some good reason to not do that. I'm not going to dig into this further tonight. If you want TLS for MX delivery, you really should be looking at DNSSEC/TLSA for DANE. I don't recall what Exim's 4.86 release will be doing in terms of fallback to plaintext given DANE, but it's the first DANE release so there may well be Issues. Postfix's DANE support is more mature at this time (unsurprising, since Viktor works on that). -Phil _______________________________________________ mailop mailing list [email protected] http://chilli.nosignal.org/mailman/listinfo/mailop
