on fait un partenariat pour faire gérer le mail (boîte complète, voire NDD) de nos adhérents par un chatons spécialisé mail. En échange leurs adhérents peuvent profiter de certains de nos services. Voir le niveau d’intégration, de la simple reconnaissance d’adhésion, à l’intégration dans sans-nuage, en passant par de la marque blanche. PING @Sud-Ouest.org
On envisage donc de souscrire au Junk Mail Reporting Program de Microsoft (ou de passer par @kepon) , d’où mes questions :
Ca implique quoi niveau protection des données perso de nos adhérents ? Quel type de meta données envoyé par ces dispositifs ?
quel est le lien entre l’outil omailgw et ce genre de dispositif ? @kepon
A mon avis rien de plus… Sinon qu’ils arrivent à relier ton compte hotmail avec une IP émettrice, mais sinon ils ont déjà « tout » (je peux me tromper)
Chez certain le lien, c’est la prise en charge des FBL / complaints en gros quand quelqu’un chez @yahoo (par exemple) met un de vos messages en SPAM ça t’envoie un message sur abuse@sans-nuage… et oMailgw blacklist le destintatire pour ne plus lui envoyer de message…
Non c’est le « dernier » maillon émetteur qui souscrit.
Bon après je ne vois pas trop le frein à la souscription Junk Mail à part d’avoir un compte microsoft poubelle pour ça…
Après ça dépend si vous voulez « plus vous en charger » ou « continuer d’essayer » (je vous y encourage à continuer ! Après si vous voulez discuter conseil, je peux prendre du temps pour ça… si vous avez la ressource humaine/l’envie… et peut être que d’autre ici aurait à partager…)
Et oui, c’est chronophage, mais même avec un service tiers, payant, ce n’est pas 100% d’arrivée en INOBX, l’enveloppe, son contenu, la réputation du nom de domaine est aussi prise en compte…
J’essaye de raccrocher les wagons. En vrai, on a tous des problèmes de délivrabilité et on a peu ou prou les même solutions.
Mais quid des postfix à instances multiples et de faire tourner sur un pool d’IP ? y en a qui ont essayé ça ?
Concernant DANE, qqun a t-il pu montrer ses réels effets sur la delivrabilité ?
De notre coté (chez kaz.bzh), l’IP du serveur de mail s’est faite blacklistée pendant 10j chez M$. Et les utilisateurs l’ont pas très bien vécu (nous non plus du coup ). Pour info, on fait parti du machin " Junk Mail Reporting Program" et on espérait que ça aurait pu nous aider mais nan.
Bref, comme on a plusieurs srv avec des IP pas sur les même blocs, on s’est dit, qu’en cas de blocage, pour un provider particulier, qu’on pouvait faire transiter les mails par ces srv.
Et pour finir, il y a eut un gros travail de fait, que j’ai suivi de loin depuis 2 ans sur une mutualisation des envois de mails pour les CHATONS. J’ai l’impression que c’est en pause ?
C’est exactement ce que je fais, j’ai plusieurs petits VPS avec très peu de ressources (juste pour faire du postfix/rspamd/omailgw-cli ) ici et là… et je joue avec les transports postfix pour passer le trafic ici ou là quand ça bloque ici ou là… oMailgw a été conçu pour cette usage (centraliser les logs de plusieurs passerelles, gérer les routes entre elles)
Pas mis en place mais j’ai des doutes… Et des effets me semble diffficilement mesurable…
Ho oui c’est partie dans le >/dev/null mais c’est (à mon avis) trop colosale… Et pas que techniquement… C’est humainement qu’il y aurait un gros travail à faire (et ça c’est pas le point fort du collectif). Je peux développer mais c’est pas le sujet ici.
C’est pas dans /dev/null, y’a eu du boulot de fait, des avancées, beaucoup de boulot, mais c’est aussi ma faute : je suis nul en gestion de groupe / projet, et le côté organisation / planification + la surcharge d’autres trucs à côté ça m’a fait complètement décrocher, je me suis très incompétent Mais je pense toujours à ce chouette projet qui est toujours très pertinent, mais moi ce que je sais faire c’est coder, c’est tout
Hello,
Je plussoie carrément ce que dis bohwaz, ça serait top de poursuivre. Mais effectivement, c’est très gros. Perso, je suis déjà bien occupé avec le CHATONS et pas aussi calé que vous sur la messagerie, même si, en gestion de projet, peut-être que je serai plus à l’aise.
A ce stade, est-ce qu’on a besoin de passer par une recherche de financement pour que le projet prenne corps ? Je dis ça un peu au hasard hein.
J’ai vu que télécoop envisageait de lancer un service mail en 2027, ils recherchent des gens avec des compétences pour commencer à en discuter. Et dans un second temps ils proposeraient un cloud.
Peut-être qu’en leur expliquant les problèmes que rencontrent les petits hébergeurs (et donc ceux qui commencent) et qu’on a des idées et des solutions dans le collectif…
Ils pourraient être partenaires/financeurs de la mutualisation SMTP ?
Pour info on avait très bien avancé sur le cahier des charges avec @sekil principalement qui a fait tout le boulot, je ne sais pas ce qu’il est devenu, voir peut-être avec @acnh38 qui coachait le projet.
@kepon a raison c’est très ambitieux il faudrait se prévoir une première étape plus petite, mais moi j’ai toujours pas le temps et l’énergie mais on peut débloquer du budget Paheko dessus Et oui il y avait des petits hébergeurs intéressés (c’était aussi l’objectif, que ça soit un truc utilisable par un hébergeur).
Le but ici n’est pas de mutualiser le SMTP au début, mais déjà de faire une passerelle qui va empêcher tes hébergés de te faire blacklister, en limitant les envois aux adresses invalides par exemple. Dans un second temps le but est de partager avec des copains de confiance les adresses invalides. Et enfin à terme de pouvoir relayer du trafic SMTP entre copains, en ayant du coup l’assurance que les envois seront « propres » car filtrés par cette « passerelle ».
Je confirme les propos de @bohwaz.
C’est @sekil qui a été le dernier intervenant sur le projet mais il a arrêté pour des modifs professionnels.
Au delà du CdC, il y a d’autres infos sur le wiki : Architecture fonctionnelle, fonctionnement de la CI CD, …
Et les CR de réunions.
Bref, tout ce qui a été fait est très bien documenté.
Pour rappel, le projet est construit sur 2 modules :
Aspect trafic pris en charge par un serveur SMTP (Postfix) avec des extensions nécessaires
Bounce service : Développement spécifique.
Reste que le projet est complexe. Plusieurs personnes y ont déjà consacré beaucoup de temps. A la louche, il faut envisager 300 jours de boulot. Quoi qu’on fasse, il me semble utopique de relancer le projet si on n’a pas un minimum, non négligeable, d’énergie à y consacrer.
Perso, je reste motivé et je serai partant pour faire un atelier sur ce sujet lors du camp CHATONS qu’on pourrait ouvrir à celleux qui ne seront pas en présentiel.
Je propose donc un Framadate pour décider d’un créneau lors du camp CHATONS. C’est aussi un bon moyen de se compter
). Pour info, on fait parti du machin " Junk Mail Reporting Program" et on espérait que ça aurait pu nous aider mais nan.
mais c’est (à mon avis) trop colosale… Et pas que techniquement… C’est humainement qu’il y aurait un gros travail à faire (et ça c’est pas le point fort du collectif). Je peux développer mais c’est pas le sujet ici.
Mais je pense toujours à ce chouette projet qui est toujours très pertinent, mais moi ce que je sais faire c’est coder, c’est tout 
Et oui il y avait des petits hébergeurs intéressés (c’était aussi l’objectif, que ça soit un truc utilisable par un hébergeur).