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.

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.
