Anführungsstriche sind drin und Schlüsselpaar ist seit langem unverändert.
An wen muss ich mich wenden, um einen Bug zu eröffnen?
Anführungsstriche sind drin und Schlüsselpaar ist seit langem unverändert.
An wen muss ich mich wenden, um einen Bug zu eröffnen?
Könntest du den Link zum Bug hier hinterlassen? Mich würde interessieren, ob das am Ende ein Bug ist, oder ob die anderen Programm einschließlich Thunderbird/Enigmail nur großzügiger sind.
Hab das ausprobiert. Die Änderung führt nur dazu, dass die Mail nun als PGP- Verschlüsselt erkannt wird. Allerdings ist nach wie vor kein Mailtext zu sehen (nur leeres Fenster) und der Anhang, der mitgeschickt wurde ist auch nicht da.
Neben dem Text "OpenPGP" ist nun ein rot durchgestrichenes Schloß zu sehen. Wenn man draufklickt kommt die Meldung: "Es gibt unbekannte Probleme mit dieser verschlüsselten Nachricht."
RFC3156 beschreibt, wie eine mit OpenPGP verschlüsselte Mail zu deklarieren ist. Den Block «Content-Type: multipart/encrypted» nochmals in einen Block «Content-Type: multipart/mixed» einzubetten - so wie totemomail es macht - ist dabei nicht vorgesehen.
Ob das erlaubt ist, kann ich nicht beurteilen, aber die Auswirkungen sind ja sichtbar.
nochmals in einen Block «Content-Type: multipart/mixed» einzubetten - so wie totemomail es macht - ist dabei nicht vorgesehen.
Wo steht das? Habe ich nicht gefunden. Oder schließt du das allein daraus, dass es nicht erwähnt ist? Das wäre m.E. eine unerlaubte Folgerung. Beispiel: PGP/Inline kann Anhänge nicht mit der Mail verschlüsseln, wie es bei MIME geht. Eine Inline Mail mit Anhang wird dann wohl einen mixed Block haben. Vermute ich mal, weil jede normale Mail mit Anhang diesen Content-Type hat.
Der RFC gilt ausdrücklich für OpenPGP. Vielleicht liegt eher darin der Grund und Thunderbird ist durch das integrierte OpenPGP nicht mehr 100% kompatibel zu GnuPG, OpenKeyChain etc. . Die von dir ignorierten Hinweise von airnobi, dass nämlich andere Programme diese Mails entschlüsseln können und selbst Thunderbird bis zur 68 es konnte, würden sehr gut dazu passen. Keine Ahnung. Ich meine, man sollte die Antwort die Experten überlassen und einen Bug aufmachen.
Hier der Link zum Bug:
Guter Schritt. Wenn die Entwickler das Thema nicht schon kennen sollten, wirst du bestimmt gefragt, mehr Infos zu liefern. Die brauchen bestimmt ein konkretes Beispiel.
Die Hinweise, die du hier gegeben hast, sollten dort auch rein. Also, dass es alle Mails von dieser Firma betrifft, egal welcher Absender. Dass Thunderbird 68 keine Probleme hatte, dass K-9 die Mails entschlüsseln kann. Vielleicht kannst du das noch ergänzen? Sonst haben die keinerlei Ansatzpunkte.
Hab noch ein paar Infos ergänzt.
Hab das ausprobiert. Die Änderung führt nur dazu, dass die Mail nun als PGP- Verschlüsselt erkannt wird. Allerdings ist nach wie vor kein Mailtext zu sehen (nur leeres Fenster) und der Anhang, der mitgeschickt wurde ist auch nicht da.
Neben dem Text "OpenPGP" ist nun ein rot durchgestrichenes Schloß zu sehen. Wenn man draufklickt kommt die Meldung: "Es gibt unbekannte Probleme mit dieser verschlüsselten Nachricht."RFC3156 beschreibt, wie eine mit OpenPGP verschlüsselte Mail zu deklarieren ist. Den Block «Content-Type: multipart/encrypted» nochmals in einen Block «Content-Type: multipart/mixed» einzubetten - so wie totemomail es macht - ist dabei nicht vorgesehen.
Ob das erlaubt ist, kann ich nicht beurteilen, aber die Auswirkungen sind ja sichtbar.
Ich habe das gleiche Problem mit einer Mail von totemomail.
Ich habe, dank der Hinweise hier, mal ein wenig experimentiert und den äußeren multipart/mixed Block um den inneren multipart/encrypted Block (mit der Nachricht) entfernt und somit auch den zweiten Teil des multipart/mixed Blocks.
Und siehe da: Thunderbird konnte den PGP Teil problemlos entschlüsseln und darstellen.
Diese Info gehört dringend in den Bug. Sie könnten den Entwicklern Arbeit ersparen. Die waren schnell. Es gibt schon ein Update, wonach der verschlüsselte Teil ok ist. Nun kommt die spannende Frage, ob das eine Verletzung seitens Totemo ist oder vielleicht eine Einschränkung von OpenPGP-Mails gegenüber GnuPG oder ob der Thunderbird zu streng agiert.
Ich habe, dank der Hinweise hier, mal ein wenig experimentiert und den äußeren multipart/mixed Block um den inneren multipart/encrypted Block (mit der Nachricht) entfernt und somit auch den zweiten Teil des multipart/mixed Blocks.
Und siehe da: Thunderbird konnte den PGP Teil problemlos entschlüsseln und darstellen.
Hier mal ein Beispiel, wie Thunderbird (78.14.0) das macht:[box]
MIME-Version: 1.0
Subject: ...
Content-Type: multipart/encrypted;
protocol="application/pgp-encrypted";
boundary="xAeQMX5W3MZrXwiLOrZwWqBqgWj1F86R8"
This is an OpenPGP/MIME encrypted message (RFC 4880 and 3156)
--xAeQMX5W3MZrXwiLOrZwWqBqgWj1F86R8
Content-Type: application/pgp-encrypted
Content-Description: PGP/MIME version identification
Version: 1
--xAeQMX5W3MZrXwiLOrZwWqBqgWj1F86R8
Content-Type: application/octet-stream; name="encrypted.asc"
Content-Description: OpenPGP encrypted message
Content-Disposition: inline; filename="encrypted.asc"
-----BEGIN PGP MESSAGE-----
…
-----END PGP MESSAGE-----
--xAeQMX5W3MZrXwiLOrZwWqBqgWj1F86R8--[/box]
Der Block «Content-Type: multipart/encrypted» enthält drei Teile:
Bleibt die Frage, ob es nur einen «richtigen» Weg gibt oder mehrere. Dann wäre Mozilla in der Pflicht …
Servus,
Interessantes Thema. Mich erinnert es an ein Problem mit MS Exchange, bei dem ebenfalls die Struktur PGP-verschlüsselter E-Mails verändert wurde bzw. wird. Mir hat zwar mal jemand die Mimes und Content-Types in E-Mails erklärt, ich bekomme es aber nicht mehr zusammen. Diese reinen Mail-Interna haben mich, im Gegensatz zur Verschlüsselung an sich, nie wirklich interessiert.
Zum Thema: Siehe Abschnitt 4.1. in diesem Artikel von der IETF: https://tools.ietf.org/id/draft-dkg-o…angling-00.html
Das sieht sehr ähnlich aus. Die Ursache wäre demnach der MTA. Vielleicht bringt es euch weiter.
Pfiats eich.
Susanne
Zum Thema: Siehe Abschnitt 4.1. in diesem Artikel von der IETF: https://tools.ietf.org/id/draft-dkg-o…angling-00.html
Das sieht sehr ähnlich aus. Die Ursache wäre demnach der MTA. Vielleicht bringt es euch weiter.
Danke für den Link, der bestätigt, daß es nur eine korrekte Deklaration gibt (wie in RFC 3156 beschrieben):
"An e-mail message with OpenPGP encryption and/or signature has standard form."
Damit hat für mich totemomail den «Schwarzen Peter». Thunderbird hält sich an den Standard und es kann nicht die Aufgabe eines MUA sein, aus «Schrott» etwas Brauchbares zu zaubern.
Damit hat für mich totemomail den «Schwarzen Peter». Thunderbird hält sich an den Standard und es kann nicht die Aufgabe eines MUA sein, aus «Schrott» etwas Brauchbares zu zaubern.
Nein, das kann und darf man so nicht daraus ableiten. Deshalb hatte ich mich auch nicht dazu geäußert. Du interpretierst etwas hinein, was dort nicht steht.
Du interpretierst etwas hinein, was dort nicht steht.
1. Würde es bedeuten, dass andere Programme einschließlich Thunderbird/Enigmail sich nicht an den Standard halten würden. Siehe auch Punkt 3.
Thunderbird hält sich beim Verschlüsseln an den Standard, wie RFC 3156 ihn vorgibt, s. mein Beispiel in #31. Daß Vorgängerversionen von TB und andere Programme versuchen, aus verunstalteten Mails noch etwas Brauchbares herauszuholen, bedeutet nicht, daß sie sich nicht an den Standard halten.
2. Gibt es nicht den Standard. Es gibt eine ganze Reihe weiterer RFCs. Inline/PGP unterscheidet sich zum Beispiel deutlich von PGP/MIME.
Inline/PGP interessiert im vorliegenden Fall überhaupt nicht.
3. Die RFCs lassen stets einen gewissen Spielraum, wie gerade am Beispiel K-9 gezeigt. Manches muss eingehalten werden, anderes ist optional.
Dann zeige doch mal, wo in RFC 3156 (oder einem anderen RFC in Verbindung mit «OpenPGP/MIME) der Block «multipart/mixed» optional ist. Aus deinem Link:
"One common mangling takes an incoming multipart/encrypted e-mail and transforms it into a multipart/mixed e-mail, shuffling body parts at the same time."
4. Laut dem Artikel ist es der MTA, der diese "Umformung" vornimmt, nicht Totemo.
Ich empfehle einen Blick auf den Quellcode in #1 zu werfen:[box]
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: OpenPGP totemomail
Comment: totemomail OpenPGP - http://www.totemo.com[/box]
Totemo ist sowohl für die Verschlüsselung als auch für den Transport verantwortlich. Sie haben die Mail «verunstaltet»!
Kann ich mir jetzt nicht verkneifen!
Geht es jetzt wieder los?
Tatsache ist, dass der von mir verlinkte Artikel den Rückschluss, den du ziehst nicht erlaubt. Weder in die eine noch in die andere Richtung. Du legst die Information darin aus, wie es dir passt.
Du benimmst dich wie unsere Politiker, die gerade im Wahlkampf stecken. Du gehst das Thema voreingenommen an, ignorierst Punkte, die dir nicht ins Bild passen und stellst unbewiesen Behauptungen auf. Beispiel:
Totemo ist sowohl für die Verschlüsselung als auch für den Transport verantwortlich. Sie haben die Mail «verunstaltet»!
Der von dir zitierte Code-Block aus der Mail zeigt, dass Totemo für die Verschlüsselung verantwortlich ist. Genau das ist die Funktion dieser Software. Die Entwickler haben bereits bestätigt, dass die vollkommen korrekt ist.
Dieser Code-Block besagt gar nichts über den Transport, der von den Mailservern und deren MTAs übernommen wird. Spätestens für den MTA/MDA beim Empfänger kann Totemo gar nicht mehr verantwortlich sein. Ob also Totemo die fraglichen Content-Type Header so erstellt hat oder nicht, geht daraus nicht hervor. Ob absichtlich oder aus Unwissenheit. Damit täuschst du die Leser.
Der Autor der IETF schreibt klar, dass typischerweise MTAs so etwas machen. Darauf wollte ich hinweisen. Es ist unsachlich und dreist, das so zu verdrehen.
Ich frage mich auch, welchen Sinn das Getue haben soll. Wem ist damit geholfen? Totemo wird laut eigenen Angaben von mehrere Millionen Personen benutzt. Das Problem haben aber nur die Benutzer von Thunderbird ab Version 78. Selbst wenn die Ursache bei Totemo liegen sollte, PGP mit Thunderbird ab 78 spielt in deren Umfeld keine große Rolle. Deren Kunden kommen aus dem Firmenumfeld und benutzen vorwiegend Outlook mit S/MIME. Selbst in diesem Fall sollte sich m.E. eher Thunderbird bewegen, damit er im Geschäft bleibt. Außerdem konnte der Thunderbird das ja mal, vor der 78, mit Enigmail.
Meine Intention war, hier einen Hinweis zu geben. Ganz neutral. Ich will weder Totemo noch Thunderbird beschuldigen. Ich werde mich deshalb auch ganz bestimmt nicht erneut in eine unsachliche Diskussion mit dir ziehen lassen. Allerdings verwahre ich mich davor, dass du meine Hinweis hier "ideologisch" verdrehst.
Geht es jetzt wieder los?
Nein, zumindest nicht weiter mit mir. Ich lasse mich auf das Spiel nicht weiter ein.
Ob also Totemo die fraglichen Content-Type Header so erstellt hat oder nicht, geht daraus nicht hervor.
Nun - bei sorgfältigem Lesen erkennt man leicht den Header «X-Mailer: Totemo_TrustMail_(Notification)» innerhalb des Blocks «Content-Type: multipart/mixed;»
Ein fremder MTA wird ja wohl kaum so dreist sein, dort einen gefälschten Header unterzubringen.
/*
Für diejenigen, die sich für Verschlüsselung interessieren, möchte ich off-topic ergänzen, wie solche Unternehmenslösungen von Totemo, Symantec usw. funktionieren. Ich beschränke mich auf die Gateways.
Ich selbst kenne diese Lösungen nur als Empfängerin. Wir haben Kunden, die solche Lösungen einsetzen, weil diese bestimmte Inhalte nur verschlüsselt übertragen dürfen. In unserem Fall sind das meist technische Daten, aus denen Dritte Rückschlüsse ziehen könnten.
Es gibt Aussagen, wonach mehr als 50% aller Geschäftsmails irgendeine Art schützenswerte Information enthalten.
Nun weiß man, dass Verschlüsselung von E-Mails seine Tücken hat und sehr viele Anwender auch schlicht überfordert. Hier kommen diese Lösungen ins Spiel. Sie vereinfachen das sehr. Im Idealfall muss der einzelne Mitarbeiter sich überhaupt nicht damit befassen.
Angenommen, ein Unternehmen möchte, dass sämtliche E-Mails, egal ob intern oder mit externen Partnern, verschlüsselt werden. Und zwar so, dass die Mitarbeiter sich nicht kümmern müssen und auch nichts falsch machen können.
Die Lösung sieht dann so aus, dass alle E-Mails zunächst über ein Gateway laufen, das vor den Mail- / SMTP-Server geschaltet ist. Dort existiert für jeden Empfänger ein Profil mit dessen öffentlichem Schlüssel. Das Gateway verschlüsselt dann jede Mail passend. Umgekehrt entschlüsselt es jede eingehende E-Mail, überprüft die gemäß der Unternehmensrichtlinien und stellt sie dann dem Mailserver zu.
Ist für einen Empfänger kein Profil vorhanden, geht die E-Mail zunächst nicht raus. Stattdessen bekommt der Empfänger eine Nachricht, in der er gebeten wird, sich ein Profil zu erstellen. Dazu genügt oftmals schon ein digital signiertes Reply. Erst dann und nach den erforderlichen Genehmigungen geht die ursprüngliche E-Mail verschlüsselt raus.
Dass alle E-Mails verschlüsselt werden, ist etwas praxisfremd. Es gibt deshalb auch ein anderes Modell. Hier verschlüsselt der sendende Mitarbeiter selbst. Das Gateway entschlüsselt, prüft die E-Mail und verschlüsselt sie dann erneut. Ebenso in der Gegenrichtung.
Das alles kann auch regelbasiert erfolgen. Ebenso kann festgelegt werden, welche Zertifikate (Herausgeber) akzeptiert werden, welche Gültigkeitsdauer sie haben müssen, ob man PGP überhaupt verwenden darf usw. .
Last but not least gibt es natürlich auch die komplette Ende-zu-Ende-Verschlüsselung. Das möchten Unternehmen verständlicherweise meist nicht, weil sie die Hoheit behalten möchten und gesetzliche Auflagen, z.B. zur Archivierung, erfüllen müssen.
Um das alles zu komplettieren bieten Totemo, Symantec und Co. in diesem Zuge auch Lösungen für Smartphones und den normalen Dateiaustausch via ftps, https, USB-Stick usw. an.
Alles in allem erreicht ein Unternehmen damit, dass E-Mails und alle anderen Dateien nur Ende-zu-Ende-verschlüsselt von A nach B kommen, mit Protokollierung und allem Drum und Dran, ohne dass die Angestellten sich mit den Details herumschlagen müssten.
Informationen, die nur für die Geschäftsführung bestimmt sind (oder die Manager der Abteilung Dieselaggregate ) können auch nur von denen gelesen werden. Selbst im Falle eines Einbruchs.
*/