[ietf-smtp] smtp improvement?

iloveemail2 <iloveemail2@protonmail.com> Fri, 14 August 2020 17:59 UTC

Return-Path: <iloveemail2@protonmail.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 BB8293A1190 for <ietf-smtp@ietfa.amsl.com>; Fri, 14 Aug 2020 10:59:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.597
X-Spam-Level:
X-Spam-Status: No, score=-1.597 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=protonmail.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 5flqJ9-HN4Vq for <ietf-smtp@ietfa.amsl.com>; Fri, 14 Aug 2020 10:59:32 -0700 (PDT)
Received: from mail-40141.protonmail.ch (mail-40141.protonmail.ch [185.70.40.141]) (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 AE56E3A119F for <ietf-smtp@ietf.org>; Fri, 14 Aug 2020 10:59:32 -0700 (PDT)
Date: Fri, 14 Aug 2020 17:59:23 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1597427970; bh=7+5G1VIKRCySJgeAsLIx+4jJbBv3leZ4JX1Tzczk3tM=; h=Date:To:From:Reply-To:Subject:From; b=XR60YsSS4YKQTRgFFptQ+MpqZ0OhIFrMwOmx2uDVztxhkxEUbu86Z9Nr28BqLTRJb OsBJQGB3yI347WYMAMKmfNeKmshK0TYWx6Jiv+cBESR8MaFp9d3mNrpRRAM2RoSBSd Mfp2+TgENLzG/1XuqNF76CQ/5lCoj22VIaDpMzZk=
To: "ietf-smtp@ietf.org" <ietf-smtp@ietf.org>
From: iloveemail2 <iloveemail2@protonmail.com>
Reply-To: iloveemail2 <iloveemail2@protonmail.com>
Message-ID: <te1SaFZOMSOjDAcEAvL24CF40exooXRe212SQoZQMoBX8BJyFGmg2KYVr5VTPxH3G5G7myxRvAfLZ7Q_Ok3MRVRlH48GHddeOLSgkpWIMKE=@protonmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/Dp38UHAUmaVR102SRCsrMqJNjPw>
Subject: [ietf-smtp] smtp improvement?
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: Fri, 14 Aug 2020 18:00:44 -0000

I was wondering if certain portions of HTTP/2 have been considered for inclusion in some sort of way SMTP?

Compression is out of the question, primarily because of relaying and the fact it would just be decompressed right after. Data consumption isn't a big problem, since most SMTP servers are in datacenters with unlimited data (bandwidth style billing).

Klensin made a post about it s long time ago with more details; I think its in the archive somewhere

Maybe the multiple resources per TCP connection/binary framing is a good idea. For SMTP, I suppose it will be something like having multiple independent packets with the MAIL FROM,MAIL TO, and other "outside" information of a message, another type of packet with the body message, and then a another packet type for just a  general command. Each of these could be in any order, and the server would respond in any order. Kind of like pipelining, but even faster since the client doesn't need to wait for the DATA go ahead. This fixes the problem with QMTP since it doesn't support the whole SMTP command set, while an implementation like this would.

It would still be over TCP; Quic is a different discussion altogether.

Sent with ProtonMail Secure Email.