problème de livraison d'emails via Free

Le
DEMAINE Benoit-Pierre
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 ?
mon exim contient source, destinataire, IP, date heure et sujet exacte
des messages transmis; puisque la loi les oblige désormais à tout
conserver, ils ont par obligation légale traces de la chose; ma question
est, comment m'adresser à la bonne personne ?

Je ne pouvais pas m'occuper du problème plus tôt: il fallait que
j'attends que le 4e jour après le problème soit passé, et que le
problème soit survenu plusieurs fois.

J'ai fait mon deuil des emails perdus; ce que je veux, c'est comprendre
la cause de la perte, pour déterminer si sa correction est à ma portée,
et le cas échéant, corriger le problème. En résumer: faire mon travail
d'admin sérieux.

Le problème avec Google Apps, c'est que c'est une structure énorme, qui
n'a pas de dimension humaine, donc, je ne sais pas à qui m'adresser pour
résoudre "un problème non décrit dans la FAQ". Ils sont bien mignons
avec leur FAQ, mais, les questions "pas si fréquentes que ça", on les
pose à qui ?

Dans un premier temps, il va falloir tracer le mail, et voire si la
perte peut être due à mon smarthost: smtp.free.fr qui se trouve être
un FAI, donc, je pense que ma question a sa place ici, plus qu'à
beaucoup d'autres endroits.

Cordialement.

--
>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)
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
DEMAINE Benoit-Pierre
Le #6727571
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)

Vince
Le #6727701
DEMAINE Benoit-Pierre a écrit:
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 ?


Pour contacter Free il faut poster sur proxad.free.services.messagerie (en
utilisant news.free.fr comme serveur et en utilisant les identifiants emails
pour s'authentifier).

--
Vince

Eric Giffard
Le #6733091
Bonjour/Bonsoir.
Désolé, je vous coupe !

Moi c'est pareil au boulot :
TOUS les mails de notre domaine (qui existe depuis 10 ans) vers Free sont
rejetés systèmatiquement!
La raison évoquée par Free : notre adresse IP publique a été blacklistée
parce notre serveur envoye des mails vers des adresses inexistantes chez
Free.
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.

Le seul contact que nous avons eu chez Free pour régler ce problème, nous a
demandé d'arrèter les NDR !!! Depuis que nous lui avons demandé de régler
ses propres problèmes : plus de nouvelle!
Le problème vient quand même plus de chez eux que de chez nous, et comme on
ne peut pas filtrer les NDR vers Free, nous sommes coincés.
Dans pas mal de cas, nous n'avons même pas de NDR.

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 ?

Bonne soirée quand même.

La suite au prochain numéro!

A bientôt
Eric Giffard
MCSE Windows XP/2000/2003
MCT Windows 2000/2003/XP/Vista

Enlever le mot "detrop" ! pour une réponse



"DEMAINE Benoit-Pierre" news: 483e0a46$0$23647$
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)



Thierry
Le #6737161
"Eric Giffard" news: g1mrm2$nh2$

Le problème vient quand même plus de chez eux que de chez nous


Ben non : si l'adresse est usurpée pour envoyer des spams ce n'est pas eux
qui envoient ces SPAM donc ils n'ont rien a voir la dedans.
Les NDR sont finalement une plaie autant que les SPAM et il n'y a aucun
interet d'en envoyer pour repondre a des SPAMS et/ou virus !
J'ai une adresse ou je recois plein de NDR sur des virus envoyés avec mon
adresse.
Génial :-(

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 ?


Chic, une MALC. Est-ce que vous donnez a votre facteur tous les prospectus
publicitaires que vous trouvez dans votre boite aux lettre ????

Que devons nous faire avec ces fournisseurs de services qui ne le rende
pas le service ?


Vous remettre en question.

Albert ARIBAUD
Le #6737141
Le Fri, 30 May 2008 10:27:57 +0200, Thierry a écrit :

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 ?

Amicalement,
--
Albert.

Albert ARIBAUD
Le #6737511
Le Fri, 30 May 2008 11:43:11 +0200, Thierry a écrit :

"Albert ARIBAUD" 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.


Ah, effectivement. J'aurais choisi "Analogie", mais c'est question de
goût. :)

Amicalement,
--
Albert.



Francois Petillon
Le #6739131
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.

François

Francois Petillon
Le #6739121
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

Eric Giffard
Le #6742301
"Francois Petillon" 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.

Et au fait, M. Petillon répondez nous en direct plutôt que par forum
interposé. Nous attendons des réponses depuis 3/4 jours.

Nous, nous essayons de trouver des solutions, vous n'avez que des
affirmations!

Vous nous avez jamais rien proposé de concret en tous cas, si ce n'est de ne
pas répondre à clients qui se seraient juste trompé dans l'adresse.

Bon Week end quand même


Albert ARIBAUD
Le #6742291
Le Fri, 30 May 2008 22:35:55 +0200, Eric Giffard a écrit :

"Francois Petillon" 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.


Euh... Tu as bien lu les RFC citées par François ?

Amicalement,
--
Albert.



Publicité
Poster une réponse
Anonyme