"Direct SOGo login is now disabled. All unauthenticated requests to /SOGo will be redirected to /. Users must use the mailcow login. Administrators can define whether a user should be redirected to the mailcow UI or SOGo after login." In our IT mailcow is accessable only in LAN or VPN. I don't like my users to login to SOGo via mailcow ui. What are the reasons to change this? Anything technical? Security? Just for fun? Is it possible to change this back?

You should the release notes or the blog at mailcow.email from time to time ;) It is explained, that is required by the change to additional authentication methods. > @"stefan21"#p23264 don’t like my users to login to SOGo via mailcow ui. The only thing that changes is the login screen. Before it was the SOGO login screen, now its the mailcow login screen. What is your problem with that?

> @"esackbauer"#p23266 You should the release notes or the blog at mailcow.email from time to time 😉 It is explained, that is required by the change to additional authentication methods. I took it from there. I hardly see in a company (I wrote already access to mailcow in LAN and with VPN ONLY) the need for additional auth methods. Again - what should that be good for? Just keep it simple. No need at all in a company for additional auth methods. Assuming the IT is secured. No need to present employees anything else as just the SOGo login. Too much options on gui leads to playground.

I actually think this is a huge improvement, even if you don't use additional login methods, because now you can configure it so that users can login to Sogo directly from the Mailcow login page, without having to add /sogo to the domain name, or having to do an extra click on the Sogo button to get to the Sogo login page, which was something many people complained about in the past. Also, users now only have to log in once and, if I understand correctly (I do not use Sogo myself), can then easily switch back and forth between Sogo and the Mailcow UI, which makes things much more intuitive.

> @"stefan21"#p23274 No need at all in a company for additional auth methods. All companies I know have some sort of Active Directory or SSO solution in place which significally enhances security and simplifiny the use of multiple services with the same security policies (password complexity, mover/leaver concept, central 2FA solution etc). mailcow having its own user directory just in its own SQL database with its own 2FA is somewhat frustrating for corporate users. Maybe you are talking about companies with just 10 employees or less?

@"stefan21"#7985 Please read the Docs!

@"stefan21"#p23274 One small addition: As I already mentioned, "normal" users will benefit from the change as well, if they are a bit open-minded and don't reject every change out of principle 😉 But even if they don't, If you think about it for a minute, you might realise that the people who develop the software that you use for free also have to pay for food and rent. And they do this by offering hosted Mailcow instances, where this certainly comnes in handy, and by selling support to companies and organisations where such features are absolutely necessary today for a product to be even considered. And those customers of the hosted Mailcow instances and the organisations who buy support are the ones who make it possible for Mailcow to continue to be developed and maintained and thus for you to continue to use it for free. I think telling your users that the login screen now looks different and that they have to change their bookmarks in their browsers is a price that is just about acceptable to pay, right?

> @"mlcwuser"#p23287 that you use for free also have to pay for food and rent. Come on - how do you know? We pay >1.000 EUR per year just for using mailcow. Since today I never opened a ticket or was asking for help from the devs. I'm doing IT since the 80s. I'm fully capable to judge what I need for my IT, and what I don't need. @"Ganzjahresgriller"#p23279 I read the docs. What are you insinuating? @"esackbauer"#p23278 We have AD. Yes, we are a small company with less than 10 users. We have a hardware FW (OPNsense, very few ports opened), there's a linux fileserver behind, we don't use any kind of cloud, we allow access (remote office, smartphones) only via VPN and LAN. Til today we've never been hacked or randomized. @"mlcwuser"#p23287 IMVHO a normal user in a company doesn't need to know about the mailcow ui. What for? Should be left to the admin. I understand that everybody has different needs. Out of curiosity - how are you using mailcow? For a company? Are you a home user? I like to do my IT in the way I want. You are free to do what you want.

Hi, I personally think these additions are great, but I would have found it relevant to be able to choose whether or not to force the redirection of /SOGo/ to / from mailcow. Because I had set up a reverse-proxy webmail pointing to /SOGo/.

Moorch 2025 Update - SOGo login changed

stefan21

GeistFighter

Yeah, didn’t come across my mind. But true, that’s right too. IMO the decision if / or /SOGo/ is presented should be left to the admin.

esackbauer

stefan21 IMO the decision if / or /SOGo/ is presented should be left to the admin.

Does that really make a difference? You cannot use the login page from SOGo anymore, because of the change in how authentication workflow was changed.
The only thing that changed is that login mask is now presented from Mailcow UI, and that you don’t need to append /SOGo for accessing your mails.

stefan21

esackbauer

Why do you think it makes sense to let a user login/present (to) the mailcow-ui? The only work to do at this point is administration. It should be left to the admin. A user usually starts playing and in the end is settings are messed up. Is it possible to deny a user login at the mailcow UI to prevent a user messing with settings around? I didn’t update right now. I’m only reading and following.

Mailcow is an email server. All a user should be able to do is receiving and sending email with a(ny) client. That’s all.

I updated to check what else has been changed.

Do I get it right, that a user can redirect himself from SOGo ui to mailcow ui config settings where he/she is able to manipulate the own settings?

DocFraggle

stefan21 Why do you think it makes sense to let a user login/present (to) the mailcow-ui? The only work to do at this point is administration. It should be left to the admin.

Administrators can define whether a user should be redirected to the mailcow UI or SOGo after login.

Read the docs before complaining please…

mlcwuser

stefan21 Come on - how do you know?

Of course I don’t know, I was just trying to make a point. 😉 But good to hear, that you are supporting the project. 👍️

stefan21 For a company? Are you a home user?

Home user.

stefan21 Why do you think it makes sense to let a user login/present (to) the mailcow-ui?

Because there are user releated settings in there.

stefan21 Is it possible to deny a user login at the mailcow UI to prevent a user messing with settings around?

Not sure to be honest, since I don’t use Sogo myself, but it also says in the release notes that you can redirect users directly to Sogo after login.

stefan21

DocFraggle

I don’t get it.

I defined the user login beeing redirected to SOGo. Works. In SOGo on the right top of the SOGo icons there is a tool sign. Clicking on it will redirect the user to mailcow settings of her/his mailbox. Am I wrong? Do I overlook something?

DocFraggle

stefan21 Yes, where’s the problem? I don’t get it, too 😄

stefan21

I don’t want a user to manipulate settings. How can this be achieved?

Seems to be so
hard to understand…?

DocFraggle

stefan21 Seems to be so hard to understand…?

Yes, because your users had the possibility before 2025-03 as well. They just had to login via https://your.mail.server/

Did you prohibit this in any way before the update?

stefan21

No. The only pre-configured link we provide(d) to users is https://my.mail.server/SOGo

No other link. Why should we?

DocFraggle

stefan21 Why should we?

For users to be able to change their password? For users to a adjust the spam settings? There’s not much more to do there.

stefan21

Mailbox -General - Details - Settings
Temp. email addresses
Spamfilter
App. passwords
Pushover api

May I suggest you play as a normal user with all this settings around, and report back?

I am opened. Try to convice me that nothing breaks while users are playing around.

DocFraggle

stefan21 Sorry, but this discussion isn’t worth my time. Good luck

stefan21

Sad. Sorry for complaining and stating my point of view.

stefan21

mlcwuser Home user.

Thank you for your reply. I understand. This is not meant as disrespecting.

mlcwuser

Yeah, but I work somewhere too of course, and although we don’t use Mailcow there, I can totally understand that you would prefer not to let users configure anything at all. Believe me, I’ve worked in IT support, I know the pain it can cause. 😉

But my impression is that the Mailcow developers have a very strong opinion on this topic, and I doubt you can make them change their mind. But feel free to open a feature request on GitHub, and I’ll upvote it. And that I mean completely unironically.

« Previous Page