Poznaj nas
Pomoc
Obsługa klienta
Formularz kontaktowy
Tel: +48 695 742 350
E-mail: biuro@roan24.pl
w dni robocze pon.-pt.
w godz. 7:00-21:00
© 2023 ROAN Agencja Interaktywna Maria Łukin w spadku. Korzystając z tej strony, zgadzasz się z naszą polityką cookies.
Formularz kontaktu
Tel: +48 695 742 350
E-mail: biuro@roan24.pl
w dni robocze pon.-pt.
w godz. 7:00-21:00
© 2023 ROAN Agencja Interaktywna Maria Łukin. Korzystanie z serwisu oznacza akceptację polityki cookies.
Należy pamiętać, że korzystając z witryny bez zmiany ustawień przeglądarki, użytkownik wyraża zgodę na politykę prywatności i przechowywanie plików cookie, które umożliwiają sprawne działanie naszej witryny.
Problème de DKIM
Aujourd’hui, une situation intéressante s’est produite lorsqu’un de nos employés n’a pas pu contacter une entreprise externe. Il m’a informé que le courrier ne lui parvenait pas depuis un domaine, supposons qu’il s’agisse de domain.com. Bien que ses messages lui parviennent, l’autre partie ne reçoit aucun message de retour indiquant la raison du rejet du courrier. Il m’a demandé de vérifier le problème. Je vais vous expliquer brièvement comment je m’y suis pris et ce qui a causé le problème.
Diagnostic de l’actualité – Exim
Comme nous utilisons exim comme MTA, les commandes ici seront spécifiques à ce système, mais le processus peut facilement être utilisé dans postfix également.
La première information est que si les messages ne sont pas renvoyés à l’expéditeur, cela signifie qu’ils sont bloqués quelque part, qu’ils ont rencontré une erreur temporaire et qu’un des serveurs va essayer de les délivrer à nouveau. Il s’agit d’une action standard et il n’y a rien d’étrange ici ; les personnes qui ont lu notre article sur le fonctionnement du courrier le savent. Et l’information importante est que les messages ont été envoyés depuis domain.com.
Lorsque les messages sont bloqués quelque part, nous vérifions notre file d’attente de messages à livrer pour voir s’ils sont bloqués chez nous ou s’ils ne nous sont même pas parvenus :
C’est-à-dire que le message est dans notre file d’attente depuis 66 minutes et qu’il ne peut pas être remis, ce qui peut paraître un peu surprenant que le message soit sur notre serveur et qu’il ne soit pas encore parvenu au destinataire, mais nous en parlerons en temps voulu. Le test suivant consiste à vérifier les journaux à l’aide de l’utile commande exigrep, qui recherche les messages basés sur des données données, par exemple un domaine, et affiche toutes les informations sur ce qui lui est arrivé. En utilisant un simple grep dans cette situation, nous ne disposerions pas de toutes les informations.
C’est-à-dire que nous avons la raison, le message n’est pas livré parce qu’il ne peut pas trouver l’entrée DKIM dans la zone DNS, et le message lui-même est signé et devrait être vérifié s’il vient d’une source réelle, donc juste pour être sûr, nous vérifions si une telle entrée existe parce que cela pourrait être un problème avec notre serveur DNS local. Nous allons utiliser le serveur DNS public de Google pour vérifier :
Nous avons donc la raison, l’entrée txt pour le domaine zendesk1._domainkey.domain.com n’existe pas et là notre serveur va chercher la clé DKIM avec laquelle il peut vérifier la signature. Tout d’abord, pourquoi zendesk1._domainkey.domain.com ? Eh bien, plus tôt dans le journal, nous avions des données DKIM données : „d=domain.com s=zendesk1 c=relaxed/relaxed a=rsa-sha256 t=1431354869″ comme vous pouvez le voir l’entrée s= est en fait zendesk1 et s représente le sélecteur. Il nous indique sous quel domaine nous devons chercher l’entrée DKIM, dans ce cas zendesk1._domainkey.domain.com, selon le modèle : valeur s._domainkey.valeur d, d étant le domaine. S’il n’y a pas d’entrée txt, cela signifie qu’il y a un problème temporaire avec le serveur DNS ou que quelqu’un ne l’a pas entré là, comme ce fut le cas pour ce domaine.
La requête de recherche elle-même a fourni une autre information, à savoir que les serveurs DNS sont gérés par Cloudflare. Il s’agit d’une entreprise avec laquelle nous avons travaillé et nous ne manquerons pas d’écrire à son sujet. Cloudflare agit comme un proxy pour le serveur web mais cela nécessite que vous abandonniez également votre propre serveur DNS, qu’est-ce que cela signifie ? Eh bien, cette personne n’a tout simplement pas entré la clé DKIM dans la zone DNS, de sorte que notre serveur n’a pas pu vérifier si le message est correctement signé, et a attendu avec la livraison jusqu’à ce que quelqu’un ajoute une entrée DNS ou le serveur DNS commence à répondre, mais cela ne s’est pas produit jusqu’à 6 heures à partir du moment où le message est arrivé sur notre serveur et il a été automatiquement retourné à l’expéditeur comme non livrable en raison d’une erreur DKIM. J’ai, bien entendu, informé l’autre partie du problème et nous attendons qu’elle le résolve.
Un bon outil pour vérifier la configuration correcte de l’e-mail est le site web . Il suffit d’envoyer un e-mail à l’adresse fournie et de cliquer sur le bouton pour obtenir un rapport complet. Les courriels envoyés depuis nos domaines obtiennent 10/10 points.
Bonus – Qu’est-ce que le sélecteur DKIM ?
Un sélecteur n’est rien d’autre qu’une information sur la clé DKIM avec laquelle le message a été signé, et où la chercher. Il a été introduit pour donner aux administrateurs la possibilité d’entrer plusieurs clés pour un seul domaine afin que les anciennes clés ou les clés compromises puissent être facilement révoquées, ou vous n’avez pas besoin de garder un œil sur la clé parce qu’elle disparaît, vous pouvez rapidement changer le sélecteur et commencer à signer avec la nouvelle clé, ou même ne pas le changer du tout mais commencer à signer avec la nouvelle clé immédiatement, cependant cela signifie que les messages qui sont envoyés pendant le changement peuvent être retournés en raison de la mauvaise clé.