Mail() ist tot, es lebe mail()

Flattr this
Tweet this: Mail() ist tot, es lebe mail()
Dent this: Mail() ist tot, es lebe mail()
Datum: 28.09.2009 01:43:34

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/38

Es sind keine Trackbacks vorhanden.


Kommentare (4)

  • Kommentar von linse am 08.10.2010 14:48:32
    Gravatar linse

    utf-8 kodiert - als iso gespeichert - und etwas über umlaute erzählen wollen - haha


  • Kommentar von robo47 am 08.10.2010 16:04:46
    Gravatar robo47

    Von was genau hast du es ?

    Was ist utf-8 kodiert und als iso gespeichert ?


  • Kommentar von Webwalker am 18.12.2010 14:25:05
    Gravatar Webwalker
    Einfach Bullshit diese Verallgemeinerungen. Warum sollte man eine Klasse verwenden die nicht weiterentwickelt wird? Wenn man weiß was man tut, sich ein wenig schlau liest und sich die genannten Klassen als Vorbild nimmt, dann spricht doch nichts gegen eine eigene Entwicklung, die speziell auf die eigenen Bedürfnisse zugeschnitten ist.

  • Kommentar von robo47 am 19.12.2010 10:57:03
    Gravatar robo47

    Keine der oben genannten Libs ist meines Wissens nach eingestellt - sprich wird nicht weiter entwickelt.

    Und betreffs

    Wenn man weiß was man tut, sich ein wenig schlau liest und sich die genannten Klassen als Vorbild nimmt, dann spricht doch nichts gegen eine eigene Entwicklung, die speziell auf die eigenen Bedürfnisse zugeschnitten ist.

    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.

You liked it ? Link it on your homepage or blog: