Einer unserer Kunden meldete sich mit dem Anliegen, das er von einem seiner Lieferanten keine Rechnungen mehr per Mail erhält.

Wie so oft in solchen Fällen gibt es keinen konkreten Zeitpunkt. Wie man allerdings anhand des MailStore-Archivs nachvollziehen konnte, kam die letzte Rechnung per Mail vor ein paar Monaten an. Interessanterweise fiel dabei auf, das alle anderen Nachrichten, z.B. Newsletter, Bestell- und Auftragsbestätigungen sowie (aufgrund des Fehlers) auch Mahnungen, ohne Probleme ankommen. Also was ist da los?

Zunächst haben wir geschaut, wie der Absender-Mailserver heißt, das kann man beispeilsweise in MailStore aus dem Quelltext einer Nachricht ersehen oder man nutzt Tools/Dienste wie MXToolBox. Letzteres liefert noch weit mehr interessante und hilfreiche Informationen.

In den aktuellen Protokollen des eingesetzten MDaemon Email Servers fanden sich keine Verbindungen. Daraufhin haben wir alle “OldLogs” des MDaemon entpackt und mit SearchMyFiles nach dem Mailserver (FQDN) des Absenders durchsucht. Die Ergebnisse waren dann durchaus interessant. Die erfolgreichen Zustellungen waren – wenig verwunderlich – völlig in Ordnung. Auffällig waren dann abgelehnte Verbindungen.

Das erste was einem ins Auge stach war in diesem Fall, das der Absender-Mailserver nicht den Angaben aus einer früher erfolgreichen Zustellung oder den Infos der MXToolBox entsprach. Hier tauchte auf einmal

mout.kundenserver.de

auf. Im Verlauf der SMTP-Session scheitert dann die SPF- und DMARC-Prüfung und folglich wird die Verbindung bzw. Zustellung abgewiesen. Im Protokoll ist das direkt ersichtlich:

Mon 2025-10-27 15:51:25.784: 09: Message will be rejected after DMARC processing.

Schaut man weiter, trifft man dann noch auf diesen Mailserver:

mout-xforward.kundenserver.de

Der war mir neu, also danach recherchiert und dabei darauf gestoßen, das dieser Mailserver von IONOS genutzt wird, wenn Nachrichten die (IONOS-)intern als Spam eingestuft werden über diesen versendet werden. Der Gedanke hierzu ist einfach: So möchte der Anbieter vermeiden, das seine regulären Mailserver auf einer Sperrliste landen.

Schlecht ist in diesem Fall, das so eben unser Kunde keine (bestimmten) Mails mehr von seinem Lieferanten empfangen kann.

Auffällig ist hier zudem, da beim Kunden Greylisting aktiv ist, das zunächst der Original-Absender-Mailserver versucht zuzustellen, das wird erstmal mit verweis auf Greylisting abgelehnt, dann als nächstes der IONOS-Mailserver kommt und versucht zuzustellen, was ebenfalls wegen Greylisting abgelehnt wird. Wohlgemerkt beides mit der Absender-Mailadresse des Lieferanten! Die Spam-Prüfung für den IONOS-Mailserver schlägt, im Gegensatz zum Original-Absender-Mailserver, hierbei fehl.

Was genau da jetzt alles schief läuft hat sich zumindest mir noch nicht ganz erschlossen. Ein Teil der Geschichte könnte sein, das beim Original-Absender keine DMARC-Policy gesetzt ist, ein weiterer Teil ist, das IONOS als Backup-MX im DNS eingetragen ist, das dieser dann allerdings via SMTP zustellen möchte ist mir neu (soll eigentlich in einem Postfach beim Anbieter landen, das via MultiPop abgerufen wird).

  • Im Moment sieht das für mich so aus, als ob der Original-Absender-Mailserver erst mal direkt beim MDaemon anklopft, es greift zunächst Greylisting,
  • Der Absender-Mailserver geht dann an den Backup-MX (was erstmal OK ist), dieser nimmt die Nachricht (evtl.) an und versucht diese dann via SMTP am MDaemon zuzustellen, was aus obigen Gründen nicht klappt.

Als Sofort-Maßnahme haben wir erstmal im MDaemon den Absender auf die “Freigabeliste (nach Absender)” im Spamfilter gesetzt. Mal sehen wie diese Geschichte noch weiter geht. Imho sollte der Kunde sein Backup-MX-Konstrukt überdenken.

Interessant ist hierzu zudem folgender Beitrag:

MSXFAQ – 1&1/IONOS und SBL


Wie hat Dir der Artikel gefallen ?

1 Stern2 Sterne3 Sterne4 Sterne5 Sterne (1 Stimmen, durchschnittlich 5,00 von 5 Sternen)
Loading...

Du möchtest den Blog unterstützen ?

Neben PayPal.ME gibt es noch weitere Möglichkeiten, lies hier wie du diesen Blog unterstützen kannst.