Web-Formulare und die Crux mit der Spam-Erkennung – wenn E-Mails einfach nicht ankommen

Web-Formulare und die Crux mit der Spam-Erkennung – wenn E-Mails einfach nicht ankommen

Viele Formulare – z.B. Kontaktformulare im Web – funktionieren immer noch so, dass nach Absenden des Formulars die Inhalte der Formularfelder durch ein Skript auf der Website in eine E-Mail gepackt und vom Webserver aus an ein Postfach des Website-Betreibers, z.B. kontakt@beispielfirma.de gesendet werden. Das Skript kann den E-Mail-Absender  – genauer die From-Adresse und die ReplyTo-Adresse – dabei frei eintragen – was liegt da näher, als die vom Website-Besucher eingegebene E-Mail-Adresse, z.B. max.muster@example.com, zu verwenden. Vorteile liegen auf der Hand: z.B. kann der Mitarbeiter, der das Postfach kontakt@beispielfirma.de verwaltet, einfach auf “Antworten” klicken, um eine E-Mail direkt an den Anfragenden zu versenden. Ebenso kann ein Autoresponder den Nutzer über den Eingang seiner E-Mail in kontakt@beispielfirma.de informieren.

Was lange Jahre perfekt funktionierte, führt inzwischen zu sehr viel Frust, nämlich dann, wenn die E-Mail aus dem Kontaktformular nicht mehr zugestellt wird. 

Was sind die Gründe?

Meistens liegt es an den inzwischen strengeren Verfahren zur Erkennung von Spam-Mails, die z.B. prüfen, ob unser Webserver anhand seiner IP-Adresse überhaupt berechtigt ist, eine E-Mail eines Postfaches auf example.com zu versenden. Dazu prüft ein Anti-Spam-Mechanismus, der noch vor dem eigentlichen Spam-Filter sitzt,  z.B., ob die Domain example.com im DNS einen Eintrag mit der IP-Adresse des Webservers besitzt. Das kann ein A-Record sein oder ein spezieller TXT-Record – aber dazu später mehr. Das wird regelmäßig nicht der Fall sein, da die Domain des Absenders ja in der Regel überhaupt nichts mit der Domain des Webservers zu tun haben wird. Eine Ausnahme stellen ausgerechnet eigene Tests des Website-Betreibers dar: seine Mitarbeiter:innen werden häufig ihre Firmen-E-Mail im Formular hinterlegen, und diese geht dann meist problemlos durch den Spam-Filter, weil sie z.B. auf derselben Domain beruht, wie die Website selbst. Beim Testen fallen die Probleme also fatalerweise gar nicht auf.

Was tun, wenn E-Mails nicht ankommen?

Der E-Mail-Absender der vom Formular generierten Mail darf nicht dynamisch sein, sondern sollte fix auf eine Domain lauten, die unter der Kontrolle des Website-Betreibers steht, z.B. kontakt@beispielfirma.de. Dann kann der Website-Betreiber nämlich im DNS einen so genannten SPF-Record eintragen. Das ist ein Textstring, der besagt, dass der Server mit der IP-Adresse des Webserver – z.b. 78.65.43.21 berechtigt ist, E-Mails im Adressraum …@beispielfirma.de zu versenden. Ein solcher SPF-Record würde z.B. wie folgt aussehen:

v=spf1 ip4:78.65.43.21 -all

SPF steht übrigens für Sender Policy Framework. Natürlich stellt das Unternehmen vor neue Herausforderungen, denn nun funktioniert eine einfache Antworten-Funktion ebenso wenig wie ein Autoresponder. Man könnte nun natürlich zwischen der From-Adresse und der ReplyTo-Adresse differenzieren. Als ReplyTo könnte man nach wie vor die Adresse des Formular-Ausfüllers eintragen. Das geht auch in den meisten Fällen gut, allerdings vergeben manche Spamfilter kräftigen Punktabzug, wenn die ReplyTo-Adresse eine bei einem Freemail-Anbieter registrierte Adresse ist, da Spammer natürlich auch gerne solche Adressen nutzen. Kommen also Kontaktanfragen von Unternehmen durch, aber solche Privatleuten mit Account bei GMX, t-online und Co., könnte es an dieser Spam-Filter-Regel liegen (die übrigens die Bezeichnung “FREEMAIL_FORGED_REPLYTO” mit der Langform “Freemail in Reply-To, but not From” besitzt).

Tools

Neben Problemen mit fehlendem SPF-Record gibt es natürlich noch viele weitere Gründe, warum E-Mails aus Formularen nicht ankommen, und hier ist im Einzelfall Detektivarbeit erforderlich. Mancher Webserver wird versuchen, eine E-Mail an seine eigene Domain intern auf dem Server auszuliefern, statt sie rauszusenden. Andere Server werden sich daran stören, dass es z.B. das Postfach “noreply” überhaupt nicht gibt.

• Bei all dem helfen verschiedene Tools, unser liebstes ist mail-tester.com: https://www.mail-tester.com .
  Dieser Anbieter stellt ein dynamisch generiertes E-Mail-Postfach mit zufälliger Adresse zur Verfügung, an das man sein Formular die Nachricht senden lässt. Danach kann man in einer ausführlichen Analyse Problembereiche und Anleitungen zu deren Behebung sehen. Allerdings ist die Anzahl kostenfreier Tests auf wenige Tests pro Tag beschränkt.
• Einen ähnlichen Zweck verfolgt das Tool: https://spamcheck.postmarkapp.com. Dieses Tool funktioniert etwas anders als mail-tester.com. Man kopiert dort die kompletten Rohdaten der E-Mail in ein Feld und erhält eine Bewertung. Vorteil: man kann die Rohdaten direkt verändern (z.B. die ReplyTo-Adresse) und sieht sofort die Auswirkungen. Und wo bekommt man die Rohdaten her? Z.B. kann man sie von oben genanntem mail-tester.com kopieren.
• Mehrere Tools zur Analyse und Generierung des SPF-Records liefert z.B. https://www.spf-record.de/spf-lookup . Mit diesem Rüstzeug versehen steht einer Optimierung von Formular-generierten E-Mails nichts mehr im Wege.

Haben wir etwas vergessen? Natürlich: das Thema “Datenschutz”.

Datenschutz

Das Thema “Datenschutz” darf heutzutage nicht fehlen. Wenn der Website-Besucher auf einem https-gesicherten Formular seine Daten eingibt, darf er erwarten, dass diese auch in einem gesicherten Transportkanal weitergeleitet werden. Hier sollte der E-Mail-Versand zumindest in einem TLS-Kanal erfolgen. Man erkennt das an den oben erwähnten Rohdaten, die eine Zeile wie “using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)“ enthalten sollten.

Geschrieben von Stefan Schütt, Pagemachine AG