Quelles solutions gratuites ou solution open source utilisez vous ou connaissez vous pour gerer les envois de mails ( non spam ) et leur suivi ?
Les logs du serveur de mail. -- ASPO Infogérance - http://aspo.rktmb.org/activites/infogerance Unofficial FAQ fcolc - http://faq.fcolc.eu.org/ Linux User Group sur Orléans et alentours. Tél: + 33 2 38 76 43 65 (France)
( Wed, 29 Dec 2004 00:39:37 +0100 ) Imochon :
Bonjour,
Bonjour
Quelles solutions gratuites ou solution open source utilisez vous ou
connaissez vous pour gerer les envois de mails ( non spam ) et leur suivi ?
Les logs du serveur de mail.
--
ASPO Infogérance - http://aspo.rktmb.org/activites/infogerance
Unofficial FAQ fcolc - http://faq.fcolc.eu.org/
Linux User Group sur Orléans et alentours.
Tél: + 33 2 38 76 43 65 (France)
Quelles solutions gratuites ou solution open source utilisez vous ou connaissez vous pour gerer les envois de mails ( non spam ) et leur suivi ?
Les logs du serveur de mail. -- ASPO Infogérance - http://aspo.rktmb.org/activites/infogerance Unofficial FAQ fcolc - http://faq.fcolc.eu.org/ Linux User Group sur Orléans et alentours. Tél: + 33 2 38 76 43 65 (France)
Dominique Blas
Rakotomandimby (R12y) Mihamina wrote:
( Wed, 29 Dec 2004 00:39:37 +0100 ) Imochon :
Bonjour,
Bonjour
Quelles solutions gratuites ou solution open source utilisez vous ou connaissez vous pour gerer les envois de mails ( non spam ) et leur suivi ?
Les logs du serveur de mail. Tout à fait et << un-script-qui-va-bien >> pour les envois (*).
Il n'y a rien de mieux combinant à la fois : la souplesse (texte, HTML, pièces-jointes, annuaire), la gratuité, et le volume (des millions peuvent partir ainsi).
db
(*) Voire un script qui analyse la log du serveur afin de compiler les erreurs en retour (adresse inexistante, domaine ou serveur inexistant).
-- email : usenet blas net
Rakotomandimby (R12y) Mihamina wrote:
( Wed, 29 Dec 2004 00:39:37 +0100 ) Imochon :
Bonjour,
Bonjour
Quelles solutions gratuites ou solution open source utilisez vous ou
connaissez vous pour gerer les envois de mails ( non spam ) et leur suivi
?
Les logs du serveur de mail.
Tout à fait et << un-script-qui-va-bien >> pour les envois (*).
Il n'y a rien de mieux combinant à la fois :
la souplesse (texte, HTML, pièces-jointes, annuaire),
la gratuité,
et le volume (des millions peuvent partir ainsi).
db
(*) Voire un script qui analyse la log du serveur afin de compiler les
erreurs en retour (adresse inexistante, domaine ou serveur inexistant).
Quelles solutions gratuites ou solution open source utilisez vous ou connaissez vous pour gerer les envois de mails ( non spam ) et leur suivi ?
Les logs du serveur de mail. Tout à fait et << un-script-qui-va-bien >> pour les envois (*).
Il n'y a rien de mieux combinant à la fois : la souplesse (texte, HTML, pièces-jointes, annuaire), la gratuité, et le volume (des millions peuvent partir ainsi).
db
(*) Voire un script qui analyse la log du serveur afin de compiler les erreurs en retour (adresse inexistante, domaine ou serveur inexistant).
-- email : usenet blas net
Fabien LE LEZ
On Wed, 29 Dec 2004 16:23:03 +0100, "Rakotomandimby (R12y) Mihamina" :
Les logs du serveur de mail.
Pas suffisant. Pas mal de serveurs SMTP acceptent l'email, puis renvoient un message à l'expéditeur quand ils s'aperçoivent qu'ils n'arrivent pas à amener l'email à son destinataire.
-- ;-)
On Wed, 29 Dec 2004 16:23:03 +0100, "Rakotomandimby (R12y) Mihamina"
<mihamina@mail.rktmb.org>:
Les logs du serveur de mail.
Pas suffisant. Pas mal de serveurs SMTP acceptent l'email, puis
renvoient un message à l'expéditeur quand ils s'aperçoivent qu'ils
n'arrivent pas à amener l'email à son destinataire.
On Wed, 29 Dec 2004 16:23:03 +0100, "Rakotomandimby (R12y) Mihamina" :
Les logs du serveur de mail.
Pas suffisant. Pas mal de serveurs SMTP acceptent l'email, puis renvoient un message à l'expéditeur quand ils s'aperçoivent qu'ils n'arrivent pas à amener l'email à son destinataire.
-- ;-)
Dominique Blas
Fabien LE LEZ wrote:
On Wed, 29 Dec 2004 16:23:03 +0100, "Rakotomandimby (R12y) Mihamina" :
Les logs du serveur de mail.
Pas suffisant. Pas mal de serveurs SMTP acceptent l'email, puis renvoient un message à l'expéditeur quand ils s'aperçoivent qu'ils n'arrivent pas à amener l'email à son destinataire.
Et donc ? l'expéditeur a bien une BAL non ?
Ce n'est pas compliqué de parcourir les réponses en erreur afin d'identifier les adresses les ayant provoquées.
Cette analyse des réponses peut bien entendu être automatisé via un script qui interprète la réponse retournée à l'expéditeur. L'avantage du script c'est qu'il fournit un tableau bien propre et dans un seul courriel des adresses en erreur.
db -- email : usenet blas net
Fabien LE LEZ wrote:
On Wed, 29 Dec 2004 16:23:03 +0100, "Rakotomandimby (R12y) Mihamina"
<mihamina@mail.rktmb.org>:
Les logs du serveur de mail.
Pas suffisant. Pas mal de serveurs SMTP acceptent l'email, puis
renvoient un message à l'expéditeur quand ils s'aperçoivent qu'ils
n'arrivent pas à amener l'email à son destinataire.
Et donc ? l'expéditeur a bien une BAL non ?
Ce n'est pas compliqué de parcourir les réponses en erreur afin
d'identifier les adresses les ayant provoquées.
Cette analyse des réponses peut bien entendu être automatisé via un script
qui interprète la réponse retournée à l'expéditeur.
L'avantage du script c'est qu'il fournit un tableau bien propre et dans un
seul courriel des adresses en erreur.
On Wed, 29 Dec 2004 16:23:03 +0100, "Rakotomandimby (R12y) Mihamina" :
Les logs du serveur de mail.
Pas suffisant. Pas mal de serveurs SMTP acceptent l'email, puis renvoient un message à l'expéditeur quand ils s'aperçoivent qu'ils n'arrivent pas à amener l'email à son destinataire.
Et donc ? l'expéditeur a bien une BAL non ?
Ce n'est pas compliqué de parcourir les réponses en erreur afin d'identifier les adresses les ayant provoquées.
Cette analyse des réponses peut bien entendu être automatisé via un script qui interprète la réponse retournée à l'expéditeur. L'avantage du script c'est qu'il fournit un tableau bien propre et dans un seul courriel des adresses en erreur.
db -- email : usenet blas net
Fabien LE LEZ
On Wed, 29 Dec 2004 20:26:28 +0100, Dominique Blas :
Ce n'est pas compliqué de parcourir les réponses en erreur afin d'identifier les adresses les ayant provoquées.
Si. Il s'y mélangent des accusés de réception, des messages d'avertissement et des erreurs. Et y'a pas deux logiciels serveurs qui ont les mêmes messages. Du coup, une analyse totalement automatique des messages reçus est quasi-impossible.
-- ;-)
On Wed, 29 Dec 2004 20:26:28 +0100, Dominique Blas <nospam@spam.int>:
Ce n'est pas compliqué de parcourir les réponses en erreur afin
d'identifier les adresses les ayant provoquées.
Si. Il s'y mélangent des accusés de réception, des messages
d'avertissement et des erreurs. Et y'a pas deux logiciels serveurs qui
ont les mêmes messages. Du coup, une analyse totalement automatique
des messages reçus est quasi-impossible.
On Wed, 29 Dec 2004 20:26:28 +0100, Dominique Blas :
Ce n'est pas compliqué de parcourir les réponses en erreur afin d'identifier les adresses les ayant provoquées.
Si. Il s'y mélangent des accusés de réception, des messages d'avertissement et des erreurs. Et y'a pas deux logiciels serveurs qui ont les mêmes messages. Du coup, une analyse totalement automatique des messages reçus est quasi-impossible.
-- ;-)
Dominique Blas
Fabien LE LEZ wrote:
On Wed, 29 Dec 2004 20:26:28 +0100, Dominique Blas :
Ce n'est pas compliqué de parcourir les réponses en erreur afin d'identifier les adresses les ayant provoquées.
Si. Il s'y mélangent des accusés de réception, des messages d'avertissement et des erreurs. Et y'a pas deux logiciels serveurs qui ont les mêmes messages. Du coup, une analyse totalement automatique des messages reçus est quasi-impossible. Non, la ligne d'info est pratiquement toujours située au même endroit et,
surtout, les codes d'erreurs sont réglementés. Maintenant si le MTA en face ne suit pas les RFC inutile d'en parler.
d
-- email : usenet blas net
Fabien LE LEZ wrote:
On Wed, 29 Dec 2004 20:26:28 +0100, Dominique Blas <nospam@spam.int>:
Ce n'est pas compliqué de parcourir les réponses en erreur afin
d'identifier les adresses les ayant provoquées.
Si. Il s'y mélangent des accusés de réception, des messages
d'avertissement et des erreurs. Et y'a pas deux logiciels serveurs qui
ont les mêmes messages. Du coup, une analyse totalement automatique
des messages reçus est quasi-impossible.
Non, la ligne d'info est pratiquement toujours située au même endroit et,
surtout, les codes d'erreurs sont réglementés.
Maintenant si le MTA en face ne suit pas les RFC inutile d'en parler.
On Wed, 29 Dec 2004 20:26:28 +0100, Dominique Blas :
Ce n'est pas compliqué de parcourir les réponses en erreur afin d'identifier les adresses les ayant provoquées.
Si. Il s'y mélangent des accusés de réception, des messages d'avertissement et des erreurs. Et y'a pas deux logiciels serveurs qui ont les mêmes messages. Du coup, une analyse totalement automatique des messages reçus est quasi-impossible. Non, la ligne d'info est pratiquement toujours située au même endroit et,
surtout, les codes d'erreurs sont réglementés. Maintenant si le MTA en face ne suit pas les RFC inutile d'en parler.
d
-- email : usenet blas net
Fabien LE LEZ
On Thu, 30 Dec 2004 17:56:06 +0100, "Rakotomandimby (R12y) Mihamina" :
Imochon n'a pas accroché a notre theorie on dirait :-).
Il n'a accroché à rien du tout, même pas au thread.
-- ;-)
On Thu, 30 Dec 2004 17:56:06 +0100, "Rakotomandimby (R12y) Mihamina"
<mihamina@mail.rktmb.org>:
Imochon n'a pas accroché a notre theorie on
dirait :-).
Il n'a accroché à rien du tout, même pas au thread.
