oMailgw est un logiciel libre que je développe pour répondre à un besoin très concret : gérer, superviser et partager une ou plusieurs passerelles e-mail sortantes basées sur Postfix.
En pratique, c’est l’outil que j’utilise derrière mon offre de passerelle e-mail / relai SMTP : https://retzo.net/services/hebergement/passerelle-e-mail-relai-smtp/
L’idée est de proposer une brique libre et auto-hébergeable pour celles et ceux qui veulent :
- garder la main sur leur trafic sortant ;
- mutualiser une ou plusieurs passerelles ;
- donner de l’autonomie aux utilisateurs sur la lecture de leurs erreurs ;
- et mieux suivre la réputation / délivrabilité sans devoir tout relire à la main dans les logs. (c’est chouette grep mais quand il faut suivre les rebonds sur plusieurs serveurs ça fait beaucoup de grep… et trop de grep tue le grep)
Le besoin de départ
Quand on exploite une passerelle sortante Postfix, on a vite les mêmes problèmes :
- certains messages sont refusés ;
- d’autres sont différés ;
- des destinataires n’existent plus ;
- certaines plateformes acceptent puis classent mal ;
- on peut se retrouver blacklisté à force d’insister vers de mauvaises cibles ;
- et, côté utilisateurs, la compréhension de ce qui se passe est souvent très limitée.
Sur un petit service mutualisé, ça pose un problème classique : l’administrateur a les logs, mais l’utilisateur ne sait pas forcément pourquoi son trafic passe mal. À l’inverse, laisser tout le monde fouiller dans les logs du serveur n’est évidemment pas une solution.
oMailgw a été pensé pour faire le lien entre ces deux mondes :
donner une vision d’exploitation aux administrateurs, tout en ouvrant une partie de cette visibilité aux utilisateurs, avec des permissions adaptées.
Un projet pensé aussi dans un esprit d’entraide CHATONS
Le projet a aussi été imaginé avec une logique d’entraide entre petites structures, notamment dans un contexte proche de celui des CHATONS.
L’idée de fond est simple : plusieurs petites structures peuvent avoir intérêt à mutualiser du savoir-faire, du monitoring, voire une partie de leur infrastructure de sortie e-mail, tout en gardant chacune leur autonomie.
Dans ce type de scénario, oMailgw permet par exemple :
- de superviser plusieurs passerelles sortantes ;
- de suivre les erreurs par serveur, par domaine, par utilisateur ou par authentification SMTP ;
- de donner à chaque structure ou client une vue limitée à ce qui la concerne ;
- et, en cas de souci de réputation sur une IP, de mieux comprendre ce qui se passe avant de décider d’un basculement ou d’un rééquilibrage du trafic.
À quoi ressemble l’architecture
Le projet est découpé en trois briques principales :
- oMailgw API : le cœur applicatif, développé en PHP avec Laravel, avec stockage des données côté base SQL ;
- oMailgw UI : une interface web en HTML/JS, qui consomme l’API ;
- oMailgw CLI : un client installé sur une ou plusieurs passerelles utilisant Postfix, chargé de lire les logs et de remonter les informations à l’API via HTTP.
À qui ça s’adresse ?
Je vois plusieurs cas d’usage assez nets.
1. Le petit hébergeur / admin sys qui opère une ou plusieurs passerelles
Cas typique : on a un ou plusieurs Postfix sortants, on veut suivre les erreurs, la file d’attente, les comptes SMTP auth, les messages refusés, les domaines problématiques, et éviter de naviguer uniquement dans les logs système.
2. Le prestataire qui fournit un service de relai SMTP à ses clients
C’est le cas que j’ai chez Retzo : proposer un service de relai SMTP simple à intégrer, avec interface/API de suivi, et laisser les clients consulter leurs propres envois, erreurs et rapports.
3. Un collectif ou une fédération de petites structures
Dans un esprit proche des CHATONS, plusieurs structures peuvent vouloir partager des outils, de la supervision, voire des passerelles de sortie, tout en cloisonnant les accès.
Fonctionnalités principales
Aujourd’hui, oMailgw permet notamment :
- la consultation des logs de trafic e-mail sortant ;
- la recherche et le filtrage dans les logs ;
- la consultation du détail d’un message ;
- la visualisation des e-mails encore en file d’attente ;
- des permissions fines selon plusieurs critères, par exemple :
- expéditeur complet ;
- domaine expéditeur ;
- authentification SMTP ;
- serveur source ;
- la gestion des authentifications SMTP ;
- la gestion de
transport_map(permet de rediriger une partie du trafic vers l’une ou l’autre des passerelles selon sa réputation) ; - la gestion de blacklists manuelles ;
- des mécanismes d’auto-blacklist (FBL, User Unknown revenu au moins 3 fois…) ;
- des rapports périodiques par e-mail ;
- des statistiques sur le trafic et les erreurs ;
- l’export CSV des logs ;
- une interface différenciée selon les rôles (
root,admin,user,mailgw).
L’un des points auxquels je tenais était l’autonomie utilisateur :
un utilisateur qui envoie réellement via la passerelle peut se créer un compte et consulter uniquement ce qui le concerne, au lieu de dépendre d’une lecture manuelle côté admin.
Ce que la version 1.0 apporte
La 0.9 posait déjà bien les bases, mais la 1.0 marque un cap plus net côté exploitation.
Qualification des bounces
Le gros travail a porté sur la manière de qualifier les erreurs.
Au lieu d’avoir seulement des messages SMTP bruts parfois difficiles à exploiter, la 1.0 introduit une qualification plus homogène :
successsofthardunknown
et ajoute des raisons normalisées exploitables côté API, statistiques, dashboard et rapports.
L’objectif est simple : mieux distinguer, par exemple :
- une erreur temporaire ;
- une boîte inexistante ;
- un rejet pour suspicion de spam ;
- un refus lié à la réputation ;
- ou un cas plus ambigu qui demande une analyse.
Intégration des FBL
Autre point important : la prise en charge des Feedback Loops (FBL), donc des plaintes remontées quand un destinataire marque un message comme abusif / indésirable.
Dans oMailgw 1.0, ces plaintes peuvent être récupérées via IMAP, intégrées à l’outil, puis relayées par notification aux administrateurs autorisés.
Pour moi, c’est un vrai progrès : on ne regarde plus seulement les messages non délivrés, on commence aussi à voir plus clairement les messages mal reçus.
Rapports plus lisibles
Les rapports périodiques ont été revus :
- rendu HTML plus propre ;
- seuils visuels pour repérer plus vite les zones problématiques ;
- ajout de rapports autour des blacklists et du spool ;
- personnalisation par utilisateur.
Chaque utilisateur peut désormais mieux définir ce qu’il considère comme une erreur dans ses rapports, avec notamment la possibilité d’inclure ou non les soft bounces dans les statistiques.
Interface plus orientée exploitation
La 1.0 apporte aussi :
- une administration des utilisateurs réellement finalisée côté
root-panel; - un dashboard plus modulaire ;
- des raisons de bounce visibles dans davantage de vues ;
- l’export CSV ;
- une meilleure cohérence entre front et back sur les libellés et le calcul des taux d’erreur.
Démo, code source, documentation
Démo :
Forge / code source :
- https://framagit.org/omailgw
- https://framagit.org/omailgw/omailgw
- https://framagit.org/omailgw/omailgw-api
- https://framagit.org/omailgw/omailgw-cli
Plus d’image :
Service utilisant oMailgw :
Annonce de la version 1.0 :
Quelques remarques sur l’état du projet
Le projet m’est d’abord utile à moi, dans un contexte réel d’exploitation.
C’est sans doute aussi ce qui lui donne sa forme actuelle : il ne cherche pas à couvrir tout le champ de l’e-mail, mais à répondre à des besoins concrets de supervision de passerelles sortantes.
La 1.0 ne veut pas dire “projet terminé”, mais plutôt : le socle est là, les usages réels aussi, et l’outil commence à devenir suffisamment cohérent pour être présenté plus largement.
