Bug#923548: unblock: postfix/3.4.0-2
Package: release.debian.org
Severity: normal
User: release.debian.org@packages.debian.org
Usertags: unblock
Please unblock package postfix
I realize 'unblock' is slightly jumping the gun, but I would like to solicit
feedback/agreement from the release team before doing something non-minimal
right before freeze.
Upstream postfix has just release 3.4.0. I would like to include it in
Buster. I know it's late, but I think it's worth doing anyway. Here are the
new features relevant to Debian (from the RELEASE_NOTES):
=============
Major changes - bdat support
--------------------
[Feature 20180826] Postfix SMTP server support for RFC 3030 CHUNKING
(the BDAT command) without BINARYMIME, in both smtpd(8) and
postscreen(8). This has no effect on Milters, smtpd_mumble_restrictions,
and smtpd_proxy_filter. See BDAT_README for more.
Major changes - containers
--------------------------
N/A for Debian package.
Major changes - database support
--------------------------------
[Feature 20181105] Support for (key, list of filenames) in map
source text.
- Currently, this feature is used only by tls_server_sni_maps.
- When a map is created from source with "postmap -F maptype:mapname",
the command processes each key as usual and processes each value
as a list of filenames, concatenates the content of those files
(with one newline character in-between files), and stores an entry
with (key, base64-encoded result).
- When a map is queried with "postmap -F -q ...", the command
base64-decodes each value. It reports an error when a value is
not in base64 form.
This "postmap -F -q ..." behavior also works when querying the
memory-resident map types cidr:, inline:, pcre:, randmap:, regexp:,
and static:. Postfix reads the files specified as table values,
stores base64-encoded content, and base64-decodes content upon
table lookup.
Internally, Postfix will turn on this behavior for lookups (not
updates) when a map is opened with the DICT_FLAG_RHS_IS_FILE flag.
Major changes - logging
-----------------------
[Feature 20190126] Support for logging to file or stdout, instead
of using syslog.
N/A for Debian package.
Major changes - safety
----------------------
[Feature 20180623] Automatic retirement: dnsblog(8) and tlsproxy(8) process
will now voluntarily retire after after max_idle*max_use, or some
sane limit if either limit is disabled. Without this, a process
could stay busy for days or more.
Major changes - tls connection pooling
--------------------------------------
[Feature 20180617] 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 Postfix SMTP client now logs whether an SMTP-over-TLS connection
is newly established ("TLS connection established") or whether the
connection is reused ("TLS connection reused").
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
Major changes - tls support
---------------------------
[Feature 20190106] SNI support in the Postfix SMTP server, the
Postfix SMTP client, and in the tlsproxy(8) daemon (both server and
client roles). See the postconf(5) documentation for the new
tls_server_sni_maps and smtp_tls_servername parameters.
[Feature 20190106] Support for files that contain 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 the TLS_README sections "Server-side
certificate and private key configuration" and "Client-side certificate
and private key configuration", and in the postconf(5) documentation
for the parameters smtp_tls_chain_files, smtpd_tls_chain_files,
tlsproxy_client_chain_files, and tlsproxy_tls_chain_files.
Note: the command "postfix tls" does not yet support the new
consolidated certificate chain format. If you switch to the new
format, you'll need to manage your keys and certificates directly,
rather than via postfix-tls(1).
Major changes - usability
-------------------------
[Feature 20180812] Support for smtpd_reject_footer_maps (as well
as the postscreen variant postscreen_reject_footer_maps) for more
informative reject messages. This is indexed with the Postfix SMTP
server response text, and overrides the footer specified with
smtpd_reject_footer. One will want to use a pcre: or regexp: map
with this.
===================
The TLS related changes align postfix much better with the openssl version we
are shipping in Buster and are generally good for security/privacy.
I've packaged postfix-3.4.0 and uploaded it to experimental. I haven't run
into any issues with testing yet and it has built on all archs it's been tried
on (all release archs except mips*el are built).
No significant packaging changes were required to adapt the Debian packaging
to postifix-3.4.0. I dropped one obsolete patch that would have had to be
rewritten (and I should have dropped it years ago).
Given the outstanding track record this upstream has for delivering mature,
well tested code I believe this change is appropriate for this stage of the
release cycle given the benefits it will provide, but it is definitely not
minor, so I'd like release team feedback before uploading to unstable.
If the time comes where this needs an actual unblock, I'll upload the full
diff per the normal unblock requirements.
Scott K
Reply to: