Re: [ietf-smtp] CHUNKING and PIPELINING

[Viktor Dukhovni <[e-mail]>]

> On Mar 8, 2021, at 2:31 AM, Ned Freed <[e-mail]> wrote:
> 
>> What Jeremy did not mention is that he's seeing interoperability
>> issues (reportedly with Google and IIRC Yahoo) when pipelining
>> "BDAT nnnn LAST<CRLF>QUIT<CRLF>".

Oops (I guess that was clear from context), I meant:

	BDAT nnnn LAST<CRLF>
	...<nnnn> bytes of data...
	QUIT<CRLF>

>> Did Google, et. al. not implement PIPELINING for BDAT correctly?
>> It is not (to me) entirely obvious from the spec.  The PIPELING
>> semantics should have been spelled out more clearly in 3030.
> 
> And the handling of invalid BDAT (especially the second example I gave) as
> well. But I think common sense is all you need to see that this should be OK
> and there's something wrong in Google-Yahoo-land.

That's certainly what I'd like to be the case, but I am not sure the
specification succeeds in making it clear.  The only example shows
QUIT sent separately:

   https://tools.ietf.org/html/rfc3030#section-4.2

   R: <wait for connection on TCP port
   S: <open connection to server>
   R: 220 cnri.reston.va.us SMTP service ready
   S: EHLO ymir.claremont.edu
   R: 250-cnri.reston.va.us says hello
   R: 250-PIPELINING
   R: 250-BINARYMIME
   R: 250 CHUNKING
   S: MAIL FROM:<[e-mail]> BODY=BINARYMIME
   S: RCPT TO:<[e-mail]>
   S: RCPT TO:<[e-mail]>
   R: 250 <[e-mail]>... Sender and BINARYMIME ok
   R: 250 <[e-mail]>... Recipient ok
   R: 250 <[e-mail]>... Recipient ok
   S: BDAT 100000
   S: (First 10000 octets of canonical MIME message data)
   S: BDAT 324
   S: (Remaining 324 octets of canonical MIME message data)
   S: BDAT 0 LAST
   R: 250 100000 octets received
   R: 250 324 octets received
   R: 250 Message OK, 100324 octets received
   S: QUIT
   R: 221 Goodbye

> Has anyone tried pipelining RSET after BDAT LAST, or QUIT after the trailing
> dot on a regular DATA on these servers? (Our client doesn't attempt any of this
> because we can't tell right away whether or not there's another message we want
> to send on this connection, so we don't know what command we're going to send
> next and we don't want to wait to find out.)

With plain old "DATA" (Postfix support CHUNKING only in the server role), Postfix
acting as a client always pipelines ".<CRLF>QUIT<CRLF>" and has no trouble with
Google or Yahoo.

[ Postfix only caches connections when there's a sufficient backlog
  for the same destination, so under "normal" conditions we know to
  close the connection right away. ]

So it seems it is specifically "BDAT LAST" + (ultimately) QUIT that
these providers are allergic to.

I take it there's at least agreement on this list that pipelining of
these is not definitely proscribed.  And perhaps even expected?  If
so, perhaps (unless they're already here) time to reach out to Google
et. al., though in the meantime a conservative implementation might
need to not enable pipelining after BDAT by default.

-- 
	Viktor.