Mailserver ohne PTR record lehnt ALLE Mails ab

  • PD-Admin Version: v4.81 64bit

    Debian 9

    SE: 6-0.380


    Seit dem Update der PD-Admin-Version lehnt der Server ALLE eingehenden mails mit "missing PTR Record" ab wenn das eingeschaltet ist:v


    Jun 7 14:57:21 server15 greylisting[27812]: sender service@xxxxxxxx.de, address 52.100.174.xxx: missing PTR record.

    Jun 7 14:57:21 server15 greylisting[27818]: sender servizio@xxxxxxx.it, address 40.107.21.xxx: missing PTR record.

    Jun 7 14:57:21 server15 greylisting[27819]: sender service@xxxxxxxx.de, address xxx:111:xxx:xxx::30d: missing PTR record.

    Jun 7 14:57:22 server15 greylisting[27826]: sender servizio@xxxxxxxx.it, address 40.107.21.xxx: missing PTR record.

    Jun 7 14:57:22 server15 greylisting[27831]: sender servizio@xxxxxxxx.it, address xxx:111:xxx:xxx::62d: missing PTR record.


    Erst wenn ich die PTR-Prüfung abschalte kommen die Mails rein.


    Jun 8 08:51:58 server15 greylisting[2413]: sender manfred.onderka@onit-gmbh.de, address 87.191.185.204: missing PTR record.


    Nach Abschaltung der PTR-Prüfung und Ablehnung

    Jun 8 08:54:10 server15 greylisting[5476]: sender manfred.onderka@onit-gmbh.de, address 87.191.185.204 bypassed: SPF ok.

    Jun 8 08:54:12 server15 qmail: 1623135252.596577 info msg 69075050: bytes 8526 from <manfred.onderka@onit-gmbh.de> qp 5529 uid 1016

    Jun 8 08:54:13 server15 qmail: 1623135253.147768 info msg 69075034: bytes 8691 from <srs-SRS0=aEnKiTj+=LC=onit-gmbh.de=manfred.onderka@server15.xxxxxxx.de> qp 5561 uid 1029




  • Ich kann das nicht bestätigen, eben sicherheitshalber nochmal getestet.

    Für die weitere Fehlersuche: Ich würde mal andere Nameserver in Deiner resolv.conf antesten.


    (Info: Habe Beitrag nachträglich editiert, hatte zunächst behauptet die Zurückweisungen wären legitim da tatsächlich kein PTR Record vorhanden wäre, das war absoluter Quatsch. Sorry, man sollte halt keine Fehlersuche betreiben während man nebenbei telefoniert)

  • hm. rätselhaft.

    Mindestens meiner hat ja einen PTR-Record:


    dig -x 87.191.185.204


    ; <<>> DiG 9.10.3-P4-Debian <<>> -x 87.191.185.204

    ;; global options: +cmd

    ;; Got answer:

    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4816

    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1


    ;; OPT PSEUDOSECTION:

    ; EDNS: version: 0, flags:; udp: 512

    ;; QUESTION SECTION:

    ;204.185.191.87.in-addr.arpa. IN PTR


    ;; ANSWER SECTION:

    204.185.191.87.in-addr.arpa. 86114 IN PTR david.onit4u.de.


    ;; Query time: 21 msec

    ;; SERVER: 192.168.181.1#53(192.168.181.1)

    ;; WHEN: Tue Jun 08 09:23:31 CEST 2021

    ;; MSG SIZE rcvd: 85

  • Wie oben editiert, sorry - ich hatte anfänglich behauptet die Rückweisungen wären legitim und hatte dass sogar mit einem dig Schnipsel belegt, der zeigt dass es durchaus NICHT legitim war ;-)
    War leider abgelenkt.


    Wie auch immer, nachvollziehen kann das Problem nicht auf meinen Servern und ich denke auch andere hier wären schon von Ihren Anwendern gelyncht worden wenn es so wäre. Daher glaubte ich hier eher an ein lokales DNS Problem und würde mal entsprechend testen. Zum Beispiel mal irgendeinen anderen Nameserver in die resolv.con rein machen.

  • Auf beiden Servern die bei hetzner stehen sind die PTR Auflösungen korrekt, aber sobald ich im PD-Admin Mails ohne gültigen PTR auf ablehnen stelle werden ALLE eingehenden mails abgelehnt.

    Jetzt auf allen Maschinen aufgetreten mit Debian10, Debian9 und CentOS8 bei mir.


    dig -x 40.107.21.88


    ; <<>> DiG 9.10.3-P4-Debian <<>> -x 40.107.21.88

    ;; global options: +cmd

    ;; Got answer:

    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33925

    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1


    ;; OPT PSEUDOSECTION:

    ; EDNS: version: 0, flags:; udp: 4096

    ;; QUESTION SECTION:

    ;88.21.107.40.in-addr.arpa. IN PTR


    ;; ANSWER SECTION:

    88.21.107.40.in-addr.arpa. 3331 IN PTR mail-vi1eur05on2088.outbound.protection.outlook.com.


    ;; Query time: 0 msec

    ;; SERVER: 213.133.99.99#53(213.133.99.99)

    ;; WHEN: Tue Jun 08 09:37:15 CEST 2021

    ;; MSG SIZE rcvd: 119

  • Bei der IP scheint doch ein Tobit-eMail-Server zu laufen, wenn ich mich mit der 87.191.185.204 verbinde, dann kommt:


    220 david.onit4u.de Service ready by david3 (0603) ESMTP Server (Tobit.Software, Germany)


    Hast Du es mal von GMX oder einem anderen Anbieter versucht?


    Denn ich kann auch auf keinem Server ein Problem nach dem Update feststellen.

  • Das fällt mir aktuell auf diesen geupdateten Server im messages Logfile auf:


    09:26:07 server10 smtpd[2880563]: 1623137167.561107 Use of uninitialized value $Sys::Hostname::Long::hostlong in pattern match (m//) at PERL2EXE_STORAGE/Sys/Hostname/Long.pm line 166.


    /usr/bin/perl ist aber auf /usr/local/pdadmin/bin/perl gelinkt

  • Also, es muss an der 64bit PD-Admin 4.81 liegen.

    Wenn ich die 32-bit Variante bei Debian9 und CentOS8 (was vorher auch verwendet wurde) drüber installiere werden die PTR-Ablehnungen auch nur dann abgelehnt wenn es tatsächlich keinen PTR gibt.


    Hat jemand schonmal bei Debian9 und CENTos8 die 64-bit umgestellt?

  • Auf jedenfall ist das Problem erstmal gelöst wenn ich die 32-bit Varianten verwende, dann sind auch die PERL2EXE_STORAGE Meldungen weg, sowohl auf Debian9 als auch CentOS8.
    Bei Debian10 scheint die 64-bit variannte dieses Verhalten nicht zu haben.

  • Hier können durchaus Distributions- bzw. Kernelversions abhängige Unterschiede sein. Als ich zuletzt hier Probleme hatte (wenn auch mit anders gelagerter Fehlermeldung, aber es war ebenfalls PERL Zeugs), musste ich auf meinen Gentoo Servern auf 125000000 erhöhen, auf meinen Centos Servern war das nicht nötig. Probiers mal.

  • Ich habe jetzt alle auf 128000000 gesetzt.
    Nachdem ich das hier auch gefunden habe was zwar anders ist aber auch ähnlich klingt.


    RE: Fehlermeldung im Zusammenhang mit smtpd


    Auf dem CentOS8 habe ich den qmail-smtpd neu gestartet und die 64bit Version nochmal drüber installiert.

    Schaut auf den ersten Blick aus als wäre das das die Lösung. Ich beobachte das bis morgen bevor ich das weiter ausrolle und hier ggf. vollzug melden kann.


    Danke an alle. Das Forum ist wirklich toll und funktioniert wirklich. DANKE DANKE