Question naïve: pourquoi la conversion de forme casse-t-elle la signature ?
Ce n'est pas une question naïve, c'est une vraie question. Quand tu constates que tes mails ont des signatures PGP cassées ou sont rejetés parce que signatures DKIM invalides, et bien tu mets du temps à comprendre ce qui se passe. En tout cas j'ai mis du temps.
La conversion (8bit en 7bit ou l'inverse) casse la clé PGP parce que la conversion change le contenu du mail, donc le contenu ne correspond plus à la clé. Pareil pour DKIM, si on change l'encoding après signature, le contenu et la clé ne correspondront plus.
Alors certes, le serveur de destination ou le client de messagerie qui vérifie les signatures pourrait se dire : "la clé ne correspond pas, essayons de convertir le mail dans un autre encoding, recalculons la clé et vérifions". Mais il y a là trois points d'achoppement :
- vers quel encoding convertir pour tester ? On ne connait pas l'encoding de départ (ou intermédiaire, au moment de la signature), on doit donc tester tous les encodings possibles et imaginables ? C'est super lourd.
- une telle solution ne serait potentiellement exploitable que si tous les MTA et clients décident de le faire. Comme c'est lourd à faire, ce n'est pas gagné.
- Je réitère mon propos : un MTA (Mail Transfer Agent) ne devrait pas avoir à toucher au body d'un mail, uniquement au header. Donc une RFC qui dit que le MTA devrait réencoder un mail est déjà bancale à la base.
Le problème de base vient de la RFC qui dit que les mails en 8bit devraient (should) être convertis en 7bit (il existe plusieurs encodages en 7bits) avant signature DKIM. Du coup, on se retrouve avec : certains serveurs s'en foutent et signe les mails 8bit sans réencoder avant (c'est possible, rien de bloquant dans la façon de calculer la clé), d'autres réencodent en faisant péter l'éventuelle signature PGP, certains serveurs de vérification vont éventuellement accepter les 8bit et faire le calcul comme il faut alors que d'autres feront la conversion parce que c'est dit dans la RFC qu'il faut la faire.
C'est un merdier inextricable qui devrait faire cas d'école sur l'implication d'un seul mot foireux dans une RFC.
[^] # Re: Autohébergement
Posté par xulops (site web personnel) . En réponse au journal Linux ne m'intéresse plus. Évalué à 3.
Ce n'est pas une question naïve, c'est une vraie question. Quand tu constates que tes mails ont des signatures PGP cassées ou sont rejetés parce que signatures DKIM invalides, et bien tu mets du temps à comprendre ce qui se passe. En tout cas j'ai mis du temps.
La conversion (8bit en 7bit ou l'inverse) casse la clé PGP parce que la conversion change le contenu du mail, donc le contenu ne correspond plus à la clé. Pareil pour DKIM, si on change l'encoding après signature, le contenu et la clé ne correspondront plus.
Alors certes, le serveur de destination ou le client de messagerie qui vérifie les signatures pourrait se dire : "la clé ne correspond pas, essayons de convertir le mail dans un autre encoding, recalculons la clé et vérifions". Mais il y a là trois points d'achoppement :
- vers quel encoding convertir pour tester ? On ne connait pas l'encoding de départ (ou intermédiaire, au moment de la signature), on doit donc tester tous les encodings possibles et imaginables ? C'est super lourd.
- une telle solution ne serait potentiellement exploitable que si tous les MTA et clients décident de le faire. Comme c'est lourd à faire, ce n'est pas gagné.
- Je réitère mon propos : un MTA (Mail Transfer Agent) ne devrait pas avoir à toucher au body d'un mail, uniquement au header. Donc une RFC qui dit que le MTA devrait réencoder un mail est déjà bancale à la base.
Le problème de base vient de la RFC qui dit que les mails en 8bit devraient (should) être convertis en 7bit (il existe plusieurs encodages en 7bits) avant signature DKIM. Du coup, on se retrouve avec : certains serveurs s'en foutent et signe les mails 8bit sans réencoder avant (c'est possible, rien de bloquant dans la façon de calculer la clé), d'autres réencodent en faisant péter l'éventuelle signature PGP, certains serveurs de vérification vont éventuellement accepter les 8bit et faire le calcul comme il faut alors que d'autres feront la conversion parce que c'est dit dans la RFC qu'il faut la faire.
C'est un merdier inextricable qui devrait faire cas d'école sur l'implication d'un seul mot foireux dans une RFC.