[Gestion de newsletter] Comment détecter les fausses adresses email ?

Difficile de contrôler, sauf à demander un email de verification.... qui passe souvent en spam

 

Bonsoir,

Personnellement je fais le ménage à la main , c'est long et fastidieux mais bon avec un rechercher sur les erreurs d'envoies , çà se passe quand m^me assez bien

@+

 

+1.

D'ailleurs la solution ne serait-elle pas de mettre un code textuel (A1234 qui doit être re-saisit sur le site) dans un e-mail afin d'éviter de tomber en SPAM à cause des liens hypertextes ?

 

Hum... je suis justement en train de réfléchir à faire du bounce management.

En gros l'idée est de créer une boite mail pour les retours en erreur (par exemple : -erreur@ndd.com). Lors de l'envoi de la newsletter, il faut alors configurer que si le mail n'existe pas, le mail de retour d'erreur arrive sur -erreur@ndd.com
Et enfin, grâce à un script PHP, on parcours chaque mail de la boite -erreur@ndd.com et on défini si il s'agit d'un hard bouce ou d'un soft bounce. Grâce à un système de scoring, on peut ainsi définir une liste de mail à filtrer.

Voila, ce n'est que pure théorie car je n'ais pas encore mis en place ce système. J'ais juste fait des tests et ça a l'air de fonctionner.

 

quelle différence fais-tu entre "hard" bounce et "soft" bounce ?

 

hard bounce -> la boite du destinataire n'existe pas ou plus
soft bounce -> la boite est pleine ou autre raison qui fait que le mail revient en erreur.

C'est pour ça qu'il y aurait un système de scoring sur le soft bounce. Admettons qu'un mail est revenu en soft bounce plusieurs fois sur une période de 3 mois par exemple, alors il passerait en hard bounce.

D'ailleurs, vu que ce n'est qu'en état purement théorique et test de mon côté, si quelqu'un a réellement mis en place ça sur un site en production, je suis preneur d'infos

 

À quel niveau tu renseignes cette adresse e-mail ?
return-path ?

 

le "problème", c'est que nombre de serveurs mels n'envoient pas de bounce. Sur mes serveurs mels, c'est comme cela que je procède. Car le bounce fait quoi ?
- il renvoie un mel au spammeur pour lui indiquer que l'adresse mel n'existe pas, tant pis, il va réessayer aussitôt avec une autre
- il envoie un mel (considéré comme spam) au soit-disant expéditeur, alors que le spammeur ce n'est pas lui

ça ne change rien, car le mel de demande de validation passera lui en spam

 

Tomber dans la boîte de SPAM n'est pas forcément une fatalité si l'on s'assure de son formatage ?

 

si, surtout avec des mels génériques comme yahoo.
Sans forcément donner une fausse adresse, mais monmel@yahoo.fr qui est tapé avec une inversion de lettre et qui donne omnmel@yahoo.fr ça ne passe pas.
Si tu as plusieurs erreurs de ce genre, en rajoutant ceux qui sciemment inventent de fausses adresses mels, ça fait pas mal de possibilités

 

Les adresses fausses, erronnées, involontairement ou pas sont effectivement une plaie pour emaileurs.

1) Pkoi donne t'on une mauvaise adresse email ?
- parce qu'on est obligé de s'inscrire pour pouvoir acceder à ce qu'e l'on veut sur ton site.
- parce qu'on est oblige de s'inscrire pour jouer à un jeu, meme pour 30 secondes
- parce qu'on est pas sur du service que l'on attend de toi alors on donne une truc jetable pour voir...

2) pkoi les adresses reviennent fausses ?
- parce que y'en a qui ont la mixomatose des mains
- parce que certains ne gardent pas une adresse plus de 3 mois a cause du spam
- parce que tu ne fais pas le menage dans ta base
- parce que tu ne regarde pas tes retours
- parce que tu n'a pas une approche comportementale de ta base

3) et ca fait quoi quand ca revient en erreur ?
- Si tu nettoies pas ta base, ca fait s'accumuler les adresses fausses
- un trop haut taux de NPAI en envoi fait que ta campagne passe en spam potentiel (temporaire ou pas) chez tes destinataires (ou plutot leurs FAI/webmails)
- ce taux de NPAI accepté diminue comme neige au soleil puisqu'il est passé de 5 à 1% chez certains :-/

4) pkoi même si je tiens ma base propre cela ne sert pas à grand chose de travailler dans son coin ?
Parce que gerer ces retours devient quasi impossible pour un petit webmaster. C'est énormément de travail et puis le pire c'est que vous n'avez pas tous les retours de la part des serveurs de mail de vos destinataires.
Comme souligné plus haut, certains serveurs de mail sont régis comme des firewalls et ne bronchent plus si un mail arrive avec une erreur. Tu ne sais alors pas que t'as des NPAI qui pourissent ta base et tu va te retrouver avec des campagnes systematiquement en spam temporaire, puis definitif.
Quand tu travaille avec un professionnel de l'emailing ( les vrais hein ;-) ) son service déliverabilité est en lien direct avec FAI et webmails et ils sont integré dans la FBL (Feedback Loop) cad qu'ils recoivent les retours qui normalement sont silencieux pour toi
En plus ils sont directement au courant quand des changements ont lieux dans les moyens de filtrages, etc.

Je reviens sur un petit point sur le soft bounce et le comportemental.
Oui il faut traiter les soft bounces car un jour ou l'autre, ils peuvent se transformer en spam trap et là ca fait très mal.
De la même manière il ne faut pas avoir peur de mettre de cote tes destinataires amorphes, cad ceux qui n'ouvrent ou cliquent jamais tes mails. S'ils ne réagissent pas du tout, y compris à des campagnes de reveil, vire les, c'est des maisl envoyés pour rien avec risque de listage au bout.

Petit détail interessant sur Snipemail il y a une option pour gerer les NPAI :
- On laisse ou pas une seconde chance aux NPAI hard (parce qu'une mauvaise propagation d'un DNS tombé cela arrive, si si !) D'ou un classement en NPAI hard seulement la seconde fois consécutive qu'un email revient en hard.
- on classe en hard les emails après X NPAI softs consecutif, et tu fixes X entre 1 et 9.

C'est vrai que ce genre de choses est bien plus dur à faire si t'es pas ESP (Email Service Provider) et integré dans la FBL de tes gros destinataires

 

Évidemment, si l'adresse est fausse ou erronée, ca ne marchera pas.
Mais l'origine de cette idée vient d'ici :

 

Pour verifier si le host existe tu peux utiliser la fonction php getmrr() ce qui te permet d'éliminer tous les hosts farfelus.

Ensuite, si le host existe, tu établis une connection vers le destinataire avec fsockopen()sur le port 25 du host, tu te présente (envoi de "Hello") et tu t'identifies (ton adresse mail). Tu recupere le code de retour et si c'est OK, tu sais que l'adresse mail est valide.

SI le serveur depuis lequel tu exécute le script est correctement déclaré au niveau des SPF , il y a de fortes chances pour que les connections qui renvoient un code invalide correspondent à une adresse qui n'existe réellement pas. :wink:

J'utilise cette technique lors de la validation de formulaire d'inscription et je n'ai jusqu'à présent pas eu de problème.

 

Avec ces deux méthodes et d'après ce que j'en sais, le résultat sera tout de même aléatoire en fonction de la configuration des serveurs. Certains refusent ce genre de requête, d'autres sont (inutilement ?) sur-sécurisés.

 

getmrr() fait juste un reverse sur le HOST donc verifie son existance, c'est fiable :wink:

avec fsockopen() tu peux déjà trier les adresse valides. De plus, cela fonctionne chez les principaux fournisseurs d'adresse mail

Maintenant, le mieux est de faire le test et de mesurer le taux d'échec

 

C'est un peu risqué : avec getmrr() tu vérifies que le domaine soit "up" au moment de l'inscription, même si c'est peu probable : il suffit qu'il y ait un problème de DNS temporaire sur ce domaine (ou ton serveur) pour rejeter une adresse pourtant valide. Alors que ce genre de cas ne pose aucun soucis à un serveur de mail, la file d'attente servant entre autre à ça.

Quand au fsockopen() là c'est du grand n'importe quoi : les serveurs MX n'ont aucune obligation d'être tous up en permanence, et encore moins d'être tous sur l'IP "principale" du domaine. C'est d'ailleurs faux pour une très grande partie des domaines. Laissez donc faire le serveur de mail, qui lui au moins sait ce qu'il fait... 8O

 

Un peu dur le "Grand n'importe quoi" non Bool ? 8O

getmxrr effectue une recherche DNS pour obtenir les enregistrements MX de l'hôte hostname , donc c'est bien sur le MX que je fais le fsockopen quelquesoit sont IP.

Ensuite, la probalité que le serveur soit doit down est tellement faible (et rien n'empeche de faire plusieurs tests différés) et enfin le but est de conserver les adresses valides, ce que fait ma methode :mrgreen: J'ai un taux d'erreur de moins de 3% d'adresses mail valides rejetés et de 0% d'adresses invalides.

Faut bien lire avant d'être péremptoire mon petit Spirou :lol:

 

Effectivement ce n'était pas précisé dans ton message et j'ai fait une déduction trop hâtive, mea culpa. Il n'empêche que ça m'étonnerait fortement que tu checkes toutes les IP de tous les serveurs MX, alors que c'est justement une pratique anti spam de plus en plus répandue, à savoir annoncer une dizaine de serveurs MX et n'en faire fonctionner que 4 par exemple.

3% d'adresses rejetées injustement, moi ça me semble énorme. Et comme je disais c'est amené à s'accroître.

 

fandecine,
Si le serveur est configuré pour pas retourner de message à ce genre de requète tu fais quoi ?
C'est le plus en plus le cas ces temps-ci à cause du spam

 

Ben si le serveur ne respecte pas le protocole SMTP je ne vois pas comment il peut communiquer avec d'autres serbeurs SMTP et recevoir du courrier :mrgreen: Si tu configure ton serveur SMTP pour ne pas répondre, il ne répondra à personne, même pas à un envoi de mail "classique". Ensuite, j'ai bien précisé que le serveur d'ou est executé le script doit être correctement configuré au niveau des SPL des DNS. Dans ce cas le serveur SMTP que tu contacte te considére comme un MTA fonctionnant sur un serveur déclaré comme envoyant du courrier même si son IP ou son Host est different de celui du NDD.

 

Pour moi tu vas trop vite en besogne, tu dis utiliser deux mécanismes :

1) getmxrr() qui retourne la liste des serveurs MX du domaine. Ces serveurs MX ne sont absolument pas obligatoires, même dans la doc de PHP il est indiqué que cette fonction ne doit pas être utilisée pour vérifier la validité d'une adresse email.

2) ensuite tu dis que tu fais fsockopen() sur le port 25 du serveur MX ; et là je te réponds qu'il y a de plus de plus souvent un plusieurs serveurs MX annoncés ayant chacun plusieurs IP.
Par exemple 4 serveurs MX annoncés, ayant 2 IP chacun ; soit 8 adresses IP à vérifier. Et comme je le disais ça m'étonnerait que ton script à coup de fsockopen() vérifie toutes ces combinaisons, alors que ton serveur de mail le fera.
De la même façon certains serveurs de mail ne répondent qu'au bout d'une trentaine de seconde, c'est parfaitement compatible avec la RFC du protocole SMTP le timeout recommandé pour un client étant de 300 secondes, oui 5 minutes ! Quel est le timeout sur ton script ?


Pour moi le seul moyen fiable de vérifier la validité d'une adresse email c'est de laisser le MTA s'en charger. C'est d'ailleurs ce que font tous les emailers ; et même avec ça généralement ils ne rejettent une adresse qu'après 2 erreurs complètes générées par le MTA.

 

Bon, un petit dessin valant mieux qu'un long discours, j'ai concocté un script didactique à partir des miens car il est difficile de balancer un script sorti de son contexte. Et puis, le but, c'est de comprendre comment ça marche :wink: Je vous invite également à consulter les RCP afin de connaître les codes de retour SMTP afin d'affiner le script selon vos besoins (je n'ai traité ces codes que par famille)

Code:

<?php
//*****************************************
// cette fonction accepte deux paramètres en entrée :
//   - l'adresse mail à teste : $mail
//   - une adresse mail valide et déclarée autorisée sur le serveur ou est executé le script : $monMail
// en sortie, on recupère un code :
//   - 0 : essayer ulterieurement
//   - 1 : adresse mail valide
//   - -1 : adresse mail invalide
//   - 2 : ce cas n'a pas été prévu dans le script (normalement, ne doit pas arriver)
//*****************************************

function testMail($mail,$monMail) {
    $resultat=-1;
    $erreur=false;
    $addr=explode("@",$mail);
    if(getmxrr($addr[1],$hosts,$weight)) {
        foreach($hosts as $host) {   // on va tester tous les MX
            $Connect = @fsockopen($host,25,$errno,$errstr); 
            if($Connect) {
                $reponse1=substr(fgets($Connect, 1024),0,1); //seul le premier caractère de la reponse nous interesse
                fputs ($Connect, "HELO {$_SERVER['HTTP_HOST']}\r\n");
                $reponse2 = substr(fgets ( $Connect, 1024 ),0,1); //seul le premier caractère de la reponse nous interesse
                fputs ($Connect, "MAIL FROM: <".$monMail.">\r\n");
                $reponse3 = substr(fgets ( $Connect, 1024 ),0,1); //seul le premier caractère de la reponse nous interesse
                fputs ($Connect, "RCPT TO: <".$mail.">\r\n");
                $reponse4 = substr(fgets ($Connect, 1024),0,1); //seul le premier caractère de la reponse nous interesse
                if($reponse1==2 && $reponse2==2 && $reponse3==2 && $reponse4==2) return(1); // c'est bon, l'adresse mail est valide
                else if ($reponse1==5 || $reponse2==5 || $reponse3==5 || $reponse4==5) $erreur=true; // l'adresse est invalide
                else if ($reponse1==3 || $reponse2==3 || $reponse3==3 || $reponse4==3) $resultat=3; // demande en cours de traitement, vraisemblablement timeout un peu long
                else if ($reponse1==4 || $reponse2==4 || $reponse3==4 || $reponse4==4) $resultat=0; // erreur temporaire, faudrat re-essayer
                else $resultat=0; // bon, on essayera plus tard                
            }
        }
        //si on arrive ici, c'est qu'il y a une erreur ou une indisponibilité/erreur temporaire
        if($resultat==0) return(0); // au moins un MX à signalé une erreur temporaire, ça vaut le coup de re-essayer plus tard
        else if($resultat==3) return(0); // vraisemblablement timeout un peu long, ça vaut le coup de re-essayer plus tard
        else if($erreur) return(-1); // l'adresse mail à de forte chance d'être incorrecte
        else return(2);
    } else {
        return(-1);
    }
}

Maintenant, pour ceux qui comme Bool :wink: n'ont pas confiance en la fonction getmxrr() de php il peuvent faire un exec() avec dig :

Code:

<?php exec("dig MX domaine.com", $resultat); ?>

le tableau retourné est juste un peu plus complexe à traiter (il suffit juste de parcourir le tableau à la recherche des MX). Pour les plus pointilleux encore, vous pouvez carrément faire un script PERL (langage bien plus adapté que PHP pour ce genre de choses)

Ensuite, pour le problème des délais de réponse (timeout) signalé par Bool cela se code également. Tous les cas particuliers peuvent êtres pris en compte, cela dépend seulement des objectifs que l'on se fixe

Enfin, pour conclure, je répondrais à Bool qu'un MTA c'est juste du code qui peut être totalement recodé entièrement ou partiellement dans toutes sortes de langages. (Personnellement je n'ai jamais codé de MTA mais je me souviens d'un TP que je faisais faire à mes étudiants dont le but était de coder un serveur web)

Bool, rien n'empèche de faire des tests en amont :wink:

 

Tu ignores volontairement mes réponses non ?
getmxrr() retourne évidement les bons résultats, c'est à dire la liste des MX. Je n'ai jamais dit le contraire. Ce que je te dis c'est que ce n'est pas suffisant, vu qu'il n'a jamais été obligatoire d'avoir un serveur MX sur son domaine ; et c'est même stipulé noir sur blanc dans la doc PHP.

Pour les timeouts, ils sont à multiplier par le nombre de serveurs MX et IP du domaine... et oui tu peux parfaitement t'amuser à recoder un MTA en PHP, mais ré-inventer la roue alors qu'on ne connait que très partiellement la RFC du protocole en question ça me semble complètement farfelue comme approche.
Laissez donc faire le MTA, il sert à ça, et gère ça infiniment mieux.

Maintenant ça dépend effectivement des "objectifs" comme tu dis. Pour moi le respect des standards et normes en fait partie.

Pour les tests en "amont" je suis d'accord, sauf que dans le cas présent il s'agit de refuser une inscription sous prétexte que l'adresse email ne réponde pas à ton interprétation du protocole SMTP... Mais trop tard, le client est parti voir ailleurs, faut pas croire que tous les internautes te contactent quand ils se font refouler à l'entrée du site.

 

Et je te dis que les serveurs MX ne sont pas obligatoires. Si le domaine n'a pas de serveur MX la question getmxrr() ne te retournera rien (oui ton tableau $hosts sera vide), alors que le domaine est parfaitement valide et reçoit très bien ses emails.

Sinon je n'ai pas critiqué l'intention - le forum est bourré de personnes de bonnes intentions (encore heureux) - mais l'approche qui est de très mauvais conseil à mon sens.

Maintenant je pense qu'il est clair que je ne te ferai pas entendre raison, donc on va en rester là.

 

si, tu me donne une adresse mail valide (qui reçoit bien du courrier) dont je ne pourrais pas trouver les MX :mrgreen:

 

J'ai pas lu tout le débat, mais sur ce point je ne comprends pas non plus.
Pour recevoir le courrier il faut forcément un MX de destination ?
Par contre c'est vrai qu'il peut y en avoir plusieurs.

 

commande : dig MX yahoo.fr

Code:

; <<>> DiG 9.3.4-P1.1 <<>> MX yahoo.fr
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40911
;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 5, ADDITIONAL: 15

;; QUESTION SECTION:
;yahoo.fr.                      IN      MX

;; ANSWER SECTION:
yahoo.fr.               2204    IN      MX      10 d.mx.mail.yahoo.com.
yahoo.fr.               2204    IN      MX      10 e.mx.mail.yahoo.com.
yahoo.fr.               2204    IN      MX      10 f.mx.mail.yahoo.com.
yahoo.fr.               2204    IN      MX      10 g.mx.mail.yahoo.com.
yahoo.fr.               2204    IN      MX      10 a.mx.mail.yahoo.com.
yahoo.fr.               2204    IN      MX      10 b.mx.mail.yahoo.com.
yahoo.fr.               2204    IN      MX      10 c.mx.mail.yahoo.com.

;; AUTHORITY SECTION:
yahoo.fr.               6330    IN      NS      ns7.yahoo.com.
yahoo.fr.               6330    IN      NS      ns1.yahoo.com.
yahoo.fr.               6330    IN      NS      ns2.yahoo.com.
yahoo.fr.               6330    IN      NS      ns3.yahoo.com.
yahoo.fr.               6330    IN      NS      ns5.yahoo.com.

;; ADDITIONAL SECTION:
a.mx.mail.yahoo.com.    21      IN      A       67.195.168.31
b.mx.mail.yahoo.com.    23      IN      A       66.196.97.250
c.mx.mail.yahoo.com.    1103    IN      A       216.39.53.3
c.mx.mail.yahoo.com.    1103    IN      A       216.39.53.2
d.mx.mail.yahoo.com.    1103    IN      A       66.196.82.7
e.mx.mail.yahoo.com.    1106    IN      A       216.39.53.1
f.mx.mail.yahoo.com.    1104    IN      A       209.191.88.247
f.mx.mail.yahoo.com.    1104    IN      A       68.142.202.247
g.mx.mail.yahoo.com.    23      IN      A       209.191.118.103
g.mx.mail.yahoo.com.    23      IN      A       206.190.53.191
ns1.yahoo.com.          6330    IN      A       68.180.131.16
ns2.yahoo.com.          6330    IN      A       68.142.255.16
ns3.yahoo.com.          6330    IN      A       217.12.4.104
ns5.yahoo.com.          6330    IN      A       119.160.247.124
ns7.yahoo.com.          6330    IN      A       68.142.226.82

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Dec 18 12:47:26 2008
;; MSG SIZE  rcvd: 499
[/quote]

 

Il y en à plusieur et elles sont pas sur même domaine, mais elles existent et sont identifiables :mrgreen:

A prioris, je sus pas plus con qu'un MTA, sinon, n'hésitez pas, hein, vous me le dites

 

Non justement. C'est même indiqué dans la doc de getmxrr() :

Tous mes domaines ont un ou plusieurs serveurs MX. Mais ça n'a pas toujours été le cas. Quand je n'avais qu'un seul serveur dédié je ne précisais pas de MX.

Et ce n'est là qu'un point flagrant de la RFC qui n'est pas respecté. Il y en a très certainement bien d'autres.

 

hé bien dans ce cas, tu utilise "hostname" pour le fgets, c'est tout !

Maintenant, j'attend toujours une adresse mail valide dont je ne pourrai touver le host auquel envoyer un mail (j'ai modifié la formulation car tu est vraiment trés pointilleux :mrgreen: )

 

Tu le fais vraiment exprès.... je n'ai aucun domaine en ma possession qui n'a pas de MX, mais le problème n'est pas là :
oui à chacun des bugs soulevés dans ton script tu pourras faire une correction, c'est évident. Mais combien de patch faudra t-il avant que le script fonctionne vraiment ?
Le problème c'est que tu te lances là dedans avec un script que tu pensais "bon" alors qu'il ne l'est pas. Comment peux tu penser une seule seconde qu'en quelques lignes de PHP tu feras toutes les vérifications nécessaires à un serveur de mail avant qu'il ne déclare l'adresse email comme invalide ?

 

Je le fais pourtant !

Mais tu sais trés bien que balancer le script original sorti de son contexte n'apporterait rien (j'utilise en fait une classe maison pour certain sites en PHP, classe qui fait bien plus que cela) et unscript PERL sur mon serveur de mail personnel. j'ai donc ré-écrit un script, en éliminant tout ce qui sort du sujet, en plus dans un esprit didactique pour que les lecteurs comprennent, et généralement les wrinautes apprécient mes script même si ils ne sont pas complets.

En matière de partage de connaissance, l'objectif n'est pas de livrer un outils clés en main (ça, c'est du service :mrgreen: ) mais de permettre au lecteur de comprendre et tant mieux si certains trouvent des imperfections, cela prouve que l'objectif est atteint : ils ont compris

La question originale était de savoir comment éliminer les adresses farfelues (exemple donné AAA@bbb.ff) d'une base mail, et je pense que j'apporte une (pas la) réponse.

Maintenant, si je prends le temps de polémiquer c'est parce que je pense qu'une réaction plus éclairante de ta part vis a vis du lecteur aurait été de noter les erreurs et d'y apporter des solutions en non pas commencer par dire que c'est du grand n'importe quoi.

voilou, voilou 8)

PS: En plus de ça, je mords :mrgreen:

 

Oui et j'avais d'ailleurs avoué avoir répondu trop hativement, pensant qu'il s'agissait d'une simple vérification d'existence du domaine (ce qui finalement aurait été mieux à mon sens).

Il n'en reste pas moins que le script est très loin de respecter la norme SMTP, et que je continuerai donc à fortement le déconseiller.

Maintenant pourquoi n'ai je pas soumis de "solution" ? Parce que pour moi la réponse la plus pertinante du topic est celle de Wefficient, qui maitrise vraiment le sujet, et que je n'ai rien à ajouter de plus.

 

Merci Bool

Extremenet, ca fait presque 50% de perte :-(
Et htomail cela pesait combien dans ta base ?

Hotmail, chez mes clients, cela reste quand même un domaine lourd sur lequel ils ne peuvent pas faire l'impasse. Par contre je comprends que lorsqu'on travaille avec d'autres solutions il puisse faire partie des domaines qui posent de gros problèmes de réception.

Enfin un des éléments qui me fait dire qu'il y a de grandes chances que tout ton travail sera vain est :

Mutualisé => emailing non maitrisé => ip blacklistée

En mutualisé, tu multiplie tous les risques de blacklistage par autant d'utilisateurs de ton ip.
Et même si toi tu veux travailler proprement, si cela se trouve t'as un gros sagouin qui a pris un hebergement au mois juste pour balancer sa sauce...

Commence par obtenir un petit dédié ou y'aura que toi dessus pour faire tes emailing, ou alors passe par une solution spécialisée. Mais dans l'état, cela me semble vachement compromis comme stratégie...

 

Question blacklist

Bonjour à tous,

J'ai lu tous vos messages, mais je ne sais toujours pas si il faut utiliser ou non cette technique.

Je l'ai trouvé sur beaucoup de sites, et implémenté hier sur mon serveur dédié linux.
Or, j'ai eu un problème de taille, mon serveur s'est retrouvé en blacklist en moins de 24 heures !

J'ai demandé le blacklist, et laissé le script tourner encore à chaque demande d'inscription, et ai été reblacklisté !

J'ai donc pris la décision de supprimer le script...
Vous n'avez pas ce genre de problème lors de l'utilisation de getmxrr avec fsockopen pour tester la validité des adresses ?

 

Re: Question blacklist

Hélas 1000 fois hélas...

LE problème d'Internet est que la pertinence des réponses ne se voit pas au nombre d'occurrences.
Si c'était le cas, la croisade que je mène depuis 2006 aurait déjà porté ses fruits et je n'aurais plus jamais à intervenir dans les différentes communautés virtuelles pour des problématiques emailing.

On verra toujours des personnes faire du bricolage, vouloir être plus malin que les autres et finir blacklistées.

Même combat dans le référencement ;-)

 

Re: Question blacklist

Cela veut dire que vous êtes aussi blacklisté ?
Et qu'il n'y a pas d'autre solution ?

 

Non je ne suis pas blacklisté moi même parce que justement je ne bricole pas.
J'ai passé l'age de perdre du temps en voulant bricoler ou réinventer l'eau chaude. Mon temps je le passe là ou j'ai vraiment de la valeur ajoutée.

Je passe par un prestataire spécialisé qui a une vraie équipe de professionnels spécialisés en déliverabilité et qui sont en contact permanent avec les grands FAI et Webmails.
Maintenant je gère une partie de leur microemailing au travers de ma solution.
Mais bon, tout cela est expliqué dans le blog en signature...

 

Inclinons nous humblement devant ton omniscience :mrgreen:

et vive l'obscurantisme ! restez ignorants, le savoir c'est pour les spécialistes, pas pour vous pauvres ignorants :evil:

SAVOIR PARTAGER C'EST AVANT TOUT PARTAGER LE SAVOIR.

Une communauté même viruelle c'est fait pour ça !

Tu peux me considérer comme un "bricoleur" (je bricole en informatique depuis presque 30 ans) et j'ai connu les informaticiens savant, ceux qui gardaient jalousement leur prés-carré et leur précieux savoir. Et puis, badaboum ! La micro informatique déboule avec son lot de "bricoleurs".

Si le net est ce qu'il est aujourd'hui c'est an grande partie grâce à ces "bricoleurs".

mais pour en revenir au sujet, les solutions que je péconise dans ce post, je les applique, certes à mon modeste échellon, et mes serveurs ne sont pas blacklistés pour autant :mrgreen:

PS: Je suis également un professionnel car je gagne ma vie en vendant des prestations de services dans le domaine de l'administration de serveurs et de l'infogérence

 

fandecine, le fait que la plupart des entreprises que je côtoie ont un service informatique déplorable, c'est bien à cause de bricoleurs qui se croient très fort parce qu'ils arrivent a faire "suivant, suivant, suivant, terminer" pour installer un logiciel. Pour moi les bricoleurs sont une vrai plaie puisque je passe mon temps à démêler leur merdier.

Il y a certains domaines dans lesquels on peut bricoler, ton script peut être intéressant à petite échelle, et est à utiliser uniquement à l'inscription, mais surtout pas à l'envoie d'une grosse campagne emailing (c'est le blacklistage garantie sinon), l'utiliser pour des adresses qui ont eu plusieurs retours d'erreurs pour nettoyer la base de temps en temps, par toujours par petite quantité.

Dès lors que l'on veut faire du emailing de masse, il ne suffit plus, et il devient nécessaire de ne plus bricoler dans son coin et de passer par une solution professionnelle.

Ton attaque vis à vis de wefficient est déplacé surtout qu'il à pas mal participé et donné beaucoup de conseils

 

Pour le coté partage, il me semble que cela a déjà été fait dès le premier post de Wefficient non ? Je ne vois pas quelle info il a "cachée" ici.

 

Mon propos n'a rien de personnel, mais réponds à un propos qui me hérisse, c'est tout. Si tu rencontre des bricoleurs dans les entreprises que tu cotois c'est justement parceque le transfert de savoir ne s'est pas fait ou c'est mal fait.

J'ai enseigné l'informatique (systémes d'exploitation, langage C) et je connais les contenus des formations (même si c'était il y a 10 ans) et je devais me battre pour avoir accés à des ordinateurs pour mes étudiants, et j'ai accueilli en entreprise des stagiaires "Administrateurs réseau" qui ne connaissaient même pas la ligne de commande!

La majorité (pour ne pas dire tous) le informaticiens de qualité que je connais sont des auto-didactes et se sont formés sur le tas , en bricolant.

J'ai donc beaucoup de mal à entendre des messages du genre "si tu comprends pas ou si tu maitrise pas, adresse toi à un professionnel (sous enttendu comme moi)".

Bool, je ne parle pas d'info cachée, je n'ai rien contre wefficient que je ne connais pas personnellemnt et qui est sûrement quelqu'un de trés bien et trés compétant. Je lui repproche juste des propos qui personnelement me choquent, rien de plus.

En ce qui concernne les solutions que je publie sur WRI leur principal objectif est pédagogique et j'estime que si la personne qui me lit comprends le mécanisme et même si elle y découvre des failles, des incohérance, elle sera plus à même de mener une réflexion pertinante et faire ses propres choix.

Mais je ne suis qu'un pauvre idéaliste post 68'ard :mrgreen:

 

C'est en partie vrai, mais le transfert de savoir ne s'est pas fait pour plusieurs raisons :
- les entreprises quand elles ont commencé à avoir besoin d'un système informatique, c'était souvent : tiens toi tu as un ordi chez toi, c'est donc toi qui va s'occuper de notre informatique (c'est encore le cas dans l'éducation nationale et les responsables ressources dans les lycées et collèges).
- Forcement quand tu vas chez eux pour dépatouiller le merdier, ils sont souvent loin d'avoir le niveau pour que tu puisses leur expliquer le pourquoi du comment (surtout quand tu dois toi même être productif et réparer cela dans un temps assez court). Attention, je ne dis pas que l'on ne peut pas, mais souvent le manque de temps et de connaissance de l'interlocuteur (quand il s'y intéresse, déjà ça c'est pas gagné).

Moi aussi j'ai enseigné, et il m'arrive d'enseigner encore, mais directement dans les entreprises justement, et tu n'imagines pas la quantité de "stagiaires" qui n'en ont rien à faire. J'ai eu aussi certains qui sont venus a mes formations sous le prétexte de voir si je ne disais pas des conneries à leurs utilisateurs, mais c'était pour ne pas avoir qu'en tant que responsable informatique, ils ne savaient pas faire.

Aujourd'hui, il existe pas mal de formations informatique pour les entreprises, certes cela à un coût, mais si au départ l'utilisateur n'en fait pas la demande, ou n'avoue pas ne pas avoir le niveau, c'est sûr qu'il n'y aura pas transfert de connaissances.

Moi ce que je sous entend, c'est que arrivé à un certain niveau, avec la meilleure volonté du monde le bricoleur aura du mal à faire aussi bien et aussi rapidement qu'un vrai pro (attention, il y a des bons et des moins bons, ça c'est un autre problème).

Quand on parle d'emailling de masse, il y a un travail constant à faire pour que la base soit propre, et que le serveur soit toujours accepté par les différents prestataire de boites mails, en général, tu as déjà pas mal d'autre choses à faire, et déléguer le boulot est parfois le meilleurs calcul à faire.

Je ne renie pas le but pédagogique, bien au contraire, mais beaucoup le prendrons comme un script gratuit pour tester l'existance des boites mails, et se retrouverons dans le cas de mazo0012 parce qu'ils n'ont pas pris la peine de l'étudier un peu pour l'utiliser intelligemment

 

DadouDuck, tous les informaticiens de plus de 40 ans sont des "bricoleurs" comme tu dis car il y a 20 ans les études d'informatiques consistaient à faire des maths (beaucoup) et que tu pouvais arriver j'usqu'au DESS à la fac sans jamais avoir toucher un clavier. Quand aux école d'ingénieurs, elle formait surtout des ingénieurs ... IBM :mrgreen: Et je ne parle du WEB, car les premières vraies formation sont apparues dans les années 2000.

Pour ce qui est des formations en entreprise, c'est encore autre chose car c'est généralement des formations à des Outils et non des concepts ou des technologies (rentabilité oblige).

Je suis ingénieur en informatique industrielle à la base (cad automates et automatisme voir automatique, microprocesseurs, électronique) Je n'ai jamais été formé au WEB et ses technologies et pourtant je me considère comme un professionnel dans mon domaine (et mes clients aussi du moins je l'espère :wink: ) , bien que j'ai appris ces technologies sur le tas, et sans jeu de mot sur le tard

J'ai arrêté d'enseigner car mes étudiants étaient plus intéressés par leurs "exams" que par la véritable compréhension des technologies enseignées et que dans la formation professionnelle la maîtrise des savoirs passait après la rentabilité.

Je me bat tous les jours dans le milieu associatif pour démystifier "les savoirs informatiques" car j'ai trop connu les informaticiens savants enfermées dans leur tour d'ivoire (tellement repliés sur eux mêmes qu'ils n'ont pas vu arriver la micro informatique et qu'ils en sont morts ! )

Le meilleur moyen d'amener le WEB à maturité c'est de diffuser le plus largement possible les savoirs et les connaissances. C'est la direction qu'ont choisis les inventeurs du WEB en diffusant librement, largement et gratuitement leur technologie, c'est également l'objectif des logiciels libres : je t’offre une technologie mais aussi et surtout, les moyens de savoir comment elle fonctionne.

Voilou! ces discussions philosophiques nous ont éloigné du sujet initial mis je pense que c'est un sujet important.

 

J'ai un peu le même cursus à savoir BTS info industrielle mais j'étais déjà sur le web à l'époque.

La raison pour laquelle je n'aime pas les bricoleurs, c'est que la plupart du temps, le bricoleur bricole sans toujours comprendre ce qu'il fait. Il se contente de patcher des petits trucs ensemble pour que cela tienne à peu près.

Et contre ce profil, je tire à boulet rouge !

Après il y a aussi des Mc Guyver mais tu me concèderas que si Mc Guyver fabrique des trucs avec des bouts de ficelle, il sait ce qu'il fait et pourquoi il le fait !!! C'est pas du tout la même catégorie et ici je tire mon chapeau ;-)

Comme l'a très justement souligné Dadouduck, la solution que tu as donnée va être copiée collée, sans que le bricoleur emprunteur ne prenne la peine de comprendre. Beaucoup ne liront même pas le contexte et les échanges de ce fil !
Résultat : Blacklistage sans qu'ils comprennent toujours pourquoi :-(

Pour ce qui est des gens qui ont appris sur le tas, je ne leur jette point la pierre vu que je suis passé par là également pour pas mal des choses que j'ai faites sur le web, vu qu'à l'époque rien n'existait. Ce qui importe c'est de comprendre et maitriser. Quand je vois des formations HTML ou on te pose directement les mains sur un Wysiwyg sans te faire comprendre le principe des balises, ça me hérisse.
Des formations sur la recherche d'information qui commencent par "voici Google", j'ai des boutons. Quand je donnais des formations sur ce sujet, on passait 1/2 journée sur l'essence même d'un moteur, d'un annuaire et sur une méthodologie pour que la connaissance acquise ne soit pas liée à un logiciel ou une technologie.
La démarche est loin du bricolage puisqu'on cherche à obtenir une maitrise des concepts. L'outil lui peut s'apprendre sur le tas ensuite.