Wietse, is this sufficient? I know it is not very detailed on the "impact analysis". Since pipelined "[message]<CRLF>.<CRLF>QUIT<CRLF>" works correctly, while in theory there could be other pipelining issues, none other that SAV come to mind.
The SMTP service at mail.global.frontbridge.com does not fully conform to RFC 2920 which defines the ESMTP PIPELINING extension. Specifically, in http://tools.ietf.org/html/rfc2920#section-3.1 we see that "RSET", "MAIL FROM", and "RCPT TO" are some of the commands that can appear anywhere in a pipelined group, while "EHLO", "DATA" and "QUIT" are some of the commands that can only appear as the last command in a group. Section 3.2 http://tools.ietf.org/html/rfc2920#section-3.2 specifies required server behaviour: (1) MUST respond to commands in the order they are received from the client. ... (9) MUST NOT flush or otherwise lose the contents of the TCP input buffer under any circumstances whatsoever. A correct implementation of RFC 2920 is recorded below from an intranet MSFT Exchange 2007 server. S> 220 exchange.example.com Microsoft ESMTP MAIL Service ready at Sun, 28 Nov 2010 02:41:13 -0500 C> EHLO amnesiac.example.com S> 250-exchange.example.com Hello [192.0.2.1] S> 250-SIZE 29999104 S> 250-PIPELINING S> 250-DSN S> 250-ENHANCEDSTATUSCODES S> 250-STARTTLS S> 250-AUTH S> 250-8BITMIME S> 250-BINARYMIME S> 250-CHUNKING S> 250 XEXCH50 C> MAIL FROM:<sen...@example.com> C> RCPT TO:<recipi...@example.com> C> RSET C> QUIT S> 250 2.1.0 Sender OK S> 250 2.1.5 Recipient OK S> 250 2.0.0 Resetting S> 221 2.0.0 Service closing transmission channel The four pipelined client commands "MAIL FROM", "RCPT TO", "RSET" and "QUIT" are all processed by the Exchange server which correctly returns four responses. The same test against the public MX host for Microsoft's Exchange engineering group yields similar results: S> 220 mail7.exchange.microsoft.com Microsoft ESMTP MAIL Service ready at Sat, 27 Nov 2010 23:43:19 -0800 C> EHLO amnesiac.example.com S> 250-mail7.exchange.microsoft.com Hello [192.0.2.1] S> 250-SIZE 104857600 S> 250-PIPELINING S> 250-DSN S> 250-ENHANCEDSTATUSCODES S> 250-STARTTLS S> 250-X-ANONYMOUSTLS S> 250-AUTH S> 250-X-EXPS NTLM S> 250-8BITMIME S> 250-BINARYMIME S> 250-CHUNKING S> 250-XEXCH50 S> 250 XSHADOW C> MAIL FROM:<sen...@example.com> C> RCPT TO:<recipi...@example.com> C> RSET C> QUIT S> 250 2.1.0 Sender OK S> 250 2.1.5 Recipient OK S> 250 2.0.0 Resetting S> 221 2.0.0 Service closing transmission channel Finally, testing mail.global.frontbridge.com we get non-conformant results. S> 220 DB3EHSMHS006.bigfish.com Microsoft ESMTP MAIL Service ready at Sun, 28 Nov 2010 07:47:08 +0000 C> EHLO amnesiac.example.com S> 250-DB3EHSMHS006.bigfish.com Hello [192.0.2.1] S> 250-SIZE 157286400 S> 250-PIPELINING S> 250-ENHANCEDSTATUSCODES S> 250-STARTTLS S> 250-AUTH S> 250-8BITMIME S> 250-BINARYMIME S> 250 CHUNKING C> MAIL FROM:<sen...@example.com> C> RCPT TO:<recipi...@example.com> C> RSET C> QUIT S> 250 2.1.0 Sender OK S> 221 2.0.0 Service closing transmission channel <Client sees premature TCP close while expecting two more responses> In this case the client's "RCPT TO" and "RSET" commands are "lost", and the "QUIT" response arrives out-of-order. One may speculate that the issue may be not in Microsoft Exchange, but rather in proxy software in front of the Exchange server. Correct response sequencing is recovered by breaking the group between "RSET" and "QUIT": S> 220 VA3EHSMHS032.bigfish.com Microsoft ESMTP MAIL Service ready at Sun, 28 Nov 2010 07:48:50 +0000 C> EHLO amnesiac.example.com S> 250-VA3EHSMHS032.bigfish.com Hello [192.0.2.1] S> 250-SIZE 157286400 S> 250-PIPELINING S> 250-ENHANCEDSTATUSCODES S> 250-STARTTLS S> 250-AUTH S> 250-8BITMIME S> 250-BINARYMIME S> 250 CHUNKING C> MAIL FROM:<sen...@example.com> C> RCPT TO:<recipi...@example.com> C> RSET S> 250 2.1.0 Sender OK S> 250 2.1.5 Recipient OK S> 250 2.0.0 Resetting C> QUIT S> 221 2.0.0 Service closing transmission channel Significantly, the FrontBridge SMTP servers correctly handle pipelining of DOT + QUIT at the end of a delivery transaction, perhaps because this "group" has only two elements, or is otherwise treated specially. S> 220 DB3EHSMHS003.bigfish.com Microsoft ESMTP MAIL Service ready at Sun, 28 Nov 2010 07:27:55 +0000 C> EHLO amnesiac.example.com S> 250-DB3EHSMHS003.bigfish.com Hello [192.0.2.1] S> 250-SIZE 157286400 S> 250-PIPELINING S> 250-ENHANCEDSTATUSCODES S> 250-STARTTLS S> 250-AUTH S> 250-8BITMIME S> 250-BINARYMIME S> 250 CHUNKING C> MAIL FROM:<sen...@example.com> C> RCPT TO:<recipi...@example.com> C> DATA S> 250 2.1.0 Sender OK S> 250 2.1.5 Recipient OK S> 354 Start mail input; end with <CRLF>.<CRLF> C> [message-content]<CRLF>.<CRLF> C> QUIT S> 250 2.6.0 <20101128070828.ab036504...@amnesiac.example.com> [InternalId=11073071] Queued mail for delivery S> 221 2.0.0 Service closing transmission channel -- Viktor. P.S. The new "[InternalId=...]" in the "DOT" response is encouraging, have not seen these from MSFT Exchange before, this should make tracking down problems easier when a single message is carried in multiple envelopes.
