This is the Postfix 3.1 (experimental) release.

The stable Postfix release is called postfix-3.0.x where 3=major
release number, 0=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-3.1-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.11 or earlier, read RELEASE_NOTES-3.0
before proceeding.


Major changes with snaphot 20151227
===================================

This introduces a safety limit on the number of address verification
probes in the active queue (address_verify_pending_request_limit),
by default 1/4 of the active queue maximum size. The queue manager
enforces the limit by tempfailing probe messages that exceed the
limit. The design avoids dependency on global counters that may get
out of sync after a process crashes.

Tempfailing requests in this manner is not as bad as one might
think.  The Postfix verify cache proactively updates active addresses
well before they expire. The address_verify_pending_request_limit
affects only unknown addresses and inactive addresses that have
expired (by default, after 31 days).

Incompatible change with Postfix snapshot 20150721
--------------------------------------------------

As of the middle of 2015, all supported Postfix releases no longer
enable "export" grade ciphers for opportunistic TLS, and no longer
use the deprecated SSLv2 and SSLv3 protocols for mandatory or
opportunistic TLS.

These changes are very unlikely to cause problems with server-to-server
communication over the Internet, but they may result in interoperability
problems with ancient client or server implementations on internal
networks.  To address this problem, you can revert the changes with:

Postfix SMTP client settings:

    lmtp_tls_ciphers = export
    smtp_tls_ciphers = export
    lmtp_tls_protocols = !SSLv2
    smtp_tls_protocols = !SSLv2
    lmtp_tls_mandatory_protocols = !SSLv2
    smtp_tls_mandatory_protocols = !SSLv2

Postfix SMTP server settings:

    smtpd_tls_ciphers = export
    smtpd_tls_protocols =
    smtpd_tls_mandatory_protocols = !SSLv2

These settings, if put in main.cf, affect all Postfix SMTP client
or server communication, which may be undesirable. To be more
selective, use "-o name=value" parameter overrides on specific
services in master.cf. Execute the command "postfix reload" to make
the changes effective.

Major changes with snaphot 20150710
===================================

postscreen support for the TTL of DNSBL and DNSWL lookup results
----------------------------------------------------------------

Historically, the default setting "postscreen_dnsbl_ttl = 1h" assumes
that a "not found" result from a DNSBL server will be valid for one
hour.  This may have been adequate five years ago when postscreen
was first implemented, but nowadays, that one hour can result in
missed opportunities to block new spambots.

To address this, postscreen now respects the TTL of DNSBL "not
found" replies, as well as the TTL of DNSWL replies (both "found"
and "not found").  The TTL for a "not found" reply is determined
according to RFC 2308 (the TTL of an SOA record in the reply).

Support for DNSBL or DNSWL reply TTL values is controlled by two
configuration parameters:

postscreen_dnsbl_min_ttl (default: 60 seconds).

    This parameter specifies a minimum for the amount of time that
    a DNSBL or DNSWL result will be cached in the postscreen_cache_map.
    This prevents an excessive number of postscreen cache updates
    when a DNSBL or DNSWL server specifies a very small reply TTL.

postscreen_dnsbl_max_ttl (default: $postscreen_dnsbl_ttl or 1 hour)

    This parameter specifies a maximum for the amount of time that
    a DNSBL or DNSWL result will be cached in the postscreen_cache_map.
    This prevents cache pollution when a DNSBL or DNSWL server
    specifies a very large reply TTL.

The postscreen_dnsbl_ttl parameter is now obsolete, and has become
a default value for the new postscreen_dnsbl_max_ttl parameter.

Destination-independent delivery rate delay
-------------------------------------------

Support to enforce a destination-independent delay between email
deliveries.  The following example inserts 20 seconds of delay
between deliveries with the SMTP transport, limiting the delivery
rate to at most three messages per minute.

/etc/postfix/main.cf:
    smtp_transport_rate_delay = 20s

For details, see the description of default_transport_rate_delay
and transport_transport_rate_delay in the postconf(5) manpage.
