Kein Mailempfang von GMail

  • Ein von mir betreuter Server nimmt seit gestern morgen keine Mails von GMail mehr an, zumindest scheint es so, dass es an der Serverkonfiguration liegt.
    In /var/log/mail.log taucht überhaupt nichts der Art auf, es ist so als würde die Mail den Server garnicht erreichen.

    Die Fehlermeldung von Google kommt nach knapp 24 Stunden und lautet:

    Zitat

    The recipient server did not accept our requests to connect. Learn more at https://support.google.com/mail/answer/7720


    Was mir dazu einfällt:

    • ich habe letzte Woche das Zertifikat getauscht und Comodo statt Letsencrypt verwendet. Hostname stimmt, installiert habe ich es mit dem Script "dc-ssl-install.sh" von B&K.
    • Ich verwende fail2ban mit IP-Tables, augenscheinlich gibts aber auf der Ban-Liste keine IP von Google. Aber Sicherheitshalber habe ich mal durchgestartet und den Filter dadurch gelöscht, das ergab aber keine Änderungen
    • Ich verwende zusätzlich IPv6 weil damit der Traffic kostenlos ist und ich mit einem Kollege darüber HD Space für Dateisicherungen teile.
    • Der Server wird aktuell von http://www.backscatterer.org/ gelistet, angeblich aber schon seit dem 11.5. Das manuelle Delisting soll 89 Franken kosten, was ich als unseriös empfinde und deswegen nicht mache.

    Mehr Besonderheiten oder Ursachen gibts eigentlich nicht.


    Ich habe keine Idee, was hier falsch läuft.


    Viele Grüße,

    Martin

  • 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?

  • Danke für deine Antwort,

    Ansonsten muss man sich einmal die Mail genauer anschauen, die von Google abgelehnt wird.

    es ist ja so dass keine Mails von Gmail HEREIN kommen. Dabei haben verschiedene Absender an verschiedene Empfänger auf demselben Server dieselben Probleme. Es ist also kein domainbezogenes Problem

    Mailausgang von dem betroffenen Server AN Gmail klappt problemlos.


    Viele Grüße,

    Martin

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

  • Ich würde ausnahmsweise Sumeragi widersprechen, meiner Erfahrung nach haben die einliefernden gmail Mailserver durchaus einen PTR Record.


    Ich würde im ersten Schritt auch nochmal alle Logs abklopfen. Manchmal ist das setup des systemloggers etwas ungeschickt, sodass vielleicht relevante Meldungen in einem anderen Log gelandet sind. Ich würde hier an Deiner Stelle Mails von einem gmail Konto schicken und nebenbei live am Server mit schauen.


    Sollte sich tatsächlich rausstellen, dass gmail weiterhin sagt dass Dein Server die Mails ablehnt OHNE dass Du auch nur irgendwas im Log davon mitbekommst, würde ich als nächstes andere Ursachen prüfen. Als erstes würde mir ein ipv6 Problem einfallen. gmail stellt bevorzugt per ipv6 zu. Ein denkbares Szenario wäre zum Beispiel, dass Du einen Hostnamen im MX Record hast, der einen AAAA Record hat, eine Kontaktaufnahme an diese ipv6 Adresse aber aus irgendeinem Grund nicht funktioniert.

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

  • Es ist tatsächlich so, dass ich in den Logs überhaupt nichts sehe. Allerdings muss ich mit der IPv6 Sache zurückrudern, das war ein anderer Server, da hab ich was durcheinander gebracht. Der betroffene Server hat kein IPv6, der MX Hostname ist ein A Record und verweist auf die Server-IP.

    Allerdings ist der Hostname des Servers (vom Provider vergeben) ein anderer als der eMail-SSL-Hostname, den wir an die Kunden rausgeben,

    Der Server meldet sich mit seinem Hostnamen im SMTP Dialog.
    Auch das lief aber vorher schon viele Monate problemlos.


    Macht es Sinn hier mal ein paar records zu posten oder andere Zusammenhänge darzustellen?

  • Macht es Sinn hier mal ein paar records zu posten oder andere Zusammenhänge darzustellen?

    Ich kann zwar nichts versprechen, aber es kann vielleicht nicht schaden. Vielleicht fällt jemandem von uns was auf. Zumindest eine betroffene Domain wär nicht uninteressant, den MX Record dazu etc. können wir dann eh selbst abfragen.

  • hostname: bfnet.bpaserver.net

    MX und somit auch email-ssl-hostname: mail.bf-net.de


    Achja, da läuft noch Wheezy, das sollte Google aber eigentlich nicht interessieren.

  • Das scheint mir echt ne harte Nuss zu sein. Soweit fällt mir in der DNS/MX Konfiguration nichts auf. Über die Tatsache, dass das implementierte Zerti einen anderen Common Namen hat als sich der Server im SMTP Dialog meldet (und auf den der PTR Record lautet), kann man diskutieren. Ich würde es mitelfristig harmonisieren, vermute aber mal nicht dass es was mit Deinem Problem zu tun hat.

    Das Zerti ist ja relativ jung, vielleicht kannst Du trotzdem mal überlegen, ob der Zeitpunkt ab dem es die Probleme gab (3-4 Tage auf oder ab, weil es ja immer etwas dauert bis es bemerkt wird) mit dem Zeitpunkt der Zerti Installation zusammenfallen könnte. Falls ja, wär es ein Hinweis. Vielleicht bricht Google den SMTP Dialog ja tatsächlich ab, wenn das Zerti nicht mit dem Hostnamen zusammenpasst. Wenn zu so einem frühen Zeitpunkt der SMTP Dialog von der Gegenstelle abgebrochen wird, wär es auch denkbar dass Du nichts schlüssiges im Log siehst.


    Ansonsten haben wir das bald soweit durchanalysiert, dass bald nur mehr Routing/Firewall Probleme von Google zu Dir übrig bleiben. Das würde dann auch ebenfalls erklären warum Du so gar nichts im Log siehst.

  • Oder vielleicht doch mal testweise ein Zerti besorgen das auf den eigentlichen Hostnamen aus dem SMTP Dialog (bfnet.bpaserver.net) lautet und das an dc-install verfüttern. Dann wieder testen ob von gmail was durchkommt. Dank letsencrypt kostet so ein Experiment ja nichts (ausser Zeit) und Du kannst dann das als Ursache zumindest ausschließen - bzw. sollte das Mail dann durchgehen, weißt Du dass das doch die Ursache ist.

  • So ein Zertifikat hab ich, darüber läuft ja alles was unterhalb des servernamens aufzurufen ist, roundcube, phpMyAdmin und natürlich pdadmin.

    Wenn ich das installiere drehen aber alle Kunden-Outlooks ab und ich hänge für den Rest des Tages am Telefon.


    Ich glaube ich muss nochmal in den Mail Logs recherchieren, wann die letzte Gmail Mail rein gekommen ist.
    iptables ist nun erstmal leer, ganz nebenbei steigt direkt mächtig die Serverlast an. Die Sperrliste war aber auch echt lang...

  • Ich hab das Problem gefunden, der Server hat TLS Verbindungen abgelehnt weil das Zertifikat nicht gefunden wurde und somit hat Gmail sich geweigert, sich zu verbinden.

    Beim Blick in die Datei /var/qmail/control/servercert.pem hat sich gezeigt, dass zwischen dem Cert und dem Cacert ein Umbruch fehlte, so das

    -----END CERTIFICATE----------BEGIN CERTIFICATE-----

    in einer Zeile stand. Das hat qmail-smtpd gereicht, das Zertifikat als ungültig anzusehen.
    Nun gehts wieder, ein Test-Telnet auf Port 25 bestätigt TLS, was es vorher nicht tat, und die erste GMail Mail kam gerade schon rein.


    Was bleibt ist die Frage, warum der Umbruch fehlte. Ich habe es mit dem dc-ssl-install.sh Shellscript nicht reproduziert bekommen, selbst wenn ich in der Zertifikatdatei direkt nach dem Trenner alles lösche.


    Vielen Dank für eure Hilfe, Sumeragi und Michael!


    Viele Grüße,

    Martin

  • Cool! Wenngleich sich in meiner Gedankwelt die Hinweise schon verdichtet haben, dass es in Richtung des Zertis als Ursache geht, wär ich darauf nicht gekommen.


    Wobei, jetzt wo Du es sagst, darauf muss man generell aufpassen. Manche Anbieter liefern die Zertifikatsdateien mit Windows Zeilenumbrüchen und wenn man diese dann auf Linux System spielt, kann genau so ein Quatsch rauskommen. Ich glaube zum Beispiel GoDaddy liefert bis heute eine der Dateien aus dem Zertifikatspaket mit Windows Zeilenumbrüchen aus, die zweite Datei nicht.

  • 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


    Ich hatte noch keine Installation bei der das nicht der Fall war.
    Das hatte ich auch schonmal in einer Installationanleitung für Debian 9.2 angemerkt, weil ich auch ewig nach dem Fehler bei den Mails gesucht hatte...


    Debian 9 "Stretch" mit PD Admin

  • Ich hab das Zertifikat von einer Webseite herunter geladen, per FTP wieder hoch (für das Shellscript) und dann verarbeiten lassen.

    Vermutlich ist da irgendwo was schief gelaufen, meinem FTP Client CyberDuck hab ich evtl. vergessen auf ASCII zu stellen...