ietf-smtp
[Top] [All Lists]

[ietf-smtp] Proposal: SMTP Early Pipelining

2018-09-01 11:58:35
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?
-- 
Cheers,
  Jeremy

_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp