Re: [ietf-smtp] smtp improvement?
Brandon Long <blong@google.com> Tue, 15 September 2020 00:39 UTC
Return-Path: <blong@google.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 4A4133A0BEE for <ietf-smtp@ietfa.amsl.com>; Mon, 14 Sep 2020 17:39:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level:
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 CBnDi1E6HuR5 for <ietf-smtp@ietfa.amsl.com>; Mon, 14 Sep 2020 17:39:06 -0700 (PDT)
Received: from mail-vs1-xe2b.google.com (mail-vs1-xe2b.google.com [IPv6:2607:f8b0:4864:20::e2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 099C53A0B75 for <ietf-smtp@ietf.org>; Mon, 14 Sep 2020 17:39:04 -0700 (PDT)
Received: by mail-vs1-xe2b.google.com with SMTP id j185so960165vsc.3 for <ietf-smtp@ietf.org>; Mon, 14 Sep 2020 17:39:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LR1wN5JVdrYbq8EquEK2hL82yMTNLoiDc07VT1DiWR4=; b=PrjYWt7xq8aZSiSuyIpMdwjyZDuo7EXoeosZjIUJMPq6/o8I+iHwTSPQtjEMaZuW/A RbwY75sYECfVe28r4YquwH2eql0xCDP6FWS7WNxPv5LQMq2uXG2icRw086Jghwv4RYFQ qaQ1Bc7tVC6ms+qleOnlaZ/8kmyB5wtxW4Q/7tYqdjoupm4sHLL69lXxYrgFKz1V508N gKH5+91ByWCexiKCv4jQYRLHLkZ9AGKz9cX7bpd6AlN99cSDS/iZNZOy15kXQsgtUTVz bi7LQ97uw6aFqt2+BJ7AIH8FtILA1iQZFMPpLv+HRL/R5NE/HH1G1el/rKIcLGp2DyTd w28w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LR1wN5JVdrYbq8EquEK2hL82yMTNLoiDc07VT1DiWR4=; b=qWvjPm4tC4MsI8+bntZQKgsaXwdTNkXb8hmYz1kMHLc2aP2JaLDZqIoe+ORHh0o3lv 44jyYUr8RzmTJIEezHJjiN1dE/mVBVAQiv0EE5JWuMhFONpambKDzsPFH2nauB4JxGcl pf03aXUD5QqvSr/L9Jgh9L4qB/BMAcfsJSWpfw85xdcbrDb+ovCpwGufItzucyXi4+0M IFQmRuvL3OBA7pqCa/hkpqQIZi63i7itDU2KGA6rX4xUq0hf1QZ3tw4VNYmNGPVBhrOC vmK0nsjnqOI//C4gm8mM3X52wKDx4CE3jptPNDhvArwwouM2nHepL/mDkMCCFlVbi/4s Ounw==
X-Gm-Message-State: AOAM530Exd2IS7gQUvyG9ZQfikGvBBJyMVhrFHEVhhzFuWspoc0TxXTT lxbriWztkU0uD4hqQvTSrHjRB+J8fEH2Au1zfppc
X-Google-Smtp-Source: ABdhPJwhk6J35rllFZJ6i0IuJ+6QneozDVijoj/gal1BxB6PyckavGYmaUWZkfUATCAI+Nr+t874Oa2gb0CNovJX/gs=
X-Received: by 2002:a67:7dd3:: with SMTP id y202mr9754317vsc.0.1600130342669; Mon, 14 Sep 2020 17:39:02 -0700 (PDT)
MIME-Version: 1.0
References: <te1SaFZOMSOjDAcEAvL24CF40exooXRe212SQoZQMoBX8BJyFGmg2KYVr5VTPxH3G5G7myxRvAfLZ7Q_Ok3MRVRlH48GHddeOLSgkpWIMKE=@protonmail.com> <FF9469BF7566121BCD4D30D8@PSB>
In-Reply-To: <FF9469BF7566121BCD4D30D8@PSB>
From: Brandon Long <blong@google.com>
Date: Mon, 14 Sep 2020 17:38:50 -0700
Message-ID: <CABa8R6t3hmuGyP-=+tidqMp23SHmwddH247=7OwuTDs3NJJzyg@mail.gmail.com>
To: John C Klensin <john-ietf@jck.com>
Cc: iloveemail2 <iloveemail2@protonmail.com>, ietf-smtp <ietf-smtp@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000abbc5d05af4f6016"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/7bqUD96UcAu28qEltmvHv-8YL_c>
Subject: Re: [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: Tue, 15 Sep 2020 00:39:14 -0000
Yes, I should point out that at Google, we do multiplex multiple connections between a proxy frontend and our actual smtp servers, but we don't do it at the command level, but at the stream level, which is a much simpler mechanism for integration and utility across different protocols (we do this with imap, pop, xmpp, and probably others, on top of the various types of HTTP). Envoy has at least some support for this: https://www.envoyproxy.io/docs/envoy/v1.15.0/intro/arch_overview/http/upgrades#tunneling-tcp-over-http-2 STARTTLS requires some OOB handshaking to make this work which I'm not sure that Envoy supports, but I'm sure it could be extended to do it. Ditto with passing the connection metadata forward, though envoy probably already does that as HTTP headers on the request stream. This is another reason we don't really care about the number of inbound connections from external folks... and again, the number of connections is orders of magnitude smaller than most people would see for HTTP. Brandon On Mon, Sep 14, 2020 at 2:04 PM John C Klensin <john-ietf@jck.com> wrote: > To add to Brandon's and Dave's comments, think about the > interactions between what you propose and tunneling SMTP over > TLS, which is the preferred conventional wisdom and between it > and relay situations. As they suggested, it is not clear what > problem you are trying to solve and if it would actually solve > it without making other things worse. > > I also question your assertion about "most SMTP servers". Had > you said that most SMTP traffic is handed by servers in big data > centers, etc., I'd guess you might be right. But there are > still a very large number of servers out there supporting only a > since enterprise, one that might be a SOHO environment, probably > more than enough to more than outnumber those large servers and, > in most cases, associated cloud and/or cluster arrangements. > > john > > > --On Friday, August 14, 2020 17:59 +0000 iloveemail2 > <iloveemail2=40protonmail.com@dmarc.ietf.org> wrote: > > > 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. > > > > > > _______________________________________________ > > ietf-smtp mailing list > > ietf-smtp@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf-smtp > > > _______________________________________________ > ietf-smtp mailing list > ietf-smtp@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-smtp >
- [ietf-smtp] smtp improvement? iloveemail2
- Re: [ietf-smtp] smtp improvement? Brandon Long
- Re: [ietf-smtp] smtp improvement? Dave Crocker
- Re: [ietf-smtp] smtp improvement? John C Klensin
- Re: [ietf-smtp] smtp improvement? Brandon Long
- Re: [ietf-smtp] smtp improvement? John C Klensin
- Re: [ietf-smtp] smtp improvement? iloveemail2
- Re: [ietf-smtp] smtp improvement? John Bucy