Stil mit {stil}

Wenn Apple seine hübschen Emails versendet, haben sie leichtes Spiel: Die Mail landet »zuhause« in der Apple Email oder MobileMe und nicht in einem Webmailer wie Google Gmail oder gar Horde-Email.

Die meisten Emailprogramme bieten dem Benutzer nur ein spartanisches Reservoir an Formatierungen, die schon mit roter fetter Schrift enden. Das Versenden grafischer Emails – z.B. als Newsletter, Einladung oder Marketing-Kampagne – muss von speziellen Anwendungen umgesetzt werden.

Irgendwie sind Emails mit einem netten Layout ja verrucht. Wir sehen sie fast nur in Spam-Emails und im einen oder anderen kommerziellen Newsletter. Also werden wir von allen Seiten gewarnt:
Grafische Emails sind Teufelswerk! Haltet Eure Newsletter in reinem Text und krönt sie optisch durch eine Zeile eleganter Gleichheitszeichen.

================================================

Aber seien wir doch mal ehrlich: Zu Weihnachten würden wir doch auch gern schöne Weihnachts-Emails versenden. Da beseitigt das Email-Standard-Projekt die Skrupel: Das Projekt listet auf, in welchem Umfang die Mailprogramme und Webmailer die Web-Standards unterstützen. Das Ende der puritanischen Emails langsam aber sicher in Sicht.

Email-Clients und formatierte Emails

Email-Clients sind keine Browser und ihr Verständnis für HTML-codierte Emails ist beschränkt – wer da glaubt, dass er Ahnung von modernem Webdesign hat, musste sich auf die alten (Un-) Tugenden des Tabellenlayouts der 90iger Jahre besinnen.

Ups … solange es Outlook und Google Gmail gibt, brauchen wir das alte Wissen immer noch.

Zu allem Überfluss gibt es Email-Clients wie Sand am Meer … von Lotus Notes (das wohl aber in Deutschland wenig verbreitet zu sein scheint) über Outlook 2007 bis zu Entourage und Thunderbird … nicht zu vergessen all die web-basierten Mailer wie Google Gmail, Thunderbird oder Apples hübscher Webmailer MobileMe. Die größte Klippe stellt Outlook 2007 dar, das sich auf eine Untermenge von HTML 4.01 und CSS 1 zurück entwickelt hat.

HTML-formatierte Emails versenden

Email-Clients können keine HTML-codierten Emails versenden. Würden wir eine HTML-Seite einfach im Klartext in die Email schreiben, käme nach dem Versenden einfach nur die HTML-Ansicht wieder heraus. Entweder programmieren wir uns einen Formular-Mailer, der die Email als

$headers[] = “Content-Type: text/html; charset=utf-8″;

versenden kann (das erfordert einen Webserver mit PHP & Co.) oder schaffen uns eine Desktop-Anwendung zum Versenden von Newslettern an.
Campain Monitor

Editoren für HTML-Emails

Am besten werden HTML-Emails in einem einfachen Texteditor wie BBedit oder NotePad mit möglichst simplen HTML geschrieben. Das erzeugt den saubersten Code. WYSIWYG-Editoren oder Microsoft Word erzeugen HTML-Code mit unkontrollierbaren Zutaten. Einige Email-Clients bestrafen Emails, die mit Microsoft FrontPage erzeugt wurden – weil Spammer gern diesen Editor benutzen.

Stylesheets für grafische Emails

Für die Formatierung ist Inline-CSS (style=”") die beste Wahl. Ein externes Stylesheet wird zu oft vom Email-Client entfernt – auch ein Style-Tag im Kopf des Dokuments. Webbasierte Mailprogramme wie Horde befürchten, dass ein Stylesheet die eigene Formatierung der Seite gefährdet.
Habe ich Inline-Stile empfohlen? Ältere Webdesigner erinnern sich vielleicht noch an die verstaubten und unerwünschten Attribute wie bgcolor und Co? Sie sind für einige Webmailer die einzige Chance, um eine Hintergrundfarbe in die Email zu kerben. Augen zu und durch: Standards sind überbewertet.

Holt die Layouttabellen aus der Versenkung

Einfache Layouttabellen bieten die sicherste Positionierung. Bei grafischer HTML-Email müssen wir alle Skrupel beiseite schieben und die Layouttabellen wieder aus der Schublade holen. Positionierung über CSS ist viel zu unsicher.
Allerdings sollte auf das Verschachteln von Layouttabellen verzichtet werden. Einige Email-Clients vertragen nicht einmal die Attribute colspan und rowspan.

Testen

Das Layout prüft man am besten im Vorschaufenster verschiedener Email-Clients. Hier ist deutlich weniger Platz als auf einer normalen Webseite, denn die meisten Empfänger lesen ihre Email im Vorschaufenster und kaum ein Benutzer zieht sein Emailfenster bildschirmfüllend auf. Eine Breite von 500 Pixel oder weniger ist angebracht und am besten wird das Layout auf der linke Seite untergebracht: Logos und die wichtigsten Inhalte sollten auf der linken Seite liegen.

Kein JavaScript, ActiveX, Flash, eingebettetes Video, kein Sound, kein DHTMl

Da in derartigen Medien häufig Viren verborgen liegen, werden diese Inhalte von Antivirenprogrammen blockiert.

Bilder für grafische Emails

HTML-Emails werden mit absoluten Pfaden codiert (z.B. zu Bildern auf dem Server): <img src=”http://www.xxx.xx/images/bild.gif” …>
Fancy XHTML kann man sich schenken und den Schrägstrich am Ende vergessen.
Viele Emailprogramme schalten Bilder von Haus aus ab. Der Empfänger muss eine Schaltfläche »Bilder anzeigen« klicken – kaum ein Leser fühlt sich motiviert, diesen Button bei jeder Email zu drücken. Also muss immer auch eine Volltext-Email verfügbar sein.

head und body

Webmail-Programme wie Horde, Yahoo, MSN, Hotmail, Apple-Webmail und Gmail löschen i.d.R. jeden HTML-Code über und unter dem body-Tag und das body-Tag selber ebenfalls, weil ansonsten ein body-Tag innerhalb des eigenen body-Tags existieren würde. Also kann die Emailseite nicht ohne weiteres eine Hintergrundfarbe durch das style-Attribut des body-Tags bekommen. Stattdessen nutzt man am besten eine seitengroße Tabelle mit einer Hintergrundfarbe.

Trotzdem ist es so gut wie ausgeschlossen, dass eine grafische Email mit HTML in allen Email-Clients pixelgenau gleich aussieht. Um es gleich offen zu sagen: Wenn die Email in der Mehrzahl der Email-Clients auch nur nett aussieht, ist das Design schon ein Volltreffer.

Erfolgskontrolle ohne Aussagekraft

Ein kleines transparentes GIF-Bild kann prüfen, wie oft die Email empfangen und gelesen wurde. Jedes Laden des Bildes wird gezählt. Wenn »Bilder anzeigen« im Email-Client nicht aktiviert ist, wird das Bild auch nicht geladen.

Weil das Bildchen-zählen natürlich auch gern von Spammern benutzt wird, kann es schon ein Kriterium für den Abflug in den Spam-Kasten des Empfängers sein.

Doppelter Volltreffer: Alles schön bunt in den Fängen der Spamfilter

Grafische HTML-Email muss in allen auffindbaren Mailprogrammen und gegen möglichst viele Spamfilter getestet werden.
Das ist aber noch nicht alles. Damit eine Serien-Email nicht auf der Blackliste der Empfänger landet, sollte man auf eine ganze Reihe von Ausdrücken und Wörtern verzichten – klar, dass »Superangebot« genauso wie »Sex« und »Viagra« zu den Begriffen gehört, die sich von allein verbieten.

Gut kommt hingegen die persönliche Anrede an. Immer die vollständigen Kontaktdaten in den Fuss der Email setzen: Postadresse, Telefon, Email usw. Am besten setzt man noch einen Unsubscribe (Abbestellen)-Link in die Email, falls es sich um einen Newsletter handelt, der öfters versendet werden soll.

Die Gefahr, mit einer grafischen HTML-Email im Spamfilter hängen zu bleiben, darf nicht unterschätzt werden. Wer HTML-Emails verfasst, sollte sich mit den Kriterien gängiger Spamfilter auseinander setzen.

Content analysis details: (7.1 points, 7.0 required)

pts rule name description
—- ———————- ————————————————–
0.6 NO_REAL_NAME From: does not include a real name
3.4 HELO_DYNAMIC_IPADDR Relay HELO’d using suspicious hostname (IP addr 1)
3.3 HELO_DYNAMIC_HCC Relay HELO’d using suspicious hostname (HCC)
0.0 HTML_MESSAGE BODY: HTML included in message
0.0 MIME_HTML_ONLY BODY: Message only has text/html MIME parts
2.9 HTML_IMAGE_ONLY_04 BODY: HTML: images with 0-400 bytes of words
0.3 HTML_SHORT_LINK_IMG_1 HTML is very short with a linked image
3.6 MIME_BOUND_DD_DIGITS Spam tool pattern in MIME boundary
3.5 MSGID_SPAM_CAPS Spam tool Message-Id: (caps variant)
3.4 SUBJ_ILLEGAL_CHARS Subject: has too many raw illegal characters
3.2 RCVD_HELO_IP_MISMATCH Received: HELO and IP do not match, but should
1.3 RCVD_NUMERIC_HELO Received: contains an IP address used for HELO
0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay lines
0.3 PORN_URL_SEX URI: URL uses words/phrases which indicate porn (sex)

Als Absender-Emailadresse eignet sich die Emailadresse, unter der man bereits mit dem Empfänger korrespondiert hat. Das senkt die Gefahr, sofort in die Spammerliste zu wandern.

Links
How to code Email Newsletters
Email Marketing Software für Designer
Ausführliches Tutorial »Briefpapier mit Outlook erstellen«