SM2TP : GT mutualisation SMTP

Groupes de travail Mutualisation SMTP
123

Je comprends l’exigence « chapeau » mais je me demande juste si c’est :

  • Utile (sécurité : même si oui la sécurité tu peux empiler les couches pour faire un milles feuilles c’est toujours plus de sécurité…
  • Ne serait-ce pas un frein à certain usage. Ou alors le rendre facultatif / paramétrable pour passer outre cette vérification ?
    • Personnellement quand un CHATONS vient dans l’urgence pour dire « j’ai un pépin vers ce @machin.com je peux plus envoyer, bloqué… tu peux router pour moi ? » ajouter une clé unique par domaine en plus du SPF dans le DNS ça me semble chronophage. Pas tant si t’as 5 domaine à gérer mais quand t’en a beaucoup ça commence à compter… Perso je ne sais pas combien j’ai de domaine entrant, certainement vraiment beaucoup (trop) pour envisager ce type de contrainte. Et j’ai pas parlé du fait que t’as parfois la main ou qu’il n’y est pas de technicien compétent sur une zone DNS. Là on part pour 20 échanges :sweat_smile:

Oui pour en parler mais pas sûr d’être disponible encore ce mercredi (le peut être que j’avais indiqué dans le sondage est toujours un peut êtres) Donc je m’exprime pour vous donner du grains pour la discussion.

Pour moi cet histoire de relayage/routage ça fait partie des points incontournable sur l’entraide, la fédération… C’était le sujet N°1 pour oMailgw, que j’avais en tête quand je pensai au CHATONS. En tout cas, tel qu’est utilisé mon service de passerelles par quelques chatons… c’est pour pallier à des problèmes temporaires vers x ou y domaines destinataires.

Aussi si t’as des problèmes d’un coup vers un (gros destinataires) qu’est-ce que tu fais ? Tu ferme la porte 25 pour plus faire entrer de message ? Ou tu as préalablement discuté avec les copains pour dire "moi je peux tout router mais j’ai besoin d’aide vers hotmail de temps en temps ça coince, le temps d’un déblackliste qui peut prendre 1 mois…)

Il me semble que c’était un point de l’enquête le fait d’être prêt à router tout ou partie, le fait de pouvoir aider ponctuellement ou non… si on met pas de mécanisme de relay/routage entre nous ça complexifie la chose sur ce point d’entraide.

Sur la data/monitoring oui ça complexifie un peu les choses. Moi j’ai réussi (je penses) à trier à partir du log. Mais c’est certain que ça complexifie cette tâche.

Sur la peur de la « boucle » pas de lézard, en tout cas sur un MTA tel que postfix ça rebondi pas longtemps. Voici un test de boucle :

Table de routage (omailgw) : j’ai créé une boucle avec le domaine destinataire mercereau.info

Sélection_020
Sélection_020938×549 71.3 KB

ça fait quelques rebond et ensuite j’ai un bounces

Action: failed
Status: 5.4.0
Remote-MTA: dns; mailgw2.retzo.net
Diagnostic-Code: smtp; 554 5.4.0 Error: too many hops

David

1 « J'aime »
124

OK

Je ne pense pas qu’il soit une bonne idée de traiter en urgence une telle demande, pour des raisons de confiance. C’est un risque pour le relai d’accepter de relayer des mails qui vont peut-être impacter sa réputation.

Maintenant il est vrai que c’est de la responsabilité de l’administrateur du relai. Si l’administrateur veut lever ces restrictions, libre à lui. Donc effectivement on peut le passer en paramétrable.

Je n’avais pas pensé à cette éventualité. A mon sens, il y a donc plusieurs cas :

  • Le cas normal : Le relai n’est pas blocklisté, donc il n’a pas besoin de relayer le mail à un autre relai.
  • Blocklisting récent : L’administrateur se rend compte que son relai vient de se faire blocklister, et que la queue d’émission est pleine de mails bloqués. La question est donc qu’est ce qu’on fait des mails en queue ?
  • Blocklisting ancien : L’administrateur veut continuer à relayer des mails mais en sachant que l’IP de ce relai sera refusée par certaines destinations. La question est donc qu’est ce qu’on fait dans ce cas ?

En face, on a plusieurs modes de fonctionnement :

  1. Relayage à 1 niveau (c’est ce à quoi je pensais, et je crois @bohwaz également) : Le MTA émetteur choisit un relai parmi une liste regroupant tous les relais qui lui sont accessibles (donc potentiellement plusieurs relais de plusieurs organisations), via un mécanisme de round-robin pondéré par le volume accepté par chaque relai.
  2. Relayage multiple interne : Comme dans le relayage à 1 niveau, le MTA émetteur choisit un relai parmi une liste regroupant tous les relais qui lui sont accessibles. Mais le relai peut retransmettre à un autre relai de la même organisation (notamment en cas de blocage).
  3. Relayage multiple externe : Comme dans le relayage multiple interne. Mais le relai peut transmettre à une autre organisation (notamment en cas de blocage).

Le mode 3 règlerait tous les problèmes mais me semble poser les problèmes politiques que j’évoquais. Je pense qu’on peut imaginer :

  • Accepter les modes 1 et 2 (mais peut-être ne fournir d’implémentation que pour le mode 1).
  • Définir un moyen de déclarer les domaines destinataires qu’un relai est capable de relayer.
  • Discuter de ce qu’on fait des mails bloqués en queue.

Il n’y a pas de boucle parce que tu as défini des règles explicites. J’ai peur d’une boucle dans le cas où on utilise le mécanisme SM2TP pour re-relayer le mail.

125

Oui, tu peux diffuser.

126

Désolé du retard de réponse j’ai pris 10 jours de vacances pour avoir un peu de soleil :slight_smile:

Pour moi ça ne pose pas de souci, la solution te permet de collecter tes propres bounces et bloquer les envois de tes utilisateurs sans faire baisser ton score chez les destinataires, sans partager, et c’est déjà une plus-value par rapport à ce que propose un SMTP classique. Donc il suffit de pas se fédérer pour n’utiliser ça que pour soit, c’est pas un souci je pense.

Bof, ça me fait pas trop peur, c’est un protocole assez simple à implémenter quand même. Mais si y’a déjà un truc maintenu avec un bon historique, genre go-smtp, autant l’utiliser.

Disons que s’ils avaient été conçus pour être extensible et correspondaient à notre besoin je ne serais pas contre, mais c’est sûr que c’est un pari. On veut une solution qui marche encore dans 10 ou 20 ans, donc se baser sur un projet jeune, c’est un pari risqué, si le dév cesse on est coincés.

Je suis d’accord, pour moi il ne faut pas permettre le re-relayage. Si un relais « partenaire » n’est pas capable de relayer un message, pour raison X ou Y (genre on est bloqués par free.fr, on ne relaie donc pas les mails vers free.fr), il doit refuser le message, et le relais original doit trouver une autre solution pour envoyer le message (par exemple utiliser un autre relais, ou l’envoyer lui-même).

Faire des chaînes de relais c’est le meilleur moyen de se retrouver dans des boucles, ou des galères à debug.

Donc router via un niveau de relais partenaire oui, mais que ce partenaire puisse relayer à d’autres derrière, non.

Je pense qu’il y a une incompréhension avec @kepon ici. Oui on veut bien router le trafic mail des copains (1 niveau de relais), mais on ne veut pas que ces copains renvoient nos mails à d’autres serveurs qu’on ne maîtrise pas (2+ niveaux).

Pour les boucles il y a des mécanismes pour gérer ça, on peut ajouter un header et le détecter par exemple.

127

Alors, vous trouverez sur ce lien une version augmentée du fichier de résultats : S’identifier – Nextcloud

J’y ai ajouté 3 onglets où je croise les réponses aux sections hard bounces, soft bounces et plaintes avec les features définies dans le CDC pour ces sections.

Note: Onlyoffice n’affiche pas le coloring des cellules que j’ai fait avec LibreOffice, il faut télécharger le fichier si vous voulez l’avoir.

128

Pas compris ça me fait télécharger le PDF du résumé fait par alain l’autre fois ?

129

Désolé, mauvais lien. Voici le bon : S’identifier – Nextcloud

1 « J'aime »
130

Bonjour à tous,
J’ai ouvert le BigBlueButton
A tout de suite.

131

@kepon tu décris précisément notre cas d’usage, ça compte pour nous de pouvoir rentrer sans modifier des dizaines de domaines, dont on gère pas forcément les DNS nous-même.

132

On a éclairci ce point dans la réunion de ce soir (je pense) : il ne s’agit pas de rajouter qq chose au DNS. Il s’agit simplement de vérifier que le SPF du domaine expéditeur n’empêche pas le relais sortant d’envoyer le mail.

Donc normalement tu n’as rien à modifier d’autre que t’assurer que le SPF est OK vis à vis de l’IP du relais sortant. Si le SPF n’est pas OK, ton mail sera de toutes façons bloqué au niveau du SMTP des destinataires (s’ils sont bien configurés), donc autant le bloquer au niveau du relais de sortie pour te prévenir en amont, avant de pourrir ton score auprès des SMTP destinataires.

2 « J'aime »
133

Désolé j’ai dû quitter la réunion un peu tôt. Ça serait chouette d’enregistrer les réus, pour pouvoir suivre ensuite quand on n’est pas dispo, car ça sera pareil pour la prochaine, je suis pris tous les mercredi soir à 20h10.

Merci beaucoup @sekil et @acnh38 pour la gestion, les notes, le CdC !

Sur la vérification de MX, la RFC 822 demande qu’un serveur SMTP doive avoir une adresse postmaster@domaine, de plus on peut dire qu’il est risqué d’envoyer des mails avec un domaine expéditeur qui n’a pas de MX. Mais je peux penser à des cas où le MX n’existe pas, genre pour tester des envois en local, donc le mieux est de pouvoir désactiver cette vérification.

J’ai rajouté une note dans ce sens dans le cahier des charges.

Question sous-jacente : est-ce qu’on veut vérifier nous-même que l’adresse expéditeur existe dans le MX du domaine expéditeur (donc faire le verification callback nous-même) ? (je dirais non perso)

Re-routage : Après la réunion de ce soir je pense qu’il existe une incompréhension entre nous sur la position et le rôle du relais « local », et notamment la question du re-routage.

Ce que j’appelle le relais « local » c’est l’instance du « logiciel SM2TP » sur ton infra (sur ta machine, sur une autre machine, peu importe).

Dans mon esprit, c’est ce relais local qui détermine quoi faire du message qu’il reçoit, selon des règles configurées de :

  • soit contacter directement le SMTP du domaine destinataire pour envoyer le mail
  • soit transférer le message à un relais « partenaire », qui lui sera en charge de remettre le mail au SMTP du domaine destinataire

Dans le cas ou le relais « partenaire » sélectionné refuse de transmettre le mail (par exemple avec une erreur 5xx + un message d’erreur spécifique), le relais « local » reconsidère quel relais utiliser. Si aucun autre relais « partenaire » n’est disponible, soit le relais « local » fait l’envoi lui-même soit il refuse le message en mode « je ne peut pas envoyer ce message, aucune route n’est dispo » (ou, éventuellement, le logiciel SM2TP conserve le mail en queue et remonte une erreur au sysadmin en mode « j’ai des mails, je sais pas quoi en faire, intervention nécessaire »).

À aucun moment le relais partenaire ne peut transférer ce message à un autre relais. C’est le relais « local » qui décide par où passe le mail. Cela permet de conserver la confiance (on sait que le relais partenaire ne fait pas passer nos messages par un tiers qu’on ne connaît pas), et simplifier les choses.

Voilà pour régler la question du re-routage.

Pour la question du DKIM, l’incompréhension se pose du fait que vous avez une vision « sysadmin », moi j’ai une vision dév. Dans le contexte d’un dév, je branche directement mon NextCloud (par exemple) sur le relais SM2TP « local », en indiquant le host, le port, username et mot de passe SMTP. NextCloud ne gère pas le DKIM. Donc c’est au serveur SM2TP de faire la signature DKIM. C’est le cas d’un gros nombre d’applicatifs.

Pour moi le but de SM2TP c’est de remplacer SES, Tipimail, etc. qui fournissent un service « prêt à utiliser » : tu configure le serveur SMTP, et ça marche, bien sûr après avoir modifié tes DNS pour intégrer les enregistrements SPF et DKIM du service.

Si on doit installer et configurer un « middleware » qui va faire de la signature DKIM devant SM2TP, ça complexifie grandement la stack et les risques de soucis.

D’ailleurs dans plein de cas d’utilisation, on n’aura pas d’autre SMTP sur notre machine / réseau, car on ne fait que de l’envoi de mail, pas de réception.

Donc pour moi il faudrait pouvoir dire que le relais local accepte de signer le DKIM pour un domaine. Mais à aucun moment un relais « partenaire » ne doit signer les mails transmis par un autre relais. (toujours la question de confiance)

Donc pour résumer pour moi, et dans ma compréhension initiale du projet, le relais local est l’orchestrateur : il reçoit les mails, des applicatifs, fait les vérifications, et route les mails, soit lui-même, soit vers un relais partenaire.

J’ai l’impression que sur ce point on n’a pas forcément compris la même chose ?

134

Du coup je pense aussi qu’il y a confusion dans le CdC sur le nommage, entre le rôle du relais local, et le rôle du relais partenaire.

Dire juste « le relais » me semble trop vague, on ne sait pas de qui on parle.

135

Oui ce point à été éclaircie de vive voix comme le dit @bohwaz , j’avais compris « chapeau » comme vérification préalable en fait c’était plus un « titre, sous titre » (je sais pas si c’est plus clair comme ça :-p )

Ok, c’est compris / acceptable pour moi

L’angle mort que je vois c’est : s’il y a des messages déjà dans un relais en spooler (donc accepté, 200…) et qui sont maintenant impossible à envoyer (typiquement Free quand il blackliste il refuse les messages) comment sont-il traité ? Pour moi le plus simple serait à ce moment de faire du re-routage.

J’entends le besoin, c’est pas déconnant. Et ça me semble pas hors de porté d’implémenté opendkim ou autres trucs qui c’est faire…
Mais ça complexifie la couche de vérification préalable à l’acceptation du message. ça ajoute un cas possible…

Carrément, je pense qu’a la réunion ça nous a perdu.

Note : ne pourrait-il pas y avoir des cas d’usage ou un utilisateur de la fédération n’a pas(/plus - temporairement ou jamais eu) de relais local ?

2 « J'aime »
136

A vos agendas : La prochaine réunion a été fixée au mercredi 20 novembre à 19h toujours sur le BBB : Poursuite de la revue du CdC.
Merci à tout.es pour vos contributions.

1 « J'aime »
137

Bonne question !

On pourrait imaginer que le relais « local » garde les messages qu’il transmet au relais « partenaire » tant que le relais partenaire n’a pas remonté l’info « c’est bon j’ai envoyé au SMTP destinataire, il a dit 200 OK ». Comme ça si le relais est finalement bloqué, le relais local peut décider de ré-essayer autrement.

Ça fait que c’est toujours le relais local qui a la main, le relais sortant « partenaire » lui est « bête » : il ne fait que router le mail, et renvoyer le résultat au relais local d’origine. Et pas besoin de re-routage : c’est le relais « local » qui éventuellement décide de passer par un autre relais, ou envoyer lui-même, ou autre solution.

Oui en fait il faudrait simplement dire : pour tel domaine, tu signe tous les mails avec DKIM (quitte à écraser si c’est déjà signé avec DKIM). Pas de vérification, pas de cas additionnel à gérer : beaucoup plus simple.

Go par exemple dispose d’une librairie (tierce) pour signer en DKIM : dkim package - github.com/emersion/go-msgauth/dkim - Go Packages

Idem pour les autres langages j’imagine. Donc potentiellement pas grand chose à rajouter.

Hum je ne vois pas dans quel cas ça peut arriver, mais c’est un cas qu’on n’a pas à gérer, si tu n’as pas de relais local, c’est comme si t’avais désinstallé ton postfix : tu peux plus envoyer de mails.

Par contre si tu veux parler du cas d’un relais partenaire : « il a eu un relais, on lui a confié des mails par le passé, mais là il répond plus », oui il faut prévoir le cas, en mode « relais injoignable » et donc ne pas réessayer de relayer par lui pendant un temps qui s’allonge progressivement, jusqu’à complètement bloquer.

Mais si tu n’as pas de relais local, ben vu que c’est le relais local qui gère tout, tu ne peux plus rien faire…

138

Pour clarifier les choses je suggérerais de changer dans le CdC :

  1. rajouter la définition « MTA émetteur = logiciel émettant un message sortant, exemple : serveur SMTP (postfix, Exim, etc.), logiciel spécifique à l’usage mail (Sympa, RoundCube, SoGo, etc.), applications ayant besoin d’émettre des mails (NextCloud, etc.) », pour clarifier qu’on ne parle pas forcément d’un logiciel SMTP
  2. transformer « le relai » en « le relais local » partout sauf où il est question du relais partenaire, dans ce cas indiquer « relais partenaire »

Exemple :

  • [M] Le relai ne peut transférer un message qui lui est soumis à un autre relai

Serait transformé en :

  • [M] Le relais partenaire ne peut transférer un message qui lui est soumis à un autre relais.

Si vous avez de meilleurs mots à mettre sur « relais local » et « relais partenaire » n’hésitez pas, j’ai pas trouvé mieux pour le moment.

Je ne touche pas pour le moment en attendant l’avis de @sekil :slight_smile:

139

Du coup si je comprends bien dans ton esprit le « relai local » c’est Postfix (+ un petit quelque chose) et/ou le dev de 0 d’un SMTP.
Dans ce cas je comprends pas bien pourquoi tu veux que le relai local puisse signer DKIM s’il te faut un Postfix (ou autre) pour pouvoir envoyer sur la fédération c’est pas beaucoup plus compliquer de brancher opendkim ou autre qui signe en DKIM sur postfix (ou autre).

J’avoue que plus on en parle, plus ça s’assombrir pour moi / ou ça soulève de nouvelle interrogation / truc que j’avais compris de travers…

  • Le relais local est indispensable à l’envoi de message sur la fédération
  • Le relais local peut envoyer directement les messages sans passer par un relai partenaire ?
  • Est-ce qu’un relai local peut être aussi un relai partenaire ?

Ok. ça serait à tester mais ça me semble périeux en ressources. ça veut dire que tu conserve une connexion SMTP ouverte durant tout le traitement (vérification diverse + l’anti spam ça peut être long + DNSBL… + réponse du relai de l’opérateur contacté) et tu met en parallèle ça sur le nombre de mail qui arrive… Certain opérateur n’aime pas être re-contacter trop vite (orange par exemple) donc si t’as mis des règles en ce sens et que tu as 2 mails orange coup sur coup c’est des secondes…
J’ai pas connaissance de SMTP qui fonctionne sans spooler mais je me dis qu’il y a peut être une raison à ça…

David

140

Oui.

Oui. C’est lui qui récupère les blocklists notamment.

Oui.

141

Pourquoi garder la connexion ouverte ?

Le relais partenaire reçoit le message, le met dans sa queue, dit « OK reçu », et recontacte le relais original lorsqu’il a envoyé (ou que ça a foiré). C’est asynchrone.

142

Je parle dans le cadre où SM2TP est un logiciel séparé. Si c’est un postfix, alors oui tu peux brancher des trucs en plus. Mais à voir comment ça interagit avec les vérifications.