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.

Major changes with snapshot 20190121-nonprod
============================================

Support for logging to file without using syslog. This solves a
usability problem for MacOS users, may be useful when systemd is
getting in the way, and provides 99% of the solution for logging
to stdout from a container. Hopefully we will have 100% soon.

To enable logging to file without using syslog:
-----------------------------------------------

Configure the postlogd(8) daemon in master.cf:
    # postfix upgrade-configuration

Configure the logfile pathname in main.cf:
    # postconf maillog_file=/var/log/postfix.log

Reload Postfix (master will log to syslog and Postfix logfile):
running an older version of the master daemon):
    # postfix reload

Use "postfix stop" and "postfix start" for a fresh master daemon
that logs to Postfix logfile only.


To rotate the logfile with a daily cronjob:
-------------------------------------------

- Rename the current logfile in the same directory, appending the
  current date to file file name:
   # mv postfix.log postfix.log.$(date +%Y%M%d)

- DO NOT YET COMPRESS THE FILE. POSTFIX STILL WRITES TO IT.

- Reload Postfix, so that it will start writing to a new file:
   # postfix reload

- Compress the old file, and move it elsewhere if needed.

Limitations of Postfix internal logging:
----------------------------------------

- Non-daemon Postfix programs don't know that they should log to
  the internal logging service until after they have processed
  command-line options and main.cf parameters. These programs still
  log earlier events to the syslog service.

- If Postfix is down, then logging from non-daemon programs will
  be lost, except for logging from the postfix(1) and postlog(1)
  commands. These can log directly to file when running as root, for
  example during Postfix start-up.

- Non-daemon Postfix programs can talk to postlogd(8) only if they
  are run by the super-user, or if their executable files have set-gid
  permission.

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:<sender@example.com>
    S: 250 2.1.0 Ok
    C: RCPT TO:<recipient@example.com>
    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.
