*GELÖST (MX auf FQDM)* Mails von "bekannten" Absendern verschwinden

  • Hi Zusammen,


    ich verbringe nun 3 Vollzeit-Tage mit dem Problem :(
    Auf der endlosen Suche habe ich zahlreiche "ähnline" Probleme gefunden, dort kommen dann aber gar keine eMails an.


    Setting:
    Froxlor / Postfix / Dovecot
    Postfix und Dovecot nach Froxlor Konfiguration neu aufgesetzt.


    Interne Mails über alle angelegten eMails funktioniert!
    Kommunikation mit meiner privaten @live.de eMail-Adresse (Senden und Empfangen) funktioniert tadellos!
    Mails von Bekannten (@yahoo, @gmail.com) kommen an und können beantwortet werden.


    Jedoch:
    Mails von "bekannteren" absendern (wie bspw. Accountbestätigungsmails von twitter, affili.net, cyberport.de) kommen nicht an.
    Ich kann diese auch sonst nirgends auf dem Server -außerhalb der von Froxlor definierten Mailordner- finden.


    Die letzte Vermutung, welche ich noch habe ist die, dass die Mails nicht empfangen werden können, da die Mail-Demons ohne Verschlüsselung arbeiten?


    Kennt jemand ein solches Verhalten und kann hierzu einen Lösungsansatz oder Denkanstoß liefern?


    Falls Configs o.ä. benötigt werden, kurz bescheid geben.
    Aber wie gesagt: is auf SQL-Zugänge sind die Configs im Originalzustand.


    Allerbesten Dank bereits im Voraus.


    Beste Grüße
    Pascal

  • Was sagt denn das mail.log, wenn du es nach spezifischen Einträgen zu twitter oder cyberport durchsuchst? Normalerweise sollte dort ja ein Hinweis zu finden sein, wie die Verbindung verlaufen ist (Fehler bei Verbindung, Fehler bei Mail-Annahme, etc.).
    Führe doch mal

    Code
    1. grep -i twitter /var/log/mail.log


    oder

    Code
    1. grep -i cyberport /var/log/mail.log


    aus. Damit kannst du (hilfreich bei größeren Logs) die Zeit eingrenzen und dann einfach mal gezielt nachschauen, was bei der Verbindung passiert ist.

  • Hi Oliver,


    danke fürs fixe Feedback.


    EDIT:
    Einen Hinweis zu Cyberport habe ich nun in der "mail.log.1" gefunden.

    Code
    1. May 11 08:58:44 SRV01 postfix/qmgr[31752]: BAE3240319: from=<bounce+2e8736.13e72-partner=getthedeals.[email]de@partner.cyberport.de[/email]>, size=3317, nrcpt=1 (queue active)
    2. May 11 10:43:18 SRV01 postfix/qmgr[31752]: 21B5640319: from=<bounce+2e8736.13e72-partner=getthedeals.[email]de@partner.cyberport.de[/email]>, size=50037, nrcpt=1 (queue active)


    Sagt mir leider gar nichts. Die Mail ist nie zugestellt worden.
    Seither wurde der Mailserver (leider) neu aufgesetzt.
    Zu Twitter und affilinet weiterhin keinen Hinweis. Ich habe mir die eMails aktuell noch einmal zusenden lassen.
    /EDIT

    Ich erhalte dort (auch nach Erhöhung des Loglevels - und ja, das Log ist nun deutlich detaillierter) keine Informationen zu diesen "tlds".
    Im Gegentest finde ich sämtliche Mails/Infos, welche ich mir von meiner privaten @live.de Adresse gesendet habe.


    Gruß
    Pascal

  • Ich erhalte dort (auch nach Erhöhung des Loglevels - und ja, das Log ist nun deutlich detaillierter) keine Informationen zu diesen "tlds".
    Im Gegentest finde ich sämtliche Mails/Infos, welche ich mir von meiner privaten @live.de Adresse gesendet habe.


    Hast du evtl. zwei konkurrierende MX- oder A-Einträge? Scheinbar ist ja verbindungstechnisch soweit OK, wenn Mails von live.de eintreffen. Vielleicht nutzt live.de den korrekten MX/A und die anderen Provider den falschen?!
    IPv6 Verbindung mal gecheckt? Vielleicht sendet live.de über IPv4 und die anderen versuchen es über IPv6?!


    Sind wage Vermutungen, nähere Infos zu deinem System wären durchaus hilfreich, evtl. auch die anonymisierten Logs/Logabschnitte.

  • Hi Zusammen und danke für die zahlreichen Denkanstöße!


    Ich habe nun das LOG belauscht.
    Bei den besagten Absendern (wie z.B. Twitter) tut sich weiterhin nichts.


    Bei allen anderen Mails (ja, auch die @live.de) wird das LOG gut beschrieben (aber hier funktioniert ja auch alles).
    In den Logs sehe ich neben dem korrekten Mailempfang lediglich die Logins meiner clienten sowie immer wieder Loginversuche einer bestimmten (im Netz bekannten Spam-) IP-Adresse.


    MXTOOLBOX hatte mir zunächst ausgespuckt, dass der MX-Eintrag zu meinem genutzten "mailname" (srv01.domain.tld) nicht existiert.
    Habe diesen nun gesondert angelegt (als mailname nutze ich eine Subdomain und habe den MX-Eintrag nun für Wildcards -statt zuvor nur für die tld an sich- gesetzt).
    Nun findet auch MXTOOLBOX diesen Eintrag.


    Grundsätzlich ist hier nun alles "OK", bis auf die folgenden beiden Warnungen (welche nach anderen Foren nicht weiter tragisch sein sollen):


    Reverse DNS does not match SMTP Banner
    Warning - Does not support TLS.



    Alle MX-Einträge zeigen grundsätzlich auf die selbe IP. Hier sollte es keine Probleme geben.


    Versand via IPv4 und v6: Ich hatte das bereits in irgendeiner Config entdeckt.
    Weiß leider nicht mehr wo und begebe mich auf die Suche.

  • In den Logs taucht wirklich absolut nichts zu den besagten Absendern auf.
    Diese sind auch viel zu umfangreich, um sie hier posten zu können (selbst mit Aufteilung auf 2 Posts).


    Was immer wieder auftaucht, sind solche EInträge:

    Code
    1. May 15 19:44:52 SRV01 postfix/anvil[3348]: statistics: max connection rate 1/60s for (smtp:xx.xx.xx.xxx) at May 15 19:41:30
    2. May 15 19:44:52 SRV01 postfix/anvil[3348]: statistics: max connection count 1 for (smtp:xx.xx.xx.xxx) at May 15 19:41:30
    3. May 15 19:44:52 SRV01 postfix/anvil[3348]: statistics: max cache size 1 at May 15 19:41:30


    Grüße
    Pascal


  • Warning - Does not support TLS


    Das ist eigentlich ziemlich eindeutig! Dein Mailserver unterstützt kein SSL/TLS. Das solltest du ganz dringend nachkonfigurieren bzw. dich in das Thema einlesen. So hast du Glück, dass überhaupt Mails ankamen. Denn viele Mailserver verschicken Mails mittlerweile nur noch, wenn der Empfänger SSL/TLS unterstützt.

  • Das ist eigentlich ziemlich eindeutig! Dein Mailserver unterstützt kein SSL/TLS. Das solltest du ganz dringend nachkonfigurieren bzw. dich in das Thema einlesen. So hast du Glück, dass überhaupt Mails ankamen. Denn viele Mailserver verschicken Mails mittlerweile nur noch, wenn der Empfänger SSL/TLS unterstützt.

    OK, es ist zunächst angepasst.
    Zertifikate sind nicht so das Problem.


    Auch MXTOOLBOX schimpft nicht mehr und gibt ein OK.


    Leider tut sich zu den zu empfangenden Mails weiterhin nichts (auch nicht im Log).

  • So hast du Glück, dass überhaupt Mails ankamen. Denn viele Mailserver verschicken Mails mittlerweile nur noch, wenn der Empfänger SSL/TLS unterstützt.


    Hast Du ein Beispiel, welche Provider das sein sollen? Das verstößt nämlich eindeutig gegen geltende RFC und sorgt sicher für Probleme, an denen der Mailserver mit erzwungenem TLS schuld ist.


    Dass es trotzdem fast schon fahrlässig ist, einen Mailserver ohne TLS zu betreiben, ist eine andere Geschichte. Trotzdem muss man zusätzlich als Fallback den Empfang und Versand auch ohne TLS ermöglichen.



    MfG Christian


  • Hast Du ein Beispiel, welche Provider das sein sollen? Das verstößt nämlich eindeutig gegen geltende RFC und sorgt sicher für Probleme, an denen der Mailserver mit erzwungenem TLS schuld ist.


    Spontan hätte ich jetzt gesagt, dass sich das RFC nur auf den Mailserver Teil bezieht (smtpd), nicht aber auf den Client Modus (smtp), welchen man ja nochmal unabhängig davon konfigurieren kann. Auch die Postfix Doku geht nur im Server Teil auf den RFC ein (http://www.postfix.org/TLS_README.html). Zumindest die Symptome machen den Eindruck, dass es daran liegen könnte. Ich selbst betreibe Mailserver seit einiger Zeit nur noch mit erzwungenem TLS. Falls da draußen wirklich noch Mailserver ohne TLS Unterstützung existieren, will ich mit diesen gar nicht kommunizieren und von diesen auch keine Mails empfangen. Wirkliche Probleme hatte ich damit auch noch keine. Aber das ist ein anderes Thema.


    Zurück zum eigentlichen Problem. Spliddorama : Siehst du nach der Umstellung (TLS Aktivierung) immer noch nichts in den Logs? Da müsste es doch zumindest Connection Versuche geben.

  • Hi Paul,


    nein, auch nach erfolgter TLS-Aktivierung gibt es weiterhin keine Regung im Log.
    Habe diesen auch wieder/weiterhin im verbose-modus laufen.


    Hätte ich es nicht x-fach kontrolliert, könnte man meinen, dass ich falsche eMail-Adressen angegeben habe.
    Das kann ich jedoch zu 100% ausschließen.


    Es gibt keine weiteren mailserver, auf die fälschlicherweise geleitet werden könnte.


    Sämtliche MX-Einträge (auch die von weiteren TLDs, welche auf die Server-IP zeigen, sind identisch.


    Das einzige, was direkt sichtbar ist, ist der nicht passende SMTP-Header.
    Das soll jedoch kein Problem sein und ist bei netcups ja normal, da von der IP ja der Hostname "vXXXXXXX.quicksrv.de" zurückgegeben wird.


    Beste Grüße
    Pascal

  • SMTP Header ist für dein Problem erstmal unwichtig, weil dieser ja erst dann übetragen wird, wenn überhaupt eine Verbindung aufgebaut wurde, aber da scheint es ja schon zu Haken!


    Läuft dein Server auf DualStack? A und AAAA Record für den Server angelegt, worauf der MX zeigt? Postfix Listener für IPv6 aktiviert? Grundsätzliche IPv6-Konnektivität gegeben? Port 25 frei in der Firewall für IPv6 (IP6Tables)?
    Ich weiß aus Erfahrung (meinen Logs), dass Microsoft Mails nur per IPv4 empfängt und sendet. Ich tippe immer noch auf ein Problem mit deinem Empfang über IPv6.
    Solltest du allerdings nur IPv4 konfiguriert haben (auch im DNS) erübrigt sich mein Verdacht!

  • Hi Oliver,


    mit IPv6 kenne ich mich noch so ziemlich gar nicht aus.
    Unter "ip addr show" wird mir unter "inet6" auch eine v6-Adresse angezeigt.
    Konnektivität nicht getestet, da Kenntnisse fehlen.


    In den DNS-Einstellungen gab es bisher nur einen Präfix (subdoamin) welche auf eine externe v6-Adresse (per AAAA) gezeigt hat.
    Diesen habe ich jetzt nur zur Sicherheit entfernt (war nicht weiter wichtig).


    Gestern Morgen hatte ich "inet_interfaces", sowie "inet_protocols" vorbeugend auf "all" gesetzt.


    PS: Ansonsten leiten sämtliche Einträge lediglich per A-Record auf die IPv4.


    Gruß
    Pascal

  • Hi Zusammen und besten Dank!


    die genauen Absender-Adressen sind mir ja unbekannt.
    Ich habe bei twitter mal eine GMail-Adresse hinterlegt (die Bestätigungsmail kam dann dort an).
    Die Absender-Adresse ist "verify@twitter.com".


    Gruß
    Pascal

  • Den Test verstehe ich nicht - mein Versuch waere gewesen, das ich dir eine Mail an deinen Server direkt schicke, damit man sich die Logs ansehen kann (beim dir und bei mir). Eine Mail an twitter zu schicken, wo dann eine gmail-Adresse hinterlegt ist - was soll das fuer eine Info bringen ?


    Gruss,