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.

Last updated 13 May 2026

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 --------------------

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.

It was found that Berkeley DB reads the DBCONFIG configuration file from the current working directory by default. This happens when calling dbcreate() with dbenv=NULL; or using the dbmopen() function.

References:

http://seclists.org/oss-sec/2017/q2/452 http://www.postfix.org/announcements/postfix-3.2.2.html

Proposed patch:

http://seclists.org/oss-sec/2017/q2/475

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

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.6

Last updated 24 July 2024

Latest version: 3.10.13

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

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

DISPUTED postfixgroups.pl in Postfix 2.5.2 allows local users to overwrite arbitrary files via a symlink attack on the (1) /tmp/postfixgroups.stdout, (2) /tmp/postfixgroups.stderr, and (3) /tmp/postfixgroups.message temporary files. NOTE: the vendor disputes this vulnerability, stating "This is not a real issue ... users would have to edit a script under /usr/lib to enable it."

Postfix 2.4 before 2.4.9, 2.5 before 2.5.5, and 2.6 before 2.6-20080902, when used with the Linux 2.6 kernel, leaks epoll file descriptors during execution of "non-Postfix" commands, which allows local users to cause a denial of service (application slowdown or exit) via a crafted command, as demonstrated by a command in a .forward file.

Postfix before 2.3.15, 2.4 before 2.4.8, 2.5 before 2.5.4, and 2.6 before 2.6-20080814, when the operating system supports hard links to symlinks, allows local users to append e-mail messages to a file to which a root-owned symlink points, by creating a hard link to this symlink and then sending a message. NOTE: this can be leveraged to gain privileges if there is a symlink to an init script.

Postfix 2.5 before 2.5.4 and 2.6 before 2.6-20080814 delivers to a mailbox file even when this file is not owned by the recipient, which allows local users to read e-mail messages by creating a mailbox file corresponding to another user's account name.

The postfix.postinst script in the Debian GNU/Linux and Ubuntu postfix 2.5.5 package grants the postfix user write access to /var/spool/postfix/pid, which might allow local users to conduct symlink attacks that overwrite arbitrary files.

A heap-based buffer overread flaw was found in the way Postfix mail transport agent performed SASL handlers management for SMTP sessions, when the Cyrus SASL authentication was enabled. A remote attacker could use this flaw to cause Postfix smtpd server crash via specially-crafted SASL authentication request.

Note: The default configuration of Postfix mail transport agent, as shipped with Red Hat Enterprise Linux 4, 5, and 6 do not enable SASL support for SMTP authentication for mail clients (thus Postfix server instances using it are not vulnerable to this flaw).

Workaround: If your Postfix server configuration contains directive like:

smtpdsaslauthenable = yes

change 'yes' to 'no' or comment the whole line out not to be vulnerable to this flaw.

The STARTTLS implementation in Postfix 2.4.x before 2.4.16, 2.5.x before 2.5.12, 2.6.x before 2.6.9, and 2.7.x before 2.7.3 does not properly restrict I/O buffering, which allows man-in-the-middle attackers to insert commands into encrypted SMTP sessions by sending a cleartext command that is processed after TLS is in place, related to a "plaintext command injection" attack.

Multiple SQL injection vulnerabilities in Postfix Admin (aka postfixadmin) before 2.3.5 allow remote authenticated users to execute arbitrary SQL commands via (1) the pw parameter to the pacrypt function, when mysqlencrypt is configured, or (2) unspecified vectors that are used in backup files generated by backup.php.

DISPUTED A certain Postfix 2.10.1-7 package could allow an attacker to send an email from an arbitrary-looking sender via a homoglyph attack, as demonstrated by the similarity of \xce\xbf to the 'o' character. This is potentially relevant when the /etc/postfix/senderlogin feature is used, because a spoofed outbound message that uses a configured sender address is blocked with a "Sender address rejected: not logged in" error message, but a spoofed outbound message that uses a homoglyph of a configured sender address is not blocked. NOTE: some third parties argue that any missed blocking of spoofed outbound messages - except for exact matches to a sender address in the /etc/postfix/senderlogin file - is outside the design goals of Postfix and thus cannot be considered a Postfix vulnerability.

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.14

Latest version: 3.9.14

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