Zimbra and SMTP Smuggling attack on Postfix

Recently an SMTP Smuggling attack on Postfix was published, as mentioned by the Postfix project:

Days before a 10+ day holiday break and associated production change freeze, SEC Consult has published an email spoofing attack that involves a composition of email services with specific differences in the way they handle line endings other than <CR><LF>.

Unfortunately, criticial information provided by the researcher was not passed on to Postfix maintainers before publication of the attack, otherwise we would certainly have convinced SEC Consult to postpone publication until after people had a chance to update their Postfix or other affected systems.

The net result: a presumably unintended zero-day attack was published because some people weren’t aware of the scope of the attack.

At this time it means an upstream fix by Postfix is needed to fully fix the security issue.

Zimbra will create a patch with updated configuration files and an updated version of Postfix as soon as possible, meanwhile we recommend to add:



To the bottom of all the following files:



Remove the already existing line that reads: smtpd_discard_ehlo_keywords =  from /opt/zimbra/common/conf/main.cf.default

And then as the OS user zimbra restart the MTA:

zmmtactl restart

The following line should already be set in the configuration files, but be sure to check if it is indeed present on your installation:

smtpd_data_restrictions = reject_unauth_pipelining



9 Responses to Zimbra and SMTP Smuggling attack on Postfix

  1. sigtrap December 28, 2023 at 2:23 AM #

    The file /opt/zimbra/common/conf/main.cf.default already has the line ‘smtpd_discard_ehlo_keywords =’
    But the workaround is to add the line to the bottom of the main.cf.default?

    • Avatar photo
      Barry de Graaff December 28, 2023 at 2:48 AM #

      Thanks for your comment, will update the blog post.

  2. Ashish Kataria December 28, 2023 at 1:48 PM #

    You may either replace that line with smtpd_discard_ehlo_keywords=chunking or remove the already existing line and add it to the bottom.

    • Geert Hendrickx January 9, 2024 at 4:55 AM #

      It’s cleaner to use `postconf -e` to edit Postfix configuration, it will add new or update existing lines as needed.

    • Avatar photo
      Barry de Graaff January 11, 2024 at 3:55 AM #

      I am not sure if using postconf on template files will always have the desired effect, but again this issue will be addressed by a Zimbra patch postconf should not be needed.

  3. Ricardo M January 15, 2024 at 8:09 AM #

    For us it seems like the SMTP Server is still vulnerable, even after these setting are set and the MTA is restarted.

    It’s not possible with BDAT anymore, but with LF-DOT-CRLF it’s still possible to smuggle. Tested with the Tool from Xeam. Is anybody else experiencing this?

  4. Ashish Kataria January 22, 2024 at 3:31 AM #

    It appears that the tool from Xeam is not providing reliable results.
    Big e-mail providers like Microsoft and GMX who allowed sending an . sequence from their outbound SMTP server’s to the inbound SMTP server (postfix in our case) as unfiltered, have already patched this issue.

    If you’re planning to test this further, I would recommend trying out

    Postfix as an outbound server interprets . as an end-of-data sequence.
    In that case, go ahead to “Scanning postfix as an inbound SMTP servers”.

  5. Geert Hendrickx January 22, 2024 at 6:26 AM #

    Will you consider upgrading Postfix to 3.6.14 or newer? This new release improves the initial fixes released in December, with less impact on broken clients and better logging. See https://www.postfix.org/announcements/postfix-3.8.5.html

    Or wait a bit until Postfix 3.9 comes out. Unlike older releases, 3.9 will enable all recommended mitigations by default.

    • Avatar photo
      Barry de Graaff January 23, 2024 at 4:13 AM #

      We are planning to upgrade Postfix soon.

Leave a Reply

Copyright © 2022 Zimbra, Inc. All rights reserved.

All information contained in this blog is intended for informational purposes only. Synacor, Inc. is not responsible or liable in any manner for the use or misuse of any technical content provided herein. No specific or implied warranty is provided in association with the information or application of the information provided herein, including, but not limited to, use, misuse or distribution of such information by any user. The user assumes any and all risk pertaining to the use or distribution in any form of any subject matter contained in this blog.

Legal Information | Privacy Policy | Do Not Sell My Personal Information | CCPA Disclosures