[Top] [All Lists]

Re: BDAT, RFC 3030 protocol clarification?

2003-06-12 19:32:34

my understanding was  that the client should not send BDAT commands unless 
it had received a 2xx response from MAIL and at least one of the RCPT
commands. failure to do so could cause synchronization problems if the server 
then said 5xx in response to BDAT because it wasn't going to accept the
message anyway.

IMHO if a server is ignoring data in the TCP buffer when it claims to support
PIPELINING, that server is broken and we shouldn't try to fix it in the spec.
but if a server complains when a client sends BDAT for no valid recipients,
I don't blame the server for that.  

this isn't quite as severe as a pipeline "stop" but it does mean that the 
pipeline stalls if the client hasn't seen the response to MAIL and at least
one good response to RCPT before it wants to start sending data.

especially in these days of rampant spam, it's more important for a server to
be able to refuse traffic which it wouldn't forward/relay anyway than it is
for the client to be able to avoid a pipeline stall.


I am preparing a revision to RFC 3030 in anticipation of draft-standard

The below reported interoperability failure seems to result from a
difference in interpretation of the following paragraph.  This paragraph,
and the example in section 4.2, seems to, but may not clearly state, that a
pipelining "stop" is required after the sending of the "envelope" and the
beginning of the "body" sending portions of the SMTP transaction.

----Quoted from section 2 of RFC 3030 ---

After all MAIL and RCPT responses are collected and processed, the message
is sent using a series of BDAT commands.  The BDAT command takes one
required argument, the exact length of the data segment in octets.  The
message data is sent immediately after the trailing <CR> <LF> of the BDAT
command line.  Once the receiver-SMTP receives the specified number of
octets, it will return a 250 reply code.


Matti Aarnio and others have questioned the need, and in the case below, did
not implement, the pipeline stop. The stop costs an extra round-trip, but
eliminating it may continue interoperability problems with servers that
assume otherwise.  

I would like opinions on how to clarify this... do we clarify that a stop is
a suggestion when sending large messages or do we clarify that this is a
required full stop?

I hum for clarifying the stop as mandatory as the most conservative
interpretation and one that promotes maximum interoperability with the
installed base.