On 11/03/2021 02:17, Viktor Dukhovni wrote:
Google was actually sending TCP FIN without sending an SMTP response
for the MAIL command, much less the BDAT (which is what I had assumed).
Here, I'm not surprised. It is not prudent to start to tear
down the TLS connection before reading all the server replies,
and hence sending a "close_notify" right after a pipelined
"QUIT" is unwise.
I had thought that sending a TLS close-alert had semantics
"no further data sourced from here, but the other direction
is unaffected" - just like the TCP FIN. Re-reading RFC 8446
(TLS 1.3 spec) I still think so: Section 6 "Alert Protocol" :-
The
"close_notify" alert is used to indicate orderly closure of one
direction of the connection. Upon receiving such an alert, the TLS
implementation SHOULD indicate end-of-data to the application.
That text is rather new in RFC8446, and prior versions of TLS (1.0—1.2)
do not support half-close.
And even if they did, many applications are
simply not prepared to handle this.
https://tools.ietf.org/html/rfc5246#page-29
The other party MUST respond with a close_notify
alert of its own and close down the connection immediately,
discarding any pending writes.
So Google, were it thinking to follow the TLS 1.2 interpretation
(which it shouldn't have; it was a 1.3 session) violated that in
sending a TCP FIN without first sending a TLS close alert.
But, at least for TLS <= 1.2 de jure, I have to agree with you
on not being eager with the TLS close.
I still think I'll call them on it.
--
Cheers,
Jeremy
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp