Le récepteur de courrier perd la résolution IP en nom d'hôte après une récente mise à niveau et empêche le fonctionnement des mesures anti-spam

Il semble que la dernière mise à jour du récepteur de courrier (Self-hosted mail-receiver update following Let's Encrypt root certificate change) ne résolve plus les adresses IP en noms d’hôte. Cela provoque des problèmes avec les restrictions d’accès client postfix qui fonctionnaient auparavant, activées en ajoutant la ligne suivante à mail-receiver.yml :

  POSTCONF_smtpd_client_restrictions: 'regexp:/etc/postfix/shared/client_access_regex'

Voici un extrait du journal du récepteur de courrier, montrant une connexion entrante :

Oct 01 17:38:11 discourse-mail-receiver postfix/master[1]: reload -- version 3.5.6, configuration /etc/postfix
Oct 01 17:41:58 discourse-mail-receiver postfix/smtpd[151]: connect from unknown[167.71.160.115]
Oct 01 17:41:59 discourse-mail-receiver postfix/smtpd[151]: disconnect from unknown[167.71.160.115] ehlo=2 starttls=1 mail=1 quit=1 commands=5

Ce qui résolvait auparavant vers le nom d’hôte du client d’origine www11-do.checktls.com[167.71.160.115] est désormais non résolu et marqué unknown[167.71.160.115].

Cela entre en conflit avec les entrées de regex dans le fichier client_access_regex, conçu pour rejeter tous les hôtes sans enregistrement PTR valide (ce qui concerne essentiellement tous les relais de spam), ainsi que tous les hôtes provenant de plages d’adresses IP dynamiques (principalement des hôtes virtuels, et aussi essentiellement tous les relais de spam).

Puisqu’aucune adresse IP n’est résolue en nom d’hôte, aucune des règles ne fonctionne plus. Pire encore, la ligne /unknown/ REJECT bloque désormais tous les courriers entrants. J’ai dû désactiver temporairement la règle pour permettre les connexions entrantes, et toutes les autres règles sont rendues inactives par le problème de résolution. Cela expose à nouveau le serveur au spam (mon forum était inondé de spam avant la mise en œuvre de ces règles, et depuis leur mise en place, je ne me souviens plus avoir reçu le moindre message).

Je ne peux pas revenir à l’ancienne version comme solution de contournement (en raison des problèmes liés à Let’s Encrypt), et la nouvelle version rouvre les vannes du spam. Je serais donc très reconnaissant si une correction était apportée (j’ai essayé de trouver comment activer manuellement la résolution DNS à l’intérieur de l’image Docker, mais sans succès).

Voici un fichier client_access_regex à titre de référence, au cas où quelqu’un rencontrerait les mêmes problèmes récurrents de spam et souhaiterait l’essayer (utilisez Customize direct-delivery Postfix configuration pour configurer /etc/postfix/shared et mail-receiver.yml) :

#  regex dns: ([a-zA-Z0-9]+(-[a-zA-Z0-9]+)*\\.)+[a-zA-Z]{2,}
#  regex ip: ((25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\\.){3}(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)
#
#  dyn-ip-dns:
/((\\.|-|x)(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)){2}((\\.|-)[a-zA-Z0-9]+)+\\.[a-zA-Z]{2,}/        REJECT
/unknown/                               REJECT
/sample-spam\\.domain\\.com/              REJECT

J’ai résolu ce problème pour un autre conteneur. Il suffit de commenter le mauvais certificat et tout fonctionne, mais je ne suis pas sûr de savoir comment relancer l’ancien conteneur.

La solution consiste à entrer dans le nouveau conteneur et à résoudre le problème.

https://github.com/discourse/mail-receiver/pull/12

@david Cela devrait résoudre les deux problèmes mentionnés dans Self-hosted mail-receiver update following Let's Encrypt root certificate change - #6 by md-misko

Veuillez évaluer si la suppression de postfix de la chroot jail introduit des problèmes de sécurité (selon moi, cela ne devrait pas, car postfix est déjà isolé dans une image docker dédiée).