Themabewertung:
  • 0 Bewertung(en) - 0 im Durchschnitt
  • 1
  • 2
  • 3
  • 4
  • 5
Es wurde kein Boni vergeben
#1
Shocked 
Guten Abend NSP-Team,
zum Wochenstart beschäftigt mich die Nachrichtenverfolgung. Genauer gesagt der Hinweis "Es wurde kein Boni vergeben, da die E-Mail nicht authentifiziert" in den Details der Nachrichtenverfolgung im Reiter "Überprüfung". Fährt man mit dem Mauszeiger über das Wort "authentifiziert" erscheint folgender Hinweis.
   

Unser NSP nimmt für mehrere Domains (domaina.de und domainb.de) E-Mails an. Für domaina.de nehmen unsere NSP Gateways direkt E-Mails vom Absender via SMTP entgegen. Hingegen für domainb.de werden die E-Mails (eingehend/ausgehend) über E-Mailserver eines IT-Dienstleisters. Der E-Mail Server fungiert als Relay und nicht als Proxy. Das Verhalten kann leider auch nicht geändert werden.

Das hat zur Folge, dass wir bei der dafür angelegten eingehenden Regel im NSP auf die Prüfung des SPF Eintrags verzichten müssen. Anderenfalls schlägt bei jeder E-Mail an domainb.de der Filter an und vergibt SCL Punkte. Das hat zur Folge, dass die Funktion Level of Trust laut der Beschreibung (siehe Screenshot) nicht mehr angewendet wird.

Daher würde ich gerne auf das "vertraute Subnetz" ausweichen, um LoT auch für domainb.de wieder nutzen können. Allerdings habe ich in der NSP Management Konsole die entsprechende Einstellung nicht gefunden. Ich habe die IP-Adressen vorab unter E-Mail-Routing -> E-Mail-Servers des Unternehmen eingetragen - erfolglos.

Was mir aufgefallen ist, dass unter Erweiterte Einstellungen -> Level-of-Trust-Konfiguration ebenfalls bei dem Wort Authentifizierung ein Hinweis eingeblendet wird. Dort ist allerdings von "vertrauten Subnetz" keine Rede.
   

Kann mir jemand auf die Sprünge helfen, wo ich die IP-Adressen eintragen kann?
Gerne habe ich auch für "schönere" Lösungen ein offenes Ohr. :-)

Gruß,
Daniel
Zitieren
#2
Hallo Daniel,

das "vertraute Subnetz" kann nur mittels PowerShell gesetzt werden:
Set-NspPartnerTrustDetails -Domain google.com -AddSubnets 8.8.8.8/32
und zum entfernen:
Set-NspPartnerTrustDetails -RemoveSubnets 8.8.8.8/32 -Domain google.com

Damit bindest du also ein Subnetz an die Partner was dir in deinem Fall denke ich nicht wirklich groß weiter hilft.
Wenn du nun für einzelne Partner einen Trust haben möchtest weil du weißt, dass die sind vertrauenswürdig und die sollen z.B. im URL Safeguard anders behandelt werden würde ich eher den Weg gehen und einen statischen Trust Wert im Partner setzen.

Etwas groß besseres fällt mir spontan auch nicht ein, das ist einfach wirklich ein risen nachteil, dass eine Reputationsprüfung in dieser Richtung durch das SMTP Relay nicht möglich ist :/


Gruß,
Jan
Zitieren
#3
Hallo Jan,
in diesem Fall hilft mir das Feature nicht weiter. Weil ich müsste somit alle Absender Domains als vertrauenwürdig markieren. Somit ist der NSP fast wirkungslos.
Ich bin ziemlich sicher, dass ich hier nicht alleine bin mit der geschilderten Problematik.

Warum wird die Funktion L-o-T überhaupt an SPF, DKIM, S/MIME u.ä. gekoppelt? Gerade die Merkmale V-Punkte für die Absender Domäne, V-Punkte für die Beziehung zwischen Abender und Empfänger, V-Punkte für den Absender in der Nachrichtenverfolgung sind meiner Meinung nach davon unabhängig.


Gruß,
Daniel
Zitieren
#4
(25.05.2020, 13:34)SBW schrieb: Hallo Jan,
in diesem Fall hilft mir das Feature nicht weiter. Weil ich müsste somit alle Absender Domains als vertrauenwürdig markieren. Somit ist der NSP fast wirkungslos.
Ich bin ziemlich sicher, dass ich hier nicht alleine bin mit der geschilderten Problematik.

Warum wird die Funktion L-o-T überhaupt an SPF, DKIM, S/MIME u.ä. gekoppelt? Gerade die Merkmale V-Punkte für die Absender Domäne, V-Punkte für die Beziehung zwischen Abender und Empfänger, V-Punkte für den Absender in der Nachrichtenverfolgung sind meiner Meinung nach davon unabhängig.


Gruß,
Dani
Hallo Dani,

wenn nicht als MX fungiert, ist Protection offiziell keine unterstützte Umgebung. Es gibt einige Ausnahmen, bei denen wir dem Kunden das im Vorfeld gesagt haben (es steht aber auch überall in den Installationsvoraussetzungen) und der Kunde mit den Einschränkungen leben muss. Im Prinzip kann ich Dir nur raten, für die E-Mails von dem vorgeschalteten Provider für domainb.de eine eigene Regel zu erstellen, in der die meisten Prüfungen abgeschaltet sind. Die Malware-Action kann und sollte aktiviert bleiben.

Die Frage nach dem Warum ist schnell beantwortet: In Zeiten von EMOTET wäre eine Bonuspunkte-Vergabe ohne Prüfungen ein fataler Fehler. Absender-Adressen werden im großen Stil gefälscht und müssen daher abgesichert sein.

Gruß Stefan
Zitieren
#5
Hallo Stefan,
Zitat:wenn nicht als MX fungiert, ist Protection offiziell keine unterstützte Umgebung. Es gibt einige Ausnahmen, bei denen wir dem Kunden das im Vorfeld gesagt haben (es steht aber auch überall in den Installationsvoraussetzungen) und der Kunde mit den Einschränkungen leben muss.
ich meine sogar, dass du uns bei Einführung gewarnt hast. Allerdings nach fast 6 Jahren wollte ich unverblühmt nachfragen. Wink  Evtl. gibt es inzwischen anderweitige Lösungsansätze für die Thematik.

Zitat:Im Prinzip kann ich Dir nur raten, für die E-Mails von dem vorgeschalteten Provider für domainb.de eine eigene Regel zu erstellen, in der die meisten Prüfungen abgeschaltet sind.

Das ist leider nicht aus organisatorischen als auch technischen Gründen nicht möglich. Details möchte ich an der Stelle nicht öffentlich nennen.

Zitat:Die Frage nach dem Warum ist schnell beantwortet: In Zeiten von EMOTET wäre eine Bonuspunkte-Vergabe ohne Prüfungen ein fataler Fehler. Absender-Adressen werden im großen Stil gefälscht und müssen daher abgesichert sein.

Das Problem ist eigentlich nur SPF. Alle anderen Verfahren scheren sich nicht darum ob SMTP Proxy oder Relay, direkte Zustellung oder über 6 Server. DKIM wird nach wie vor nur schleppend umgesetzt und mit S/MIME könnene viele gar nichts anfangen.


Gruß,
Daniel
Zitieren
#6
Es gibt noch eine weitere Möglichkeit. Da dies aber ein öffentlicher Thread ist, möchte ich zunächst alle anderen Leser*innen ausdrücklich davor warnen. Es hat einen triftigen, sicherheitsrelevanten Grund, warum wir Bonuspunkte nur nach vorheriger Authentifizierung vergeben!
In der MMC unter "Konfiguration / Erweiterte Einstellung" gibt es im Abschnitt "Level of Trust" die Einstellmöglichkeit für das Level of Trust-System. Dort kann man auf der ersten Registerkarte unter "Authentifizierung" den Radiobutton auf "Erfordere eine Authentifizierung nur für den Domänenbonus" einstellen. Wenn das ausgewählt ist, werden für Adresspärchen stumpf Bonuspunkte vergeben, ohne weitere Prüfung. Für die Domäne gibt es auch weiterhin keine Bonuspunkte.
Hilft das evtl. schon weiter?
Gruß Stefan
Zitieren
#7
Guten Abend Stefan,
vielen Dank für die Idee. Ich werde mir die Thematik in aller Ruhe skizzieren, die Vor- und Nachteile abwägen sowie mögliche Auswirkungen durchspielen.
Das muss - wie du schon geschrieben hast - sehr, sehr gut durchdacht sein. Sonst ist der Schaden hinterher größer als vorher der Nutzen.


Gruß,
Daniel
Zitieren


Gehe zu:


Benutzer, die gerade dieses Thema anschauen: 1 Gast/Gäste