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
Suite à la mise à jour du CDC, j’ai également mis à jour la page d’architecture fonctionnelle :
A la réflexion, cela me fait considérer qu’on peut diviser en plusieurs projets :
Le développement d’un service de collecte, stockage et partage des données de bounce et statistiques.
Le développement d’un service de relais fédérés
Le développement d’un frontend
L’intégration et le packaging.
Le service de bounces et le service de relais sont fonctionnellement relativement indépendants : On peut imaginer déployer le service de bounces seul pour partager les données de bounce entre plusieurs émetteurs qui assurent eux-mêmes leurs propres envois, comme on peut imaginer déployer le service de relais seul, sans collecte et partage des bounces. En définissant correctement les interfaces entre les deux, on peut les développer indépendamment.
Concernant le relai, comme je l’ai déjà indiqué, je pense qu’il est préférable de le mettre en oeuvre sur la base d’un MTA existant (ma préférence se portant sur Postfix), OpenDKIM pour la signature, et le développement d’un module milter ou d’un service policy pour les fonctionnalités spécifiques au projet. Et en tout cas c’est ce qui permettra d’arriver le plus rapidement à un MVP.
Concernant le service de bounces, même si on pourrait modifier un logiciel existant de collecte de logs (tel que Lightmeter (Lightmeter / ControlCenter · GitLab), ça ne me parait pas aberrant de partir sur un développement de 0 vu les fonctionnalités spécifiques qu’on doit implémenter.
Dans ce cas de figure, pour permettre l’interaction du relai avec le service de bounces, il faudra que le service de bounces fournisse une librairie (dans un langage à convenir) et/ou une CLI, de manière à permettre au relai : d’une part de notifier des entrées de log au service bounces, d’autre part de requêter les listes de blocage.
Suite à la réunion d’hier, j’ai MAJ la page d’architecture fonctionnelle :
Ton approche permet de simplifier le schéma. J’ai droppé le frontend qui n’a plus vraiment besoin d’être décrit dans cette version. J’ai aussi retiré la numérotation des interfaces internes qui n’ont pas besoin d’être décrites.
Cela donne 4 interfaces (les 2 et 3 pourraient être fusionnées) :
1/ Traffic entre les relais : SMTP
2/ Signalisation interne entre le MTA et le bounce service d’un relai pour la requête des blacklists : A discuter
3/ Signalisation interne entre le MTA et le bounce service d’un relai pour la notification des logs/bounces/feedbacks : A discuter
4/ Signalisation externe entre les relais pour la notification des bounces et logs : A discuter (probablement une API basée sur HTTP)
Je peux par ailleurs te confirmer qu’il n’y a pas de problème à renvoyer les logs générés par le relai partenaire directement au relai local comme tu l’as proposé. Pour cela, j’ai inséré dans l’interface 3 le client hostname (cad le nom du relai local qui s’est connecté au relai partenaire), le bounce service n’aura qu’à envoyer le log vers ce hostname.
Je viens de relire le CdC et de regarder l’archi. Merci encore pour ce super job.
Pour optimiser la prochaine réunion, je me permets de poser cette question à propos de la notion de Federated Relay, qui n’est toujours pas claire pour moi :
Contexte : Admettons que nous avons 3 organisations : Org1, Org2 et Org3.
L’organisation Org1 met à disposition 2 relais : Org1-Rel1 et Org1-Rel2
L’organisation Org2 met à disposition 3 relais : Org2-Rel1, Org2-Rel2 et Org2-Rel3
L’organisation Org3 met à disposition un relai : Org3-Rel1
Org1 a établi une relation de confiance avec Org2 mais pas avec Org3
Org2 a établi une relation de confiance avec Org1 et Org3
Org3 a établi une relation de confiance avec Org2 et potentiellement d’autres organisations
Usage : Org1-Rel1 demande à Org2-Rel1 de relayer un mail qui donne lieu à un bounce
1ere question : Est-ce que la relation de confiance entre Org1 et Org2 se fait au niveau des 2 organisations ou pour chaque relai de ces 2 organisations ?
2eme question : Est-ce que les bounces sont gérés au niveau des organisations ou au niveau des relais ?
3eme question :En considérant que les bounces soient gérés au niveau des relais, j’aimerais comprendre qui sera informé de ce bounce
Org1-Rel1 et Org2-Rel2 : Ça semble évident. Mais qu’en est-il de :
Org1-Rel2 ?
Org2-Rel2 ?
Org2-Rel3 ?
Org3-Rel1 ?
des autres relais avec qui org3 a établi une relation de confiance ?
Si les bounces sont gérés au niveau des organisations, la question reste valide pour org3.
En espérant que ces questions soient compréhensibles et pertinentes…
Merci d’avance de ton retour et bonne journée.
D’un point de vue technique, elle se fait entre chaque relai. Ce qu’on a discuté avec @bohwaz, c’est que traiter les interconnexions relai à relai semblait plus simple d’un point de vue technique et qu’intégrer la notion d’organisation dans l’implémentation n’était pas justifiée.
Il n’empêche qu’on pourra réintégrer ce concept dans le cas où l’on voit que c’est pertinent. Je pense notamment que cela pourra permettre de factoriser certains aspects de la configuration.
Les bounces sont gérés au niveau des relais.
D’un point de vue technique, les relais doivent établir des relations 1-1 entre chaque relai de chaque organisation.
Si on ne considère que la relation entre Org1 et Org2 :
Interne Org1
Org1-Rel1 ↔ Org1-Rel2
Relation Org1 ↔ Org2
Org1-Rel1 ↔ Org2-Rel1
Org1-Rel1 ↔ Org2-Rel2
Org1-Rel1 ↔ Org2-Rel3
Org1-Rel2 ↔ Org2-Rel1
Org1-Rel2 ↔ Org2-Rel2
Org1-Rel2 ↔ Org2-Rel3
Interne Org2
Org2-Rel1 ↔ Org2-Rel2
Org2-Rel1 ↔ Org2-Rel3
Org2-Rel2 ↔ Org2-Rel3
Voici le diagramme de séquence des échanges prévus
Mail Org1-Rel1 → Org2-Rel1 (Interface IF1)
Log Org2-Rel1 → Org1-Rel1 (Interface IF4)
Si Bounce
Bounce record Org2-Rel1 → Org1-Rel1 (Interface IF4)
Bounce record Org2-Rel1 → Org1-Rel2 (Interface IF4)
Bounce record Org2-Rel1 → Org2-Rel2 (Interface IF4)
Bounce record Org2-Rel1 → Org2-Rel3 (Interface IF4)
Bounce record Org2-Rel1 → Org3-Rel1 (Interface IF4)
Le choix d’émettre les bounce records depuis l’organisation relayant le mail (et non depuis l’organisation émettrice) se justifie selon moi par le fait que la base de données de bounces doit avant-tout protéger l’IP du relai.
La question se pose si on veut propager au delà de Org3.
Bonjour @sekil,
Dans un 1er temps, c’est ce transfert qui m’interroge.
Le mail à l’origine provient de Org1-Rel1 qui n’a pas de relation de confiance avec Org3-Rel1.
Le point positif c’est une propagation des bounces sur une plus grande plage d’organisations, ce qui est parfaitement dans l’esprit collaboratif.
Le point négatif, c’est que ça permette à une organisation malfaisante d’arriver à établir une relation de confiance avec une seule organisation pour récupérer plein d’info sur les bounces. Ne sachant pas quelles sont les infos potentiellement confidentielles présentes dans un bounce, je ne sais pas si cette alerte est réellement pertinente.
La propagation au delà de Org3, cad en cascade est potentiellement encore plus problématique.
Merci pour ta réponse.
J’espère qu’on aura d’autres avis sur le sujet d’ici lundi ou lors de cette prochaine réunion.
A+
Pour moi (en l’état) mais je peux être corrigé / on peut me faire prendre conscience d’un problème. Je vois pas ce qui est problématique à partager une « liste d’adresse qui n’existe pas/plus »
Dans l’idée si c’est pas un problème pourquoi ça serait pas ouvert (en mode open data) ?
Le seul truc qui pourrait s’approcher d’un truc pénible :
Les fautes d’un caractères dans une adresse, qui amène à une arrivé en bounces qui amène à diffuser des adresses presque bonne… c’est encore plus vrai quand le bounce c’est @gmaiil.com… ça se corrige vite…
Les adresses qui re-deviennent bonne, qui sortent de la liste bounces… avec des diff on pourrait chopper des adresses valides
Vos commentaires me semblent pertinents (pour une fois je suis d’accord, c’est rare ! ). En fait j’ai également pensé à cette problématique lorsque j’ai écris ma réponse, et je pense que cela fait aussi écho à des commentaires relatifs au RGPD que l’on avait eu dans notre sondage.
Déjà, je commencerais par un premier commentaire, sur la notion de confiance et qu’est ce qu’on met dedans. Pour moi, la relation de confiance recoupe essentiellement le fait :
Pour un émetteur : d’accepter de faire relayer un mail par un relai, auquel cas, l’émetteur doit avoir une très forte confiance envers l’opérateur du relai parce que cet opérateur est en mesure de voir le contenu de tous les mails qui passent par lui. Cela veut dire aussi que l’émetteur devra impérativement prévoir dans ses CGUs de déclarer le relai comme sous-traitant au titre du RGPD.
Pour un relai : d’accepter de relayer le mail pour le compte d’un émetteur, auquel cas la relation de confiance consiste pour l’opérateur du relai de faire confiance à l’émetteur de ne pas émettre de spam et de mettre en oeuvre les moyens nécessaires pour ne pas altérer la réputation du relai. Dans cette direction de la relation, il n’y a pas de notion de données personnelles, donc le relai n’a pas besoin de déclarer l’émetteur comme sous-traitant.
Il va effectivement falloir voir en détail les informations qu’on diffuse et les informations qu’on ne diffuse pas. Il est d’ores et déjà prévu de hasher les adresses de manière à ce qu’il soit difficile de récupérer les données en clair. Maintenant il y a d’autres données qui peuvent être sensibles tels que les horodates, et il est établi en transmettant trop de données ou des données trop précises on peut inférer les données initiales ou permettre des croisements de données. Il faudra donc être attentifs à ce qu’on envoie.
Oui, sachant que étant donné qu’on prévoir de hasher l’adresse des bounce records échangés dans la fédération, il est impossible de retrouver l’adresse originale qui a fait l’objet d’une typo puisque son hash ne correspondra pas.
Oui c’est vrai. Bon là dessus je ne sais pas quoi répondre pour l’instant !
Dans mon idée, il faudrait idéalement faire le nécessaire pour que les données de bounces ne puissent pas être qualifiées de données personnelles, précisément pour éviter d’avoir à établir une relation de confiance plus complexe qu’actuellement. Parce que si cela devient des données personnelles, ça veut dire qu’il faudra que l’émetteur déclare toutes les organisations qui auront accès aux données comme sous-traitants dans leurs CGUs.
Merci pour le schéma c’est effectivement plus clair comme ça.
Pour la question RGPD/etc. :
Si on partage uniquement les bounces pour adresse invalide, effectivement peut-être qu’on peut imaginer qu’une adresse invalide hashée n’est pas forcément une donnée personnelle, mais je pense qu’une adresse invalide qui contient juste une typo, et qui est hashée, pourra éventuellement être considérée comme une donnée personnelle pseudonymisée, et donc toujours soumise au RGPD.
Le problème : on ne peut pas savoir automatiquement qu’une adresse coucouinvalide@gmeuhmail.com n’est pas une donnée personnelle mais que jeanne.dupnot@gmeuhmail.com en est une car faute de frappe mais indique quand même un nom/prénom.
Pour les soft bounces ou hard bounces liés à d’autres motifs que l’adresse invalide, on ne peut pas échapper au fait que certaines des données de bounce puissent être qualifiées de données personnelles pseudonymisées.
Pour moi c’est pour ça que c’était important que l’info de bounce soit renvoyée par le relais partenaire vers le relais originel. Ainsi c’est le relais originel, et lui seul, qui décide vers qui partager cette info.
On peut décider, pour des raisons de RGPD, ou d’anonymat de ses utilisateurs, qu’on ne veut pas partager nos bounces avec d’autres relais du réseau, et ça me semble légitime comme besoin.
Ce n’est pas incompatible avec le fait que le relais partenaire conserve aussi l’info du bounce, c’est juste que c’est pas à lui de décider s’il doit partager ce bounce avec le reste du réseau, à mon sens.
Le but ici est que tu reste en maîtrise du partage des données de tes utilisateurs. Le relais partenaire peut effectuer du stockage d’adresses en bounce pour ses besoins de protection de réputation, mais il ne doit pas décider à ta place avec qui ce bounce sera partagé.
Pour la question de déclaration dans les CGU, tu devrais de toutes façons le faire, comme le dit @sekil : le relais partenaire aura accès à l’adresse expéditrice et à l’adresse destinataire, donc fera du traitement de données personnelles.
). En fait j’ai également pensé à cette problématique lorsque j’ai écris ma réponse, et je pense que cela fait aussi écho à des commentaires relatifs au RGPD que l’on avait eu dans notre sondage.