Différences

Ci-dessous, les différences entre deux révisions de la page.

--- pratique:informatique:mail:serveur_mail2 [22/09/2024 12:04] – [Tester] Zatalyz
+++ pratique:informatique:mail:serveur_mail2 [04/06/2026 10:20] (Version actuelle) – [Dovecot] Zatalyz
@@ Ligne 2: / Ligne 2: @@
 ===== Pas à pas =====
 <WRAP center round todo 60%>
-Version en travail reprenant les points clés vu dans les divers tutos et adaptés à ma propre façon de fonctionner.
+<del>Version en travail</del> reprenant les points clés vu dans les divers tutos et adaptés à ma propre façon de fonctionner.
+Voir [[pratique:informatique:mail:serveur_mail3]] parce que j'ai changé d'idée plusieurs fois, je repart de zéro !!!
 </WRAP>
@@ Ligne 28: / Ligne 30: @@
 poste.example.org.  IN  A  a.b.c.d
 poste.example.org.  IN  AAAA  2001:a::b
-example.org.  IN  MX  10 mail.example.org.
+example.org.  IN  MX  10 poste.example.org.
 </code>
@@ Ligne 47: / Ligne 49: @@
 L'un et l'autre doivent donner le nom de domaine configuré pour les ip en question. Le "@9.9.9.9" à la fin permet de passer par l'extérieur, si on teste en local sur un ordi local, dig ne retourne rien...
+<WRAP center round info 60%>
+=== IPV6 et fournisseurs ===
+La gestion d'ipv6 dépend entièrement du bon vouloir du fournisseur. Pas évident de savoir en amont, sauf à déjà avoir des machines chez ce fournisseur et accès à l'interface d'administration.
+Quand on monte un serveur mail en local, cela dépend du FAI, mais aussi des capacités de la box.
+  * Chez OVH, ma box (jamais remplacée et assez vieille) ne permettais pas de faire de l'ipv6, mais l'interface web d'OVH le prenait en compte ; c'est donc sans doute ok à présent ?
+  * Chez Free, la box ne le gère pas non plus et ça reste un problème relevé sur les forums en 2026. De toute façon, les IP de Free seront résidentielles, et cela garantit une déliverabilité très mauvaise...
+</WRAP>
 ===== Ports et nftables =====
@@ Ligne 71: / Ligne 81: @@
 On ouvre les ports sur le proxy quand tout le reste est fini...
+<WRAP center round info 100%>
+Avec la config paramétrée dans [[pratique:informatique:parefeu:nftables|nftables]], ce qu'il faut modifier/surveiller :
+  * ''/etc/nftables.d/30-fight.nft'' : Protection contre le SMTP/Email Bombing, vérifier si ça ne bloque pas des serveurs légitimes.
+  * ''/etc/nftables.d/40-confperso.nft'' : Autoriser en entrée ''80, 443, 25, 587, 993, 4190'' (encore que les deux premiers, uniquement si on a des outils de gestion web sur le serveur même ? mais c'est mon cas...)).
+  * ''/etc/nftables.d/50-output.nft'' : Autoriser en sortie ''25, 465, 587'' (TODO : J'ai un petit doute sur SIEVE, on vérifiera...).
+</WRAP>
 ===== Vérifier l'host =====
@@ Ligne 105: / Ligne 122: @@
   * dovecot-managesieved : permet aux utilisateurs de définir leurs règles de filtre.
-La chasse aux spams se fera avec rspamd, un logiciel tiers qui traite les spams. Il gère aussi la signature automatique des clés de domaine (DKIM).
+La chasse aux spams se fera avec <del>rspamd, un logiciel tiers qui traite les spams. Il gère aussi la signature automatique des clés de domaine (DKIM)</del>.
+<WRAP center round help 60%>
+Rspamd est certes plebiscité mais... j'ai des misères à le faire tourner, et puis ça m'agace qu'il fasse "tout" (je préfère le KISS). Je ne veux pas que si rspamd plante, ça fasse foirer la signature DKIM... La solution Spamassassin+Opendkim est sans doute plus adaptée. Je vais quand même refaire des tests avec les deux et voir. Par ailleurs j'ai fait un test avec Modoboa (tout compris !) et rspamd consommait bien plus de mémoire "à vide" que Spamassassin+Amavis+Opendkim...
+La chasse au spam reste donc un point en suspens pour le moment, attendant plus d'expérimentations, mais je vais plutôt vers la solution SpamAssassin.
+</WRAP>
 Mariadb ne sert qu'à stocker les utilisateurs donc très peu de données, sa perfomance ne sera pas un souci. Je vais avoir la surcouche graphique avec [[https://github.com/postfixadmin/postfixadmin|Postfixadmin]], qui permettra à mes utilisateurs de gérer leurs propres alias et mot de passe.
@@ Ligne 117: / Ligne 141: @@
 Le certificat SSL sera géré avec certbot, classique et fonctionnel.
-On va avoir un peu d'apache pour quelques outils visuels de gestion (adminer, rspamd).
+On va avoir un peu d'apache pour quelques outils visuels de gestion (adminer, rspamd?, postfixadmin).
 Finalement :
@@ Ligne 132: / Ligne 156: @@
 Mon apt est configuré pour ne pas installer par défaut les recommandés et suggérés, ce qui demande de voir la liste et de compléter au besoin. Ici, à installer en complément pour se simplifier la vie :
   sudo apt install shared-mime-info xdg-user-dirs php-curl php-gd php-cli
+<WRAP center round help 60%>
+Par ailleurs, il faudrait que je gère un chouïa mieux DMARC. C'est paramétré mais :
+  * Je n'envoie pas de rapports en retour (c'est une mauvaise pratique, il faudrait que je le fasse)
+  * Je n'analyse pas les rapports DMARC reçus (du coup quand il y a un souci, je m'en rends compte tardivement).
+[[https://github.com/liuch/dmarc-srg|Dmarc-srg]] semble plutôt sympa sur l'analyse des rapports. En bonus, il se connecte en imap donc peut être installé sur une autre machine sans aucun souci.
+[[https://github.com/trusteddomainproject/OpenDMARC|OpenDmarc]] (référence sur le sujet) génère les rapports à envoyer aux autres admins. Ça semble une sacré usine à gaz, probablement assez lourd. À voir et tester, mais... jusqu'ici, ne pas envoyer les rapports ne me fait pas "jeter" non plus. Par ailleurs cela demande que les milters aient vérifié SPF et DKIM (ce qui, de toute façon, serait mieux...). Opendkim gère DKIM, pour SPF voir le milter policyd-spf peut-être.
+</WRAP>
 et enfin (parce qu'il est un chouïa pénible sinon)
   sudo apt install rkhunter
@@ Ligne 384: / Ligne 420: @@
 Primo créer un user spécialement pour gérer les mails, et stocker ces derniers sur /var/vmail :
-  groupadd -g 5000 vmail
+<code>groupadd --system vmail
-  useradd -g vmail -u 5000 vmail -d /var/vmail -m
+useradd --system --gid vmail vmail
-  chown -R vmail:vmail /var/vmail
+mkdir -p /var/vmail
+chown -R vmail:vmail /var/vmail
+chmod u=rwx,g=rx,o= /var/vmail</code>
+<WRAP center round info 100%>
+  * ''--system'' crée un utilisateur explicitement "système", spécialement réservé aux services et daemons. L'ID sera choisi automatiquement dans ce qui est dispo sur la plage réservée aux utilisateurs systèmes.
+</WRAP>
 Ensuite on va modifier des fichiers. Veiller à ce que les lignes suivantes existent et soient commentés/décommentées comme indiqué.
@@ Ligne 753: / Ligne 796: @@
 Postfixadmin étant un clicodrôme parfait, je vous laisse explorer.
+===== Paramétrer les alias systèmes vers admin@ =====
+C'est bien beau tout ça, mais quand un mail interne au système (par exemple à root) est envoyé, il arrive où ? Nul part, et cette fois pas question de jouer avec [[pratique:informatique:mail:mail_relai|Msmtp]] : le relai, ça sera "nous". Mais, la logique n'est pas très différente.
+On commence par éditer ''/etc/aliases'' :
+<code txt /etc/aliases>
+mailer-daemon: postmaster
+postmaster: root
+nobody: root
+hostmaster: root
+usenet: root
+news: root
+webmaster: root
+www: root
+ftp: root
+abuse: root
+noc: root
+security: root
+default: admin@example.org
+root: admin@example.org
+</code>
+Oui, sans le @ à la fin des alias, cette fois. Et vers admin@example.org ou autre, hein, tant que c'est un utilisateur présent sur le système.
+Puis on régénère le fichier de postfix à propos des alias :
+  postalias /etc/aliases
+Et on peut tester l'envoi d'un mail. J'ai craqué, installé ''bsd-mailx'' (dont la syntaxe pour l'envoi d'un mail test ne me pose pas de souci) et hop :
+  echo "Test" | mail -s "Test " root
+Cela arrive bien dans la boite mail configurée !
 ===== Tester =====
@@ Ligne 829: / Ligne 903: @@
 </WRAP>
-Prochain test : envoyer un mail à l'extérieur.
+==== Todo ====
+<del>Prochain test : envoyer un mail à l'extérieur. Ce qui demande que j'ouvre des ports sur la box, c'est pas de suite.</del> : fait :)
+Il va falloir configurer dkim et tout l'toutim.
+Tester aussi si je peux envoyer un message avec un de mes alias ET si je suis bloquée si je tente d'utiliser un autre alias du domaine sans le bon compte.
+Problème pour envoyer un message à "nimporte qui sauf moi". Revoir la conf...
+Dans les trucs à intégrer :
+  * ARC (Authenticated Received Chain) : transferts de mail. Voir OpenARC ? (les mêmes que opendkim et opendmarc, les trois logiciels se répondent bien).
+  * MTA-STS (Strict Transport Security) : force le chiffrement TLS. Mais ça va demander de bien creuser... Parce que ça risque de bloquer des copains ? Va avec TLS-RPT (TLS Reporting) qui fait des rapports sur les échecs de chiffrement
+  * DANE, DNSSEC : DANE utilise DNSSEC pour publier l'empreinte de votre certificat TLS directement dans le DNS. Ce qui demande que je comprenne mieux DNSSEC *aussi*. Complément à MTA-TLS.
+Dans les trucs "osef" mais que je note pour arrêter de me demander ce que c'est quand je le croise :
+  * BIMI : ajoute son logo à côté des emails, ça sert à rassurer la populace mais ça demande de passer par une certification tiers et ce n'est pas gratuit, pour un truc qui me semble quand même un peu gadget à côté du reste. En plus faut une marque déposée. Bref, un truc clinquant pour les riches, espérons que cela ne devienne pas une obligation...
+ARC, MTA-STS, TLS-RPT, BIMI, DANE et SMTP TLS SRV
 ===== vieux tuto =====
@@ Ligne 854: / Ligne 946: @@
-===== Paramétrer les alias systèmes vers admin@ =====
-C'est bien beau tout ça, mais quand un mail interne au système (par exemple à root) est envoyé, il arrive où ? Nul part, et cette fois pas question de jouer avec [[pratique:informatique:mail:mail_relai|Msmtp]] : le relai, ça sera "nous". Mais, la logique n'est pas très différente.
-On commence par éditer ''/etc/aliases'' :
-<code txt /etc/aliases>
-mailer-daemon: postmaster
-postmaster: root
-nobody: root
-hostmaster: root
-usenet: root
-news: root
-webmaster: root
-www: root
-ftp: root
-abuse: root
-noc: root
-security: root
-default: admin@example.org
-root: admin@example.org
-</code>
-Oui, sans le @ à la fin des alias, cette fois. Et vers admin@example.org ou autre, hein, tant que c'est un utilisateur présent sur le système.
-Puis on régénère le fichier de postfix à propos des alias :
-  postalias /etc/aliases
-Et on peut tester l'envoi d'un mail. J'ai craqué, installé ''bsd-mailx'' (dont la syntaxe pour l'envoi d'un mail test ne me pose pas de souci) et hop :
-  echo "Test" | mail -s "Test " root
-Cela arrive bien dans la boite mail configurée !