Identifier les problèmes d'emails

Cette note a pour objectif de décrire les étapes à effectuer pour identifier les problèmes de mails qui ne partent pas ou n'arrivent pas dans les boites-aux-lettres des destinataires. Elle doit permettre aux administrateurs de Kentika d'avoir des informations pertinentes à transmettre au support Kentika ou à leur propre service informatique, pour permettre de régler ces problèmes le plus rapidement possible.

Description du fonctionnement d'envoi des emails dans Kentika

Dans la plupart des cas (envoi de mails ponctuels, DSI, produits presse, scripts...), Kentika fonctionne en deux temps pour envoyer des emails :

1. Le mail est généré
2. Le mail est envoyé

En 1, le mail est généré et stocké dans la messagerie interne de Kentika. Il n'est pas envoyé immédiatement. Certains processus long de génération de mails (comme la DSI ou Kentika Press) bloquent l'envoi des mails tant qu'ils n'ont pas tous été générés.

En 2, un processus interne à Kentika se déclenche toutes les 2 minutes pour vérifier s'il y a des mails à envoyer. Si c'est le cas, il les envoie.

La messagerie interne

Tous les messages en attente (ou envoyés) sont stockés dans une table de la base de données. Ces enregistrements sont accessibles depuis l'explorateur de données :

Si vous n'avez pas cette option dans votre explorateur, il faut l'activer depuis les paramètres de messagerie.

Le statut des message

En cas de non réception de messages attendus, la première étape est donc de se rendre dans la messagerie pour identifier si les messages ont bien été générés. S'ils ne se trouvent pas dans la messagerie, le problème vient de la génération des mails, et non de leur envoi. Cela peut avoir de nombreuses raisons qui sortent de l'objet de cette note technique.

Si les messages sont bien dans la messagerie, la colonne Traité permettra d'avancer dans l'identification du problème.

Cette colonne peut prendre 3 valeurs, visibles sur la capture d'écran ci-dessus :

1. "Traité"
2. "error (*)"
3. Rien (la colonne est vide)

Il faut donc commencer par identifier les emails non reçus. Pour cela, vous disposez de plusieurs champs que vous pouvez afficher, ou sur lesquels vous pouvez trier ou rechercher. En particulier : Objet du mail, destinataire(s), date de création du mail ou heure de création du mail. L'expéditeur est aussi disponible, mais il n'est pas toujours évident de connaître l'expéditeur d'un mail automatique (créé par un script ou une DSI, par exemple).

La colonne Traité donnera plus d'informations sur l'état du mail :

Traité

Lorsque le mail est Traité, Kentika a contacté le serveur de messagerie, qui a accepté cet email. En parallèle avec le service postal, la lettre a été déposée auprès du service postal. S'il n'est pas arrivé, c'est qu'il a été bloqué en amont de Kentika. Dans ce cas, il faut faire remonter le problème auprès du service qui gère votre serveur de messagerie.

Le cas le plus commun est une détection entre le serveur de messagerie où le mail est envoyé et la boite-aux-lettres du destinataire en tant que spam. Il peut être utile de déclarer une entrée SPF auprès du DNS du domaine d'envoi de mail.

Il est possible que des réglages dans Kentika puisse régler ce problème, mais sans information précise sur la raison pour laquelle le mail a été bloqué, l'équipe de Kentika ne peut rien faire pour résoudre ce problème.

error (*)

Lorsque le mail est en error (*), le serveur de messagerie n'a pas répondu à Kentika ou a répondu avec une erreur. Si un LOGTRACE est activé dans Kentika, le message d'erreur (pas toujours très parlant, malheureusement) y est inscrit et peut donner des pistes quant à l'origine du problème.

D'autres indices peuvent être récupérés en regardant quels emails sont touchés :

• Si tous les emails sont en error (*), il est probable qu'il y a un souci de communication avec le serveur SMTP. Il est alors intéressant de vérifier les réglages de Kentika.
• Si une série de mails créés en même temps sont partiellement en error (*) (par exemple, 253 emails de DSI ont été générés, mais seuls 200 sont Traités, le reste est en error (*)). Dans ce cas, il est probable que le serveur de messagerie impose une limite au nombre de mails qui peuvent être envoyés sur une période donnée (en général par heure). Dans ce cas, soit il est possible de demander à augmenter cette limite (parfois en changeant de prestataire de serveur de messagerie), soit l'équipe de Kentika peut fournir un script permettant de temporiser l'envoi par rapport à cette limite, dans le cadre des coupons d'assistance.
• Si certains mails seulement sont en error (*), il faut commencer par vérifier que les destinataires sont corrects. Très souvent, le destinataire n'a pas d'adresse email, ou l'adresse est erronée (caractère interdit, erreur de copier-coller, espace avant ou après...)
  Si le destinataire est correct, les messages d'erreur du LOGTRACE peuvent aider. S'il est possible d'obtenir un message d'erreur sur le serveur de messagerie, cela peut souvent être plus utile.
  Il se peut également que l'expéditeur ne soit pas autorisé à utiliser le serveur de messagerie. Si un serveur de messagerie interne à l'entreprise est utilisé mais que la base Kentika intègre des personnes extérieures (avec des adresses emails externes), il est possible que le serveur de messagerie interne refuse d'envoyer ces messages.

Vide (pas de valeur)

Ceci peut être normal si le mail vient d'être généré, ou s'il a été généré alors qu'un processus de création de mails long (DSI ou Kentika Press, par exemple) est en court.

Si cela dure plus longtemps, en revanche, alors le mail est probablement "bloqué". À chaque fois que Kentika contacte le serveur de messagerie, ce dernier lui répond qu'il est là, mais quand Kentika lui envoie le mail, il n'envoie pas de réponse. Kentika est donc bloqué en attente d'une réponse (ok ou erreur).

Cela peut venir d'une erreur dans le destinataire ou l'expéditeur du mail, mais cela peut également avoir d'autres raisons. Ceci est assez gênant car cela peut bloquer l'envoi d'autres emails, voire la génération des emails. (Kentika n'exécute pas la DSI si un email est bloqué, par exemple, pour éviter d'engorger la messagerie.)

Renvoyer un mail en erreur

Lorsqu'un message est en error (*), il peut être intéressant de tenter de le renvoyer. Cela peut permettre de l'envoyer si une erreur sur le destinataire a été corrigée, par exemple. Ou cela peut permettre de voir si l'erreur se produit à certains moment de la journée et pas à d'autres. (Il arrive fréquemment qu'un mail refusé lors de l'envoi groupé avec d'autres mails soit refusé par le serveur de messagerie, mais accepté plus tard, envoyé seul.)

Pour renvoyer un email individuel en error (*), il suffit de l'ouvrir dans l'explorateur. Un message apparaîtra :

Cliquer sur OK permet de demander à renvoyer le message. Il faut ensuite valider l'email pour enregistrer le changement de statut. Le message aura alors la colonne Traité vide, il sera renvoyé au prochain passage du processus d'envoi des mails.

Pour renvoyer un lot d'emails en erreur, il suffit d'appliquer la formule ci-dessous sur ces emails :

Là encore, la colonne Traité repassera à vide, et les emails seront envoyés au prochain passage du processus d'envoi des mails.

Vérifier les réglages de messagerie

Les réglages sont accessibles depuis le poste client : Fichier > Préférences > Paramétrage > Messagerie.

Plus d'informations sur cet écran sont accessibles sur cette page.

Il existe par défaut un script qui permet de tester l'envoi des messages et les bons réglages de messagerie. Il est accessible depuis le poste client : Fichier > Exploitation > onglet B > Tester envoi emails.

Le script demande une adresse email de destination, et tente d'envoyer un email à l'adresse définie comme adresse des envois effectués par le logiciel dans les réglages. Il affiche à l'écran les messages d'erreur éventuels rencontrés.

Relancer le serveur Kentika

Comme indiqué plus haut, il arrive que certains messages sont bloqués. Après avoir supprimé ou corrigé les mails bloqués ou en erreur, si l'envoi des mails ne se fait toujours pas, il peut être intéressant de relancer le serveur Kentika pour s'assurer que les processus d'envoi ne sont plus bloqués.