ietf-smtp
[Top] [All Lists]

Re: [ietf-smtp] CHUNKING and PIPELINING

2021-03-11 03:53:08
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