Hello, I have a mailcow server (named mailcow) behind a reverse proxy reachable by mail.test.com. Since latest version, when I connect to https://mail.test.com, I get the mailcow login page (which is normal). When I enter the credential, it directs to the same login page with address mailcow.test.com (which of course will not work outside). Before the latest version, it was working perfectly. the maicow.conf is `MAILCOW_HOSTNAME=mailcow.test.com ADDITIONAL_SERVER_NAMES=mail.test.com ` How can I solve this issue ? Thanks.

Assuming mailcow is real name used for server right? Than my guess you will need to falsify your domain on your proxy ``` # Ngnix proxy_redirect https://mailcow.test.com/ https://mail.test.com/; ``` ``` # Apache Header edit Location ^https://mailcow\.test\.com/(.*)$ https://mail.test.com/$1 ``` may work

Hello, Yes the real server name is mailcow but I do not want to create a public dns entry of the server. This is strange as it was working ok before I ,migrated to the latest version.

Well first of all, did you try my suggestion? Second, sorry but i do not understand your setup. So if `mailcow.test.com` should not have public dns than switch your config? ``` MAILCOW_HOSTNAME=mail.test.com ADDITIONAL_SERVER_NAMES=mailcow.test.com ``` my guess is that after this no redirect will be needed,...

Hello, Yes the real server name is mailcow but I do not want to create a public dns entry of the server. This is strange as it was working ok before I ,migrated to the latest version. Whatr is even stranger is that if I modify the name in the url of the login page, it keeps on changing to mailcow.test.com, but once I am logged in SOGO, I can change the url to mail.test.com and it flies normally. any clue ?

Well, MC switched to an SSO type of login. So it uses a single point of authentication, where multiple providers can be used to authenticate, with the goal of authenticating to multiple services at once (SOGo, MC-UI, etc.). So to me it seems logical that they enforce MAILCOW_HOSTNAME as the gateway into MC. If this is a regression for you, it may be worth opening an issue on GitHub to see if the devs view it the same way. In the meantime, why not try my suggestion about your proxy server? I think it could work.

Hello this is weird, I put ``` MAILCOW_HOSTNAME=mail.test.com ADDITIONAL_SERVER_NAMES=mail.test.com ``` in the mailcow.conf file. I restarted the containers, but the login interface still redirects to mailcow.test.com

Well most of things are multi-layered. If you poke into MC inner working you will find that redirect is most-likely stored in oauth_clients mysql table. I would try to check what is there,.. Something like this,... ``` docker compose exec mysql-mailcow mysql -u root mailcow -e "SELECT * FROM oauth_clients;" ``` Do you see your old domain there? Also in slightly similar issue other users find that re-run ./update.sh help them, worth try, should not broke anything,...

updating mailcow didn't solve the issue :( and the command returned an access denied. `root@mailcow:/opt/mailcow-dockerized# docker compose exec mysql-mailcow mysql -u root mailcow -e "SELECT * FROM oauth_clients;" ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: NO)`

Sure, how about to pass some env variable to try to log in? `docker compose exec mysql-mailcow mysql -u${DBUSER} -p${DBPASS} -e`

Thanks, but this doesn't return anything : `root@mailcow:/opt/mailcow-dockerized# docker compose exec mysql-mailcow mysql -u${DBUSER} -p${DBPASS} mailcow -e "SELECT * FROM oauth_clients;" root@mailcow:/opt/mailcow-dockerized# `

latest version changes webmail login url

lthiry

Well
Caddy is working perfectly on other services, and was working ok before the latest mailcow version.
The problem occurs at the login page. This page is perfectly displayed, but when entering the credentials, it wants to forward to the server real name instead of the public name.
And as the real server name is not known on the internet, it fails.
If you correct the wrong name by the public name, it will work.

« Previous Page