Versand von E-Mails durch Web-Applikationen
Einleitung
Diverse Web- bzw. E-Mail-Kunden betreiben Web-Seiten oder andere Applikationen die E-Mails an die eigenen Mitarbeiter und/oder Kunden versenden wollen.
Dies ist leider nicht ganz unproblematisch, im Folgenden daher technische Informationen und Vorschläge zu dem Thema.
Problemfelder beim Versand von E-Mails durch Applikationen
E-Mails direkt vom Web-Server haben schlechten Default-Absender
Auf jedem ITEG-Webserver, aber auch auf vielen Webservern anderen Anbietern läuft lokal ein SMTP-Server der als MTA (Message Transfer Agent) verwendet werden kann, entweder indem man auf localhost:25
verbindet und SMTP spricht, oder indem man Mail-Bodies durch die meist vorhandene sendmail
-Kompatibilitäts-Binary piped.
In beiden Fällen hat das E-Mail einen ungeeigneten Absender (Envelope und Header), wie z.B. kundexy@cwh22.iteg.at
.
An eine solche Adresse kann man keine E-Mails schicken, und sie hält auch keiner Verifikation durch empfangende Mailserver stand, daher kommen solche E-Mails oft nicht zugestellt - und verschlechtern die E-Mail-Reputation des Web-Servers (bis hin zum Landen der IP-Adressen des Servers auf Sperrlisten).
E-Mails direkt vom Web-Server haben echten Absender, aber nicht mit diesem authentifiziert
Um obiges Problem zu vermeiden und/oder um ohne Verwendung des E-Mail-Header-Feldes ReplyTo (oder Sender) Antworten auf solche E-Mails zu erhalten werden manchmal echte E-Mail-Adressen als Absender gesetzt.
Meistens wird nur der Header-Absender gesetzt, d.h. das E-Mail-Header-Feld From. Manchmal wird auch der Envelope-Sender gesetzt (SMTP-Kommando MAIL FROM
). Für die Folgen ist der Unterschied eher akademisch, bei der Analyse von Zustell-Problemen und für das Design von Allowlists aber manchmal zu beachten.
Leider bringt dieser Ansatz neue Probleme auf:
Der Web-Server ist oft nicht im SPF-Record zu der Domain abgedeckt und werden nicht zugestellt
Die E-Mails sind nicht mit DKIM signiert, und werden nicht zugestellt
Strenge empfangende Mail-Server lehnen unauthentifiziert gesendete E-Mails mit dort gehostetem Absender (!) generell ab, und die E-Mails werden nicht zugestellt. Das betrifft auch insbesondere E-Mail-Kunden von ITEG, weil unsere Mailcows eben aus gutem Grund streng sind. Aus diesem Grund werden unsere Mail-Server nicht mehr als halb-offene SMTP-Relay-Server für alle unsere Web-Server freischalten, das würde die Mailserver selbst sehr schnell auf Sperrlisten bringen.
Alle diese Details verschlechtern die E-Mail-Reputation des Web-Servers (bis hin zum Landen der IP-Adressen des Servers auf Sperrlisten).
Seiten- bzw. Folge-Effekte für alle Kunden die vom gleichen Web-Server E-Mails verschicken
Leider sind viele Empfänger von automatischen E-Mails zu schnell mit dem Klick auf “Junk” / “Spam”.
Das bringt besonders bei nicht-authentifiziert verschickten E-Mails die sendende IP-Adresse, also den Web-Server, schnell auf Sperrlisten.
Das verringert dann zusätzlich die Versand-Chance für E-Mails die von Applikationen anderen Kunden vom gleichen Server verschickt werden.
Lösungen: Authentifiziert verschicken bzw. Newsletter-Spezialisten
Lösung für einzelne E-Mails: Versand authentifiziert über einen eigenen Mail-Account
Die Lösung für obige Probleme (für einzelne E-Mails) ist es, E-Mails grundsätzlich über den für die Absender-Domain zuständigen E-Mail-Server zu verschicken, und zwar authentifiziert und verschlüsselt.
Verschlüsselung sollte dabei nicht Port 25 und STARTTLS verwenden, sondern den von vornherein verschlüsselten Port 465. Diverse Mail-Server haben aufgehört auf Port 25 überhaupt Authentifizierung zu erlauben.
Beim Versand von Massen-E-Mails wie Newslettern hat das natürlich den Nachteil die Reputation des eigenen Mail-Servers und der eigenen Mail-Domain zu gefährden.
Lösung für Newsletter: Spezialisierte Anbieter, evtl. Sub-Domain
Für den Versand von Newslettern oder anderen E-Mails an zig, hunderte, oder gar tausende Empfänger gibt es spezialisierte Anbieter.
Leider sind einige der Platzhirsche nicht DSGVO-konform und/oder USA-basiert.
Wir möchten keine einzelnen Anbieter empfehlen, daher sollte betroffene Kunden die Suchmaschine Ihrer Wahl z.B. mit newsletter tools dsgvo
befragen.
How-Tos für E-Mail-Versand durch Applikationen
Newsletter: Einfaches Opt-Out!
Newsletter sollten eine möglichst einfache Opt-Out-Möglichkeit bieten, Empfänger sollen mit maximal 3 Klicks aus dem Verteiler kommen.
Leider prüfen empfangende Mail-Server alle Links in E-Mails so tief, dass teils sogar Java-Script ausgeführt wird, eine pauschale Empfehlung für eine Methode können wir daher nicht geben.
E-Mail-Empfänger sollten natürlich im Newsletter immer noch sehen, welche Ihrer evtl. mehreren E-Mail-Adressen überhaupt im Verteiler ist.
Grundsätzlich: Siehe oben, Lösung für Newsletter.
Java-Applikationen
Java’s normaler Mail-Client ist etwas zickig.
Unser Code dazu findet sich in unserem freien Tool FancyMail. Das Repository ist unter git://git.clazzes.org/java-libs/util/fancymail-main.git
öffentlich clone-bar, der relevante Code ist in fancymail/src/main/java/org/clazzes/fancymail/sending/SMTPClient.java
in der Methode createSmtpSession()
. Die Properties werden hier via BluePrint aus *.cfg
-Dateien geholt und in die Bean gesetzt. Für eigene Applikationen wird man hier ohnehin eigenen Code schreiben, falls man keine andere Bibliothek verwendet, die das kann.
Perl-Applikationen
Ja, Perl gibt es noch. Wir haben für Monitoring-Alarme eine Perl-Lösung die Net::SMTP verwendet, deren Code aber nicht mehr öffentlich ist.
Die nicht-Öffentlichkeit ist aber mehr Faulheit als Geheimhaltung, bei Interesse können wir auf Anfrage den SMTP-Teil als Code-Beispiel bereitstellen.
PHP-Applikationen
Die normale mail-Funktion versendet leider dumm über eine sendmail
-Kompatible binary (wobei wir die dort dokumentierte Variante mit sendmail.ini
erst beim Schreiben dieser Zeile entdeckt und nicht näher untersucht haben). Man kann sich - auch in älteren PHP-Umgebungen - ggfs. mit msmtp bereitstellen, dem man Details zu einem zum Versand zu nutzenden SMTP-Account über eine Konfigurationsdatei ~/.msmtprc
bzw. auch über Kommandozeile und damit über php.ini
-Settings bereitstellen kann.
Für native PHP-Lösungen bietet sich das pear-Modul Mail an.
Beides ist in den bald für alle ITEG-Hosting-Kunden kommenden dockerisierten PHP-FPM-Umgebungen installiert.
Andere Applikationen
Keine Ahnung
Die bei PHP erwähnte Lösung mit msmtp
sollte aber in ziemlich jeder Server-Situation helfen.