Beiträge von MAD M!NDWORX

    Der Tipp mit Cloudmark war goldrichtig! Die neue ServerIP war wohl vorbelastet. Alle Blacklistentests (kloth, rbl, mxtoolbox) zeigten alles grün, testen aber nicht auf Cloudmark. Nach kurzem Kontakt mit dem Support wurde die IP von der Blacklist gestrichen. Mal ehrlich: Das hätte hosteurope aber auch mal kommunizieren können anstatt der "wir geben Ihnen keine Auskunft, weil Sie nicht Kunde bei uns sind" Antwort. Oder wenigstens den Mailserver ein "blacklisted" zurückmelden lassen anstatt die Verbindung zu kappen.


    Vielen Dank für die Hilfe!

    Leider scheint es nicht an SPF/DKIM zu liegen. SPF war ja schon gesetzt, DKIM habe ich dazu genommen. Trotzdem erscheint immer noch "connection died".


    mail-tester.com gibt den Mails der Absender einen Score 10/10, also sollten die valide sein.


    Etwas Recherche führte zu Infos, dass es an den MTU liegen könnte. Diese liegen bei 1500, wie auch bei anderen Servern, die problemlos Mails an 80.237.138.5 zustellen können -- nur die laufen auf Debian statt centos.


    Hat sonst jemand vielleicht noch eine Idee, woran das sofortige "connection died" liegen könnte? Dankeschön!

    Hallo.


    Ich habe einen neuen Server mit CENTOS 8 aufgesetzt mit der Standardumgebung.


    Im maillog fällt auf, dass E-Mails an den hosteurope Mailserver nicht zugestellt werden, da die Verbindung im selben Moment gleich wieder beendet wird.


    Mar 19 11:40:34 xxxxx qmail[23583]: 1616154034.546906 starting delivery 11005: msg 24925158 to remote xxxx@xxxx.de

    Mar 19 11:40:34 xxxxx qmail[23583]: 1616154034.897424 delivery 11005: deferral: Connected_to_80.237.138.5_but_connection_died._(#4.4.2)/


    Andere Mailserver haben absolut kein Problem und nehmen Mails an. Am Inhalt der Mails sollte es nicht liegen, es sind verschiedene Empfänger mit verschiedenen Mailinhalten.


    Die IP ist auf keiner relevanten Blacklist.


    Nun möchte Hosteurope "aus Datenschutzgründen" keinen Kontakt mit mir, die EMPFÄNGER der Mails sollen sich mit dem Hosteurope Support in Verbindung setzen. Bisher hat dies aber wahrscheinlich keiner getan und möglicherweise fehlt da auch die Motivation.


    Hatte das schonmal jemand und kann ggf. einen Lösungsvorschlag machen?


    Vielen Dank!

    Dafür habe ich mir das hier gebaut.


    /usr/local/pd-admin2/htdocs/autoconfig/mail/.htaccess

    Apache Configuration
    RewriteEngine on
    RewriteRule autodiscover\.xml$ autoconfig.php [L]
    RewriteRule Autodiscover\.xml$ autoconfig.php [L]
    RewriteRule config-v1\.1\.xml$ autoconfig.php [L]


    /usr/local/pd-admin2/htdocs/autoconfig/mail/autoconfig.php


    in /usr/local/pd-admin2/conf/httpd.conf-template eintragen:


    Der Hostname des Mailservers wird hier allerdings nicht aus der Konfiguration genommen, sondern fest in der autoconfig.php eingetragen. Geht mit Sicherheit auch eleganter.

    Hallo.


    Ich habe seit dem Update auf pd-admin 4.66 auch das Problem, dass ich die Adminoberfläche nicht mehr aufrufen kann. Login funktioniert, aber danach kommt der 500er Fehler. Im Errorlog steht nur "End of script output before headers: administrator.cgi"


    Mit pd-admin 4.65 lief alles problemlos!


    System: Debian 9

    SE: 6.365

    pd-admin: 4.66

    Apache: 2.4


    Wie kann ich nachvollziehen, warum es bei der administrator.cgi knallt?

    Wie kann ich testweise wieder auf pd-admin 4.65 zurück, um wenigstens ein paar Einstellungen vorzunehmen?

    Für 85.25.93.254 ist als Name mail.myinfinity.life festgelegt, aber für mail.myinfinity.life wurde kein A Eintrag vorgenommen. Das müsstest Du noch machen, A Eintrag für mail.myinfinity.life auf 85.25.93.254

    Das Zertifikat muss einmal manuell per certbot erstellt werden. Dies sieht so aus:


    /opt/pdadmin/bin/certbot-auto certonly --webroot -w /usr/local/pd-admin2/htdocs -d hostname.server.tld


    hostname.server.tld wird durch den pd-admin Hostnamen ersetzt.


    Anschließend müssen Symlinks für Certs/Key erstellt werden:


    ln -s /etc/letsencrypt/live/hostname.server.tld/cert.pem /opt/pdadmin/sslcerts/hostname.server.tld-cert

    ln -s /etc/letsencrypt/live/hostname.server.tld/fullchain.pem /opt/pdadmin/sslcerts/hostname.server.tld-cacert

    ln -s /etc/letsencrypt/live/hostname.server.tld/privkey.pem /opt/pdadmin/sslcerts/hostname.server.tld-key


    Anschließend dann /opt/pdadmin/bin/httpd_vhosts.pl ausführen, damit die Konfiguration neu geschrieben und geladen wird.


    Quelle: https://www.cajus.name/2018/03…r-hostnamen-mail-dienste/ (Letzter Kommentar, hier etwas spezifischer aufgelistet)


    Wichtig ist dann noch, dass das Zertifikat für den Mailserver immer automatisch erneuert wird. Das Script dazu ist auch auf der Seite zu finden.


    Viel Erfolg!

    Majjo: Ist mir auch aufgefallen bei meiner Neuinstallation. Hier hilft der von Monderka gepostete Fix:


    Code
    chmod u+s /opt/pdadmin/bin/forward_filter


    Der Besitzer kann auf root:root bleiben.


    Achja, ebenfalls bei frischen Installationen nicht zu vergessen:

    Code
    printf "1" > /var/qmail/control/ignorewronganswer


    Sonst gibt es DNS Probleme mit qmail.