Kurzer Hinweis an Nutzer, die einen Mail-Server bei IONOS oder Strato betreiben und sich wundern, dass verschickte Nachrichten eventuell vom Empfänger zur Annahmen abgelehnt werden. Es sieht so aus, als ob die IP-Netzwerkadressen der beiden genannten Anbieter auf Black-Lists gelandet sind und alle Empfänger, die auf solche Sperrlisten zugreifen, die E-Mails zurückweisen.
Ein eigener Fall
Eines meiner E-Mail-Postfächer ist bei 1&1 im Rahmen meines DSL-Vertrages angesiedelt. Zum 2. Januar 2023 erhielt ich eine Mail, die ich an einen Leser schicken wollte, mit folgender Antwort zurück.
Undelivered Mail Returned to Sender
I’m sorry to have to inform you that your message could not
be delivered to one or more recipients. It’s attached below.For further assistance, please send mail to postmaster.
If you do so, please include this problem report. You can
delete your own text from the attached returned message.The mail system
<xxxx@xxxxx.com>: host debaisvkd.dyndns.org[188.192.101.152] said: 550
5.7.1 Recipient not authorized, your IP has been found on a block list (in
reply to RCPT TO command)
Reporting-MTA: dns; inpost.tmes.trendmicro.eu
X-Postfix-Queue-ID: F31B21000131D
X-Postfix-Sender: rfc822; xxxx@xxxxy.de
Arrival-Date: Tue, 2 Jan 2024 17:26:27 +0000 (UTC)Final-Recipient: rfc822; xxxr@xxxxk.com
Original-Recipient: rfc822;xxxx@xxxx.com
Action: failed
Status: 5.7.1
Remote-MTA: dns; debaisvkd.dyndns.org
Diagnostic-Code: smtp; 550 5.7.1 Recipient not authorized, your IP has been found on a block list
Die Nachricht wird also von Trend Micro abgewiesen, weil die IP-Adresse des E-Mail-Servers auf einer Sperrliste (Black List) gelandet ist. Hab mir nichts dabei gedacht und dem Leser die Antwort per Freemail-Konto übermittelt.
Warnung auf Facebook
Nun hat mich ein Leser auf Facebook auf eine Diskussion in einer Gruppe hingewiesen, die sich genau mit diesem Thema befasst. Dort weist jemand darauf hin, dass die IP-Netze von IONOS und Strato auf einer Blacklist gelandet seien und die E-Mails ggf. abgelehnt würden.
Ein Nutzer schreibt, dass man auf MX-Toolbox testen könne, ob Mail-Server mit ihren IP-Adressen auf einer solchen Blacklist gelandet sind. Bei einer Strato-IP wurde mir diese als auf der Blackliste SORBS SPAM gemeldet. Für meinen Server bei 1&1 habe ich da aber keine Listung mehr gefunden. Es gibt Hinweise, dass die IP-Adresse bei uceprotect gelandet sein könnte. Zu diesem Thema hatte ich mal den Blog-Beitrag UCEPROTECT SPAM-Protection als Problembär? veröffentlicht. Hat noch jemand die Tage solche Mail-Probleme beobachtet?
Ähnliche Artikel:
UCEPROTECT SPAM-Protection als Problembär?
Microsoft 365 und die Mails mit QR-Phishing-Codes
Merkwürdige Bewerbungsmails aus dem Ausland ohne weitere Reaktion – was steckt dahinter?
Outlook scheitert beim Mail-Versand mit Non-Delivery Report (Error 0x80040305)
OVH: Mail-Versand an Telekom-Server erfordert DKIM
Warnung vor Phishing-Mails, die „Beschwerden zu E-Mails“ vorgaukeln
Manche Outlook.com-Nutzer können keine Mails mit Anhang senden
IONOS schafft SMTP-Relay (SmartHost) zum 15. Januar 2024 ab
hm.
ich lese da, dass „debaisvkd.dyndns.org“ die Email mit 550 ablehnt „said:“ und Trendmicro Dir das als Bounce mitteilt.
Was der Trendmicro Server da in den Header geschrieben hat sieht irgendwie sehr seltsam aus.
die .134 ist der Kundenserver. und er lässt sich rückwärts auflösen. daraus wird .134-.trendmicro mit einer andere IP…
Ist zwar wurscht für die Funktion, aber unschön.
Wie ich schon mal schrieb stehen einige Mail server von 1&1 mit Absicht dauerhaft in den Blacklists.
Diese Mail out kommen m.W. bei Email Weiterleitungen zum Einsatz, zumindest wenn die email als Spam erkannt worden ist. Insofern ist es eine Null Aussage, daß eine IP von 1&1 auf einer Blacklist steht, wenn nicht gesagt wird welche.
Genaueres weiß 1&1…
Der MX für debaisvkd.dyndns.org zeigt auf Trendmicro.
E-Mails an eine dynamische Adresse kann probleme geben, wenn sich die IP gerade geändert hat.
Die von Dir verwendete IP 212.227.126.134 (mout.kundenserver.de, 1&1) ist auf alle Fälle bei SORBS gelistet:
Problem Entries, (listings will cause email problems.)
6715 „Spam“ entries [00:01:37 31 Dec 2023 GMT-05].
212.227.126.134 – 6715 entries [00:01:37 31 Dec 2023 GMT-05].
Ein weiterer Eintrag existiert bei Hostkarma:
IP address 212.227.126.134 returned DNS result code 127.0.0.2.
212.227.126.134 is Black listed
Kann schon mal passieren, wenn jemandes Mailserver gehackt wurde, der dort gehostet ist. Es erwischt manchmal sogar Microsoft selbst:
Die IP-Adresse des Absendersystems, der dazugehörige rDNS, die Absenderdomain oder der im HELO-Banner verwendete FQDN ist auf Sperrlisten hinterlegt, weshalb davon emittierte Nachrichten kategorisch abgelehnt werden. Dies ist üblicherweise bei Spam-Versendern, von Cyberkriminellen kontrollierten Netzwerken oder kompromittierten Rechnern der Fall.
Zeitstempel Absender Gegenstelle Weitere Informationen
03.01. 01:32:16 noreply@eu.yammer.com mail-vi1eur05on2050.outbound.protection.outlook.com[40.107.21.50] Sperrliste: bl.spamcop.net
Yammer ist der alte Name für einen der MS-Teams-Dienste.
Ich selbst verwende 1&1 als Smart Host zum versenden und hatte das schon öfter. Wird aber schnell gefixt sein
Der Empfänger hat eine IP Adresse bei Kabeldeutschland.
Er hat eine dynamische, wechselnde IP Addresse.
Damit sein Host erreicht werden kann, hat er sich einen Host Namen bei dyndns besorgt…
Seine E-Mails lässt er durch Trendmicro annehmen und filtern.
Bei Trendmicro ist eingetragen, das die E-Mails bei seinem dyndns Host abgeliefert werden soll.
seine Dyn IP sei 1.1.1.1.
Diese IP hat Trendmicro gecacht.
Jetzt würfelt Kabel Deutschland die IP Adressen neu aus.
Er bekommt 1.1.1.2, die 1.1.1.1 bekommt ein Fremder.
Bei TM ist aber für seine Domain noch eine Zeitlang die 1.1.1.1 gespeichert. DNS abfragen sind kostenbar.
Kommt eine E-Mail für seine Domain, will TM sie bei der .1 abliefern. Da hängt nun aber ein anderer Host hinter, der natürlich keine E-Mails für fremde Domains annimmt und mit einem 550 rejected. Ein paar Minuten später wird die Email wieder funktionieren, weil TM die neue IP hat
Auf dem derzeitigen Host läuft ein unkonfigurierter IIS, wenn ich das richtig sehe.
Nur m so was passieren kann, wenn man mit einer Dyn IP Adresse emails empfangen will.
„Bei TM ist aber für seine Domain noch eine Zeitlang die 1.1.1.1 gespeichert. DNS abfragen sind kostenbar.“
Nee, DNS Abfragen sind nicht kostbar, die verursachen sogar gar nicht mal viel Traffic. Ich würde aber mal sagen, dass die TTL genau das Problem sein wird. Die ist in der Regel höher eingestellt, um unnötig viel Belastung für den zuständigen DNS Server (hier dyndns.org) zu vermeiden.
Ich habe auf meinen selbst gehosteten DNS Servern daher für die Hosts mit wechselnden IP-Adressen eine TTL von 60 Sekunden im Record hinterlegt. Rechne ich nun den disconnect, reconnect, die Dauer, bis auf Server 1 die neuen Daten eingegangen sind, die dann von Server 2 abgeholt und verarbeitet werden (DNS Server mit gleichzeitigem Angebot von http* ist eher suboptimal) und der entsprechende Host wieder per domain name verfügbar ist, dann komme ich auf mindestens 120 Sekunden. Das ist einfach zu lang, um einen seriösen Dienst betreiben zu können, zumal der reverse DNS Eintrag eben beim einem MTA viel kritischer ist als bei einem HTTPd, sich aber bei vom ISP zur Verfügung gestellten Adressen nicht verändern lässt (es gibt Ausnahmen).
Wenn dann noch verinnerlicht wird, dass RBL maximal eine Ergänzung zu anderen Abwehrmaßnahmen zu sehen ist und nicht als Allheilmittel, dann wird klar, dass meine immer wieder gern gemachte Aussage zu dem Thema durchaus ernst zu nehmen ist: Man will keinen MTA an dynamisch wechselnder IP-Adresse oder einer IP-Adresse, deren rDNS man nicht beeinflussen kann, betreiben. Und man will eigentlich auch gar nicht an einen MTA mit diesen Voraussetzungen Mail schicken.
Was mich bei Deinen Ausführungen ein wenig irrtiert, ist, dass Du offensichtlich annimmst, dass jeder einen MTA zu Hause rumstehen hat. Denn ein 550 kann nur von einem MTA kommen. Ein Endpunkt ohne Angebot des Dienstes wird gar nichts auf Deinen Einlieferversuch antworten, schon gar nicht, dass Deine Absender-IP-Adresse auf einer RBL steht. Deswegen passt das TTL-Argument auch nicht zu diesem Problem, ist aber, wie Du richtig festgestellt hast, ein generelles Problem von MTA an Einwahlzugängen.
Du scheinst eine andere Definition von „kostbar“ zu haben:)
„Nee, DNS Abfragen sind nicht kostbar, die verursachen sogar gar nicht mal viel Traffic. Ich würde aber mal sagen, dass die TTL genau das Problem sein wird. Die ist in der Regel höher eingestellt, um unnötig viel Belastung für den zuständigen DNS Server (hier dyndns.org) zu vermeiden.“
Das ist doch „kostbar“ Es kostet Dich als Frager zwar nicht viel, aber belastet den Betreiber des DNS Servers unnötig.
das meine ich mit „kostbar“.
Auch erfolgen DNS abfragen per UDP, es gibt also keine Verbindung. TCP kommt erst zum Einsatz, wenn größer Datenmengen übertragen werden.
Das ganze wird noch komplizierter, weil manche MTA die Email Adresse in der Que speichern. Eine ganz schlechte Idee.
Hier kommt betreibt der Besitzer der Domain einen eigenen Server auf einer Dynamischen IP.
Das ist nicht üblich, nicht schön.
Vermutlich damit das etwa stabiler wird hat er für seine dyndns Domain den Spam Proxy von Trendmicro eingetragen.
Der leitet die gefilterten emals an seinen eigenen SMTP Server weiter, der dann die Verteilung innerhalb seiner Firma übernimmt.
Und dieses Server scheint den Header zu analysieren und dabei auf den Kundenserver zu stoßen und die Email zu rejecten.
TM reicht das nur an den Absender als bounce weiter.
Zu kleine TTL Angaben werden wohlweißlich von manchen ignoriert
Ja, natürlich kann man sich rücksichtslos verhalten.
Nennt man auch dysozial.
Das sollte eigentlich kein Thema sein.
„Was mich bei Deinen Ausführungen ein wenig irrtiert, ist, dass Du offensichtlich annimmst, dass jeder einen MTA zu Hause rumstehen hat. Denn ein 550 kann nur von einem MTA kommen. Ein Endpunkt ohne Angebot des Dienstes wird gar nichts auf Deinen Einlieferversuch antworten, schon gar nicht, dass Deine Absender-IP-Adresse auf einer RBL steht. Deswegen passt das TTL-Argument auch nicht zu diesem Problem, ist aber, wie Du richtig festgestellt hast, ein generelles Problem von MTA an Einwahlzugängen.“
Es ist nicht gut für eine konstruktive Diskussion dem anderen irgendwas zu unterstellen.
Ich rede hier nur über diesen Fall.
Die 550 kommt hier NICHT von Trendmicro, sondern von einer dyn IP bei Kabel Deutschland.
Diese RfC Header in Bounce mails sind manchmal etwas irreführend .
Hier ist eine Domain bei Dyndns mit dem Trendmicro Server als MX konfiguriert. Wie soll der User denn an die E-Mails kommen, die TM gefiltert hat?
Witzigerweise läuft auf dem Host ein frischer IIS.
Jetzt hast Du etwas missverstanden. Du sprachst in Deinem Konstrukt davon, dass die IP-Adresse des Ziel-MTA gewechselt hätte und TM das nicht mitbekam. Die neue Zieladresse hätte aber mit 550 abgelehnt. Und genau das greife ich auf, wenn ich sage: kann nicht sein, weil ganz sicher nicht an jedem DSL-Endpunkt ein MTA läuft. An den meisten DSL-Endpunkten läuft rein gar kein Dienst. Und kein Dienst kann auch keine Ablehnung verursachen, noch dazu spezifisch eine Ablehnung im Bereich SMTP.
Ich war weit weg davon, Dir etwas zu unterstellen.
Wenn ich schon „dyndns.org“ im Domänennamen lese, dann weiß ich schon wieder alles. Da will ich dann auch gar keine Mail hin schicken.
Ich hatte gestern das gleiche Problem mit meiner web.de-Email-Adresse. IP weiss ich gerade nicht mehr, war aber auch eine von 1&1.
gerade mal geprüft: mein Server bei Strato steht (mal wieder) in Sippenhaft bei UCEPROTECT (die Typen, die behaupten, die Guten zu sein, aber einfach nur Kohle machen wollen…)
Sicher, daß es „nur“ Sippenhaft ist?
Auf dem 37c3 wurde ein neuer Angriffsvektor auf SMSP publiziert, SMTP-Smuggling.
Da das CERT wohl was verkackt hat, gab es eine koordinierte Release, bei der aber so unwichtige Open-Source-Projekte wie Postfix und Exim fehlen.
Möglicherweise setzt Du ja einen davon auf Deinem Server ein, es sind jedenfalls im Moment reichlich Angriffe in freier Wildbahn zu beobachten.
> Sicher, daß es „nur“ Sippenhaft ist?
Ja, denn UCEPROTECTL1 ist noch grün, nur L2 und L3 sind rot: das sind Bereichsblocks, die aber wohl durchaus von einigen PMs eingesetzt werden. Früher gab es ja nur geblockt/nicht geblockt, das haben sie jetzt mit den 3 Level etwas entschärft, aber da es ja auch größer Installationen mit mehreren Servern gibt verwenden wohl durchaus auch PMs die L2 oder gar L3…
> Auf dem 37c3 wurde ein neuer Angriffsvektor auf SMSP publiziert, SMTP-Smuggling.
Den Workaround für Postfix gibt es schon einige Tage, und der ist auch drin (bis die Distro den gefixten Postfix verteilt).
„unwichtige Open.Source-Projekte“ YMMD! Ich behaupte jetzt mal, dass die von Dir genannten beiden auf der Welt sehr viel häufiger vertreten sind als alles andere.
Muß man jeden Sarkasmus mit einem Smiley kennzeichnen?
Die Auswahl der benachrichtigten Unternehmen „Microsoft, Cisco und GMX“ fand ich ohnehin sehr schräg.
Lass Deinen Ironie Detector mal reparieren.
FYI:
Postfix und Exim sind vermutlich die am häufigsten MTA neben Sendmail.
Insofern ist es schon seltsam, das angeblich „vergessen“ wurde dort auch zu informieren…
Das SMTP smuggling ist eine uralte Sache.
Es brauchte keinen CCC 37c3 oder CVE um die Spammer davon zu informieren.
Die sind ja nicht völlig aus der Welt.
Das war sog. „Bild Journalismus“
Es fehlt nur das Fragezeichen…
Schade
Nachtrag: https://heise.de/-9584467
Ich mag UCE auch nicht, darum sind die bei mir gänzlich blockiert (inkl. alle mir bekannten „Honeypots“ von denen). Zur Erklärung: Sie setzen Domänen auf, die wie ’ne Bärenfalle fungieren. Sobald man sie aufruft/kontaktiert, landet man auf deren Sperrliste.
Ihre Begründung: „Nur Spammer kämen an diese Adressen und würden zu Recht auf die schwarze Liste gesetzt“.
Das einzige, was Du tun kannst: Gesprächspartner, die auf UCE setzen, kontaktieren (evtl. per Telefax?) und auf das Gebaren ihren dollen Dienstleisters aufmerksam machen.
Dich alleine wird man ignorieren und auslachen. Sobald sich mehrere melden, wird es Konsequenzen haben.
Was ich ziemlich bedenklich finde, dass sich hinter (aktuell 188.192.101.152) anscheinend ein ein Exchange 2010 findet…
Oder ist dies ein Honeypot?
Scheint auch noch auf einem IIS 7.5 zu laufen. Das sieht mal wieder nach einem sehr gepflegten System und einer Spamschleuder aus.
DSL Dyndns MX… was erwartest du.
Das ist eine Dynamische IP.
Wer weiß wem die IP aktuell gehört?
Vielleicht ist die Ip-änderung nicht bei dyndns gelandet, die Kabeldeutschland inzwischen gemacht hat.
Jetzt kommt da bei der Domian für webmail.mvpatwork.com ein Zertifikats Fehler.
Da hält wohl wer seinen Dyn DNS Eintrag nicht aktuell?
…
Dürfte bald offline gehen
Hier bislang beim Versand über Strato (Eigeneinsatz + ca. 20 Kunden) keine Probleme. Aber vielleicht werten auch nur deren Empfänger keine Blacklisten aus. Die Methode scheint mir heutzutage generell ein bisschen aus der Zeit gefallen.
Leider findet die MX-Toolsbox auch nicht alle RBL’s in die man aufgenommen werden kann. Beispiel: SpamCop. Ich habe aktuell einen Kunden, dessen Mail-URL offensichtlich dort gelistet ist. In der MX-Toolbox wird jedoch nichts angezeigt.
Spamcop schreibt selbst das man sie nur mit großer Vorsicht benutzen soll
„The SCBL is aggressive and often errs on the side of blocking mail.“
Also versuche den Empfänger zu benachrichtigen.
Er soll die Liste rausnehmen,wenn er stabil mit E-Mails versorgt werden will.
IIRC will SpamCop für kommerzielle, umfangreiche Nutzungen Asche sehen. Vermutlich brauchst Du ein kostenpflichtiges Abo bei MXtools. Wäre ja sonst albern.
Hallo zusammen, ich bin volliger Laie auf diesem Gebiet und habe nur gemerkt, dass einige unserer geschäftlichen Mails, die über STRATO laufen, nicht bei den Empfängern angekommen sind.
Der Blacklist-Check zeigt, dass unsere Domain auf folgenden beiden Blacklistst steht: bl.fmb.la, dnsbl-3.uceprotect.net.
Meine Frage ist nun, was ich dagegen tun kann. UCE-Protect schreibt ja, dass das Listing nach 7 Tagen automatisch aufgehoben wird. Jedoch besteht das Problem bereits mindestens 8 Wochen. Heute habe ich zum ersten Mal den Listencheck gemacht.
Ich freue mich, wenn ihr einen Tipp für mich als völlige Unwissende auf diesem Gebiet habt.
Wenn Deine Mails über Strato laufen, ist Dein Ansprechpartner an dieser Stelle auch Strato.
Hallo zusammen,
mit Blacklists hat IONOS scheinbar mehr Probleme als gedacht.
Mein NAS versendet 2x tägl. Status-Emails.
Seit gestern werden die Dinger mit „Mail delivery failed returning message to sender“ abgelehnt.
Heute morgen hab ich mich dann mal auf die Suche nach der Ursache begeben.
Ergebnis: Die IP von IONOS’s MTA steht beim „Spamhaus-Project“ auf der Liste.
Danach hab ich gleich noch die IP mit „mxtoolbox.com/blacklists.aspx“ gecheckt…
Ohje, die Adresse ist gleich bei 7 Blacklistdiensten gelistet.
Zum Schluß wollte ich noch IONOS anschreiben.
Allerdings ist das Meldungsformular kaputt… fehlt zum Abschließen/Senden der Button
Nun denn, kann man nur warten…
Grüße Mike
Moin,
gestern nach Servermigration festgestellt, dass Mails von meinem Server UCEPROTECT2 und UCEPROTECT3 gelistet sind. Daher laufen sie bei GMail gleich im Spam-Ordner auf, bzw. werden woanders gleich geblockt:
: host
cdc-s-mxgw04.comramo.net[81.14.163.24] said: 554 5.7.1 Message is detected
by Header Analysis check. This email from IP 194.164.51.236 has been
rejected. The email message was detected as spam. Header Analysis ### Mehr
Informationen unter https://www.comramo.de/mailfaq/ ### (in reply to end of
DATA command)
Mailservereinstellungen und DNS sind m. E. völlig in Ordnung, einzig der Hinweis auf die Blacklist lässt für mich den Schluss auf die Nichtzustellung.
Schaue ich auf https://www.uceprotect.net/en/rblcheck.php nacj, ist meine IP dort bei Lvl 1 mit einem Listingrisiko „DNS Risk“ vermerkt und dann im Lvl 2 gelistet. Allerdings kann ich den DNS-Hinweis nicht nachvollziehen – eigentlich ist alles sauber eingestellt.
Ein weiterer Check bei https://dnschecker.org/ip-blacklist-checker.php?query=194.164.51.236 weist lediglich aus, dass offensichtlich die gesamte Range blacklisted ist:
dnsbl-2.uceprotect.net
Net 194.164.48.0/20 is UCEPROTECT-Level2 listed because 49 impacts are seen from IONOS-AS This is the joint network for IONOS, Fasthosts, Arsys, 1&1 Mail and Media and 1&1…/AS8560 there. See: http://www.uceprotect.net/rblcheck.php?ipr=194.164.51.236
—————
Was nun? Wer hat eine Idee, was nun zu machen ist? Mit Ionos werde ich mich dann mal am Dienstag in Verbindung setzen. Kann ja nicht sein, dass man mit einem „neuen“ Server gleich blacklisted ist (oder seht hier jemand fehlerhafte Mailservereinstellung/ DNS-Einträge? – z. B. websklave.de)