Inconsistent SMTP AUTH enforcement: Outlook vs Thunderbird

[adrian.gibanel.btactic]

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.

No, we have not tested this specific scenario.

[asa]

Thanks for the clarification.

Based on our testing, this behavior is reproducible in our environment. The enforcement works correctly with Thunderbird, but Outlook is not affected and still allows a mismatched From address.

From a practical and security point of view, this looks like a problem, but it’s not clear whether Zimbra considers this expected behavior or a bug.

Has anyone else seen the same behavior with Outlook?
Is there a known workaround or recommended configuration to fully enforce sender alignment for Outlook clients?

Any input or experience would be helpful.

[yeak]

Could you show output of the following?

# su - zimbra
$ postconf smtpd_sender_restrictions
$ postconf smtpd_sender_login_maps
$ postmap -q adem@company.com ldap:/opt/zimbra/conf/ldap-slm.cf

[asa]

Could you show output of the following?

# su - zimbra
$ postconf smtpd_sender_restrictions
$ postconf smtpd_sender_login_maps
$ postmap -q adem@company.com ldap:/opt/zimbra/conf/ldap-slm.cf

zimbra@mail:/home/sshuser$ postconf smtpd_sender_restrictions
smtpd_sender_restrictions = check_sender_access regexp:/opt/zimbra/common/conf/tag_as_originating.re, permit_mynetworks, reject_sender_login_mismatch, permit_sasl_authenticated, permit_tls_clientcerts, check_sender_access regexp:/opt/zimbra/common/conf/tag_as_foreign.re
zimbra@mail:/home/sshuser$ postconf smtpd_sender_login_maps
smtpd_sender_login_maps = proxy:ldap:/opt/zimbra/conf/ldap-slm.cf
zimbra@mail:/home/sshuser$ postmap -q boss@regulacloud.com ldap:/opt/zimbra/conf/ldap-slm.cf
boss, boss@regulacloud.com,boss, boss
zimbra@mail:/home/sshuser$

[yeak]

zimbra@mail:/home/sshuser$ postmap -q boss@regulacloud.com ldap:/opt/zimbra/conf/ldap-slm.cf
boss, boss@regulacloud.com,boss, boss

This postmap verifies that if you SMTP AUTH using "boss@regulacloud.com", you can only use the MAIL FROM from the above output.

My post asks to verify "adem@regulacloud.com". If you don't see "boss" in the output, then it should not allow mail client to change itself to boss.

If all are in proper order, YET you still can use Outlook to break it, then you can check the mail header for "Return-Path" address.

[asa]

zimbra@mail:/home/sshuser$ postmap -q boss@regulacloud.com ldap:/opt/zimbra/conf/ldap-slm.cf
boss, boss@regulacloud.com,boss, boss

This postmap verifies that if you SMTP AUTH using "boss@regulacloud.com", you can only use the MAIL FROM from the above output.

My post asks to verify "adem@regulacloud.com". If you don't see "boss" in the output, then it should not allow mail client to change itself to boss.

If all are in proper order, YET you still can use Outlook to break it, then you can check the mail header for "Return-Path" address.

Thanks for the commands, but as I’ve clearly stated in my previous posts (and specifically in my reply to @adrian.gibanel.btactic), these configurations are already active and working perfectly fine with Thunderbird.

The issue isn't whether smtpd_sender_login_maps is configured or not—it is. The problem is that while Zimbra/Postfix correctly enforces these rules for Thunderbird, it somehow bypasses or ignores them for Outlook clients on the exact same ports (465/587).

Before we go further into my LDAP outputs, I’d appreciate it if you could actually reproduce the scenario yourself:

Use an Outlook client.

Manually change the 'From' address to another internal user.

Observe how Zimbra accepts the mail despite reject_sender_login_mismatch being active.

Once you see that Outlook can still spoof internal senders while Thunderbird is blocked, you'll understand that providing more config outputs won't solve a client-dependent enforcement gap. Does your environment actually block Outlook in this scenario? Because mine doesn't, and that's the whole point of this thread.

[yeak]

I setup the lab and configure SLM for the Zimbra.

Then use Thunderbird and Outlook to do the test.

First configure it correctly to confirm the correct username can send out the mail. Just test send to self.

Then modify Thunderbird and Outlook to change email address to other name not the same as the username. Like "boss".

Outlook fails to verify the SMTP verification. Logs in Zimbra also show it is not allowed.