SM2TP : GT mutualisation SMTP

[kepon]

@sekil

En fait c’est un peu une exigence chapeau, dont la vérification SPF serait une sous-exigence. Mais je suis d’accord sur le fait que ce n’est pas forcément clair. Si ça te va, je te propose que ce soit discuté lors de la réunion.

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

@sekil

C’est déjà et avant tout l’interdiction à relayer vers une autre organisation. Il y a plusieurs problèmes à autoriser le re-relayage :

• Risque de boucle de relayage : le relai va relayer vers un autre relai qui risque de relayer à nouveau, etc.
• Problème de confiance : Le principe de la fédération est de partager les données et ressources avec des partenaires de confiance. Cette confiance n’est pas transitive, donc l’organisation émettrice ne fait pas nécessairement confiance aux partenaires auxquels l’organisation relayeuse fait confiance.

Je pense que tu te poses la question surtout sur un relayage interne vu la manière dont ton système est architecturé. Là dessus, je n’ai pas une opinion forte, mais je vois quand même des risques également :

• Complexité sur la chaine d’émission : Autoriser le re-relayage risque de complexifier la chaine de relayage et rendre le debug plus difficile.
• Complexité sur l’architecture du relai : Les fonctionnalités du relai sont réparties sur la chaine de relayage du mail, depuis son entrée jusqu’à sa sortie, avec des fonctions de supervision. Je ne sais pas l’impact que cela risque de causer.

Je pense qu’il faut qu’on en discute, dans quelle mesure cette restriction serait un problème.

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

ç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

[sekil]

@kepon

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.

OK

@kepon

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

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.

@kepon

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

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.

@kepon

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.

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.

[sekil]

@acnh38

Bonjour @sekil,
La prochaine réunion est après-demain, mercredi.
Es-tu Ok pour que je diffuse l’adresse du CdC dès maintenant à celles et ceux qui ont répondu au sondage et qui ne sont pas forcément branché.es sur le forum ? Ça sera autant de temps de gagné pour celles et ceux qui ne découvriront pas le doc en séance.
Si oui, je propose de supprimer l’ancienne version que tu as laissé en fin de document pour ne pas ajouter de confusion.
Dans l’attente de ton retour.

Oui, tu peux diffuser.

[bohwaz]

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

@sekil

Concernant les démons SMTP que tu cites, je dois admettre que je n’en connais aucun. Sans vouloir mettre en cause le sérieux avec lequel ils ont probablement été écrits, se baser sur un MTA inconnu au bataillon (c’est à dire peu éprouvé) suscite en moi le même niveau de confiance que le fait de ré-implémenter nous-même un nouveau MTA.

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.

@sekil

Utiliser une librairie SMTP existante : Je n’ose pas croire que @bohwaz avait en tête de ré-implémenter le protocole SMTP.

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.

@sekil

Sachant qu’il faut être clair qu’on ne peut pas contenter tout le monde, à la lecture des résultats, il est clair que certains répondants n’adhèrent pas aux éléments déterminants du projet (à savoir le partage des données de bounces à une fédération).

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.

@sekil

C’est déjà et avant tout l’interdiction à relayer vers une autre organisation. I

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.