Re: [ietf-smtp] CHUNKING and PIPELINING
Ned Freed <ned.freed@mrochek.com> Mon, 08 March 2021 05:36 UTC
Return-Path: <ned.freed@mrochek.com>
X-Original-To: ietf-smtp@ietfa.amsl.com
Delivered-To: ietf-smtp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC5573A2539 for <ietf-smtp@ietfa.amsl.com>; Sun, 7 Mar 2021 21:36:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5AeTmrjwuR6R for <ietf-smtp@ietfa.amsl.com>; Sun, 7 Mar 2021 21:36:17 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [98.153.82.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24EE63A2537 for <ietf-smtp@ietf.org>; Sun, 7 Mar 2021 21:36:17 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RWEGEQHTOW00FHOP@mauve.mrochek.com> for ietf-smtp@ietf.org; Sun, 7 Mar 2021 21:31:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1615181472; bh=ROdG637hAsq8cZBjb8BKRbViNnhhSyAa6Drzs3oiYWM=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=NNAgKWBdBYmNq3+BRZTlvM0lhON8kr6CIJ9kqAL0u1WcbDLhZ1prb954L0FJ2Stb+ kPRVuWYKcl1nMaCZV4HdOkFQtEowzvDTNDehwGHtC6dieWj9HIqmWaBtGjs1HD21om UcGE8WgIW8a/PDoTbm3Q2k/XGE+aiI2rRs9OY4MA=
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: TEXT/PLAIN; CHARSET="us-ascii"
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RWDMX50OQ8005PTU@mauve.mrochek.com>; Sun, 7 Mar 2021 21:31:10 -0800 (PST)
Cc: ietf-smtp@ietf.org
Message-id: <01RWEGEP5NI8005PTU@mauve.mrochek.com>
Date: Sun, 07 Mar 2021 20:31:32 -0800
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Sun, 07 Mar 2021 15:14:10 -0500" <1AFA5DBF-325F-4943-BBE3-45311CC485CA@dukhovni.org>
References: <b1202e49-26b2-35d8-0db7-bb94acd0d52f@wizmail.org> <01RWCSPP4820005PTU@mauve.mrochek.com> <1AFA5DBF-325F-4943-BBE3-45311CC485CA@dukhovni.org>
To: Viktor Dukhovni <ietf-dane@dukhovni.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/1y8BD_sPv9eeAh31LL_F_DRXJQ8>
Subject: Re: [ietf-smtp] CHUNKING and PIPELINING
X-BeenThere: ietf-smtp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of issues related to Simple Mail Transfer Protocol \(SMTP\) \[RFC 821, RFC 2821, RFC 5321\]" <ietf-smtp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-smtp/>
List-Post: <mailto:ietf-smtp@ietf.org>
List-Help: <mailto:ietf-smtp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Mar 2021 05:36:19 -0000
> > On Mar 6, 2021, at 7:58 PM, Ned Freed <ned.freed@mrochek.com> wrote: > > > >> Is is permitted to pipeline a QUIT after a BDAT LAST? > > > > RFC 5321 section 4.1.1.10 is quite clear that QUIT can be issued at > > any time. The state of the connection doesn't matter. > > So yes, a QUIT can be pipelined after BDAT LAST. It doesn't matter > > if the BDAT succeeds or fails. > Are you sure about that? For example, PIPELINING of QUIT with > "DATA" would often not have the intended effect. :-) Sorry, I left out an important restriction: The connection must be in a state to accept commands. So DATA, AUTH, TURN, and QUIT do require a check. (Although in the case of QUIT it really doesn't matter - if the command, in violation of the specification, fails, what, exactly, are you supposed to do? Send it again and hope it works this time?) However, if the command in question always leaves the connection in a state to accept commands, there should be no problem pipelining a command that the specification say can be sent at any time. > With PIPELINING, the client needs to wait for all the server replies > after EHLO, DATA, VRFY, EXPN, TURN, QUIT, and NOOP: > https://tools.ietf.org/html/rfc2920#section-3.1 > before sending further commands. First, I'm not seeing a MUST NOT in there. I also note that the data itself following a succesful DATA command is not specified as ending a command group, and RFC 3030 clearly indicates that BDAT without the LAST can be pipelined. Second, it also says that the reason for this is there's a change of state the client has to accommodate. Since QUIT is specifically required to be accepted in any command state, other requirements insure that it will work. I don't think any conclusion other than BDAT LAST can be pipelined with QUIT is reasonable. It's OK to pipeline it with a RSET as well, for the same reasons. > So the question is where "BDAT LAST" fits into the picture. BDAT, irrespective of the use of LAST, includes the data as part of the command itself. After it's done, succeed or fail, you're back to accepting commands. Now, this does leave open the question of how to handle malformed BDAT commands. This is tricky: For example, what are you supposed to do if you get: BDAT garbage or better yet: BDAT 2456 something-other-than-last There's also the question of what to do if you have support for BDAT but it's disabled and you didn't offer it in the EHLO response. > > > >> RFC 3030 (SMTP Service Extensions > >> for Transmission of Large > >> and Binary MIME Messages) > >> does not say whether or not BDAT LAST is a synch point per > >> RFC 2929 (SMTP Service Extension for Command Pipelining). > > > > That would only matter if there were restrictions on when QUIT can > > be sent. > But there are such restrictions, it must not be sent pipelined with > any of the list above (admittedly sending QUIT again after QUIT is > rather redundant). OK, so let's suppose that it is reasonable to conclude from the language that BDAT LAST/QUIT pipelining isn't allowed. The question then is given all the other requirements on clients and servers, e.g. must process commands in order, must push out responses to group ending commands, must not flush the input buffer, and so on, is it possible for a compliant server and a client that's compliant in every other way to screw up? If there is on, I'm not seeing it. > What Jeremy did not mention is that he's seeing interoperability > issues (reportedly with Google and IIRC Yahoo) when pipelining > "BDAT nnnn LAST<CRLF>QUIT<CRLF>". > Did Google, et. al. not implement PIPELINING for BDAT correctly? > It is not (to me) entirely obvious from the spec. The PIPELING > semantics should have been spelled out more clearly in 3030. And the handling of invalid BDAT (especially the second example I gave) as well. But I think common sense is all you need to see that this should be OK and there's something wrong in Google-Yahoo-land. Has anyone tried pipelining RSET after BDAT LAST, or QUIT after the trailing dot on a regular DATA on these servers? (Our client doesn't attempt any of this because we can't tell right away whether or not there's another message we want to send on this connection, so we don't know what command we're going to send next and we don't want to wait to find out.) Ned
- [ietf-smtp] CHUNKING and PIPELINING Jeremy Harris
- Re: [ietf-smtp] CHUNKING and PIPELINING Ned Freed
- Re: [ietf-smtp] CHUNKING and PIPELINING Viktor Dukhovni
- Re: [ietf-smtp] CHUNKING and PIPELINING Jeremy Harris
- Re: [ietf-smtp] CHUNKING and PIPELINING Ned Freed
- Re: [ietf-smtp] CHUNKING and PIPELINING Ned Freed
- Re: [ietf-smtp] CHUNKING and PIPELINING Viktor Dukhovni
- Re: [ietf-smtp] CHUNKING and PIPELINING Gene Hightower
- Re: [ietf-smtp] CHUNKING and PIPELINING Viktor Dukhovni
- Re: [ietf-smtp] CHUNKING and PIPELINING Jeremy Harris
- Re: [ietf-smtp] CHUNKING and PIPELINING Ned Freed
- Re: [ietf-smtp] CHUNKING and PIPELINING Viktor Dukhovni
- Re: [ietf-smtp] CHUNKING and PIPELINING Jeremy Harris
- Re: [ietf-smtp] CHUNKING and PIPELINING Tony Finch
- Re: [ietf-smtp] CHUNKING and PIPELINING John Levine
- Re: [ietf-smtp] CHUNKING and PIPELINING Gene Hightower
- Re: [ietf-smtp] CHUNKING and PIPELINING John R Levine
- Re: [ietf-smtp] CHUNKING and PIPELINING Gene Hightower