[Top] [All Lists]

Re: [ietf-smtp] smtp improvement?

2020-09-14 16:04:43
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.


--On Friday, August 14, 2020 17:59 +0000 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

Sent with ProtonMail Secure Email.

ietf-smtp mailing list

ietf-smtp mailing list

<Prev in Thread] Current Thread [Next in Thread>