Re: [ietf-smtp] CHUNKING and PIPELINING

[Viktor Dukhovni <[e-mail]>]

> On Mar 10, 2021, at 7:04 PM, Jeremy Harris <[e-mail]> wrote:
> 
> 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.

My first read of RFC3030 was that one's expected to pause after
all the RCPT commands and before the first BDAT, to check
whether at least one recipient had been accepted.  But this
appears to not be the case.

So indeed you can pipeling the entire MAIL transaction from "MAIL"
to "QUIT" (if the number of BDAT segments is small enough).

What's worse (or better depending on your perspective) is that
you can even pipeline MULTIPLE mail transactions, nothing there
to stop the next "MAIL" command being sent right after "BDAT LAST".

At some point a 3030bis clarifying these issues would be welcome
IMHO.

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

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

That should be your implementation, only do the TLS close_notify
once you're neither writing nor reading any SMTP chatter.

-- 
	Viktor.