KeyHelp Community

Wenn man es richtig umsetzt würde der "eine böse User" gar nicht auffallen.

Ich weiß ja nicht wieviele Postfächer du betreust, aber bei mir ist das eine fünfstellige Zahl.
Ebenso bei einigen guten Kollegen mit welchen ich mich bedenkenlos vernetzen würde.

Wenn dann am Ende einer von über 250.000 Postfach-Usern Unsinn treibt, dann soll er das eben.
https://de.wikipedia.org/wiki/Normalverteilung

IPs, Email Adressen oder Domain Namen blockieren bringt kaum eine Entlastung, weil Phishing & Malware Crap über riesige Botnets verteilt werden ... am effektivsten ist ein Content blocking, also z.b. nur der Domain Name aus der URL im content (links zu malware, images etc.) oder halt spezielle Text Parts ... die schnappe ich mir über body checks, dazu noch postscreen in Verbindung mit einem F2B RBL Filter.

Tobi wrote: ↑Wed 19. Feb 2025, 13:10 Damit nicht ein bestimmter "Listenbereitsteller" verklagt werden kann muss es einen Karussell-Server geben.
Dieser stellt keine Liste bereit sondern leitet die eingehende Anfrage an einen zufälligen KeyHelp-Server weiter.
Somit kann man nie genau sagen welcher Endpoint-Server letztendlich zur Sperrung einer bestimmten Mail geführt hat.

Die Idee ist im Grunde gut, aber es könnte auch nur eine kurzfristige "Schlupfloch" Lösung werden ... wenn das so weitergeht mit der Regulierungswut.
Solche Auflagen in einer Zeit extremster Cyberattacken berücksichtigen zu müssen, also mehr oder weniger Hostsysteme schutzlos zu betreiben im Sinne der DSGVO oder was auch immer, ist allerdings auch keine Lösung. Anbieter solcher Listen sollten unterstützt und nicht abgestraft werden oder die EU soll eben selbst einen effektivn DNSBL Server bereitstellen.
Wenn dies nicht möglich ist, wäre es sinnvoll die wirklich undurchdachten, selbstzerstörerischen Auflagen zu widerrufen ... Petition, Verfassungsbeschwerde, Demos, Revolution etc.

Wen verklagst du wenn du im Darknet falsche Anschuldigungen findest?

Genau nach diesem anonymen Prinzip stelle ich mir den Hashwert-Austausch von deinen o.g. „Text Parts“ oder „bodychecks“ vor.

Wenn dann plötzlich innerhalb kürzester Zeit viele voneinander unabhängige Server denselben Hashwert annoncieren, dann kann mein Server E-Mails mit denselben Merkmalen abwehren und ggf. sogar bereits empfangene Mails rückwirkend löschen.

Moin Tobi!
der Austausch oder die Breitstellung von Spam, Phish Auswertungen die content basierend sind (keywords, domain name, url shortener) sollte problemlos möglich sein, wenn darin keine IP Adressen oder explizite Emailadressen vorhanden sind. In dem Fall wäre auch kein anonymes PingPong notwendig.
Ok, das könnte effektiv sein bei einer internen Rotation ... eine extra mit rotierende Domain whitelist könnte bei fehlerhaften Markierungen nützlich sein.

Guten Morgen!

So richtig verstehe beim Mitlesen nicht, wo der Unterschied zu den Fuzzy-Hashes und der Blacklist unter bl.rspamd.com ist. Warum etwas in klein neu aufziehen, was es in groß und funktional bereits gibt und das bereits in rspamd enthalten ist? Auch da ist es so, dass es interne Thresholds gibt und die Hashes gewichtet werden, sodass nicht eine Meldung zwingend sofort ein FUZZY_DENIED auslöst.

Vielleicht entgeht mir etwas, aber die rspamd.com-Leute machen eigentlich genau das mit Fuzzy und ihrer Blacklist. Geht es nur darum, ein Netz "vertrauenswürdiger" Server zu bauen?

Grüße,
Thorsten

Vor allem geht es darum ein Netzwerk aufzubauen welches nicht an einen bestimmten Betreiber gebunden ist und von heute auf morgen deaktiviert werden kann.

Die Abschaltung der Blacklist von ix.bla.bla ist ein sehr gutes Beispiel dafür wie finanzielle Interessen die Meinungsfreiheit einschränken können.

Ralph wrote: ↑Thu 20. Feb 2025, 10:03 oder die Breitstellung

sorry, es sollte Bereitstellung heißen, die "Breitstellung" war lediglich ein Tippfehler

Das hat mich jetzt mit voller Breitseite getroffen

Ich bin aktuell in der Planung eine zentrale Datenbank für meine Hosting Server in Frankfurt aufzubauen, würde mich auch bereiterklären diese dann potenziell zu teilen, wenn Interesse bestünde ..

+1 Gute Idee

Diese (leer) Attacken von verbrannten IP Adressen aus, die nur darauf abzielen DNSBL lookup rate limits zu überschreiten haben sich nochmals gut verdoppelt ... meine rejects (beim shared hosting) liegen derzeit bei ca. 60-70% (glücklicherweise noch, über EU externe DNSBL).
Die DNSBL rate limits werden sich zwangsläufig bei den noch übrig gebliebenen Anbietern weiter verschärfen, also Ziel der Attacken ist es auch die verbliebenen DNSBL Anbieter nicht mehr nutzen zu können um damit freie Bahn zu schaffen für malware, phishing & hacking.
Neue zusätzliche IP & Content Blacklists (intern o. extern) sind bei diesem Ausmaß an Attacken momentan unverzichtbar, auch direkte Attacken auf Webs und Systeme gehen durch die Decke, User bekommen von gehackten Websites meistens erst später davon mit und die Angreifer IPs sind dann bereits aufgrund der DSGVO Frist nicht mehr feststellbar ... der Anbieter bekommt dann erstmal die Schuld Zuweisungen ab. Die derzeitigen EU Vorgaben unterstützen jedenfalls massivst die Angreifer und dass kann so nicht weitergehen, alle wirkungsvollen Lösungen ob jetzt konform oder nicht sind mir äusserst willkommen.

Ralph wrote: ↑Mon 3. Mar 2025, 09:44 Diese (leer) Attacken von verbrannten IP Adressen aus, die nur darauf abzielen DNSBL lookup rate limits zu überschreiten haben sich nochmals gut verdoppelt ... meine rejects (beim shared hosting) liegen derzeit bei ca. 60-70% (glücklicherweise noch, über EU externe DNSBL).
Die DNSBL rate limits werden sich zwangsläufig bei den noch übrig gebliebenen Anbietern weiter verschärfen, also Ziel der Attacken ist es auch die verbliebenen DNSBL Anbieter nicht mehr nutzen zu können um damit freie Bahn zu schaffen für malware, phishing & hacking.
Neue zusätzliche IP & Content Blacklists (intern o. extern) sind bei diesem Ausmaß an Attacken momentan unverzichtbar [...]

Gutes Argument.