Re: [ietf-smtp] smtp improvement?

Brandon Long <blong@google.com> Fri, 14 August 2020 22:21 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 46C433A0406 for <ietf-smtp@ietfa.amsl.com>; Fri, 14 Aug 2020 15:21:25 -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 01dG7_jZGzAs for <ietf-smtp@ietfa.amsl.com>; Fri, 14 Aug 2020 15:21:23 -0700 (PDT)
Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (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 A4B413A0402 for <ietf-smtp@ietf.org>; Fri, 14 Aug 2020 15:21:23 -0700 (PDT)
Received: by mail-il1-x136.google.com with SMTP id r13so5306519iln.0 for <ietf-smtp@ietf.org>; Fri, 14 Aug 2020 15:21:23 -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=lS4iNqlgpiUERvzmW2njrAvGCoVZXyWFLgjcKdSHHb8=; b=qLuIg1BGaX6rTR7PoGZ0P3zvA/2MF7elzfPKgD+EVlHybBU4Uc+tMmR5AowZVltxmh /B46j9sZbyPyEjkguIIYNVDerfjzxr0BsQlQzbVakkjRyrvGsCLRuJ+9saf2pmSizwep qYsiq0SlBWbLMLAdzZtasmfa7wxDwmTTN1IeJhdO+pvJ21yEnzfDxlcg+jQ9xOAG0xiB hXazRjudguedPZUgMqpWplAtTlGeqpjbcv2ZYDagFEaITu5pBw78hOV8EuC1JN+K7gVu M7DW+IDJ01l3bcr+iDkgvNVgK1XVrjZlNS1Pq7cFIE4VFcwG9ZE63vbnTgzq5CAFxfaJ wcPw==
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=lS4iNqlgpiUERvzmW2njrAvGCoVZXyWFLgjcKdSHHb8=; b=kKo6kJhXFU04D3VaUdpyQMg3Zc6YC5cXXkf0EWxM7pM7fTfg48NNDPvucdIPMd/S6X S7J1KqY9bbkBSYYKJrMw7GG/S4Z1hyGDVJ2YZxDCZ2Wir7+L7QD+YM8PWRFMGy9KugiN 0P+ypyY56drp989zeTIuGKhXgefKpGwt4Pa7gyez8FyFWa7j75El4CSa+3ylAizIzbTQ oF4apXf1Iy7Ac1mFQORRptEiOOawj96EyQJx4uLT9gROLONj+e6I5Jm4aRhWUq9F+8Ds 2RkkexzACivQnMyCwuXJWmjs5LyQYXKlhsUJzcNaesQG9prgSnTvQPp+9cw8ZnySeR83 7iqA==
X-Gm-Message-State: AOAM532+1zQTrq/w7tpJxJA54+v+3F115GuyfQ64EGHIzEjkLsFpkERV BPeSEJoDysTxFog4twR18FAr5u33RfoyN3Qb2vZ2
X-Google-Smtp-Source: ABdhPJzIQUCzDbV9cNbd1ClplFnTQtmW09PTZf3+eBKeKng6nyiYadGdsagued6dfGm77nZxr4w6qSgBQ0HRfU+ad0M=
X-Received: by 2002:a92:40c1:: with SMTP id d62mr3917152ill.35.1597443682433; Fri, 14 Aug 2020 15:21:22 -0700 (PDT)
MIME-Version: 1.0
References: <te1SaFZOMSOjDAcEAvL24CF40exooXRe212SQoZQMoBX8BJyFGmg2KYVr5VTPxH3G5G7myxRvAfLZ7Q_Ok3MRVRlH48GHddeOLSgkpWIMKE=@protonmail.com>
In-Reply-To: <te1SaFZOMSOjDAcEAvL24CF40exooXRe212SQoZQMoBX8BJyFGmg2KYVr5VTPxH3G5G7myxRvAfLZ7Q_Ok3MRVRlH48GHddeOLSgkpWIMKE=@protonmail.com>
From: Brandon Long <blong@google.com>
Date: Fri, 14 Aug 2020 15:21:10 -0700
Message-ID: <CABa8R6tt6pCEJ642JmcZE6Xgc+8ziGJOPzOsX0qTiDBbR-FWFg@mail.gmail.com>
To: iloveemail2 <iloveemail2@protonmail.com>
Cc: "ietf-smtp@ietf.org" <ietf-smtp@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003df4ae05acddd744"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/BoaRWgolBm-8vRQkMqL3p0hVBeU>
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: Fri, 14 Aug 2020 22:21:25 -0000

What problems are you trying to solve with these?  Latency and connection
counts?

The number of connections is inherently much lower with server to server
for MTAs, and when you have consumer to server (MSA), the amount of traffic
is even less.  I know
a lot of places operate with some strict connection limits, but I think
that's more of a weak fair sharing method than due to actual limitations...
or maybe just that many servers haven't needed to move away from the one
process per connection model... which means they also wouldn't be first in
line for handling multiple transactions at once anyways.

Latency?  We see messages transmitted in seconds at our border with other
large providers at least (that's memory from looking a couple times, I
haven't done any deep investigation), and from our own experiences, our
latency isn't usually a question of parallelism.

I don't see the strong need here.

Brandon

On Fri, Aug 14, 2020 at 11:00 AM 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
>