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

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

Expand Messages
  • Justin Piszcz
    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]:
    Message 1 of 8 , Dec 1, 2008
      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?

      Justin.
    • 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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.