search

mailcow / mailcow-dockerized

mailcow: dockerized - 🐮 + 🐋 = 💕
https://mailcow.email
GNU General Public License v3.0
8.64k stars 1.16k forks source link

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

Open ceskyDJ opened 2 weeks ago

ceskyDJ commented 2 weeks ago

Contribution guidelines

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

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 commented 2 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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.