Bonjour à toutes et à tous. Même problème que @ynhbaka et ce depuis des années (au sens propre), étant moi aussi chez OVH. Ca disparait puis réapparait beaucoup trop régulièrement sans vraiment savoir pourquoi.
J’ai 2 serveurs dans des domaines et endroits différents : un où j’ai trifouillé la config IPV4/IPV6/DNS/etc., et un autre laissé en config par défaut. Les 2 ont ce problème.
Certains emails importants n’arrivent pas à destination depuis ma boite mail, et d’autres provenant d’expéditeurs fiables tels que des adresses mails professionnelles ou des hotmail et qui n’arrivent pas dans ma boite mail. Idem pour les mails de double authentication (banques, etc.).
Ceci est si agaçant (surtout les mails importants) que je cherche un autre fournisseur qu’OVH. Si quelqu’un a une idée chez un concurrent aussi “propre” niveau confidentialité qu’OVH et chez lequel il ne rencontre pas de souci qu’il n’hésite pas svp, merci.
Quand j’ai rencontré ce souci, il y a deux ans, j’ai d’abord commenté la ligne renvoyant à spamhaus dans la configuration de postfix, mais cela revenait à désactiver partiellement le filtre antispam, donc solution efficace mais très provisoire et peu fiable.
J’ai modifié la configuration de postfix en suivant le tutoriel fourni par Spamhaus sur mon espace client DQS : Configuring DQS on Postfix — Spamhaus Technology Documentation 2.0 documentation et tout fonctionne parfaitement depuis, sur mes deux serveurs. Je n’ai plus d’erreur “open resolver” et le filtre anti-spam fonctionne ; une fois la modification faite, on peut d’ailleurs tester sa configuration ici : https://blt.spamhaus.com/ (accessible aussi depuis l’espace client Spamhaus à la fin de la mise en place du DQS).
L’inconvénient est qu’il faut surveiller les mises à jour de la configuration de postfix régulièrement avec regen-conf (edit : avec les arguments dry-run & with-diff), puisque qu’elle ne sera plus automatiquement mise à jour par Yunohost.
Merci pour ton retour. Ca m’intéresse vivement. Je comprends que tu as modifié le postfix de yunohost avec le tuto de Spamhaus. Qu’entends-tu par “surveiller les mises à jours de la configuration de postfix régulièrement avec regen-conf” ?
Je pensais que regen-conf permettait de regénérer un fichier de config (en l’occurence ici celui de postfix) mais cela viendrait à effacer la config de Spamhaus non ? J’ai dû mal comprendre quelque chose, merci
Toutefois, il faut utiliser regen-conf avec les arguments dry-run et with-diff, ce que j’ai oublié de mentionner dans mon précédent message. Ainsi, tu peux voir ce qui a changé entre ton fichier modifié manuellement et le fichier mis à jour par Yunohost.
Mais pas d’inquiétude, en deux ans, il n’a pas beaucoup changé ; c’est une habitude à prendre afin de ne pas passer à côté d’un nouveau réglage.
Pour faire marche arrière, c’est simple, supprimer le fichier puis relancer la dernière commande.
La configuration que j’ai donné n’est peut être pas exacte, dans mon main.cf les chaînes se terminent par une virgule (ce que je ne vois pas dans la config données par spamhaus) et la nouvelle directive rbl_reply_maps est insérée à la fin du fichier main.cf, je ne sais pas si c’est le bon endroit, ce n’est pas précisé, il faudra adapter au besoin. Pour ces 2 points si tu pouvais le préciser que je corrige si il y a erreur.
Pour le reste de la configuration (/etc/postfix/dnsbl-reply-map ), ce n’est pas touché par les mises à jours, aussi il suffit de suivre la documentation de Spamhaus.
Créer le hook, appliquer tout le tuto de spamhaus avant de lancer le regen-conf
Alors, j’ai testé le hook et ça semble fonctionner, au détail près qu’il faut indiquer smtpd_client_restrictions et non smtpd_recipient_restrictions pour que les paramètres de Spamhaus soient insérés au bon endroit dans le main.cf de postfix.
Ensuite, dans la configuration proposée par Spamhaus, il y a bien les virgules.
Enfin, j’ai ajouté une ligne pour retirer la mention à “zen.spamhaus.org” puisqu’il n’est plus nécessaire au vu du recours au service DQS et cela risquerait de produire des erreurs “open resolver”, ce que nous cherchons justement à éviter ici (je ne suis pas sûr que ce soit optimal, mais je n’ai pas trouvé d’autre commande pour le faire).
Donc, le hook corrigé donne ça ( modifier PERSONALKEY par la clé DQS fournie par Spamhaus") :
yunohost settings set email.antispam.enable_blocklists -v no
Suivi d’un :
yunohost tools regen-conf postfix
D’ailleurs ça me semble être un bug car il y a la même option (Activer les listes de blocages pour le traffic entrant) sur la webadmin à l’adresse https://domain.tld/yunohost/admin/#/tools/settings/email et le regen-conf ne se fait pas automatiquement ce qui devrait être le cas.
Pour remettre les listes de blocage, passer la valeur à yes au lieu de no.
C’est préférable d’utiliser cette commande plutôt que la suppression avec un sed, d’autant plus qu’il suffit de la passer qu’une fois. La commande suivante ne dois rien renvoyer avec l’utilisation du hook pour être sûr que les mises à jour du fichier se passent bien :
Le problème est que cette option désactive tous les filtres antispam, n’est-ce pas ? Or, ici, c’est uniquement Spamhaus qui nous embête.
Aussi, retirer la ligne qui fait référence à zen.spamhaus.org du main.cf de postfix permet de conserver les autres services antispam (en complément du DQS de Spamhaus).
Oui tu as raison, n’étant pas concerné par ce problème je n’ai pas regardé suffisamment en détail et cette commande retire bien tous les filtres antispam. Si tu souhaites conserver spamcop et seulement retirer spamhaus, ta méthode est la bonne. Si un yunohost tools regen-conf -n -d ne retourne rien après application du hook alors c’est tout bon, les mises à jour se feront bien et les modifications seront remises en place, plus besoin de surveiller ce fichier. Dans le doute, vu que tu retires la ligne spamhaus, il vaut mieux passer la commande yunohost settings set email.antispam.enable_blocklists -v yes avant pour être sûr que les filtres sont activés. Si ils ne l’étaient pas, il faudrait dans ce cas rajouter le filtre spamcop avec le hook au lieu de retirer la ligne spamhaus.
@Gwylohm : J’ai reporté l’ensemble des étapes dans le topic sur les hooks, n’hésite pas à le signaler si j’ai oublié quelque chose.
Merci beaucoup pour ce hook que j’ai adopté (après avoir cependant substitué smtpd_recipient_restrictions à smtpd_client_restrictions comme décrit dans la doc officielle de Spamhaus).
Les diagnostics Yunohost peuvent toujours indiquer par intermittence que les IPs sont sur liste noire de Spamhaus (notamment avec la fameuse mention ‘open resolver’). Par intermittence car ca dépend des volumes de requêtes envoyées à l’instant T à Spamhaus par tel ou tel serveur DNS ouverts/publiques utilisé par Yunohost.
C’est, si j’ai bien compris, tout à fait normal car d’une part les tests de Yunohost sont effectués à partir d’une liste dnsbl statique (/usr/share/yunohost/dnsbl_list.yml) - qui ne tient par définition pas compte des modifications faites par le hook - et d’autre part les tests sont bien effectués via des serveurs DNS ouverts/publiques (les serveurs DNS utilisés sont ceux listés dans /etc/resolv.dnsmasq.conf).
En définitive il faut donc dans ce cas précis - c’est à dire si et seulement si vous avez configuré le service DQS Spamhaus - ignorer les diagnostics Yunohost concernant les listes Spamhaus.
Dans le doute on peut toujours confirmer que les IPs de notre instance Yunohost ne sont pas sur listes noires (de Spamhaus ou autres) via les services en ligne de type https://mxtoolbox.com/. Mais ca ne détectera pas le problème de l’open resolver qui doit être traité soit avec le DQS de Spamhaus soit en utilisant un serveur DNS récursif (et non ouvert). La 1ère solution est plus facile à mettre en oeuvre.
PS: désolé de la longueur de ce message (il est proportionnel au temps mis à comprendre comment tout cela fonctionnait, interagissait et pourquoi il était normal de rester avec des diagnotics Yunohost en erreur).
NB : depuis les correctifs de il y a quelques semaines quand on a taffé sur le sujet après qu’il ait pris de l’ampleur, les requêtes DNS vers spamhaus sont maintenant faites “en direct” via les IP de spamhaus listées dans /etc/dnsmasq/spamhaus. Donc il n’y a plus d’intermédiaire DNS entre le serveur et spamhaus. Ça a résolu le problème pour beaucoup de monde, mais visiblement pas tous. On a identifié que Spamhaus refuse spécifiquement les requêtes venant de serveur OVH en IPv6. Et apparament d’autres providers dont je n’ai pas le nom - et peut-être pas que en IPv6 pour les autres. Donc c’est la merde.
Effectivement, la doc officielle de Spamhaus mentionne “recipient_restrictions”, toutefois, le fichier main.cf de postfix, dont on dispose sous YNH, place les requêtes de filtres antispam dans “client_restricitions” et non pas “reciption_restrictions”.
Je ne sais pas si cela fait une grande différence (car le test antispam de Spamhaus fonctionne aussi pour moi) mais je tenais à préciser pourquoi le hook mentionne “client_restrictions” et non “recipient_restrictions”.
s’expliquant par l’allocation par OVH d’une IP en ::/64.
Je pense que cette erreur peut-être elle aussi ignorée si et seulement si on paramètre Postfix pour n’envoyer qu’en IPv4. Mais elle sera toujours reportée par les diagnotics Mail de Yunohost (check_blocklist). Normal le code interroge Spamhaus explicitement pour l’IPv6 de l’instance Yunohost utilisée ou pas.
Oui c’est compliqué. Dans l’idéal pour l’erreur open resolver il faudrait avoir en local un serveur récursif (donc pas dnsmasq) ce qui est compliqué à mettre en oeuvre j’imagine (beaucoup de devs). À défaut peut-être compléter l’erreur remontée par Yunohost en ajoutant un petite phrase sur le moyen de résoudre le problème pour Spamhaus avec une URL vers le forum récapitulant la marche à suivre. Pas idéal non plus j’en conviens…
La différence concerne a priori seulement à quel stade de la transaction Postfix fait le contrôle (mais pas à quel stade il l’applique). Donc oui pas une grande différence dans les faits.
Avec ce que j’ai expliqué, je ne vois pas ce que ça changerait, ou alors je sais pas bien ce qu’est un serveur récursif… Les query DNS sont déjà faites en direct sur Spamhaus. Il n’y a pas de server DNS intermédiaire. Spamhaus refuse de répondre aux query de certains serveurs, basé sur des critères X ou Y style “cette IP est dans un bloc que j’aime pas”
Bon bein dans ce cas il n’y a plus comme solution soit d’utiliser leur Data Query Service (DQS) (solution retenue de mon côté pour le moment) soit de carrément supprimer Spamhaus de la config Yunohost. Resterait à voir si les dnsbl restantes sont suffisantes.
C’est de plus en plus compliqué d’auto héberger un serveur mail… mais c’est la raison pour laquelle je me tourne vers Yunohost en me disant qu’en mutualisant l’effort il sera moindre au final.
modifier PERSONALKEY par la clé DQS fournie par Spamhaus") :
