[lemonade] Re: PIPELINING, AUTH, and CHUNKING
Tony Finch <dot@dotat.at> Thu, 23 February 2006 13:08 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCGCy-0003mG-2G; Thu, 23 Feb 2006 08:08:36 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCG1C-0003sA-OS for lemonade@ietf.org; Thu, 23 Feb 2006 07:56:26 -0500
Received: from ppsw-0.csi.cam.ac.uk ([131.111.8.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCG1B-0008At-AG; Thu, 23 Feb 2006 07:56:26 -0500
X-Cam-SpamDetails: Not scanned
X-Cam-AntiVirus: No virus found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:57979) by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25) with esmtpa (EXTERNAL:fanf2) id 1FCG13-0003SI-2Q (Exim 4.54) (return-path <fanf2@hermes.cam.ac.uk>); Thu, 23 Feb 2006 12:56:17 +0000
Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1FCG13-00084t-Mt (Exim 4.53) (return-path <fanf2@hermes.cam.ac.uk>); Thu, 23 Feb 2006 12:56:17 +0000
Date: Thu, 23 Feb 2006 12:56:17 +0000
From: Tony Finch <dot@dotat.at>
X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk
To: Chris Newman <Chris.Newman@Sun.COM>
In-Reply-To: <DFFAA59A7AAA0F1946ED42D8@[10.1.110.5]>
Message-ID: <Pine.LNX.4.64.0602231207420.24112@hermes-2.csi.cam.ac.uk>
References: <Pine.LNX.4.64.0602220017450.24112@hermes-2.csi.cam.ac.uk> <DFFAA59A7AAA0F1946ED42D8@[10.1.110.5]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a
X-Mailman-Approved-At: Thu, 23 Feb 2006 08:08:35 -0500
Cc: lemonade@ietf.org, ietf-smtp@ietf.org, Gregory Vaudreuil <GregV@ieee.org>
Subject: [lemonade] Re: PIPELINING, AUTH, and CHUNKING
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=subscribe>
Errors-To: lemonade-bounces@ietf.org
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 <dot@dotat.at> 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 lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade
- [lemonade] streamlined message submission Tony Finch
- Re: [lemonade] streamlined message submission Ned Freed
- Re: [lemonade] streamlined message submission Tony Finch
- Re: [lemonade] streamlined message submission Ned Freed
- Re: [lemonade] streamlined message submission Dave Cridland
- Re: [lemonade] streamlined message submission Antony Bowesman
- Re: [lemonade] streamlined message submission Ned Freed
- Re: [lemonade] streamlined message submission Tony Finch
- Re: [lemonade] streamlined message submission Tony Finch
- Re: [lemonade] streamlined message submission Dave Cridland
- Re: [lemonade] streamlined message submission Chris Newman
- [lemonade] Re: PIPELINING, AUTH, and CHUNKING Tony Finch
- [lemonade] Re: PIPELINING and failed recipients Tony Finch
- [lemonade] Re: PIPELINING and failed recipients Dave Cridland
- [lemonade] SMTP QUICKSTART Tony Finch
- Re: [lemonade] SMTP QUICKSTART Dave Cridland
- Re: [lemonade] SMTP QUICKSTART Tony Finch
- Re: [lemonade] SMTP QUICKSTART Tony Finch
- Re: [lemonade] SMTP QUICKSTART Chris Newman
- Re: [lemonade] SMTP QUICKSTART Mark Crispin
- Re: [lemonade] Re: PIPELINING, AUTH, and CHUNKING Chris Newman
- Re: [lemonade] SMTP QUICKSTART Ned Freed
- Re: [lemonade] Re: PIPELINING, AUTH, and CHUNKING Tony Finch
- Re: [lemonade] Re: PIPELINING, AUTH, and CHUNKING Alexey Melnikov
- Re: [lemonade] SMTP QUICKSTART Tony Finch
- Re: [lemonade] Re: PIPELINING, AUTH, and CHUNKING Tony Finch
- Re: [lemonade] Re: PIPELINING, AUTH, and CHUNKING Arnt Gulbrandsen
- Re: [lemonade] Re: PIPELINING, AUTH, and CHUNKING Rob Siemborski
- Re: [lemonade] SMTP QUICKSTART Tony Finch
- Re: [lemonade] SMTP QUICKSTART Dave Cridland
- Re: [lemonade] SMTP QUICKSTART Tony Finch
- Re: [lemonade] SMTP QUICKSTART Dave Cridland
- Re: [lemonade] SMTP QUICKSTART Tony Finch
- Re: [lemonade] streamlined message submission Randall Gellens
- Re: [lemonade] streamlined message submission Dave Cridland
- Re: [lemonade] streamlined message submission Tony Finch
- Re: [lemonade] streamlined message submission Randall Gellens
- [lemonade] Re: PIPELINING, AUTH, and CHUNKING Randall Gellens
- [lemonade] Re: PIPELINING, AUTH, and CHUNKING Randall Gellens
- [lemonade] Re: PIPELINING and failed recipients Randall Gellens
- Re: [lemonade] streamlined message submission Dave Cridland
- Re: [lemonade] streamlined message submission Ned Freed
- Re: [lemonade] streamlined message submission Dave Cridland
- [lemonade] Re: PIPELINING and failed recipients Robert A. Rosenberg
- Re: [lemonade] streamlined message submission Randall Gellens
- [lemonade] Re: PIPELINING and failed recipients Randall Gellens