Victor Duchovni: > > 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.
Thanks. I'll put this up on a page so people can refer to this when the problem happens. The URL would be: http://www.postfix.org/workarounds.html It will take 24 hours to propagate once I have set this up. Wietse > 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. > >
