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
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
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.
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.
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.
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
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.
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.
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…
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… 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…
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…
