Re: [ietf-smtp] Proposal: SMTP Early Pipelining

John C Klensin <john-ietf@jck.com> Mon, 03 September 2018 20:09 UTC

Return-Path: <john-ietf@jck.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 A2264130DE7 for <ietf-smtp@ietfa.amsl.com>; Mon, 3 Sep 2018 13:09:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
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 SRehDOu4EXAl for <ietf-smtp@ietfa.amsl.com>; Mon, 3 Sep 2018 13:09:37 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E462D12D7F8 for <ietf-smtp@ietf.org>; Mon, 3 Sep 2018 13:09:36 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1fwvAC-000L3T-Dl; Mon, 03 Sep 2018 16:09:32 -0400
Date: Mon, 03 Sep 2018 16:09:25 -0400
From: John C Klensin <john-ietf@jck.com>
To: Tony Finch <dot@dotat.at>, Jeremy Harris <jgh@wizmail.org>
cc: ietf-smtp@ietf.org
Message-ID: <C8742199DE7666C7C00A3F6C@PSB>
In-Reply-To: <alpine.DEB.2.20.1809031916090.3596@grey.csi.cam.ac.uk>
References: <a7a84459-99a9-fb40-fb07-64c7f6504621@wizmail.org> <alpine.DEB.2.20.1809031916090.3596@grey.csi.cam.ac.uk>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/wogt93LcsJTiIIsngyXAYhMLvCU>
Subject: Re: [ietf-smtp] Proposal: SMTP Early Pipelining
X-BeenThere: ietf-smtp@ietf.org
X-Mailman-Version: 2.1.27
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, 03 Sep 2018 20:09:39 -0000


--On Monday, September 3, 2018 19:28 +0100 Tony Finch
<dot@dotat.at> wrote:

> Jeremy Harris <jgh@wizmail.org> wrote:
> 
>> To increase the coverage of pipelining beyond the current
>> ESMTP PIPELINNG extension:
> 
> This is a fun idea and I have some thoughts that I encourage
> you to steal with liberal abandon:
>...
> These died on the grounds of being a ridiculously
> over-engineered paper protocol.
>...

Thanks.  This caused me to think of a different option with few
fewer turnarounds and less complexity.   The following is
proposed as a thought exercise and mostly (but not entirely) in
jest.

If one wants super-efficient pipelining, one doesn't send EHLO,
one sends a special session-opening command and sends it without
waiting for the 220 greeting message.  In honor of
BITNET/EARN/NETNORTH and, to some extent, RFC 2442, let's call
it BSMTP, with the same argument that would have been used with
EHLO.  This extension is intended for use only by prearrangement
among related parties and other consenting adults  if only
because implementations that did not recognize it (including
anti-spam system) could be expected to treat receipt of "BSMTP"
after the greeting message as equivalent to "ThisIsAnAttack" or
"HereComesTheSpam".  

After sending that command, the client waits a short period of
time to see if the server closes the connection or sends back a
5yz response,  If the server sends a 2yz response or does not
respond usefully, the client sends as much stuff in a single
stream as it thinks appropriate, potentially including multiple
messages without pausing to wait for the server to send out
response codes.  

Variations would include requiring that this be done only over
TLS or treating BSMTP as including STARTTLS with appropriate
arguments.

Really few required turnarounds :-(

   john