E-Mail Like a Pro - Anleitung von toscom

Der E-Mail-Versand ist längst nicht mehr einfach. SMTP ist ein sehr altes Protokoll und als es entwickelt wurde, hat sich keiner Gedanken um Security gemacht. Damit eine E-Mail von einem Server zum anderen kommt, muss heutzutage vieles beachtet werden. Spamfilter verlangen immer mehr damit E-Mails so halbwegs durchgehen - geschweige denn nicht in Junkmail landen.

Angeblich setzen sich in Amerika und Europa zurzeit neue Standards durch, was bedeutet, dass künftig noch mehr beachten werden muss.

Hier eine Liste was heute so verlangt wird:

MX-Record

(Mail Exchange Resource Record oder auch MX-RR)

Der MX-Record ist eigentlich nur dazu da, dass eine E-Mail ihren Weg zum Mailserver findet. Er sagt aus, unter welchem Domainnamen der Mailserver zur Domäne oder Subdomäne erreichbar ist.

Wird eine E-Mail versendet, sucht der Ausgangs-Mailserver zunächst den MX-Record der Domain ab. Im besten Fall existiert mindestens ein MX-Record zu jeder Domain. Hast du eine Domain "beispiel.at", dann suchen Mailserver den MX-Record für beispiel.at ab. Damit wissen alle Mailserver wo sie E-Mails an @beispiel.at hinschicken können. Es gibt vereinzelt Spamfilter die E-Mails bevorzugen, wenn die IP-Adresse bei einem MX-Record von der jeweiligen Domain stammt. Das ist zwar nicht Standard und auch nicht RFC-konform, aber dennoch immer wieder üblich.

PTR-Record

(Pointer Resource Records)

Ein PTR-Record ist ein Reverse Record mit dem man eine IP-Adresse in einen Full-Qualified-Domain-Name (FQDN) umwandeln kann. PTR-Records können nicht vom Domaininhabern eigenständig verwaltet werden, sondern müssen stattdessen vom jeweiligen Provider der die IP-Adresse administriert gesetzt werden. Bei Hetzner ist das Hetzner, bei UPC eben UPC usw.

Fast jeder Spamfilter (auch wenn er noch so schlecht ist) verlangt einen PTR-Record. Das bedeutet, die IP-Adresse, welche von einer E-Mail zu einem Spamfilter geschickt wird, muss Reverse auflösbar sein. Den meisten Spamfiltern ist es dabei aber egal was als Record genommen wird - "name.domain.tld" oder "wasauchimmer.domain.tld".

Allerdings sollte darauf geachtet werden, dass der Record möglichst keine dynamischen Inhalte aufweist wie bei "blah.dynamic.domain.tld". Denn das kann wiederum zu Problemen mit Spamfiltern führen, obwohl es eigentlich kein Standard ist und egal sein sollte.

Manche Spamfilter gehen sogar so weit, dass sie versuchen den FQDN, den sie vom PTR-Record bekommen, aufzulösen und schauen ob dieser wirklich mit der IP-Adresse übereinstimmt, die aufgelöst wurde. Auch das ist nicht RFC-konform, aber manche Spamfilter sind sehr strikt.

SPF-Record

(Sender Policy Framework Resource Record)

Der SPF-Record soll Spamfiltern helfen die Herkunft der E-Mails zu bestimmen. Die Idee ist folgende: Es wird in der Domain beispiel.at ein SPF-Record eingetragen, der festlegt welche IP-Adressen E-Mails mit dem Absender@beispiel.at versenden dürfen. Spamfilter können den SPF-Record prüfen und dann dementsprechend handeln. Es kann zwar im SPF-Record definiert werden, wie Spamfilter "reagieren" sollen, wenn E-Mails von anderen als im Record festgelegten IP‘s hereinkommen, allerdings halten sich nicht alle Spamfilter daran.

Typische Fehlermeldung bei E-Mail-Notifications von Webservern oder bei Newsletter: Die IP vom Sender ist nicht im SPF-Record und die Emails werden geblockt.

Zur Veranschaulichung der SPF-Record von beispiel.at aufgelöst:

host -t txt beispiel.at
beispiel.at descriptive text "v=spf1 mx -all"

Der Record sagt: "NUR der MX-Record darf Emails mit @beispiel.at versenden. Alle anderen IP-Adressen, die nicht eingetragen sind und im Namen von beispiel.at Emails versenden wollen, werden nicht akzeptiert."

DKIM

(DomainKeys)

Man könnte meinen, dass der SPF-Record "eh schon ganz toll ist" und das Fälschen von Absendern unmöglich macht. Das ist aber nicht der Fall. Spammer verpacken ihren Inhalt jetzt einfach in einen SMTP-"Envelope"-Header und außen kommt ein anderer Absender von einer anderen Domain drauf. Und somit ist der SPF überwunden. Deswegen wurde DKIM eingerichtet.

DomainKeys dienen zur Authentifizierung von Absender E-Mail-Adressen. Es wird der Header der E-Mail verschlüsselt und der Fingerprint beigelegt. Im DNS der Domain wird mittels DKIM-Record der öffentlichen Schlüssel hinterlegt. Mit dem Schlüssel können Spamfilter einen Gegencheck durchführen und kontrollieren, ob die mit DKIM-signierte E-Mail auch wirklich vom Absender mit dem zugehörigen privaten Schlüssel stammt.

Hier hab ich einen DKIM aufgelöst:

host -t txt default._domainkey.beispiel.at
default._domainkey.beispiel.at descriptive text "k=rsa; t=s;
p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDBWHqatJfzi3bA+r3f4nDg2+9GZN1k8HhzwLk1hwyru5gI1Gp5RiCzQFg2MqyuuZuaqQzd4yq7d7XQ7LK0qbz764sm
DDPhNOsWsfOvAAWy08P8PcOW+aYz3VcnXNsCR/6H/ytZJim3pAdRojRX/KzCWS6ecjdZs7diCKWa6nZpTQIDAQAB"

Ein typischer Fehler ist, dass Newsletter oder E-Mail Notifications nicht mit DKIM signiert werden und deswegen von Spamfiltern als "Falsch" angesehen werden.

DMARC

(Domain-based Message Authentication, Reporting and Conformance)

DKIM und SPF zusammen sind die superbesten Freunde und gemeinsam nennt man diese Bande "DMARC".

Wenn beide Records eingerichtet sind, kann schon sehr gut sichergestellt werden, dass nur Server die auch darin festgelegt sind E-Mails von einer Domain verschicken können. Aber als Admin möchte man vielleicht auch wissen, was sich rund um seine Domain abspielt. Während mit SPF und DKIM beschrieben wird, wer eine Mail versenden darf und ob sie unverändert vom Absender stammt, kann mit einem sogenannten DMARC-Record festlegt werden, wie der Empfänger-Server "reagieren" soll.

Unter anderem kann beispielsweise folgendes definiert werden: "Generiert einen täglichen Bericht und schickt den an postmaster@beispiel.at". Dann bekommt man von Google einmal am Tag einen Bericht darüber, wer E-Mails von meiner Domain geschickt hat und ob er dazu berechtigt war - also DKIM und SPF erfüllt hat.

Return-Path

Viele E-Mails werden von Servern generiert und haben deshalb im Return-Path-Header eine E-Mail-Adresse eingetragen die nicht existiert. Damit werden Bounces ins Nirvana geschickt.

E-Mails mit einem invaliden Return-Path sind eine "Unart", die es zu vermeiden gilt. Ein Beispiel wie ich es fast täglich sehe ist: E-Mail-Notifications werden als www-data@beispiel.tld versendet. www-data ist aber keine gültige Mailbox.

Das kann zu zwei Problemen führen:

• Wenn der Spamfilter Senderverification durchführt, also überprüft, ob es beim Absendemailserver die Mailbox überhaupt gibt, dann wird die E-Mail abgewiesen, weil der Sender nicht verifiziert werden kann
• Wenn es Probleme gibt, bekommt es niemand mit, weil Fehlermeldungen verworfen werden

Art des Mailversands

Eine spannende Angelegenheit ist auch wie E-Mails verschickt werden, denn auch dabei kann viel falsch gemacht werden.

Angenommen ich habe eine Webapplikation wie einen Webshop, die einem Benutzer eine E-Mail schicken soll, dann wäre es eine schlechte Vorgehensweise den Mailversand der Applikation zu überlassen und die Applikation schickt via SMTP die E-Mail direkt an den Mailserver des Empfängers. Besser und richtig wäre, dass der Versand durch einen Mailserver erfolgt.

Zum einen sind beim E-Mail-Versand durch die Webapplikation vermutlich keine Records für die IP-Adresse des Webservers gesetzt und zum anderen gibt es höchstwahrscheinlich keine Warteschlange. Beim E-Mail-Versand wird aber davon ausgegangen, dass ständig ein temporärer Fehler auftreten kann. Deswegen ist eine Warteschlange unbedingt nötig.

Ein schönes Beispiel ist Greylisting. Manche Mailserver nehmen E-Mails beim ersten Zustellversuch grundsätzlich nicht an. Erst wenn die Zustellung nach einer bestimmten Zeit erneut versucht wird, wird die E-Mail vom Server angenommen. Grund für diese Einstellung ist Spamversuchen entgegenzuwirken, weil wenn es sich um einen seriösen Versand mit Warteschlange durch einen Mailserver handelt, wird eine Zustellung automatisch nochmals probiert. Handelt es sich beim Auftraggeber allerdings um eine Applikation, ist diese Logik nicht hinterlegt und die E-Mail verschwindet einfach.

Gut ist es auch, wenn ein lokales MTA (Mailsystem) des Servers installiert und zum Senden verwendet wird. Dabei wird sichergestellt, dass der Versand über eine Warteschlange geht. Dann gilt es noch einen "echten" Absender zu definieren, sodass Fehlermeldungen auch irgendwo ankommen und die E-Mails durch das Senderverify gehen. Und am Ende achtet man noch darauf, dass alle Records richtig gesetzt sind, sodass die Server-IP des Senders auch wirklich von der Absenderdomäne aus schicken darf.