Re: [ietf-smtp] CHUNKING and PIPELINING

[Jeremy Harris <[e-mail]>]

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