Beiträge von Sumeragi

    Möglicherweise funktioniert dies nicht mit FastCGI. Schon Mal versucht auf PHP-FPM umzustellen? Wenn man im Angebot den Haken bei "SAPI Änderungen" setzt, kann je Endkunde der PHP Interpreter gesetzt werden.


    Nutze leider Apache 2.4 und damit funktioniert FastCGI nicht.


    Ich würde auch empfehlen auf Apache 2.4 umzustellen, da der Apache 2.2 End-of-Life ist und keinerlei Sicherheitsupdates mehr erhält.

    Dann spamd durchgestartet und per telnet von einem anderen Server eine Testnachricht geschickt. Das erzeugt im Logfile leider nur Einträge mit dem Merkmal Message tagged as spam by SpamAssassin und Spam mail safed to quarantine maildir.


    Was hab ich da wohl falsch gemacht?

    Sieht für mich soweit richtig aus. Wenn dort "Spam mail safed to quarantine maildir" steht, sollte die Mail in die Quarantäne Mailbox eingeliefert worden sein. Wie sieht denn der vollständige Log Eintrag dazu aus?

    smtp-auth ist nicht nur auf Port 587 möglich, sondern auch auf Port 25 und 465. Ich würde daher IPs direkt für alle drei Ports blocken.


    Auch kann es sein, dass nach einem Blocking wine bestehende Verbindung nicht sofort beendet wird. So lange können dann noch Versuche gestartet werden.

    Der Fehlermeldung nach fehlt die .bash_profile Datei unter /home/avwonabe/. Was passiert denn wenn die Datei manuell angelegt und dann die CLI Version gesetzt wird?


    Wäre auch noch interessant zu wissen welches Betriebssystem eingesetzt wird. Womöglich wird dort per Default keine .bash_profile angelegt.

    Bei meinem System mit CentOS 7 und SE 4-0.333 kam es ebenfalls zu keinem Fehler nach dem Update.


    Sucht man nach der Art des Fehlers tritt dieser wohl häufig mit dem "strict mode" auf. Auf meinem System ist dies nicht aktiviert:

    Code
    1. mysql> SHOW VARIABLES LIKE 'sql_mode';
    2. +---------------+-------+
    3. | Variable_name | Value |
    4. +---------------+-------+
    5. | sql_mode | |
    6. +---------------+-------+
    7. 1 row in set (0.05 sec)

    Wäre also die Frage, ob auf dem problematischen System der "strict mode" konfiguriert ist.

    Dann wäre der Mail-Header interessant. Dort sollte enthalten sein, weshalb Google die Mail als Spam eingestuft hat.

    Woran machen Sie das aus? Welche Fehlermeldung gibt es? Ich habe lediglich ein SPF Record in der Domain und keinerlei Probleme bei der Zustellung von Mails an Google. Halte es also nicht für ein allgemeines Problem und ohne weitere Informationen lässt schwer was dazu sagen.

    Bei allen Zertifikaten die wir bisher hatten muss nach dem install-script die Datei überarbeitet werden und der Zeilenumbruch manuell rein.

    /var/qmail/control/servercert.pem

    Dieses Problem hatte ich bisher nie. Wie tbc233 schrieb, wird es wahrscheinlich daran liegen in welchem Format die Dateien ausliefert werden.

    Von der Schilderung her hatte ich den Eindruck, sämtliche Mails mit PDFs seien betroffen. Ich hatte bisher keinerlei Probleme. Als ich es heute getestet hatte, war die Signatur bereits aktualisiert und eine Testzustellung erfolgreich. Da zuvor bereits ein Erfolg mit aktualisierter Signatur vermeldet wurde, hatte ich dies ebenfalls bestätigt. Ich nahm an, das Problem sei somit behoben.


    Man bräuchte also einmal eine PDF, womit das Verhalten reproduzierbar ist.

    Die Version 7.1.1 sollte es in der SE 0.332 nicht mehr geben. Bei mir sieht dies so aus

    Worauf zeigt denn die cli Binary?

    Code
    1. # ls -al /usr/local/pd-admin2/bin/php-7.1-cli
    2. lrwxrwxrwx. 1 root root 43 6. Mai 15:39 /usr/local/pd-admin2/bin/php-7.1-cli -> /usr/local/pd-admin2/php-7.1.29/bin/php-cli

    tbc233 mein Log sagte folgendes:


    Code
    1. Apr 29 12:37:30 ironman greylisting[23229]: sender *************@googlemail.com, address 2a00:1450:4864:20::32e: missing PTR record.

    Macht man ein whois auf die IP, sieht man dass diese zu Google gehört. Allerdings hat die IP ein gültigen PTR Record, wie ich jetzt im Nachhinein feststelle.


    Ich hatte jedenfalls Probleme bei der Zustellung nach Aktivierung von IPv6. Offenbar kann das Greylisting Skript IPv6 Adressen nicht korrekt auflösen. Folglich werden Mails von IPv6 Adressen nicht angenommen, wenn die Annahme von Adressen ohne PTR-Record verweigert wird. Dies vermute ich auch hier als Problem.

    Ist in der Serverkonfiguration von pd-admin eingestellt, dass Mail-Server ohne PTR-Record abgelehnt werden? Die Google Mail-Server haben nämlich kein PTR-Record. Dies sollte auch entsprechend im Mail Log protokolliert sein.


    Interessant wäre zudem, ob im System Log die Verbindungen des smtpd von Google geloggt werden. Im Mail Log werden die Zustellungen und Logins protokolliert, im System Log die Verbindungen. Wenn eine Verbindung Zustande kommt, wird dies geloggt.

    An dem Zertifikat sollte es nicht liegen. Comodo bzw. Sectigo wird von Google afaik problems akzeptiert.


    Ich verwende auf meinem Server ebenfalls IPv6. Mails werden zu Google und von Google per IPv6 zugestellt. Da konnte ich bisher keinerlei Probleme feststellen.


    Bei backscatterer.org wird man gelistet, wenn der Server viele Bounce-Mails erzeugt und diese immer hin und her gehen. Dies muss nicht zwingend mit Google zusammen hängen, kann aber ein Indiz sein. Eigentlich ist backscatterer.org keine richtige Spam-Blacklist und sollte auch nicht zum filtern verwendet werden.


    Wurde einmal mit

    Code
    1. /usr/local/pd-admin2/sbin/qmHandle -s
    2. /usr/local/pd-admin2/sbin/qmHandle -l
    3. /usr/local/pd-admin2/sbin/qmHandle -vMESSAGEID

    geprüft ob und was da so in der Mail-Queue hängt?

    Ansonsten muss man sich einmal die Mail genauer anschauen, die von Google abgelehnt wird. Sind z.B. Absender, Return-Header oder SPF korrekt?

    Ich würde vermuten, durch das Upgrade würden libs aktualisiert und entweder gibt es dadurch eine Inkompatibilität oder es fehlt eine andere lib. Vielleicht kann ja ein anderer Debian 9 Nutzer seine installierte(n) *libc* Pakete auflisten?