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?

    6 days later

    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 addons.thunderbird.net Icon Sieve

    addons.thunderbird.net Icon addons.thunderbird.net
    Sieve
    This Extension implements the ManageSieve protocol for securely managing Sieve Script on a remote IMAP server...
    addons.thunderbird.net
    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.

          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!

          ===================================
          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 addons.thunderbird.net Icon Sieve

          addons.thunderbird.net Icon addons.thunderbird.net
          Sieve
          This Extension implements the ManageSieve protocol for securely managing Sieve Script on a remote IMAP server...
          addons.thunderbird.net
          add-on) can use it to manage Sieve scripts remotely. If you don’t need this functionality, you can leave the port closed.

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

              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.

              No one is typing