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.

[asa]

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.

Thanks for reply.

I am not talking about changing the email address in the account settings. I want to test it this way: Configure the account correctly first so it passes the test. Then, compose a new email and manually change the 'From' field to another address (e.g., boss@...) and try to send it. I want to see if Zimbra allows sending when the authenticated user differs from the 'From' header during the actual mail submission.

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

Thanks for reply.

I am not talking about changing the email address in the account settings. I want to test it this way: Configure the account correctly first so it passes the test. Then, compose a new email and manually change the 'From' field to another address (e.g., boss@...) and try to send it. I want to see if Zimbra allows sending when the authenticated user differs from the 'From' header during the actual mail submission.

Ah, didn't expect this is possible under Outlook! I see it now. It is worrying.

Some search in postfix docs found this: Note: to enforce that the From: header address matches the envelope sender (MAIL FROM) address, use an external filter such as a Milter, for the submission or submissions (formerly called smtps) services. For example: https://github.com/magcks/milterfrom.

This will need some R&D to integrate...

Basically Thunderbird will change the SASL login to the new address but Outlook uses the original one, only change the header From and added header Sender. This result is mail is still seen as legit. All this is happening at the Postfix level, not at Zimbra jetty yet.

Update:

There is ZimbraMilter integration at port 7026 on MTA to do DL ACL control. There is also custom milter write up by Barry. Well, they are quite old now.

I hope Zimbra can find time to start Zimbra Developer Network (for example) so that we all can help faster...