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

Postfix 2.4 patchlevel 05 available

Expand Messages
  • Wietse Venema
    Postfix stable release 2.4.5 fixes a one-bit typing error that slipped in during code cleanup for the Postfix 2.4.4 release, making the loopback TCP
    Message 1 of 5 , Jul 31 5:34 PM
    • 0 Attachment
      Postfix stable release 2.4.5 fixes a one-bit typing error that
      slipped in during code cleanup for the Postfix 2.4.4 release, making
      the loopback TCP performance workaround ineffective. Since I will
      be traveling in the coming weeks I am releasing Postfix 2.4.5 now.

      Wietse

      Postfix stable release 2.4.4 fixes multiple problems with Milter
      support, and provides workarounds for SASL inter-operability and
      loopback TCP performance problems.

      Postfix snapshot 20070731 and earlier snapshots address the same
      problems. Postfix 2.3.12 will be released soon, with a back-ported
      version of the more important fixes.

      This is a summary of changes; for details please see HISTORY or
      RELEASE_NOTES below.

      MILTER bugfix:
      When a milter replied with ACCEPT at or before the first RCPT
      command, the cleanup server would apply the non_smtpd_milters
      setting as if the message was a local submission. Problem
      reported by Jukka Salmi.

      MILTER bugfix:
      Problem with header updates after body updates. Reported by
      Jose-Marcio Martins da Cruz.

      MILTER robustness:
      Assorted cleanups to harden error handling in the Postfix Milter
      client.

      SASL workaround for Postfix SMTP client:
      Some non-Cyrus SASL SMTP servers require SASL login without
      authzid (authoriZation ID), i.e. the client must send only the
      authcid (authentiCation ID) + the authcid's password. This is
      now the default Postfix SMTP client behavior.

      Loopback TCP performance workaround:
      Some systems exhibited poor SMTP and Milter performance with
      loopback (127.0.0.1) connections. Problem reported by Mark
      Martinec.

      Available from ftp://ftp.porcupine.org/mirrors/postfix-release/official:

      26242 Jul 31 13:15 postfix-2.4-patch04.gz
      472117 Jul 31 10:20 postfix-2.4.4.HISTORY
      9175 Jul 20 11:27 postfix-2.4.4.RELEASE_NOTES
      2934579 Jul 31 14:00 postfix-2.4.4.tar.gz
      280 Jul 31 14:00 postfix-2.4.4.tar.gz.sig

      Soon available from the mirrors listed at http://www.postfix.org/

      Wietse

      RELEASE_NOTES file entries:
      ===========================

      By default, the Postfix Cyrus SASL client no longer sends a
      SASL authoriZation ID (authzid); it sends only the SASL
      authentiCation ID (authcid) plus the authcid's password. Specify
      "send_cyrus_sasl_authzid = yes" to get the old behavior, which
      is to send the (authzid, authcid, password), with the authzid
      equal to the authcid. This workaround for non-Cyrus SASL servers
      is back-ported from Postfix 2.5.

      HISTORY file entries:
      =====================
      20070613

      Bugfix: the Milter client assumed that a Milter application
      does not modify the message header or envelope, after that same
      Milter application has modified the message body of that same
      email message. This is not a problem with updates by different
      Milter applications. Problem was triggered by Jose-Marcio
      Martins da Cruz. Also simplified the handling of queue file
      update errors. File: milter/milter8.c.

      20070614

      Workaround: some non-Cyrus SASL SMTP servers require SASL login
      without authzid (authoriZation ID), i.e. the client must send
      only the authcid (authentiCation ID) + the authcid's password.
      In this case the server is supposed to derive the authzid from
      the authcid. This works as expected when authenticating to a
      Cyrus SASL SMTP server. To get the old behavior specify
      "send_cyrus_sasl_authzid = yes", in which case Postfix sends
      the (authzid, authcid, password), with the authzid equal to
      the authcid. File: xsasl/xsasl_cyrus_client.c.

      20070619

      Portability: /dev/poll support for Solaris chroot jail setup
      scripts. Files: examples/chroot-setup/Solaris8,
      examples/chroot-setup/Solaris10.

      20070719

      Cleanup: Milter client error handling, so that the (Postfix
      SMTP server's Milter client) does not get out of sync with
      Milter applications after the (cleanup server's Milter client)
      encounters some non-recoverable problem. Files: milter/milter8.c,
      smtpd/smtpd.c.

      20070729

      Performance: workaround for poor TCP performance on loopback
      (127.0.0.1) connections. Problem reported by Mark Martinec.
      Files: util/vstream_tweak.c, milter/milter8.c, smtp/smtp_connect.c,
      smtpstone/*source.c.

      20070730

      Bugfix: when a milter replied with ACCEPT at or before the
      first RCPT command, the cleanup server would apply the
      non_smtpd_milters setting as if the message was a local
      submission. Problem reported by Jukka Salmi. Also, the cleanup
      server would get out of sync with the milter when a milter
      replied with ACCEPT at the DATA command. Files:
      cleanup/cleanup_envelope.c, smtpd/smtpd.c, milter/milters.c.
    • Mark Martinec
      ... Perfect! I tried with postfix-current-2.5.20070731 and transfer of a large mail body to a milter on a loopback interface is now more than 50 times faster
      Message 2 of 5 , Aug 1, 2007
      • 0 Attachment
        > Postfix stable release 2.4.5 fixes a one-bit typing error that
        > slipped in during code cleanup for the Postfix 2.4.4 release,
        > making the loopback TCP performance workaround ineffective.

        > Loopback TCP performance workaround:
        > Some systems exhibited poor SMTP and Milter performance with
        > loopback (127.0.0.1) connections.

        Perfect! I tried with postfix-current-2.5.20070731 and transfer
        of a large mail body to a milter on a loopback interface is now
        more than 50 times faster (38 MB/s).
        Capture: http://www.ijs.si/~mark/tmp/dkim-pf-20070731.tcpdump.bz2

        Mark
      • Wietse Venema
        ... The workaround is version dependent (#ifdef VSTREAM_CTL_BUFSIZE). - Postfix 2.5 uses large VSTREAM buffers on connections with large MSS. - Postfix
        Message 3 of 5 , Aug 1, 2007
        • 0 Attachment
          Mark Martinec:
          > > Postfix stable release 2.4.5 fixes a one-bit typing error that
          > > slipped in during code cleanup for the Postfix 2.4.4 release,
          > > making the loopback TCP performance workaround ineffective.
          >
          > > Loopback TCP performance workaround:
          > > Some systems exhibited poor SMTP and Milter performance with
          > > loopback (127.0.0.1) connections.
          >
          > Perfect! I tried with postfix-current-2.5.20070731 and transfer
          > of a large mail body to a milter on a loopback interface is now
          > more than 50 times faster (38 MB/s).
          > Capture: http://www.ijs.si/~mark/tmp/dkim-pf-20070731.tcpdump.bz2

          The workaround is version dependent (#ifdef VSTREAM_CTL_BUFSIZE).

          - Postfix 2.5 uses "large" VSTREAM buffers on connections with
          "large" MSS.

          - Postfix 2.[34] use the same old 4096 byte VSTREAM buffers and
          turn off Nagle delays on connections with "large" MSS.

          The 2.5 VSTREAM code needs to prove itself first for some time.
          It should make very little difference with today's loopback
          interfaces.

          Wietse
        • Pascal Maes
          Hello I think that when the size of the message is greater then the limit, the message is rejected. That s the whole message which is rejected. Is it possible
          Message 4 of 5 , Sep 28, 2007
          • 0 Attachment
            Hello

            I think that when the size of the message is greater then the limit,
            the message is rejected.
            That's the whole message which is rejected.

            Is it possible to reject a short part of the message ?

            Regards,
            --
            Pascal
          • Noel Jones
            ... Don t confuse a bounce with a reject. A reject sends a short 550 rejected ... response to the client during the SMTP transaction without returning any
            Message 5 of 5 , Sep 28, 2007
            • 0 Attachment
              At 08:24 AM 9/28/2007, Pascal Maes wrote:
              >Hello
              >
              >I think that when the size of the message is greater then the limit,
              >the message is rejected.
              >That's the whole message which is rejected.
              >
              >Is it possible to reject a short part of the message ?
              >
              >Regards,
              >--
              >Pascal

              Don't confuse a bounce with a reject.

              A reject sends a short "550 rejected ..." response to the client
              during the SMTP transaction without returning any portion of the
              message. The sender's mail server may send a bounce message to them,
              you have no control over that.

              If you are sending bounces (you accept the mail, then send a DSN or a
              return message indicating non-delivery), you can control the size of
              the bounce with bounce_size_limit.
              http://www.postfix.org/postconf.5.html#bounce_size_limit

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