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.