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 outbound
packet of MAIL/RCPT/(DATA/BDAT)/. 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 the
FIN thing to tear the connection down and drain the hose (and losing the
responses in the process).
I suppose adding language of the form "A client SHOULD drop back from pipelining
mode when retrying a connection that failed without returning a status code"
would be too much? (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...)
Computer Systems Senior Engineer
Description: PGP signature