Suite à IPV6 blacklistage... et l'enfer commence ! A l'aide!

Support
,
1

Salut !

Je me suis mis en tête de configurer mon server VPS OVH avec yunohost en IPV6. Tout fonctionnait très bien… jusqu’à un blacklistage de spamhaus.org.

Ne parvenant pas à régler le soucis, j’ai fini par retirer l’IPV6 et le blacklistage de spamhaus a été levé.
Diagnostic yuno: https://paste.yunohost.org/raw/ecosewuxef
Retour de Gmail quand je tente de m’envoyer un mail par une adresse gmail: DNSBL Error Code - Open/public resolver - The Spamhaus Project

Maintenant, j’ai un soucis quand on m’envoie un email voici les retours:

Decision Engine classified the mail item was rejected because of IP Block (from outbound normal IP pools) → 554 5.7.1 Service unavailable; Client host [40.107.8.87] blocked using cbl.abuseat.org; Error: open resolver; DNSBL Error Code - Open/public resolver - The Spamhaus Project

554 5.7.1 Service unavailable; Client host [209.85.210.53] blocked using cbl.abuseat.org; Error: open resolver; DNSBL Error Code - Open/public resolver - The Spamhaus Project

Spamhaus m’assure que je ne suis pourtant plus blacklisté… et effectivement je fais des tests partout et ce n’est plus le cas…

Comment diagnostiquer le problème ? Merci de votre aide !

1 Like
2

(Adapté de Yunohost + messagerie - #10 by tituspijean)

C’est la faute de la configuration automatique des VPS d’OVH, qui injecte la ligne search openstacklocal ou nameserver <une ip DNS de OVH> dans ton /etc/resolv.conf.

J’ai désactivé ça, et le mien ne contient plus que nameserver 127.0.0.1, à part des lignes commentées.

J’avais essayé deux choses:

  1. La première, plus précise, est d’empêcher la modification de resolvconf.
Essai infructueux

Crée un fichier /etc/cloud/99-disable-resolvconf.cfg avec comme texte: manage-resolv-conf: false
Un redémarrage est conseillé pour s’assurer que c’est désactivé (en vérifiant le contenu de /etc/resolv.conf

Bon après l’avoir réessayé moi-même, ceci seule laisse un nameserver 213.186.33.99 qui est le DNS d’OVH… ça doit être une autre option, mais je ne sais pas laquelle.

  1. Désactivons complètement cloud-init avec touch /etc/cloud/cloud-init.disabled.
    Redémarre le système et vérifie. Attention, de mémoire j’avais dû reconfigurer à la main l’IPv6 (eh oui, c’est géré par le cloud-init), mais dans ton cas tu l’as désactivé. :wink:
3

Salut !
merci pour ta réponse.

  • J’ai tenté de commenter le nameserver dans resolv.conf … il se remet au reboot !

  • J’ai tenté de commenter et de rajouter le TOUCH, sans succès…

Est-ce que j’ai bien compris ton idée ?

SpamHaus me répond ça: https://check.spamhaus.org/ticketing/?a=ST3461075&b=0a9487da5d9b5cfd16879ef9ab1dc75e

4

Bon à ce stade, le seul moyen trouver pour recevoir des emails c’est d’éditer etc/postfix/main.cf
et commenter les lignes suivantes :

Requirements for the connecting server

smtpd_client_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_rbl_client bl.spamcop.net,
#reject_rbl_client cbl.abuseat.org,
#reject_rbl_client zen.spamhaus.org,

ça me débloque mais ce n’est pas idéal…

5

@ths
Pour protéger un fichier contre toutes modifications, tu peux utiliser chattr en tant que root.

chattr +i tonfichier

Pour permettre à nouveau la modification.

chattr -i tonfichier
6

Non, le fichier est géré par resolvconf, et sera écrasé régulièrement ou au redémarrage du serveur.
L’option avec chattr, je ne sais pas trop quoi en penser. Normalement /etc/resolv.conf est un lien symbolique, je ne sais pas ce que ça donne avec chattr.

Tu as bien redémarré? :thinking:

7

Salut
Je crois qu’il n’y a pas de solution pour l’instant car l’adresse IPv6 des VPS d’OVH n’est pas en /64
J’ai ouvert un incident chez OVH. Il m’a été répondu

Une discussion est en cours auprès de nos administrateurs quant à l’attribution de /64 sur VPS. Au vu du sujet, une communication sera faite dès leur décision prise.

J’ai vu que cette “discussion” est en cours depuis plusieurs années :frowning:
René

1 Like
8

L’erreur est celle-ci, et est uniquement liée à l’histoire du resolveur public. Ce n’est pas la même que pour la blocklist côté client qui risque en effet de rejeter l’IPv6 en /128 assignée par OVH si jamais une autre IP du même bloc /64 a une activité blacklistable.

Ma solution dans ce cas: ouvrir un ticket de support. Les “administrateurs” ne se bougeront que quand ils perdront des clients ou quand la charge sur le support client deviendra significative. En somme, il faut les faire travailler :slight_smile: et ça leur permet de détecter des serveurs aux activités dommageables.

9

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.