Subject: Re: [ietf-smtp] smtp improvement?

From: Dave Crocker <[email-masked]>
Date: Mon, 14 Sep 2020 12:29:53 -0700

On 8/14/2020 3:21 PM, Brandon Long wrote:
> What problems are you trying to solve with these?

Indeed.  Proposals should always provide a clear and compelling (or at 
least strong) statement of need, which divides into a statement of what 
the problem or opportunity is and a statement of community support for 
doing something about it.

The latter might not be readily available, but its essential before 
making progress.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: John C Klensin <[email-masked]>
Date: Mon, 14 Sep 2020 17:04:21 -0400

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=[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-smtp

---

From: Brandon Long <[email-masked]>
Date: Mon, 14 Sep 2020 17:38:50 -0700

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

---

From: John C Klensin <[email-masked]>
Date: Mon, 14 Sep 2020 23:26:59 -0400

--On Monday, September 14, 2020 17:38 -0700 Brandon Long
<[email-masked]> wrote:

> 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).
>...

I would be mildly astonished if you were doing anything else.
It raises some questions that I periodically worry about but
none of them are specific to SMTP or even email more generally.

best,
   john

---

From: iloveemail2 <[email-masked]>
Date: Tue, 15 Sep 2020 14:56:48 +0000

I do agree with both Mr. Long, Mr. Crocker, and Mr. Klensin here.

However the point of my email was not to create a formal proposal or anything, but rather to inspire discussion about how things are done. Every once in a while it is important to ruminate on how things are done and how that came to be. When this happens, we reaffirm the strength and the rigor of the standards you have made, and sometimes (but usually not in things like standards development) during this process we may find other unrelated problems.

I had also posted some of the things without knowing a lot of the stuff Mr. Long had said. If I had known that before hand obviously I wouldn't have posted it. So it is good that we have a "safe space" for discussion.

It is very good to see the public square in action and people discussing their ideas rationally.

---

From: John Bucy <[email-masked]>
Date: Tue, 15 Sep 2020 11:53:36 -0700

On Mon, Sep 14, 2020 at 5:40 PM Brandon Long <blong=
[email-masked]> wrote:

> 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.
>

We're making some progress on STARTTLS support in Envoy
https://github.com/envoyproxy/envoy/issues/9577

cheers
john