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 5ème 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 by date of activity
127 discussions
Est_il possible de stopper l’envoi des infolettres sans désactiver les plugins mailshot et newsletters ?
Cela fait 2 fois que je me fais avoir sur une sauvegarde en local avec une infolettre planifiée qui repart avec le cron des mois après l’arrêt de la planification.
Je voudrais quand même pouvoir tester les envois. mais pas en pourrissant des centaines de destinataires...
Merci
Reply to this message
Bonjour,
question récurrente j’imagine (je l’ai vue sans réponse ...) :
que faire de ceci lorsqu’on ne fait pas appel à un service d’envoi en nombre externe (petit nombre, petite fréquence)
“Les envois échoués sont directement marqués en statut fail et ne sont pas relancés. Dans le cas d’un SMTP il pourrait être utile de faire plusieurs tentatives avant de déclarer l’envoi vers une adresse en echec (prise en compte des retry-later notamment).”
Comme il n’est pas possible d’exporter la liste des fails non plus et que je n’ai pas trouvé de dispositif pour faire plusieurs tentatives et que j’ai la certitude que la plupart des adresses en échec répondront (fait avec la fonction d’envoi test)
d’avance merci!
Je viens de mettre à jour ce paragraphe sur la gestion des erreurs car elle est implémentée dans le plugin depuis un moment déjà, même en SMTP, et donc si vous êtes à jour c’est que votre SMTP vous limite sur le nombre et/ou la fréquence des mails envoyés.
Et donc que vous devriez vraiment utiliser un prestataire externe dédié à ce type d’usage :)
merci pour ce retour rapide.
Le plugin a été mis à jour juste avant les deux derniers envois, l’un avec 7/22 fails l’autre avec 27/89 fails mais je ne vois aucun bouton pour effectuer une deuxième tentative d’envoi pour les recalés. Ainsi, je ne pense pas qu’ovh (puisqu’il s’agit d’ovh) puisse désactiver un bouton dans l’espace privé du site...
Je crains qu’il y ait autre chose pourtant tous les plugins ont été mis à jour.
y aurait-il d’autres causes?
Les envois indiqués en
fail
ont déjà fait l’objet de 5 tentatives. Le processus est interne et l’envoi n’est marqué échoué que si les 5 tentatives echouent.OVH a une limite sur le nombre et la fréquence des mails envoyés par leur SMTP, c’est fait exprès pour éviter les abus. Donc leur SMTP est très bien pour envoyer manuellement des emails depuis votre logiciel de mail, mais pas du tout pour envoyer une grande série.
A défaut vous pouvez utiliser le réglage de cadence maximale d’envoi, dans les réglages des plugins, qui permet de temporiser et d’envoyer les mails petit à petit pour ne pas déclencher les blocages des serveurs SMTP comme celui là.
merci pour ces infos car en effet il fallait deviner ces 5 tentatives successives.
Spontanément j’avais retiré l’info de la cadence et du nombre (mais pas encore fait de nouvel envoi).
Alors, voilà : ne sachant pas ces 5 tentatives, j’avais relevé la liste des “fails” (pas très simple car pour n’avoir que les adresses de messageries, il faut effacer la date, pas très élégant, mais faisable) puis j’ai collé ces adresses (une bonne vingtaine) dans un message avec l’URL de l’infolettre en ligne que j’ai envoyé.
J’ai alors reçu d’ovh les adresses en erreur, elles n’étaient plus que deux, l’une (un truc “marketing machin chose” sans lien avec l’objet de l’envoi), l’autre taxée de “n’existe pas” et toutes les autres sont passées soit une vingtaine. J’ai supprimé ces deux adresses de la liste mais pas encore fait de nouvel envoi.
Plusieurs questions à ce sujet : avec mailshot, nous ne recevons pas de message d’ovh concernant ces erreurs (?), il est possible qu’une ou deux adresses en erreur bloquent la suite (?). Par ailleurs, ovh nous oblige à cocher le SSL (déprécié) : ?
Enfin, pour certains sites (tous sous SPIP), j’ai du installer wanewsletter devant le nombre important de fails et la non réception de message d’ovh donnant les adresses en erreur et le motif. Wanewsletter fonctionne avec un script php donc sans identification de l’envoyeur si celui-ci met n’importe quelle adresse comme envoyeur (?).
Maintenant, je suis d’accord pour privilégier l’adresse authentifiée comme envoyeur ...
Voilà, c’est juste un retour.
Encore merci, on va se débrouiller.
Bon. On va commencer par le début :
Quelles que soient vos raisons que vous estimez légitimes, à partir du moment où vous faites de l’envoi d’email en nombre vous entrez dans la catégories des spammeurs, que vous le vouliez ou non.
Vous allez donc vous heurter à plein d’obstacles mis en places par tout ceux qui essayent de lutter contre le SPAM, car en tant qu’utilisateur tout le monde hait le SPAM, non ? ;)
1/ L’envoi par le serveur comme le fait wanewsletter c’est très mauvais. En tant qu’envoyeur il n’y a aucune erreur, donc vous avez l’impression que c’est bien, mais en fait vous n’avez peut-être aucun mail qui n’arrive. La raison pour laquelle c’est très mauvais est que tous les entêtes d’envois montrent que le mail a été envoyé par un serveur web (et pas un serveur de mail ni un prestataire d’envoi), ce qui est le comportement de 99% des spammeurs et donc déclenche toutes les alarmes partout où va passer le mail. Il a donc toutes les chances d’être bloqué quelque part avant d’arriver chez son destinataire.
C’est pour ça que cette option est volontairement bloquée dans MailShot. Ça ne sert à rien de faire ça si ce n’est à augmenter le volume de spam et de mail qui partent à la poubelle
2/ Non un envoi en erreur ne bloque pas les suivants, non il n’y a pas de problème de configuration de votre boite mail OVH sinon rien ne partirait.
Mais comme je l’ai dit avant, OVH limite le nombre de mail envoyé par heure (ou minute, ou jour, je ne me souviens plus) et au delà les envois sont en erreur.
Ce ne sont pas des problèmes avec les destinataires mais avec le SMTP
Là encore c’est pour éviter que vous utilisiez leur service de mail pour faire de l’envoi de SPAM
3/ Quand vous envoyez un mail manuellement, l’erreur vous revient en retour dans votre boite mail un peu plus tard (ou plus exactement dans l’adresse mail de retour des erreurs, qui, si elle n’est pas précisée, est la même que celle de l’envoi).
C’est comme ça que fonctionnent les MAIL, mais ça n’est pas du tout adapté à de l’envoi en masse. Pour avoir les erreurs il faut donc se connecter à l’adresse mail, relever les mails, les lire, et voir ceux qui correspondent à des erreurs d’envoi et à quelle adresse cela correspond. Pas pratique du tout. Une solution est d’avoir une boite mail spécifique pour les retour d’erreur, ce que le plugin vous permet de configurer. Ça permet déjà de n’avoir que des retours d’erreur dans cette boite mail. Ensuite le plugin peut éventuellement faire le relevé et gérer les erreurs, via une option disponible dans le code mais pas dans l’interface.
Parce que c’est pas du tout simple à utiliser et mettre en place et on a pas envie de faire le support pour ça.
4/ Utilisez un service d’envoi de mail en nombre. Vraiment. Définitivement. Arrêtez de perdre votre temps. Ou arrêtez d’envoyer des mails en nombre. Ça pollue, ça embête tout le monde, et en plus ils n’arrivent pas à destination.
Le SPAM gratuit et facile c’est fini, il y a eu tellement d’abus qu’il y a des tonnes de barrières à tous les étages…
je comprends votre mouvement d’humeur qui intéresse tout le monde en ce qui concerne les spam et pire encore. Le sujet est complexe.
Nous avons du fermer l’inscription et la remplacer par un formulaire qui permet de valider au coup par coup les demandes (un formulaire “formidable”). L’adresse d’envoi est selon mailshot qui est respectueux, une adresse authentifiée et c’est bien ainsi. Les intermédiaires quand le nombre des inscrits est faible, c’est de l’info qui part on ne sait où, c’est d’ailleurs encore plus vrai quand le nombre d’inscrits est très élevé. Leur objectif est bien sûr celui de toute société (faire des sous pour vivre).
Pour dire qu’il n’y a pas de bonne solution et que la meilleure est celle qu’on expérimente et qu’on choisit.
Bonjour Cerdic et je reviens à la charge ...
avec une précision : quand le spam vient de celui qui s’inscrit ... ça s’fait! juste pour préciser pourquoi l’inscription a été fermée (dans mon idée, c’est quelqu’un qui a voulu bien faire en “achetant” du trafic, du faux trafic. 100 à 200 inscrits par jour qui bien entendu ne confirment pas. pourtant l’antispam était activé. C’est juste une précision. mais peut-être auriez-vous une autre explication en lien avec l’antispam)
pour arriver à une suggestion : serait-il possible de créer un csv pour la liste des envois manqués?
Reply to this message
Bonjour à tous,
Je rencontre depuis ce matin un soucis avec tous mes sites (ils sont nombreux) exploitant Sparkpost.
Lors d’un envoi via l’API et le plugin newsletter, je reçois le message d’erreur suivant :
??? Fail recuperer_page array ( 'options' => array ( 'open_tracking' => false, 'clic_tracking' => false, ), 'campaign_id' => '', 'recipients' => array ( 0 => array ( 'address' => array ( 'email' => 'jul@blabla.com', 'name' => '', ), ), ), 'content' => array ( 'from' => array ( 'email' => 'jul@blabla.com', 'name' => 'Site de démonstration ', ), 'subject' => '[TEST] Petites annonces', 'headers' => array ( 'Errors-To' => 'no-reply@blabla.com', 'Precedence' => 'bulk', ), 'text' => '...', 'html' => '...', ), )
L’envoi via SMTP fonctionne sans soucis mais bon c’est dommage de perdre l’usage de l’API...
J’ai reçu un email de Sparkpost envoyant sur ce lien :
https://www.sparkpost.com/docs/tech-resources/tlsv1-0-test-hostname/
Visiblement il y a du changement de protocole TLS et des urls des serveurs à partir du 1er Juillet !
Je tiens à signaler que j’utilise SPIP 3.2.1 et que tous les plugins sont à jour.
Merci de votre assistance !
Après quelques recherches supplémentaires, je comprends les urls des serveurs ’Endpoints’ ne change pas.
SparkPost https://api.sparkpost.com/api/v1
SparkPost EU https://api.eu.sparkpost.com/api/v1
Par contre ils n’acceptent plus les requêtes en TLS v1.0 mais uniquement TLS v1.1 et +
https://www.sparkpost.com/blog/tls-v1-0-deprecation/
«On June 30th, 2018, SparkPost will be deprecating TLSv1.0 fallback across all of our systems. These older implementations contain very severe vulnerabilities that directly impact the integrity and security of your communications; vulnerabilities which cannot be fixed in these older implementations. As long as connections are made using TLSv1.1 or later, this change will result in zero impact to your ongoing use of our service. However, if connections are made using TLSv1.0, you will observe a failure to successfully connect to API and SMTP endpoints. To ensure that there is no impact to existing processes, it is best to verify that your clients support TLSv1.1 and/or TLSv1.2, and do not explicitly rely on SSL3 or TLSv1.0.»
https://www.sparkpost.com/blog/tls-v1-0-deprecation/
On June 30th, 2018, SparkPost will be deprecating TLSv1.0 fallback across all of our systems. These older implementations contain very severe vulnerabilities that directly impact the integrity and security of your communications; vulnerabilities which cannot be fixed in these older implementations. As long as connections are made using TLSv1.1 or later, this change will result in zero impact to your ongoing use of our service. However, if connections are made using TLSv1.0, you will observe a failure to successfully connect to API and SMTP endpoints. To ensure that there is no impact to existing processes, it is best to verify that your clients support TLSv1.1 and/or TLSv1.2, and do not explicitly rely on SSL3 or TLSv1.0.
Hello,
Tu n’es pas tout seul, il semble que cela soit générique du coté Sparkpost.
Le changement TLS est finalement annoncé pour le 09/07/18
Bonjour DD,
Le changement TLS est effectivement annoncé pour le 09/07/18 mais l’API est donc déjà inexploitable.
Il y aurait-t-il un hotfix envisageable?
Merci
Il semble qu’ils aient revert l’utilisation du TLSv1.2 obligatoire car cela remarche à nouveau sans rien changer au plugin.
Cela dit la version 1.25.0 du plugin corrigée par https://zone.spip.org/trac/spip-zone/changeset/110983/spip-zone fonctionne avec SparkPost SI le TLSv1.2 est bien disponible dans PHP, ce qui peut se vérifier depuis
ecrire/?exec=info
. Il faut impérativementtlsv1.2
dans la ligne :Bonjour Cerdic,
Excellente nouvelle! Par contre je ne vois pas la mise à jour sur mon dépot, ni dans cette page, on voit toujours la v1.24 et non pas v1.25.
Quelle est la marche à suivre?
Pour info j’héberge mes sites en Simple Hosting chez GANDI et je constate bien que le TLS1.2 est pris en charge :
Registered Stream Socket Transports tcp, udp, unix, udg, ssl, tls, tlsv1.0, tlsv1.1, tlsv1.2
Merci!
La mise en jour via SVP sera disponible vers 18h15 le temps que les paquets soit regenerés. Il faudra peut être actualisé tes depots manuellement.
a noter que curl n’est pas présent non plhus chez tous les hebergeurs (ecrire/?exec=info permet de s’en assurer)
Merci !
L’API est de nouveau fonctionnelle.
Je confirme !
Merci beaucoup
tout content de trouver ce fil surtout résolu avec une mise à jour, je me dépeche de mettre à jour, mais cela ne résoud pas le pb !
- j’utilise sparkpost depuis un bon moment
- le problème apparait pour un nouveau site ou j’ai reproduit la config des autres
- j’ai bien curl et tls dans ma config php mais pas tls1.2
- mais j’ai l’erreur suivante dans le log mailshot
2018-06-27 05:33:59 87.231.147.43 (pid 5012) :Pri:ERREUR: Erreur Envoi mail (email destinataire) via Facteur : Forbidden.
c’est donc peut-être plutôt un pb de confif sparkpost, mais je ne vois pas de différence avec les autres API et domaines configurés sur Sparkpost et mailshot...
merci d’avance d’une idée... je ne trouve pas de doc sur cette erreur “forbidden”...
pam
il te faut curl (exigence Spipienne) ET tls 1.2 (exigence sparkpost)
j’ai bien curl
mais uniquement tls, pas tls1.2... et j’ai bien sûr demandé à l’hébergeur (ovh) comment activer tls 1.2, sauf que la doc dit qu’il faut une config dénommée “stable” (parmi la liste des configs proposé par ovh) ce qui est mon cas, sans que tls12. ne soit activé...
mais ce qui est bizarre, c’est que les sites existants continuent à fonctionner.... sans tls1.2 et pas le nouveau site... peut-être que sparkpost n’impose tls1.2 que pour les nouvelles configs ?
pam
oups... finalement, c’était simple
il trainait un vieux fichier .ovhconfig dans un sous-répertoire avec les mauvaises directives...
en le supprimant, tout est OK pour la config. curl tls1.2..
mais j’ai toujours (après avoir vidé le cache !)
Forbidden. array ( ’options’ => array ( ’open_tracking’ => false, ’clic_tracking’ => false, ), ’campaign_id’ => ’’, ’recipients’ => array ( 0 => array ( ’address’ => array ( ’email’ => ’
après désinstallation complète de mailshot et réinstallation, ca fonctionne...
par contre, je ne sais pas pourquoi le téléchargement de mailshot se fait avec un zip et donc dans un dossier appelé mailshot-v1... alors que c’est le même que le mailshot tout court que j’avais ?
en tout cas, merci de la réactivité aux évolutions des normes !
bonjour j ai suivi le fil d’actualité d’abord comment savoir si on est passé tls1.2.
comment se fait la manipulation pour changer de tls 1.1 en tls 1.2.
Merci d’avance
ben...tout est dans le fil !
vérifie ce qui est activé dans ta config php en affichant la page ecrire/ ?exec=info (donc http://tondomaine.xxx/ecrire/?exec=info
tu vois une page de config php avec une ligne “Registered Stream Socket Transports” ou tu vois ou pas tls1.2...
chez ovh, on a automatiquement tls1.2 quand on a une config dite “stable”...ce qui se définit dans le fichier .ovhconfig qui doit être à la racine de ton hébergement...
bon courage !
Reply to this message
Depuis la dernière mise à jour (SPIP + plugins) dans la branche 3.1 les envois de test passent, mais les envois en nombre ne démarrent pas, même en s’efforçant d’activer le CRON
Où regarder pour savoir la raison de ce problème, et comment l’ameliorer ?
Précision : Je constate que les envois à une personne font apparaitre l’absence de champ expediteur (que l’on choisisse les réglages de SPIP ou personnalisant l’adresse d’envoi).
Je ne sais pas si cela est la raison, mais de toute évidence ce n’est pas normal.
Bonjour,
Tu as des captures des erreurs ?
Alors j’ai découvert que c’était un problème d’authentification auprès du serveur SMTP, que j’ai pu contourner. Désolé de ne pas avoir signalé la fin d’incident ici.
Le problème n’était donc pas lié à SPIP. SI c’est possible de dépublier ce fil, je pense que ce serait même préférable.
Reply to this message
Est-ce qu’il envisageable d’avoir une gestion de bounces avec Sparkpost ? Il faudrait implémenter cela comment ?
Maieul,
J’ai vu sur Sparkpost que l’on pouvait mettre un bounces sur un cname mais cela impose d’envoyer avec un sous domaine.
Je me trompe ?
Oui, sparkpost permet une gestion de bounce avec un sous domaine. Mais ma question était plutot : comment obtient t-on les résultats des bounces dans SPIP, et pas en allant dans l’interface sparkpost/en consultant l’API sparkpost
Je pense que si tu envoi avec un email est sur la config du bonce ça remonte mais du coup faut envoyer avec email.domaine.ext
tu n’a pas compris mon problème.
Sparkpost recoit parfaitement les infos de bounce, une fois les réglages faits, et je peux envoyer depuis mon domain principal. Pas de souci de ce côté là.
non, le problème est de récupéré les infos que sparkpost a recupéré chez SPIP.
parce que moi je bloque la dessus https://screenshots.firefox.com/lg5o2ddStI7pYtEa/app.sparkpost.com
il veut un sous domaine
oui il faut que tu crée un sous domain chez ton prestataires de domaines. avec un cname qui pointe vers sparkpost.
Oui et envoyer avec et ça doit le faire alors.
non, non ! tu envoie avec ton adresse sans le prefixe bounce !!
Ba non justement il faut que bounces.domaine.ext soit connu par sarkpost.
Ou alors je comprends rien.
oui boucne.domaine.ext doit être reconnu par sparkpost. MAIS pour autant, lorsque tu envoie via sparkpost, tu envoie via ton domaine principal.
En fait c’est assez “simple”.
1. Tu envoie depuis @domaine.tld via sparkpost
2. Sparkpost
a. Ajoute un entete indiquant que le bounce doit être envoyé sur bounce.domaine.tld
b. Envoie chaque message avec sa technique
3. En cas de bounce, le serveur qui recoit le message envoie le bounce non pas sur @domaine.tld mais sur @bounce.domaine.tld
4. Si tu a fais correctement tes réglages DNS, c’est donc sparkpost qui recoit les notifs de bounces
5. Il les analyses et te fournit ainsi les résultats de bounce. Cela lui sert également pour renvoyer les mails si besoins lorsque le bounce est de type “indisponibilité temporaire”.
Donc tu a juste à configurer bounce.domaine.tld en CNAM sur sparkpostmail.com chez ton fournisseur de domaine. Ensuite, tu attends les 3/4 heures de propagation, tu vérifie que sparkpost et ok, et ca roule.
Bonjour,
Je crois qu’il faut utiliser l’API et pas le SMTP pour que les infos sur les bounce / fail soit transmise à SPIP.
j’utilise l’API, et je les vois pas.
J’ai testé mais il faut envoyer avec bounces.... du coup .
heu ????? non moi j’envoie sans bounce, et l’API marche nickel....
on peut voir ta config ?
Bah heu, je met juste la clef d’APi quoi...
et tu as essayer d’envoyer avec le sous domaine ?
bah non, pourquoi faire?
Tester les bounces ;)
Mais ca n’a rien à voir !!!
tu as toujours rien compris, je sais plus comment t’expliqiuer les choses.
Tu envoie depuis ton domaine principal, et sparkpost recois les bounces !!!
Reply to this message
Bonsoir,
On peut envisager d’implémenter ceci dans la configuration https://www.sparkpost.com/blog/smart-send/ ?
Merci.
Cela me semble assez simple a faire avec une petite config, ça serait bien pour les grande liste ou peu de monde lit les emails.
Reply to this message
Hello,
J’utilisais sparkpost.com sans problème mais je n’arrive pas à faire fonctionner eu.sparkpost.com avec mailshot.
Est-ce que ce plugin est utilisable avec eu.sparkpost.com ?
J’ai le message d’erreur:
“Unauthorized. array ( ’options’ => array ( ’open_tracking’ => false, ’clic_tracking’ => false, ), ’campaign_id’ => ’’, ’recipients’ => array ( 0 => array ( ’address’ => array ( ’email’ => ’mon@site.fr’, ’name’ => ’’, ), ), ), ’content’ => array ( ’from’ => array ( ’email’ => ’mail@site.com’, ’name’ => ’Site’, ), ’subject’ => ’Info’, ’headers’ => array ( ’Precedence’ => ’bulk’, ), ’text’ => ’...’, ’html’ => ’...’, ), )”
Merci
Bonjour,
eu.sparkpost.com ne fonctionne pas comme domaine.
Pourquoi quitter sparkpost.com ?
L’API Sparkpost est utilisée avec le endpoint
https://api.sparkpost.com/api/v1/
codé en dur, donc non ça ne peut pas fonctionner aveceu.sparkpost.com
qui nécessite d’utiliser le endpointhttps://api.eu.sparkpost.com/api/v1
.Je vais regarder pour ajouter une option et prendre en charge la variante eu
OK la version 1.24 du plugin doit fonctionner avec eu.sparkpost.com, j’ai ajouté une option de configuration
https://zone.spip.org/trac/spip-zone/changeset/110537
(à tester)
Super merci bien je vais tester.
Avec eu.sparkpost.com les données sont stockées et traitées en Europe ; mais attention le quota maximum pour le “free plan” est de 750 envois / jour et contrairement à sparkpost.com il n’y a pas apparemment pas d’augmentation de celui-ci même si la réputation du compte (ie taux de bounce) est top.
Reply to this message
Bonjour
Sous “Gestion des erreurs” je lis : Dans le cas d’un SMTP il pourrait être utile de faire plusieurs tentatives avant de déclarer l’envoi vers une adresse en echec (prise en compte des retry-later notamment).
Où est-ce que ces plusieurs tentatives / le retry-later se metten en place ?
Merci d’avance : )
Reply to this message
bonjour
avec mailshot et un abonnement mailjet, j’ai une erreur quand je fais un envoi test :
merci si vous avez une piste
je précise :
spip 3.2
php 5.6
squelettes avec plein de plugins ...
merci
Bonsoir,
ce fil en dessous répond probablement à votre besoin d’infos : https://contrib.spip.net/Mailshot#forum494923
Reply to this message
Bonjour,
Je viens de recevoir l’info suivante en provenance de Sparkpost : est-ce que cela influe sur le plugin ou la configuration du plugin ?
Merci !!
Reply to this message
Add a comment
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.
Follow the comments: |