> Indem wir moderne Produkte wie den [Symfony_Mailer](https://wiki.selfhtml.org/wiki/PHP/Tutorials/Symfony_Mailer) empfehlen und alle Bedenken und möglichen Probleme in diesen Abschnitt packen: > > [Vorteile gegenüber Eigenbaulösungen](https://wiki.selfhtml.org/wiki/PHP/Tutorials/Symfony_Mailer#Vorteile_gegen.C3.BCber_Eigenbaul.C3.B6sungen)(¹) Ich bleibe aber dabei, dass **im Falle einfacher Mails** (nur Text-Teil, genau ein Empfänger, kein variabler Versender) und den gegebenen technischen Voraussetzungen die sinnhafte(!) Verwendung von [mail()](https://www.php.net/manual/de/function.mail.php) die sicherste Lösung ist. Das Erkennen, ggf. Filtern oder Zurückweisen von unzulässigen Input (z.B. Zeilenumbrüchen in der Adresse oder im Subjekt - sofern man dessen Setzung durch den Webbenutzer so notlos wie überhaupt zulassen will) ist eigentlich keine allzugroße Herausforderung. Schwierig wird es erst, wenn man [Multipart-Mails](https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html) oder Anhängen versenden will oder kein MTA konfiguriert ist - was nicht oft vorkommt bzw. bei einem eigenem Server zumindest für diejenigen, die einen solchen eigenem Server betreiben *können*(²), auch nicht „so gar schwierig“ ist. Sowohl [mail()](https://www.php.net/manual/de/function.mail.php) als auch [PHPMailer](https://github.com/PHPMailer/PHPMailer) und eben auch der [Symfony_Mailer](https://symfony.com/doc/current/mailer.html) haben das Potential dafür, bei unbedarfter Anwendung zu ungewollten Ergebnissen zu führen. Gerade die großen Libs bringen als „[eierlegende Wollmilchsäue](https://de.wikipedia.org/wiki/Eierlegende_Wollmilchsau)“ schon in der Theorie viel Programmcode und also eigene Fehlerquellen mit. Was mir immer Bauchschmerzen bereitet ist, dass große Teile davon auch dann geladen werden, wenn diese gar nicht gebraucht werden. ---- ¹) Rate(t) mal, wer das *„Schon gehackt“* eigentlich in die Titelzeile [des dort verlinkten Beitrags](https://forum.selfhtml.org/self/2020/mar/20/css-kompatibelitat-ie-edge/1767569#m1767569) tippen wollte, aber gerade nur ein abgelaufenes [Feingebäck](https://de.wikipedia.org/wiki/HTTP-Cookie) hatte… ²) Gemeint ist das *„Können“*, welches vom *„Lernen, kombiniert mit Sorgfalt und einem wachen Verstand“* her kommt.

> Indem wir moderne Produkte wie den [Symfony_Mailer](https://wiki.selfhtml.org/wiki/PHP/Tutorials/Symfony_Mailer) empfehlen und alle Bedenken und möglichen Probleme in diesen Abschnitt packen: > > [Vorteile gegenüber Eigenbaulösungen](https://wiki.selfhtml.org/wiki/PHP/Tutorials/Symfony_Mailer#Vorteile_gegen.C3.BCber_Eigenbaul.C3.B6sungen)(¹) Ich bleibe aber dabei, dass **im Falle einfacher Mails** (nur Text-Teil, genau ein Empfänger, kein variabler Versender) und den gegebenen technischen Voraussetzungen die sinnhafte(!) Verwendung von [mail()](https://www.php.net/manual/de/function.mail.php) die sicherste Lösung ist. Das Erkennen, ggf. Filtern oder Zurückweisen von unzulässigen Input (z.B. Zeilenumbrüchen in der Adresse oder im Subjekt - sofern man dessen Setzung durch den Webbenutzer so notlos wie überhaupt zulassen will) ist eigentlich keine allzugroße Herausforderung. Schwierig wird es erst, wenn man [Multipart-Mails](https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html) oder Anhängen versenden will oder kein MTA konfiguriert ist - was nicht oft vorkommt bzw. bei einem eigenem Server zumindest für diejenigen, die einen solchen eigenem Server betreiben *können*(²), auch nicht „so gar schwierig“ ist. Sowohl [mail()](https://www.php.net/manual/de/function.mail.php) als auch [PHPMailer](https://github.com/PHPMailer/PHPMailer) und eben auch der [Symfony_Mailer](https://symfony.com/doc/current/mailer.html) haben das Potential dafür, bei unbedarfter Anwendung zu ungewollten Ergebnissen zu führen. Gerade die großen Libs bringen als „[eierlegende Wollmilchsäue](https://de.wikipedia.org/wiki/Eierlegende_Wollmilchsau)“ schon in der Theorie viel Programmcode und also eigene Fehlerquellen mit. Was mir immer Bauchschmerzen bereitet ist, dass große Teile davon auch dann geladen werden, wenn diese gar nicht gebraucht werden. ---- ¹) Rate(t) mal, wer das *„Schon gehackt“* eigentlich in die Titelzeile [des dort verlinkten Beitrags](https://forum.selfhtml.org/self/2020/mar/20/css-kompatibelitat-ie-edge/1767569#m1767569) tippen wollte, aber gerade nur ein abgelaufenes Feingebäck hatte… ²) Gemeint ist das *„Können“*, welches vom *„Lernen, kombiniert mit Sorgfalt und einem wachen Verstand“* her kommt.

> Indem wir moderne Produkte wie den [Symfony_Mailer](https://wiki.selfhtml.org/wiki/PHP/Tutorials/Symfony_Mailer) empfehlen und alle Bedenken und möglichen Probleme in diesen Abschnitt packen: > > [Vorteile gegenüber Eigenbaulösungen](https://wiki.selfhtml.org/wiki/PHP/Tutorials/Symfony_Mailer#Vorteile_gegen.C3.BCber_Eigenbaul.C3.B6sungen)(¹) Ich bleibe aber dabei, dass **im Falle einfacher Mails** (nur Text-Teil, genau ein Empfänger, kein variabler Versender) und den gegebenen technischen Voraussetzungen die sinnhafte(!) Verwendung von [mail()](https://www.php.net/manual/de/function.mail.php) die sicherste Lösung ist. Das Erkennen, ggf. Filtern oder Zurückweisen von unzulässigen Input (z.B. Zeilenumbrüchen in der Adresse oder im Subjekt - sofern man dessen Setzung durch den Webbenutzer so notlos wie überhaupt zulassen will) ist eigentlich keine allzugroße Herausforderung. Schwierig wird es erst, wenn man [Multipart-Mails](https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html) oder Anhängen versenden will oder kein MTA konfiguriert ist - was nicht oft vorkommt bzw. bei einem eigenem Server zumindest für diejenigen, die einen solchen eigenem Server betreiben *können*(²), auch nicht „so gar schwierig“ ist. Sowohl [mail()](https://www.php.net/manual/de/function.mail.php) als auch [PHPMailer](https://github.com/PHPMailer/PHPMailer) und eben auch der [Symfony_Mailer](https://symfony.com/doc/current/mailer.html) haben das Potential dafür, bei unbedarfter Anwendung zu ungewollten Ergebnissen zu führen. Gerade die großen Libs bringen als „[eierlegende Wollmilchsäue](https://de.wikipedia.org/wiki/Eierlegende_Wollmilchsau)“ schon in der Theorie viel Programmcode und also eigene Fehlerquellen mit. Was mir immer Bauchschmerzen bereitet ist, dass große Teile davon auch dann geladen werden, wenn diese gar nicht gebraucht werden. ---- ¹) Rate(t) mal, wer das *„Schon gehackt“* eigentlich in die Titelzeile [des dort verlinkten Beitrags](https://forum.selfhtml.org/self/2020/mar/20/css-kompatibelitat-ie-edge/1767569#m1767569) tippen wollte, aber gerade keinen Keks hatte… ²) Gemeint ist das *„Können“*, welches vom *„Lernen, kombiniert mit Sorgfalt und einem wachen Verstand“* her kommt.

> Indem wir moderne Produkte wie den [Symfony_Mailer](https://wiki.selfhtml.org/wiki/PHP/Tutorials/Symfony_Mailer) empfehlen und alle Bedenken und möglichen Probleme in diesen Abschnitt packen: > > [Vorteile gegenüber Eigenbaulösungen](https://wiki.selfhtml.org/wiki/PHP/Tutorials/Symfony_Mailer#Vorteile_gegen.C3.BCber_Eigenbaul.C3.B6sungen)(¹) Ich bleibe aber dabei, dass **im Falle einfacher Mails** (nur Text-Teil, genau ein Empfänger, kein variabler Versender) und den gegebenen technischen Voraussetzungen die sinnhafte(!) Verwendung von [mail()](https://www.php.net/manual/de/function.mail.php) die sicherste Lösung ist. Das Erkennen, ggf. Filtern oder Zurückweisen von unzulässigen Input (z.B. Zeilenumbrüchen in der Adresse oder im Subjekt - sofern man dessen Setzung durch den Webbenutzer so notlos wie überhaupt zulassen will) ist eigentlich keine allzugroße Herausforderung. Schwierig wird es erst, wenn man [Multipart-Mails](https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html) oder Anhängen versenden will oder kein MTA konfiguriert ist - was nicht oft vorkommt bzw. bei einem eigenem Server zumindest für diejenigen, die einen solchen eigenem Server betreiben *können*(²), auch nicht „so gar schwierig“ ist. Sowohl [mail()](https://www.php.net/manual/de/function.mail.php) als auch [PHPMailer](https://github.com/PHPMailer/PHPMailer) und eben auch der [Symfony_Mailer](https://symfony.com/doc/current/mailer.html) haben das Potential dafür, bei unbedarfter Anwendung zu ungewollten Ergebnissen zu führen. Gerade die großen Libs bringen als „[eierlegende Wollmilchsäue](https://de.wikipedia.org/wiki/Eierlegende_Wollmilchsau)“ schon in der Theorie viel Programmcode und also eigene Fehlerquellen mit. Was mir immer Bauchschmerzen bereitet ist, dass große Teile davon auch dann geladen werden, wenn diese gar nicht gebraucht werden. ---- ¹) Rate(t) mnal, wer das „Schon gehackt“ eigentlich in die Titelzeile [des dort verlinkten Beitrags](https://forum.selfhtml.org/self/2020/mar/20/css-kompatibelitat-ie-edge/1767569#m1767569) tippen wollte… ²) Gemeint ist das *„Können“*, welches vom *„Lernen, kombiniert mit Sorgfalt und einem wachen Verstand“* her kommt.

> Indem wir moderne Produkte wie den [Symfony_Mailer](https://wiki.selfhtml.org/wiki/PHP/Tutorials/Symfony_Mailer) empfehlen und alle Bedenken und möglichen Probleme in diesen Abschnitt packen: > > [Vorteile gegenüber Eigenbaulösungen](https://wiki.selfhtml.org/wiki/PHP/Tutorials/Symfony_Mailer#Vorteile_gegen.C3.BCber_Eigenbaul.C3.B6sungen)(¹) Ich bleibe aber dabei, dass **im Falle einfacher Mails** (nur Text-Teil, genau ein Empfänger, kein variabler Versender) und den gegebenen technischen Voraussetzungen die sinnhafte(!) Verwendung von [mail()](https://www.php.net/manual/de/function.mail.php) die sicherste Lösung ist. Das Erkennen, ggf. Filtern oder Zurückweisen von unzulässigen Input (z.B. Zeilenumbrüchen in der Adresse oder im Subjekt - sofern man dessen Setzung durch den Webbenutzer so notlos wie überhaupt zulassen will) ist eigentlich keine allzugroße Herausforderung. Schwierig wird es erst, wenn man [Multipart-Mails](https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html) oder Anhängen versenden will oder kein MTA konfiguriert ist - was nicht oft vorkommt bzw. bei einem eigenem Server zumindest für diejenigen, die einen solchen eigenem Server betreiben *können*(²), auch nicht „so gar schwierig“ ist. Sowohl [mail()](https://www.php.net/manual/de/function.mail.php) als auch [PHPMailer](https://github.com/PHPMailer/PHPMailer) und eben auch der [Symfony_Mailer](https://symfony.com/doc/current/mailer.html) haben das Potential dafür, bei unbedarfter Anwendung zu ungewollten Ergebnissen zu führen. Gerade die großen Libs bringen als „[eierlegende Wollmilchsäue](https://de.wikipedia.org/wiki/Eierlegende_Wollmilchsau)“ schon in der Theorie viel Programmcode und also eigene Fehlerquellen mit. Was mir immer Bauchschmerzen bereitet ist, dass große Teile davon auch dann geladen werden, wenn diese gar nicht gebraucht werden. ---- ¹) Rate(t) mnal, wer das „Schon gehackt“ eigentlich in die Titelzeile des dort verlinkten Beitrags tippen wollte… ²) Gemeint ist das *„Können“*, welches vom *„Lernen, kombiniert mit Sorgfalt und einem wachen Verstand“* her kommt.

> Indem wir moderne Produkte wie den [Symfony_Mailer](https://wiki.selfhtml.org/wiki/PHP/Tutorials/Symfony_Mailer) empfehlen und alle Bedenken und möglichen Probleme in diesen Abschnitt packen: > > [Vorteile gegenüber Eigenbaulösungen](https://wiki.selfhtml.org/wiki/PHP/Tutorials/Symfony_Mailer#Vorteile_gegen.C3.BCber_Eigenbaul.C3.B6sungen) Ich bleibe aber dabei, dass **im Falle einfacher Mails** (nur Text-Teil, genau ein Empfänger, kein variabler Versender) und den gegebenen technischen Voraussetzungen die sinnhafte(!) Verwendung von [mail()](https://www.php.net/manual/de/function.mail.php) die sicherste Lösung ist. Das Erkennen, ggf. Filtern oder Zurückweisen von unzulässigen Input (z.B. Zeilenumbrüchen in der Adresse oder im Subjekt - sofern man dessen Setzung durch den Webbenutzer so notlos wie überhaupt zulassen will) ist eigentlich keine allzugroße Herausforderung. Schwierig wird es erst, wenn man [Multipart-Mails](https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html) oder Anhängen versenden will oder kein MTA konfiguriert ist - was nicht oft vorkommt bzw. bei einem eigenem Server zumindest für diejenigen, die einen solchen eigenem Server betreiben *können*(¹), auch nicht so schwierig ist. Sowohl [mail()](https://www.php.net/manual/de/function.mail.php) als auch [PHPMailer](https://github.com/PHPMailer/PHPMailer) und eben auch der [Symfony_Mailer](https://symfony.com/doc/current/mailer.html) haben das Potential dafür, bei unbedarfter Anwendung zu ungewollten Ergebnissen zu führen. Gerade die großen Libs bringen als „[eierlegende Wollmilchsäue](https://de.wikipedia.org/wiki/Eierlegende_Wollmilchsau)“ schon in der Theorie viel Programmcode und also eigene Fehlerquellen mit. Was mir immer Bauchschmerzen bereitet ist, dass große Teile davon auch dann geladen werden, wenn diese gar nicht gebraucht werden. ---- ¹) Gemeint ist das *„Können“*, welches vom *„Lernen, kombiniert mit Sorgfalt und einem wachen Verstand“* her kommt.

> Indem wir moderne Produkte wie den [Symfony_Mailer](https://wiki.selfhtml.org/wiki/PHP/Tutorials/Symfony_Mailer) empfehlen und alle Bedenken und möglichen Probleme in diesen Abschnitt packen: > > [Vorteile gegenüber Eigenbaulösungen](https://wiki.selfhtml.org/wiki/PHP/Tutorials/Symfony_Mailer#Vorteile_gegen.C3.BCber_Eigenbaul.C3.B6sungen) Ich bleibe aber dabei, dass **im Falle einfacher Mails** (nur Text-Teil, genau ein Empfänger, kein variabler Versender) und den gegebenen technischen Voraussetzungen die sinnhafte(!) Verwendung von [mail()](https://www.php.net/manual/de/function.mail.php) die sicherste Lösung ist. Das Erkennen, ggf. Filtern oder Zurückweisen von unzulässigen Input (z.B. Zeilenumbrüchen in der Adresse oder im Subjekt - sofern man dessen Setzung durch den Webbenutzer so notlos wie überhaupt zulassen will) ist eigentlich keine allzugroße Herausforderung. Schwierig wird es erst, wenn man [Multipart-Mails](https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html) oder Anhängen versenden will oder kein MTA konfiguriert ist - was nicht oft vorkommt bzw. bei einem eigenem Server zumindest für diejenigen, die einen solchen eigenem Server betreiben *können*, auch nicht so schwierig ist. Sowohl [mail()](https://www.php.net/manual/de/function.mail.php) als auch [PHPMailer](https://github.com/PHPMailer/PHPMailer) und eben auch der [Symfony_Mailer](https://symfony.com/doc/current/mailer.html) haben das Potential dafür, bei unbedarfter Anwendung zu ungewollten Ergebnissen zu führen. Gerade die großen Libs bringen als „[eierlegende Wollmilchsäue](https://de.wikipedia.org/wiki/Eierlegende_Wollmilchsau)“ schon in der Theorie viel Programmcode und also eigene Fehlerquellen mit. Was mir immer Bauchschmerzen bereitet ist, dass große Teile davon auch dann geladen werden, wenn diese gar nicht gebraucht werden.

> Indem wir moderne Produkte wie den [Symfony_Mailer](https://wiki.selfhtml.org/wiki/PHP/Tutorials/Symfony_Mailer) empfehlen und alle Bedenken und möglichen Probleme in diesen Abschnitt packen: > > [Vorteile gegenüber Eigenbaulösungen](https://wiki.selfhtml.org/wiki/PHP/Tutorials/Symfony_Mailer#Vorteile_gegen.C3.BCber_Eigenbaul.C3.B6sungen) Ich bleibe aber dabei, dass **im Falle einfacher Mails** (nur Text-Teil, genau ein Empfänger, kein variabler Versender) und den gegebenen technischen Voraussetzungen die sinnhafte(!) Verwendung von [mail()](https://www.php.net/manual/de/function.mail.php) die sicherste Lösung ist. Das Erkennen, ggf. Filtern oder Zurückweisen von unzulässigen Input (z.B. Zeilenumbrüchen in der Adresse oder im Subjekt - sofern man dessen Setzung durch den Webbenutzer so notlos wie überhaupt zulassen will) ist eigentlich keine allzugroße Herausforderung. Schwierig wird es erst, wenn man [Multipart-Mails](https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html) oder Anhängen versenden will oder kein MTA konfiguriert ist - was nicht oft vorkommt bzw. bei einem eigenem Server zumindest für diejenigen, die einen solchen eigenem Server betreiben können, auch nicht so schwierig ist. Sowohl [mail()](https://www.php.net/manual/de/function.mail.php) als auch [PHPMailer](https://github.com/PHPMailer/PHPMailer) und eben auch der [Symfony_Mailer](https://symfony.com/doc/current/mailer.html) haben das Potential dafür, bei unbedarfter Anwendung zu ungewollten Ergebnissen zu führen. Gerade die großen Libs bringen als „[eierlegende Wollmilchsäue](https://de.wikipedia.org/wiki/Eierlegende_Wollmilchsau)“ schon in der Theorie viel Programmcode und also eigene Fehlerquellen mit. Was mir immer Bauchschmerzen bereitet ist, dass große Teile davon auch dann geladen werden, wenn diese gar nicht gebraucht werden.