Collecteurs

La configuration des récepteurs est accessible depuis le menu Configuration -> Récepteurs.

Un récepteur permet d'importer des emails depuis une boîte aux lettres et de les transformer en tickets GLPI. Un mécanisme de routage les acheminera vers l'entité de destination.

Un récepteur est associé à une adresse email. Il est possible d'en ajouter autant que vous le souhaitez. Bien sûr, plus vous configurez de récepteurs, plus le temps d'importation sera long.

Pour déclarer un nouveau collecteur, vous devrez fournir un nom de serveur, ainsi que les options de connexion (IMAP ou POP, SSL, TLS, validation du certificat). Il est possible de limiter la taille maximale des pièces jointes (pas d'importation, ou de 1 à 100 Mio). Cette valeur de configuration est héritée de la configuration principale (Configuration -> Général -> Assistance). Une option de configuration permet de basculer la date de création des tickets entre la date d'importation ou la date de l'email.

Optionnellement, vous pouvez définir un répertoire d'archive dans la boîte aux lettres où seront stockés les emails importés et refusés.

Les récepteurs qui rencontrent des erreurs seront indiqués au-dessus de la liste. Dans ce cas, le nombre d'erreurs successives sera affiché dans le formulaire de configuration du collecteur.

Une fois le formulaire validé, vous pouvez tester la connexion et la récupération des messages en utilisant le bouton dédié.

Une action automatique effectuera l'importation sur les récepteurs configurés ; l'intervalle entre deux exécutions peut être configuré dans le formulaire de tâche automatisée.

Une autre action automatique enverra des notifications lorsqu'un collecteur échoue de manière répétée à importer des emails. Voir la configuration des notifications.

Les réponses aux emails générés depuis GLPI pour les tickets sont nettoyées lors de l'importation par un collecteur : tout le contenu situé entre les balises up et bottom sera supprimé. Les réponses doivent être faites avant ou après le message original.

Listes noires

Les récepteurs peuvent utiliser un mécanisme de liste noire afin de supprimer des contenus récurrents mais inutiles, comme les signatures d'email.

La liste noire peut également empêcher l'importation d'emails provenant d'adresses email spécifiques ; cela peut être utile pour prévenir le spam, ou pour gérer des alias d'email.

Règles pour l'assignation d'un ticket ouvert via un récepteur

GLPI implémente un mécanisme de routage des tickets ouverts par email, afin de les créer dans la bonne entité. Ceci est basé sur le moteur de règles.

Si les notifications ne sont pas activées dans la configuration, le menu n'apparaît pas dans Règles.

Les critères disponibles sont :

• nom du récepteur

• demandeur

• domaine de l'email, qu'il soit connu ou non

• en-têtes de l'email : auto_submitted, from, in_reply_to, received, subject, to, X-Auto-Response-Suppress, X-priority, X-UCE-Status

• corps de l'email.

Enfin, il existe un troisième type de critère qui opère sur des données spécifiques à l'utilisateur ou à la configuration des entités :

• domaine email connu : vérifie que le domaine email de l'email envoyé correspond à un domaine renseigné dans une entité. Ce critère permet d'éliminer par exemple tout spam, c'est-à-dire les messages ne provenant pas de domaines autorisés.

• utilisateur : groupe : vérifie que l'utilisateur GLPI associé à l'adresse email de l'expéditeur appartient à un groupe donné.

• utilisateur avec profil : l'utilisateur possède un profil donné.

• utilisateur avec profil unique : l'utilisateur possède un et un seul profil dans GLPI. Si le profil est associé à plusieurs entités différentes, alors celle qui est définie comme entité par défaut dans les options de personnalisation de l'utilisateur sera l'entité du ticket. Si aucune n'est définie dans les préférences, la règle ne correspond pas.

• utilisateur avec le profil une seule fois : l'utilisateur possède un profil donné une seule fois : il n'a pas le profil assigné sur plusieurs entités distinctes.

Les actions sont soit le refus du ticket (avec ou sans notification du refus à l'émetteur), soit l'importation dans une entité (manuelle, depuis TAG, depuis domaine mail, depuis profil utilisateur).

Le moteur s'arrête à la première règle correspondante.

exemple

Un exemple d'utilisation du moteur est le suivant :

1. règle refusant les emails dont le domaine email est inconnu (ne tenant pas compte du spam) ;

2. règle refusant les messages provenant de listes de diffusion ;

3. règles affectant les emails si l'utilisateur n'a qu'un seul profil (cas des utilisateurs de l'interface simplifiée) ;

4. règle affectant les emails à une entité si l'utilisateur a un profil particulier (par exemple pour les super administrateurs, qui ont accès à toutes les entités, mais sont physiquement dans une entité particulière).