Juste pour confirmer ma compréhension de l'architecture : omailgw-cli, c'est bien un agent qui tourne sur le serveur Postfix, qui lit les logs mail et interroge la file d'attente, puis pousse ces informations vers omailgw-api via HTTP ? Et le flux est bien unidirectionnel (cli vers api), l'API ne peut pas envoyer de commandes en retour vers le serveur mail ?
C'est ça.
L'API ne peut pas interroger le CLI. C'est toujours le CLI qui envoie des infos à l'API.
Ceci étant dit, quand le CLI initie une demande à l'API d'envoi de log, préalablement, elle peut recevoir (si tu l'as paramétré, si tu le souhaites... Tu peux ne pas le faire) :
* Les "transports maps" : chemin / route ajouté dans l'interface par l'utilisateur "root" pour rediriger du trafic vers certains domaines (exemple, ma mailgw1 est bloqué vers hotmail, je bascule tout le trafic hotmail vers mailgw2...)
* Les authentifications SMTP créé par les utilisateurs admin. (permette l'authentification sur les passerelles)
Encore une fois, tu peux ne pas utiliser ces fonctionnalités, ça se configure dans le config.php
[^] # Re: Trop bien
Posté par David (site web personnel, Mastodon) . En réponse au journal oMailgw 1.0, un outil libre pour superviser des passerelles SMTP sortantes mutualisées. Évalué à 3.
C'est ça.
L'API ne peut pas interroger le CLI. C'est toujours le CLI qui envoie des infos à l'API.
Ceci étant dit, quand le CLI initie une demande à l'API d'envoi de log, préalablement, elle peut recevoir (si tu l'as paramétré, si tu le souhaites... Tu peux ne pas le faire) :
* Les "transports maps" : chemin / route ajouté dans l'interface par l'utilisateur "root" pour rediriger du trafic vers certains domaines (exemple, ma mailgw1 est bloqué vers hotmail, je bascule tout le trafic hotmail vers mailgw2...)
* Les authentifications SMTP créé par les utilisateurs admin. (permette l'authentification sur les passerelles)
Encore une fois, tu peux ne pas utiliser ces fonctionnalités, ça se configure dans le config.php