Frage zur Fehlereingrenzung beim Mailversand

[mabu]

Hallo.

Heute ist in einem Fall zufällig aufgefallen, dass eine Mail, die laut NSP nicht versendet werden konnte (Grund 4.7.1 This email was rejected because it violates our security policy / 4.7.1 The message could not be validated successfully. ) gar nicht der externe Mailserver diese Mitteilung liefert, sondern die NSP-Gatewayrolle.

Bei uns sieht es so aus (Multimandantenumgebung in einem RZ - nicht unser Exchange), dass zwischen Exchange und dem NSP zwei Relay-Server vom RZ platziert worden sind. Die IPs dieser beiden Relay-Server sind auch in den "Mailservern des Unternehmens" hinzufügt worden.

Nun schickt ein User einen Replay auf eine Mail und dabei sind 4 Empfänger von @domain1.de enthalten. Fehler kommt (bzw. "temporär nicht zugestellt" und in regelmäßigen Abständen taucht die Meldung nun auf). Schickt er die gleiche Mail an einen der Empfänger, geht diese durch.

Anderer User mit Replay auf eine Mail und auch hier wieder mehrere Empfänger von @domain2.de enthalten. Fehler kommt auch hier genauso. Mail an einen einzelnen in der @domain2.de und es klappt sofort.

Der Absender erhält die Fehlermeldung (wohl vom Relay-Server) dann auch erst einige Tage später, da der Relay wohl immer weiter versucht, die Mail loszuwerden.

In der Nachrichtenverfolgung sehe ich überhaupt nichts, was die Ursache dafür sein könnte.

Frage nun: was sollte ich im Logging auf der GW-Rolle aktivieren, damit ich hier am besten analysieren kann, warum die GW-Rolle diese Mail mit 4.7.1 ablehnt?

Zum Testen kann ich ja problemlos eine Testmail an die jeweils 4 Mailadressen schicken und bekomme dann hoffentlich das problematische Verhalten repliziert.

 

[869288141]

Guten Abend Martin,
aktiviere doch unter Erweitere Einstellungen -> Monitoring den Parameter "Ungültige Absender und Empfänger...". Anschließend stelle das Problem nochmals nach. Dann solltest du in der Nachrichtenverfolgung mehr dazu sehen können.

Schickt er die gleiche Mail an einen der Empfänger, geht diese durch.

Immer der gleichen Empfänger oder ist es egal welcher der 4?


Gruß,
Daniel

 

[mabu]

Hallo Daniel.

Ich habe das eben mal aktiviert und anschließend hat User dann die gleiche Mail nur mit "TEST" als Vorsatzwort im Betreff noch einmal geschickt.

In der Nachrichtenverfolgung in der NCC sehe ich da aber keine Änderung - in der WebApp genauso.

Muss evtl. die GW-Rolle neu gestartet werden, wenn die Einstellung im Monitoring aktiviert wird?

Zum Einzelversand: wir haben in beiden Fällen tatsächlich nur den "Hauptempfänger" genutzt und es mit den weiteren Adressen nicht separat probiert.

Hinweis: ich habe auch geprüft, wie es mit vorhandenen S/MIME-Zertifikaten der Empfänger aussieht. Bei einer Firma haben wir überhaupt keine Zertifikate vorliegen. Bei der anderen teilweise für einige der Empfänger. Die Domänen sind aber auch nicht in der Regel für Zwangsverschlüsselung (wo auch die Fehlermeldung eine andere wäre, wenn dies das Problem sein sollte).

Da es leider ein Mailrelay vom RZ ist, muss ich das irgendwie eingrenzen, sollte der Fehler auf deren Seite liegen. Dafür könnte ich mir das Logging auf der GW-Rolle vorstellen. Bin nur nicht sicher, was von den Optionen da dann wirklich zu aktivieren ist.

 

[Sören]

Bin nur nicht sicher, was von den Optionen da dann wirklich zu aktivieren ist.

Proxy System, Mail Validation, Mail Delivery Service -> wenn dann die Testmail wieder abgewiesen wurde, starte bitte einmal die GW Rollen neu, denn erst dann werden die Logs finalisiert geschrieben!

Du brauchst halt den svctraceviewer um die Logs analysieren zu können. Wenn du nicht weiter kommst, sende mir die Logs per PN. Aber dann bitte vorbereitet! Ich brauch das Zeitfenster wann die Mail nicht verarbeitet wurde durch den NSP, ich brauch im besten Fall die IP, ich brauch den Absender und den Empfänger und am besten noch die MSG ID. Versuch bitte so viele Infos zu liefern wie nur möglich!

Noch ein Hinweis: du schreibst ja das die Mails nicht im Monitoring auftauchen. Dann geh mal bitte in den global tenant und schau da nach, denn Mails die wir keinem Tenant zuordnen können, landen dort.

Muss evtl. die GW-Rolle neu gestartet werden, wenn die Einstellung im Monitoring aktiviert wird?

Starte mal zur Sicherheit die Rollen neu und u.U. schon die geblockten IP löschen, zur Sicherheit hier:

 

[mabu]

Danke für die Infos.

Irgendwie war "GW-Rolle neu starten" generell die Lösung Also ich habe erneut im Monitoring die eine Option aktiviert und anschließend diesmal die GW-Rolle neu gestartet - und auf einmal ging die Testmail sofort durch und der interne Relay-Server im RZ ist auch andere Mails, die die GW-Rolle vorher abgelehnt hat, losgeworden.

Von der Mail an die weitere Domäne mit den 4 Empfängern habe ich noch keine Rückmeldung von einem erneuten Test. Vermute aber, dass es da nun auch klappt.

Was auch immer da los war - Neustart der GW-Rolle hat Problem behoben. Wäre ich jetzt so nicht drauf gekommen als möglichen Lösungsweg. Wieder was dazugelernt.

 

[Sören]

ich mag nicht ausschließen, leider, dass das ein bug ist der wieder auftritt... sollte dem so sein, dann schreib mich bitte direkt an damit wir uns das anschaune können

aber erstmal bin ich auch happy das es wieder geht

 

[Stavros.Petropoulos]

Dies betrifft uns wohl auch. Ein Endkunde erhält eine Mail, welche abgelehnt wird mit folgender Fehlermeldung:
"4.7.1 This email was rejected because it violates our security policy
4.7.1 The message could not be validated successfully."
Ich probiere es auch mit Neustarts der Gateways und hoffe auf Besserung

EDIT:
Ich sehe bei 2 betroffenen Mails folgende Fehlermeldung beim Filter "Spam URI Realtime Blocklists":
"Filter konnte nicht rechtzeitig beendet werden und wurde abgebrochen."
Eventuell ist das die Ursache?

 

[Sören]

Dies betrifft uns wohl auch. Ein Endkunde erhält eine Mail, welche abgelehnt wird mit folgender Fehlermeldung:
"4.7.1 This email was rejected because it violates our security policy
4.7.1 The message could not be validated successfully."
Ich probiere es auch mit Neustarts der Gateways und hoffe auf Besserung

EDIT:
Ich sehe bei 2 betroffenen Mails folgende Fehlermeldung beim Filter "Spam URI Realtime Blocklists":
"Filter konnte nicht rechtzeitig beendet werden und wurde abgebrochen."
Eventuell ist das die Ursache?

sende mir mal bitte die Message Track als PN

 

[teamrocket0]

Hallo zusammen,
ich habe leider das gleich Problem aber mit dem Reputationsfilter.
Dort habe ich ebenfalls diese Fehlermeldung: Filter konnte nicht rechtzeitig beendet werden und wurde abgebrochen.
Ein Dienste Neustart half leider nicht.
Hat noch jemand eine Idee?

 

[Sören]

Hallo zusammen,
ich habe leider das gleich Problem aber mit dem Reputationsfilter.
Dort habe ich ebenfalls diese Fehlermeldung: Filter konnte nicht rechtzeitig beendet werden und wurde abgebrochen.
Ein Dienste Neustart half leider nicht.
Hat noch jemand eine Idee?

evtl braucht der angefragte DNS Server zu lange um antworten zu liefern, du kannst mal Testweise Google oder Cloudflare DNS im NSP eintragen:

 

[869288141]

evtl braucht der angefragte DNS Server zu lange um antworten zu liefern

Wenn dir evtl. Datenschutz etwas bedeutet, würde ich dir die DNS Server deines ISP empfehlen. Ist meisten sowieso die beste Lösung. Weil dadurch gerade bei CDNs auch die IP-Adresse des nächstliegende Endpunkt zurückgeben wird. Ansonsten kann vorkommen, dass eine Anfrage durch halb Europa geht. Alternativ kannst du mit Wireshark die Pakete und Laufzeiten anschauen.