Beiträge von MAD M!NDWORX

    Dafür habe ich mir das hier gebaut.


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

    Code
    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.

    Ich habe einen neuen Server mit pd-admin aufgesetzt und die Amazon Benachrichtigungen an ein dortiges Postfach senden lassen.


    Leider ist auch da das Problem, dass die Mails nicht zugestellt werden. Einziger Log Eintrag:


    Code
    Nov 27 12:15:42 neuerserver greylisting[25722]: sender ***@sellernotifications.amazon.com, address 54.240.1.35 bypassed: SPF ok.


    Danach passiert nichts mehr. Im syslog steht:


    Code
    Nov 27 12:15:42 neuerserver greylisting[25722]: sender ***@sellernotifications.amazon.com, address 54.240.1.35 bypassed: SPF ok.
    Nov 27 12:15:42 neuerserver smtpd: 1574856942.218321 tcpserver: end 25721 status 256
    Nov 27 12:15:42 neuerserver smtpd: 1574856942.218345 tcpserver: status: 0/450


    Diesmal Status 256, auf dem alten Server immer Status 0.


    Kann ich irgendwie ein komplettes LOG der Verbindung erstellen, um ggf. den Auslöser des Verbindungsabbruchs zu finden?


    Werden denn bei euch die Sellernotifications problemlos zugestellt?

    Erst einmal Dankeschön für die Antworten!


    Im Syslog ist auch nichts auffälliges, daher bin ich echt verwundert, dass nur die Amazon Seller Notifications nicht durchkommen:


    Nov 21 07:24:19 *** greylisting[870]: sender ***@sellernotifications.amazon.com, address 54.240.1.50 bypassed: SPF ok.

    Nov 21 07:24:19 *** smtpd: 1574317459.533300 tcpserver: end 430 status 0

    Nov 21 07:24:19 *** smtpd: 1574317459.533316 tcpserver: status: 4/40


    Ich werde mal den Spamdyke deaktivieren und schauen, ob es vielleicht daran liegt. Wobei der eigentlich auch melden müsste, wenn da was abgewiesen wird. Und auf den eingesetzten Blacklisten sind die amazon Mailserver nicht eingetragen, das habe ich geprüft.


    Der Kunde, der das Problem meldete, hat sich schon mit der Amazon Technik in Verbindung gesetzt und diese meinten, alles sei OK.


    Wenn auch das Abschalten von Spamdyke nicht hilft, werde ich den Kunden auf einen anderen Server legen und hoffen, dass sich das Verhalten dann gibt. Wobei mir eine Problemlokalisierung und -lösung ansich lieber wäre.

    Lieber pd-admin Mitnutzer!


    Seit gut einer Woche werden Nachrichten von @sellernotifications.amazon.com offensichtlich nicht mehr an qmail übergeben.


    VORHER:

    Nov 3 04:32:41 *** greylisting[29606]: sender ***@sellernotifications.amazon.com, address 54.240.1.5 bypassed: SPF ok.

    Nov 3 04:32:48 *** qmail-smtpd: qmail-smtpd/VC started

    Nov 3 04:32:49 *** qmail: 1572751969.579792 new msg 60907772

    Nov 3 04:32:49 *** qmail: 1572751969.579809 info msg 60907772: bytes 6133 from <***@sellernotifications.amazon.com> qp 30232 uid 1011

    Nov 3 04:32:49 *** qmail-smtpd: qmail-smtpd/VC started

    Nov 3 04:32:50 *** qmail: 1572751970.375127 starting delivery 125735: msg 60907772 to local ***@***

    Nov 3 04:32:50 *** qmail: 1572751970.375145 status: local 1/10 remote 0/20

    Nov 3 04:32:51 *** dovecot: lda(***): msgid=<***@eu-west-1.amazonses.com>: saved mail to INBOX


    JETZT:

    Nov 21 07:24:19 *** greylisting[870]: sender ***@sellernotifications.amazon.com, address 54.240.1.50 bypassed: SPF ok.

    Nov 21 07:24:21 *** qmail-smtpd: qmail-smtpd/VC started


    Danach erfolgt keine Verarbeitung mehr durch qmail.


    Am kompletten System wurde nichts geändert. qmail softlimit steht auf 128000000.


    Greylisting ist in der Serverkonfiguration deaktiviert, keine Ahnung warum die Mail trotzdem an den Prozess übergeben wird.


    Ist euch sowas auch mal vorgekommen? Wie habt ihr das gelöst?


    Dankeschön und Grüße,

    m.

    Aus aktuellem Anlass: Es kommt in letzter Zeit sehr häufig vor, dass einige t-online Mailserver auf der bl.spamcop.net Blacklist landen. Dann werden nicht mehr alle Mails von t-online Absendern angenommen (je nach verwendetem mailout Server). Das ist natürlich nicht optimal!


    Ist es möglich, whitelisten zu definieren, die die blacklisten "überbieten"? So dass z.B. alle t-online Mailserver trotzdem durchgelassen werden, selbst wenn sie auf bl.spamcop.net gelistet sind?

    Das haben wir schon versucht.


    Es ist kein mysql Standard sondern wird Teil des Templatesystems der von Dir verwendeten Software sein.


    Da hilft nur: Mehr Infos zur Software geben oder einfach mal an den Entwickler wenden.