-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Format: 1.8 Date: Mon, 10 Aug 2026 19:35:04 +0300 Source: postfix Binary: postfix-doc Architecture: all Version: 3.10.13-0+deb13u1 Distribution: trixie-security Urgency: medium Maintainer: all / amd64 / i386 Build Daemon (x86-grnet-03) Changed-By: Michael Tokarev Description: postfix-doc - Documentation for Postfix Changes: postfix (3.10.13-0+deb13u1) trixie-security; urgency=medium . * new upstream stable/bugfix/security release From the release announcement by Wietse Wenema at https://www.postfix.org/announcements/postfix-3.11.6.html : . These defects were found by Qualys assisted by Claude Mythos Preview, and by OpenAI Security; more than half date from 20 or more years ago. When I implemented Postfix, I knew that there were going to be mistakes. That is the reason why Postfix has its architecture and safety nets. The number of defects may seem large, but considering that they were found in a code base of over 150 thousand lines, the error rate is still lower than what I designed for. . o Policy bypass: . - Bug (introduced: Postfix 2.2, date: 20041102): missing SMTP server resets of MAIL FROM and RCPT TO command state after smtpd_end_of_data_restrictions rejected a message. This resulted in SMTP protocol state desynchronization between the remote SMTP client and the Postfix SMTP server. . - A crafted remote SMTP client could then send RCPT TO and DATA without MAIL FROM, and deliver a second message. Then, smtpd_end_of_data_restrictions skipped check_recipient_access constraints, because a recipient counter was > 1. . - The failure to reset MAIL FROM and RCPT TO state also affected Milter support (added in Postfix 2.3). Here, after a Milter replied with "accept this message" based on the message envelope, and smtpd_end_of_data_restrictions rejected the message, the Postfix SMTP server as before accepted RCPT TO and DATA without MAIL FROM, and smtpd_end_of_data_restrictions as before skipped check_recipient_access constraints for the second message. Under these conditions, the Postfix Milter client remained in the "accept this message" state, skipping Milter policy enforcement for the second message. . o Denial of service: . - Bug (defect introduced: Postfix 3.4, date: 20180805): SMTP server command history memory exhaustion with a large number of very small BDAT requests. . - Bug (defect introduced: Postfix 1.1, date: 20021116): address verification cache poisoning. A local user could use the postdrop command to submit an address verification probe with envelope or message content that Postfix rejected later, resulting in a negative address verification cache entry for that address. On systems that enable address verification, the negative address verification cache entry would force the Postfix SMTP server to reject a message that it should accept (denial of service). . o Server crashes and panic()s: . - Bug (defect introduced: Postfix 3.4, date: 20180805): missing SMTP server reset of RCPT TO state, after a BDAT command error. A crafted remote SMTP client could then send a DATA command without MAIL FROM or RCPT TO, and crash a Postfix SMTP daemon process with a null pointer read error. . - Bug (defect introduced: Postfix 2.4, date: 20051222): null pointer read crash while parsing a malformed Dovecot AUTH server response. . o Read after free, uninitialized read, under/over read: . - Bug (defect introduced: Postfix 2.8, date: 20100914): read-after-free in the PSC_CALL_BACK_NOTIFY() macro. This had no effect on program execution, because myfree() wiped memory, and that memory was not yet reused. . - Read after free (no privilege escalation) in debug logging (defect introduced: Postfix 2.2, date: 20050117). . - Bug (defect introduced: Postfix 2.10, date: 20120617): uninitialized memory read in postscreen HaProxy client after remote I/O exception, causing garbage to be logged. . - Latent bug (defect introduced: Postfix 2.7, date: 20090618): uninitialized memory read after dnsblog(8) returns a string that is not an IPv4 address. . - Bug (defect introduced: before Postfix alpha, date 19970424): the DNS client could read up to two bytes past the end of an MX record, before discovering that the record was too short. This behavior was later copied with SRV records, potentially over-reading up to six bytes. . - Bug (defect introduced: Postfix 1,1, date: 20010524): the postsuper command under-read or over-read a very short queue filename. No crash, information leak, or privilege escalation. . o Other code hygiene: . - Bug (defect introduced: before Postfix alpha, date: 19971106): 'int' over-shift, in the queue file record-length parser. Postfix programs do not generate such records, but an attacker could cause postdrop to reject input or panic(). . - Bug (defect introduced: Postfix 2.2, date: 20050117): non-transitive comparison of IPv4 addresses. . - Bug (defect introduced: Postfix 1.0, date: 20000928): the fast flush server, used by the SMTP command "ETRN", and by the commands "postqueue -s site" and "postqueue -i queue_id" (and their sendmail(1) equivalents), used the wrong duplicate suppression API, resulting in unnecessary queue scans by the queue manager. . - Queue hygiene: the postdrop command accepted the null record type which the rest of Postfix ignores. Checksums-Sha1: 7cb9f39ccf12204963c15aee93f9d89d3d50bf77 1408616 postfix-doc_3.10.13-0+deb13u1_all.deb ec66a93aa2fe659c73b025fb9b6d2601923ca62c 7650 postfix_3.10.13-0+deb13u1_all-buildd.buildinfo Checksums-Sha256: 7249e06fd1601c5b2dfc76470ee38271445656099d1c87072dd27fb1405cf350 1408616 postfix-doc_3.10.13-0+deb13u1_all.deb 77fdc280e9ce7b78a123f340387224ffe76c64d160d4db4e9e002158701ff2c5 7650 postfix_3.10.13-0+deb13u1_all-buildd.buildinfo Files: 4b54bca10c30cad5b54138a99a7ead59 1408616 doc optional postfix-doc_3.10.13-0+deb13u1_all.deb dd0cbc211e32fdcb2eec69c7df0de34e 7650 mail optional postfix_3.10.13-0+deb13u1_all-buildd.buildinfo -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE5ZI1lXv5WjhHIVjsN8Ugyu9dQiQFAmp6BYMACgkQN8Ugyu9d QiTBrRAAsY35S5RnAdUbonSpbW9GPDgsOUjsI4ZU3uDChZz9ZjqWZXS3oo16fpDJ Uv1bccnOPNUjxSR+H4CxHEG1Pgm3EvInsjp5WOnnSRx7xVF0IiZPxSCgf3JDSj2h 59GvFtv0a/uB45zFvZVMSXJZpE/7vOAaHMtDEi/qKbExvLwb8AuoaFP9EfAdD7xd Oxc9J86dN0vS5yMztzPUdLhdPq5a7TBVChcCasAoY6ycKNpARNKUmEFm0v/R10EJ xExv4cGzuYD8OxXtSgcCsf8kyl8siwDc55WcmrPhXLYOBv2TLXFLcJTJOeU3jo0H QvvT3v61OOKmjE8OsSXHHpdxut2Y6O/aYfbRKC+IKJRw4At9eRVBLZ50qED84Anb ha2Qs7Eo9b+AsC51Ss5H4gL2PGn6IybnuCuSrBVgkjvTKCvva/oN6udIcvI+0D9u ZW+1xiL2OuDMHWT/eAVds24sRQhMrEmae+lxUgf6UxiUln9tZSDFpm6UY0+QzBKu UudUcWWqSXtAD7gjGA2ZwfjTOxYl+z7RRKI+AwqE/SksZgfpPbHjDwGhEYYDkdYl ixyGLzhA6mvMUHr7DlAvAWbEAWAMtgF1VhzBphdLjpVhUekrhop1U/wC8cVQ5ltg sWEXGGYuNB5GYtFeYsCZ26RgZkXxr4EzZz5OY17lQaQ1BgVZ948= =EPAm -----END PGP SIGNATURE-----