Re: RFD: zelf diensten draaien op eigen computer mag vaak niet van ISP
In article <k17k2053ldq81bd0q5ptlqm0dg72uu6lnf@4ax.com>,
Peter Peters <peter.peters@utwente.nl> wrote:
>On Tue, 10 Feb 2004 17:11:30 +0100, philip@pch.home.cs.vu.nl (Philip
>Homburg) wrote:
>
>>Xs4all levert 'gratis' aan al hun klanten de mogelijkheid om hun
>>binnenkomende mail te laten scannen op virussen. Een paar weken terug
>>stond in een artikel over MyDoom dat blijkbaar ongeveer 30% van de klanten
>>daar gebruik van maakt. Xs4all heeft dus de capaciteit om op grote schaal
>>te scannen.
>
>Maar het zijn de gebruikers die het moeten willen. En blijkbaar wil 70%
>dat niet. En ik kan je garanderen dat een doos die nu 30% scant helemaal
>niet zeker ook 100% kan scannen. En dus moet er een nieuwe doos komen en
>moeten de tarieven verhoogd worden (of minder verlaagd). Uiteindelijk
>betalen de klanten het dus toch.
Dan ga je er vanuit dat klanten evenveel mail sturen als ze ontvangen.
Het kosten aspect van abuse bestrijding wordt door hetnet goed
geillustreerd.
--
Everyone I've met who had any experience with the phenomenon have confirmed my
opinion that if a Ph.D. in computer science knows anything at all about
computers, it's probably pretty much an accident. -- J.D. Baldwin, in asr
Re: RFD: zelf diensten draaien op eigen computer mag vaak niet van ISP
On Wed, 11 Feb 2004 13:41:01 +0100, philip@pch.home.cs.vu.nl (Philip
Homburg) wrote:
>>>Xs4all levert 'gratis' aan al hun klanten de mogelijkheid om hun
>>>binnenkomende mail te laten scannen op virussen. Een paar weken terug
>>>stond in een artikel over MyDoom dat blijkbaar ongeveer 30% van de klanten
>>>daar gebruik van maakt. Xs4all heeft dus de capaciteit om op grote schaal
>>>te scannen.
>>
>>Maar het zijn de gebruikers die het moeten willen. En blijkbaar wil 70%
>>dat niet. En ik kan je garanderen dat een doos die nu 30% scant helemaal
>>niet zeker ook 100% kan scannen. En dus moet er een nieuwe doos komen en
>>moeten de tarieven verhoogd worden (of minder verlaagd). Uiteindelijk
>>betalen de klanten het dus toch.
>
>Dan ga je er vanuit dat klanten evenveel mail sturen als ze ontvangen.
Op een gegeven moment zal het aantal mailtjes dat verzonden wordt
overeen moeten komen met het aantal mailtjes dat ontvangen wordt.
--
Peter Peters, senior netwerkbeheerder
Dienst Informatietechnologie, Bibliotheek en Educatie (ITBE)
Universiteit Twente, Postbus 217, 7500 AE Enschede
telefoon: 053 - 489 2301, fax: 053 - 489 2383, http://www.utwente.nl/civ
Re: RFD: zelf diensten draaien op eigen computer mag vaak niet van ISP
In article <m47k201ngkp14mn0gq049kbahl2q271vpf@4ax.com>,
Peter Peters <peter.peters@utwente.nl> wrote:
>On Tue, 10 Feb 2004 18:03:16 +0100, philip@pch.home.cs.vu.nl (Philip
>Homburg) wrote:
>
>>Met andere woorden, ISPs bemoeien zich wel degelijk met de inhoud van het
>>Internet verkeer van hun klanten.
>
>Alle zaken die je hierboven aanvoert hebben niets te maken met de inhoud
>maar met de oorsprong. TPGpost heeft de plicht om brieven te bezorgen
>ook als ze in het buitenland zijn gepost. Maar ze hebben de vrijheid om
>geen brieven van land X aan te nemen als daarmee geen
>vergoedinsovereenkomst is gesloten. En datzelfde zeggen de providers
>over de spamblokkades.
Een (niet-discrimerende) vergoedingsovereenkomst valt binnen het
concept van een common carrier. Een ander voorbeeld is SMS. Maar bij
spam gaat dat niet op. Xs4all weigert spam te ontvangen, zelf nadat Ab.Fab
aangaf bereid te zijn daarvoor te betalen. Dan kom je dus buiten het
common carrier principe.
>>Kom op zeg. In het geval van Swen gaat dat argument echt niet op. Een
>>ISP heeft de volledige mail op een zeker moment in de mail spool staan.
>
>Maar de ISP mag daar niet inkijken zonder toestemming van de klant. En
>zoals je in je andere posting meldde, geeft maar 30% van de xs4all
>klanten die toestemming.
Waar staat dat de ISP daar niet in mag kijken? Geautomatiseerde verwerking
van e-mail is de norm. Natuurlijk kijken de mail servers van xs4all in
mijn mail (nou ja, spam dus). Anders kunnen ze die mail niet doorsturen.
Hoe kan een netwerk stack een checksum uitrekenen zonder naar de inhoud
te kijken? Dan kom je op het spammer argument: 'kijken' is datgene wat ik
niet leuk vind.
Juist met de wet in de hand is het automatisch blokkeren van sommige
soorten e-mail te verdedigen.
Verder regelen ISPs allerlei zaken in de algemene voorwaarden. Er is geen
enkele reden om aan te nemen dat verplichte virusscanning strijdig zou
zijn met de wet.
--
Everyone I've met who had any experience with the phenomenon have confirmed my
opinion that if a Ph.D. in computer science knows anything at all about
computers, it's probably pretty much an accident. -- J.D. Baldwin, in asr
Re: RFD: zelf diensten draaien op eigen computer mag vaak niet van ISP
In article <hj0i20pngp12je213k7c0jecr5lle3vdb0@4ax.com>,
Peter Peters <peter.peters@utwente.nl> wrote:
>On Tue, 10 Feb 2004 15:40:42 +0100, philip@pch.home.cs.vu.nl (Philip
>Homburg) wrote:
>
>>>>Het kan natuurlijk
>>>>zijn dat de KPN 1:40 alleen hanteert voor downstream en dat er upstream
>>>>veel meer bandbreedte beschikbaar is.
>>>
>>>KPN verwacht dat de provider zelf al de lower- en upper-limit instellen
>>>van de PVC naar de betreffende klant. Is dat niet in overeenstemming met
>>>wat zij denken dat het is, komen alleen pakketten die nog net in 1
>>>ATM-cel passen door het netwerk.
>>
>>We hadden het over de upstream. Hoe kan een ISP een limit instellen voor
>>de upstream bandbreedte? De DSLAM bepaalt de upstream bandbreedte van
>>een ADSL aansluiting.
>
>Wat ik had begrepen van BBned is dat de upstream wordt geaggregeerd in
>de DSLAM a.d.h.v. het profiel van de gebruiker. En dat zal dan dus ook
>voor de upstream gelden.
Dit begrijp ik niet. De upstream wordt geaggregeerd en dat zal dan ook
voor de upstream gelden???
Zelfs als je die eerste upstream door downstream vervangt wordt het
niet echt duidelijk.
--
Everyone I've met who had any experience with the phenomenon have confirmed my
opinion that if a Ph.D. in computer science knows anything at all about
computers, it's probably pretty much an accident. -- J.D. Baldwin, in asr
Re: RFD: zelf diensten draaien op eigen computer mag vaak niet van ISP
Peter Peters wrote:
>
> On Wed, 11 Feb 2004 13:41:01 +0100, philip@pch.home.cs.vu.nl (Philip
> Homburg) wrote:
>
> >>>Xs4all levert 'gratis' aan al hun klanten de mogelijkheid om hun
> >>>binnenkomende mail te laten scannen op virussen. Een paar weken terug
> >>>stond in een artikel over MyDoom dat blijkbaar ongeveer 30% van de klanten
> >>>daar gebruik van maakt. Xs4all heeft dus de capaciteit om op grote schaal
> >>>te scannen.
> >>
> >>Maar het zijn de gebruikers die het moeten willen. En blijkbaar wil 70%
> >>dat niet. En ik kan je garanderen dat een doos die nu 30% scant helemaal
> >>niet zeker ook 100% kan scannen. En dus moet er een nieuwe doos komen en
> >>moeten de tarieven verhoogd worden (of minder verlaagd). Uiteindelijk
> >>betalen de klanten het dus toch.
> >
> >Dan ga je er vanuit dat klanten evenveel mail sturen als ze ontvangen.
>
> Op een gegeven moment zal het aantal mailtjes dat verzonden wordt
> overeen moeten komen met het aantal mailtjes dat ontvangen wordt.
Twee opmerkingen over details, die toch wel relevant zijn :
1. er zullen ISP's zijn met minder te verzenden dan te ontvangen
mailberichten (omdat ze bijvoorbeeld niet of nauwelijks als spambron
functioneren),
2. waar laten we in dit overzicht de geweigerde e-mail (geen bounces,
alleen returncode) ?
--
Fred Mobach - fred@mobach.nl - postmaster@mobach.nl
Systemhouse Mobach bv - The Netherlands - since 1976
website : http://fred.mobach.nl
Q: servos ad pileum vocare ?
A: servos fenestrae ad pileum rubrem vocare !
Re: RFD: zelf diensten draaien op eigen computer mag vaak niet van ISP
In article <vgak20hrfljude3uvmjehgc6m7gtvi7ah6@4ax.com>,
Peter Peters <peter.peters@utwente.nl> wrote:
>On Wed, 11 Feb 2004 13:41:01 +0100, philip@pch.home.cs.vu.nl (Philip
>Homburg) wrote:
>>Dan ga je er vanuit dat klanten evenveel mail sturen als ze ontvangen.
>
>Op een gegeven moment zal het aantal mailtjes dat verzonden wordt
>overeen moeten komen met het aantal mailtjes dat ontvangen wordt.
Daarom snapt de PTT (in het begin) ook niets van ISPs. Wel veel lijnen maar
er werd nooit mee gebeld...
--
Everyone I've met who had any experience with the phenomenon have confirmed my
opinion that if a Ph.D. in computer science knows anything at all about
computers, it's probably pretty much an accident. -- J.D. Baldwin, in asr
Re: RFD: zelf diensten draaien op eigen computer mag vaak niet van ISP
In article <402A319C.E60490A2@mobach.nl>, Fred Mobach <fred@mobach.nl> wrote:
>Peter Peters wrote:
>> Op een gegeven moment zal het aantal mailtjes dat verzonden wordt
>> overeen moeten komen met het aantal mailtjes dat ontvangen wordt.
>
>2. waar laten we in dit overzicht de geweigerde e-mail (geen bounces,
>alleen returncode) ?
De meederheid zal wel direct-to-MX mail zijn van spam/virus-engines.
Die tellen niet echt mee.
--
Everyone I've met who had any experience with the phenomenon have confirmed my
opinion that if a Ph.D. in computer science knows anything at all about
computers, it's probably pretty much an accident. -- J.D. Baldwin, in asr
Re: RFD: zelf diensten draaien op eigen computer mag vaak niet van ISP
On Wed, 11 Feb 2004 14:43:56 +0100, Fred Mobach <fred@mobach.nl> wrote:
>Twee opmerkingen over details, die toch wel relevant zijn :
>1. er zullen ISP's zijn met minder te verzenden dan te ontvangen
>mailberichten (omdat ze bijvoorbeeld niet of nauwelijks als spambron
>functioneren),
Dat is een detail. ;-)
>2. waar laten we in dit overzicht de geweigerde e-mail (geen bounces,
>alleen returncode) ?
Dan wordt het mailtje niet verzonden en dus ook niet ontvangen.
--
Peter Peters, senior netwerkbeheerder
Dienst Informatietechnologie, Bibliotheek en Educatie (ITBE)
Universiteit Twente, Postbus 217, 7500 AE Enschede
telefoon: 053 - 489 2301, fax: 053 - 489 2383, http://www.utwente.nl/civ
Re: RFD: zelf diensten draaien op eigen computer mag vaak niet van ISP
On Wed, 11 Feb 2004 13:50:14 +0100, philip@pch.home.cs.vu.nl (Philip
Homburg) wrote:
>>>Met andere woorden, ISPs bemoeien zich wel degelijk met de inhoud van het
>>>Internet verkeer van hun klanten.
>>
>>Alle zaken die je hierboven aanvoert hebben niets te maken met de inhoud
>>maar met de oorsprong. TPGpost heeft de plicht om brieven te bezorgen
>>ook als ze in het buitenland zijn gepost. Maar ze hebben de vrijheid om
>>geen brieven van land X aan te nemen als daarmee geen
>>vergoedinsovereenkomst is gesloten. En datzelfde zeggen de providers
>>over de spamblokkades.
>
>Een (niet-discrimerende) vergoedingsovereenkomst valt binnen het
>concept van een common carrier. Een ander voorbeeld is SMS. Maar bij
>spam gaat dat niet op. Xs4all weigert spam te ontvangen, zelf nadat Ab.Fab
>aangaf bereid te zijn daarvoor te betalen.
Ze weigerden een redelijke vergoeding te betalen.
>Dan kom je dus buiten het
>common carrier principe.
En dat is ook bij common carriers van belang.
>>>Kom op zeg. In het geval van Swen gaat dat argument echt niet op. Een
>>>ISP heeft de volledige mail op een zeker moment in de mail spool staan.
>>
>>Maar de ISP mag daar niet inkijken zonder toestemming van de klant. En
>>zoals je in je andere posting meldde, geeft maar 30% van de xs4all
>>klanten die toestemming.
>
>Waar staat dat de ISP daar niet in mag kijken? Geautomatiseerde verwerking
>van e-mail is de norm.
Maar je kunt ook geautomatiseerd zoeken op worden als "bin laden", bom
e.d.
>Natuurlijk kijken de mail servers van xs4all in
>mijn mail (nou ja, spam dus).
Als je dat hebt aangezet.
>Anders kunnen ze die mail niet doorsturen.
Mijn mailservers kunnen dat best zonder in de e-mail te kijken. Daarvoor
geeft de andere mailserver in RCPT-TO: het adres mee waarnaar het
doorgestuurd moet worden.
>Hoe kan een netwerk stack een checksum uitrekenen zonder naar de inhoud
>te kijken?
Van een netwerkpakket. Niet van een e-mail.
>Juist met de wet in de hand is het automatisch blokkeren van sommige
>soorten e-mail te verdedigen.
Dat is heel moeilijk volgens een aantal juristen die ik enkele weken
geleden op een seminiar heb gesproken. Je kunt wel besluiten dat iets
niet mag, maar als je niet besluit hoe het geimplementeerd mag worden,
gelden de wetten die je verbieden om ernaar te gaan kijken.
>Verder regelen ISPs allerlei zaken in de algemene voorwaarden. Er is geen
>enkele reden om aan te nemen dat verplichte virusscanning strijdig zou
>zijn met de wet.
Waarschijnlijk is dat niet het geval. Maar dat zou betekenen dat de AV
gewijzigd moet worden. Met daarin een vrijwaringsverklaring dat de ISP
niet aansprakelijk gesteld kan worden als een virus er toch doorheen
komt. En dat zou voor consumenten best eens weggewuivd kunnen worden als
een extra bezwarende voorwaarde die aan consumenten niet opgelegd kan
worden. Dat is anders als zoiets buiten de AV overeen wordt gekomen.
--
Peter Peters, senior netwerkbeheerder
Dienst Informatietechnologie, Bibliotheek en Educatie (ITBE)
Universiteit Twente, Postbus 217, 7500 AE Enschede
telefoon: 053 - 489 2301, fax: 053 - 489 2383, http://www.utwente.nl/civ
Re: RFD: zelf diensten draaien op eigen computer mag vaak niet van ISP
On Wed, 11 Feb 2004 13:51:39 +0100, philip@pch.home.cs.vu.nl (Philip
Homburg) wrote:
>>Wat ik had begrepen van BBned is dat de upstream wordt geaggregeerd in
>>de DSLAM a.d.h.v. het profiel van de gebruiker. En dat zal dan dus ook
>>voor de upstream gelden.
>
>Dit begrijp ik niet. De upstream wordt geaggregeerd en dat zal dan ook
>voor de upstream gelden???
Die hele tweede zin had er niet in gemoeten.
--
Peter Peters, senior netwerkbeheerder
Dienst Informatietechnologie, Bibliotheek en Educatie (ITBE)
Universiteit Twente, Postbus 217, 7500 AE Enschede
telefoon: 053 - 489 2301, fax: 053 - 489 2383, http://www.utwente.nl/civ
Re: RFD: zelf diensten draaien op eigen computer mag vaak niet van ISP
On Wed, 11 Feb 2004 15:26:45 +0100, philip@pch.home.cs.vu.nl (Philip
Homburg) wrote:
>>2. waar laten we in dit overzicht de geweigerde e-mail (geen bounces,
>>alleen returncode) ?
>
>De meederheid zal wel direct-to-MX mail zijn van spam/virus-engines.
>Die tellen niet echt mee.
Uit mijn ervaring is dat de laatste batches aan wormen geleerd hebben
van blokkades op dynamische en ADSL-ranges. Degenen die ik hier de
laatste maanden langs zie komen gaan naar de smarthost.
En de SMTP-engine van die wormen zijn zelfs beter dan die van Microsoft
Exchange. ;-(
--
Peter Peters, senior netwerkbeheerder
Dienst Informatietechnologie, Bibliotheek en Educatie (ITBE)
Universiteit Twente, Postbus 217, 7500 AE Enschede
telefoon: 053 - 489 2301, fax: 053 - 489 2383, http://www.utwente.nl/civ
Re: RFD: zelf diensten draaien op eigen computer mag vaak niet van ISP
In article <2kjk20tmsi52dc48176hha73981ba6bdq4@4ax.com>,
Peter Peters <peter.peters@utwente.nl> wrote:
>On Wed, 11 Feb 2004 15:26:45 +0100, philip@pch.home.cs.vu.nl (Philip
>Homburg) wrote:
>>De meederheid zal wel direct-to-MX mail zijn van spam/virus-engines.
>>Die tellen niet echt mee.
>
>Uit mijn ervaring is dat de laatste batches aan wormen geleerd hebben
>van blokkades op dynamische en ADSL-ranges. Degenen die ik hier de
>laatste maanden langs zie komen gaan naar de smarthost.
Mooi, want een smarthost blockt veel makkelijker. Welke wormen zijn dat
dan? Swen gaat via de smarthost, maar MyDoom weer niet.
--
Everyone I've met who had any experience with the phenomenon have confirmed my
opinion that if a Ph.D. in computer science knows anything at all about
computers, it's probably pretty much an accident. -- J.D. Baldwin, in asr
Re: RFD: zelf diensten draaien op eigen computer mag vaak niet van ISP
In article <iqgk20tsur2gpjv4dac1s3hv5q5lbg0163@4ax.com>,
Peter Peters <peter.peters@utwente.nl> wrote:
>On Wed, 11 Feb 2004 13:50:14 +0100, philip@pch.home.cs.vu.nl (Philip
>Homburg) wrote:
>>Een (niet-discrimerende) vergoedingsovereenkomst valt binnen het
>>concept van een common carrier. Een ander voorbeeld is SMS. Maar bij
>>spam gaat dat niet op. Xs4all weigert spam te ontvangen, zelf nadat Ab.Fab
>>aangaf bereid te zijn daarvoor te betalen.
>
>Ze weigerden een redelijke vergoeding te betalen.
Beweer jij hier nu echt dat xs4all een bedrag heeft genoemd dat het voor
Ab.Fab mogelijk zou maken om spam te sturen naar klanten van xs4all? Is dat
ergens gedocumenteerd?
>>Waar staat dat de ISP daar niet in mag kijken? Geautomatiseerde verwerking
>>van e-mail is de norm.
>
>Maar je kunt ook geautomatiseerd zoeken op worden als "bin laden", bom
>e.d.
En dus? Dat bepaalde toepassingen illegaal zijn betekent niet dat alle
toepassingen illegaal zijn.
>>Hoe kan een netwerk stack een checksum uitrekenen zonder naar de inhoud
>>te kijken?
>
>Van een netwerkpakket. Niet van een e-mail.
En dus? Een ISP mag wel in een network-packet kijken en niet in e-mail?
Dat klopt niet, wat dezelfde argumenten die gelden voor e-mail gelden
ook voor network-packets
Blijft over een afweging van belangen.
>>Juist met de wet in de hand is het automatisch blokkeren van sommige
>>soorten e-mail te verdedigen.
>
>Dat is heel moeilijk volgens een aantal juristen die ik enkele weken
>geleden op een seminiar heb gesproken. Je kunt wel besluiten dat iets
>niet mag, maar als je niet besluit hoe het geimplementeerd mag worden,
>gelden de wetten die je verbieden om ernaar te gaan kijken.
Wie is de 'je' die moet besluiten hoe het geimplementeerd moet worden?
Toch niet de overheid, dan heeft niemand meer een eigen
verantwoordelijkheid. Alleen burocratie is dan van belang.
Virus scanning is niet moeilijk. Bij veel virussen (waaronder Swen) kan
je met aan zekerheid grenzende waarschijnlijk vast stellen of een
mailtje verzonden is door het virus of niet.
Controleren of een bepaald virus aanwezig is in een mailtje is ongeveer
net zo privacy gevoelig als de routing van IP Packets.
>>Verder regelen ISPs allerlei zaken in de algemene voorwaarden. Er is geen
>>enkele reden om aan te nemen dat verplichte virusscanning strijdig zou
>>zijn met de wet.
>
>Waarschijnlijk is dat niet het geval. Maar dat zou betekenen dat de AV
>gewijzigd moet worden. Met daarin een vrijwaringsverklaring dat de ISP
>niet aansprakelijk gesteld kan worden als een virus er toch doorheen
>komt.
Hoe zo? Het 'recht' om op virussen te scannen staat los van een eventuele
aansprakelijkheid.
>En dat zou voor consumenten best eens weggewuivd kunnen worden als
>een extra bezwarende voorwaarde die aan consumenten niet opgelegd kan
>worden. Dat is anders als zoiets buiten de AV overeen wordt gekomen.
Een ISP verkoopt geen bescherming tegen claims van derden. In het
algemeen wordt door de acties van een ISP de schade als gevolg van een
virus niet groter. Het lijkt me dus logisch dat de verantwoordelijkheid
bij de klant blijft.
Filteren op binnenkomende virussen is in die zin veel interessanter, omdat
de ISP daar wel (aan de klant) een dienst levert.
--
Everyone I've met who had any experience with the phenomenon have confirmed my
opinion that if a Ph.D. in computer science knows anything at all about
computers, it's probably pretty much an accident. -- J.D. Baldwin, in asr
Re: RFD: zelf diensten draaien op eigen computer mag vaak niet van ISP
Philip Homburg wrote:
>
> In article <iqgk20tsur2gpjv4dac1s3hv5q5lbg0163@4ax.com>,
> Peter Peters <peter.peters@utwente.nl> wrote:
[...]
> Filteren op binnenkomende virussen is in die zin veel interessanter, omdat
> de ISP daar wel (aan de klant) een dienst levert.
Filteren op uitgaande virussen is ook interessant voor die klanten, het
voorkomt opname in bloklijsten van virusbronnen.
--
Fred Mobach - fred@mobach.nl - postmaster@mobach.nl
Systemhouse Mobach bv - The Netherlands - since 1976
website : http://fred.mobach.nl
Q: servos ad pileum vocare ?
A: servos fenestrae ad pileum rubrem vocare !
Re: RFD: zelf diensten draaien op eigen computer mag vaak niet van ISP
On Wed, 11 Feb 2004 17:51:43 +0100, philip@pch.home.cs.vu.nl (Philip
Homburg) wrote:
>>>De meederheid zal wel direct-to-MX mail zijn van spam/virus-engines.
>>>Die tellen niet echt mee.
>>
>>Uit mijn ervaring is dat de laatste batches aan wormen geleerd hebben
>>van blokkades op dynamische en ADSL-ranges. Degenen die ik hier de
>>laatste maanden langs zie komen gaan naar de smarthost.
>
>Mooi, want een smarthost blockt veel makkelijker. Welke wormen zijn dat
>dan? Swen gaat via de smarthost, maar MyDoom weer niet.
Maar Swen schakelt terug naar direct-to-MX als de smarthost niet
reageert of hem blokkeert. Is bekend of MyDoom niet toevallig eerst
direct-to-MX probeert en als dat niet lukt de smarthost?
--
Peter Peters, senior netwerkbeheerder
Dienst Informatietechnologie, Bibliotheek en Educatie (ITBE)
Universiteit Twente, Postbus 217, 7500 AE Enschede
telefoon: 053 - 489 2301, fax: 053 - 489 2383, http://www.utwente.nl/civ