Mailcow-dockerized: Have SOGo as root and admin panel under /admin

[mwent-cray]

As title states, swap SOGo and Admin panel around.
That way you can get:
mail. => SOGo webmail
mail./admin => mailcow admin panel
Would be convenient to but the admin panel behind basic auth

[PhoenixPeca]

Hi @mwent-cray,

you can achieve this by setting up mailcow-dockerized behind an aliased reverse proxy via nginx/apache. You may want to take a look at this in the docs. But instead of setting it the standard way, you will do it like this:
Example for Apache2:
```

[. . .]
RewriteEngine on
# Create reverse proxies via RewriteRule with the 'P' flag.
RewriteRule ^/admin/(.*)$ http://127.0.0.1:8080/$1 [P]

[. . .]
# This links '/*' (anything not handled above) to SOGo.
ProxyPass / http://127.0.0.1:8080/SOGo/
ProxyPassReverse / http://127.0.0.1:8080/SOGo/
[. . .]

````
Now you get the point, I'll give the chance to let you find a configuration for NGINX.

As for setting up a basic auth, I really do not recommend setting up one because this prevents non-admin users who wants to change his/her mailcow settings via admin panel. Instead, I recommend you to utilize the built-in 2 factor authentication for mailcow.

I'm closing this for now, don't hesitate to reply back and I would be happy to reopen this for you. 😉

[mwent-cray]

@PhoenixPeca Thank you for the explanation. I tried this actually before opening a ticket. (Using Nginx) But was unsuccessful. Any idea?

[PhoenixPeca]

Sorry, I can't help you with NGINX, I am currently using apache. Actually, I am doing it right now in my production server but only with apache. and I have no time to test a configuration for nginx. 😭 I'm really sorry for that.

Update

However, I think this might work for you: https://serverfault.com/questions/650117/serving-multiple-proxy-endpoints-under-location-in-nginx
I can't test it though

[Dunky13]

It would be nice if the issue can stay open - if anyone finds a solution for this.

[axd]

Hi everyone, I'll post in this issue for convenience.

I've been trying to make it work this thing out but, it was not possible because of SOGo, it shows "normal" but I couldn't login with any user, I just made that "admin" works fine.

I'm sharing my nginx conf file but it looks pretty dirty, if someone could help us to clarify how to achieve this, maybe @andryyy?

Also I've been thinking that the references to the files for the admin (css/js/img) should be relative and not absolute, because I had to add a location for each one.

server {
    listen 80;
    server_name mail.domain.com autodiscover.domain.com autoconfig.domain.com;

    return 301 https://$host$request_uri;
}

server {
    server_name mail.domain.com autodiscover.domain.com autoconfig.domain.com;
    listen 443 ssl;

    ssl_certificate /etc/letsencrypt/live/mail.domain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/mail.domain.com/privkey.pem;

    location /css {
        proxy_pass http://127.0.0.1:8080/css/;
        proxy_set_header Host $http_host;
    }

    location /js {
        proxy_pass http://127.0.0.1:8080/js/;
        proxy_set_header Host $http_host;
    }

    location /img {
        proxy_pass http://127.0.0.1:8080/img/;
        proxy_set_header Host $http_host;
    }

    location /inc {
        proxy_pass http://127.0.0.1:8080/inc/;
        proxy_set_header Host $http_host;
    }

    location /fonts {
        proxy_pass http://127.0.0.1:8080/fonts/;
        proxy_set_header Host $http_host;
    }

    location ^~ /admin/ {
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        client_max_body_size 100m;

        proxy_pass http://127.0.0.1:8080/;
    }

    location ~ \.php {
        return 301 https://$host/admin/$request_uri;
    }

    location ^~ /api/v1/ {
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        client_max_body_size 100m;

        proxy_pass http://127.0.0.1:8080/api/v1/;
    }

    location /SOGo.woa/WebServerResources/ {
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        client_max_body_size 100m;

        proxy_pass http://127.0.0.1:8080/SOGo/WebServerResources/;
    }

    location /.woa/WebServerResources/ {
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        client_max_body_size 100m;

        proxy_pass http://127.0.0.1:8080/SOGo/WebServerResources/;
    }

    location /SOGo/WebServerResources/ {
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        client_max_body_size 100m;

        proxy_pass http://127.0.0.1:8080/SOGo/WebServerResources/;
    }

    location (^/SOGo/so/ControlPanel/Products/[^/]*UI/Resources/.*\.(jpg|png|gif|css|js)$ {
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        client_max_body_size 100m;

        proxy_pass http://127.0.0.1:8080/SOGo/$1.SOGo/Resources/$2;
    }


    location /rspamd/ {
        proxy_pass http://127.0.0.1:8080/rspamd/;
        proxy_set_header Host $http_host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_redirect off;
    }

    location /Autodiscover/Autodiscover.xml {
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        client_max_body_size 100m;

        proxy_pass http://127.0.0.1:8080/SOGo/Autodiscover/Autodiscover.xml;
    }

    location ~ /(?:m|M)ail/(?:c|C)onfig-v1.1.xml {
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        rewrite /(?:m|M)ail/(?:c|C)onfig-v1.1.xml /$1 break;

        proxy_pass http://127.0.0.1:8080;
    }

    location ^~ /Microsoft-Server-ActiveSync {
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        client_max_body_size 100m;

        proxy_pass http://127.0.0.1:8080/SOGo/Microsoft-Server-ActiveSync;
    }

    location / {
        return 301 https://$host/SOGo/$request_uri;
    }

    location / {
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
        proxy_set_header x-webobjects-server-protocol HTTP/1.0;
        proxy_set_header x-webobjects-remote-host $remote_addr;
        proxy_set_header x-webobjects-server-name $server_name;
        proxy_set_header x-webobjects-server-url https://$http_host;
        proxy_set_header x-webobjects-server-port $server_port;
        client_body_buffer_size 128k;
        client_max_body_size 100m;

        proxy_pass http://127.0.0.1:8080;
        break;
    }
}

[nickian]

Can someone who has successfully set this up on Apache post a complete example? Nothing I've seen here works, neither does the example here: https://mailcow.github.io/mailcow-dockerized-docs/firststeps-rp/

When I use the code below, the proxy works, but it doesn't point to SOGo, it just goes to the admin login. And https does not work. It says invalid certificate because it's trying to use the certificate for the domain in the Docker nginx config for some reason.

<VirtualHost *:443>

    ServerName webmail.domain.com
    ServerAlias webmail.domain.com

    # You should proxy to a plain HTTP session to offload SSL processing
    ProxyPass / http://127.0.0.1:8080/SOGo
    ProxyPassReverse / http://127.0.0.1:8080/SOGo

    ProxyPreserveHost On
    ProxyAddHeaders On

    # This header does not need to be set when using http
    RequestHeader set X-Forwarded-Proto "https"

    # If you plan to proxy to a HTTPS host:
    SSLProxyEngine On

    SSLEngine on
    SSLCertificateFile /home/user/ssl/certificate.crt
    SSLCertificateKeyFile /home/user/ssl/key.key
    SSLCertificateChainFile /home/user/ssl/chain.crt

</VirtualHost>

# PORT FORWARD FROM 80 TO: 443
<virtualhost *:80>
    ServerName webmail.domain.com
    ServerAlias webmail.domain.com
    ServerAdmin webmaster@localhost
    RewriteEngine on
    ReWriteCond %{SERVER_PORT} !^443$
    RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [NC,R,L] 
</virtualhost>

[reinistihovs]

add this in mailcow-dockerized/data/web/index.php
after "

if ($_SERVER['REMOTE_ADDR'] != "Your.Public.IP.Address"){
header("Location: ./SOGo/");
exit();
}

This way everyone except Administrators IP will be redirected to SOGo and wont have access to the admin panel at all, and for user password change you can enable it in /mailcow-dockerized/data/conf/sogo/sogo.conf
by setting SOGoPasswordChangeEnabled = yes; ( restart SOGo afterwards)

[sammdu]

Here's my attempt:

My attempt is done using the nginx server, conditions are going to be different if you use another server such as apache.

Within mailcow.conf I changed the port binding of mailcow from 80/443 to 10080/10443, so I can use nginx as a reverse proxy, to direct https://mail.my.email/admin traffic to https://127.0.0.1:10443, (the same applies to directing https://mail.my.email to https://127.0.0.1:10443/SOGo)
Here's my nginx configuration, referencing this mailcow doc:

location /admin {
        proxy_pass https://127.0.0.1:10443/;
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        client_max_body_size 100m;
}

Unfortunately as I later found out, the entire Mailcow admin portal uses _absolute path_ for all the resources (incl. images, css, javascript, etc), thus the html page loaded fine but all the images and page layout are unable to load because they're trying for the files at, for example, https://mail.my.email/style.css when in fact the file is located at https://mail.my.email/admin/style.css

So okay, I thought to myself, I'll just redirect all my root traffic (https://mail.my.email/) to /admin by adding a redirect function in the root block, within the nginx configuration file. Here's what I added:

location / {
    return    301 https://$server_name/admin/$request_uri;
}

Now the /admin page loaded fine, but accessing root (https://mail.my.email) will also be redirected to /admin, not good for security (as it exposes the admin portal to the public), and eliminating the possibility for redirecting root traffic (https://mail.my.email) to the SOGo interface as described above.

---

Possible solutions I came up with:

1. Change all the url's in the admin portal to relative path (e.g. ./js/main.js instead of /js/main.js, dot-slash instead of slash)
   However this is going to be a dirty task since there's going to be countless url's and resources within the portal, and it's never gonna be an easy task to replace each and every one of them.
2. Work out the portal the same way SOGo and other plugins have. However I'm not familiar with the project and don't really know the mechanism powering this functionality, so I have no way to know whether it's possible or not. This would then have to be left for the amazing devs maintaining this project, @andryyy @xervia

---

Hope this problem gets addressed soon, and please follow up if you have better solutions! Thanks very much!

[sammdu]

Oh sorry I did not read @axd 's post in detail, turns out he created a more sophisticated config to address the problem on the nginx side.
Well then I guess that'll serve as the make shift solution, but still would be nice if mailcow has more solid support for url configuration.
However, webmail is still a problem since certain directories are being redirected from root it might result in conflict with SOGo or other (I plan to use rainloop) webmail's directories.

[mkuron]

Unfortunately, there is only so much configurability a one-size-fits-all solution like Mailcow can offer. If you want any more sophisticated URL routing, you'll need to put a reverse proxy in front of it or edit the Nginx config as suggested above. You can post a pull request against the docs repo to explain how to make these modifications.

I think the only compromise we could make is to move the Mailcow admin interface to /admin and make it configurable whether / redirects to /admin/ or to /SOGo/ (that redirect could be done in PHP, so the setting could be stored in the database). That would also require fixing all the absolute links.

[sammdu]

Yeah that will be acceptable. I can live with reverse-proxy'ing, just the absolute links will be a pain, and has to be fixed.
Currently I'll just comment out the admin portal since I'm not gonna use it regularly, so I can have webmail at the root; if I want to use the portal I'll just comment out the webmail section and uncomment the admin routing.
That'll be semi-good-enough for a personal email server, since I don't have to worry about user experience / uptime for anyone else, but if anyone wants to use it as a small gruop/organization mail server the links has to be fixed.

[cubefoo]

why would anyone want their members facing the admin login by default?
imho even if you are the only user it doesn't make sense
is this going to be fixed soon?

[andryyy]

Because mailcow UI is for users and admins.

[nickian]

The URL should just be changed to something generic like /webmail or /mail instead of /SOGo.

[cubefoo]

true
using the slug /SOGo is very unfortunate if you value a clean url appearance
it would be great if we had the option to modify this slug (or move SOGo to root)

[asifbacchus]

In case anyone finds this discussion like I did (top google result), I came up with a pretty simple way to get this done using the documentation as a base and setting up a reverse proxy using nginx on the host system. The root of the domain will go to SOGo and /admin will go to mailcow. Everything else seems to work just fine. My nginx.conf is here, SSL settings here and the actual site configuration is here. Sorry, I like doing things in different files/modules. I'm just learning so please comment on my gists and let me know if you find stuff not working or if you have suggestions!

[lajosbencz]

Serving the admin page (mailcow ui) instead of the webmail page (sogo) seems counter-intuitive.

In 99% of the cases, the user will want to access his/her mails, not change the timezone if the profile.
It would be much easier if the root served sogo by default. Or at least have mailcow ui served under /admin by default, and allow the index to be configured.

[kukukk]

Hi,

As an alternate solution it is possible to use 2 subdomains:

• mail.example.com => /
• webmail.example.com => / with redirect to /SOGo/

To redirect to /SOGo/ I use the following config options for Apache

RewriteEngine on
RewriteCond %{REQUEST_URI} !^/SOGo
RewriteRule ^(.*?)/? /SOGo/$1 [R=301]

This way I can use mail.example.com as the imap/smtp/exchange server address and to access the admin panel, while the webmail can be accessed via https://webmail.example.com.

But yes, +1 for having SOGo as root and the admin panel on /admin.

[rmobis]

@mkuron

I think the only compromise we could make is to move the Mailcow admin interface to /admin and make it configurable whether / redirects to /admin/ or to /SOGo/ (that redirect could be done in PHP, so the setting could be stored in the database). That would also require fixing all the absolute links.

@andryyy @PhoenixPeca @mkuron would you be willing to accept a PR that implements this?

[ashiq54689]

Instruction from @asifbacchus worked for me. / now redirects to /SOGo/. However, I actually want to change /SOGo/ to something else, for example /mailapp/. And once user login to webmail, the link they will see is, domain/mailapp/so/username@domain/Mail/view#!/Mail/0/INBOX. Is there any way to achieve that?

[asifbacchus]

@Angel54689
I'm glad that reverse proxy setup worked for you!

Regarding your other question: I cannot think of a way to do what you want without getting into a 'too many redirects' situation which would prevent the browser from displaying the page. More importantly, and perhaps someone can correct me on this if I'm wrong, I'm almost positive that SOGo internally sends redirects to the browser with its root URL (/SOGo) so unless you edit the templates in the SOGo source code, I do not think you can change /SOGo to anything else.

Sorry for not having better news... I'll tinker with this for you, but I'm pretty sure what you want cannot be (easily) accomplished. Is there any reason you're trying to change the displayed URL?

[ashiq54689]

@asifbacchus You are right, I am getting too many redirects. And, yes, SOGo internally sends redirects to the browser with /SOGo. I was trying different methods for the last few hours. I have even tried URL masking, configured another proxy using another domain. Ultimately nothing worked.

I am referencing https://forum.iredmail.org/topic13309-change-sogo-access-url.html, https://lists.inverse.ca/sogo/arc/users/2014-10/msg00229.html, https://lists.inverse.ca/sogo/arc/users/2011-02/msg00444.html,
and finally the bug report https://sogo.nu/bugs/view.php?id=331. In every case, they say, it will work or it's possible, unfortunately, nobody can confirm it.

Thanks for your help, appreciated it.

[asifbacchus]

@Angel54689

The only reference I can find for your situation is here, https://sogo.nu/support/faq/how-to-customize-the-html.html where they discuss changing source templates. I have NOT tried this and haven't researched it, but if you really need a different URL I think it's just about the only place you can start. Good luck :-)

[mseed]

To solve problem with confusing peoples with login dialog I changed login page like this: http://fastlinux.eu/_mailcow/mc01.png http://fastlinux.eu/_mailcow/mc02.png http://fastlinux.eu/_mailcow/mc03.png (Expandable area for login form and separate area for apps).

[ruffy91]

To solve problem with confusing peoples with login dialog I changed login page like this: http://fastlinux.eu/_mailcow/mc01.png http://fastlinux.eu/_mailcow/mc02.png http://fastlinux.eu/_mailcow/mc03.png (Expandable area for login form and separate area for apps).

How did you achieve this?

[andryyy]

mseed has shared this here: https://github.com/mailcow/mailcow-dockerized/pull/2056 :)

[rubinho76]

Hello,
a direct forwarding of the Sogo port 20000 would already help some. You could address the port 20000 directly with an external reverse proxy (Pfsense). As a result, the Admin-Gui is not reachable from the outside.

[thebritt]

In case anyone found this on Google like I did and is interested in a quick workaround to redirect based on URL.

I added the below code to the Mailcow index.php.

If user goes to https://fqdn/ then redirect to /SOGo/.
If user goes to https://fqdn/?admin then do not redirect, load index.php (mailcow admin logon page)

<?php
        if (strpos($_SERVER['REQUEST_URI'], '/?admin') !== false) {
                /*Do nothing if user navigates to URL/?admin (Render the index.php page)*/
        } else {
                /*Add javascript then HTML if this doesn't work*/
                echo "<script type='text/javascript'>window.location.replace('/SOGo/');</script>";
                echo "<meta http-equiv='refresh' content='0;url=/SOGo/'>";

        }
?>

[asifbacchus]

Damn, I need to learn more PHP... nice solution @thebritt :-) You would have to do this after each update though, right?

Anyways, for the same reason as everyone else (the benefit of anyone finding this from a Google search), just thought I'd update the option to have nginx do the redirect for you, assuming you're using it as a reverse proxy as per the setup guide. It's pretty much the same as my previous post, except that redirects to 'admin' cause loops in recent updates so you have to pick a different subdir (I choose 'setup' in my example). So, @thebritt has an excellent solution if you want to keep using 'admin' and/or if you are not using a reverse proxy. If you want to handle it all via nginx, then here's the updated setup I use and hopefully, it'll help someone else too. Just add these two location blocks:

# proxy root to SOGo
location / {
    rewrite ^/$ /SOGo;
    proxy_pass http://127.0.0.1:8080;
}

# proxy /setup to Mailcow Admin Panel (root)
location ^~/setup/ {
    proxy_pass http://127.0.0.1:8080/;
}

HTH.

[Gaddea]

@asifbacchus

Tried for quite some time to have something similar but with Traefik. Any hints hon how to do this?

Thanks.

[asifbacchus]

@asifbacchus

Tried for quite some time to have something similar but with Traefik. Any hints hon how to do this?

Thanks.

@Gaddea
I have never used Traefik but I checked out their documentation and it doesn't seem too difficult to do this.

I would think you'd do something like this:

1. Create a Frontend with a MATCHER rule of something like 'PathStrip: /admin' forwarding to your mailcow backend. This will take "server.tld/admin" and redirect it as just "server.tld" which would bring up the default mailcow admin page.
2. Add an additional rule, this time a MODIFIER something like 'AddPrefix: /SOGo' also for your mailcow backend. This should rewrite "server.tld" to "server.tld/SOGo" and kick you directly to the SOGo page from mailcow.

Based on the documentation, the config would look something like:

[frontends.mailcowFrontend]
backend = "mailcowBackend"
    [frontends.mailcowFrontend.routes.test_1]
    rule = "PathStrip: /admin/"
    [frontends.mailcowFrontend.routes.test_2]
    rule = "AddPrefix: /SOGo/"

Again, this is all based on the documentation. I don't know exactly how the redirects work in Traefik since I've never worked with it and, unfortunately, don't have time at the moment to spin up a virtual environment to test it out. I'm just guessing based on a quick read of the documentation, but maybe this will inspire you along the right path?

Let us know if this works or if this was helpful in finding a solution. Good luck :-)

[joeknock90]

@asifbacchus
This almost works. I understand that you are only going from the docs and I am absoultely no expert, but here's what happens for me. I use a docker-compose.override.yml file to adjust settings for the stack as follows:

docker-compose.override.yml
````
version: "2.1"

services:
nginx-mailcow:
labels:
- "traefik.enable=true"
- "traefik.docker.network=http_network"
- "traefik.admin.frontend.rule=Host: mail.mydomain.com;PathStrip:/admin"
- "traefik.webmail.frontend.rule=Host: mail.mydomain.com;AddPrefix:/SOGo"
- "traefik.autodiscover.frontend.rule=Host:autodiscover.mydomain.com"
- "traefik.autoconfig.frontend.rule=Host:autoconfig.mydomain.com"
networks:
http_network:
rspamd-mailcow:
labels:
- "traefik.rspamd.frontend.rule=Host:mail.mydomain.com;Path:/rspamd"

networks:
http_network:
external: true
````

This DOES move the default interface to mail.mydomain.com/admin,

HOWEVER

while mail.mydomain.com does resolve SOGo (you can see
the title change in the browser to the sogo page) the page does not load.

EDIT: Ok so it seems that in Firefox the page loads but php/css does not.

And logging into the admin functions is unusable.

[asifbacchus]

@joeknock90
I think you need the trailing slash on the AddPrefix -- i.e. /SOGo/
Also, I don't see any mention of you adding any headers to your proxy requests. I don't think authentication and stuff will work without those headers as explained in the [mailcow documentation] (https://mailcow.github.io/mailcow-dockerized-docs/firststeps-rp/)

That's all I can think of right now, but I'll keep mulling it over. Also, any hints in the nginx logs from mailcow? Let me know... I'm kinda interested now since I've never looked at Traefik before but, now I'm interested :-)

[maetthew]

Fwiw I'd just like to chime in and mention that a feature that let me easily configure URL's for the services would be preferable.

I would like to achieve the following URL structure:

https://domain.tld - Nextcloud
https://mail.domain.tld - Webmail client
https://admin.domain.tld - Mailcow UI

[asifbacchus]

Fwiw I'd just like to chime in and mention that a feature that let me easily configure URL's for the services would be preferable.

I would like to achieve the following URL structure:

https://domain.tld - Nextcloud
https://mail.domain.tld - Webmail client
https://admin.domain.tld - Mailcow UI

@maetthew
I think that would be a cool feature, but maybe tough to implement due to the wide variation of people's desired setups? On the other hand, it's super simple with a reverse-proxy sitting in front of your servers. If you need help with such a set-up, feel free to pm me so we don't clutter the thread and I'd be happy to help you out :-)

[joeknock90]

@asifbacchus
Good call on trailing slash on SOGo. It now loads just fine. Unfortunately /admin resolves to the same thing as the the root subdomain. (mail.example.com/admin just goes straight to /SOGo)

Screw all that I'm an idiot who can't type.

So trailing slash does fix SOGo and made it mail.mydomain.com. I am able to log in and manipulate and send email and etc.

The following
- "traefik.admin.frontend.rule=Host: mail.mydomain.com;PathStrip:/admin/"

Does put admin at the correct place but logging just fowards me directly to SOGo.

We are getting pretty close!

Looking into header config now. Thanks!

[asifbacchus]

I was reviewing the documentation and it seems the issue is that that MATCH rules are processed before MODIFIER rules within the same directive. As such, it first matches /admin/ and strips it, reprocesses the request through the _same rules_ but this time matches the stripped domain and adds /SOGo/ as per the rules and voila -- you are forwarded to the SOGo site. This actually happens with NGINX and Apache also, that's why we use two separate proxy directives. Could you not do the same with Traefik? Use two frontends?

Frontend 1 for SOGo:

[frontends.mailcowFrontend]
  backend = "mailcowBackend"
  [frontends.mailcowFrontend.routes.test_1]
    rule = "AddPrefix: /SOGo/"

Frontend for mailcow admin:

[frontends.mailcowAdmin]
  backend = "mailcowBackend"
  [frontends.mailcowAdmin.routes_test_1]
    rule = "PathStrip: /admin/"

I don't know if that kind of setup is viable in Traefik, but it would seem to separate the requests and prevent internal looping? Again, I'm just assuming how Traefik works here. But, this is essentially how NGINX and Apache would handle it, two separate directives. Maybe this could help?

[maetthew]

Fwiw I'd just like to chime in and mention that a feature that let me easily configure URL's for the services would be preferable.
I would like to achieve the following URL structure:
https://domain.tld - Nextcloud
https://mail.domain.tld - Webmail client
https://admin.domain.tld - Mailcow UI

@maetthew
I think that would be a cool feature, but maybe tough to implement due to the wide variation of people's desired setups? On the other hand, it's super simple with a reverse-proxy sitting in front of your servers. If you need help with such a set-up, feel free to pm me so we don't clutter the thread and I'd be happy to help you out :-)

@asifbacchus Yeah idk really but I imagine it wouldn't be that hard to have a section in the Mailcow UI where you can define URL's and then have the backend rewrite the configs for nginx but I've really no clue exactly how hard it would be.

Yeah I'm set on the reverse proxy for the time being, just haven't had the time recently to research enough and I have very limited experience with nginx and none setting up a reverse proxy so I might just take you up on that offer, thanks :)

[infracritical]

I have an idea on something (and forgive me if this may be too overly simplified, or not entirely secured enough)...

As the main website is "http://mailcow" points to the admin page and NOT SOGo, why not do this:

(1) Copy the %MAILCOW_DIR%/data/web/index.php to %MAILCOW_DIR%/data/web/admin.php
(2) Create a new "index.php":

header("Location: "https:mailcow-sogo");
exit();
?>

Am I wrong for thinking this, or is there something more that I'd need to do?

[asifbacchus]

@infracritical you'd have to make sure all the links worked from all modules and would have to repeat this procedure after every update. Something like a reverse proxy or server-side rewrite is more reliable and resilient, IMO.

[infracritical]

Actually, I already figured it out.

https://mailcow.domain -> https://mailcow.domain/SOGo/so/

https://mailcow.domain/alt.php -> https://mailcow.domain/admin/
and by ".../admin/", it's really "https://mailcow.domain/admin.php" rewritten as "https://mailcow.domain/admin/"

This simple workaround works for me.

P.S. I also have https://webmail.mailcow.domain -> https://mailcow.domain/SOGo/so/

NOTE: Within the "/opt/mailcow-containerized/data/web/index.php" file, replace the contents with

header("Location: https://mailcow.domain/SOGo/so/");
exit();
?>

If I do "https://mailcow.domain/alt.php", I get the usual login screen; once logged in, it goes to "https://mailcow.domain/admin/", which is really "https://mailcow.domain/admin.php".

[asifbacchus]

@infracritical I think some of your post got eaten by github somehow? Otherwise, maybe posting what you actually did might help others viewing this in the future - just a suggestion. I do see that you mention replacing the contents of the index.php file -- again, I think you should know that will likely not survive an update so make sure you document your work so you can re-create it! Nice work getting things solved for your situation though :-)

[infracritical]

Alright...here's one possible solution that I've implemented for me, and it works quite simply like this:

(1) Login to your server, and become 'root' (or whatever is the server administrator).
(2) cd /opt/mailcow-dockerized/data/web
(3) mv ./index.php ./index2.php
(4) vi ./index.php; within the new 'index.php', enter the following:

NOTE: The domain name, 'domain.com', is an example; substitute your own domain.

<?php
header("Location: https://domain.com/SOGo/so/");
exit();
?>

(5) Please note that your 'admin' login is still there; it's just that you now need to access it as:
https://domain.com/index2.php
which will now redirect (once logged on) you to https://domain.com/admin.php
(aka 'https://domain.com/admin/').
(6) ...and you're done!

For my needs, this more than satisfies my requires of keeping the administrative properties separated from the webmail software, SOGo. Thought I'd comment here, and see if this helps anyone.

Cheers!

[ravinayag]

In Addition to @infracritical update, you can rename the below-listed files for betterment access from the web.
Here what I did, and it works well and solves my requirement, but not test with all submodules are working. ( 💯 it should work since it gets redirected.) 👍
1) mv admin.php webmail.php
2) mv index2.php admin.php

Note: Don't do this exercise without @infracritical his procedure. else you may end up with some issues due to overwriting of admin.php.

Thanks

[maverick85]

my .02c here

Why is this ticket closed?
This is one of the longest issues I've read through, everybody complaining the same, everybody clearly stating how obvious it is that
(a) /SOGo should be served by default on the fqdn of the server instead of admin,
(b) the /SOGo path is awful and not suited for those who'd just prefer something cleared like "webmail",
(c) there are a number of possible ways of doing this, much have been dissected in this issue. Some much fancier than others,
(d) never the less this is one of the most requested features, with users constantly hitting the wall on this and opening new issues about it;

Yet we stand here now with this issue closed.
I don't really understand why, or if its simple opacity from developers or team members of closing it for the sake of not answering to the community. Either way, the implementation of this out of the box is far due.

[andryyy]

This is neither a ticket (this is not a ticket system!) nor is it "due".

The UI is for users and admins.
SOGo is moreover mostly hardcoded into SOGo.

The UI is a jumping point from / to your user settings, the admin settings, domain admin settings and, well, the webmailer. It is a portal. A portal should be available at /.

If you want to redirect / to /SOGo: do it. There is nothing in this mooniverse holding you back from doing that. :)

You can even create a site "webmail.domain.tld" and redirect it to SOGo. It is part of the docs. Should be the easiest solution.

I do understand that the opinions are rather split about this topic. I stick to my decision. :)

[maverick85]

Well isn't a ticket, but certainly is an issue.
About being due I'm not sure if you've been elected judge (maybe so) :) - it seems to me there's a massive interest in this feature for years.

The UI is for users and admins.

It is indeed. Usually the admin area isn't the splash screen, but rather a specific path.

SOGo is moreover mostly hardcoded into SOGo.

This is a no issue. As mentioned before there are many ways of solving it, from subdomains to alias etc.
The point is having an out-of-the-box solution, and not having the
(a) administration (user&admin alike) area before the mailbox access
(b) to bend over backwards to change something that should already been thought that way

The UI is a jumping point from / to your user settings, the admin settings, domain admin settings and, well, the webmailer. It is a portal. A portal should be available at /.

We completely disagree on "portal" for email. I imagine when you login to yahoo mail, hotmail or any other, your "portal" is different from the rest of the world. While you apparently see all those options, us commoners only see emails and the respective mailboxes (thank god)

If you want to redirect / to /SOGo: do it. There is nothing in this mooniverse holding you back from doing that. :)

You can even create a site "webmail.domain.tld" and redirect it to SOGo. It is part of the docs. Should be the easiest solution.

It's funny you mention this bc before going on google to look for this, I noticed nothing on the documentation refers what you mention here. Would you be so kind to point me (and others) towards the relevant documentation?

[hachre]

I think he was referring to this in the docs:
https://mailcow.github.io/mailcow-dockerized-docs/u_e-webmail-site/

[maverick85]

@hachre thanks a lot! Completely missed it

[nickian]

I have settled for redirecting /webmail to /SOGo (perhaps the worst directory name to try to remember). I just did this by creating /data/web/webmail/index.php that does the redirection.

I have to admit that _every_ user on my server has been confused by the default login screen being for administration settings only. It is demonstrably bad UX, but I understand the technical limitations. Also, most "regular" users simply don't care to mess with their configuration settings.

Thanks for the subdomain info. I'll check that out as well.

[maverick85]

actually that was the easiest most practical solution @nickian
the content of index.php if anyone's interested

<?php
header("Location: ../SOGo/so/");
exit();
?>

But I still defend and stand by this becoming a built-in feature.
The options panel should not be the first page, it is not good UX

[andryyy]

The portal stays at /. :) Sorry, if you don't like this answer.

Don't just give your users an URL. Tell them it is a portal with useful user configuration options AND a jumping point to mail or other apps. Show them, what they can configure.
They can even auto configure their Apple devices from here. They can also find help how to configure their other devices. You can set ACLs if you don't trust your users. You can forbid certain actions.

We will not hide this portal (!) by default.