Re: Gmail spam [Re: [EGD-discu] Assemblée extraordinaire]

[ Thread Index | Date Index | More ergodis.org/discussions Archives ]


Non c’est pas méchant mais quand même un minimum arbitraire. Si je veux me baser uniquement sur PGP pour m’auth, plutôt que dkim, je peux pas ? Et si je veux envoyer mes mails par tor ? ou depuis le grand pseudo-internet RATé (sans IP publique) pour éviter de passer par mon VPN distant (et faire plus local, donc plus rapide) ? avec spf c’est chiant (faut tout mettre à autorisé, et là des fois ça pose soucis).

Sans oublier que dkim, c’est de la signature par clé publique asynchrone, donc de l’auth très forte, qui a des avantages comme des inconvénients (toute déclaration vaut preuve, comme chez la police, et toute preuve est transitivement transmissible). Me semble que le fait que l’auth soit aussi forte était le truc qui empêchait Bayart de signer tous ses mails. Et mine de rien je comprends.

Donc si j’autohéberge mon mail sur mon laptop, et que tout est signé par dkim… bah l’auth est aussi forte que si je signais chacun de mes mails via PGP. Parce que quoi, je vais prétendre que qqun d’autre a la clé privée ? alors que tout est hébergé chez moi ? Ici la clé privée dkim comme la clé privée PGP ont le même niveau de sécurité, et si on a l’un, a priori on a l’autre. Le taux de plausible et raisonnable deniability est le même pour les deux.

Alors oui, je parle de cas un peu limite, mais ici on parle de technique plus que de commerce ou politique. Avec aussi peu de mesures (PGP, etc. omis) l’utilisateur final devrait juste être signalé que c’est pas authentifié correctement, et ça devrait passer, pas être filtré.

Pour lutter contre le spam, ya que le contenu de vrai. Pour le reste on peux mutualiser par adresse, mais ça devrait être à l’utilisateur de maîtriser comment il gère ses métadonnées (notamment, la base de l’antispam, se baser sur la liste de contact : ça devrait pas être au serveur d’avoir la liste de contacts, ou de collecter, stocker et garder la liste des gens à qui on écrit dans les faits). Donc à l’utilisateur de choisir son auth préférée.

Bon après là c’est encore plus limite je sais parce que la lutte contre le spam c’est pas juste la nuisance utilisateur mais aussi la bande passante de ouf, m’enfin, à l’heure de la compression qui s’améliore… qui pourrait se mutualiser entre les connections (je suis sérieusement en train d’imaginer zstd qui construit un dictionnaire multi-spam pour permettre aux spams d’origine différentes de mieux se compresser après négociation TLS)…

Et puis si le circuit entre l’utilisateur et le serveur était plus court yaurait pas se problème (genre du SMTP en push entre les deux plutôt que du pop, ou le serveur sur la même machine comme chez moi : là ça serait acceptable de reprendre direct les (méta)données utilisateur).

Enfin je digresse (mais bon comme c’est le (nouveau (re)) topic…)…



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/