Mailcow.conf config options explanation

gorby · 2025-04-07T12:31:49+00:00

Hello there,
New to mailcow, I chose it for its countless config options, and the spirit of the community here in the forum.
And I like the mooh-things around

I have a few questions about options in the mailcow.conf config file :

1) I don’t need the groupware features, so I put :
SKIP_SOGO=y
.. but is there anything else I have to do to disable SoGo ?

2) In the “Other bindings” options, I have IMAP and IMAPS ports :

IMAP_PORT=143
IMAPS_PORT=993

Is that a good practice to disable IMAP port (143) just to strenghten the security of the server ?
Are there drawbacks if I disable it ?

3) Regarding POP :

POP_PORT=110
POPS_PORT=995

If I don’t want POP to be activated, can I just comment these two lines ?
Or there is a better way to completely disable it ?

Thanks,

–
Leo.

DD4niel · 2025-04-07T14:33:18+00:00

Best practice would be to disable POP3 like this: bulk change of mailboxes

mailcow communityDiscussion

bulk change of mailboxes

mgw2013

We would like to bulk change all existing mailboxes such that POP3 is disabled (I’m aware that I could change this by mailbox but we already have 250+…). What would be the recommended approach? Txs -mgw

3 2 12 days ago

You could comment out ports that you don’t want to publish in the docker-compose file, but I wouldn’t do that in the config file since the config file probably always expects some value.

gorby Is that a good practice to disable IMAP port (143) just to strenghten the security of the server ?

Good practice would be to correctly configure your mail clients to use the correct protocols. Port 143 also supports StartTLS, so it isn’t unencrypted per se.

esackbauer · 2025-04-07T15:04:18+00:00

gorby . but is there anything else I have to do to disable SoGo ?

No. But with disabling SOGo you lose also ActiveSync protocol (in case you wanted to use it)

gorby · 2025-04-07T18:59:41+00:00

Thanks @esackbauer for your feedback.
Correct me if I’m wrong but ActiveSync is only useful for having push notiications on your ios smartphone ?

–
Léo.

[unknown] Understood, thank you for the clarifications !

esackbauer · 2025-04-08T07:39:37+00:00

gorby but ActiveSync is only useful for having push notiications on your ios smartphone

Yes.

DocFraggle · 2025-04-08T07:55:15+00:00

gorby ActiveSync is only useful for having push notiications on your ios smartphone

ActiveSync also connects your mailbox’ calendar and contacts automatically without further ado

esackbauer · 2025-04-08T08:03:43+00:00

DocFraggle

That is done by the config profile for iOS as well
However ActiveSync has the advantage that shared calenders or additional calenders show up on iOS without additional config on the phone itself.
WIth CalDAV you have to link the additional calenders yourself on the phone.

DocFraggle · 2025-04-08T08:14:27+00:00

esackbauer That is done by the config profile for iOS as well

Ah okay, I’m not an Apple user

gorby · 2025-04-08T08:38:06+00:00

Thank you everyone for the feedback.
I’m still testing the solution, and I’m still hesitating between SoGo and Roundcube.
In one hand I only use email (not caldav etc..) and I’m used to Roundcube look & feel and its plugins, and on the other hand SoGo seems to have some nice features for email.

I know some of you would answer me that if I only need email, maybe mailcow is not the good project for that, but I disagree : Just because I only need a fraction of the software doesn’t mean I should turn to solutions that seem better suited to my needs, but rather less aligned with the community spirit and the connection I feel to the project.

Mmlcwuser · 2025-04-08T09:41:54+00:00

gorby I have disabled Sogo as well, as I don’t need the groupware functionally, because I have separte Nextcloud instance for that. Also I don’t really like the UI of Sogo, but that’s of course highly subjective.

Regarding POP3, you can enable/disable it per mailbox in the UI and you can also set the encryption policy.

Also, by setting (or not setting) certain SRV records, you can announce to the clients which ports they should prefer. You can also play with the priority and weight of certain records, or even explicitly tell clients not to use certain ports: DNS setup - mailcow: dockerized documentation

docs.mailcow.email

DNS setup - mailcow: dockerized documentation

None

If I understand correctly, this won’t help if someone explicitly tries to connect to a less secure port (e.g. 587 instead of 465), or if a client only supports STARTTLS, or simply does not respect the RFC, but it should at least reduce the risk of your users connecting to less secure ports unintentionally, while still being able to connect to those ports if necessary for certain edge cases.

If you don’t need those ports for anything, and want to be 100% sure that nobody can connect to them, don’t open them or block them with a firewall. Ideally, use a firewall in front of your server rather than on the Mailcow server itself (I use my VPS provider’s) - unless you know what you’re doing, as there are some potential pitfalls with the usual iptables/nftables front-ends like UFW, FirewallD and how they interact with Docker.