Inconsistent SMTP AUTH enforcement: Outlook vs Thunderbird

[asa]

We are observing a serious inconsistency in how Zimbra enforces the authenticated sender depending on the mail client.

When a Zimbra mailbox is configured in Microsoft Outlook, the user can manually change the From address to another internal user and the message is accepted and delivered, even though no Send As or delegation permission exists.

The same operation is correctly rejected by Thunderbird, which indicates that this is not generic SMTP behavior but a server-side enforcement gap exposed when Outlook is used.

Environment:
• Zimbra Collaboration Suite (observed on 10.1.x, also reproducible on earlier versions)
• SMTP AUTH
• Clients tested:
• Microsoft Outlook 2016 / 2019 / 365
• Mozilla Thunderbird
• No aliases configured
• No Send As or delegated permissions granted

Steps to reproduce:
1. Create a mailbox:
adem@company.com
2. Configure this mailbox in Microsoft Outlook using SMTP AUTH.
3. In Outlook, manually change the From address to:
boss@company.com
4. Send an email to an internal recipient.

Actual result (Outlook):
• Message is accepted by Zimbra
• Message is delivered internally
• Recipient sees:
From: boss@company.com
• The authenticated user is still adem@company.com

This allows internal sender impersonation.

Expected result:

One of the following should occur:
• The message is rejected
• The From address is rewritten to the authenticated user
• Send As permission is required

Thunderbird comparison:

Using the same account (adem@company.com) in Thunderbird:
• Changing the From address to boss@company.com
• Sending fails with an authentication/authorization error (5.7.x)
• The message is not accepted by the server

This demonstrates that Zimbra can detect and block this condition, but does not enforce it consistently across clients.

Security impact:

This behavior enables internal impersonation, including executive spoofing. In organizations where Outlook is widely used, this creates a significant internal phishing risk. Because DMARC does not apply to internal mail flow, recipients have no visible indication that spoofing has occurred.

Notes:
• Google Workspace does not allow this behavior. It enforces alignment between the authenticated user and the From address unless explicit Send As permission is configured.
• Thunderbird’s behavior further indicates that this should not be considered expected or acceptable behavior.

Conclusion:

This appears to be a server-side enforcement issue where Zimbra accepts mismatched From headers from Outlook while correctly rejecting them from Thunderbird. From a security perspective, this should be treated as a bug or at least require a configuration option to enforce authenticated sender alignment

[Klug]

Are you using the same port for auth with Outlook and TB ?
Outlook would default to 465 while Thunderbird to 587 (submission).

Here's what I have in master.cf for port 465:

Code: Select all

465    inet  n       -       n       -       -       smtpd
        -o content_filter=scan:[127.0.0.1]:10030
        -o smtpd_sasl_auth_enable=yes
        -o smtpd_tls_wrappermode=yes
#       -o smtpd_tls_key_file=
#       -o smtpd_tls_cert_file=
        -o smtpd_client_restrictions=
        -o smtpd_data_restrictions=
        -o smtpd_helo_restrictions=
        -o smtpd_recipient_restrictions=
        -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
        -o syslog_name=postfix/smtps
        -o milter_macro_daemon_name=ORIGINATING
#       -o smtpd_proxy_filter=[127.0.0.1]:10027
#       -o smtpd_proxy_options=speed_adjust

And for port 587:

Code: Select all

submission inet n      -       n       -       -       smtpd
        -o content_filter=scan:[127.0.0.1]:10030
        -o smtpd_etrn_restrictions=reject
        -o smtpd_sasl_auth_enable=yes
        -o smtpd_tls_security_level=may
#       -o smtpd_tls_key_file=
#       -o smtpd_tls_cert_file=
        -o smtpd_client_restrictions=permit_sasl_authenticated,reject
        -o smtpd_data_restrictions=
        -o smtpd_helo_restrictions=
        -o smtpd_recipient_restrictions=
        -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
        -o syslog_name=postfix/submission
        -o milter_macro_daemon_name=ORIGINATING
#       -o smtpd_proxy_filter=[127.0.0.1]:10027
#       -o smtpd_proxy_options=speed_adjust

As you can see, these are different, submission (587) has this:

Code: Select all

        -o smtpd_client_restrictions=permit_sasl_authenticated,reject

[ghen]

Are you aware of the difference between SMTP envelope sender (also known as "Return Path") vs. the From header ? (i.e., RFC 5321 vs. RFC 5322) Otherwise you may be drawing incorrect conclusions.

Perhaps Outlook changes only the user-visible From header, and still sets the envelope sender (which is what your SMTP server cares about) to the authenticated user, whereas Thunderbird changes both, and gets rejected?

[asa]

Thanks for the responses.

Yes, we are aware of the distinction between the SMTP envelope sender (RFC 5321 / Return-Path) and the RFC 5322 From header. The issue we are describing is not based on a misunderstanding of these concepts.

To clarify what we are seeing:

When using Outlook, changing the From address to another internal user (for example boss@company.com) results in the message being accepted and delivered internally. The authenticated SMTP user remains adem@company.com, and the envelope sender (Return-Path) stays aligned with that authenticated user. Only the RFC 5322 From header is changed.

This behavior is exactly the problem being raised.

From a security and authorization standpoint, allowing an authenticated user to arbitrarily set the visible From header to another internal address without Send As permission enables internal impersonation. While traditional SMTP enforcement focuses on the envelope sender, modern mail systems—Google Workspace included—also enforce authorization on the visible From header for internal domains.

Regarding submission ports:

We are using the default client behavior:
• Outlook typically submits via port 465 or 587
• Thunderbird typically uses port 587 (submission)

Both ports have SMTP AUTH enabled and use permit_sasl_authenticated rules, so in both cases Postfix is aware of the authenticated identity. The difference in behavior cannot be explained purely by envelope sender handling, because Thunderbird rejects messages where the visible From does not match the authenticated user, while Outlook submissions with a mismatched From are accepted. This leads to different authorization outcomes for the same account, on the same server and domain.

This effectively creates a client-dependent authorization gap. Even with a correct envelope sender, the lack of enforcement on the RFC 5322 From header for internal domains allows impersonation that recipients cannot distinguish. Since DMARC does not apply to internal mail flow, envelope sender alignment alone does not mitigate this risk.

The core concern here is not RFC compliance in isolation, but consistent authorization and reasonable security expectations for internal users. At minimum, there should be a server-side option to enforce that the visible From header matches the authenticated user, or that explicit Send As permission is required, regardless of client or submission port.

Additionally, we tested the same scenario on Google Workspace using Outlook.

When the From field is manually set to an unauthorized internal address (for example boss@company.com), Google does not expose this value as the visible From to the recipient. The authenticated user remains the visible sender, while the user-supplied From value is retained only in the message headers (for example as an X-Original-From–type field for logging and audit purposes).

In practice, Google accepts the client-supplied information but does not trust it for display unless it is authorized. This prevents internal impersonation while still preserving traceability. A similar approach on Zimbra—where an unauthenticated Outlook-provided From is not exposed as the visible sender—would already mitigate the issue to a large extent.

As shown in the attached message headers, in this example the authenticated sender is info@company.com, while Outlook attempted to use aliveli@company.com as the From address. Google clearly records this by keeping the authenticated sender as the visible From, and storing the user-supplied, unauthorized address separately (for example in X-Google-Original-From).

In other words, even when Outlook provides an unauthenticated From value, Google consistently presents the message to recipients as coming from the authenticated account. This prevents impersonation while still preserving the original client-supplied information for auditing and troubleshooting purposes.

[adrian.gibanel.btactic]

Regarding submission ports:

We are using the default client behavior:
• Outlook typically submits via port 465 or 587
• Thunderbird typically uses port 587 (submission)

Given the same configuration (the same from address, login details and recipient address):

Can you force Outlook to use 465 port and log the behaviour?
Can you force Outlook to use 587 port and log the behaviour?
Can you force Thunderbird to use 465 port and log the behaviour?
Can you force Thunderbird to use 587 port and log the behaviour?

From the results... Can you still conclude that it's an specific Outlook problem?

That way we will rule out the port difference behaviour that @Klug hinted.

[asa]

We tested the same scenario via Thunderbird on port 587 and observed different behavior depending on whether the forged From address exists as a local Zimbra account.

If the forged From address does NOT exist in Zimbra (example: boss2@regulacloud.com), the message is rejected. As shown in Screenshot 1, Postfix logs clearly show that the authenticated user is personel@regulacloud.com, and the sender address is rejected during RCPT with a 550 error.

If the forged From address DOES exist as a local Zimbra account (example: boss@regulacloud.com), the message is accepted and delivered. In this case, the logs no longer reference the authenticated user in the message flow. The message is queued and processed as if it legitimately originated from boss@regulacloud.com, even though SMTP AUTH was performed as personel@regulacloud.com.

This behavior is specific to Thunderbird tests on port 587.

When performing the same tests via Outlook, the existence of the forged From address in Zimbra makes no difference at all. Messages are accepted regardless of whether the From address exists locally, and the forged address may not appear in the logs at all, while the message is still delivered with the fake From visible to the recipient.

This further highlights that sender authorization enforcement is inconsistent and client-dependent, and that Outlook submissions bypass checks that are partially enforced for Thunderbird.

Log records and screen ratios related to this issue are contained within the eml-log-file.zip archive.

Myconf:

zimbra@mail:/home/sshuser$ zmprov gacf | grep zimbraMtaSmtpdRejectUnlisted
zimbraMtaSmtpdRejectUnlistedRecipient: yes
zimbraMtaSmtpdRejectUnlistedSender: yes

Code: Select all

#
# Postfix master process configuration file.  For details on the format
# of the file, see the Postfix master(5) manual page.
#
# ==========================================================================
# service type  private unpriv  chroot  wakeup  maxproc command + args
#               (yes)   (yes)   (yes)   (never) (100)
# ==========================================================================
smtp      inet  n       -       n       -       1       postscreen
tlsproxy  unix  -       -       n       -       0       tlsproxy
dnsblog   unix  -       -       n       -       0       dnsblog
smtpd     pass  -       -       n       -       -       smtpd
        -o smtpd_tls_security_level=may
        -o content_filter=scan:[127.0.0.1]:10030
#       -o smtpd_proxy_filter=[127.0.0.1]:10027
#       -o smtpd_proxy_options=speed_adjust
465    inet  n       -       n       -       -       smtpd
        -o content_filter=scan:[127.0.0.1]:10030
        -o smtpd_sasl_auth_enable=yes
        -o smtpd_tls_wrappermode=yes
#       -o smtpd_tls_key_file=
#       -o smtpd_tls_cert_file=
        -o smtpd_client_restrictions=
        -o smtpd_data_restrictions=
        -o smtpd_helo_restrictions=
        -o smtpd_recipient_restrictions=
        -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
        -o syslog_name=postfix/smtps
        -o milter_macro_daemon_name=ORIGINATING
#       -o smtpd_proxy_filter=[127.0.0.1]:10027
#       -o smtpd_proxy_options=speed_adjust
submission inet n      -       n       -       -       smtpd
        -o content_filter=scan:[127.0.0.1]:10030
        -o smtpd_etrn_restrictions=reject
        -o smtpd_sasl_auth_enable=yes
        -o smtpd_tls_security_level=may
#       -o smtpd_tls_key_file=
#       -o smtpd_tls_cert_file=
        -o smtpd_client_restrictions=permit_sasl_authenticated,reject
        -o smtpd_data_restrictions=
        -o smtpd_helo_restrictions=
        -o smtpd_recipient_restrictions=
        -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
        -o syslog_name=postfix/submission
        -o milter_macro_daemon_name=ORIGINATING
#       -o smtpd_proxy_filter=[127.0.0.1]:10027
#       -o smtpd_proxy_options=speed_adjust

[adrian.gibanel.btactic]

Can you please check if the Enforcing a match between FROM address and sasl username wiki page would enforce your expected security flow ?

[asa]

Yes, we tested the configuration described in the “Enforcing a match between FROM address and sasl username” wiki page.

After applying those steps, the behavior in Thunderbird is corrected and works exactly as expected. Messages are consistently rejected when the RFC 5322 From address does not match the authenticated SASL user, regardless of whether the forged From address exists as a local Zimbra account or not. In other words, Thunderbird behaves correctly and predictably with this enforcement enabled.

However, the same configuration has no effect on Outlook.

When sending via Outlook, messages with a mismatched From address are still accepted and delivered, and the visible From remains forged. There is no change in behavior, no rejection, and no enforcement, even though the authenticated SASL user is clearly known.

This is exactly the issue being raised here:
the documented enforcement works for Thunderbird but is bypassed by Outlook submissions. That indicates the problem is not a missing configuration, but an inconsistency in how enforcement is applied depending on the client.

So while the wiki solution partially addresses the problem, it does not fully enforce the expected security flow in environments where Outlook is used, which is the primary concern in our case.

For reference, the file new-log.zip contains the related EML files and SMTP log entries, in case you would like to review the message flow in more detail.

[adrian.gibanel.btactic]

However, the same configuration has no effect on Outlook.

I am still not sure that this is an specific Outlook issue but rather a port one.

You're doing your tests using Thunderbird with 587 port and Outlook with 465 port. Isn't it?

From your feedback I'm not sure If you have set both Outlook and Thunderbird to use the same port.

[asa]

We understand the question about a possible port-related difference.

To clarify, Outlook was tested using both port 587 and port 465, and the outcome is the same in both cases. The enforcement described in the wiki does not change Outlook’s behavior on either port.

With the enforcement enabled, Thunderbird behaves as expected and consistently blocks messages where the visible From address does not match the authenticated user. Outlook, however, continues to accept and deliver messages with a forged From address, regardless of which port is used.

Could you please confirm whether you have tested this specific scenario with Outlook? In particular, whether the recipient sees the forged From address or the authenticated sender when sending without Send As permission. It would be helpful to know if you observe the same behavior on your own system when testing with Outlook.

We will share the Outlook screenshots and the corresponding log entries that demonstrate this behavior.