Sendmail-Path PHP Mail und /etc/aliases

  • Sendet man eine Mail per PHP-Mail an einen nicht-erreichbaren Empfänger, mit z.B. diesem Script oder einer anderen beliebigen Anwendung, landen diese Mails im Nirvana und der Absender wird nicht über die unzustellbarkeit informiert. Dies kommt sehr häufig vor, wenn z.B. WordPress-Kontaktformulare automatische Antworten versenden.


    PHP
    <?php 
    $from = "info@kundendomain.de";
    $to = "test@htstruzwirsi.de"; // hier wird bewusst eine nicht-erreichbare Mailadresse verwendet.
    $subject = "PHP Mail Test Script";
    $message = "Das ist ein Test";
    $headers = "From:" . $from;
    mail($to,$subject,$message, $headers);
    echo "Test email geschickt";
    ?>


    Als Return-Path ist im Header einer jeden Mail von Hause aus beispielsweise hinterlegt: <web35@s1.serverdomain.de>


    Damit der Kunde eine Info oder den Mailrückläufer erhält, würde ein Eintrag in der Datei /etc/aliases wie folgt aushelfen:


    web35: info@kundendomain.de ---> wobei hier die Adresse des Kunden verwendet werden sollte, die im LiveConfig für den Kunden hinterlegt ist.


    Nun macht es keinen sinn, diese Datei für hunderte Kunden manuell zu pflegen. Hier wäre es sinnvoll, wenn LiveConfig diese Aufgabe künftig übernehmen würde und diese Einträge gleich mit anlegt.


    Ich verweise wiederum auf Plesk, denn dort ist die Sache, genau wie bei Confixx, bereits so eingestellt:


    Zitat

    Default Return-Path for PHP mail script is taken as server administrator mail address.


    Plesk erlaubt es sogar für jeden Kunden, einen individuellen Return-Path festzulegen: https://support.plesk.com/hc/e…-Path-for-PHP-mail-script


    Eine Sache, die ich bei LiveConfig vermisse. Es würde jedoch schon reichen, wenn durch LiveConfig die Datei /etc/aliases gepflegt wird, indem dort für jeden Benutzer die im LiveConfig hinterlegte Mailadresse des Kunden hinterlegt wird. Somit wird der Kunde zumindest informiert, wenn eine Mail per PHP-Mail nicht zugestellt werden konnte, indem er den Rückläufer und den Grund der Nichzustellbarkeit erhält.

  • Im Grunde ist die Definition Serverseitig eine sinnvolle Sache. Dennoch ist es praktisch, die PHP-Mails konkreter zu definieren. Via http://php.net/manual/de/function.mail.php ist es angerissen und mit "$headers.="Return-Path:<name@example.com>\r\n";" erhält man auch einen wünschenswerten Eintrag für Rückläufer. Bei PHP im SafeMode erhielt man damals immer die Meldung, dass der 5. Parameter im Mail-Befehl nicht unterstützt werden würde. Bei Confixx wurde hilfsweise eine .forward im HomeDir des Kunden mit der E-Mail-Adresse gefüllt, die im Kundendatensatz eingetragen wurde.


    Abgesehen von dieser Möglichkeit im Script kann sie natürlich auch mit E-Mail-Adressen angewendet werden, die auf dem betreffenden Server nicht gepflegt werden. Dann landen solche Mails bestimmt öfter im Spam-Ordner der Ziele.

  • Pl*k benötigt zwangsweise von jedem Benutzer/Kunden eine E-Mail-Adresse (u.a. um dann so beliebte Mails wie "We would like to hear your opinion about Pl*k" zu schicken).


    LiveConfig tut das eben nicht - in Bezug auf die DSGVO ist eine E-Mail-Adresse ein persönliches Datum, welches technisch nicht für die Erbringung der Dienstleistung (Webhosting) benötigt wird. Somit ist es prinzipiell schwer, eine Voreinstellung hierfür zu treffen.


    Wer seinen Endkunden die php.ini-Einstellung sendmail_from ermöglichen möchte, kann das mit zwei Mausklicks tun: in der php.ini-Verwaltung einen neuen Eintrag "sendmail_from" anlegen, Wert dabei leer lassen, und die Änderbarbeit auf "durch Kunden" einstellen. Dann kann jeder Kunde in seinen php.ini-Einstellungen hierfür einen Wert eintragen.

  • Pl*k benötigt zwangsweise von jedem Benutzer/Kunden eine E-Mail-Adresse (u.a. um dann so beliebte Mails wie "We would like to hear your opinion about Pl*k" zu schicken).


    LiveConfig tut das eben nicht - in Bezug auf die DSGVO ist eine E-Mail-Adresse ein persönliches Datum, welches technisch nicht für die Erbringung der Dienstleistung (Webhosting) benötigt wird. Somit ist es prinzipiell schwer, eine Voreinstellung hierfür zu treffen.


    Wer seinen Endkunden die php.ini-Einstellung sendmail_from ermöglichen möchte, kann das mit zwei Mausklicks tun: in der php.ini-Verwaltung einen neuen Eintrag "sendmail_from" anlegen, Wert dabei leer lassen, und die Änderbarbeit auf "durch Kunden" einstellen. Dann kann jeder Kunde in seinen php.ini-Einstellungen hierfür einen Wert eintragen.


    Finde ich nicht gut - Kunden wollen generell so wenig wie möglich mit der Technik zu tun haben. Das sagt die Erfahrung. Die meisten verstehen gar nichts, wenn man mit solchen Begriffen um sich wirft.


    Problem: der Kunde schickt per PHP-Mail Mails an irgendwelche Adressen, die zum Teil nicht erreichbar sind, z.B. Bestellbestätigungen aus Shops oder Anmeldemails usw. Diese Mails landen im Nirvana (oder besser dauerhaft in der Queue) und der normale Kunde weiß das nicht und ist im glauben, das die Mail an eine gültige Adresse verschickt worden ist.


    Gäbe es ansonsten bei "sendmail_from" einen Platzhalter der Mailadresse, die bei LC für den jeweiligen Kunden hinterlegt ist?

  • Finde ich nicht gut - Kunden wollen generell so wenig wie möglich mit der Technik zu tun haben. Das sagt die Erfahrung.


    Kann ich voll und ganz unterschreiben.


    Zitat

    Gäbe es ansonsten bei "sendmail_from" einen Platzhalter der Mailadresse, die bei LC für den jeweiligen Kunden hinterlegt ist?


    Genau das ist ja das Problem: es ist eben nicht unbedingt eine E-Mail-Adresse des LC-Kunden hinterlegt.


    Was ich mir vorstellen könnte, dass wir einen Platzhalter einführen, der - falls vorhanden - durch die E-Mail-Adresse des Hauptkontaktes (oder Tech-C) ersetzt wird. Falls keiner vorhanden ist, bleibt das Feld leer. Wir müssten aber noch testen, wie sich PHP bei einem leeren sendmail_from in der php.ini verhält (ich vermute aber, dass das funktionieren müsste). Als Zwangs-Option beim sendmail_path (-f) würde das aber garantiert Probleme geben, wenn dort keine Adresse drin steht.


  • Das wäre ein sehr guter Lösungsansatz, um dieses seit Jahren bestehende Problem in den Griff zu bekommen. Wir hinterlegen zu jedem Kunden seit Beginn an generell auch dessen aktuelle Mailadresse - die beste Vorsaussetzung also, diese Funktion zu integrieren. ;)

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!