Salut les gens,
Je suis assez chaud pour lancer un truc sur la mutualisation de nos passerelles smtp, le cas d’utilisation étant « ah je suis blacklisté, donc en attendant je passe par chez toi, bro ! »
la discussion est ouverte,
Je me permets de pinger @bohwaz @kepon
Salutations
Wouhou yes !
Moi ce que j’adorerais c’est plus ambitieux : c’est d’avoir un truc « en amont » de nos SMTP (comme ça on touche pas trop à nos configs de SMTP respectifs), qui fasse donc du SMTP mais tourne sur un autre port.
Concrètement on se connecterait à ce « SMTP fédéré », en local, avec une authentification spécifique.
Une fois connecté à ce service, il vérifierait :
Le but (n°1) est de bloquer très vite si un de nos utilisateurs s’est fait hacké et est utilisé pour envoyer du spam, ou de retarder par exemple en cas d’envoi suspect. Et donc qu’on puisse se faire confiance entre membres du réseau fédéré, que ce réseau ne puisse pas être utilisé par un des membres de manière malicieuse, ni qu’une faille chez un des membres puisse l’être par un tiers.
De même le service vérifierait que chaque adresse destinataire n’a pas déjà eu un bounce / signalement pour spam dans les derniers X jours. Dans ce cas on bloquerait les envois vers cette adresse, on ne laisserait passer vers cette adresse que des messages de vérification de l’adresse (avec un lien à cliquer par exemple).
Et ce au niveau de tout le réseau : si le chaton Z à envoyé un mail à invalide@hotmail.fr le jeudi qui est revenu en hard bounce, il faut que l’envoi du chaton Y à la même adresse le vendredi soit aussi directement bloqué.
Ici le but (n°2) est de s’assurer que nos adresses IP ne seront pas bloquées. Mais aussi d’améliorer la délivrabilité, et que le réseau ne tombe que rarement sur des adresses invalides, car on aura déjà une base de donnée des adresses invalides.
Note : les adresses e-mail ne seraient pas stockées en clair mais sous la forme d’un hash de l’adresse, permettant de limiter les risques en cas de fuite de la BDD. Mais il y a peut-être mieux pour protéger la vie privée…
Le service ferait aussi en sorte de répartir les envois au sein du réseau, afin que par exemple un envoi de newsletter à 100.000 destinataires se fasse manière égrénée dans le temps, depuis plusieurs adresses IP du réseau.
Là le but (n°3) est de faire en sorte que le volume d’envoi depuis chaque IP soit régulier. Exemple : Framasoft ne fait pas de service de mails, mais envoie une grosse newsletter une fois par an, c’est pas grave car on égrène l’envoi sur quelques jours, et en plus le volume ne sera pas énorme d’un coup car le réseau écoule déjà le volume habituel des mails de 10 chatons qui font de l’hébergement de boîtes mails, et 4 autres qui ont 300 listes de discussion actives, et donc le volume d’envoi quotidien est déjà dans les 10.000 mails / jour / IP.
Enfin le but n°4 est de détecter les blocages d’IP de la part d’un serveur destinataire (genre Orange) et de passer les envois vers ce fournisseur sur d’autres IP, le temps que ça se débloque. Pour cela il faudrait être très vigilant à ne pas provoquer un blocage en chaîne de plusieurs IP. Il faudrait aussi intégrer un réseau de surveillance des blacklists de nos IP…
Une fois tous les filtres passés, ce service utiliserait le « vrai » SMTP du serveur pour faire l’envoi définitif, ou alors (??) irait directement délivrer ça au SMTP destinataire (MX) mais là ça voudrait dire intégrer la gestion de DKIM… ce qui serait peut-être une bonne idée, je sais pas.
Tout cela serait assorti d’une API HTTP permettant de savoir si une adresse est invalide / bounce, et la réputation d’une IP / login expéditeur / CHATON, ainsi que de la possibilité pour chaque login expéditeur de configurer un webhook pour savoir si un envoi a fait un bounce.
Bref voilà c’est assez ambitieux, le but étant d’avoir AWS SES, mais en fédéré entre nous, et d’ailleurs ça peut servir à d’autres : une telle solution serait sûrement très utile dans une entreprise qui veut avoir son réseau d’envoi de mails aussi…
Moi je suis prêt à pousser pour que Paheko mette du budget de développement là-dessus, genre 10k€ 
Mais pas à le développer car pas le temps 
Parce que de mon côté pouvoir faire du fallback manuel ailleurs en cas de blocage d’IP c’est pas suffisant car ça veut dire devoir gérer manuellement plein de trucs au niveau des mails. L’idée que j’expose est plus dans le sens de « SMTP as a service ».
Je suis bien incapable de donner un avis sur la solution technique imaginée par @bohwaz. Mais il y a déjà du jus de cerveau
Par contre, je veux bien contribuer activement sur ce projet dans les domaines que je maîtrise un peu.
Donc, je rebondis sur l’aspect financement. Je trouverais sympa que tous les Chatons intéressés se positionnent sur ce point. J’avais en tête un financement participatif (avec HelloAsso car je n’en connais pas d’autre). Il faut encore que je pose la question en interne Hadoly, mais je pense qu’on pourrait « prêter » notre compte bancaire pour récolter les fonds.
Ensuite, je me pose quelques questions tel que :
Salut Thomas,
C’est dans ce sens que j’ai développé oMailgw pour gérer ces passerelles sortantes … Pour a la fois que chacun puisse gérer ces passerelles et qu’en même temps on puisse faire du routage sur tout ou sur certains domaines bloquant… Maintenant oMailgw fait juste de l’interface, sinon ça reste du Postfix, c’est pas du SMTP as service comme le propose @bohwaz .
Je suis agréablement surpris de ça, la dernière fois que tu m’avais contacté à la recherche de service alternatif à Amazon pour tes mails tu voulais que je m’aligne avec les prix d’Amazon… on parlait pas en k€… Mais c’est cool !
Pour ta proposition @ThomasC je crois que tout le monde en rêve plus ou moins (en tout cas ceux qui font du mail) et que même si techniquement c’est pas si difficile (parce qu’on est des techos et que c’est la partie amusante pour nous) il y a tout une partie de gestion humaine à cette mutualisation qui est loin d’être neutre parce que le mail : c’est du temps humain, y’a pas d’histoire… (même avec du « as a service »). Et du coup qui assume ce temps humain ? Comment on équilibre la balance ? Comment on fait quand Paul aura fait blacklisté par 4 fois les IP pour X raisons (pas nécessairement de sa faute) et que ça génère une surcharge de travail, une gêne pour le groupe qui n’a plus que 1/3 des messages vers @outlook qui arrivent ?
C’est pour ça que de mon côté j’ai fini par proposer un service de passerelle : https://retzo.net/services/hebergement/passerelle-e-mail-relai-smtp/ (Actuellement 2 CHATONS qui font transiter tout leur trafic et 2 autres qui font partiellement transiter leur trafic « en cas de blacklist/problème ». A mon sens c’est un type d’échange (le monétaire) qui permet d’équilibrer la balance, enfin c’est fait pour ça…
C’était le sens de oMailgw, que chacun puisse avoir sa/ses passerelles mais qu’on puisse collaborer au besoin
J’ai fais ça, je ne distribue plus les messages après X code SMTP retourné en UserUnknown (like) : README.md · master · oMailgw / oMailgw-api · GitLab avec le risque (faible mais existant) qu’une boîte qui n’existe plus à un moment X existe à un moment Y…
Je suis pas sûr que même avec tout les CHATONS réuni le volume de mail soit suffisamment pour dire à @outlook, @gmail « hey on existe, vous êtes gentil avec nous ! » quand on vois que des Gandi galère… mais sait-on jamais 
Perso j’ai constaté tout de même qu’au delà d’un certain seul de mails par jour (plusieurs miliers) le blacklistage n’est quasi plus existent / en tout cas ne devient pas le problème principal (j’ai mis aussi des règles stric du genre : si le SPF et le DKIM ne sont pas présent, ou faux = pas de distribution : [resolu] [rspamd] e-mail sortant activer les politiques/symboles SPF/DKIM - #14 par kepon ) le problème principal pour moi à l’heure actuelle ces les mails qui sont dit « délivré » en réponse SMTP, mais qui :
Perso je n’ai pas beaucoup de ressource humaine à ajouter au pot commun en ce moment (je suis en chantier) et pas non plus de ressources financières à offrir (ayant soutenu l’intégralité du développement de oMailgw l’an passé… et ça a été plus long/fastidieux que prévu…
Même si mon infra est plutôt « stable » actuellement, donc plus vraiment besoin de mutualiser des ressources… Je veux quand même bien en être s’il y a discussion/organisation « mutualisation » mailgw… et si y’a 10K€ qui rentre pour du dev en ce sens et que vous voulez pas repartir d’une page blanche, oMailgw est open source… Welcom !
David
J’en parle à l’équipe, mais ça serait super de voir quelque chose émerger dans ce sens, oui
Oui oMailgw est une bonne idée mais c’est différent car ça intervient derrière le SMTP, pas devant. Mon idée est plus de construire sur la bonne idée de oMailgw pour se fédérer
Et du coup qui assume ce temps humain ? Comment on équilibre la balance ? Comment on fait quand Paul aura fait blacklisté par 4 fois les IP pour X raisons (pas nécessairement de sa faute) et que ça génère une surcharge de travail, une gêne pour le groupe qui n’a plus que 1/3 des messages vers @outlook qui arrivent ?
Ce que je développe c’est justement éviter que ça n’arrive en premier lieu, en surveillant le volume d’envoi de chaque expéditeur et en bloquant rapidement en cas de souci. Il vaux mieux bloquer des envois de mail pendant 24-48h, que de se faire blacklister.
Je suis agréablement surpris de ça, la dernière fois que tu m’avais contacté à la recherche de service alternatif à Amazon pour tes mails tu voulais que je m’aligne avec les prix d’Amazon… on parlait pas en k€… Mais c’est cool !
Plusieurs choses :
mais possible que d’autres points posent problème ensuite, car notamment on a besoin des FBL ce que tu ne fait pas je crois, mais si tu as de la dispo hésite pas à m’envoyer un mail avec les tarifs et ce qui est inclus / pas inclus Ça pourrait faire partie de la solution, d’avoir des boîtes mails « de test » qui sont mises en copie de certains mails au hasard, et ensuite avec un script IMAP on va vérifier où tombe le mail. De mon côté j’ai des comptes chez laposte.net, SFR, GMail, Free etc. et je fait des tests de délivrabilité manuellement quand il y a des soucis. Il me manque Orange car il faut être abonné chez eux pour avoir une adresse, et quand on se désabonne la boîte mail est supprimée, donc c’est chiant. Il faudrait trouver un abonné orange qui accepte de créer une boîte mail pour nous, mais bon bof.
Du coup j’ai constaté par exemple que avoir plus de 2 fois le même domaine en lien dans le mail peut provoquer la mise en spam chez Laposte.net.
Salut !
Cette discussion est vraiment intéressante. J’avais fait un peu de même, faire quelques boites chez différents domaine mais je n’avais pas organisé ça de manière aussi importante.
par contre, je me demandais si tu avais déjà sollicité VadeSecure @bohwaz pour tester la délivrabilité ? C’est à la fois un prestataire qui fournit des solutions antispam chez certains gros fournisseurs de mail et qui ferait également de la presta de conseil sur la délivrabilité (ça mange à plein de rateliers différents, c’est pratique…).
Je ne savais pas qu’ils font ça, mais je trouve leur antispam utilisé par free particulièrement relou donc pas forcément envie de leur donner des sous, et ça sera sûrement plus cher que de le faire moi-même ^^
La délivrabilité c’est souvent mesuré en plaçant des traqueurs dans les messages.
Bof bof.
Et, certains serveurs comme Gmail peuvent répondre OK 250, mais ne pas délivrer le message dans le boîte du destinataire.
Bonjour,
Voici un compte-rendu ( largement incomplet) d’une longue discussion que j’ai eu avec des copains qui maîtrisent le sujet du mail depuis de longues années.
1/ première réaction : il faut arrêter de faire des envois de masse (newletters = spam). Le mail n’est pas un outil adapté à la communication de masse. Il faut promouvoir d’autres canaux de communication et éduquer les gens à venir chercher l’info (débat autour des consommateurs/acteurs).
2/ L’outil envisagé peut être totalement contre-productif et fait courir le risque de faire blacklister toutes une série d’IP en cascade (à priori pas uniquement les IP qui « utiliseraient » le service, mais là, je n’ai pas tout compris).
3/ Le stockage des adresses « invalides » pose un problème de RGPD (on est censé avoir l’autorisation du propriétaire de l’adresse pour la stocker). Au delà, une question se pose : qui serait le responsable de traitement de ce service ?
4/ Il semblerait que le partage des DKIM présente un risque important. Un chaton renégat pourrait utiliser les DKIM des autres chatons pour un usage malveillant. La confiance à un instant T ne peut être éternelle…
Au final, la solution proposée par Bohwaz semble assez ingénieuse mais il semblerait que l’envoi de masse d’email est Don Quichotesque. Il serait vain de penser passer entre les mailles des filets des bigtechs. Pour un résultat à discuter : Quel est le taux de lecture effectif résultant de ces newletters ? Ne faut-il pas envisager un média mieux adapté ?
De mon point de vue, ces éléments ne remettent pas en cause le projet. Par contre, il faut peut- être prévoir une période de maturation plus longue avant de réaliser une solution technique inadaptée.
J’aurais bien aimé évoquer ce projet lors de la prochaine réunion mensuelle. Mais je ne suis malheureusement pas disponible le 13 juin. J’espère que d’autres personnes auront à cœur de faire avancer le sujet.
Miaou
Oui alors non, ça fait 30 ans qu’on fait des newsletter, c’est un média qui fonctionne pour informer les gens. « éduquer les gens à venir chercher l’info » ça finit juste en boucle whatsapp, ce qui est largement pire. Perso je suis engagé dans plein d’assos, si je dois aller chercher les infos de chaque asso manuellement, je ne fait plus rien de ma vie. Le mail est parfait pour avoir des infos quand on le veut, de manière peu intrusive et qui demande peu de temps d’attention. Donc pas d’accord du tout avec ce point de vue qui me semble très « geek ».
Comme je l’ai dit il faut imaginer un mécanisme contre ça, c’est pas insurmontable.
On peut stocker, comme le fait Paheko, un hash de l’adresse e-mail, pour avoir une donnée pseudonymisée, ou un hash+salt pour avoir une donnée anonymisée. Chacune des deux approches a des avantages et inconvénients, mais à partir du moment où le message passe par le SMTP d’un CHATON, celui-ci dispose déjà de l’adresse e-mail du destinataire en clair dans ses logs, donc ça ne change pas grand chose… (et actuellement : tout le monde s’en contrefout d’avoir plein d’adresses mail en clair dans les logs, donc faudrait pas non plus trop se prendre la tête avec ça…)
Après s’il existe une meilleure solution, comme par exemple du K-anonymity je veux bien mais je suis pas sûr que ça marche pour ce cas d’usage.
Un CHATON peut révoquer un certificat DKIM simplement en supprimant le sélecteur de ses DNS. Donc non la confiance n’est pas éternelle
Sur ce point, pour moi il serait impensable que le serveur intermédiaire fasse la signature DKIM.
Le DKIM, c’est signé exclusivement par le chaton émetteur, et en l’occurrence le relai ne doit pas modifier le message pour ne pas casser la signature.
Par contre il faut effectivement déclarer le serveur intermédiaire dans ses SPFs.
Il me semblait qu’il y avait un souci avec DKIM si ce n’était pas le dernier relais qui signait ? Je ne sais plus quoi exactement, mais si ce n’est pas le cas oui aucune raison de le faire au niveau du relais, c’est plus simple à faire en local Dans ce cas on peut imaginer 2 options :
Et du coup ça règle la question de la confiance.
Dans tous les cas un relais « sortant » ne doit pas accepter d’envoyer un message non signé ou avec un SPF/DMARC qui ferait que le message soit rejeté : valider en amont que le message est OK avant qu’il parte.
Autant que je sache, DKIM signe le contenu et certains headers, donc tant qu’on ne change pas le contenu, tu peux relayer le message autant que tu veux.
Le problème de relayage avec DKIM c’est sur les mailing list quand le serveur de liste ré-écrit les adresses des émetteurs/destinataires, ou sur les redirections sieve quand le destinataire est modifié. Je ne connais pas d’autre problème lié à DKIM dans un cas de relayage.
Oui, c’est clair.
Yep en relisant ça fait sens, j’ai dû confondre avec les soucis dûs aux redirections, merci
J’ai re-réfléchi à ce point et :
Donc je ne pense pas que ça pose de souci, mais c’est un point qui peut demander plus de réflexion/discussion pour s’en assurer
pour être parfaitement conforme il faudrait juste ajouter une suppression des hash après un certain temps (1-3 an ?)
et plus pénible il faut une page pour pouvoir demander le retrait d’une adresse (mais qui ne doit pas dire si on l’avait ou pas sinon il y a un risque de fuiter des données personnelles)
Si si, tu peux prévenir : tu envoies un mail à l’adresse indiquée pour l’informer qu’elle a été retirée de la liste.
ben c’est une adresse qu’on a flagué comme mauvaise donc ça va être compliqué de lui envoyer un mail (mais on s’éloigne du sujet du thread)
Une adresse invalide n’a pas à être supprimé car elle n’est pas liée à une personne réelle, donc ce n’est pas une donnée personnelle
+1 pour la suppression du hash après X temps sans envoi (sauf les adresses invalides du coup)