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

Reply via email to