Je précise qu’il s’agit bien d’une architecture fonctionnelle et non technique, donc cela se contente de décrire les traitements nécessaires, mais ne présage pas de l’architecture technique et donc des composants logiciels qui permettront sa mise en oeuvre.
Je vais raffiner en ajoutant les données stockées et transférées par chaque fonction, ainsi que les problèmes auxquels j’ai déjà pensé.
Je peux déplacer tout ça sur le groupe Gitlab CHATONS si on me donne l’accès.
Je me permet de compléter des notions entant que newbie.
En effet, perso, je suis une bille en email.
C’est bien pour cela que j’ai utilisé une solution « clef en main » (Modoboa) pour mon serveur EMail.
Du coup, @sekil et @bohwaz, vous m’avez un peu perdu dans vos jargons.
Pourquoi ne pas faire une petite page genre « le SMTP pour les nul(le)s » ?
Pour commencer, je propose 2 termes (assez basic) donc j’ai recherché la définition pour être sur de ne pas faire un contre sens:
bounce ou bounce message (https://en.wikipedia.org/wiki/Bounce_message)
Message (rebondi) qui n’a pas pu être remis à son destinataire. Il est renvoyé à l’expéditeur avec un message d’erreur.
Appel aux newbies comme moi: si vous avez découvert d’autres termes jargons, n’hésitez pas à en partager la définition, ne soyez pas timide
C’est un des éléments qui m’a fait me poser des questions pour l’architecture fonctionnelle :
Qu’est-ce qui fait qu’une adresse est dans la « global suppression list » ou dans la « account-level suppression list » ?
Quand tu as des adresses qui bouncent, est-ce qu’elles sont ajoutées automatiquement à la « global suppression list » ou bien à la « account-level suppression list » ?
Je n’ai pas pris en compte la feature d’associer un score à chaque chaton. Est-ce que je l’ajoute ?
Sur ce point ça me parait clair, c’est à dire qu’on peut différencier les données à usage de logs des données à usage de filtrage :
Dans la BDD locale, on va stocker des logs d’émission associés à chaque organisation autorisée à émettre (Sender Org), et dans cette table on pourra stocker les adresses en clair, et le messageID des mails pour pouvoir les corréler dans les logs du serveur.
Dans la BDD locale ainsi que dans les propagations des statistiques de bounce vers les autres relais, on stocke et on transfère uniquement des hash d’adresse, parce qu’on n’a pas besoin des adresses en clair.
Je pense que sur ce point c’est aligné avec ce que j’ai décris, c’est à dire que le relai ne fait que relai. S’il est sur le même système qu’un serveur mail existant, il doit effectivement être mis sur un port différent.
Je ne comprend pas l’usage de cette adresse.
Le relai reçoit le code SMTP du destinataire oui, mais il peut être nécessaire de parser les logs pour extraire le code de rejet si le MTA utilisé comme relai ne fournit pas d’API pour remonter les stats et bounces. Et à vrai dire je ne serais personnellement pas à l’aise à placer un MTA non éprouvé en coupure sur le chemin du traffic mail.
Si j’ai bien compris, oMailGW ne se met pas en coupure mais extrait les logs et fournit les transport_map & cie, et je pense que ce principe nous permettra d’être plus robuste.
Enfin bon, on pourra discuter de tout ça en temps utile.
On est d’accord, si on intègre une fédération multi-niveaux, cela exige une signature des informations afin de pouvoir garantir la validité le relai qui les a générées.
Cela peut aussi permettre à une organisation fédérée de refuser les données de bounce en provenance d’une autre organisation fédérée à laquelle il ne fait pas confiance.
Par contre, et c’est très bien parce que je ne vois pas ça dans ton message, il ne faut pas limiter la propagation des données de bounce, il faut les propager tant que la chaine se poursuit (e.g. CHATONS 1 → CHATON 2 → CHATONS 3-4-5-6 → CHATONS 7 → …). Dans le cas contraire, on pourrait se trouver à voir des déséquilibres dans la production des bounces :
Un relai faiblement connecté recevrait peu de données de bounces et devrait produire la majorité des données de bounces
Un relai très connecté recevrait beaucoup de données de bounces et serait à l’origine de peu de données de bounces
Sur ce point, je pense que c’est dangereux et non souhaitable :
Dangereux parce que cela peut mener à des boucles de relayage entre différents relais interconnectés
Non-souhaitable parce que si deux organisations fédérées ont fait le choix de ne pas se connecter directement, c’est qu’elles ne se font pas suffisamment confiance pour transmettre les messages l’une via l’autre : l’émetteur ne veut pas que le relai puisse lire son traffic ET/OU le relai ne souhaite pas que la réputation de son IP soit engagée par le traffic de l’émetteur
Par conséquent, pour moi :
En acceptant un message, le relai s’engage à l’émettre lui-même vers le serveur du destinataire.
S’il estime ne pas être en mesure de traiter ce message, le relai doit le refuser (je n’ai pas vérifié si un MTA classique sait changer de relai dans ce cas).
Un serveur SMTP en PHP codé par nos soins, je vais avoir de sérieuses objections (cf ci-dessus ;)). On peut faire pas mal de choses avec un serveur postfix et un transport_maps dynamique pour chaque requête (si j’ai bien compris c’est déjà le principe de oMailGW).
Sur ce point je ne vois aucune limitation qui interdirait de faire ça. Le service outbound.protection.outlook.com est intégralement basé sur ce principe.
On est d’accord que hard bounces ce sont les codes 5xx et les soft bounces ce sont les codes 4xx ?
Y a-t-il une mécanique différente à prévoir pour chacun de ces deux types de bounces ou bien la mécanique serait similaire ?
Prise en compte des feedback loop
On est d’accord que ce sont les données reçues via l’adresse publiée dans l’enregistrement DMARC ?
Auquel cas ces données seront reçues par l’émetteur et non le relai, ce sera donc à l’émetteur de les traiter ou non et d’en tenir compte. D’autant qu’on peut supposer qu’un « bounce » de ce type est lié au contenu.
Comptabilisation de bounces par émetteur et détection d’émetteurs dysfonctionnels
Quand Laposte.net répond « Service refusé » (erreur 4xx) ça veut dire que le mail sera toujours refusé… car identifié comme suspect
Certains répondent « spam detected » avec une erreur 4xx : idem, ça sert à rien d’essayer de renvoyer le mail
C’est un statut à la con : le mail est refusé définitivement, mais l’adresse mail destinataire est valide.
C’est ce que j’appelle « rejet permanent du message ».
Feedback loops : non c’est toi qui choisi l’adresse en général, bien que ça dépende des fournisseurs, il n’y a rien de standardisé à ce sujet. Ça n’a absolument rien à voir avec DMARC.
En général voici comment ça se passe pour être inscrit à une feedback loop :
tu crée un compte chez le fournisseur (Outlook, Yahoo, etc.)
tu prouve que tu es propriétaire d’une adresse IP, généralement via un mail envoyé à abuse@[reverse DNS de l’IP]
tu configure ce que tu veux recevoir, et où
Exemple chez Microsoft :
Donc l’action est faite une fois pour chaque IP expéditrice (ou pour chaque réseau, si tu as plusieurs IP).
Normalement pour un hébergeur français il faut s’inscrire à ces FBL :
GMail propose un truc moins pratique donc je l’ai jamais essayé jusque là.
C’est plutôt chiant à mettre en place du coup si on n’a pas de compte Outlook/Yahoo…
Ensuite une fois le mail de reporting reçu au format ARF, il faut le parser pour retrouver l’adresse mail de la personne qui nous a mis dans les spams, l’adresse de l’expéditeur, et le Message-ID.
Les trucs de niveaux de liste de blocage c’est pas encore très clair pour moi, mais l’idée je pense c’est que si tu as un expéditeur en local qui envoie plein de mails vers des adresses invalides qui sont déjà dans la blocklist (donc sans faire d’envoi réel), alors tu va bloquer ces envois (forcément), mais tu dois prendre en compte ça pour indiquer que peut-être cet expéditeur est en train d’envoyer du spam.
Pour le score par CHATONS j’ai pas trop réfléchi à l’idée… S’il ne relaye ses mails vers personne d’autre ça ne sert pas à grand chose, mais ça peut avoir une utilité pour quand tu veux justement relayer, en mode transparence : « nous on a un score de <0,4% de bounces réels (donc sans compter ceux bloqués par la blocklist fédérée) sur nos envois, donc on n’a rien qui fait du spam chez nous ». Ça peut aussi avoir une valeur indicative pour toi en tant que CHATONS, que tu puisse monitorer ce score et donc détecter par exemple un formulaire de contact wordpress qui serait abusé.
Oui je crois qu’on est d’accord
C’est pour les feedback loops
Je suis un dév, pas un « vrai » sysadmin donc moi je vois les solutions en terme de code Surtout dans une idée d’avoir un truc intégré sans avoir à configurer plein de trucs. Notamment car nous on n’utilise pas postfix, mais Exim, et que d’autres utilisent peut-être d’autres solutions encore.
Mais l’idée c’est que si on se met d’accord sur une API de communication entre nœuds et une logique d’échange des clés / fonctionnement du réseau, peu importe ensuite l’implémentation, donc il est possible ensuite d’avoir plusieurs implémentations interopérables, mais bon dans un premier temps ce qui serait cool c’est de concentrer les efforts
L’idée de faire un prototype de serveur SMTP en PHP (qui peut très bien gérer jusqu’à plusieurs centaines de mails par seconde à mon avis, donc d’ici à ce qu’on bloque on aura une meilleure idée), c’est de voir si l’idée fonctionne en pratique et partager le code entre l’applicatif web, la fédération et le relais SMTP.
Après ça peut être un truc dans un autre langage compilé, tant qu’on me file un paquet debian à la fin et qu’il faut pas faire du docker, ni du npm, tout me va
Oui exactement, à mon avis ça me semble important de pouvoir choisir de limiter la confiance accordée à des nœuds externes à ton réseau de confiance « explicite ».
Oui oui bien sûr la transmission doit se faire en intégralité.
En fait dans mon idée, chaque nœud possède une copie de toute la base de données fédérées, mais sait exactement d’où vient chaque événement (par exemple via un UUID, ou directement la clé publique du nœud, avec libsodium ces clés sont relativement courtes).
Je suis complètement d’accord, on s’est mal compris.
Pour moi la fédération d’envoi, c’est juste relayer depuis le relais local vers un des relais avec qui on fédère « explicitement », et donc en toute confiance. Donc comme un relais SMTP actuel en fait
Il n’est absolument pas question que les mails de C1 se retrouvent relayés chez C3 via C2, alors que la relation de confiance n’existe qu’entre C1 et C2. Il n’y a qu’un seul niveau de relais : le noeud local transmet directement au noeud de sortie final, avec qui il a une relation de confiance. Le noeud de sortie « ami » doit évidemment refuser le mail et ne pas le re-transmettre ailleurs.
En espérant être clair ce coup-ci
Ça serait pas forcément comme truc final, mais comme prototype. L’avantage c’est que ça fait une seule base de code, un seul langage. Niveau perfs ça devrait tenir très largement les besoins jusqu’à plusieurs centaines de mails par seconde, donc de quoi voir venir.
Mais normalement l’adresse expéditeur existe dans le SMTP entrant de la structure… On pourrait peut-être rajouter ça comme vérification (avec cache) : que l’adresse expéditrice est bien valide dans le SMTP entrant de la structure.
De toute façon il va falloir comptabiliser aussi les blocages d’expéditeurs pour éviter de mettre en danger la réputation de nos IPs, donc il faut effectivement :
Comptabilisation des bounces/rejet/feedback par destinataire
Comptabilisation des bounces/rejet/feedback par domaine destinataire
Comptabilisation des bounces/rejet/feedback par émetteur
Comptabilisation des bounces/rejet/feedback par domaine émetteur
Et effectivement, à titre informatif, construire une stat globale de pourcentage de bounce/rejet par CHATONS pour pouvoir détecter et promouvoir les bonnes pratiques.
Ok, c’est clair maintenant.
Je suis un dev aussi.
Et un « vrai » sysadmin, je sais pas
Mais avoir un soft tout intégré n’est pas un leitmotiv pour moi, et lorsque des choses existent déjà et font le job, j’ai plutôt tendance à les réutiliser plutôt que les réimplémenter.
En l’occurrence, outre le fait que PHP soit très mal adapté pour implémenter un serveur ou un démon de manière générale (les dev Nextcloud se débattent avec memcache, redis &cie pour pallier leur erreur initiale), il ne s’agit pas juste d’implémenter SMTP, il y a de nombreuses fonctions déjà implémentés dans les MTA existants (authentification, rate limiting, etc) qui prendront beaucoup de temps à réimplémenter. Et s’il faut le faire proprement il faudra les tester voire les CI/CDiser. Je ne sais pas pour toi mais personnellement je n’ai pas envie d’implémenter une suite de tests SMTP. Maintenant si tu as envie de le faire, fais-toi plaisir.
Je ne vois pas le code qu’il y aurait à partager entre l’API et le serveur SMTP, on est sur deux services assez disjoints qui font des opérations qui n’ont pas grand chose à voir (c’est une intuition pour le moment, on verra lorsque l’architecture sera plus claire). Et mon avis est que disjoindre les fonctions facilite leur vérification, leur maintenance, et l’interopérabilité.
Maintenant on n’est pas obligé d’utiliser le même MTA pour le relai et pour le MX, même sur le même OS. Le MTA sélectionné aurait sa configuration de référence fournie pour ce cas d’usage, avec le minimum d’adaptations locales. Alors il est vrai que Debian met en conflit les mail-transport-agent entre eux (je viens de vérifier), dans ce cas on pourrait repackager le MTA pour supprimer le conflit, donc rien de bloquant.
Je ne le vois pas forcément comme un avantage.
Oui OK
Oui. Et d’après wikipedia la vérification se fait bien auprès du MX du domaine de l’émetteur et non du serveur émetteur donc dans ce cas c’est safe d’avoir un relai qui n’est pas le MX du domaine.
Je ne suis même pas sûr qu’il soit nécessaire d’avoir un serveur qui parle SMTP sur le port 25 sur la même IP, mais par sécurité on peut le prévoir.
Non je ne pense pas que ça soit nécessaire, tant que le domaine du « MAIL FROM » a un MX correctement configuré avec SMTP derrière, tout devrait bien aller
+12 000 ! Je suis pas certain que coder un serveur SMTP soit une bonne route, ça va être un boulot énorme pour que ça fonctionne bien. On a plus de chance de générer des problèmes (un problème c’est potentiellement des mails non distribué) en développant un serveur SMTP qu’utilisez un postfix ou autre qui est éprouvé depuis des lustres, qui bénéficie d’une grosse communauté, et qui possèdes de nombreuses portes pour interagir avec lui.
Et pour le coup je vois pas le « gain » de fonctionnalité possible entre lire le log et constater un retour SMTP en direct sinon l’instantanéité (mais est-ce que c’est un pré-requis ? et encore avec un surveillance « ionotify » sur un log on peut approcher ça… )
Pour oMailgw de mon côté je suis partie à « lire les logs » parce que je voulais surtout pas impacter le fonctionnement d’un truc qui marche bien (postfix dans mon cas), juste interagir avec lui, lui envoyer dynamiquement des conf (blacklist, trnasport…) mais y’a peut être un intermédiaire à trouver…
Sur le côté dev / sysadmin, c’est cool qu’il y est les 2 profiles c’est très complémentaire ici pour le coup. Pour le coup c’est un outil qui va servir à des sysadmin, du coup garde à ne pas partir sur une usine que seul les dev comprennent entre eux (je trouve que Crowdsec c’est typiquement ça…) et pour moi ton côté dev @bohwaz explique pour moi ta direction vers le dev d’un service SMTP complet.
Sauf si j’ai vite lu, j’ai l’impression que ça focalise beaucoup autour des bounces type user unknown, du partage de ceux-ci. A mon avis c’est vraiment pas le cœur du problème (dans l’optique ou on souhait faciliter le déploiement de service mail chez les CHATONS). Si on veux partager une liste d’utilisateur qui n’existe pas, on a pas vraiment besoin d’une tel usine à gaz, on partage une base/un fichier qu’on peut « brancher » sur nos services SMTP (avant même le relai)
Et ça part dans la technique alors qu’il y a des potentielles problèmes humain / financier qui serait bien plus difficile à surmonter pour nous je penses.
Ha pardon j’avais mal compris. Alors effectivement non. oMailgw il « regard » (surveille les logs) il envoi à l’API et l’API lui retourne des fichiers de conf à jour en fonction…
J’ai pas l’impression que les serveurs SMTP existants te permettent de bloquer une adresse avec des règles dynamiques.
Imagine : pour les gens qui ont des boîtes mail, je veux bien qu’ils envoient des mails à des boîtes en soft bounce, si le soft bounce a plus de 24h. Mais pour les envois de masse, je veux qu’une boîte avec 5 soft bounces soit définitivement bloquée tant qu’elle ne valide pas sa validité via l’envoi d’un mail + lien à cliquer.
À moins que ton serveur SMTP ne spawne un script à chaque mail envoyé, mais pour le coup ça risque de vite devenir lourd ?
Enfin si c’est possible c’est cool, je connais pas trop postfix car je suis parti sur Exim dont la config est plus simple et standard sur Debian.
Pour moi le partage des bounces c’est une bonne première étape pour améliorer notre délivrabilité, et donc réduire notre charge mentale sur les mails qui n’arrivent pas à destination.
Pour moi le cœur du problème c’est justement que ça sert à rien de partager les envois entre nos infrastructures, si on ne peut pas faire confiance aux envois venant des autres, en sachant qu’on a autre chose à faire de nos vies que de vérifier les logs venant des autres.
Donc étape 1 : améliorer la délivrabilité en améliorant nos pratiques et en étant plus zens en sachant qu’un de nos utilisateurs⋅trices ne puisse pas d’un coup démolir notre réputation et nous faire bloquer partout parce qu’on n’a pas réagi super vite.
Actuellement ça n’existe pas.
Je ne sais pas si c’est le cœur du problème, mais j’ai l’impression que ça serait déjà un bon pas en avant. Quel serait le cœur du problème du coup ?
Précisément, s’agissant de postfix, toutes les maps (structures de données utilisées par Postfix pour à peu près toutes ses fonctionnalités, depuis la liste des mailbox à la sélection d’un relai en passant par les blacklists), peuvent utiliser les types suivants : Postfix Lookup Table Overview
Maintenant, effectivement ici la liste des services auxquels tu peux faire des appels en mode requête-réponse est limitée. Donc tu as aussi, dans postfix toujours, la possibilité d’implémenter un script de policy service dans lequel tu vas passer tous tes mails pour vérification : Postfix Configuration Parameters
Maintenant, si tu n’aimes pas postfix, tu peux encore implémenter un programme utilisant le protocole milter (comme le font la plupart des modules DKIM, DMARC, ou antispams), ce qui te permet d’avoir un filtre compatible avec la grande majorité des serveurs SMTP.
Dans le cas de oMailGW, de ce que je lis dans le code, les blacklists postfix sont générées lors d’un appel régulier à omailgw-cli (par cron), qui vient écrire un fichier postfix maps (et appeler la commande qui va bien pour compiler le fichier). Sachant qu’il se trouve que postfix recharge ses maps lorsqu’elles sont modifiées. Donc il s’agit d’une semi-dynamicité.
Pour l’utiliser depuis 15 ans, je peux dire que Postfix permet clairement des choses qu’aucun autre serveur SMTP ne permet, et je suis convaincu que ça peut être une boite à outils très utile pour ce qu’on a à faire. Mais je ne l’ai pas poussé parce que pour moi ce n’est pas le sujet des discussions actuellement.
Voilà pourquoi pour le moment, à mon avis, il est bien trop tôt pour se demander comment on va faire les choses et se précipiter à se dire qu’on va réutiliser tel ou tel composant, ou qu’au contraire on va réimplémenter un serveur SMTP. Je pense qu’on doit se concentrer sur qu’est ce qu’on veut et comment on veut que la solution fonctionne.
Je suis d’accord pour que la première étape soit d’améliorer gentillement notre délivrabilité mais la question que je pose c’est de savoir si oui, et dans quel mesure partager les bounces (et donc ne plus envoyer vers des adresses qui n’existe pas) ça améliore la délivrabilité. Sur quoi on se base pour dire ça ? Il y a des études sur le sujet ? Juste un sentiment ?
Pour moi la difficulté c’est de réagir automatiquement, vite à un problème complexe que même un humain n’a pas parfois pas toutes les clés de compréhension (parce qu’en face, les règles sont mouvantes…) :
Une boîte est piratée (envoi vers des e-mail qui existe) et PAF on se fait blacklister en face peu de temps… action à mener : bloquer l’expéditeur ? Bloquer l’IP émettrice ? Router le reste du trafic légitime (des autres IP) vers une autre passerelle pour les destinataires qui bloque maintenant pour ce d
Quelqu’un transfère un e-mail à une mailing liste (quasi systématiquement bloqué chez certain opérateur) : On bloque avant ? Comment le détecter ? Et pi mince, c’est du trafic légitime…
Un blacklitage est connu mais ne dépend pas d’un domaine de destination (C.F. : [colaboration] Blocage proofpoint et quand le log dit « blacklisté » on route vers une nouvelle passerelle ? Sauf si c’est du SPAM alors là on va finir par bloquer toutes les IP…
… Je dois pouvoir allonger la liste des problèmes complexes qui mérite de la surveillance , des essai-erreurs… ou juste du temps sans émettre et pi, paf, on essaie de nouveau 2 mois après en serrant les fesses et ça passe… ou pas…
Sans paraître pessimiste je vois bien que vous avancer vers un truc full automatique avec le moins d’humain possible mais j’ai l’impression que même les gros opérateurs on beaucoup d’humain pour gérer des e-mails… Alors qu’est-ce qui fait qu’on est plus malin qu’eux ? En ajoutant en plus une couche de complexité / de collaboration entre structure (humaine et technique)
C’est un truc super important chez SES et autres solutions commerciales d’envoi de mails, c’est donc que c’est pas juste un sentiment mais que c’est important pour de vrai je pense
Difficile de détecter que c’est la boîte X qui a été piratée tant que le volume d’envoi ne semble pas inhabituel, ni que le volume de rejets n’augmente pas. Bien sûr les complaints aident bien dans ce genre de cas !
Moi je dirais : si c’est inhabituel comme volume pour l’expéditeur X on ralentit automatiquement les envois dans un premier temps (file d’attente avec sortie des mails en mode lent : 1 mail / minute par exemple), en attendant de voir, si ça continue à augmenter après X heures / Y volume, alors blocage en attendant une inspection manuelle du cas.
Là c’est plus de la gestion de la mailing list elle-même, qui peut détecter/bloquer les forwards, mais bon je pense que le cas est assez rare pour ne pas s’en soucier perso.
Le but est d’automatiser le max. de choses, mais pas de remplacer les humains, plutôt de leur faciliter la tâche
