L’e-mail n’est pas une simple affaire. Des centaines de millions de messages sont envoyés chaque jour. À lui tout seul, Zendesk en reçoit et en traite plusieurs millions. Au fil du temps, la mission de l’e-mail a évolué. Il ne se limite plus aux communications entre deux individus, mais s’est élargi aux envois en masse et aux communications par machine. Cette complexité nouvelle a introduit plusieurs menaces, notamment les boucles d’e-mail, que Zendesk prend en compte dans le cadre de sa gestion des e-mails.
Cet article contient les sections suivantes :
Qu’est-ce qu’une boucle d’e-mail ?
Les accusés de réception automatiques sont une pratique courante pour les logiciels qui reçoivent des e-mails. Le déclencheur par défaut Notifier le demandeur et les personnes en copie (CC) de la réception de la demande en est un exemple. Quand un ticket est créé dans Zendesk Support, l’utilisateur est notifié par e-mail. Ce type de comportement, même s’il est courant, peut provoquer un problème quand ce sont deux machines qui s’envoient des messages.
Le problème pour les machines n’est pas de recevoir les e-mails. Par exemple, si une machine reçoit un e-mail d’une autre machine et envoie une réponse automatique, pas de problème. Mais si cette deuxième machine envoie elle aussi une réponse automatique, cela risque de déclencher une boucle d’e-mail. Dans ce scénario, les deux machines continueront de se répondre automatiquement chaque fois qu’elles reçoivent une notification, ce qui crée une boucle infinie, qui ne s’arrêtera que si quelqu’un intervient.
Les boucles peuvent aussi se déclencher d’autres façons. Les mises à jour des tickets peuvent provenir de l’API, du partage de tickets, d’une application ou d’une interface Web. Ces mises à jour peuvent déboucher sur des e-mails envoyés par des notifications par déclencheur, comme Notifier le demandeur et les personnes en copie (CC) de la mise à jour des commentaires. Parfois, ces e-mails peuvent déboucher sur une autre mise à jour, pas par e-mail mais par d’autres moyens.
Comment Zendesk empêche les boucles d’e-mail
Zendesk prend diverses mesures pour empêcher les boucles d’e-mail. Mais attention, nous ne pouvons pas empêcher toutes les boucles d’e-mail. Elles font désormais partie de l’écosystème et nous faisons de notre mieux, mais comme le spam, elles sont parfois inévitables.
Voici quelques-unes des mesures que nous avons mises en place pour empêcher les boucles d’e-mail :
Pour savoir comment Zendesk empêche les boucles d’e-mail Zendesk-Zendesk, consultez Comment Zendesk empêche les boucles d’e-mail entre les comptes Zendesk.
Adresses d’assistance uniques, pas utilisées pour les utilisateurs
Vos utilisateurs vous contactent à vos adresses d’assistance. Si vous utilisez des adresses d’assistance externes (p. ex., support@monentreprise.com), Zendesk Support empêche les boucles d’e-mail en interdisant les utilisateurs ayant l’une de vos adresses d’assistance comme adresse e-mail. En d’autres termes, si vous avez un utilisateur final avec l’adresse support@exemple.com, vous ne pouvez pas activer support@exemple.com comme adresse d’assistance. Et si support@exemple.com est l’une de vos adresses d’assistance, vous ne pouvez pas créer d’utilisateur avec cette adresse.
Cela empêche l’envoi des notifications à vos adresses d’assistance. Si nous envoyions un e-mail à l’une de ces adresses, elle le transférerait automatiquement à Zendesk Support, ce qui créerait un autre ticket. Ce processus se poursuivrait en boucle et de nombreux tickets ou commentaires seraient créés.
Les e-mails de masse et les adresses no-reply ne créent pas de tickets
Certains e-mails ne créent pas de tickets par défaut, comme les e-mails ou messages en masse qui sont identifiés comme provenant d’une machine.
C’est aussi le cas pour les e-mails dont l’expéditeur est une adresse no-reply. Ces cas sont essentiellement régis par les tickets suspendus. Vous pouvez ajouter l’adresse à la liste autorisée si vous connaissez l’expéditeur et lui faites confiance, mais cela multipliera la limite de débit pour cette adresse e-mail spécifique et le nombre de suspensions par dix. À ce moment-là, Zendesk commence à abandonner le trafic. Zendesk se réserve le droit de suspendre ou de bloquer tout trafic qui dépasse des niveaux sûrs. Le canal E-mail n’est pas conçu pour le trafic programmatique ou automatisé ; c’est le but exclusif de l’API. L’utilisation du canal E-mail pour ce type de trafic doit se limiter à une solution alternative temporaire.
Quand un ticket est créé pour le compte d’un expéditeur de messages en masse, Zendesk supprime les notifications automatiques. Les commentaires des agents continueront de générer des notifications, mais pour éviter les boucles d’e-mail, Zendesk supprime tous les messages envoyés sans qu’un commentaire ait été ajouté. Cela est vrai quand vous récupérez ces messages dans les tickets suspendus ou quand vous ajoutez de tels utilisateurs à la liste autorisée.
Limite des mises à jour de ticket effectuées par un utilisateur en une heure
En dernier recours, Zendesk limite le nombre de mises à jour qu’un utilisateur peut effectuer en une heure. Cette limite est de 20 e-mails par utilisateur par heure. Au-delà de ce chiffre, les 20 mises à jour suivantes sont suspendues. S’il y a plus de 40 mises à jour, toutes les mises à jour supplémentaires sont rejetées (elles ne créent même pas de tickets suspendus). Cela nous permet d’empêcher que les boucles d’e-mail ne deviennent des problèmes graves.
Cette limite ne fonctionne pas si l’autre système n’utilise pas toujours la même adresse e-mail. Certains systèmes utilisent une nouvelle adresse e-mail pour chaque message automatisé.
Vous pouvez ajouter l’adresse à la liste autorisée si vous connaissez l’expéditeur et lui faites confiance, mais cela multipliera la limite de débit pour cette adresse e-mail spécifique et le nombre de suspensions par dix. À ce moment-là, Zendesk commence à abandonner le trafic. Zendesk se réserve le droit de suspendre ou de bloquer tout trafic qui dépasse des niveaux sûrs. Le canal E-mail n’est pas conçu pour le trafic programmatique ou automatisé ; c’est le but exclusif de l’API. L’utilisation du canal E-mail pour ce type de trafic doit se limiter à une solution alternative temporaire.