Dans un environnement SBS 2003 avec Exchange, je reçois convenablement les
messages de l'extèrieur alors que expéditeurs recoivent eux une notification
de non remise :
Reporting-MTA: dns;toto.com
Received-From-MTA: dns;smtp24.orange.fr
Arrival-Date: Tue, 30 Jan 2007 17:19:48 +0400
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
Antoine Leca
Denis écrivit dans news::
Dans un environnement SBS 2003 avec Exchange, je reçois convenablement les messages de l'extèrieur alors que expéditeurs recoivent eux une notification de non remise : Reporting-MTA: dns;toto.com Received-From-MTA: dns;smtp24.orange.fr
J'ai peur de dire une grosse bêtise, mais pour moi cette non-remise n'a pas été émise par Exchange mais plutôt par un autre serveur SMTP, qui doit donc logiquement se situer en amont sur le chemin (genre, au hasard, celui du FAI).
Comment récupérez-vous vos messages ? (SMTP ou POP?)
Arrival-Date: Tue, 30 Jan 2007 17:19:48 +0400
+0400? Heure de l'Atlantique? Hummm... Avec cette information, vous devriez pouvoir chercher dans votre journal (SYSTEM32LogFilesSMTPSVC1) si le message a réellement atteint votre serveur, et de là fouiller les journaux d'évenements pour voir si Exchange a eu un souci.
Cause possible : Le courrier local est refusé car le message est trop volumineux. Un numéro d'ID de sécurité de compte principal absent sur le destinataire peut également provoquer ce message d'erreur.
Résolution du problème : Vérifiez les autorisations d'accès ainsi que la taille du message. Vérifiez si le destinataire dispose d'un numéro d'ID de sécurité de compte.
Pour info, selon la RFC (http://www.ietf.org/rfc/rfc1893.txt), un serveur devrait répondre 5.2.3 pour un «simple» dépassement de quota, et 5.2.1 derait signaler seulement un problème d'autorisation : 5.x.x: "ne pas résssayer", et X.2.1 "Mailbox disabled, not accepting messages".
Antoine
Denis écrivit dans
news:B4622007-5540-4055-AA03-5A01FA35E59A@microsoft.com:
Dans un environnement SBS 2003 avec Exchange, je reçois
convenablement les messages de l'extèrieur alors que expéditeurs
recoivent eux une notification de non remise :
Reporting-MTA: dns;toto.com
Received-From-MTA: dns;smtp24.orange.fr
J'ai peur de dire une grosse bêtise, mais pour moi cette non-remise n'a pas
été émise par Exchange mais plutôt par un autre serveur SMTP, qui doit donc
logiquement se situer en amont sur le chemin (genre, au hasard, celui du
FAI).
Comment récupérez-vous vos messages ? (SMTP ou POP?)
Arrival-Date: Tue, 30 Jan 2007 17:19:48 +0400
+0400? Heure de l'Atlantique? Hummm...
Avec cette information, vous devriez pouvoir chercher dans votre journal
(SYSTEM32LogFilesSMTPSVC1) si le message a réellement atteint votre
serveur, et de là fouiller les journaux d'évenements pour voir si Exchange a
eu un souci.
Cause possible : Le courrier local est refusé car le message
est trop volumineux. Un numéro d'ID de sécurité de compte
principal absent sur le destinataire peut également provoquer
ce message d'erreur.
Résolution du problème : Vérifiez les autorisations d'accès
ainsi que la taille du message. Vérifiez si le destinataire
dispose d'un numéro d'ID de sécurité de compte.
Pour info, selon la RFC (http://www.ietf.org/rfc/rfc1893.txt), un serveur
devrait répondre 5.2.3 pour un «simple» dépassement de quota, et 5.2.1
derait signaler seulement un problème d'autorisation : 5.x.x: "ne pas
résssayer", et X.2.1 "Mailbox disabled, not accepting messages".
Dans un environnement SBS 2003 avec Exchange, je reçois convenablement les messages de l'extèrieur alors que expéditeurs recoivent eux une notification de non remise : Reporting-MTA: dns;toto.com Received-From-MTA: dns;smtp24.orange.fr
J'ai peur de dire une grosse bêtise, mais pour moi cette non-remise n'a pas été émise par Exchange mais plutôt par un autre serveur SMTP, qui doit donc logiquement se situer en amont sur le chemin (genre, au hasard, celui du FAI).
Comment récupérez-vous vos messages ? (SMTP ou POP?)
Arrival-Date: Tue, 30 Jan 2007 17:19:48 +0400
+0400? Heure de l'Atlantique? Hummm... Avec cette information, vous devriez pouvoir chercher dans votre journal (SYSTEM32LogFilesSMTPSVC1) si le message a réellement atteint votre serveur, et de là fouiller les journaux d'évenements pour voir si Exchange a eu un souci.
Cause possible : Le courrier local est refusé car le message est trop volumineux. Un numéro d'ID de sécurité de compte principal absent sur le destinataire peut également provoquer ce message d'erreur.
Résolution du problème : Vérifiez les autorisations d'accès ainsi que la taille du message. Vérifiez si le destinataire dispose d'un numéro d'ID de sécurité de compte.
Pour info, selon la RFC (http://www.ietf.org/rfc/rfc1893.txt), un serveur devrait répondre 5.2.3 pour un «simple» dépassement de quota, et 5.2.1 derait signaler seulement un problème d'autorisation : 5.x.x: "ne pas résssayer", et X.2.1 "Mailbox disabled, not accepting messages".
Antoine
Denis
Bonjour et merci d'avoir répondu, Je récupère mes messages en smtp, et je ne pense pas que cela vienne du smtp du provider car j'ai moi même essayé d'envoyer des messages de l'extèrieur, et je n'ai ce problème que lorsque j'envoi des messages à mon domaine....
"Antoine Leca" a écrit :
Denis écrivit dans news:: > Dans un environnement SBS 2003 avec Exchange, je reçois > convenablement les messages de l'extèrieur alors que expéditeurs > recoivent eux une notification de non remise : > Reporting-MTA: dns;toto.com > Received-From-MTA: dns;smtp24.orange.fr
J'ai peur de dire une grosse bêtise, mais pour moi cette non-remise n'a pas été émise par Exchange mais plutôt par un autre serveur SMTP, qui doit donc logiquement se situer en amont sur le chemin (genre, au hasard, celui du FAI).
Comment récupérez-vous vos messages ? (SMTP ou POP?)
> Arrival-Date: Tue, 30 Jan 2007 17:19:48 +0400
+0400? Heure de l'Atlantique? Hummm... Avec cette information, vous devriez pouvoir chercher dans votre journal (SYSTEM32LogFilesSMTPSVC1) si le message a réellement atteint votre serveur, et de là fouiller les journaux d'évenements pour voir si Exchange a eu un souci.
Cause possible : Le courrier local est refusé car le message est trop volumineux. Un numéro d'ID de sécurité de compte principal absent sur le destinataire peut également provoquer ce message d'erreur.
Résolution du problème : Vérifiez les autorisations d'accès ainsi que la taille du message. Vérifiez si le destinataire dispose d'un numéro d'ID de sécurité de compte.
Pour info, selon la RFC (http://www.ietf.org/rfc/rfc1893.txt), un serveur devrait répondre 5.2.3 pour un «simple» dépassement de quota, et 5.2.1 derait signaler seulement un problème d'autorisation : 5.x.x: "ne pas résssayer", et X.2.1 "Mailbox disabled, not accepting messages".
Antoine
Bonjour et merci d'avoir répondu,
Je récupère mes messages en smtp, et je ne pense pas que cela vienne du smtp
du provider car j'ai moi même essayé d'envoyer des messages de l'extèrieur,
et je n'ai ce problème que lorsque j'envoi des messages à mon domaine....
"Antoine Leca" a écrit :
Denis écrivit dans
news:B4622007-5540-4055-AA03-5A01FA35E59A@microsoft.com:
> Dans un environnement SBS 2003 avec Exchange, je reçois
> convenablement les messages de l'extèrieur alors que expéditeurs
> recoivent eux une notification de non remise :
> Reporting-MTA: dns;toto.com
> Received-From-MTA: dns;smtp24.orange.fr
J'ai peur de dire une grosse bêtise, mais pour moi cette non-remise n'a pas
été émise par Exchange mais plutôt par un autre serveur SMTP, qui doit donc
logiquement se situer en amont sur le chemin (genre, au hasard, celui du
FAI).
Comment récupérez-vous vos messages ? (SMTP ou POP?)
> Arrival-Date: Tue, 30 Jan 2007 17:19:48 +0400
+0400? Heure de l'Atlantique? Hummm...
Avec cette information, vous devriez pouvoir chercher dans votre journal
(SYSTEM32LogFilesSMTPSVC1) si le message a réellement atteint votre
serveur, et de là fouiller les journaux d'évenements pour voir si Exchange a
eu un souci.
Cause possible : Le courrier local est refusé car le message
est trop volumineux. Un numéro d'ID de sécurité de compte
principal absent sur le destinataire peut également provoquer
ce message d'erreur.
Résolution du problème : Vérifiez les autorisations d'accès
ainsi que la taille du message. Vérifiez si le destinataire
dispose d'un numéro d'ID de sécurité de compte.
Pour info, selon la RFC (http://www.ietf.org/rfc/rfc1893.txt), un serveur
devrait répondre 5.2.3 pour un «simple» dépassement de quota, et 5.2.1
derait signaler seulement un problème d'autorisation : 5.x.x: "ne pas
résssayer", et X.2.1 "Mailbox disabled, not accepting messages".
Bonjour et merci d'avoir répondu, Je récupère mes messages en smtp, et je ne pense pas que cela vienne du smtp du provider car j'ai moi même essayé d'envoyer des messages de l'extèrieur, et je n'ai ce problème que lorsque j'envoi des messages à mon domaine....
"Antoine Leca" a écrit :
Denis écrivit dans news:: > Dans un environnement SBS 2003 avec Exchange, je reçois > convenablement les messages de l'extèrieur alors que expéditeurs > recoivent eux une notification de non remise : > Reporting-MTA: dns;toto.com > Received-From-MTA: dns;smtp24.orange.fr
J'ai peur de dire une grosse bêtise, mais pour moi cette non-remise n'a pas été émise par Exchange mais plutôt par un autre serveur SMTP, qui doit donc logiquement se situer en amont sur le chemin (genre, au hasard, celui du FAI).
Comment récupérez-vous vos messages ? (SMTP ou POP?)
> Arrival-Date: Tue, 30 Jan 2007 17:19:48 +0400
+0400? Heure de l'Atlantique? Hummm... Avec cette information, vous devriez pouvoir chercher dans votre journal (SYSTEM32LogFilesSMTPSVC1) si le message a réellement atteint votre serveur, et de là fouiller les journaux d'évenements pour voir si Exchange a eu un souci.
Cause possible : Le courrier local est refusé car le message est trop volumineux. Un numéro d'ID de sécurité de compte principal absent sur le destinataire peut également provoquer ce message d'erreur.
Résolution du problème : Vérifiez les autorisations d'accès ainsi que la taille du message. Vérifiez si le destinataire dispose d'un numéro d'ID de sécurité de compte.
Pour info, selon la RFC (http://www.ietf.org/rfc/rfc1893.txt), un serveur devrait répondre 5.2.3 pour un «simple» dépassement de quota, et 5.2.1 derait signaler seulement un problème d'autorisation : 5.x.x: "ne pas résssayer", et X.2.1 "Mailbox disabled, not accepting messages".
