oMailgw pour gérer ces passerelles sortantes

Bonjour à tous,

J’avais lancé un sujet [recherche] interface web pour relai SMTP sortante mais je n’avais pas trouvé chaussure à mon pied, alors j’ai commencé à m’y mettre, il reste beaucoup de travail mais voilà un premier jet : oMailgw

Cas d’usage

  • Infrastructure d’hébergement e-mail avec X passerelles e-mail de sorties (pour pouvoir jongler avec les IP en cas de blacklistage)
    • oMailgw permet à l’administrateur un suivi des logs, remonté d’erreurs, statistiques d’utilisation fines
  • Au sein d’un collectif de petit hébergeur (type C.H.A.T.O.N.S), pouvoir collectiviser X passerelles de sorties e-mails chez un ou plusieurs C.H.A.T.O.N.S. afin que chacun gère sa réputation e-mail mais qu’en cas de problème on puisse basculer chez les un(s) ou chez les autre(s) une partie du trafic le temps de retrouver une réputation IP viable.
    • il pourrait y avoir plusieurs oMailgw-UI (interface) pour plusieurs passerelles

Comment ça marche

  • Une interface (oMailgw-UI) qui reçoit les logs de différentes passerelles (oMailgw-cli) (mailgw - serveur de mail sortant) via API HTTP
  • L’utilisateur via l’UI peut voir les logs le concernant / des statistiques (notamment sur les retours d’erreur)
    • Un utilisateur peut être un chaton, qui a accès à l’ensemble des logs qu’il émet, ou un utilisateur final qui n’a accès qu’au log des messages qui le concerne (permission par regex sur des champs dans les logs)
    • Les utilisateurs qui ont déjà envoyé un e-mail via les passerelles (qui apparaissent donc dans le « from » des logs) peuvent se créer un compte en toute autonomie sur la plateforme et ainsi avoir accès à leurs logs d’envoi.
  • Un rapport quotidien/hebo/mensuelle sur les erreurs peut être émis par e-mail (exemple de rapport

C’est pas mal codé en Vanilla, parce que je suis pas développeur (même si j’essaie de faire des efforts) et un passage vers un Framwork est envisagé/envisageable, mais j’aurais besoin de soutien pour ça donc si le cœur vous en dit…

Voilà en gros…
Je parlerai de mes avances dans ce fils,
Si vous avez des questions n’hésitez pas.
David

3 « J'aime »

J’avais lu qu’une des bonnes pratiques était de séparer les IP par type d’envois. Idéalement: Un groupe d’IP pour les newsletter, un autre pour les mail listes, un pour les boites mail et un autre pour les mails techniques (recovery password et autre).

Tu as lu ça où ? Je trouve ça étrange comme dispositif et j’ai des doutes sur sa pertinence mais s’il y a des arguments je ne demande qu’a les lires pour être contredit.

Il me semble que c’est dans les docs de Google concernant l’envoi de mail mais j’ai pas trop le temps de retrouver la page de doc en question là.

Effectivement je trouve cela bizarre aussi mais j’ai fait une recherche rapide et par exemple ici https://help.returnpath.com/hc/fr/articles/224780827-Les-bonnes-pratiques-de-délivrabilité-chez-Gmail il y a ces 2 éléments :

  • Envoyez des emails appartenant à différentes catégories (par exemple : des promotions, des notifications de transaction et des notifications provenant des réseaux sociaux) à partir de plusieurs adresses d’envoi et restez cohérent dans le choix de ces adresses.
  • Utilisez des adresses IP, des sous-domaines et des domaines différents pour chaque flux d’emails (par exemple : les messages de marketing ou les messages transactionnels). La segmentation donne un meilleur contrôle à l’abonné car celui-ci a la possibilité de se désinscrire d’un flux tout en conservant son abonnement à d’autres.

La première me semble logique est permet une catégorisation, label automatique par des clients mails comme ceux de google ou autre.

La seconde je ne comprends pas forcément et si c’est propre à Google ou pas.

1 « J'aime »

Hello @kepon ,

Je viens de retrouver un projet que j’avais mis de côté pour le tester un jour, ça m’était complètement sorti de la tête : Lightmeter / ControlCenter · GitLab

J’ai l’impression que ça couvre une partie de ce que tu souhaites faire.

1 « J'aime »

Pour info, oMailgw va être revu, repris au propre, passer de PHP Vanilla à Laraval (API) + client JS

L’intention est détaillé ici : vers une v1.md · main · oMailgw / oMailgw-doc · GitLab

Je vais allouer pas mal de ressource humaine (moi+un stagiaire développeur) dans les 2-3 prochains mois pour que ça avance.

4 « J'aime »

La version 0.9 de oMailgw est sortie : grosse refonte avec Laravel pour la partie API, pure HTML/JS pour l’UI

Maintenant celui-ci (en plus d’être plus propre) permet maintenant :

  • Visualiser des logs de trafic e-mail sortant selon des permissions :
    • from : complet ou seulement le domaine
    • smtpd_username : authentification SMTP
    • server : le serveur (la passerelle)
  • Visualiser un beau dashboard/statistique
  • Recevoir un e-mail rapport quotidien/mensuelle/hebdo en cas d’erreur seulement ou tout le temps
  • Visualiser les e-mails en attentes sur les passerelles (toujours selon les permissions précédentes)
  • Apprentissage des « hard-bounces » : détection des retours type : Recipient address rejected: User unknown pour que le message soit rejeté à l’entrée la prochaine fois.
  • Voir les e-mails en attentes (spooler) sur les différentes passerelles e-mails connectés selon nos permissions d’accès au log
  • Gestion des routes/transport_map depuis l’interface/l’API
  • Gestion des authentifications SMTP depuis l’interface/l’API
  • Rspamd en anti-spam

Note : il peut demeurer quelques bug dans l’UI mais l’API fonctionne bien, c’est en prod chez moi.

N’hésitez pas à venir vers moi si vous voulez tester le machin.

David

5 « J'aime »

Bonjour,

Si un administrateur veut pouvoir utiliser une autre adresse IP de sortie (en cas de soucis), il doit la déclarer au préalable avec une ligne SPF dans ses DNS, n’est ce pas?

D’autre part, il y a une coresponsabilité entre les deux administrateurs. Il faudra garder des logs pour éventuellement pouvoir les produire en cas de requête judiciaire. Mais je suppose que ça, c’est déjà prévu.

Bonjour LautreG,

Oui, ça c’est inhérent au fonctionnement SPF, pas spécifique à oMailgw…

Si tu peux détailler le contexte hypothétique auquel tu fais référence ça peut m’aider à te répondre. oMailgw c’est utile que pour partager (avec des permissions) ces logs mais les logs bruts pour les requêtes judiciaires doivent être conservés dans les délais légaux.

David

Ou pas, de mémoire* sauf envois en nombre (type newsletter) les emails ne sont pas concerné par les décrets sur les logs. C’est lié à la définition légale d’un service de communication au public en ligne il me semble…

* comme c’est de mémoire faut vérifier

Pour baisser le prix d’un cluster de machines de sortie mail, chez Framasoft, j’ai mis en place un postfix multi-instances avec une adresse IP par instance. Je me suis basé sur cet article : À la découverte du mode multi-instances de Postfix | Sysnove.

Un serveur + un bloc d’adresses /29 nous coûte moins cher que 2 serveurs (donc 2 adresses IP) et ça nous permet de décharger notre pauvre serveur framalistes qui n’en pouvait plus, avec Orange et ses blocage.

ha c’est intéressant comme retour, j’ai toujours été frileux à l’idée de faire du multi-instance, notamment parce que j’ai à l’esprit un bruit de couloir qui disait que parfois c’était le bloc qui était bloqué et non l’IP… Donc je me disais qu’avoir un bloc ça revenait a mettre tout mes œufs dans le même panier… Mais du coup tu es peut être en mesure de me dire si c’est une légende urbain ? Si tu as eu des expériences de blocage « par bloc » ou seulement par IP ?

Pour oMailgw le mode multi-instance devrait pas poser de problème… En effet le « cli » récupère les logs par « regex »… la meilleurs approche serait d’avoir un « omailgw-cli » par instance pour bien trier ça dans l’interface…

Autre chose, ce truc de séparer les flux par IP, je comprends l’intérêt (certain flux sont plus susceptibles de générer mauvaise réputation) mais il y a aussi une considération au volume sur la réputation. Donc si on est « petit » (comprendre peu de volume) séparer les flux divise le volume et donc pénalise potentiellement la réputation… :frowning: La question à cent mille euros qui vient derrière c’est : à quel seuil (de volume) il est intéressant de séparer les flux ? J’ai le sentiment qu’on ne peut qu’avoir des réponses au doigt mouiller, mais si vous voulez vous y risquer ça m’intéresse…

David

On s’est déjà fait bloquer certaines adresses IP du postfix multi-instances mais pas le /29 entier.

Je pense que le bloc entier peut être banni si on envoie du spam comme des bourrins, encore et encore, mais a priori, ça va pour nous.

1 « J'aime »