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(_dot_)com(_at_)dmarc(_dot_)ietf(_dot_)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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp