Différences

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

--- 200-postfix-dovecot-etc:080-milters [le 30/05/2025 à 09:14] – supprimée - modification externe (Date inconnue) 127.0.0.1
+++ 200-postfix-dovecot-etc:080-milters [le 04/10/2025 à 17:24] (Version actuelle) – ↷ Liens modifiés en raison d'un déplacement. 66.249.69.2
@@ Ligne 1: / Ligne 1: @@
+====== Postfix et les «milters» ======
+//Ce protocole est utilisé par les applications exécutées en dehors du MTA pour inspecter les événements SMTP (CONNECT, DISCONNECT), les commandes SMTP (HELO, MAIL FROM, etc.) ainsi que le contenu des messages (en-têtes et corps). Tout cela se produit avant la mise en file d'attente des messages.
+La prise en charge de Milter par Postfix s'explique par l'existence d'un large éventail d'applications, permettant non seulement de bloquer le courrier indésirable, mais aussi de vérifier l'authenticité (exemples : OpenDKIM et DMARC ) ou de signer numériquement le courrier (exemple : OpenDKIM )((Traduction «google» de la [[http://www.postfix.org/MILTER_README.html|documentation originale]] de Postfix))//.
+Parmi la nombreuse liste de filtres proposés, nous utiliserons spamassassin, opendkim opendmarc
+====== Spamassassin ======
+Un filtre éventuellement adaptatif puisqu'il peut
+En installant le paquet ''spamass-milter'' toutes les (très nombreuses) dépendances viendront avec.
+===== spamass-milter =====
+Le démon ''spamass-milter'' nécessite quelques ajustements de configuration. Modifier le fichier ''/etc/default/spamass-milter'' de la façon suivante:
+  OPTIONS="-u spamass-milter -i 127.0.0.1"
+  OPTIONS="${OPTIONS} -r 5"
+  OPTIONS="${OPTIONS} -- -s 10485760"
+  * l'option ''-r'' fixe le score à partir duquel le message est considéré comme spam (15 est la valeur par défaut, 5, c'est plutôt serré),
+  * l'option ''-- -s 10485760'' c'est pour passer au client ''spamc'' la taille maximale des messages à filtrer
+Après avoir relancé le démon ''spamass-milter'', il faudra s'assurer que:
+  - Les démons ''spamass-milter'' et ''spamd'' sont actifs:<html><pre class="code"><b>systemctl status spamass-milter</b>
+● spamass-milter.service - LSB: milter for spamassassin
+     <b>Loaded: loaded</b> (/etc/init.d/spamass-milter; generated)
+     <span class="bhly">Active: active (running)</span> since Fri 2025-05-09 17:50:38 CEST; 1h 32min ago
+ Invocation: 88bd33c0d06f4ec7914c5fe9a364951a
+       Docs: man:systemd-sysv-generator(8)
+      Tasks: 5 (limit: 1099)
+     Memory: 1000K (peak: 2.2M)
+        CPU: 186ms
+     CGroup: /system.slice/spamass-milter.service
+             └─3194 /usr/sbin/spamass-milter -P /var/run/spamass/spamass.pid -f -p <span class="hly">/var/spool/postfix/spamass/spamass.sock -u spamass-milter -i 127.0.0.1</span>
+<b>systemctl status spamd</b>
+● spamd.service - Perl-based spam filter using text analysis
+     <b>Loaded: loaded</b> (/usr/lib/systemd/system/spamd.service; enabled; preset: enabled)
+     <span class="bhly">Active: active (running)</span> since Fri 2025-05-09 17:51:22 CEST; 1h 33min ago
+     ...
+    <span class="hly">spamd: server started on IO::Socket::IP [::1]:783, IO::Socket::IP [127.0.0.1]:783 (running version 4.0.1)</span>
+    ...
+</pre></html>
+===== Postfix =====
+  - Configurer Postfix en ajoutant ces lignes à ''main.cf'':<html><pre class="code">
+<span class="hlg">milter_protocol = 6
+milter_default_action = accept
+non_smtpd_milters = $smtpd_milters</span>
+<span class="hly"># spamass-milter configuration
+<b>smtpd_milters = unix:/spamass/spamass.sock</b>
+# milter macros useful for spamass-milter
+milter_connect_macros = j {daemon_name} v {if_name} _
+milter_data_macros = j i {auth_type} {daemon_name} v {if_name} _
+milter_rcpt_macros = j {auth_type} {daemon_name} v {if_name} _
+</pre></html>
+Les lignes vertes:
+  * **milter_protocol** comme son nom l'indique est la version du protocole utilisé: 6 depuis Postfix 2.6,
+  * **milter_default_action** action à mener en cas d'erreur de fonctionnement d'un milter.
+  * **non_smtpd_milters** sont les filtres qui peuvent s'appliquer un autre démon que smtpd (lmtpd par exemple).
+  *
+Les lignes jaunes sont directement tirées de la documentation officielle du milter pour son intégration dans Postfix.
+La ligne en gras contenir par la suite la liste des autres filtres mis en œuvre. Pour l'instant, il n'y a que spamassassin.
+===== Tests =====
+==== Envoi d'un spam ====
+Un client disposant d'une boîte aux lettres sur notre MTA poste un spam type fourni dans la documentation officielle de spamassassin à un correspondant quelconque. Dans l'exemple, le test est effectué avec le MUA «claws-mail», configuré pour utiliser STARTTLS et le port «submission».
+Le MTA refuse le message. Le client voit apparaître un «popup»:
+{{ 200-postfix-dovecot-etc:erreur_spam.png?700 |Erreur d'envoi}}
+En affichant les traces , nous retrouvons:
+<html><pre class="code">
+[2025-05-12 18:00:32] ESMTP> MAIL FROM:<admin@home.nain-t.net> SIZE=430
+[2025-05-12 18:00:32] SMTP< 250 2.1.0 Ok
+[2025-05-12 18:00:32] SMTP> RCPT TO:<user@home.nain-t.net>
+[2025-05-12 18:00:32] SMTP< 250 2.1.5 Ok
+[2025-05-12 18:00:32] SMTP> DATA
+[2025-05-12 18:00:32] SMTP< 354 End data with <CR><LF>.<CR><LF>
+[2025-05-12 18:00:32] SMTP> . (EOM)
+<span class="hly">[2025-05-12 18:00:32] SMTP< <b>550 5.7.1 Blocked by SpamAssassin</b>
+** erreur pendant la session SMTP
+*** Une erreur est survenue pendant l'envoi du message :
+5.7.1 Blocked by SpamAssassin</span>
+</pre></html>
+==== Réception d'un message ====
+Un correspondant envoie un message à «user@home.nain-t.net». Ce message est propre, il passe. Nous pouvons trouver dans l'en-tête du message reçu les lignes suivantes:
+<html><pre class="code">
+<span class="bhly">X-Spam-Status: No, score=-0.2 required=15.0</span> <span class="hlg">tests=DKIM_SIGNED,DKIM_VALID,
+	DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,SPF_HELO_NONE,SPF_PASS</span>
+	autolearn=ham autolearn_force=no version=4.0.1
+X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on mail.home.nain-t.net
+</pre></html>
+Le message est tellement propre qu'il a même un score <0. Au passage, nous remarquons que le MTA de l'émetteur présente une information SPF correcte, Une signature DKIM valide, que DMARC est OK.
+Reste à faire de même avec notre MTA.
+===== SPF =====
+"Sender Policy Framework" est une norme de vérification du nom de domaine de l'expéditeur d'un courrier électronique, normalisée dans la RFC 72081 (section 3.1)2. L'adoption de cette norme est de nature à réduire le spam((Définition issue de [[https://fr.wikipedia.org/wiki/Sender_Policy_Framework|Wikipedia]].))
+Sa mise en œuvre est assez simple, il suffit de créer un enregistrement TXT dans la zone DNS du domaine expéditeur, cet enregistrement indiquant les adresses IP (v4 comme v6) des MTA "officiels" pour ce domaine, ainsi que les restrictions à appliquer si l'IP émettrice n'est pas dans la liste. Il est également possible pour un domaine donné, d'inclure le champ SPF d'un autre serveur.
+==== Le principe ====
+L'idée de base est de vérifier que l'émetteur du message a utilisé un serveur MTA sortant légitime pour le domaine annoncé dans l'adresse de l'émetteur:
+  - l'émetteur du message a une adresse @exemple.tld. Il envoie ce message @autrexemple.tld
+  - Il utilise un MTA sortant légitime pour le domaine exemple.tld.
+  - le smtp qui gère autrexemple.tld, lorsqu'il reçoit ce message va vérifier que le smtp que l'émetteur a utilisé pour envoyer son message est bien légitime pour le domaine exemple.tld. Par la suite, le paramètre "RCPT TO" indiquera l'adresse du destinataire. Tout ceci constitue l'enveloppe du message.
+Un petit schéma ?
+{{ 200-postfix-dovecot-etc:spf.svg?700 | SPF: le principe}}
+  - untel@home.nain-t.net envoie un message à untel@gmail.com. Pour ce faire, il utilise son MTA: mail.home.nain-t.net.
+  - Le message arrive sur le MTA du destinataire.
+  - Celui-ci interroge via DNS  l'enregistrement SPF du domaine émetteur (home.nain-t.net) pour savoir si son adresse IP est bien autorisée à relayer ce message.
+    * Si c'est le cas, le MTA destinataire va poursuivre la transaction,
+    * si ce n'est pas le cas, le MTA suivra la directive indiquée dans l'enregistrement SPF. Cette directive peut être plus ou moins permissive:
+      * **-** Fail (échec) Le message doit être rejeté,
+      * **~** SoftFail le message peut être accepté, mais doit être marqué,
+      * **?** Neutral Le MTS destinataire fera ce qu'il veut. Il devrait accepter mais il n'est pas du tout obligé.
+La syntaxe du champ est la suivante:
+  * **a**  autorise toutes les adresses disposant d'un champ A ou AAAA du domaine à agir comme MTA
+  * **mx** autorise les adresses disposant du champ MX (Mail Exchanger) ce qui est pour le moins logique.
+  * **ipv4** et/ou **ipv6** spécifient des adresses IP autorisées. Adresses uniques ou sous-réseaux CIDR.
+  * **all** pour indiquer le sort de toutes les adresses non spécifiées.
+Un exemple très directif pour un domaine quelconque pourrait être:
+  SPF 	v=spf1 mx -all
+Ce qui veut dire que pour ce domaine, seule la ou les adresses IP indiquées dans des champs MX sont autorisées, à l'exclusion de toute autre.
+==== Les limites ====
+Mail-From: c'est l'adresse de l'auteur du message dans le dialogue SMTP. Dans l'en-tête du message reçu, nous la retrouvons dans la ligne ''Return-Path:''. Normalement identique à l'adresse retrouvée dans le champ ''From:''. Plus exactement, un MUA «normal» Présente sur Mail-From, et sur From: la même adresse. Mais ceci peut se bricoler. La preuve, sur un authentique spam:
+<html><pre class="code">
+<span class="bhly">Return-Path: &lt;printing7@printingpress.xicp.net&gt;</span>
+Delivered-To: prof@nain-t.net
+...
+<span class="bhlr">From: "admin@hongchengco.com" &lt;admin@hongchengco.com&gt;</span>
+Subject: Various styles of Jersey and sneakers for you
+To: irp@nain-t.net
+...
+<span class="hlr">Reply-To: admin@hongchengco.com</span>
+...
+</pre></html>
+===== DKIM =====
+**"Domain Keys Identified Mail"** permet au serveur SMTP sortant de signer les e-mails qu'il émet avec une clé privée. La clé publique correspondante est accessible par le serveur DNS du domaine. Ainsi, le serveur SMTP destinataire peut s'assurer de l’authenticité su serveur émetteur. Il devient alors facile de comparer les domaines du serveur émetteur à la partie droite de l'adresse de l'adresse indiquée dans l'en-tête ''From'' qui devraient être identiques. Bien entendu, il faut abandonner la pratique consistant à utiliser par exemple le serveur SMTP de son fournisseur d'accès en présentant une adresse appartenant à un autre domaine.\\ \\
+===== DMARC =====
+**"Domain-based Message Authentication, Reporting, and Conformance"** propose une solution de déploiement et de surveillance des problèmes liés à leur authentification, en s'appuyant sur SPF et DKIM.