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. :-)
Sorry, I left out an important restriction: The connection must be in a state
to accept commands. So DATA, AUTH, TURN, and QUIT do require a check. (Although
in the case of QUIT it really doesn't matter - if the command, in violation of
the specification, fails, what, exactly, are you supposed to do? Send it again
and hope it works this time?)
However, if the command in question always leaves the connection in a state to
accept commands, there should be no problem pipelining a command that the
specification say can be sent at any time.
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.
First, I'm not seeing a MUST NOT in there. I also note that the data itself
following a succesful DATA command is not specified as ending a command group,
and RFC 3030 clearly indicates that BDAT without the LAST can be pipelined.
Second, it also says that the reason for this is there's a change of state the
client has to accommodate. Since QUIT is specifically required to be accepted
in any command state, other requirements insure that it will work.
I don't think any conclusion other than BDAT LAST can be pipelined with QUIT is
reasonable. It's OK to pipeline it with a RSET as well, for the same reasons.
So the question is where "BDAT LAST" fits into the picture.
BDAT, irrespective of the use of LAST, includes the data as part of the command
itself. After it's done, succeed or fail, you're back to accepting commands.
Now, this does leave open the question of how to handle malformed BDAT
commands. This is tricky: For example, what are you supposed to do if
you get:
BDAT garbage
or better yet:
BDAT 2456 something-other-than-last
There's also the question of what to do if you have support for BDAT but
it's disabled and you didn't offer it in the EHLO response.
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).
OK, so let's suppose that it is reasonable to conclude from the language that
BDAT LAST/QUIT pipelining isn't allowed. The question then is given all the
other requirements on clients and servers, e.g. must process commands in order,
must push out responses to group ending commands, must not flush the input
buffer, and so on, is it possible for a compliant server and a client that's
compliant in every other way to screw up?
If there is on, I'm not seeing it.
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.
And the handling of invalid BDAT (especially the second example I gave) as
well. But I think common sense is all you need to see that this should be OK
and there's something wrong in Google-Yahoo-land.
Has anyone tried pipelining RSET after BDAT LAST, or QUIT after the trailing
dot on a regular DATA on these servers? (Our client doesn't attempt any of this
because we can't tell right away whether or not there's another message we want
to send on this connection, so we don't know what command we're going to send
next and we don't want to wait to find out.)
Ned
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp