• Bewerte uns auf OMR Reviews: Klick

  • 25Reports geht live, schaut es euch an: Klick

  • Achtet bitte in den Beiträgen darauf, dass ihr keine Informationen teilt, die der DSGVO unterliegen können. Verpixelt bitte die entsprechenden Stellen in Screenshots, postet hier auf keinen Fall Messagatracks ohne Rücksprache und auch in den Log Files können persönliche oder sensible Daten enthalten sein.

    Macht uns auch bitte per PN darauf aufmerksam wenn ihr etwas seht. Schreibt mich (@sören) einfach direkt an. 

  • Zertifikate vom Deutschen Forschungsnetz beziehen (Harica CA)? Klick

Fehlermeldung in "Echtzeit-Blocklisten" in Nachrichtenverfolgung

mabu

Well-known member
Registriert
19 Dezember 2019
Beiträge
359
Reaktionspunkte
30
Hallo.

Da ich vorhin eine unerwünschte Mail im Posteingang hatte, habe ich mal im NSP geprüft, warum die angenommen worden ist. Und dabei fiel mir auf, dass im Filter "Echtzeit-Blocklisten" diese Fehlermeldung zu finden war:

Eine Aufgabe wurde abgebrochen.
bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
bei Netatwork.NoSpamProxy.Net.DnsClient.<RetryCoreAsync>d__28.MoveNext()
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem …


Scheint seit knapp zwei Stunden bei recht vielen eingehenden Mails so zu sein. Aber nicht bei allen. Dadurch scheinen auch eine nicht erwünschte Mail angenommen zu werden.

Habe GW-Rolle mal neu gestartet. Kommt aber immer noch bei Mails vor. Eben auch bei einer Testmail von extern von mir.

Protokollierung von RealTimeBlocklists hat mir keine Erkenntnisse gebracht.

Ich vermute mal, dass eine der Anbieter auf der Liste der RBLs da nicht erreichbar ist. Kann aber mit der Fehlermeldung nichts anfangen. Zur Sicherheit auch Protoll für DNSServer eingeschaltet (auch wenn in Fehler DNSClient steht). Aber auch nichts auffälliges aus meiner Sicht.

Was meint Ihr dazu?
 
Moin Martin,
welchen DNS-Server fragt die Gateway Rolle denn? Den im Windows-IP-Stack hinterlegten? Oder einen manuellen? So oder so, würde ich mal die andere Version ausprobieren.
Hast Du auch die Listen als solche gecheckt?
Gruß Stefan
 
Hallo Stefan.

Es sind die DNS-Server, die im Windows-Server zugeordnet sind. Das ist einmal die 1.0.0.1 und als sekundärer der "Haupt-DNS-Server im Rechenzentrum", in dem u.a. unser NSP gehostet wird. Aus den nun fast 6 Jahren Erfahrung mit dem NSP im RZ war das dann die für uns sinnvollste Konfig in den DNS-Einstellungen.

Die Einträge unter "Echtzeit-Blocklisten" in den Filtern haben meiner Ansicht nach längere Zeit keine Probleme gemacht.

Ich habe diese eben aber nochmal in allen Inbound-Regeln auf Standard zurück, dann SpamCop entfernt und Spamhaus ZEN hinzugefügt. Änderte aber am Ergebnis erstmal nichts.

Frage 1: worauf weißt mich den die Fehlermeldung hin?
Frage 2: könntet Ihr unter "Konfiguration -> Voreinstellungen -> Echtzeit-Blocklisten" irgendwie eine Art Check einbauen, der jeweils anzeigt, ob die DNS-Auflösung an der GW-Rolle aus funktioniert? Und könntet Ihr aufgrund der vom NSP ausgehenden Anfragen an diese Listen nicht auch eine Spalte mit "erfolgreich ja/nein ?" mit hinzufügen?
Frage 3: ist Euch irgendeine Statusseite im Web bekannt, auf die der aktuelle Status solcher RBL-Seiten angezeigt wird? Auf die Schnelle habe ich vorhin nichts gefunden.
 
Es sind die DNS-Server, die im Windows-Server zugeordnet sind. Das ist einmal die 1.0.0.1 und als sekundärer der "Haupt-DNS-Server im Rechenzentrum", in dem u.a. unser NSP gehostet wird. Aus den nun fast 6 Jahren Erfahrung mit dem NSP im RZ war das dann die für uns sinnvollste Konfig in den DNS-Einstellungen.
Könnte es sein, dass das RZ den 1.0.0.1 blockiert und nun die DNS Anfragen einfach ins Leere laufen? Abgesehen davon wundert mich es gerade, dass ein RZ solch eine Konfiguration überhaupt zu lässt. Weil da in der Regel noch einige Split-DNS Server dazwischen hängen. ;-)

Kannst du die betroffenen DNSBL manuell auf dem Server über eine Eingabeaufforderung + nslookup erreichen?
 
Moin Martin,
idealerweise solltest Du diese Art der Fehlermeldung gar nicht erst bekommen. NSP sollte das abfangen und in eine "gescheite" Fehlermeldung umwandeln. Das deutet immer daraufhin, dass etwas sehr unerwartetes passiert ist, das der Code stand jetzt, nicht abfangen kann.
Als Übersicht für Blacklisten nutze ich gerne die Funktion von MXToolbox. Das sind meiner Erfahrung nach die größten Sammlungen.
Gruß Stefan
 
Ich glaube, dass Euer Hinweis "Abschaltung der DNS-Blacklist Nixspam" vermutlich die Lösung gebracht hat.

Ich habe in allen Inbound-Regeln Nixspam gegen 8 Uhr heute früh entfernt. Und seitdem gibt es den Fehler bei den Echtzeit-Blocklisten nicht mehr. Die eingehenden Mails davor haben die Meldung jedes Mal.
 
Sorry fürs ausgraben dieses alten Threads.

Ich habe ein ähnliches Problem. Bei allen Mails, die über das Internet reinkommen, wirft der Filter Echtzeit-Blocklisten diesen Fehler:
Eine Aufgabe wurde abgebrochen.
bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
bei Netatwork.NoSpamProxy.Net.DnsClient.<RetryCoreAsync>d__28.MoveNext()
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
bei System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
bei Netatwork.NoSpamProxy.Net.DnsClient.<ResolveInsecureInternalAsync>d__27`1.MoveNext()
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
bei System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
bei Netatwork.NoSpamProxy.Net.DnsClient.<Try>d__30`1.MoveNext()
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
bei System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
bei Netatwork.NoSpamProxy.Net.DnsClient.<ResolveAsync>d__25`1.MoveNext()
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
bei System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
bei Netatwork.NoSpamProxy.Net.DnsClient.<TryGetHostEntryAsync>d__22.MoveNext()
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
bei System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
bei Netatwork.NoSpamProxy.Net.DnsClient.<TryGetHostEntriesAsync>d__14.MoveNext()
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
bei System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
bei Netatwork.NoSpamProxy.Addins.Core.Filter.RealtimeBlocklistFilter.<EvaluateAsync>d__14.MoveNext()
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
bei System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
bei Netatwork.NoSpamProxy.Addins.Core.Filter.RealtimeBlocklistFilter.<ExecuteAsync>d__9.MoveNext()
--- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
bei System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
bei Netatwork.NoSpamProxy.MailValidation.MailValidator.<ExecuteFilterAsync>d__105.MoveNext()

Zurückführen konnte ich das Problem auf die Echtzeit-Blocklisten von SpamRATS. Entferne ich beide aus dem Filter, kommt der Fehler nicht mehr auf.

Wir setzen die Version 15.4 aus dem regulären Kanal ein.

Gibt es hier Änderungen? Als DNS-Server nutzen wir 8.8.8.8 und 1.1.1.1.

Ich habe die SpamRATS Listen jetzt erstmal raus genommen.

Beste Grüße
Alex
 
Interessant. Habe derzeit gleiches Problem wie @AlexL
Habe dann die beiden SpamRats Listen entfernt und der Fehler ist weg.
1759852666130.png

NSP 15.5.01910
DNS Server 8.8.8.8 und 8.8.4.4 werden für externe DNS-Auflösung genutzt
 
Hallo Alex,
was gibt die DNSBL SpamRats zurück, wenn du die Abfrage mit Hilfe nslookup manuell ausführst?

Abgesehen davon: Wie hoch ist euer eingehendes (Internet -> NSP) Volumen? Zitat auf der Webseite:
If you are familiar with this method, register an API Key first, registration is free. Our RBL's are free to use for most people, unless you are a larger organization with very high query rates, or providing commercial email protection services. (Don't worry, we will let you know) For more information on what qualifies for complimentary/free access.

Gruß,
Daniel
 
Hallo Alex,
was gibt die DNSBL SpamRats zurück, wenn du die Abfrage mit Hilfe nslookup manuell ausführst?

Abgesehen davon: Wie hoch ist euer eingehendes (Internet -> NSP) Volumen? Zitat auf der Webseite:


Gruß,
Daniel
Hallo Daniel,

hier die versuchte DNS-Auflösung. Ich hoffe, ich habe das versucht, was du wolltest. Spamrats.com löst auf, sobald ich aber gegen eine Liste prüfe, bekomme ich nur Timeouts.

1759901890745.png

Ich habe jetzt mal einen API-Key beantragt und versuche das dann nochmal.

Unser Gesamtaufkommen Mails -> NSP beträgt in etwa 2.000 Mails pro Tag. Davon kommt etwa ein Viertel aus dem NdB, wird also nicht gegen RBLs geprüft, da private Adressen. Also das zu prüfende Volumen liegt etwa bei 1.500 / Tag.

Viele Grüße
Alex
 
Hallo Alex,
was mich stutzig macht ist, dass bei dir eine Zeitüberschreitung/ DNS request timed out kommt. Wenn es keinen Eintrag in der DNS Zone gibt, sollte eigentlich sowas wie "Non-existent domain/NXDOMAIN" zurück geliefert werden. Leider hat der Betreiber auf seiner Webseite kein positives Beispiel Eintrag genannt. Und die Blacklist ist auch nicht einsehbar... :-(

Könnte auch sein, dass Spamrats die großen DNS Anbieter wie Google, Quad9 gesperrt hat. Was bei aktuell wohl funktioniert, ist der DNS von Cloudflare:
nslookup 1.1.3.192.spam.spamrats.com. 1.1.1.1
Server: one.one.one.one
Address: 1.1.1.1

*** 1.1.3.192.spam.spamrats.com. wurde von one.one.one.one nicht gefunden: Non-existent domain.
Sieht das bei dir ähnlich aus?

Gruß,
Daniel

P.S. Kann mich gerade aber auch irren, bin schon 18 Stunden auf den Beinen...
 
Hallo Daniel,

du hast natürlich vollkommen Recht. Grundsätzlich sollte Non-existent zurück kommen.

nslookup 1.1.3.192.spam.spamrats.com. 1.1.1.1
Server: one.one.one.one
Address: 1.1.1.1

DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
*** Zeitüberschreitung bei Anforderung an one.one.one.one.

nslookup 1.1.3.192.spam.spamrats.com. 8.8.8.8
Server: dns.google
Address: 8.8.8.8

DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
*** Zeitüberschreitung bei Anforderung an dns.google.

nslookup 1.1.3.192.spam.spamrats.com. 9.9.9.9
Server: dns9.quad9.net
Address: 9.9.9.9

*** 1.1.3.192.spam.spamrats.com. wurde von dns9.quad9.net nicht gefunden: Non-existent domain.
Hab das gerade nochmal durchgespielt und jetzt gerade scheint 9.9.9.9 zu funktionieren... Damit kannste aber ja überhaupt nicht planen.
Mein API-Key ist bislang auch noch nicht gekommen. Eigentlich sollte dieser binnen 1h laut Spamrats kommen. Bestätigungsmail habe ich natürlich aktiviert, aber bislang ist noch nichts da...

Schauen wir mal, ob da noch was kommt. Ansonsten muss ich die wohl einfach wirklich draußen lassen. Oder das Error-Handling muss da entsprechend im Code angepasst werden. @JanJäschke / @StefanCink ;-)

Beste Grüße
Alex
 
Guten Morgen,
gleiches Verhalten bei uns seit gestern. Wir nutzen Google DNS Server. Wenn sich das im Tagesverlauf nicht ändert muss ich wohl oder übel Spamrats rausnehmen.
VG
 
Hallo Daniel,

du hast natürlich vollkommen Recht. Grundsätzlich sollte Non-existent zurück kommen.


Hab das gerade nochmal durchgespielt und jetzt gerade scheint 9.9.9.9 zu funktionieren... Damit kannste aber ja überhaupt nicht planen.
Mein API-Key ist bislang auch noch nicht gekommen. Eigentlich sollte dieser binnen 1h laut Spamrats kommen. Bestätigungsmail habe ich natürlich aktiviert, aber bislang ist noch nichts da...

Schauen wir mal, ob da noch was kommt. Ansonsten muss ich die wohl einfach wirklich draußen lassen. Oder das Error-Handling muss da entsprechend im Code angepasst werden. @JanJäschke / @StefanCink ;-)

Beste Grüße
Alex
ich werde es mir mal intern anschauen ☺️
 
Hallo zusammen,
bis Jan sich wieder von der IT-SA erholt hat, würde ich für einen weiteren Test die DNS-Server eures jeweiligen ISP hinterlegen. Ist sowieso empfohlen, wenn man Cloud Dienste konsumiert. Ich tippe nach wie vor auf eine DNS-Sperre seitens Anbieter.

Unabhängig davon würde mich interessieren, was die DNSBL von Spamrats an Mehrwert bietet?!


Gruß,
Daniel
 
Zuletzt bearbeitet:
Ach kein Stress, eine Übergangslösung gibt es ja :)


Wieso sollte man dann den DNS von in unserem Fall der Telekom nutzen? Das erschließt sich mir nicht ganz...

Wahrscheinlich ist der Mehrwert tatsächlich nur marginal. Aber jeder Baustein ist eben ein Quäntchen mehr.

Viele Grüße
Alex
 
Hallo Alex,
Ach kein Stress, eine Übergangslösung gibt es ja :)
Wenn es eine DNS Sperre ist, kann Jan nichts bewirken. ;) Daher würde es mich brennend interessieren.

Wieso sollte man dann den DNS von in unserem Fall der Telekom nutzen? Das erschließt sich mir nicht ganz...
Details kannst du hier nachlesen.

Wahrscheinlich ist der Mehrwert tatsächlich nur marginal. Aber jeder Baustein ist eben ein Quäntchen mehr.
Gerne mal die erfassten Daten anschauen, ob und wie oft die Liste einen Hit hatte. Ich habe die Liste noch nie in meiner jungen Karriere mit NSP verwendet. Daher würden mich Daten dazu interessieren. Klar, lieben haben als brauchen. Ich sage immer, weniger ist mehr. :p


Gruß,
Daniel
 
Moin Daniel,

Wenn es eine DNS Sperre ist, kann Jan nichts bewirken. ;) Daher würde es mich brennend interessieren.
Immerhin könnte das Error Handling verbessert werden, damit man auch sehen kann, wo der Fehler herkommt.

Details kannst du hier nachlesen.
Das werde ich mir zu Gemüte führen, vielen Dank!

Gerne mal die erfassten Daten anschauen, ob und wie oft die Liste einen Hit hatte. Ich habe die Liste noch nie in meiner jungen Karriere mit NSP verwendet. Daher würden mich Daten dazu interessieren. Klar, lieben haben als brauchen. Ich sage immer, weniger ist mehr. :p
Gibt es eine Möglichkeit das schnell und einfach kummuliert herauszufinden?

Viele Grüße und einen guten Wochenstart!
Alex
 
Hallo Alex,
Immerhin könnte das Error Handling verbessert werden, damit man auch sehen kann, wo der Fehler herkommt.
Da sind wir schon zwei. Die Frage kann ich dir leider auch nicht beantworten. Ich frage mich seit Anfang an, warum das nicht möglich ist. Bisher hat mir darauf noch niemand eine Antwort gegeben.

Gibt es eine Möglichkeit das schnell und einfach kummuliert herauszufinden?
Schnell und einfach ist relativ. Müsstest du über eine SQL-Abfrage direkt auf der Datenbank der Intranet-Rolle auswerten. Das erfordert aber entsprechende Zugriffsrechte und etwas Erfahrung mit SQL, sonst wird es schnell kompliziert.


Gruß,
Daniel
 
Zuletzt bearbeitet:
Zurück
Oben