In article <C8742199DE7666C7C00A3F6C@PSB> you write:
If one wants super-efficient pipelining, one doesn't send EHLO,
one sends a special session-opening command and sends it without
waiting for the 220 greeting message. ...
This sounds ever more like djb's qmtp from 20 years ago, which does
one (1) round trip per message.
Ignoring connection setup and capabilities negotiation, so does pipelined
SMTP + BDAT.
And in these intra-ADMD scenarios setup and negotiation can and should be
amortized across multiple messages. When you manage to push hundreds or
thousands of messages across a single connection on average, who cares about
the round trips it took to set it up?
Long timeouts and/or connection pinning are the obvious way to implement this,
but depending on load they may not even be necessary.
All that said, if you really want to pursue this and have a security
layer requirement, the first step should be to switch to smtps in order
to take advantage of the 0RTT support in TLS 1.3.
https://cr.yp.to/proto/qmtp.txt
(I'm certainly not saying it's perfect, but I've used it and its
junior version QMQP for ages among my internal hosts.)
It seems to me that if both ends have to know in advance that they're
not going to use our mutant SMTP, there's no reason for it to look
like SMTP at all.
On the contrary, there's a real cost to introducing protocols with similar
functionality but slightly different semantics. Especially for so little
benefit.
Ned
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp