Problem mit Datenverlust bei WP Contact Form 7 & Office 365 – Mails kommen nicht beim Empfänger an und verschwinden

Problembeschreibung: Mangelhafte Zuverlässigkeit der Email Zustellung bei restriktiven Email Service Providern

Bei einem Kundenprojekt ergab sich nach einiger Zeit folgendes Szenario: Potentielle Neukunden, die das Kontaktformular (WordPress Plugin Contact Form 7) ausgefüllt und abgeschickt hatten, meldeten sich glücklicherweise noch einmal telefonisch, um nachzuhaken.

Beim Abschicken des Kontaktformular auf der WordPress-basierten Website lief alles völlig in Ordnung samt Meldung, daß das Formular übermittelt wurde. Darüber hinaus erhielt der Absender ebenfalls eine Bestätigungsmail (auch aus Contact Form 7 generiert), in der ihm – neben seinen eingegebenen Formulardaten – mitgeteilt wird, daß sich ein Mitarbeiter mit ihm in Verbindung setzen wird.

Beim Kunden kam jedoch überhaupt keine Email über das Kontaktformular an und es war purer Zufall, daß sich jemand noch einmal telefonisch bzw. per Email gemeldet hat.

Der Kunde hat seine Email über Microsoft Office365 konfiguriert und ansonsten funktioniert sowohl der Email-Versand als auch Empfang auf allen Mailkonten reibungslos und fehlerfrei.

Die Problematik scheint bekannt zu sein und ist dokumentiert in der Microsoft Community. Das Problem ist nur: Man bekommt gar nicht mit, dass Emails ggf. verloren gegangen sind und dies kann für eine Unternehmens-Website bei einem Erstkontakt bares Geld bedeuten!

Test der Kontaktformulare

Um zu überprüfen, ob es sich um eine Fehlfunktion des WP Plugins Contact Form 7 handelt wurde kurzerhand im Dashboard unter „Formulare“ von allen Formularen eine Kopie erstellt, bei der die Email-Adresse des Kunden durch eine erwiesenermaßen funktionierende alternative Email-Adresse ersetzt wurde. Über ein Testpage mit allen Formularen konnte man diese schnell ausfüllen, abschicken und sich wundern, wo denn überhaupt das Problem liegt. Sowohl die für den Kunden bestimmte Email, als auch die Bestätigungsmail für den Ausfüller des Formulars wurden reproduzierbar korrekt erstellt, versendet und zugestellt. Auch die Bestätigung seitens des Contact Form 7 Formulars nach Betätigen des „Submit“ / Senden Buttons ließ keine Zweifel, das hier alles korrekt läuft.

Wichtig ist hier auch, bei einem Projekt nicht nur lokal oder auf einem Staging Server zu testen, sondern auch im realen Betrieb auf dem Live Server und mit dem jeweiligen Mail Service Provider. Auch bei einem Wechsel des Mail Service Providers sollte die korrekte Funktionalität erneut getestet werden.

Gegenmaßnahmen

Hinzufügen weiterer Header Daten in Contact Form 7

Nach einiger Recherche wurde klar, daß es in bestimmten Kombinationen von Contact Form 7 mit diversen Email-Providern bzw. Mailserver zu dem nicht dokumentierten Verlust von Emails kommen kann.

Als möglicher Lösungsansatz wurden hier also sowohl SENDER als auch REPLY-TO gesetzt, um Mailservern mit sehr strikten Vorgaben hier einen kompletteren Header-Datensatz zu bieten.

Absicherung der Emails über BCC

Um Sicherzugehen, daß keine über ein Formular verschickte Mail verlorengeht, wurde in den Header-Settings des Contact Form 7 Formulars zusätzlich eine alternative Email-Adresse als BCC festgelegt. Nach erneutem Testen konnte lediglich festgestellt werden, daß alle über das Formular erzeugten Mails bei der BCC Adresse ankommen, beim Office 365 Account jedoch nicht. Zumindest war Contact Form 7 damit entlastet und die Suche konzentrierte sich auf die Office365 Email-Konfiguration.

Mailserver Whitelist in Office 365 einrichten

Da die Probleme reproduzierbar nur bei der Kombination aus Email Versand aus dem Contact Form 7 an mit Office 365 verwalteten Mail-Account auftraten, ist davon auszugehen, dass Office 365 oder evtl. der MS Exchange Server, der im Hintergrund läuft, die Mails als Spam droppt (BOUNCE) und noch nicht mal in den Spam-Ordner einsortiert. Es kann nur gemutmaßt werden, ob dies allgemein bei per Script PHP mail() – absoluter Webstandard – verschickten Emails gilt, oder sonstige Parameter eines Anti-Spam Algorithmus vielleicht dazu führen, daß die Mails nicht nur nicht zugestellt werden, sondern einfach spurlos verschwinden.

Einige Einträge im Mail-Header einer Email (XXXXX does not  designate permitted sender hosts), die nur als Copy an den Absender zugestellt wurde, lassen vermuten, dass Office 365 den Webserver derselben Domain als Spam einstuft.

Um zu vermeiden, daß Office365 den Server auf dem WordPress und das Contact Form 7 installiert ist als malicious oder potentiellen Spamer einstuft, werden sowohl der Webserver als auch der Mailserver des Providers in Office 365 in eine Whitelist eingetragen. Wie dies geht, ist hier gut beschrieben: http://kb.rolet.com/whitelist-domain-bypass-spam-filtering-microsoft-office-365/

Mailversand per SMTP statt PHP mail() mit WordPress Plugin

Man kann WordPress per Plugin so konfigurieren, daß statt der Standard PHP mail() function ein SMTP Server mit SSL oder TLS Authetifizierung verwendet wird. Empfehlenswert ist hier das Plugin WP Mail SMTP.

So kann man den Mail-Versand auch über einen festen Account eines Email Providers organisieren. Hier könnte man z.B. eine feste Email Adresse  zum Verschicken der Serverseitig generierten Mails erstellen und die Daten eingeben im WordPress Admin Bereich unter „Einstellungen“->“Email“ (Beispiel WP Mail SMTP)

Dort wären folgende Settings zu ändern:

Und natürlich bestätigen und die Einstellungen speichern

Schreiben der übermittelten Formulardaten in Datenbank

Um sicherzugehen, daß keine Daten verlorengehen, weil eine Email – aus welchen Gründen auch immer – ohne Fehlerprotokoll nicht zugestellt wurde, sollte man die per Formular übermittelten Daten am besten direkt in die Datenbank schreiben. Die Hersteller von Contact Form 7 bieten hierfür ein eigenes Plugin namens Flamingo an, das sie auch im per Link im Dashboard empfehlen. Flamingo arbeitet direkt mit Contact Form 7 zusammen, ist allerdings momentan nur dann wirklich produktiv einsetzbar, wenn man entweder die Standard-Vorgaben [your-name], [your-email] und [your-subject] einhält, oder das Plugin dementsprechend ein wenig anpasst, damit es auch mit frei gewählten Formaten wie fixem oder individuell geriertem Subject und zusammengesetzten Adressaten wie [anrede] [vorname] [nachname] <[email]> zurechtkommt.

Evtl. sollte dies der Standard sein, wenn Flamingo denn mal ausgereift ist und man sollte den Email Versand als zusätzliche (nicht ganz zuverlässige) Information ansehen

DNS Records checken

Darüber hinaus lohnt sich ein Blick in die DNS Einträge der Domain des eigenen Webspaces bzw. Servers. In manchen Fällen kann eine Fehlkonfiguration des MX Records zu ähnlichen Problemen führen, wie in http://community.office365.com/en-us/f/158/t/207807.aspx beschrieben.

Weiterhin kann eine Änderung des SPF Records (Sender Policy Framework) eine Verbesserung der Email Zustellung bringen, wie YOAST in dem Beitrag Email Reliability: use an SPF record weitgehend unbekannte Faktoren in der Zuverlässigkeit der Email Zustellung und Generierung aus WordPress heraus beschreibt. Wie man dies bei einem gängigen Provider durchführen kann und welche Einstellungen hier vorzunehmen sind, sei hier exemplarisch am Beispiel eines Artikels der Strato KnowledgeBase wiedergegeben und muss im Detail beim eigenen Provider nachgeschaut erden

Das könnte Sie auch interessieren: