|
Diese Diskussion wurde archiviert.
Es können keine neuen Kommentare abgegeben werden.
|
 |
|
|
|
Von Anonymer Feigling am Saturday 07. August 2004, 10:17 MEW (#1)
|
|
|
|
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Saturday 07. August 2004, 10:31 MEW (#2)
|
|
|
|
|
Das verwendete Verfahren kursiert seit einiger Zeit - einfach mal nach "greylisting" googeln.
Bis jetzt ist das Ergebnis verblüffend. Bei mir eingesetzt (mit sendmail/MIMEDefang) eliminiert es >98% des ankommenden Spams. Ich verzichte im Moment sogar auf TMDA, da die sonst eintrudelnden 500-800 Spam-Mails pro Tag jetzt wieder auf ein erträgliches Mass reduziert sind. Dafür nehme ich Mailverzögerungen im Bereich von 10 Minuten bis einer Stunde in kauf.
Allzu grosse Hoffnungen sollte man sich nicht machen - der Schutz ist recht einfach zu umgehen. Im Prinzip reicht es, wenn Spammer (resp. Spamproxies) ihre Adressliste einfach zeitversetzt um eine halbe bis eine Stunde durchgehen. Grossartiges Queueing und reagieren auf TEMPFAIL ist dazu gar nicht notwendig. Zum Glück sind die Spammer im Moment noch nicht so weit, aber man muss damit rechnen, dass das Spiel mit "temporary failures" auch nur temporär wirksam sein wird.
Ein weiterer Nachteil von Greylisting ist, dass es die Queues von "normalen", absendenden Mailservern signifikant verlängert, da die temporär abgewiesenen Nachrichten ja erst Mal in der Queue landen. Wie schlimm das ist, wird sich erst zeigen, wenn plötzlich alle Greylisting einsetzen - dank Aufbau der Greylist (=bereits erfolgreiche Mailquellen werden erinnert) sollte der Effekt nicht allzu drastisch ausfallen.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Greylist ist sicher eine Komponente der Spam-Abwehr.
Wie isses eigentlich, als erstes die erste Ziffer der IP-Adresse zu untersuchen?
Diese sagt was drüber aus, ob es sich um eine arin- ripe-, apnic-, latnic- etc -Adresse handelt.
Da wir wissen, dass Amerika eines der Hauptspammer ist, und das zweitgrösste Kontingent aus Asien kommt, könnte man für RIPE-Origin die serverseitige Spam-Policy recht locker halten.
Damit sind 95% meiner Mail-Partner nicht betroffen.
Nur für nicht-RIPE nimmt man härtere Dinger.
Dann vergleicht man MX und Absender. Bei kleinen Providern sind die sicherlich gleich, lässt man auch durch, auf die Gefahr hin, der Absender hat zum Spamen eine Wegwerfdomain registriert.
Erst in der dritten Stufe wendet man dann so Methoden wie greylist an, das ganze eventuell noch mit ner hübsch langen Teergrube.
Das schöne an greylist ist ja, dass keine Mail weggeworfen wird, sondern einfach rfc-konform behandelt wird.
Hab mir noch nicht angeguckt, wie das bei postfix geht... aber wenn der Check aufn Perlscript umgebogen wird, dann müsste doch auch mehr möglich sein.
Aber vielleicht hats ja auch schon jemand implementiert, dann mal bitte Bescheid sagen.
Viele Grüße,
Florian
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Saturday 07. August 2004, 14:35 MEW (#3)
|
|
|
|
|
habe schnell ein ebuild gemacht: Bug# 59691
gruss
SteveB
|
|
|
|
|
|
|
|
|
|
|
|
|
Ich habe schon festgestellt, dass teilweise jetzt schon Spam doppelt geschickt wird, weil greylisting ist schon eine Weile bekannt.
Weiter habe ich schon Viren gesehen, welche sich via den Mail-Server des ISP raussenden, aktuelles Bespiel hier (ClamAV hat ein Worm.Gibe.F erkannt):
Return-Path: <xxxxx@bluewin.ch>
Received: from mail4.bluewin.ch (mail4.bluewin.ch [195.186.4.74])
by batman.home4u.ch (amavis-milter) id i769KUbV079098; Fri, 6 Aug 2004 11:20:30 +0200 (CEST)
Received: from xxxxx (62.202.x.x) by mail4.bluewin.ch (Bluewin AG 7.0.030.2)
id 410F7F610007EC72; Fri, 6 Aug 2004 09:18:41 +0000
Date: Fri, 6 Aug 2004 09:18:41 +0000 (added by postmaster@bluewin.ch)
Message-ID: <410F7F610007EC72@mail4.bluewin.ch> (added by postmaster@bluewin.ch)
FROM: "Microsoft Public Assistance" <pxdqbmrsq_bamdtw@support.net>
TO: "Customer" <customer@support.net>
SUBJECT: Current Pack
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="ordmmuvv"
Dies sind momentan wohl noch Einzelfälle, zeigt aber klar, dass sich die "Bösen" auch informieren und ihr Tools anpassen.
Weiter müsste man jetzt die Frage aufwerfen, ob ein ISP auch auf dem SMTP-Relay-Server (welcher die Kunden zum raussenden von Mails nutzen) einen Virenscanner betreiben sollten, um nicht Virenmails seiner Kunden zu verteilen. Aber ev. war dieser Virus einfach zu neu, und wurde noch nicht erkannt.
bye
Fabian
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Saturday 07. August 2004, 17:15 MEW (#5)
|
|
|
|
|
Es Versendet sich jeder halbschlaue virus eh schon über den SMTP des porviders , bzw. probiert es mehrmals.
Wenn das aufkommt, machen es auch die primitiveren viren.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Die meisten Würmer / Viren die ich mit dem Virenfilter auf dem Mailserver rausziehe sind Direkteinlieferungen von dynamischen IPs.
Theoretisch könnte man die auch stoppen, wenn man einfach dynamische IPs blockt oder eben über Greylisting. Eine endgültige Lösung ist das natürlich nicht.
|
|
|
|
|
|
|
|
|
|
|
|
|
> Theoretisch könnte man die auch stoppen, wenn man einfach dynamische IPs blockt oder eben über Greylisting. Eine endgültige Lösung ist das natürlich nicht.
Klar, wenn es dir egal ist, dass du von vielen technisch versierten Benutzern keine Mails mehr bekommst scheint das durchaus eine Loesung zu sein. Deine Taktik scheint mir etwa so gut wie die, eine Handgranate in ein Zimmer zu werfen und zu hoffen, dass du mehr Boese als Gute erwischst.
--
PPC: Penguin Powered Computing
|
|
|
|
|
|
|
|
|
|
|
|
|
Wenn sich Greylisting verbreitet, werd ich all den Spam doppelt bekommen, weil die Spammer das Zeug einfach zweimal schicken. Was macht ihr dann? Zweimal greylisten und erst beim dritten Mal akzeptieren?
Das Postgrey Zeug ist meiner Mainung nach nicht genug durchdacht. Ueberprueft wird "the triplet CLIENT_IP / SENDER / RECIPIENT". Wuerde CLIENT_IP alleine oder SENDER und RECIPIENT zusammen nicht genuegen? Wird die IP des Senders nach einem erfolgreichen Transfer wenigstens auf eine Whitelist gesetzt?
"Hopefully spammers or viruses will not try again later, as it is however required per RFC"
In dem RFC steht aber auch nirgends, dass ein Mailtransfer unbedingt von derselben IP wiederholt werden muss. Was, wenn irgendein wildes Load-Balancing den neuen Versuch von einer anderen IP startet?
Eine halbe Stunde Verzoegerung gilt fuer eine Richtung, wenn beide Mailserver Greylisting verwenden ist es ploetzlich maximal eine Stunde Verzoegerung fuer eine Antwort auf ein Mail. Ach ja, wenn noch ein MX dazwischenliegt erhalten die Greylister auch Bounces erst mit Verzoegerung. Mailinglisten (Nutzer und Betreiber) werden auch ihre helle Freude an Greylisting haben.
Wenn es schnell gehen muss: Das Mail nach 5 Minuten einfach nochmal schicken. Dann hat der Empfaenger halt zwei davon, aber wenigstens kommt das Mail in einer anstaendigen Zeit an. Die Greylister werden nun natuerlich ihren Mailserver so konfigurieren, dass er nach 5 Minuten nochmal versucht, gut gemacht!
Greylisting verzoegert Mails und belastet Mailserver (ja, die die legitime Mails verschicken). Spammer leben von Idioten die auf sie reinfallen. Wozu SMTP totschlagen? Ich bin immer noch Op und Mod in meiner Inbox, mit dem Mittelfinger ueber der Taste D wie 'Delete'.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Leider ist greylisting keine Lösung des Spam-Problems, sondern reduziert das aufkommen nur vorübergehend. Etwas, was in eine ähnliche Kategorie fällt, wir hier an der UNSW von der CSE gemacht: Sie setzen 10 Blackhole Mailserver auf, die jegliche Mail direkt nach /dev/null weiterleiten. Diese Blackhole Mailserver bekommen hohe Priotitäten im DNS, während der einzige richtige Mailserver eine niedrige Priorität bekommt.
Die Idee dahinter ist, dass ein durchschnittlicher Virenschreiber oder Spammer nicht weiss, dass gemäss Standard ein Mailserver seine Mail immer an den Mailserver mit der tiefsten Priorität im DNS-Eintrag schicken sollte. Demnach schicken Viren und Spammer ihre Mails an die Blackholes, während jeder richtig konfigurierte Mailserver die Mail an den richtigen Mailserver schickt.
Das ganze ist hier beschrieben und funktioniert natürlich nur, solange Virenschreiber und Spammer nicht wissen, wie das mit den Mailservern und dem DNS richtig funktioniert...
|
|
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Sunday 08. August 2004, 11:18 MEW (#9)
|
|
|
|
|
Das halte ich aber für extrem gefährlich:
Was ist, wenn der 'echte' MX down ist? Dann werden die mails alle nach /dev/null ausgeliefert.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Monday 09. August 2004, 19:04 MEW (#11)
|
|
|
|
|
Sorry für die Pedanterie, aber:
Die Idee dahinter ist, dass ein durchschnittlicher Virenschreiber oder Spammer nicht weiss, dass gemäss Standard ein Mailserver seine Mail immer an den Mailserver mit der tiefsten Priorität im DNS-Eintrag schicken sollte.
Das stimmt natürlich nicht. Mailserver sollen ihre Mail gemäss Standard an den MX mit der höchsten Priorität - also den mit dem niedrigsten Wert - schicken. Priorität eins ist höher als Priorität 100.
|
|
|
|
|
|
|
|
