Mutualisation SMTP

[acnh38]

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 :

• Qui aurait le droit d’utiliser ce « SMTP as a service » ? Uniquement les Chatons ?
• Comment gère-t-on les mésusages potentiels de ce service ?
• Est-ce jouable que ce service ne soit pas centralisé mais un service libre qui serait déployable par n’importe quel hébergeur ?
• Est-ce que ce service intègre un nettoyage des adresses de distribution ? Je pense aux listes de diffusion qui ne sont jamais mises à jour et génèrent une quantité d’envois inutiles.
• Comment fait-on pour faire la promotion de ce service, notamment auprès des bigtech qui se sont arrogés le droit de privatiser en partie (blacklistage) un service central de l’internet ?
  J’en profite pour pinguer celles et ceux que ce sujet devrait intéresser : @Framasoft, @IndieHosters, @LeCloudGirofle, @whilelm . N’hésitez pas à faire suivre.

[kepon]

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 .

@bohwaz

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

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…

@acnh38

Est-ce jouable que ce service ne soit pas centralisé mais un service libre qui serait déployable par n’importe quel hébergeur ?

C’était le sens de oMailgw, que chacun puisse avoir sa/ses passerelles mais qu’on puisse collaborer au besoin

@acnh38

Est-ce que ce service intègre un nettoyage des adresses de distribution ? Je pense aux listes de diffusion qui ne sont jamais mises à jour et génèrent une quantité d’envois inutiles.

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…

@acnh38

Comment fait-on pour faire la promotion de ce service, notamment auprès des bigtech qui se sont arrogés le droit de privatiser en partie (blacklistage) un service central de l’internet ?

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 :

• Soit ne le sont pas
• Soit le sont mais dans les indésirables sans raison apparente / de façon aléatoire / sans que personne ne puisse vraiment savoir pourquoi…

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

[Maxime]

J’en parle à l’équipe, mais ça serait super de voir quelque chose émerger dans ce sens, oui

[bohwaz]

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 :

• quand on s’était contactés, le budget de Paheko c’était 20.000 €, aujourd’hui c’est 80.000 €, ça permet de faire les choses différemment
• il y a une grosse différence entre payer un presta qui ferait l’envoi de mails à notre place, et investir dans le développement d’une solution qui profiterait à des dizaines de structures, dont nous
• je t’avais envoyé un mail pour connaître les tarifs pour la presta d’envoi de mails en mars 2024, et tu ne m’a pas répondu du coup je ne sais pas quel est le tarif que tu propose 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

@kepon

le problème principal pour moi à l’heure actuelle ces les mails qui sont dit « délivré » en réponse SMTP, mais qui :

• Soit ne le sont pas
• Soit le sont mais dans les indésirables sans raison apparente / de façon aléatoire / sans que personne ne puisse vraiment savoir pourquoi…

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

[whilelm]

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

[bohwaz]

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 ^^

[LautreG]

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.

[acnh38]

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

[bohwaz]

@acnh38

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

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

@acnh38

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

Comme je l’ai dit il faut imaginer un mécanisme contre ça, c’est pas insurmontable.

@acnh38

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 ?

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.

@acnh38

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…

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

[sekil]

@bohwaz

@acnh38

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…

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.

[bohwaz]

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 :

1. Le relais « local » signe le message avant de le transmettre au relais final (qui peut très bien être le relais local d’ailleurs) : ça permet de contacter directement le SMTP « fédéré » (en local donc) depuis une appli, sans avoir à configurer un postfix ou autre pour signer les messages.
2. Le relais « local » reçoit le message déjà signé et le transmet donc tel quel.

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.

[sekil]

@bohwaz

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

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.

@bohwaz

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.

Oui, c’est clair.

[bohwaz]

@sekil

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.

Yep en relisant ça fait sens, j’ai dû confondre avec les soucis dûs aux redirections, merci

[bohwaz]

@acnh38

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 ?

J’ai re-réfléchi à ce point et :

• le hashage de l’adresse e-mail n’anonymise pas l’adresse mais peut la pseudonymiser, c’est mieux que rien mais pas parfait
• conserver une adresse e-mail invalide (hard bounce) ne pose pas de souci avec le RGPD, car elle n’est pas liée à une personne réelle
• conserver une adresse e-mail d’une personne qui a demandé à ne plus recevoir de mails (plainte pour spam, ou opt-out), fait partie des raisons valides de conserver une donnée personnelle (sauf si la personne fait une demande d’effacement)
• conserver une adresse e-mail (pour assurer le suivi des soft bounces par exemple) pour assurer le fonctionnement du service fait aussi partie des autorisations. Si on stocke l’adresse hashée cela démontre qu’on ne peut utiliser cette donnée pour un autre usage, comme envoyer du spam, ou revendre la donnée.

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

[Meewan]

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)

[sekil]

@Meewan

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.

[Meewan]

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)

[bohwaz]

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)

[LautreG]

Il me semblait qu’il y avait un souci avec DKIM si ce n’était pas le dernier relais qui signait

J’ai un serveur qui est dans ce cas, et ça ne pose aucun soucis.

[hd99]

très étonnant, ressemble beaucoup à cette discussion :

Pypi bloque les mails en outlook.com et hotmail.com - LinuxFr.org