Beiträge von weltmeister


    Ist denn ein "DKIM-Signature:"-Header in versendeten E-Mails enthalten?


    Nein, dieser fehlt, ist auch im Quelltext nicht ersichlich.



    Wenn nein, was taucht alles in /var/log/mail.log auf, wenn eine E-Mail versendet wird?


    Nichts ungewöhnliches meiner Meinung nach:


    Code
    Jan 23 14:34:46 s1 postfix/smtps/smtpd[12921]: 265C42D0005: client=p4FD1FDC1.dip0.t-ipconnect.de[79.209.253.193], sasl_method=CRAM-MD5, sasl_username=info@domain.de
    Jan 23 14:34:46 s1 postfix/cleanup[9742]: 265C42D0005: message-id=<5f6937f2-f678-2cb4-ddce-e5bc15fa841b@domain.de>
    Jan 23 14:34:46 s1 postfix/qmgr[9011]: 265C42D0005: from=<info@domain.de>, size=1257, nrcpt=1 (queue active)
    Jan 23 14:34:46 s1 postfix/smtp[13385]: 265C42D0005: to=<xxxxx@freenet.de>, relay=emig.freenet.de[195.4.92.217]:25, delay=0.43, delays=0.12/0.02/0.12/0.18, dsn=2.0.0, status=sent (250 OK id=1edyis-0000dN-EE)
    Jan 23 14:34:46 s1 postfix/qmgr[9011]: 265C42D0005: removed

    Ja, oft. Wir haben letztendlich den täglichen Endkundenkontakt.


    Zitat

    Jeder 0815-Hoster, wie 1und1 & Co. bieten diese Weiterleitungsart an, warum ist das hier nicht möglich?


    Soetwas bekommen wir teilweise von den Kunden zu hören.

    Betrifft die Mails, die durch DNS-Blacklists abgewiesen werden: hier sollte dem Kunden die möglichkeit (auswahl) angeboten werden, ob diese Mails abgwiesen werden oder in einen Spamordner verschoben werden.
    Es kam schon oft vor, dass für einen Kunden wichtige Mails nicht angekommen sind, die Kunden flippen dann regelrecht aus. Deaktiviert man die DNS-Blacklists, werden alle mit Spam überhäuft. Es muss also eine sinnvolle Lösung her. (Bei Plesk gibt es genau diese Funktion bereits)

    Konnte es lösen. Hatte nicht beim webspace bei PHP FastCGI gespeichert


    Man sollte mit Debian 9 eigentlich sowieso nur noch FastCGI in diesem Menüpunkt auswählen können, wenn kein suPHP mehr vorhanden ist. Genau das Problem hatte ein Reseller auch, der hat stundenlang nach dem Fehler gesucht, dabei war es nur so eine Kleinigkeit.

    ... und genau diese Einstellungen kann doch jeder Kunde in seiner htaccess-Datei mauell setzen / überschreiben, d.h. er überschreibt die global-gesetzten Einstellungen durch seine eigenen. (Bei uns funktioniert das zumindest so ohne Probleme)


    Allerdings wäre eine solche Funktion angebracht, bei Plesk kann man diese Header komfortabel über die Weboberfläche eintragen / ändern. Eine Sache, die es früher bei Confixx in ähnlicher Form schon gab.

    nicht "localhost" setzen, sondern "127.0.0.1". Dann geht die Kommunikation über TCP.


    Danke, das wurde testweise geändert. Leider kein Erfolg.


    Die Datei 50-client.cnf sieht so aus:



    Die Fehlermeldung lautet nach wie vor:


    Zitat

    #2002 - Connection refused &mdash; Der Server antwortet nicht (evtl. ist der Socket des lokalen MySQL-Servers nicht korrekt konfiguriert).


    Hat jemand eine Idee?

    Wenn die phpmyadmin-Installation auf dem gleichen Server ist (localhost) ist keine Verbindung möglich.


    Herr Keppler hat dazu folgende Info geschickt:


    Zitat

    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864662
    Debian 9 ist installiert) in /etc/mysql/mariadb.conf.d/50-client.cnf fehlt folgende Zeile:


    socket = /var/run/mysqld/mysqld.sock


    Ohne diesen Eintrag können einige Anwendungen bei "localhost"-Verbindungen nicht den MySQL-Socket finden.


    Leider schafft dies keine Abhilfe. Von allen "externen" Servern ist der Zugriff jedoch möglich. Hat jemand eine andere Idee?


    Auszug aus der config.inc.php:


    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.

    Auch hier muss ich wieder auf Plesk verweisen: viele Kunden, die vorher Plesk genutzt haben, wünschen sich auch für LiveConfig einen solchen Dateibrowser.


    Ich selbst würde diese Funktion auch sehr begrüßen, mit der möglichkeit, Dateien zu verändern, löschen, bearbeiten, verschieben, komprimieren usw.

    Danke, das hat leider nicht funktioniert und in der Dokumentation findet man kein Wort dazu. Das sollte ggf. mal mit ergänzt werden. Besser wäre eine Möglichkeit, dies direkt in der Oberfläche komfortabel festlegen zu können.

    Gibt es die Möglichkeit, PHP 7.2. als Standard für neu angelegte Accounts zu verwenden? Das würde ein paar Klicks zusätzlich einsparen.