Subject: [lemonade] RE: PIPELINING, AUTH, and CHUNKING

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
Date: Thu, 23 Feb 2006 08:34:06 -0600

A revised version of the ESMTP binary extension expired as an ID two years ago or so. That document clarified the interaction between chunking and pipelining.  A reference to the expired draft is below.

I stalled in the process of moving the document to draft standard (unable to compile a suitable implementation report).  I will resurect the draft and edit the language to make it consistent with the RFC 2920 concept of a group.

http://mirrors.isc.org/pub/www.watersprings.org/pub/id/draft-vaudreuil-esmtp-binary3-01.txt

Greg V.

-----Original Message-----
From: Tony Finch [mailto:[email-masked]]On Behalf Of Tony Finch
Sent: Thursday, February 23, 2006 7:56 AM
To: Chris Newman
Cc: Tony Finch; Gregory Vaudreuil; [email-masked]; [email-masked]
Subject: Re: PIPELINING, AUTH, and CHUNKING

On Wed, 22 Feb 2006, Chris Newman wrote:
> Tony Finch wrote on 2/22/06 0:54 +0000:
>
> > Current securely authenticated message submission requires at least
> > eleven round trips (including TCP startup and shutdown). BURL can
> > reduce this to nine.
>
> I'm glad someone noticed that little feature I slipped into BURL :-)

Yes it is nice, but on reflection I think the way it is specified isn't
ideal. In particular, to quote that bit from RFC 2920 again:

   Additional commands added by other SMTP extensions may only appear as
   the last command in a group unless otherwise specified by the
   extensions that define the commands.

So I think the BURL spec is wrong to talk about pipelining AUTH, and if
you want to allow pipelined AUTH it should be specified as an update to
RFC 2554.

Furthermore, it isn't safe in all situations for a client to pipeline a
single round-trip AUTH. For example, it's common to have dual-purpose MSA
and MX servers which operate in MSA mode after AUTH and MX mode otherwise.
If the client pipelines an AUTH and an intended submission, but the auth
fails, bad things will happen - recipients will be rejected that would
have been OK, an incomplete message will suffer an anti-spam penalty
instead of being fixed up, etc.

Pipelined AUTH is OK if the server is going to reject any un-authenticated
submissions, in which case the server should explicitly say so, perhaps by
using an EHLO keyword line such as 250 PIPEAUTH PLAIN EXTERNAL.

I've also copied this message to Gregory Vaudreuil because of questions
about PIPELINING and BDAT, as well as BURL.

RFC 3030 implies that BDAT can be pipelined, though the way it says so
doesn't follow the "last command in a group" model of RFC 2920.
Furthermore, some of the descriptive text and the example in section 4.2
imply a synchronization point between the envelope and data, though
because all the commands in the sequence can be pipelined, this isn't a
forced sync point. It would be more correct to terminate the envelope
commands with a NOOP to force a sync.

The BURL spec requires a sync point after the "LAST" BDAT or BURL command,
instead of after the message envelope. I think it would be better for BDAT
and BURL to not require any synchronization at all: if the client wants a
sync, it can use the NOOP command. Note that the main reason a sync point
is required after DATA is so that the client and server agree about
whether the next utterance from the client is a command or is message
data. This isn't a problem for BDAT because the command and data are sent
together, with a single response from the server for both.

This would allow a client to pipeline multiple messages together, which
means you can move from using TCP in interactive mode to bulk data mode,
and therefore make the best use of the available bandwidth. For example,
consider a 1Mb/s link with a 100ms RTT. If the client sends a 5KB message,
this takes about 50ms to transmit, so by the time the server's replies
arrive the client will be one or two messages further on; if there was a
problem, the client can deal with it asynchronously, and it will have done
50ms extra useful work. If the client sends a 20KB message, the server's
replies will start arriving part-way through message transmission, so if
there is a problem the client can usefully RSET it before the next chunk
to save time and bandwidth.

I think it would be cool to allow this kind of high-bandwidth asynchronous
message transmission. It is also more friendly from the point of
congestion control than having multiple concurrent SMTP connections
perpetually in TCP slow start.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
FAIR ISLE FAEROES: NORTH OR NORTHEAST 4 OR 5, INCREASING 6 IN FAIR ISLE FOR A
TIME, BUT VARIABLE 4 IN FAEROES AT FIRST. FAIR. GOOD.

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: Tony Finch <[email-masked]>
Date: Thu, 23 Feb 2006 14:44:55 +0000

On Thu, 23 Feb 2006, Vaudreuil, Greg M (Greg) wrote:
>
> A revised version of the ESMTP binary extension expired as an ID two
> years ago or so. That document clarified the interaction between
> chunking and pipelining.  A reference to the expired draft is below.

Cool, thanks. Yes, it's much clearer, and allows full pipelining of
multiple messages :-)

> I stalled in the process of moving the document to draft standard
> (unable to compile a suitable implementation report).  I will resurect
> the draft and edit the language to make it consistent with the RFC 2920
> concept of a group.

A couple of additional suggestions arising from the updated draft:

Should the sentence abut pipelining in the middle of page 4 be moved to
the paragraph about pipelining at the top of the same page?

Also, "Receivers MUST accept the BDAT command even where there are no
valid recipients." - why not allow them to reject in this situation?

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
TYNE DOGGER: NORTHEAST 4 VEERING EAST 5 OR 6. OCCASIONAL RAIN. MAINLY GOOD.