ISP /pas/ blacklisté par Free? :-)
Gilles Ganault
Comme mon hébergeur est incompétent à solutionner le problème de ses
MTAs blacklistés chez Free... je suis obligé de déplacer mes domaines
ailleurs.
===
host mx1.free.fr [212.27.48.7]: 500 Too many spams from your IP (
66.7.206.79), please visit http://postmaster.free.fr/
===
Connait-on les hébergeurs qui ne risquent pas de connaître ce genre de
plaisanterie, de préférence à des prix accessibles aux particuliers?
Merci.
Mickaël Wolff
> Connait-on les hébergeurs qui ne risquent pas de connaître ce genre de
> plaisanterie, de préférence à des prix accessibles aux particuliers?
Très franchement, tout le monde peut être à la merci d'un tel
blacklisting. Maintenant, il y a des comportements qui permettent de
diminuer ce risque... mais personne ne peut garantir qu'il ne sera
blacklisté par Free ou un autre.
Même avoir son serveur dédié ne permet pas d'être certain à 100 % de
ne jamais être banni.
Remarque que ce n'est certainement pas la faute de ton ISP, c'est
peut-être Free qui n'est pas réactif. Enfin, si tu expliquais mieux le
problème que tu souhaites éviter, on pourrait plus t'aider.
Surtout si c'est toi qui est responsable du blacklistage :p Ou un
abonné à une de tes éventuelles listes qui a oublié qu'il était abonné, etc.
Cordialement, Mickaël.
--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org
Gilles Ganault
<mickae...@laposte.net> wrote:
> Maintenant, il y a des comportements qui permettent de
>diminuer ce risque... mais personne ne peut garantir qu'il ne sera
>blacklisté par Free ou un autre.
Puisque, comme d'hab, Free est un trou noir niveau information (les
boîtes n'ont pourtant que le mot "transparence" à la bouche...), on ne
peut que faire des hypothèses, mais j'imagine que le simple fait de
limiter l'envoi de mails/seconde doit déjà réduire le risque.
Quelqu'un sait si les filtres anti-SPAM type Bayerisien sont très
coûteux en CPU et/ou à acheter si pas de bonne solution en
open-source? Ca expliquerait pourquoi mon hébergeur ne se bouge pas le
Q.
> Remarque que ce n'est certainement pas la faute de ton ISP, c'est
>peut-être Free qui n'est pas réactif. Enfin, si tu expliquais mieux le
>problème que tu souhaites éviter, on pourrait plus t'aider.
Je ne suis pas le seul à avoir le problème : il semble que Free a
décidé récemment d'installer un système de blacklisting temporaire et
perso (il a sa propre DB, pas RBL etc.). Un MTA qu'il considère comme
spammeur est blacklisté automatiquement pendant quelques heures.
Résultat, quand un contact t'envoie un mail à un domaine hébergé chez
un hébergeur blacklisté, il se prend un message d'erreur, mais toi, tu
n'es pas averti du fait :-/
Ca ressemble à ça:
====
host mx1.free.fr [212.27.48.7]: 500 Too many spams from your IP (
66.7.206.79), please visit http://postmaster.free.fr/
====
Pénible.
manu free
>mon hébergeur est incompétent à solutionner le problème de ses
>MTAs blacklistés chez Free... je suis obligé de déplacer mes domaines
>ailleurs.
Si Free est blacklisté par l'hébergeur, vous allez aussi dire que
c'est sa faute car il est 'incompétent à solutionner le problème'
Toujours la faute de l'hébergeur ... cela ne changera donc jamais ?
C'est comme l'histoire du SMTP chez Wanadoo/Free, c'est aussi 'l'hébergeur
qui est incompétent à solutionner le problème'
Bien sur, vous vous dite 'cela à toujours fonctionné ainsi, donc je ne
change rien et à l'hébergeur de trouver une solution'
Curieux ...
Emmanuel.
"Gilles Ganault" <nos...@nospam.com> a écrit dans le message de
news:5d09o3946ka9s53qa...@4ax.com...
Gilles Ganault
wrote:
>Toujours la faute de l'hébergeur ... cela ne changera donc jamais ?
Je précise : je leur ai envoyé à deux reprises le message de Free, qui
contient une page courte, simple et explicite sur la cause du
problème, quoi faire pour le résoudre, et un mail de contact pour
avoir plus d'infos.
>Bien sur, vous vous dite 'cela à toujours fonctionné ainsi, donc je ne
>change rien et à l'hébergeur de trouver une solution'
En tant que client, il ne me semble pas excessive d'attendre d'un
fournisseur qu'il consacre au moins 5mn à un problème sévère comme ça
et me donne une réponse plus argumentée que "voici comment fermer
votre compte".
Par ailleurs, je pense que Free aurait pu y aller progressivement, par
exemple en ajoutant un avertissement en bas de page aux mails et en
envoyant un message aux admins du MTA source, avant de blacklister
dans qqs mois.
Francois Petillon
> Par ailleurs, je pense que Free aurait pu y aller progressivement, par
> exemple en ajoutant un avertissement en bas de page aux mails et en
> envoyant un message aux admins du MTA source, avant de blacklister
> dans qqs mois.
Nous avions commencé en ne mettant le blacklistage que sur les MX
secondaires. Maintenant, en ce qui concerne les messages aux admins, je
vais vous donner quelques chiffres : en journée, il y a entre 200K et
300K IP blacklistées alors que la durée des blacklistes vont de 1h à
24h. Il y a de 4 à 5 millions d'IP qui nous ont envoyé recement du mail
et plus de 8 millions d'IP ont été, à un moment ou à un autre, été
blacklisté en l'espace de quelques mois de production. Donc, non, je ne
me vois pas envoyer quelques dizaines/centaines de milliers de mails par
jour pour dire "attention, on vous a blacklisté". Et pour ceux qui
voudrait faire remarquer qu'à la vue de ces chiffres, nous devrions
remettre en cause la solution, je doute sérieusement qu'il y ai autant de
MTA au monde...
François
Gilles Ganault
<fa...@fanfan.staff.proxad.net> wrote:
>Nous avions commencé en ne mettant le blacklistage que sur les MX
>secondaires. Maintenant, en ce qui concerne les messages aux admins
Merci pour ces explications
1. Il aurait été quand même mieux pendant une période de test
d'envoyer un mail ou d'ajouter un bas de page dans les mails au
destinataire du mail, plutôt que de nous laisser découvrir le problème
par hasard. En l'occurence, heureusement qu'un client qui a qqs
connaissances techniques m'a renvoyé mon mail à une autre adresse, là
où les autres ont sans doute simplement supprimé le "Mail delivery
failed: returning message to sender" sans savoir, voire même ces mails
ont été supprimés automatiquement par leur anti-SPAM :-/
2. Le SPAM ne date pas d'aujourd'hui : pourquoi Free a-t-il pris une
telle décision aussi brutale et sans avertir ses clients?
3. Puisque Free ne se base pas sur les systèmes publiques de RBL..
comme Free décide-t-il qu'un MTA envoie du SPAM? Par le contenu? Par
le nombre de mails envoyés/seconde?
> Et pour ceux qui voudrait faire remarquer qu'à la vue de ces chiffres,
> nous devrions remettre en cause la solution, je doute sérieusement
> qu'il y ai autant de MTA au monde...
Quand on voit que de gros hébergeurs comme OVH ou Amen se sont
retrouvés blacklistés... Et moi, j'en suis au troisième mail à mon
hébergeur US qui ne bouge tj pas et va m'obliger à mes frais à
déménager mes sites chez un hébergeur qui a l'heur de plaire à mon FAI
qu'est Free.
Pas glop du tout :-/
Xavier Roche
> 1. Il aurait été quand même mieux pendant une période de test
> d'envoyer un mail ou d'ajouter un bas de page dans les mails
Ce n'est pas facile techniquement amha (et puis bon, modifier une
correspondance privée, bof bof) et surtout l'interêt du blacklist est de
diminuer la charge, pas de l'augmenter (ce qui arriverait si on
triturait les messages à la volée).
> destinataire du mail, plutôt que de nous laisser découvrir le problème
> par hasard.
Il me semble que le code d'erreur utilisé est tout à fait explicite.
Après, si le serveur d'origine est incapable de renvoyer l'info à
travers le bounce, c'est en effet dommage, mais cela ne vient pas de
free à priori.
> où les autres ont sans doute simplement supprimé le "Mail delivery
> failed
Très mauvaise idée, en effet.
> 2. Le SPAM ne date pas d'aujourd'hui : pourquoi Free a-t-il pris une
> telle décision aussi brutale et sans avertir ses clients?
Il me semble (que François Pétillon me corrige) que c'est un problème de
charge devenue trop importante.
En clair, free peut toujours ajouter des serveurs, mais il a décidé que
le ratio signal/bruit devenait trop mauvais.
Moi, en tant que client, je n'aime pas l'idée de payer une partie de
l'infrastructure sur mon abonnement pour permettre à des spammeurs de
pouvoir m'envoyer du mail.
J'approuve donc à 100% cette mesure.
> Pas glop du tout :-/
Essayez déja d'utiliser un hébergeur qui a une politique responsable, et
qui dégage ses clients quand ils spamment ?
Que des sites particulièrement pollués par des spammeurs se fassent
progressivement blacklister par l'ensemble des ISP, moi je trouve cela
très positif.
A terme, ils devront choisir entre perdre tous leurs clients, ou agir en
fermant des comptes.
plop
> Gilles Ganault wrote:
>> 1. Il aurait été quand même mieux pendant une période de test
>> d'envoyer un mail ou d'ajouter un bas de page dans les mails
>
> Ce n'est pas facile techniquement amha (et puis bon, modifier une
> correspondance privée, bof bof) et surtout l'interêt du blacklist est de
> diminuer la charge, pas de l'augmenter (ce qui arriverait si on
> triturait les messages à la volée).
Yahoo, MSN, ... ajoutent en bas de chaque mail leur publicité....
donc, modifier de la correspondance privée n'est qu'un problème
d'éthique (Ok, j'exagère).
>
>> [...]
>
> En clair, free peut toujours ajouter des serveurs, mais il a décidé que
> le ratio signal/bruit devenait trop mauvais.
>
> Moi, en tant que client, je n'aime pas l'idée de payer une partie de
> l'infrastructure sur mon abonnement pour permettre à des spammeurs de
> pouvoir m'envoyer du mail.
De même, certains ISP ne permettent plus de passer le port par
défaut pour envoyer des e-mails (j'ai un trou de mémoire).
Il reste toujours le problème des particuliers qui utilisent des
produits microsoft vérollés... c'est pourtant simple de passer sous
Linux, et bon nombre d'utilisateurs en seraient satisfait.
A bientôt
G
Gilles Ganault
<xro...@free.fr.NOSPAM.invalid> wrote:
>Il me semble que le code d'erreur utilisé est tout à fait explicite.
Oui. Sauf que c'est un client, plus habile techiquement que la
moyenne, qui m'a prévenu par une autre adresse. Sinon, je n'aurais
jamais su que des mails étaient refusés par Free.
>Après, si le serveur d'origine est incapable de renvoyer l'info à
>travers le bounce, c'est en effet dommage, mais cela ne vient pas de
>free à priori.
D'autres personnes ayant subi le même problème peuvent-ils témoigner
que leur MTA leur a remonté le pb?
>En clair, free peut toujours ajouter des serveurs, mais il a décidé que
>le ratio signal/bruit devenait trop mauvais.
D'un seul coup d'un seul, sans prévenir ses clients.
>Essayez déja d'utiliser un hébergeur qui a une politique responsable, et
>qui dégage ses clients quand ils spamment ?
Je connais un moyen beaucoup plus simple de décourager les spammeurs :
augmenter le délai entre chaque connexion.
Gilles Ganault
>À l'envoi, ce qui est très différent. Là, ce qui est proposé, ce serait
>qu'un intermédiaire modifie le contenu du message (hors entête, bien
>sûr).
Pendant trois mois, pour prévenir les clients de Free que les mails
provenant de tel MTA sont encore acceptés mais ne le seront plus une
fois mis en place le blacklisting, j'aurais trouvé ça très bien.
Xavier Roche
>> En clair, free peut toujours ajouter des serveurs, mais il a décidé que
>> le ratio signal/bruit devenait trop mauvais.
> D'un seul coup d'un seul, sans prévenir ses clients.
Euh, pour leure dire quoi ? "On va agir en conséquence pour limiter
d'avantage l'arrivée de spam" ?
> Je connais un moyen beaucoup plus simple de décourager les spammeurs :
> augmenter le délai entre chaque connexion.
Ce n'est pas faisable sur un tel volume ; et cela ne décourage en rien
des machines zombifiées qui ont tout leur temps (spécialement quand
l'hébergeur ne fait rien) pour spammer.
Remi THOMAS
Pourquoi changer d'hébergeur?
Si tu es un particulier, tu ouvres un compte GMail et tu utilises ce serveur
SMTP. Comme l'anti-spam de GMail est très performant il ne risque pas de se
faire blacklister.
Rémi
Gilles Ganault
>Chic, plein de spam pendant trois mois, pour un blacklisting de 24h.
>Vache, ça c'est du temps de réaction...
Je réexplique : pendant trois mois, bas de page pour avertir qu'à
partir de telle date, le MTA source sera blacklisté. Après, couic.
>[Et puis, je ne vous dis pas les systèmes automatisés qui rejeteront les
> mails ainsi modifiés puisque devenus non conformes à la structure
> attendue.]
On peut y réfléchir. Après tout, Google et Yahoo rajoute des trucs. En
tout ca, c'est quand même moins inacceptable que de perdre des mails
sans même en être averti.
Gilles Ganault
wrote:
>Pourquoi changer d'hébergeur?
Parce que je n'aime pas les mails web et préfère récupérer tous mes
mails dans une seule BAL:
con...@toto.com -> ma...@free.fr
Mais si Free blacklist le MTA qui héberge toto.com... ben mes clients
se prennent un "Too many spams from your host" du plus bel effet... et
sans que j'en sois même averti :-/
Xavier Roche
> On peut y réfléchir. Après tout, Google et Yahoo rajoute des trucs.
NON. Pas en entrée.
Franck
En plus c'est mal, ça casse les signatures numériques.
patpro ~ Patrick Proniewski
Gilles Ganault <nos...@nospam.com> wrote:
pourquoi en serais-tu averti ?
C'est l'expéditeur qui est averti de la non-délivrance, pas le
destinataire.
Tes récriminations sont techniquement non-fondées. Les FAI ne vont pas
modifier le fonctionnement de SMTP pour te plaire.
patpro
Dominique ROUSSEAU
> On 09 Jan 2008 20:25:08 GMT, Martin Lafaix <laf...@online.fr> wrote:
>>Chic, plein de spam pendant trois mois, pour un blacklisting de 24h.
>>Vache, ça c'est du temps de réaction...
>
> Je réexplique : pendant trois mois, bas de page pour avertir qu'à
> partir de telle date, le MTA source sera blacklisté. Après, couic.
Donc ajouter de la charge, là où le but est de la réduire.
Quand on a un serveur SMTP qui relaye de la merde, il faut l'assumer et
prendre des mesures (oui, ça peut signifier couper un client, si il
abuse du service).
Est ce que c'est pénible, les politiques mises en place par AOL, Free &
co qui blacklistent à tour de bras des serveurs ? Oui, surement.
Mais jusqu'à preuve du contraire, on reste libre de choisir ce que l'on
veut recevoir ou non. Et quand on délègue celà à son fournisseur de
service (= utiliser une email chez AOL, ...), et que sa politique ne
convient plus, on peut changer de fournisseur.
>>[Et puis, je ne vous dis pas les systèmes automatisés qui rejeteront les
>> mails ainsi modifiés puisque devenus non conformes à la structure
>> attendue.]
>
> On peut y réfléchir. Après tout, Google et Yahoo rajoute des trucs.
Sur les mails sortants. Les utilisateurs de ces services le "subissent"
en toute connaissance de cause.
> En tout ca, c'est quand même moins inacceptable que de perdre des
> mails sans même en être averti.
Il y a un forcément un retour. Ou alors le MTA d'origine est en carton,
et tant pis pour lui.
Stephane Kanschine
On a le même problème. Depuis que les mua et les webmail savent gérer du
multi comptes, concentrer tout sur une seul bal n'est pas du confort
c'est de la fainéantise. Techniquement avec les en têtes forgés,
free.fr ne peut se fier que sur toto.com qui devient l'émetteur de
cet email et donc le spammeur. En bref, c'est assez crade de tout
concentrer sur une adresse. Je ne serais pas étonné, comme un certains
hébergeur où j'ai pu travailler qui limitait le nombre de forward, que
tout le monde arrive à fortement limiter cette fonctionnalité, voir à la
supprimer vu que chaque maillon de la chaîne devient irresponsable.
J'me demandais d'ailleurs si il y avait des "greffrons"
postfox/exim/qmail/whatever qui savaient remonter les en têtes Received
en se disant que tel maillon ne forgeaient pas les en têtes, et en
remontant d'un cran à chaque fois pour chercher le "vrai" émetteur du
spam.
--
Stephane Kanschine
Association APINC : http://www.apinc.org/
Stephane Kanschine
> On Thu, 10 Jan 2008 09:26:31 +0100, "Remi THOMAS" <re...@xtware.com>
On a le même problème. Depuis que les mua et les webmail savent gérer du
multi comptes, concentrer tout sur une seul bal n'est pas du confort
c'est de la fainéantise. Techniquement avec les en têtes forgés, free.fr
ne peut se fier que sur toto.com qui devient l'émetteur de cet email et
donc le spammeur. En bref, c'est assez crade de tout concentrer sur une
adresse. Je ne serais pas étonné, comme un certains hébergeur où j'ai pu
travailler qui limitait le nombre de forward, que tout le monde arrive à
fortement limiter cette fonctionnalité, voir à la supprimer vu que
chaque maillon de la chaîne devient irresponsable.
J'me demandais d'ailleurs si il y avait des "greffons"
postfix/exim/qmail/whatever qui savaient remonter les en têtes Received
en se disant que tel maillon fait est une partie de confiance, ne forge
BertrandB
> Je connais un moyen beaucoup plus simple de décourager les spammeurs :
> augmenter le délai entre chaque connexion.
Dans le grey listing il y a de ça ... mais ça demande quand même pas mal
de ressource.
BertrandB
relais de mail différent de celui de son isp. Je sais que le smtp de
laposte.net oblige que l'expéditeur soit une adresse laposte.net mais
pour le smtp de gmail je ne sais pas. Sur le forum ovh il y a un
utilisateur qui a utilisé ce système avec une version modifiée de phpmailer.