Je rattrape mon retard sur les fonctionnalités de sondage POP3 et de réponse par e-mail et je commence à les comprendre.
Mais j’ai du mal à expliquer ce que notre serveur POP3 enregistre dans le journal lorsque Discourse s’y connecte. Pourriez-vous m’aider à expliquer les lignes appariées RETR/access enregistrées dans le journal du serveur POP3 chaque fois que Discourse s’y connecte ? Cela se produit, comme prévu par la valeur de pop3 polling period mins, toutes les 5 minutes.
Dans le fichier joint (21,2 Ko), les lignes enregistrées depuis l’activation des deux fonctionnalités et la première action de sondage.
J’hésite entre demander ici et chercher de l’aide sur le forum Dovecot. J’ai demandé ici car c’est Discourse qui interroge les e-mails du serveur. Votre réponse m’a aidé à faire correspondre le nombre de « lignes appariées » au nombre de messages disponibles sur le serveur. Je ne comprends pas encore pourquoi parfois le nombre de lignes appariées est exactement le nombre de messages dans la boîte de réception, mais d’autres fois il n’est que de 36.
Je cherche maintenant des informations auprès de la communauté Dovecot : j’ai besoin d’une explication complète du journal pour pouvoir utiliser les fonctionnalités POP3 de Discourse.
Êtes-vous sûr que les 36 sont causés par Discourse et non par, par exemple, Roundcube ou un autre client de messagerie qui récupère les e-mails page par page ?
Aussi sûr qu’un débutant utilisant l’été pour améliorer ses compétences peut l’être ! Merci de prendre en compte le problème.
Je pense que RoundCube utilise IMAP ici. La pièce jointe nouvelle pièce jointe (9,8 Ko) inclut une série n=36. Elle se reproduit toutes les 5 minutes. C’est principalement pourquoi je suppose que c’est lié à Discourse. Je ne suis pas encore capable de comprendre quand n est égal au nombre de messages dans la boîte de réception du compte de premise.
Je suis maintenant plus sûr de l’origine et après avoir lu RFC 1939 et pu accéder à rails c pour travailler avec la bibliothèque net/pop au moins pour quelques actions de base.
Ce que je ne parviens pas à expliquer, c’est pourquoi certains cycles d’interrogation ne lisent que 36 messages. Le dernier accès est toujours UID=36.
19 août 15:46:00 igfae dovecot: pop3(premises): Debug: Mailbox INBOX: Opened mail UID=36 because: access
19 août 15:46:00 igfae dovecot: pop3(premises): Debug: Mailbox INBOX: Opened mail UID=36 because: RETR
Ce nombre n’a pas été modifié malgré le fait qu’il y ait maintenant plus de messages sur le compte.
Pourriez-vous m’aider à trouver une explication à ce comportement ? Le personnel de sécurité de notre centre n’aime pas avoir des logiciels en cours d’exécution générant des journaux que nous ne pouvons pas expliquer ! Merci !
Cependant, aussi tentant que cela puisse être - car je n’aime pas non plus les choses que je ne comprends pas - je pense que c’est un exercice inutile puisqu’il n’y a pas de problème réel.
J’ai rapidement vérifié le code source la dernière fois et je n’y ai rien trouvé.
Je suggère de baisser le niveau de journalisation…
La journalisation est un autre sujet sur lequel j’ai beaucoup à apprendre !
Dans le fichier actuel /var/log/maillog de notre serveur de messagerie, 30644 lignes sur 36467 sont liées à Dovecot. Discourse est le seul service utilisant Dovecot dans notre organisation. Bien que de nombreuses personnes soient en vacances, 84 % des enregistrements dépeignent l’activité d’envoi d’e-mails de Discourse.
Je n’ai aucun contrôle sur ce que le serveur de messagerie enregistre. Je peux seulement le lire. Ainsi, je ne peux modifier que les informations que Discourse/Dovecot envoient. La plupart des lignes incluent Debug. Je suppose donc que la configuration de journalisation dans notre instance Discourse envoie des informations de débogage au serveur de messagerie.
Comment pourrais-je modifier ce comportement ?
Veuillez accepter mes excuses à l’avance si j’ai une compréhension erronée du fonctionnement du processus de journalisation ! Merci !
Non, le serveur de messagerie est configuré pour enregistrer au niveau « debug ».
Ce qui se passe est le suivant :
l’instance dovecot de votre organisation a été configurée pour enregistrer au niveau de débogage. Le niveau de débogage est destiné au dépannage avancé et nécessite une connaissance approfondie du fonctionnement du logiciel dovecot. Comme il n’y a pas de problème, il n’y a pas besoin de dépannage, et comme il n’y a pas besoin de dépannage, le niveau de journalisation peut être défini sur un niveau inférieur (moins verbeux).
Votre personnel de sécurité dans votre centre se plaint de ne pas comprendre les journaux. C’est parce que la compréhension de ces journaux nécessite une connaissance approfondie du fonctionnement du logiciel dovecot, qu’ils n’ont pas.
D’où la solution : le personnel qui gère le logiciel dovecot doit modifier le niveau de journalisation.
Ce n’est pas quelque chose dont ils devraient se plaindre aux personnes utilisant le logiciel dovecot (c’est-à-dire vous). C’est quelque chose qu’ils ou leurs collègues ont fait.
Ils l’ont fait ! Le journal est beaucoup plus propre et informatif maintenant.
Merci beaucoup pour votre explication. Il est beaucoup plus facile de dialoguer avec une bonne description et une analyse de la situation. Je comprends toutes les préoccupations de sécurité car nous avons connu des situations difficiles ces deux dernières années. J’accepte l’exercice de lutter pour une explication mais, sans votre aide et l’aide d’autres bénévoles ici et là, il ne serait pas possible pour des personnes comme moi, avec peu de compétences informatiques, d’utiliser et de promouvoir l’utilisation d’outils formidables comme Discourse.
De plus, je vais maintenant passer à d’autres doutes liés aux paramètres de messagerie. Merci beaucoup !