GuiGui's Show

Quand j'ai reçu un énième email semblant émaner de ma propre adresse emails et me réclamant du pognon pour ne pas dévoiler que je me pignole sur du porn, je me suis dit que, quand même, il doit exister un moyen de bloquer ça sans recourir à un antispam. Je m'en suis jamais préoccupé jusque-là car j'en reçois très peu, mais j'ai désormais du temps pour creuser la question, donc autant en profiter. \o/

Contexte : je n'ai pas d'antispam sur mon serveur emails personnel, pas besoin (il suffit de filer sa véritable adresse à des gens de confiance et de filer une adresse générique ‒ un alias ‒ ou la véritable en y ajoutant un délimiteur / tag aux autres, et surtout aux sociétés commerciales, aux windowsiens et aux listes de discussion archivées sur le web). J'ai un seul serveur emails pour mon domaine personnel. J’utilise le MTA Postfix.

Comme d'hab' avec l'email (et le courrier postal), il y a deux endroits où l'on peut mentir sur l'adresse de l'expéditeur : sur l'enveloppe (« MAIL FROM » dans un dialogue SMTP, ce que l'on peut lire dans le journal d'un serveur emails), et dans l'entête du courrier (ce qu'affiche un logiciel de messagerie ‒ MUA ‒).

Comme d'hab', il faut se souvenir que, peu importe l'expéditeur (toi ou un tiers qui veut t'écrire), c'est toujours le même démon qui répond du côté de ton serveur emails. Du coup, comment différencier les usages ? Si l'on ne différencie pas, on bloquera les emails que l'on émet…

Généralement, les emails transitent entre deux serveurs emails sur le port tcp/25 alors que les emails entre un humain est un serveur emails transitent sur le port tcp/587 que l'on nomme aussi submission (c'est ce qui permet de bloquer le port tcp/25 sur les accès à Internet dans l'espoir de juguler le spam).

Postfix permet d'associer un démon à un service (cela se passe dans son fichier de configuration master.cf) et de lui filer une conf' spécifique (sinon les X démons prendront les mêmes paramètres communs dans main.cf). Du coup, il suffit d'appliquer le filtrage sur le service smtp, mais pas sur le service submission.

J'ai déjà fait l'inverse, appliquer un filtrage particulier sur submission, afin de supprimer les entêtes ajoutés par mon logiciel de messagerie (sa marque, son modèle, sa version ‒ entête « User-Agent » ‒), par feu Enigmail (sa version), et celui ajouté par mon serveur emails pour consigner l'origine de l'email, c'est-à-dire l'adresse IP de ma station de travail.

Je sais donc déjà comment filtrer un entête dans un email. Je cherche une option de Postfix permettant de contrôler une adresse emails lors de la transaction SMTP (« MAIL FROM »). Le paramètre « smtpd_sender_restrictions » est là pour ça. Il a justement une valeur qui fait ce que je veux : « check_sender_access ».

Nous avons tout ce qu'il nous faut.

Contrôle de l'enveloppe

D'abord, je crée une table d'associations /etc/postfix/sender_access (le nom est libre) contenant « <MON_DOMAINE> REJECT ». Tu peux remplacer l'action « REJECT » par « DISCARD » qui permet de jeter l'email sans en informer l'expéditeur. La liste des actions possibles est dans la doc' officielle. Je génère ensuite le dictionnaire au format attendu : postmap /etc/postfix/sender_access.

Ensuite, dans /etc/postfix/main.cf, j'ajoute la valeur « check_sender_access hash:/etc/postfix/sender_access » au paramètre « smtpd_sender_restrictions ». Pour rappel, l'ordre des valeurs compte : un mauvais enchaînement peut autoriser des actions indésirées voire dangereuses (ouvrir un relai mondial de spam, par exemple).

Enfin, je débraye ce filtrage sur le service submission (sinon je ne pourrais plus envoyer d'emails). Je pourrais reprendre la liste des restrictions que j'applique déjà à l'adresse expéditrice d'un dialogue SMTP, mais pourquoi ne pas tout simplement interdire tout envoi d'email sans authentification préalable ? Simple et efficace. Pour ce faire, dans /etc/postfix/master.fr, je remplace la ligne :

submission inet  n       -       y       -       -       smtpd

Par les lignes :

submission inet  n       -       y       -       -       smtpd
    -o smtpd_sender_restrictions=permit_sasl_authenticated,reject

J'ordonne à Postfix de prendre en compte les modifications de sa configuration : systemctl reload postfix.

Je teste :

• que je peux toujours émettre des emails avec mon logiciel de messagerie ;
  
  
• que je reçois toujours des emails émis depuis un autre fournisseur d'emails ;
  
  
• qu'il n'est plus possible, pour un tiers, d'utiliser une adresse de mon domaine en « MAIl FROM ». Cela se fait avec telnet (pour rappel, un dialogue SMTP s'écrit en texte) ;
  
  
• que je n'ai pas ouvert mon serveur à tous les vents (« RCPT TO » hors domaine couplé à un « MAIL FROM » dans puis hors du domaine, « MAIL FROM » d'un domaine inexistant, etc., en fonction des vérifications que tu appliquais avant cette modif'). Vérif' à effectuer sur les ports tcp/25 et tcp/587.

Contrôle de l'entête

D'abord, je crée un fichier /etc/postfix/header_checks_smtpd (le nom est libre) contenant « /^From:.*@<MON_DOMAINE>/ REJECT » (même remarque que ci-dessus concernant les actions possibles). Oui, je pourrais ajouter un joker après l'arobase afin de bloquer tous les sous-domaines de mon domaine, mais c'est inutile : mon postfix vérifie l'existence d'un domaine émetteur (reject_unknown_sender_domain dans smtpd_sender_restrictions), donc il verra qu'un sous-domaine de mon domaine n'existe pas.

Ensuite, dans /etc/postfix/main.cf, j'ajoute le paramètre header_checks=regexp:/etc/postfix/header_checks_smtpd.

Attention : j'ai rien d'autre à faire, car j'ai déjà une vérification des entêtes spécifique au service submission. Sans cela, j'aurai appliqué le paramètre précédent au service « smtp » dans master.cf, pas en général dans main.cf. ;)

Enfin, j'ordonne à Postfix de prendre en compte les modifications de sa configuration : systemctl reload postfix.

Je teste :

• que je peux toujours émettre des emails avec mon logiciel de messagerie ;
  
  
• que je reçois toujours des emails émis depuis un autre fournisseur d'emails ;
  
  
• qu'il n'est plus possible, pour un tiers, d'utiliser une adresse de mon domaine dans un entête email « From » (avec telnet, toujours) ;
  
  
• que je n'ai pas ouvert mon serveur à tous les vents (« RCPT TO » hors domaine avec un « MAIL FROM » dans puis hors du domaine, « MAIL FROM » d'un domaine inexistant, etc.). Vérif' à effectuer sur les ports tcp/25 et tcp/587.

ÉDIT DU 09/07/2023 : quand tu envoies un email à une liste de discussion, tu reçois une copie de ta prose. Si la liste ne ré-écrit pas l'entête « From », alors cette copie sera bloquée. J'ai débrayé ce filtre depuis plusieurs mois, et il s'avère que le contrôle de l'enveloppe est amplement suffisant pour bloquer les spams évoqués au début de ce shaarli. FIN DE L'ÉDIT DU 09/07/2023.

ÉDIT DU 16/07/2023 : avec ma méthode, les emails locaux (émis par un site web, par exemple) destinés à un utilisateur local, pris en charge par les composants pickup ou local de Postfix, se feront rejeter. Ben, oui, je mets la restriction dans /etc/postfix/main.cf et j'ajoute une exception pour le seul service submission, donc, forcément, elle s'applique à tout sauf à submission. Dans mon cas d'usage, je m'en fiche, mais si t'as besoin de ce type d'emails, il te faudra appliquer la restriction uniquement au composant smtpd. Cela se fait dans master.cf, en calquant ce que j'ai fait pour submission. FIN DE L'ÉDIT DU 16/07/2023.

Conseil

Dans un premier temps, utilise une action « INFO "Blocage FROM" » (le message peut être personnalisé) pendant quelques jours. Ainsi, Postfix journalisera, en ces termes, les emails qui déclencheront ces nouveaux filtres sans les jeter. Une recherche dans le journal permettra de t'assurer que tout est OK avant la mise en prod' (action « DISCARD » ou « REJECT »).