SM2TP : GT mutualisation SMTP

acnh38 · Juillet 17, 2024, 3:06

Bonjour,
Suite au post Mutualisation SMTP,
Suite à l’atelier du dimanche « Mutualiser l’envoi de mails » organisé par @bohwaz réfectoire 11h30 dont le CR se trouve sur campchatons2024 - Libreto (A date, petit problème pour l’accès en lecture, mais l’accès en écriture fonctionne),
Suite aux nombreux posts sur les difficultés rencontrées par les CHATONS pour envoyer des mails (https://forum.chatons.org/t/lancement-de-stalwart-smtp-un-serveur-smtp-moderne-et-integre/4636,https://forum.chatons.org/t/recherche-interface-web-pour-relai-smtp-sortante/3663, Orange/wanadoo retard : delivery temporarily suspended - je suis tout seul?, oMailgw pour gérer ces passerelles sortantes, …),

Nous proposons la création d’un Groupe de Travail SM2TP (Single Mutualized Mail Transfert Protocol). Cette proposition de nom pourra bien sûr changer. Une autre proposition a été faite : Bubble Mail.
Le but consiste à créer un service robuste pour garantir la bonne délivrabilité des mails envoyés et éviter le blacklistage de nos adresses IP, même pour des envois en masse.
Notons qu’il est d’ores et déjà envisagé de partager ce service avec les copain.e.s mais ce sujet fera partie des discussions et des décisions du GT comme les nombreux autres points qui restent ouverts.
Pour celles et ceux qui sont intéressé.e.s, merci de compléter le Framadate : Sondage - SM2TP - Mutualisation SMTP - Framadate (même si vous n’êtes pas disponibles aux dates proposées).
Pour celles et ceux qui auraient des questions, ce GT sera notamment présenté lors de la prochaine réunion mensuelle du lundi 12 août.
Même si ce sujet semble à priori technique, n’hésitez pas à venir. Il y a autant de questions politiques et organisationnelles que de questions techniques.
Bref, un beau projet en perspective qui nécessite une large contribution.
A très bientôt.

kepon · Juillet 17, 2024, 10:43

Merci pour le CR, j’ai lu avec attention et je me permet de corrigé ma partie :

Existence d’un CHATON qui propose un service : Omailgw par ~~retzien~~ (retzo). Fait de la surveillance, mais pas du côté mutualisé.

Je comprends pas bien le côté « mutualisé » pour le coup il est plutôt distribué. Les passerelles sont indépendantes, une interface web/api peut être central ou être multiple… ça a été pensé pour être mutualisé sur le papier.

Omailgw fait uniquement de l’analyse de log (a posteriori). Pas de surveillance a priori.

Si si, oMailgw est capable de réagir / fait de la surveillance, pour l’instant ça fait (que) des blackliste si le retour SMTP est « l’utilisateur n’existe pas » plus de X fois, alors blacklist (e-mail pas transmis) : config/rules.php · master · oMailgw / oMailgw-api · GitLab

acnh38 · Juillet 18, 2024, 12:35

Bonjour @kepon,
Il y a un vrai sujet pour savoir ce qu’on veut faire entre un service distribué et/ou mutualisé et/ou fédéré et/ou … Cela fait partie des propositions « politiques » que devra faire le GT.
Je n’ai pas regardé le framadate mais j’espère que tu auras un peu de temps à consacrer à ce GT qui pourrait effectivement s’appuyer sur oMailgw ou sur un REX de oMailgw, au moins pour une version 1.
J’en profite pour pinguer quelques personnes qui sont à priori sensibles à ce sujet : @ThomasC, @LautreG, @Adrien, @quentin, @Maxime, @whilelm, @sekil, @ljf, @tms, @chris2fr, @ManchotManosquin, @Meewan. N’hésitez pas faire suivre à celles et ceux que vous avez en visibilité.

kepon · Juillet 18, 2024, 1:24

Je vais essayer de participer, j’ai rempli le sondage date.

Mon commentaire était surtout là pour corriger, éclaircir ce que fait oMailgw vu que je n’étais pas là pour en parler… J’aurai l’occasion d’en parler plus dans le détail, mais j’ai pas d’intérêt particulier à ce que oMailgw soit repris ici / utilisé comme base… Si c’est le bon outil de départ c’est ça de moins à faire mais si c’est pas le cas je dormirai bien aussi. C’est un logiciel libre que j’ai mis dans le pot commun, il répond à mon besoin, je me suis dit que ça pouvait servir à d’autres mais si c’est pas le cas il répond quand même à mon besoin

oMailgw ça a été douloureux à pondre pour moi et j’ai dû mal à y remettre de l’énergie pour de nouvelle fonctionnalités (c’est pas les idées qui manques)
J’ai mis plusieurs mois à temps plein, avec un stagiaire sur 3 mois… (autant de temps de travail bénévole ou j’ai pas gagné de sous… mais surtout je pensai pas que ça allait être aussi long… sinon j’y serai pas allé ) on s’est bien pris le chou parce que c’est rempli de cas spécifique les logs de mails (ID de queue, pas d’ID parce que rejeté avant, ID non unique pour plusieurs envois…) bref… ça me fait penser que j’avais documenté ça ici : Log-Postfix.md · main · oMailgw / oMailgw-doc · GitLab (si jamais)

David

rodinux · Juillet 20, 2024, 10:34

Bonjour, nous sommes aussi très intéressés aussi pour contribuer à ce groupe de travail avec @Equipe_numericloud et aux réflexions autour de ce projet.

acnh38 · Juillet 20, 2024, 12:39

C’est l’été, tout le monde est chaud bouillant
Comme il y a déjà 6 candidats dispo (@Maxime, @LautreG, @Laurent, @sekil, @ManchotManosquin, @rodinux) le jeudi 25 juillet à 21h, je propose de faire une 1ere réunion.
Comme pour les réunions mensuelles, le temps sera surveillé : On ne dépasse pas 1h pour celles et ceux qui bossent le lendemain.
Dommage que @kepon ne le soit pas car il aurait pu présenter oMailgw à celles et ceux qui ne connaissent pas ou mal. Ça sera pour une prochaine fois.
J’ouvre un pad qui pourra servir d’OdJ et de CR : Etherpad Hadoly. J’essaie de le compléter d’ici jeudi mais toutes les propositions sont les bienvenues.
Faites du bruit autour de vous si d’autres candidat.e.s sont aussi chaud.e.s.

kepon · Juillet 20, 2024, 2:28

Oui désolé je suis a la montagne en famille… Si je trouve une connexion + que la négo familiale se passe bien je tache de me connecter mais rien de sûr…

acnh38 · Juillet 22, 2024, 12:27

J’ai commencé à remplir le pad d’Odj pour la réunion de jeudi : Etherpad Hadoly.
J’en profite pour pinguer @keo que j’ai retrouvé en relisant les différentes notes sur ce sujet. Désolé pour l’oubli.

bohwaz · Juillet 22, 2024, 7:52

Sauf erreur de ma part, oMailGW ne permet pas de bloquer un envoi vers une adresse blacklistée non ? Enfin je veux dire avant que le mail ne parte du SMTP local et ne transmette le mail au SMTP du destinataire.

J’ai modifié le pad en ajoutant des trucs que j’ai en tête, c’est encore très décousu, il va falloir affiner tout ça (dans ma tête ^^). Il faut que je me repenche sur oMailGW aussi du coup. Si d’autres gens connaissent d’autres solutions aussi, ne pas hésiter à les mentionner

J’ai noté le 25 juillet à 21h.

kepon · Juillet 23, 2024, 3:26

Si, enfin si je comprends bien ce que tu veux… Pour être plus clair je vais te donner un exemple :

On ajoute un blacklisté les mails qui sont refusés pour cause de « boîte mail inexistante » plus de 2 fois par défaut : config/rules.php · master · oMailgw / oMailgw-api · GitLab
Ensuite on distribue cette blacklistée aux passerelles. En utilisant smtpd_recipient_restrictions de postfix oMailgw / oMailgw-cli · GitLab :
- omailgw-cli travail dans les 2 sens… il sait donner ces logs, son spooler à l’API et recevoir des data : transport_map, blackliste, authentification SMTP…

mailquiexistepas@gmai.com 550 Recipient Blacklisted by rules UserUnknown

Ainsi si (par exemple) au Retzien, (qui fait passer son trafic SMTP par mes passerelles oMailgw) un utilisateur tente d’envoyer plus de 2 fois un e-mail à mailquiexistepas@gmai.com, la 3ème fois c’est la passerelle qui refusera le message et ça n’ira plus demander à gmai.com… Sorte d’auto-nettoyage de liste de mail… J’ai envisagé faire un TTL sur les blackliste, mais j’ai pas pris le temps et au final est-ce que c’est pertinent ? La question se pose… pas simple ce type d’arbitrage quand on automatise…

David

bohwaz · Juillet 23, 2024, 10:35

Ah oui j’avais loupé la blacklist dans postfix merci ! Par contre du coup si je comprends bien c’est des listes « statiques » donc on ne peut pas avoir un traitement différencié au cas par cas vu que les listes sont des fichiers textes mis à jour, et non des programmes appelés à chaque instance.

C’est effectivement un truc qui me semble super important pour améliorer notre délivrabilité à tous, par exemple chez un CHATONS qui aurait 100 mailings lists, une liste qui aurait l’adresse a@b.com inscrite : l’adresse est invalide, l’adresse est désinscrite de la liste, mais si 5 autres listes ont la même adresse inscrite, ça continuera à essayer d’envoyer, pour chaque liste… Et si l’adresse est réinscrite (import d’un carnet d’adresses par exemple) on renverra encore à une adresse invalide. Avoir une liste de blocage globale me semble donc super utile pour améliorer la délivrabilité d’un hébergeur.

Pour le TTL des adresses en hard bounce j’ai eu le cas chez Paheko : mail envoyé à une adresse le lundi, qui n’existait pas, mais créée le mercredi suivant… L’adresse était blacklistée car hard bounce (inexistante), mais devenue valide ensuite et voulant recevoir des mails…

Donc j’ai réglé le souci comme ça : on peut quand même envoyer un mail à une adresse en hard bounce (ou qui a trop de soft bounces, ou qui a fait un signalement pour spam), mais le seul mail qu’on peut envoyer c’est un mail généré par la plateforme du style « L’organisme XXX souhaite vous envoyer des e-mails. Cliquez ici pour confirmer que vous souhaitez recevoir ces messages : https://… ».

On ne peut pas envoyer ce type de mail plus d’une fois tous les X jours pour éviter les abus.

Merci du coup j’ai rajouté ce point à la liste des besoins / désirs dans le pad, parce que c’est important.

Pour info Amazon SES ont plusieurs niveau de blacklist :

global suppression list: c’est la liste qui s’applique à tous les clients, tu ne peux pas savoir si une adresses est dedans ou pas, mais si tu essaye d’envoyer à une adresse de cette liste, SES n’enverra rien en réalité (pour limiter son score auprès des destinataires), mais ça comptera dans ton quota d’envois à des adresses invalides. Une adresse reste dans cette liste jusqu’à 14 jours (plus il y a d’envois, plus ça reste longtemps, avec un max à 14 jours).
account-level suppression list: c’est la liste qui s’applique à ton compte client SES à toi, tu peux voir les adresses dans cette liste, les supprimer de la liste, mais si tu envoie et que ça bounce (ou que l’adresse est encore dans la global suppression list), ça joue dans ton score…

On pourrait s’inspirer d’un tel fonctionnement pour partager les adresses invalides entre nous, mais uniquement le hash (blacklist globale) pour préserver la vie privée, et avoir l’adresse en clair au niveau du CHATONS dès qu’il envoie un mail à cette adresse… Bon je réfléchit à voix haute là, c’est pas forcément super clair comme idée.

kepon · Juillet 25, 2024, 8:35

La liste sont mises à jours par le « cli » qui demande les infos à l’API, je suis partie du principe que le « cli » était « bête » et que c’est l’API le moteur… la liste est mise à jour dès qu’un y a une nouvelle entrée en liste noir ou blanche.

ça fait ça, a@b.com sera toujours refusé au routage par la passerelle en répondant le message SMTP 550 Recipient Blacklisted by rules UserUnknown tant que personne ne l’a ajouté en liste blanche ou supprimé de la liste noir.

Ok, pas simple simple à gérer mais c’est une idée.

Bonne idée !

Laurent · Juillet 25, 2024, 9:33

Bonjour à tous,

Déjà, j’ai bien noté que l’on se retrouve ce soir, 21h, pour la première réunion de ce GT, chouette

Je suis justement en train de préparer un petit mailing pour mon logiciel (annonçant une nouvelle mise à jour).
Et donc, je fais une passe sur les adresses en erreur (550, 450 ou même ‹ domain name not found ›) au précédent envoi, histoire de les virer pour « assainir » le nouveau.
Je m’apperçois que j’ai plusieurs adresse en « xxx@yyy.zzz.mailguardianpro.online », « xxx@yyy.zzz.webmaildirect.online », « xxx@yyy.zzz.mailsecurenet.online » ou « xxx@yyy.zzz.securemailboxnet.fun » et aucunes de ses adresses ne sont passées.
Du coup, je les enlève de mon prochain mailing.

Questions donc:

Est ce que ces domaines sont connus aussi chez vous comme « à problème » ?
Il y en a-t-il d’autres ?
Doit-on se faire une « black-list » des domaines douteux ?
Est-ce que ce genres d’actions simple ne seraient pas à identifier pour améliorer nos envois ?

bohwaz · Juillet 25, 2024, 9:50

Tous ces domaines semblent appartenir à la même personne, ont été créés très récemment, et semblent envoyer du spam : Stop Forum Spam Domain Report for nvda96.securemailboxnet.fun

Donc à mon avis c’est des spammeurs.

On pourrait faire un whois sur le nom de domaine et traiter comme suspect un domaine qui a moins d’un an d’existence.

Mais ici le serveur n’a même pas de MX dans son DNS, donc ça suffit à considérer comme spam. De mon côté je vérifie systématiquement que le domaine de l’adresse destinataire comporte bien un enregistrement MX.

De plus je blackliste les MX qui utilisent spamenmoins.com ou mailinblack.com, en effet ces providers demandent une validation manuelle de l’expéditeur (via un lien envoyé par mail, et un captcha à remplir) avant de pouvoir leur délivrer des mails. Ce qui est impossible à faire pour les mails de rappel de mot de passe etc. Avant j’autorisais ces services à l’inscription, mais après les gens ne pouvaient recevoir les mails donc maintenant je bloque toute utilisation de ces services, ça me limite le support.

pyg · Juillet 25, 2024, 12:27

Bon, j’avais dit en juin à @apascale que j’étais chaud pour rejoindre le copil SM2TP (avec des contraintes de temps, et sachant que ce n’est pas moi l’adminsys de Framasoft).

Cependant, on a eu des événements un peu (beaucoup) complexes à gérer à Framasoft :-/
C’est en train de se tasser, mais clairement, de mon côté, j’ai pris plusieurs mois de retard sur mon plan de charge salarié.

En conséquence, je suis en train de revoir mon plan de charge pour les 6/12 prochains mois, et… il va falloir que je fasse du tri dans mes engagements pour remettre Framasoft au cœur de mes actions et de mon temps de travail

Dans ce « tri », il m’apparaît assez clairement que ma participation au copil n’est plus appropriée.
Ca m’emmerde évidemment, d’abord parce que j’étais motivé, ensuite parce que ce projet me paraît important, mais aussi parce que j’aurai sans doute pu apporter des choses côté structuration et gestion de projets (qui reste mon métier quasi à temps plein).

Mais là, il faut que je prenne soin de moi (et de Frama), et ouvrir un nouveau chantier (nouvelles réunions, nouveaux CR, nouvelles idées à brasser, nouvelles propositions à mettre en œuvre, etc) ne me permettra pas de le faire correctement.

En conséquence, je préfère me retirer du copil (ça devrait avoir zéro impact, puisque je n’avais rien commencé ).

Cependant, si c’est OK, je propose de ne pas fermer la porte à double tour :

j’essaierai de suivre les messages/échanges ici, pour me tenir informé
je (et Framasoft) reste à votre disposition si vous avez des questions concernant notre infra (Je rappelais ici qu’on était en gros à 300 000 mails sortants par jour, ce qui a mon avis fait de nous le plus gros chaton en terme de mails sortants). Notre adminsys @Framasky est en congés jusqu’au 18/08, donc on sera pas hyper réactifs, mais si vous avez des questions, et ben ça sera avec plaisir qu’on essaiera d’y répondre.

Vala vala. Désolé pour ce « rendez-vous manqué », et je vous souhaite toute la réussite possible pour ce projet

Maxime · Juillet 25, 2024, 1:23

Hello @pyg !
Il y a en ce moment deux groupes de travail sur les mails :

un sur une campagne de com’ pour promouvoir les hébergeurs de mail alternatifs (c’est celui où il y a le COPIL)
un sur la mutualisation de portes de sortie SMTP (ce fil)

Du coup je note que tu n’es plus dispo pour le COPIL sur la campagne. Bon courage à vous côté Frama, on espère vous croiser vite <3.

sekil · Juillet 25, 2024, 6:53

Il y a un lien de connexion ?

Merci

bohwaz · Juillet 25, 2024, 6:59

J’ai trouvé ce lien là dans l’agenda nextcloud, qui semble générique pour les CHATONS : CHATONS

Mais je suis tout seul pour le moment ^^

ppom · Juillet 25, 2024, 8:08

La réunion vient de se terminer ! On a bien pris des notes, si des extés veulent savoir ce qui s’est dit, c’est ici : https://pad.hadoly.fr/p/SM2TP

@acnh38 tu nous as manqué ! Mais on s’est bien débrouillé pour cette première réunion, qui s’est finie avec 5 min de retard (je pense que ça va ). On s’est mis d’accord pour refaire une réunion la semaine du 19 aout. Est-ce que tu veux bien mettre à jour le framadate pour n’inclure que cette semaine, et on voit qui est dispo ?

acnh38 · Juillet 25, 2024, 9:45

Vraiment désolé de vous avoir fait faux bon.
C’est ça les retraités, incapable de gérer plus de 2 projets différents dans la même journée.
Je ne doute pas que vous avez autant avancé sans moi.
Je lirai le CR.
Je vous laisse le choix de l’amende