Article View: de.comm.provider.webspace
Article #10Re: zwischen den Fronten - eigener Mailserviceprovider auf Blacklist bei eigenem Zugangsprovider
From: Alexander Talos
Date: Sat, 29 Jun 2002 23:59
Date: Sat, 29 Jun 2002 23:59
87 lines
5335 bytes
5335 bytes
Hej! >Nun verwendet inode im rahmen seiner anti-spam-policy externe >blacklists. Auf einer von diesen Listen scheint seit l�ngerem Ich setze genau aus diesem Grund keine Blacklisten zum Blocken ein. Ich bin mir auch mit Kollegen einig, dass, wenn wir so ein Service installieren, dieses nur auf individuellen ausdruecklichen Wunsch (kundgetan via Webmaske) nach Hinweis auf die Nebenwirkungen geschehen soll - in der Zwischenzeit wird nur eine Header-Zeile eingefuegt. >| Server m�glich. Dies ist eine Schutzma�nahme, die nicht nur Inode Mailserver >| sondern auch andere Provider haben. Aus diesem Grund bitte ich Sie, Ihren Und darueber, ob das gescheit ist, oder nicht, kann man sich ewig die Schaedel einhauen. YMMV sozusagen. >| Zu diesen Organisationen (abuse.net und wie sie alle heissen) kann ich nur Das ist ein Griff tief ins Klo. Abuse.net betreibt keine RBL, sondern eine Datenbank, um domain -> abuse-Adresse zu mappen. Ein ausgesprochen nuetzliches Service, das aber mit Blacklists rein gar nichts zu tun hat. Ein umfassendes Verzeichnis von RBLs gibt es unter: http://www.declude.com/JunkMail/Support/ip4r.htm >| wiederholt sagen: Wir k�nnen nicht verhindern, dass wir durch wen auch immer >| das eine oder andere Mal dort gelistet sind - in aller Regel sind wir dann Tatsache ist, dass man in groesseren Netzen schneller geblacklistet wird, als auf den ersten Blick anzunehmen ist. Es reicht ein User, der ein ungeschuetztes formmail.cgi auf seinen Webspace wirft, oder einer, der auf seinem prinzipiell relayberechtigten Rechner mal gschwind ein offenes Wingate installiert... >| nicht an jemanden schicken kann, weil der eine Blacklist einsetzt, auf der >| einer unserer Mailserver gelistet ist, dann soll er den doch einfach fragen, >| mit welchem Recht er denn das macht und damit verhindert, dass er seine Das Recht ist aus der Sicht des Absenders leicht zu klaeren: Es ist niemand gezwungen, Mail von irgendjemandem anzunehmen. Wenn ich auf meinem Mailserver konfiguriere, dass ich von Hosts, deren IP-Adresse durch 3 Teilbar ist oder die in ihrem Namen nicht mindestens drei "at" drin haben, keine Mail entgegennehme, dann ist das mein Bier. Die Frage ist, ob "meine" oder in dem Fall Inodes User damit einverstanden sind. Nachdem, soweit ich das verstehe, diese freiwillig die Blacklisterei nutzen, ist es deren - wenn auch mittelbare - Willenserklaerung, von Dir keine Mail zu empfangen. >| �ber diesen Mailserver verschickt hat bzw. diesen Povider auffordern, >| derartige Zensuren zuk�nftig zu unterlassen. Genauso gut kann ich auch Da hat jemand keine Ahnung, was Zensur heisst, mal abgesehen davon, dass diese Filterfunktion offenbar bei Inode frei waehlbar ist. >Ich komme mir hier richtig zwischen die Fronten geraten vor, da ich >beides nicht direkt beeinflussen kann, einerseits ich au�er von inode Das ist das ausdrueckliche Konzept vieler Blacklistbefuerworter: Die Kunden geblacklisteter Provider sollen sich a) beschweren und b) Provider wechseln, damit auf diese Weise Druck auf die verantwortlichen Admins ausgeuebt wird. Wenn legitime Mail deshalb nicht ankommt, ist das Kollateralschaden - vulgo Pech gehabt. Es funktioniert aber nichtmal diese Brachialmethode so wirklich generalpraeventiv. Ein merkbarer Erfolg fuer den individuellen Spam-Nichtempfaenger ist aber absolut gegeben. >Kann mir jemand einen Rat geben, wie ich sinnvoll und mit m�glichst >wenig Aufwand vorgehen soll/kann? Eigentlich war ich mit beiden http://relays.osirusoft.com/faq.html#_Toc533558155 Ich weiss nicht, ob wirklich osirusoft die verwendet Blackliste ist und warum die Austragung nicht funktioniert hat. Nach dem Schnitzer von abuse.net nehme ich fast an, netdiscounter hat doch nicht so sehr den vollen Durchblick. Mir sind jedenfalls osirusoft bisher nicht als Produzenten von massenhaft fehlerhaft positiv markiertem Spam aufgefallen, was bei notorisch nichtfunktionierendem Austragen geschlossener Relays aber der Fall sein muesste. Ciao Alexander, der RBLs sehr skeptisch gegenuebersteht.
Technical Details
Message-ID:
<3d1e49e6$0$13184$3b214f66@news.univie.ac.at>Path:
arc1-ca.pugleaf.net!archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.online.be!newscore.univie.ac.at!aconews-feed.univie.ac.at!news.univie.ac.at!not-for-mailReferences:
<3d1dee6f$0$20648$91cee783@newsreader02.highway.telekom.at>Show Full Headers
Complete Article Headers
X-Google-Language: GERMAN,ASCII X-Google-Thread: 10249a,4a3c9005ce8737aa X-Google-Attributes: gid10249a,public X-Google-Thread: f5443,4a3c9005ce8737aa X-Google-Attributes: gidf5443,public X-Google-ArrivalTime: 2002-06-29 16:59:36 PST Path: arc1-ca.pugleaf.net!archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.online.be!newscore.univie.ac.at!aconews-feed.univie.ac.at!news.univie.ac.at!not-for-mail From: at@atat.at (Alexander Talos) Newsgroups: de.comm.provider.webspace,at.internet.provider Subject: Re: zwischen den Fronten - eigener Mailserviceprovider auf Blacklist bei eigenem Zugangsprovider References: <3d1dee6f$0$20648$91cee783@newsreader02.highway.telekom.at> Organization: Arbeitsgemeinschaft fuer total abgehobene Technologie Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit User-Agent: slrn/0.9.6.2 (Linux) Date: 29 Jun 2002 23:59:35 GMT Lines: 88 Message-ID: <3d1e49e6$0$13184$3b214f66@news.univie.ac.at> NNTP-Posting-Host: 194.152.96.209 X-Trace: 1025395175 news.univie.ac.at 13184 194.152.96.209 X-Complaints-To: news-adm@news.univie.ac.at