DNS anti-spam blocklists
Cor Bosman
en graag meedoen met een trial.
ik ben bezig met een test (puur technisch nog) voor DNS based anti-spam
blocklists. We kunnen daarmee, per email adres, email blocken of een
header toevoegen.
In de testperiode gebruiken we 3 blocklists.
bl.spamcop.net (SpamCop)
inputs.orbz.org (ORBZ)
relays.osirusoft.com (Osirusoft)
Als er mensen zijn die mee willen doen, laat het dan weten. Als je bang
bent email te verliezen die je toch wilt hebben (de kans is zeer klein
maar het kan wel), kies dan voor de Header optie, zodat je het even aan
kunt kijken. Ikzelf kies echter meteen voor de block optie want ik heb
wel vertrouwen in die lists :)
Ik moet dan een list hebben met alle email adressen waar je dit op wilt.
Aangezien we er NOG geen interface voor hebben, en veel mensen sneller tikken
dan 1, lever het aub aan een vorm die ik direkt in de config file kan
stoppen..zie onder. Je kan normale email adresssen opgeven
(c...@xs4all.nl), maar ook op domain (c...@bofh.nl), of aliasen van een
account (re...@xs4all.nl), of popboxen (pop...@xs4all.nl) enz enz
Je kan 1 of meer blocklists opgeven, en ik wil het graag hebben in het
volgende formaat:
c...@xs4all.net DNSBL:bl.spamcop.net,DNSBL:inputs.orbz.org,DNSBL:relays.osirusoft.com
sco...@xs4all.nl HDRBL:bl.spamcop.net,HDRBL:inputs.orbz.org,HDRBL:relays.osirusoft.com
Hoeft natuurlijk niet alle 3, je kan ook voor 1 of 2 kiezen.
links zet je het mailadres, rechts een comma seperated list van of
HDRBL of DNSBL met daarna een : en de list in kwestie.
HDRBL voegt alleen een header toe, DNSBL blocked de mail volledig.
Het kan ook voor een heel domain:
bofh.nl DNSBL:bl.spamcop.net,DNSBL:inputs.orbz.org,DNSBL:relays.osirusoft.com
Voor mensen die echt willen spelen ermee, je kan ze ook mixen.. dus dit kan
ook:
wh...@bofh.nl DNSBL:relays.osirusoft.com
bofh.nl DNSBL:bl.spamcop.net,HDRBL:inputs.orbz.org
Ik ga het uiteraard checken, maar lever graag wel domains aan die van
jou zijn, of doe anders gewoon niet mee.
De header is op dit moment:
X-XS4ALL-SPAM-Warning: Sending machine is listed in bl.spamcop.net,inputs.orbz.org,relays.osirusoft.com
Als je je afvraagt wat je kan doen met header tagging, dan is dat een
goede vraag. Veel mail programmas kunnen op basis van bv een header
mail saven in een aparte mailbox. Ook kan je handmatig checken of XS4ALL
de mail ziet als spam, en zo het een tijdje aankijken voor je echt voor blocking
kiest.
Mensen die dit allemaal niet snappen, klik snel door naar het volgende
bericht. Emails ala "Hey dat wil ik ook, hoe werkt dat" worden in mijn
speciale /dev/null mailbox gesaved.
Groetjes,
Cor
Wesley Schwengle
-snip, DNS Spam blocking-
> Mensen die dit allemaal niet snappen, klik snel door naar het volgende
> bericht. Emails ala "Hey dat wil ik ook, hoe werkt dat" worden in mijn
> speciale /dev/null mailbox gesaved.
LOL, hoe vaak lees je die box?
-- Wesley
Marco Nelissen
> Hoi allemaal, dit is voor mensen die snappen hoe DNS blocklists werken,
> en graag meedoen met een trial.
(knip)
Prima initiatief, maar waarom niet gewoon meteen voor iedereen de
header-optie aanzetten? Er gaat dan zeker geen mail verloren, en
iedereen kan meedoen zonder dat je met de hand config-files moet
gaan knippen en plakken.
Marco
Vincent Schonau
> Mensen die dit allemaal niet snappen, klik
NO CARRIER
Vince.
Cor Bosman
Bv omdat ik niet de verschillende blocklists in 1 keer wil opzadelen
met een paar miljoen hits per dag? En ik weet zelf ook nog niet of dat
wel schaalt. Daar is zo'n test juist voor.
Cor
Reinier Jonker
Lees die alinea nog eens heel goed door... :-)
--
/) | Reinier Jonker - ICQ: 74612239
/ / | Power Mac G4 350 AGP - 640MB - Mac OS X 10.1.1 [5M28]
\___\ | "sudo rm -r /bin/laden"
Wesley Schwengle
> >
> > > Mensen die dit allemaal niet snappen, klik snel door naar het volgende
> > > bericht. Emails ala "Hey dat wil ik ook, hoe werkt dat" worden in mijn
> > > speciale /dev/null mailbox gesaved.
> >
> > LOL, hoe vaak lees je die box?
>
> Lees die alinea nog eens heel goed door... :-)
Lees jij ff tussen de regels door en feel the sarcasm..
Ff ontopic, het is een nifty ID. Misschien kunnen jullie deze klant ff
waarschuwen, wellicht dat ie wilt testen:
http://www.xs4all.nl/~sister/procmailrc
-- Wesley, praat /dev/null
Nico Bartels
>De header is op dit moment:
>X-XS4ALL-SPAM-Warning: Sending machine is listed in bl.spamcop.net,inputs.orbz.org,relays.osirusoft.com
Het lijkt prima te werken. Ik heb nog geen valse positieven gezien.
Keurig alleen rotzooi in mijn spam-foldertje. Als mijn vertrouwen groot
genoeg is/blijft, kan ik dan mijn opties ook (laten) veranderen van
HDRBL naar DNSBL?
Ciao!
Nico.
--
Heaven, the treasury of everlasting joy.
Shakespeare (1564-1616)
Martin Cleaver
>>De header is op dit moment:
>>X-XS4ALL-SPAM-Warning: Sending machine is listed in
>>bl.spamcop.net,inputs.orbz.org,relays.osirusoft.com
>
> Het lijkt prima te werken. Ik heb nog geen valse positieven gezien.
> Keurig alleen rotzooi in mijn spam-foldertje. Als mijn vertrouwen
groot
> genoeg is/blijft, kan ik dan mijn opties ook (laten) veranderen van
> HDRBL naar DNSBL?
Wassat? Interessante bericht, maar ik ben bang dat ik wat achtergrond
informatie mis... Ik wil ook van mijn spam bevrijd worden... hoe?
Groet
Martin
Cor Bosman
>On 14 Dec 2001 11:37:25 GMT, c...@xs3.xs4all.nl (Cor Bosman) wrote:
>>De header is op dit moment:
>>X-XS4ALL-SPAM-Warning: Sending machine is listed in bl.spamcop.net,inputs.orbz.org,relays.osirusoft.com
>Het lijkt prima te werken. Ik heb nog geen valse positieven gezien.
>Keurig alleen rotzooi in mijn spam-foldertje. Als mijn vertrouwen groot
>genoeg is/blijft, kan ik dan mijn opties ook (laten) veranderen van
>HDRBL naar DNSBL?
Ja hoor. Ik heb gister wel 2 false positives gehad (maar dat hou je toch).
Als reaktie op deze posting mailde 2 mensen vanuit UPC dat ze dit ook
wilden. Alleen..eh..de mailservers van UPC staan op die blocklists.
En aangezien wij alleen input blocklists hebben, is dat HEEEL kwalijk.
Dat betekent dat die dozen zelf of open relay zijn, of source van VEEL
spam zonder dat iemand bij UPC er wat aan doet.
Ik had het gelukkig net even op HDRBL gezet, anders had ik die mails
dus nooit gezien :)
Maar tja..wat is een false positive. Als UPC weigert mee te werken
aan oplossen van spam, dan hoef ik ook geen mail van hun mailservers.
Cor
Ewoud Dronkert
> kan ik dan mijn opties ook (laten) veranderen van
> HDRBL naar DNSBL?
Als het na een testperiode ook serverside goed blijkt te gaan, zal het
misschien een optie worden in het servicecentrum?
Rob Janssen
Zoals je al kon lezen: als je dit moet vragen is het nog niet voor jou.
Het is een test voor mensen die snappen hoe het werkt.
Rob
--
+--------------------------------+--------------------------------------+
| Rob Janssen pe1...@amsat.org | WWW: http://www.xs4all.nl/~pe1chl/ |
| AMPRnet: r...@pe1chl.ampr.org | AX.25 BBS: PE1CHL@PI8ZAA.#NBO.NLD.EU |
+--------------------------------+--------------------------------------+
Rob Janssen
>Ja hoor. Ik heb gister wel 2 false positives gehad (maar dat hou je toch).
>Als reaktie op deze posting mailde 2 mensen vanuit UPC dat ze dit ook
>wilden. Alleen..eh..de mailservers van UPC staan op die blocklists.
>En aangezien wij alleen input blocklists hebben, is dat HEEEL kwalijk.
>Dat betekent dat die dozen zelf of open relay zijn, of source van VEEL
>spam zonder dat iemand bij UPC er wat aan doet.
Ach ja dat is natuurlijk vanwege dat belachelijke idee dat als er bij een
provider één klant is die zijn systeem niet goed voor elkaar heeft, die
hele provider in de ban moet.
Door het blacklisten van die "2nd stage open relays" wordt dit gewoon een
ongeloofwaardig en onwerkbaar systeem, dat zie je nu al.
Cor Bosman
>Cor Bosman <c...@xs3.xs4all.nl> wrote:
>>Ja hoor. Ik heb gister wel 2 false positives gehad (maar dat hou je toch).
>>Als reaktie op deze posting mailde 2 mensen vanuit UPC dat ze dit ook
>>wilden. Alleen..eh..de mailservers van UPC staan op die blocklists.
>>En aangezien wij alleen input blocklists hebben, is dat HEEEL kwalijk.
>>Dat betekent dat die dozen zelf of open relay zijn, of source van VEEL
>>spam zonder dat iemand bij UPC er wat aan doet.
>Ach ja dat is natuurlijk vanwege dat belachelijke idee dat als er bij een
>provider een klant is die zijn systeem niet goed voor elkaar heeft, die
>hele provider in de ban moet.
>Door het blacklisten van die "2nd stage open relays" wordt dit gewoon een
>ongeloofwaardig en onwerkbaar systeem, dat zie je nu al.
Rob, het kan geen kwaad je eens in de materie in te lezen voor je je
mening geeft.
Ik zei specifiek dat het om een _INPUTS_ lijst gaat. DNS blocklists
kennen vaak 2 varianten. Inputs en outputs. Ik zal het even voor je
uittekenen:
Versie 1.. server is zelf open relay:
in out
[SPAM] -> [UPC MAILSERVER] -> [INTERNET]
In dit geval komt UPC op zowel inputs als outputs.
Versie 2..
in out
[SPAM] -> [KLANT van UPC] -> [UPC MAILSERVER] -> [INTERNET]
In dit geval is de klant een input, and de UPC mailserver een output.
En dan kan dit nog:
[KLANT van UPC] -> [UPC MAILSERVER] -> [INTERNET]
Dan moet UPC gewoon optreden tegen de klant.
Hoe dan ook, wetende dat UPC op een inputs lijst staat, is versie 2 niet
aan de orde. Dat betekent dat alleen 1 en 3 overblijven. Dus OF
smtp1.a2000.nl relayed zelf, of een klant stuurt spam en UPC doet daar
herhaaldelijk niks aan.
Groeten,
Cor
Nico Bartels
>Ach ja dat is natuurlijk vanwege dat belachelijke idee dat als er bij een
>provider één klant is die zijn systeem niet goed voor elkaar heeft, die
>hele provider in de ban moet.
Dat zou inderdaad niet goed zijn.
>Door het blacklisten van die "2nd stage open relays" wordt dit gewoon een
>ongeloofwaardig en onwerkbaar systeem, dat zie je nu al.
Ik denk dat het toch anders zit. UPC heeft OF zelf een open relay, OF
een klant die zelf spammed. In beide gevallen is het UPC die er
blijkbaar niets aan doet (open relay dicht zetten of klant afsluiten).
Als het alleen een klant is die z'n zaakjes software-technisch niet voor
elkaar heeft, dan kom je als provider niet op een input-block-list.
Ciao!
Nico.
--
Cynics are made, not born.
Karl Marx (1818-1883)
Rob Janssen
>>Ach ja dat is natuurlijk vanwege dat belachelijke idee dat als er bij een
>>provider een klant is die zijn systeem niet goed voor elkaar heeft, die
>>hele provider in de ban moet.
>>Door het blacklisten van die "2nd stage open relays" wordt dit gewoon een
>>ongeloofwaardig en onwerkbaar systeem, dat zie je nu al.
>Rob, het kan geen kwaad je eens in de materie in te lezen voor je je
>mening geeft.
>Ik zei specifiek dat het om een _INPUTS_ lijst gaat. DNS blocklists
>kennen vaak 2 varianten. Inputs en outputs. Ik zal het even voor je
>uittekenen:
Aha dat is kennelijk nieuw sinds ik er voor het laatst naar keek (en het
belachelijk vond dat men een provider zou blokken om wat zijn klanten doen,
gecombineerd met het eventueel ervaren van gebrek aan actie daartegen).
>Versie 1.. server is zelf open relay:
> in out
> [SPAM] -> [UPC MAILSERVER] -> [INTERNET]
>In dit geval komt UPC op zowel inputs als outputs.
>Versie 2..
> in out
> [SPAM] -> [KLANT van UPC] -> [UPC MAILSERVER] -> [INTERNET]
>In dit geval is de klant een input, and de UPC mailserver een output.
>En dan kan dit nog:
>
> [KLANT van UPC] -> [UPC MAILSERVER] -> [INTERNET]
>Dan moet UPC gewoon optreden tegen de klant.
>Hoe dan ook, wetende dat UPC op een inputs lijst staat, is versie 2 niet
>aan de orde. Dat betekent dat alleen 1 en 3 overblijven. Dus OF
>smtp1.a2000.nl relayed zelf, of een klant stuurt spam en UPC doet daar
>herhaaldelijk niks aan.
Zoals je weet kan een klant van UPC eventueel Windows 2000 draaien, en als
dat zo is dan is er een fikse kans dat iedere willekeurige buitenstaander
een CMD.EXE op zijn systeem kan runnen. Dat is ook voor een fiks aantal
klanten bij XS4ALL het geval. Wellicht zijn er al spammers die deze
gehackte systemen gebruiken om hun spam te versturen? Die zijn dan niet
te onderscheiden van open relays of spammende klanten (afhankelijk van
hoe de spammer het precies aanpakt).
Als dat zo is dan zie ik niet waarom UPC op een blacklist zou moeten
komen. "UPC moet optreden tegen die klant" is een leuk verhaal, maar
er zijn natuurlijk honderden zo niet duizenden van die klanten en als
die om en om eens gebruikt worden dan is het dweilen met de kraan open.
Bovendien is dat hele idee dat een provider moet optreden tegen open relays
van klanten een zelfbedachte regelgeving en het blacklisten van die
provider is het eigen rechter spelen tegen overtreding van die zelfbedachte
regels. Waarom zou een provider zich daaraan moeten storen en er kosten
voor moeten maken om binnen die regels te opereren? Dan kan er ook wel
iemand gaan roepen dat je geen copyrighted materiaal mag verspreiden via
Usenet en actie gaan ondernemen tegen de provider die dat toch doet en
geen screening toepast cq zijn klanten die dat posten berispt en afsluit.
Het gaat in dit geval nog over zelf door de klant ingestelde filters voor
alleen zijn eigen mail, dus dat mag. Maar ik kan me best voorstellen
dat men bij UPC denkt "nou als je onze mail niet wilt onder je zelf
bedachte regels dan neem je die mail toch gewoon NIET?" waarom zouden
zij maatregelen moeten nemen om een blokking systeem te laten functioneren?
Cor Bosman
>>Hoe dan ook, wetende dat UPC op een inputs lijst staat, is versie 2 niet
>>aan de orde. Dat betekent dat alleen 1 en 3 overblijven. Dus OF
>>smtp1.a2000.nl relayed zelf, of een klant stuurt spam en UPC doet daar
>>herhaaldelijk niks aan.
>Als dat zo is dan zie ik niet waarom UPC op een blacklist zou moeten
>komen. "UPC moet optreden tegen die klant" is een leuk verhaal, maar
>er zijn natuurlijk honderden zo niet duizenden van die klanten en als
>die om en om eens gebruikt worden dan is het dweilen met de kraan open.
Tja, en toch zal je moeten dweilen. Want anders gaat de hoofdkraan gewoon
ergens dicht. Een ISP die het gewoon echt niks kan schelen dat z'n klanten
spammen die is heel snel een paria. Of dat hier ook het geval is weet ik
niet. Ik ken de redenen niet dat de mailservers van UPC op blocklists staan.
>Bovendien is dat hele idee dat een provider moet optreden tegen open relays
>van klanten een zelfbedachte regelgeving en het blacklisten van die
>provider is het eigen rechter spelen tegen overtreding van die zelfbedachte
>regels. Waarom zou een provider zich daaraan moeten storen en er kosten
>voor moeten maken om binnen die regels te opereren? Dan kan er ook wel
>iemand gaan roepen dat je geen copyrighted materiaal mag verspreiden via
>Usenet en actie gaan ondernemen tegen de provider die dat toch doet en
>geen screening toepast cq zijn klanten die dat posten berispt en afsluit.
Er zijn heeeel weinig ISPs die outputs lists gebruiken voor blocking.
De kans dat je als klant van een ISP dus mail misloopt omdat de afzender's
ISP een second stage relay is, is miniem. En die blocklists zijn ook
vandaag de dag nog zeer omstreden. Maar inputs lists zijn echt niet meer
omstreden. Wat dat betreft kan de genie niet terug in de bottle.
>Het gaat in dit geval nog over zelf door de klant ingestelde filters voor
>alleen zijn eigen mail, dus dat mag. Maar ik kan me best voorstellen
>dat men bij UPC denkt "nou als je onze mail niet wilt onder je zelf
>bedachte regels dan neem je die mail toch gewoon NIET?" waarom zouden
>zij maatregelen moeten nemen om een blokking systeem te laten functioneren?
De UPC mailservers staan op een inputs blocklist. Dat is niet goed.
Dat betekent dat er spam via die servers verstuurd wordt, en er niks
aan gedaan wordt. Het is gelukkig nog steeds zo dat de meeste mensen,
inclusief ISPs, dat een probleem vinden. UPC moet OF z'n mailservers
afleren te relayen voor derden, OF z'n klanten vertellen te stoppen met
spam sturen. Dat is normaal ISP gedrag. Er niks tegen doen is abnormaal
ISP gedrag.
Onze klanten hebben binnenkort wellicht inderdaad de keuze om abnormaal
ISP gedrag niet meer te accepteren. Als die ISP dat geen probleem vindt,
dan niet. Maar wij zijn echt niet de enigen in de wereld die die lists
gebruiken, en als jij straks als UPC klant de helft van je mail niet meer
kwijt kunt omdat UPC weigert op te treden tegen abuse, dan is de maat
als UPC klant toch op een gegeven moment wel vol.
Let wel, je moet echt even bedenken dat je dit niet moet verwarren met
OUTPUTS blocking. Want wat dat betreft ben ik het volledig met je eens
dat die lijsten op de bodem van de hel thuishoren.
Cor
Herbert Groot Jebbink
> ISP gedrag niet meer te accepteren. Als die ISP dat geen probleem vindt,
> dan niet. Maar wij zijn echt niet de enigen in de wereld die die lists
> gebruiken, en als jij straks als UPC klant de helft van je mail niet meer
> kwijt kunt omdat UPC weigert op te treden tegen abuse, dan is de maat
> als UPC klant toch op een gegeven moment wel vol.
vind ik ook, dan ga je als UPC klant toch lekker naar een andere ISP
op de kabel, dat zal ze leren bij UPC.
hgj
Herbert Groot Jebbink
> Dan kan er ook wel iemand gaan roepen dat je geen copyrighted
> materiaal mag verspreiden via Usenet en actie gaan ondernemen
> tegen de provider die dat toch doet en geen screening toepast
> cq zijn klanten die dat posten berispt en afsluit.
precies, laten we maar eens aktie gaan ondernemen, ik heb net
newszilla.xs4all.nl in het algemeen en cor in het bijzonder
aangemeld bij de BSA, als ik het goed begrijp krijg ik nu 10% van
de waarde van de software in de warez groepen op newszilla, toch?
hgj
Marcel de Groot
"Cor Bosman" <c...@xs3.xs4all.nl> wrote in message
news:3c19e475$0$5441$e4fe...@dreader3.news.xs4all.nl...
> Hoi allemaal, dit is voor mensen die snappen hoe DNS blocklists werken,
> en graag meedoen met een trial.
>
> ik ben bezig met een test (puur technisch nog) voor DNS based anti-spam
> blocklists. We kunnen daarmee, per email adres, email blocken of een
> header toevoegen.
>
> In de testperiode gebruiken we 3 blocklists.
>
> bl.spamcop.net (SpamCop)
> inputs.orbz.org (ORBZ)
> relays.osirusoft.com (Osirusoft)
>
>
> Als er mensen zijn die mee willen doen, laat het dan weten. Als je bang
> bent email te verliezen die je toch wilt hebben (de kans is zeer klein
> maar het kan wel), kies dan voor de Header optie, zodat je het even aan
> kunt kijken. Ikzelf kies echter meteen voor de block optie want ik heb
> wel vertrouwen in die lists :)
>
De test verliep zo goed dat jullie het maar meteen aangezet hebben op alle
accounts? (Ik ben ervoor hoor, absoluut!!)
Ik heb er niet omgevraagd, maar ben er wel blij mee dat ie toegevoegd is.
Ik kreeg net een SPAM mailtje binnen en ging de headers kopieren voor
Spamcop en zag
> X-XS4ALL-SPAM-Warning: Sending machine is listed in
bl.spamcop.net,inputs.orbz.org,relays.osirusoft.com
deze header staan!!
Cool!
Marcel
z0ne
>Ik ken de redenen niet dat de mailservers van UPC op blocklists staan.
Ai.. niet gebruiken, lijkt me dan..
--
z0ne / z0...@cryogen.com http://www.deds.nl/
'All my life I wanted to be some-one.
I guess I should have been more specific.. ' - Jane Wagner
Jan Ehrhardt
>Ian Zachar wrote:
>
>> Cor Bosman wrote:
>>
>> > Tja, en toch zal je moeten dweilen. Want anders gaat de hoofdkraan
>> > gewoon ergens dicht. Een ISP die het gewoon echt niks kan schelen dat
>> > z'n klanten spammen die is heel snel een paria. Of dat hier ook het
>> > geval is weet ik niet. Ik ken de redenen niet dat de mailservers van UPC
>> > op blocklists staan.
>>
>> Over welke mailserver van UPC heb je het? Alleen smtp1.a2000.nl of staat
>> mail-out.chello.nl ook op die blocklist?
>
>Je doelt waarschijnlijk op smtp2.a2000.nl die op bl.spamcop.net staat.
Het ging over smtp1.a2000.nl (62.108.1.88) die in inputs.orbz.org staat.
Jan
Jan Ehrhardt
>Rob Janssen wrote:
>
>> Maar ik kan me best voorstellen
>> dat men bij UPC denkt "nou als je onze mail niet wilt onder je zelf
>> bedachte regels dan neem je die mail toch gewoon NIET?"
>
>Ik hoop niet dat men dat denkt. In het verleden is het wel eens gebeurd dat
>mail van UPC klanten werd geweigerd door oa hotmail. De (interne)
>nieuwsgroepen stonden gedurende die blokkade vol met boze klachten.
>
>De laatste maanden zie ik weinig van zulke klachten in de nieuwsgroepen.
>
>Overigens staat noch smtp1.a2000.nl, noch smtp2.a2000.nl noch
>mail-out.chello.nl op dit moment in ordb.org.
Er wordt ook gekeken in inputs.orbz.org. En daar staat smtp1.a2000.nl wel
in.
X-XS4ALL-SPAM-Warning: Sending machine is listed in inputs.orbz.org
Jan
Philip Homburg
Rob Janssen <nom...@pe1chl.ampr.org> wrote:
>Bovendien is dat hele idee dat een provider moet optreden tegen open relays
>van klanten een zelfbedachte regelgeving en het blacklisten van die
>provider is het eigen rechter spelen tegen overtreding van die zelfbedachte
>regels. Waarom zou een provider zich daaraan moeten storen en er kosten
>voor moeten maken om binnen die regels te opereren? Dan kan er ook wel
>iemand gaan roepen dat je geen copyrighted materiaal mag verspreiden via
>Usenet en actie gaan ondernemen tegen de provider die dat toch doet en
>geen screening toepast cq zijn klanten die dat posten berispt en afsluit.
Waarom zou een provider niet wat moeite doen om zijn deel van het Internet
schoon te houden? Dus testen op open-relays bij klanten, sock-proxies, etc.
Verder kan rate limiting op mail servers, news servers, etc. ook geen kwaad.
Ik bleek door een klein foutje een smurf-amplifier te hebben (factor twee
of drie, en met een uplink van 64kbit/s schiet het ook niet op), maar het
is toch handiger daarop gewezen te worden door iemand die scant, dan dat je
er pas achter komt als er misbruik van gemaakt is.
In principe is vrijwel iedere computer waar een klant van een ISP niet goed
op let, een gevaar. En het is veel efficienter als er centraal gescand wordt
dan dat je wacht tot er misbruik van gemaakt wordt.
Alleen ISPs hebben blijkbaar geen zin (tijd/geld) om structureel te scannen.
Philip Homburg
Cor Bosman
>Rob Janssen wrote:
>> Maar ik kan me best voorstellen
>> dat men bij UPC denkt "nou als je onze mail niet wilt onder je zelf
>> bedachte regels dan neem je die mail toch gewoon NIET?"
>Ik hoop niet dat men dat denkt. In het verleden is het wel eens gebeurd dat
>mail van UPC klanten werd geweigerd door oa hotmail. De (interne)
>nieuwsgroepen stonden gedurende die blokkade vol met boze klachten.
>De laatste maanden zie ik weinig van zulke klachten in de nieuwsgroepen.
>Overigens staat noch smtp1.a2000.nl, noch smtp2.a2000.nl noch
>mail-out.chello.nl op dit moment in ordb.org.
smtp1.a2000.nl staat in inputs.orbz.org
Cor
Cor Bosman
>> Als er mensen zijn die mee willen doen, laat het dan weten. Als je bang
>> bent email te verliezen die je toch wilt hebben (de kans is zeer klein
>> maar het kan wel), kies dan voor de Header optie, zodat je het even aan
>> kunt kijken. Ikzelf kies echter meteen voor de block optie want ik heb
>> wel vertrouwen in die lists :)
>>
>De test verliep zo goed dat jullie het maar meteen aangezet hebben op alle
>accounts? (Ik ben ervoor hoor, absoluut!!)
>Ik heb er niet omgevraagd, maar ben er wel blij mee dat ie toegevoegd is.
>Ik kreeg net een SPAM mailtje binnen en ging de headers kopieren voor
>Spamcop en zag
>> X-XS4ALL-SPAM-Warning: Sending machine is listed in
>bl.spamcop.net,inputs.orbz.org,relays.osirusoft.com
>deze header staan!!
>Cool!
Als het goed is, is dit niet het geval. Zou een bug kunnen zijn.
Is deze email soms ook aan anderen gericht? We kunnen niet voorkomen
dat als iemand van een lijst van recipients header tagging wil, dat
de header dan in de mail staat bij iedereen.
Cor
Rob Janssen
>Waarom zou een provider niet wat moeite doen om zijn deel van het Internet
>schoon te houden? Dus testen op open-relays bij klanten, sock-proxies, etc.
>Verder kan rate limiting op mail servers, news servers, etc. ook geen kwaad.
Voornamelijk omdat de providers daar altijd zo dubbel in zijn.
Aan de ene kant roepen ze graag dat het Internet open is voor iedereen en
dat ze zich niet bezig houden met de content maar alleen met de doorgifte,
aan de andere kant proberen ze zich dan te bemoeien met spam, en proberen
ze mensen die de ongelukkige keuze gemaakt hebben om een abonnement te
nemen bij een ISP die niet anti-spam is uit te sluiten van mail.
Als er dan een land is waar men probeert om bepaalde zaken buiten de deur
te houden waar men ZELF toevallig niet tegen is, dan wordt daar
verontwaardigd op gereageerd. Dat vind ik een vreemde houding.
Eerst was altijd het (NLIP?) standpunt dat er niet gefilterd moest worden,
en nu zijn er kennelijk al eigen ideeen die WEL als filtercriterium mogen
gelden. Bij XS4ALL is het nog vrije keuze maar bij andere providers heb je
kennelijk al gewoon pech en wordt mail van collega's waar men het niet mee
eens is al botweg geweigerd als spam.
Slechte ontwikkeling, denk ik. Loopt uit op oorlog, kijk maar in de echte
wereld.
Marcel de Groot
Aha..
Voor zover ik kan zien is de mail niet aan anderen gericht.. Er staat maar 1
geadresseerde in het to: veld
Zal er een BCC gebruikt zijn van o.a. een andere XS4ALL gebruiker en dan
komt ie dus bij iedereen erin die ook in het BCC veld staat?
Marcel
Erik Hensema
>Hoi allemaal, dit is voor mensen die snappen hoe DNS blocklists werken,
>en graag meedoen met een trial.
Het blijkt dat mail-out.namezero.com in bl.spamcop.net staat. Voor zover ik
weet is dat een output, geen input.
De mensen van namezero zijn echter wel redelijk clueless bezig geweest,
want ze hebben twee mailservers, verbonden via een 10.x netwerk...
Ik heb die lui gemailt met twee vragen:
a) hoe zijn jullie op die lijst gekomen (note: ik weet het ;-))
b) wat gaan jullie er aan doen
Een vraagje aan procmail experts in de zaal: hoe kan ik op een gemakkelijke
en schaalbare (dus desnoods tientallen servers whitelisten) manier
mailservers whitelisten in mijn setup? Ik heb nu zoiets:
:0:
* X-XS4ALL-SPAM-Warning:.*
spam
ergens hoog in mijn .procmailrc staan.
--
Erik Hensema (er...@hensema.net) ICQ# 8280101
xs4all newsservers FAQ: http://www.xs4all.nl/~hensema/newsservers/index.html
Marcel de Groot
> Nico Bartels <nbar...@spamcop.net> writes:
>
> >On 14 Dec 2001 11:37:25 GMT, c...@xs3.xs4all.nl (Cor Bosman) wrote:
>
> >>De header is op dit moment:
> >>X-XS4ALL-SPAM-Warning: Sending machine is listed in
bl.spamcop.net,inputs.orbz.org,relays.osirusoft.com
>
> >Het lijkt prima te werken. Ik heb nog geen valse positieven gezien.
> >Keurig alleen rotzooi in mijn spam-foldertje. Als mijn vertrouwen groot
> >genoeg is/blijft, kan ik dan mijn opties ook (laten) veranderen van
> >HDRBL naar DNSBL?
>
> Ja hoor. Ik heb gister wel 2 false positives gehad (maar dat hou je toch).
Hmm, blij dat ik 'm op HDRBL heb laten zetten... Vanavond 6 mailtjes van
mailing-lists die in mijn SPAM-foldertje terecht zijn gekomen terwijl dit
echt lijsten zijn waarop ik mij ingeschreven heb.. (Ik weet het, ik weet
het.. Het gaat om de machines waar ze van verzonden zijn)
>
> Ik had het gelukkig net even op HDRBL gezet, anders had ik die mails
> dus nooit gezien :)
Ik vind het wel vreemd dat deze mailing-lists blijkbaar van machines
verstuurd worden die ook in de blocklist staan..
>
> Cor
Marcel
ps. Cor, mocht je willern weten om welke mailing-lists het gaat, dan moet je
het maar even melden! :)
Cor Bosman
>Ik vind het wel vreemd dat deze mailing-lists blijkbaar van machines
>verstuurd worden die ook in de blocklist staan..
>>
>> Cor
>Marcel
>ps. Cor, mocht je willern weten om welke mailing-lists het gaat, dan moet je
>het maar even melden! :)
Python?
Cor
J. Wijnands
Ik vind de vergelijking met xs4all hier niet terrecht.
Xs4all probeert wat te doen aan open relay's bij klanten.
> Als dat zo is dan zie ik niet waarom UPC op een blacklist zou moeten
> komen. "UPC moet optreden tegen die klant" is een leuk verhaal, maar
> er zijn natuurlijk honderden zo niet duizenden van die klanten en als
> die om en om eens gebruikt worden dan is het dweilen met de kraan open.
>
UPC heeft, de laatste keer dat ik keek, in hun AUP staan dat
het draaien van een server sowieso niet eens toegestaan is.
Dweilen met de kraan open? Wellicht. Maar UPC lijkt het
gewoon te verdommen om zelfs maar een dweil aan te schaffen.
Bovendien, en misschien zie ik dit te simpel hoor, ben ook
maar het slachtoffer van spam, geen unixbeheerder, zou het
toch mogelijk moeten zijn om uitgaand smtp verkeer wat niet
via hun mailservers gaat te blokkeren aan de rand van hun
netwerk.
> Bovendien is dat hele idee dat een provider moet optreden tegen open relays
> van klanten een zelfbedachte regelgeving en het blacklisten van die
> provider is het eigen rechter spelen tegen overtreding van die zelfbedachte
> regels. Waarom zou een provider zich daaraan moeten storen en er kosten
> voor moeten maken om binnen die regels te opereren? Dan kan er ook wel
> iemand gaan roepen dat je geen copyrighted materiaal mag verspreiden via
> Usenet en actie gaan ondernemen tegen de provider die dat toch doet en
> geen screening toepast cq zijn klanten die dat posten berispt en afsluit.
>
Hoezo eigen rechter spelen? Niemand dwingt je toch om van
blacklists gebruik te maken? Een provider hoeft zich er niet
aan te houden en kan gewoon de consequenties daarvan
aanvaarden.
> Het gaat in dit geval nog over zelf door de klant ingestelde filters voor
> alleen zijn eigen mail, dus dat mag. Maar ik kan me best voorstellen
> dat men bij UPC denkt "nou als je onze mail niet wilt onder je zelf
> bedachte regels dan neem je die mail toch gewoon NIET?" waarom zouden
> zij maatregelen moeten nemen om een blokking systeem te laten functioneren?
>
Ik zou toch bijna denken dat je pro-spam bent.
Xs4all kennende wordt deze dienst, als 'ie operationeel
wordt, toch aangeboden op opt-in basis.
> Rob
>
--
Met vriendelijke groeten/Best regards
Jeroen Wijnands
http://www.xs4all.nl/~wijnands
--
Never commit yourself! Let someone else commit you.
Marcel de Groot
"Cor Bosman" <c...@xs4.xs4all.nl> wrote in message
news:9vsama$hon$1...@xs4.xs4all.nl...
Nee, die zie ik er niet tussen staan!
mail-machine lijst
snowball.com IGN.com
pm0.net Newline Cinema
audible.com Audible.com
listbuilder.com Three Dead Trolls in a Baggie
dundee.net Woody's Windows Watch
" " Devshed.com
Marcel
Jan Ehrhardt
>UPC heeft, de laatste keer dat ik keek, in hun AUP staan dat
>het draaien van een server sowieso niet eens toegestaan is.
Dat geldt niet voor zakelijke klanten. Oftewel: Priority Telecom klanten
mogen evt. wel een eigen server draaien, Chello-abo's niet.
Jan
Cor Bosman
>> Dweilen met de kraan open? Wellicht. Maar UPC lijkt het
>> gewoon te verdommen om zelfs maar een dweil aan te schaffen.
>Overdrijf je niet een beetje? Ik heb ook wel eens scheldverhalen gelezen
>over open relays van XS4All. Als je bij ab...@chello.nl een open relay
>meldt wordt daar serieus iets aan gedaan is mijn ervaring.
>Ik heb het idee dat er wat (langdurige) administratieve problemen zijn met
>smtp1.a2000.nl en smpt2.a2000.nl . Is Priority, Chello of A2000 (wat daar
>nog van over is) nu verantwoordelijk voor deze mailservers??
Er is wel een GROOT verschil. XS4ALL stond op _outputs_ lists.
Maw, klanten van XS4ALL waren open relay, en gebruikten xs4all
mailservers als second-stage relay. Dan kom je op een outputs list.
Mede hierom zijn wij bezig klanten aktief te scannen op open relays.
smtpX.a2000.nl staat op inputs. Dat betekent dat ze zelf spam genereren
op de 1 of andere manier.
Cor
Rob Janssen
>> Zoals je weet kan een klant van UPC eventueel Windows 2000 draaien, en als
>> dat zo is dan is er een fikse kans dat iedere willekeurige buitenstaander
>> een CMD.EXE op zijn systeem kan runnen. Dat is ook voor een fiks aantal
>> klanten bij XS4ALL het geval. Wellicht zijn er al spammers die deze
>> gehackte systemen gebruiken om hun spam te versturen? Die zijn dan niet
>> te onderscheiden van open relays of spammende klanten (afhankelijk van
>> hoe de spammer het precies aanpakt).
>Ik vind de vergelijking met xs4all hier niet terrecht.
>Xs4all probeert wat te doen aan open relay's bij klanten.
Weet iemand of XS4ALL wat onderneemt tegen ongepatchte Windows 2000 IIS
systemen? Lijkt me dat dat gevaarlijker tijdbommen zijn dan relayende
mailservers. Die dingen kunnen namelijk ALLES, niet beperkt tot spammen
met zelfbedachte headers.
>> Het gaat in dit geval nog over zelf door de klant ingestelde filters voor
>> alleen zijn eigen mail, dus dat mag. Maar ik kan me best voorstellen
>> dat men bij UPC denkt "nou als je onze mail niet wilt onder je zelf
>> bedachte regels dan neem je die mail toch gewoon NIET?" waarom zouden
>> zij maatregelen moeten nemen om een blokking systeem te laten functioneren?
>Ik zou toch bijna denken dat je pro-spam bent.
Ik ben helemaal niet pro-spam, ik heb er zelf ook veel last van.
Maar ik zie weinig heil in blokkeren van complete mailservers "omdat de
beheerder het maar beter voor elkaar had moeten hebben" waarbij de
definitie van "goed voor elkaar" ook nog eens anders is dan de originele
ontwerpprincipes van een mailserver.
Ik kan me goed voorstellen dat een provider zich niet gaat bezighouden
met het tevreden houden van andere providers die eisen stellen aan het
beheer van de eigen servers of services.