The stable Postfix release is called postfix-2.9.x where 2=major
release number, 9=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.10-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.8 or earlier, read RELEASE_NOTES-2.9
before proceeding.

Major changes with snapshot 20130201
====================================

The "postconf -Mn" feature is withdrawn, in favor of a better design
that not only supports queries but also updates of named properties
of a master.cf service entry. But there is not enough time to finish
that for Postfix 2.10.

Incompatible changes with snapshot 20121224
===========================================

The postconf command produces more warnings:

- An attempt to modify a read-only parameter (process_name, process_id)
  in main.cf or master.cf.

- An undefined $name in a parameter value in main.cf or master.cf
  (except for backwards-compatibility parameters such as $virtual_maps).

Major changes with snapshot 20121224
====================================

The postconf command has been updated to make trouble-shooting (and
support) easier. In summary, use "postconf -Mnxf" and "postconf
-nxf" to review master.cf and main.cf parameter settings with
expanded parameter values.

- "postconf -x" now expands $name in main.cf and master.cf parameter
  values.

- "postconf -Mn" now shows services that have "-o name=value"
  parameter settings in master.cf.

- postconf warns about attempts to modify a read-only parameter
  (process_name, process_id) in main.cf or master.cf.

- postconf warns about an undefined $name in a parameter value in
  main.cf or master.cf (except for backwards-compatibility parameters
  such as $virtual_maps).

Added with snapshot 20121227:

- "postconf -o name=value" overrides main.cf parameter settings.
  This can be used, for example, to examine stress-dependent settings
  with "postconf -x -o stress=yes".

Incompatible changes with snapshot 20121123
===========================================

The postscreen deep protocol tests now log the last command before
a protocol error ("UNIMPLEMENTED" when the last command is not
implemented, "CONNECT" when there was no prior command). The
changed logfile messages are:

NON-SMTP COMMAND from [address]:port after command: text
BARE NEWLINE from [address]:port after command
COMMAND TIME LIMIT from [address]:port after command
COMMAND COUNT LIMIT from [address]:port after command
COMMAND LENGTH LIMIT from [address]:port after command

Incompatible changes with snapshot 20121007
===========================================

As part of a forward compatibility safety net, the Postfix installation
procedure adds the following smtpd_relay_restrictions entry to
main.cf when there is none:

    smtpd_relay_restrictions = 
	permit_mynetworks 
	permit_sasl_authenticated 
	defer_unauth_destination

If your site has a complex mail relay policy configured under
smtpd_recipient_restrictions, this safety net will defer mail that
the built-in smtpd_relay_restrictions setting would bounce. 

To eliminate this safety net, take one of the following three
actions:

- Set smtpd_relay_restrictions empty, and keep using the existing
  mail relay authorization policy in smtpd_recipient_restrictions.

- Copy the existing mail relay authorization policy from
  smtpd_recipient_restrictions to smtpd_relay_restrictions.

- Set smtpd_relay_restrictions by hand to the new built-in
  policy: permit_mynetworks reject_unauth_destination.

There is no need to change the value of smtpd_recipient_restrictions.

Major changes with snapshot 20121007
====================================

This version introduces the smtpd_relay_restrictions feature
for mail relay control. The new built-in default settings are:

    smtpd_relay_restrictions = 
	permit_mynetworks 
	reject_unauth_destination

    smtpd_recipient_restrictions =
	( optional spam blocking rules would go here )

For comparison, this is the Postfix before 2.10 default:

    smtpd_recipient_restrictions =
	permit_mynetworks 
	reject_unauth_destination
	( optional spam blocking rules would go here )

With Postfix versions before 2.10, the mail relay policy and spam
blocking policy were combined under smtpd_recipient_restrictions,
resulting in error-prone configuration.

As of Postfix 2.10, the mail relay policy is preferably implemented
with smtpd_relay_restrictions, so that a permissive spam blocking
policy under smtpd_recipient_restrictions will not unexpectedly
result in a permissive mail relay policy.

As usual, this new feature is introduced with safety nets to prevent
surprises when a site upgrades from an earlier Postfix release.

1 - FORWARD COMPATIBILITY SAFETY NET: the Postfix installation
    procedure adds the following smtpd_relay_restrictions entry to
    main.cf when there is none:

    smtpd_relay_restrictions = 
	permit_mynetworks 
	permit_sasl_authenticated 
	defer_unauth_destination

    If your site has a complex mail relay policy configured under
    smtpd_recipient_restrictions, this safety net will defer mail
    that the built-in smtpd_relay_restrictions setting would bounce.

    To eliminate this safety net, take one of the following three
    actions:

    - Set smtpd_relay_restrictions empty, and keep using the existing
      mail relay authorization policy in smtpd_recipient_restrictions.

    - Copy the existing mail relay authorization policy from
      smtpd_recipient_restrictions to smtpd_relay_restrictions.

    - Set smtpd_relay_restrictions by hand to the new built-in
      policy: permit_mynetworks reject_unauth_destination.

    There is no need to change the value of smtpd_recipient_restrictions.

2 - BACKWARDS COMPATIBILITY SAFETY NET: sites that migrate from
    Postfix versions before 2.10 can set smtpd_relay_restrictions
    to the empty value, and use smtpd_recipient_restrictions exactly
    as they used it before.

Incompatible changes with snapshot 20120924
===========================================

Postfix no longer uses FIFOs to emulate UNIX-domain sockets on
Solaris 9 (Vintage 2002!) and later. If you install Postfix for
the first time on an older Solaris system, edit the master.cf file
and replace "unix" with "fifo" for the pickup and qmgr services.

Major changes with snapshot 20120924
====================================

Laptop-friendliness: the default master.cf file now uses "unix"
instead of "fifo" for the pickup and qmgr services. This avoids
periodic disk drive spin-up.

Incompatible changes with snapshot 20120625
===========================================

The postscreen(8)-to-smtpd(8) protocol has changed.  To avoid "cannot
receive connection attributes" warnings and dropped connections,
execute the command "postfix reload". No mail will be lost as long
as the remote SMTP client tries again later.

Major changes with snapshot 20120625
====================================

Support for upstream proxy agent in the postscreen(8) and smtpd(8)
daemons.  To enable the haproxy protocol, specify one of the
following:

    postscreen_upstream_proxy_protocol = haproxy
    smtpd_upstream_proxy_protocol = haproxy

Note 1: smtpd_upstream_proxy_protocol can't be used in smtpd processes
that are behind postscreen. Configure postscreen_upstream_proxy_protocol
instead.

Note 2: To use the nginx proxy with smtpd(8), enable the XCLIENT
protocol with smtpd_authorized_xclient_hosts. This supports SASL
authentication in the proxy agent (Postfix 2.9 and later).

Major changes with snapshot 20120422
====================================

This release adds support to turn off the TLSv1.1 and TLSv1.2
protocols.  Introduced with OpenSSL version 1.0.1, these are known
to cause inter-operability problems with for example hotmail.

The radical workaround is to temporarily turn off problematic
protocols globally:

/etc/postfix/main.cf:
    smtp_tls_protocols = !SSLv2, !TLSv1.1, !TLSv1.2
    smtp_tls_mandatory_protocols = !SSLv2, !TLSv1.1, !TLSv1.2

    smtpd_tls_protocols = !SSLv2, !TLSv1.1, !TLSv1.2
    smtpd_tls_mandatory_protocols = !SSLv2, !TLSv1.1, !TLSv1.2

However, it may be better to temporarily turn off problematic
protocols for broken sites only:

/etc/postfix/main.cf:
    smtp_tls_policy_maps = hash:/etc/postfix/tls_policy

/etc/postfix/tls_policy:
    example.com         may protocols=!SSLv2:!TLSv1.1:!TLSv1.2

Important:

- Note the use of ":" instead of comma or space. Also, note that
  there is NO space around the "=" in "protocols=".

- The smtp_tls_policy_maps lookup key must match the "next-hop"
  destination that is given to the Postfix SMTP client. If you
  override the next-hop destination with transport_maps, relayhost,
  sender_dependent_relayhost_maps, or otherwise, you need to specify
  the same destination for the smtp_tls_policy_maps lookup key.

Major changes with snapshot 20120306
====================================

New master "-w" option, to wait for daemon process initialization
to complete. This feature returns an error exit status if master
daemon initialization fails, or if it does not complete in a
reasonable amount of time. The exit status is used by "postfix
start" to provide more accurate information to system start-up
scripts.

Major changes with snapshot 20120303
====================================

New control for "permit" logging in smtpd_mumble_restrictions.
Specify "smtpd_log_access_permit_actions = static:all" to log all
"permit"-style actions, or specify a list of explicit names.  More
details are in the postconf(5) manpage.
