To increase the coverage of pipelining beyond the current ESMTP
PIPELINNG extension:
I'll first note that the extent to which the pipelining is both technically
feasible and operationally practical was carefully considered when the original
extension was specified. All of the options described here were considered
(plus at least one other having to do with the DATA command); and intentionally
excluded from the original 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.
FWIW, the IP address is the wrong key to use, since IP address can and do
change and/or get reassigned willy-nilly in some environments. The server host
name would be a better choice.
But the problem here is that there's no means of invalidating the cache in the
event of a server capability change. This can lead to clients failing to use
extensions that are available, including security-related extensions, or
attempting to use extensions that are available. There are also extensions like
SIZE who values cannot be usefully cached.
What this implies is that in order to be sure that things are OK, when the
synchronization point is reached prior to finalizing the transaction (and such
a point has to be included) the client must check and make sure the EHLO
response it got and the response it had cached are, modulo things like the
argument to the SIZE extension, the same in regards to the extensions the
client supports. If they aren't the client must then check and make sure none
of the changes mattered, and if they did, RSET and restart the transaction.
(The client also has the choice of playing it safe and restarting
unconditionally when the responses don't match.)
Given the past history of SMTP implementation issues I am more than a little
skeptical that clients will get this right.
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.
I'm afraid this part is a complete nonstarter. Spam engines do this routinely
and thus it's regularly used as a means of spam detection.
And the PIPE_CONNECT extension doesn't solve this problem. Sure, you
can require that an MTA which offers the PIPE_CONNECT extension allow
commands to be sent before the banner, but spam filtering SMTP proxies that
implement this sort of thing are common as dirt, and an MTA has no way
of knowing if any of them are present.
This is an accident waiting to happen. Nothing more and nothing less.
- 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 need to maintain multiple sets of capabilities further complicates
the implementation of this extension.
And while we're considering security layers, it should also be noted that the
recent increase in use of STARTTLS has necessarily led to an overall increase
in round trips, yet AFAIK this increase had had no significant impact on SMTP
operationally. This argues strongly that the need for additional optimization
in this regard isn't exactly urgent.
- 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?
I remain to be convinced of the utility here. The PIPELINING extension was
written at a time when network latency was a much bigger problem than it is
now, the average number of recipients per message was higher, messages were on
average smaller, and the ability to use multiple connections in parallel was
much more limited. It was a clear win at the time, and in hindsight perhaps was
a bit too cautious in its approach.
But the world is different now, the benefits of pipelining are less, let alone
taking it to the extreme, and iven the tradeoffs here I don't see how this
makes sense as a general purpose SMTP extension.
SUBMIT is another matter, but I think the work on JMAP is going to obviate
the need for SUBMIT optimizations.
Ned
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp