Différences

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

--- 200-postfix-dovecot-etc:020-postfix [le 30/05/2025 à 09:14] – ↷ Page déplacée de 200-messagerie:010-postfix-dovecot-etc:020-postfix à 200-postfix-dovecot-etc:020-postfix prof
+++ 200-postfix-dovecot-etc:020-postfix [le 02/11/2025 à 18:11] (Version actuelle) – prof
@@ Ligne 3: / Ligne 3: @@
 ===== Objectif =====
-Par défaut, postfix réceptionne les messages concernant «mydestination» et les stocke au format «mailbox»  orienté POP3. Nous préférons bien sûr le format «maildir» propre à IMAP. Potfix dispose de son propre LDA((Local Delivery Agent)), nous lui préférerons celui qui est proposé par Dovecot.
+Par défaut, postfix réceptionne les messages concernant «mydestination» et les stocke au format «mailbox»  orienté POP3. Nous préférons bien sûr le format «maildir» propre à IMAP. Potfix dispose de son propre LDA((Local Delivery Agent)), nous lui préférerons au final celui qui est proposé par Dovecot qui offre quelques fonctionnalités intéressantes.
 ===== Première configuration =====
 ==== Modification du fichier ''/etc/aliases''. ====
@@ Ligne 22: / Ligne 22: @@
 <html><pre class="code">
 compatibility_level = 3.9
-<span class="bhly">mydomain = home.nain-t.net
+<span class="hly">mydomain = home.nain-t.net
 myorigin = $mydomain</span>
 smtpd_banner = $myhostname ESMTP $mail_name (Debian)
 inet_protocols = all
-mynetworks_style = host
+<span class="bhly">mynetworks_style = subnet
-<span class="bhly">mynetworks = 127.0.0.0/8 192.168.60.0/24 [::ffff:127.0.0.0]/104 [::1]/128 [2a01:e0a:875:b1d0::0]/64
 mydestination = $myhostname, home.nain-t.net, localhost.home.nain-t.net, , localhost</span>
 mailbox_size_limit = 0
@@ Ligne 47: / Ligne 46: @@
 <span class="bhly">home_mailbox = Maildir/</span>
 </pre></html>
-  * **mydomain** et **myorigin** permettent au serveur de poster les messages d'administration @home.nain-t.net plutôt que @mail.home.nain-t.net. Ce n'est pas fondamental et tout-à-fait optionnel.
+Notons ces points:
-  * **mynetworks** définit les adresses de sous-réseaux dont fait partie le serveur. Les clients dont l'adresse appartient à l'un de ces sous-réseaux sont considérés comme sûrs et sont acceptés sans restriction pour l'envoi de messages.
+  * le paramètre ''mynetworks_style = subnet'' permet d'indiquer simplement à Postfix que les clients appartenant à son sous-réseau sont automatiquement autorisés. Le ou les sous-réseaux sont déduits de la configuration ip telle qu'il est possible de la vérifier avec la commande ''ip addr ls''. Ce paramètre évite dans les cas simples d'avoir à configurer explicitement le paramètre ''mynetworkx''.
+  * un hôte correctement configuré dispose par lui-même d'un nom d'hôte complètement qualifié.
+  * la commande ''hostname -f'' permet de vérifier cette configuration. dans le cas de notre maquette:
+<html><pre class="code">
+<b>hostname -f</b>
+<span class="hly">mail.home.nain-t.net</span>
+</pre></html>
+Dans ce cas de figure, il n'est pas nécessaire de préciser les paramètres ''myhostname'' et ''mydomain'' qui seront automatiquement déduits, mais il n'est pas gênant de les préciser tout de même.
+.
+  * **myorigin** définit la partie droite des adresses apposées à un nom d'utilisateur destinataire local. Par exemple lorsqu'un message administratif est envoyé à ''root''. Par défaut, ''myorigin = myhostname''. Il est préférable dans un cas comme le notre de faire plutôt ''myorigin = mydomain''\\
+  * **mynetworks** définit les adresses de sous-réseaux dont fait partie le serveur. Les clients dont l'adresse appartient à l'un de ces sous-réseaux sont considérés comme sûrs et sont acceptés sans restriction pour l'envoi de messages. Autrement-dit, ils peuvent utiliser le MX sans avoir à s'identifier, leur adresse IP le faisant à leur place.\\  La syntaxe employée ici peut paraître obscure, qui mélange notations IPv6 et IPv4 (''[::ffff:127.0.0.0]/104'').\\  Une autre syntaxe non moins opaque, mais plus légère consistreait à remplacer cette ligne par:\\ ''mynetworks_style = subnet''
   * **mydestination** liste les destinations considérées comme locales dans les adresses entrantes et donc gérées par le LDA.
   * **smtpd_tls_key_file** et **smtpd_tls_cert_file** indiquent les chemins d’accès à la clé privée et au certificat générés par «let's encrypt».
-  * **home_mailbox** indique à Postfix que les messages locaux sont stockés au format «Maildir».
+  * **home_mailbox** indique à Postfix que les messages locaux sont stockés au format «Maildir», avec le LDA intégré à postfix pour l'instant.
@@ Ligne 57: / Ligne 67: @@
 ==== L'authentification de l'émetteur ====
-Lorsqu'un client doit poster un e-mail, son MUA est configuré pour utiliser un MTA. Typiquement celui proposé par son fournisseur d'accès. Lorsque le client est connecté par l'entremise de son FAI, il dispose d'une adresse qui fait partie des réseaux du FAI et ce dernier peut user de cette particularité pour autoriser le relai de ce message.
+Lorsqu'un client doit poster un e-mail, son MUA est configuré pour utiliser un MTA. Typiquement celui proposé par son fournisseur d'accès. Lorsque le client est connecté par l'entremise de son FAI, il dispose d'une adresse qui fait partie des réseaux du FAI et ce dernier peut user de cette particularité pour autoriser le relai de ce message. C'est la configuration telle que nous l'avons vue lus haut.
-En revanche, le client nomade, qui est amené à se connecter au Net par divers autre moyens, ne disposera pas forcément d'une adresse IP appartenant à son FAI. Dans ce cas, plusieurs cas sont possibles:
+En revanche, le client nomade, qui est amené à se connecter au Net par divers autres moyens, ne disposera généralement pas  d'une adresse IP appartenant à son FAI. Dans ce cas, plusieurs cas sont possibles:
   - le client nomade utilise alors un «webmail» et s'authentifie via son adresse e-mail et son mot de passe,
-  - le client nomade modifie son MUA pour utiliser le MTA proposé par le FAI qui le connecte (solution de type «shadoks»(([https://fr.wikipedia.org/wiki/Les_Shadoks])),
+  - le client nomade cherche à modifier la configuration de son MUA pour utiliser le MTA proposé par le FAI qui le connecte (solution de type «shadoks»(([https://fr.wikipedia.org/wiki/Les_Shadoks])),
-  - le FAI habituel du client nomade a mis à sa disposition le port «submission» qui permet au client d'utiliser TLS pour s'authentifier auprès du MTA avec son mom d'utilisateur (ou son adresse mail) et son mot de passe.  Postfix sait faire, en s'appuyant sur le serveur IMAP associé. C'est cette technique que nous mettrons en œuvre.
+  - le FAI habituel du client nomade a mis à sa disposition le port «submission» qui permet au client d'utiliser TLS pour s'authentifier auprès du MTA avec son mom d'utilisateur (ou son adresse mail) et son mot de passe.  Postfix sait le faire, en s'appuyant sur le serveur IMAP associé. C'est cette technique que nous mettrons en œuvre.
 ==== Les restrictions ====
 Postfix propose une [[https://www.postfix.org/SMTPD_ACCESS_README.html|panoplie de restrictions]] applicables aux mails entrants:
@@ Ligne 79: / Ligne 89: @@
 </note>
 === Éviter de s'y retrouver ===
-Première mesure: Ne pas se retrouver en situation de relais ouvert (open-relay). Autrement dit configurer correctement Postfix pour qu'il n'accepte pas de relayer des messages émis pas des gens inconnus. Ceci est déjà en partie réalisé avec le paramètre ''mynetworks'' qui; comme son nom l'indique, ne s'intéresse qu'à l'adresse IP de l'émetteur. Ce n'est pas suffisant, une station dans le réseau contaminée par un virus quelconque peut être amené à poster en douce du spam «à gogo». De plus, un client nomade ne pourra pas utiliser notre MX s'il n'est pas connecté à l'un de nos réseaux. Il faudra trouver une astuce.
+Première mesure: Ne pas se retrouver en situation de relais ouvert (open-relay). Autrement dit configurer correctement Postfix pour qu'il n'accepte pas de relayer des messages émis pas des gens inconnus. Ceci est déjà en partie réalisé avec le paramètre ''mynetworks'' qui; comme son nom l'indique, ne s'intéresse qu'à l'adresse IP de l'émetteur. Pour les nomades, il faut mettre en œuvre une authentification solide et s'assurer que des attaques répétées ne finissent pas par s'approprier des identifiants d'utilisateurs légitimes.
-Deuxième mesure: Le RDNS (reverse DNS) devrait être systématiquement mis en place. Autrement dit, une recherche DNS sur l'adresse IP du serveur doit renvoyer son nom. Ceci induit deux choses:
+Deuxième mesure: Le RDNS (reverse DNS) devrait être systématiquement mis en place. Autrement dit, une recherche DNS sur l'adresse IP du serveur doit renvoyer son vrai nom (''myhostname''). Ceci induit deux choses:
-  - Le nom attribué au serveur MX **doit être** par un champ A (IPv4) ou AAAA (IPv6) et **en aucun cas** par un alias (champ CNAME);
+  - Le nom attribué au serveur MX **doit être** défini par un champ A (IPv4) ou AAAA (IPv6) et **en aucun cas** par un alias (champ CNAME);
   - il faut être en mesure de paramétrer le RDNS, ce qui n'est pas toujours possible lorsque l'on passe par un F.A.I et que celui-ci ne propose pas de solution. Free par exemple ne propose qu'une solution pour l'unique IPv4 fournie et actuellement rien pour IPv6. Les zones de définition des champs «IN PTR» ne pouvant se trouver (si elles existent) que sur les DNS du pourvoyeur d'adresses IP et non chez le gestionnaire du nom de domaine.
   - Au minimum configurer correctement SPF (Sender Policy Framework) autrement dit mettre en place un champ «TXT» sur le DNS du domaine permettant au MX du destinataire que l'émetteur a utilisé un MX dans le domaine de son adresse d'émetteur.