ARCHIV 1999-2006

ARCHIV :: # 4369

Apple Mail Linebreak-Problem kostet Apple Millionen Dollar

Alles, was sie niemals über umbrechende URLs wissen wollten...

Autor: kai - Datum: 08.09.2006

Nach etwas sinnieren und viel Rumprobieren wurde mir klar, dass das URL-Umbruchsproblem in Apple Mail weiterreichendere Folgen hat als Ärger für die User, wenn der Empfänger am anderen Ende eine nicht-klickbare zerstückelte URL erhält:
Apple bietet im iTMS die Funktion "iTunes Music Store URL kopieren" im Kontextmenü an, unter anderem damit man Freunden und Verwandten direkte Links auf empfehlenswerte Lieder schicken kann.
Nur: Was ist, wenn der Link beim Empfänger dann gar nicht klickbar ist?
Der normale Nicht-Apple-Mail-Anwender (und das sind ca. 98%) hat entweder keine Lust oder weiss nicht, wie er aus der zerstückelten URL wieder eine Ganze machen kann, und da der Name und Interpret des Songs nicht in der URL enthalten sind kann er noch nicht einmal manuell suchen.
Wenn diese Situation nur einmal in 1000 Fällen eintritt, was sehr pessimistisch gerechnet ist, sind durch das Problem Apple inzwischen schon über eine Million Dollar durch die Lappen gegangen - und dabei rechne ich nur einzelne Songs, keine Videos und keine ganzen Alben ("Hallo Tom, wenn du mir was zum Geburtstag schenken willst: Dieses Album hätte ich gerne [kaputter Link]"). Es gibt laut den letzten mir bekannten Zahlen deutlich über 20 Mio aktive MacOS X-User da draussen, und es ist wohl nicht vermessen zu vermuten, dass der Großteil davon Apple Mail nutzt und dank ihrer Apple-Affinität zu den aktivsten iTMS-Kunden gehört, die obendrein mit einer gesunden Portion Missionierungsdrang gesegnet sind.

Wir machen die Probe aufs Exempel mit einer Vielzahl an Mail-Clients, eruieren, wodurch das Problem überhaupt entsteht und wie das mit den Internet-Standards aussieht. Ausserdem bieten wir Notlösungen zur Problembehebung an, bis Apple endlich reagiert... 1. Technischer Hintergrund
Das Problem entsteht, weil Apple ein Space und ein Whitespace (Newline, Hexadezimal-Code 0x0a) in zu lange URLs einfügt. Für eine Erklärung warum siehe weiter unten, aber soviel vorweg: Zumindest halten sie sich dabei an Internet-Standards.

Hierzu ein kleiner Abriss des Internet-Standardisierungs-Prozesses: Nachdem jemand zusammen mit anderen eine neue Idee ausgearbeitet hat wird das ganze als RFC (Request for Comments) als Vorschlag eingereicht, es folgt dann dem sogenannten "Standards track" und ist vorerst ein "proposed Standard". Dann diskutiert man darüber, wenn Änderungen notwendig sind wird ein neues RFC mit einer eigenen Nummer erstellt, das alte RFC wird dann meist "obsoleted", d.h. aus dem Standards Track entfernt. Danach wird es, wenn alle zufrieden sind, von der IETF (Internet Engineering Task Force) zum sogenannten Draft Standard (DS) befördert, quasi ein Testlauf eines zukünftigen verpflichtenden Standards. DS ist die zweite Stufe des Standards Track. Wenn alles wunderbar ist wird es letztendlich zum finalen Standard geadelt (STD).

Das vormals zitierte RFC1738 ging in RFC3986 auf, was unter dem Namen STD66 als verpflichtender Internet-Standard die höchste Hierarchieebene erreicht hat.
In RFC3986 ist zu lesen:
"In some cases, extra whitespace (spaces, line-breaks, tabs, etc.) may have to be added to break a long URI across lines. The whitespace should be ignored when the URI is extracted."

Man beachte, dass da nicht steht, dass die URL umbrechen muss, nur, dass sie umbrechen darf. Ebenso sollte man das Whitespace entfernen beim Verarbeiten der URL im Mail-Client, aber dies scheint wohl nicht verpflichtend zu sein. Es stellt sich die berechtigte Frage, wozu ein Standard definiert wird, wenn die Umsetzung seiner Features optional ist! ;-)

Neben RFC3986 gibt es noch RFC3676, bisher allerdings erst ein RFC im "Proposed"-Stadium. RFC3676 beschreibt die Definition des "delsp"-Flags im "Content-Type"-Feld des Mail-Headers, zusammen mit dem Text-Attribut "flowed" (als Alternative zum bisherigen "plain"). Beides zusammen soll Probleme beim Quoting, wie das gefürchtete Kamm-Quoting vermeiden, indem es, wenn delsp und flowed gesetzt sind, die zur Abwärtskompatibilität eingebauten "soften" Zeilen-Enden bei der Verarbeitung durch den anzeigenden Mailer automatisch entfernt. "Abwärtskompatibel" heisst in diesem Fall, dass Mailer, die keine "soften" Linebreaks kennen stattdessen nur ganz normale Linebreaks darstellen.
Harte Zeilenumbrüche erzeugen nicht nur Kammquotings und unschönen Blocksatz bei nicht-proportionaler Schrift, sie sind obendrein auch sehr problematisch beim Lesen auf Geräten mit kleinem Screen, wie etwa Handys, PDAs oder auch iPods.

2. Zeilenumbrüche in der Praxis
Wir testen mit vielen verschiedenen Mailern unter Linux, Windows und MacOS. Unser Test-Link ist "Break the line" von den Guano Apes. ;-)

Voll klickbare Links zeigt nur Mutt, Balsa und Apple Mail an, Opera ist ebenfalls klickbar, bricht den Link allerdings um wenn geantwortet wird.

Halb funktioniert es in Thunderbird/Mozilla(Seamonkey): Der Umbruch und das Space werden herausgefiltert, der Teil der URL hinter dem Umbruch ist allerdings nicht-klickbarer Plaintext, die URL ist kaputt. Hierbei handelt es sich allerdings um einen Bug, der schon in Bugzilla gelistet ist und der wohl bald behoben wird.

Nicht funktionieren tut es mit Evolution, Kmail, Squirrelmail, Outlook, Outlook Express, Sylpheed und Eudora, was wohl leider den größten Teil der verwendeten Mailer abdecken wird.

Achtung: Besondere Vorsicht ist gegeben mit Mailinglisten, denn diese entfernen beim Weiterleiten in der Regel im Content-Type-Feld des Mail-Headers einer Apple-Mail das "delsp=yes; format=flowed". Dies führt dazu, dass die wenigen Mailer, die delsp/flowed berücksichtigen, wie etwa Thunderbird oder auch Apple Mail selbst, die Spaces am Ende nicht mehr entfernen und der Link kaputtgeht.

3. Gegenmaßnahmen
Bis Apple sich des Problems annimmt (Die Vorteile des RFC3686-Ansatzes mit flowed und delsp sind unbestreitbar, aber zumindest für URLs sollten Ausnahmeregelungen gelten) müssen wir uns eben selbst helfen:

a) Im vorherigen Artikel wurde schon TinyURL erwähnt, mit dem man lange Links auf sehr handliche Größe abkürzen kann. Dies ist allerdings leicht aufwendig, dafür aber 100% sicher für alle Mailer der Welt.

b) Eine weitere Methode findet sich in RFC3986:

"Using <> angle brackets around each URI is especially recommended as a delimiting style for a reference that contains embedded whitespace."

Wenn ein Link in spitzen Klammern steht, filtern viele Mailer alle für URLs illegalen Zeichen zwischen den spitzen Klammern, also eben auch Space und softe linebreaks. Dadurch ist zwar nicht garantiert, dass der Link vollständig klickbar am anderen Ende ankommt (manchmal noch mit Zeilenumbruch, aber das ist ja sekundär), denn Outlook ignoriert auch das, aber die Zahl der empfangenden Mailer, die damit klar kommen kann so zumindest erhöht werden.

c) Ein weiterer Trick ist, Statt Plain-Text Rich-Text/HTML zu verwenden, was für Emails allerdings zweifelhaften Ruf genießt. Vorsicht: Nur weil "Formatierter Text" bei den Apple Mail-Einstellungen im Reiter "Verfassen" vorausgewählt ist heisst das noch lange nicht, dass jede Mail in HTML verfasst wird. Erst wenn auch konkret irgendwo in der Mail Formatierung verwendet wird (Schriftgröße/Art, Farben, unterstrichene Links, MIDI-Hintergrundmusik, AniGIF-Gefunzel usw. vorsicht: Gilt nicht für Bilder, Bilder alleine kann Apple Mail (wie alle anderen Attachments) auch in Plaintext im Multi-Part-MIME-Format umsetzen!) sendet Apple Mail nach einer entsprechenden Warnung die Mail auch wirklich im Rich-Text-Format.
Wenn der Empfänger allerdings einen Mailer ohne Web-Engine nutzt, beispielsweise diverse Kommandozeilen-Mailer wie Mutt, Pine oder Emacs, handelt man sich damit unter Umständen allerdings ziemlich verärgerte Antworten ein.

4. Problemlösung seitens Apple
Das Problem zu lösen ist nicht ganz leicht, und ich kann mit dem jetzigen Kenntnisstand nachvollziehen, warum Apple dies bisher nicht getan hat. Laut Definition ist die maximale Länge einer nicht-umgebrochenen Zeile in einer Email wegen diversen Implementierungs-Einschränkungen innerhalb des Mail-Server-Netzes 998 Zeichen, gängiger und empfohlener Standard sind sogar nur 78 Zeichen (Apple setzt ihre soft-linebreaks nach maximal 72 Zeichen). Wenn Apple wie andere Mailer harte statt softe Linebreaks nutzen würde stellt sich das Problem, dass der Mailer, selbst wenn er den Text in einem Quoting neu umbricht (wie er es jetzt mit den soften Linebreaks auch macht!), nicht zwischen echten Zeilenschaltungen und Mailer-Umbrüchen unterscheiden kann. Macht ein User nicht zwei Zeilenschaltungen sondern nur eine für einen neuen Absatz lässt sich im Nachhinein nicht mehr ermitteln, ob die Zeilenschaltung Absicht war, oder vom Mailer gemacht wurde. Somit weiss Apple Mail nicht eindeutig, ob es diese Zeilenschaltung neu umbrechen soll. Darüberhinaus löst "harte statt softe Linebreaks" das Umbruchsproblem in URLs in keinster Weise.

Ein Lösungsansatz der nicht das gesamte, durchaus sinnvolle und optisch schönere Konzept des delsp/flowed über den Haufen werfen würde wäre, dass für Zeilen mit URLs Ausnahmeregelungen gelten sollen und diese Zeilen nicht umgebrochen werden, weder soft noch hart. Da eine URL für den Lesefluss irrelevant ist kann also der empfangende Mailer hier umbrechen, wo er will (oder eben auch gar nicht). In RFC3986, in welchem die Syntax und Einschränkungen von URLs (heute in Standardisierungkreisen eher mit dem Überbegriff "URIs" bezeichnet, aber dieser Terminus ist in der breiten Masse immer noch nicht gebräuchlich) definiert werden, steht zu lesen:

"URI producers should use names that conform to the DNS syntax, even when use of DNS is not immediately apparent, and should limit these names to no more than 255 characters in length."

Man beachte auch hier wieder das Wörtchen "should", was dazu führte, dass diese Grenze heute nicht generell verpflichtend ist. Bekannt ist u.a., dass der Internet Explorer URLs bis zu 2048 Zeichen verarbeiten kann, also gibt es sicherlich irgendwo Webserver, die ihre Cookies lieber per URL kodieren (um Cookie-Blocker zu umgehen) und sogar noch ein ASCII-kodiertes User-Icon mit reinpacken! ;-)
255 Zeichen wäre also ganz klar innerhalb der 998-Zeichen-Grenze, 2048 wäre das allerdings nicht mehr.
Solche URLs sind aber wahrscheinlich sehr selten, somit dürften die resultierenden Probleme vernachlässigbar sein, wenn Apple Mail nach Erreichen der 998 Zeichen einen soften Linebreak einfügt. Andere Mailer machen es ja nicht anders, denn ab einer gewissen Länge bricht jeder Mailer um.

Probleme gibt es beim Ansatz "Ausnahmeregelung für Zeilen mit URLs" nur, wenn eine zu lange URL direkt im Fließtext steht. Obwohl kaum jemand solche leseflussfeindlichen Mails schreibt wäre der sinnvollste Ansatz wohl, dass Apple Mail vor der URL und danach einen soften Linebreak einfügt, damit die maximale Fensterbreite optimal genutzt ist.

Kommentare

SHOULD!!!!

Von: Lars Träger | Datum: 10.09.2006 | #1
<ftp://ftp.isi.edu/in-notes/rfc2119.txt>

3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

"Ich hab kein Bock weil ich zu faul und/oder Microsoft bin" ist kein "valid reason".

@KAI

Von: /me | Datum: 10.09.2006 | #2
"Ich kenn Leute, die machen Word auf, nur um sich zerstückelte URLs wieder zusammenzubasteln, kein Scheiss.. Und das sind noch welche von der Freak-Fraktion!"

Wie jetzt? Du kennst Leute?
- Deine einzigen Freuden bestehen im Bashen von Apple und ihren neuen, bösen Freunden und nun willst du plötzlich im _realen_ Leben echte Menschen kennen? Nicht doch, das ist zu witzig. :-D

Back to basics?!

Von: MILE | Datum: 09.09.2006 | #3
Womit schreibst Du (svenc) Deiner Briefe? Mit der alten Olympia-Schreibmaschine oder gar mit dem feschen Mont Blanc Füller? ;)))

Nein, du verwendest einen Computer, um den Inhalt auch optisch angenehmer, lesbarer, übersichtlicher zu gestalten...nehme ich zumindest an...!? Ob du das nun in Word ode Pages tus, sei dahingestellt...aber dennoch wirst du darin Formatierungen verwenden, oder...?!

Und eben diese Möglichkeit hat man seit langem in Mail-Nachrichten auch, warum soll man sie also nicht nutzen...?!

Warum denken immer alle, eine formatierte Mail wäre immer gleich zu setzen mit dem verpönten "Klickibunti-Dreck" diversen Outlook-Guerillas...?!? In Maßen und dezent eingesetzt bietet eine formatierte Mail nunmal Gestaltungsmöglichkeiten, die wir alle als Computernutzer gewohnt sind und die -- richtig verwenden -- die Lesbarkeit erhöhen, Kerninformationen hervorheben, den Inhalt strukturieren...!

Willkommen im 21. Jahrhundert...! ;)

Qual-ität

Von: ein stänkerer | Datum: 09.09.2006 | #4
Peter: "ein Großteil der Kommentare sind unter aller Sau."

haben sich halt dem niveau der "artikel" angepasst

@nix

Von: Peter | Datum: 08.09.2006 | #5
Muss dir zustimmen, ein Großteil der Kommentare sind unter aller Sau. Man kann den Ausführungen von Kai zustimmen oder sie ablehnen, aber so darauf reagieren wie hier, das gehört ins Heise-Forum. Schämts euch.

Peter

Re: HTML-Mails sind die Krätze...

Von: svenc | Datum: 08.09.2006 | #6
Hi Kai,

selten hast Du mir so aus der Seele gesprochen.

Ein Fakt hast Du vergessen.

Wenn man mal überschaut, wieviel Traffic im InterNet alleine durch eMail verursacht wird, sollte man sich mal ausmalen, wie stark dieser Traffic ansteigt, wenn alle Anwender nur noch HTML-eMails versenden.
Das würde eine Verdrei-/vier-/fünffachung des Traffics bedeuten.
WWW wäre dann gleichbedeutend mit
WeltWeitemWarten
Ich habe leider keine genauen Zahlen, aber ich schätze mal, dass derzeit (per Stückzahl) noch etwa die Hälfte aller Mails "PlainText" sind.
Bei der Datenmenge würde ich mal behaupten, liegt der Faktor bei vielleicht 1 zu 8.

HTML-eMails sind einfach Dreck.
Wer mir eine Mail schreibt und dafür HTML benötigt, muss scheinbar auch bei der Konversation mit bunten Flaggen winken, damit er verstanden wird.

Gruss

svenc

@Malte: Bandbreite

Von: svenc | Datum: 08.09.2006 | #7
"Bandbreite
--- das ich nicht lache. Wir leben in einer Welt mit Bandbreite im Überschuss. Wen interessiert es schon ob 1 oder 10 kb übertragen werden? Hatte ich vorweggenommen das Argument, weil es seit Ende der 90er veraltet ist..."

Das ist riesiger Blödsinn, sorry, aber das ist so.

Typische Firma in Deutschland, ADSL-Leitung, vielleicht 512KBit Sendeleistung.
Viel eMail-Verkehr.
Rechne Dir selber aus, was passiert, wenn die Mails plötzlich 10mal so groß sind, wie bisher.
-> Längere Laufzeiten
-> weniger Bandbreite für andere Dienste
-> Mehrbelastung für die Mailserver
(wer schon mal einen echten Mailserver konfiguriert hat, weiss, was da vor sich geht und welche Datenmengen dann verschoben, gesichert, verwaltet werden müssen).
-> Alleine das Öffnen der Mails (da muss ja dann direkt die HTML-Render-Engine anspringen) verbraucht unnötig Rechenzeit und bei älteren Rechnern (nicht jeder hat immer das aktuellste Equipment vor sich stehen) braucht das auch schon mal 1 oder 2 Sekunden oder sogar länger, bis sich die Mail dann in Ihrer Bildzeitungsqualität zeigt.

Wer zu blöd ist, seine eMails in PlainText so zu formatieren, dass sie verständlich und lesbar sind, soll vielleicht mal RTF probieren, obwohl ich auch das für nicht notwendig halte.

Ich frage mich immer, wie sehen die Briefe der Leute aus, die HTML-eMails schreiben.
Womit schreibst Du (Malte) Deiner Briefe? Mit Quark oder InDesign? Benutzt Du auch im Text x verschiedene Zeichensätze, Formatierungen, Farben?
Dann hast Du definitiv ein Problem, Dich mitzuteilen :-)

Gerade bei der Korrespondenz ist "weniger oft mehr", denn der Inhalt ist entscheidend, die Formulierung, nicht die Farbe des Briefpapiers.

Gruss

svenc

Willkommen bei...

Von: ghme | Datum: 08.09.2006 | #8
...wir basteln uns Probleme die sonst niemand hat.

Zusammenbruch des Internets wegen HTML-E-Mails. Ja genau...

@ghme: siehe Titel

Von: Unsere Susi | Datum: 08.09.2006 | #9
Kai sagt es ja schon zusammenfassend: "Alles, was sie niemals über umbrechende URLs wissen wollten..."

Stimmt. Ich habe nichts hinzuzufügen.

@Macco

Von: Tommy | Datum: 08.09.2006 | #10
Ich glaube, Kais Kenntnisse sind halt ebenso veraltet wie die Prozessoren, denen er immer noch nachweint ;-)

@*nix

Von: Tommy | Datum: 08.09.2006 | #11
"Die Kommentare zu dem Artikel find ich diesmal so richtig unter aller Sau - niemand kann hier behaupten Kai hätte sich nicht bemüht!"

Soll das ein Witz sein - "bemüht"? Meinst du "bemüht" im Sinne von "er hat sich stets bemüht" - so wie man es in einem Arbeitszeugnis schreiben würde? Dann würde ich Dir sogar beipflichten. Aber um "Mühe" geht es hier halt nicht, ein bisschen Kompetenz wäre eine schöne Sache.

"may be added" (Die Korrekte Übersetzung des kompl. Zitats) (mit Erklärung)

Von: *nix | Datum: 08.09.2006 | #12
Ihr könnt euch alle gerne weiterstreiten, hier jedenfalls mal eine korrekte Übersetzung.

"In some cases, extra whitespace (spaces, line-breaks, tabs, etc.) may have to be added to break a long URI across lines. The whitespace should be ignored when the URI is extracted. The whitespace should be ignored when the URI is extracted."

"In manchen Fällen müssen möglicherweise extra Whitespaces (Leerzeichen, Zeilenumbrüche, Tebulatoren, etc.) hinzugefügt werden um eine lange URI über die Zeilen hinweg brechen zu können. Der Whitespace sollte dann dabei ingnoriert werden, wenn die URI extrahiert wird."

Kai hat mit seinem "must" allerdings vollkommen recht, sprachlich kann man nicht von einer klaren Einschränkung sprechen. Allerdings findet "must" im Englischen nur in sehr drastischen Einschränkungen Anwendung, vor allem von Authoritäten, meist imperativ, und immer Verknüpft mit einer Kondition (auch wenn nicht ausgesprochen).

"You must ignore Whitespaces when the URI is extracted" - "Sie müssen Whitespaces ignorieren wenn die URI extrahiert wird" (in Gedanken fortzusetzen mit "sonst passiert etwas schlimmes") ..sowas steht auf einem Sicherungskasten (..must shutdown before..)

@Tommy

Von: *nix | Datum: 08.09.2006 | #13
=D

@Kai

Von: Macco | Datum: 08.09.2006 | #14
Kai:
"Vielleicht geht's ja hier um die MAXIMALE LÄNGE, die ne Zeile in einer Mail haben darf, kann das sein?"

So jetzt mal Butter bei die Fische: welche Content-Kodierungen außer der von Dir angeführten, die 24 Jahre alt ist, kennst Du?
Wenn Du Dich unbedingt als Vollpfosten aufführen willst, magst Du das tun. Aber hör auf hier hanebüchenen veralteten Quatsch abzusondern. Das hält ja kein Mensch aus.

@Kai

Von: Tommy | Datum: 08.09.2006 | #15
"Realität (bzw. geschriebenes) wird ignoriert und im Gegenzug suggeriert, dass man nicht zuhören würde, obwohl man genau auf alles eingeht. Noch nen kräftigen Schuss ad homs oben drauf und fertig ist die Mischung! 8)"

Das nenne ich eine treffende Selbstdarstellung Deinerseits! Relevante Passagen aus den Postings der anderen weg lassen, unfähig sein, einen eigenen Fehler zuzugeben, und der Rest Deiner Beschreibung trifft Deine Winkelzüge auch ganz gut...

"Nette Gäste gibt's hier seit dem Intel-Switch, echt..."

Deine Paranoia ist mittlerweile so grenzenlos, dass Du über stationäre Behandlung nachdenken solltest. Oder warte, vielleicht bist Du gar nicht paranoid, vielleicht sind sie _wirklich_ alle hinter Dir her ;-)

Atrikel wie Kommentare

Von: *nix | Datum: 08.09.2006 | #16
wiedermal sinnfrei..

Probleme mit Mail.app?

-> anderen Mail-Client verwenden
-> Mail an Apple schicken

Ich mein, toll Kai, dass du dich so damit befasst hast - nur wen zur Hölle intressiert das hier? dödödödöd Zeichenlänge in einem RFC-Standard aufbereitet für die Macuserschaar? Sonst geht's dir gut, oder? Macuser lieben Lösungen, nicht Probleme, aber das hast du ja wohl nie so richtig verstanden.

Die Kommentare zu dem Artikel find ich diesmal so richtig unter aller Sau - niemand kann hier behaupten Kai hätte sich nicht bemüht! Er arbeitet ein sehr komplexes Thema auf und geht da durchaus richtig auf viele Punkte ein. (Bis auf die Auswertung des Englisch im RFC.. leider ist das Englisch vieler Entwickler nicht auf dem Niveau dt. Gymnasien, M$ hat's aber Oxfordgenaugenommen während Apple-Devs mit Hirn implementiert haben)...

dennoch, wer ein Problem hat, hat längst eine Lösung - wer mit Mail kein Problem hat sollte auch nicht Wirklich Interesse an diesem Thema haben. Und wen das Thema intressiert, für den hat es Kai schon auf den Punkt gebracht.


Warum schon wieder sinnlos Trolldiskutiererei? Nur weil Jemand mit dem Namen Kai einen Artikel schreibt der ein Problem mit einem Apple-Produkt bespricht? Rotes Tuch..

@Kai: Lesen bildet

Von: Tommy | Datum: 08.09.2006 | #17
Abstract RFC 2822 (von Dir selbst verlinkt) beginnt mit "This standard specifies a syntax for text messages..."

Also nochmal für die ganz Schnellen unter uns: Nehmen wir mal an, Plain Text ist in der E-Mail, nichts anderes. Da gibt's keine

Vorname:

Von: Kai (MacGuardians) | Datum: 08.09.2006 | #18
Zwar komplett offtopic, aber trotzdem: Alt.
Wenn du rechnen könntest wäre dir klar, dass 16.000 Opteron-Cores _im Peak-Idealfall_ bei 2.8 GHz nur 89.600 GFLOPS (das würde noch nichtmal für Platz 3 der *aktuellen* Top500 reichen!) schaffen. D.h. die restlichen 1.510.400 GFLOPS (ja, das sind fast 17 mal mehr als die Opteron-Leistung!) der 1.6 PFLOPS peak müssen von den 16.000 Cells kommen! <:-)

Es ist für normal denkende Menschen also ziemlich offensichtlich, wer hier für wen den Wasserträger spielt! ;-)

Böses Eigentor würd ich sagen, hehe...

may/should/must

Von: Daniel | Datum: 08.09.2006 | #19
Irgendwo gibt es eine RFC, die genau festlegt, was may/should/must in RFCs bedeutet. Im Prinzip bedeutet es:

may - mach es, wenn Du willst.
should - mach es! Außer Du hast einen verdammt guten Grund. Dann wundere Dich aber nicht, wenn etwas nicht geht.
must - mach es! Keine Ausreden.

@Tommy: Wie würdest Du das denn übersetzen? Ich lese das auch so, dass es sein könnte (may), dass man die URL umbrechen muss (have to). Wann man umbrechen muss steht da nicht, wenn man muss - z.B. weil die länger als x Zeichen ist - dann darf man auch.

Nochmal zu Deinen Englisch-Kenntnissen

Von: Tommy | Datum: 08.09.2006 | #20
""may have to be" heisst nix anderes als "könnte eventuell [..] werden", also heisst "extra whitespaces may have to be added" "extra Trennzeichen könnten eventuell hinzugefügt werden müssen" - Also keine Verpflichtung, das zu tun, verpflichtend wäre "must be added"!"

"may have to be added" im Zusammenhang mit "in some cases" bedeutet nichts anderes, als dass _in_manchen_Fällen_ die Whitespaces hinzugefügt werden müssen, oder, in Deinen Worten: "könnten... werden müssen" heißt nichts anderes, als dass Bedingungen auftreten können, unter denen eben dies erforderlich ist (= sein muss). Mach Dir um mein Englisch keine Gedanken, mein Studium war lang genug.

Böses Eigentor würd ich sagen, hehe...

Von: Vorname | Datum: 08.09.2006 | #21
Ich habe erst garnicht nachgerechnet.

Aber ohne starke Gerneral Purpose CPU scheint es nicht zu gehen ;-) hehehe

... selbst im Supercomputerbereich, der nichts mit Macs zu tun hat.

;-)

@Kai

Von: Macco | Datum: 08.09.2006 | #22
Kai:
"Im übrigen: Was ist denn deiner Meinung nach eine "text message", wenn keine Email?"

Es kann ja niemand etwas dafür, dass Du sämtliche möglichen formaterhaltenden Kodierungen des MIME-Formates verschlafen hast. Mit HTML hat das zudem rein gar nichts zu tun.

@Tommy: Postings fertig schreiben bildet auch! ;-)

Von: Kai (MacGuardians) | Datum: 08.09.2006 | #23
..und Sätze fertig lesen bzw. komplett zitieren auch:
"This standard specifies a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages."

Sauber ausm Kontext gequotet würd ich sagen! ;-)

Und du fragst mich ernsthaft, was das mit Mails zu tun hat? Na danke fürs Gespräch...

@Kai: nicht verstehen wollen...

Von: Tommy | Datum: 08.09.2006 | #24
...ist eine echte Kunstform von Dir, oder? jetzt _lies_ nochmal, was ich geschrieben habe und dann versuch, das auch zu _begreifen_! Es geht nicht um die Frage, ob es sich hier um E-Mails handelt, sondern um die Tatsache, dass dieses RFC _nichts_ mit "klickbaren Links" zu tun hat, die Dein Client Dir freundlicherweise anzeigt. Nochmal: eine URL innerhalb eines Plain-Text-Body-Parts (für Dich: das ist ein Teil einer E-Mail) ist in keinster Weise lt. Standard derart zu kennzeichnen, dass der Client sie als "klickbaren Link" darstellen muss.

Jetzt wiederhole ich mich schon wieder, obwohl mir klar sein müsste, dass Deine Lesekompetenz zwischen zwei Postings kaum steigen wird. Immerhin gibst Du jetzt schon zu, dass die zitierte Passage vorkommt. Der Patient macht Fortschritte.

Zum Thema (absichtliches?) Missverstehen

Von: Tommy | Datum: 08.09.2006 | #25
sei mir erlaubt, an dieser Stelle Helge Schneider zu zitieren mit den Worten:

"Eine Diskussion kann hier auch gar nicht zu Stande kommen, denn die Intelligenzen der Teilnehmer sind, äh, verschieden..."

Englisch-Kenntnisse...

Von: Kai (MacGuardians) | Datum: 08.09.2006 | #26
"Mach Dir um mein Englisch keine Gedanken, mein Studium war lang genug."

Soso. Was "within the framework of 'electronic mail' messages" heisst hast du jedoch anscheinend nicht gelernt! ;-)

Komm mal runter von deinem hohen Ross. Glaubst du ernsthaft, du bist der einzige, der hier Englisch kann? Ich spreche schon seit über 10 Jahren fließend Englisch, also verschone mich doch bitte mit solchen herablassenden Sprüchen...

Ich bleib dabei: Wäre dem so, wie du behauptest, würde da "must be" stehen, nicht "may have to be". Willst du mir ernsthaft erzählen, dass "may" und "must" dasselbe ist?

Tommy:

Von: Kai (MacGuardians) | Datum: 08.09.2006 | #27
"...ist eine echte Kunstform von Dir, oder? jetzt _lies_ nochmal, was ich geschrieben habe und dann versuch, das auch zu _begreifen_! Es geht nicht um die Frage, ob es sich hier um E-Mails handelt, sondern um die Tatsache, dass dieses RFC _nichts_ mit "klickbaren Links" zu tun hat, die Dein Client Dir freundlicherweise anzeigt."

Bitte: Verschone mich mit deiner Arroganz und lerne erstmal selbst zu lesen. RFC2822 wurde in diesem Satz verlinkt: "Laut Definition ist die maximale Länge einer nicht-umgebrochenen Zeile in einer Email wegen diversen Implementierungs-Einschränkungen innerhalb des Mail-Server-Netzes 998 Zeichen"

Hier geht's nicht um klickbare Links? D'oh! Erzähl Geschichten! Vielleicht geht's ja hier um die MAXIMALE LÄNGE, die ne Zeile in einer Mail haben darf, kann das sein? Oops, exakt genau das steht da ja, wie doof! ;-)

Gespräch sinnlos,

Von: Tommy | Datum: 08.09.2006 | #28
Kommunikationswille Deinerseits gleich null, Eingehen auf meine Postings gleich null, Verständnis von Inhalten ebenfalls gleich null. Was für eine Diskussion sollte hier auch stattfinden?

Tommy:

Von: Kai (MacGuardians) | Datum: 08.09.2006 | #29
"Immerhin gibst Du jetzt schon zu, dass die zitierte Passage vorkommt. Der Patient macht Fortschritte."

Fakt: Die zitierte Passage kommt in keiner von mir verlinkten Seite vor.

Wenn du dich auf einer verlinkten Seite weiter durchklickst finde ich das lobenswert, dass du deinen Horizont erweitern willst, aber es wäre echt furchtbar nett von dir mir dann auch im selben Posting zu sagen, auf was du dich genau beziehst, wenn du mir schon vor den Karren kacken willst! ;-) Das Interwebby ist groß, weisst du, da gibt's mächtig viele Links zum Draufklicken! 8)

Sinnlos...

Von: Kai (MacGuardians) | Datum: 08.09.2006 | #30
"Was für eine Diskussion sollte hier auch stattfinden?"

Ja, lassen wir's lieber. Du bist offensichtlich unfähig zu begreifen, worum's geht.. Dein einziges Ziel ist es mir ans Bein zu pinkeln, und sei's noch so abstrus an den Haaren herbeigezogen...
Realität (bzw. geschriebenes) wird ignoriert und im Gegenzug suggeriert, dass man nicht zuhören würde, obwohl man genau auf alles eingeht. Noch nen kräftigen Schuss ad homs oben drauf und fertig ist die Mischung! 8)

Nette Gäste gibt's hier seit dem Intel-Switch, echt...

Noch 'ne Bemerkung zum User-Profil...

Von: Tommy | Datum: 08.09.2006 | #31
Wie viele Kunden des iTunes-Musicstore verwenden wohl Mail-Clients, die keine HTML-Mails beherrschen?

...und noch watt, Kai...

Von: Tommy | Datum: 08.09.2006 | #32
"This standard specifies a syntax for text messages"

Was hat dieser RFC mit klickbaren Links zu tun? Eine "Text Message" hat erstmal gar keine klickbaren Links. Das, was der Client *versucht*, daraus zu machen, hat mit diesem RFC rein gar nichts zu tun. Was zimmerst Du Dir hier für Hirngespinste zurecht?

@Tommy

Von: Macco | Datum: 08.09.2006 | #33
Lern lesen: so wenige können es ja nicht sein. Kai sagt doch, dass es bereits zu Millionenverlusten geführt hat.

@Macco

Von: Tommy | Datum: 08.09.2006 | #34
Wieso hab ich nur das Gefühl, dass hier in Zukunft jeder Running Gag losgeht mit den Worten: "Kai sagt doch..."

Das Beste aus allen Welten

Von: Rainer Pelitz | Datum: 08.09.2006 | #36
Na, die machen doch genau das, was ich immer predige: Das Beste aus allen Welten verbinden!

Nur hätte ich nun noch einen Cor2Duo mit Reingeschraubt!

Windows Vista drauf und dann hat man einen PC, der allen Eventualitäten trotzt!!!!

Thommy:

Von: Kai (MacGuardians) | Datum: 08.09.2006 | #37
Sag mal, was hast du eigentlich für ein Problem? Welche Laus ist dir denn über die Leber gelaufen?

[Link]

"may have to be" heisst nix anderes als "könnte eventuell [..] werden", also heisst "extra whitespaces may have to be added" "extra Trennzeichen könnten eventuell hinzugefügt werden müssen" - Also keine Verpflichtung, das zu tun, verpflichtend wäre "must be added"!

So. Und jetzt guckst du noch mal nach, was "in some cases" heisst! ;-)

"Für wie blöd hältst Du die Leute eigentlich?"

Die Frage lautet eher für wie faul ich die Leute halte! <:-)
Ich kenn Leute, die machen Word auf, nur um sich zerstückelte URLs wieder zusammenzubasteln, kein Scheiss.. Und das sind noch welche von der Freak-Fraktion!

"Was hat dieser RFC mit klickbaren Links zu tun?"

Welches RFC soll das sein? Kann den von dir zitierten Text weder in RFC3986 noch in RFC3676 finden.
Im übrigen: Was ist denn deiner Meinung nach eine "text message", wenn keine Email?

rob72:
"Habt ihr keine Freunde/Familie, denen ihr mal bunte Emails mit embeddeden (YESS!) Fotos oder netten Fonts JUST FOR FUN (!) zuschickt?!?!"

Fotos kann ich auch ohne HTML-Mails schicken, und extra Fonts verwenden ist mal so überflüssig wie Rotz. V.a. weil man überhaupt nicht wissen kann, ob der Font am anderen Ende auch installiert ist!

Malte

Von: pm | Datum: 08.09.2006 | #38
Es ist falsch mir Zynismus gegenüber Cyrus zu unterstellen. Die hatten jahrelang eine gute Chance Ihr Produkt zu lizenzieren etc. Auch die Schwäche PoP relativ spät zu implementieren kann mir nicht zu Last gelegt werden.
Ansonsten kann ich aber sagen, dass nach den ersten Tests die neue Version sehr vielversprechend ausschaut. Sollten wir diese Mehrfachfenster noch wegbringen - hat das Produkt durchaus eine Perspektive.

Nachdem Apple es nicht schaffte die letzten 5 Versionen von Mail mindestens so stabil wie Eudora auszuliefern gibt es keinen Grund für einen Mail Einsatz.

Bei mir zählt nur Stabilität. Das Aussehen der Applikation ist relativ zweitrangig. Eudora ist gut zu handhaben auch mit Multiple Accounts etc. (Form follows function Prinzip)

Noch mehr Kai-derwelsch

Von: Tommy | Datum: 08.09.2006 | #39
"998 Zeichen, gängiger und empfohlener Standard sind sogar nur 78 Zeichen"

Werfen wir da etwa die Protokoll-Limitation mit einer _Empfehlung_ zur besseren Darstellung im Client durcheinander, sofern dieser nicht standardkonform implementiert wurde?

"The more conservative 78 character recommendation is to accommodate the many implementations of user interfaces that display these messages which may truncate, or disastrously wrap, the display of more than 78 characters per line, in spite of the fact that such implementations are non-conformant to the intent of this specification"

@pm

Von: Malte | Datum: 08.09.2006 | #40
Jetzt geht der Glaubenskrieg erst richtig los. Ein Hardliner ist auf der Bühne... :-D

Ich mag Apple Mail und hab auch wenig Probleme damit bis jetzt. Allerdings ist mein Mail aufkommen auch relativ gering... Bei Eudora hat mich schon immer das Interface gestört. Ist einfach hässlich (ja, ich achte auf das Äussere)

@pm

Von: Malte | Datum: 08.09.2006 | #41
Es birgt übrigens einen gewissen Zynismus, den durch den Konkurs einer Firma sozusagen erzwungenen Freeware-Status einer Software mit Danke zu kommentieren...

Englisch lernen mit Kai

Von: Tommy | Datum: 08.09.2006 | #42
"In some cases, extra whitespace (spaces, line-breaks, tabs, etc.) MAY HAVE TO BE ADDED TO BREAK a long URI across lines."

"may have to be added" paraphrasierst Du mit
"Man beachte, dass da nicht steht, dass die URL umbrechen muss, nur, dass sie umbrechen darf."

Datt üben wir nochmal...

Yo...

Von: ghme | Datum: 08.09.2006 | #43
HTML-Mails verwenden entweder Computer-Anfänger

Na dann bin ich lieber Computer-Anfänger, als Vollcrackgeekdude im Sinne von Kai.

Noch kurz zum Thema

Von: Tommy | Datum: 08.09.2006 | #44
@Kai: ...kostet Apple Millionen? Für wie blöd hältst Du die Leute eigentlich?

so - jetzt atmen wir alle mal inne Tüte....

Von: rob72 | Datum: 08.09.2006 | #45
...ein...aus...ein...aus...
ruuuhig

aber dennoch mein Senf dazu:
- Millionen verschwendet, wegen falscher URL?!
never! Und wenn schon: Wie war das noch mit dem aktuellen positiven Cash (flow), der sich da in Cupertino, CA türmt?!

- keine html-mails verwenden?!
Ja gehts denn noch. Diese äätzenden 'plain-text' Emails. Gääähn. Wieso sind Emails nur Info?! Hä?!
Habt ihr keine Freunde/Familie, denen ihr mal bunte Emails mit embeddeden (YESS!) Fotos oder netten Fonts JUST FOR FUN (!) zuschickt?!?!

- Standards - da gibts IMMER und ÜBERALL diese 'optionalen' Formulierungen. Egal ob IETF or IEEE oder oder. Das ginge gar nicht ohne 'may' oder 'optional' message parts.

naja - solong
Wochenende ruft schon...
...tühüss

Html-Mails sind Gehirngerechter!

Von: Rainer Pelitz | Datum: 08.09.2006 | #46
Genau! Ich finde, mit html-Mails hat man viel mehr Möglichkeiten der Verschönerung!
Wundert mich dass das von macusern nicht mehr genutzt wird. Da kann man mal seine ganze Kreativität spielen lassen!

Vorterile von html-mails:

-Jede Nachricht ein kleines Kunstwerk mit schönen Farben, Dynamik und Glamour.

-Aber auch Text kann viel übersichtlicher und dynamischer gestaltet werden.

-So kann man mit unterschiedlichen Schrifttypen der Langeweile beim lesen entgegenwirken.

-besonders wichtige Passagen kann man fett oder bunt machen oder blinken lassen!
So wird nichts übersehen, was bedeutung haben könnte. Man kann mit kursiv, fett, bunt, blinkend, eine wahre Hierarchie der Wichtigkeit erstellen. Das ist für das Gehirn viel eingängiger!

Nachteil:

Was mich ärgert: Viele Spamfilter lassen solche masils nicht durch! Als würde ich für Penisverlängerungspillen werben. Eine Unverschämtheit!

p.s.: ich kanns ja nicht lassen: bei Outlook unter vista wird es mit Sicherheit ebenfalls sehr schöne Vorlagen geben!

obiger Post galt Malte und ghme

Von: Rainer Pelitz | Datum: 08.09.2006 | #47
Ich gebe euch recht. html-Mails sind in Wirklichkeit eine bereicherung (des Kulturlebens auch)!!

@malte

Von: imaginetics | Datum: 08.09.2006 | #48
schallplatten gibt es sehr wohl noch, habe mehrere hundert davon und kaufe ständig neue dazu ;)

Okay, na dann

Von: Malte | Datum: 08.09.2006 | #49
"Weiss gar nicht, was es da zu diskutieren gibt."

Oh, jetzt bin ich aber überzeugt. Und das von jemandem der einen ewig langen Text über die URL-Problematik schreibt...

@Rainer Pelitz
Guter Beitrag. in Sachen Sachlichkeit unschlagbar. Und wieder die vorher schon diskutierten Punkte von vorne aufgegriffen... Danke!

"des Kulturlebens auch"
Beispiel Nummer 2 von schlechten Lesekenntnissen und/oder Textverständnis. Aber was solls...

Nochmal: Um Verschönerung ging es mir nicht (lesen hilft!!!).

Ansonsten hab ich alles gesagt. Man sollte aber halt nicht alles pauschal verurteilen nur weil einige Leute mit einigen Sachen nicht umgehen können...

@imaginatics

Von: Malte | Datum: 08.09.2006 | #50
Ich mag Schallplatten auch. Nur als Beispiel für so ein Thema, über das einige Leute gerne überflüssige Glaubenskriege vom Zaum brechen... ;-)

Malte

Von: Rainer Pelitz | Datum: 08.09.2006 | #51
..warum magst Du mich nicht?

Leben und leben lassen...

...

Von: Malte | Datum: 08.09.2006 | #52
Nicht mögen ist immer so ein großer Begriff. So weit würde ich nicht gehen. Ich mag aber deinen Text nicht... :-D

Der "Fehler" ist seit langem bekannt

Von: p m | Datum: 08.09.2006 | #53
Es braucht da keineswegs den Kai dafür. Das entscheidene ist aber, ist es auch relevant.
Da bin ich klar der Meinung, dass das nicht der Fall ist. Mail setzen sowieso nur Leute ein die mutig sind - da Apple das Programm dermassen verunstaltet hat, dass es weniger stabil läuft als GNUmail welches auf dem gleichen Code basiert. Alle anderen Eudora, Mullberry (Als Freeware, danke) haben damit null Probleme

Den itms nutzen sowieso nur musikalische Banausen, welche besser den Ohrenarzt aufsuchen würden. Die Qualität der Songs ist erbärmlich. Nicht nur im Vergleich zu 180 g Vinyl Platten, sondern auch zu gut produzierten CD's.

Einfache Lösung:

Von: iMac | Datum: 08.09.2006 | #54
ein Wort im Mail markieren, Rechtsklick/Link bearbeiten, und erst hier die URL eingeben.

Klappt doch perfekt und ohne Mühe!

Kommandozeile

Von: Malte | Datum: 08.09.2006 | #55
Uhh,
das beste Argument hab ich vergessen.

Aber dazu brauche ich nicht ernsthaft was zu sagen, oder?

Wieso in aller Welt denken seit MacOS X lauter Mac-User sie müssten zu Kommandozeilen-Freaks werden? (damit meine nicht Power User die sich ernsthaft damit auskennen).

Und wenn wir schon über Kommandozeile reden: Wieso benutzen wird überhaupt das Web? Früher ging das doch auch ohne Bilder und HTML. Und wieso gibt es die Schallplatte nicht mehr? Und Kassetten waren auch viel cooler, weil da konnte man hin und her spulen und sie rückwärts hören. Und überhaupt dieser ganze neumodische Mist wie GUIs, Farbmonitore und so...

Ich schnall es einfach nicht...

iMac:

Von: Kai (MacGuardians) | Datum: 08.09.2006 | #56
Jo, nur dass dann halt ne HTML-Mail erzeugt wird (sogar wenn man "nur plaintext" ausgewählt hat!)...

Weiss gar nicht, was es da zu diskutieren gibt. HTML-Mails verwenden entweder Computer-Anfänger, Spammer (ja, Apple auch!) oder Firmen mit ner miesen PR-Abteilung, die nicht kapieren, dass HTML-Mails für Redakteure ungefähr so toll und erwünscht sind wie ein Kropf!

HTML-Mails braucht die Welt ungefähr so "dringend" wie Microsoft Comic Chat, ein IRC-Client, der zu Recht komplett gefloppt ist...

HTML-Mail

Von: Malte | Datum: 08.09.2006 | #57
"Irgendwo immer falsch dargestellt"

--- passiert mir bei Text bei deutschen Umlauten auch irgendwo immer. Jetzt erzählt mir nicht ich soll ohne Umlaute schreiben. Ich mag die deutsche Sprach so wie sie ist...

Replys
--- würde ich so auch nicht pauschalisieren, das kommt nämlich auf den Client an der das Reply verschickt hat

Würmer/Viren
--- mag sein, tun attachments auch. Kommt auch immer auf den Client an. Ist aber das einzige Argument was ein bisschen zieht. Da gebe ich euch recht...

Webmail
--- Wie gesagt, kommt drauf an. Korrekte HTML-Mails werden immer auch in einer nicht HTML-Variante verschickt (ist das ein Standard? ich vermute schon, weiß es aber nicht). Auf jeden Fall sollte bei einem vernünftige konfiguriertem Client das Problem so nicht auftreten.

HTML-Mails sind unsachlich
--- aha, das ist mal ne Aussage. Unsachlich ist immer nur der Inhalt, die Mail kann nichts dafür (gilt ebenso für Papier übrigens). Ne, im Ernst, nur weil einige (vielleicht viele) Leute nicht vernünftig mit gestalterischen Mitteln umgehen können, heisst das ja noch lange nicht, dass ich sie nicht verwenden darf. Es kommt immer auf den User an und diese werden meisst durch MS falsch erzogen (Stichwort: Word Art, was ja aus irgendeinem Grund auch verwendet wird).

Bandbreite
--- das ich nicht lache. Wir leben in einer Welt mit Bandbreite im Überschuss. Wen interessiert es schon ob 1 oder 10 kb übertragen werden? Hatte ich vorweggenommen das Argument, weil es seit Ende der 90er veraltet ist...

Ich finde Firlefanz in Mails ebenso überflüssig, aber die Möglichkeit mal was fett zu machen oder eben einen Link einzubauen sehr sinnvoll. Gerade weil man heutzutage ne Million Mails pro Tag bekommt. Wenn die Leute nur zu doof dafür sind solche Stilmittel adequat einzusetzen ist das in erster Linie ein eMail-"Kultur"-Problem. Davon gibt es ja bereits jetzt genug (kein [aussagekräftiges] Betreff verwenden, Witz-Werbe-Mitleids-Mails etc...).

Das ist ein Problem über das man mal schreiben könnte. Aber besser in der (Computer-)Bild...

Blubbblubblubb

Von: ghme | Datum: 08.09.2006 | #58
"werden irgendwo immer falsch dargestellt"
Yo, vor allem eingefügte Links, nicht?

"Email = Text, maximal attachment, Firlefanz: überflüssig"
Das ist die Strategie, die die Welt voran treibt...

"Sind beim Reply einfach nur noch kaputter Scheiss"
Kann man auch nicht entfernen...

"HTML-Mails öffnen Scheunentore für automatische Exploits (Würmer/Viren) mittels buffer-overflow manipulierten Inhalten"
Yo, damit schlägt sich der MacUser ja jeden Tag rum. Btw. die von Dir erlaubten Attachments sind wesentlich gefährlicher, daher wenn schon denn schon: auch keine Attachments

"HTML-Mails sind unmöglich um sie per Kommandozeile zu lesen"
Oh mein Gott! Das Problem #1 dieser Welt.

"HTML-Mails sind extrem stressig im Webmailer zu lesen (Dereferrer-Scheiss!)"
Oh mein Gott! Das Problem #2 dieser Welt.

@Malte

Von: njyo | Datum: 08.09.2006 | #59
* Weil HTML Mails unsachlich sind. Weil damit jeder wieder anfängt clicki-bunti Mails zu schreiben, die mehr aussehen wie MSN Nachrichten, als sinnvolle Kommunikation. Ich habe zur Zeit schon genügend Probleme Kontakt mit meiner Bank, Versicherung, etc. via Mail zu erhalten. Wenn jeder anfängt Mails wie die von der WWDC06 an solche Leute zu senden, dann nimmt niemand mehr meine Mails an.
* Weil HTML Mails eine Bedrohung der Sicherheit sind. Da es ja sogar für Apples WebKit ein Image-of-Death gab, welches sehr leicht in ein HTML Mail eingefügt werden kann. Nur eines der Beispiele.
* Weil mehr Bandbreite verschwendet wird.
* Weil Webmail Clients nicht immer HTML mails unterstützen.

Schöne Grüße,
_W

@Kai:

Von: njyo | Datum: 08.09.2006 | #60
Willkommen zurück!

Scheinbar haben die Leute auf der RedKon erkannt, dass Kai's Evil Twin (Abe, ein Applehasser) seinen Bruder beim gemeinsamen WWDC'05 schauen überwältigt und in eine Schrank gesperrt hatta. Nur die misstrauischen Redaktionskollegen konnten wohl den Unterschied erkennen und haben unseren Kai befreit. ;)
Wunderbar zu sehen, dass Du in alter Stärke und Objektivität zurück bist. Ich freue mich.

Schöne Grüße,
_W

HTML-Mails sind die Krätze...

Von: Kai (MacGuardians) | Datum: 08.09.2006 | #61
..und das sag ich als Klickibunti-Fan!

- werden irgendwo immer falsch dargestellt
- Email = Text, maximal attachment, Firlefanz: überflüssig
- Sind beim Reply einfach nur noch kaputter Scheiss
- Email = Text, maximal attachment, Firlefanz: überflüssig
- HTML-Mails öffnen Scheunentore für automatische Exploits (Würmer/Viren) mittels buffer-overflow manipulierten Inhalten
- Email = Text, maximal attachment, Firlefanz: überflüssig
- HTML-Mails sind unmöglich um sie per Kommandozeile zu lesen
- Email = Text, maximal attachment, Firlefanz: überflüssig
- HTML-Mails sind extrem stressig im Webmailer zu lesen (Dereferrer-Scheiss!)

..hab ich schon erwähnt, dass Tschingderassabumm-Firlefanz in Mails so überflüssig ist wie Rotz? ;-) Eine Email ist INFORMATION und kein Multimedia-Spektakel!

Aus all diesen Gründen sind HTML-Mails allgemein so verhasst und auf nahezu jeder Mailingliste werden HTML-Mailende -zu recht- erstmal gebeten, den Scheiss abzustellen!

Apple kann seine Mail-Templates in Leopard gerne behalten.... Die blödeste Klickibunti-Firlefanz-Idee seit langem!

Million-Dollar-Problem

Von: ghme | Datum: 08.09.2006 | #62
"Apple bietet im iTMS die Funktion "iTunes Music Store URL kopieren" im Kontextmenü an, unter anderem damit man Freunden und Verwandten direkte Links auf empfehlenswerte Lieder schicken kann."

Apple bietet im iTMS die Funktion "Freunden empfehlen" ohne Kontextmenü an, unter anderem damit man Freunden und Verwandten direkte Links auf empfehlenswerte Lieder schicken kann. Damit wird aber leider das ganze Problem obsolet, daher darf diese Funktion nicht angewendet werden. Auch weil dann Teufelswerk HTML Mails verschickt werden.

@ Malte

Von: ghme | Datum: 08.09.2006 | #63
Aus welchen Grund bitte sollte man denn keine HTML-Mails versenden?

Weil sonst dieses Problem nicht existieren würde. Ausserdem vermutet man, dass die stärkste Kaufkraft beim iTMS von Leuten kommt, die Mutt, Pine oder Emacs verwenden.

Anmerkung:

Von: Kai (MacGuardians) | Datum: 08.09.2006 | #64
Da alles mit delsp/flowed sowie dem Umbruch von URLs laut Standard _optional_ ist, zwingt kein Standard Apple es auf diese Weise umzusetzen, das ist ihre ureigene Entscheidung. Sie könnten auch weiterhin innerhalb des Standards bleiben wenn sie es nur unterlassen würden, URLs umzubrechen (was explizit im Standard vorgesehen ist!)..
MaW: Apple nutzt einen Internet-Standard, der nicht verpflichtend ist. Den anderen Herstellern kann also eigentlich kein Vorwurf bezüglich Standards-Untreue gemacht werden, wenn sie diesen nicht unterstützen...

Was Standards bringen, die nur optional sind? Nunja, das sollte man am besten die IETF fragen! ;-)

Problem?

Von: Malte | Datum: 08.09.2006 | #65
Also wirklich,
ich seh auch kein echtes Problem und die Überschrift hat Bild-Zeitungs Niveau. Die Argumentation hinkt genauso wie diejenige der Musikindustrie, wenn diese behauptet sie würde zig Milliarden an realen Einnahmen durch Raubkopien verlieren...

Ich seh auch kein echten Handlungsbedarf bei Apple. Einfach HTML-Mail verwenden. Alle Leute der Mail-Clients diese nicht unterstützen leben hinterm Mond. Aus welchen Grund bitte sollte man denn keine HTML-Mails versenden? Datenaufkommen oder einfach nur verbortes beharren auf veralteten Technolgien? Kommandozeilen Clients dürften ja zur Minderheit gehören. IN diesem Fall bleiben 99.99 restliche User die diese Mails ohne Probleme lesen können. Die anderen benutzen vermutlich eh Unix/Linux und da ist es ja eh schwierig mit iTunes.

Wo war noch das Problem? Vor lauter wirrer Theorien hab ich den Überblick verloren (wie kann man über so ein Pseudo Problem ein solch langen Text schreiben?)

Und wie kommt es eigentlich das diese URL-Sachen nur bei den MG ein Problem zu sein scheint?

Puh...

Von: ghme | Datum: 08.09.2006 | #66
Line-Break Problem : nunja
Also bei mir trat dieses Problem geschätzte NULL mal auf (siehe 3c und "Hyperlink hinzufügen", aber das ist ja scheinbar wieder einmal nicht geekig genug). Wäre mal interessant, ob einer hier dieses Problem wirklich mal hatte...

Millionen-Dollar-Verluste : aua
Auf sowas kommt definitiv nur Kai.

Kai:

Von: Markus | Datum: 08.09.2006 | #67
aah - es geht darum, dass mutmasslich der am haeufigsten *weltweit* eingesetzte Email-Client Outlook ist, und sich scheins damit vorrangig dieser Nutzerpopulation das beschriebene Problem stellt *?! … here goes the Apple experience… =8)*

Zumindest was die Entwickler von Opensource-Projekten angeht *sei es nun Mailer oder Clients* , ist das kontaktieren mutmasslich sinnvoll und, bei entsprechender Argumentation meiner Erfahrung nach, ziemlich sicher von Erfolg- die *lies: Evolution, Squirellmail & Co.* kennen das Problem wahrscheinlich schlicht nicht, und es ist ja nun ziemlich simpel zu korregieren (was im uebrigen fuer jeden Entwickler gleichermassen *un*aufwendig, und keinesfalls fuer einen Bestimmten "einfacher" waere.). Wenn also mein Lieblingsmailclient damit ein Problem haette, wuerde ich die entsprechenden Entwickler auf jeden Fall kontaktieren. *was Outlook angeht koennen die Illuminati-Begeisterten, die hier mitlesen, ja mal im stillen Kaemmerlein darueber sinnieren warum ein MS-Produkt scheins den Kommerz via Itunes-Musicstore erschwert? =B) *

Ansonsten lohnt es sich vielleicht seitens der Betroffenen zwecks Evaluierung *er meint: "ja mei, wieviele "kollateral" Geschaedigte sind wir denn eigentlich?"* und spaeterer Uebermittlung an die Entwickler mal einfach eine entsprechende Petitionsseite aufzusetzen *?* Wobei meinereiner denkt, dass Apple, ob der vorhandenen Standardkonformitaet, hier gar nicht kontaktiert werden muss.

urlx ist viel cooler als das doofe tinyurl

Von: woz | Datum: 08.09.2006 | #68
urlx ist viel cooler als das doofe tinyurl

unimac:

Von: Kai (MacGuardians) | Datum: 08.09.2006 | #69
Ja, das mit dem Javascript-Link wollte ich eigentlich noch einbauen.. Einfach Den Link hier in die Lesezeichenleiste des Browsers ziehen und auf ner beliebigen URL drauf klicken um die kurz zu machen.

woz:
Was hat "Media to entertain" mit nem URL-Kurzmacher zu tun?

shorturl.com fällt mir noch ein, aber die schenken sich wenig im Vergleich zu tinyurl...

Schizophren?

Von: iBrain | Datum: 08.09.2006 | #70
An welcher Stelle genau verhält sich Apple nun nicht standardkonform?

Warum ist das ein Problem von Apple Mail?

Weil das Mailprogramm von Apple ist?

Ich frage mich ja sowieso,

Von: Kommentar | Datum: 08.09.2006 | #71
wieviel Geld generell durch fehlerhafte Software und schlechte Usability verloren geht. Und warum das die Manager nicht interessiert.

Und am meisten wundere ich mich darüber,

Von: Kommentar | Datum: 08.09.2006 | #72
das die landläufige Meinung der Kunden ist: "das ist so, da kann man nix machen, Software wird immer einen bestimmte Prozentsatz an Fehlern haben". Ja hallo, aber die gleichen Leute regen sich bei jedem noch so kleinen Hardwareproblem theatralisch auf.

Wenn die Softwareindustrie in den letzten Jahrzehnte was gut hinbekommen hat, dann diese unvergleichliche Konditionierung des »mündigen« Kunden.

Vielleicht sollten wir mal nach 30 Jahren Software-Basteleien die gesetzliche Gewähleistungspflicht auf für Software einführen?!

Geburtstag

Von: Tom | Datum: 08.09.2006 | #73
Hi Kai!

Wann hast Du denn Geburtstag? ;)

Geburtstag

Von: Tom | Datum: 08.09.2006 | #74
Hi Kai!

Wann hast Du denn Geburtstag? ;)

iBrain:

Von: Kai (MacGuardians) | Datum: 08.09.2006 | #75
"An welcher Stelle genau verhält sich Apple nun nicht standardkonform?"

An welcher Stelle im Artikel steht, dass sie dies nicht tun? Ich find da nur Sätze wie "Zumindest halten sie sich dabei an Internet-Standards."

"Warum ist das ein Problem von Apple Mail?"

Aus demselben Grund, warum Safari auch IE-spezifischen HTML-Code, warum OS X auch SMB unterstützt und warum Keynote auch in PDF und PPT exportieren kann, warum iTunes auch mp3 kann und warum iPhoto mit JPGs arbeitet: Wer ein Programm macht, das zum Rest der Welt inkompatibel ist, bürdet seinen Usern Probleme auf, die nicht sein müssten. Wie sich diese lösen lassen und Apple trotzdem standardkompatibel bleiben kann steht übrigens im Artikel. Solltest du echt mal lesen! ;-)

Tom:

Von: Kai (MacGuardians) | Datum: 08.09.2006 | #76
Warum? Willst du mir einen Intelmac schicken oder doch ne Briefbombe? ;-)

Ich empfehle

Von: Chrissie | Datum: 08.09.2006 | #77
den mutt-email-client
[Link]

"All mail clients suck. This one just sucks less."

Zusammen mit dem leistungsfähigen vim-Text-Editor gehören derartige Probleme der Vergangenheit an, mann kann sich auf's mailen konzentrieren.

?!?? funktioniert doch … (mit Apple Mail 2.1 (752/752.2))

Von: Markus | Datum: 08.09.2006 | #78
gentle persons,

mutmasslich mache/verstehe ich ja etwas falsch - also via Kontextmenue in iTunes die URL kopiert, als "plain text" versendet, mit Apple's Mail 2.1 (752/752.2) empfangen - voilá! *wem's gefaellt auch gerne "BOOM" =8)* funktioniert - ein einfach anzuklickender Link - nicht die Spur eines Problemes.

Falls es natuerlich darum geht, das 98% der NICHT-Apple Mailprogramme damit nicht zurecht kommen (das Textzitat: "Der normale Nicht-Apple-Mail-Anwender (und das sind ca. 98%)…" laesst ja, gelinde gesagt, weiten Interpretationsspielraum bezueglich dessen, was der Author vermutlich sagen will…), wird es Zeit die entsprechenden Entwickler zu kontaktieren, oder?

Markus:

Von: Kai (MacGuardians) | Datum: 08.09.2006 | #79
"wird es Zeit die entsprechenden Entwickler zu kontaktieren, oder?"

Na dann mach mal! ;-) Viel Spass dabei M$ zu überreden, in Outlook auf delsp/flowed zu setzen!... Wäre das erste mal, dass M$ Rückwärtskompatibilität zugunsten von Standards aufgibt!
Bei Apple ist der Aufwand auch deutlich geringer, denn die müssen nur nen Sonderfall beim Umbruch für URLs einbauen und nicht das gesamte Umbruchsverhalten ändern wie M$ bei Outlook!

Übrigens: Wenn du dir die Mail über ne Mailingliste (wie etwa Mailman) schickst, ist sie auch in Apple Mail kaputt! 8)

Meine Lösung: Microsoft Entourage!

Von: uniMac | Datum: 08.09.2006 | #80
Seit ich vor drei jahren gewechselt habe weil Apple Mail mir vier Mal alle Mails verloren hat bei einer "Disk full"-Situation. Hab ich mit Apple Mail kurzen Prozeß gemacht!

Seitdem bin ich happy das ich das gemacht habe!

Aber klar, das Problem kann ich nachvollziehen. Taucht bei Entourage übrigens nicht auf! Dafür hat Entourage 'ne andere Macke: Bei "Replys" wird in der deutschen Version *entgegen der Standards* ein "AW: " vor das Betreff gestellt. Das ist gegen den Standard der "Re: " definiert. Es gibt aber Hacks um das zu beheben.

Ansonsten, kann ich generell zu TinyURL raten, da kann man sich einen "JavaScript-Link" in die Bookmarkleiste tun und jede URL direkt in eine TinyURL wandeln. Beste Lösung, weil man nie weiss welcher Mail-Client gerade auf der Empfängerseite zum Einsatz gelant.

just my 2 cents.

Ich hätte da gerne mal ein Problem ...

Von: kleine Made | Datum: 08.09.2006 | #81
Hallo Kai,

Glückwunsch zum gelungenem Einstand. Seit langer Zeit mal wieder ein nüchterner Artikel, in dem du den potentiellen Benutzer eines Sony-Akkus nicht mit bin Ladens Leuten auf eine Stufe stellst (auch wenn du das so nicht gesagt hast). Was ich aber nicht ganz verstehe, wieso schreibt Chrissie "auf's"? Das ist doch im falschen Deutsch! Und wieso schickst du Mails mit URLs an Mailman-verwaltete Mailinglisten - es weiß doch jeder, dass die auf der anderen Seite unklickbar rauskommen. Da müßte Apple echt mal nachbessern ...