Ersatztext für Newsletter ohne HTML

[Ingo]

Hallo

Ich versende einmal in der Woche einen E-Mail Newsletter. Ich nutze dafür einen Dienst. Meine Newsletter E-Mail sind in HTML gestaltet.

Nun gibt es ja User, die keine HTML-E-Mail möchten und Ihre E-Mail-Programme so eingestellt haben, dass alle E-Mails nur mit dem Text-Teil dargestellt werden.

Bei dem von mir verwendeten Dienst, sind diese Text-Teile meiner Newsletter E-Mails aber ganz furchtbar formatiert. Und da habe ich zur zeit auch keinen gescheiten Einfluss drauf.

Darum habe ich mir gedacht, dass ich in den Text-Teil der E-Mail einfach einen netten Hinweis mache, dass man sich die Mails auch über den Browser angucken kann. Dafür bietet der Dienst eine Funktion und einen Link an.

Nun wollte ich Euch mal fragen, was Ihr von dem folgenden Text haltet. Ist der gut und leicht verständlich auch für Internet-Anfänger?

Hallo und guten Tag. Ihr E-Mail-Programm zeigt leider keine HTML-E-Mails (mit Bildern, Farben usw.) an. Darum kann unser Newsletter in Ihrem E-Mail-Programm nicht korrekt angezeigt werden. Sie können unseren Newsletter aber auch einfach über Ihren Internet-Browser betrachten. Klicken Sie dazu bitte einfach auf den folgenden Link … [link]

Gruß Ingo

[Rolf B]

Hallo Ingo,

der Text scheint mir in Ordnung - ich bin aber eigentlich zu technikaffin, um zu wissen, ob er den OmA-Test wirklich besteht.

Viele Mail-Clients sind stark eingeschränkt, was HTML E-Mails angeht; sie unterstützen kein modernes CSS und zwingen Dich zu inline-styles und table layout.

Urgh? Ja.

Der gröbste Klops ist Outlook. Microsoft hatte einmal den Internet Explorer als HTML Rendering Engine drin, und das haben sie ersetzt. Du freust Dich? Nein, kein Anlass. Sie verwenden (trommelwirbel) WORD. Katschrrrrrr - uff. Und das tun sie auch in den neuesten Outlook-Versionen noch.

Ich habe keine anständige neutrale Quelle für Grundregeln für HTML EMail, bestimmt gibt's hier andere, die etwas haben. Aber was ich gefunden habe, ist:

• schreib dein HTML so, dass man den Newsletter immer noch als solchen erkennt (man muss nur das Geraffel in spitzen Klammern überlesen)
• sei sparsam mit CSS und verwende inline styles
• verwende Table Layout und sei großzügig mit width-Angaben für die Zellen
• verlass dich nicht auf Bilder, viele (die meisten?) HTML Mailclients unterdrücken sie zunächst. Die Twitter-Lösung, einfach alles in ein Bild zu packen und nur das Bild zu tweeten, verbietet sich für Mails.

Den User auf eine Webseite zu locken, um die HTML Ansicht dort zu erhalten, ist zwiespältig. Wenn ich den Newsletter-Absender kenne und ihm vertraue, hm, gut, dann würde ich das tun. Andernfalls würde mein Finger sofort zum Entf Knopf auf meiner Tastatur zucken. Denn eine Mail, die mich auf eine Webseite holen will? Sehr verdächtig, was will sie mir unterjubeln, welches böse JavaScript will meinen PC berauben, wer will da meine Mailadresse auf Existenz prüfen? Phishy, phishy…

Besser ist es, wenn Du deine HTML Mails so gestaltest, dass sie auch in einem Text-Only Browser lesbar sind.

Du könntest zum Beispiel eine Text-only Version der HTML Version vorschalten und in <!-- --> einklammern. Ein HTML Mailer sollte diesen Teil als Kommentar ansehen und unterdrücken (es sei denn, ich traue diesen Burschen gerade zu viel zu).

Leider bin ich nicht hinreichend erfahren in HTML Mails, um dazu kompetent einen Aufsatz zu schreiben; aber das wäre ein guter Blog-Beitrag für Selfhtml.

Rolf

[Matthias Scharwies]

Servus!

Ich habe keine anständige neutrale Quelle für Grundregeln für HTML EMail, bestimmt gibt's hier andere, die etwas haben. Aber was ich gefunden habe, ist:

• sei sparsam mit CSS und verwende inline styles
• verwende Table Layout und sei großzügig mit width-Angaben für die Zellen
• verlass dich nicht auf Bilder, auch HTML Mailclients unterdrücken die zunächst.

Leider bin ich nicht hinreichend erfahren in HTML Mails, um dazu kompetent einen Aufsatz zu schreiben; aber das wäre ein guter Blog-Beitrag für Selfhtml.

Ein Ausgangspunkt wäre:

• HTML/Tutorials/responsive_Newsletter, (was man bestimmt überarbeiten müsste)

Herzliche Grüße

Matthias Scharwies

[Rolf B]

Hallo Matthias,

tja, das hatten wir gestern abend indirekt schon. Wenn man ja wüsste, was alles im Wiki steht. Da ist ein lebendiger Index schon recht hilfreich 😂

Rolf

[Der Martin]

Hallo,

Den User auf eine Webseite zu locken, um die HTML Ansicht dort zu erhalten, ist zwiespältig.

ja, aber durchaus üblich. Nicht nur beim Newsletter-Versand; ich sehe das regelmäßig auch bei Dienstleistern wie meinem Internet-Provider oder meinem Stromanbieter, wenn sie mir was mitzuteilen haben.

Wenn ich den Newsletter-Absender kenne und ihm vertraue, hm, gut, dann würde ich das tun. Andernfalls würde mein Finger sofort zum Entf Knopf auf meiner Tastatur zucken.

Naja, mal ehrlich: Entweder ich habe den Newletter aus gutem Grund abonniert, dann impliziert das für mich auch, dass ich dem Absender vertraue und ihn für seriös halte. Wenn nicht, würde ich auch keinen Newsletter bestellen.
Kenne ich den Absender jedoch nicht, oder habe ich den Newsletter nicht ausdrücklich angefordert, gilt die Nachricht sowieso sofort als SPAM und ist "in no time" gelöscht.

Denn eine Mail, die mich auf eine Webseite holen will? Sehr verdächtig, was will sie mir unterjubeln, welches böse JavaScript will meinen PC berauben, wer will da meine Mailadresse auf Existenz prüfen? Phishy, phishy…

Zum Beispiel sowas.

Besser ist es, wenn Du deine HTML Mails so gestaltest, dass sie auch in einem Text-Only Browser lesbar sind.

Noch besser, wenn man sie als multipart/alternative erzeugt, wie sich das gehört, und eine Variante in text/plain mitschickt. Aber das ist im Fall von Ingos Newsletter-Versender ja wohl suboptimal gelöst.

Du könntest zum Beispiel eine Text-only Version der HTML Version vorschalten und in <!-- --> einklammern. Ein HTML Mailer sollte diesen Teil als Kommentar ansehen und unterdrücken (es sei denn, ich traue diesen Burschen gerade zu viel zu).

Auch eine schicke Idee!

Live long and pros healthy,
 Martin

[Rolf B]

Hallo Der,

Noch besser, wenn man sie als multipart/alternative erzeugt, wie sich das gehört, und eine Variante in text/plain mitschickt.

Siehste, ich hab keine Ahnung an dieser Ecke. Ist das state-of-the-art und wird von den Mailern verstanden?

Rolf

[Der Martin]

Hi,

Noch besser, wenn man sie als multipart/alternative erzeugt, wie sich das gehört, und eine Variante in text/plain mitschickt.

Siehste, ich hab keine Ahnung an dieser Ecke. Ist das state-of-the-art

mehr oder weniger. Das konnte schon Outlook Express vor 20 Jahren.

und wird von den Mailern verstanden?

Ja. Ein Mailclient, der HTML anzeigen kann (und darf), pickt sich den HTML-Teil raus und ignoriert den Plaintext-Teil; andernfalls wird der Plaintext-Teil angezeigt und das HTML ignoriert.

Ob das auch "alle" Webmailer so umsetzen, weiß ich nicht - ich tendiere aber zum Ja.

Live long and pros healthy,
 Martin

[Auge]

Hallo

und wird von den Mailern verstanden?

Ja. Ein Mailclient, der HTML anzeigen kann (und darf), pickt sich den HTML-Teil raus und ignoriert den Plaintext-Teil; andernfalls wird der Plaintext-Teil angezeigt und das HTML ignoriert.

… und das schon seit „quasi immer“.

Da hier bisher ^[1] immer von Outllok geschrieben wird, möchte ich mal die Situation in einem anderen Client darstellen. Der Thunderbird gibt, wenn ihm die Ausgabe von HTML verboten wurde, den Nur-Text-Teil einer Multipart-E-Mail aus, so er vorhanden ist. Gibt es keinen Nur-Text-Teil, wird aus dem HTML der Inhalt entnommen. Ist das im HTML Fließtext mit Absätzen, sieht die Ausgabe einem Nur-Text-Teil ähnlich, wird im HTML viel mit (tief) verschachtelten Elementen und Tabellen gearbeitet, kommt da gerne ein unübersichtlicher Textklops raus.

Ob das auch "alle" Webmailer so umsetzen, weiß ich nicht - ich tendiere aber zum Ja.

Ich würde eher davon ausgehen, dass das in den meisten Webmailern nicht einstellbar ist. Wozu auch? Der Webmailer erstellt seine Programmoberfläche mit HTML, warum also die E-Mail selbst, die in dieser Programmoberfläche dargestellt wird, nicht in HTML rendern, wenn sie denn mit HTML angeliefert wurde? Ich vermute, dass auch Nur-Text-E-Mails im Webmailer als HTML gerendert wird.

Tschö, Auge

---

1. soweit ich gelesen habe ↩︎

[MudGuard]

Hi,

Ich würde eher davon ausgehen, dass das in den meisten Webmailern nicht einstellbar ist. Wozu auch? Der Webmailer erstellt seine Programmoberfläche mit HTML, warum also die E-Mail selbst, die in dieser Programmoberfläche dargestellt wird, nicht in HTML rendern, wenn sie denn mit HTML angeliefert wurde?

Gerade weil es HTML in HTML ist. Da kann z.B: ein </div> zuviel oder zu wenig in der Mail die Darstellung der äußeren Seite leicht mal zerlegen.

cu,
Andreas a/k/a MudGuard

[Ingo]

Hallo Martin

Noch besser, wenn man sie als multipart/alternative erzeugt, wie sich das gehört, und eine Variante in text/plain mitschickt. Aber das ist im Fall von Ingos Newsletter-Versender ja wohl suboptimal gelöst.

Ja ganz genau das ist das Problem. Die Variante halte ich natürlich auch für die beste. Aber bei meinem Dienstleister stricken die da gerade herum. Und aktuell sind die text/plain teile einer multipart-Mail ganz furchtbar. Im Grunde kann ich dort nur einen Text ohne Zeilenumbrüche und Leerzeilen verwenden. Alles andere schaut dann im Text-teil der Mail nach dem Versand grauenhaft aus.

In der Hoffnung, dass die das bald beheben, hatte ich mir eben den Text mit dem Link zur Web-Version ausgedacht.

Gruß Ingo

[Gunnar Bittersmann]

@@Rolf B

Ich habe keine anständige neutrale Quelle für Grundregeln für HTML EMail, bestimmt gibt's hier andere, die etwas haben.

Smashing Conference bietet in Kürze einen Workshop „Building Modern HTML Emails“ an.

😷 LLAP

[Matthias Scharwies]

Servus!

@@Rolf B

Ich habe keine anständige neutrale Quelle für Grundregeln für HTML EMail, bestimmt gibt's hier andere, die etwas haben.

Smashing Conference bietet in Kürze einen Workshop „Building Modern HTML Emails“ an.

Danke!

Herzliche Grüße

Matthias Scharwies