Subject: [ietf-smtp] smtp improvement?

From: iloveemail2 <[email-masked]>
Date: Fri, 14 Aug 2020 17:59:23 +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.

---

From: Brandon Long <[email-masked]>
Date: Fri, 14 Aug 2020 15:21:10 -0700

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=
[email-masked]> wrote:

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