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.
okay, I reread RFC 2920 - I had mis-remembered how it handled the DATA
synchronization problem. The client has to drain once after EHLO (2 payload
packets) to make sure that the server actually supports PIPELINING and/or
CHUNKING, and once after the BDAT LAST (2 more) to make sure that the
message was accepted.
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'm tempted to suggest that clients could limit the TCP window size until
they're sure they want to see the message, since it's easier to adjust
the TCP window size (at least on some platforms) than the BDAT chunk size.
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...)
I think this is along the same lines is "a server MAY terminate an SMTP
connection if the client keeps sending BDAT even though previous BDAT
commands resulted in errors..." - it is not something that the standard should
require, but it is implementation advice that might be useful.
Keith