Bonjour,
 
Le sujet doit déjà avoir été lancé depuis longtemps mais je voudrais avoir quelques informations quand a l'utilisations des newsletter :
 
Pour la mise en place d'une newsletter simple comptant maximum 100 envois par jours.
 
Les 3 solutions qui s'offrent a moi sont :
 
- Utiliser un server SMTP en local
- Utiliser le server SMTP du FAI
- Utiliser le server SMTP du server d'hebergement (en cas d'hebergement)
 
De ces 3 possibilitées je retiens qu'il ya un probleme : le blacklistage.
 
Utiliser un server SMTP local pourrait me faire blacklister par mon hebergeur, utiliser celui du FAI aussi, donc je pense me tourner vers la 3eme solution (la meilleur ?) et utiliser le SMTP de l'hebergeur.
 
L'hebergeur en question est : Hostpanel.
 
Après avoir appeler celui ci explique que les mails envoyés peuvent être bloquer par Hotmail par exemple et qu'il faut contourner le problème de son côté, l'hebergeur explique qu'il utilise une methode (en quoi consiste elle ? est ce la meilleur solution ?).
 
Si il indique qu'il est mieux de passer par l'hebergement pour ne pas se faire blacklister il me faut alors utiliser un script qui sois sur de ne pas bloquer et de ne pas pouvoir être hacker par les header ...
 
Bref, je me demande si cette solution reste la meilleur ?
 
Ensuite dans le cas d'utilisation d'un script PHP, lequel serait le plus adapté a l'envois que je veux faire c'est a dire envois d'informations simple au format HTML pour une centaines d'envois par jour ?
 
Après quelque recherche sur le net il existe énormement de script newsletter dont certains sont sur de se voir hacker le plus rapidement possible, mais dans cette masse de script, il deviens difficile de choisir.
 
Quel type de script recommandez vous niveau sécurité et pourquoi ?

salut,
 
Qu'est ce que ca signifie, 'se faire hacker par les headers' ?  
 
 
(je sais que le moment est mal choisit mais bon...)  
=)
 
 

Bonsoir,
sinon, il existe wanewsletter

Bonjour,
 
Suite au dernier message, ayant tester une premiere newsletter a savoir WAnewsletter, les questions de sécurité se posent. Ce systeme de news est il fiable ?
 
Ce systeme de mail servira pour un projet profesionnel, je ne demande pas de me pondre un script tout fait mais simplement des informations quand a la sécurité et surtout avoir l'experiences de developpeur ayant utilisé les differents systemes.
 
Sur le site : http://www.certa.ssi.gouv.fr
 
On trouve des failles de sécurité en grand nombre, les utilisateurs retrouvent aussi beaucoup de problème quand aux attaques, récuperation de listes et autres spam bot qui èrent sur le net.
 
Dans l'absolu je ne connais quasiment pas de systeme de hack de newsletter, d'ailleurs leurs failles associés me sont inconnues, mais après quelque recherche sur le net, il deviens difficile de savoir qui utilise "ze systeme" et surtout pourquoi ?

Salut,
ayant créé NewsletTux qui propose le même style de service que WA Newsletter, je peux apporter mon point de vue sur la question ...
 
Concernant les blacklistages, c'est très difficile de satisfaire tout le monde. Si tu n'es pas dans le spam/indésirable d'hotmail (puisque c'est celui qui est cité), rien ne garantit que tu ne le seras pas demain non plus : les filtres sont régulièrement mis à jour, et les serveurs de messagerie très avares en réponses concrètes.
 
Quant à tester l'existence d'une adresse mail, c'est tout bonnement impossible : les serveurs mails rejettent ce genre de demande et ton script PHP (quel qu'il soit) pourrait l'assimiler à une non-existence de l'adresse. Sur certains serveurs, *au mieux*, tu pourras tester que le domaine machin.tld existe, mais jamais tu n'obtiendras (à l'heure actuelle) de réponse sur user@machin.tld
 
Concernant les attaques par injection de headers, j'ai fait attention dans mon système à ceci : primo, à aucun moment pour rédiger une newsletter tu ne rentres manuellement d'adresse mail (donc pas de danger de rentrer n'importe quoi), deuxio, lors de l'inscription d'un abonné (puisque c'est la porte d'entrée pour les emails) l'email est vérifié par pattern design, c.à.d. que je lui dis "si la suite de caractèrees rentrée ressemble à machin@truc.tld alors tu gardes" => les injections de headers peuvent se faire là également mais sont bloquées par ce système.
 
Enfin tertio, le système d'écriture de newsletter dans mon script est contrôlé par les sessions PHP réputées pour leur sécurité. Et il existe un mode "administrateur" du script (où tu pourras manuellement ajouter des emails à une liste de diffusion) et un mode "écrivain" qui ne pourra rien faire de tout ça, il ne pourra qu'écrire la newsletter (et encore, selon ce qu'on lui a permis).
 
Pour ajouter un dernier argument, les emails sont envoyés en clair, c.à.d. en objet direct : pas de copie carbone, pas de copie cachée. Le système d'envoi des emails le gère, mais dans mon script, il n'est à aucun endroit utilisé.
 
Je dis cela sur mon script, je ne dénigre pas pour autant WA Newsletter, l'auteur peut également s'exprimer quant à son script.
 
 
Les meilleurs moyens que je vois pour vérifier les emails sont :
- avertir l'utilisateur de penser à vérifier son courrier indésirable
- demander la validation de l'email ... par email
 
si tu as 100 envois par jour, fais attention à ne pas passer pour un spammeur également (d'où l'intérêt de demander aux gens d'ouvrir leur courrier indésirable et d'autoriser les envois de ton site).

 
Merci pour ta réponse NewsletTux
 
En fait j'ai hesiter entre 2 methodes :
 
- Passer par un outil déjà fait (WAnewsletter etc ...)
- Passer par un script creer a la main
 
Pour le script déjà fait j'ai tester WAnewsletter et son utilisation est très simple, couplé a un FCKeditor pour un utilisateur sans connaissances HTML, plus acces user friendly, mais aussi risque de hack, car systeme open source connu.
 
Pour le script faire maison, pas mal de questions de sécurité lié aux Headers, en fait beaucoup d'articles tournent sur internet pour la sécurité mais je pense que certains articles datant de 2003 sont devenus obsolote.
 
Donc le script fait main pourrait être aussi dangereux que l'open source connu, puisque les failles de mail() et compagnie sont déjà bien connues des bot et hack en tout genre. Vouloir faire un systeme plus personnalisé me verrais peut être retourner les même erreurs voir plus qu'un open source.
 
Dans les 2 cas il ya pas de risque 0, les 2 peuvent être bouffer je pense d'une manière ou d'une autre.
 
Comme les outils déjà fait possedent une communautée et des codeurs ainsi que des mis a jour je me suis tourné vers cette solution.
 
Pour le blacklistage je pense qu'il n'y a plus de problem puisque les bloqueurs se font du type :
 
DNS Lookup Adresse DNS d'envoie (Ip du server) = Ip du SMTP
 
Hors sur une solution en hebergement mutualisé la question est reglé de plus Wanewsletter permet d'envoyer par flots de mails donc sans risque.
 
C'est vraiment les failles sur les header, injection sql et tout autre type d'attaques que je voudrais éviter, en passant par une fonction coder moi même je n'aurais pas les connaissances de tout les systemes de protection.
 
Utiliser un script fait main est il plus securisé qu'utiliser WAnewsletter ?
 
Entre les 2 mon coeur balance.

 
En fait ce que j'entendss pas le hack de header, c'est l'utiliser s'il est stocker directement sur la page, penser aux injections SQL et ce genre d'attaques, mais comme je le dis dans le message précédent il m'est encore inconnu toute les failles de ce type, et donc la protection du script par la même occasion.

Oui tout à fait ... Mon script ne l'a pas, nativement, mais on peut facilement le rajouter dessus.
 

Pas forcément, certains techniques sont toujours d'actualité ... Bien que l'évolution des systèmes tels qu' Apache tend à montrer qu'on comble des failles, mais combler une faille peut en ouvrir une autre dont nous n'avons, à l'heure actuelle, pas conscience ...
 

C'est l'avantage (indéniable) de l'open source, d'avoir une communauté de personnes prêtes à "mettre les mains dans le cambouis". Et la plupart des gens qui font des scripts "open source" ont commencé "à la main", seuls. Le risque 0 n'existe pas, et tu as raison de le souligner, mais ce qu'il faut savoir, c'est par rapport au besoin que tu as : un système "tout prêt" est-il assez malléable pour que je puisse l'adapter, ou dois-je repartir de 0 et en recréer un ? voilà l'une des questions que tu dois te poser, concernant la malléabilité de mon script, si tu as des questions sur ce point, je peux y répondre (WA Newsletter, je ne peux pas y répondre par contre )
L'autre question qui émane de tes message se base sur la sécurité, là je suis tenté de dire "on n'est jamais mieux servi que par soi-même", c'est ce qui m'a amené à faire mon script. De là, tu peux choisir de partir vers un script codé à la main, mais de combien de temps disposes-tu pour le faire ?
Si tu pars sur du "tout prêt", (ce qui n'est pas forcément signe de mauvaise qualité), regarde comment évolue la communauté du script, regarde ses perspectives d'avenir, regarde comment les gens résolvent leurs erreurs ... Si c'est facile et rapide, tu peux te dire qu'avec ce type de script si jamais tu rencontres une erreur, statistiquement parlant tu as de fortes chances de la résoudre vite et bien.
 

NewsletTux le permet aussi, via un SMTP externe (je sais que mon hébergeur, Nuxit, a mis à la disposition de ses clients un serveur SMTP pour ce type d'envoi, précisément).
 

 
Tu peux utiliser un peu de bon sens déjà, si tu dois recevoir un email, vérifier que c'est bien du texte, avec un arobase, etc. Puis après, il y a les réflexes du développeur, d'une part, et l'ouverture d'esprit aux sites de sécurité des données. Sans parler du fait que si tu "adhères" à une communauté d'un logiciel open source, outre le fait d'avoir le code source complet et accessible du logiciel, tu as aussi les réactions de la communauté, avec ce que ça apporte : les infos de bonne qualité, comme celles de moins bonne, mais en principe les gens savent se corriger ... Et puis concernant les 2 scripts cités (WA Newsletter et NewsletTux), il y a une personne à la tête de chaque projet, qui est censée avoir un minimum de connaissances pour trancher s'il y a des points délicats, tu n'es pas non plus perdu dans un monde de gens dont personne ne se dégage pour trancher sur des décisions.
 

Eh bien je ne pense pas qu'au sortir de ma réponse tu aies la décision toute faite, ce que je peux te conseiller, dans l'absolu, c'est d'essayer un "tout fait" pour le décortiquer : voir ce qui se passe, comment sont traitées les données, etc : de là, tu apprécieras la qualité du travail, en te documentant sur ce qui peut se faire, ce qui peut soit te donner l'envie de l'adopter ("et plus si affinités" ) soit t'en inspirer pour créer ton propre script, qui te conviendra à 100% ...
 
Bon courage en tous cas !