Mailshot permet l’envoi en nombre d’emails au moyen d’un SMTP (ou d’un service externe) dédié à cet effet. Il permet de limiter la cadence d’envoi.
Enfin, ce plugin implémente la partie send de l’API Newsletter et peut donc être utilisé avec les plugins Mailsubscribers et Newsletters pour l’envoi de Newsletters.
La question du SPAM
Avant de décrire en détail le fonctionnement du plugin, il est important de souligner que l’envoi de mails en nombre est rendu de plus en plus difficile en raison de la prédominance du SPAM. Plus de 95% des emails qui circulent sur les serveurs de courriers sont du SPAM. Les opérateurs de mails (FAI, gmail...) sont donc de plus en plus stricts dans les règles de filtrage.
En tant qu’éditeur de contenu et utilisateur de ce plugin, vous avez une responsabilité : n’envoyer du contenu qu’à des utilisateurs qui l’ont sollicité par une demande explicite. Lorsque vous ne respectez pas cette règle, vous envoyez des emails non sollicités, c’est à dire du SPAM. Et vous contribuez à renforcer les règles de filtrage des opérateurs de mail.
Cette situation généralisée entraine bien des désagréments :
- certains mails légitimes n’arrivent jamais à vos destinataires ;
- en tant qu’expéditeur régulier vous risquez d’être blacklisté, voire votre serveur risque d’être blacklisté.
C’est pour cette raison que ce plugin ne permets pas d’envoyer des mails à l’aide de la fonction mail() de PHP. Cette fonction permet l’envoi simple de mail, mais elle passe par un canal partagé entre tous les sites hébergés par un serveur. Si vous l’utilisez à mauvais escient, c’est tous les autres utilisateurs qui seront pénalisés.
C’est également pour cette raison que ce plugin propose d’utiliser un service d’envoi de mail (serveur SMTP dédié, service externe commercial) spécifique à cet usage. Ainsi, même si vos envois en nombre déclenchent - à tort ou à raison - un filtrage chez les opérateurs de mail, le reste du fonctionnement du site n’en sera pas affecté (envoi des mails d’inscriptions, de formulaire de contact, de notification de forum, de pétitions...). Utilisez cette possibilité et protégez le fonctionnement quotidien de votre site web.
Ou alors ne venez pas demander de l’aide sur vos mails en erreur, on vous aura prévenu.
Installation
L’installation du plugin nécessite le plugin Facteur qui prend en charge l’envoi des mails à l’aide d’un serveur SMTP.
Configuration
La configuration du plugin concerne le service d’envoi qui sera utilisé pour les envois en nombre ainsi que les réglages d’expéditeur (nom et email) :
Service d’envoi
Le réglage par défaut est d’utiliser le même service d’envoi que pour les autres mails (soit le serveur de mail SMTP configuré dans le plugin Facteur). Ce réglage fonctionne mais n’est pas conseillé comme indiqué plus haut.
Si aucun serveur SMTP n’est configuré par défaut, le premier choix est désactivé comme ceci :
Cette fois vous n’y couperez pas : vous devez alors absolument choisir un autre service pour l’envoi de vos emails.
Vous pouvez configurer un serveur SMTP (celui qui gère les emails de votre nom de domaine, Gmail...) (assurez vous dans tous les cas qu’il accepte que vous passiez par lui pour cet usage) :
Sinon, et c’est la solution la plus fiable, il vaut mieux utiliser un service dédié à l’envoi de mails en nombre comme Mailjet [1], Sparkpost [2] ou Mandrill [3] (disclaimer : l’auteur n’a aucun intérêt dans ces services commerciaux).
Le plugin propose aussi l’utilisation du service Mandrill, mais celui-ci est désormais soumis à l’utilisation d’un compte MailChimp payant, ce qui en restreint l’accès.
Cadence d’envoi
Dans tous les cas, que vous utilisiez un serveur SMTP ou un service externe, il est possible, voire probable, que vous soyez soumis à une cadence d’envoi maximale (nombre maximum de mails par quart-d’heure, par heure, par jour...). Dans ce cas là, convertissez cette cadence maximale en nombre de mail par jour et renseignez le champ Limiter la cadence d’envoi. La cadence sera prise en compte en espaçant l’envoi des mails de façon régulière pour ne pas dépasser cette moyenne journalière.
Envoi rapide
A contrario, si vous utilisez un service d’envoi capable d’envoyer très vite, ou de tout recevoir très vite et de mettre en attente les envois surnuméraires (c’est le cas de Mandrill notamment), vous pouvez activer l’option d’envoi rapide.
Quand cette option est cochée le plugin essaye d’envoyer aussi rapidement que possible à tous les destinataires. Notamment, en fonction du nombre d’envoi total à réaliser, il va lancer des processus parallèles pour accélérer le traitement, en étant capable par exemple d’envoyer 50 000 mails/heure si on a 200 000 destinataires.
Attention toutefois, envoyer rapidement un grand nombre de mails est une chose, mais il faut penser que cela va provoquer un pic de visites simultanées sur votre site, et que votre hébergement doit aussi être dimensionné pour absorber ce trafic supplémentaire.
Expéditeur
La dernière partie du formulaire permet de fixer les noms et emails de l’expéditeur qui apparaitra sur vos envois en nombre.
Historique des envois
Pour chaque envoi, le plugin conserve un historique de chaque adresse mail destinataire, date d’envoi, et statut (lu, cliqué, rejeté…) si il est récupéré depuis un service externe. Si vous envoyez beaucoup de lettres à beaucoup de destinataires, cela peut faire grossir la base de données de manière excessive, et dans ce cas il est préférable de purger les statistiques d’envoi pour les vieux envois.
Seul le détail des statistiques sera purgé, mais vous conserverez une statistique globale du nombre de mails reçus, lus, cliqués, rejetés…
Personnalisation du contenu des courriels
Avant chaque envoi d’un email, le plugin déclenche la personnalisation du mail à l’aide des variables qui décrivent le destinataire (voir Newsletters).
Les variables sont celles fournies par le plugin Mailsubscribers pour la description d’un inscrit :
- nom
- listes
- lang
- status
- url_unsubscribe
Pour plus de détail, voir ce que retourne la methode newsletter/subscriber de l’API Newsletter.
Lors de l’envoi à un email unique qui n’est pas forcément inscrit, le plugin essaye de remplir au mieux les variables.
Envoi d’une Info-lettre
L’envoi d’une info-lettre se fait depuis la page d’administration de l’info-lettre, tel que décrit par Newsletters. Un formulaire d’envoi est disponible :
Si la première partie du formulaire sert à faire un envoi unitaire, c’est ici la seconde partie qui nous intéresse. En sélectionnant une liste d’inscrits, on peut déclencher l’envoi en masse à cette adresse en cliquant sur le bouton « Envoyer ! » en regard du selecteur :
On reçoit alors un message de confirmation du déclenchement de l’envoi, et l’envoi en cours apparaît en bas du formulaire. Un résumé de l’avancement apparaît (exprimé en nombre de mails envoyés par rapport nombre total de destinataires). Des boutons de contrôle permettent de mettre l’envoi en pause ou d’abandonner l’envoi.
Tant qu’un envoi est en cours, la liste est rafraichie toutes les 2minutes pour afficher la progression de l’envoi.
Suivi des envois de lot
Il est possible d’avoir une vision plus détaillée des envois de lot (passés en en cours). Pour cela, utilisez le menu Publication > Suivi des envois de mails en nombre. Vous accédez alors à une page qui récapitule les envois en cours et les envois terminés :
Les lots d’envoi en cours sont affichés d’une puce orange, les envois en pause d’une puce blanche, les envois terminés d’une puce verte et les envois abandonnés d’une puce rouge.
Si on clic sur le lien Envoi N°x d’un des envois, on arrive sur une page récapitulative complète qui expose la date et l’avancement de l’envoi, le contenu HTML et texte envoyé, ainsi que la liste des destinataires :
Les destinataires sont regroupés par statut (envoi à venir, envoi réussi, email ouvert, email cliqué, envoi échoué). Il est ainsi possible de retrouver si l’email a déjà été envoyé à un destinataire particulier, ou si il l’a ouvert, ou cliqué sur un lien [4].
Gestion des erreurs
Lorsque l’envoi à un destinataire échoue, on incrémente un compteur de tentative pour ré-essayer en fin de lot. À la 5e tentative en échec l’envoi est marqué en statut fail et n’est plus relancé.
Il est possible de personnaliser ce nombre de 5 tentatives en définissant la constante define('_MAILSHOT_MAX_TRY', 5);
La gestion des bounce est prise en charge avec le service Mandrill qui notifie en HTTP pour signaler quand un envoi a été rejeté. Dans le cas de l’envoi par SMTP on ne gère pas les bounce (l’API interne le permet au moyen de la fonction newsletter/feedback mais il faut implémenter la partie relève d’une boite mail qui sert à collecter les bounces).
Pour le service Mailjet, l’API calcule les bounces.
Si la même adresse de destinataire a été vue en échec ou en bounce lors des 3 derniers envois (et que chacun de ces envois a réussi pour au moins un destinataire) cette adresse est automatiquement désabonnée de toutes les listes.
Il est possible de personnaliser ce seuil de 3 envois en définissant la constante define('_MAILSHOT_MAX_FAIL', 3);
En cas de non-déclenchement des envois :
Si l’envoi ne démarre pas ou met du temps, c’est parce que le cron de SPIP ne fonctionne pas ou pas assez souvent. Vous pouvez le forcer à la main en appelant l’url spip.php?action=cron mais en général c’est lié à un hebergeur qui bloque les appels http sortant, ou un site avec vraiment très peu de traffic.
Dans ce cas, un paliatif peut-être d’ajouter dans le fichier mes_options.php la ligne :
define('_HTML_BG_CRON_FORCE',true);
Migration depuis un ancien plugin
Lors de l’installation, le plugin regarde si les plugins SPIP-Listes ou SPIP-Lettre étaient auparavant utilisés. Si les tables correspondantes sont détectées, l’historique des envois (et des destinataires si possible) est automatiquement importé. Il contient naturellement le contenu HTML et Texte qui avait été envoyé.
Après avoir installé le plugin Mailshot et vérifié que toutes les anciens envois ont bien été importés, vous pouvez désinstaller votre ancien plugin pour supprimer ses données si vous le souhaitez.
Discussions par date d’activité
127 discussions
Bonjour et félicitations pour cet excellent plugin.
Une remarque concernant la gestion des erreurs : actuellement, Mailshot gère une liste des « envois échoués », comme expliqué clairement dans la doc.
Est-il possible de prévoir une évolution du plugin, qui consisterait à pouvoir re-tenter l’envoi des « échoués » svp ? Dans certains cas, ça représente un gros volume de messages, qu’il est impossible de refaire partir autrement.
Merci par avance.
Les envois sont marqués « échoués » dans 2 cas différents :
Dans les deux cas il n’est pas très pertinent de re-forcer un nouvel envoi, si ce n’est de risquer de se faire étiqueter spammeur par un des SMTP sur la chaine de livraison du mail.
A priori les envois échoué correspondent à des adresses qui ne sont plus valides donc, d’une façon ou d’une autre.
Bonsoir Cédric,
Merci beaucoup pour ta réponse très complète. Sauf erreur de ma part les détails que tu donnes concernant les envois « échoués » ne figurent pas dans la documentation, ce serait bien de les y mettre ?
Je trouve que la stratégie est bonne, effectivement si l’envoi est tenté 5 fois il est inutile d’insister.
Pour en revenir à mon problème il s’agit sûrement d’un problème de paramétrage de mon côté : sur 310 e-mails j’ai 135 « fails », c’est énorme !
Etant sur un serveur mutualisé OVH, il semblerait que je ne sois pas un cas unique :
https://www.mail-archive.com/spip@rezo.net/msg60215.html
Je vais chercher une solution de ce côté.
Ah oui il ne faut pas utiliser le SMTP OVH, il a des protections contre l’envoi en masse. Je te conseille d’utiliser Mailjet ou Mandrill, le service est gratuit pour les volumes que tu as, et les envois seront de bien meilleure qualité (mails qui n’arrivent pas dans les SPAMs, tracking ouverture/clic/rejets..)
Cerdic, je reviens sur ce sujet pour dire qu’après abandon de l’envoi via OVH + utilisation de l’API de Mandrill, ça fonctionne largement mieux !
Concernant Mailshot ça roule parfaitement, mais il reste un problème pour la gestion des newsletters. La gestion des abonnements (inscriptions, désinscriptions) repose sur le plugin « Mailsuscribers », qui fait lui-même reposer les envois de message sur « Facteur ».
« Facteur » ne sait pas s’interfacer avec Mandrill, il propose la fonction mail() de PHP ou de passer par le SMTP (et donc dans lon cas par OVH, ce qui ne fonctionne pas ou très mal). Je pense aller soumettre le problème sur la page de « Facteur », car j’imagine qu’on est assez nombreux à rencontrer ces problèmes à cause d’OVH.
Encore merci pour les infos.
Pour facteur tu peux utiliser la fonction
mail()mais tu peux aussi utiliser Mandrill : dans ton interface d’admin mandrill il t’es indiqué des paramètres à utiliser en SMTP que tu peux mettre dans Facteur. Ainsi tous tes mails passeront par Mandrill.Répondre à ce message
Bonjour,
Et merci pour votre plugin Mailshot que je teste actuellement pour un
site associatif .
Je l’utilise conjointement avec l’API de Mandrill et le tout semble
fonctionner parfaitement sur de « petits envois ».
Le problème c’est que nous sommes la version numérique d’une revue
associative qui existe depuis plus de 20 ans, et que nos envois peuvent
concerner jusqu’à 28000 contacts pour une newsletter.
Mailshot peut-il traiter ce type d’envoi avec ses réglages par défaut, y
a t’il quelque à modifier dans le code pour établir une stratégie
d’envoi, ou n’est-ce pas possible du tout ?
C’est une question un peu bête mais je ne souhaite pas faire de « grosse
bavure ».
Merci d’avance pour vos retours !
Sébastien.
Répondre à ce message
Bonjour,
J’ai un petit problème avec mailshot avec un compte mailjet.
Pour les nouveaux comptes chez mailjet, le serveur d’envoi n’est plus le même.
Il faut aller changer manuellement la variable « host » dans le fichier bulkmailer/mailjet.php pour que cela fonctionne.
Comment intégrer le choix du serveur d’envoi dans la configuration du plugin ?
Merci
Salut,
merci pour cette info... j’ai passé qqs heures à faire des tests entre 2 comptes, dont un ancien qui fonctionnait parfaitement ! A s’arracher les cheveux :)
Pour plus de précision, la modif est à faire L42 de bulkmailer/mailjet.php :
au lieu de
Oui en effet, ils ont changé le nom du serveur, mais aussi l’API, donc cette modif permet bien l’envoi des mails, mais ne suffit pas car on ne pourra pas exploiter l’analyse des envois etc.
Je regarde cela dans un futur proche (j’espère).
Salut Cédric,
super nouvelle, tiens nous au courant...
Et merci, hein :)
jean marie
Répondre à ce message
Bonjour,
est-il possible d’utiliser Mailshot en « Standalone » ?
Je m’explique : je voudrais pourvoir envoyer des mails aux auteurs du site (des adhérents de l’association avec le statut ’visiteur’. Et ils sont nombreux.
La fonction ’newsletter_bulkstart’ est particulièrement intéressante puisque elle permet de fractionner les envois et ainsi éviter que le serveur SMTP ne considère l’envoi comme du spam.
Toutefois, l’argument ’listes’ fait référence à une une liste référencé dans « Mailsubscriber ». Est-il possible de surcharger cette fonction pour que l’argument "listes’ soit un array contenant le listing des adresses emails ?
Peetdu.
Répondre à ce message
Bonjour,
Je viens de passer un site en 3.0.16 et j’ai mis en place les plugins newsletter avec lesquels j’ai eu un petit souci, j’avais oublié ne pas avoir cURL sur ce serveur. J’ai installé mais à cette occasion j’ai un peu épluché les spip.log et j’ai trouvé sur tous les sites avec ces plugins les erreurs suivantes :
1/
Jul 24 18:13:11 XXX.XXX.XXX.XXX (pid 23195) :Pri:WARNING: Contextes AJAX forces en fichiers ! Cela arrive lorsque la valeur du contexte depasse la longueur maximale autorisee par Suhosin (1024) dans 'suhosin.get.max_value_length'. Ici : 1368. Vous devriez modifier les parametres de Suhosin pour accepter au moins 1024 caracteres.J’ai effectivement suhoshin mais le msg d’erreur est marrant car il suggère de mettre une valeur inférieure à ce dont on a besoin, en l’occurrence il faudrait ici au moins 1368 ... en plus cela peut troubler le chaland, moi j’avais déjà 1024. Bref j’ai mis 1536, erreur disparue
2/
Jul 24 18:26:50 XXX.XXX.XXX.XXX (pid 14467) :Pri:ERREUR: fonction execute_pipeline_newsletter_pre_envoi absente : pipeline desactiveLà effectivement je ne trouve cette fonction nulle part ... ? Comment pourrait-on corriger ça ?
Merci.
L’envoie de la newsletter est lent et j’ai également ce message d’erreur : ERREUR : fonction execute_pipeline_newsletter_pre_envoi absente : pipeline desactive.
Est ce que quelqu’un aurait une solution ?
Merci d’avance.
Bonjour, pas d’inquietude concernant ce log sur newsletter_pre_envoi, c’est bénin.
Si l’envoi des newsletter est lent ou bloqué cela vient du cron du site qui ne fonctionne pas assez souvent parce que le site est peu fréquenté ou que l’hébergeur empeche les appels http sortant qui sont utilisés pour appeler le cron.
Dans ce cas, un paliatif peut-être d’ajouter la ligne
dans le fichier mes_options.php
Répondre à ce message
bonjour,
un message d’errrer surprenant en tentant d’afficher le suivi d’une infolettre qui ne partait pas...
Erreur SQL 1054
Unknown column ’maj’ in ’order clause’
SELECT id_mailshot AS id, sujet AS titre, 0 AS id_parent FROM spip_mailshots WHERE id_mailshot=390 ORDER BY 0+titre,titre,maj DESC
effectivement, le champ « maj » n’existe pas dans cette table...
pam
Bonjour, cela vient du plugin numérotation rapide et a été corrigé récemment !
Répondre à ce message
Salut cedric :-)
Après l’envoi d’une lettre, j’ai reçu par mail de mandrill :
Your Mandrill webhook at URL .../mailshot_webhook.api/mandrill/ has failed with the following error: POST to .../mailshot_webhook.api/mandrill/ failed with 404: <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>404 Not Found</title> </head><body> <h1>Not Found</h1> <p>The requested URL /mailshot_webhook.api/mandrill/ was not found on this server.</p> </body></html> .Tu aurais une idée du pourquoi ? Sachant que le site est un SPIP 3.0.17 [21515] en php 5.4.30 et MySQL
Habituellement j’ai pas de problème. Les plugs sont en version.
MailShot 1.6.5
MailSubscribers 1.5.5
Newsletters 1.3.5
Franck
Il faut t’assurer que tu as bien un fichier
.htaccessactif avec les lignesRépondre à ce message
Merci Cédric pour toutes ces explications précises concernant l’envoi en nombre et l’usage des fournisseurs d’emailing.
Par besoin de trouver quelques fonctionnalités de personnalisation des infoslettres (pouvoir choisir de les envoyer en français, en Belge , et en chti ou en Letton) j’ai cherché à comparer quelques fournisseurs comme « mailjet », « mandrill », etc ....
J’ai trouvé ce comparatif de fournisseurs d’emailing trés complet et bien renseigné.
Je le partage aux lecteurs de cette page, à qui il rendra probablement service : http://socialcompare.com/fr/comparison/transactional-emailing-providers-mailjet-sendgrid-critsend
Pour avoir utilisé "www.mailjet.com" avec satisfaction, par curiosité j’ai voulu tester https://fr.sendinblue.com et j’avoue que pour un certain nombre de fonctionnalités les services sont bien pratiques avec plus de fonctions.
Il n’y a pas encore d’API Sendinblue adaptée à SPIP. est-ce que c’est quelque chose qui peut s’envisager ?
Est-ce que d’autres spipeurs de Flandres et de Navarre en passant par la Lorraine auraient aussi utilisé Sendinblue ?.
Merci de tous vos avis et retours qui seront utiles.
Bon week-end.
Répondre à ce message
Bonjour,
J’ai un site peu fréquenté, et 430 inscrits à la newsletter (invitations à des concerts pour un restaurant).
Le cron se déclenche toutes les 6 minutes et fait 1 envoi s’il y a un hit sur le site (si j’ai bien compris).
Passant par mailjet, j’ai configuré à 200 envois par jours.
Mais ma newsletter met au moins 5 jours à partir.
Est-ce que je peux modifier le plugin pour qu’il fasse plus d’envois par visite du site ?
Merci !
Est-ce que tu utilises bien la dernière version du plugin ? Car les problèmes de cadence ont normalement été corrigés… a moins que cela reste encore perfectible sur les sites très peu visités.
Avec 430 inscrits et 200 envois par jours, il faudrait normalement un peu plus de 2 jours pour l’envoi.
Tu peux tricher en augmentant simplement le nombre d’envois par jour : en indiquant 400 au lieu de 200 le plugin enverra les mails 2 fois plus vite (mais il se peut alors qu’il ne respecte pas le nombre maxi de 200 sur une journée).
Bonjour Cedric et merci.
J’utilise la version 1.6.5 (j’aurais du préciser).
Envoie ce matin à 11h30. 16 mails sont partis (il est presque 16 heures)
Je vais essayer de monter à 400 et de conserver un œil dessus, mais est-ce que la modif ser aprise en compte pour cet envoi ?
Passé à 400 envois par jour.
Je ne m’en suis pas trop occupé cet après-midi et j’en suis à 32/434.
Donc maintenant, Mailshot envoie 2 mails à chaque hit.
Existe-il un moyen d’en envoyer dix et de respecter la limite ?
Comme l’augmentation ne changeait rien, j’ai mis un auto-refresh sur une page et rebaisser la cadence à 200/jour.
L’envoi est maintenant « fini » à 80/434.
Y a-t-il un moyen de le relancer ?
Répondre à ce message
Bonjour,
SPIP 3.0.16
MailShot 1.6.5
Newsletters 1.3.2
J’ai un problème avec MailShot, qui vient surement de la config de l’hébergeur de mon client (planet-works), car quand je teste depuis mon hébergeur (alwaysdata) tout marche bien.
Quand je veux tester avec envoi unique, via le service Mandrill,
cela me répond « API call to messages/send failed : Empty reply from server »
Si dans la config, je choisis serveur SMTP cela me répond « SMTP Error : Data not accepted. »
L’une et l’autre des options dans la config marchent bien quand je teste depuis mon hébergeur. Donc il doit y avoir qque chose qui coince du coté de l’hébergeur de mon client, mais quoi ?
Merci de vos lumières
Répondre à ce message
Ajouter un commentaire
Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :
Merci d’avance pour les personnes qui vous aideront !
Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.
Suivre les commentaires :
|
