[Fwd: Postfix 2.3 stable release available]

[Nick Smith]

On 7/12/06, Mike Jakubik <mikej at rogers.com> wrote:
> Just an FYI for postfix users. Bonus points for the first one to try and
> see if it works with MS :)
>
> -------- Original Message --------
> Subject:        Postfix 2.3 stable release available
> Date:   Tue, 11 Jul 2006 21:16:18 -0400 (EDT)
> From:   wietse at porcupine.org (Wietse Venema)
> Reply-To:       Postfix users <postfix-users at postfix.org>
> To:     Postfix announce <postfix-announce at postfix.org>
> CC:     Postfix users <postfix-users at postfix.org>
>
>
>
> A few months later than usual, Postfix stable release 2.3 is now
> available. The release was postponed until Postfix was complete
> enough for today's email environment. Hopefully I can now spend
> more time doing new projects.
>
> You can find the Postfix 2.3.0 source code via the mirror sites
> listed at http://www.postfix.org/. If it's not there today, then
> it should show up in the course of the next 24 hours.
>
>    435112 Jul 11 17:24 postfix-2.3.0.HISTORY
>     35125 Jul 11 16:40 postfix-2.3.0.RELEASE_NOTES
>   2770830 Jul 11 17:25 postfix-2.3.0.tar.gz
>       280 Jul 11 17:25 postfix-2.3.0.tar.gz.sig
>
> What follows is a very much compressed summary of what has changed.
> See the RELEASE_NOTES file for compatibility issues that may affect
> your site. The HISTORY file gives a blow-by-blow account of what
> happened over the past 1+ year.
>
>         Wietse
>
> - DSN (delivery status notification) support as described in RFC
> 3461 .. RFC 3464.  This gives email senders control over notification
> of successful, delayed, and failed delivery.  DSN involves extra
> parameters to the SMTP "MAIL FROM" and "RCPT TO" commands, as well
> as extra Postfix sendmail command line options for mail submission.
> See DSN_README for details, including how to limit the amount of
> information that you are willing to disclose.
>
> - Major updates to the TLS (SMTP encryption and authentication)
> support.  Postfix 2.3 introduces a configuration user interface
> that is based on the concept of TLS security levels (none, may,
> encrypt, verify, secure) and that can more effectively deal with
> DNS spoofing.  The old configuration user interface, with multiple
> boolean parameters to enable or enforce TLS, is still supported but
> will be removed after a few releases.  See TLS_README for details.
>
> - Milter (mail filter) application support, compatible with Sendmail
> version 8.13.6 and earlier. This allows you to run a large number
> of plug-ins to reject unwanted mail, and to sign mail with for
> example domain keys. All Milter functions are implemented except
> the one that replaces the message body (this will be added later).
> All this and more is described in MILTER_README.
>
> - Enhanced status codes (RFC 3463). For example, status code 5.1.1
> means "recipient unknown".  Mail clients can translate these status
> codes into text in the user's own language, and greatly improve the
> user experience. Enhanced status codes can be specified in Postfix
> access tables, in header/body_checks content filter rules, in "rbl"
> reply templates, and so on.
>
> - Configurable bounce messages with support for non-ASCII character
> sets.  Details are in the bounce(5) manual page.
>
> - Plug-in support for SASL authentication in the Postfix SMTP server
> and client. With this, Postfix can support multiple SASL implementations
> without conflicting source code patches.  Postfix 2.3 has Dovecot
> SASL support built into the SMTP server.  As before, support for
> Cyrus SASL is available as add-on feature for the Postfix SMTP
> server and client.  See SASL_README for more information.
>
> - Support for sender-dependent ISP accounts, in the form of
> sender-dependent relayhost lookup and sender-dependent SASL
> username/password lookup.
>
> - The Postfix SMTP client now implements both the SMTP and LMTP
> protocols.  This means that a lot of features have become available
> for LMTP mail delivery, including the shared TCP connection cache.
>
> - After TLS handshake failure, the SMTP client will now reconnect
> to the same server to try plaintext delivery (if TLS policy permits).
> Earlier Postfix versions would skip the server and defer delivery
> if no alternate MX host was available.
>
> - All delay logging now has sub-second resolution. Besides the total
> delay, Postfix logs separate delays for different stages of delivery
> (time in queue, time in queue manager, time to set up connection,
> and time to deliver). This gives better insight into the nature of
> performance bottle necks.
>
> - Smarter utilization of cached SMTP connections. When one destination
> has multiple inbound SMTP servers, the Postfix SMTP client will now
> send less mail via the slower ones, and more mail via the faster ones.
>
> - Support for empty MX records. Older Postfix versions treat this
> as a malformed response and defer mail delivery.
>
>
> --
> MailScanner mailing list
> mailscanner at lists.mailscanner.info
> http://lists.mailscanner.info/mailman/listinfo/mailscanner
>
> Before posting, read http://wiki.mailscanner.info/posting
>
> Support MailScanner development - buy the book off the website!
>
Well, in addition to the good stuff listed in the release
announcement, there is the
not-quite-so-good-and-potentially-very-alarming-stuff mentioned here:

http://archives.neohapsis.com/archives/postfix/2006-06/0345.html

IMPORTANT NOTICE. Once milter support is added to Postfix 2.3 production
snapshots and later appears in the 2.3.0 production release, versions of
MailScanner designed for ALL earlier versions of Postfix will ROUTINELY
corrupt mail (not just sometimes as they do now).

DO NOT use Mailscanner implementations for earlier Postfix releases with
Postfix 2.3. It was always discouraged, now it is definitely outright
broken. You have been warned.

I really don't want to fan any flames, but at the same time I'd like
to know exactly how worried to be about statements like this. Speaking
personally, I have yet to see a single issue (up to 2.2.10) caused by
MailScanner manipulating Postfix queue files (~350k messages per day),
but that is not to say that problems have never been caused (eg as
referred by the OP from the thread above)

I'd very much like to look at milter-ahead or something similar to cut
down accepting messages to unknown users. Is there any genuine reason
to believe that MS 4.54.5 will cause mass destruction as implied here?

Thanks

Nick