Back to postfix PTS page

Accepted postfix 3.4.14-0+deb10u1 (source) into proposed-updates->stable-new, proposed-updates



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Format: 1.8
Date: Mon, 29 Jun 2020 21:33:31 -0400
Source: postfix
Architecture: source
Version: 3.4.14-0+deb10u1
Distribution: buster
Urgency: medium
Maintainer: LaMont Jones <lamont@debian.org>
Changed-By: Scott Kitterman <scott@kitterman.com>
Changes:
 postfix (3.4.14-0+deb10u1) buster; urgency=medium
 .
   [Cody Brownstein]
 .
   * README.Debian corrections:
     - Fix instructions wrt SMTP generic mapping
     - Fix authentication configuration example
 .
   [Scott Kitterman]
 .
   * Updated debian/watch to track postfix 3.4 series for stable updates
   * Check GPG signature when downloading new versions via uscan
 .
   [Wietse Venema]
 .
   * 3.4.11
     - No changes that affect Debian 10 (Buster)
 .
   * 3.4.12
     - Bugfix: segfault in the tlsproxy client role when the server
       role was disabled. This typically happens on systems that
       do not receive mail, after configuring connection reuse for
       outbound TLS. Found during program maintenance. File:
       tlsproxy/tlsproxy.c.
 .
     - Bugfix (introduced: Postfix 3.4): maillog_file_rotate_suffix
       default value used the minute instead of the month. Reported
       by Larry Stone. Files: conf/postfix-tls-script,
       proto/MAILLOG_README.html, proto/postconf.proto.
       global/mail_params.h, postfix/postfix.c.
 .
     - Bitrot: avoid U_FILE_ACCESS_ERROR after chroot(), by
       initializing the ICU library before making the chroot()
       call. Files: util/midna_domain.[hc], global/mail_params.c.
 .
     - Noise suppression: avoid "SSL_Shutdown:shutdown while in
       init" warnings. File: tls/tls_session.c.
 .
     - Bugfix (introduced: Postfix 2.2): a TLS error for a PostgreSQL
       client caused a false 'lost connection' error for an SMTP
       over TLS session in the same Postfix process. Reported by
       Alexander Vasarab, diagnosed by Viktor Dukhovni. File:
       tls/tls_bio_ops.c.
 .
     - Bugfix (introduced: Postfix 2.8): a TLS error for one TLS
       session may cause a false 'lost connection' error for a
       concurrent TLS session in the same tlsproxy process. File:
       tlsproxy/tlsproxy.c.
 .
   * 3.4.13
     - Bugfix (introduced: Postfix 3.1): "postfix tls deploy-server-cert"
       did not handle a missing optional argument. File:
       conf/postfix-tls-script.
 .
     - Bugfix (introduced: Postfix 3.4): in the Postfix SMTP server,
       the SNI callback reported an error when it was called a
       second time. This happened after the server-side TLS engine
       sent a TLSv1.3 HelloRetryRequest (HRR) to a remote SMTP
       client. Reported by Ján Máté, fixed by Viktor Dukhovni.
       File: tls/tls_misc.c.
 .
   * 3.4.14
     - Bugfix (introduced: Postfix 3.4): the connection_reuse
       attribute in smtp_tls_policy_maps resulted in an "invalid
       attribute name" error. Fix by Thorsten Habich. File:
       smtp/smtp_tls_policy.c.
 .
     - Bugfix (introduced: Postfix 3.4): SMTP over TLS connection
       reuse was broken for configurations that use explicit trust
       anchors. Reported by Thorsten Habich. Cause: the tlsproxy
       client was sending a zero certificate length. File:
       tls/tls_proxy_client_print.c.
 .
     - Bugfix (introduced: Postfix 3.4): SMTP over TLS connection
       reuse was broken for configurations that use explicit trust
       anchors. Reported by Thorsten Habich. Fixed by calling DANE
       initialization unconditionally (WTF). File: tlsproxy/tlsproxy.c.
 .
     - Bugfix (introduced: Postfix 2.11): The Postfix smtp(8)
       client did not send the right SNI name when the TLSA base
       domain was a secure CNAME expansion of the MX hostname (or
       non-MX nexthop domain). Domains with CNAME expanded MX hosts
       are not conformant with RFC5321, and so are rare. Even more
       rare are MX hosts with TLSA records for their CNAME expansion.
       For this to matter, the remote SMTP server would also have
       to select its certificate based on the SNI name in such a
       way that the original MX host would yield a different
       certificate. Among the ~2 million hosts in the DANE survey,
       none meet the conditions for returning a different certificate
       for the expanded CNAME. Therefore, sending the correct SNI
       name should not break existing mail flows. Fixed by Viktor
       Dukhovni. File: src/tls/tls_client.c.
Checksums-Sha1:
 34d6f59b33a77259b46e56cd66096f013847ecd3 3024 postfix_3.4.14-0+deb10u1.dsc
 4b450b39ca5f68e0b65076a3eed5e9cbcf2ead3a 4576001 postfix_3.4.14.orig.tar.gz
 087f26d0ec41f0a286392969ee6695682176c561 220 postfix_3.4.14.orig.tar.gz.asc
 db12fc1f45b521da76ecf937d150194bcaab431b 206260 postfix_3.4.14-0+deb10u1.debian.tar.xz
 5eb44be6334dfbf6cb2eeeddfc116862791175f9 5797 postfix_3.4.14-0+deb10u1_source.buildinfo
Checksums-Sha256:
 3b22bbe0b14bcd2b7c18d71ee85ee56938cefd39b076575ade4bfc13a86e6be2 3024 postfix_3.4.14-0+deb10u1.dsc
 03483f95d2ba7fc264014f117d22644376878223334a6afd47b7c02485da00e8 4576001 postfix_3.4.14.orig.tar.gz
 a52388e908e43649065789a9cc16f7f24566e93cc907669b6e4e877ede57e45c 220 postfix_3.4.14.orig.tar.gz.asc
 0afa70c5ca3ff5e52d7e7e7ab836e8e0e666b7a6870043e6baf03a9d4b07840f 206260 postfix_3.4.14-0+deb10u1.debian.tar.xz
 ac3e44e9688af5e18440a14abddf4a0c16246a50531327217fbad8dae0a005b4 5797 postfix_3.4.14-0+deb10u1_source.buildinfo
Files:
 981b31a586e438cebb2793bb2035997d 3024 mail optional postfix_3.4.14-0+deb10u1.dsc
 8dd2a593f68363792c056e7bb9dca659 4576001 mail optional postfix_3.4.14.orig.tar.gz
 0516877bcdbf8ec4f958fdae4ffb708e 220 mail optional postfix_3.4.14.orig.tar.gz.asc
 c1c24806218b0f05fb971edfd4e2dcee 206260 mail optional postfix_3.4.14-0+deb10u1.debian.tar.xz
 913dafb6108272540b61f3e657d73de0 5797 mail optional postfix_3.4.14-0+deb10u1_source.buildinfo

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE53Kb/76FQA/u7iOxeNfe+5rVmvEFAl76locACgkQeNfe+5rV
mvFXrBAAs16QoWssibb+KceFJtuWO0FodwU5rvPBQMZy6L5fh7pfZwtalqGUQWJF
z7PZ0YaoEehzqDCfb0geOh9Vn5vBawcIj3vVQkxtGsCHAx3qU9eXSjXHPuLu02Wr
vO5o+W4mpyiksG2IsVTROKdxe/+DRmtk3/SzrOCtw0u8BagUD5rPmmQFWhVOgDr5
13p2Rjq1IuSsmRqjtdDR7CJ6H6ufCP9+juPkXlrabKd2mEKgOb1LEk6lGIzg3YCd
z8hUP7xk5qAc5+uTmxWc2Ley4sGdOuxePLLmXBe6TQzfIorv+/DHlwf+rqJrkTYk
6LgwOd7o6isdl0LJoAe7Ss3+lc4XY2T6SJjl5n0hK+N+iDKFeQsCinfDIgrxxiki
0wQemHL2S6fH5AN4H4D2hIKQCKP7i+Gio+gODY6EFQsa6+OohD+pt8GAf/6z4qsD
AvB95Jr+7jKPB0r4qn8nIWwmprDgZ90k0s48hpkyu17XfeNbLqGEdi40ERyX72yy
QC1UV+ryMZWHlIUk9BkMxnxS6OJPjUBHTy6wys+ag619TVKcM3VDhq+kCxiUzU5a
96P1RKGuUX4Kdi8bpBs/QhQeMPYOV7F4IyKU1dzhHbpnwYPY6uOBuHQMn96WvieT
hBo+P//N3iLjFOmFyhGbB2hN7JoDj44GzGrAoUJYKeD2WZeyViw=
=zcBe
-----END PGP SIGNATURE-----