Des comptes de test illimités sur un domaine catch-all

Pourquoi un fournisseur de messagerie n’est pas la bonne forme pour la QA

Toutes les façons de donner des adresses e-mail à une suite de tests ont été essayées, et chacune fuit à un endroit différent :

La quatrième ligne, c’est ce guide. C’est le même mécanisme sur lequel tournent les domaines jetables publics — un serveur qui accepte chaque adresse sur un domaine plutôt qu’une liste de boîtes — appliqué à un nom que personne d’autre que vous n’utilise.

L’unique enregistrement DNS

Chez votre fournisseur DNS, ajoutez un seul enregistrement MX à la racine d’un domaine que vous possédez. Aucun autre enregistrement ici, aucun TXT pour prouver quoi que ce soit, aucun compte sur ce site :

Enregistrement MX pour le domaine10 smtp.grabmail.ioCopier

1. Publiez le MX. Priorité 10, pointant vers smtp.grabmail.io. Supprimez tout autre MX sur le domaine — le courrier ne peut être livré qu’à un seul endroit, et un enregistrement résiduel en envoie une partie ailleurs.
2. Attendez le DNS. Généralement quelques minutes ; parfois le TTL de l’enregistrement qui était là avant. dig MX qa-example.com montre quand le changement a pris effet.
3. Envoyez un message à n’importe quelle adresse dessus. C’est la première livraison qui connecte le domaine : le serveur consulte le MX à ce moment-là, s’y reconnaît, et accepte. À partir de là, chaque adresse du domaine est une boîte.

Un schéma de nommage qui dit qui a créé la boîte

Avec chaque adresse valide, la partie locale est libre de porter de l’information — et à deux heures du matin, avec une exécution échouée et une boîte ouverte, vous voudrez qu’elle le fasse. Trois parties, jointes par des tirets, dans cet ordre :

// one helper, every runner: who made it, which run, and eight random characters
export const testAddress = (who: string, run = process.env.GITHUB_RUN_ID ?? 'local') =>
  `${who}-${run}-${crypto.randomUUID().slice(0, 8)}@qa-example.com`;

testAddress('signup');        // signup-1234567890-3f9a1c2e@qa-example.com

Lire n’importe quelle adresse, avec les trois mêmes appels

Rien dans l’API ne change pour votre propre domaine. Le même appel de listage, le même appel de message, la même suppression — aucune clé sur le palier public, et le domaine dans l’adresse est la seule chose qui diffère :

$ curl -sG https://grabmail.io/api/v1/mailbox --data-urlencode "address=signup-1234567890-3f9a1c2e@qa-example.com"

Ce qui signifie que chaque utilitaire de ce site fonctionne sans changement après la modification d’une seule constante : la fixture Playwright, la tâche Cypress, les modules Python et Node. Trois choses méritent d’être connues, auxquelles les domaines publics ne vous font pas penser :

Un 404 signifie que le MX n’est pas encore là

Le listage répond 404 pour un domaine qui n’est pas hébergé ici. Sur votre propre domaine, c’est un problème DNS — l’enregistrement ne s’est pas propagé, ou pointe ailleurs — pas un problème d’API. dig MX d’abord.

L’alias fonctionne aussi sur votre domaine

Chaque boîte, sur n’importe quel domaine, a une seconde adresse sur un domaine séparé, qui livre dedans et ne peut pas la lire. Donnez-la à un site quand vous préférez qu’il ne puisse pas ouvrir la boîte ; interrogez votre propre adresse.

Une adresse chargée se pagine

Une adresse catch-all qui collecte des bounces ou une journée de notifications peut contenir plus d’une page de 200. Repassez next comme before jusqu’à ce qu’il vaille null.

Garder un domaine de test utilisable

Un domaine qui vous appartient ne figure sur aucune liste noire de mail jetable, ce qui est souvent la raison même d’en utiliser un : l’application testée refuse grabmail.io et tout autre domaine public, exactement comme elle le devrait. Quatre habitudes le maintiennent ainsi :

• Utilisez un domaine dédié — qa-example.com, pas un sous-domaine de production, pas le domaine auquel écrivent les clients. Le service n’accepte que des domaines enregistrables (example.com, jamais mail.example.com), et un domaine de test ne devrait avoir aucun autre rôle.
• Ne le publiez pas. Les listes sont constituées à partir de ce qui apparaît sur les sites de mail jetable publics et dans les listes d’adresses partagées. Un domaine qui n’apparaît jamais que dans votre propre suite de tests n’a aucun moyen d’y figurer.
• Verrouillez-le avec SPF et DMARC. Un domaine qui ne fait que recevoir, sans SPF, est un domaine depuis lequel n’importe qui peut usurper du courrier ; deux enregistrements referment cette faille, et ne coûtent rien.
• N’y faites pas pointer du vrai courrier. Dès l’instant où un système de staging envoie des notifications client vers une adresse catch-all, une boîte publique contient des données client. Les domaines de test transportent du courrier de test.

Si l’application refuse tous les domaines catch-all — certains contrôles anti-fraude le font, en sondant si une adresse aléatoire sur le domaine est acceptée — il existe un pool payant de domaines .com à l’apparence ordinaire, tenus à l’écart des listes, décrit sur la page tarifs. Pourquoi les formulaires d’inscription bloquent le mail jetable explique ce que voit chaque type de contrôle.

Pour une équipe : un domaine, plusieurs testeurs, plusieurs pipelines

Un seul domaine catch-all sert tout le monde, parce que la partie locale est la seule chose qui doit différer, et elle est gratuite. Ce dont une équipe a besoin, c’est d’un accord sur le nommage ci-dessus et trois petites conventions :

Un préfixe par pipeline et par personne

e2e-, nightly-, alice-. Rechercher le préfixe dans un journal de job retrouve chaque boîte qu’il a créée ; rechercher celui d’un collègue retrouve le bug qu’il examine.

Rien de partagé, jamais

Il n’y a pas de « boîte d’équipe » sur le domaine, ni de fixture qui distribue une adresse fixe. Si deux personnes ont besoin de la même boîte, l’une envoie l’adresse à l’autre.

Les limites de débit sont par client

Une lecture par seconde par adresse, 1200 requêtes par minute par client — un runner de CI est un client, un ordinateur portable en est un autre. Une équipe de dix personnes qui exécutent des suites en même temps, ce sont dix clients, pas un seul.

Les limites qui s’appliquent

Votre propre domaine reçoit le même service que les domaines publics, avec les mêmes plafonds. Aucun n’est ajustable, et aucun n’est un problème pour une suite de tests :

Avant de considérer que c’est terminé

• Un domaine enregistrable dédié, avec un seul enregistrement MX : 10 smtp.grabmail.io, et aucun autre MX.
• Un message envoyé à n’importe quelle adresse dessus, et relu via l’API.
• SPF et DMARC publiés, pour que personne ne puisse envoyer en se faisant passer pour le domaine.
• Un utilitaire de nommage — qui, quelle exécution, huit caractères aléatoires — utilisé par chaque suite.
• Le domaine conservé dans la configuration d’environnement, jamais dans le code, les captures d’écran ou les tickets.
• Rien de ce qui envoie du vrai courrier client ne pointe vers lui.

À partir de là, les suites sont celles déjà écrites : Playwright avec le domaine dans sa fixture, la discipline indépendante du runner, et le workflow GitHub Actions avec le domaine dans une variable.

Questions