Port 25 bloqué pour spam à répétition

Salut,

Au lieu de tout répéter, je me permet de vous proposer une petite lecture : ce lui là :
https://community.ovhcloud.com/community/fr/detection-spam-vps?id=community_question&sys_id=8314390cfd9e8e902d4c483e6acd5141
qui date d'un jour ou deux.


édit : VPS, dédié, KS, SYS, c'est pareil.

Merci pour votre réponse. J'avais en effet vu ce thread. Par contre je ne trouve pas d'autre processus que postfix utilisant le port 25 :

$ sudo lsof -i tcp:25
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
master 28451 root 13u IPv4 7407995 0t0 TCP *:smtp (LISTEN)
master 28451 root 14u IPv6 7407996 0t0 TCP *:smtp (LISTEN)

Soit il n'y a rien, soit c'est quelque chose qui utilise le port ponctuellement.

Clamscan ne donne rien non plus :

----------- SCAN SUMMARY -----------
Known viruses: 10149836
Engine version: 0.99.2
Scanned directories: 1
Scanned files: 32
Infected files: 0
Data scanned: 53.68 MB
Data read: 4.58 MB (ratio 11.71:1)
Time: 336.432 sec (5 m 36 s)

Plusieurs éléments :
- que donne la file d'attente du serveur ?
- tu as retrouvé le message-id dans tes logs pour juger de la pertinence du mail ?
- est-ce que tu nettoies les adresses qui ne fonctionnent plus de tes listes ?

J'ai des messages en queue :

$ sudo mailq
-Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient-------
550FF4EC2B1B* 48367 Sun Feb 25 18:48:53 bounce+contact==a==13flo.com==liste@xxx.org
contact@13flo.com

6E6E64EC280D* 35220 Sun Feb 25 18:47:39 bounce+ritow==a==mail.com==liste@xxx.org
ritow@mail.com

87AB34EC2B55* 48364 Sun Feb 25 18:48:58 bounce+ritow==a==mail.com==liste@xxx.org
ritow@mail.com
…
-- 529 Kbytes in 12 Requests.

Ces messages sont suspects en effet.


Le mail en question est passé par la modération et je l'ai fait passer. Il n'a rien de suspect. Il a d'ailleurs été scanné par le serveur de mon adresse e-mail (à laquelle j'ai reçu le mail car abonné à la liste) et il a l'air clean :

X-xxx-MailScanner-Information: Please contact the ISP for more information
X-xxx-MailScanner-ID: w1PK4EQc022409
X-xxx-MailScanner: Found to be clean
X-xxx-MailScanner-From: liste-owner@xxx.org
X-Spam-Status: No

Merci pour votre réponse. J'avais en effet vu ce thread. Par contre je ne trouve pas d'autre processus que postfix utilisant le port 25 :

$ sudo lsof -i tcp:25
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
master 28451 root 13u IPv4 7407995 0t0 TCP *:smtp (LISTEN)
master 28451 root 14u IPv6 7407996 0t0 TCP *:smtp (LISTEN)

Ce que tu liste la, c'est des process à l'écoute, autrement dit ceux pour recevoir des mails. Les smtpd ou smtp daemons.
Ces process ne s'occupent pas de la transmission d'un mail vers les destinataires en dehors de ton serveur.
"master" est le process maître de postfix.

Tout mini script perl PHP ou autre, programme, peut choper un porte de sortie puis s'adresser au [destination] porte 25 pour envoyer un mail - puis s'arrêter quelques mille seconds après quand le boulot est fait.

Coupe ton serveur web pour mieux voir.
Soit : un règle parfeu qui bloque toutes les connections vers une destination TCP, porte 25.

Puis, sache que ton "engin de spam embarqué" ne va pas utiliser ces mails par un filtre spam/virus. Il l'adresse diretc (jusqu'à OVH va te bloquer pour de bon, ou ton IP sera tellement listé sur toutes les blacklists que plus personne accepte des mail de ton serveur.

Je regardais ce qui était demandé dans le thread en question.

Si je coupe mon serveur web, je verrai mieux quoi ? Je ne peux pas le couper comme ça « pour voir »
Je ne veux pas non plus bloquer les mails entrant et sortants vu que je les utilise.

Qu'est-ce que l'« engin de spam embarqué » ? Un script potentiellement sur mon système qui envoie des mails par mon postfix ? OK mais comment je peux le repérer concrètement ?

Ce que je vois de suspect c'est des erreurs dans fail2ban.log :

2018-03-01 15:47:40,324 fail2ban.action [4727]: ERROR iptables -w -n -L INPUT | grep -q 'f2b-sshd[ \t]' -- stdout: b''
2018-03-01 15:47:40,325 fail2ban.action [4727]: ERROR iptables -w -n -L INPUT | grep -q 'f2b-sshd[ \t]' -- stderr: b''
2018-03-01 15:47:40,326 fail2ban.action [4727]: ERROR iptables -w -n -L INPUT | grep -q 'f2b-sshd[ \t]' -- returned 1
2018-03-01 15:47:40,327 fail2ban.CommandAction [4727]: ERROR Invariant check failed. Trying to restore a sane environment
2018-03-01 15:47:40,447 fail2ban.action [4727]: ERROR iptables -w -D INPUT -p tcp -m multiport --dports ssh -j f2b-sshd
2018-03-01 15:47:40,448 fail2ban.action [4727]: ERROR iptables -w -D INPUT -p tcp -m multiport --dports ssh -j f2b-sshd
2018-03-01 15:47:40,450 fail2ban.action [4727]: ERROR iptables -w -D INPUT -p tcp -m multiport --dports ssh -j f2b-sshd
2018-03-01 15:47:40,451 fail2ban.actions [4727]: ERROR Failed to execute unban jail 'sshd' action 'iptables-multiport' info '{'time': 1519915060.1248522, 'failures': 5, 'matches': 'Mar 1 15:37:34 xxx sshd[754]: Invalid user admin from xxx.xxx.xxx.xxx port 53831Mar 1 15:37:34 xxx sshd[754]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=xxx.xxx.xxx.xxxMar 1 15:37:36 xxx sshd[754]: Failed password for invalid user admin from xxx.xxx.xxx.xxx port 53831 ssh2Mar 1 15:37:39 xxx sshd[761]: Invalid user support from xxx.xxx.xxx.xxx port 60403Mar 1 15:37:39 xxx sshd[761]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=xxx.xxx.xxx.xxx', 'ip': 'xxx.xxx.xxx.xxx'}': Error stopping action

Ça suggère que j'ai une mise à jour des règles qui s'est mal passé. Je n'ai pas vérifié ça après une mise à niveau du système.
Edit : c'est peut être juste que j'ai relancé mon firewall alors que des IP étaient bannies par failban.

Si je coupe mon serveur web, je verrai mieux quoi ? Je ne peux pas le couper comme ça « pour voir »
Je ne veux pas non plus bloquer les mails entrant et sortants vu que je les utilise.

"Arrêter ton serveur web" : que pour prouver que c'est lui qui est responsable pour l'envoi des mails.
Faut pas faire pendant des jours - semaines. Il faut rapidement localiser "le code" puis le supprimer ET localiser la fuite qui a permis la contamination.

Qu'est-ce que l'« engin de spam embarqué » ? Un script potentiellement sur mon système qui envoie des mails par mon postfix ? OK mais comment je peux le repérer concrètement ?

Un script oui, exécuté par Apache ou nginx.. Mais ce script, il n'est pas fou, il ne va pas passer par ton serveur mail (pour que tu le détecte facilement ? ha-non !) Ce script envoi direct. (et non, il ne passe par par ton filtre anti-spam non plus - lol)
Pour repérer, coup ton serveur web. Constate que l’envoi des spams s'arrête. Puis, allume-la et traite site par site. Vire toutes les plugins et extension - supprime manuellement leur répertoires d'installation - les fichiers qui reste après dé-installation est souvent une bonne preuve qu'il ne s'agit pas des fichiers du le-dit plugin mais des fichiers "spammeur" généré après.
Comme j'ai dit souvent : par exemple, WordPress (CMS) lui même, c'est du quasi béton. Ces extensions et plugins : t'as du chopper une merde.

Sache qu'OVH a le droit a tout moment de bloquer la possibilité que tu utiliser tout portes 25 (serveur mail destinataires) à tout moment : ton serveur ne pourrait plus envoyer des mails et devient donc inutile (sauf si tu passe par ton ISP, ou gmail, mais eu aussi, ils font rapidement te tirer par l’oreille si tu canarde des tiers avec des spams).

Pour localiser quel script envoi et mail, et comment, ce n'est pas hyper sorcier. Il n'existe pas mille possibilités.
Déjà ceci :
grep -R "mail(" /chemin/vers/ton/racine/site/*
va te donner une indice - beaucoup de faux positif, bien sur, mais tout ces points peuvent être vérifié avec le code source de ton site web (Github et autres).
Si t'as un plugin ou extension qui utilise la fonction mail() de PHP c'est déjà très suspect.

Pense aussi à mettre en place ce genre d'outils :
https://www.1domaine.fr/munin/papy-team.org/www.papy-team.org/index.html#postfixdomaine.fr/munin/papy-team.org/www.papy-team.org/index.html#postfix
Ça me permet de voir très rapidement s’il il y a quelque chose de suspect.
Par exempla, même en traitent des milliers des mails sortent / entrant par jour, le queue de postfix doit rester vide. ET SI un mail est présent dans le queue, il s'agit souvent un mail qui patiente car le serveur en face utilise une sorte de grey listing https://www.1domaine.fr/munin/papy-team.org/www.papy-team.org/postfix_mailqueue.htmldomaine.fr/munin/papy-team.org/www.papy-team.org/postfix_mailqueue.html

Edit : c'est peut être juste que j'ai relancé mon firewall alors que des IP étaient bannies par failban.

fail2ban est utile pour des tentatives de connexions sur des portes 22, 465, 587 etc avec un
Normalement, les spams n'entre pas comme ça - car dans ce cas c'est postfix qui le traite - donc très visible dans son log.
Ce qui traite fail2ban est un autre 'soucis' : j'en ai des milliers : https://www.1domaine.fr/munin/papy-team.org/www.papy-team.org/fail2ban.htmldomaine.fr/munin/papy-team.org/www.papy-team.org/fail2ban.html
Déjà la porte 22 (SSH) de ton serveur : désactive ton méthode de authentification par mot de pas. Utilise des clés public/privé et le soucis n'existe plus.

Le problème est que je ne vois pas de flux de spam. En fait la queue est toujours vide. J'avais quelques messages au moment où j'ai répondu à un message. Mais depuis je l'ai vidée et quand je vérifie elle est vide.

Bref si je ne remarque pas de spam sortant, ça ne sert à rien de couper mon serveur web parce que je ne saurait pas quoi vérifier. J'ai fait des recherches de fonctions mail, et ça a l'air clean.

Je veux bien que OVH me coupe mon port 25 s'il estime que j'envoie du SPAM. Mais j'aimerais bien plus d'informations que « Spam score: 300 ». En l'occurrence les messages en question sont des messages de mailing list, que j'ai personnellement modérés et qui ne contiennent pas d'informations pouvant éventuellement être considérées comme du spam. Ou alors il faudra me dire quoi exactement.

Les adresses de ta mailing list sont TOUTES bonnes ?

Qu'appelles-tu « bon » ? Rien ne me semble d'être des adresses bidon. Mais ça c'est pour la réception.

D'ailleurs en l'occurrence, les messages signalés par OVH sont des messages envoyés par postfix vu que ce sont des messages de mes mailing lists.

Le problème est que je ne vois pas de flux de spam. En fait la queue est toujours vide. J'avais quelques messages au moment où j'ai répondu à un message. Mais depuis je l'ai vidée et quand je vérifie elle est vide.

Tes 'vrais' mails à toi, oui.
Sur ton serveur, il y a beaucoup des programmes et services, et il n'y pas de "loi" qui dise qu'ils sont obligé d'utiliser ton serveur mail pour transmettre des mails.
Ils ouvrent un adresse IP et porte 25 pour le transmettre directement. Ils n'ont pas besoin de utiliser la fonction 'mail()' de PHP - ils peuvent, et normalement, mail() utilise postfix - mais ce n'est pas une obligation non plus.
Ce qui explique pourquoi que coté postfix (les logs) il n'y rien à voir de suspect.

Ou alors il faudra me dire quoi exactement.

Concrètement : car c'est toi qui a choisi d’utiliser un serveur qui peut le faire. (preuve : coupe le serveur : l'envoi des spams s'arrête)
Autrement dit : ton choix de programmes ou scripts sur ce serveur (preuve : enlève les programmes et services et l'envoi s'arrête).
Puis, un "tiers" est passé, a détecté une faille, upload son scripts à lui, puis il utilise ton serveur pour envoyer ces mails (il est payé pour le faire - ça rapporte pour lui un revenu).
A toi de choisir des scripts sans failles, à toi de lui f*utre dehors.

OVH ne va pas te démontrer quel programme ou quel script à envoyé ces mails "score 300", ils n'ont pas le droit de toucher ton serveur, c'est au admin (toi) de le faire, ça fait partie de son boulot.

Pour prouver que ton serveur transmet bien des mails, même si le log de postfix te dit que non : ajoute ceci à ton parafeu :
`iptables -I OUTPUT-p tcp -m tcp --dport 25 -j ACCEPT`
Ce règle ne fait rien en fait - il s'applique quand un pacquet sort de ton serveur avec destination une porte 25, autrement dit : un serveur mail "destination".
Maintenant, patiente un peu, puis, régulièrement :
` iptables -L OUTPUT -nvx`
T'auras ceci comme résultat - c'est le compteur 'pkts' qui nous intéresse :
Chain OUTPUT (policy ACCEPT 3111 packets, 1341922 bytes)
pkts bytes target prot opt in out source destination
18 1610 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:25
Le compteur "pkts" augmente chaque fois des mails sortent de ton serveur !!
Si au même moment postfix n'a rien envoyé - son log ne otre pas de trace d'envoi, t'as le preuve qu'un autre processus que postfix "parle" aux IP's, destination quelconque, porte "25" (donc : des mails sortent).
Ceci prouve que t'as un autre processus que postfix qui transmets des mails.

D'ailleurs en l'occurrence, les messages signalés par OVH sont des messages envoyés par postfix vu que ce sont des messages de mes mailing lists.

Donc le filtre spam d'OVH ( https://www.vadesecure.com/fr/ ) n'aime pas tes mails ?! A toi de les présenter pour qu'ils passent 'mieux' ;)

J'ai des bases en réseau, je sais comment un script peut envoyer un mail sans passer par postfix. Je ne fais que tester les pistes que l'on me donne.

Pour le moment le souci est bien qu'à part mes messages de mailing list, je ne vois rien sortir. J'ai ajouté la règle iptables, et pour le moment tout est à 0. Je vais laisser tourner quelques heures, quelques jours… et je verrai. Je surveillerai quand un message passera sur les listes.

Donc le filtre spam d'OVH ( https://www.vadesecure.com/fr/ ) n'aime pas tes mails ?! A toi de les présenter pour qu'ils passent 'mieux' ;)

Je trouve ça gonflé comme solution. Il s'agit de mailing lists. Les posteurs écrivent les mails comme ils le souhaitent, je ne vais pas donner des consignes non plus… Ce sont des e-mails d'une association, les posteurs sont des professionnels, il n'y a rien de « pas présentable ». Ou alors j'aimerais qu'OVH me donne ses critères de « présentabilité ». Parce que de ce que j'ai vu pour le moment, ils perturbent mon service sans raison valable.

Bonjour,

J'ai personnellement le même problème, avec une mailing liste de 200 000 inscrits envoyés 4 fois par mois, je viens de faire une migration sur une autre machine SYS, je n'ai jamais eu de problèmes de ce genre en 14 ans, et là avec le nouveau serveur (nouvelle IP) je suis bloqué et détecté comme SPAM, la semaine dernière sur l'ancien serveur encore tout était ok, mais ça bloque !!

Il y a t-il un moyen de contacter un admin qui gère l'antispam ? car au support je n'obtiens aucune satisfaction quant à la résolution du problème de notre dédié SYS : je ne peux plus envoyer nos newsletters à mes abonnés (200 000) à cause de la nouvelle IP qui m'a été attribuée ! et ça va commencer à devenir un vrai problème

72h après toujours pas de résolution du problème, si ça avait une grande boite le problème aurait été réglé dans l'heure

Depuis 12 ans chez OVH, on change d'IP, on envoit notre 582ème newsletter et là bam, port 25 bloqué pour SPAM : réponse du support: refaites vous une réputation ! notre réputation existe déjà depuis 12 ans !

c'est quoi ce droit de vie ou de mort sur une société ? si j'étais un SPAMMEUR cela ferait belle lurette que les gmail, hotmail, yahoo & consorts refuseraient nos mails ! personne n'a attendu OVH pour faire la chasse aux vrais spammeurs, c'est purement arbitraire

J'ai abandonné l'idée d'obtenir de l'aide sur ce sujet.

quand je vois l'épreuve du combattant que je suis en train de traverser juste pour être réhabilité dans mon droit je comprends, tu as sans doute raison, je n'abandonnerai pas

Quand on a une IP qui est clean et qui nous sert à envoyer pas mal de mail, il faut la garder à tout prix !
C'est pourquoi, il est important de travailler avec une IP fail over, que vous pouvez déplacer d'un serveur à un autre.
Là, vous semblez être bloqué par OVH, pour une raison plus ou moins obscure.
Mais vous pourriez tout aussi bien être bloqué par les destinataires ou systèmes antispams divers, justement parce que votre nouvelle IP n'a aucune réputation et envoie en masse. (pire, votre IP a une très mauvaise réputation du fait des propriétaires précédents).
Ca ne résoud pas votre problème, mais il faut y penser, pour la prochaine fois que vous changerez de serveur, sinon, ça recommencera.

Votre réputation personnelle n'a rien à voir là-dedans, seule la réputation de l'IP est en jeu.
Quand on a une nouvelle IP, il faut commencer par envoyer très peu de mails, puis augmenter peu à peu. Comme si on avait une nouvelle activité qui croît.

Oui effectivement je pourrais être bloqué par d'autres, mais si cela était le cas, je pourrais débloquer la situation facilement vu que je ne fais pas de SPAM, nous sommes inscrits à tous les FBL, nous avons une base opt-in et clean réalisée au fil des années, nous n'envoyons pas de marketing, juste notre newsletter, et OVH bloque le port pour mass mailing, mais laissez les prestataires SMTP bloquer nos mails si ce sont des SPAMS ! on a envoyé une newsletter à 200 000 inscrits par semaine depuis 12 ans avec les infrastructures OVH, on a changé 4 fois de serveurs, pas le moindre soucis et aujourd'hui, arbitrairement ils nous bloquent et mitigent notre port 25 ! Se refaire une réputation alors que tout a toujours été parfait c'est mettre en péril un société par pure bêtise, car il s'agit bien d'un disfonctionnement de leur antispam à OVH, le technicien au téléphone m'a dit qu'il pensait que je ne faisais pas de SPAM, la situation est ubuesque et pour le moment je n'arrive pas à avoir accès à un superviseur ou un médiateur, le support est tout puissant

la réputation de notre IP même quand elle change on s'en occupe très bien, on envoit des newsletters par petits paquets, domaines par domaines, au 200 ème mail le port est bloqué par OVH, vous voulez qu'on attende quoi sérieusement

Bonjour,

dans ce cas précis le plus simple est de passer par Twitter et d'expliquer le tout à @olesovhcom (https://twitter.com/olesovhcom/with_replies) par DM.

Comme ça au moins cela pourra peut être servir à ajuster vaderetro côté OVH pour ce genre de usecase ou tout simplement peut être avoir une explication de ce qui déclenche le (faux)positif et une correction d'une ou des deux parties concernés.

Cordialement, janus57

Merci pour ton conseil et pour le temps consacré à nous aider, je vais essayer

on ne peut pas lui envoyer de message, il faut qu'il nous suive

Bonjour,

suffit de lui écrire en public avec un bref résumé du problème et de comment cela impacte votre société, si c'est pas lui qui demande des explications en DM c'est pratiquement sûr qu'un corp OVH avec un certain niveau d'accès vous contacte (un peu comme les corp qui passent sur le forum qui sont bien souvent des N3 voir chef de services).

Cordialement, janus57

J'ai déjà interpellé l'équipe depuis plusieurs jours sur twitter, rien ne se passe, je dépends de OVH canada, j'avais un serveur à OVH EU (RBX1) que j'ai du fermer pour bouger aux amériques mais avec toujours un serveur en europe à GRA1, car ils n'ont pas été capable de transférer mon contrat sur l'autre entité OVH Canada (on parle de paperasse... c'est pour dire) donc j'ai subi en quelque sorte une migration forcée vers un nouveau serveur et nouvelle IP, le support FR de Montréal sont très gentils au téléphone, mais ne savent pas résoudre mon problème, et me disent qu'ils répondent à mon billet une fois que j'aurai raccroché mais ne le font pas, le support FR en France comprend mon problème mais ne peuvent pas m'aider car je dépend de OVH canada, le serpent qui se mord la queue, le pot de terre contre le pot de fer, etc etc...

Bonjour,

sauf que généralement c'est pas la même quand octave s'en mêle (sur le côté technique).

Pour le côté paperasse c'est parce que les entités OVH EU/CA/UK/US sont indépendant niveau BDD client (et plus encore pour US qui est une société à part).

Cordialement, janus57

OVH est une grande boite qui a beaucoup de succès mais qui grandit trop vite et ça entraîne des lacunes, à tel point que dans des situations pareilles, si vous ne vous appelez pas cdiscount, ou que vous n'avez pas un pote à OVH, ou que vous n'avez pas souscrit au support VIP à 49 € HT/mois, vous pouvez agoniser la bouche ouverte pendant longtemps, depuis 2004 que j'ai des dédiés chez eux (j'étais chez ikoula avant) je n'avais pas eu trop à m'en plaindre, mais c'est comme avec les assurances, tout va bien jusqu'au jour où vous devez la faire jouer...

Pour le côté paperasse, j'ai du me séparer d'un autre dédié, j'en ai gardé qu'un seul, dommage, un simple transfert à la date du renouvellement de contrat aurait suffit, puisque les serveurs ne bougent pas...

Tout veut être controlé par des machines, des logiciels, mais quand il y a des erreurs, il faut que des humains les corriges derrière, on ne peut pas tout déshumaniser, alors j'attends...

C'est quand même un comble qu'ils nous bloquent notre port 25 à cause d'une IP à mauvaise réputation qu'ils nous donnent.
Quant au support par Twitter par lequel on doit écrire des messages publics… c'est le top de la confidentialité. Peut être qu'une startup a d'autres choses à communiquer sur son twitter que des problèmes de serveur…

Oui, je me suis entendu dire plusieurs fois par le support "refaites vous une réputation" n'envoyez plus votre newsletter pendant un certain temps etc... ! incroyable... on travaille dans les bons plans et on a loupé la période du début des soldes à cause d'eux ! notre ndd, notre site a déjà sa réputation depuis 12 ans, notre activité l'est, ils ne veulent pas toucher à leur censure de filtre, pour eux du mass mailing aussi légitime soit-il passe en SPAM 300, leur logiciel vaderetro a toujours raison

Moi c'est pour une mailing list d'association. Quelqeus centaines d'abonnés. Tu parles d'un spam…

SPAM = Envoi répété d'un message électronique, souvent publicitaire, à un grand nombre d'internautes sans leur consentement

ce qui n'est pas notre cas, ni le vôtre, c'est une censure complètement abusive dont nous sommes victimes

Thomas, le support (une autre personne encore) m'a contacté suite à mes nombreux messages et a semble t-il pris mon problème au sérieux, je lui ai envoyé 2 EML (que j'avais déjà envoyé pourtant à un autre membre du support) et m'a dit aujourd'hui que le problème est réglé, il m'a été dit que le système avait établi des règles sévères à tort, je constaterai le bon fonctionnement ou non lors de l'envoi de ma prochaine newsletter, je te conseille alors de perdurer dans ta démarche via le manager pour obtenir gain de cause, merci aux autres

Dans le cas de gros mailings, il est impératif de traiter l'intégralité des bounces pour être certain de ne toucher que des adresses valides. Ce qui sous-entend que :
- le mail doit partir avec un from valide
- la boite correspondante au from doit exister
- des traitements doivent prendre tous les bounces pour désinscrire les boites à problème.

Sous peine de se faire tagger comme un mauvais élève.

Bonjour, je traite nos bounces après chaque envoi, notre base est clean, et nous sommes inscrits aux FBL qui existent. Nous ne sommes pas tagué par les serveurs SMTP (free, hotmail, gmail, yahoo etc...) mais uniquement par principe par OVH qui ne voulait pas ajuster son filtre, ils ont reconnu leur erreurs après de nombreux mails, appels, etc... et jours de relance, je commence actuellement des tests pour vérifier qu'ils ont bien fait le nécessaire