Why are some service ports exposed to the host?

cjwalsh

Is there a good reason that several services in mailcow have their ports exposed on the host, even though they are limited to localhost (127.0.0.1)? Is this just for convenience, or is it not possible to resolve the addresses for the relevant services at runtime?

Specifically, I’m talking about these ports as configured in mailcow.conf:
DOVEADM_PORT=127.0.0.1:19991 SQL_PORT=127.0.0.1:13306 SOLR_PORT=127.0.0.1:18983 REDIS_PORT=127.0.0.1:7654

Limiting these ports to localhost should minimise the chance of access from outside the host, but it does extend the attack surface area somewhat and also means traffic is being routed via the mailcow network gateway out to the host and then back into the mailcow network, which seems inefficient.

So why does mailcow do this, instead of e.g. connecting directly to redis-mailcow:6379?

Also, is the Sieve port necessary to expose to the internet if you don’t use SoGo? Or is it used via the Admin console when configuring filters?

mlcwuser

cjwalsh Is there a good reason that several services in mailcow have their ports exposed on the host,

Not a Docker expert, so I can’t answer that…

cjwalsh Also, is the Sieve port necessary to expose to the internet if you don’t use SoGo? Or is it used via the Admin console when configuring filters?

Local clients (e.g. Thunderbird with the Sieve add-on) can use it to manage Sieve remotely. If you don’t need this functionality, you can leave the port closed.

cjwalsh cjwalsh Is there a good reason that several services in mailcow have their ports exposed on the host,
Not sure, I’d guess that some things running on the host might need to be able to access those services under certain circumstances…?

cjwalsh Also, is the Sieve port necessary to expose to the internet if you don’t use SoGo? Or is it used via the Admin console when configuring filters?

Email clients (e.g. Thunderbird with the addons.thunderbird.net Icon Sieve add-on) can use it to manage Sieve scripts remotely. If you don’t need this functionality, you can leave the port closed.

mlcwuser

===================================
Please ignore the mess above. For some reason the forum software doesn’t let you delete/edit posts after a few minutes and as if that wasn’t annoying enough, new posts are also merged with the posts you actually wanted to edit or remove 🙄

Maybe an admin would like to take care of it and delete it for me…
===================================

Anyways, here’s my edited post:

cjwalsh Is there a good reason that several services in mailcow have their ports exposed on the host, even though they are limited to localhost (127.0.0.1)?

I’m not sure, maybe there are certain use cases where things running on the host need to be able to access those services…?

cjwalsh Also, is the Sieve port necessary to expose to the internet if you don’t use SoGo? Or is it used via the Admin console when configuring filters?

Email clients (e.g. Thunderbird with the Sieve add-on) can use it to manage Sieve scripts remotely. If you don’t need this functionality, you can leave the port closed.

cjwalsh

@mlcwuser that makes sense about local mail clients being able to manage the Sieve filters, thanks for clarifying that.

Felix

The only caveat to using managesieve directly from a client would be that any changes are not synced back to SOGo. SOGo, annoyingly, keeps filters in its own database and format and builds the sieve rules on the fly when changing any of the rules.