Ich habe eine eMail bekommen, welche unlesbar ist und deren Quelltext unter anderem die folgenden Angaben enthält:

Content-Type: text/plain
Content-Transfer-Encoding: base64

Das heisst – so nehme ich an – die eMail war mit einer für Windows-Benutzer bestimmten Kodierung verschickt worden. Kann ich als Mac-Benutzer irgend etwas tun, um diese eMail lesbar zu machen?

Und zweitens, wo kann ich mehr zu diesen Fragen lernen?

Vielen Dank für eure Angaben.

Versuch doch mal, die Mail in TextEdit oder BBEdit oder so zu öffnen. Oder, falls es sich um einen Anhang handeln sollte, die Endung zu ändern, oder so.

*daumendrückundmitfühl*

Ties-Malte: Danke für deine Hinweise; wie ich sehe, hattest du ähnliche Schwierigkeiten. Ich habe mir die Decoder-Seite angeschaut, nur, die Kommentare darüber sind nicht gerade ermutigend. Ausserdem wird dort erwähnt, dass base64-kodierte Dokumente auch mit dem StuffIt Expander dekomprimiert werden können (dieses Format wird dort auch angegeben). Also habe ich das ganze Text-Wirrwarr aus de eMail kopiert und eine reine Textdatei damit gemacht und der die Endung .mime gegeben. Der StuffIt Expander hat das dann schleunigst in eine Datei umgewandelt mit einem brauchbaren Titel und einer pdf-Dateiendung. Das ganze konnte dann aber nicht geöffnet werden (siehe Bild). Mit TextEdit ging's bei keinem Versuch (auch nicht als Textdatei), BBEdit habe ich nicht – leider! – weil ich bis jetzt immer dachte, dass mir das Programm, für die seltenen Fälle, wo ich es benötigen würde, zu teuer ist. (Ach, das ist ein Zeugs, wenn man alle Programme legal kaufen will und damit zwar arbeitet, aber kaum verdient!)

bei solchen sachen handelt es sich meist um einen virus der als attachment einer mail beigefügt wurde. die attachments haben diverse endungen wie .pdf, .pif, .com, .exe, .doc usw.
im prinzip können sie deinem mac nicht schaden, aber verschwende keine zeit damit wenn du den absender nicht kennst.

falls doch dann schreib ihm schnell zurück er soll dir das attachment nochmal schicken und vorher mit stuffit komprimieren.

borg:

Nein, es handelt sich nicht um einen Virus, sondern um ein pdf-Dokument, das war mir schon klar.

Zu deiner zweiten Bemerkung: ja, das müsste so gemacht sein, oder, dass Anhänge eben für beliebige Computer kodiert werden (AppleDouble), denn, der Anhang kam aus einem Mac, war aber auch an Windows-Benutzer gerichtet, welche diesen problemlos öffnen konnten.

OSXNerd: Danke für deine ausführlichen Erklärungen! Es kommen einige ergänzende Bemerkungen:

1. Meine Schlussfolgerungen bezüglich Mac/Windows-Kopatibilität machte ich aufgrund der Angaben im von mir benutzten eMail-Programm (Entourage aus Office X), die zugänglich sind wenn ich selbst einen Anhang verschicken möchte (siehe das Bild unten!).

2. Die Möglichkeit, dass die eMail bei der Übertragung verfälscht worden ist, besteht, da es sich um eine weitergeleitete eMail handelt (habe zwar alle < plus ein Leerschritt herausgenommen.

3. Das manuelle Dekomprimieren habe ich nach deiner Anleitung versucht, der von dir angegebene Anfangskode stimmte sogar überein, auch das Schluss-= gab es. Allerdings kann dann StuffIt Expander mit diesem Dokument nichts anfangen. Wenn ich dann noch vor dem Kode praktisch die Deklaration einsetze¹, dann funktioniert das Dekomprimieren, das heisst, genau so, wie in meinem Anfangsbeitrag beschrieben. Das so erzeugte pdf-Dokument kann dann durch den Reader nicht geöffnet werden und es kommt die entsprechende Fehlermeldung.

¹ Content-Type: application/pdf; name = "Dokumenttitel.pdf"
Content-Transfer-Encoding: base64

<b>Ich muss da noch anfügen: </b>Selbstverständlich kann ich mir das PDF noch einmal vom Versender schicken lassen, das ist nicht das Problem. Meine Frage stellte ich, weil ich gerne die Gründe verstehen möchte, welche zu der für mich nicht lesbaren eMail geführt hatten, um dann mit diesem Wissen, den Absender zu instruieren, damit sich das nicht dauernd wiederholt (wie bis jetzt). Und der Absender schickt von einem Mac aus.

Da will ich diesen alten Thread mal wieder mit Leben erwecken.



Unter Tiger Mail habe ich das gleiche Problem ein PDF Anhang nicht enkodiert zu bekommen.

Nach dem normalen Mailtext steht dort:

Content-Type: APPLICATION/OCTET-STREAM; NAME="RG300008881.pdf"
Content-Transfer-Encoding: BASE64

Danach dann alle Daten. Stuffit konnte mir das nicht dekodieren.
Unter Windows über die Weboberfläche kann ich die PDF Datei laden, unter Safari nicht (macht eine kleine html Datei daraus).

Ist Tiger Mail jetzt wirklich so buggy?
Unter Panther hatte ich diese Probleme nie und unter Tiger schon des öfteren.
Es ist zum Verzweifeln.

Vielleicht hat ja noch ein anderer Tiger Nutzer Probleme mit den Anhängen oder der Textkodierung?

Hat dieses Problem mit der Dekodierung der Mail Anhänge wirklich niemand anders mehr außer mir?

Ich gebe es auf und verwende für solche Mails halt Windows unter VPC, oder auf der Arbeit unter Windows zippen und zuschicken, dann geht's.

Ein echtes Armutszeugnis für Apple und Tiger Mail - bin stark enttäuscht.

Öhm, ein echtes Armutszeugnis für Apple und Tiger Mail?

Denn offensichtlich haben andere das Problem nicht. Tut mir für dich zwar Leid, wenn niemand eine Lösung parat hat, aber… Hast du die Mail mal an jemand anderen mit Tiger/Mail.app weitergeleitet? Konnte der die Mail öffnen oder nicht?

Bis jetzt hatte ich noch nie Probleme mit Anhängen, aber du kannst mir ja mal einen schicken

Das Problem ist, daß der Windows-Mail-Client keine standardkonforme Base64-Kodierung hinkiegt. Aber heul ruhig weiter und schieb's Deinem Mac in die Schuhe.

Vielleicht kann mir jemand bei meinem Problem helfen: Mails an Mac-Benutzer empfangen meine Mails mit Bildanhängen problemlos. Mails an Windows-Benutzer empfangen meine Mails mit reinem Text, aber nicht mit Bildanhängen. Bitte macht es nicht zu akademisch, dazu fehlen mir die höheren Mac-Weihen

MacMark:
Das meine ich ja grad:
Windows hat ca 90% Marktanteil und deswegen müßte sich Apple anpassen, auch wenn es keine Standard konforme Base64 Kodierung ist, was das Windows Mail erzeugt.

jesses:
Hast Du die Option "Anhänge Windows-kompatibel senden" bei dem Einfügen der Anhanges über die Klammer, markiert?

JustDoIt:
Noch einmal: Hast du die betreffende Mail mal an jemanden mit Tiger/Mail weitergeleitet, um zu überprüfen, ob es nicht an deinen Einstellungen liegen könnte? Denn ich hatte das Problem schon lange nicht mehr! (Übrigens, hier im Forum gibt es eine Menge Leute, die Tiger/Mail verwenden und zum Überprüfen bereit wären, nur so am Rande… Rantanplan hatte es dir sogar ganz konkret angeboten!)

P.S. Ich bin zwar durchaus der Meinung, dass Programme ggf. auch mit leichten Abweichungen zurechtkommen können müssen, gerade wenn diese Abweichungen häufig vorkommen. Aber das kann natürlich nur in begrenztem Umfang gelten, eher müsste doch die Forderung an die Programmierer gelten, vernünftigen Code zu schreiben! Wohin der Irrsinn sonst führt, haben wir doch beim "Browserkrieg" gesehen.

So, und was für ein System mit welchem Programm mit welchen Einstellungen verwendet der Absender, dessen Zeugs du nicht lesen kannst? Könnte es sein, dass dieser vielleicht einen gewissen Anpassungsbedarf hat?

Tja, Lösung suchen oder lieber nur ein bisschen Apple-Bashing betreiben?

jesses:
Bekommen alle Win-User plain-text ohne Anhang, oder nur einige, die dieses vll. in den Einstellungen drinnen haben? Sonst: Win-kompatibel anklicken, ggf. vorher zippen. Warum die aber plain-text bekommen statt formatierten, weiß ich auch nicht, denn unter "Verfassen" hast du "formatierten Text" ja vermutlich eingestellt, sonst würden Mac-User den ja nicht bekommen…

Mein Problem hat sich erledigt. Obschon ich nichts verändert habe, die Mails kommen jetzt auch mit Bildanhängen an. Vielleicht mußte ich erst das Forum fragen.

Das Problem ist meistens ein Mail-Server zwischen dem Sender und dem Empfänger, der die Message Header verstümmelt - dies sind meistens auf dem Server laufenden Virenscanner (z.B. SpamAssasin), die den Content-Type im Header verändern oder einen zusätzlichen solchen Header hinzufügen. Gemäss RFC2822 ist dies natürlich gar nicht gut und es ist nicht definiert, was in solchen Fällen geschehen soll (i.e., welcher der verschiedenen Header verwendet werden soll).

Mit ein Bisschen Einlesen in RFC2822 und Untersuchung des kompletten Mail Quelltextes lässt sich meistens relativ schnell erkennen, dass Mails die dieses Problem aufzeigen, nicht RFC2822 konform sind (das Problem liegt also nicht an Mail - Thunderbird ist is solchen Fällen meist noch weniger felxibel und zeigt einfach ganze Teile der Maldung gar nicht an!). Falls sich aufgrund der Header erkennen lässt, welcher MailServer (SMTP Server des Senders oder Server des Empfängers) die Mail verstümmelt hat, hilft manchmal einfach eine nette Mail an dessen Sysadmin, um auf das Problem aufmerksam zu machen.

Ist halt mehr Arbeit als einfach zu schreien "Scheisse, funktioniert nicht und ist alles ein Problem dass ich Mail sowieso nicht gerne habe, weil mir die Icons nicht gefallen"

Mit dem Problem "Windows vs. Mac" kann das ganze überhaupt nichts zu tun haben.
<br>
<br>base64 ist eine Standardkodierung, die unabhängig von jedem Betriebssystem genormt ist. Sie ist im MIME-Standard definiert und wird eigentlich von jedem Mailprogramm, das nach 1995 entwickelt wurde, unterstützt.
<br>
<br>Wenn die Mail bei Dir nicht dekodiert werden kann, ist sie entweder auf dem Übertragungsweg verfälscht worden, oder das absendende Mail-Programm hat die Daten fehlerhaft kodiert. Danach sieht es eher aus, denn die Kombination der Angaben "text/plain" mit einer base64-Kompression ist sehr ungewöhnlich.
<br>
<br>AppleDouble ist eine alte Technik (aus der Mac OS-Zeit), Dateien nochmal in eine Hülle zu packen, damit Typcodes und Resource-Forks nicht verloren gehen. Da Mac OS X dieses Zeug nicht mehr benötigt, spielt das hier keine Rolle. Diese Technik dient gerade nicht dazu, Dateien kompatibel zu verschicken, sondern ist - genau im Gegenteil - ein Verfahren, das nur für das alte Mac OS gedacht war. Das Verwenden von StuffIt ist aus dem gleichen Grund in Mac OS X unnötig, lohnt sich natürlich trotzdem, um die Datei kleiner zu machen.
<br>
<br>Zum manuellen Dekomprimieren einer base64-Kodierung kannst Du tatsächlich StuffIt verwenden. Prüfe nochmal nach, ob Du den richtigen Textblock kopiert hast: Ab der ersten Zeile des Blocks mit Textzeichen, z.B.
<br>
<br>JVBERi0xLjMNCiX15Pb8DQoNCjcgMCBvYmogPDwgL1R5cGUgL1hPYmplY3QN
<br>
<br>bis hin zur letzten Zeile, die mit "=" endet, z.B.
<br>
<br>MzIwOTgNCiUlRU9GDQo=
<br>
<br>Den Abschnitt von der ersten bis zu letzten Zeile ohne etwas drumherim in TextEdit einfügen, dann mit der Endung "mime" abspeichern. Mit Doppelklick in StuffIt öffnen. Falls der Dateiname nicht dekodiert wird, die entstehende Datei UNKNOWN.001 in Datei.pdf umbenennen.