bonsoir tous
certains mails partent sans pbs,
mais prennent des heures pour atteindre le destinataire;
peut-on essayer de cerner d'ou vient le pb ?
existe t'il des outils de trace ?
merci d'avance
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Stephane Dupille
bonsoir tous
Hello,
certains mails partent sans pbs, mais prennent des heures pour atteindre le destinataire; peut-on essayer de cerner d'ou vient le pb ?
Ce n'est pas forcément un problème. Le mail est un outil de communication asynchrone. Il n'y a jamais eu de garantie de livraison du courier en un temps donné. Si vous voulez communiquer avec quelqu'un, en ayant la certitude que le message arrive en un temps donné, il faut utiliser un autre outil (comme le téléphone par exemple). Le mail n'est pas une message instantanée.
Et ce n'est pas parce que la plupart des mails arrivent en quelque secondes que cela est la règle, et que cela doit toujours être comme ça.
Sinon, la latence peut s'expliquer de plusieurs manières : site qui fetch les mails sur un serveur au lieu de les recevoir directement (par exemple un spool UUCP rmail), ou un serveur qui a mis en place une greylist. Ou encore un serveur raz la gueule qui n'arrive plus à suivre ce qu'il se passe, ou tout bêtement en panne. Ou même encore une simple QoS où l'admin a décidé que le mail n'est pas prioritaire et la transmission est bloquée par un autre transfert plus urgent.
Bref, il y a des milliers de raisons qui font qu'un mail peut mettre du temps pour arriver.
existe t'il des outils de trace ?
Pas vraiment dans le sens où vous l'entendez.
merci d'avance
Ah mais de rien.
bonsoir tous
Hello,
certains mails partent sans pbs,
mais prennent des heures pour atteindre le destinataire;
peut-on essayer de cerner d'ou vient le pb ?
Ce n'est pas forcément un problème. Le mail est un outil de
communication asynchrone. Il n'y a jamais eu de garantie de livraison
du courier en un temps donné. Si vous voulez communiquer avec
quelqu'un, en ayant la certitude que le message arrive en un temps
donné, il faut utiliser un autre outil (comme le téléphone par
exemple). Le mail n'est pas une message instantanée.
Et ce n'est pas parce que la plupart des mails arrivent en quelque
secondes que cela est la règle, et que cela doit toujours être comme
ça.
Sinon, la latence peut s'expliquer de plusieurs manières : site qui
fetch les mails sur un serveur au lieu de les recevoir directement
(par exemple un spool UUCP rmail), ou un serveur qui a mis en place
une greylist. Ou encore un serveur raz la gueule qui n'arrive plus à
suivre ce qu'il se passe, ou tout bêtement en panne. Ou même encore
une simple QoS où l'admin a décidé que le mail n'est pas prioritaire
et la transmission est bloquée par un autre transfert plus urgent.
Bref, il y a des milliers de raisons qui font qu'un mail peut mettre
du temps pour arriver.
certains mails partent sans pbs, mais prennent des heures pour atteindre le destinataire; peut-on essayer de cerner d'ou vient le pb ?
Ce n'est pas forcément un problème. Le mail est un outil de communication asynchrone. Il n'y a jamais eu de garantie de livraison du courier en un temps donné. Si vous voulez communiquer avec quelqu'un, en ayant la certitude que le message arrive en un temps donné, il faut utiliser un autre outil (comme le téléphone par exemple). Le mail n'est pas une message instantanée.
Et ce n'est pas parce que la plupart des mails arrivent en quelque secondes que cela est la règle, et que cela doit toujours être comme ça.
Sinon, la latence peut s'expliquer de plusieurs manières : site qui fetch les mails sur un serveur au lieu de les recevoir directement (par exemple un spool UUCP rmail), ou un serveur qui a mis en place une greylist. Ou encore un serveur raz la gueule qui n'arrive plus à suivre ce qu'il se passe, ou tout bêtement en panne. Ou même encore une simple QoS où l'admin a décidé que le mail n'est pas prioritaire et la transmission est bloquée par un autre transfert plus urgent.
Bref, il y a des milliers de raisons qui font qu'un mail peut mettre du temps pour arriver.
existe t'il des outils de trace ?
Pas vraiment dans le sens où vous l'entendez.
merci d'avance
Ah mais de rien.
Patrick Texier
Le Tue, 30 Jan 2007 23:18:49 +0100, bpdu92 a écrit :
mais prennent des heures pour atteindre le destinataire; peut-on essayer de cerner d'ou vient le pb ? existe t'il des outils de trace ?
Il faut analyser les champs Received: dans les entêtes de bas en haut : chaque serveur ajoute sa trace au dessus des précédentes.
Voici un exemple qui est resté coincé 12 heures en interne sur une liste Yahoo!
|Received: from [snip] by t6.bullet.scd.yahoo.com with NNFMP; 27 Jan 2007 00:25:20 -0000 |Received: from [snip] by m30.grp.scd.yahoo.com with QMQP; 26 Jan 2007 12:34:14 -0000
Attention aux fuseaux horaires qui peuvent être différents (ici GMT : -0000).
Le Tue, 30 Jan 2007 23:18:49 +0100, bpdu92 a écrit :
mais prennent des heures pour atteindre le destinataire;
peut-on essayer de cerner d'ou vient le pb ?
existe t'il des outils de trace ?
Il faut analyser les champs Received: dans les entêtes de bas en haut :
chaque serveur ajoute sa trace au dessus des précédentes.
Voici un exemple qui est resté coincé 12 heures en interne sur une liste
Yahoo!
|Received: from [snip] by t6.bullet.scd.yahoo.com with NNFMP; 27 Jan 2007 00:25:20 -0000
|Received: from [snip] by m30.grp.scd.yahoo.com with QMQP; 26 Jan 2007 12:34:14 -0000
Attention aux fuseaux horaires qui peuvent être différents (ici
GMT : -0000).
Le Tue, 30 Jan 2007 23:18:49 +0100, bpdu92 a écrit :
mais prennent des heures pour atteindre le destinataire; peut-on essayer de cerner d'ou vient le pb ? existe t'il des outils de trace ?
Il faut analyser les champs Received: dans les entêtes de bas en haut : chaque serveur ajoute sa trace au dessus des précédentes.
Voici un exemple qui est resté coincé 12 heures en interne sur une liste Yahoo!
|Received: from [snip] by t6.bullet.scd.yahoo.com with NNFMP; 27 Jan 2007 00:25:20 -0000 |Received: from [snip] by m30.grp.scd.yahoo.com with QMQP; 26 Jan 2007 12:34:14 -0000
Attention aux fuseaux horaires qui peuvent être différents (ici GMT : -0000).
ES
un truc bete ... pour l analyser l entete faudrait encore que le dit eMail soit recu :-)
effectivement l envoi d email n est pas une certitude en reception de fait de nombreux parametres independants de l expediteur comme du destinataire( anti spam/Virus/phishing, filtrage suivant mots clef, ip,format, pays,langue ,piece jointe)
sinon depuis quelques jours les Serveurs de gros fournisseurs Yahoo(monde) neuf etc etc .... sont completement a la ramasse entre les codes de rejet bizarre suite a une erreur d interpretation SMTP ou encore d utilisateurs soudainement n existant plus
et bizarrement ca coincide avec une vague de spam assez virulante qui demande tout de meme au destinataire de rectifier lui meme l url recue pour etre valide ...
http://www.aaaaa%com http://www.aaaa!com etc etc
Patrick Texier wrote:
mais prennent des heures pour atteindre le destinataire; peut-on essayer de cerner d'ou vient le pb ? existe t'il des outils de trace ?
Il faut analyser les champs Received: dans les entêtes de bas en haut : chaque serveur ajoute sa trace au dessus des précédentes.
Voici un exemple qui est resté coincé 12 heures en interne sur une liste Yahoo!
|Received: from [snip] by t6.bullet.scd.yahoo.com with NNFMP; 27 Jan 2007 00:25:20 -0000 |Received: from [snip] by m30.grp.scd.yahoo.com with QMQP; 26 Jan 2007 12:34:14 -0000
Attention aux fuseaux horaires qui peuvent être différents (ici GMT : -0000).
un truc bete ... pour l analyser l entete faudrait encore que le dit
eMail soit recu :-)
effectivement l envoi d email n est pas une certitude en reception
de fait de nombreux parametres independants de l expediteur
comme du destinataire( anti spam/Virus/phishing, filtrage suivant mots
clef, ip,format, pays,langue ,piece jointe)
sinon depuis quelques jours les Serveurs de gros fournisseurs
Yahoo(monde) neuf etc etc ....
sont completement a la ramasse entre les codes de rejet bizarre
suite a une erreur d interpretation SMTP
ou encore d utilisateurs soudainement n existant plus
et bizarrement ca coincide avec une vague de spam assez virulante
qui demande tout de meme au destinataire de rectifier lui meme l url
recue pour etre valide ...
http://www.aaaaa%com
http://www.aaaa!com
etc
etc
Patrick Texier wrote:
mais prennent des heures pour atteindre le destinataire;
peut-on essayer de cerner d'ou vient le pb ?
existe t'il des outils de trace ?
Il faut analyser les champs Received: dans les entêtes de bas en haut :
chaque serveur ajoute sa trace au dessus des précédentes.
Voici un exemple qui est resté coincé 12 heures en interne sur une liste
Yahoo!
|Received: from [snip] by t6.bullet.scd.yahoo.com with NNFMP; 27 Jan 2007 00:25:20 -0000
|Received: from [snip] by m30.grp.scd.yahoo.com with QMQP; 26 Jan 2007 12:34:14 -0000
Attention aux fuseaux horaires qui peuvent être différents (ici
GMT : -0000).
un truc bete ... pour l analyser l entete faudrait encore que le dit eMail soit recu :-)
effectivement l envoi d email n est pas une certitude en reception de fait de nombreux parametres independants de l expediteur comme du destinataire( anti spam/Virus/phishing, filtrage suivant mots clef, ip,format, pays,langue ,piece jointe)
sinon depuis quelques jours les Serveurs de gros fournisseurs Yahoo(monde) neuf etc etc .... sont completement a la ramasse entre les codes de rejet bizarre suite a une erreur d interpretation SMTP ou encore d utilisateurs soudainement n existant plus
et bizarrement ca coincide avec une vague de spam assez virulante qui demande tout de meme au destinataire de rectifier lui meme l url recue pour etre valide ...
http://www.aaaaa%com http://www.aaaa!com etc etc
Patrick Texier wrote:
mais prennent des heures pour atteindre le destinataire; peut-on essayer de cerner d'ou vient le pb ? existe t'il des outils de trace ?
Il faut analyser les champs Received: dans les entêtes de bas en haut : chaque serveur ajoute sa trace au dessus des précédentes.
Voici un exemple qui est resté coincé 12 heures en interne sur une liste Yahoo!
|Received: from [snip] by t6.bullet.scd.yahoo.com with NNFMP; 27 Jan 2007 00:25:20 -0000 |Received: from [snip] by m30.grp.scd.yahoo.com with QMQP; 26 Jan 2007 12:34:14 -0000
Attention aux fuseaux horaires qui peuvent être différents (ici GMT : -0000).
Rakotomandimby (R12y) Mihamina
ES wrote:
effectivement l envoi d email n est pas une certitude en reception
Si. C'est un protocole très solide (et tout et tout); et on est certain que le mail arrivera, mais ce qu'on ne sait pas c'est _quand_.
de fait de nombreux parametres independants de l expediteur comme du destinataire (anti spam/Virus/phishing, filtrage suivant mots clef, ip,format, pays,langue
le destinataire devrait pouvoir choisir de recevoir tous les mails qui lui sont adressés. il devrait pouvoir demander de sont prestataire, que les robots du prestataire marquent les emails, et au destinataire de faire les filtrages necessaires.
,piece jointe)
Là par contre, c'est clair que SMTP n'est pas FTP. Pour transmettre des fichiers, on n'utilise pas les emails...
ES wrote:
effectivement l envoi d email n est pas une certitude en reception
Si.
C'est un protocole très solide (et tout et tout); et on est certain que le
mail arrivera, mais ce qu'on ne sait pas c'est _quand_.
de fait de nombreux parametres independants de l expediteur
comme du destinataire (anti spam/Virus/phishing, filtrage suivant mots
clef, ip,format, pays,langue
le destinataire devrait pouvoir choisir de recevoir tous les mails qui lui
sont adressés. il devrait pouvoir demander de sont prestataire, que les
robots du prestataire marquent les emails, et au destinataire de faire les
filtrages necessaires.
,piece jointe)
Là par contre, c'est clair que SMTP n'est pas FTP. Pour transmettre des
fichiers, on n'utilise pas les emails...
effectivement l envoi d email n est pas une certitude en reception
Si. C'est un protocole très solide (et tout et tout); et on est certain que le mail arrivera, mais ce qu'on ne sait pas c'est _quand_.
de fait de nombreux parametres independants de l expediteur comme du destinataire (anti spam/Virus/phishing, filtrage suivant mots clef, ip,format, pays,langue
le destinataire devrait pouvoir choisir de recevoir tous les mails qui lui sont adressés. il devrait pouvoir demander de sont prestataire, que les robots du prestataire marquent les emails, et au destinataire de faire les filtrages necessaires.
,piece jointe)
Là par contre, c'est clair que SMTP n'est pas FTP. Pour transmettre des fichiers, on n'utilise pas les emails...
