On Mar 6, 2021, at 7:58 PM, Ned Freed
<ned(_dot_)freed(_at_)mrochek(_dot_)com> wrote:
Is is permitted to pipeline a QUIT after a BDAT LAST?
RFC 5321 section 4.1.1.10 is quite clear that QUIT can be issued at
any time. The state of the connection doesn't matter.
So yes, a QUIT can be pipelined after BDAT LAST. It doesn't matter
if the BDAT succeeds or fails.
Are you sure about that? For example, PIPELINING of QUIT with
"DATA" would often not have the intended effect. :-)
With PIPELINING, the client needs to wait for all the server replies
after EHLO, DATA, VRFY, EXPN, TURN, QUIT, and NOOP:
https://tools.ietf.org/html/rfc2920#section-3.1
before sending further commands. So the question is where "BDAT LAST"
fits into the picture.
RFC 3030 (SMTP Service Extensions
for Transmission of Large
and Binary MIME Messages)
does not say whether or not BDAT LAST is a synch point per
RFC 2929 (SMTP Service Extension for Command Pipelining).
That would only matter if there were restrictions on when QUIT can
be sent.
But there are such restrictions, it must not be sent pipelined with
any of the list above (admittedly sending QUIT again after QUIT is
rather redundant).
What Jeremy did not mention is that he's seeing interoperability
issues (reportedly with Google and IIRC Yahoo) when pipelining
"BDAT nnnn LAST<CRLF>QUIT<CRLF>".
Did Google, et. al. not implement PIPELINING for BDAT correctly?
It is not (to me) entirely obvious from the spec. The PIPELING
semantics should have been spelled out more clearly in 3030.
--
Viktor.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp