Je comprends ta frilosité. Haraka a 12 ans et doit être très éprouvé, mais stalwart et kumomta sont très récents.
Le seul dont j’ai entendu parler en production autour de moi, c’est stalwart, qui est utilisé par Ecomail.fr (administré par @NathanH).
Lors de la réunion, on a évoqué les limitations liées à l’architecture décrite actuellement, et les alternatives. J’avais indiqué que je ferais une analyse des différentes options et des implications.
Voici mon analyse que j’ai essayé de faire la plus complète et neutre que possible. Je répondrais à vos posts dans un autre message.
Limitations
Impact sur l’infra de l’émetteur
En l’état du CDC, on doit éviter au maximum de modifier l’infrastructure de l’émetteur. L’installation de logiciels complémentaires sur l’infra de l’émetteur, ou la nécessité d’utiliser un relai local viendrait en contradiction avec cette contrainte.
Choix dynamique du relai depuis le MTA émetteur
En l’état du CDC, le MTA émetteur doit sélectionner un relai parmi une liste de ses relais déclarés. Ce choix peut être simple (liste séquentielle), mais les fonctionnalités peuvent exiger un choix plus complexe (e.g. round-robin sur l’ensemble des relais déclarés pondéré en fonction de leur volume), ou encore de tenter d’émettre le mail localement avant de relayer. Enfin, le mécanisme de relayage doit permettre de sélectionner le relai suivant dans le cas où le relai sélectionné refuse le mail. En fonction de l’implémentation utilisée en tant que MTA et du mécanisme de choix, cela peut nécessiter de placer de l’outillage côté MTA émetteur.
Exemple : Postfix permet la configuration de plusieurs relais, et itèrera sur la liste des relais s’il reçoit un connection refused ou un soft-bounce (code SMTP 4xx). Postfix permet également de configurer des relais en fallback, dans le cas où il n’aurait pas réussi à émettre lui-même le mail. En revanche, pas de possibilité de pondérer la liste ni round-robin. D’autres implémentations telles que opensmtpd sont réputées comme plus basiques et il n’est pas certain qu’elles permettent ces comportements.
Limitations d’usage du relai
Un relai peut ne pas être en mesure d’émettre vers certains domaines destination, par exemple parce qu’il sait que sa réputation vers ces destinations est insuffisante. Le relai peut également avoir des limitations dans le volume de traffic qu’il est en mesure de traiter et transmettre. Ces limitations d’usage peuvent être implémentées lors de la phase d’acceptation du mail par le relai, en émettant un soft-bounce (code 4xx) lorsque le relai ne supporte pas la destination ou le volume de traffic.
Auquel cas, le MTA émetteur sélectionnera le relai suivant (à condition que ce comportement soit supporté par l’implémentation du MTA émetteur).
Gestion d’un mail rejeté (soft-bounce/blocklist)
Dans le cas où le relai figure dans une liste de blocage ou a une réputation insuffisante pour passer des mails à une destination, les MX de cette destination répondront systématiquement un soft-bounce ou hard-bounce. Dans ce cas de figure, soit on autorise le re-relayage automatique, auquel cas le mail sera transmis à un autre relai, soit le mail va rester en queue d’émission, sans possibilité d’être transmis. Auquel cas, seul un acte d’administration et un re-relayage des mails bloqués peut permettre de vider la queue.
Propagation d’un mail non-conforme
Un mail non conforme peut entrainer le rejet (soft ou hard bounce) et la baisse de réputation d’un relai. Dans le cas où un re-relayage automatique est utilisé, ce mail pourrait propager une baisse de réputation à l’ensemble des relais et leur mise sur liste de blocage par le destinataire. La propagation d’un mail non-conforme pourrait donc amener à faire placer de très nombreux relais sur liste de blocage.
Boucles de relayage et traçabilité
Le re-relayage peut entrainer des effets de boucle dans le cas où tous les relais seraient incapables d’émettre le mail. Le mail se retrouverait à boucler indéfiniment dans l’infrastructure de relai. Comme discuté en réunion, une telle boucle peut être évitée en parsant les headers Received du mail et en détectant le HELO du serveur ou le nombre de hops.
Par ailleurs, le re-relayage peut rendre la traçabiité de l’émission du mail plus difficile dans la mesure où il est nécessaire d’aller consulter les logs sur l’ensemble des relais pour comprendre son parcours et identifier les problèmes associés à ce mail.
Confiance émetteurs/relayeurs
Afin de faciliter la mise en oeuvre de la fédération d’un point de vue organisationnel, la participation des émetteurs et des relayeurs se fait sur la base d’accords gré-à-gré. Ces accords impliquent une confiance réciproque : L’organisation émettrice fait confiance aux organisations relais pour transmettre ses mails en respectant la vie privée de ses usagers, l’organisation relai fait confiance aux organisations émettrices pour ne pas émettre de contenu malveillant. On peut se trouver dans une situation dans laquelle une organisation relai ne fasse pas confiance aux mêmes organisations que ses organisations émettrices, parce qu’elle n’auront pas conclu les mêmes accords.
Dans ces conditions, un re-relayage d’un mail d’une organisation relai vers une autre organisation relai peut entrainer une rupture de la confiance.
Contraintes fonctionnelles sur le MTA émetteur
Le CDC SM2TP impose des exigences sur le mail pour qu’il puisse être accepté par les relais. Cela impose des contraintes fonctionnelles sur le MTA émetteur, telles que la nécessité d’appliquer une signature DKIM au mail. Le mail ne peut donc être soumis directement par n’importe quel MTA à un relai sans préparation préalable.
Options de mise en oeuvre
1/ MTA émetteur → Relai, re-relayage interdit
Correspond au schéma (simplifié) actuel : https://framagit.org/chatons/sm2tp/-/wikis/uploads/b51d3eff246f47ed74f0daff43c7650d/sm2tp.png
Le MTA émetteur prépare le mail conformément aux exigences du CDC SM2TP de manière à ce qu’il puisse être accepté par les relais (e.g. signature DKIM). Il émet le mail lui-même ou transmet son mail directement à l’un des relais participant à la fédération SM2TP. Le relai doit émettre le mail lui-même, tout re-relayage est interdit.
2/ MTA émetteur → Relai, re-relayage intra autorisé/automatisé
Idem option 1, à l’exception que le relai est autorisé à relayer le mail à l’intérieur de son organisation. Ce re-relayage peut être automatique.
3/ MTA émetteur → Relai, re-relayage inter autorisé/automatisé
Idem option 1, à l’exception que le relai est autorisé à relayer le mail à l’intérieur ou l’extérieur de son organisation (au sein de la fédération). Ce re-relayage peut être automatique.
4/ MTA émetteur → Relai local → Relai distant
Le MTA émetteur n’a pas besoin de préparer le mail de manière à ce qu’il respecte les exigences fonctionnelles du CDC SM2TP (ou du moins les exigences associées sont réduites). Il transmet le mail à un relai local, qui applique les exigences du CDC SM2TP, puis décide d’émettre lui-même le mail vers la destination ou bien de le transmettre à un autre relai.
Le relai local participe par ailleurs à la fédération de relais.
Matrice impacts option/limitations
| Option de mise en oeuvre | Impact sur l’infra de l’émetteur | Choix dynamique du relai | Limitations d’usage du relai | Gestion d’un mail rejeté | Propagation d’un mail non-conforme | Boucles de relayage et traçabilité | Confiance émetteurs/relayeurs | Contraintes fonctionnelles sur le MTA émetteur |
|---|---|---|---|---|---|---|---|---|
| MTA émetteur → Relai, re-relayage interdit | OK | TBD (2) | OK | TBD (3) | OK | OK | OK | TBD (7) |
| MTA émetteur → Relai, re-relayage intra autorisé/automatisé | OK | TBD (2) | OK | TBD (3) | TBD (4) | TBD (5) | OK | TBD (7) |
| MTA émetteur → Relai, re-relayage inter autorisé/automatisé | OK | TBD (2) | OK | OK | TBD (4) | TBD (5) | TBD (6) | TBD (7) |
| MTA émetteur → Relai local → Relai distant | TBD (1) | OK | OK | TBD (3) | OK | OK | OK | OK |
Notes :
- (1) La contrainte d’installer un relai local instaure une contrainte sur l’infra de l’émetteur et/ou contraint l’émetteur à mettre en oeuvre un relai.
- (2) Un choix dynamique du relai n’est pas possible sans instrumentation du MTA émetteur. Un choix simple du relai est possible dans la mesure où le MTA le permet.
- (3) La gestion d’un mail rejeté peut nécessiter une action d’administration. Dans le cas où le re-relayage intra-organisation est autorisé et automatisé, cette gestion peut être limitée au cas de figure dans lequel aucun des relais n’a pu délivrer le mail.
- (4) L’automatisation du relayage peut entrainer une propagation d’un mail non-conforme et la mise sur blocklist.
- (5) Une boucle de relayage peut être évitée en configurant un hop-limit (supporté de base dans postfix par exemple). En revanche, l’autorisation d’un re-relayage peut rendre la traçabilité plus difficile.
- (6) L’autorisation du relayage inter-organisation est susceptible de rompre la confiance entre l’émetteur et le relai.
- (7) Le MTA émetteur doit implémenter les contraintes fonctionnelles avant de pouvoir transmettre le mail à un relai.
Vérification du MX
Pour moi si la RFC l’exige, il faut qu’on l’exige et qu’on le vérifie, parce que ça fait potentiellement partie des choses que les destinataires vont vérifier.
Par contre ça ne me parait pas nécessaire de vérifier que l’adresse expéditeur existe. II me semble qu’il n’est pas anormal d’émettre des mails depuis des adresses inexistantes.
Sélection du relai et re-routage
Alors, cette notion de relais local est une notion inédite par rapport à ce qui est décrit actuellement, et donc effectivement ce que tu dis @bohwaz est plus compréhensible à la lumière de cette notion. J’ai intégré cette option dans le tableau pour pouvoir comparer avec les autres options évoquées.
Je comprend de ta proposition qu’il s’agit d’un noeud relai (donc participant en tant que relai à la fédération) mais servant en même temps de MTA émetteur et de point d’entrée vers la fédération. Pour être plus précis, je comprend qu’il n’y aurait qu’un seul type de noeud (et donc une seule implémentation), la différence se trouvant plutôt entre est-ce que le mail est une soumission initiale (la soumission d’un mail au relai local) et ou une soumission relai (la soumission d’un mail du relai local vers le relai partenaire). Les fonctionnalités du noeud changent alors en fonction de si le mail est une soumission initiale ou une soumission relai.
Je pense que cette option peut être intéressante. Elle amène des contraintes particulières, notamment le fait que l’émetteur doit déployer un noeud relai dans son infrastructure pour pouvoir émettre des mails (contrainte qu’on peut tout à fait considérer comme légitime), mais d’un autre côté elle peut éliminer ou simplifier d’autres limitations.
La question du mode de sélection du relai est un autre sujet même si connexe à celle-ci. En l’occurrence, comment est-ce que le MTA émetteur (ou le relai local) doit choisir son next-hop. Il est clair que cela nécessite au minimum de la configuration, voire de l’instrumentation du côté de l’émetteur, et cela dépend du niveau de complexité du fonctionnel que l’on veut supporter et des fonctionnalités du MTA. J’ai clairement négligé de traiter ce point dans le CDC et il faudra donc en discuter en réunion.
Hormis quelques détails, l’algorithme que tu décris @bohwaz est également celui que j’avais en tête. Pour vérifier la compatibilité avec les implémentations existantes, j’ai fait des tests et des vérifications sur Postfix. En terme de configuration il est possible soit de faire émettre le mail localement et utiliser les relais en fallback, soit utiliser uniquement les relais. Dans les deux cas il itèrera sur la liste des nexthop en cas de connection refused ou de soft-bounce. On a donc, au moins sur 1 implémentation de MTA, un comportement compatible avec cet algorithme.
Un tel fonctionnement me semble non-conforme avec SMTP et hypothèquerait définitivement la possibilité d’utiliser une implémentation MTA standard pour mettre en oeuvre le relai, pour traiter un cas qui doit relever de l’exception. Sur les implémentations standard, lorsque le mail est accepté par un MTA (le relai), il est supprimé de la queue d’émission de l’émetteur. Le comportement que tu décris implique donc de garder en queue un mail qui a pourtant été accepté par le pair.
Après une réflexion sur le sujet, j’ai imaginé un fonctionnement que l’on peut implémenter avec un MTA standard (je vous ai déjà parlé de Postfix, je ne me souviens plus ? 
).
En résumé, il s’agit pour le relai de re-soumettre le mail à l’émetteur dans le cas où il n’a pas réussi à l’envoyer :
-
Le MTA émetteur (ou relai local) soumet son mail au relai
-
Le relai vérifie s’il est en mesure de le transmettre (cf diverses vérifications décrites dans le CDC)
-
Si OK → le relai l’accepte avec un 200 OK
-
Le MTA émetteur (ou relai local) supprime le mail de sa queue d’émission
-
Le relai tente d’émettre le mail
-
Si NOK → le relai le garde en queue
-
Le relai re-soumet le mail qu’il n’a pas réussi à envoyer, au MTA émetteur (ou relai local) sur un accès spécial
Cet algorithme implique simplement de prévoir un compte spécial dans le MTA émetteur (ou le relai local) permettant au relai de lui « rendre » le mail s’il n’a pas réussi à le transmettre. Pour moi, il s’agit d’un événement exceptionnel qui implique une action manuelle d’administration, mais on peut éventuellement automatiser si besoin.
Support DKIM
Si tu regardes les résultats du questionnaire, tu remarqueras que la grande majorité des répondants ont déjà mis en oeuvre le support DKIM via leur propre infra (très majoritairement basée sur Postfix). Je ne veux pas remettre en cause ton usage ni tes besoins, mais il faut reconnaître que le mail est une activité de sysadmin et qu’il requiert une « infra de sysadmin » et que la majorité des personnes susceptibles de mettre en oeuvre le projet sont des sysadmin. J’ai l’impression que tu veux ajouter dans le projet la fonctionnalité de simplifier la mise en oeuvre et l’administration d’une infra mail, mais pour le coup ça fait beaucoup dévier des objectifs initiaux.
Je ne sais pas exactement ce que tu entends par un middleware dans ce contexte particulier. Ce que je peux te dire, c’est que pour la mise en oeuvre de la signature DKIM, le sysadmin classique va installer et configurer un démon OpenDKIM et le connecter en mode milter à son MTA (en général Postfix), et que ça lui prendra quelques dizaines de minutes.
Maintenant, si on opte pour une archi relai local/partenaire, je n’ai rien contre le principe d’intégrer la signature DKIM, mais pour moi c’est une fonctionnalité clairement optionnelle et non prioritaire car elle existe déjà dans les infrastructures existantes. Il faut se concentrer sur les fonctions qui n’existent pas déjà dans les infrastructures actuelles.
Divers
Alors, pour le moment, nous n’en sommes pas là. Après que tu sois parti de la réunion, @bohwaz, la question du re-routage a été discuté et on a identifié qu’il y avait plusieurs blocages sur le fond. Il a été convenu que j’analyse les différentes options (mon post précédent) et qu’on en discute. On appliquera des modifications au CDC lorsqu’on aura mis les choses au clair.
Merci @ppom pour ton retour d’expérience.
Oui, tant que c’est désactivable, parce que sinon pour tester sur un réseau local ça risque d’être chiant s’il faut installer un serveur DNS en plus.
+1
Désolé du coup c’est que je me suis mal exprimé car dans ma tête ça a toujours été comme ça, d’avoir une solution « tout en un ».
Pas tout compris par rapport à postfix, j’espère qu’on pourra en reparler en visio pour que ça soit clair pour moi.
Je crois pas que le protocole SMTP demande explicitement à ce que le relais supprime le mail une fois qu’il est remis au destinataire ?
Mais on est ici dans un cas très particulier, où on envoi le mail à un relais. La logique des serveurs SMTP actuels (sauf erreur de ma part) c’est que si le relais ne peut pas remettre le mail au destinataire, il renvoie une erreur au Return-Path (en résumé), et que c’est à l’expéditeur de réessayer. Mais ici l’expéditeur n’a pas la main sur le chemin du mail, c’est le relais local qui choisit le routage du mail.
Mais effectivement c’est pas le fonctionnement « normal » d’un postfix/Exim. Ton idée est intéressante mais j’ai peur que ça mène à une boucle du coup, si le relais « local » n’a pas compris que ce mail a déjà été routé auparavant. C’est pour ça que dans ma tête un soft spécifique fait sens, car dans ce cas il suffit d’enregistrer que telle route a été utilisée pour tel mail. Si le mail revient comme non délivré, alors le relais local recommence son choix de routage, en éliminant cette route qui a déjà été essayée, jusqu’à ne plus avoir aucune option de routage.
Après là on est clairement dans un fonctionnement plutôt avancé, ça ne me paraît pas du tout essentiel que la solution fasse ça dès le début. Par contre renvoyer le mail à l’expéditeur en mode « ah ah démerde toi » ne me semble pas acceptable non plus. Donc renvoyer le mail dans une queue spéciale du relais local, en mode c’est à l’admin sys de trouver une solution pour les mails dans cette queue, me semble tout à fait acceptable.
Pour résumer :
- pouvoir renvoyer les 2000 mails refusés via une autre route, manuellement = OK
- devoir renvoyer individuellement chacun des 2000 mails refusés = pitié non
Je lis ton message d’avant maintenant
Pas sûr de comprendre ? Si on ne doit pas installer d’autre logiciel, alors on fait comment ?
Oui ! D’où à mon avis l’intérêt d’utiliser Sisimai (par exemple) pour identifier clairement la cause de rejet. Ou plus drastiquement : il ne faudrait pas essayer de re-relayer un mail qui bounce chez le SMTP destinataire final (via un autre relais). Car on n’est pas forcément sûrs qu’un soft bounce chez tel fournisseur ne veut pas dire que le mail a été vu comme spam (exemple des messages cryptiques chez ‹ laposte.net › « service indisponible » qui veulent dire que le mail est refusé).
Pourquoi ne pas juste rajouter un header X-SM2TP-Relay: XXX par exemple ? Plus simple à détecter que parser les headers received non ?
Pour le reste j’avoue commencer à être paumé, faut que je relise tout ça à tête reposée un autre jour ^^
Bonjour,
A vos agendas : Pour celleux qui n’étaient pas présent.es lors de la décision, la prochaine réunion aura lieu le jeudi 5 décembre à 19h30 sur le BigBlueButton habituel.