This is the Postfix 2.12 (experimental) release. The stable Postfix release is called postfix-2.11.x where 2=major release number, 11=minor release number, x=patchlevel. The stable release never changes except for patches that address bugs or emergencies. Patches change the patchlevel and the release date. New features are developed in snapshot releases. These are called postfix-2.12-yyyymmdd where yyyymmdd is the release date (yyyy=year, mm=month, dd=day). Patches are never issued for snapshot releases; instead, a new snapshot is released. The mail_release_date configuration parameter (format: yyyymmdd) specifies the release date of a stable release or snapshot release. If you upgrade from Postfix 2.10 or earlier, read RELEASE_NOTES-2.11 before proceeding. Notes for distribution maintainers ---------------------------------- The Postfix build/install procedure has changed to support Postfix shared libraries and database plugins. [Update 20140625: As a result of maintainer feedback, 1) the Postfix release version is no longer used as a filename suffix for Postfix shared libraries, database plugins or dynamicmaps.cf; 2) non-executable files have been moved away from $daemon_directory to $meta_directory (usually, /etc/postfix). The release notes below for 20140530 have been updated accordingly.] To avoid massive frustration due to broken patches, PLEASE BUILD POSTFIX FIRST WITHOUT APPLYING ANY PATCHES. Follow the INSTALL instructions (see "Building with Postfix shared libraries and database plugins" below), and see how things work and what the shared libraries, database plugin, and configuration files look like. Only then, go ahead and perform your platform-specific customizations. Maintainers may also benefit from the makedefs documentation (mantools/srctoman - makedefs | nroff -man | less) with information about build options that are not described in the INSTALL instructions. Major changes with snapshot 20140801 ==================================== The Postfix SMTP server now logs at the end of a session how many times an SMTP command was successfully invoked, followed by the total number of invocations if it is different. This logging will often be enough to diagnose a problem without verbose logging or network sniffer. Normal session, no TLS: disconnect from name[addr] ehlo=1 mail=1 rcpt=1 data=1 quit=1 Normal session. with TLS: disconnect from name[addr] ehlo=2 starttls=1 mail=1 rcpt=1 data=1 quit=1 All recipients rejected, no ESMTP command pipelining: disconnect from name[addr] ehlo=1 mail=1 rcpt=0/1 quit=1 All recipients rejected, with ESMTP command pipelining: disconnect from name[addr] ehlo=1 mail=1 rcpt=0/1 data=0/1 rset=1 quit=1 Password guessing bot, hangs up without QUIT: disconnect from name[addr] ehlo=1 auth=0/1 Mis-configured client trying to use TLS wrappermode on port 587: disconnect from name[addr] unknown=0/1 Logfile analyzers can trigger on the presence of "/". It indicates that Postfix rejected at least one command. Incompatible changes with snapshot 20140714 =========================================== After upgrading Postfix, the "postfix reload" (or start/stop) is required. Several Postfix-internal protocols have been extended to support SMTPUTF8. Failure to reload or restart will result in mail staying queued and the logile will contain warning messages about unexpected attributes. Major changes with snapshot 20140715 ==================================== Support for Email Address Internationalization (EAI) as defined in RFC 6531..6533. This supports UTF-8 in SMTP/LMTP sender addresses, recipient addresses, and message header values. The implementation is based on initial work by Arnt Gulbrandsen that was funded by CNNIC. See SMTPUTF8_README for a description of Postfix SMTPUTF8 support. Major changes with snapshot 20140703 ==================================== This release introduces three new configuration parameters that control error recovery for failed SMTPD policy requests. * smtpd_policy_service_default_action (default: 451 4.3.5 Server configuration problem): The default action when an SMTPD policy service request fails. * smtpd_policy_service_try_limit (default: 2): The maximal number of attempts to send an SMTPD policy service request before giving up. This must be a number greater than zero. * smtpd_policy_service_retry_delay (default: 1s): The delay between attempts to resend a failed SMTPD policy service request. This must be a number greater than zero. See postconf(5) for details and limitations. Incompatible changes with snapshot 20140701 =========================================== For clarity, the pipeline and random lookup tables are now called pipemap and randmap, respectively. The 20140618 text below has been updated accordingly. The old names remain supported for a while. Incompatible changes with snapshot 20140625 =========================================== For compliance with file system policies, some files have been moved from $daemon_directory to the directory specified with the new meta_directory configuration parameter which has the same default value as the config_directory parameter. This change affects non-executable files that are shared between multiple Postfix instances such as postfix-files, dynamicmaps.cf, and multi-instance template files. For backwards compatibility with Postfix 2.6 .. 2.11, specify "meta_directory = $daemon_directory" in main.cf before installing or upgrading Postfix, or specify "meta_directory = /path/name" on the "make makefiles", "make install" or "make upgrade" command line. Incompatible changes with snapshot 20140618 =========================================== The pipe(8) delivery agent will now log a limited amount of command output upon successful delivery, and will report that output in "SUCCESS" delivery status reports. This is another good reason to disable inbound DSN requests at the Internet perimeter. Major changes with snapshot 20140618 ==================================== This introduces several lookup tables with unusual properties. randmap table ------------ The "randmap" lookup table performs random selection. This may be used to implement load balancing, for example: /etc/postfix/transport: # Deliver my own domain as usual. example.com : .example.com : /etc/postfix/main.cf: transport_maps = # Deliver my own domain as usual. hash:/etc/postfix/transport # Deliver other domains via randomly-selected relayhosts randmap:!smtp:smtp0.example.com!smtp:smtp1.example.com A variant of this can randomly select SMTP clients with different smtp_bind_address settings. The first ASCII character after "randmap:" will be used as the separator between the results that follow (do not use space, ",", ":" or non-ASCII). Some future version may support the form randmap:/path/to/file, to load the list of random values, one per line, from a textfile. To implement different weights, specify lookup results multiple times. For example, to choose smtp:smtp1.example.com twice as often as smtp:smtp0.example.com, specify smtp:smtp1.example.com twice. pipemap table -------------- As the name suggests, the "pipemap" table implements a pipeline of lookup tables. The name of the table specifies the pipeline as a sequence of tables. For example, the following prevents SMTP mail to system accounts that have "nologin" as their login shell: /etc/postfix/main.cf: local_recipient_maps = pipemap:!unix:passwd.byname!pcre:/etc/postfix/no-nologin.pcre alias_maps /etc/postfix/no-nologin.pcre: !/nologin/ whatever The first ASCII character after "pipemap:" will be used as the separator between the lookup tables that follow (do not use space, ",", ":" or non-ASCII). Each "pipemap:" query is given to the first table. Each table lookup result becomes the query for the next table in the pipeline, and the last table produces the final result. When any table lookup produces no result, the entire pipeline produces no result. Some future version may support the form pipemap:/path/to/file, to load the list of lookup tables, one per line, from a textfile. Incompatible changes with snapshot 20140530 =========================================== The Postfix 2.12 build procedure expects that you specify database library dependencies with variables named AUXLIBS_CDB, AUXLIBS_LDAP, etc. With Postfix 2.12 and later, the old AUXLIBS variable still supports building a statically-loaded CDB etc. database client, but only the new AUXLIBS_CDB etc. variables support building a dynamically-loaded or statically-loaded CDB etc. database client. See CDB_README, LDAP_README, etc. for details. Failure to follow this advice will defeat the purpose of dynamic database client loading. Every Postfix executable file will have database library dependencies. And that was exactly what dynamic database client loading was meant to avoid. Major changes with snapshot 20140530 ==================================== Support to build Postfix with Postfix shared libraries, and with dynamically-loadable database clients. Postfix shared libraries introduce minor runtime overhead and result in smaller Postfix executable files. Dynamically-loadable database clients are useful when you distribute or install pre-compiled packages. Postfix 2.12 supports dynamic loading for CDB, LDAP, LMDB, MYSQL, PCRE, PGSQL, SDBM, and SQLITE database clients. This is based on Debian code by LaMont Jones, and based on a port by Viktor Dukhovni. Currently, support exists for recent versions of Linux, FreeBSD, MacOS X, and for the ancient Solaris 9. To support Postfix shared libraries and dynamically-loadable database clients, the Postfix build procedure had to be changed (specifically, the files makedefs and Makefile.in, and the files postfix-install and post-install that install or update Postfix). These changes are introduced early in the annual Postfix development cycle to give down-stream maintainers sufficient time to prepare their build systems for the next stable Postfix release in 2015. Building with Postfix shared libraries and database plugins ----------------------------------------------------------- Please see the INSTALL section "Building with Postfix shared libraries and database plugins" for fine-tuning details. To build with Postfix shared libraries (files named libpostfix-*.so), use: % make makefiles shared=yes ...other arguments... To build with dynamicmaps.cf support and dynamically-loadable database clients (files named postfix-*.so), use: % make makefiles dynamicmaps=yes ...other arguments... This implicitly enables support for Postfix shared libraries. Postfix 2.12 supports dynamic loading for CDB, LDAP, LMDB, MYSQL, PCRE, PGSQL, SDBM, and SQLITE database clients. NOTE: The Postfix 2.12 build procedure expects that you specify database library dependencies with variables named AUXLIBS_CDB, AUXLIBS_LDAP, etc. With Postfix 2.12 and later, the old AUXLIBS variable still supports building a statically-loaded database client, but only the new AUXLIBS_CDB etc. variables support building a dynamically-loaded or statically-loaded CDB etc. database client. See CDB_README, LDAP_README, etc. for details. Failure to follow this advice will defeat the purpose of dynamic database client loading. Every Postfix executable file will have database library dependencies. And that was exactly what dynamic database client loading was meant to avoid. Differences with Debian ----------------------- Besides changes to the Postfix "build" system as described above, the user-visible changes with respect to Debian are: - The new shlib_directory parameter specifies the location of the libpostfix-*.so shared-library files and the postfix-*.so database plugins. You can change the location of these files after Postfix is built. However, you may have to run ldconfig if you change the libpostfix-*.so location. No ldconfig is needed if you keep the libpostfix-*.so files in the compiled-in default $shlib_directory location. - The new meta_directory parameter specifies the location of the file dynamicmaps.cf and some other non-executable files. The meta_directory parameter has the same default value as the config_directory parameter, so this is backwards compatible with Debian (but the default setting may be changed at compile time). - Postfix supports the directory dynamicmaps.cf.d in addition to the file dynamicmaps.cf. Maintainers can use one configuration file per database plugin, which simplifies installation and removal of individual plugins. - Likewise, Postfix supports the directory postfix-files.d in addition to the file postfix-files, Again, maintainers can use one configuration file per database plugin, which simplifies installation and removal of individual plugins. Major changes with snapshot 20140321 ==================================== Delivery status filter support, to replace the delivery status codes and explanatory text of successful or unsuccessful deliveries by Postfix mail delivery agents. This was originally implemented for sites that want to turn certain soft delivery errors into hard delivery errors, but it can also be used to censor out information from delivery confirmation reports. This feature is implemented as a filter that replaces the three-number enhanced status code and descriptive text in Postfix delivery agent success, bounce, or defer messages. Note: this will not override "soft_bounce=yes", and this will not change a successful delivery status into an unsuccessful status or vice versa. The first example turns specific soft TLS errors into hard errors, by overriding the first number in the enhanced status code. /etc/postfix/main.cf: smtp_delivery_status_filter = pcre:/etc/postfix/smtp_dsn_filter /etc/postfix/smtp_dsn_filter: /^4(\.\d+\.\d+ TLS is required, but host \S+ refused to start TLS: .+)/ 5$1 /^4(\.\d+\.\d+ TLS is required, but was not offered by host .+)/ 5$1 The second example removes the destination command name and file name from local(8) successful delivery reports, so that they will not be reported when a sender requests confirmation of delivery. /etc/postfix/main.cf: local_delivery_status_filter = pcre:/etc/postfix/local_dsn_filter /etc/postfix/local_dsn_filter: /^(2\S+ delivered to file).+/ $1 /^(2\S+ delivered to command).+/ $1 This feature is supported in the lmtp(8), local(8), pipe(8), smtp(8) and virtual(8) delivery agents. That is, all delivery agents that actually deliver mail. The new main.cf parameters and default values are: default_delivery_status_filter = lmtp_delivery_status_filter = $default_delivery_status_filter local_delivery_status_filter = $default_delivery_status_filter pipe_delivery_status_filter = $default_delivery_status_filter smtp_delivery_status_filter = $default_delivery_status_filter virtual_delivery_status_filter = $default_delivery_status_filter See the postconf(5) manpage for more details.