Re: [lemonade] Re: PIPELINING, AUTH, and CHUNKING

Chris Newman <Chris.Newman@Sun.COM> Fri, 24 February 2006 00:12 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCQZI-0006ES-Ed; Thu, 23 Feb 2006 19:12:20 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCQZG-0006Dq-Uz for lemonade@ietf.org; Thu, 23 Feb 2006 19:12:18 -0500
Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCQZG-000482-FK; Thu, 23 Feb 2006 19:12:18 -0500
Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id k1O0CGuf006947; Thu, 23 Feb 2006 17:12:18 -0700 (MST)
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IV600G010HCYJ00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM); Thu, 23 Feb 2006 17:12:16 -0700 (MST)
Received: from [10.1.110.5] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IV60041W0KEQL20@mail-amer.sun.com>; Thu, 23 Feb 2006 17:12:16 -0700 (MST)
Date: Thu, 23 Feb 2006 16:13:35 -0800
From: Chris Newman <Chris.Newman@Sun.COM>
Subject: Re: [lemonade] Re: PIPELINING, AUTH, and CHUNKING
In-reply-to: <Pine.LNX.4.64.0602231207420.24112@hermes-2.csi.cam.ac.uk>
To: Tony Finch <dot@dotat.at>
Message-id: <D8C82F88144190E47AF0501B@[10.1.110.5]>
MIME-version: 1.0
X-Mailer: Mulberry/3.1.6 (Mac OS X)
Content-type: text/plain; format="flowed"; charset="us-ascii"
Content-transfer-encoding: 7bit
Content-disposition: inline
References: <Pine.LNX.4.64.0602220017450.24112@hermes-2.csi.cam.ac.uk> <DFFAA59A7AAA0F1946ED42D8@[10.1.110.5]> <Pine.LNX.4.64.0602231207420.24112@hermes-2.csi.cam.ac.uk>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Cc: lemonade@ietf.org, ietf-smtp@ietf.org, Gregory Vaudreuil <GregV@ieee.org>
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


Tony Finch wrote on 2/23/06 12:56 +0000:

> 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.

Well, if a server advertises all of BURL, PIPELINING, and AUTH PLAIN/EXTERNAL, 
then it must permit AUTH PLAIN/EXTERNAL to be pipelined in order to comply with 
the BURL spec.  A bit convoluted, but that's what the specs say.  Yes, this 
would probably be better done in an RFC 2554 update, but I don't have time to 
write one.

> 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.

BURL is a submit-only extension with a normative reference to 
draft-gellens-submit-bis-02 which requires authentication.  So it's safe for 
clients to assume authentication is required if both BURL and AUTH are 
advertised.

                - Chris


_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade