On Mon, 16 Jun 2003 13:23:37 EDT, Keith Moore said:
yes. but clients are still not supposed to send BDAT unless the server
has returned 2xx on MAIL and at least one RCPT command.
The problem is that this requires a mandatory pipe drain just before sending
the DATA/BDAT command.
Given that we can otherwise get a short e-mail down to
a 3 packet handshake (less if a keep-alive connection is re-used), one
packet of MAIL/RCPT/(DATA/BDAT)/.
Not with DATA -- you have to check to see if the state change was
accepted before you can send the content.
IMO this is the real win of BDAT over DATA.
and one return packet of a string of 250's,
requiring a drain would double the number of RTTs involved.
pipelining clients have an obligation to read server BDAT responses and
act on them in a timely fashion, just not to block waiting on those
I think the problem here is that for a sufficiently large BDAT body (multiple
megabytes and up), you have to choose between drinking from the fire hose so
you stay connected so you can send the client the responses, and just doing
FIN thing to tear the connection down and drain the hose (and losing the
responses in the process).
Right again. And you may want to do this even if the MAIL FROM and a RCPT
TO succeeded but you want to fail the BDAT for some other reason.
I suppose adding language of the form "A client SHOULD drop back from
mode when retrying a connection that failed without returning a status code"
would be too much?
Having written fallback code to handle the connection closing after
sending EHLO, I fear that this may cause as many problems as it solves...
(Incidentally, I've encountered mail clients behind b0rked
firewalls that broke PMTU Discovery - the symptom was that pipelining would
fail, but it would work when not pipelining...)
Yes, I've seen that. Had one just the other day, in fact. I've also seen
instances where pipelining worked and non-pipelined commands failed. (Firewall
nonsense of a different sort.)