Détecter une adresse e-mail hébergée sur Google Suite
Analyse des adresses e-mail et identification du fournisseur d’hébergement aident à mieux connaître les clients. Une adresse e-mail utilisant Google Suite peut correspondre à un service payant ou à un hébergement destiné à un établissement universitaire.
Une adresse peut aussi être hébergée par les services Google depuis l’époque où « Google Apps for your domain » était proposé gratuitement. Dans ce cas, il ne s’agit pas d’un service e-mail premium payant. Les informations publiques ne permettent pas de distinguer ces cas de façon fiable.
Tout domaine qui peut recevoir des e-mails possède des enregistrements MX dans ses enregistrements DNS. Pour un domaine Google Suite, ces enregistrements pointent vers les serveurs e-mail de Google. Si l’adresse e-mail est john@example.com et que le domaine example.com utilise GSuite, un enregistrement MX peut ressembler à ceci :
{
"host": "wsj.com",
"class": "IN",
"ttl": 1800,
"type": "MX",
"pri": 1,
"target": "aspmx.l.google.com"
}
On voit ici clairement l’adresse du serveur cible : aspmx.l.google.com. Ce serveur reçoit physiquement tous les e-mails envoyés aux adresses ***@example.com.
Pour accéder aux données des enregistrements MX, il faut un service capable d’interroger les enregistrements DNS. Dans cet exemple, nous pouvons utiliser notre API de démonstration :
http://sampleapis.Decisimo.net/dns/?email=john@example.com
Assembler les éléments dans le moteur de décision Decisimo
1. Créer un objet de données de démonstration
Créons un objet de données de démonstration pour tester rapidement nos règles. Ajoutez l’attribut $.email avec la valeur fictive journalist@wsj.com (ce domaine utilise GSuite).
2. Créer une source de données
Dans Data sources, le bouton New ouvre le formulaire à côté de AI Assistant. Décrivez le fournisseur et l’appel, puis vérifiez et appliquez les paramètres HTTP.
3. Créer un flux de décision
Dans le nouveau flux de décision, ajoutez trois étapes : start, external data et rule set. Reliez-les ensuite dans cet ordre.
Start indique au moteur le début de l’exécution. L’étape External data appelle en parallèle les sources de données définies, à partir des options de l’étape. Rule set contient l’ensemble de règles sélectionné.
4. Définir l’étape External data
Ajoutez ensuite une option à External data pour utiliser la vérification DNS que nous venons de créer. Cette vérification attend l’adresse e-mail dans le paramètre email. Indiquez que ce paramètre doit reprendre la valeur de l’attribut $.email de l’objet de données.
5. Créer une version intermédiaire et la tester
Nous pouvons maintenant déployer le flux de décision et le tester. Le déploiement crée un instantané du flux de décision et de tous ses éléments. Nous pouvons ainsi tester le comportement du flux lors de l’exécution.
Sur la page de la version, à gauche, sélectionnez l’objet de données de test dans la liste déroulante, puis cliquez sur load. Un objet JSON contenant les attributs de l’adresse e-mail s’affiche en dessous.
Une fois l’objet de données chargé, cliquez sur « Tester la version », patientez un instant, puis examinez le résultat de l’exécution simulée. À la fin du test, le panneau de droite affiche le JSON initial, enrichi des données recueillies par le moteur pendant l’exécution.
Le résultat montre les données externes récupérées par la vérification DNS. Dans le chemin output - check - dns-check - mx se trouve un tableau des enregistrements MX trouvés pour l’adresse e-mail.
Si mx ne contient aucun enregistrement, le domaine ne reçoit pas d’e-mails. Il peut y avoir un seul enregistrement ou parfois 10.
Pour récupérer ces détails MX dans notre règle, nous devons écrire du JSONPath. Il est préférable de copier la réponse ou le résultat JSON. Si vous ne maîtrisez pas JSONPath, vous pouvez utiliser un site comme jsonpath.com.
6. Créer une règle
Maintenant que nous savons quelles données attendre, nous créons un ensemble de règles pour déterminer si une adresse e-mail est hébergée par Google.
Notre règle évaluera le contenu de $.output.check.dns-check.mx[0].target. Les utilisateurs de Gmail ont généralement plusieurs enregistrements, nous ne chercherons donc pas une correspondance exacte. Toute cible se terminant par aspmx.l.google.com sera considérée comme hébergée par Google.
Nous allons créer deux règles : l’une pour détecter l’hébergement Google, l’autre pour indiquer qu’il ne s’agit pas d’un hébergement Google GSuite.
Ensuite, modifiez l’étape rule set du flux de décision. Sélectionnez l’ensemble de règles, enregistrez-le, puis testez et déployez à nouveau.
7. Tester, créer un point d’accès API et le déployer
Nous pouvons maintenant vérifier que l’adresse est correctement détectée. Idéalement, wsj.com doit renvoyer « is google ». Les autres domaines doivent renvoyer no.
Si le test est concluant, vous pouvez configurer un point d’accès API. Créez-le sur une instance aussi proche que possible de vos serveurs. En Europe, choisissez une instance européenne. En Asie, choisissez-en une en Asie. Une autre région peut ajouter plusieurs centaines de millisecondes au temps de réponse.
Une fois le point d’accès API prêt, retournez dans les versions. Sélectionnez la dernière version qui fonctionnait, puis testez-la à nouveau. Si tout fonctionne, sélectionnez votre point d’accès API en bas de la page et cliquez sur deploy. Lorsque le message confirme la fin du déploiement, vous pouvez envoyer des requêtes au point d’accès API. Il exécutera le flux de décision que vous venez de tester.
8. Tester le point d’accès API avec Postman
Copiez le JSON du test et l’URL du point d’accès API, puis ouvrez Postman pour commencer les essais.
Dans Postman, sélectionnez la méthode POST. Collez l’URL du point d’accès API dans le champ request URL. Cliquez sur Body, sélectionnez Raw, puis remplacez text par JSON à droite. Collez ci-dessous le JSON contenant l’adresse e-mail, puis cliquez sur SEND.
Si tout fonctionne, vous devriez obtenir la même réponse que lors du test dans le portail.
9. Intégrer le point d’accès à votre système
Si tout fonctionne correctement, intégrez le point d’accès API à votre système pour mettre à jour les règles et déployer rapidement les modifications. Le point d’accès reste le même. Les règles du flux de décision peuvent être modifiées dès que nécessaire.
Bonne prise de décision !
Questions fréquentes
La règle doit-elle vérifier le premier enregistrement MX ou tous les enregistrements ?
Vérifiez toutes les cibles MX, pas seulement la première. Le DNS peut renvoyer plusieurs enregistrements, dont l’ordre peut varier. Normalisez les noms d’hôte et comparez-les à une liste tenue à jour des serveurs de messagerie publiés par Google, y compris les serveurs alternatifs. Une comparaison limitée aux cibles se terminant par « aspmx.l.google.com » peut manquer des configurations Google valides.
Une recherche MX permet-elle de savoir si Google Workspace est payant ?
Non. Une recherche MX identifie le service de messagerie qui gère un domaine, mais ne permet pas de distinguer de façon fiable un compte Google Workspace payant d’un ancien hébergement gratuit Google Apps. Le résultat indique une « adresse e-mail hébergée par Google », et non la preuve d’un compte payant. Si cette distinction compte pour une décision, il est possible de demander confirmation au client ou de vérifier l’information à partir d’une autre source qu’il a autorisée.
Comment la règle doit-elle traiter un domaine sans enregistrement MX ou une recherche DNS qui échoue ?
Distinguez « aucun enregistrement MX » de « échec de la recherche DNS ». Un domaine sans enregistrement MX peut encore recevoir des e-mails grâce à un enregistrement d’adresse de repli. En revanche, un délai d’attente dépassé ou une erreur du résolveur signifie que le fournisseur est inconnu. En cas d’échec, renvoyez un résultat distinct, par exemple « inconnu » ou « erreur de recherche », et définissez explicitement la façon dont la décision en aval doit le traiter.
Que tester avant de déployer la vérification des e-mails ?
Testez des domaines utilisant les cibles MX principales et alternatives de Google, un fournisseur autre que Google, plusieurs enregistrements MX, aucun enregistrement MX et un délai d’attente DNS dépassé. Vérifiez qu’un échec temporaire de recherche ne renvoie pas à tort un résultat définitif « pas Google ». Testez ensuite le point d’accès déployé avec les mêmes entrées et comparez ses réponses à celles du test de la version.
À quelle fréquence le service doit-il actualiser les résultats MX ?
Pour définir la durée de mise en cache, partez de la durée de vie de l’enregistrement DNS et évitez de conserver les résultats du fournisseur au-delà de cette période. Une durée de cache fixe et longue peut rendre la classification obsolète si un domaine change de fournisseur de messagerie. Si les requêtes sont fréquentes, mettez les réponses DNS en cache selon leur durée de vie et traitez séparément les échecs de recherche et les résultats en cache.
