| Main Archive Page > Month Archives > postfix-users archives |
Re: FrontBridge RFC 2920 write-up
From: Wietse Venema <wietse_at_nospam>Date: Sun Nov 28 2010 - 18:37:41 GMT
To: postfix-users@postfix.org
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:<sender@example.com>
> C> RCPT TO:<recipient@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:<sender@example.com>
> C> RCPT TO:<recipient@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:<sender@example.com>
> C> RCPT TO:<recipient@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:<sender@example.com>
> C> RCPT TO:<recipient@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:<sender@example.com>
> C> RCPT TO:<recipient@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.AB036504373@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.
>
>