GermanHi,
is there any way to disable the user-login for the mailcow ui?
For standard, it’s possible to login to the administration-ui with every user account.
I don’t want, that users are able to change password or spam filter settings.
When i login to ui with admin, it’s possible to give the users ACL-Settings.
But there’s no option to forbid password change or whole logon to the ui.
Regards
Didi
I will never understand why the Mailcow developers insist that the admin interface must be the landing page, and why there is no easy way to restrict access to it. They probably just want to push their brand, and by doing so, they hope to gain some more business customers ;-)
However, I don’t think it’s a good idea to forbid users to change their passwords. And honestly, I don’t even want to know the reasons for this request, because they can’t be good either. Much better than forbidding users to change their passwords would be to enforce strong password policies and 2FA. But these are just my 2cents on this topic.
Have something to say?
Join the community by quickly registering to participate in this discussion. We'd like to see you joining our great moo-community!
mlcwuser I will never understand why the Mailcow developers insist that the admin interface must be the landing page, and why there is no easy way to restrict access to it. They probably just want to push their brand, and by doing so, they hope to gain some more business customers ;-)
Yeah… totally…
But what would you “recommend” us to do if the admin page should not be a landing page then?
Tell us and we can discuss about it.
And by the way: The project is completely open source so you can contribute too if you have any ideas and changes which are not only words 
But it’s also possible to forbid password-change via Sogo with:
/opt/mailcow-dockerized/data/conf/sogo/sogo.conf
SOGoPasswordChangeEnabled = YES; —> NO;
So i’m interested to forbid this also in the UI-Interace when logging in there with user account.
mlcwuser I will never understand why the Mailcow developers insist that the admin interface must be the landing page, and why there is no easy way to restrict access to it. They probably just want to push their brand, and by doing so, they hope to gain some more business customers ;-)
Well, you are always free to use something else if you find something better. I didn’t find projects with such a convenient self-made web interface yet.
If I were OP I’d just use a reverse proxy in front of Mailcow. With that you can redirect and restrict stuff however you like. It’s not a one-click-solution, but I don’t expect that from a free product.
First of all, I probably should have worded my post differently. I completely understand why the developers decided to do it that way (there is a longer discussion about it on GitHub), I just don’t necessarily agree with this decision.
Also, I only use Mailcow for personal use, and can very well live with it as it is now. To me it’s just a small imperfection in an otherwise great product.
DerLinkman But what would you “recommend” us to do if the admin page should not be a landing page then?
Tell us and we can discuss about it.
I would prefer if mail.mydomain.tld would land directly on Sogo, or in my case Roundcube and the admin interface would be in a sub directory like e.g. /admin or so. The second best option. would be if both were in separate sub folders, like /admin and /webmail, because then I could easy redirect mail.mydomnain.tld to maildomain.com/webmail.
I know that i could use another subdomain, or I could name my mail server differently, but that’s not ideal either, because ideally the names / URLs for the webmail and for the email clients would be identical. But again, It’s not that big of a deal for me, as it might have sounded in my previous post.
D4niel Well, you are always free to use something else if you find something better. I didn’t find projects with such a convenient self-made web interface yet.
Yes, of course one can do many things, and at the end of the day it is open source, I get it.
DerLinkman And by the way: The project is completely open source so you can contribute too if you have any ideas and changes which are not only words
I have absolutely nothing against the admin interface itself, I actually agree with you, that it is one of the best out there.
But! I don’t think it’s a good fit for a landing page, because let’s face it, you don’t need to change the settings in the Admin UI every day, but might use your webmail every day. Also, most normal users, like e.g. my girlfriend, don’t know what most of the settings are in there, and they have me to configure them ;-) The only thing normal users would looking for, is an option to change their passwords, which is also possible through Sogo or Roundcube. This may of course be diffefrent if you are using Nextcloud to provide hosting services. But even then, in most cases, only the domain admin would use the admin panel, on a daily basis.
mlcwuser This may of course be diffefrent if you are using Nextcloud to provide hosting services.
Sorry, I was a bit in rush and now I cannot edit my post anymore. It should of course read “using Mailcow to provide hosted mail services.” I also mixed up the quotes. Sorry if that caused any confusion
DerLinkman
Btw. A third, and probably the most elegant way would be to use the Mailcow login portal for both, the webmail and the admin panel, preferably with a setting that defaults to webmail. Mailu does it like this: Just to provide an example of what I mean.
dietherr So i’m interested to forbid this also in the UI-Interace when logging in there with user account.
Maybe you can open a feature request on Github, if there isn’t already one…
I just wanted to express my alignment with mlcwuser’s view, that it would be much more “comfortable” if the main panel would be hidden behind a url, instead of acting as the main page. It would by just fine, if SOGo would be the main page.
This way it would be possible to add additional custom security layers on top of the admin panel url, which in the current scenario is rather impossible without some weird server configuration gymnastics.
As written before, you can do that with a reverse proxy in front. Its not rocket science. However I do not see a big problem.
Give out to the users “webmail.domain.tld” that redirects them via e.g. nginx to mail.domain.tld/SOGo. Its easier to remember, too.
I have no problem with my users seeing and using mailcow ui.
I guess the password change and 2FA setup feature is not a bad thing security wise…
esackbauer
I don’t agree that a proxy is solving the issue - the panel is still accessible through the host root. This is a matter of Security through obscurity. The host root should not be a gateway to the mail server in my opinion.
It makes only sense, if the server is dedicated to the mail server (which, yes, I know, is best practice). But not everyone wants/needs to invest into two servers. And in those scenarios, the current solution is not ideal.
blaubit_cpt
Once again, you can have a reverse proxy which asks for credentials (which must not be the ones of mailcow) even before the login page of mailcow is seen.
Hiding the mailcow UI behind a different admin panel url is BTW also security by obscurity…
Dear all,
just my 5 cents to the topic. From paperless, Vaultwarden and nextcloud I am used to disable the login form for the Admin subsite - If the Admin user has setup a passkey.
Would that be a good compromise?
I can understand both sides and I am of the opinion as well that the admin and domain admin subsites must be public available.
Best,
Daniel
daniel-san05 I can understand both sides and I am of the opinion as well that the admin and domain admin subsites must be public available.
Well, that depends, of course. If Mailcow is running on a VPS and you’re administering it from a dynamic IP—which is probably the case for most home and SMB users—then it’s difficult to restrict access to certain IPs only. However, for larger organizations that host it on-premises, it might make sense to restrict access to the admin interfaces to local IP ranges or even a dedicated local management subnet.
Also, things have changed quite a bit in the meantime. Now, the user login and the two admin logins are actually in separate subdirectories of the URL.
This means it’s now possible to restrict access to /admin and/or /domainadmin on the web server or reverse proxy while leaving the normal user login wide open. Of course, ultimately, all three login forms are served by the same backend and middleware, but that’s no different with Nextcloud and Paperless. In fact, those two don’t even have separate URLs or login forms for users and admins.
