Nous exécutons le courrier. Envoi transactionnel sortant et en vrac via des instances séparées Postfix, envoi entrant via son propre, boîtes aux lettres sur Dovecot, filtrage et notation via Rspamd.L'identité de l'expéditeur est vérifiée par rapport au DNS en direct avant qu'un message ne puisse revendiquer le domaine d'un client.
| Mesure | Valeur | Source | Mesurées |
|---|---|---|---|
| Composants de courrier en production | 5 (Postfix outbound, Postfix bulk, Postfix inbound, Dovecot, Rspamd) | kubectl get deployments -n mail | |
| Envoi de chemins séparés par classe de réputation | 2 (transactional and bulk, on distinct instances) | kubectl get deployments -n mail | |
| Vérifications du domaine de l'expéditeur effectuées avant qu'un envoi ne soit autorisé | 2 (domain ownership proven by DNS record, and SPF authorisation verified live) | transactional sender-identity resolution in the email service |
Quel bâtiment il nous a appris
Quand un email marketing n’arrive pas, l’outil de campagne le signale comme envoyé. C’est techniquement vrai et complètement inutile. Le message a été accepté pour la livraison et ensuite abandonné, reporté ou classé comme spam par un système de réception selon des règles que l’outil de campagne ne peut pas voir et que son fournisseur n’expliquera pas. C’est l’échec inexpliqué le plus commun dans le marketing numérique, et une agence qui ne dispose que d’un outil de campagne n’a aucun moyen de l’enquêter.
Nous séparons l’envoi en vrac de l’envoi transactionnel afin qu’une newsletter ne puisse pas nuire à la réputation dont dépendent les réinitialisations de mot de passe. Nous vérifions, par rapport au DNS en direct au moment de l’envoi, si un domaine a vraiment été prouvé comme appartenant au locataire qui le revendique et si son enregistrement SPF nous autorise réellement — et si cette recherche échoue, nous n’enregistrons pas de verdict plutôt que de deviner, car une conjecture ici envoie un courrier qui échoue à l’authentification et apprend aux systèmes de réception à ne pas faire confiance au domaine.
Nous avons une fois perdu une classe de message entrant parce qu’un webhook a publié des données encodées dans un formulaire et que le gestionnaire a essayé de l’analyser en tant que JSON, renvoyant un joyeux 200 tout en rejetant le contenu. Trois gouttes silencieuses distinctes existaient sur ce chemin. Rien n’a alerté, car tout a signalé un succès. Les systèmes qui échouent en réussissant sont les plus difficiles à trouver et c’est la raison pour laquelle nous instrumentons les chemins d’ingestion obsessionnellement sur le travail du client.
Il y a une limite de connexion qui mérite d'être mentionnée aussi, car c'est le genre de détail qui apparaît seulement sous charge réelle : un serveur de messagerie permet un nombre limité de connexions simultanées par utilisateur et par adresse, par processus, si vous dépassez ce nombre, les choses cessent de fonctionner de manière à ressembler à des échecs d'authentification. La planification de la capacité pour le courrier est une véritable ingénierie, et presque personne n'y consacre de budget.
Construit avec
- Postfix
- Dovecot
- Rspamd
- SPF
- DKIM
- DMARC
- IMAP
- Java
- Spring Boot
Dites-nous ce que vous essayez de faire
Une courte conversation est généralement suffisante pour savoir si nous sommes les bonnes personnes, si nous ne le sommes pas, nous le dirons et vous indiquerons quelque part mieux.