Am 04.08.22 um 00:03 schrieb Bill Cole via mailop:
A MTA that can't get STARTTLS to work will retry (or even continue in the same session) without encryption, as it SHOULD per the standard.
Erm, no, it doesn't. And that's not how RFC 3207 defines things, anyway:
After receiving a 220 response to a STARTTLS command, the client MUST start the TLS negotiation before giving any other SMTP commands. If, after having issued the STARTTLS command, the client finds out that some failure prevents it from actually starting a TLS handshake, then it SHOULD abort the connection.
Repeat after me: it SHOULD abort the connection. (At least some sendmail code runs in a timeout here, which then leads to an aborted connection — basically fine by the RFC.) Guess what happens on the next queue run ... Point is: there is no defined fallback to 1982. If STARTTLS does not result in a TLS-secured connection, the _expected_ behaviour is to abort the SMTP connection. If the MTA marks that message as "STARTTLS failed already once, try without next time" is totally up to the implementor. And, frankly, I wouldn't care to carry this state anyway. Let's look at RFC 3207 again:
The SMTP client and server should note carefully the result of the TLS negotiation. If the negotiation results in no privacy, or if it results in privacy using algorithms or key lengths that are deemed not strong enough, or if the authentication is not good enough for either party, the client may choose to end the SMTP session with an immediate QUIT command, or the server may choose to not accept any more SMTP commands.
This, to me, reads as "whatever was _ever_ a valid way of engaging in a STARTTLS'd SMTP communication has to be supported until the end of time; if you don't like the established encryption level, you are free to drop then connection _then_, with a meaningful error message". Not supporting legacies like SSLv3, TLS 1.1, etc. at the STARTTLS level is _not_ to be considered to be conforming to RFC 3207. IMHO, YMMV. -kai _______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop