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 Likes

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 Like

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 Like