Jeremy.
This seems interesting enough to be worth writing up as an I-D.
My entirely subjective impression is that the typical message
content transmitted over SMTP is moderately long (in terms of
packets and acks). That differs from years ago when SMTP was
often used to transmit a lot of what amounted to control
messages (as well as, occasionally SOML, SEND, and their
pseudo-IM friends) so I'm curious about why you think saving
1.5-2.5 turnarounds is enough of an improvement to justify yet
another path through SMTP code and more client database
information, but I definitely don't have a strong opinion about
that.
Please also think a bit more about the cache expiration
situation. In particular, if a client opens a connection to a
particular server, sees the extension advertised, and remembers
that information for next time, my quick impression is that it
should (probably MUST) check that the extension advertisement
appears every time it relies on the cached information and that,
if it does not, the cache entry MUST be flushed immediately.
Relying on the feature being supported when it isn't because the
server has changed its mind would, I assume, cost extra
turnarounds as the client and server backed off.
best,
john
--On Saturday, September 1, 2018 17:58 +0100 Jeremy Harris
<jgh(_at_)wizmail(_dot_)org> wrote:
To increase the coverage of pipelining beyond the current ESMTP
PIPELINNG extension:
A new extension, keyword PIPE_CONNECT, to advertise the
capability. No new commands or command parameters.
A client seeing the keyword in a server's EHLO response MAY
cache information about the response and the IP address of the
server. The information MUST include the TLS status (cleartext
versus encrypted) for which it applies.
A client having valid cached information for cleartext use
may use that information on subsequent connections to that IP.
If such cached information includes this extension:
- the client MAY send an EHLO command without waiting
for receipt of a banner from the server, and MAY send a
following STARTTLS or AUTH command (if permitted by cached
information of those extensions) without waiting for either
banner or ehlo-response.
- the client MAY send an EHLO command followed by any sequence
of MAIL, RCPT and DATA (or BDAT) commands permitted by
cached information of the traditional PIPELINING extension,
all before waiting for any responses.
After a successful STARTTLS negotiation and TLS startup, a
client having valid cached information for encrypted use may
use that information on connections to that IP.
If such cached information includes this extension:
- the client MAY send an EHLO command followed by any sequence
of MAIL, RCPT and DATA (or BDAT) commands permitted by
cached information of the traditional PIPELINING extension,
all before waiting for any responses.
- the client MAY send an EHLO command followed by an AUTH
command, if permitted by cached information of that
extension, before waiting for any responses.
In all cases the traditional presence and sequencing of
commands MUST be used by the client, the checking of responses
MUST be done by the client, and the presence and sequencing of
responses MUST be used by the server.
The client MAY invalidate cached information at any time.
Information MUST be invalidated upon any error (4xx or 5xx)
response from the server for an smtp transaction using this
extension. It is RECOMMENDED that information also be
invalidated after a limited time.
----------
Discussion :-
You can take 1.5 roundtrips out of a cleartext SMTP
connection, 2.5 out of a STARTTLS one.
It combines nicely with TCP Fast-Open, as it converts the
protocol to client-starts. However, they are not tied
together; both are individually useful.
I'm not especially wedded to the keyword. A different word
would be fine if people have opinions. Alternatively we could
extend the PIPELINING extension with an optional parameter to
advertise the capability.
I have an implementation up and running.
Is the WG interested?
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp