Des messages qui arrivent

Un message de bienvenue, envoyé une seule fois lors du premier usage d’un compte, et un avis à la personne avec qui un document a été partagé.

Les deux ont demandé trois tentatives. L’avis était branché sur un point d’entrée que l’application n’appelle jamais, puis déclenché après la réponse, si bien que la requête ne quittait jamais la fonction, puis bloqué par une clé réellement absente des premières compilations. La délivrabilité, elle, réclamait DMARC et pas seulement SPF et DKIM.

Le courrier d’un produit est surtout une chose dont il faut se méfier, alors disons combien il y en a peu ici. Deux messages : une bienvenue, au premier usage réel d’un compte, et un avis à la personne avec qui un compte a partagé un document. Pas de résumés, pas d’actualités du produit, rien dont il faille se désabonner.

Pourquoi ils n’arrivaient pas

Trois défauts, l’un après l’autre. L’avis a d’abord été branché sur un point d’entrée que l’application n’appelle jamais. Il a ensuite été corrigé pour partir une fois la réponse rendue — ce qui vient naturellement à l’écriture et se révèle faux dans une fonction serverless, car la plateforme peut geler l’instance à l’instant où une réponse part, et une requête qui n’est pas encore sortie ne sort jamais. Trois adresses ont été ajoutées sur un déploiement en service et le fournisseur de courrier n’a rien consigné : pas un échec, une absence.

Un envoi fait donc désormais partie de la requête qui l’a déclenché, et il est attendu, avec un délai de quatre secondes : un fournisseur qui passe une mauvaise minute ne transforme pas un partage en partage lent. Le troisième défaut était plus terne : la clé manquait vraiment dans les premières compilations.

Pourquoi ils partaient en indésirables

SPF et DKIM étaient en place depuis le début et n’ont jamais été le problème. Ce qui manquait, c’était DMARC — l’entrée DNS qui dit ce qu’un destinataire doit faire du courrier qui échoue aux deux autres — et un domaine jeune qui envoie du courrier automatique sans elle est traité durement. C’est du DNS et non du code, ce qui explique en partie les trois tentatives.

Ce que le code peut faire, c’est ne rien aggraver. Les deux parties MIME plutôt que du texte seul, car un message automatique tout en texte venant d’un domaine sans historique est ce dont un filtre se méfie le plus. Un objet qui commence par le nom du document au lieu d’une adresse nue à côté d’un nom de fichier entre guillemets, une paire dont les filtres connaissent la forme. Et un Reply-To pointant vers la personne qui a partagé, car un message auquel on ne peut pas répondre se lit comme de la machinerie.

Ce que ces messages ne sont pas

Ni images ni pixel de suivi ; la partie HTML reprend les mots de la partie texte, mise en forme par le convertisseur du produit lui-même. Le nom d’un document est imprimé dans une portion de code, si bien qu’un fichier nommé [Confirm your account](https://elsewhere.example) arrive comme du texte et non comme un lien vivant dans un message portant notre signature. Un déploiement sans clé n’envoie rien et ne dit rien, et un partage réussi n’est jamais annoncé comme échoué parce que le courrier l’a été. Tout cela est en anglais quelle que soit votre langue : cela part vers une adresse dont nous ne savons rien d’autre.

Autres lectures : partager un document sous forme de lien et si un convertisseur en ligne est sûr.