ça c’est une volonté de dev, mais quand est-ce que ça a été tranché ? (on en a parlé sur le forum, qu’il était possible d’interagir avec des SMTP existant, que ça paraissait moins complexe, casse gueule… je retrouve plus la discussion pardon)
à la question « Quels impacts considérez-vous inacceptables sur serveurs mis à disposition comme relai ? »
14/30 (pas bien loin de la majorité) personnes ont répondu "Nécessité d’utiliser un serveur SMTP spécifique, en remplacement de l’implémentation utilisée actuellement " ça va finir par fâcher plus de 2, 3 personnes si faut installer un SMTP dédié…
Aussi à la question « Quel serveur SMTP utilisez-vous en tant que serveur d’envoi » : 27/30 répondent postfix…
Donc si on se fit uniquement au sondage, moi ça me parait limpide sur le fait qu’il faille composer avec Postfix. Après on peut faire une Macron et nier le résultat du sondage/élection
Oui, bien sûr, mais ce que je veux dire c’est qu’il ne faut pas se mettre la contrainte de devoir absolument le supporter. Par exemple si on fournit une solution packagée sous forme de paquets de distribution et/ou sous forme de conteneurs, on le fera pour un nombre limité de distributions.
Je n’étais pas clair, c’est vrai. Je parlais de ces configurations là :
Refus / Mise à disposition de l’émetteur / Mise à disposition de l’émetteur et de la fédération / Uniquement pour l’administrateur du relai
Le choix de la bonne option fait partie du cahier des charges parce qu’il impacte directement la fédération. Le rendre configurable implique un travail de généricité, et donc potentiellement une charge supplémentaire de développement.
Être indépendant du SMTP existant oui, par contre s’imposer de s’intégrer avec tous les SMTP pour leur permettre de fonctionner en tant que relai non.
En d’autres termes, on va construire le relai sur la base d’une implémentation SMTP de référence (c’est à dire existante de notre choix, ou bien implémentée par nous) qui nous offre les fonctionnalités idéales pour l’implémentation du relai, mais on ne permettra pas d’utiliser n’importe quelle implémentation SMTP comme relai.
Par contre, oui, il faut que l’interface entre le serveur émetteur (existant) et le relai soit standardisée (donc typiquement SMTP avec authentification) de manière à pouvoir interagir avec les implémentations SMTP les plus communes.
La discussion était légèrement différente, c’était « est-ce qu’on doit réimplémenter un serveur SMTP from scratch ou utiliser une implémentation existante ». Sachant qu’effectivement ma position est qu’il est préférable d’utiliser une implémentation existante (je m’en fous de laquelle tant qu’elle est bien maintenue et répond fonctionnellement à notre besoin) pour éviter du travail et des problèmes.
Maintenant, utiliser 1 implémentation existante qu’on maîtrise et dont on contrôle le fonctionnement, c’est différent de supporter 100% des implémentations existantes comme relai.
Il faut plutôt regarder l’option « Nécessité d’utiliser un serveur SMTP spécifique, en complément du serveur existant », puisque c’est plutôt ça qui serait fait (ils gardent leur serveur existant mais se connectent à notre implémentation depuis leur MTA pour émettre leurs mails).
On va être clair, moi ça m’irait très bien d’utiliser postfix comme implémentation SMTP pour le relai parce que je le maîtrise bien, et qu’il propose beaucoup de fonctionnalités permettant de contrôler le flux de mails (policy services, content filters, milters), et donc nous épargnerait du travail sur la chaine de traitement des mails, mais je sais que @bohwaz est d’un avis différent. Après, une option intermédiaire si on veut supporter la plupart des implémentations SMTP comme relai serait d’implémenter un milter (supporté à ma connaissance par sendmail, exim et postfix mais pas par opensmtpd).
De manière générale, par rapport à la question de l’OS et de l’implémentation SMTP, je pense qu’il faudrait qu’on vise une distribution du relai sous forme de VM et conteneur parce que je pense que la majeure partie des utilisateurs le déploieront de cette manière. Un tel packaging nous laisserait libre tous les choix. Je n’ai pas pensé à poser explicitement la question.
Bonjour @sekil,
J’ai mis à jour les titres en ligne avec tes propositions.
Pour ce qui est des choix, il me semble qu’une décision collégiale s’impose. Je comprends que rendre tout paramétrable génère une charge de conception et de dev sans doute inaccessible. Pour l’instant, je suis parti sur un CdC qui n’est que le reflet des réponses au sondage. Après analyse de la première version du CdC, il sera temps de décider de ce qu’on conserve et de ce qu’on supprime.
En tout cas, je n’ai ni l’envie ni la capacité de décider qu’on garde ou qu’on supprime telle ou telle option.
Donc, je propose de continuer sur le même modèle en sachant que ce n’est qu’une version « Martyr ».
Pour moi il est clair qu’il ne faut pas aller toucher à l’installation SMTP existante, sinon on n’est pas sortis des problèmes, car chacun voudra modifier la config du SMTP qui fait du entrant aussi, ce qui est juste normal.
C’est pour ça que se reposer sur postfix (ou exim, ou autre) n’est pas une solution à mon sens.
On projette une solution qui ne fait que du SMTP sortant, si on commence à mixer avec un logiciel qui est aussi utilisé pour du SMTP entrant… on n’aura que des problèmes.
J’espère qu’on est au moins d’accords sur ce point, sinon je vois pas comment on pourrait continuer parce que pour moi ça me semble être un élément bloquant.
Si on est OK sur ça, la décision suivante (selon moi) c’est :
Partir sur un logiciel développé de plus ou moins zéro, qui soit indépendant.
Se reposer sur un logiciel SMTP existant, et lui greffer une config particulière, éventuellement des modules ou des patchs, pour arriver à nos fins. Du coup peu importe que ça soit Postfix, Exim, ou n’importe quel autre, tant qu’il répond au besoin. Dans ce cas ça veut dire qu’il doit :
3. soit être repackagé sous un autre nom, pour ne pas entrer en conflit avec les paquets systèmes existants (même principe, de ne pas toucher à la config existante)
4. soit que ça soit exclusivement fourni sous forme de package Docker / VM.
Moi je suis plus favorable à une solution (1) qui nous donnera toute indépendance et latitude de faire ce qu’on veut.
La solution (2) peut être acceptable je pense, mais :
pour moi ça ressemble plus à de la bidouille instable (mais je peux me tromper), ça me rappelle mon vécu sur AlternC et ça me fait peur
le (3) c’est potentiellement des soucis / du taf à devoir repackager ça sous un autre nom (genre je pense à repackager postfix pour Debian sous un autre nom)
le (4) ne présente aucun intérêt pour Paheko parce qu’on n’utilise pas Docker, et je pense pas qu’on veuille dédier une VM/IP à juste ça. Ça pourrait être reconsidéré, faudrait que j’y réfléchisse, mais ça me semble plus lourd / complexe comme mise en place, par rapport à juste un apt install. De même que ça freinerait l’adoption sur des OS autres comme FreeBSD du coup. Si on peut faire un paquet debian / rpm, alors ça ira très bien dans un docker aussi. Par contre si c’est un apt install postfix dans un docker + modif de la config via des scripts, c’est carrément moins portable.
Mon avis perso c’est aussi que ça serait dommage de faire du bidouillage à base de postfix/parsing de logs plutôt que de faire un logiciel « propre » vu le potentiel du projet.
Mais pour le moment je voudrais surtout mettre de côté toutes les considérations de choix technique et construire le cahier des charges « ideal ». À partir de là on aura une meilleure idée de ce qu’il faut, et pouvoir ensuite présenter des choix, parce que peut-être que ce que je présente ici est caduque du fait des besoins exprimés.
Je n’ai pas encore eu le temps de me plonger dans la lecture de tout ça désolé, je suis très pris ces derniers temps, et je pars en vacances la semaine prochaine donc pas sûr d’avoir le temps d’ici là.
Oui j’avoue que j’ai passé beaucoup de temps à galérer avec postfix et jamais trop réussi à comprendre comment ça fonctionnait, problème que je n’ai pas eu avec Exim, c’est juste ça, mais je ne suis pas opposé à ce qu’on se base sur postfix, j’ai juste peur que ça réponde pas au besoin, mais je connais sûrement pas assez postfix pour ça. Je n’ai jamais touché un milter non plus, il faudra que je regarde, mais j’aurais une meilleure vue après que le cahier des charges soit rempli. De là on verra ce qui est envisageable, ou ce qui doit être éliminé car trop complexe.
C’est ce qui m’inquiète, c’est qu’une volonté de dev « page blanche » soit guider par une méconnaissance des mécanisme type milter… Aussi je trouve ça dommage et j’avoue que perso je suis pas sûr de « faire confiance » à un SMTP jeune / frais de développement pour l’envoi de mes mails, c’est trop critique… Déjà que ça demande beaucoup de surveillance le mail, si en plus on se cogne des non délivré + remontés de bugs parce que la conversation SMTP se passe pas bien…
L’option milter (ou autre) me semble moins coûteuse en temps de dev + beaucoup moins risque en bug/problématique sur la délivrabilité des messages. Même si j’ai conscience qu’elle va peut être aussi limiter les fonctionnalités (j’ai pas toutes les clés sur les possibilités des milter et autres mécanisme pour causer avec des SMTP.
Note : moi même je trouve ça toujours plus sympa le dev « page blanche », moins de truc à reprendre/contraintes, apprendre comment ça marche un machin…
Tout ça reste mon avis hein… Je donne mon avis en suivant le projet de pas si prêt…
Je ne comprend pas cette remarque. Je ne vois pas quel problème ça pose d’utiliser une implémentation SMTP qui sait aussi faire du entrant. C’est comme tout logiciel, ce n’est pas parce qu’il peut le faire qu’on est obligé d’activer et utiliser la fonctionnalité.
Je ne sais pas pour exim, mais je sais que tu peux configurer postfix (et c’est le cas d’opensmtpd également) pour qu’il se comporte comme tu veux. Si tu veux le configurer pour qu’il se comporte uniquement comme relai, tu peux le faire, et ça se passera très bien.
Je suis personnellement défavorable à cette option, pour les raisons que j’avais indiquées (qui sont grosso-modo les mêmes que @kepon) : la quantité de travail, et la maturité de l’implémentation.
Si on peut éviter de patcher, c’est préférable, parce que patcher impliquerait de devoir maintenir une branche, donc là aussi du travail. Et un très gros risque qu’une évolution du logiciel pète notre patch.
Disons que la fourniture sous forme de package Docker ou de VM est l’idéal en terme de développement, dans le sens ou on est certain de maîtriser toutes les dépendances et conflits et la conformité de la configuration.
Mais je comprends et je respecte ta préférence à installer sur le système existant. Donc oui si on partait sur cette direction, il faut le faire sans hypothéquer l’intégration sous forme de paquets.
C’est la question du make or « buy » (ou plutôt reuse), et on peut réutiliser proprement si on maîtrise et respecte le fonctionnement des softs. En l’occurrence, quand on fait du reuse il faut exploiter les capacités d’extension offerts par le soft qu’on réutilise et éviter de patcher.
Je ne sais pas ce qui avait mal marché pour AlternC mais pour ma part j’ai plutôt une bonne expérience avec le reuse. A titre d’exemple, j’ai implémenté notre interface de gestion d’adhérent comme un plugin roundcube. Ça marche bien et ça ne pète pas à chaque MAJ parce que ça utilise des APIs définies et documentées, dont on sait qu’elles seront maintenues par le développeur du logiciel.
Oui, c’est vrai. Il faut repackager postfix pour Debian parce que de ce que j’ai vu, postfix est déclaré comme Provides mail-transport-agent, et les mail-transport-agent sont marqués comme Conflicts mail-transport-agent. En d’autres termes, on ne peut donc installer qu’un seul mail-transport-agent.
Télécharger le paquet postfix compilé, extraire et modifier l’archive control du paquet, modifier le DEBIAN/control et reconstruire le paquet, c’est un peu moins propre mais ça se fait en quelques lignes de bash
Ok
Il faut considérer aussi où sera le mieux dépensé notre temps. A mon sens, ré-implémenter quelquechose qui existe déjà n’est pas l’endroit où il faut qu’on concentre nos efforts. Il faut qu’on se concentre sur ce qui n’existe pas, et l’intégrer avec des briques existantes (même si ces briques là ne font pas exactement ce qu’on veut) pour arriver le plus rapidement à un MVP fonctionnel et solide. Une fois qu’on aura ce MVP, si on identifie des briques qui ne sont pas idéales et qui sont faciles à remplacer, on aura tout le loisir de le faire dans un second temps.
Je suis d’accord que parser des logs texte n’est pas ce qui est le plus élégant ni performant, et j’aimerais bien qu’il y ait une autre solution avec les softs existants, mais d’un autre côté ça fonctionne et c’est plutôt fiable. On peut facilement faire un script en Perl ou Python de quelques dizaines de lignes qui va parser régulièrement les logs, insérer dans une DB ou une file, pour le traiter par le soft qui va gérer les bounces. C’est infiniment moins de travail que d’implémenter un relai SMTP du même niveau de qualité que les logiciels existants.
Enfin, en terme d’architecture, il faut clairement différencier les composants qui ne font pas la même chose. On n’a pas besoin que le soft qui gère les bounces et le relai SMTP soient le même logiciel. Et il est même préférable de distinguer les deux pour de multiples raisons (éviter qu’un bug de l’un impacte l’autre, faciliter le debug et la maintenance, permettre la scalabilité, etc).
Il est clair que ces discussions sont compliquées mais je pense qu’il est important qu’on les ait de manière à ce qu’on se comprenne entre nous, qu’on soit conscients ce qui nous gène exactement dans telle ou telle option de manière à parvenir au meilleur compromis, et quelles sont nos « lignes rouges ».
Je pense que toi @bohwaz, @kepon et moi-même serons techniquement les plus gros contributeurs et les meneurs du projets, donc il faut avant toute autre chose qu’on soit tous les trois à l’aise avec les choix qui seront faits. On ne peut pas prendre le risque de perdre des énergies et volontés parce que le projet prendrait une direction qui ne semble pas acceptable à l’un d’entre nous.
De mon avis très extérieur, je suis plutôt en faveur du meilleur des deux mondes : reposer sur une librairie solide existante.
Utiliser une librairie permettrait :
de ne pas réinventer la route (comme en réutilisant un daemon existant),
tout en ayant une flexibilité maximale en terme d’extension du code existant et de configuration, (comme en partant de zéro).
Reste à savoir si ce meilleur des deux mondes cette librairie existe.
Il y a dans la liste go-smtp, une librairie Go développée depuis 10 ans, qui implémente un serveur SMTP et a très peu d’issues ouvertes. Un audit plus profond serait quand même nécessaire.
J’ai regardé sur des serveurs SMTP écrits dans des langages modernes (stalwart, mox, kumoMTA) si leurs librairies internes ont une API publique, mais il semble que ce ne soit pas le cas. Se baser sur leurs librairies n’est donc sûrement pas une bonne idée. (maddy explicite que son API internal est instable)
Sinon, dans le scénario où vous vous branchez sur un serveur existant, je pense que ça vaut le coup de s’intéresser à des daemons SMTP pas écrits en C qui proposent un système de plugin moderne et complet :
stalw.art propose un protocole similaire à milter mais basé sur du HTTP+JSON : ça pourrait simplifier le développement du plugin, puisque il suffirait d’écrire serait un serveur HTTP très simple (et c’est sûrement le protocole qui a le meilleur support en termes de librairies dans tous les langages)
haraka propose un système de plugin où l’on écrit des hooks en JS directement exécutés au sein du daemon.
kumoMTA propose un système de configuration en lua, ce qui donne aussi un support premium pour modifier en profondeur le fonctionnement du daemon (entre autres, des hooks).
Je sais pas à quel point je vais pouvoir m’investir sur ce projet, j’ai déjà pas mal sur le feux… Et j’avoue que j’ai pas de « besoin » là, chez moi, ça tourne bien en l’état avec oMailgw. Donc je met mon grain de sel bien volontiers mais c’est difficile de dire jusqu’où je peux aller. Aussi certain choix sont fait sans que je soit ok avec ça va pas forcément causé un désinvestissement de ma part (vu que j’ai pas de « besoin » pour mon infra là, maintenant…)
J’oriente vers ce qui me semble raisonnable du point de vu de l’admin sys… Et vu que j’ai compris que vous aviez plus des profils dev je fais la balance (j’en ai déjà causé : certain projet orienté système créé par des dev ne sont pas toujours évident à utilisé par des sys, hors ici ça serait un outil pour des sys admin et non pour des dev… voilà mon point de vigilance)
Aussi peut être que des choses que maintenant je ne crois pas bonne/raisonnable serons les bons choix dans le futur… ça je ne sais pas le dire.
Suite au sondage, la prochaine réunion SM2TP aura lieu le mercredi 6 novembre à 19h.
Voici l’email que je viens de diffuser à tous ceux qui ont répondu au questionnaire en souhaitant être informé des prochaines réunions :
Bonjour,
Suite aux réponses au sondage, la prochaine réunion aura lieu le mercredi 6 novembre à 19h avec BBB : BigBlueButton.
En toute transparence, le jeudi 7 novembre avait remporté 1 suffrage de plus, mais je ne suis personnellement plus disponible à cette date.
L’initialisation du cahier des charges n’est pas finalisée. Nous faisons le maximum pour le diffuser au plus tôt.
A bientôt
Alain pour l’équipe de coordination
@sekil, @bohwaz, @kepon : Si vous avez le temps de faire une revue du CdC (MyPads) avant cette réunion, ça serait top qu’on puisse le diffuser afin qu’il puisse servir de support…
Je pense avoir terminé une version acceptable comme base de discussion. Je pense qu’une relecture par @kepon et @bohwaz serait utile.
Concernant le sondage, pour préciser ce que j’en disais plus tôt, je pense que nous devons utiliser les résultats pour évaluer dans quelle mesure les directions que nous sommes susceptibles de prendre seraient à même d’être partagées ou non par les répondants, et donc quelle proportion de gens on risque de perdre dans le même temps. 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).
A ce titre, j’ai regardé pour clusteriser les résultats sur certaines questions (hard bounce, soft bounce et plaintes) sur la base des fonctionnalités correspondantes proposées dans le CDC, j’espère réussir à terminer d’ici la réunion.
On essaye de jouer le jeu du compromis ? Malheureusement, ça ne va pas marcher !
Utiliser une librairie SMTP existante : Je n’ose pas croire que @bohwaz avait en tête de ré-implémenter le protocole SMTP. Il me parait évident que son option impliquait de se baser sur une librairie SMTP existante et solide. Seulement, un MTA inclut beaucoup plus de choses que la simple gestion du protocole SMTP, ça inclut des mécanismes de queuing, de gestion des bounces et des deferrals, de rate limiting, de gestion des headers, d’authentification, des politiques de sécurité, …
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. Et je pense que les sysadmins auront globalement la même réaction que moi. Bon, maintenant il faut reconnaître qu’utiliser une de ces implémentations nous ferait partir de moins loin par rapport au fait de tout refaire.
J’entends bien, mais je pense que tu es celui parmi nous qui est allé le plus loin sur cette voie. S’il s’avère que l’on constate, d’après le CDC, l’architecture et les choix techniques, que oMailgw couvre déjà une partie des besoins, je pense que se posera clairement la question d’exploiter ou faire évoluer le code existant. Auquel cas, ta contribution sera déterminante, au moins pour nous assister.
Je viens de faire une relecture, des petites choses par ci par là mais 2 plus grosses :
[M] Le relai doit contrôler la conformité du domaine émetteur avant de relayer un mail
Note: Cette vérification a pour objet de protéger la réputation du relai en cas de mauvaise configuration du domaine émetteur
Note: Certains éléments de cette vérification de conformité peuvent être mis en cache si pertinent
Note: Lors de la réalisation des requêtes DNS, les requêtes doivent valider la chaine DNSSEC, si présente.
Je m’oppose pas à ça mais est-ce que ça fait pas doublon avec une vérification SPF. En effet si le serveur qui relai est identifié dans le champs SPF + que le MTA émetteur à été authentifier, on doit pouvoir relayer le message en provenance de n’importe quel domaine sans (trop) de crainte ?
Relai des mesasage :
[M] Le relai ne peut transférer un message qui lui est soumis à un autre relai
Je ne comprends pas ce point. Un autre relai ça serait un relai copain chatons ? Pourquoi donc ? Si ce relai rencontre des difficultés avec un domaine x (exemple hotmail) pourquoi ne pourrait-il pas router vers un autre relai uniquement pour ce domaine ? (moyennant authentification et tout le reste du mécanisme bien sûr…)
Pour ne pas interférer avec le corps du CDC, j’ai mis tes remarques en italique et préfixées par ton pseudo. Par contre j’ai gardé en l’état les contributions au contenu.
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.
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.
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.
