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

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


DKIM, comme tout en-tête SMTP, s’ajoute en haut du mail au fur et à mesure qu’il passe tel et tel logiciel (comme une pile), et ne concerne donc que les en-tête en bas. Si quand t’ajoutes un en-tête, tu le fais en bas, bah c’est une mauvaise pratique.

De toute façon, dkim spécifie les headers signés, donc tout nouveau header ajouté, sauf à être redondant avec les autres, et placé en dessous, n’est pas concerné. Le plus chiant avec dkim, c’est évidemment qu’on signe le corps. Mais comme je disais, on peux dire qu’on signe le corps que du début jusqu’à tel octet.

L’effet « sparadrap » ça s’appelle un protocole ouvert et décentralisé. Nomément : l’un des plus vieux d’entre eux, je crois le plus vieux de la couche applicative. C’est sûr qu’un truc centralisé et récent comme Signal est plus simple, puisque tout est interdit. Mais c’est au final pas forcément plus fiable, plus libéral (au sens politique), ou aussi pérenne.

Mais si je veux [0], moi aussi je peux décider de faire une implé dkim qui signe avec des paramètres crypto extraits d’une clé PGP, qui se trouve plusieurs fois dans le DNS, réutilisée dans DNSSEC, DANE, TLSA, etc. et qui remplace tous les autres types d’auth, le tout en passant par Tor. Puis j’appelle ça différemment que le mail, je rend ça privateur, ou centralisé, au choix, et les gens vont se mettre à dire que c’est mieux, plus simple, parce que c’est moins le bordel, alors que j’ai simplement repris de l’existant, ce qui prouverait que l’existant est très bien.

Au final principe de robustesse oblige : le mieux est de gérer un maximum de truc (notamment en sortie), en commençant par le plus vieux et largement déployé, et de tout additionner, de sorte à ce que rien ne soit exclusivement obligatoire en entrée.

Après c’est du taff de tout vérifier, et de tout émettre, donc c’est pour ça que je dis que c’est une plaie d’arbitrairement imposer des trucs, plutôt que de laisser choisir. Chacun devrait suivre le principe de robustesse et donc pas arbitrairement filtrer/refuser des mails pour ce genre de raisons techniques.

[0] non en vrai si je veux je peux pas forcément j’ai pas les compétences, l’organisation, la concentration et le temps nécessaire pour, pour l’instant, malheureusement, je crois.



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