Wenn Ihr das Problem schon so weit analysiert habt, dann macht doch zu bitte einen Bug auf. Ich denke, dass auch ein Link hier ins Thema womöglich für's Erste für Kai in Ordnung wäre.
S/MIME: Digitale Unterschrift ungültig
-
- 91.*
- Linux
-
MAlfare -
25. Juli 2022 um 17:05 -
Geschlossen -
Unerledigt
-
-
Sieht also so aus, als ob da beim Transport über den GMX-SMTP-Server eine Maus ein Leerzeichen weggefressen hat
Nicht nur das – die Textkodierung hat sich geändert!
Wenn ich das mit deinem Beispiel nachstelle, kodiert TB die Mail (ohne PGP-Signatur) folgendermaßen:
[box]Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
[/box]und die empfangene Mail ist ebenfalls so kodiert.
Mit PGP-Signatur kodiert TB die ausgehende Mail so:
[box]Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
test
--=20
------------------------------------------------------
Ing. Andr=C3=A9 Nachname
Stra=C3=9Fe Hausnummer
Land PLZ Ort
-----------------------------------------------------*
[/box]Nicht-ASCII Zeichen und das Leerzeichen im Signaturtrenner werden ausgangsseitig (und auch in der empfangenen Mail) richtig kodiert und somit ist die Signatur gültig. GMX würde die Mail in diesem Fall sehr wahrscheinlich unangetastet lassen.
Bei dir gibt es aber den Unterschied im 'Content-Transfer-Encoding:' zwischen ausgehender und empfangener Mail! Falls TB mit 'S/MIME' Signatur die Mail nicht als 'quoted-printable' kodiert und ob GMX das zu Recht 'korrigiert' oder ob das ein Fehler in TB ist, kann ich nicht beurteilen. Dazu müßte man sich näher mit den RFCs beschäftigen …
Neue Erkenntnisse:
Es liegt an Thunderbird UND am GMX-SMTP-Server.
Lasse ich den Signaturtrenner und é und ß weg, ist in der gesendeten, wie auch in der empfangenen Mail die Codierung 7bit und die Dig. Sign. O.K.
Verwende ich stattdessen den SMPT-Servver von A1 sind beide 8bit-codiert und die dig- Sign. ist O.K mit Sinaturtrenner und unabhängig vom Inhalt.
Der GMX-SMTP-Server sollte das umcodieren von 8bit auf quoted-printable ganz einfach unterlassen.
Thunderbird hat aber scheinbar mit irgeneinem Update ebenfalls ein Problem eingeführt:
ZitatThen enter mailnews.send.jsmodule on top and change that to false
(vom oberen Link) scheint das Problem gelöst zu haben.
Thunderbird versendet dann bereits printed-qoutable, weshalb keine umcodierung stattfindet und die dig. Signatur ist O.K.
-
Lasse ich den Signaturtrenner und é und ß weg, ist in der gesendeten, wie auch in der empfangenen Mail die Codierung 7bit und die Dig. Sign. O.K.
Klar – bei reinem ASCII besteht ja auch kein Grund, die Mail umzukodieren.
Der GMX-SMTP-Server sollte das umcodieren von 8bit auf quoted-printable ganz einfach unterlassen.
Du hast ja schon herausgefunden, wie unkooperativ sie sind – an der Stelle wirst du nicht weiterkommen, dazu sind sie einfach zu groß.
[box]mailnews.send.jsmodule false[/box]
Traurig – das Problem existiert anscheinend schon seit Version 88.0beta, wirkt sich aber offensichtlch nur bei S/MIME aus, s.:
Thunderbird — Beta Notes (88.0beta)www.thunderbird.netBei mir stehen die Einträge 'mailnews.*.jsmodule' auf 'true' und es gibt keine Probleme mit einer PGP-Signatur (und somit auch nicht mit GMX oder anderen Providern, die meinen, etwas korrigieren zu müssen).
-
Lasse ich den Signaturtrenner und é und ß weg, ist in der gesendeten, wie auch in der empfangenen Mail die Codierung 7bit und die Dig. Sign. O.K.
Klar – bei reinem ASCII besteht ja auch kein Grund, die Mail umzukodieren.
Der GMX-SMTP-Server sollte das umcodieren von 8bit auf quoted-printable ganz einfach unterlassen.
Du hast ja schon herausgefunden, wie unkooperativ sie sind – an der Stelle wirst du nicht weiterkommen, dazu sind sie einfach zu groß.
[box]mailnews.send.jsmodule false
[/box]Traurig – das Problem existiert anscheinend schon seit Version 88.0beta, wirkt sich aber offensichtlch nur bei S/MIME aus, s.:
https://www.thunderbird.net/en-US/thunderb…a/releasenotes/
Bei mir stehen die Einträge 'mailnews.*.jsmodule' auf 'true' und es gibt keine Probleme mit einer PGP-Signatur (und somit auch nicht mit GMX oder anderen Providern, die meinen, etwas korrigieren zu müssen).
Welche Version verwendest du, und welche Codierung verwendet dein Thunderbird beim Versenden?
Mein TB hat die Version 91.11.0 und verwendet nach der angeführten Änderung quoted-printable, vorher 8bit.
-
Welche Version verwendest du, und welche Codierung verwendet dein Thunderbird beim Versenden?
Ich arbeite mit Version 91.10.0 (64 Bit) auf 'arm64' (Raspberry Pi-400).
Grundsätzlich sind ausgehende Mails hier mit
kodiert, außer mit einer PGP-Signatur, wie oben in den Beispielen gezeigt. Dann kodiert TB die Mail ebenfalls in 'quoted-printable'.
-
in meinem Fall immer mit 8bit auch mit S/MIME-Signatur.
Dürfte auch nicht behoben werden, der Bug-Report Status steht auf RESOLVED INVALID
1745458 - Messages incorrectly signed using S/MIME when special characters are present (because amavisd-new changed the message)RESOLVED (nobody) in Thunderbird - Untriaged. Last updated 2022-02-02.bugzilla.mozilla.orgZitatStatus: UNCONFIRMED → RESOLVED
Closed: 8 months ago
Resolution: --- → INVALIDAuf jeden Fall vielen Dank für die Hilfe zur Selbsthilfe!
-
Auf jeden Fall vielen Dank für die Hilfe zur Selbsthilfe!
Gern geschehen – ich mag solche Fehler und wenn die Zusammenarbeit so gut funktioniert, umso mehr.
-
Ich habe das Problem mit den beiden (Umgehungs-)Lösungen kurz zusammengefaßt:[box]
12.08.2022
Das Problem existiert schon seit Längerem (TB 88.0.0?).
TB 91.1.0
Digitale Signatur (S/MIME) ungültig bei Verwendung des GMX_SMTP-Servers UND vorhandenen Nicht-ASCII-Zeichen UND/ODER Signaturtrenner.
TB versendet "Content-Transfer-Encoding: 8bit" GMX codiert um in "Content-Transfer-Encoding: quoted-printable"
Führt zu einer ungültigen Signatur
Der SMTP-Server von A1 tut das nicht, die Signatur bleibt gültig.
Diese beiden Änderungen in den Einstellungen von TB beheben/umgehen das Problem:
Herausgefunden hat das : Marcin Wilk, im Dezember 2021
1.) Then enter *mailnews.send.jsmodule* on top and change that to *false*.
--> TB versendet: Content-Transfer-Encoding: quoted-printable
2.) Sending with *mail.strictly_mime* set to *true* also is working fine with the bad server.
--> TB versendet: Content-Transfer-Encoding: base64
Derzeit verwende ich Version 2.[/box]
-
Then enter *mailnews.send.jsmodule* on top and change that to *false*
Das Problem daran ist, dass dies irgendwann in einer zukünftigen Version nicht mehr gehen wird.
-
Tja, darüber werde ich mir den Kopf zerbrechen (müssen), wenn es soweit ist.
Nachdem ich aber weder Einfluß auf GMX, noch auf die Entwicklung von Thunderbird habe, bleibt mir nichts anderes übrig, als mit einer Lösung zu leben, die JETZT funktioniert, auch wenn es nur eine Umgehungslösung ist.
-
Wenn Ihr das Problem schon so weit analysiert habt, dann macht doch zu bitte einen Bug auf. Ich denke, daß auch ein Link hier ins Thema womöglich für's Erste für Kai in Ordnung wäre.
Wenn ich wüßte wie, vielleicht.
Warum nur vielleicht: Weil es bereits einen gab:
1745458 - Messages incorrectly signed using S/MIME when special characters are present (because amavisd-new changed the message)RESOLVED (nobody) in Thunderbird - Untriaged. Last updated 2022-02-02.bugzilla.mozilla.orgClosed Bug 1745458 Opened 8 months ago Closed 8 months ago
Tracking Status: RESOLVED INVALIDIn Kurzform klingt das für mich nach: Der SMTP-Server ist Schuld, uns geht das nichts an.
Bereits erwähnt auch:
Thunderbird — Beta Notes (88.0beta)www.thunderbird.netWer ist Kai?
-
Wer ist Kai?
-
Community-Bot
3. September 2024 um 20:50 Hat das Thema geschlossen. -