Configuration Mailcow derrière NPM bouclée

Bonjour,

Après de nombreuses recherches et péripéties, ma configuration de serveur de messagerie est enfin bouclée.

La mise en place de mon nouveau serveur date de début mai.

Descente (temporaire) dans le nid de coucous

À cause des sources d'information très médiocres qui existent ainsi que des atermoiements et de la fiabilité quasi-inexistante des solutions d'« intelligence artificielle » ¹, mais aussi du fait de l'abrutissement dans lequel je me suis laissé entraîner, à tort, au lieu de prendre une approche plus saine, j'ai rencontré de grandes difficultés au départ dans la mise en place de ma configuration.

J'ai aussi perdu beaucoup de temps au tout début car j'avais fait l'énorme bêtise de croire que des outils de gestion de déploiement étaient à même de m'aider à faire vite et simple. Tout est allé beaucoup mieux une fois que j'ai foutu toute cette merde à la poubelle et réinstallé proprement mon serveur pour reprendre la main dessus.

Comme toujours, pourtant, la solution est simple et (presque) claire comme de l'eau de roche quand

• on n'est pas dupé ni mal orienté par le « bullshit » omniprésent ;
• on a bien compris :
  • le fonctionnement des deux outils (j'ai nommé NPM et Mailcow, plus précisément ceux des outils de Mailcow qui s'occupent de cette partie) ;
  • l'organisation et la structure des fichiers (particulièrement bien construite côté NPM).
• on a assimilé :
  • les « caprices » qui président au nommage d'un fichier dans les outils Mailcow.
• on s'en remet à des méthodes simples, efficientes, gérées en propre.
  • Il est largement préférable d'avoir la main sur le système de base et de s'appuyer sur des scripts robustes et une tâche cron sur le serveur.
  • C'est bien plus
    • performant,
    • sûr (sécurité),
    • maîtrisable,
    • évolutif,
    • formateur,
    • durable et
    • sans entrave
      • ni unitaire (à l'échelle d'un des services)
      • ni globale (à l'échelle de l'architecture et de l'infrastructure).

Mon choix : Ne surtout pas m'enfermer et me retrouver coincé avec des outils mal conçus, mal documentés, et qui à l'arrivée, pour quelques petits avantages sans grand intérêt sur des tâches simples, nous rendent la vie bien plus compliquée voire impossible pour des tâches plus critiques, plus importantes et plus complexes.

Synthèse de l'architecture

J'ai donc aujourd'hui une architecture basée sur deux piles (stack) :

• une pile NPM ;
• une pile Mailcow et
• une chaîne de liaison gérée par une tâche cron qui lance un script bash.

NPM (Nginx proxy manager)

C'est NPM qui gère l'ensemble des certificats TLS de tous les serveurs, y compris les serveurs de messagerie (SMTP / IMAP).

C'est aussi NPM qui me permet d'ajouter une couche d'authentification pour l'accès aux serveurs web de Mailcow (accès webmail, administration).

Chaîne de liaison

Elle se compose simplement d'une tâche cron, exécutée quotidiennement.
Cette tâche démarre un script qui :

• copie les deux fichiers (certificat et clef) depuis le dossier NPM vers le dossier Mailcow ;
• recharge les services Mailcow qui utilisent ce certificat :
  • Postfix ;
  • Dovecot et
  • nginx (le serveur web associé à Mailcow). ²
• alimente un journal d'événements (log) pour confirmer que la tâche a bien été effectuée jusqu'au bout.

Mailcow

Côté Mailcow, il faut penser à indiquer d'ignorer (skip) ACME qui se charge de la création et du renouvellement des certificats dans le cas d'une installation isolée (fichier mailcow.conf à la racine, généralement mailcow-dockerized/) :

SKIP_LETS_ENCRYPT=y

Pour le service web, qui permet d'accéder au webmail ou à l'administration de mailcow ou des domaines paramétrés, il convient d'indiquer un port HTTP, que l'on met en correspondance dans NPM pour le port HTTPS exposé.

Exemple :

HTTP_PORT=8080 # Port à indiquer dans le mapping NPM
HTTP_BIND=

HTTPS_PORT=8443 # (non utilisé)
HTTPS_BIND=

# Redirect HTTP connections to HTTPS - y/n
HTTP_REDIRECT=n # Important : NE PAS rediriger les flux HTTP vers HTTPS dans Mailcow
                # C'est bien NPM qui se charge de transmettre ce flux HTTP, en HTTPS, au monde extérieur.

Pas d'IPv6

Tant que Free ne permet pas d'activer le reverse DNS en IPv6, ce n'est tout simplement pas possible.

Il faut penser à désactiver l'IPv6 sur le serveur.

À défaut, il faut désactiver IPv6 au niveau de Mailcow pour qu'il n'essaie pas d'envoyer des courriels avec IPv6.

Sécurité

Je recommande d'activer des listes d'accès (ACL) dans NPM pour :

• l'accès au webmail (/) ;
• l'accès à l'administration des domaines (/domainadmin/) ;
• l'accès à l'administration générale (/admin/) ou
• tous ces accès à la fois.

En rappelant que nous pouvons réduire considérablement la surface d'attaque :

• en n'activant pas NPM du tout (plus d'accès public) et en accédant au serveur web uniquement en local ;
• en n'autorisant pas le webmail ;
• et bien d'autres scénarios possibles
• tout en conservant le principe du frontal NPM pour la création et le renouvellement des certificats.

Au plaisir,

Marc JESTIN
Éco-citoyen de la Terre
https://marcjestin.fr

Nota bene : Cet article n'est pas rémunéré, pas plus qu'aucune de mes publications.

Si vous voulez me soutenir, vous pouvez effectuer un don personnel => https://marcjestin.fr/mes-coordonnees-bancaires.html.

Si vous voulez faire appel à mes services, contactez-moi => 06 13 03 17 96 ou https://marcjestin.fr/fr/contact.

Si vous disposez d'informations authentifiées de nature à améliorer ce contenu, je vous invite à me les communiquer.