Mail() ist tot, es lebe mail()
Immer wieder sieht man wie sich Leute mit mail() abquälen wenn sie mit PHP E-Mails versenden wollen.
Die Probleme können hier verschiedene Ursachen haben:
- unzureichende Kenntnisse über relevante RFC's (Umbrüche, Datumsformate)
- fehlende/falsche header
- bescheidenes/umständliches Setup beim Hoster (Zusätzliches freischalten von Absender, Limitierungen für Anzahl, Größe, Empfängerzahl ... )
Während es für die kleine schnelle Info-Mail gerade noch okay ist, versuchen Leute immer wieder das Rad neu zu erfinden wenn es um Dinge wie HTML-Mails, Datei-Anhängen, eingebette Daten
oder die passende Mail-Header geht.
Das muss heutzutage absolut nicht sein, denn dieses Rad wurde schon zu oft neu erfunden und die Chance dass E-Mails wegen Kleinigkeiten (falscher Umbruch, ungültiger Header, falsches
Datumsformat, ...) von anderen Mailservern als SPAM markiert werden, ganz abgelehnt werden oder der Mailclient sie am Ende nicht ordentlich darstellen kann ist einfach zu groß.
Die Möglichkeiten eventuelle Fehler zu debuggen sind oftmals sehr schwer, weil sie von vielen Faktoren wie z.b. dem eigenen Mailserver, dem fremden Mailserver, dem Mailclient des
Empfängers, der jeweiligen Konfiguration dieser Komponenten und eventueller weiterer Komponenten abhängt.
Deshalb sollte man zum verschicken von Emails auf fertige erprobte und geteste Klassen zurückgreifen.
Hier gibt es mittlerweile einige sehr gute Klassen die neben HTML-Mails, eingebetten Daten (CSS, Bilder), Datei-Anhängen und Mail-Headern auch noch verschiedene Transports (mail(),
Sendmail und SMTP) unterstützen. Ausserdem verfügen manche sogar noch über Plugins oder Erweiterungen für LoadBalancing zwischen mehreren Servern, Failover, Speicher-sparende Versand
(trotz großer Dateianhänge) und Queueing die sich beim Massenversand von Mails von Vorteil sein können.
Beim Versand über SMTP spart man sich oftmals auch die Nervereien mit dem umständlichen Setup beim Hoster und gerade beim Versenden von großen Mengen an Mails (Newsletter etc) ist der
direkte Versand via SMTP auch noch schneller.
Ein paar dieser Klassen möchte ich hier mal auflisten und für ein paar habe ich auch ein paar fertige Codeschnipsel die zeigen wie man damit eine HTML-Email via SMTP versendet.
| Mailer | Version | PHP-Version | Extensions | Lizenz | Links |
| phpmailer | 5.0.2 (26.05.2009) | php 5 | LGPL v2.1 | Download | |
| Zend_Mail | 1.9.3 (22.09.2009) | php 5.2 |
spl optional: posix |
New BSD License | Download |
| ezcMail |
1.6.3 (22.06.2009) ezComponents 2009.1.2 |
php 5.2 |
pcre, spl, reflection, iconv optional: openssl, mcrypt, fileinfo |
New BSD License |
Download Dokumentation API |
| Swiftmailer | 4.0.5 (27.09.2009) | php5 | spl | LGPL 3 |
Download Dokumentation |
| Swiftmailer | 3.3.3 (26.03.2008) | php 4/php5 | LGPL 3 |
Download Dokumentation |
|
|
PEAR Mail (PEAR Mime) |
1.1.4 (11.10.2006) 1.2.0 beta (15.5.2009) |
php4 | PHP 2.02/New BSD License |
Download Dokumentation |
Alle diese Klassen bieten die Grundfunktionen für den Versand von (Html-)E-Mails via mail() oder SMTP, erlauben es Dateianhänge hinzuzufügen und unterstützen das setzen von Mail-Headern
(Return-Path, etc).
Ich selbst setzte meistens Zend_Mail ein da ich eh mit dem Zend_Framework arbeite. Ansonsten fällt meine Wahl auf den Swiftmailer.
Codeschnipsel für den Versand von HTML-Emails via SMTP:
Trackbacks (0)
Trackbackurl: http://www.robo47.net/trackback/text/38Es sind keine Trackbacks vorhanden.
You liked it ? Link it on your homepage or blog:
Benjamin Steininger ist Webentwickler auf der Suche nach einem neuen Job und
photographiert sehr gerne. Er beschäftigt sich viel mit dem Internet, PHP, Symfony, Testing und hat einen
Kommentare (4)
utf-8 kodiert - als iso gespeichert - und etwas über umlaute erzählen wollen - haha
Von was genau hast du es ?
Was ist utf-8 kodiert und als iso gespeichert ?
Keine der oben genannten Libs ist meines Wissens nach eingestellt - sprich wird nicht weiter entwickelt.
Und betreffs
Warum Klassen umschreiben oder neue eigene schreiben ? Sind die eigenen speziellen Bedürfnisse so exotisch dass man nicht einfach auf ein existierendes System aufbauen kann ? Sprich Basis-Klassen durch Vererbung erweitern, auf die Interfaces der Libs aufsetzen um sie zu erweitern etc ... So kann man jederzeit von den Weiterentwicklungen und Bugfixes des Klasse profitieren, spart Arbeit und Zeit.
Generische Lösungen die andere auch interessieren kann man dem jeweiligen Projekt wieder beisteuern und alle haben was davon.
Ich sehe halt einfach, viel zu viele Leute haben 0 Ahnung vom Mails versenden, nutzen einfach nur mail() und fertig. Kaum jemand will/kann für so eine lapidare Sache wie eine Mail verschicken - was in fast jeder Web-Applikation vorkommt - alle nötigen RFCs lesen/kennen, sich über eventuelle Bugs in Server/Client-implementierungen Informieren, Sämtliche User Contributed Notes auf php.net/mail lesen, etc.
Und der Ärger ist dann groß wenn man irgendwann später feststellt dass ein großer Teil der Mails garnicht erst ankommt, beim User direkt im Spam landet, Darstellungsprobleme (Charset, etc) auftreten, Dateiahnänge nicht ankommen oder in irgendeiner Form defekt sind (falsch encodiert, abgeschnitten, ... ).
Die Kommentare zu diesem Beitrag sind gesperrt.