k9-Mail und APG

J

jochen-01

Stammgast
123
Hallo,

ich habe ein sehr störendes Problem mit k9 in Verbindung mit APG (gnupg). Wenn ich eine verschlüsselte Mail lesen will, zeigt k9 die nur als Anhang. Wähle ich "öffnen", kommt die Meldung, "es wurde kein Anzeigeprogramm für application/pgp gefunden". Die Mail hatte ich unmittelbar zuvor mit k9/APG verschlüsselt verfaßt und geschickt.

Wie bringe ich mein Telefon dazu, den mime type application/pgp mit APG zu öffnen?
 
hmmm, soll so nicht sein.



Klar kann man diesen Attachment speichern und dann separat öffnen mit APG, aber so ist es nicht unbedingt vorgesehen, es sei denn die Mails haben wirklich einen verschlüsselten File als Attachment.


Bei k9 ist es sonst von Vorteil die Mails nicht formatiert also nur als Text zu schreiben, dann geht alles prima. (..Kontoeinstellungen, Nchricht verfassen, Formatierung auf reinen Text stellen)
 
ottosykora schrieb:
hmmm, soll so nicht sein.
Sehe ich genauso.
Bei k9 ist es sonst von Vorteil die Mails nicht formatiert also nur als Text zu schreiben, dann geht alles prima. (..Kontoeinstellungen, Nchricht verfassen, Formatierung auf reinen Text stellen)
Das hatte ich schon bei der Installation so eingestellt. Es ist auch immer noch so.
 
was ist es denn für ein Attachment? Kann man es speichern und dann mit APG öffnen oder sieht es nach was anderem aus?

Ist es ein pgp text oder ist es binär?

Hast du unter APG, Einstellungen ASCII Armor angewählt? (sonst kann es ja dann binäre Files machen)

Ich betreibe APG mit und ohne k9 und wenn ich es alles als plain text mache dann funktioniert es auch.
--
-----
ja also das mit dem ASCII armor ist es. Wenn Editor auf Text steht und man dann nicht ASCII Daten hat, werden diese in eine binäre pgp Datei gepackt. Wenn es wieder zu ASCII gemacht wird, kann es ja auf Text stehende k9 nun ohne Problem im Mail Body transportieren.
 
Zuletzt bearbeitet von einem Moderator:
ottosykora schrieb:
was ist es denn für ein Attachment? Kann man es speichern und dann mit APG öffnen oder sieht es nach was anderem aus?
Wenn ich es speichere, kann ich es mit APG entschlüsseln.
Ist es ein pgp text oder ist es binär?
Content-Type: application/pgp; format=text; x-action=encrypt
Old-Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Hast du unter APG, Einstellungen ASCII Armor angewählt? (sonst kann es ja dann binäre Files machen)
Gerade getestet: ASCII armor bei APG eingestellt. Leider kein Erfolg. K9 zeigt immer noch die Mail als leer mit Anhang. Wählt man den Anhang aus, beschwert es sich, daß es kein Anzeigeprogramm für application/pgp gäbe.
ja also das mit dem ASCII armor ist es. Wenn Editor auf Text steht und man dann nicht ASCII Daten hat, werden diese in eine binäre pgp Datei gepackt. Wenn es wieder zu ASCII gemacht wird, kann es ja auf Text stehende k9 nun ohne Problem im Mail Body transportieren.
Entweder, bei mir ist das anders, oder ich stehe auf einer ziemlich dicken Leitung.
 
>Old-Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit<

also hier stimmt was nicht

content transfer encoding kann nicht 8-bit sein wenn wir nur ascii Text schicken, weil Internet Email gar keine 8-bit schicken kann, nur 7bit Buchstaben. Damit wird wohl alles eben nochmals als binär ins base64 codiert und dann eben wieder in 8bit Daten umgewandelt.

content transfer encoding muss auf quoted printable lauten auch wenn charset UTF-8 ist.

Bitte schau nochmals nach bei dem Format von Mails ob du nicht dort auf Auto stehst, weil dann ist genau die nochmalige base64 codierung da.

hast du probiert das ganze mit einem Desktopclient zu empfangen?
Wie sieht es dort aus?



Bei mir k9 Version 4.200

Der ursprüngliche Beitrag von 17:35 Uhr wurde um 19:02 Uhr ergänzt:

was mich noch etwas irritiert ist diese old-content...

Ich meine das sieht so aus als wenn es jemand nach dem original Format nochmals ändert.

Bei mir erscheint nichts von 'Old-content'


Kann das mit einem bestimmten Mail Service zu tun haben? Also irgendein Mail Service welcher unbedingt alles in binäre Daten umwandeln will?
 
Zuletzt bearbeitet von einem Moderator:
ottosykora schrieb:
>Old-Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit<

also hier stimmt was nicht

content transfer encoding kann nicht 8-bit sein wenn wir nur ascii Text schicken, weil Internet Email gar keine 8-bit schicken kann, nur 7bit Buchstaben. Damit wird wohl alles eben nochmals als binär ins base64 codiert und dann eben wieder in 8bit Daten umgewandelt.
Sicher?
Bitte schau nochmals nach bei dem Format von Mails ob du nicht dort auf Auto stehst, weil dann ist genau die nochmalige base64 codierung da.
Steht auf &quot;nur Text&quot;.
hast du probiert das ganze mit einem Desktopclient zu empfangen?
Wie sieht es dort aus?
Völlig normal, nachdem gnupg es erfolgreich entschlüsselt hatte. Sowohl mit Thunderbird/Enigmail, als auch mit mutt.
Bei mir k9 Version 4.200
Hier auch.
was mich noch etwas irritiert ist diese old-content...

Ich meine das sieht so aus als wenn es jemand nach dem original Format nochmals ändert.
Na ja, gnupg ändert etwas. Zumindest bei inline encrypted text. Die Änderung wird ja auch sauberst in den Mail-Header eingetragen.
bei mir erscheint nichts von 'Old-content'

Kann das mit einem bestimmten Mail Service zu tun haben? Also irgendein Mail Service welcher unbedingt alles in binäre Daten umwandeln will?
Hier läuft postfix mit dovecot. Die Testmails haben meinen Mailserver nicht verlassen. Noch Ideen?
 
>Na ja, gnupg ändert etwas. Zumindest bei inline encrypted text. Die Änderung wird ja auch sauberst in den Mail-Header eingetragen.<

also was da abläuft ist wirklich etwas merkwürdig.
Warum sollte gnupg etwas zusätzlich ändern? OK es ist eingetragen, aber warum sollte es alles in 8bit von sich aus ändern wenn internet Mail nur 7bit erlaubt und somit muss alles wieder nochmals in 7bit codiert werden.

Also bei dem APG lässt sich ja gar nicht sehr viel verstellen. Ich habe alles ziemlich default, Sym Algo 3DES, Hash SHA-1, Kompressionen standard zip.
Und wie schon erwähnt ASCII Armor, damit eben schon aus dem pgp alles in 7bit kommt.

Automatismen in k9 zur Verschlüsselung etc habe ich abgestellt.

In k9 erstelle ich reine TXT Mails, die werden dann so wie sie sind verschlüsselt und dann, weil sie ASCII sind gesendet und zwar nur mit einem Teil in Mail Body, kein Attachment etc.

Untershcied ist wohl nur dass ich Android 2.3x verwende auf beiden meinen Geräten, sonst nichts.

Ach noch was, bei APG habe ich als Language 'Systemdefault' eingestellt, das ist aber auch schon Deutsch bei mir.

Was passiert wenn du nur ein Clear Sign an einem Text Mail machst? Kommt wenigstens das als Text an oder wird es auch irgendwie eingepackt?


Mein Pubkey ist sonst auf dem Server, F204AC51





----
Internet Mail kann nur 7bit Ascii Zeichen verwenden. Darum ist auch im Fall von binärdaten oder 8bit Chars ein zusätzliches encoding nötig, meistens base64, aber auch UU etc sind möglich.
Also wenn etwas bei dir den simplen 7bit Text nochmals in 8bit umwandelt, muss es dann nochmals in 7bit umgewandelt werden und wird zu einem Attachment weil original 8bit Daten.

Es gibt jedoch proprietäre Mail Protokole die schon von sich aus 8bit verwenden. So war es früher zum Bsp mit Compuserve Mail.
Ich weiss nichts über Postfix, aber kann dieser nicht irgend etwas von sich aus modifizieren oder so ähnlich?

Passiert das gleiche wenn du es über einen sonstigen Provider schickst?

Mein k9 ist gegenwärtig nur auf gmx eingestellt und da geht alles normal.
 
Zuletzt bearbeitet von einem Moderator:
  • Danke
Reaktionen: jochen-01
ottosykora schrieb:
>Na ja, gnupg ändert etwas. Zumindest bei inline encrypted text. Die Änderung wird ja auch sauberst in den Mail-Header eingetragen.<

also was da abläuft ist wirklich etwas merkwürdig.
Warum sollte gnupg etwas zusätzlich ändern?
Macht es nicht. Siehe unten.

OK es ist eingetragen, aber warum sollte es alles in 8bit von sich aus ändern wenn internet Mail nur 7bit erlaubt und somit muss alles wieder nochmals in 7bit codiert werden.
Man kann heutzutage schoin davon ausgehen, daß Internet Mail 8 Bit übertragen kann. Früher wurde da von Mailserver zu Mailserver öfters man hin- und hergewandelt.

Ich behaupte jetzt mal, daß mein Mailserver 8-bit-fest ist. Eine Testmail, die den Server nicht verlassen hat:
Code:
Date: Tue, 20 Nov 2012 18:13:00 +0100
From: Jochen <xxx@yyy.zzz>
To: Jochen <xxx@yyy.zzz>
Subject: Test 8 Bit
Message-ID: <20121120171259.GA17615@xxx.yyy>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.5.20 (2009-06-14)

äöü
Was passiert wenn du nur ein Clear Sign an einem Text Mail machst? Kommt wenigstens das als Text an oder wird es auch irgendwie eingepackt?
Das selbe. Aber hier kommt der Grund:
Code:
# mime type fuer PGP encrypred und PGP signed Emails korrigieren
##:0
* !^Content-Type: message/
* !^Content-Type: multipart/
* !^Content-Type: application/pgp
{
      :0 fBw
      * ^-----BEGIN PGP MESSAGE-----
      * ^-----END PGP MESSAGE-----
      | formail \
          -i "Content-Type: application/pgp; format=text; x-action=encrypt"

      :0 fBw
      * ^-----BEGIN PGP SIGNED MESSAGE-----
      * ^-----BEGIN PGP SIGNATURE-----
      * ^-----END PGP SIGNATURE-----
      | formail \
          -i "Content-Type: application/pgp; format=text; x-action=sign"
}
Den Block habe ich seit ca. 10 Jahren in meiner .procmailrc. Der Grund dafür war, daß damals (tm) einige Mailer den content-type nicht richtig deklariert haben. Deshalb habe ich ihn glatt vergessen.

Jetzt habe ich ihn auskommentiert und Mails lassen sich jetzt auch auf dem Telefon entschlüsseln. Wenn ich in der nächsten Zeit noch Gründe für diesen Block sehe, überlege ich, wie ich das besser hinbekomme.
Mein Pubkey ist sonst auf dem Server, F204AC51
"Found 0 Keys".

Danke für die Hilfe.
 
hmm, also doch ausserhalb des pgp.


>Man kann heutzutage schoin davon ausgehen, daß Internet Mail 8 Bit übertragen kann. Früher wurde da von Mailserver zu Mailserver öfters man hin- und hergewandelt.<

das darf nicht angenommen werden weil dann es nicht mit elementaren RFC kompatibel ist. Auch wenn es der eine oder andere Server theoretisch kann, darf es nicht sein. Internet Mail sieht nur 7bit vor. Aus diesem Grund wird alles was einen Mail client verlässt auf 7bit kodiert, darum werden Attachnments mit base64 oder ähnlichem von je 24bit auf 28bit verlängert und dann wieder durch 4 geteilt und erst so gesendet.
Erscheinen also irgendwo Daten die offensichtlich im 8bit Format vorliegen, werden sie automatisch zu Attachment gemacht.


Der Server ist zwar 8bit tauglich , klar kann er das, aber ein Mail Client darf es nicht und ich kenne so weit keinen Mail Client der sich am Internet Mail beteiligen will und etwas anderes als 7bit Chars produziert (auch k9 kann nichts anderes). Alles muss mit dem Standard für Internet Mail kompatibel sein, sonst könnte man nicht miteinander kommunizieren.
Und wenn formatierte Texte versendet werden (html etc) muss immer noch eine reine Text Version extrahiert werden und an der ersten Stelle im Body liegen.
Erst dann können die nun in 7bit kodierten 8bit (oder binär Daten) Teile angefügt werden.
(dein Mailsystem hat es also richtig gemacht, die 8bit Daten in einem Attachment aus 7bit Chars geschickt, was auch von k9 richtig erkannt wurde)

Es ist nicht so relevant was zwischen Servern hin und her geht, was da noch weiter gepackt wird oder nicht, jedoch sendet ein Client immer 7bit und ein Client ist nur auf 7bit Empfang ausgelegt. Und alles muss genau so am Client eintreffen wie es der Sender geschickt hat.

Alles davon abweichende kann nur in privaten geschlossenen Netzen (die gibt es) verwendet werden. Dort kann man dann Bilder verschicken die nicht als Attachments gesendet werden, alles in einem File, keine Multipart Messages etc wie es bei Internet Mail zwingend ist.
Also dir selber kannst du natürlich schon 8bit respektive reine binär Daten schicken (entsprechend aufgebauten Client vorausgesetzt) über deinen eigenen Server, erwarte nicht dass so was bei einem normalen Internet Mail Nutzer auch richtig ankommt.




Es ist ansonsten nicht sehr gesund Mails nach dem sie den Client verlassen haben nochmals zu modifizieren, hier ging es noch glimpflich ab, aber gerade bei Verschlüsselung und Signaturen kann es fatal sein. Ich würde persönlich alle Mechanismen die versuchen an einem Mail etwas zu ändern nachdem es den Client verlassen hat beseitigen.
Wahrscheinlich wäre zum Bsp eine Mail nach x509 signiert nicht richtig angekommen, dort ist es noch wesentlich empfindlicher auf Änderungen unterwegs.
Na ja, es gibt leider auch einige Mail Provider die versuchen die Mails 'zu verbessern' auf ihren Servern, was eben dazu führt dass die gut gemeinte Infrastruktur für digitale Signaturen unbrauchbar wird.


--
keyserver / suche:
APG unterstüzt keine Suche nach Key ID, nur User ID, ist eben nur ein unvollständiger pgp Agent mit viel weniger als absoluten minimal Funktionen.
Dort musst du schon ottosykora eingeben.
Vernünftige gpg/pgp Frontends genau wie CLI haben natürlich die Möglichkeit nach Key ID oder auch nur Fragmenten davon zu suchen.
 
ottosykora schrieb:
Internet Mail sieht nur 7bit vor. Aus diesem Grund wird alles was einen Mail client verlässt auf 7bit kodiert, darum werden Attachnments mit base64 oder ähnlichem von je 24bit auf 28bit verlängert und dann wieder durch 4 geteilt und erst so gesendet.
Erscheinen also irgendwo Daten die offensichtlich im 8bit Format vorliegen, werden sie automatisch zu Attachment gemacht.
Na ja, ganz so ist es nicht mehr. RFC822 (auch meine Religion) wurde inzwischen erweitert, um das 8-Bit-Problem zu lösen. RFC1652 (von 1994) beschreibt kurz wie das im Header aussehen soll. Unter (MIME) Part One: Format of Internet Message Bodies ist das etwas zusammengefasst. Aber das ist hier ja auch nicht der entscheidende Punkt, da meine procmailrc ja beteiligt war.

Der Server ist zwar 8bit tauglich , klar kann er das, aber ein Mail Client darf es nicht und ich kenne so weit keinen Mail Client der sich am Internet Mail beteiligen will und etwas anderes als 7bit Chars produziert
Z.B. Thunderbird erzeugt sauber deklarierte 8-Bit encoded Text Mails. Die liegen auch im server spool so vor.
Und wenn formatierte Texte versendet werden (html etc) muss immer noch eine reine Text Version extrahiert werden und an der ersten Stelle im Body liegen.
Der Überzeugung bin ich auch. Allerdings halten sich nicht mehr alle HTML-Versender daran (sigh).

Es ist nicht so relevant was zwischen Servern hin und her geht, was da noch weiter gepackt wird oder nicht, jedoch sendet ein Client immer 7bit und ein Client ist nur auf 7bit Empfang ausgelegt.
Nein. Inzwischen nicht mehr (s.o.)
Und alles muss genau so am Client eintreffen wie es der Sender geschickt hat.
Allerdings. Sonst wäre signierte Mail sehr lustig.

Es ist ansonsten nicht sehr gesund Mails nach dem sie den Client verlassen haben nochmals zu modifizieren, hier ging es noch glimpflich ab, aber gerade bei Verschlüsselung und Signaturen kann es fatal sein. Ich würde persönlich alle Mechanismen die versuchen an einem Mail etwas zu ändern nachdem es den Client verlassen hat beseitigen.
Es wurde keine ausgehende Mail modifiziert, sondern eingehende. Außerdem habe ich den Body nicht angerührt (behüte!).

keyserver / suche:
APG unterstüzt keine Suche nach Key ID, nur User ID, ist eben nur ein unvollständiger pgp Agent mit viel weniger als absoluten minimal Funktionen.
Das wollte ich damit gleich mal testen. Ich hatte nicht angenommen, daß die von Dir genannte ID falsch sei. ;-)

Danke nochmal für die zuträglichen Gedanken.
 

Ähnliche Themen

S
  • Sigi43
Antworten
2
Aufrufe
103
Sigi43
S
Gisela13
  • Gisela13
Antworten
8
Aufrufe
753
Gisela13
Gisela13
A
  • anna2
2
Antworten
20
Aufrufe
1.275
PieDieÄj
P
Zurück
Oben Unten