Moin zusammen,
nachdem ich mit Jörg W. zum Thema schon in einem Ticket diskutiert habe und er mich auch an das Forum verwiesen hat, möchte ich zu den bereits vorhandenen Themen noch ein weiteres Thema eröffnen, da die anderen Themen bereits ein gewisses Alter erreicht haben und sich die Diskussion in meinen Augen auch versandet ist.
Das Problem, was ich habe, ist sehr ähnlich zu diesem Fall:
Bei uns stellt es sich so dar, dass eine E-Mail von einem Newsletterserver relayed wurde und es so aussieht, dass die E-Mail wirklich vom Originalserver kommt. In der Nachrichtenverfolgung des NSP kann man dies nicht von anderen, echten E-Mails unterscheiden. Erst die Prüfung des Headers hat hier den originalen Quellserver geliefert.
Darüber bin ich dann mit Jörg in die Diskussion zum LoT gekommen und habe auch hier diesen Beitrag gefunden:
Die Beispielrechnungen in den Docs hat mir Jörg auch freundlicherweise zur Verfügung gestellt.
docs.nospamproxy.com
Was ich hier aber als gravierendes Probleme sehe, wird auch schon im ersten Link beschrieben. Die Berechnung führt ab einem bestimmten Vertrauenslevel zu so absurd hohen Berechnungswerten, dass als Ergebnis immer -10 herauskommen muss, weil dort ja gecuttet wird.
In unserem Fall kam eine E-Mail rein, die von der Core Antispam Engine mit 4 Punkten und vom Reputationsfilter mit 1 bewertet wurde. 5 SCL-Punkte würden für eine Ablehnung sorgen. Das Trustlevel liegt bei 45, was zu einem berechneten Wert von -31 (!) führt.
Warum?
Wir haben mehrere Filter drin, die bei aufsummierten Multiplikatoren einen Wert von 9 ergeben.
Gemäß des Links zur Berechnung ergibt sich somit für den Gesamt-SCL:
9 * -4 = -36
5 SCL-Punkte durch die Filter
-36 + 5 = -31
Selbst bei einer deutlich einfacheren Berechnung 5 - (45/10) = 0,5 wäre die E-Mail in diesem Fall ja durchgekommen.
Allerdings führt in der aktuellen Konfiguration und in unserer Filteransammlung dazu, dass jedes Vertrauenslevel die E-Mail durchgelassen hätte. Gut, die Idee hinter dem LoT ist ja, dass auch bei temporär schlechter Bewertung des Absenders noch Mails durchkommen. Auf einer Blacklist landet man ja mit Pech schneller, als einem das lieb ist.
Trotzdem haben wir hier in meinen Augen einen Mangel in der Berechnung und das LoT damit nicht wirklich nutzbar, weil schon das kleinste Trustlevel durch die Anzahl und Werte der Filter einen so heftigen Hebel bekommt, dass alles durchgehen wird, egal wie schlecht, von Viren und oder unerwünschten Anhängen mal abgesehen. Der URL-Safeguard hat im Übrigen hier nicht angeschlagen.
Technisch am Sichersten wären E-Mails natürlich im TXT-Format, ohne HTML, Hyperlinks und Anhänge grundsätzlich auch zu verbieten. Das wird nur niemand akzeptieren.
Für das LoT würde ich mir aber wünschen, dass man hier die Berechnung noch einmal überdenkt.
Ich weiß nicht, ob das bereits implementiert ist und ich es einfach nicht finde, aber in meinen Augen wäre vielleicht eine Art Vergleich mit bereits bekannten Mails desselben Absenderservers eine Idee. Wie gesagt konnte man im Vergleich der Header andere Quellserver finden, die vorher nicht aufgeführt waren, außerdem eine chinesische IP - Geoblocking gibt es aktuell ja leider auch noch nicht. Im Header tauchte außerdem ein Wert auf, den andere Mails ebenfalls nicht hatten: X-<Newslettersende>-Incoming. Hätte also ein solcher Vergleich stattgefunden und ein Veto gegenüber dem LoT gehabt, wäre die Mail nicht durchgegangen - eine Idee vielleicht?
So sehr ich die Konfiguration und Verschachtelung einer Cisco Ironport / ESA manchmal verflucht habe, die Möglichkeiten bestimmte Header nach Auftreten einfach zu blockieren oder gegenüber dem dem NSP auch bestimmte Header einfügen oder abfragen zu können, das hatte schon etwas.
Bin gespannt, was ihr denkt.
Gruß
Michael
nachdem ich mit Jörg W. zum Thema schon in einem Ticket diskutiert habe und er mich auch an das Forum verwiesen hat, möchte ich zu den bereits vorhandenen Themen noch ein weiteres Thema eröffnen, da die anderen Themen bereits ein gewisses Alter erreicht haben und sich die Diskussion in meinen Augen auch versandet ist.
Das Problem, was ich habe, ist sehr ähnlich zu diesem Fall:
Bei uns stellt es sich so dar, dass eine E-Mail von einem Newsletterserver relayed wurde und es so aussieht, dass die E-Mail wirklich vom Originalserver kommt. In der Nachrichtenverfolgung des NSP kann man dies nicht von anderen, echten E-Mails unterscheiden. Erst die Prüfung des Headers hat hier den originalen Quellserver geliefert.
Darüber bin ich dann mit Jörg in die Diskussion zum LoT gekommen und habe auch hier diesen Beitrag gefunden:
Die Beispielrechnungen in den Docs hat mir Jörg auch freundlicherweise zur Verfügung gestellt.
Spam Confidence Level (SCL)
docs.nospamproxy.com
Was ich hier aber als gravierendes Probleme sehe, wird auch schon im ersten Link beschrieben. Die Berechnung führt ab einem bestimmten Vertrauenslevel zu so absurd hohen Berechnungswerten, dass als Ergebnis immer -10 herauskommen muss, weil dort ja gecuttet wird.
In unserem Fall kam eine E-Mail rein, die von der Core Antispam Engine mit 4 Punkten und vom Reputationsfilter mit 1 bewertet wurde. 5 SCL-Punkte würden für eine Ablehnung sorgen. Das Trustlevel liegt bei 45, was zu einem berechneten Wert von -31 (!) führt.
Warum?
Wir haben mehrere Filter drin, die bei aufsummierten Multiplikatoren einen Wert von 9 ergeben.
Gemäß des Links zur Berechnung ergibt sich somit für den Gesamt-SCL:
9 * -4 = -36
5 SCL-Punkte durch die Filter
-36 + 5 = -31
Selbst bei einer deutlich einfacheren Berechnung 5 - (45/10) = 0,5 wäre die E-Mail in diesem Fall ja durchgekommen.
Allerdings führt in der aktuellen Konfiguration und in unserer Filteransammlung dazu, dass jedes Vertrauenslevel die E-Mail durchgelassen hätte. Gut, die Idee hinter dem LoT ist ja, dass auch bei temporär schlechter Bewertung des Absenders noch Mails durchkommen. Auf einer Blacklist landet man ja mit Pech schneller, als einem das lieb ist.
Trotzdem haben wir hier in meinen Augen einen Mangel in der Berechnung und das LoT damit nicht wirklich nutzbar, weil schon das kleinste Trustlevel durch die Anzahl und Werte der Filter einen so heftigen Hebel bekommt, dass alles durchgehen wird, egal wie schlecht, von Viren und oder unerwünschten Anhängen mal abgesehen. Der URL-Safeguard hat im Übrigen hier nicht angeschlagen.
Technisch am Sichersten wären E-Mails natürlich im TXT-Format, ohne HTML, Hyperlinks und Anhänge grundsätzlich auch zu verbieten. Das wird nur niemand akzeptieren.
Für das LoT würde ich mir aber wünschen, dass man hier die Berechnung noch einmal überdenkt.
Ich weiß nicht, ob das bereits implementiert ist und ich es einfach nicht finde, aber in meinen Augen wäre vielleicht eine Art Vergleich mit bereits bekannten Mails desselben Absenderservers eine Idee. Wie gesagt konnte man im Vergleich der Header andere Quellserver finden, die vorher nicht aufgeführt waren, außerdem eine chinesische IP - Geoblocking gibt es aktuell ja leider auch noch nicht. Im Header tauchte außerdem ein Wert auf, den andere Mails ebenfalls nicht hatten: X-<Newslettersende>-Incoming. Hätte also ein solcher Vergleich stattgefunden und ein Veto gegenüber dem LoT gehabt, wäre die Mail nicht durchgegangen - eine Idee vielleicht?
So sehr ich die Konfiguration und Verschachtelung einer Cisco Ironport / ESA manchmal verflucht habe, die Möglichkeiten bestimmte Header nach Auftreten einfach zu blockieren oder gegenüber dem dem NSP auch bestimmte Header einfügen oder abfragen zu können, das hatte schon etwas.
Bin gespannt, was ihr denkt.
Gruß
Michael
Zuletzt bearbeitet von einem Moderator:
