Loading ...
Sorry, an error occurred while loading the content.

Re: postfix 2.8 and upper don't close connection with smtpd_proxy_filter

Expand Messages
  • Wietse Venema
    ... Why is this a problem, three years after the change was made? Wietse
    Message 1 of 17 , Apr 22, 2013
    • 0 Attachment
      Ludovic LEVET:
      > Hi,
      >
      > Since i have upgrade my postfix from 2.6.x to 2.8.x or 2.10.x postfix
      > don't send the command QUIT after the response (code 250) to END-OF-MESSAGE.
      > dedi.ludosoft.org[127.0.0.1]

      Why is this a problem, three years after the change was made?

      Wietse
    • Ludovic LEVET
      Sorry to not upgrade before, but 2.6.X version is already supported version ... :-) Sorry to see that this upper version brake the RFC protocol submission
      Message 2 of 17 , Apr 22, 2013
      • 0 Attachment
        Sorry to not upgrade before, but 2.6.X version is already supported
        version ... :-)
        Sorry to see that this upper version brake the RFC protocol submission
        (when it talk to proxy) since 3 years ...

        Ludovic.


        Le 22/04/2013 18:21, Wietse Venema a écrit :
        > Ludovic LEVET:
        >> Hi,
        >>
        >> Since i have upgrade my postfix from 2.6.x to 2.8.x or 2.10.x postfix
        >> don't send the command QUIT after the response (code 250) to END-OF-MESSAGE.
        >> dedi.ludosoft.org[127.0.0.1]
        > Why is this a problem, three years after the change was made?
        >
        > Wietse
      • Ludovic LEVET
        no brake but broke .... See RFC5321 : http://www.ietf.org/rfc/rfc5321.txt 4.1.1.10. QUIT (QUIT) This command specifies that the receiver MUST send a 221 OK
        Message 3 of 17 , Apr 22, 2013
        • 0 Attachment
          no brake but broke ....

          See RFC5321 :

          http://www.ietf.org/rfc/rfc5321.txt

          4.1.1.10. QUIT (QUIT)

          This command specifies that the receiver MUST send a "221 OK" reply,
          and then close the transmission channel.

          The receiver MUST NOT intentionally close the transmission channel
          until it receives and replies to a QUIT command (even if there was an
          error). The sender MUST NOT intentionally close the transmission
          channel until it sends a QUIT command, and it SHOULD wait until it
          receives the reply (even if there was an error response to a previous
          command). If the connection is closed prematurely due to violations
          of the above or system or network failure, the server MUST cancel any
          pending transaction, but not undo any previously completed
          transaction, and generally MUST act as if the command or transaction
          in progress had received a temporary error (i.e., a 4yz response).

          The QUIT command may be issued at any time. Any current uncompleted
          mail transaction will be aborted.

          Syntax:

          quit = "QUIT" CRLF



          Ludo.


          Le 22/04/2013 19:17, Ludovic LEVET a écrit :
          > Sorry to not upgrade before, but 2.6.X version is already supported
          > version ... :-)
          > Sorry to see that this upper version brake the RFC protocol submission
          > (when it talk to proxy) since 3 years ...
          >
          > Ludovic.
          >
          >
          > Le 22/04/2013 18:21, Wietse Venema a écrit :
          >> Ludovic LEVET:
          >>> Hi,
          >>>
          >>> Since i have upgrade my postfix from 2.6.x to 2.8.x or 2.10.x postfix
          >>> don't send the command QUIT after the response (code 250) to
          >>> END-OF-MESSAGE.
          >>> dedi.ludosoft.org[127.0.0.1]
          >> Why is this a problem, three years after the change was made?
          >>
          >> Wietse
          >
        • Wietse Venema
          ... If your server cannot handle a missing QUIT, get a better one. Wietse
          Message 4 of 17 , Apr 22, 2013
          • 0 Attachment
            Ludovic LEVET:
            > no brake but broke ....

            If your server cannot handle a missing QUIT, get a better one.

            Wietse
          • Ludovic LEVET
            This is not a reply ... http://www.ietf.org/rfc/rfc5321.txt Chapter 4.1.1.10. If we can t write proper code and respect RFC for interoperability, the better is
            Message 5 of 17 , Apr 23, 2013
            • 0 Attachment
              This is not a reply ...

              http://www.ietf.org/rfc/rfc5321.txt
              Chapter 4.1.1.10.

              If we can't write proper code and respect RFC for interoperability, the
              better is to change of work ... We are not in the world of Microsoft,
              and made what we want like we want and the rest of the world must be
              complied with...

              Ludovic.


              Le 22/04/2013 20:38, Wietse Venema a écrit :
              > Ludovic LEVET:
              >> no brake but broke ....
              > If your server cannot handle a missing QUIT, get a better one.
              >
              > Wietse
            • Bastian Blank
              Please fix your MUA, it produces TOFU. ... Not showing what the actual problem is, is no question either. Especially, why are you the only person experiencing
              Message 6 of 17 , Apr 23, 2013
              • 0 Attachment
                Please fix your MUA, it produces TOFU.

                On Tue, Apr 23, 2013 at 11:48:42AM +0200, Ludovic LEVET wrote:
                > This is not a reply ...

                Not showing what the actual problem is, is no question either.
                Especially, why are you the only person experiencing this in over three
                years?

                > http://www.ietf.org/rfc/rfc5321.txt
                > Chapter 4.1.1.10.

                You miss 3.8.

                Please show a session _transcripts_ for the problem you are talking
                about.

                Bastian

                --
                Madness has no purpose. Or reason. But it may have a goal.
                -- Spock, "The Alternative Factor", stardate 3088.7
              • Ludovic LEVET
                Hi Bastian, The transcription is on mail first mail : A copy : Debug : ... ... Apr 22 14:36:47 dedi dkimproxy.in[18373]: DKIM verify - none;
                Message 7 of 17 , Apr 23, 2013
                • 0 Attachment
                  Hi Bastian,

                  The transcription is on mail first mail :

                  A copy :

                  Debug :

                  Before with postfix 2.6.18 :
                  ----------------------------
                  ...
                  Apr 22 14:36:47 dedi dkimproxy.in[18373]: DKIM verify - none; from=<test@...>
                  Apr 22 14:36:47 dedi postfix/cleanup[4973]: B2FCF261729: message-id=<20130422123631.B2FCF261729@...>
                  Apr 22 14:36:47 dedi postfix/qmgr[4966]: B2FCF261729: from=<test@...>, size=651, nrcpt=1 (queue active)
                  Apr 22 14:36:47 dedi postfix/smtpd[4972]: public/cleanup socket: wanted attribute: status
                  Apr 22 14:36:47 dedi postfix/smtpd[4972]: input attribute name: status
                  Apr 22 14:36:47 dedi postfix/smtpd[4972]: input attribute value: 0
                  Apr 22 14:36:47 dedi postfix/smtpd[4972]: public/cleanup socket: wanted attribute: reason
                  Apr 22 14:36:47 dedi postfix/smtpd[4972]: input attribute name: reason
                  Apr 22 14:36:47 dedi postfix/smtpd[4972]: input attribute value: (end)
                  Apr 22 14:36:47 dedi postfix/smtpd[4972]: public/cleanup socket: wanted attribute: (list terminator)
                  Apr 22 14:36:47 dedi postfix/smtpd[4972]: input attribute name: (end)
                  Apr 22 14:36:47 dedi postfix/smtpd[4972]: > dedi.ludosoft.org[127.0.0.1]: 250 2.0.0 Ok: queued as B2FCF261729
                  Apr 22 14:36:47 dedi postfix/smtpd[4972]: watchdog_pat: 0x8d721b8
                  Apr 22 14:36:47 dedi postfix/smtpd[4968]: < 127.0.0.1:10025: 250 2.0.0 Ok: queued as B2FCF261729
                  Apr 22 14:36:47 dedi postfix/smtpd[4968]: > dedi.ludosoft.org[127.0.0.1]: 250 2.0.0 Ok: queued as B2FCF261729
                  Apr 22 14:36:47 dedi postfix/smtpd[4968]: > 127.0.0.1:10025: QUIT
                  Apr 22 14:36:47 dedi postfix/smtpd[4968]: watchdog_pat: 0x9fea028
                  Apr 22 14:36:47 dedi postfix/smtpd[4972]: < dedi.ludosoft.org[127.0.0.1]: QUIT
                  Apr 22 14:36:47 dedi postfix/smtpd[4972]: > dedi.ludosoft.org[127.0.0.1]: 221 2.0.0 Bye
                  Apr 22 14:36:47 dedi postfix/smtpd[4972]: match_hostname: dedi.ludosoft.org ~? 127.0.0.0/8
                  Apr 22 14:36:47 dedi postfix/smtpd[4972]: match_hostaddr: 127.0.0.1 ~? 127.0.0.0/8
                  Apr 22 14:36:47 dedi postfix/smtpd[4972]: disconnect from dedi.ludosoft.org[127.0.0.1]
                  Apr 22 14:36:48 dedi postfix/smtp[4974]: B2FCF261729: to=<test@...>, relay=filenet.ludosoft.org[82.236.203.193]:25, delay=17, delays=16/0.08/0.27/0.52, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 9F6BE122798B)
                  Apr 22 14:36:48 dedi postfix/qmgr[4966]: B2FCF261729: removed
                  Apr 22 14:36:52 dedi postfix/smtpd[4968]: < dedi.ludosoft.org[127.0.0.1]: QUIT
                  Apr 22 14:36:52 dedi postfix/smtpd[4968]: > dedi.ludosoft.org[127.0.0.1]: 221 2.0.0 Bye
                  Apr 22 14:36:52 dedi postfix/smtpd[4968]: match_hostname: dedi.ludosoft.org ~? 127.0.0.0/8
                  Apr 22 14:36:52 dedi postfix/smtpd[4968]: match_hostaddr: 127.0.0.1 ~? 127.0.0.0/8
                  Apr 22 14:36:52 dedi postfix/smtpd[4968]: disconnect from dedi.ludosoft.org[127.0.0.1]


                  Now with postfix 2.10.0 :
                  ----------------------------
                  ...
                  Apr 22 14:15:08 dedi dkimproxy.in[1459]: DKIM verify - none; from=<test@...>
                  Apr 22 14:15:08 dedi postfix/cleanup[2975]: C0BBC261729: message-id=<20130422121456.C0BBC261729@...>
                  Apr 22 14:15:08 dedi postfix/qmgr[2966]: C0BBC261729: from=<test@...>, size=651, nrcpt=1 (queue active)
                  Apr 22 14:15:08 dedi postfix/smtpd[2974]: public/cleanup socket: wanted attribute: status
                  Apr 22 14:15:08 dedi postfix/smtpd[2974]: input attribute name: status
                  Apr 22 14:15:08 dedi postfix/smtpd[2974]: input attribute value: 0
                  Apr 22 14:15:08 dedi postfix/smtpd[2974]: public/cleanup socket: wanted attribute: reason
                  Apr 22 14:15:08 dedi postfix/smtpd[2974]: input attribute name: reason
                  Apr 22 14:15:08 dedi postfix/smtpd[2974]: input attribute value: (end)
                  Apr 22 14:15:08 dedi postfix/smtpd[2974]: public/cleanup socket: wanted attribute: (list terminator)
                  Apr 22 14:15:08 dedi postfix/smtpd[2974]: input attribute name: (end)
                  Apr 22 14:15:08 dedi postfix/smtpd[2974]: > dedi.ludosoft.org[127.0.0.1]: 250 2.0.0 Ok: queued as C0BBC261729
                  Apr 22 14:15:08 dedi postfix/smtpd[2974]: watchdog_pat: 0x8e10870
                  Apr 22 14:15:08 dedi postfix/smtpd[2970]: < 127.0.0.1:10025: 250 2.0.0 Ok: queued as C0BBC261729
                  Apr 22 14:15:08 dedi postfix/smtpd[2970]: > dedi.ludosoft.org[127.0.0.1]: 250 2.0.0 Ok: queued as C0BBC261729
                  Apr 22 14:15:08 dedi postfix/smtpd[2970]: proxy-accept: END-OF-MESSAGE: 250 2.0.0 Ok: queued as C0BBC261729; from=<test@...> to=<test@...> proto=ESMTP helo=<dedi.ludosoft.org>
                  Apr 22 14:15:08 dedi postfix/smtpd[2970]: watchdog_pat: 0x839f800
                  Apr 22 14:15:09 dedi postfix/smtp[2976]: C0BBC261729: to=<test@...>, relay=filenet.ludosoft.org[82.236.203.193]:25, delay=13, delays=12/0.08/0.25/0.78, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as BAC10122195B)
                  Apr 22 14:15:09 dedi postfix/qmgr[2966]: C0BBC261729: removed
                  Apr 22 14:15:11 dedi postfix/smtpd[2970]: < dedi.ludosoft.org[127.0.0.1]: QUIT
                  Apr 22 14:15:11 dedi postfix/smtpd[2970]: > dedi.ludosoft.org[127.0.0.1]: 221 2.0.0 Bye
                  Apr 22 14:15:11 dedi postfix/smtpd[2970]: match_hostname: dedi.ludosoft.org ~? 127.0.0.0/8
                  Apr 22 14:15:11 dedi postfix/smtpd[2970]: match_hostaddr: 127.0.0.1 ~? 127.0.0.0/8
                  Apr 22 14:15:11 dedi postfix/smtpd[2970]: disconnect from dedi.ludosoft.org[127.0.0.1]
                  Apr 22 14:20:08 dedi postfix/smtpd[2974]: smtp_get: timeout
                  Apr 22 14:20:08 dedi postfix/smtpd[2974]: > dedi.ludosoft.org[127.0.0.1]: 421 4.4.2 dedi.ludosoft.org Error: timeout exceeded
                  Apr 22 14:20:08 dedi postfix/smtpd[2974]: match_hostname: dedi.ludosoft.org ~? 127.0.0.0/8
                  Apr 22 14:20:08 dedi postfix/smtpd[2974]: match_hostaddr: 127.0.0.1 ~? 127.0.0.0/8
                  Apr 22 14:20:08 dedi postfix/smtpd[2974]: timeout after END-OF-MESSAGE from dedi.ludosoft.org[127.0.0.1]
                  Apr 22 14:20:08 dedi postfix/smtpd[2974]: disconnect from dedi.ludosoft.org[127.0.0.1]



                  My master.cf :

                  #
                  # Postfix master process configuration file.  For details on the format
                  # of the file, see the Postfix master(5) manual page.
                  #
                  # ==========================================================================
                  # service type  private unpriv  chroot  wakeup  maxproc command + args
                  #               (yes)   (yes)   (yes)   (never) (100)
                  # ==========================================================================
                  #smtp      inet  n       -       n       -       -       smtpd
                  smtp      inet  n       -       n       -       20      smtpd
                      -o smtpd_proxy_filter=127.0.0.1:10025
                      -o smtpd_client_connection_count_limit=20
                      -o smtpd_proxy_timeout=600s
                      -o smtp_connection_cache_on_demand=no

                  ...



                  Why nobody complain ? the response is in the session transcription :
                  ...
                  Apr 22 14:20:08 dedi postfix/smtpd[2974]: smtp_get: timeout
                  Apr 22 14:20:08 dedi postfix/smtpd[2974]: > dedi.ludosoft.org[127.0.0.1]: 421 4.4.2 dedi.ludosoft.org Error: timeout exceeded
                  Apr 22 14:20:08 dedi postfix/smtpd[2974]: match_hostname: dedi.ludosoft.org ~? 127.0.0.0/8
                  Apr 22 14:20:08 dedi postfix/smtpd[2974]: match_hostaddr: 127.0.0.1 ~? 127.0.0.0/8
                  Apr 22 14:20:08 dedi postfix/smtpd[2974]: timeout after END-OF-MESSAGE from dedi.ludosoft.org[127.0.0.1]
                  Apr 22 14:20:08 dedi postfix/smtpd[2974]: disconnect from dedi.ludosoft.org[127.0.0.1]
                  ...

                  During this time (define by smtpd_proxy_timeout=600s ), there is a lot of pending process from smtpd and perl dkim, this 2 process wait for end of communication, until postfix close the connection by time out.
                  But, normaly postfix smtp must send a 'QUIT' command if the socket is not reuse (cache connexion process) but  the param 'smtp_connection_cache_on_demand=no' is not take care.

                  The mail is transfered well, but the connexion is not terminate properly.

                  So, like you said in 3.8 of RFC5321 confirm what i said :

                  3.8.  Terminating Sessions and Connections

                     An SMTP connection is terminated when the client sends a QUIT
                     command.  The server responds with a positive reply code, after which
                     it closes the connection.

                     An SMTP server MUST NOT intentionally close the connection under
                     normal operational circumstances (see Section 7.8) except:

                     o  After receiving a QUIT command and responding with a 221 reply.

                     o  After detecting the need to shut down the SMTP service and
                        returning a 421 response code.  This response code can be issued
                        after the server receives any command or, if necessary,
                        asynchronously from command receipt (on the assumption that the
                        client will receive it after the next command is issued).

                     o  After a timeout, as specified in Section 4.5.3.2, occurs waiting
                        for the client to send a command or data

                  But in this case, dkimproxy is the server, and postfix smpt the client ! Postfix smtp must send 'QUIT' command !

                  Ludo.

                  Le 23/04/2013 12:12, Bastian Blank a écrit :
                  Please fix your MUA, it produces TOFU.
                  
                  On Tue, Apr 23, 2013 at 11:48:42AM +0200, Ludovic LEVET wrote:
                  
                  This is not a reply ...
                  
                  Not showing what the actual problem is, is no question either.
                  Especially, why are you the only person experiencing this in over three
                  years?
                  
                  
                  http://www.ietf.org/rfc/rfc5321.txt
                  Chapter 4.1.1.10.
                  
                  You miss 3.8.
                  
                  Please show a session _transcripts_ for the problem you are talking
                  about.
                  
                  Bastian
                  
                  

                • Bastian Blank
                  Don t send copies, I m subscribed. ... This is no transcript. This is several smtpd sessions intermingled. ... This is no smtp proxy. This is a smtp server
                  Message 8 of 17 , Apr 23, 2013
                  • 0 Attachment
                    Don't send copies, I'm subscribed.

                    On Tue, Apr 23, 2013 at 01:01:20PM +0200, Ludovic LEVET wrote:
                    > The transcription is on mail first mail :

                    This is no transcript. This is several smtpd sessions intermingled.

                    > Why nobody complain ? the response is in the session transcription :
                    > ...
                    > Apr 22 14:20:08 dedi postfix/smtpd[2974]: smtp_get: timeout
                    > Apr 22 14:20:08 dedi postfix/smtpd[2974]: >
                    > dedi.ludosoft.org[127.0.0.1]: 421 4.4.2 dedi.ludosoft.org Error:
                    > timeout exceeded
                    > Apr 22 14:20:08 dedi postfix/smtpd[2974]: match_hostname:
                    > dedi.ludosoft.org ~? 127.0.0.0/8
                    > Apr 22 14:20:08 dedi postfix/smtpd[2974]: match_hostaddr: 127.0.0.1
                    > ~? 127.0.0.0/8
                    > Apr 22 14:20:08 dedi postfix/smtpd[2974]: timeout after
                    > END-OF-MESSAGE from dedi.ludosoft.org[127.0.0.1]
                    > Apr 22 14:20:08 dedi postfix/smtpd[2974]: disconnect from
                    > dedi.ludosoft.org[127.0.0.1]

                    This is no smtp proxy. This is a smtp server receiving stuff from
                    localhost and it times out.

                    > During this time (define by smtpd_proxy_timeout=600s ), there is a
                    > lot of pending process from smtpd and perl dkim, this 2 process wait
                    > for end of communication, until postfix close the connection by time
                    > out.

                    Wrong side. This is the normal session timeout and have nothing to do
                    with a proxy.

                    > But, normaly postfix smtp must send a 'QUIT' command if the socket
                    > is not reuse (cache connexion process) but the param
                    > 'smtp_connection_cache_on_demand=no' is not take care.

                    It doesn't even need to close the connection.

                    > The mail is transfered well, but the connexion is not terminate properly.

                    Show proof.

                    > So, like you said in 3.8 of RFC5321 confirm what i said :

                    Stop arguing with standards.

                    > Le 23/04/2013 12:12, Bastian Blank a écrit :
                    > >Please fix your MUA, it produces TOFU.

                    As you ignored be: PLONK and EOD.

                    Bastian

                    --
                    Most legends have their basis in facts.
                    -- Kirk, "And The Children Shall Lead", stardate 5029.5
                  • Wietse Venema
                    ... After sending END-OF-MESSAGE, the Postfix smtpd_proxy_CLIENT closes the SMTP connection to the before-queue content filter. Apparently the content filter
                    Message 9 of 17 , Apr 23, 2013
                    • 0 Attachment
                      > > Apr 22 14:20:08 dedi postfix/smtpd[2974]: smtp_get: timeout
                      > > Apr 22 14:20:08 dedi postfix/smtpd[2974]: >
                      > > dedi.ludosoft.org[127.0.0.1]: 421 4.4.2 dedi.ludosoft.org Error:
                      > > timeout exceeded
                      > > Apr 22 14:20:08 dedi postfix/smtpd[2974]: match_hostname:
                      > > dedi.ludosoft.org ~? 127.0.0.0/8
                      > > Apr 22 14:20:08 dedi postfix/smtpd[2974]: match_hostaddr: 127.0.0.1
                      > > ~? 127.0.0.0/8
                      > > Apr 22 14:20:08 dedi postfix/smtpd[2974]: timeout after
                      > > END-OF-MESSAGE from dedi.ludosoft.org[127.0.0.1]
                      > > Apr 22 14:20:08 dedi postfix/smtpd[2974]: disconnect from
                      > > dedi.ludosoft.org[127.0.0.1]

                      After sending END-OF-MESSAGE, the Postfix smtpd_proxy_CLIENT closes
                      the SMTP connection to the before-queue content filter.

                      Apparently the content filter is waiting for QUIT *after* the
                      connection is closed. Please file a bug report for the content
                      filter.

                      Wietse
                    • Ludovic LEVET
                      Hi Wietse, I m agree with you, after sending END-OF-MESSAGE, the Postfix smtpd_proxy_CLIENT closes the SMTP connection to the before-queue content filter
                      Message 10 of 17 , Apr 23, 2013
                      • 0 Attachment
                        Hi Wietse,

                        I'm agree with you, after sending END-OF-MESSAGE, the Postfix
                        smtpd_proxy_CLIENT closes the SMTP connection
                        to the before-queue content filter without sending QUIT command and wait
                        for a 221 reply.

                        But Postfix smtpd complain to be compatible with ESMTP protocol
                        (http://www.postfix.org/SMTPD_PROXY_README.html), and specify in Postfix
                        Before-Queue Content Filter 'How Postfix talks to the before-queue
                        content filter' that QUIT command is used.
                        It this true on postfix 2.6.x but not on upper version.

                        So, DKIMproxy work like it will be, it repeat the same dialog in IN
                        (port 10025) to OUT (port 10026) and add only status in header. So, if
                        it don't received QUIT command in IN, it don't send it in OUT.

                        Then the problem is well in Postfix smtpd_proxy_CLIENT (was ok on 2.6.x
                        version).

                        So, i think and i said that ESMTP protocol will be fully respected by
                        Postfix smtpd_proxy_CLIENT.
                        Modifying dkimproxy will be only a workaround for this problem, but it
                        will not be serious implemantation in respect of RFC.

                        Are you agree with me ?

                        Ludovic.


                        Le 23/04/2013 14:22, Wietse Venema a écrit :
                        >>> Apr 22 14:20:08 dedi postfix/smtpd[2974]: smtp_get: timeout
                        >>> Apr 22 14:20:08 dedi postfix/smtpd[2974]: >
                        >>> dedi.ludosoft.org[127.0.0.1]: 421 4.4.2 dedi.ludosoft.org Error:
                        >>> timeout exceeded
                        >>> Apr 22 14:20:08 dedi postfix/smtpd[2974]: match_hostname:
                        >>> dedi.ludosoft.org ~? 127.0.0.0/8
                        >>> Apr 22 14:20:08 dedi postfix/smtpd[2974]: match_hostaddr: 127.0.0.1
                        >>> ~? 127.0.0.0/8
                        >>> Apr 22 14:20:08 dedi postfix/smtpd[2974]: timeout after
                        >>> END-OF-MESSAGE from dedi.ludosoft.org[127.0.0.1]
                        >>> Apr 22 14:20:08 dedi postfix/smtpd[2974]: disconnect from
                        >>> dedi.ludosoft.org[127.0.0.1]
                        > After sending END-OF-MESSAGE, the Postfix smtpd_proxy_CLIENT closes
                        > the SMTP connection to the before-queue content filter.
                        >
                        > Apparently the content filter is waiting for QUIT *after* the
                        > connection is closed. Please file a bug report for the content
                        > filter.
                        >
                        > Wietse
                      • Michael Storz
                        ... And this is exactly the problem: smtpd_proxy_CLIENT closes the connection without sending the QUIT command first, which is in violation of RFC 5321,
                        Message 11 of 17 , Apr 23, 2013
                        • 0 Attachment
                          Am 2013-04-23 14:22, schrieb Wietse Venema:
                          >> > Apr 22 14:20:08 dedi postfix/smtpd[2974]: smtp_get: timeout
                          >> > Apr 22 14:20:08 dedi postfix/smtpd[2974]: >
                          >> > dedi.ludosoft.org[127.0.0.1]: 421 4.4.2 dedi.ludosoft.org Error:
                          >> > timeout exceeded
                          >> > Apr 22 14:20:08 dedi postfix/smtpd[2974]: match_hostname:
                          >> > dedi.ludosoft.org ~? 127.0.0.0/8
                          >> > Apr 22 14:20:08 dedi postfix/smtpd[2974]: match_hostaddr:
                          >> 127.0.0.1
                          >> > ~? 127.0.0.0/8
                          >> > Apr 22 14:20:08 dedi postfix/smtpd[2974]: timeout after
                          >> > END-OF-MESSAGE from dedi.ludosoft.org[127.0.0.1]
                          >> > Apr 22 14:20:08 dedi postfix/smtpd[2974]: disconnect from
                          >> > dedi.ludosoft.org[127.0.0.1]
                          >
                          > After sending END-OF-MESSAGE, the Postfix smtpd_proxy_CLIENT closes
                          > the SMTP connection to the before-queue content filter.

                          And this is exactly the problem: smtpd_proxy_CLIENT closes the
                          connection without sending
                          the QUIT command first, which is in violation of RFC 5321, section
                          "4.1.1.10. QUIT (QUIT)"

                          We see the same behavior here with pre-queue amavisd:

                          Apr 23 22:01:21 lxmhs57 amavis[32118]: (32118-01) ESMTP> 554 5.7.0
                          Reject, id=32118-01 - spam
                          Apr 23 22:01:21 lxmhs57 postfix-mwnin/smtpd[32156]: <
                          [127.0.0.1]:10001: 554 5.7.0 Reject, id=32118-01 - spam
                          Apr 23 22:01:21 lxmhs57 postfix-mwnin/smtpd[32156]: > unknown
                          [95.58.34.47]: 554 5.7.0 Reject, id=32118-01 - spam
                          Apr 23 22:01:21 lxmhs57 postfix-mwnin/smtpd[32156]: proxy-reject:
                          END-OF-MESSAGE: 554 5.7.0 Reject, id=32118-01 - spam; from=<SPAMMER>
                          to=<CUSTOMER> proto=ESMTP helo=<bla>
                          Apr 23 22:01:21 lxmhs57 amavis[32118]: (32118-01) smtp readline: EOF
                          Apr 23 22:01:21 lxmhs57 amavis[32118]: (32118-01) SMTP session over,
                          timer stopped
                          Apr 23 22:01:21 lxmhs57 amavis[32118]: (32118-01) ESMTP: notice: client
                          broke the connection without a QUIT ()

                          >
                          > Apparently the content filter is waiting for QUIT *after* the
                          > connection is closed. Please file a bug report for the content
                          > filter.
                          >
                          > Wietse

                          Wietse, this was a bug report for Postfix! Filing a bug report for the
                          content filter because it does not check for a dropped connection is
                          another story.

                          Michael
                        • Viktor Dukhovni
                          ... This is irrelevant. All TCP services need to handle mid-stream client disconnect sensibly. QUIT is nice to send, but this is not always possible, so
                          Message 12 of 17 , Apr 23, 2013
                          • 0 Attachment
                            On Tue, Apr 23, 2013 at 10:52:02PM +0200, Michael Storz wrote:

                            > >After sending END-OF-MESSAGE, the Postfix smtpd_proxy_CLIENT closes
                            > >the SMTP connection to the before-queue content filter.
                            >
                            > And this is exactly the problem: smtpd_proxy_CLIENT closes the
                            > connection without sending
                            > the QUIT command first, which is in violation of RFC 5321, section
                            > "4.1.1.10. QUIT (QUIT)"

                            This is irrelevant. All TCP services need to handle mid-stream
                            client disconnect sensibly. QUIT is nice to send, but this is not
                            always possible, so deviating from RFC 5321 by not sending QUIT
                            is harmless.

                            > >Apparently the content filter is waiting for QUIT *after* the
                            > >connection is closed. Please file a bug report for the content
                            > >filter.
                            >
                            > Wietse, this was a bug report for Postfix! Filing a bug report for
                            > the content filter because it does not check for a dropped
                            > connection is another story.

                            And yet that's the real problem, the content filter must propagate
                            not only QUIT but also EOF.

                            --
                            Viktor.
                          • Wietse Venema
                            ... If you have a problem with disconnect without quit , then you are spending too much time in the company of computers. If some software cannot handle
                            Message 13 of 17 , Apr 23, 2013
                            • 0 Attachment
                              > > After sending END-OF-MESSAGE, the Postfix smtpd_proxy_CLIENT closes
                              > > the SMTP connection to the before-queue content filter.
                              >
                              > And this is exactly the problem: smtpd_proxy_CLIENT closes the

                              If you have a problem with "disconnect without quit", then you are
                              spending too much time in the company of computers.

                              If some software cannot handle "disconnect without quit", then
                              please file a bug report there.

                              I am done with this thread. Go out, have a beer.

                              Wietse
                            • Kristof Bajnok
                              ... For the OP, http://cr.yp.to/smtp/quit.html might be an explanation of the quit-problem. I suppose Postfix dropped client quit for similar reasons. Kristof
                              Message 14 of 17 , Apr 23, 2013
                              • 0 Attachment
                                On 2013-04-23 23:21, Viktor Dukhovni wrote:
                                >>> After sending END-OF-MESSAGE, the Postfix smtpd_proxy_CLIENT closes
                                >>> > >the SMTP connection to the before-queue content filter.
                                >> >
                                >> > And this is exactly the problem: smtpd_proxy_CLIENT closes the
                                >> > connection without sending
                                >> > the QUIT command first, which is in violation of RFC 5321, section
                                >> > "4.1.1.10. QUIT (QUIT)"
                                > This is irrelevant. All TCP services need to handle mid-stream
                                > client disconnect sensibly. QUIT is nice to send, but this is not
                                > always possible, so deviating from RFC 5321 by not sending QUIT
                                > is harmless.

                                For the OP, http://cr.yp.to/smtp/quit.html might be an explanation of
                                the quit-problem. I suppose Postfix dropped client quit for similar reasons.

                                Kristof
                              • Ludovic LEVET
                                I m sad to see this type of response ... Sorry, but when I take the bus, i come in by the door, and out by the door. I don t go out of the bus by the window,
                                Message 15 of 17 , Apr 25, 2013
                                • 0 Attachment
                                  I'm sad to see this type of response ...

                                  Sorry, but when I take the bus, i come in by the door, and out by the
                                  door. I don't go out of the bus by the window, the emergency issue.
                                  So today, your are saying me to go out by the windows, the door is
                                  locked ...

                                  So, yes it may be true, i'm 'too old school' professional computer.
                                  And yes ... why writing RFC and lose so much time to elaborate it ...
                                  Oh, yes ! For interoperability and perfect dialog between 2 or more
                                  program ...

                                  I don't understand why it create a polemic, it was working before, not
                                  now. And nobody have create a new RFC to remove this command. Using
                                  emergency
                                  mode like normal operating mode is not a normal work.

                                  And what else ?
                                  I go out take a coffe (G.Cloney French joke ...)

                                  Ludovic.


                                  Le 23/04/2013 23:28, Wietse Venema a écrit :
                                  >>> After sending END-OF-MESSAGE, the Postfix smtpd_proxy_CLIENT closes
                                  >>> the SMTP connection to the before-queue content filter.
                                  >> And this is exactly the problem: smtpd_proxy_CLIENT closes the
                                  > If you have a problem with "disconnect without quit", then you are
                                  > spending too much time in the company of computers.
                                  >
                                  > If some software cannot handle "disconnect without quit", then
                                  > please file a bug report there.
                                  >
                                  > I am done with this thread. Go out, have a beer.
                                  >
                                  > Wietse
                                • Ludovic LEVET
                                  Deviation is use only in case of problem, et RFC give this possibility by the time out , but not in normal condition. Ludovic. ... -- ... Ce message inclut
                                  Message 16 of 17 , Apr 25, 2013
                                  • 0 Attachment
                                    Deviation is use only in case of problem, et RFC give this possibility
                                    by the 'time out', but not in normal condition.

                                    Ludovic.

                                    Le 23/04/2013 23:21, Viktor Dukhovni a écrit :
                                    > On Tue, Apr 23, 2013 at 10:52:02PM +0200, Michael Storz wrote:
                                    >
                                    >>> After sending END-OF-MESSAGE, the Postfix smtpd_proxy_CLIENT closes
                                    >>> the SMTP connection to the before-queue content filter.
                                    >> And this is exactly the problem: smtpd_proxy_CLIENT closes the
                                    >> connection without sending
                                    >> the QUIT command first, which is in violation of RFC 5321, section
                                    >> "4.1.1.10. QUIT (QUIT)"
                                    > This is irrelevant. All TCP services need to handle mid-stream
                                    > client disconnect sensibly. QUIT is nice to send, but this is not
                                    > always possible, so deviating from RFC 5321 by not sending QUIT
                                    > is harmless.
                                    >
                                    >>> Apparently the content filter is waiting for QUIT *after* the
                                    >>> connection is closed. Please file a bug report for the content
                                    >>> filter.
                                    >> Wietse, this was a bug report for Postfix! Filing a bug report for
                                    >> the content filter because it does not check for a dropped
                                    >> connection is another story.
                                    > And yet that's the real problem, the content filter must propagate
                                    > not only QUIT but also EOF.
                                    >

                                    --
                                    -------------------------------------------------------------------------------------------------------------------------
                                    Ce message inclut une signature numérique. Il certifie que l'expéditeur et le contenue du message sont authentiques.
                                    Si votre logiciel de messagerie est compatible, Il doit garantir que le document n'a pas été altéré entre l'instant où
                                    l'auteur l'a signé et le moment où le lecteur le consulte.
                                    Loi n°2000-230 du 13 mars 2000 Art. 1316, 1316-1, 1316-2, 1316-3, 1316-4 du Code civil.
                                    La présence d'un fichier joint 'smime.p7s' (fichier signature) indique que votre client messagerie n'est pas compatible.
                                    -------------------------------------------------------------------------------------------------------------------------
                                  Your message has been successfully submitted and would be delivered to recipients shortly.