Beiträge von HBO

    Und wer mit dem debuggen und einstellen der korrekten Konfiguration nicht zurecht kommt baut sich hier am Besten noch eine Open Relay Spam Schleuder auf. Ich verstehe auch bis heute nicht wieso man auf Webseiten keinen vernünftiges PHP Mail mit SMTP Auth herstellt, was hat (auch wenns nur ein sendmail ist) ein Mailserver auf nem Webserver zu suchen?


    Wie alle Anderen schon schrieben:
    DNS Einträge prüfen
    Postfix Konfiguration prüfen


    Erhält der eigentliche Mailserver der die Mail empfangen soll/wollte auch einen Log Eintrag?

    Der Wert "Auto-Konfiguration" gibt ja auch nur die URL an unter der die Autodiscover Konfiguration liegt (Apache Seitig).


    Der effektive SMTP Wert für den Mail Client als SMTP Server kommt aus "SMTP Konfigurieren" Tab "Allgemein" und zwar hier der Servername. Entweder als "Standard" und damit der FQDN Hostname oder halt alternativ auf "manuell" der richtige Host.


    Funktioniert bei uns unter Ubuntu 14.04 und CentOS 6 (2 verschiedene Business <> Standard Instanzen) einwandfrei.

    Das mit dem nil sollte man ggfl mal in den MultiPHP Wiki Eintrag übernehmen, dazu gabs ja schon diverse Fragen.

    Sieht bei mir so aus und funktioniert einwandfrei:
    LC.web.addPHP(nil, "/opt/php-5.5/bin/php-cgi")
    LC.web.addPHP("php53", "/opt/php-5.3/bin/php-cgi")
    LC.web.addPHP("php54", "/opt/php-5.4/bin/php-cgi")
    LC.web.addPHP("php56", "/opt/php-5.6/bin/php-cgi")
    LC.web.addPHP("php70", "/opt/php-7.0/bin/php-cgi")
    LC.web.addPHP("php71", "/opt/php-7.1/bin/php-cgi")


    Die 5.5 wird damit als Standard ausgewählt. Gilt glaube aber auch nur für Neuverträge bzw sobald eine neue Domain hinzu gefügt wird. Bestehende Einträge mit Auswahl werden meines Wissens nach nicht überschrieben.

    Wir haben das über DNS geregelt, alte Konfiguration war ein PowerDNS, nach der Migration wurde LC
    mit BIND genutzt. Man hat also in LC soweit alles voreingestellt, der Kunde machte letzte Anpassungen. Am Ende wurde nur der zuständige DNS in der Domain geändert, fertig.


    Sofern in LC irgendwas deaktiviert wird, wird auch nur die Leistung gesperrt. Sei es der Login in LC selbst, bei Mails der Zugang oder bei Webspace wird auf eine Custom 404 weiter geleitet. Entspricht eigentlich genau dem was es tun soll. Änderungen an den Settings zBsp eine DNS Änderung etc pp halte ich für rechtlich problematisch.

    Die Integration mit Liveconfig ist schonmal eine Hürde, ich habe es dann doch lieber gelassen da ich nicht so viel in der custom.lua arbeiten wollte oder gar Liveconfig mit manueller Postfix Konfiguration. Am Ende ist das System nun komplett manuell verwaltet.
    Ansonsten konfiguriert man Kaspersky einmal, man sollte aber doch Wartungsaufwand zwecks anlernen etc rein stecken.

    Naja, das selbst zu bauen ist ja nun nicht wirklich schwer um zum einen Unabhängig zu sein bis ein Update etc pp kommt und man die PHP Version so hat wie man das gerne möchte. Einmaliger Aufwand: Einen configure/build Befehl schreiben und ggfl Abhängigkeiten installieren. Nach jedem PHP innerrelease Update neue Sourcen ziehen, Befehl drüber laufen lassen, freuen.
    Wir nutzen zBsp auch gerne vorwiegend die Module als "shared" und laden bei den Kunden nur die am häufig genutzten Module vor, alle anderen Module kann der Kunde in den PHP Einstellungen in LC manuell aktivieren.


    @ KK - Wie Ihnen sicher nicht entgangen ist - LC 2.2.3 ist tatsächlich fast 1 Jahr alt - das Problem, welches ich meine, besteht allerdings seit DREI Jahren ......


    ....


    Und sicher ist mir bekannt, wo ich welche (sorry) angeblichen Verbesserungen nachlesen kann, denn ich bin ein sehr aufmerksamer Leser - gerade aus diesem Grund mache ich nicht jedes Update sofort.


    Tatsächlich?
    Änderungen in Version 2.3.0-r4555 (05.05.2017):
    ...
    Neustart von LiveConfig-Diensten (lclogparse, lcpolicyd, lcsam) nach Paket-Aktualisierung verbessert


    Immer schön das man nicht updatet und auch Linux Security Fixes damit nicht mitnehmen will, einfach nur zum Kopfschütteln.

    Logisch ist das richtig so, es gibt ja nicht umsonst noch "Server verwalten" und "Server hinzu fügen". Zugriff auf den jeweiligen Server muss der User haben um dort die Dienste zu nutzen.

    Wie gesagt, sind nur Beispiele. Ich würde hier nun nicht die gesamte eingesetzte Konfiguration posten, ist mehr oder weniger eine Wissenschaft für sich. Nicht umsonst zahlt man für zwischen geschaltete Anti Spam Gateways einiges an Geld.

    Mal einfach ein paar Beispiele (hab keine Spoiler Funktion gefunden):
    65_debian.cf


    init.pre

    Code
    loadplugin Mail::SpamAssassin::Plugin::URIDNSBL
    loadplugin Mail::SpamAssassin::Plugin::Hashcash
    loadplugin Mail::SpamAssassin::Plugin::SPF


    local.cf


    Ansonsten noch die v3xx.pre Dateien angepasst. Anschauen sollte man sich auch in jedem Fall mal die Dateien in /usr/share/spamassassin und in eigene Konfiguration gewünschte Änderungen laden (so passiert hier erstmal nichts bei einem SA update).


    Empfehlenswert sind dann noch folgende Seiten:
    http://www.spamtips.org/p/ultimate-setup-guide.html
    http://www.spamtips.org/2011/02/smfbracketsto-rule.html
    http://mailspike.net/usage.html