Re: [ietf-smtp] CHUNKING and PIPELINING

[Jeremy Harris <[e-mail]>]

On 09/03/2021 20:47, Viktor Dukhovni wrote:
>> On Mar 8, 2021, at 10:45 PM, Gene Hightower <[e-mail]> wrote:
>>
>> I can pipeline QUIT after BDAT nnnn LAST to Google's servers and it
>> seems to work. Works with Microsoft/Outlook, too.
> 
> Thanks, I just tried it, and it worked for me as well.
> Jeremy, was there perhaps a bug in your code?

As it turns out, no - or at least not the obvious part.
Some further testing has found that the syndrome
(at least with Google's SMTP servers) is down to my pipelining all of

(SMTP) MAIL, RCPT, BDAT LAST, QUIT, (TLS) close-alert, (TCP) FIN.

The TLS alert and TCP FIN go in the last of the flight of TCP
segments carrying the SMTP commands and data.

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).


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.



If I separate out the SMTP commands from the TLS & TCP shutdowns,
reaping the SMTP responses in between, all is well.  If I send
the TLS shutdown with the SMTP commands but not with a TCP FIN,
it is not ok.


Perhaps I need to raise the question on the tls mailinglist.
-- 
Cheers,
   Jeremy