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

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

Expand Messages
  • 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 1 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 2 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 3 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 4 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.