Hello, I recently migrated from Zimbra to Carbonio. After resolving some initial issues, everything seemed to be working fine at first, but there are still a couple of things that are not working correctly.
First, I tried disabling the "reject_authenticated_sender_login_mismatch" setting because I have network scanners that send emails and authenticate using account X, but change the "From" address to Y. Since there are many of these devices, I disabled the check through the AdminWeb interface under the MTA section. It appeared to be working at first, but then I noticed that even messages sent via port 587 using the correct authentication and without changing the "From" address started being rejected, as if the "From" did not match the authenticated user. For example:
Apr 17 12:14:36 srv-mail postfix/submission/smtpd[1011099]: NOQUEUE: reject: RCPT from 5.3.168.192.in-addr.arpa[192.168.3.5]: 553 5.7.1 integracao@xxxxx.com: Sender address rejected: not owned by user integracao; from=integracao@xxxxx.com to=user1@xxxx.com proto=ESMTP helo=<srv01.xxxxx.com>
Even after re-enabling the option in AdminWeb and restarting all services, the problem remained. While searching for a solution, I found two forum threads:
https://community.zextras.com/forum/carbonio-general-thread/sender-address-rejected-not-logged-in/
I tried the suggestion from that thread, but it didn’t work. What partially resolved the issue was a solution found in this Zimbra forum:
<a class="" href=" removed link " target="_new" rel="noopener" data-start="1564" data-end="1611"> removed link
The workaround was to remove the "reject_sender_login_mismatch" line from the file removed link Originally, the file had a line like:
permit_mynetworks, reject_sender_login_mismatch
After removing that line and restarting the MTA, sending started working again. However, I find this solution a bit strange and I’m wondering: what is the correct way to handle this situation?
The second issue is that some machines on my internal network are managing to send email via port 25 without authentication, even though they are not included in the "mynetworks" parameter. My current "mynetworks" configuration is:
127.0.0.0/8 192.168.255.0/24 192.168.3.70/32 192.168.3.71/32 192.168.3.72/32 192.168.3.73/32 192.168.3.7/32 192.168.3.9/32 10.10.1.0/24 192.168.3.15/32 192.168.3.59/32 192.168.3.66/32 10.10.1.10/32 192.168.3.240/32 192.168.3.183/32
However, devices with IP addresses like 192.168.3.97 or 192.168.107.5 are still able to send emails without authenticating. Can you help me understand why this is happening and how to prevent it?
Thanks in advance for your help.
Hi!
Does anyone have any ideas about this problem?
😀
regards;
The topic says "solved" but I do not see the solution here... The link got removed by anti* filter.
Anyway I'm facing the same problem. We migrated form zimbra OS 8.8 to carbonio CE 25.9. Client used to send some automated mails authenticated by "qi@domain" but with other email adresses (from the same domain) in "from". I tried multiple ways but ultimately failed.
I tried "carbonio prov ma qi@domain zimbraAllowAnyFromAddress TRUE" - with absolutely no effect.
I tried "carbonio prov ma qi@domian zimbraAllowFromAddress else@domain" - it failed with ERROR: service.INVALID_REQUEST (invalid request: zimbraAllowFromAddress may not contain an internal account: else@domain) ... this allowed me to enter external addresses (not hosted on carbonio), or invalid (non-exeistent) addresses for domains hosted on carbonio (which then cannot be used to send anyway). - the same happens if trying via web admin / domains / accounts / qi@domain / user prefs / addresses allowed for sending
I tried "carbonio prov grr account else@domain usr qi@domain sendAs" - this works but only for sending from the webmail interface. Not via SMTP AUTH (port 587). Same for grr sendOnBehalfOf.
I tried adding my own sender login map according to this post: Serverfault and checked that it works using: postmap -q else@domain 'unionmap:{ldap:/opt/zextras/conf/ldap-slm.cf,pcre:/opt/zextras/conf/extra-slm.cf}'. But I was unable to modify the main.cf:
carbonio prov mcf zimbraMtaSmtpdSenderLoginMaps 'unionmap:{proxy:ldap:/opt/zextras/conf/ldap-slm.cf,pcre:/opt/zextras/conf/extra-slm.cf}' ... config was modified, but main.cf remained the same even after `systemctl restart carbonio-configd.service`. Again probably the smtpd_sender_login_maps.cf allow only the default proxy:ldap:/opt/zextras/conf/ldap-slm.cf and lmdb:/opt/zextras/conf/slm-exceptions-db. I even created /opt/zextras/conf/slm-exceptions-db (and ran postmap to creatre *.lmdb file, added to the unionmap, but it did not get through. The unionmap is crucial in this case, because without the union the first lookup will match - so either LDAP which would allow users to use only their own login, or the exception, which would allow only qi@domain (and nobody else) to send mail on behalf of @domain.
So as last resort I tried to disable the check altogether by clearing zimbraMtaSmtpdSenderRestrictions.
carbonio prov gcf zimbraMtaSmtpdSenderRestrictions: reject_sender_login_mismatch ... clearing via web admin / mta / inbound flow / reject sendel login mismatch ... after save gcf was empty, but the main.cf was unchanged - restarting configd apparently rewrote main.cf, but the option stays there, probably because it is hardcoded in smtpd_sender_restrictions.cf
The last option I'm a bit afraid to do on production is to touch the ldap server directly and add zimbraAllowFromAddress for qi@domain manually.
Please is there any way to do this?
Best regards
Vladislav Kurz
One more question - one of the ways to go seems to be modification of templates in opt - zextras - conf - zmconfigd - smtpd_sender_restrictions.cf or smtpd_sender_login_maps.cf.
Will my modifications survive updates/upgrades?
I'll answer for my self - no it won't. Templates in zmconfigd get overwritten by upgrades. So any hints on modifying them are bound to fail sooner or later.
Is there any way how to preserve/merge custom changes in /opt/zextras/conf/zmconfigd ?
No, template files in /opt/zextras/conf/zmconfigd/ will not survive upgrades. They're owned by the carbonio-core package and get replaced on every update.
But you don't need to edit templates. There are some LDAP attributes that control these Postfix settings, and those do survive upgrades because they're stored in LDAP. So try just not by editing templates. Instead, use carbonio prov to set LDAP attributes.
For Customize Sender Restrictions:
# 1. Check current value (as zextras) su - zextras carbonio prov gs $(hostname -f) zimbraMtaSmtpdSenderRestrictions # 2. Set the new value carbonio prov ms $(hostname -f) zimbraMtaSmtpdSenderRestrictions "reject_authenticated_sender_login_mismatch" # 3. Restart services (as root) exit systemctl restart carbonio-configd.service systemctl restart carbonio-mta.target # 4. Verify su - zextras -c 'postconf smtpd_sender_restrictions'
If this persists, then we would lookinto Sender Login Maps.
let us know.
Well, that works partially. Templates check some LDAP values, but some are hard-set in the template. My LDAP attribute is:
$ carbonio prov gs $(hostname -f) zimbraMtaSmtpdSenderRestrictions zimbraMtaSmtpdSenderRestrictions: reject_sender_login_mismatch
/opt/zextras/conf/zmconfigd/smtpd_sender_restrictions.cf contains:
%%exact VAR:zimbraMtaSmtpdSenderRestrictions reject_authenticated_sender_login_mismatch%% %%contains VAR:zimbraMtaSmtpdSenderRestrictions check_sender_access lmdb:/opt/zextras/conf/postfix_reject_sender%% %%contains VAR:zimbraServiceEnabled cbpolicyd^ check_policy_service inet:localhost:%%zimbraCBPolicydBindPort%%%% %%contains VAR:zimbraServiceEnabled amavis^ check_sender_access regexp:/opt/zextras/common/conf/tag_as_originating.re%% permit_mynetworks, reject_sender_login_mismatch permit_sasl_authenticated permit_tls_clientcerts %%contains VAR:zimbraServiceEnabled amavis^ check_sender_access regexp:/opt/zextras/common/conf/tag_as_foreign.re%%
So yes, first two lines can be enabled by setting zimbraMtaSmtpdSenderRestrictions to two very specific values, but:
1. I cannot put just anything there. My LDAP says reject_sender_login_mismatch so it is not projected to postfix conf, because the templete checks for reject_authenticated_sender_login_mismatch
2. reject_sender_login_mismatch is hardcoded on line 5, so it cannot be disabled by anything that I put in any LDAP attribute. (And enabling it on the first line would be just redundant.)
1. I cannot put just anything there. My LDAP says reject_sender_login_mismatch so it is not projected to postfix conf, because the templete checks for reject_authenticated_sender_login_mismatch
That's right. You can only use something if that attribute exists or supported by LDAP.
Let's dig more.
@vladki try this command :
#this means account@domain is allowed to send with this from zmprov ma account@domain zimbraAllowFromAddress 'other@domain' #zimbraAllowFromAddress is a multi key value to add more you need to use +zimbraAllowFromAddress
@vladki try this command :
#this means account@domain is allowed to send with this from zmprov ma account@domain zimbraAllowFromAddress 'other@domain' #zimbraAllowFromAddress is a multi key value to add more you need to use +zimbraAllowFromAddress
That fails with error: ERROR: service.INVALID_REQUEST (invalid request: zimbraAllowFromAddress may not contain an internal account: other@domain).
That's right. You can only use something if that attribute exists or supported by LDAP.
Not only the attribute must exist in LDAP. Also the value of the attribute must be set to something already expected by the templates. And in this case the reject_sender_login_mismatch is set always, without regard to anything in LDAP.