----- Forwarded message from Wietse Venema via Postfix-announce <postfix-announce () postfix org> -----

To: Postfix announce <postfix-announce () postfix org> Date: Tue, 8 Sep 2026 07:56:36 -0400 (EDT) CC: Postfix users <postfix-users () postfix org> Subject: [pfx-ann] Postfix stable release 3.11.7 and legacy releases 3.10.14, 3.9.15, From: Wietse Venema via Postfix-announce <postfix-announce () postfix org> Reply-To: Wietse Venema <wietse () porcupine org>

[An on-line version of this announcement will be available at https://www.postfix.org/announcements/postfix-3.11.7.html]

This release addresses medium-impact problems that need to be fixed as some enable remote DOS or SMTP smugggling.

The fixes below, and more, are also released in the unstable version postfix-3.12-20260902.

In addition to updated releases for the supported Postfix versions 3.8-3.11, releases will also be available for the out-of-support Postfix versions 3.5-3.7. NOTE: these do not include the patches for out-of-support Postfix versions that have been issued for "large SMTP inputs (June 2026)", and for "TLSA parsing (June 2026)". Those patches still need to be applied.

These defects were found by "Qualys assisted by Claude Mythos Preview", and by "OpenAI Security"; three date from 20 or more years ago.

SMTP smuggling:

Bug (introduced: Postfix 3.9, date: 20240106) SMTP smuggling was still possible with smtpdproxyfilter (disabled by default) when the after-filter SMTP server used the default policy settings "smtpdforbidbarenewlineexclusions = $mynetworks" and "smtpdforbidbarenewline = normalize". Reported by OpenAI Security. Fix by Wietse.

As suggested by OpenAI Security, eliminate stray CR characters from the smtpdproxyfilter input stream. The before-proxy-filter SMTP server already eliminated stray LF.

Bug (introduced: Postfix 3.11, date: 20250917): SMTP smuggling was possible with smtpdproxyfilter (disabled by default) when the before-filter SMTP server added a "Require-TLS-ESMTP: yes" message header, due to implementation edge cases. Adding this header is enabled with the "requiretlsesmtpheader = yes" default setting. Reported by OpenAI Security. Fix by Wietse.

Server crashes and panic()s:

Bug (defect introduced: Postfix 3.0, date: 20140707): null pointer read error after receiving MAIL FROM, RCPT TO, and VRFY with an UTF8 address but no SMTPUTF8 parameter. This requires "smtputf8enable = yes" (the default) and "strictsmtputf8 = yes" (not default). With this, the SMTP server did an unnecessary MAIL FROM reset without RCPT TO reset. A crafted remote SMTP client could then send a DATA command and crash a Postfix SMTP server process with a null pointer read error. Reported by Wonyoung Jung (78ResearchLab AI).

Other bugs

Bug (defect introduced: Postfix 3.4, date: 20180303): the MySQL client setting "tlsverifycert = yes" had no effect with Oracle MySQL 8 and later. Report and fix by OpenAI Security.

Bug (defect introduced: Postfix-beta, date: 19990119): the pipe(8) delivery agent deleted a command-line argument if the argument contained $user AND $user expanded to an empty string, breaking the positional order of arguments. This was a workaround for a problem that hopefully no longer exists. Reported by Qualys, assisted by Claude Mythos Preview.

Bug (defect introduced: Postfix 2.3, date: 20050323): the SMTP client enhanced status code parser could process stale data when a remote SMTP server sent a three-digit reply without other text. Reported by Qualys, assisted by Claude Mythos Preview.

TLS

Isolation: stamp Postfix SMTP server TLS session tickets with their master.cf service name. With this, an SMTP server defined in master.cf will no longer accept tickets issued by a different SMTP server defined in the same master.cf file. Fix by OpenAI security.

Configuration safety

The postmap and postalias commands now log a warning when creating a root-owned database file in a directory that is not owned by root. They log that the database source file, indexed file(s), and parent directory should have the same owner, to prevent a privilege-escalation attack. Problem reported by OpenAI Security, remediation strategy (don't break production deployment) by Wietse.

Read after free, memory over-read

Bug (introduced: Postfix 2.3, date: 20060629): a malicious Milter or attacker-in-the-middle could trigger a null-terminated heap memory overread in the SMTP daemon while formatting a malformed multiline response. Fix from OpenAI Security adopted with minor changes.

Bug (defect introduced: Postfix 3.0, date: 20141117): in the postqueue command don't free() text before logging a fatal error message. Reported by Qualys, assisted by Claude Mythos Preview.

Code hygiene: in the SMTP client protocol engine, evaluate a RETURN() macro argument before freeing resources. Reported by Qualys, assisted by Claude Mythos Preview.

Code hardening (defense in depth, prevention)

(Postfix 3.11) Hardening: in the non-BerkeleyDB migration service, delay the decision between running postmap or postalias until after the database file/directory owner/permission checks. The benefit from making the decision early (better error messages) was not worth the risk. Qualys, assisted by Claude Mythos Preview.

(Postfix-3.11) Hardened the database parent directory permission checks for automatic re-indexing with the non-Berkeley-DB migration service.

Hardening command-line email submission: the postdrop command now disallows null and line-break characters in queue file envelope records (line-break characters in non-envelope queue file records are already neutralized by default with "cleanupreplacestraycrlf = yes").

The new constraint not only eliminates line-break injection into local mailbox files as reported by OpenAI Security, but also prevents other forms of misuse. Later, this constraint may be moved into the Postfix core. Fix by Wietse.

Shut up nagging from multiple AIs and harden the virtual delivery agent against an evil (LDAP or SQL) database.

Code hygiene: myrealloc(ptr, 0) still resulted in a panic. Reported by Qualys, assisted by Claude Mythos Preview. Also adopt a mystrndup() fix from Postfix 3.12.

Other:

Portability: OpenBSD does not define NSINT16SZ. Brad Smith.

You can find the updated Postfix source code on the mirrors listed at https://www.postfix.org/.

Wietse Postfix-announce mailing list -- postfix-announce () postfix org To unsubscribe send an email to postfix-announce-leave () postfix org

----- End forwarded message -----

When mailmaxuseripconnections is set (default 10) and reached, submission-login can crash with epoll() panic caused by file descriptor handling issues. If running in high-security mode (default for community releases), only the new submission connection gets terminated. If running in high-performance mode (default for Pro releases), all connections handled by the submission-login process will be terminated. The crashes can cause failure for user to send a message, or it can cause duplicate messages to be sent. If TLS is not used (in the backend server processing the submission), duplicate deliveries cannot happen, because the crash can only happen at AUTH stage. Limit the number of connections handled by single submission-login process. This has a performance impact though. Update to non-vulnerable version. No publicly available exploits are known.

The first round Wietse fixed was a few months ago in https://www.openwall.com/lists/oss-security/2026/05/04/25.

See his summary below for details, but they're all at most DoS.

-------------------- Start of forwarded message -------------------- To: Postfix announce <postfix-announce () postfix org> Date: Mon, 10 Aug 2026 11:50:35 -0400 (EDT) CC: Postfix users <postfix-users () postfix org> Subject: [pfx] Postfix stable release 3.11.6 and legacy releases 3.10.13, 3.9.14, 3.8.20, 3.7.22, 3.6.20, 3.5.27 From: Wietse Venema via Postfix-users <postfix-users () postfix org>

[An on-line version of this announcement will be available at https://www.postfix.org/announcements/postfix-3.11.6.html]

This release addresses medium-impact problems that need to be fixed as some enable remote DOS or policy bypass.

The fixes below, and more, are also released in the unstable version postfix-3.12-20260809.

In addition to updated releases for the supported Postfix versions 3.8-3.11, releases will also be available for the out-of-support Postfix versions 3.5-3.7. NOTE: these do not include the patches for out-of-support Postfix versions that have been issued for "large SMTP inputs (June 2026)", "TLSA parsing (June 2026)", and "SMTP smuggling fixes". Those patches still need to be applied.

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.

Policy bypass:

Bug (introduced: Postfix 2.2, date: 20041102): missing SMTP server resets of MAIL FROM and RCPT TO command state after smtpdendofdatarestrictions 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, smtpdendofdatarestrictions skipped checkrecipientaccess constraints, because a recipient counter was > 1. Reported by OpenAI Security. File: smtpd/smtpd.c.

As reported by OpenAI Security, 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 smtpdendofdatarestrictions rejected the message, the Postfix SMTP server as before accepted RCPT TO and DATA without MAIL FROM, and smtpdendofdatarestrictions as before skipped checkrecipientaccess 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.

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. Reported by OpenAI security. File: smtpd.c.

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). Problem reported by OpenAI Security. File: postdrop.c.

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. Reported by OpenAI Security. File: smtpd/smtpd.c.

Bug (defect introduced: Postfix 2.4, date: 20051222): null pointer read crash while parsing a malformed Dovecot AUTH server response. Reported by Qualys, assisted by Claude Mythos Preview. File: xsasldovecotserver.c.

Read after free, uninitialized read, under/over read:

Bug (defect introduced: Postfix 2.8, date: 20100914): read-after-free in the PSCCALLBACKNOTIFY() macro. This had no effect on program execution, because myfree() wiped memory, and that memory was not yet reused. Problem reported by Qualys, assisted by Claude Mythos Preview. File: postscreendnsbl.c.

Read after free (no privilege escalation) in debug logging (defect introduced: Postfix 2.2, date: 20050117). Reported by Qualys, assisted by Claude Mythos Preview. File: util/inetconnect.c.

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. Reported by Qualys, assisted by Claude Mythos Preview. File: postscreenhaproxy.c.

Latent bug (defect introduced: Postfix 2.7, date: 20090618): uninitialized memory read after dnsblog(8) returns a string that is not an IPv4 address. Reported by Qualys, assisted by Claude Mythos Preview. File: postscreendnsbl.c.

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. Problem reported by Qualys, assisted by Claude Mythos Preview. File: dnslookup.c.

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. Reported by Qualys, assisted by Claude Mythos Preview. Files: postsuper.c, mailqueue.h.

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(). Reported by Qualys, assisted by Claude Mythos Preview. File: record.c.

Bug (defect introduced: Postfix 2.2, date: 20050117): non-transitive comparison of IPv4 addresses. Reported by Qualys, assisted by Claude Mythos Preview. File: sockaddr.c.

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 queueid" (and their sendmail(1) equivalents), used the wrong duplicate suppression API, resulting in unnecessary queue scans by the queue manager. Reported by Qualys, assisted by Claude Mythos Preview. File: flush.c.

Queue hygiene: the postdrop command accepted the null record type which the rest of Postfix ignores. Reported by OpenAI Security. File: postdrop.c.

You can find the updated Postfix source code at the mirrors listed at https://www.postfix.org/.

Wietse Postfix-users mailing list -- postfix-users () postfix org To unsubscribe send an email to postfix-users-leave () postfix org -------------------- End of forwarded message --------------------

On Mon, May 04, 2026 at 05:38:55PM +0100, Sam James wrote: Sam James <sam () gentoo org> writes: The most significant one here seems to be the first entry under "Fixed in Postfix 3.8, 3.9, 3.10:".

-------------------- Start of forwarded message -------------------- To: Postfix announce <postfix-announce () postfix org> Date: Sun, 3 May 2026 19:43:27 -0400 (EDT) CC: Postfix users <postfix-users () postfix org> Subject: [pfx] Postfix stable release 3.11.2 and legacy releases 3.10.9, 3.9.10, 3.8.16 From: Wietse Venema via Postfix-users <postfix-users () postfix org>

[An on-line version of this announcement will be available at https://www.postfix.org/announcements/postfix-3.11.2.html]

[...] I am interested in feedback on whether using my own judgement is acceptable for bringing these to oss-security, where I believe they may of interest (releases with fixes that appear security-related, as the volume is increasing with the current wave of new tooling ()), or whether there are some guidelines I should apply.

Thanks in advance.

() I of course only plan to bring such things where I plan to treat them at least in part as a security bug downstream. Yes, I think your judgement fits what many of us would like to see on this list. Thank you!

As to this specific issue, I guess Wietse called it a bug and not a vulnerability deliberately. I trust his judgement on this, but I don't mind downstreams being cautious. Per my reading, exposure is limited to other trusted components and impact is not directly security relevant (if only a child process crashes and will be respawned).

Alexander

Hi,

On Mon, May 04, 2026 at 05:35:38PM +0100, Sam James wrote: The most significant one here seems to be the first entry under "Fixed in Postfix 3.8, 3.9, 3.10:". [...] Fixed in Postfix 3.8, 3.9, 3.10:

Bugfix (defect introduced: Postfix 2.3, date: 20050323): buffer over-read when Postfix an enhanced status code is not followed by other text. For example, "5.7.2" without text after the three-number code. This CANNOT be triggered with an SMTP or LMTP server response; is confirmed with an access(5) table and likely with a policy server response; can possibly be triggered with pipe-to-command output, headerchecks(5), bodychecks(5), an error(8) transport in transportmaps, or a milter response; and is confirmed with a DNSBL server TXT response while Postfix is configured with "$rblcode $rbltext" in rblreplymaps or defaultrblreply. This could result in process termination. Problem reported by Kamil Frankowicz. This one got https://www.cve.org/CVERecord?id=CVE-2026-43964 assigned.

Regards, Salvatore

Postfix before 3.8.16, 3.9 before 3.9.10, and 3.10 before 3.10.9 sometimes allows a buffer over-read and process crash via an enhanced status code that lacks text after the third number.

Last updated 13 May 2026

Sam James <sam () gentoo org> writes: The most significant one here seems to be the first entry under "Fixed in Postfix 3.8, 3.9, 3.10:".

-------------------- Start of forwarded message -------------------- To: Postfix announce <postfix-announce () postfix org> Date: Sun, 3 May 2026 19:43:27 -0400 (EDT) CC: Postfix users <postfix-users () postfix org> Subject: [pfx] Postfix stable release 3.11.2 and legacy releases 3.10.9, 3.9.10, 3.8.16 From: Wietse Venema via Postfix-users <postfix-users () postfix org>

[An on-line version of this announcement will be available at https://www.postfix.org/announcements/postfix-3.11.2.html]

[...] I am interested in feedback on whether using my own judgement is acceptable for bringing these to oss-security, where I believe they may of interest (releases with fixes that appear security-related, as the volume is increasing with the current wave of new tooling ()), or whether there are some guidelines I should apply.

Thanks in advance.

() I of course only plan to bring such things where I plan to treat them at least in part as a security bug downstream.

The most significant one here seems to be the first entry under "Fixed in Postfix 3.8, 3.9, 3.10:".

-------------------- Start of forwarded message -------------------- To: Postfix announce <postfix-announce () postfix org> Date: Sun, 3 May 2026 19:43:27 -0400 (EDT) CC: Postfix users <postfix-users () postfix org> Subject: [pfx] Postfix stable release 3.11.2 and legacy releases 3.10.9, 3.9.10, 3.8.16 From: Wietse Venema via Postfix-users <postfix-users () postfix org>

[An on-line version of this announcement will be available at https://www.postfix.org/announcements/postfix-3.11.2.html]

Fixed in Postfix 3.11:

Bugfix (defect introduced: Postfix 3.11): the proxymap(8) daemon dereferenced an uninitialized pointer after a request protocol error. This daemon is not exposed to local or remote users. Found by Claude Opus 4.6.

Bugfix (defect introduced: 20260309) a change, to set the servicename default value to "amnesiac", violated a test that parameter names in postconf output must match 1:1 with parameter names in the postlink script.

Fixed in Postfix 3.10:

Bugfix (defect introduced: Postfix 3.10): The RFC 2047 encoder for the sender "full name" could loop when a very long fullnameencodingcharset value was configured in main.cf. Found by Claude Opus 4.6.

Fixed in Postfix 3.8, 3.9, 3.10:

Bugfix (defect introduced: Postfix 2.3, date: 20050323): buffer over-read when Postfix an enhanced status code is not followed by other text. For example, "5.7.2" without text after the three-number code. This CANNOT be triggered with an SMTP or LMTP server response; is confirmed with an access(5) table and likely with a policy server response; can possibly be triggered with pipe-to-command output, headerchecks(5), bodychecks(5), an error(8) transport in transportmaps, or a milter response; and is confirmed with a DNSBL server TXT response while Postfix is configured with "$rblcode $rbltext" in rblreplymaps or defaultrblreply. This could result in process termination. Problem reported by Kamil Frankowicz.

For older Postfix versions, a buffer over-read patch is included at the end of this text.

Code cleanup: log a fatal error instead of dereferencing a null pointer after a first/next cursor initialization failure. Fedor Vorobev. This affected the Berkeley DB client.

Fixed in Postfix 3.8, 3.9, 3.10. 3.11:

Portability: support for recent FreeBSD, NetBSD, and OpenBSD versions. Brad Smith.

Bugfix (defect introduced: Postfix 2.2, date 20041207): When truncating a database file, the cdb: database client looked at the file size from before requesting an exclusive lock on a database file, instead of the file size after the exclusive lock was granted. Found by Claude Opus 4.6.

Bugfix (defect introduced: Postfix alpha, date 19980309): file descriptor leak after fork() failure. Found by Claude Opus 4.6.

Mistakes in debug logging. Found by Claude Opus 4.6. This affected two files in Postfix 3.8 and 3.9, three files in Postfix 3.10 and 3.11.

Unchecked null pointer results after an out-of-memory condition in a library dependency. Found by Claude Opus 4.6. The fix is to return an error status or to log a fatal error. This affected three source files.

Missing or incomplete guards for ssizet or int overflow, found by Claude Opus 4.6. This affected three source files. These limits are unlikely to be exceeded because the size of in-memory objects is limited by design (the number of in-memory objects is also limited).

You can find the updated Postfix source code at the mirrors listed at https://www.postfix.org/.

Wietse

Buffer over-read patch for Postfix 2.3 .. 3.7:

--- /var/tmp/postfix-3.8.15/src/global/dsnutil.c 2006-01-07 20:28:37.000000000 -0500 +++ src/global/dsnutil.c 2026-05-01 16:59:50.961688175 -0400 @@ -155,5 +155,5 @@ strncpy(dp->dsn.data, cp, len); dp->dsn.data[len] = 0; - cp += len + 1; + cp += len; } else if ((len = dsnvalid(defdsn)) > 0) { strncpy(dp->dsn.data, defdsn, len); Postfix-users mailing list -- postfix-users () postfix org To unsubscribe send an email to postfix-users-leave () postfix org -------------------- End of forwarded message --------------------

Latest version: 3.11.7

Latest version: 3.10.14

End of life: 3/6/2026, Latest version: 3.7.23

End of life: 3/6/2026, Latest version: 3.7.23

On 4/30/24 14:13, nightmare.yeah27 () aceecat org wrote: What is the benefit of stripping versus the much more natural option of rejecting such messages? This applies to <CRLF>.<CRLF> and RFC 5321 section 4.5.2 as well.

Postfix' CVE-2023-51764 patchset adds options to normalize (default), note, reject, or ignore bare newlines: cleanupreplacestraycrlf = default:yes smtpdforbidbarenewline = default:normalize smtpdforbidbarenewlineexclusions = default:$mynetworks (See Postfix' HISTORY file for more context.)

To get back to your question, these all have usecases. What should be the default is described in RFC 5321. Offering options and using the RFCs sane default seems like a fair balance.

On 4/30/24 14:42, Erik Auerswald wrote: Well, my reading of the RFC does not forbid this sequence. RFC 5321 clearly does not require transforming this sequence into another sequence. I should have initially clarified that "forbidden" pattern refers to RFC 5321 section 4.5.2: Without some provision for data transparency, the character sequence "<CRLF>.<CRLF>" ends the mail text and cannot be sent by the user. In general, users are not aware of such "forbidden" sequences. To allow all user composed text to be transmitted transparently, the following procedures are used: o Before sending a line of mail text, the SMTP client checks the first character of the line. If it is a period, one additional period is inserted at the beginning of the line. o When a line of mail text is received by the SMTP server, it checks the line. If the line is composed of a single period, it is treated as the end of mail indicator. If the first character is a period and there are other characters on the line, the first character is deleted.

I believe "<CRLF><NUL>.<CRLF>" is a forbidden sequence. Resnick's response to this sequence is: "Yes, the sending MTA should strip the NUL (as per RFC 5321 section 4.1.1.4) and then dot-stuff the dot on the line by itself (as per RFC 5321 section 4.5.2)." You to seem to advocate for "repair". The "repair" strategy makes Cisco's ESA vulnerable. I would argue that rejecting messages is less insecure. By default, Cisco ESA is not RFC compliant. Their "clean" option only replaces bare <CR> and <LF> characters with <CRLF>. So that <CR>.<CR> becomes <CRLF>.<CRLF>. Both of these are "forbidden" patterns and should be dot stuffed.

On 4/30/24 17:48, Steffen Nurpmeso wrote: Given that RFC 733 is from 1977 and RFC 822 is from 1982 i feel this entire thread is exaggerating. The history of EOD attacks makes the recent SMTP Smuggling attacks so surprising! It is hard to believe that SMTP servers were recently vulnerable to <CRLF>.<CRLF> variations and that others still are.

Thanks Solar :)

Mark Esler and Bastien Roucariès

Latest version: 3.9.15

Latest version: 3.9.15

On Fri, Dec 29, 2023 at 12:50:55PM -0800, Alan Coopersmith wrote: On 12/26/23 11:15, Claus Assmann wrote: On Sun, Dec 24, 2023, Marcus Meissner wrote: - CVE-2023-51765 sendmail Can you update the text for this (or point me to the proper way/persons to do this)? https://www.cve.org/CVERecord?id=CVE-2023-51765 shows: Assigner: MITRE Corporation

so you can submit updates/corrections via the web form at: https://cveform.mitre.org/ Yes please use this form, or if you do not want one of us can do it.

I did not request the sendmail and exim CVEs, also the postfix CVE seems not my proposed description, so I guess someone else requested them.

Ciao, Marcus

Happy christmas list! On 24/12/2023 12.33, Marcus Meissner wrote: On Sat, Dec 23, 2023 at 02:29:34PM +0200, Valtteri Vuorikoski wrote: On Fri, Dec 22, 2023 at 11:46:48AM +0100, Marcus Meissner wrote: Hi,

FWIW as no CVEs were to be found yet, I filed a CVE request for Postfix now.

Not sure if we need it for others like sendmail too, as that is also referenced by the security researchers. Looks like exim opened a bug on this yesterday too, no sign of CVE yet: <https://bugs.exim.org/showbug.cgi?id=3063> CVEs are assigned now for:

- CVE-2023-51764 postfix - CVE-2023-51765 sendmail - CVE-2023-51766 exim

Ciao, Marcus

On Sat, Dec 23, 2023 at 02:29:34PM +0200, Valtteri Vuorikoski wrote: On Fri, Dec 22, 2023 at 11:46:48AM +0100, Marcus Meissner wrote: Hi,

FWIW as no CVEs were to be found yet, I filed a CVE request for Postfix now.

Not sure if we need it for others like sendmail too, as that is also referenced by the security researchers. Looks like exim opened a bug on this yesterday too, no sign of CVE yet: <https://bugs.exim.org/showbug.cgi?id=3063> CVEs are assigned now for:

- CVE-2023-51764 postfix - CVE-2023-51765 sendmail - CVE-2023-51766 exim

Ciao, Marcus

On Fri, Dec 22, 2023 at 05:41:56PM +0100, Solar Designer wrote: Subject: [pfx-ann] Postfix stable release 3.8.4 This was followed by almost identical announcements for 3 other stable branches of Postfix, with the fix included in 3.7.9, 3.6.13, and 3.5.23. I'm not forwarding those individual messages in here, but I thought it's relevant to mention that these 4 branches/releases got the fix now. [An on-line version of this announcement will be available at https://www.postfix.org/announcements/postfix-3.8.4.html]

Fixed with Postfix 3.8.4:

Security: this release adds support to defend against an email spoofing attack (SMTP smuggling) on recipients at a Postfix server. For background, see https://www.postfix.org/smtp-smuggling.html.

Sites concerned about SMTP smuggling attacks should enable this feature on Internet-facing Postfix servers. For compatibility with non-standard clients, Postfix by default excludes clients in mynetworks from this countermeasure.

The recommended settings are:

# Optionally disconnect remote SMTP clients that send bare newlines, # but allow local clients with non-standard SMTP implementations # such as netcat, fax machines, or load balancer health checks. # smtpdforbidbarenewline = yes smtpdforbidbarenewlineexclusions = $mynetworks

The smtpdforbidbarenewline feature is disabled by default.

You can find the updated Postfix source code at the mirrors listed at https://www.postfix.org/.

Wietse Postfix-announce mailing list -- postfix-announce () postfix org To unsubscribe send an email to postfix-announce-leave () postfix org

----- End forwarded message ----- Alexander

----- Forwarded message from Wietse Venema via Postfix-announce <postfix-announce () postfix org> -----

To: Postfix announce <postfix-announce () postfix org> Date: Fri, 22 Dec 2023 11:30:21 -0500 (EST) CC: Postfix users <postfix-users () postfix org> Subject: [pfx-ann] Postfix stable release 3.8.4 From: Wietse Venema via Postfix-announce <postfix-announce () postfix org> Reply-To: Wietse Venema <wietse () porcupine org>

[An on-line version of this announcement will be available at https://www.postfix.org/announcements/postfix-3.8.4.html]

Fixed with Postfix 3.8.4:

Security: this release adds support to defend against an email spoofing attack (SMTP smuggling) on recipients at a Postfix server. For background, see https://www.postfix.org/smtp-smuggling.html.

Sites concerned about SMTP smuggling attacks should enable this feature on Internet-facing Postfix servers. For compatibility with non-standard clients, Postfix by default excludes clients in mynetworks from this countermeasure.

The recommended settings are:

# Optionally disconnect remote SMTP clients that send bare newlines, # but allow local clients with non-standard SMTP implementations # such as netcat, fax machines, or load balancer health checks. # smtpdforbidbarenewline = yes smtpdforbidbarenewlineexclusions = $mynetworks

The smtpdforbidbarenewline feature is disabled by default.

You can find the updated Postfix source code at the mirrors listed at https://www.postfix.org/.

Wietse Postfix-announce mailing list -- postfix-announce () postfix org To unsubscribe send an email to postfix-announce-leave () postfix org

----- End forwarded message -----

Hi,

On Fri, Dec 22, 2023 at 01:11:37PM +0100, Marcus Meissner wrote: On Fri, Dec 22, 2023 at 11:09:49AM +0000, Stuart Henderson wrote: On 2023/12/22 11:46, Marcus Meissner wrote: FWIW as no CVEs were to be found yet, I filed a CVE request for Postfix now.

Not sure if we need it for others like sendmail too, as that is also referenced by the security researchers. I'd think that sendmail should have a CVE, too, or there could be one CVE pertaining to both Postfix and sendmail, because SEC Consult write in their blog post:

"After testing some popular e-mail software in their default configuration, it turned out that Postfix and Sendmail fulfil the requirements, are affected and can be smuggled to."

As such I'd say that both Postfix and sendmail are known to be vulnerable. I'm a little confused by sec-consult's process here. They identify a problem affecting various pieces of software including some very widely deployed open source software, go to the trouble of doing a coordinated disclosure, but only do that with...looking at their timeline... gmx, microsoft and cisco? Yes its weird.

I was also confused and actually only spotted the OSS software being affected on third read over their page.

They also reference CERT and VINCE, but at least SUSE was not pulled into the VINCE issue if there was any. (as CERT has not published anything I am not sure there was any besides the Cisco disclosure). According to the timeline, they involved CERT/CC and VINCE in August:

2023-08-17: Contacting CERT Coordination Center (CERT/CC) for further discussion with Cisco ... 2023-09-13: CERT/CC accepts the case ... 2023-11-29: CERT/CC allows public release of SMTP smuggling, since no software vulnerabilities were identified ("it's not a bug, it's a feature") ... 2023-12-18: Release date of blog post

The first timeline entry omits a bit from the text, i.e., VINCE:

"we contacted CERT/CC on 17th August to get some help for further discussion with Cisco and involve other potentially affected vendors (such as sendmail) through the VINCE communication platform." Also postfix timeline starts 4 days ago only. https://www.mail-archive.com/postfix-announce () postfix org/msg00090.html This is three days after the SEC Consult blog post.

My personal interpretation is as follows:

SEC Consult concentrated on the big email platforms, because of the potential impact. They informed platforms that could be used to perform the attack against vulnerable targets. They informed Cisco since they used an affected Cisco product and could thus be targeted (even though for Cisco this is not a vulnerability, but a feature). They involved CERT/CC and VINCE, probably with the assumption that this would result in identifying and informing affected vendors and projects. The CERT/CC and VINCE involvement resulted in "there is no vulnerability". SEC Consult publish their findings.

Now, others (including me) see this as a vulnerability affecting at least some open source email servers. SNAFU.

Cheers, Erik

On 2023/12/22 11:46, Marcus Meissner wrote: Hi,

FWIW as no CVEs were to be found yet, I filed a CVE request for Postfix now.

Not sure if we need it for others like sendmail too, as that is also referenced by the security researchers. I'm a little confused by sec-consult's process here. They identify a problem affecting various pieces of software including some very widely deployed open source software, go to the trouble of doing a coordinated disclosure, but only do that with...looking at their timeline... gmx, microsoft and cisco?

Hi,

FWIW as no CVEs were to be found yet, I filed a CVE request for Postfix now.

Not sure if we need it for others like sendmail too, as that is also referenced by the security researchers.

Ciao, Marcus On Thu, Dec 21, 2023 at 02:46:56PM +0000, Claus Assmann wrote: Just for completeness: sendmail 8.18.0.2 has options to handle this too, e.g., Accept only CR LF . CR LF as end of an SMTP message as required by the RFCs when the new srvfeatures option 'o' is used.

And for those who read the source code there's also an FFR: / enable checking for "bare LF" in message / "FFRBARELF",

Last updated 24 July 2024

Hi,

As if we did not have sufficient protocol vulnerability work short before Christmas break this year, here is one more:

https://sec-consult.com/blog/detail/smtp-smuggling-spoofing-e-mails-worldwide/

While it looks like "old stuff", this is new quality.

tldr: The end of "SMTP data phase" with "<CR><LF>.<CR><LF>" is not consistently implemented everywhere (e.g. when leaving out <CR> or inserting \0 or so) and could lead to one server passing it through and the other processing it, leading to mail spoofing.

The security report it for some custom email servers, but at least Postfix announced mitigation work already:

https://www.mail-archive.com/postfix-users () postfix org/msg100901.html

Ciao, Marcus

Latest version: 3.8.21

Latest version: 3.8.21

End of life: 2/16/2025, Latest version: 3.6.21

End of life: 2/16/2025, Latest version: 3.6.21