You are not logged in.
Pages: 1
Bonjour,
J'aimerais savoir quels sont les critères qui fait que GLPI ne collecte pas un mail dans un collecteur ?
Actuellement j'ai un collecteur qui se voit avec environ 50% de mail mis en rejet ??
Avant la migration en 9.3, il n'y avait pas de rejet sur ce collecteur. Donc pour débugger j'ai besoin de savoir sur quoi se base GLPI pour considérer un mail à rejeter.
Merci
Manu
GLPI 9.4.2
Debian 9
MariaDB 10.1
Plugin : FusionInventory, Order, PDF, Import fabricant, Comportement
Offline
Les principales raisons sont : le mail match avec votre blacklist, le From n'a pas les droits de créer un ticket ou un suivi ou il est inconnu de GLPI et vous n'autorisez pas la création de ticket anonyme, le ticket ne peut être affecté à aucune entité...
CentOS 6.5 - CentOS 7.x
PHP 5.6 - PHP 7.x - MySQL 5.6 - MariaDB 10.2 + APC + oOPcache
GLPI from 0.72 to dev version
Certifiée ITIL (ITV2F, ITILF, ITILOSA)
Offline
Bonjour,
Je rencontre le même soucis depuis la maj 9.3.2.
Au niveau des règles, les mails rejetés passe bien le test, dans la liste noir, celle-ci est vite pour les adresses.
Cela est d'ailleurs aléatoire, par exemple, toto@societe1.com aura bien sont mail pris en compte et la création du ticket, tata@societe1.com elle aura sont mail rejeté dans les log du collecteur "mailgate".
Auriez vous des pistes pour diagnostiquer de façon plus poussé ?
Je rappel qu'avant la migration 9.2 vers 9.3 il n'y avait aucun soucis, aucune règle n'a changé.
Cordialement
Offline
Je précise que suite aux tests, les mails d'un même utilisateur peut être aussi bien acceptés a un moment, puis refusé dans le "mailgate" a un autre moment.
Offline
Je n'avais pas précisé que j'ai bien vérifié les règles «Règles pour assigner un ticket créé via un collecteur de courriels»
Même si elles n'ont pas été modifiées depuis la migration.
J'ai activé le déplacement des mails rejeté vers un dossier de la boite mail collectée.
Exemple, hier 9 nouveaux tickets créer mais 30 mails rejetés, et cela ne concerne qu'un seul collecteur et une adresse
GLPI 9.4.2
Debian 9
MariaDB 10.1
Plugin : FusionInventory, Order, PDF, Import fabricant, Comportement
Offline
En regardant les mails rejetés, je vois dans le lot des réponses à des notifications de ticket.
J'ai également simplifier les règles pour être sûr qu'une valeur ne puisse être mal interprétée.
GLPI 9.4.2
Debian 9
MariaDB 10.1
Plugin : FusionInventory, Order, PDF, Import fabricant, Comportement
Offline
Je viens de faire un test, j'ai remplacé le fichier inc/mailcollector.class.php de la version 9.3.2 par celui de la 9.3.1
Cela fonctionne au niveau collecte et création de ticket.
GLPI 9.4.2
Debian 9
MariaDB 10.1
Plugin : FusionInventory, Order, PDF, Import fabricant, Comportement
Offline
Bonjour,
Grand merci pour cette info, effectivement en copier l'ancien fichier mailcollector cela refonctione...
En espèrant que cela n'apporte pas de nouveau bug (nous venons de la version 9.2), je vais regarder un peu les différence dans les deux version de fichiers.
Mais encore merci !
Guillaume
Offline
La version 9.3.1 avait des bug c'est pour ça qu'il a été modifié.
Je n'ai plus la liste en tête mais cela concernait les emoj et PJ entre autres.
GLPI 9.4.2
Debian 9
MariaDB 10.1
Plugin : FusionInventory, Order, PDF, Import fabricant, Comportement
Offline
Proposition de correction : https://github.com/glpi-project/glpi/pull/4890
CentOS 6.5 - CentOS 7.x
PHP 5.6 - PHP 7.x - MySQL 5.6 - MariaDB 10.2 + APC + oOPcache
GLPI from 0.72 to dev version
Certifiée ITIL (ITV2F, ITILF, ITILOSA)
Offline
Bonjour,
En 9.3.2, la principale modification pouvant expliquer ce que vous remontez est que les mails sont refusés dès lors que l'utilisateur n'a pas les droits pour effectuer l'actions découlant de la collecte.
- Si un utilisateur n'a pas les droits pour créer un ticket, son mail sera refusé. Ce refus a lieu même si la création de tickets anonymes est autorisé
- Si un utilisateur n'a pas les droits d'ajouter un suivi au ticket, son mail sera refusé. Ce refus a lieu même si l'ajout de suivi anonymes est autorisé
Le fait que des refus aient lieu même lorsque l'action est autorisée pour un utilisateur anonyme a été source de retours négatifs de la part des utilisateurs, et nous avons donc choisi de modifier ce comportement. La modifications suivante doit permettre de ne plus effectuer de vérification de droits lorsque l'action est autorisée pour les utilisateur anonymes : https://github.com/glpi-project/glpi/pull/4904.
Merci de nous faire un retour pour nous indiquer si votre problème est lié à ce comportement et résolu par cette correction ou s'il est autre et nécessite de mener d'autres investigations.
Cordialement
Offline
Pages: 1