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 )¹⁾.

Parmi la nombreuse liste de filtres proposés, nous utiliserons spamassassin, opendkim opendmarc

Un filtre éventuellement adaptatif puisqu'il peut

En installant le paquet spamass-milter toutes les (très nombreuses) dépendances viendront avec.

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:

1. Les démons spamass-milter et spamd sont actifs:

   systemctl status spamass-milter
   ● spamass-milter.service - LSB: milter for spamassassin
        Loaded: loaded (/etc/init.d/spamass-milter; generated)
        Active: active (running) 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 /var/spool/postfix/spamass/spamass.sock -u spamass-milter -i 127.0.0.1
   
   systemctl status spamd
   ● spamd.service - Perl-based spam filter using text analysis
        Loaded: loaded (/usr/lib/systemd/system/spamd.service; enabled; preset: enabled)
        Active: active (running) since Fri 2025-05-09 17:51:22 CEST; 1h 33min ago
        ...
       spamd: server started on IO::Socket::IP [::1]:783, IO::Socket::IP [127.0.0.1]:783 (running version 4.0.1)
       ...
   

1. Configurer Postfix en ajoutant ces lignes à main.cf:

   milter_protocol = 6
   milter_default_action = accept
   non_smtpd_milters = $smtpd_milters
   
   # spamass-milter configuration
   smtpd_milters = unix:/spamass/spamass.sock
   # 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} _
   
   

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.

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»:

En affichant les traces , nous retrouvons:

[2025-05-12 18:00:32] ESMTP> MAIL FROM: SIZE=430
[2025-05-12 18:00:32] SMTP< 250 2.1.0 Ok
[2025-05-12 18:00:32] SMTP> RCPT TO:
[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 .
[2025-05-12 18:00:32] SMTP> . (EOM)
[2025-05-12 18:00:32] SMTP< 550 5.7.1 Blocked by SpamAssassin
** erreur pendant la session SMTP
*** Une erreur est survenue pendant l'envoi du message :
550 5.7.1 Blocked by SpamAssassin

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:

X-Spam-Status: No, score=-0.2 required=15.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,SPF_HELO_NONE,SPF_PASS
	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

Reste à faire de même avec notre MTA.

“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²⁾

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.

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:

1. l'émetteur du message a une adresse @exemple.tld. Il envoie ce message @autrexemple.tld
2. Il utilise un MTA sortant légitime pour le domaine exemple.tld.
3. 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 ?

1. untel@home.nain-t.net envoie un message à untel@gmail.com. Pour ce faire, il utilise son MTA: mail.home.nain-t.net.
2. Le message arrive sur le MTA du destinataire.
3. 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.

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:

Return-Path: <printing7@printingpress.xicp.net>
Delivered-To: prof@nain-t.net
...
From: "admin@hongchengco.com" <admin@hongchengco.com>
Subject: Various styles of Jersey and sneakers for you
To: irp@nain-t.net
...
Reply-To: admin@hongchengco.com
...

“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.

“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.