Ich habe das Problem, dass Thunderbird alte Zertifikate nicht löscht und darum neue nicht in den Nachrichten auswählt, weil eben neben den neuen, gültigen auch noch die alten, ungültigen enthalten sind.
Warum willst du alte Zertifikate löschen?
Ich hab noch nie eines gelöscht (außer für Testzwecke erstellte).
In Konteneinstellungen/Ende-zu-Ende-Verschlüsselung habe ich TB nach der Installation eines neuen mitgeteilt, welches er in Zukunft verwenden soll.
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:
Closed Bug 1745458 Opened 8 months ago Closed 8 months ago
Tracking Status: RESOLVED INVALID
In Kurzform klingt das für mich nach: Der SMTP-Server ist Schuld, uns geht das nichts an.
Bereits erwähnt auch:
Wer ist Kai?
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.
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
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]
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
Status: UNCONFIRMED → RESOLVED
Closed: 8 months ago
Resolution: --- → INVALID
Auf jeden Fall vielen Dank für die Hilfe zur Selbsthilfe!
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.
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:
Then 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.
Hmm – im Quellcode (Strg + U) siehst du nicht unbedingt das, was als Zeichenkodierung tatsächlich in der Datei steckt. Ich habe bei meinen Versuchen die beiden Dateien für den Vergleich direkt auf Dateiebene aus der 'Sent'- und der 'Inbox'-Datei extrahiert.
Das habe ich jetzt auch gemacht.
Die Unterschiede:
| Empfangen | Gesendet | |
| Content-Ttransfer-Encoding: | quoted-printable | 8bit |
| Signaturtrenner | =2D-LF (ohne Leerzeichen) | -- LF (mit Leerzeichen) |
| Folge von ----- (Erste und letzte Zeile der "Signatur") | =2D------ | ------- |
| Letzter Buchstabe meines Namens | =C3=A9 | é |
| ...straße | stra=C3=9Fe | straße |
Alles Andere ist identisch, die Nachricht, die nur aus dem Wort "test" besteht, und die digitale Signatur, die so beginnt:
--------------ms010703050308040003020908
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
C6MwggVeMIIDRqADAgECAgMC8XgwDQYJKoZIhvcNAQENBQAwVDEUMBIGA1UEChMLQ0FjZXJ0Das "é" und das "ß" hatte ich versuchsweise auch schon weggelassen, was aber nichts geändert hat.
Sieht also so aus, als ob da beim Transport über den GMX-SMTP-Server eine Maus ein Leerzeichen weggefressen hat 
Was auch erklärt, warum die digitale Signatur gültig ist, wenn ich auf die "Signatur", und damit auch auf den Signaturtrenner verzichte.
Jetzt müßte ich also "nur" noch GMX dazu bringen, dies in Zukunft nicht mehr zu tun. 
Eine Textdatei, die so Sachen wie Adresse, Telefonnummer, E-Mailadresse,.... enthält und an den meisten E-Mails hängt, abgetrennt durch einen "Signaturtrenner" "--LF"
Hier könnte das Problem liegen. Ohne es testen zu können (ich habe kein GMX-Konto mehr) – evtl. 'korrigiert' GMX den Signaturtrenner "--LF" auf die Standard Form "-- LF".
Interessante Idee.
Nur, damit wir einander nicht mißverstehen: Der Signaturtrenner trennt nicht die digitale Signatur von der Nachricht, sondern das visitenkartenähnliche Anhängsel von dieser, in diesem Fall:
------------------------------------------------------
Ing. Vorname Nachname
Straße Hausnummer
Land PLZ Ort
E-Mail: Vorname.Nachname@gmx.at
Mobile: Telefonnummer
Web : URL
-----------------------------------------------------* Ich habe sowohl die gesendete (mit gültiger Signatur) als auch die empfangene Mail (mit ungültiger Signatur) im Quellcode angezeigt und daraus zwei Dateien erstellt. Diese mit Meld verglichen, Meld sagt "Dateien sind Identisch".
Beide Dateien liefern auch den selben HASH-Wert, sind also bitweise identisch!
Wie kann das sein?
Wo liegt mein Denkfehler?
Oder hat das ganze mit Schrödingers Katze zu tun?
In einem Hex-Editor sieht der Signaurtrenner so aus: 2D 2D 20 0A, also -- LF, nicht wie ich früher angeführt habe, --LF (die Leerzeichen sieht man so schlecht) 
Habe gehofft, hier jemanden zu finden, der vielleicht eine Idee hat, was da, und warum passiert.
Die Hoffnung, sagt man, stirbt zuletzt.
Aber irgendwann stirbt sie halt auch.
Ich bin dann mal weg.
Die Frage nach der Datei hast du leider immer noch nicht beantwortet. Aber ich sehe, du weißt wie du dir Freunde machst. Dann schau, wie weit du damit kommst.
Ich bin nicht hier um Freunde zu suchen, sondern zweckdienliche Hinweise zu einem merkwürdigen Verhalten von Thunderbird und GMX-Servern.
Wenn du dich hierhin begeben hättest:
Konteneinstellungen / Konto / "Stattdessen eine Datei als Signatur anhängen (Text,HTML oder Grafik):"
wäre dir (hoffentlich) klar geworden, um was für eine Datei es sich wohl handeln wird.
Eine Textdatei, die so Sachen wie Adresse, Telefonnummer, E-Mailadresse,.... enthält und an den meisten E-Mails hängt, abgetrennt durch einen "Signaturtrenner" "--LF"
Konteneinstellungen / Konto / "Stattdessen eine Datei als Signatur anhängen (Text,HTML oder Grafik):"
Nun, das hier hat zu der Frage von Susi to visit geführt, weil es sich dabei eben nicht um die elektronische Unterschrift handelt, sondern nur um eine Art Fußnote (um das Wort Signatur zu vermeiden) unter der Mail.
Wenn ich die Mail ohne Signatur(datei) versende, ist die dig. Signatur O.K.
Wenn ich Dich hier richtig verstehe, macht es also einen Unterschied, ob Du eine Signatur-Datei an der Mail dran hast oder nicht. Die Signatur-Datei würde also die elektronische Unterschrift brechen. Das würde ja bedeuten, dass die Signatur-Datei womöglich erst nach dem elektronischen Unterschreiben dran gehängt wird. Oder GMX macht irgendwas komisches mit der Signatur-Datei, wodurch die elektronische Unterschrift dann gebrochen wird.
So ist es.
Die Bezeichnung "Signatur" für dieses visitenkartenähnliche Anhängsel habe nicht ich erfunden, auch nicht den Begriff "Signaturtrenner" "--
", der es von der Mail abtrennt.
In den den Konteneinstellungen gibt es die Möglichkeit, den Text für diese "nicht-digitale Signatur" einzugeben, oder eine vorhandene Textdatei zu verwenden. Beides probiert, macht keinen Unterschied. Auch mit und ohne das AddOn Signature Switch.
Gegen die Idee, daß die Visitenkarte nach dem Erstellen der digitalen Signatur angehängt wird, spricht, daß im Ordner "Gesendet" die Signatur gültig ist.
Nachdem aber das alles keine Rolle spielt, wenn ich einen anderen SMPT-Server verwende, habe ich den SMTP-Server von GMX in Verdacht. Oder etwas zwischen meinem Thunderbird und dem/den SMTP-Server(n).
Eine der beiden Fragen war:
Was ist das für eine Datei?
Dir ist bekannt, dass eine Signatur, wie man sie unter den Kontoeinstellungen anhängen kann, etwas ganz anderes ist als die digitale Signatur per S/MIME oder PGP?
Seit Jahr(zehnt)en!
Man sollte andere Menschen nicht für dümmer halten als sich selbst. 
Was meinst du damit? Was ist das für eine Datei?
Konteneinstellungen / Konto / "Stattdessen eine Datei als Signatur anhängen (Text,HTML oder Grafik):"
Hallo!
Ich vermute das Problem nicht in Thunderbird, sondern eher beim SMTP-Server von GMX, aber wer weiß.
Ich nehme aber an, dass es hier Leute gibt, die sich intensiver mit Mail und Thunderbird beschäftigen und vielleicht auch GMX verwenden.
TB: 91.11.0
Linux Mint 20.3
POP3
GMX
Keine AC-Software
Keine Firewall
Das Problem:
Ich signiere meine Mails digital (Zertifikat von CA-Cert). Die Empfänger bekommen die Information, daß die Signatur ungültig sei.
Ich habe einige Tests ausgeführt:
Mail an mich selber gesendet.
Die Signatur in Gesendet ist O.K. die empfangene nicht.
Wenn ich die Mail zusätzlich verschlüßle, ist die Signatur O.K
Wenn ich die Mail ohne Signatur(datei) versende, ist die dig. Signatur O.K.
Wenn ich statt des GMX-SMTP-Server den von meinem Provider (A1) verwende, ist die Signatur auch O.K.
Deshalb mein Verdacht, daß der GMX-SMTP-Server, wenn die Mail nicht verschlüsselt ist und eine Signatur enthält, den Mailinhalt verändert und sie deshalb beim Empfänger mit ungültiger Signatur ankommt.
GMX ist nicht sehr kooperativ
Kann das Problem jemand nachvollziehen, hat Ideen zu Ursache und vielleicht eine Lösung?
