Wow. It honestly hadn't occurred to me to think about TLS and pipelining, but
it obviously warrants some consideration.
While I agree with your analysis, checking on the TLS list sounds like
a really good idea.
Ned
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
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp