SOGo save icon greyed out and cannot be used when adding a email forward (same issue as #3625)

[beckzg]

Prior to placing the issue, please check following: (fill out each checkbox with an X once done)

• I understand that not following or deleting the below instructions will result in immediate closure and/or deletion of my issue.
• I have understood that this bug report is dedicated for bugs, and not for support-related inquiries.
• I have understood that answers are voluntary and community-driven, and not commercial support.
• I have verified that my issue has not been already answered in the past. I also checked previous issues.

Summary

Today we updated our mailcow and since the update, the Forwarding preferences in the SOGo can not be saved, the save button is greyed out.

Logs

In the browsers web development tools I see the following error:
Failed to load resource: the server responded with a status of 404 ()
https://<mailcow server>/SOGo/so/<account>/activeExternalSieveScripts

Reproduction

Tried to restart the SOGo image, the whole mailcow and the VM too. Tried to remove the data from the corresponding sogo.sieve file.

System information

Question	Answer
My operating system	Ubuntu 20.04.3 LTS
Is Apparmor, SELinux or similar active?	No
Virtualization technlogy (KVM, VMware, Xen, etc - LXC and OpenVZ are not supported	KVM
Server/VM specifications (Memory, CPU Cores)	4vCPU and 16GB RAM
Docker Version (docker version)	20.10.11
Docker-Compose Version (docker-compose version)	1.29.2
Reverse proxy (custom solution)	HAProxy

• Output of git diff origin/master, any other changes to the code? If so, please post them.
• All third-party firewalls and custom iptables rules are unsupported. Please check the Docker docs about how to use Docker with your own ruleset. Nevertheless, iptabels output can help us to help you: iptables -L -vn, ip6tables -L -vn, iptables -L -vn -t nat and ip6tables -L -vn -t nat.
• DNS problems? Please run docker exec -it $(docker ps -qf name=acme-mailcow) dig +short stackoverflow.com @172.22.1.254 (set the IP accordingly, if you changed the internal mailcow network) and post the output.

diff --git a/data/conf/postfix/main.cf b/data/conf/postfix/main.cf
index a445b60c..0622cc12 100644
--- a/data/conf/postfix/main.cf
+++ b/data/conf/postfix/main.cf
@@ -198,3 +198,6 @@ parent_domain_matches_subdomains = debug_peer_list,fast_flush_domains,mynetworks

DO NOT EDIT ANYTHING BELOW

User overrides

+myhostname = mx.mailocal.com
+#sender_dependent_relayhost_maps = pcre:/opt/postfix/conf/relay_mandrill.pcre
diff --git a/data/web/lang/lang.ru.json b/data/web/lang/lang.ru.json
index 9310e276..cfa7f5de 100644
--- a/data/web/lang/lang.ru.json
+++ b/data/web/lang/lang.ru.json
@@ -105,7 +105,13 @@
"timeout2": "Тайм-аут для подключения к локальному хосту",
"username": "Имя пользователя",
"validate": "Проверить",

•    "validation_success": "Проверка прошла успешно"
  

•    "validation_success": "Проверка прошла успешно",
  

•    "xmpp": "Активировать XMPP для этого домена",
  

•    "xmpp_access": "Пользователь XMPP",
  

•    "xmpp_access_info": "XMPP должен быть включен для этого домена.",
  

•    "xmpp_admin": "Администратор XMPP",
  

•    "xmpp_admin_info": "Повысить пользователя XMPP до <span class=\"text-danger\">администратора домена</span>.",
  

•    "xmpp_info": "Эта опция добавит функциональность чата для этого домена."
  

  },
  "admin": {
  "access": "Настройки доступа",

docker exec -it $(docker ps -qf name=acme-mailcow) dig +short stackoverflow.com @172.22.1.254
151.101.129.69
151.101.1.69
151.101.65.69
151.101.193.69

[beckzg]

I opened a case at SOGO, they just answered that it is already resolved in the nightly build: https://www.sogo.nu/bugs/view.php?id=5444

[MAGICCC]

In the meantime you can also rebuilt the image locally :)

[DerLinkman]

Yeah, i think that isn´t working either. I`ve build the image but the error still exists.
Can anyone proof that?

[andryyy]

Did you press TAB after entering the address? Or enter?

[DerLinkman]

Both actually. But did it matter? If so, since when 😄

[Shargann]

Can confirm - I have identical problem on couple of Mailcow instances I manage. TAB/enter/clicking outside text field don't work.

[MAGICCC]

Strange..
I rebuilt 3 days ago and works fine.
I enter an email and hit enter and the save icon turns green

[Shargann]

In my cases it's only happening on accounts that haven't had redirections configured before. Changing/adding/turning on and off redirections on accounts that have them configured works just fine.

[MAGICCC]

Hm ok, which version are you on after you rebuilt the image?
I am currently on version 5.3.0 (build @shiva2.inverse 202112120603) (You can use something like docker-compose logs sogo-mailcow | grep "version")

[Shargann]

sogo-mailcow_1 | Dec 15 10:25:35 d3a4787552e2 sogod [9]: version 5.3.0 (build @shiva2.inverse 202112120603) -- starting
Also, I noticed that in my cases it's 500 error not 404 on https://mailcow server/SOGo/so/account/activeExternalSieveScripts

[DerLinkman]

Ok guys, another strange behaviour:
sogo-mailcow_1 | Dec 16 09:44:54 e64dedfd9a5e sogod [80]: <0x0x5607fbaed960[SOGoSieveManager]> Could not login 'servercow@mail.domain' on Sieve server: <0x0x5607fb73d600[NGSieveClient]: socket=<NGActiveSocket[0x0x5607fbbf9820]: mode=rw address=<0x0x5607fbbf9890[NGInternetSocketAddress]: host=e64dedfd9a5e port=51684> connectedTo=<0x0x5607fbc78980[NGInternetSocketAddress]: host=dovecot port=4190>>>: {RawResponse = "{ok = 0; reason = \"Authentication failed.\"; }"; result = 0; }

In this case the SOGo save button is actually clickable but came with the 500 error from above.

[MAGICCC]

As seen in Telegram @dragoangel and me dont have this problem and I have no idea which difference our mailboxes can have

[DerLinkman]

Ok guys, another strange behaviour: sogo-mailcow_1 | Dec 16 09:44:54 e64dedfd9a5e sogod [80]: <0x0x5607fbaed960[SOGoSieveManager]> Could not login 'servercow@mail.domain' on Sieve server: <0x0x5607fb73d600[NGSieveClient]: socket=<NGActiveSocket[0x0x5607fbbf9820]: mode=rw address=<0x0x5607fbbf9890[NGInternetSocketAddress]: host=e64dedfd9a5e port=51684> connectedTo=<0x0x5607fbc78980[NGInternetSocketAddress]: host=dovecot port=4190>>>: {RawResponse = "{ok = 0; reason = \"Authentication failed.\"; }"; result = 0; }

In this case the SOGo save button is actually clickable but came with the 500 error from above.

To be clear (i forgot that) i´ll downgraded the SOGo container (to 5.2.0) to check if this issue is a SOGo one or not.

[pantunes87]

Hi,

I have the version 5.3.0 and I'm facing the same issue.

[pantunes87]

In the console log (browser), I can see this:

angular.js:13692 GET https://webmail.domain.com/SOGo/so/user@domain.com/activeExternalSieveScripts 500
(anonymous) @ angular.js:13692
s @ angular.js:13418
(anonymous) @ angular.js:13159
(anonymous) @ angular.js:18075
$digest @ angular.js:19242
$apply @ angular.js:19630
(anonymous) @ angular.js:1966
invoke @ angular.js:5208
c @ angular.js:1964
Wc @ angular.js:1984
Ee @ angular.js:1869
(anonymous) @ angular.js:36595
b @ angular.js:3587

[Shargann]

I've checked SoGo container logs, and when browser gets 500 on activeExternalSieveScripts, SoGo logs:
Dec 17 13:58:56 38fcca4e5bcc sogod [75]: <0x0x5594064038c0[SOGoSieveManager]> Could not login 'asdfgh@domain.xyz' on Sieve server: <0x0x55940621d920[NGSieveClient]: socket=<NGActiveSocket[0x0x5594063c9fe0]: mode=rw address=<0x0x5594062c0210[NGInternetSocketAddress]: host=38fcca4e5bcc port=37464> connectedTo=<0x0x5594063fe620[NGInternetSocketAddress]: host=dovecot port=4190>>>: {RawResponse = "{ok = 0; reason = \"Authentication failed.\"; }"; result = 0; }

[Shargann]

Ok, next observation - newly created mailboxes does not have "Sieve" as allowed protocol enabled by default. I don't know if it was intentionally changed behavior, but other mailboxes which were created long (and not so long) time ago have Sieve protocol enabled by default (as I didn't changed anything in protocols). This is checked on two independent Mailcow installations.
After enabling Sieve protocol on these new mailboxes, error 500 on activeExternalSieveScripts becomes error 404. SoGO logs this:
Dec 17 14:11:30 38fcca4e5bcc sogod [72]: IP_ADDR "GET /SOGo/so/dcsdscsdc@domain.pl/activeExternalSieveScripts HTTP/1.0" 404 0/0 0.637 - - 0 - 13

[dragoangel]

Ok, next observation - newly created mailboxes does not have "Sieve" as allowed protocol enabled by default. I don't know if it was intentionally changed behavior, but other mailboxes which were created long (and not so long) time ago have Sieve protocol enabled by default (as I didn't changed anything in protocols). This is checked on two independent Mailcow installations.
After enabling Sieve protocol on these new mailboxes, error 500 on activeExternalSieveScripts becomes error 404. SoGO logs this:
Dec 17 14:11:30 38fcca4e5bcc sogod [72]: IP_ADDR "GET /SOGo/so/dcsdscsdc@domain.pl/activeExternalSieveScripts HTTP/1.0" 404 0/0 0.637 - - 0 - 13

This known bug in mailcow at current state

[DerLinkman]

Ok, it seems to be that if you've use the newest container which andryyy built a few hours ago and make sure that sieve is enabled that issue is gone? I tested this in 2 several cases by now and it seems to have worked.

To test that make sure to update the mailcow because sogo is downloading new updates as well.

Then make sure that you've enabled sieve as a used protocol for the affected mailbox.

You should now be able to set the sogo options again.

[Shargann]

I've updated moment ago and for me (after enabling sieve) everything works as it should. Thanks guys!

[pantunes87]

for me too! many thanks :)

[DerLinkman]

Very nice 🙂

I don't know for sure but was this sieve option available all the time? Or was it patched in lately?

Because if so it could be the issue point here.

The sogo issue only affects old mailboxes right?

[Shargann]

For me it affected only mailboxes which have not had forwarding configured before, regardless of fact that sieve protocol was enabled by default (like on old mailboxes) or by hand (on new mailboxes). Only difference was that if sieve was not enabled, I've got error 500, not 404.
On mailboxes which have had forwarding enabled, editing or disabling/enabling forwarding worked fine.

[DerLinkman]

It may close the issue folks, we have to see if it does. It worked for some mailcow support customers at least.

[evilMouse]

Sorry for opening old thread, but it's not clear to me and I couldn't find answer anywhere else: is sieve filter enabled by default for new mailboxes in new versions?

[dragoangel]

@evilMouse yes, it fixed, you can check the ACLs

[evilMouse]

@dragoangel Maybe I wasn't clear enough: I haven't updated yet, so I can't check it on live system :)
Thank you for info.

[dragoangel]

Then I don't understand your complains, sorry.

[evilMouse]

@dragoangel It's not complaint, I just want to keep updates to minimum, so I asked about this issue before update.