Subject: [ietf-smtp] Proposal: SMTP Early Pipelining

From: Jeremy Harris <[email-masked]>
Date: Sat, 1 Sep 2018 17:58:11 +0100

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

---

From: John C Klensin <[email-masked]>
Date: Sat, 01 Sep 2018 14:32:16 -0400

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
<[email-masked]> wrote:

> A new extension, keyword PIPE_CONNECT, to advertise the
> capability. No new commands or command parameters.
> 
> 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.
> 
>   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.
> - 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.
> 
>

---

From: "John Levine" <[email-masked]>
Date: 1 Sep 2018 15:51:41 -0400

In article <F03BA3F206076D16E3DF5BDE@PSB> you write:
>messages ...

Agreed.  The average number of recipients in legit mail has also
dropped to close to 1, because bulk mail is pretty much all customized
per recipient, so the number of round trips even without pipelining is
pretty small.  (There's a Chinese spambot that sends 21 receipts per
message, but it doesn't count.)  If you want to get more mail through,
send it in parallel.  My not particularly large mail server easily
handles 50 connections in each direction and I could increase it to
200 if I needed to.

Also, checking for clients that send HELO/EHLO before the greeting
remains a surprisingly effective way to recognize spambots.  You could
sort of imagine ways to whitelist clients who'd seen an early
pipelining flag, but in the common case that there's a bunch of MTAs
behind a single pool of IPs and a load balancer, keeping the cache in
sync and guessing what IPs are in a client pool wouldn't work very
well.  I'd rather crank up the concurrency than lose early talker
checks.

R's,
John

---

From: Phil Pennock <[email-masked]>
Date: Sun, 2 Sep 2018 01:16:59 -0400

On 2018-09-01 at 15:51 -0400, John Levine wrote:
> remains a surprisingly effective way to recognize spambots.

How about for internal connections between a front-end mail-server which
does all the spam/malware filtering and a backend layer which handles
storage etc?

While I'm no longer a postmaster for a commercial service, I could see
it being useful to optimise the traffic flows there.

The same sorts of places where forward callouts can make sense.  If
you're going to do forward callouts for verification, or even
cut-through delivery, then reducing the start-up overhead should make
life somewhat easier and reduce latency in a cut-through.

Because of exactly the concern you raise, I'd be hesitant to enable such
a feature directly facing most of the Internet, but would certainly set
it up within a cluster (not already using non-SMTP for internal
handling) and could see it as a useful thing for perimeter servers to
enable on a whitelist for connections from high-volume peers.

The round-trips are less of an issue for local services such as MLMs
injecting mail, but perhaps still interesting.  It might also be an
interesting mode to enable for connections from localhosts, as various
senders which aren't fully SMTP-enabled could then just pipeline
everything.  `cat | nc` becomes a potentially valid approach to send
mail on your own systems.  That's not _bad_, though it's non-portable to
other environments.

Certainly makes it easier to set up monitoring probes which are designed
around the HTTP model, if they can just connect and send stuff and have
it work.  Some of those don't really do expect-style interactions.
Whitelist your monitoring services and you're good to go.

-Phil

---

From: John C Klensin <[email-masked]>
Date: Sun, 02 Sep 2018 04:11:08 -0400

And this is an example of the main reason I would like to see
the proposal in I-D form.  If the idea is unsuitable or not
worth the trouble for general use (as (as I surmised and John L.
and Michael seem to confirm) but useful for particular special
cases (as Phil suggests), being able to reform a draft with a
clear statement about applicability -- possibly including a
whitelist of permitted address ranges -- would be important.

Jeremy, I can't recall your posting an Internet Draft in the
past -- if you need a hand getting started, drop me a note
off-list.

best,
   john

--On Sunday, September 2, 2018 01:16 -0400 Phil Pennock
<[email-masked]> wrote:

>> Also, checking for clients that send HELO/EHLO before the
>> greeting remains a surprisingly effective way to recognize
>> spambots.
> 
> How about for internal connections between a front-end
> mail-server which does all the spam/malware filtering and a
> backend layer which handles storage etc?
> 
> While I'm no longer a postmaster for a commercial service, I
> could see it being useful to optimise the traffic flows there.
> 
> The same sorts of places where forward callouts can make
> sense.  If you're going to do forward callouts for
> verification, or even cut-through delivery, then reducing the
> start-up overhead should make life somewhat easier and reduce
> latency in a cut-through.
> 
> Because of exactly the concern you raise, I'd be hesitant to
> enable such a feature directly facing most of the Internet,
> but would certainly set it up within a cluster (not already
> using non-SMTP for internal handling) and could see it as a
> useful thing for perimeter servers to enable on a whitelist
> for connections from high-volume peers.
> 
> The round-trips are less of an issue for local services such
> as MLMs injecting mail, but perhaps still interesting.  It
> might also be an interesting mode to enable for connections
> from localhosts, as various senders which aren't fully
> SMTP-enabled could then just pipeline everything.  `cat | nc`
> becomes a potentially valid approach to send mail on your own
> systems.  That's not _bad_, though it's non-portable to other
> environments.
> 
> Certainly makes it easier to set up monitoring probes which
> are designed around the HTTP model, if they can just connect
> and send stuff and have it work.  Some of those don't really
> do expect-style interactions. Whitelist your monitoring
> services and you're good to go.
> 
> -Phil
> 
> _______________________________________________
> ietf-smtp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-smtp

---

From: Hector Santos <[email-masked]>
Date: Sun, 02 Sep 2018 09:35:41 -0400

+1 for an I-D and group discussion on it with additional considerations.

This appears to be a client-side optimization.  Adding a server-side 
optimization component to this to reduce server-side 
Authentication/Authorization/Verification hooks, shims and callouts, 
might add worth to the consideration.  Off hand, for example:

     Server advertising PIPE_CONNECT MAY include optimization
     for using server-side cached authentication, authorization,
     verification session information estasblished by augmented
     protocols such SPF and other high overhead session-level
     filters. Server-side cached PIPE_CONNECT data SHOULD have an
     expiration time and cached data MUST only be applicable to
     subsequent connections from the same IP address and client
     session data, e.e. EHLO/HELO, MAIL FROM, RCPT TO.

-- 
HLS

---

From: John C Klensin <[email-masked]>
Date: Sun, 02 Sep 2018 10:18:03 -0400

--On Sunday, September 2, 2018 09:35 -0400 Hector Santos
<[email-masked]> wrote:

> This appears to be a client-side optimization.  Adding a
> server-side optimization component to this to reduce
> server-side Authentication/Authorization/Verification hooks,
> shims and callouts, might add worth to the consideration.  Off
> hand, for example:
 
>      filters. 

Hector,

It seems to me that nothing prevents a server from doing many of
those things now, with no extension advertisement or client
authorization needed.  Whether they would be a good idea or not
is another matter: all the server knows at initial connection
time is a client IP address and, at least within some limits,
the bad bad guys know how to spoof those if they are
sufficiently motivated and it provides almost no information if
a message is relayed through a very large provider with fairly
weak authentication of some of its web users and MUA clients.

> Server-side cached PIPE_CONNECT data SHOULD have
> an

I am trying to figure out how that would usefully work beyond
just remembering whether a client pipelines garbage and whether
even that would be useful as a separate operation.  

Let me illustrate by working through a mini-example.   In the
normal (non-pipelined) flow of an SMTP session, suppose a
session is opened and then the server concluded that the MAIL
command fails (e.g., the sender information fails SPF or DKIM
checks).  Does your server remember that failure from one
session to the next?  If so, what does it do with it?  Remember
that particular backward-pointing address as invalid?   Decide
to not accept anything from that domain, or connections from
that IP address again (and how does one manage the cache in that
case)?  

The issue of whether that would be a good idea aside (I
obviously have my doubts), how would it change if the EHLO and
MAIL commands were pipelines?  If RCPT were part of the
pipeline, it would obviously be discarded and an error reply
sent, but, in the non-pipelined case, the rejection would be
sent after MAIL (similarly for EHLO and MAIL), so that doesn't
even save a turnaround unless you would use the cached
information to decline the initial connection-opening request on
an IP address basis.  But doing that doesn't interact with
pipelining at all and, worse, given the ability to spoof an IP
address in a situation that does not require TCP-level
connection establishments, be an invitation to the sort of DoS
attack in which the attacker says "please shoot yourself in the
foot" and the server complies.

So, again, I would like to see an I-D that includes an analysis
of sequencing, advantages, and costs.

As with Phil's observation, it may be useful to remember that
nothing prevents a server from giving a specific client that it
an authenticate and authorize to its satisfaction special
treatment.

Perhaps it is also time for everyone to remember the admonition
that, if memory serves, was Marshall Rose's key contribution to
RFC 1425, the third full paragraph of Section 3 ("It must be
emphasized..."): any extension adds complexity and, while I
(speaking personally and not attributing this to Marshall or
anyone else) would far prefer to have extensions that are going
to be deployed comprehensibly and publicly documented, low-value
extensions add complexity to the protocol and demands on server,
and often client, implementations and are therefore usually best
avoided.

 best,
     john

---

From: "John Levine" <[email-masked]>
Date: 2 Sep 2018 11:19:25 -0400

In article <0ADD62DB514A798127616369@PSB> you write:
>worth the trouble for general use ...

Agreed.  If you know who the client is or have other ways of dealing
with bad actors, e.g., submission servers where senders have to
authorize first or present a client cert in STARTTLS, you might as
well go as fast as you can.

Happy to help read or edit the I-D.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Sun, 02 Sep 2018 13:11:35 -0400

On 9/2/2018 10:18 AM, John C Klensin wrote:
> those things now,

+1 and they may for the most part.

> ...

I see your points and I agree.

Overall, my thinking is in the area of "automated but temporary trust" 
to help reduce session overhead redundancy.  However, it is well noted 
these optimization considerations are lessen with today's hardware and 
performance -- just repeat it.  Let's not fall victim to complexity 
and potential timing and syncing exploits.

> of sequencing, advantages, and costs.

+1

-- 
HLS

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sun, 2 Sep 2018 19:31:55 +0200

Assuming that TLS is used (which the IETF considers to be necessary by 
default, right?), then I think practically the same effect could be reached 
by:

1. Permit immediate STARTTLS, without waiting for the banner or EHLO.
2. Let the client send (AUTH+)MAIL+RCPT+DATA in one batch inside TLS.
3. Require TLS 1.3 support for compliant clients/servers.

Given that, a client should only need to wait for one roundtrip during 
STARTTLS and for one roundtrip during DATA.

Arnt

---

From: Claus Assmann <[email-masked]>
Date: Sun, 2 Sep 2018 10:36:28 -0700

> 1. Permit immediate STARTTLS, without waiting for the banner or EHLO.

Hmm, like smtps?

---

From: Ned Freed <[email-masked]>
Date: Sun, 02 Sep 2018 08:38:19 -0700 (PDT)

> To increase the coverage of pipelining beyond the current ESMTP

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.

> 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.

>   those extensions) without waiting for either banner or

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.

> 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.

> 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

---

From: "John Levine" <[email-masked]>
Date: 2 Sep 2018 16:34:54 -0400

>> 1. Permit immediate STARTTLS, without waiting for the banner or EHLO.

Sort of, except that smtps is really submits. There's no way to signal
to an SMTP client that it can use smtps so in practice it's only used
for submission.  People have suggested kludges like using the high
bits of the MX priority value but they never went anywhere.

If we really want to speed up mail transmission over private links, we
can do a lot better than SMTP.  Twenty years ago Dan Bernstein offered
a stripped down QMTP:

https://cr.yp.to/proto/qmtp.txt

It still works fine, except that now it'd need some way for the server
to tell the client about options that affect what the client can send,
like BINARYMIME and SMTPUTF8 and RRVS.

---

From: Jeremy Harris <[email-masked]>
Date: Mon, 3 Sep 2018 14:13:13 +0100

> past -- if you need a hand getting started, drop me a note

With John's help (thanks!) I've now done this.

The draft reflects my original thinking and does not
yet incorporate any of the suggestions and objections
received.

> A new version of I-D, draft-harris-early-pipe-00.txt
> has been successfully submitted by Jeremy Harris and posted to the
> IETF repository.
> 
> Name:		draft-harris-early-pipe
> Revision:	00
> Title:		SMTP Service Extension for Early Pipelining
> Document date:	2018-09-03
> Group:		Individual Submission
> Pages:		6
> URL:            https://www.ietf.org/internet-drafts/draft-harris-early-pipe-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-harris-early-pipe/
> Htmlized:       https://tools.ietf.org/html/draft-harris-early-pipe-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-harris-early-pipe
> 
> 
> Abstract:
>    PIPE_CONNECT is an SMTP extension supporting the pipelining of
>    banner, EHLO and one folling command in an SMTP conversation.  It
>    permits a reduction in delivery latency by eliminating a nunmber of
>    network round-trips.

-- 
Cheers,
  Jeremy

---

From: Jeremy Harris <[email-masked]>
Date: Mon, 3 Sep 2018 14:35:22 +0100

>> 1. Permit immediate STARTTLS, without waiting for the banner or EHLO.

Perhaps that should be a TCP-level thing.
Is there a TCP-AO-with-encryption ?

-- 
Cheers,
  Jeremy

---

From: Jeremy Harris <[email-masked]>
Date: Mon, 3 Sep 2018 15:28:31 +0100

> name would be a better choice.

The name, on its own, has its own potential for problems in complex
environments.  Even a DNS-roundrobin to a mismatched set of servers.
On the plus side, a client might see fewer names than IPs.

Operators don't have to advertise the extension in such environments.
We could add guidance for cases where it won't work well.

> SIZE who values cannot be usefully cached.

This was the issue prompting the invalidate-cache-on-SMTP-error
requirement.

I don't think that capability upgrades at a server are a big issue.
So long as the client does a time-based invalidate it will eventually
pick up the change, and in the meantime it is no worse off than an
unaware (of the new extension) client.

> unconditionally when the responses don't match.)

[Similar suggestion from John Klensin]

The downside is that we have to do the EHLO response parsing, previously
avoidable, but that is not a big point.  Overall I'm happy to add
this in as a MUST.

We might ask how often downgrades are expected.  I'd think "hardly
ever", outside the pathological environments considered above.

> and thus it's regularly used as a means of spam detection.

I fully agree that you don't want to advertise this globally.
Probably you already don't advertise PIPELINING globally for the
same reasons.  You may still make it available selectively.

>  spam filtering SMTP proxies that

I'm unsure why an MTA operator would not be aware of any proxies he
is operating.

> in this regard isn't exactly urgent.

I agree, it is a weak argument.  It is only efficiency and latency.

[I wrote:]
>> to client-starts.

Obviously, more roundtrips are saved when TFO is also used.

[John Klensin wrote:]
> a bit too cautious in its approach.

Agreed on the number of recipients.  On the other hand, I think we see
more single-message connections (less batching).

On message size: yes it has increased - but for that we're into
bandwidth issues, not roundtrip time limitations; the data portion
of the SMTP connection is internally pipelined by TCP.

-- 
Cheers,
  Jeremy

---

From: Ned Freed <[email-masked]>
Date: Mon, 03 Sep 2018 08:11:05 -0700 (PDT)

> This was the issue prompting the invalidate-cache-on-SMTP-error

That's nowhere near sufficient, as it fails to address the issue of
extensions not being used when the need to be.

> I don't think that capability upgrades at a server are a big issue.

I strongly disgagree.

> unaware (of the new extension) client.

Sure, no harm in not using STARTTLS when it becomes available. Or other
security-related extensions, at least one of which (REQUIRETLS) is about to
exit the standards process.

No harm at all.

> ever", outside the pathological environments considered above.

Downgrades are not the major issue here.

> same reasons.  You may still make it available selectively.

Do you really trust people to get this right?

				Ned

---

From: John C Klensin <[email-masked]>
Date: Mon, 03 Sep 2018 12:18:51 -0400

--On Monday, September 3, 2018 08:11 -0700 Ned Freed
<[email-masked]> wrote:

>> Probably you already don't advertise PIPELINING globally for
>> the same reasons.  You may still make it available
>> selectively.
> 

Based on experience with people getting almost anything wrong
that it is possible to get wrong and my concern about marginal
complexity, I certainly don't.   I think that suggests that, if
this is going to go forward, a very careful explanation in the
text about what is necessary to get it right is a requirement.
Then we can at least worry about people who won't bother to read
that text rather than those who will guess at what is needed to
get it right and leave things out.

That, of course, gets back to the question of whether the
complexity this adds, including both the complexity of getting
it right and the complexity of dealing with folks who get it
wrong is worth it in terms of payoff..  Still trying to reserve
judgment.

Another thought along those lines: for the special cases, such
as submission and within a collection of closely-related
machines, out of band agreements might be a better option than a
formal SMTP extension, more or less along the lines of the
handwaving about similar situations in the MUA-> submission
server spec.   In part because you are not requiring any sort of
client announcement, an agreement among a set of related systems
to go ahead and do this.  That would have the advantage that, if
all of the systems legitimately using the technique among
themselves are under single operational management, there is a
management mechanism for deciding to not do it any more (even if
that is a rare case) and everyone can get the word as to when to
flush the caches to take advantage of new features.   From the
standpoint of that approach, we also have a relatively
non-complex answer to the "what is someone gets it wrong and
uses this with a target server that can't/won't handle it"
question: either the antispam mechanisms kill the transaction,
the server sends out a lot of 5yz "command out of sequence"
responses, or you somehow luck out.   None of those is a really
bad outcome other than wasting some server time and the client
operator(s)  would get strong incentives to clean up their act.

I don't know if there are useful cases for this that do not fall
under the above umbrella.

best,
   john

---

From: Tony Finch <[email-masked]>
Date: Mon, 3 Sep 2018 19:28:04 +0100

> To increase the coverage of pipelining beyond the current ESMTP

This is a fun idea and I have some thoughts that I encourage you to steal
with liberal abandon:

http://people.ds.cam.ac.uk/fanf2/hermes/doc/qsmtp/draft-fanf-smtp-quickstart-a-00.html

http://people.ds.cam.ac.uk/fanf2/hermes/doc/qsmtp/draft-fanf-smtp-quickstart-b-00.html

These died on the grounds of being a ridiculously over-engineered paper
protocol. The simpler -a version reduces connection startup time from 9
round trips to 5, not counting any TLS optimizations (see the summaries in
the appendix). The -b version includes a capability cache and stuff I
forget.

On the other hand I think faster message submission is more likely to make
headway as part of JMAP.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
a fair, free and open society

---

From: John C Klensin <[email-masked]>
Date: Mon, 03 Sep 2018 16:09:25 -0400

--On Monday, September 3, 2018 19:28 +0100 Tony Finch
<[email-masked]> wrote:

>> To increase the coverage of pipelining beyond the current
>> ESMTP PIPELINNG extension:
> 
> This is a fun idea and I have some thoughts that I encourage
> you to steal with liberal abandon:
>...
> These died on the grounds of being a ridiculously
> over-engineered paper protocol.
>...

Thanks.  This caused me to think of a different option with few
fewer turnarounds and less complexity.   The following is
proposed as a thought exercise and mostly (but not entirely) in
jest.

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.  In honor of
BITNET/EARN/NETNORTH and, to some extent, RFC 2442, let's call
it BSMTP, with the same argument that would have been used with
EHLO.  This extension is intended for use only by prearrangement
among related parties and other consenting adults  if only
because implementations that did not recognize it (including
anti-spam system) could be expected to treat receipt of "BSMTP"
after the greeting message as equivalent to "ThisIsAnAttack" or
"HereComesTheSpam".  

After sending that command, the client waits a short period of
time to see if the server closes the connection or sends back a
5yz response,  If the server sends a 2yz response or does not
respond usefully, the client sends as much stuff in a single
stream as it thinks appropriate, potentially including multiple
messages without pausing to wait for the server to send out
response codes.  

Variations would include requiring that this be done only over
TLS or treating BSMTP as including STARTTLS with appropriate
arguments.

Really few required turnarounds :-(

   john

---

From: "John Levine" <[email-masked]>
Date: 5 Sep 2018 19:57:57 +0200

In article <C8742199DE7666C7C00A3F6C@PSB> you write:
>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.

(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.

R's,
John

---

From: Ned Freed <[email-masked]>
Date: Wed, 05 Sep 2018 11:10:58 -0700 (PDT)

> 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.

> not going to use our mutant SMTP, there's no reason for it to look

On the contrary, there's a real cost to introducing protocols with similar
functionality but slightly different semantics. Especially for so little
benefit.

				Ned

---

From: John Bucy <[email-masked]>
Date: Wed, 5 Sep 2018 16:37:57 -0700

> Ignoring connection setup and capabilities negotiation, so does pipelined

btw when gmail's smtp client is offered pipelining+chunking, it pipelines a
bdat with the first 65k of the payload along with mail+rcpt but then waits
for one of the rcpts to succeed before sending the rest.

cheers
john

---

From: Ned Freed <[email-masked]>
Date: Wed, 05 Sep 2018 16:40:08 -0700 (PDT)

> for one of the rcpts to succeed before sending the rest.

That's a cute trick. I'd have to check the code to be sure, but I think our
approach right now is to only pipeline the BDAT when the message is small
enough to fit in the buffer.

				Ned

---

From: Jeremy Harris <[email-masked]>
Date: Thu, 6 Sep 2018 09:23:36 +0100

> for one of the rcpts to succeed before sending the rest.

Likewise, Exim pipelines the BDAT and message if it's small enough
for the output buffer.  If larger it pipelines a BDAT and the message
headers.

I'm not aware of any MTA doing header-inspection and early-reject of
later BDATs, but the support is there.
-- 
Cheers,
  Jeremy