[An on-line version of this announcement will be available at http://www.postfix.org/announcements/postfix-3.6.3.html]
Fixed in Postfix 3.6.3, 3.5.13, 3.4.23, 3.3.20:
(problem introduced in Postfix 2.4, released in 2007):
queue file corruption after a Milter (for example, MIMEDefang) made
a request to replace the message body with a copy of that message
body plus additional text (for example, a SpamAssassin report).
The most likely impacts were a) the queue manager reporting a fatal
error resulting in email delivery delays, or b) the queue manager
reporting the corruption and moving the message to the corrupt queue
for damaged messages.
However, a determined adversary could craft an email message that
would trigger the bug, and insert into its queue file a content
filter destination or a redirect email address. Postfix would then
deliver the message headers there, in most cases without delivering
the message body. With enough experimentation, an attacker could
make Postfix deliver both the message headers and body.
Some details of a successful attack depend on the Milter implementation,
and on the Postfix and Milter configuration details; these can be
determined remotely through experimentation. Failed experiments may
be detected when the queue manager terminates with a fatal error,
or when the queue manager moves damaged files to the "corrupt" queue
as evidence.
Technical details: when Postfix executes a "replace body" Milter
request it will reuse queue file storage that was used by the
existing email message body. If the new body is larger, Postfix
will append body content to the end of the queue file. The corruption
happened when a Milter (for example, MIMEDefang) made a request to
replace the body of a message with a new body that contained a copy
of the original body plus some new text, and the original body
contained a line longer than $line_length_limit bytes (for example,
an image encoded in base64 without hard or soft line breaks).
In queue files, Postfix stores a long text line as multiple records
with up to $line_length_limit bytes each. Unfortunately, Postfix's
"replace body" support did not account for the additional queue
file space needed to store the second etc. record headers. And
thus, the last record(s) of a long text line could overwrite one
or more queue file records immediately after the space that was
previously occupied by the original message body.
Problem report by Benoit Panizzon.
(problem introduced in Postfix 2.10, released in 2012): The postconf "-x" option could produce incorrect output, because multiple functions were implicitly sharing a buffer for intermediate results. Problem report by raf, root cause analysis by Viktor Dukhovni.
(problem introduced in Postfix 2.11, released in 2013): The check_ccert_access feature worked as expected, but produced a spurious warning when Postfix was built without SASL support. Fix by Brad Barden.
Fix for a compiler warning due to a missing 'const' qualifier when compiling Postfix with OpenSSL 3. Depending on compiler settings this could cause the build to fail.
Fixed in Postfix 3.6:
The known_tcp_ports settings had no effect. It also wasn't fully implemented. Problem report by Peter.
Fix for missing space between a hostname and warning text.
You can find the updated Postfix source code at the mirrors listed at http://www.postfix.org/.