Développeurs

Hébergement e-mail pour développeurs : des boîtes à vous

Le courrier de votre domaine est vérifié et chiffré, puis écrit dans votre cloud Tout expéditeur Routage et filtrage SPF · DKIM · DMARC Chiffré par boîte Votre compte cloud S3 R2 WebDAV Git Le compte de votre infra

Deux produits différents répondent à « e-mail pour développeurs ». L’un envoie du courrier depuis votre application — SES, Postmark, Resend, cent autres — et ne veut surtout pas le garder. Cet article parle de l’autre : la boîte qu’un humain lit, sur un domaine qui vous appartient, avec l’archive posée dans un stockage que vous payez déjà.

Voulez-vous un hébergement e-mail ou une API d’envoi ?

Si c’est du code qui envoie le message, vous voulez une API. Si c’est une personne qui le lit, vous voulez un hébergement. Ce ne sont ni des substituts ni des concurrents : les prestataires transactionnels existent pour remettre du courrier et en rendre compte, les hébergeurs de boîtes existent pour recevoir le courrier, le conserver et vous laisser le chercher. La plupart d’entre nous ont besoin des deux, sur des adresses différentes du même domaine.

Tout ce qui suit concerne le second cas. Nisdos Mail exploite le MX de votre domaine, authentifie et filtre le courrier entrant, chiffre chaque message avec une clé propre à la boîte et l’écrit dans votre bucket S3, votre bucket R2, votre serveur WebDAV ou votre dépôt Git.

Que veulent les développeurs qu’une suite facturée au siège ne leur donne pas ?

Trois choses, et davantage de stockage n’en fait pas partie.

Une adresse par chose, pas par personne. Une suite facturée par utilisateur vous pousse vers une identité unique et une arborescence de dossiers. Des adresses illimitées sur votre propre domaine laissent le routage faire le travail : stripe@, alerts-staging@, receipts@, une adresse par compte fournisseur, une par projet. Quand un service laisse fuir sa liste, le spam arrive sur l’adresse que vous avez donnée à ce service et nomme la source dans son propre en-tête To:. Quand un projet s’arrête, vous supprimez un canal au lieu de démêler des filtres.

Du stockage dans le compte qu’ils rapprochent déjà. Si votre infrastructure tient dans un compte cloud avec une facture, une histoire IAM et une politique de sauvegarde, le courrier est l’exception bizarre : le quota opaque d’un fournisseur, avec un bouton d’export. Pointer les boîtes vers un bucket de ce même compte fait obéir le courrier aux règles que vous avez déjà écrites — versionnage, cycle de vie, réplication, journaux d’accès.

Une facture qui suit les données, pas les effectifs. Les offres au siège ont du sens pour une société de salariés et aucun pour un développeur seul avec quatre projets, huit adresses de rôle et un robot de build. Chez Nisdos Mail, utilisateurs, alias et domaines sont illimités dans des conditions d’usage raisonnable ; le compteur, c’est le stockage, à $2 par 25 GB et par mois si nous l’hébergeons, ou au tarif de votre fournisseur si vous apportez votre bucket. Le stockage hébergé dans l’UE ajoute $1 par 25 GB.

Pourquoi une adresse par projet vaut-elle mieux qu’un filtre ?

Parce qu’une adresse est un fait sur l’expéditeur, tandis qu’un filtre est une supposition sur le courrier. Les filtres cassent quand un fournisseur change son domaine d’envoi. Une adresse inventée pour un seul usage garde son sens aussi longtemps que cet usage existe, et elle échoue bruyamment plutôt qu’en silence : le courrier destiné à alerts-staging@ ne peut pas finir au mauvais endroit parce que quelqu’un a modifié une règle.

Elle vous donne aussi une frontière d’isolement révocable. Une adresse par compte fournisseur signifie qu’un compte fournisseur compromis se retrace à une adresse et se tue en supprimant cette adresse, sans toucher à l’identifiant de quoi que ce soit d’autre. C’est le même réflexe qu’une clé d’API distincte par service, appliqué à l’identité avec laquelle vous vous inscrivez.

Pouvez-vous faire un grep dans votre archive ?

Aux conditions que vous choisissez, parce que le chiffrement est un réglage par boîte et non un réglage à l’échelle du produit. Pointez une boîte vers un dépôt Git et l’archive arrive sous forme de fichiers sous contrôle de version, avec l’historique que cela implique : une boîte d’alertes ou de reçus devient un répertoire que vous cherchez avec les outils que vous passez déjà sur vos logs. Une boîte sur l’offre chiffrée est opaque à grep par conception, ce qui est exactement ce que vous voulez pour du courrier personnel. Le point, c’est que les deux boîtes ne sont pas obligées de faire le même choix.

Dans le webmail, la recherche accepte les opérateurs que vous tapez déjà : from:, has:attachment, newer:7d, in:anywhere, avec navigation au clavier et des étiquettes qui se comportent comme des dossiers.

Faut-il plutôt faire tourner Postfix et Dovecot ?

Parfois oui — si vous exploitez déjà du courrier pour d’autres et que le muscle existe, l’auto-hébergement vous donne tout, sans aucun fournisseur sur le chemin.

Pour tous les autres, l’estimation est fausse d’une façon précise. Monter Postfix, Dovecot, Rspamd et un renouvellement de certificat, c’est un week-end, et ce n’est pas le travail. Le travail, c’est la décennie qui suit : surveillance des listes de blocage, reverse DNS, chauffe d’adresse IP, renouvellements TLS qui échouent un jour férié, règles antispam qui se périment, et l’après-midi où un grand destinataire commence discrètement à classer votre domaine en spam sans que rien dans vos journaux dise pourquoi. La délivrabilité sortante se décide dans les systèmes de réputation des autres, et une IP neuve sur un petit bloc n’a pas droit à un procès équitable, quelle que soit la justesse de votre configuration.

L’hébergement BYOS scinde la pile dans l’autre sens : quelqu’un d’autre porte le problème de réputation, vous portez les octets. Si ce que vous vouliez de l’auto-hébergement était la garde des données et non le démon, c’est l’échange proposé.

Qu’est-ce qui manque, honnêtement ?

À savoir avant de déplacer un domaine.

Clients : le webmail aujourd’hui, avec une passerelle IMAP toujours annoncée comme à venir — un flux de travail en terminal n’est pas là. Périmètre : le courrier seulement, donc pas d’agenda, pas de drive, pas d’annuaire partagé, et une équipe qui quitte Workspace continue de payer Workspace pour le reste. Envoi : limité en débit pour tenir la plateforme à l’écart des listes noires, à partir de 10 messages par heure sur un compte gratuit et jusqu’à 50 au fil des 30 premiers jours, chaque 25 GB de stockage payant ajoutant 50 de plus par heure. Clés : sur l’offre par défaut nous détenons les clés par boîte pour que la boîte s’affiche dans un navigateur ; l’offre où nous ne pouvons pas lire votre courrier du tout est en bêta. Statut : accès anticipé, ce qui est une vraie réponse à « est-ce que cela peut porter le courrier de ma société le trimestre prochain », et la réponse est « amenez d’abord un projet perso ».

L’hébergement e-mail pour développeurs est une petite catégorie surtout parce que la plupart des développeurs ont renoncé et pointé un domaine personnalisé vers Gmail. Cela marche très bien. Cela veut juste dire que l’archive appartient à Google, que le nombre d’adresses est une limite d’offre, et que la facture grossit avec votre équipe au lieu de vos données.

Questions fréquentes

Quel est le meilleur hébergement e-mail pour un développeur ?

Cela dépend du problème que vous avez. Si c’est une application qui envoie le courrier, il vous faut un prestataire transactionnel avec une API et des webhooks. Si c’est un humain qui lit le courrier, il vous faut des boîtes hébergées sur votre propre domaine, avec des adresses illimitées et une archive que vous contrôlez — ce que fournit un hébergement BYOS comme Nisdos Mail, qui écrit chaque message dans votre stockage S3, R2, WebDAV ou Git.

Un hébergement e-mail pour développeurs, est-ce la même chose qu’une API d’envoi ?

Non, et les confondre fait rater une migration. Une API d’envoi (SES, Postmark, Resend et compagnie) existe pour expédier du courrier depuis du code et ne garde délibérément pas votre boîte. Un hébergement exploite le MX de votre domaine, reçoit le courrier, le stocke et vous donne un client pour le lire. La plupart des développeurs finissent par avoir besoin des deux, sur des adresses différentes.

Puis-je utiliser mon propre bucket S3 pour mes boîtes aux lettres ?

Oui. Nisdos Mail rattache S3, un stockage objet compatible S3, un WebDAV ou un dépôt Git par domaine ou par boîte, et chaque message est compressé et chiffré avec une clé propre à la boîte avant d’être écrit. Vous gardez les octets et payez directement votre fournisseur de stockage pour ce qu’il stocke.

Un hébergement e-mail pour développeurs doit-il se facturer par utilisateur ?

Non — la facturation au siège est un modèle économique, pas une contrainte technique. Workspace et Microsoft 365 facturent par utilisateur et par mois parce qu’ils vendent à des sociétés qui ont des salariés. Nisdos Mail laisse utilisateurs, alias et domaines illimités dans des conditions d’usage raisonnable et compte le stockage à la place : $2 par 25 GB et par mois en hébergé, plus $1 par 25 GB pour un stockage dans l’UE, ou rien du tout chez nous si vous apportez votre bucket.

Peut-on lire les boîtes en IMAP ?

Le webmail est le client d’aujourd’hui. Une passerelle IMAP est annoncée comme à venir pour l’offre de chiffrement à garde côté appareil : un flux de travail mutt ou Thunderbird n’est donc pas encore quelque chose sur quoi bâtir un plan — vérifiez l’état courant avant de migrer un domaine dont vous dépendez.