This is the Postfix 3.4 (experimental) release. The stable Postfix release is called postfix-3.3.x where 3=major release number, 3=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.4-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.2 or earlier, read RELEASE_NOTES-3.3 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. Incompatible changes with snapshot 20190126-nonprod ==================================================== This introduces a new master.cf service type 'unix-dgram' that is used by the new postlogd(8) daemon. This type is not supported by older Postfix versions. Before backing out to an older version, edit the master.cf file and remove the postlog entry. Major changes with snapshot 20190126-nonprod ============================================ [TODO: move most of this text to MAILLOG_README file] Support for logging to file or stdout, instead of using syslog. - Logging to file solves a usability problem for MacOS, and eliminates multiple problems with systemd-based systems. - Logging to stdout is useful when Postfix runs in a container, as it eliminates a syslogd dependency. To enable Postfix logging to file or stdout: -------------------------------------------- Add the following line to master.cf if not already present (note: there must be no whitespace at the start of the line): postlog unix-dgram n - n - 1 postlogd To write logs to Postfix logfile (see below for logfile rotation): # postfix stop # postconf maillog_file=/var/log/postfix.log # postfix start To write logs to stdout, typically while Postfix runs in a container: # postconf maillog_file=/dev/stdout # postfix start-fg The maillog_file parameter must contain one of the prefixes that are specified with the maillog_file_prefixes parameter (default: /var, /dev/stdout). This limits the damage from a single configuration mistake. To rotate a Postfix logfile with a daily cronjob: ------------------------------------------------- The command "postfix logrotate" renames the logfile by appending a suffix that contains the date and time, reloads Postfix so that it closes the old logfile, and after a brief pause compresses the old logfile. This command will not rotate the log if it specifies a pathname under the /dev directory, such as /dev/stdout. The command "postfix logrotate" does not (yet) remove old logfiles. Configuration parameters: - maillog_file_compressor (gzip) - maillog_file_rotate_suffix (%Y%M%d-%H%M%S) See the postconf(5) manpage for detailed descriptions. Limitations of logging to Postfix logfile or stdout: ---------------------------------------------------- Background: - Logging to Postfix logfile or stdout requires the Postfix postlogd(8) service. This program ensures that simultaneous logging from different programs will not get mixed up. Limitations: - Non-daemon Postfix programs may log to syslogd(8) before they have processed command-line options and main.cf parameters. - If Postfix is down, the non-daemon programs postfix(1), postsuper(1), postmulti(1), and postlog(1), will log directly to $maillog_file. These programs expect to run with root privileges, for example during Postfix start-up, reload, or shutdown. - Other non-daemon Postfix programs will never write directly to $maillog_file (also, logging to stdout would interfere with the operation of some of these programs). These programs can log to postlogd(8) if they are run by the super-user, or if their executable file has set-gid permission. Do not set this permision on programs other than postdrop(1) and postqueue(1). Incompatible changes with snapshot 20190106 =========================================== Postfix 3.4 drops support for OpenSSL 1.0.1 (end-of-life December 31, 2016) and earlier releases. Major changes with snapshot 20190106 ==================================== SNI support in the Postfix SMTP server, the Postfix SMTP client, and in the tlsproxy daemon (both server and client roles). Support for files that combine multiple (key, certificate, trust chain) instances. This was required to implement server-side SNI table lookups, but it also eliminates the need for separate cert/key files for RSA, DSA, Elliptic Curve, and so on. The file format is documented in TLS_README sections [TODO] and in the postconf documentation for parameters [TODO]. Major changes with snapshot 20180826 ==================================== Postfix SMTP server support for RFC 3030 CHUNKING (the BDAT command) without BINARYMIME, in both smtpd(8) and postscreen(8). To disable the SMTP server's CHUNKING support: /etc/postfix/main.cf: # The logging alternative: smtpd_discard_ehlo_keywords = chunking # The non-logging alternative: smtpd_discard_ehlo_keywords = chunking, silent_discard Be sure to specify '-o smtpd_discard_ehlo_keywords=' in master.cf for the submission and smtps services, in case you have clients that benefit from CHUNKING support. Impact on existing configurations: ---------------------------------- - There are no changes for smtpd_mumble_restrictions, smtpd_proxy_filter, smtpd_milters, or for postscreen settings, except for the additional option to suppress the SMTP server's CHUNKING service announcement. - There are no changes in the Postfix queue file content, no changes for down-stream SMTP servers or after-queue content filters, and no changes in the envelope or message content that Milters will receive. Example SMTP session -------------------- The main differences are that the Postfix SMTP server announces "CHUNKING" support in the EHLO response, and that instead of sending one DATA request, the remote SMTP client may send one or more BDAT requests. In the example below, "S:" indicates server responses, and "C:" indicates client requests. S: 220 server.example.com C: EHLO client.example.com S: 250-server.example.com S: 250-PIPELINING S: 250-SIZE 153600000 S: 250-VRFY S: 250-ETRN S: 250-STARTTLS S: 250-AUTH PLAIN LOGIN S: 250-ENHANCEDSTATUSCODES S: 250-8BITMIME S: 250-DSN S: 250-SMTPUTF8 S: 250 CHUNKING C: MAIL FROM: S: 250 2.1.0 Ok C: RCPT TO: S: 250 2.1.5 Ok C: BDAT 10000 C: ..followed by 10000 bytes... S: 250 2.0.0 Ok: 10000 bytes C: BDAT 123 C: ..followed by 123 bytes... S: 250 2.0.0 Ok: 123 bytes C: BDAT 0 LAST S: 250 2.0.0 Ok: 10123 bytes queued as 41yYhh41qmznjbD C: QUIT S: 221 2.0.0 Bye Internally in Postfix, there is no difference between mail that was received with BDAT or with DATA. Postfix smtpd_mumble_restrictions, policy delegation queries, smtpd_proxy_filter and Milters all behave as if Postfix received (MAIL + RCPT + DATA + end-of-data). However, Postfix will log BDAT-related failures as "xxx after BDAT" to avoid complicating troubleshooting (xxx = 'lost connection' or 'timeout'), and will log a warning when a client sends a malformed BDAT command. Benefits of CHUNKING (BDAT) support without BINARYMIME: ------------------------------------------------------- Support for CHUNKING (BDAT) was added to improve interoperability with some clients, a benefit that would reportedly exist even without Postfix support for BINARYMIME. Postfix does not support BINARYMIME at this time because: - BINARYMIME support would require moderately invasive changes to support email content that is not line-oriented. With BINARYMIME, the Content-Length: header specifies the length of arbitrary content that has no line boundaries. Without BINARYMIME, binary content is base64-encoded, and formatted as lines of text. - There is no conversion of BINARYMIME to a line-oriented 8BITMIME form that is compatible with legacy systems including UNIX mbox. The available options are to convert binary content into one of the 7bit forms (base64 or quoted-printable), or to return email as undeliverable. Any conversion would break digital signatures, so it would have to happen before signing. Downsides of CHUNKING (BDAT) support: ------------------------------------- The RFC 3030 authors did not specify any limitations on how clients may pipeline commands (i.e. send commands without waiting for a server response). If a server announces PIPELINING support, like Postfix does, then a remote SMTP client can pipeline all commands following EHLO, for example, MAIL/RCPT/BDAT/BDAT/MAIL/RCPT/BDAT, without ever having to wait for a server response. This means that with BDAT, the Postfix SMTP server cannot distinguish between a well-behaved client and a spambot, based on their command pipelining behavior. If you require "reject_unauth_pipelining" to block spambots, turn off the CHUNKING support announcement as described above. Incompatible change with snapshot 20180701 ========================================== To avoid performance loss under load, the tlsproxy(8) daemon now requires a zero process limit in master.cf (this setting is provided with the default master.cf file). As tlsproxy(8) processes become too busy handling TLS connections, more processes will automatically be added. By default, a tlsproxy(8) process will retire after several hours. To set the tlsproxy process limit to zero: # postconf -F tlsproxy/unix/process_limit=0 # postfix reload Major changes with snapshot 20180617 ==================================== Preliminary Postfix SMTP client support for multiple deliveries per TLS-encrypted connection. This is primarily to improve mail delivery performance for destinations that throttle clients when they don't combine deliveries. This feature is enabled with "smtp_tls_connection_reuse=yes" in main.cf, or with "tls_connection_reuse=yes" in smtp_tls_policy_maps. It supports all Postfix TLS security levels including dane and dane-only. The implementation of TLS connection reuse relies on the same scache(8) service as used for delivering plaintext SMTP mail, the same tlsproxy(8) daemon as used by the postscreen(8) service for inbound connections, and relies on the same hints from the qmgr(8) daemon. It reuses the configuration parameters described in CONNECTION_CACHE_README. The following illustrates how TLS connections are reused: Initial plaintext SMTP handshake: smtp(8) -> remote SMTP server Reused SMTP/TLS connection, or new SMTP/TLS connection: smtp(8) -> tlsproxy(8) -> remote SMTP server Cached SMTP/TLS connection: scache(8) -> tlsproxy(8) -> remote SMTP server There are a few refinements planned: - Log the TLS properties every time a connection is reused. Currently, the properties are logged when a TLS session is created.