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.

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.

Zitat

Zitat

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.

Zitat

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.    

Zitat

Steht da "Rich Text" im englischen?

Ja.

OK, das ist dann nicht so eindeutig, wobei ich RTF und HTML gleich schlimm finde.

Zitat

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.

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 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. 

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.