This is the Postfix 3.6 (experimental) release. The stable Postfix release is called postfix-3.5.x where 3=major release number, 5=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.6-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 3.4 or earlier, read RELEASE_NOTES-3.5 before proceeding. License change --------------- This software is distributed with a dual license: in addition to the historical IBM Public License 1.0, it is now also distributed with the more recent Eclipse Public License 2.0. Recipients can choose to take the software under the license of their choice. Those who are more comfortable with the IPL can continue with that license. Major changes with snapshot 20220109 ==================================== Starting with Postfix version 3.6, the "latest" compatibility level is the Postfix version that introduced the last incompatible change. The level is formatted as 'major.minor.patch', where 'patch' is usually omitted and defaults to zero. Earlier compatibility levels are 0, 1 and 2. This also introduces support for the <=level, " which matches an empty sender address, and the "@domain" wilcard pattern. More information about those can be found in the postconf(5) manpage. Example: /etc/postfix/main.cf: # Allow root and postfix full control, anyone else can only # send mail as themselves. Use "uid:" followed by the numerical # UID when the UID has no entry in the UNIX password file. local_login_sender_maps = inline:{ { root = *}, { postfix = * } }, pcre:/etc/postfix/login_senders /etc/postfix/login_senders: # Allow both the bare username and the user@domain forms. /(.+)/ $1 $1@example.com Major changes with snapshot 20201003 ==================================== The Postfix build system will no longer automatically disable DNSSEC support when it determines that Postfix will use libc-musl. Instead, Postfix will rely on the new dnssec_probe feature to determine at runtime if DNSSEC validation is available. DNSSEC support may be broken for reasons other than compatibility issues with the libc implementation. Major changes with snapshot 20200930 ==================================== When a Postfix process requires DNSSEC support (typically, for Postfix DANE support), the process may do a one-time test to determine if DNSSEC validation is available. DNSSEC support may be broken because of local configuration, libc incompatibility, or network infrastructure issues. Background: DNSSEC validation is needed for Postfix DANE support; this ensures that Postfix receives TLSA records with secure TLS server certificate info. When DNSSEC validation is unavailable, mail deliveries using opportunistic DANE will not be protected by server certificate info in TLSA records, and mail deliveries using mandatory DANE will not be made at all. The dnssec_probe parameter specifies the DNS query type (default: "ns") and DNS query name (default: ".") that Postfix may use to determine whether DNSSEC validation is available. Specify an empty value to disable this feature. By default, a Postfix process will send a DNSSEC probe after 1) the process made a DNS query that requested DNSSEC validation, 2) the process did not receive a DNSSEC validated response to this query or to an earlier query, and 3) the process did not already send a DNSSEC probe. When the DNSSEC probe has no response, or when the response is not DNSSEC validated, Postfix logs a warning that DNSSEC validation may be unavailable. Examples: warning: DNSSEC validation may be unavailable warning: reason: dnssec_probe 'ns:.' received a response that is not DNSSEC validated warning: reason: dnssec_probe 'ns:.' received no response: Server failure Incompatible change with snapshot 20200920 ========================================== Internal protocols have changed. You need to "postfix stop" before updating, or before backing out to an earlier release, otherwise long-running daemons (pickup, qmgr, verify, tlsproxy, postscreen) may fail to communicate with the rest of Postfix (warnings, timeouts). The purpose of this change is to produce better error messages, for example, when someone configures the discard daemon as a bounce service in master.cf, or vice versa. This change will break third-party code that implements a Postfix-internal protocol such as qpsmtpd. Programs that depend on Postfix internal details are not supported. Incompatible change with snapshot 20200705 ========================================== The minimum OpenSSL version is 1.1.1, which will reach the end of life by 20203-09-11. The default digest has changed from md5 to sha256 (Postfix 3.6 with compatibility_level >= 3). With a lower compatibility_level setting, Postfix defaults to using md5, and logs a warning when a Postfix configuration specifies no explicit digest type. Export-grade Diffie-Hellman key exchange is no longer supported, and the tlsproxy_tls_dh512_param_file parameter is ignored, Incompatible change with snapshot 20200531 ========================================== Postfix delivery agents now log an explicit record when delegating delivery to a different Postfix delivery agent. For example, with "best_mx_transport = local", an SMTP delivery agent will now log when a recipient will be delivered locally. This makes the delegating delivery agent visible, where it would otherwise have remained invisible, which would complicate troubleshooting. postfix/smtp[pid]: queueid: passing to transport=local This will usually be followed by logging for an actual delivery: postfix/local[pid]: queueid: to=, relay=local, ... Other examples: the local delivery agent defers mailbox delivery through mailbox_transport or through fallback_transport. Major changes with snapshot 20200509 ==================================== The threadsafe resolver API (res_nxxx() calls) is now the default, not because the API is threadsafe, but because new features are being added there. To build old style, build with: make makefiles CCARGS="-DNO_RES_NCALLS..." This is also the default for systems that are known not to support the threadsafe resolver API, such systems that use libc-musl. Incompatible changes with snapshot 20200416 =========================================== Security: this release disables DANE support on Linux systems with libc-musl, because libc-musl provides no indication whether DNS responses are authentic. This broke DANE support without a clear explanation.