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

Re: 3dm2 (3ware daemon) smtp/e-mail issue (lost connection after QUIT)

Expand Messages
  • Victor Duchovni
    ... Harmless noise, the client dropped the connection after sending QUIT and the server 221 response could not be sent down an already closed socket. This
    Message 1 of 8 , Dec 1, 2008
      On Mon, Dec 01, 2008 at 11:05:44AM -0500, Justin Piszcz wrote:

      > Quick question--
      >
      > Nov 30 17:39:03 p34 postfix/smtpd[15257]: 6B3A310676:
      > client=localhost.localdomain[127.0.0.1]
      > Nov 30 17:39:03 p34 postfix/cleanup[15260]: 6B3A310676:
      > message-id=<20081130223903.6B3A310676@...>
      > Nov 30 17:39:03 p34 postfix/qmgr[18872]: 6B3A310676:
      > from=<root@...>, size=430, nrcpt=1 (queue active)
      > Nov 30 17:39:03 p34 postfix/smtpd[15257]: lost connection after QUIT from
      > localhost.localdomain[127.0.0.1]
      > Nov 30 17:39:03 p34 postfix/smtpd[15257]: disconnect from
      > localhost.localdomain[127.0.0.1]
      >
      > Why would it lose the connection from localhost when sending a test message
      > from the 3dm2 web interface? Should I escalate this to 3ware support/or
      > is there a parameter I can change to fix this/what is causing this?

      Harmless noise, the client dropped the connection after sending "QUIT" and
      the server "221" response could not be sent down an already closed socket.

      This is a race. For clients with high enough network latency, the server
      sends 221 before the TCP 3-way close handshake completes. For clients
      that are close-by (e.g. localhost), the server can "lose" the race, and
      find the socket already closed. Use of milters to inspect the QUIT command
      can slow down the server further and make this more likely.

      There is nothing wrong with lost connections after QUIT. Newer versions
      of Postfix only log "lost connection" in the SMTP server during data
      transfer or when sending the "." response. The client is free to
      disconnect without "QUIT" at all other SMTP protocol stages.

      Sufficiently new Postfix releases will not log this condition.

      --
      Viktor.

      Disclaimer: off-list followups get on-list replies or get ignored.
      Please do not ignore the "Reply-To" header.

      To unsubscribe from the postfix-users list, visit
      http://www.postfix.org/lists.html or click the link below:
      <mailto:majordomo@...?body=unsubscribe%20postfix-users>

      If my response solves your problem, the best way to thank me is to not
      send an "it worked, thanks" follow-up. If you must respond, please put
      "It worked, thanks" in the "Subject" so I can delete these quickly.
    • Charles Marcus
      ... Hmmm... I m running 2.5.5, and get this almost every time (maybe every time) when people send through the webmail interface... It is an older version of
      Message 2 of 8 , Dec 1, 2008
        On 12/1/2008 11:54 AM, Victor Duchovni wrote:
        > There is nothing wrong with lost connections after QUIT. Newer versions
        > of Postfix only log "lost connection" in the SMTP server during data
        > transfer or when sending the "." response. The client is free to
        > disconnect without "QUIT" at all other SMTP protocol stages.
        >
        > Sufficiently new Postfix releases will not log this condition.

        Hmmm...

        I'm running 2.5.5, and get this almost every time (maybe every time)
        when people send through the webmail interface...

        It is an older version of squirrelmail (1.4.6)... maybe time to upgrade?

        --

        Best regards,

        Charles
      • Victor Duchovni
        ... Sorry, Postfix won t log clients disconnecting without sending QUIT, but it will log failure to send 221 ... . The reason is that with PIPELINEd ESMTP,
        Message 3 of 8 , Dec 1, 2008
          On Mon, Dec 01, 2008 at 11:58:42AM -0500, Charles Marcus wrote:

          > On 12/1/2008 11:54 AM, Victor Duchovni wrote:
          > > There is nothing wrong with lost connections after QUIT. Newer versions
          > > of Postfix only log "lost connection" in the SMTP server during data
          > > transfer or when sending the "." response. The client is free to
          > > disconnect without "QUIT" at all other SMTP protocol stages.
          > >
          > > Sufficiently new Postfix releases will not log this condition.
          >
          > Hmmm...
          >
          > I'm running 2.5.5, and get this almost every time (maybe every time)
          > when people send through the webmail interface...
          >

          Sorry, Postfix won't log clients disconnecting without sending QUIT,
          but it will log failure to send "221 ...".

          The reason is that with PIPELINEd ESMTP, the "250 ..." response to
          "." and "221" response to QUIT are often sent in the same I/O operation,
          so it is appropriate to report I/O errors when sending QUIT, at least
          when there are previous responses in the output buffer. Postfix 2.3+
          complains about problems flushing QUIT unconditionally.

          quit_cmd(SMTPD_STATE *state, int unused_argc, SMTPD_TOKEN *unused_argv)
          {

          /*
          * Don't bother checking the syntax.
          */
          smtpd_chat_reply(state, "221 2.0.0 Bye");

          /*
          * When the "." and quit replies are pipelined, make sure they are
          * flushed now, to avoid repeated mail deliveries in case of a crash in
          * the "clean up before disconnect" code.
          *
          * XXX When this was added in Postfix 2.1 we used vstream_fflush(). As
          * of Postfix 2.3 we use smtp_flush() for better error reporting.
          */
          smtp_flush(state->client);
          return (0);
          }

          perhaps the flush should be suppressed if there was no pending unwritten
          data in the client vstream buffer prior to the "221 2.0.0 Bye" reply.

          --
          Viktor.

          Disclaimer: off-list followups get on-list replies or get ignored.
          Please do not ignore the "Reply-To" header.

          To unsubscribe from the postfix-users list, visit
          http://www.postfix.org/lists.html or click the link below:
          <mailto:majordomo@...?body=unsubscribe%20postfix-users>

          If my response solves your problem, the best way to thank me is to not
          send an "it worked, thanks" follow-up. If you must respond, please put
          "It worked, thanks" in the "Subject" so I can delete these quickly.
        • Wietse Venema
          ... Postfix has a vstream_peek() function to count the amount of buffered input, but there is as of yet no API to count the amount of buffered output. I am not
          Message 4 of 8 , Dec 1, 2008
            Victor Duchovni:
            > On Mon, Dec 01, 2008 at 11:58:42AM -0500, Charles Marcus wrote:
            >
            > > On 12/1/2008 11:54 AM, Victor Duchovni wrote:
            > > > There is nothing wrong with lost connections after QUIT. Newer versions
            > > > of Postfix only log "lost connection" in the SMTP server during data
            > > > transfer or when sending the "." response. The client is free to
            > > > disconnect without "QUIT" at all other SMTP protocol stages.
            > > >
            > > > Sufficiently new Postfix releases will not log this condition.
            > >
            > > Hmmm...
            > >
            > > I'm running 2.5.5, and get this almost every time (maybe every time)
            > > when people send through the webmail interface...
            > >
            >
            > Sorry, Postfix won't log clients disconnecting without sending QUIT,
            > but it will log failure to send "221 ...".
            >
            > The reason is that with PIPELINEd ESMTP, the "250 ..." response to
            > "." and "221" response to QUIT are often sent in the same I/O operation,
            > so it is appropriate to report I/O errors when sending QUIT, at least
            > when there are previous responses in the output buffer. Postfix 2.3+
            > complains about problems flushing QUIT unconditionally.
            >
            > quit_cmd(SMTPD_STATE *state, int unused_argc, SMTPD_TOKEN *unused_argv)
            > {
            >
            > /*
            > * Don't bother checking the syntax.
            > */
            > smtpd_chat_reply(state, "221 2.0.0 Bye");
            >
            > /*
            > * When the "." and quit replies are pipelined, make sure they are
            > * flushed now, to avoid repeated mail deliveries in case of a crash in
            > * the "clean up before disconnect" code.
            > *
            > * XXX When this was added in Postfix 2.1 we used vstream_fflush(). As
            > * of Postfix 2.3 we use smtp_flush() for better error reporting.
            > */
            > smtp_flush(state->client);
            > return (0);
            > }
            >
            > perhaps the flush should be suppressed if there was no pending unwritten
            > data in the client vstream buffer prior to the "221 2.0.0 Bye" reply.

            Postfix has a vstream_peek() function to count the amount of buffered
            input, but there is as of yet no API to count the amount of buffered
            output.

            I am not sure it is safe to overload vstream_peek() for this purpose,
            because that would break with full-duplex VSTREAMs when the last
            operation on the VSTREAM was a write.

            Wietse
          • Victor Duchovni
            ... I agree that it is not safe to overload vstream_peek(), we need a new vstream feature to make this possible. Perhaps: /* * Number of unwritten application
            Message 5 of 8 , Dec 1, 2008
              On Mon, Dec 01, 2008 at 03:25:00PM -0500, Wietse Venema wrote:

              > > /*
              > > * Don't bother checking the syntax.
              > > */
              > > smtpd_chat_reply(state, "221 2.0.0 Bye");
              > >
              > > /*
              > > * When the "." and quit replies are pipelined, make sure they are
              > > * flushed now, to avoid repeated mail deliveries in case of a crash in
              > > * the "clean up before disconnect" code.
              > > *
              > > * XXX When this was added in Postfix 2.1 we used vstream_fflush(). As
              > > * of Postfix 2.3 we use smtp_flush() for better error reporting.
              > > */
              > > smtp_flush(state->client);
              > >
              > > perhaps the flush should be suppressed if there was no pending unwritten
              > > data in the client vstream buffer prior to the "221 2.0.0 Bye" reply.
              >
              > Postfix has a vstream_peek() function to count the amount of buffered
              > input, but there is as of yet no API to count the amount of buffered
              > output.
              >
              > I am not sure it is safe to overload vstream_peek() for this purpose,
              > because that would break with full-duplex VSTREAMs when the last
              > operation on the VSTREAM was a write.

              I agree that it is not safe to overload vstream_peek(), we need a new
              vstream feature to make this possible. Perhaps:

              /*
              * Number of unwritten application data bytes held in a vstream
              * buffer. Note, these may translate a diffent number of bytes
              * ultimately written to the network or a file, if the physical
              * I/O involves encryption, compression or other transformations.
              */
              int vstream_unwritten(VSTREAM *);

              --
              Viktor.

              Disclaimer: off-list followups get on-list replies or get ignored.
              Please do not ignore the "Reply-To" header.

              To unsubscribe from the postfix-users list, visit
              http://www.postfix.org/lists.html or click the link below:
              <mailto:majordomo@...?body=unsubscribe%20postfix-users>

              If my response solves your problem, the best way to thank me is to not
              send an "it worked, thanks" follow-up. If you must respond, please put
              "It worked, thanks" in the "Subject" so I can delete these quickly.
            • Charles Marcus
              ... Ok... we only have a few users who ever use the webmail interface, and grepping the logs shows this only happens to two of them, and pretty much every
              Message 6 of 8 , Dec 2, 2008
                On 12/1/2008 12:40 PM, Victor Duchovni wrote:
                >>> There is nothing wrong with lost connections after QUIT. Newer versions
                >>> of Postfix only log "lost connection" in the SMTP server during data
                >>> transfer or when sending the "." response. The client is free to
                >>> disconnect without "QUIT" at all other SMTP protocol stages.
                >>>
                >>> Sufficiently new Postfix releases will not log this condition.

                >> I'm running 2.5.5, and get this almost every time (maybe every time)
                >> when people send through the webmail interface...

                > Sorry, Postfix won't log clients disconnecting without sending QUIT,
                > but it will log failure to send "221 ...".

                Ok... we only have a few users who ever use the webmail interface, and
                grepping the logs shows this only happens to two of them, and pretty
                much every time...

                I'm guessing something interfering on their end (router/firewall, web
                'protection' software (Norton, Macafee, etc))...

                Don't see the 'lost connection' log entry when sending from my home, or
                from inside the office.

                Sorry for the noise...

                --

                Best regards,

                Charles
              • Victor Duchovni
                ... Unlikely, as the connection loss is with localhost (the webmail server submitting SMTP email on the users behalf), not the users desktops. The real
                Message 7 of 8 , Dec 2, 2008
                  On Tue, Dec 02, 2008 at 07:52:19AM -0500, Charles Marcus wrote:

                  > On 12/1/2008 12:40 PM, Victor Duchovni wrote:
                  > >>> There is nothing wrong with lost connections after QUIT. Newer versions
                  > >>> of Postfix only log "lost connection" in the SMTP server during data
                  > >>> transfer or when sending the "." response. The client is free to
                  > >>> disconnect without "QUIT" at all other SMTP protocol stages.
                  > >>>
                  > >>> Sufficiently new Postfix releases will not log this condition.
                  >
                  > >> I'm running 2.5.5, and get this almost every time (maybe every time)
                  > >> when people send through the webmail interface...
                  >
                  > > Sorry, Postfix won't log clients disconnecting without sending QUIT,
                  > > but it will log failure to send "221 ...".
                  >
                  > Ok... we only have a few users who ever use the webmail interface, and
                  > grepping the logs shows this only happens to two of them, and pretty
                  > much every time...
                  >
                  > I'm guessing something interfering on their end (router/firewall, web
                  > 'protection' software (Norton, Macafee, etc))...
                  >

                  Unlikely, as the connection loss is with "localhost" (the webmail server
                  submitting SMTP email on the users' behalf), not the users' desktops.

                  The real issue is that the webmail SMTP engine is not using PIPENINING,
                  so the QUIT response is sent separately from the "." response, and the
                  webmail client disconnects after sending "QUIT" without waiting for "221".
                  After that it is a race, to see whether the SMTP server can reply before
                  the kernel notices the connection is gone. With the client on "locahost",
                  the server is likely to lose the race.

                  While the log message is largelyharmless noise, I think this is worth
                  fixing, thanks for the report. It may be fixed in 2.6 and perhaps also
                  in 2.5.6 when there is sufficient cause to issue a 2.5.6 release.

                  --
                  Viktor.

                  Disclaimer: off-list followups get on-list replies or get ignored.
                  Please do not ignore the "Reply-To" header.

                  To unsubscribe from the postfix-users list, visit
                  http://www.postfix.org/lists.html or click the link below:
                  <mailto:majordomo@...?body=unsubscribe%20postfix-users>

                  If my response solves your problem, the best way to thank me is to not
                  send an "it worked, thanks" follow-up. If you must respond, please put
                  "It worked, thanks" in the "Subject" so I can delete these quickly.
                Your message has been successfully submitted and would be delivered to recipients shortly.