There are still places, where SOGo appears in UI despite being disabled

[ceskyDJ]

Contribution guidelines

• I've read the contribution guidelines and wholeheartedly agree

I've found a bug and checked that ...

• ... I understand that not following 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.

Description

There are still some places, where are SOGo items despite the fact that SOGo was disabled in configuration:

# Skip SOGo: Will disable SOGo integration and therefore webmail, DAV protocols and ActiveSync support (experimental, unsupported, not fully implemented) - y/n

SKIP_SOGO=y

I now it's "experimental, unsupported, not fully implemented". I just want to provide list of places, where should be made some changes in a future.

Logs:

sogo-mailcow-1  | SKIP_SOGO=y, skipping SOGo...
sogo-mailcow-1  | SKIP_SOGO=y, skipping SOGo...

Steps to reproduce:

Autoconfiguration XML

URI: /mail/config-v1.1.xml (URL: https://${MAILCOW_HOSTNAME}/mail/config-v1.1.xml)
Current content:

<clientConfig version="1.1">
  <emailProvider id="natasha.ceskydj.cz">
    <!-- ... -->
  </emailProvider>
  <webMail>
    <loginPage url="https://${MAILCOW_HOSTNAME}/SOGo/"/>
  </webMail>
</clientConfig>

Here should be no <webMail> element or its content should be configurable e.g. from System --> Configuration --> Options --> Customize --> App links.

App links

1. Go to System --> Configuration --> Options --> Customize --> App links.
2. See locked SOGo app link here: https://tinyurl.com/26ocmgrp

This can be fixed manually by putting this into data/web/inc/vars.local.inc.php but it's more a workaround than real fix:

<?php

// mailcow Apps - buttons on login screen
$MAILCOW_APPS = [];

Restart SOGo

1. Go to (it's in menu, so don't open click on anything, when the menu opens): E-Mail (main horizontal menu)
2. See item (the last one): "Restart SOGo" (opens modal when clicking on it just like if SOGo is enabled). You can see it here: https://tinyurl.com/277wecry

Logs

1. Go to System --> Information --> Logs --> SOGo: https://tinyurl.com/2a2vyv7z

Container information

Go to System --> Information --> System & Containers --> Container information.

I completely understand it's better to run "empty"/"does nothing" container because of dependencies, etc. I don't see any advantage of displaying the container between others in Container information section. I have these reasons for it:

1. I don't care about the container at all since I don't use features it provides. For case of debugging it is still available via docker compose stats --all sogo-mailcow. Generally I don't need to see it on dashboard, where I have other containers I need to care about
2. It may be confusing to see it there for newbies (they need to read more about it and understand why it's running even though they disabled it in configuration)
3. There are so much contains, so it's hard to navigate/orient between them, so every other container does it worse: https://tinyurl.com/2c6psans

Reset SOGo profile

1. Go to E-Mail --> Configuration --> Mailboxes --> Mailboxes --> Add mailbox --> ACL
2. See unapplicable ACL item "Reset SOGo profile": https://tinyurl.com/2d5p4flh

Similar situation is in other ACL selects (in E-Mail --> Configuration --> Mailboxes --> Templates --> Add template, E-Mail --> Configuration --> Mailboxes --> Templates --> Edit --> ACL and E-Mail --> Configuration --> Mailboxes --> Mailboxes --> Edit --> ACL (Permission) --> ACL).

Which branch are you using?

master

Which architecture are you using?

x86

Operating System:

Debian 12

Server/VM specifications:

8 GiB RAM, 4 vCPU

Is Apparmor, SELinux or similar active?

no

Virtualization technology:

KVM

Docker version:

26.1.4

docker-compose version or docker compose version:

v2.27.1

mailcow version:

2024-08a

Reverse proxy:

Caddy

Logs of git diff:

diff --git a/data/conf/postfix/main.cf b/data/conf/postfix/main.cf
index 6a87f2ec..fd4a0765 100644
--- a/data/conf/postfix/main.cf
+++ b/data/conf/postfix/main.cf
@@ -173,3 +173,36 @@ parent_domain_matches_subdomains = debug_peer_list,fast_flush_domains,mynetworks
 
 # DO NOT EDIT ANYTHING BELOW #
 # Overrides #
+
+postscreen_dnsbl_sites = wl.mailspike.net=127.0.0.[18;19;20]*-2
+  hostkarma.junkemailfilter.com=127.0.0.1*-2
+  list.dnswl.org=127.0.[0..255].0*-2
+  list.dnswl.org=127.0.[0..255].1*-4
+  list.dnswl.org=127.0.[0..255].2*-6
+  list.dnswl.org=127.0.[0..255].3*-8
+  ix.dnsbl.manitu.net*2
+  bl.spamcop.net*2
+  bl.suomispam.net*2
+  hostkarma.junkemailfilter.com=127.0.0.2*3
+  hostkarma.junkemailfilter.com=127.0.0.4*2
+  hostkarma.junkemailfilter.com=127.0.1.2*1
+  backscatter.spameatingmonkey.net*2
+  bl.ipv6.spameatingmonkey.net*2
+  bl.spameatingmonkey.net*2
+  b.barracudacentral.org=127.0.0.2*7
+  bl.mailspike.net=127.0.0.2*5
+  bl.mailspike.net=127.0.0.[10;11;12]*4
+  dnsbl.sorbs.net=127.0.0.10*8
+  dnsbl.sorbs.net=127.0.0.5*6
+  dnsbl.sorbs.net=127.0.0.7*3
+  dnsbl.sorbs.net=127.0.0.8*2
+  dnsbl.sorbs.net=127.0.0.6*2
+  dnsbl.sorbs.net=127.0.0.9*2
+  zen.spamhaus.org=127.0.0.[10;11]*8
+  zen.spamhaus.org=127.0.0.[4..7]*6
+  zen.spamhaus.org=127.0.0.3*4
+  zen.spamhaus.org=127.0.0.2*3
+
+# User Overrides
+myhostname = natasha.ceskydj.cz
+
diff --git a/docker-compose.yml b/docker-compose.yml
index cf0a028f..16789083 100644
--- a/docker-compose.yml
+++ b/docker-compose.yml
@@ -613,36 +613,6 @@ services:
           aliases:
             - ofelia
 
-    ipv6nat-mailcow:
-      depends_on:
-        - unbound-mailcow
-        - mysql-mailcow
-        - redis-mailcow
-        - clamd-mailcow
-        - rspamd-mailcow
-        - php-fpm-mailcow
-        - sogo-mailcow
-        - dovecot-mailcow
-        - postfix-mailcow
-        - memcached-mailcow
-        - nginx-mailcow
-        - acme-mailcow
-        - netfilter-mailcow
-        - watchdog-mailcow
-        - dockerapi-mailcow
-        - solr-mailcow
-      environment:
-        - TZ=${TZ}
-      image: robbertkl/ipv6nat
-      security_opt:
-        - label=disable
-      restart: always
-      privileged: true
-      network_mode: "host"
-      volumes:
-        - /var/run/docker.sock:/var/run/docker.sock:ro
-        - /lib/modules:/lib/modules:ro
-
 networks:
   mailcow-network:
     driver: bridge

Logs of iptables -L -vn:

Not related at all

Logs of ip6tables -L -vn:

Not related at all

Logs of iptables -L -vn -t nat:

Not related at all

Logs of ip6tables -L -vn -t nat:

Not related at all

DNS check:

Not related at all

[ceskyDJ]

You have a little broken template for this kind of issue (see history of the initial comment), it may be good to look at it a bit.

[DerLinkman]

Hi,

the option to remove sogo has been added before took over the development of mailcow. I don't see any reason why we should continue on allowing making sogo disabled. If you need it, then mailcow is most likely not the option for you. At least our current point of having sogo on board...

[DerLinkman]

So yeah, we will most likely think about completely removing the option to disable sogo in mailcow as we don't like this anymore. Again, this idea was born before we took over mailcows development.

[ceskyDJ]

Hi,

the option to remove sogo has been added before took over the development of mailcow. I don't see any reason why we should continue on allowing making sogo disabled. If you need it, then mailcow is most likely not the option for you. At least our current point of having sogo on board...

Hmm, it's interesting news but a little too late for me as I've already migrated everything to mailcow and don't have time to migrate somewhere else. It should have been noted (or better alerted) somewhere in docs, that you actually doesn't support future of this use-case any more.

Anyway, mailcow works well for me, at least as far as I can see. I don't know what SOGo will break when you forcedly enable it. I hope it won't break so much stuff. I was looking for ”out of the box“ mailing solution for pretty long time and finally chose mailcow which has everything I need/want from mailing server, nice UI for configuration and good docs that helped me a lot. The only one thing I didn't like on mailcow was SOGo as I'm not a man of this kind of email frontent. I want to have just mails in that frontent and support for multiple accounts at the top of it, so I use Snappymail instead. I don't need CalDAV and CardDAV from my mail server as I don't see these as something the mail server should serve. In my opinion mail server should serve email servers as best as it can. For calendar and contacts, there are different providers. Simply said SOGo would limit me in some key points too much, so I don't want to use it. I hoped I can just turn it off like you say in docs and use Snappymail as email frontent and completely different server for the rest.

I don't have an idea how others see this. Maybe I'm just the single mailcow user wanting to use something else instead of SOGo. But at least for me mailcow is just great piece of software, when you can switch off some parts of it as you can do now. I don't disable anything else but I think there will be some users that need to disable something else for their reasons maybe conceptually a little similar to my use-case.

I'll see how it will work after you take SOGo back and maybe I'll have to migrate but I hope I don't need to as I'm happy to be here for now. Do you have some plan for removing the config option for disabling SOGo, e.g. some expected date(s)?

[DerLinkman]

Hi, thanks for your comment.

It is not decided completely if we want to give users the option to disable sogo completely or not. The reason is, that mailcow relies on sogo in a few parts (Cal/CardDav for example). We need to see what we do in the future.

[ceskyDJ]

Ah, I see. I originally understand you as you've already decided to take off the option to disable SOGo. I'm sorry for my misunderstanding.

I thought about it a bit more. I think I really am a target user of Mailcow (maybe I'm just wrong). I sense mailcow as "out of the box" solution with higher possibilities of configurations, so more suitable for advanced users who just want to delegate the main part of email server maintanance to some 3rd party (I mean you). Why I have this kind of feeling of mailcow? In opposite to e.g. Mail-in-a-Box it has prepared very complex configuration file and I think pretty modular architecture. Documentation of mailcow is full of some ways how to customize or tune up something. I think it's great since for the really basic users (I don't know correct English term but we call them BFU – something like Basic Franta User in English) there is e.g. Mail-in-a-Box which works very differently and architecture is completely different, too (as it works with just one initial script, applies on the host machine, etc.).

About CalDAV/CardDAV. I think there should be an option to disable it (as is now via disabling SOGo). Not everyone has the enterprise usecase, where there is calendard and contacts glued to the user (employee) defined by an email address. I have multiple emails on more domains for different purposes as I'm a self employed software developer and have completely different needings. I think it's not that rare to not need CalDAV/CardDAV at all or just in a completely diferent way than SOGo (as example of enterprise targeted solution) provides.

[SimplyCorbett]

I feel that we need the option to at the least lock down sogo and the entire mailcow UI to specific ip addresses.

You can blacklist/whitelist in the fail2ban section but I believe (have not extensively tested) that this also drops the ip on imap and smtp.

And while you can modify the nginx config to deny all but specific ips and/or use a proxy and do the same it really should be integrated into mailcows UI IMO.

Just my two cents.

[DerLinkman]

I feel that we need the option to at the least lock down sogo and the entire mailcow UI to specific ip addresses.

You can blacklist/whitelist in the fail2ban section but I believe (have not extensively tested) that this also drops the ip on imap and smtp.

And while you can modify the nginx config to deny all but specific ips and/or use a proxy and do the same it really should be integrated into mailcows UI IMO.

Just my two cents.

Feel free to contribute :)

[obrb]

I would like to jump in here and vote for Sogo to remain optional, but not without first thanking everyone for their work and for making it all freely available. 👍

On the topic: I completely understand that Sogo is an integral part of Mailcow, and that you don't want to spend a lot of extra effort to make Sogo disappear completely from the UI or to remove the container from the stack completely, and I can very well live with the way things are now.

However, I would find it quite unfortunate if Sogo were to become a must-have. Why?

1. I don't need a full-fledged groupware, because I host my calendar and contacts on a separate Nextcloud server and it is therefore not worthwhile for me to add an extra 2GB of RAM to my VPS just to be able to run something that I don't actually use.

2. I don't need EAS/Active Sync. IMAP is more than sufficient, and a free standard that works perfectly with FOSS clients like Evolution/Gnome Online Accounts or Thunderbird on the desktop and K9 or Fairmail on mobile. I, at least have never missed an email. ;-)

3. and this is now highly subjective: I don't like Sogo. I don't like its entire UX and UI design at all. For the few occasions when I actually need webmail, I prefer to use Roundcube, where I have integrated my Nextcloud contacts via the CardDAV plugin.

Long story short, I would be very grateful if you could keep Sogo optional if it is feasible with reasonable effort. And again, at least for me, the way it is done now is completely fine.