[Top] [All Lists]

BDAT, RFC 3030 protocol clarification?

2003-06-12 18:53:45

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

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 

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.


Greg V.

-----Original Message-----
From: Matti Aarnio [mailto:mea+ietf-smtp(_at_)nic(_dot_)funet(_dot_)fi]
Sent: Monday, February 17, 2003 6:44 PM
To: ietf-smtp(_at_)imc(_dot_)org
Subject: MS Exchange 2000 broke RFC 3030 badly...

I write at this forum, as apparently MS people read this, and
me being a non-customer to them, I have no direct access routes
to send bug reports.

I have implemented ESMTP  CHUNKING / BDAT since 1997,  and now
finally some major implementations do appear -- but sadly first
of them is broken.   The end result is that even if Microsoft
fixes things this week, bug containing versions will be running
for years...     (Shall RFC 3030 be thus considered failure due
to widely installed buggy implementation ?)

In RFC 3030 two ESMTP extensions are defined:

The buggy implementation is of CHUNKING's BDAT verb processing.

Said verb runs like this:

  < nnnn bytes of message header+content data with CRLF line ends >

The server shall always consume the message content associated
with BDAT verb.  (Ok, RFC 3030 text isn't explicitely clear at this,
which has lead to a number of implementation bugs, including
the one presently being discussed.)

With simultaneous PIPELINING facility/compability declared by the
remote MTA server, a smtp-client sending in optimized pipeline mode
sends MAIL FROM, one or more of RCPT TO, and also BDAT+message content
all in one TCP data push.

How   MS Exchange 2000   as deployed at Hotmail.COM now does work is:

 - If   MAIL FROM   and   RCPT TO (one or more) are received
   successfully,  BDAT will be accepted successfully.

 - If for some reason all RCPT TOs are rejected, treatment of BDAT
   is broken.  Associated data is not consumed (discarded), and
   the result is unpredictable number of "500 Unrecognized command"
   messages, as the message content ended up in SMTP command processing.

   Following UNIX bash-script shows what happens.

(echo "EHLO foo";sleep 1;
echo -e "MAIL FROM:<>\nRCPT TO:<lklkzzh(_at_)hotmail(_dot_)com>\nBDAT 9 
sleep 2;
echo -e "MAIL FROM:<>\nRCPT TO:<lklkzzh(_at_)hotmail(_dot_)com>\nBDAT 9 
sleep 3) | telnet smtp

   Doing network protocol dump, one can see that from MAIL FROM to
   BDAT content data all are sent with single TCP data push, as is
   the nature of smtp-client in fully developed PIPELINING mode.

   Here are the received responses:

220 Microsoft ESMTP MAIL Service, Version: 
5.0.2195.5600 ready at  Mon, 17 Feb 2003 16:23:42 -0800
   <<-  EHLO foo ( Hello []
250-SIZE 4278190
250 OK
   <<- MAIL FROM:<>
250 <>....Sender OK
   <<- RCPT TO:<lklkzzh(_at_)hotmail(_dot_)com>
550 Requested action not taken: mailbox unavailable
   <<- BDAT 9 LAST (+ data)
503 Need Rcpt command.
500 Unrecognized command
500 Unrecognized command
500 Unrecognized command
   <<- MAIL FROM:<>
503 Sender already specified
   <<- RCPT TO:<lklkzzh(_at_)hotmail(_dot_)com>
550 Requested action not taken: mailbox unavailable
   <<- BDAT 9 LAST (+ data)
503 Need Rcpt command.
500 Unrecognized command
500 Unrecognized command
500 Unrecognized command

   Fully pipelined smtp client code does not expect
   any of those "500 Unrecognized command" lines, and
   goes out of protocol sync.

/Matti Aarnio   <mea(_at_)nic(_dot_)funet(_dot_)fi>