Apfelinsel
Mac-Software => Thema gestartet von: fränk am April 28, 2008, 09:26:53
-
Ich habe nun schon mehrmals von meinen E-Mail Empfängern gehört, daß die Anhänge aus meinen Mails zwar sichtbar, aber nicht einzeln speicherbar sind.
Wenn ich ein Foto oder ein PDF an eine E-Mail anhänge, dann wird dieser Anhang meistens gleich als Bild in der Mail, für mich, beim Schreiben sichtbar. Nicht immer, manchmal ist auch nur der Dateiname sichtbar. Wann was sichtbar ist, kann ich nicht sagen, ich kann keine Regelmässigkeit feststellen.
Nun bitten mich E-Mail Empfänger des Öfteren die Anhänge (für mich waren es schon immer Anhänge) als "Anhänge" zu senden.
Bin ich und Mail.app (3.2; aktuell) das Problem oder die Empfänger und (wahrscheinlich) Outlook?
-
Mail > Bearbeiten > Anhänge:
- Windows kompatibel senden
- immer am Ende einfügen
angehakt?
-
- Windows kompatibel senden
Angehakt.
Nein, nicht angehakt.
Dann war es das wohl.
Danke. ;D
Warum ist das in der Menüleiste versteckt und nicht in den Einstellungen von Mail sichtbar?
Das sind die Dinger die mich verwirren. ;)
-
Bin ich und Mail.app (3.2; aktuell) das Problem oder die Empfänger und (wahrscheinlich) Outlook?
Vermutlich beides in Kombination. ;)
Bei Mail.app weiss man leider wirklich nie so genau, was es eigentlich tut und kann das demnach auch schlecht beeinflussen. Folglich kann man auch schwerlich Dinge vermeiden, mit denen Outlook (peinlicherweise) nicht umgehen kann.
Erfahrung mit Mail.app hab ich leider kaum. Aber ich vermute, dass es im Fall der "im Mail direkt sichtbaren Bilder" HMTL-Mails verschickt und die mitgeschickten Bilder darin dann auch referenziert. Outlook stellt diese Bilder (durchaus korrekt) inline dar. Und vermutlich würden sie sich auch so auch in Outlook einzeln abspeichern lassen (ich würde mal vermuten mit Rechtsklick und Kontextmenu), der Benutzer weiss nur nicht wie.
Bei Nur-Text-Mails müssten die Bilder eigentlich immer als Anhang dargestellt werden (ausser der Empfänger hat in seinem Mail Client auch eine inline Darstellung für solche Fälle gewählt.)
Sind aber alles nur Vermutungen. Ohne konkrete Beispiele kann man nichts Konkretes sagen. ;)
-
Um Bilder und ähnliche Multimedia-Inhalte zu versenden, gibt es grundsätzlich zwei verschiedene Präsentationsmöglichkeiten, die im Mail-Standard RFC 2183 vorgesehen sind: Das Bild kann entweder "direkt im Text" eingefügt werden, oder man kann es als Dateianhang versenden. Das hat nichts mit HTML-Mails zu tun (die sollte man ja generell vermeiden).
Wie jedes Bild dargestellt werden soll, wird im Rohtext der E-Mail entweder durch die Angabe "content-disposition: inline", bzw. "content-disposition: attachment" vermerkt. Es ist bekannt, dass es einige minderwertige Mail-Programme gibt, die beim Empfang diese Angaben nicht richtig auswerten, oder dass die E-Mail sogar verstümmelt wird, wenn sie durch einen fehlerhaften Viren-Filter oder ähnliches läuft, der den erwähnten Standard nicht korrekt unterstützt.
Warum ist das in der Menüleiste versteckt und nicht in den Einstellungen von Mail sichtbar?
Weil es da nicht hingehört. Man will ja seine E-Mail nicht immer mit Krückenlösungen verschicken, sondern nur dann, wenn man weiß, dass der Empfänger Schrottprogramme einsetzt, die sich nicht an 9 Jahre alte Normen halten.
-
Es ist bekannt, dass es einige minderwertige Mail-Programme gibt...
...
...sondern nur dann, wenn man weiß, dass der Empfänger Schrottprogramme einsetzt, die sich nicht an 9 Jahre alte Normen halten.
;D ;D ;D
Soll ich raten, welche Programme das sind?
-
Das hat nichts mit HTML-Mails zu tun (die sollte man ja generell vermeiden).
OK, danke für die Korrektur. (Das Vermeiden ist mit Mail.app ja allerdings gar nicht so einfach. :))
(Eine Content-disposition als Attachment würde ich nun allerdings keinesfalls als Krückenlösung bezeichnen.)
-
OK, danke für die Korrektur. (Das Vermeiden ist mit Mail.app ja allerdings gar nicht so einfach. :))
Warum nicht? Ich habe in den Einstellungen unter "Verfassen" als Format "Reiner Text" eingestellt.
-
OK, danke für die Korrektur. (Das Vermeiden ist mit Mail.app ja allerdings gar nicht so einfach. :))
Warum nicht? Ich habe in den Einstellungen unter "Verfassen" als Format "Reiner Text" eingestellt.
OK, nicht einfach ist vielleicht falsch. Nicht offensichtlich wäre besser gewesen. Es ist (oder war es zumindest, als ich Mail.app das letzte Mal geöffnet hatte) für den Normalbenutzer nicht erkennbar, dass wenn die Einstellung nicht auf "Reiner Text" steht, der Versand dann eben als HTML erfolgt.
-
Ich habe auch "reinen Text" vorgewählt. Trotzdem sind nach dem Verfassen manche E-mails, ich merke das vor allem bei Entwürfen, formatiert. ??? Ich kann leider keine Anhaltspunkte geben, wann oder warum das passiert.
-
Vielleicht beim Antworten?
-
Ich habe noch zusätzlich in den Einstellungen unter "Verfassen" bei "Antworten" das Häkchen bei "Dasselbe Format verwenden wie in der Original-E-Mail" weggemacht, sonst versendet man natürlich auf HTML-Mails auch HTML-Mails als Antwort.
Bei mir scheint es mit dem "reinen Text" zu funktionieren. Ich wähle allerdings auch keine Formatierungen beim Schreiben aus.
Es ist (oder war es zumindest, als ich Mail.app das letzte Mal geöffnet hatte) für den Normalbenutzer nicht erkennbar, dass wenn die Einstellung nicht auf "Reiner Text" steht, der Versand dann eben als HTML erfolgt.
Das steht tatsächlich nirgendwo. Vergiss aber nicht, dass der "Normalbenutzer" leider HTML-Mails verschicken will, weil er leider gerne herumformatiert. Ich finde das auch schlimm, aber es ist leider so. Wenn es andersherum wäre (Standard ist reiner Text und man muss erst Formatierungen in den Einstellungen aktivieren), was glaubst Du wie viele Beschwerden es gäbe, dass Mail noch nicht einmal Formatierungen erlaubt, weil die Leute das nicht finden. Ich fürchte, da wurde sich der Mehrheit gebeugt. Und wer weiß, warum er reinen Text verschicken will, der findet die Option auch leicht.
Schlimmer finde ich diese Vorlagen in Mail...
-
Bin bezüglich der Frage gerade ein bisschen am Rumspielen mit Mail.app. Und ich muss einmal mehr den Kopf schütteln über dieses Programm: Hat man ein Bild in ein Mail eingefügt, kann man ja im Kontextmenu des Bildes wählen zwischen "View as Icon" und "View in Place" ("als Symbol" und "In der E-Mail darstellen"). Verschickt wird in beiden Fällen (ausser man hat den erwähnten Menupunkt angehakt) mit Content-Disposition: inline. Sehr intuitiv, wirklich. ::)
-
Hat man ein Bild in ein Mail eingefügt, kann man ja im Kontextmenu des Bildes wählen zwischen "View as Icon" und "View in Place" ("als Symbol" und "In der E-Mail darstellen"). Verschickt wird in beiden Fällen (ausser man hat den erwähnten Menupunkt angehakt) mit Content-Disposition: inline. Sehr intuitiv, wirklich. ::)
Ich kann da Deine Kritik nicht nachvollziehen. Wenn man ein Bild in eine Mail einfügt, dann geht es ja gar nicht anders als inline. Nur, wenn man das Bild ganz ans Ende legt, gäbe es eine Wahlmöglichkeit zwischen inline und attachment.
Mail versendet aber immer inline, auch bei der Option "immer am Ende" aktiviert ist. In dem Fall liegen die Anhänge halt nur immer am Ende und man kann gar nicht in der Mitte einfügen. Das deckt sich mit meinen Erfahrungen, dass Outlook zwar mit den Anhängen klar kommt, aber alles, was nach dem "Anhang" kommt, verschluckt.
Das Kontextmenü hat mit inline oder attachment nix zu tun, da geht es ausschließlich um die Darstellung am eigenen Rechner.
-
Bei mir scheint es mit dem "reinen Text" zu funktionieren. Ich wähle allerdings auch keine Formatierungen beim Schreiben aus.
Kann ich genauso bestätigen. Ich versende auch immer nur "reinen Text" und das hat - zumindest bei den letzten 36.000 E-Mails :D - auch geklappt.
Mail schaltet nur dann von selbst auf formatierten Text um, wenn es das muss, also wenn der Benutzer wirklich explizit anfängt, zu formatieren. Dann kommt aber bei den neueren Versionen sogar eine Warnmeldung (siehe unten).
Das Kontextmenü hat mit inline oder attachment nix zu tun, da geht es ausschließlich um die Darstellung am eigenen Rechner.
Genau. Die Menüs, die "View / Darstellung" heißen, beeinflussen wirklich nur die Ansicht. Hat nichts mit dem Versand zu tun.
-
Ich kann da Deine Kritik nicht nachvollziehen. Wenn man ein Bild in eine Mail einfügt, dann geht es ja gar nicht anders als inline. Nur, wenn man das Bild ganz ans Ende legt, gäbe es eine Wahlmöglichkeit zwischen inline und attachment.
Mail versendet aber immer inline, auch bei der Option "immer am Ende" aktiviert ist. In dem Fall liegen die Anhänge halt nur immer am Ende und man kann gar nicht in der Mitte einfügen. Das deckt sich mit meinen Erfahrungen, dass Outlook zwar mit den Anhängen klar kommt, aber alles, was nach dem "Anhang" kommt, verschluckt.
Das Kontextmenü hat mit inline oder attachment nix zu tun, da geht es ausschließlich um die Darstellung am eigenen Rechner.
Stimmt, Mail.app versendet tatsächlich selbst bei angehaktem erwähntem Menupunkt inline. Dass sich mit Mail.app folglich gar keine Mails mit Content-Disposition: attachment versenden lassen, ist ja noch schwächer.
Und nein, ausser ich hätte RFC 2183 komplett falsch verstanden, dann ist es eben nicht so, dass ein Attachment immer am Schluss liegen muss. Der Unterschied zwischen inline und attachment müsste eben gerade der sein, dass bei inline die betreffenden Daten ohne Zutun des Benutzers direkt dargestellt werden, während die Darstellung des Inhalts eines Attachment eine Benutzeraktion erfordern soll. Erstelle ich ein Mail und wähle für ein Bild die Icon-Darstellung (also eine Darstellung, bei welcher erst eine Benutzeraktion, nämlich ein Doppelklick darauf, notwendig ist, um den Inhalt zu sehen), dann würde ich erwarten, dass das auch so, also mit Content-Disposition: attachment versandt wird.
-
Das Kontextmenü hat mit inline oder attachment nix zu tun, da geht es ausschließlich um die Darstellung am eigenen Rechner.
Genau. Die Menüs, die "View / Darstellung" heißen, beeinflussen wirklich nur die Ansicht. Hat nichts mit dem Versand zu tun.
Und das nennt sich dann intuitiv, wenn ich beim Erstellen eines Mails eine Darstellung wählen kann, die aber auf das tatsächliche Aussehen des versandten Mails keinen Einfluss hat? Wer bitte erwartet das so?
-
Stimmt, Mail.app versendet tatsächlich selbst bei angehaktem erwähntem Menupunkt inline. Dass sich mit Mail.app folglich gar keine Mails mit Content-Disposition: attachment versenden lassen, ist ja noch schwächer.
Nicht unbedingt. Mail kann beide Methoden korrekt darstellen und versendet grundsätzlich in einer der beiden erlaubten Methoden. Also eigentlich kein Problem. Im Ernst: Wie viele Leute glaubst Du kennen den Unterschied zwischen inline und attachment und wollen dann auch noch unbedingt eines dieser beiden Methoden haben? Ist doch im Prinzip wurscht, weil beides korrekt ist und funktioniert.
Und nein, ausser ich hätte RFC 2183 komplett falsch verstanden, dann ist es eben nicht so, dass ein Attachment immer am Schluss liegen muss.
Aber genau darum ging es im Anfangsposting. Outlook kommt nicht damit klar, wenn nach Anhängen noch weiterer Inhalt kommt. Dieses Problem kann man vermeiden, wenn man Anhänge selber ans Ende setzt (wie ich bei bestimmten Empfängern) oder die Anhänge automatisch ans Ende gesetzt werden (mit der Option).
Und das nennt sich dann intuitiv, wenn ich beim Erstellen eines Mails eine Darstellung wählen kann, die aber auf das tatsächliche Aussehen des versandten Mails keinen Einfluss hat? Wer bitte erwartet das so?
Das Menü "View" oder "Darstellung" bezieht sich immer und in allen Programmen auf die Anzeige am eigenen Rechner. Das erwarte ich schon so, wenn es "view as..." heisst.
Auf die Darstellung einer Mail hast Du ja eh keinen Einfluss. Das macht das Programm und die Einstellungen des Empfängers. Genau darum versenden wir doch als reinen Text. Wir wollen dem anderen kein Format aufzwängen.
-
Und das nennt sich dann intuitiv, wenn ich beim Erstellen eines Mails eine Darstellung wählen kann, die aber auf das tatsächliche Aussehen des versandten Mails keinen Einfluss hat? Wer bitte erwartet das so?
Diese Frage stelle ich mir schon lange:
Was von dem Aussehen einer Mail liegt an mir oder meinen Einstellungen und was ist vom Versender so gewollt?
Und noch wichtiger:
Wie kommen meine Mails, vor allem Geschäftsmails beim Empfänger an?
Wie oft denkt der Empfänger: "Hat der fränk sie noch alle!"
Und irgendwie hilft es auch nicht wirklich weiter, daß der Empfänger und sein E-Mail Programm verantwortlich für den Mist ist.
Ich sehe mich als Lieferant und Nutzer einer Insellösung hier schon in der Verantwortung.
Tröstlich zu sehen, daß andere ähnliche Probleme damit haben.
-
Aber genau darum ging es im Anfangsposting. Outlook kommt nicht damit klar, wenn nach Anhängen noch weiterer Inhalt kommt. Dieses Problem kann man vermeiden, wenn man Anhänge selber ans Ende setzt (wie ich bei bestimmten Empfängern) oder die Anhänge automatisch ans Ende gesetzt werden (mit der Option).
Nö, Mail.app verschickt ja anscheinend nie als Attachment. Also kann es fränk auch gar nicht als Attachment gesendet haben. Und Outlook folglich auch kein Problem damit haben, dass nach einem Attachment noch etwas kam. Es ist ganz einfach immer inline und folglich direkt darzustellen, ob nun am Schluss oder nicht.
Das Menü "View" oder "Darstellung" bezieht sich immer und in allen Programmen auf die Anzeige am eigenen Rechner. Das erwarte ich schon so, wenn es "view as..." heisst.
Auf die Darstellung einer Mail hast Du ja eh keinen Einfluss. Das macht das Programm und die Einstellungen des Empfängers. Genau darum versenden wir doch als reinen Text. Wir wollen dem anderen kein Format aufzwängen.
Doch, auf die Darstellung (auch beim Empfänger) hätte man eben gerade mit Content-Diposition durchaus einen Einfluss. Oder sollte man haben. Dass eine bei mir gewählte Darstellungsart dann nicht auch so im tatsächlich versandten Mail definiert wird, wenn diese Möglichkeit doch bestünde, ist doch wirklich weder logisch noch intuitiv.
-
Was von dem Aussehen einer Mail liegt an mir oder meinen Einstellungen und was ist vom Versender so gewollt?
Yep, genau das ist bei fast keinem anderen Mail Client so intransparent, wie bei Mail.app.
-
Diese Frage stelle ich mir schon lange:
Was von dem Aussehen einer Mail liegt an mir oder meinen Einstellungen und was ist vom Versender so gewollt?
Da gibt es zwei verschiedene "Philosophien":
- mbs, warlord, ich und sicherlich noch mehr versenden absichtlich reinen Text. Damit hat man keinerlei(!) Einfluss auf das Aussehen beim Empfänger. So wird eine Mail beim Empfänger so angezeigt, wie der Empfänger gerne Mails liest und ich empfinde es als unhöflich und für den Empfänger auch anstrengender, wenn ich ihm meine Schriftart, -größe, -farbe etc. aufzwinge. Bei reinem Text wird es so dargestellt, wie es der Empfänger auf dem jeweiligen Gerät (Handy, Computer, iPhone etc.) für optimal hält.
- Andere Leute versenden "formatierten Text) als RTF oder HTML. Das finde ich unhöflich und schlechter lesbar. Hierdurch kann man die Anzeige beim Empfänger in gewissem Rahmen erzwingen/beeinflussen.
Und irgendwie hilft es auch nicht wirklich weiter, daß der Empfänger und sein E-Mail Programm verantwortlich für den Mist ist.
Ich sehe mich als Lieferant und Nutzer einer Insellösung hier schon in der Verantwortung.
Outlook kann keine Anhänge innerhalb einer Mail darstellen. Mail (Insellösung) bietet hier die Lösung an. Einzig: Man muss das erst einmal wissen. Ich möchte aber nicht hören, was los ist, wenn das standardmässig aktiviert wäre: "Äh, Mail kann noch nicht einmal Bilder in die Mail einfügen, die hängen immer unten..."
Was von dem Aussehen einer Mail liegt an mir oder meinen Einstellungen und was ist vom Versender so gewollt?
Yep, genau das ist bei fast keinem anderen Mail Client so intransparent, wie bei Mail.app.
Bitte?
Ist es nicht überall so?:
reiner Text = Empfänger entscheidet über Aussehen
RTF/HTML = Sender entscheidet über Aussehen, Empfänger kann evtl. noch automatisch den Quelltext anzeigen
-
Aber genau darum ging es im Anfangsposting. Outlook kommt nicht damit klar, wenn nach Anhängen noch weiterer Inhalt kommt. Dieses Problem kann man vermeiden, wenn man Anhänge selber ans Ende setzt (wie ich bei bestimmten Empfängern) oder die Anhänge automatisch ans Ende gesetzt werden (mit der Option).
Nö, Mail.app verschickt ja anscheinend nie als Attachment. Also kann es fränk auch gar nicht als Attachment gesendet haben. Und Outlook folglich auch kein Problem damit haben, dass nach einem Attachment noch etwas kam
Habe ich geschrieben, dass er es als attachment gesendet hätte? Ich kenne das Problem von Outlook, wenn der Anhang nicht am Ende ist. Genau dagegen hilft die Option. Und seitdem ich Anhänge (inline) am Ende platziere, klappt es bei meinen Outlook-Empfängern.
Doch, auf die Darstellung (auch beim Empfänger) hätte man eben gerade mit Content-Diposition durchaus einen Einfluss. Oder sollte man haben. Dass eine bei mir gewählte Darstellungsart dann nicht auch so im tatsächlich versandten Mail definiert wird, wenn diese Möglichkeit doch bestünde, ist doch wirklich weder logisch noch intuitiv.
Soso. Wir versenden doch beide aus gutem Grunde als reinem Text. Wenn hier bei mir die Mail in Lucida, 16pt dargestellt wird, ist es dann auch weder logisch noch intuitiv, dass das Aussehen beim Empfänger völlig anders ist? Genauso wie ich beim Schreiben einer Mail auswählen kann, wie die Schrift hier bei mir ist, kann ich auch aussuchen wie die eingebetteten Bilder hier bei mir angezeigt werden.
-
Bitte?
Ist es nicht überall so?:
reiner Text = Empfänger entscheidet über Aussehen
RTF/HTML = Sender entscheidet über Aussehen, Empfänger kann evtl. noch automatisch den Quelltext anzeigen
Bei welchem anderen Mail-Client merkst Du gar nicht, dass Du überhaupt HTML-Mails versendest? Und eben, welcher andere Mail-Client versendet alles inline, obwohl er Dir bei der Darstellung am eigenen Computer eine Darstellung als Attachment vorgaukelt?
Was Mail.app bei welchen Einstellungen genau macht, ist einfach zu häufig nicht oder nur schlecht erkennbar und muss erst mit aufwendigen Selbstversuchen herausgefunden werden.
-
Bei welchem anderen Mail-Client merkst Du gar nicht, dass Du überhaupt HTML-Mails versendest? Und eben, welcher andere Mail-Client versendet alles inline, obwohl er Dir bei der Darstellung am eigenen Computer eine Darstellung als Attachment vorgaukelt?
Was Mail.app bei welchen Einstellungen genau macht, ist einfach zu häufig nicht oder nur schlecht erkennbar und muss erst mit aufwendigen Selbstversuchen herausgefunden werden.
fränk hat in seinem Posting, auf dass Du Dich bezogst, geschrieben, dass ihm nicht klar ist, was an der Darstellung einer Mail an ihm oder am Versender liegt, d.h. es kann nur um die Darstellung einer empfangenen Mail bei ihm liegen. Obiges hat damit nix zu tun.
Aber auch so:
- HTML: In allen Programmen, die ich kenne, muss ich selber in den Voreinstellungen oder konkret bei einer Mail das Format vorgeben. Also nicht anders als bei Apple Mail. Zusätzlich kommt ja noch eine Warnung, wenn man aus Versehen eine Umwandlung durchführt. Sorry, aber ich sehe da echt keinen grossen Unterschied und auch die Voreinstellungen hierzu sind klar.
-inline/attachment: Du weisst ganz genau, dass das Aussehen Deiner Mail (reiner Text) nichts mit der Anzeige beim Empfänger zu tun hat. Ausgerechnet bei den Bildern soll es dann anders sein? Es wäre wenig intuitiv, wenn sich ein Menüpunkt "view as..." plötzlich nicht mehr auf die eigenen Darstellung beziehen würde, wie es das Menü "View" überall macht.
-
Soso. Wir versenden doch beide aus gutem Grunde als reinem Text. Wenn hier bei mir die Mail in Lucida, 16pt dargestellt wird, ist es dann auch weder logisch noch intuitiv, dass das Aussehen beim Empfänger völlig anders ist?
Sicher ist das logisch und intuitiv. Da ich ja als Plaintext sende, weiss ich, dass da absolut keine Formatierungen mitgehen. Und ich kann bei der Darstellung an meinem Computer ja auch gar keine Formatierungen vornehmen, ausser generell die Schrift zu wählen, in welcher mir Plaintext dargestellt wird. Die Möglichkeit, für die Darstellung an meinem Computer Formatierungen vornehmen zu können, die dann aber nicht gesendet werden, wäre ja wirklich idiotisch.
Genauso wie ich beim Schreiben einer Mail auswählen kann, wie die Schrift hier bei mir ist, kann ich auch aussuchen wie die eingebetteten Bilder hier bei mir angezeigt werden.
Die Content-Disposition lässt sich ja aber eben, wie mbs richtig korrigiert hat, bei allen Mails definieren. Auch bei Plaintext. Es ist nicht eine Formatierung. Und die "neutrale" dem Plaintext entsprechende Darstellungsart wäre dann wenn schon attachment und nicht inline.
-
Was Mail.app bei welchen Einstellungen genau macht, ist einfach zu häufig nicht oder nur schlecht erkennbar und muss erst mit aufwendigen Selbstversuchen herausgefunden werden.
Das ist aber doch Apple Philosophie. Es soll funktionieren ohne daß der Anwender mit der zugrunde liegenden Technik befaßt wird.
Man kann sich aber in der Symbolleiste einer zu sendenden E-mail das Format anzeigen lassen:
-
In allen Programmen, die ich kenne, muss ich selber in den Voreinstellungen oder konkret bei einer Mail das Format vorgeben. Also nicht anders als bei Apple Mail.
Ja, aber bei so ziemlich allen anderen Mail Clients kann ich dann sehen, dass ich jetzt HTML gewählt habe. Nicht so bei Mail.app.
-inline/attachment: Du weisst ganz genau, dass das Aussehen Deiner Mail (reiner Text) nichts mit der Anzeige beim Empfänger zu tun hat.
Nicht einverstanden. (Siehe auch meinen vorherigen Beitrag.) RFC 2183 sieht eben durchaus vor, dass der Absender Empfehlungen abgibt, ob etwas inline dargestellt werden soll oder nicht. Und der neutrale Zustand wäre eben gerade nicht inline. Inline ist ja eigentlich schon eine nicht defaultmässige Vorgabe.
Ausgerechnet bei den Bildern soll es dann anders sein? Es wäre wenig intuitiv, wenn sich ein Menüpunkt "view as..." plötzlich nicht mehr auf die eigenen Darstellung beziehen würde, wie es das Menü "View" überall macht.
Wie sinnvoll ist es, an dem Aussehen eines Mails, das ja nicht für mich selbst bestimmt und in wenigen Sekunden auch gar nicht mehr hier bei mir sein wird, etwas zu verändern, das dann keinen Einfluss auf das Aussehen beim Empfänger hat? Das wäre wie die Möglichkeit, an einem Plaintext-Mail Formatierungen vorzunehmen, rein aus Spass an der Freude.
Zudem ist gerade bei der deutschen Lokalisierung das "view as..." überhaupt nicht mehr vorhanden.
-
Das ist aber doch Apple Philosophie. Es soll funktionieren ohne daß der Anwender mit der zugrunde liegenden Technik befaßt wird.
Dass er sich nicht notwendigerweise damit befassen muss, wäre ja auch durchaus löblich und wünschenswert. Das schliesst aber einerseits nicht aus, dass sich trotzdem erkennen lässt, was genau vor sich geht, wenn das gewünscht oder notwendig ist. Und es geht andererseits bei Mails dann halt in die Hose, wenn man Defaultwerte wählt, die bekanntermassen bei weit verbreiteten anderen Mail Clients Probleme verursachen. Wenn man den Benutzern jegliche Mühen bezüglich Einstellungen abnehmen will, dann müsste man die Defaultwerte so halten, dass praktisch kein anderer Mail Client Probleme damit hat. Und ich denke, das liesse sich durchs besser machen, als das Mail.app tut, ohne dass man dabei Standards verletzen müsste.
-
Soso. Wir versenden doch beide aus gutem Grunde als reinem Text. Wenn hier bei mir die Mail in Lucida, 16pt dargestellt wird, ist es dann auch weder logisch noch intuitiv, dass das Aussehen beim Empfänger völlig anders ist?
Sicher ist das logisch und intuitiv. Da ich ja als Plaintext sende, weiss ich, dass da absolut keine Formatierungen mitgehen. Und ich kann bei der Darstellung an meinem Computer ja auch gar keine Formatierungen vornehmen, ausser generell die Schrift zu wählen, in welcher mir Plaintext dargestellt wird. Die Möglichkeit, für die Darstellung an meinem Computer Formatierungen vornehmen zu können, die dann aber nicht gesendet werden, wäre ja wirklich idiotisch.
Ich kann hier an meinem Rechner auswählen, wie plain text angezeigt wird und das sieht beim Empfänger dann anders aus. Das ist für Dich intuitiv.
Ich kann hier an meinem Rechner auswählen, wie ein Anhang angezeigt wird und das sieht beim Empfänger anders aus. Das ist für Dich nicht intuitiv.
???
Die Content-Disposition lässt sich ja aber eben, wie mbs richtig korrigiert hat, bei allen Mails definieren.
Sie lässt sich bei Apple Mail gar nicht definieren. Du hast nur abweichend von der Funktion "View", die immer nur die Darstellung bei einem selber beeinflusst, vermutet, dass Content-Disposition gemeint ist.
Aber eigentlich willst Du die fremde Darstellung ja gar nicht beeinflussen, warum willst Du es gerade hier dann über ein für diesen Zweck falsch beschriftetes Menü machen? Das wäre doch unintuitiv: Beschriftung des Menüs weicht vom üblichen Zweck ab und macht etwas völlig anderes, zudem wäre es dann noch schlecht und intransparent beschrieben. Was Dich dann stören würde. :)
Ja, aber bei so ziemlich allen anderen Mail Clients kann ich dann sehen, dass ich jetzt HTML gewählt habe. Nicht so bei Mail.app.
Ich verstehe nicht ganz, was Du willst. Wenn man in den Voreinstellungen "formatiert" anwählt oder in der Symbolleiste oder Formatierungen macht und der Warnung zustimmt, dann soll noch irgendwo fett "HTML" stehen? Ist das nicht klar, dass man dann keinen reinen Text mehr hat?
RFC 2183 sieht eben durchaus vor, dass der Absender Empfehlungen abgibt, ob etwas inline dargestellt werden soll oder nicht.
Aha, also nur eine Empfehlung, an die sich der Empfänger dann evtl. auch nicht hält, wie bei meinen Schriften auch. Ob inline oder attachment: Es ist doch im Prinzip wurscht. Beides ist erlaubt und beides funktioniert. Du störst Dich nur daran, dass Mail nur einen Teil aller Möglichkeiten implementiert hat, richtig? Wobei das Fehlen dieser Möglichkeit attachment wohl nahezu niemandem auffällt, oder?
Wie sinnvoll ist es, an dem Aussehen eines Mails, das ja nicht für mich selbst bestimmt und in wenigen Sekunden auch gar nicht mehr hier bei mir sein wird, etwas zu verändern, das dann keinen Einfluss auf das Aussehen beim Empfänger hat?
Ich vermute mal, dass das einfach nur deshalb da auftaucht, weil es auch bei empfangenen Mails so gemacht werden kann und neue Mails und schreibende Mails durch ähnliche Routinen behandelt werden.
Aber auch so finde ich diese Option ganz interessant, danke, ich kannte die vorher nämlich noch nicht. Wenn ich in eine Mail nämlich mehrere Bilder einfüge, sind die oft so groß, dass die Mail durch das dann angezeigte Bild gescrollt werden muss. Da wäre die Icon-Darstellung beim Schreiben manchmal interessant. :P
-
Ich kann hier an meinem Rechner auswählen, wie plain text angezeigt wird und das sieht beim Empfänger dann anders aus. Das ist für Dich intuitiv.
Ich kann hier an meinem Rechner auswählen, wie ein Anhang angezeigt wird und das sieht beim Empfänger anders aus. Das ist für Dich nicht intuitiv.
???
So ist es. Bei ersterem handelt es sich um eine Einstellung, die ich einfach nur global machen kann. Ich sage einfach meinem Mail Client, in welcher Schrift er Plaintext (also Text ohne Attribute wie eine vordefinierte Schrift) anzeigen soll. Dass ein anderer Benutzer solchem Text eine andere Schrift zuweisen kann und das Schriftbild folglich anders aussieht liegt in der Natur des Sache. Das ist also durchaus logisch und intuitiv.
Beim zweiten habe ich die Möglichkeit, die Darstellung eines spezifischen Inhalts zu beeinflussen. Und genau für diese Einstellung gibt es im Kopf jedes von Mail.app versandten E-Mails auch einen entsprechenden "Schalter" der mitgeschickt wird. Nur steht dieser "Schalter" immer auf dem selben "Wert", egal welchen "Wert" ich ihm bei mir gegeben habe. Das empfinde ich wirklich nicht als logisch und intuitiv.
Sie lässt sich bei Apple Mail gar nicht definieren. Du hast nur abweichend von der Funktion "View", die immer nur die Darstellung bei einem selber beeinflusst, vermutet, dass Content-Disposition gemeint ist.
Natürlich habe ich das nur vermutet. Habe ja nicht anderes behauptet. Was ich sage ist ja gerade, dass diese Vermutung doch wohl weit näher liegt, als davon auszugehen, dass ich nur aus Spass an der Freude an der Darstellung vor dem Abschicken herum hampeln kann, ohne dass das auch nur den geringsten Einfluss auf das verschickte Mail hätte.
Aber eigentlich willst Du die fremde Darstellung ja gar nicht beeinflussen, warum willst Du es gerade hier dann über ein für diesen Zweck falsch beschriftetes Menü machen?
Die Angabe ist nunmal in jedem Mail drin. Ob Du es willst oder nicht. Und wenn ich es bei mir beim Erstellen beeinflussen kann, dann würde ich einfach erwarten, dass diese so vorgenommene Einstellung dann auch tatsächlich in die genau dafür in jedem Mail enthaltene Einstellung einfliesst.
Und nochmal: Mail schickt diese "Beeinflussung" ja automatisch in jedem Mail mit. Ich kann also gar nicht wählen, ob ich beeinflussen will oder nicht. Es wird einfach getan. Und zwar wird automatisch die intrusivere der beiden Möglichkeiten gewählt.
Ich verstehe nicht ganz, was Du willst. Wenn man in den Voreinstellungen "formatiert" anwählt oder in der Symbolleiste oder Formatierungen macht und der Warnung zustimmt, dann soll noch irgendwo fett "HTML" stehen?
So würde man das erwarten, ja. Oder es sollte in der Einstellung zumindest als HTML bezeichnet werden, und nicht als Rich Text.
Aha, also nur eine Empfehlung, an die sich der Empfänger dann evtl. auch nicht hält, wie bei meinen Schriften auch.
Du kannst in einem Plaintext Mail meines Wissens keine Empfehlungen zu Schriften angeben. Und natürlich kann jede in einem Mail enthaltene Einstellung oder Empfehlung auf Empfängerseite missachtet bzw. übersteuert werden. Aber in einem Plaintext-Mail gibt es kein Gefäss, das die Schrift definiert. In jedem Multipart-Mail gibt es aber ein Gefäss, das definiert, ob Inhalte inline dargestellt werden oder nicht. Wieso diese Gefäss nicht mit dem Wert befüllt werden soll, den der Absender für die Darstellung bei sich gewählt hat, sondern mit einem Wert, den der Mail Client bestimmt, leuchtet mir wirklich nicht ein.
Ob inline oder attachment: Es ist doch im Prinzip wurscht. Beides ist erlaubt und beides funktioniert. Du störst Dich nur daran, dass Mail nur einen Teil aller Möglichkeiten implementiert hat, richtig? Wobei das Fehlen dieser Möglichkeit attachment wohl nahezu niemandem auffällt, oder?
Anscheinend eben doch. Es soll ja doch den einen oder anderen Outlook-Benutzer geben. ;)
-
Beim zweiten habe ich die Möglichkeit, die Darstellung eines spezifischen Inhalts zu beeinflussen.
Also ähnlich wie beim Wechsel auf formatierte Mails, die Du ja absichtlich nicht benutzt.
Und genau für diese Einstellung gibt es im Kopf jedes von Mail.app versandten E-Mails auch einen entsprechenden "Schalter" der mitgeschickt wird. Nur steht dieser "Schalter" immer auf dem selben "Wert"
Ja, Apple Mail unterstützt nur einen Teil der Möglichkeiten, was aber eigentlich ausreicht.
egal welchen "Wert" ich ihm bei mir gegeben habe.
Nein, Du kannst diesem "Schalter" in Mail überhaupt keinen anderen "Wert" geben. Du hast an einer völlig anderen Option, was durch die Beschriftung auch klar ist, herumgedreht und vermutet, dass die Option etwas völlig anderes macht, als ihre Beschriftung aussagt.
Ich verstehe nicht ganz, was Du willst. Wenn man in den Voreinstellungen "formatiert" anwählt oder in der Symbolleiste oder Formatierungen macht und der Warnung zustimmt, dann soll noch irgendwo fett "HTML" stehen?
So würde man das erwarten, ja. Oder es sollte in der Einstellung zumindest als HTML bezeichnet werden, und nicht als Rich Text.
Steht da "Rich Text" im englischen?
Wieso diese Gefäss nicht mit dem Wert befüllt werden soll, den der Absender für die Darstellung bei sich gewählt hat, sondern mit einem Wert, den der Mail Client bestimmt, leuchtet mir wirklich nicht ein.
Würde mir auch nicht einleuchten. Allerdings hast Du diese Einstellung nicht gewählt, weil man sie in Mail gar nicht wählen kann.
Ob inline oder attachment: Es ist doch im Prinzip wurscht. Beides ist erlaubt und beides funktioniert. Du störst Dich nur daran, dass Mail nur einen Teil aller Möglichkeiten implementiert hat, richtig? Wobei das Fehlen dieser Möglichkeit attachment wohl nahezu niemandem auffällt, oder?
Anscheinend eben doch. Es soll ja doch den einen oder anderen Outlook-Benutzer geben. ;)
Nochmal: Das Problem ist nicht inline, sondern dass Outlook nicht mit damit umgehen kann, dass nach den Anhängen noch was kommt. Sonst würde ja auch die Option "Anhänge immer am Ende senden" auch nix bringen.
Ich fasse mal zusammen, weil es arg auseinanderdriftet:
Eigentliches Problem:
- Outlook kann Inhalt nach Anhängen nicht korrekt darstellen.
- Lösung: Anhang ans Ende setzen (automatisch oder per Hand).
Dein Problem:
- Es gibt neben der von Apple Mail ausschließlich verwendeten Möglichkeit inline auch noch attachment und Du hast abweichend von allen anderen Programmen unter OS X hinter einem Menü eine versteckte Funktion zur Nutzung dieser nicht vorhandenen Möglichkeit vermutet. Wenn das Menü diese Möglichkeit geboten hätte, hättest Du aber wieder gesagt, dass wäre zu intransparent, weil die Beschriftung nicht eindeutig auf inline und attachment hinweist.
- Lösung: keine. Allerdings ist im Prinzip auch nur eine nötig für die Leute, die den Unterschied kennen und(!) gleichzeitig eine der beiden Möglichkeiten zwingend haben wollen. Für alle anderen funktioniert es auch so.
-
Also ähnlich wie beim Wechsel auf formatierte Mails, die Du ja absichtlich nicht benutzt.
Überhaupt nicht ähnlich, nein. Aber nö, ich wiederhol mich da jetzt nicht nochmal...
Ja, Apple Mail unterstützt nur einen Teil der Möglichkeiten, was aber eigentlich ausreicht.
Offenbar eben nicht.
Nein, Du kannst diesem "Schalter" in Mail überhaupt keinen anderen "Wert" geben. Du hast an einer völlig anderen Option, was durch die Beschriftung auch klar ist, herumgedreht und vermutet, dass die Option etwas völlig anderes macht, als ihre Beschriftung aussagt.
Was ist an einem Wechsel zwischen angezeigtem Inhalt und nicht angezeigtem Inhalt beim Ersteller denn bitteschön völlig anders, als ein Ändern der Einstellung ob beim Empfänger der Inhalt direkt angezeigt wird oder nicht?
Steht da "Rich Text" im englischen?
Ja.
Eigentliches Problem:
- Outlook kann Inhalt nach Anhängen nicht korrekt darstellen.
- Lösung: Anhang ans Ende setzen (automatisch oder per Hand).
Na ja, das eigentliche formulierte Problem war, dass Outlook die Anhänge inline dargestellt hat, aber eine Darstellung als attachment gewünscht gewesen wäre.
Mag ja sein, dass gewisse Outlook Versionen (ev. Outlook Express?) Schwierigkeiten damit haben, wenn es nach einem Anhang noch weitergeht. Ich konnte das bei Outlook bei uns an der Arbeit allerdings nie beobachten. Und ich erhalte dort noch und nöcher Mails mit nicht inline dargestellten Anhängen mittendrin. Könnte es eventuell gerade daran liegen, dass eben Mail.app alles mit Content-Disposition: inline versendet? Muss ich mal testen, ob so ein Mail bei mir im Büro Probleme macht.
Wenn Outlook am Ende eines Mails stehende Anhänge immer als attachment anzeigt, egal was für eine Content-Disposition angegen ist, dann ist das ans Ende Stellen aber auch nicht wirklich die Lösung des Problems, sondern eher ein Workaround der wegen einer weiteren Fehlfunktion von Outlook zufälligerweise funktioniert. ;)
Also ich weiss nicht. Aber ich lese in Foren noch und nöcher von Leuten, deren mit Mail.app verschickte Mails von Windowsianern als mangelhaft bezeichnet werden. Ich weiss ja durchaus, dass das nicht wirklich an einem Fehlverhalten von Mail.app liegt und dass die Mails nicht wirklich mangelhaft sind. Aber wenn der Auftrag lautete, mit Mail.app einen Mail Client zu bauen, der einfach funktioniert und bei dem sich der Benutzer um nichts kümmern muss, dann kann ich nur sagen: mission not accomplished.
-
ich lese in Foren noch und nöcher von Leuten, deren mit Mail.app verschickte Mails von Windowsianern als mangelhaft bezeichnet werden.
So schlimm ist es nicht. Dank der beiden oben erwähnten Häkchen habe ich keine Probleme mit meinen gesendeten E-mails.
-
Nein, Du kannst diesem "Schalter" in Mail überhaupt keinen anderen "Wert" geben. Du hast an einer völlig anderen Option, was durch die Beschriftung auch klar ist, herumgedreht und vermutet, dass die Option etwas völlig anderes macht, als ihre Beschriftung aussagt.
Was ist an einem Wechsel zwischen angezeigtem Inhalt und nicht angezeigtem Inhalt beim Ersteller denn bitteschön völlig anders, als ein Ändern der Einstellung ob beim Empfänger der Inhalt direkt angezeigt wird oder nicht?
Ganz einfach.
Du hast einen Option verwendet, die klar sagt, dass sie bei Dir die Darstellung ändert. Das tut sie nämlich in allen anderen Programmen auch. Dafür ist "view as" da.
Die von Dir gewünschte Option müsste halt völlig anders lauten und auf den gewünschten Effekt hinweisen. Würde nämlich die aktuelle Option so funktionieren, wie Du vermutet hattest, wäre es halt auch unintuitiv, wenn sich Mail völlig anders als alle anderen Mac-Programme verhält und Du würdest schimpfen. :)
Steht da "Rich Text" im englischen?
Ja.
OK, das ist dann nicht so eindeutig, wobei ich RTF und HTML gleich schlimm finde. :)
Eigentliches Problem:
- Outlook kann Inhalt nach Anhängen nicht korrekt darstellen.
- Lösung: Anhang ans Ende setzen (automatisch oder per Hand).
Na ja, das eigentliche formulierte Problem war, dass Outlook die Anhänge inline dargestellt hat, aber eine Darstellung als attachment gewünscht gewesen wäre.
Sicher? Ich bin mir fast sicher, dass der Win-User den Unterschied zwischen inline und attachment nicht kennt und nur einfach mit der Mail nicht klar kam. Ich würde es sogar wagen zu behaupten, das es einen Weg geben müsste auch in Outlook inline dargestellte Bilder zu speichern und der einfach nur nicht weiß wie.
Mag ja sein, dass gewisse Outlook Versionen (ev. Outlook Express?) Schwierigkeiten damit haben, wenn es nach einem Anhang noch weitergeht.
Das sind die einzigen Schwierigkeiten, die ich mit Outlook-Empfängern habe. Seit "Windows-kompatibel senden" und Anhang ans Ende, habe ich keine Beschwerden mehr bekommen.
Wenn Outlook am Ende eines Mails stehende Anhänge immer als attachment anzeigt...
Das habe ich nicht gesagt und habe ich auch nicht sagen wollen. Ich hatte nur früher oft den Fall, dass ich nach der eingebetteten Datei noch was geschrieben hatte und mich zunächst wunderte, dass der Empfänger scheinbar diesen Text ignorierte. Bis ich feststellen musste, dass der einfach nicht mehr angezeigt wird.
Also ich weiss nicht. Aber ich lese in Foren noch und nöcher von Leuten, deren mit Mail.app verschickte Mails von Windowsianern als mangelhaft bezeichnet werden.
s.o. Seit "Windows-kompatibel versenden" und Anhänge ans Ende kann ich nicht mehr meckern und das nicht nachvollziehen.
-
Ich würde es sogar wagen zu behaupten, das es einen Weg geben müsste auch in Outlook inline dargestellte Bilder zu speichern und der einfach nur nicht weiß wie.
Da gehe ich einig. Das hab ich ja auch schon geschrieben.
Und vermutlich würden sie sich auch so auch in Outlook einzeln abspeichern lassen (ich würde mal vermuten mit Rechtsklick und Kontextmenu), der Benutzer weiss nur nicht wie.
-
Steht da "Rich Text" im englischen?
Ja.
OK, das ist dann nicht so eindeutig, wobei ich RTF und HTML gleich schlimm finde.
"Rich Text" ist ein Fachbegriff aus der E-Mail-Welt und heißt wirklich nur "formatierter Text". Das hat nichts mit RTF zu tun. Es gibt 3 verschiedene Methoden, wie ein Mail-Programm solchen formatierten Text technisch verschicken kann:
- Als "text/richtext" nach RFC 1341
- Als "text/enriched" nach RFC 1896
- Als "text/html" nach RFC 2854
Das ist dann aber Sache der Implementation, die einen "normalen" Benutzer üblicherweise nicht interessiert.
-
Muss ich mal testen, ob so ein Mail bei mir im Büro Probleme macht.
Macht es tatsächlich. Wobei ich nicht sagen kann, obs an Outlook oder am Exchange Server liegt.
Ausgangslage war ein mit Mail.app verschicktes Mail (plaintext), bestehend aus Text, dann einem Jpeg und noch einmal Text. Da mit Mail.app erstellt natürlich alles mit Content-Disposition: inline.
Angekommen ist das Mail wie folgt: Mail-Body besteht nur aus dem Text vor dem Bild. Das Bild und der Text nach dem Bild werden nicht inline, sondern als attachment dargestellt. Der Text nach dem Bild ist dazu in eine ATTziffern.txt "Datei" verpackt worden.
Jetzt bin ich aber wirklich gespannt, ob das mit Content-Disposition: attachment anders wäre. Mal sehen, ob ich das irgendwie testen kann.
-
So würde man das erwarten, ja. Oder es sollte in der Einstellung zumindest als HTML bezeichnet werden, und nicht als Rich Text.
Da ist Mail.app immerhin nicht alleine. Outlook ist sogar noch schlimmer, wie ich gemerkt habe. (Na gut, war zu erwarten.) Das bietet eine Auswahl zwischen Plaintext, Rich Text und HTML an. Es wird aber auch bei der Wahl von Rich Text mit HTML verschickt. Er scheint einfach etwas anders generiert zu werden. ::)
Kommando zurück. Da scheint nicht Outlook schuldig zu sein, sondern Exchange Server.
Eine Content-Disposition gibt Outlook übrigens nie an.
-
Die Content-disposition Angaben von Mail.app scheinen mir wirklich äusserst ungeschickt zu sein. Was zum Teufel veranstaltet es da z.B. mit einem Dateinamen wie "D60ü geist Eig.pdf"?
--Apple-Mail-23-308863879
Content-Disposition: inline;
filename*=ISO-8859-1''D60%FC%20geist%20Eig.pdf0
Content-Type: application/pdf;
x-mac-creator=C74943C8;
x-unix-mode=0644;
x-mac-type=50444620;
name="=?ISO-8859-1?Q?D60=FC_geist_Eig.pdf>?="
Content-Transfer-Encoding: base64
-
Was zum Teufel veranstaltet es da z.B. mit einem Dateinamen wie "D60ü geist Eig.pdf"?
Bis auf die nachstehende "0" genau das, was in den Vorschriften steht. RFC 1806 Paragraph 2.3 schreibt vor, dass in der Zeile "filename*" nur US-ASCII-Zeichen verwendet werden dürfen. RFC 2184 sieht jedoch eine entsprechende Ersatzschreibweise vor, die es erlaubt, Dateinamen, die so nicht darstellbar sind, in ASCII zu konvertieren. Mail hat sich hier für die Codierung über ISO 8859-1 entscheiden und den Namen umgewandelt.
Nur die 0 am Ende ist falsch. Das ist ein bekannter Fehler in Apple Mail, der seit 10.5.2 vorhanden ist.
-
Danke, jetzt hab ich verstanden, was Mail.app tut (oder tun möchte). Die 0 sollte hinter den Asterisk.