In discussions here there is a scenario given where a MAIL-FROM, one
or more RCPT-TOs, and a DATA commands are sent as a single PIPELINE
burst thus going into DATA more before the server has responded to
the MAIL-FROM and RCPT-TO commands. This is IMO a BUG (or at least a
Design Flaw) on the part of the MUA which should NEVER send that DATA
under the assumption that the MAIL-FROM and RCPT-TOs will be
accepted.
Far from being a bug, it is behavior defined in RFC 2920, a full standard. That
means it has undergone considerable strutiny and not only are there multiple
interoperable implementations, it has proven to be robust and reliable in
widespread operational use.
It should wait it gets the queued replies and parse them
BEFORE it assumes it has permission to send the DATA and go into DATA
mode.
That's only necessary if the server doesn't offer the extension.
This will allow it to work the same as if it were NOT in
PIPELINE mode and react to the replies that the Server is sending it.
But that's the point - it does work the same and doesn't change dialogue
semantics in any way, only the timing. Indeed, the only reason this was done as
an extension was there were a few servers out there that cleared their input
buffers at various random points during the dialogue, and since that behavior,
although clearly suboptimal, wasn't specifically disallowed in RFC 821, we
decided it was best not to invalidate these good-faith implementations.
All a server needs to do to support pipelining is leave its input buffer alone.
Any server that does that can avertise the extension. (To be fair, it is
helpful if the server takes the additional step of batching up its responses,
but this isn't required.)
Pipelining on the client is more complex, of course, but the benefits of losing
all those turnarounds are so significant it is well worth the trouble. (In fact
there's a move to define an even more agressive pipelining specification that
pushes the boundaries a hcek of a lot further than RFC 2920 ever did.)
A note to this effect would help avoid this type of broken behavior.
There's nothing remotely broken about it. See above.
Ned