Email kommt beim Empfänger unvollständig an

[fa66]

Weshalb bei mir jetzt mehrere Fragezeichen aufleuchteten und ich mich dringend frage, warum es bei einem Thema wie plattformübergreifender Kommunikation so diffizile Barrieren gibt

Die diffizilen Barrieren gibt es, weil der uralte Internet-Dienst »Email« seit 1971 immer weiter aufgebläht wurde, ohne dass der Kern dieses Dienstes das jemals vorsah. Alles was in einer Email mitgesandt wird, muss (und ich hoffe, ich vertu mich hier nicht) auf einen Sieben-Bit-Datenrahmen (also 128 verschiedene Zeichen) heruntergebrochen werden. Da gibt es dann verschiedene Kodierungsmethoden, die das sendende, vor allem aber empfangende Programm (oder in Arbeitsgruppen die betreffende Serversoftware) korrekt interpretieren muss. Falls die dazu nötigen Dienste auf dem Arbeitsgruppenserver (etwa Exchange) nicht aktiviert oder nicht korrekt eingestellt sind, geht schonmal was schief.

+++ also fuesze ruhig halten, groesze bewahren und sich freuen, dass eine email heute in der regel ueberhaupt so komplex aufgebaut sein kann, wie sie es meist ist. sonst saehe sie heute noch fast wie eine fernschreiber-nachricht aus. und da waren es sogar nur fuenf bit +++

 

[fa66]

Ähnlich der ominösen Darstellung von Anhängen als Vorschau innerhalb der E-Mail, die man nur durch den Eingriff übers Terminal unterdrücken kann, verstehe ich die Logik hinter diesen Menübefehlen einfach nicht.

Das sind absolut verschiedene Baustellen.
Die direkte Anzeige unterstützter Dateiformate innerhalb der Email (genauer, innerhalb der Darstellung der Email im Anzeigefenster des benutzen Emailprogramms) ist eine Dienstleistung des jeweiligen Emailprogramms im Verband mit den Fähigkeiten des jeweiligen Betriebssystems, die dafür angezapft werden; hier also QuickLook.
Mit dem Sende- oder Empfangsprozess oder dessen Bedingungen und Limitationen hat das nichts zu tun.

 

[oneOeight]

Ähnlich der ominösen Darstellung von Anhängen als Vorschau innerhalb der E-Mail, die man nur durch den Eingriff übers Terminal unterdrücken kann, verstehe ich die Logik hinter diesen Menübefehlen einfach nicht.

Streng genommen ist das einfach Teil des MIME Standards (Inline Image, Inline Attachment).
Der wird aber unterschiedlich unterstützt von Email Clients.
Ähnlich ist das bei HTML Emails.
Meistens gilt da "Standards? Wir halten uns nicht an Standards. Wir SIND der Standard!".

 

[Maximax]

Apple-Mail-seitig einstellen:

Bearbeiten > Anhänge… >
»Anhänge immer ans Ende der Email«
»Anhänge immer Windows-kompatibel senden«

Danach das Verhalten prüfen und darüber berichten.

Gibt es beim betroffenen Empfänger anstelle des Email-Inhalts ggf. merkwürdige Anhänge als *.dat?

hallo,
super Beitrag hier auch meinen herzlichen Dank
- ich hatte dasselbe Problem - Mein Windows Empfänger bekam grundsätzlich meinen Text in eine separate .htm Datei gepackt.
wenn ich jetzt den Anhang am Ende positioniere ist die .htm Datei immer noch dabei - jedoch leer.

 

[KOJOTE]

Da gibt es einige Diskrepanzen zwischen den unterschiedlichen Systemen:
Fotos in Apple-Mail kommen bei Windows-Empfängern meiner Erfahrung nach eigebettet an und können wohl nicht einzeln geöffnet werden. Ich behelfe mir daher indem ich meine Fotos komprimiert versende.
Oder Schriftarten, die ggf. beim Empfänger nicht vorhanden sind - selbst die von mir verwendetet Helvetica wird nicht immer fehlerfrei beim Empfänger angezeigt.
Wenn es zu den genannten Beispielen Vorschläge zur Abhilfe gibt, immer gerne.

 

[fa66]

Oder Schriftarten, die ggf. beim Empfänger nicht vorhanden sind - selbst die von mir verwendetet Helvetica wird nicht immer fehlerfrei beim Empfänger angezeigt.

Nunja.
Während Apple schon lange Times New Roman, Arial und weitere für macOS in Lizenz genommen hat, gilt das auf der anderen Seite für Helvetia und Times nicht. Und so sieht eine Ersatz-Arial unter Windows eben der Helvetica nur sehr ähnlich, aber nicht gleich, was für einen abweichenden Zeilenfall reicht.

Allerdings und immer wieder: Der Datendienst Email ist für Layout nicht gemacht. Und ob HTML am Ziel nur hinreichend, nicht aber strikt interpretiert wird, kann der Sender oft nichtmal ahnen – wie ersie auch nicht zwingend wissen kann, ob sein eigenes Emailschreibprogramm mit HTML nicht bereits schlecht, hinreichend oder strikt umgeht .

 

[KOJOTE]

Ich hatte schon Fälle, da wurden meine (in reinem Text) versendeten E-Mails beim Empfänger vollständig in kryptischen Zeichen dargestellt. Aktuell werden bei einem Kunden enthaltene Umlaute im Text der E-Mails mit "?" ersetzt. Gerade im beruflichen Alltag ist sowas natürlich sehr ärgerlich.

Ich ging jetzt davon aus, dass zumindest die Helvetica eine entsprechende "Übersetzung" erfährt, die auch leserlich ist.

 

[fa66]

da wurden meine (in reinem Text) versendeten E-Mails beim Empfänger vollständig in kryptischen Zeichen dargestellt. Aktuell werden bei einem Kunden enthaltene Umlaute im Text der E-Mails mit "?" ersetzt.

Da ist im Regelfall einfach nur die Angabe über die Textkodierung falsch, sie fehlt oder sie wird nicht interpretiert. Mit der Schriftart hat dàs heutzutage nichts zu tun, die würde – in Text-Emails sowieso – durch die vom Empfänger gewählte Anzeigeschrift ersetzt.

Also:
Entweder fehlt in deiner Email im Quellcode die Angabe über die im Emailtext zu verwendete Codepage – dann muss das Zielprogramm raten – und rät halt falsch – oder verwendet eine für diesen Zustand gewählte Standardcodepage —

Oder das Emailprogramm des Empfängers ist falsch eingestellt und ignoriert die mitgesendete Angabe über die Codepage. Da kann dann der Sender garnichts machen.

Der Empfänger kann dann noch versuchen, die Codepage manuell auszuwählen – wenn das Programm eine Funktion dafür hat.
In Outlook2011:
___
Und der Sender mag einen Standard für eigene Emails vorgeben:
–––

In Mail.app scheint eine manuelle Auswahl dafür zu fehlen; vermutlich wird die Systemeinstellung verwendet.

 

[oneOeight]

In Emails nutzt man am Besten nur 7 bit ASCII,
alles andere führt zu Problemen.

 

[fa66]

+++ och. weiszt du, das hat beim fernschreiber auch mit fuenf bit geklappt. und morse lehrt uns, dass es auch mit drei bit geht. aus, kurz an, lang an. +++
lf lf
+++ obwohl, zwei bit. lang an ist ja nur zweimal kurz an ohne aus dazwischen. +++

 

[xentric]

Du hast da außerdem n paar Typos in archiviert