gorby

  • 13 minutes ago
  • Joined 6 days ago
  • 6 discussions
  • 16 posts
  • 2 best answers
  • Post posted... wait what? You got the answer!
  • In Restrict IP for location /admin/ with nginx

    Hello community,

    I’m trying to use nginx to restrict the access of mailcow UI for /admin/ location.
    I followed the docs (docs.mailcow.email Icon Custom sites - mailcow: dockerized documentation

    docs.mailcow.email Icon docs.mailcow.email
    Custom sites - mailcow: dockerized documentation
    None
    docs.mailcow.email
    ) and I’ve created a extra.conf in data/conf/nginx with inside :

    server {
   location /admin/ {
        allow 192.168.1.100;  # Allow this specific IP
        deny all;             # Deny all other IPs
   }
}

    But /admin/ is still open to every IP after a compose down & up.
    Someone has an idea ?

    –
    Léo.

  • In Configuration profiles / unsigned

    Closing, resolved.

  • In Mailcow.conf config options explanation

    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.

    • In What config to secure mailcow UI admin access ?

      And what experts think about adding an extra.conf file in the data/conf/nginx/ folder and put something like that inside :

      server { location /admin {
        allow 192.168.1.100;  # Allow this specific IP
        allow 203.0.113.0/24; # Allow this IP range
        deny all;             # Deny all other IPs
    }
}

      Is it a good practice ?
      Will it be persistent ?

      Thanks 🙂

      –
      Léo.

    • In What config to secure mailcow UI admin access ?

      esackbauer Okay, the main goal was to prevent potential exploitation of a security flaw in the submission form under /admin/. A exploit that could lead to avoid 2FA for example ? But if that’s not possible, maybe I’m just being paranoid…

        • In Mailcow.conf config options explanation

          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 !

          • In Configuration profiles with App password not generating one

            Hello (again..),

            Something unclear : I followed the tutorial to generate a configuration profile for my iOS smartphone, and I installed it. I followed this guide (docs.mailcow.email Icon Apple macOS / iOS - mailcow: dockerized documentation

            docs.mailcow.email Icon docs.mailcow.email
            Apple macOS / iOS - mailcow: dockerized documentation
            None
            docs.mailcow.email
            ) and tried Method 1.3 “IMAP and SMTP with App Password”.

            But after installing it, I go to the mailcow UI for users, click on “App Password” tab, and there are no App Password generated in the form.

            Shouldn’t there be one ?
            Thanks in advance for any clarification.

            –
            Léo.

          • In Configuration profiles / unsigned

            Hello there 🙂

            I’ve been testing mailcow and I’m particularly interested in the “Configuration profile” link to configure iOS email accounts (docs.mailcow.email Icon Apple macOS / iOS - mailcow: dockerized documentation

            docs.mailcow.email Icon docs.mailcow.email
            Apple macOS / iOS - mailcow: dockerized documentation
            None
            docs.mailcow.email
            ).

            Just a little question here : Profiles are “unsigned” when I try to install them, is that normal or did I miss something in the configuration process ?

            Thanks,

            –
            Léo.

            My bad, I missed a mention in the docs :

            Since the profile is not digitally signed, you must confirm the respective notification during installation.

            What should be done to digitally sign it then ?

            My bad, I missed a mention in the docs :

            Since the profile is not digitally signed, you must confirm the respective notification during installation.

            What should be done to digitally sign it then ?

            My bad, I missed a mention in the docs :

            Since the profile is not digitally signed, you must confirm the respective notification during installation.

            What should be done to digitally sign it then ?

            • Closing, resolved.

          • In What config to secure mailcow UI admin access ?

            Thanks @Ganzjahresgriller for your feedback.
            I didn’t think about the 2FA, that’s a great (and simple) start.

            Unfortunately, I don’t have the knowledge to install a firewall and hide the admin URL.
            If you could share me a tutorial to make this happen, I’d be grateful 🙂

          • In What config to secure mailcow UI admin access ?

            Hello 🙂

            What is the best practice to secure mailcow UI’s admin access ?
            Correct me if I’m wrong, but I think admin access shouldn’t be exposed publicly on the web like users’s access.

            Is there a way to add a layer of security upon that admin log in page ?
            Thanks 🙂

            –
            Léo.

          • In Clarification about ADDITIONAL_SERVER_NAMES config option

            Thanks @DocFraggle, I managed to understand the difference :
            ADDITIONAL_SAN is about cert generation ;
            ADDITIONAL_SERVER_NAMES is about letting nginx know it can be accessed on that server.

            Perfectly clear (my mistake was on the ADDITIONAL_SERVER_NAMES also generating the certificate).
            Thanks everyone 🙂

            –
            Leo.

          • In Clarification about ADDITIONAL_SERVER_NAMES config option

            Thanks @torbho, but that’s exactly what I’m trying to do here : access mailcow UI through mail.domain.com and not through mail.domain.com.
            Yes, I used docker compose down && docker compose up -d 🙂 👍️

            As described in the docs :

            # Additional server names for mailcow UI
#
# Specify alternative addresses for the mailcow UI to respond to
# This is useful when you set mail.* as ADDITIONAL_SAN and want to make sure mail.maildomain.com will always point to the mailcow UI.
# If the server name does not match a known site, Nginx decides by best-guess and may redirect users to the wrong web root.
# You can understand this as server_name directive in Nginx.
# Comma separated list without spaces! Example: ADDITIONAL_SERVER_NAMES=a.b.c,d.e.f

            I’m wondering if I have to declare “mailcow.*” in the ADDITIONAL_SAN section also to make it work… ?

            • In Clarification about ADDITIONAL_SERVER_NAMES config option

              Ah!
              So what’s ADDITIONAL_SERVER_NAMES is for exactly ?

            • In Clarification about ADDITIONAL_SERVER_NAMES config option

              Hello everyone,
              I read the whole config file and I think I understood it quite well.
              But there’s something not working so maybe there’s room for clarification 🙂

              I configured my server for PTR to resolve to “mail.domain.com”
              In my config file, I have :
              ADDITIONAL_SERVER_NAMES=mailcow.domain.com

              But when I started (or have restarted since), the ACME cert is generated for mail.domain.com 🟢 , but not the mailcow.domain.com's 🟥 one.
              What am I missing please ?

              I’m trying to access mailcow UI only with “mailcow.domain.com” and not “mail.domain.com”.

              –
              Leo.

              • Thanks @DocFraggle, I managed to understand the difference :
                ADDITIONAL_SAN is about cert generation ;
                ADDITIONAL_SERVER_NAMES is about letting nginx know it can be accessed on that server.

                Perfectly clear (my mistake was on the ADDITIONAL_SERVER_NAMES also generating the certificate).
                Thanks everyone 🙂

                –
                Leo.

            • In Mailcow.conf config options explanation

              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.

              • D4niel and esackbauer replied to this.

              • Best practice would be to disable POP3 like this: https://community.mailcow.email/d/4741-bulk-change-of-mailboxes/2
                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.