Mailrelay transforme les e-mails entrants en webhooks pour l'automatisation auto-hébergée

Le 24 octobre 2026, le développeur gowthamgts a publié mailrelay, un serveur de réception d'e-mails open-source conçu pour combler le fossé entre les protocoles de messagerie traditionnels et l'automatisation moderne basée sur HTTP. Cette solution auto-hébergée permet aux utilisateurs de recevoir des e-mails, d'analyser leur contenu et de déclencher des webhooks selon des règles spécifiques, facilitant ainsi l'intégration transparente avec les services homelab et les outils pour petites entreprises qui ne prennent pas en charge nativement l'ingestion d'e-mails.

Ce qui s'est passé

Cette version introduit un serveur SMTP léger écrit en Go qui agit comme relais pour les messages entrants. Au lieu de stocker les e-mails dans une boîte aux lettres traditionnelle destinée à la lecture humaine, mailrelay évalue chaque message contre des conditions définies par l'utilisateur et transmet les données aux URL de webhook spécifiées. Le système est conçu pour être résilient ; il accuse réception d'un e-mail immédiatement avec une réponse 250 OK, tandis que la livraison réelle du webhook se fait de manière asynchrone en arrière-plan. Cela garantit que les échecs temporaires ou les réponses lentes des services en aval n'entraînent pas le rejet de l'e-mail original.

Le projet propose plusieurs options de déploiement adaptées à différentes préférences d'infrastructure. Les utilisateurs peuvent l'exécuter via Docker, où l'interface web est activée par défaut, ou sous forme de binaire autonome compilé depuis les sources. L'application stocke toutes les données opérationnelles, y compris une base de données SQLite, les fichiers bruts .eml et les paramètres de configuration, dans un seul répertoire /data. Cette structure simplifie les sauvegardes et la migration pour les hébergeurs autonomes qui préfèrent une gestion minimale des dépendances. Un fichier Docker Compose de démarrage rapide est disponible pour aider les utilisateurs à tester la fonctionnalité avec un serveur echo d'exemple avant de le connecter à des services réels.

Détails clés

• Routage basé sur des règles : Les utilisateurs peuvent créer des règles dans l'interface web qui correspondent aux e-mails en fonction de champs tels que From, To, Subject, Body, les en-têtes ou les adresses d'enveloppe SMTP. Les motifs prennent en charge les globs et les expressions régulières.
• Livraison asynchrone avec tentatives : Les webhooks sont envoyés en arrière-plan avec un backoff exponentiel. Chaque tentative est enregistrée, et les livraisons échouées peuvent être rejouées manuellement depuis l'interface.
• Sécurité par défaut : Par défaut, les webhooks ne peuvent pas atteindre les réseaux privés, localhost ou les points de terminaison de métadonnées cloud. Cette restriction peut être levée via des variables d'environnement pour l'intégration de services internes.
• Prise en charge de l'authentification : L'interface web prend en charge les fournisseurs OpenID Connect (OIDC) tels que Google, Okta et Authentik pour un accès sécurisé, bien que la connexion GitHub ne soit pas prise en charge en raison de limitations du protocole.
• Formatage flexible des charges utiles : Les webhooks reçoivent du JSON analysé par défaut, mais les utilisateurs peuvent personnaliser la sortie à l'aide de modèles Go avec des fonctions pour joindre des listes ou définir des valeurs de repli.
• Vérification des e-mails : Le serveur effectue des vérifications SPF, DKIM et DMARC, avec des options pour journaliser ou appliquer ces politiques. Il vérifie également les en-têtes ARC pour préserver les résultats d'authentification des e-mails transférés.

Contexte

Pendant de nombreuses années, l'intégration des e-mails dans les flux de travail automatisés nécessitait des intergiciels complexes ou la dépendance à des plateformes SaaS tierces. Les serveurs SMTP traditionnels sont conçus pour la communication humaine, stockant les messages dans des boîtes aux lettres plutôt que de déclencher l'exécution de code. À l'inverse, les webhooks sont la norme pour la communication machine-à-machine, permettant aux applications d'envoyer des données en temps réel via HTTP. Mailrelay comble ce fossé en agissant comme un point de terminaison SMTP qui traduit les événements e-mail en requêtes HTTP.

Cette approche est particulièrement précieuse pour les environnements auto-hébergés où la confidentialité et le contrôle sont prioritaires. Au lieu d'accorder à un service cloud l'accès à des alertes financières sensibles ou à des tickets de support, les organisations peuvent maintenir l'ensemble du pipeline au sein de leur propre réseau. L'outil gère les complexités de l'analyse des e-mails, y compris l'extraction des pièces jointes et l'analyse des en-têtes, présentant les données dans un format JSON propre que les applications modernes peuvent facilement consommer.

Pourquoi c'est important

Les équipes qui exécutent leurs propres logiciels ont souvent du mal à connecter les notifications basées sur les e-mails héritées avec les tableaux de bord modernes et les outils d'automatisation. Par exemple, les alertes bancaires, les notifications d'expédition ou les e-mails de surveillance système atterrissent généralement dans une boîte de réception, nécessitant une intervention manuelle pour agir. Mailrelay permet à ces messages de déclencher automatiquement des actions dans des outils comme Home Assistant, Paperless-ngx ou des API personnalisées. Cela réduit la charge de travail manuelle et garantit que les informations critiques sont traitées immédiatement sans délai humain.

De plus, la capacité de rejouer les webhooks est un avantage opérationnel significatif. Dans les systèmes distribués, les pannes réseau ou les redémarrages de services peuvent entraîner l'échec des livraisons de webhooks. Sans mécanisme de nouvelle tentative, ces événements sont perdus à jamais. Mailrelay enregistre chaque tentative et permet aux administrateurs de renvoyer des e-mails spécifiques depuis l'interface utilisateur, assurant la cohérence des données. La posture de sécurité par défaut, qui bloque l'accès aux réseaux privés sauf autorisation explicite, protège également contre l'exposition interne accidentelle lors de la configuration de services exposés à l'extérieur.

Ce que vous pouvez faire

• Déployez la pile Docker Compose de démarrage rapide pour tester localement le listener SMTP et le serveur echo de webhook.
• Configurez smtp.allowed_recipients pour restreindre le serveur à n'accepter que les e-mails destinés à vos domaines ou adresses spécifiques.
• Mettez en place une authentification OIDC pour l'interface web en utilisant des fournisseurs comme Authentik ou Keycloak pour sécuriser l'accès administratif.
• Utilisez des modèles Go dans la configuration des règles pour supprimer les en-têtes inutiles et réduire la taille de la charge utile envoyée à vos services en aval.
• Activez webhook.allow_private_networks uniquement si vos services d'automatisation cibles résident sur le même réseau local ou pont Docker.
• Surveillez le point de terminaison /metrics avec Prometheus pour suivre le volume d'e-mails, les taux de réussite des webhooks et les comptages de nouvelles tentatives.