Pister la réception de mails ...

[Mick]

Bonjour

J'ai regardé dans :
--> \var\log\domino.log
--> notes.log

Mais je n'arrive pas à savoir ce qui a bien pu se passer ...


Un utilisateur aurait du recevoir un mail le 01/12 à 10h24 mais j'en ai aucune trace et lui ne l'a pas reçu.
Nous avons une taille maximale pour les mails à 20Mo et il se peut que le mail fasse plus.

--> Mais il est distribué plus tard ?
--> Comment puis je savoir ce qui s'est passé avec ce mail ?


Merci,

[AddemeTot]

Il s'agit de mail interne ?
Même serveur Domino pour l'expéditeur et le destinataire ?
Serveur Domino1 vers Serveur Domino2 ?
Mail venant de SMTP directement sur le serveur Domino du destinataire ?
Smtp vers Domino + routage NRPC avant reception ?

Quel est le niveau de certitude que le mail a effectivement été envoyé, en particulier si c'est un mail en provenance d'internet ?

[Mick]

Non il s'agit d'un mail extérieur et je ne sais pas quel système de messagerie la personne utilise.

Le destinataire n'a aucun retour de non distribution du mail.

Le destinataire nous dit avoir envoyé un mail le 01 décembre 2011 à 10h24 avec une pièce jointe.

[Michael DELIQUE]

salut

déjà demander à l'expéditeur de renvoyer le mail et ensuite lui demander de bien vérifier l'adresse email du destinataire quitte a mettre quelqu'un d'autre en copie

[AddemeTot]

Si ça vient d'internet, tu peux avoir des traces au niveau SMTP du coté domino, pour peu qu'en effet, l'envoyeur ne se soit pas trompé d'adresse, et que le message ne soit pas bloqué du coté de l'envoyeur.

Si on n'a pas de certitude que le mail a bien été envoyé, il faut effectivement demander a l'envoyeur de faire une nouvelle tentative.
On peut éventuellement mettre des parametres de debug sur le serveur SMTP Domino, en fonction de l'importance de l'analyse.
SmtpDebug=3 ou 4 => va loguer les sessions SMTP entrantes, les commandes utilisées et les réponses de Domino.

couplé a Console_log_Enabled=1, pour que la console soit enregistrée dans le fichier Data\IBM_TECHNICAL_SUPPORT\console.log

Mais bon, faut que ça en vaille la peine...

[roubech]

avant de s'emballer avec smtpDebug (sans vouloir te vexer batbat404), je pense que Mick devrait commencer par regarder dans log.nsf sur le(s) serveur(s) (au lieu de domino.log)
c'est pas compliqué à consulter, mais faut dejà savoir ou elle est et connaitre les différentes vues (evenements divers et routage en particulier)

ensuite, avant de deranger ton correspondant extérieur, tu peux faire le test depuis un webmail perso pour envoyer un mail vers ton collegue. Tu sera alors sur qu'il n'y a pas de pb de saisie de l'adresse et tu validera qu'il n'y a pas de pb de ton côté et alors tu pourra lui demander de refaire le test et de voir de son coté

[AddemeTot]

Je partais du principe que Mick avait fait les vérifications dans les logs actuels sans rien trouver.
Le test depuis un webmail ne prouvera malheureusement pas grand chose, si ce n'est que le routage et la réception SMTP sont fonctionnelles pour ce webmail en particulier.
Il y a effectivement beaucoup trop peu d'informations dans la description d'origine, et on peut facilement se perdre en s'éloignant du probleme de base.

[Mick]

Le destinataire vient de m'envoyer un mail sans PJ que j'ai bien reçu.
Par contre il m'a envoyé un autre mail avec une pièce jointe de 2Mo que je n'ai pas reçu ...

Et dans le log.nsf je n'ai que ça :
06/12/2011 14:53:44 SMTP Server: 0.0.0.0 connected
06/12/2011 14:53:44 SMTP Server: Originator: <111>
06/12/2011 14:53:44 SMTP Server: Recipient: <mon>
06/12/2011 14:53:44 SMTP Server: 0.0.0.0 disconnected. 0 message[s] received

Est-ce que le DAOS peut pertuber la distribution des PJ ?


Merci,

[roubech]

ca c'est la trace du second envoi ? dans la vue evenements divers ou routage ?
tu n'as pas une ligne en plus avec quelque chose du genre "... policy reason ... "
jamais activé DAOS encore, mais en théorie il est pas censé poser de pb

j'imagine que 0.0.0.0 c'est ta façon de masque l'IP réelle qui est dabns la log (et tu fais bien)
mais s'agit-il de l'IP du relais distant de l'émetteur ou de ton relais SMTP intermédiaire ?

@batbat404 : justement, comme on a pas toutes les infos, je pense que ce test a une utilité, il permet de réduire le nombre de causes possible
en effet, pour éliminer la piste d'une restriction de Domino en reception ou d'un relais intermédiaire, il faudrait savoir si seul un user interne a des pb pour recevoir les PJ ou si tout le monde ne reçoit pas les PJ > xx Mo
pour éliminer la piste d'un pb de limitation de l'émétteur, il faudrait savoir si le pb ne se pose que pour cet émetteur externe ou si un autre émetteur depuis un autre domaine a aussi le pb

[AddemeTot]

Mettre les logs te permet d'analyser directement le probleme en question. Que ce soit pour cet utilisateur ou un autre.
Chacun sa méthode, en fonction de ses impératifs, possibilité de demander une ré-émission du mail, possibilité de mettre en place les logs ou non et éventuelle maitrise de la lecture des logs.

Enfin bon, j'avais pas d'autre intention que d'aider, mais si c'est considéré comme de l'emballement, je garde mon temps pour moi hein...

[SISSI]

Bjr, Tu as essayé la fonction "Suivi de message" qui se trouve dans le client d'admin ? Onglet Messagerie-Centre de suivi.

[Mick]

Merci pour vos réponses ...

Oui ça c'est la trace de l'envoi avec PJ 2Mo extrait de l'évènement de routage du courrier.
Je n'ai pas trouvé dans les logs de "...policy reason..."

L'adresse IP correspond à mon relais SMTP intermédiaire.

[roubech]

ne le prend pas mal, batbat404, je ne dit pas que tu as tort au contraire
mais d'après ce que j'avais compris de son premier message, c'est qu'il ne connaissait pas le log.nsf, d'où mon "ne t'emballe pas", dans le sens "avant d'ajouter des traces en plus, il faut déjà commencer par regarder les traces existantes"

[Mick]

Je me permets un UP ...

Car je ne sais pas où chercher pour savoir ce que devienne certain mail à priori avec PJ que l'on ne reçoit jamais.

dois je activer le SMTP debug ?
autre ?


Merci,