Nichts spricht dagegen.
- Bilder, die beim Nachladen über den Empfang informieren Die Option ist bei mir grundsätzlich ausgeschaltet. Ich muss manuell "nachladen".
Von all den Kunden, mit den ich richtig Geld verdiene kommen nur HTML-eMails. Da fange ich doch keinen Flame-War an um die wahre Lehre. :) P. S.

die Betrugsoptionen, imho
- Bilder, die beim Nachladen über den Empfang informieren
- Bilder und Links, die Malware oder Trojaner enthalten _können_
Teilweise, so raffiniert, das schon das bloße Laden bzw. Anschauen ein System infizieren kann gilt nun einmal in besonderer Weise für Windows.
Wenn ich nur plain text zulasse, dann haben diese bösen Buben einige Angriffspunkte weniger (wenn nicht gar keine - bislang habe ich noch nichts von Attacken via plain text gelesen) M. W.

hat überhaupt nichts mit Vorteilen zu tun. Windows-Anwender erwarten HTML-Mails.
Bekomme ich von denen Text-Mails sind das in Courier-gesetzte HTML-Mails. Das ist eine solche ästhetische Entgleisung, der würde ich auch aus dem Weg gehen. Was willst'de erwarten?
There Is Bad Taste and Then There Is This O. Z.

Die Zusammenfassung von B. F.

Anmerkungen

* img src werden nicht geladen
* java/javascript ist ausgeschaltet
=> also nix mit ausspionieren
* (Industrie)-Kunden haben Accounts von max. 5 GB, öffentliche Verwaltungen z.T. wesentlich kleiner
-> aber alle mit HTML-Mails und nutzen das auch
* nicht jeder der eMail lesen kann darf auch ins Internet
* Mails lassen sich als HTML _und_ Plain Text versenden, kann also immer gelesen werden
* Backup/Restore Zeit ... ziemlich an den Haaren herbeigezogen, schwaches Hilfsargument
* PDF kann nicht jeder User öffnen (öffentliche Verwaltungen....)
Aber, im Grunde interessiert mich das alles nicht. Der Kunde will's, der Kunde bekommt's, der Kunde zahlt. P. S.

Senf

Gerade das eben nicht. Die meisten Werbe-Mails (aka "Newsletter"), die ich so bekomme, haben in img src="" externe Links. Da bei mir das Häkchen bei Einstellungen/Darstellung/Nicht lokal gesicherte... fehlt, sehen die ach so wunderbar gestalteten Mails dann immer sehr seltsam und zum Gotterbarmen aus. Das ist selbst bei der Apple Developer Connection so und die Mails sind in dieser Aufmachung eigentlich für die Füße. Geworben wird damit nur für den Mitbewerb.

Ich würde keinen Kunden anraunzen, weil er mir einer HTML-Mail schickt, aber ich selbst schicke ihm keine.
Tatsächlich habe ich eher feststellen können, dass die Kunden etwas zu weitgehende Vorstellungen haben, was man mit HTML-Mails so layouten kann. Es gab mal mit einem Kunden die Diskussion ob Einladungen per eMail nicht genauso "gestaltet" werden könnten, wie die per Schneckenpost. Die bis heute erfolgreich praktizierte Lösung war tatsächlich ein PDF im Anhang. Das konnte sogar eine Museumskuratorin auf anhieb öffnen, welche die Früchte meines Excel-Exportes (xml) nicht genießen konnte, weil ihr Excel zu alt war. Originalton: "was glauben sie denn, wir sind eine öffentliche Einrichtung".

HTML-Mails an Hinz und Kunz haben für mich den Stellenwert von HTML-Seiten "optimiert für Internet Explorer x.y! Sie benutzen nicht den Internet Explorer x.y!!! Laden Sie hier den Internet Explorer x.y herunter!!!!!eins!!!elf!".

Wenn der Kunde seine Hausschrift in der Mail sehen möchte, ist HTML-Mail sofort gegessen - Ok: es gibt auch Firmen mit Ariel als Hausschrift ;-) R. D.

Links die Signaturanzeige einer HTML-eMail in MacOSX Mail und rechts auf dem iPhone. Beide Renderer sind WebKit/KHTML. Unter Windows rendert InterExplorer oder MS Word, je nach Windows-Version.

damit wird ein weiteres Problem von "solchen" Mails gezeigt - keine Kontrolle, wie es beim Empfänger dargestellt wird. M. W.

Rede - Gegenrede

• … es kommt aber nur auf das Gefühl des Absenders an. Der Kunde muss sich wohl fühlen, wenn er sowas verschickt.
• wenn er deine Rechnung kriegt, ist es mit dem Wohlfühlen wohl endgültig vorbei …

Aber …

Das ist ist bekannt, und nicht nur deswegen sind alle IT-Abteilungen gegen HTML-Mails. ALLE. Das hat nichts mit Mac- oder Windows-Usern zu tun. Aber die IT-Abteilungen entscheiden das nicht. Das läuft z. B. in etwa so:

Chef: "Die anderen haben alle schicke Signaturen, wieso können wir das nicht?"
IT-Abteilung: "Könnten wir schon, aber dann müssten wir auf HTML umstellen, das ist Sünde. Außerdem wissen wir nicht, ob die Signatur beim Empfänger wirklich so aussieht, wie wir denken."
Chef: "Welche wirklich zwingenden Argumente sprechen gegen das Versenden von HTML-Mails?"
IT-Abteilung: "Äh, naja, wirklich zwingende..."
Chef: "Können wir mit verschiedenen Mail-Programmen prüfen, wie die Signatur bei verschiedenen Empfängern aussieht?"
IT-Abteilung: "Wir können ziemlich viele testen, z. B. GMX oder Outlook etc., aber wirklich sicher sein kann man nicht."
Chef: "Machen Sie es so. Mit dem Restrisiko können wir leben. Die Kunden sollen nicht denken, dass wir von gestern sind."
J. B.

HTML-eMails aus 4D?

Mit 4D lassen sich ansehnliche HTML-eMails genau so gut erstellen wie WebSeiten.

• PROCESS HTML TAGS ist der Befehl der Wahl
• mir fehlt ein Richtext-Editor der dem 4D-Programmierer die Arbeit erleichtert und den Anwender HTML-eMails mit Freuden erstellen läßt.
• 4D Write ist leider keine Option, oder doch?

Im Juni 2010: Inzwischen erzeuge ich mit 4D Write als Frontend ganz ansehnliche HTML-eMails. Doch bleibt das HTML grauslig. Der Code ist V2004-fähig. Wer ihn haben möchten, ich verkaufe so was :-) → Beschreibung

zum Weiterlesen

Wikipedia • Schilderung der Sinnlosigkeit des Versands von HTML E-Mail • How to Code HTML Email Newsletters • Starter templates for your HTML email campaigns • HTML E-Mail: Text Font Readability Study • Conventions for use of HTML in email …