oMailgw, le logiciel open source développé pour le service de passerelle e-mail / relai SMTP de retzo.net, passe en version 1.0.
Derrière ce chiffre un peu symbolique, l’idée est simple : le projet sort d’une phase où il était déjà fonctionnel, mais encore en construction permanente, pour entrer dans une phase plus aboutie, plus cohérente.
- Le service de relai/passerelle SMTP
- Démonstration de l’interface
- Changelog API, UI
- Code source du projet
L’objectif ne change pas : aider à comprendre ce qui se passe réellement sur le trafic e-mail sortant, pour mieux suivre la délivrabilité, repérer les problèmes, et agir avant d’abîmer la réputation d’envoi.
Mieux comprendre pourquoi un e-mail n’arrive pas
Le gros travail de cette version 1.0 porte sur la qualification des erreurs.
Quand un e-mail est refusé, mis en attente, ou rebondit, on se retrouve souvent avec des messages SMTP pas toujours simples à lire. Pour un administrateur système, cela demande du temps. Pour un utilisateur, c’est souvent complètement opaque.
Avec cette version, oMailgw va plus loin dans la normalisation et la restitution des raisons de bounce. L’idée est de ne plus avoir seulement un message technique brut, mais une raison plus claire, plus homogène, et donc plus exploitable dans l’interface, les statistiques et les rapports.
Concrètement, cela permet de mieux distinguer :
- les erreurs temporaires ;
- les erreurs définitives ;
- les refus liés à la réputation ou au filtrage ;
- les boîtes inexistantes ;
- les rejets assimilables à du spam ;
- et d’autres cas qui, jusque-là, demandaient souvent une lecture “à la main” des logs.
Les rapports deviennent plus lisibles, et plus utiles
Autre gros morceau de cette version : les rapports envoyé par e-mail.
Ils ont été revus pour être plus agréables à lire, avec un rendu HTML plus propre, des seuils visuels, et surtout davantage de personnalisation. Le but n’était pas simplement de faire “plus joli”, mais de rendre l’information plus compréhensible d’un coup d’œil.
Chaque utilisateur peut maintenant mieux choisir ce qu’il considère comme une vraie erreur dans ses rapports. Par exemple, il devient possible d’inclure ou non certains soft bounces dans les statistiques et dans les alertes, selon le contexte.
C’est important parce qu’un administrateur de plateforme et un utilisateur final n’ont pas toujours la même lecture d’un incident. L’un veut une vue large pour piloter la qualité du trafic ; l’autre veut surtout savoir ce qui bloque concrètement ses envois.
Un vrai plus autour des FBL
Le point le plus marquant de cette version 1.0, à mes yeux, c’est la prise en charge des FBL.
Pour simplifier : certains fournisseurs remontent des plaintes quand un destinataire signale un message comme abusif ou indésirable. Ces remontées, appelées Feedback Loops, sont précieuses pour comprendre qu’un trafic pose problème, même quand les logs SMTP ne suffisent pas à le montrer clairement.
oMailgw sait désormais intégrer ces plaintes, les faire remonter proprement, et notifier les administrateurs autorisés.
C’est un vrai gain pour l’exploitation du service, parce qu’on ne travaille plus uniquement à partir des rebonds classiques. On voit aussi mieux les signaux faibles de mauvaise qualité perçue côté destinataires.
Autrement dit : on ne suit pas seulement les e-mails non délivrés, on suit aussi mieux les e-mails mal reçus.
Côté administrateur
La version 1.0 renforce aussi la partie administration.
L’interface a été retravaillée, la gestion des utilisateurs est maintenant réellement intégrée côté root-panel, les rôles sont mieux exploités, et plusieurs vues ont été clarifiées, notamment autour des blacklists, du spool et du détail des messages.
Pour l’administration quotidienne, cela change plusieurs choses :
- une vision plus nette des incidents ;
- des raisons de bounce plus cohérentes d’un écran à l’autre ;
- une meilleure remontée des plaintes FBL ;
- des exports CSV depuis les logs ;
- et une base plus propre pour le suivi et le support.
Côté utilisateur
Je tenais aussi à ce que cette version améliore l’autonomie des utilisateurs.
Le principe du service reste le même : l’administrateur garde une vue d’ensemble, mais les utilisateurs peuvent accéder à leurs propres informations sans avoir à demander une analyse manuelle à chaque fois.
Avec la 1.0, cette autonomie progresse :
- les rapports sont plus lisibles ;
- les erreurs sont mieux qualifiées ;
- le tableau de bord est plus parlant ;
- et les préférences utilisateur permettent d’adapter un peu mieux la restitution à son besoin réel.
L’idée n’est pas de transformer tout le monde en expert de la délivrabilité, mais de rendre les problèmes un peu moins mystérieux.