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

Re: VOTE: server garbage, dot+quit pipelining

Expand Messages
  • mobiru
    ... Option 3 with switches to also always|never pipeline, in addition to a list of broken sites to never pipeline for. I want mail to get through but also want
    Message 1 of 38 , Dec 29, 2005
    • 0 Attachment
      > Wietse Venema wrote:
      >
      >> Possible configuration settings:
      >>
      >> 1) Eliminate the problem. Don't ignore server garbage, and
      >> always wait for the END-OF-DATA reply before sending QUIT, so
      >> that the bug is not triggered. The has a minor performance
      >> impact for deliveries to sites with correct command pipelining
      >> implementations. Supply switch A) so that masochists can force
      >> Postfix to pipeline END-OF-DATA and QUIT anyway (thus triggering
      >> the bug and causing multiple delivery attempts).
      >>
      >> 2) Pretend the problem does not exist. Ignore (but log) server
      >> garbage, and pipeline the END-OF-DATA and QUIT commands. This
      >> triggers the bug with incorrect command pipelining implementations,
      >> does not cause multiple deliveries, but may result in lost
      >> mail, in which case we blame the victim. Supply switch B) so
      >> that masochists can force Postfix not to ignore server garbage
      >> (thus causing multiple delivery attempts).
      >>
      >> 3) Share the pain. Don't ignore server garbage. Send END-OF-DATA
      >> and QUIT pipelined with new mail, and non-pipelined after some
      >> configurable time. This does not penalize normal deliveries to
      >> sites with correct SMTP implementations. Sites with defective
      >> implementations receive 2 copies of email, providing some
      >> incentive to fix their systems.
      >
      Option 3 with switches to also always|never pipeline, in addition to a
      list of
      broken sites to never pipeline for. I want mail to get through but also
      want to know if something is broken.

      Is it possible/permissible to add header that indicates the problem when
      it is invoked? Or perhaps this could be handled with an external
      filter--which could also (optionally) warn sender in case recipient
      decides to scream about duplicate messages? (would be nice if MTA's
      could complain to each other about problems.)

      --
      jd
    • mobiru
      ... Option 3 with switches to also always|never pipeline, in addition to a list of broken sites to never pipeline for. I want mail to get through but also want
      Message 38 of 38 , Dec 29, 2005
      • 0 Attachment
        > Wietse Venema wrote:
        >
        >> Possible configuration settings:
        >>
        >> 1) Eliminate the problem. Don't ignore server garbage, and
        >> always wait for the END-OF-DATA reply before sending QUIT, so
        >> that the bug is not triggered. The has a minor performance
        >> impact for deliveries to sites with correct command pipelining
        >> implementations. Supply switch A) so that masochists can force
        >> Postfix to pipeline END-OF-DATA and QUIT anyway (thus triggering
        >> the bug and causing multiple delivery attempts).
        >>
        >> 2) Pretend the problem does not exist. Ignore (but log) server
        >> garbage, and pipeline the END-OF-DATA and QUIT commands. This
        >> triggers the bug with incorrect command pipelining implementations,
        >> does not cause multiple deliveries, but may result in lost
        >> mail, in which case we blame the victim. Supply switch B) so
        >> that masochists can force Postfix not to ignore server garbage
        >> (thus causing multiple delivery attempts).
        >>
        >> 3) Share the pain. Don't ignore server garbage. Send END-OF-DATA
        >> and QUIT pipelined with new mail, and non-pipelined after some
        >> configurable time. This does not penalize normal deliveries to
        >> sites with correct SMTP implementations. Sites with defective
        >> implementations receive 2 copies of email, providing some
        >> incentive to fix their systems.
        >
        Option 3 with switches to also always|never pipeline, in addition to a
        list of
        broken sites to never pipeline for. I want mail to get through but also
        want to know if something is broken.

        Is it possible/permissible to add header that indicates the problem when
        it is invoked? Or perhaps this could be handled with an external
        filter--which could also (optionally) warn sender in case recipient
        decides to scream about duplicate messages? (would be nice if MTA's
        could complain to each other about problems.)

        --
        jd
      Your message has been successfully submitted and would be delivered to recipients shortly.