This is the Postfix 3.5 (experimental) release.

The stable Postfix release is called postfix-3.4.x where 3=major
release number, 4=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.5-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.3 or earlier, read RELEASE_NOTES-3.4
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 20200202
====================================

Support to force-expire email messages. This introduces new
postsuper(1) command-line options to request expiration, and 
additional information in mailq(1) or postqueue(1) output.

The forced-to-expire status is stored in a queue file attribute.
An expired message is returned to the sender when the queue manager
attempts to deliver that message (note that Postfix will never
deliver messages in the hold queue).

The postsuper(1) -e and -f options both set the forced-to-expire
queue file attribute. The difference is that -f will also release
a message if it is in the hold queue. With -e, such a message would
not be returned to the sender until it is released with -f or -H.

In the mailq(1) or postqueue(1) -p output, a forced-to-expire message
is indicated with # after the queue name. In postqueue(1) JSON
output, there is a new per-message field "forced_expire" (with 
value true or false) that shows the forced-to-expire status.

Incompatible changes with snapshot 20191109
===========================================

Postfix daemon processes now log the from= and to= addresses in
external (quoted) form in non-debug logging (info, warning, etc.).
This means that when an address localpart contains spaces or other
special characters, the localpart will be quoted, for example:

    from=<"name with spaces"@example.com>

Older Postfix versions would log the internal (unquoted) form: 

    from=<name with spaces@example.com>

The external and internal forms are identical for the vast majority
of email addresses that contain no spaces or other special characters
in the localpart.

Specify "info_log_address_format = internal" for backwards
compatibility.

The logging in external form is consistent with the address form
that Postfix 3.2 and later prefer for table lookups. It is therefore
the more useful form for non-debug logging.

Major changes with snapshot 20190615
====================================

This release introduces a workaround for implementations that hang
Postfix while shutting down a TLS session, until Postfix times out.
With "tls_fast_shutdown_enable = yes" (the default), Postfix no
longer waits for a remote TLS peer to respond to a TLS 'close'
request. This behavior is recommended with TLSv1.0 and later. Specify
"tls_fast_shutdown_enable = no" to get historical Postfix behavior.

Dovecot usability: the SMTP+LMTP delivery agent can now prepend
Delivered-To, X-Original-To and Return-Path headers, just like the
pipe(8) delivery agent. This uses the same "flags=DOR" command-line
flags in master.cf. See the smtp(8) manpage for details.

This obsoletes the "lmtp_assume_final = yes" setting, and replaces
it with "flags=...X...", for consistency with pipe(8).

Major changes with snapshot 20190517
====================================

Search order support for check_ccert_access. Search order support
for other tables is in design (canonical_maps, virtual_alias_maps,
transport_maps, etc.).

The following check_ccert_access setting uses the built-in search
order: it first looks up the client certificate fingerprint, then
the client certificate public-key fingerprint, and it stops when a
decision is made.

/etc/postfix/main.cf:
    smtpd_mumble_restrictions =
        ...
        check_ccert_access hash:/etc/postfix/ccert-access
        ...

The following setting, with explicit search order, produces the
exact same result:

/etc/postfix/main.cf:
    smtpd_mumble_restrictions =
        ...
        check_ccert_access {
            hash:/etc/postfix/ccert-access {
                search_order = cert_fingerprint, pubkey_fingerprint } }
        ...

The check_ccert_access search order also supports the subject_cn and
issuer_cn properties. Support is planned for rfc822name and
smtputf8mailbox.

Incompatibility with snapshot 20190427
======================================

Postfix now normalizes IP addresses received with XCLIENT, XFORWARD,
or with the HaProxy protocol, for consistency with direct connections
to Postfix. This may change the appearance of logging, and the way
that check_client_access will match subnets of an IPv6 address.
