o_/ DEMAINE Benoit-Pierre (aka DoubleHP) http://benoit.demaine.info/
If computing were an exact science, IT engineers would not have work _o<
o_/ DEMAINE Benoit-Pierre (aka DoubleHP) http://benoit.demaine.info/
If computing were an exact science, IT engineers would not have work _o<
o_/ DEMAINE Benoit-Pierre (aka DoubleHP) http://benoit.demaine.info/
If computing were an exact science, IT engineers would not have work _o<
Problème: des emails partent, mais n'arrivent pas au destinataire.
Ma station de travail effectue quotidiennement plusieurs taches cron, et
le weekly sont le samedi. Les rapports générés sont envoyés par emails,
vers un exim local, qui les délivre à son smarthost: smtp.free.fr .
C'est le circuit normal de mes emails, y compris ceux de l'utilisateur
de la station de travail.
Le destinataire des emails de cron est mon email, hébergé sur mon
domaine, dont les MX sont actuellement chez Google.Apps.
Trois emails contenant des logs systems ne me sont jamais parvenus au
mois de mai. Je dois recevoir tous les jours un rapport émis à 5h15, et
toutes les semaines un à 7h30 ... plus les délais de livraison. Hors,
entre autre, le rapport de samedi 10 au matin ne m'est jamais parvenu.
Il n'est pas dans ma boite email, ni dans le dossier spam (j'ai vérifié
dix fois).
Après analyse détaillée de mes logs exim, les 3 emails que je n'ai
jamais reçus dans ma boite ont été transmis par exim à free, cela est
certifié.
Je sais que des emails peuvent être perdus; mais, 3 en deux semaines,
c'est énorme, vraiment trop à mon gout.
Comment tracer le problème ? est-ce que ça se fait de contacter le
contacte technique de free.fr pour leur demander de scanner les logs ?
Problème: des emails partent, mais n'arrivent pas au destinataire.
Ma station de travail effectue quotidiennement plusieurs taches cron, et
le weekly sont le samedi. Les rapports générés sont envoyés par emails,
vers un exim local, qui les délivre à son smarthost: smtp.free.fr .
C'est le circuit normal de mes emails, y compris ceux de l'utilisateur
de la station de travail.
Le destinataire des emails de cron est mon email, hébergé sur mon
domaine, dont les MX sont actuellement chez Google.Apps.
Trois emails contenant des logs systems ne me sont jamais parvenus au
mois de mai. Je dois recevoir tous les jours un rapport émis à 5h15, et
toutes les semaines un à 7h30 ... plus les délais de livraison. Hors,
entre autre, le rapport de samedi 10 au matin ne m'est jamais parvenu.
Il n'est pas dans ma boite email, ni dans le dossier spam (j'ai vérifié
dix fois).
Après analyse détaillée de mes logs exim, les 3 emails que je n'ai
jamais reçus dans ma boite ont été transmis par exim à free, cela est
certifié.
Je sais que des emails peuvent être perdus; mais, 3 en deux semaines,
c'est énorme, vraiment trop à mon gout.
Comment tracer le problème ? est-ce que ça se fait de contacter le
contacte technique de free.fr pour leur demander de scanner les logs ?
Problème: des emails partent, mais n'arrivent pas au destinataire.
Ma station de travail effectue quotidiennement plusieurs taches cron, et
le weekly sont le samedi. Les rapports générés sont envoyés par emails,
vers un exim local, qui les délivre à son smarthost: smtp.free.fr .
C'est le circuit normal de mes emails, y compris ceux de l'utilisateur
de la station de travail.
Le destinataire des emails de cron est mon email, hébergé sur mon
domaine, dont les MX sont actuellement chez Google.Apps.
Trois emails contenant des logs systems ne me sont jamais parvenus au
mois de mai. Je dois recevoir tous les jours un rapport émis à 5h15, et
toutes les semaines un à 7h30 ... plus les délais de livraison. Hors,
entre autre, le rapport de samedi 10 au matin ne m'est jamais parvenu.
Il n'est pas dans ma boite email, ni dans le dossier spam (j'ai vérifié
dix fois).
Après analyse détaillée de mes logs exim, les 3 emails que je n'ai
jamais reçus dans ma boite ont été transmis par exim à free, cela est
certifié.
Je sais que des emails peuvent être perdus; mais, 3 en deux semaines,
c'est énorme, vraiment trop à mon gout.
Comment tracer le problème ? est-ce que ça se fait de contacter le
contacte technique de free.fr pour leur demander de scanner les logs ?
J'ai évidement pensé en premier lieu à un problème chez free, mais je me
suis rendu compte il y a 3 jours qu'il y a aussi 3 emails envoyés par
facebook que je n'ai pas reçus. Cela fait donc pencher la balance contre
Google.
Quand la chose sera confirmée par Free, comment contacter Google ?
--o_/ DEMAINE Benoit-Pierre (aka DoubleHP) http://benoit.demaine.info/
If computing were an exact science, IT engineers would not have work _o<
"So all that's left, Is the proof that love's not only blind but deaf."
(FAKE TALES OF SAN FRANCISCO, Arctic Monkeys)
J'ai évidement pensé en premier lieu à un problème chez free, mais je me
suis rendu compte il y a 3 jours qu'il y a aussi 3 emails envoyés par
facebook que je n'ai pas reçus. Cela fait donc pencher la balance contre
Google.
Quand la chose sera confirmée par Free, comment contacter Google ?
--
o_/ DEMAINE Benoit-Pierre (aka DoubleHP) http://benoit.demaine.info/
If computing were an exact science, IT engineers would not have work _o<
"So all that's left, Is the proof that love's not only blind but deaf."
(FAKE TALES OF SAN FRANCISCO, Arctic Monkeys)
J'ai évidement pensé en premier lieu à un problème chez free, mais je me
suis rendu compte il y a 3 jours qu'il y a aussi 3 emails envoyés par
facebook que je n'ai pas reçus. Cela fait donc pencher la balance contre
Google.
Quand la chose sera confirmée par Free, comment contacter Google ?
--o_/ DEMAINE Benoit-Pierre (aka DoubleHP) http://benoit.demaine.info/
If computing were an exact science, IT engineers would not have work _o<
"So all that's left, Is the proof that love's not only blind but deaf."
(FAKE TALES OF SAN FRANCISCO, Arctic Monkeys)
Le problème vient quand même plus de chez eux que de chez nous
Mais autre remarque, Free n'est pas le seul, un client (société sérieuse
et sans problème) ne peut pas envoyer de message vers Neuf ou Cegetel pour
les mêmes raisons, et personnellement, je ne peux répondre à une adresse
Yahoo. Donc je suppose qu'ils ont tous leur propre BL et décident eux même
de qui ils vont y mettre.
Que devons nous faire avec un facteur qui refuse de distribuer (ou jette
carrément) le courrier ?
Que devons nous faire avec ces fournisseurs de services qui ne le rende
pas le service ?
Le problème vient quand même plus de chez eux que de chez nous
Mais autre remarque, Free n'est pas le seul, un client (société sérieuse
et sans problème) ne peut pas envoyer de message vers Neuf ou Cegetel pour
les mêmes raisons, et personnellement, je ne peux répondre à une adresse
Yahoo. Donc je suppose qu'ils ont tous leur propre BL et décident eux même
de qui ils vont y mettre.
Que devons nous faire avec un facteur qui refuse de distribuer (ou jette
carrément) le courrier ?
Que devons nous faire avec ces fournisseurs de services qui ne le rende
pas le service ?
Le problème vient quand même plus de chez eux que de chez nous
Mais autre remarque, Free n'est pas le seul, un client (société sérieuse
et sans problème) ne peut pas envoyer de message vers Neuf ou Cegetel pour
les mêmes raisons, et personnellement, je ne peux répondre à une adresse
Yahoo. Donc je suppose qu'ils ont tous leur propre BL et décident eux même
de qui ils vont y mettre.
Que devons nous faire avec un facteur qui refuse de distribuer (ou jette
carrément) le courrier ?
Que devons nous faire avec ces fournisseurs de services qui ne le rende
pas le service ?
Chic, une MALC.
Chic, une MALC.
Chic, une MALC.
"Albert ARIBAUD" a écrit dans le message de
news: 483fc669$0$30958$Chic, une MALC.
J'ai les trois dernières lettres mais pour la première, je sèche
(j'aurais plutôt vu un "A" qu'un "M"). C'est quoi ?
Métaphore.
"Albert ARIBAUD" <albert.aribaud@free.fr> a écrit dans le message de
news: 483fc669$0$30958$426a34cc@news.free.fr...
Chic, une MALC.
J'ai les trois dernières lettres mais pour la première, je sèche
(j'aurais plutôt vu un "A" qu'un "M"). C'est quoi ?
Métaphore.
"Albert ARIBAUD" a écrit dans le message de
news: 483fc669$0$30958$Chic, une MALC.
J'ai les trois dernières lettres mais pour la première, je sèche
(j'aurais plutôt vu un "A" qu'un "M"). C'est quoi ?
Métaphore.
La raison réelle :
Notre serveur reçoit des spams (d'adresses usurpées chez Free) vers des
adresses inexistantes chez nous (des dizaines par jour), ça passe donc dans
le "Badmail" et le serveur renvoie une notification de non remise vers des
adresses inexistantes chez Free. Normal parce qu'elles sont utilisées par
des spammeurs.
La raison réelle :
Notre serveur reçoit des spams (d'adresses usurpées chez Free) vers des
adresses inexistantes chez nous (des dizaines par jour), ça passe donc dans
le "Badmail" et le serveur renvoie une notification de non remise vers des
adresses inexistantes chez Free. Normal parce qu'elles sont utilisées par
des spammeurs.
La raison réelle :
Notre serveur reçoit des spams (d'adresses usurpées chez Free) vers des
adresses inexistantes chez nous (des dizaines par jour), ça passe donc dans
le "Badmail" et le serveur renvoie une notification de non remise vers des
adresses inexistantes chez Free. Normal parce qu'elles sont utilisées par
des spammeurs.
La raison réelle :
Notre serveur reçoit des spams (d'adresses usurpées chez Free) vers des
adresses inexistantes chez nous (des dizaines par jour), ça passe donc dans
le "Badmail" et le serveur renvoie une notification de non remise vers des
adresses inexistantes chez Free. Normal parce qu'elles sont utilisées par
des spammeurs.
La raison réelle :
Notre serveur reçoit des spams (d'adresses usurpées chez Free) vers des
adresses inexistantes chez nous (des dizaines par jour), ça passe donc dans
le "Badmail" et le serveur renvoie une notification de non remise vers des
adresses inexistantes chez Free. Normal parce qu'elles sont utilisées par
des spammeurs.
La raison réelle :
Notre serveur reçoit des spams (d'adresses usurpées chez Free) vers des
adresses inexistantes chez nous (des dizaines par jour), ça passe donc dans
le "Badmail" et le serveur renvoie une notification de non remise vers des
adresses inexistantes chez Free. Normal parce qu'elles sont utilisées par
des spammeurs.
On Thu, 29 May 2008 20:14:37 +0200, Eric Giffard wrote:La raison réelle :
Notre serveur reçoit des spams (d'adresses usurpées chez Free) vers des
adresses inexistantes chez nous (des dizaines par jour), ça passe donc
dans
le "Badmail" et le serveur renvoie une notification de non remise vers
des
adresses inexistantes chez Free. Normal parce qu'elles sont utilisées par
des spammeurs.
** RFC 2505 **
----
1.5. Where to block spam, in SMTP, in RFC822 or in the UA Our basic
assumption is that refuse/accept is handled at the SMTP layer and that an
MTA that decides to refuse a message should do so while still in the SMTP
dialogue. First, this means that we do not have to store a copy of a
message we later decide to refuse and second, our responsibility for that
message is low or none - since we have not yet read it in, we leave it to
the sender to handle the error.
----
** RFC 3834 **
----
2. When (not) to send automatic responses An automatic responder MUST NOT
blindly send a response for every message received. In practice there are
always reasons to refuse to respond to some kinds of received messages,
e.g., for loop prevention, to avoid responding to "spam" or viruses, to
avoid being used as a means to launder or amplify abusive messages, to
avoid inappropriately revealing personal information about the recipient
(e.g., to avoid an automatic indication that a recipient has not read his
mail recently), and to thwart denial-of-service attacks against the
responder. The criteria for deciding whether to respond will differ from
one responder to another, according to the responder's purpose. In
general, care should be taken to avoid sending useless or redundant
responses, and to avoid contributing to mail loops or facilitating
denial-of-service attacks.
----
Actuellement, en envoyant des notifications automatiques sur les spams que
vous recevez, vous envoyez des mails à des personnes qui ne sont en rien
responsable de l'envoi du spam et votre notification est de fait non
sollicité et est assimilable à du spam. Vous pourrez demander aux
utilisateurs Free qui se prennent quotidiennement des centaines de bounces
de ce qu'ils pensent de ce type de notification.
Accessoirement, vous participez à l'équivalent d'un DoS sur les domaines
free.fr/online.fr qui sont utilisés intensivement comme domaines
emetteur par certains spammeurs depuis la mi-avril.
François
On Thu, 29 May 2008 20:14:37 +0200, Eric Giffard wrote:
La raison réelle :
Notre serveur reçoit des spams (d'adresses usurpées chez Free) vers des
adresses inexistantes chez nous (des dizaines par jour), ça passe donc
dans
le "Badmail" et le serveur renvoie une notification de non remise vers
des
adresses inexistantes chez Free. Normal parce qu'elles sont utilisées par
des spammeurs.
** RFC 2505 **
----
1.5. Where to block spam, in SMTP, in RFC822 or in the UA Our basic
assumption is that refuse/accept is handled at the SMTP layer and that an
MTA that decides to refuse a message should do so while still in the SMTP
dialogue. First, this means that we do not have to store a copy of a
message we later decide to refuse and second, our responsibility for that
message is low or none - since we have not yet read it in, we leave it to
the sender to handle the error.
----
** RFC 3834 **
----
2. When (not) to send automatic responses An automatic responder MUST NOT
blindly send a response for every message received. In practice there are
always reasons to refuse to respond to some kinds of received messages,
e.g., for loop prevention, to avoid responding to "spam" or viruses, to
avoid being used as a means to launder or amplify abusive messages, to
avoid inappropriately revealing personal information about the recipient
(e.g., to avoid an automatic indication that a recipient has not read his
mail recently), and to thwart denial-of-service attacks against the
responder. The criteria for deciding whether to respond will differ from
one responder to another, according to the responder's purpose. In
general, care should be taken to avoid sending useless or redundant
responses, and to avoid contributing to mail loops or facilitating
denial-of-service attacks.
----
Actuellement, en envoyant des notifications automatiques sur les spams que
vous recevez, vous envoyez des mails à des personnes qui ne sont en rien
responsable de l'envoi du spam et votre notification est de fait non
sollicité et est assimilable à du spam. Vous pourrez demander aux
utilisateurs Free qui se prennent quotidiennement des centaines de bounces
de ce qu'ils pensent de ce type de notification.
Accessoirement, vous participez à l'équivalent d'un DoS sur les domaines
free.fr/online.fr qui sont utilisés intensivement comme domaines
emetteur par certains spammeurs depuis la mi-avril.
François
On Thu, 29 May 2008 20:14:37 +0200, Eric Giffard wrote:La raison réelle :
Notre serveur reçoit des spams (d'adresses usurpées chez Free) vers des
adresses inexistantes chez nous (des dizaines par jour), ça passe donc
dans
le "Badmail" et le serveur renvoie une notification de non remise vers
des
adresses inexistantes chez Free. Normal parce qu'elles sont utilisées par
des spammeurs.
** RFC 2505 **
----
1.5. Where to block spam, in SMTP, in RFC822 or in the UA Our basic
assumption is that refuse/accept is handled at the SMTP layer and that an
MTA that decides to refuse a message should do so while still in the SMTP
dialogue. First, this means that we do not have to store a copy of a
message we later decide to refuse and second, our responsibility for that
message is low or none - since we have not yet read it in, we leave it to
the sender to handle the error.
----
** RFC 3834 **
----
2. When (not) to send automatic responses An automatic responder MUST NOT
blindly send a response for every message received. In practice there are
always reasons to refuse to respond to some kinds of received messages,
e.g., for loop prevention, to avoid responding to "spam" or viruses, to
avoid being used as a means to launder or amplify abusive messages, to
avoid inappropriately revealing personal information about the recipient
(e.g., to avoid an automatic indication that a recipient has not read his
mail recently), and to thwart denial-of-service attacks against the
responder. The criteria for deciding whether to respond will differ from
one responder to another, according to the responder's purpose. In
general, care should be taken to avoid sending useless or redundant
responses, and to avoid contributing to mail loops or facilitating
denial-of-service attacks.
----
Actuellement, en envoyant des notifications automatiques sur les spams que
vous recevez, vous envoyez des mails à des personnes qui ne sont en rien
responsable de l'envoi du spam et votre notification est de fait non
sollicité et est assimilable à du spam. Vous pourrez demander aux
utilisateurs Free qui se prennent quotidiennement des centaines de bounces
de ce qu'ils pensent de ce type de notification.
Accessoirement, vous participez à l'équivalent d'un DoS sur les domaines
free.fr/online.fr qui sont utilisés intensivement comme domaines
emetteur par certains spammeurs depuis la mi-avril.
François
"Francois Petillon" a écrit dans le
message de news:On Thu, 29 May 2008 20:14:37 +0200, Eric Giffard wrote:La raison réelle :
Notre serveur reçoit des spams (d'adresses usurpées chez Free) vers
des adresses inexistantes chez nous (des dizaines par jour), ça passe
donc dans
le "Badmail" et le serveur renvoie une notification de non remise vers
des
adresses inexistantes chez Free. Normal parce qu'elles sont utilisées
par des spammeurs.
** RFC 2505 **
----
1.5. Where to block spam, in SMTP, in RFC822 or in the UA Our basic
assumption is that refuse/accept is handled at the SMTP layer and that
an MTA that decides to refuse a message should do so while still in the
SMTP dialogue. First, this means that we do not have to store a copy of
a message we later decide to refuse and second, our responsibility for
that message is low or none - since we have not yet read it in, we
leave it to the sender to handle the error.
----
** RFC 3834 **
----
2. When (not) to send automatic responses An automatic responder MUST
NOT blindly send a response for every message received. In practice
there are always reasons to refuse to respond to some kinds of received
messages, e.g., for loop prevention, to avoid responding to "spam" or
viruses, to avoid being used as a means to launder or amplify abusive
messages, to avoid inappropriately revealing personal information about
the recipient (e.g., to avoid an automatic indication that a recipient
has not read his mail recently), and to thwart denial-of-service
attacks against the responder. The criteria for deciding whether to
respond will differ from one responder to another, according to the
responder's purpose. In general, care should be taken to avoid sending
useless or redundant responses, and to avoid contributing to mail loops
or facilitating denial-of-service attacks.
----
Actuellement, en envoyant des notifications automatiques sur les spams
que vous recevez, vous envoyez des mails à des personnes qui ne sont en
rien responsable de l'envoi du spam et votre notification est de fait
non sollicité et est assimilable à du spam. Vous pourrez demander aux
utilisateurs Free qui se prennent quotidiennement des centaines de
bounces de ce qu'ils pensent de ce type de notification.
Accessoirement, vous participez à l'équivalent d'un DoS sur les
domaines free.fr/online.fr qui sont utilisés intensivement comme
domaines emetteur par certains spammeurs depuis la mi-avril.
François
Réponse sans intérêt, vu que ce sont des fausses adresses Free qui nous
spamment,
... pas le contraire.
A vous donc, de gérer ces usurpateurs, pas à nous.
"Francois Petillon" <fanch@fanfan.staff.proxad.net> a écrit dans le
message de news:
pan.2008.05.30.14.21.24.809205@fanfan.staff.proxad.net...
On Thu, 29 May 2008 20:14:37 +0200, Eric Giffard wrote:
La raison réelle :
Notre serveur reçoit des spams (d'adresses usurpées chez Free) vers
des adresses inexistantes chez nous (des dizaines par jour), ça passe
donc dans
le "Badmail" et le serveur renvoie une notification de non remise vers
des
adresses inexistantes chez Free. Normal parce qu'elles sont utilisées
par des spammeurs.
** RFC 2505 **
----
1.5. Where to block spam, in SMTP, in RFC822 or in the UA Our basic
assumption is that refuse/accept is handled at the SMTP layer and that
an MTA that decides to refuse a message should do so while still in the
SMTP dialogue. First, this means that we do not have to store a copy of
a message we later decide to refuse and second, our responsibility for
that message is low or none - since we have not yet read it in, we
leave it to the sender to handle the error.
----
** RFC 3834 **
----
2. When (not) to send automatic responses An automatic responder MUST
NOT blindly send a response for every message received. In practice
there are always reasons to refuse to respond to some kinds of received
messages, e.g., for loop prevention, to avoid responding to "spam" or
viruses, to avoid being used as a means to launder or amplify abusive
messages, to avoid inappropriately revealing personal information about
the recipient (e.g., to avoid an automatic indication that a recipient
has not read his mail recently), and to thwart denial-of-service
attacks against the responder. The criteria for deciding whether to
respond will differ from one responder to another, according to the
responder's purpose. In general, care should be taken to avoid sending
useless or redundant responses, and to avoid contributing to mail loops
or facilitating denial-of-service attacks.
----
Actuellement, en envoyant des notifications automatiques sur les spams
que vous recevez, vous envoyez des mails à des personnes qui ne sont en
rien responsable de l'envoi du spam et votre notification est de fait
non sollicité et est assimilable à du spam. Vous pourrez demander aux
utilisateurs Free qui se prennent quotidiennement des centaines de
bounces de ce qu'ils pensent de ce type de notification.
Accessoirement, vous participez à l'équivalent d'un DoS sur les
domaines free.fr/online.fr qui sont utilisés intensivement comme
domaines emetteur par certains spammeurs depuis la mi-avril.
François
Réponse sans intérêt, vu que ce sont des fausses adresses Free qui nous
spamment,
... pas le contraire.
A vous donc, de gérer ces usurpateurs, pas à nous.
"Francois Petillon" a écrit dans le
message de news:On Thu, 29 May 2008 20:14:37 +0200, Eric Giffard wrote:La raison réelle :
Notre serveur reçoit des spams (d'adresses usurpées chez Free) vers
des adresses inexistantes chez nous (des dizaines par jour), ça passe
donc dans
le "Badmail" et le serveur renvoie une notification de non remise vers
des
adresses inexistantes chez Free. Normal parce qu'elles sont utilisées
par des spammeurs.
** RFC 2505 **
----
1.5. Where to block spam, in SMTP, in RFC822 or in the UA Our basic
assumption is that refuse/accept is handled at the SMTP layer and that
an MTA that decides to refuse a message should do so while still in the
SMTP dialogue. First, this means that we do not have to store a copy of
a message we later decide to refuse and second, our responsibility for
that message is low or none - since we have not yet read it in, we
leave it to the sender to handle the error.
----
** RFC 3834 **
----
2. When (not) to send automatic responses An automatic responder MUST
NOT blindly send a response for every message received. In practice
there are always reasons to refuse to respond to some kinds of received
messages, e.g., for loop prevention, to avoid responding to "spam" or
viruses, to avoid being used as a means to launder or amplify abusive
messages, to avoid inappropriately revealing personal information about
the recipient (e.g., to avoid an automatic indication that a recipient
has not read his mail recently), and to thwart denial-of-service
attacks against the responder. The criteria for deciding whether to
respond will differ from one responder to another, according to the
responder's purpose. In general, care should be taken to avoid sending
useless or redundant responses, and to avoid contributing to mail loops
or facilitating denial-of-service attacks.
----
Actuellement, en envoyant des notifications automatiques sur les spams
que vous recevez, vous envoyez des mails à des personnes qui ne sont en
rien responsable de l'envoi du spam et votre notification est de fait
non sollicité et est assimilable à du spam. Vous pourrez demander aux
utilisateurs Free qui se prennent quotidiennement des centaines de
bounces de ce qu'ils pensent de ce type de notification.
Accessoirement, vous participez à l'équivalent d'un DoS sur les
domaines free.fr/online.fr qui sont utilisés intensivement comme
domaines emetteur par certains spammeurs depuis la mi-avril.
François
Réponse sans intérêt, vu que ce sont des fausses adresses Free qui nous
spamment,
... pas le contraire.
A vous donc, de gérer ces usurpateurs, pas à nous.