Bonjour,
Je gère une liste par le plugin newsletter/mailsubscribers (par obligation, je n'ai pas à disposition un vrai gestionnaire de listes) et je voudrais savoir s'il y a un moyen, ou si on peut l'implémenter, de mettre dans une case à part les mails qui reviennent Undelivered (ou équivalent) plusieurs fois, par exemple avec un statut "retour".
Sinon on arrive à une accumulation de retours d'erreurs de plus en plus difficile à gérer.
Merci.
je voudrais savoir s'il y a un moyen, ou si on peut l'implémenter, de
mettre dans une case à part les mails qui reviennent Undelivered (ou
équivalent) plusieurs fois, par exemple avec un statut "retour".
Oui cela existe mais c'est très compliqué donc ça se fait en utilisant
un prestataire d'envoi spécialisé dans les emails en masse (par ailleurs
c'est souvent mieux car ils ont plusieurs serveurs disséminés et ne sont
pas reconnus comme spams etc, c'est leur boulot).
Les emails de retours sont… des emails. Donc pour les capter et les
traiter, cela signifie qu'il faut une boite email où ça arrive, et qu'un
logiciel serveur la liste automatiquement, et fasse des traitements
suivant ce qui est reçu. Un assez gros truc à maintenir donc.
Mais Sparkpost, Mailjet, etc, font cela, et ensuite font des "ping" aux
sites qui les utilisent avec leurs API. Le plugin Mailshot gère ces
retours de ces services, et désabonne alors les mauvaises adresses.
Je ma rappelle vaguement que j'ai vu une explication comment réaliser la
gestion des retours avec mise en attente des destinataires lors d'un
premier problème et désabonnement automatique après le deuxième ou
troisième échec de livraison - à condition de gérer son propre serveur mail.
Malheureusement ja n'ai pas encore eu assez de temps pour aller jusqu'au
bout de la question.
Cédric, une piste?
:-)k++
On 03.06.2018 21:36, RastaPopoulos wrote:
Le 03/06/2018 à 21:09, Perline-Spip a écrit :
je voudrais savoir s'il y a un moyen, ou si on peut l'implémenter, de
mettre dans une case à part les mails qui reviennent Undelivered (ou
équivalent) plusieurs fois, par exemple avec un statut "retour".
Oui cela existe mais c'est très compliqué donc ça se fait en utilisant
un prestataire d'envoi spécialisé dans les emails en masse (par ailleurs
c'est souvent mieux car ils ont plusieurs serveurs disséminés et ne sont
pas reconnus comme spams etc, c'est leur boulot).
Les emails de retours sont… des emails. Donc pour les capter et les
traiter, cela signifie qu'il faut une boite email où ça arrive, et qu'un
logiciel serveur la liste automatiquement, et fasse des traitements
suivant ce qui est reçu. Un assez gros truc à maintenir donc.
Mais Sparkpost, Mailjet, etc, font cela, et ensuite font des "ping" aux
sites qui les utilisent avec leurs API. Le plugin Mailshot gère ces
retours de ces services, et désabonne alors les mauvaises adresses.
Mais c'est externe ? Je ne peux pas décider de ça.
Pierre KUHN a écrit le 03/06/2018 à 21:13 :
Bonsoir,
Si tu envois via l'api mailjet cela je gère il me semble non ?
Bonne soirée.
Le dim. 3 juin 2018 à 21:11, Perline-Spip <spip@perline.org <mailto:spip@perline.org>> a écrit :
Bonjour,
Je gère une liste par le plugin newsletter/mailsubscribers (par obligation, je n'ai pas à disposition un vrai
gestionnaire de listes) et je voudrais savoir s'il y a un moyen, ou si on peut l'implémenter, de mettre dans une case à
part les mails qui reviennent Undelivered (ou équivalent) plusieurs fois, par exemple avec un statut "retour".
Sinon on arrive à une accumulation de retours d'erreurs de plus en plus difficile à gérer.
Merci.
Mais je ne peux rien utiliser d'extérieur, je n'ai aucune main là-dessus.
Si j'avais la main, je ferais comme pour les autres listes que j'utilise (et ce n'est pas compliqué du tout) : avec un gestionnaire de liste (mailman...) c'est une simple option...
RastaPopoulos a écrit le 03/06/2018 à 21:36 :
Le 03/06/2018 à 21:09, Perline-Spip a écrit :
je voudrais savoir s'il y a un moyen, ou si on peut l'implémenter, de
mettre dans une case à part les mails qui reviennent Undelivered (ou
équivalent) plusieurs fois, par exemple avec un statut "retour".
Oui cela existe mais c'est très compliqué donc ça se fait en utilisant
un prestataire d'envoi spécialisé dans les emails en masse (par ailleurs
c'est souvent mieux car ils ont plusieurs serveurs disséminés et ne sont
pas reconnus comme spams etc, c'est leur boulot).
Les emails de retours sont… des emails. Donc pour les capter et les
traiter, cela signifie qu'il faut une boite email où ça arrive, et qu'un
logiciel serveur la liste automatiquement, et fasse des traitements
suivant ce qui est reçu. Un assez gros truc à maintenir donc.
Mais Sparkpost, Mailjet, etc, font cela, et ensuite font des "ping" aux
sites qui les utilisent avec leurs API. Le plugin Mailshot gère ces
retours de ces services, et désabonne alors les mauvaises adresses.
C'est le même problème : je ne peux pas sortir de ce que je gère...
klaus++ a écrit le 04/06/2018 à 10:02 :
Je ma rappelle vaguement que j'ai vu une explication comment réaliser la
gestion des retours avec mise en attente des destinataires lors d'un
premier problème et désabonnement automatique après le deuxième ou
troisième échec de livraison - à condition de gérer son propre serveur mail.
Malheureusement ja n'ai pas encore eu assez de temps pour aller jusqu'au
bout de la question.
Cédric, une piste?
:-)k++
On 03.06.2018 21:36, RastaPopoulos wrote:
Le 03/06/2018 à 21:09, Perline-Spip a écrit :
je voudrais savoir s'il y a un moyen, ou si on peut l'implémenter, de
mettre dans une case à part les mails qui reviennent Undelivered (ou
équivalent) plusieurs fois, par exemple avec un statut "retour".
Oui cela existe mais c'est très compliqué donc ça se fait en utilisant
un prestataire d'envoi spécialisé dans les emails en masse (par ailleurs
c'est souvent mieux car ils ont plusieurs serveurs disséminés et ne sont
pas reconnus comme spams etc, c'est leur boulot).
Les emails de retours sont… des emails. Donc pour les capter et les
traiter, cela signifie qu'il faut une boite email où ça arrive, et qu'un
logiciel serveur la liste automatiquement, et fasse des traitements
suivant ce qui est reçu. Un assez gros truc à maintenir donc.
Mais Sparkpost, Mailjet, etc, font cela, et ensuite font des "ping" aux
sites qui les utilisent avec leurs API. Le plugin Mailshot gère ces
retours de ces services, et désabonne alors les mauvaises adresses.
_______________________________________________
liste spip
spip@rezo.net - désabonnement : envoyer un mail à spip-off@rezo.net
Mais je ne peux rien utiliser d'extérieur, je n'ai aucune main là-dessus.
Si j'avais la main, je ferais comme pour les autres listes que j'utilise
(et ce n'est pas compliqué du tout) : avec un gestionnaire de liste
(mailman...) c'est une simple option...
Comment ça ? Si tu as la main sur SPIP, tu as la main sur la config du
plugin Mailshot qui est le plugin qui gère les envois des Lettres, donc
tu as à la main sur le fait de choisir le serveur d'envoi et donc de
choisir par exemple Sparkpost (qui est gratuit pour un certain nombre
d'envois par mois, assez important quand même).
Sans ça, ya pas moyen de faire ce que tu veux, il faut forcément qu'un
service/logiciel récupère les emails de retour et les traite et en
informe le SPIP.
Non, je ne peux pas décider d'utiliser des éléments externes par lesquels passeraient les adresses mails des abonnés, le CA ne le voudra jamais, et il a raison.
Une autre question.
Quand on programme une newsletter récurrent et qu'on choisit "un seul mail, en test" est-ce que le mail en question a dans son sujet la mention [test] ?
Je ne peux pas le tester en live, désolée.
Merci.
RastaPopoulos a écrit le 04/06/2018 à 10:47 :
Le 04/06/2018 à 10:36, Perline-Spip a écrit :
Mais je ne peux rien utiliser d'extérieur, je n'ai aucune main là-dessus.
Si j'avais la main, je ferais comme pour les autres listes que j'utilise
(et ce n'est pas compliqué du tout) : avec un gestionnaire de liste
(mailman...) c'est une simple option...
Comment ça ? Si tu as la main sur SPIP, tu as la main sur la config du
plugin Mailshot qui est le plugin qui gère les envois des Lettres, donc
tu as à la main sur le fait de choisir le serveur d'envoi et donc de
choisir par exemple Sparkpost (qui est gratuit pour un certain nombre
d'envois par mois, assez important quand même).
Sans ça, ya pas moyen de faire ce que tu veux, il faut forcément qu'un
service/logiciel récupère les emails de retour et les traite et en
informe le SPIP.
Une autre question.
Quand on programme une newsletter récurrent et qu'on choisit "un seul
mail, en test" est-ce que le mail en question a dans son sujet la
mention [test] ?
Je ne peux pas le tester en live, désolée.
Merci.
Non il ne me semble pas, c'est juste que ça l'envoi à une seule personne
Une autre question.
Quand on programme une newsletter récurrent et qu'on choisit "un seul
mail, en test" est-ce que le mail en question a dans son sujet la
mention [test] ?
Je ne peux pas le tester en live, désolée.
Merci.
Non il ne me semble pas, c'est juste que ça l'envoi à une seule personne
Si si tant que la newsletter est pas publiée, c'est un test
et ya [test] dans le titre.
Une fois la newsletter publiée, ya plus de "test" possible.
On peut encore l'envoyer à une seule adresse mais là ya pas [test] dans le titre.
Mais elle est obligatoirement publiée puisque c'est un modèle programmé pour être envoyé tous les jours.
On n'y touche pas.
Donc ça ne devrait pas, normalement.
C'est pour cette raison que je demande si quelqu'un a testé.
Merci.
JLuc a écrit le 04/06/2018 à 11:47 :
Le 04/06/2018 à 11:40, RastaPopoulos a écrit :
Le 04/06/2018 à 11:09, Perline-Spip a écrit :
Une autre question.
Quand on programme une newsletter récurrent et qu'on choisit "un seul
mail, en test" est-ce que le mail en question a dans son sujet la
mention [test] ?
Je ne peux pas le tester en live, désolée.
Merci.
Non il ne me semble pas, c'est juste que ça l'envoi à une seule personne
Si si tant que la newsletter est pas publiée, c'est un test
et ya [test] dans le titre.
Une fois la newsletter publiée, ya plus de "test" possible.
On peut encore l'envoyer à une seule adresse mais là ya pas [test] dans le titre.