Provider neemt toegang tot mijn mail

[kalizec]

Als voormalig technisch medewerker bij een ISP kan ik bevestigen dat het redelijk normaal is dat medewerkers wachtwoorden in kunnen zien van klanten. Ook het vragen erom is normaal, immers het wachtwoord is de afgesproken code waarmee de klant zichzelf identificeerd aan de provider. Als een klant die code telefonisch doorgeeft aan de helpdesk bevestigd hij/zij daar eigenlijk mee dat hij 'echt' die persoon is. Of dat wachtwoord nu onversleuteld over internet heen gaat of onversleuteld over de telefoon gaat maakt in deze niet uit.

Nu aangaande de e-mailbox. Voor het oplossen van sommige problemen heb je nu eenmaal toegang tot de mailbox nodig. Bijvoorbeeld de klant stelt dat eea niet werkt, dan kun je alleen het tegendeel bewijzen door het uit te proberen en te zien dat het werkt. Om dat te controleren moet je dus wel toegang tot de mailbox verkrijgen.

Vervolgens is het inderdaad netjes om slechts naar de headers te kijken. Maar soms is ook dat niet te voorkomen. Stel dat een klant in het buitenland zit en er een mailtje in zijn mailbox zit die de boel echt blokkeert, dan heb je eigenlijk geen andere keus dan om met de klant te overleggen of het mailtje verwijderd mag worden. In dergelijk geval controleer je dus het wachtwoord van de klant en vervolgens zul je met de klant kunnen overleggen of bepaalde mailtjes van bepaalde afzenders weg mogen. Het alternatief is namelijk dat je alles weggooid en dat is pas echt klantonvriendelijk.

De manier waarop het initiele voorbeeld echter om gaat met de mailbox is inderdaad niet helemaal netjes, maar qua privacy gaat er niets mis. Let wel, medewerkers van ISP's moeten vrijwel altijd geheimhoudingsverklaringen tekenen. In mijn eigen geval heb ik toen ook een verklaring voor enkele tienduizenden (toen nog) guldens getekend. En ja, je ziet vreemde dingen voorbij komen, maar daar houd je gewoon je mond over.

Wel ben ik het met de TS eens dat de tekst uit het voorbeeld alles behalve klantvriendelijk handelen is vanuit de kant van de medewerker. Toch denk ik dat er geen echte schade is aangericht. Er is geen informatie uit de mailbox bij derden terecht gekomen noch blijkt uit iets dat de medewerker op eigen houtje de mailbox is gaan lezen. Inloggen om een wachtwoord te controleren en of de mailbox werkt is eigenlijk slechts een poging om te controleren of eea echt werkt, daarmee help je een klant. Dus eigenlijk is het service-gericht bedoeld.

[JvS]

andreas2005 schreef op vrijdag 11 januari 2008 @ 14:05:
[...]

Ik mag hopen dat je toch wat vriendelijker bent tegen je klanten. Die in-de-mail-gluuractie van je gebruik je alleen om de klant belachelijk te maken en daarna af te schepen. Die heeft een echt, maar overduidelijk ander probleem dan hij zelf denkt, maar krijgt "doei" te horen in plaats van dat hij wordt geholpen. Dat had je ook kunnen doen zonder in de mail te kijken.

Je moet altijd vriendelijk blijven. Helaas beginnen klanten vaak erg hoog van de toren te schreeuwen over niet werkende mailboxen. Dan vraag ik altijd of de klant het goed vindt om even aan deze kant te controleren of ik met zijn/haar gegevens kan inloggen.

Er zijn vast wel andere manieren om aan te tonen dat een box werkt. Ik geloof dat, maar een klant gelooft dat gewoon niet. Soms moet je inderdaad zeggen "kent u die en die persoon" voor het tastbaar wordt dat die mailbox écht wel werkt.

Misschien heb je geen ervaring met werken op een helpdesk. Ik heb zo'n vier jaar bij KPN gewerkt. Klanten hebben een schrufthekel aan een probleem analyseren: "Ja, los het nou maar gewoon op!" (zeker als je niet aangeeft waarom je het doet). Daarna is het gewoon in 90% van de gevallen zo dat er geen storing is, maar dat er ergens iets verkeerd ingesteld staat. Je gaat dus altijd instellingen controleren. Door te zeggen "mag ik controleren of er een storing met de mailbox is, door even in te loggen" en daarna een naam te noemen overtuig je de klant in elk geval wel dat de mailbox echt werkt. Want als je zegt "mijn mailbox-test-tool zegt dat de box gewoon werkt, zullen we even al uw instellingen nalopen? Welke foutmelding ziet u precies?" dan heeft een klant daar geen boodschap aan...

Ik snap het allemaal best wel. Het maakt het ook wel makkelijker. En ik deed het zelf zoals gezegd ook.

[World Citizen]

JvS schreef op vrijdag 11 januari 2008 @ 15:06:
[...]

Je moet altijd vriendelijk blijven. Helaas beginnen klanten vaak erg hoog van de toren te schreeuwen over niet werkende mailboxen. Dan vraag ik altijd of de klant het goed vindt om even aan deze kant te controleren of ik met zijn/haar gegevens kan inloggen.

Er zijn vast wel andere manieren om aan te tonen dat een box werkt. Ik geloof dat, maar een klant gelooft dat gewoon niet. Soms moet je inderdaad zeggen "kent u die en die persoon" voor het tastbaar wordt dat die mailbox écht wel werkt.

Misschien heb je geen ervaring met werken op een helpdesk. Ik heb zo'n vier jaar bij KPN gewerkt. Klanten hebben een schrufthekel aan een probleem analyseren: "Ja, los het nou maar gewoon op!" (zeker als je niet aangeeft waarom je het doet). Daarna is het gewoon in 90% van de gevallen zo dat er geen storing is, maar dat er ergens iets verkeerd ingesteld staat. Je gaat dus altijd instellingen controleren. Door te zeggen "mag ik controleren of er een storing met de mailbox is, door even in te loggen" en daarna een naam te noemen overtuig je de klant in elk geval wel dat de mailbox echt werkt. Want als je zegt "mijn mailbox-test-tool zegt dat de box gewoon werkt, zullen we even al uw instellingen nalopen? Welke foutmelding ziet u precies?" dan heeft een klant daar geen boodschap aan...

Ik snap het allemaal best wel. Het maakt het ook wel makkelijker. En ik deed het zelf zoals gezegd ook.

Je schets het hier zo dat je veel ervaring hebt met klanten, maar helaas blijkt er in de praktijk een staartje aan te zitten . Je hebt zeker nog nooit een klant geholpen op deze manier, en dat er om een of andere vage reden achteraf een mail verdwenen bleek te zijn...... Je moet ze dan eens horen. Dan gaat jouw hele verhaal hierboven keihard tegen je gebruikt worden , en ben jij de klos. Niet de klant die jouw blijkbaar met social-engenering omver kan lullen.

[JvS]

Ik heb dat nog niet meegemaakt nee. Dat gebeurt ook bijna nooit en een dergelijke klacht is meer iets voor de klachtenafhandeling dan voor de technische support. Mijn functies waren 1e, 2e lijn, ondersteuning van agents en af en toe een training systemen of adsl techniek geven. Dan heb je daar niet zoveel mee te maken. (het was m'n bijbaantje, ik was uitzendkracht ).

Ik zeg ook niet dat het de heilige graal is. Ik zeg alleen dat het het gesprek veel eenvoudiger maakt bij sommige klanten. Het scheelt het stukje gesprekstijd om aan te geven waarom je instellingen wil nakijken en waarom je dus niet direct in de houding schiet om de gemelde storing gaat oplossen (dat verwachten mensen).

Ik vind het overigens niet zo prettig dat je allemaal conclusies trekt over dat klanten mij met social engeneering omver kunnen lullen. Het komt op mij over dat je nu zegt dat ik door mijn zwakte in communicatie dit soort lage trucjes moet toepassen om een klant te overtuigen. Dat is niet zo. Als het moet kan je ook op andere manieren een klant overtuigen. Een hele verveldne is de "hang yourself" methode. Hele simpele vragen stellen en ze zo zelf tot de conclusie laten komen dat het belangrijk is om iets te controleren.

Het enige dat ik aangeef is dat het handig kan zijn om een klant snel te laten inzien waar het probleem in elk geval niet zit, zodat je daarna soepel door kan gaan met het oplossen van het daadwerkelijke probleem.

Ik zeg niet dat het de beste manier is. Al denk ik dat de snelheid, de tevredenheid en kostenbesparing die het oplevert nog best weleens positief uit zou kunnen pakken tegenover die ene klant die én echt een mail kwijt is waarvan hij kan aantonen dat die verstuurd is, én waarbij de helpdesk pas in zijn box heeft gekeken.

[ Voor 15% gewijzigd door JvS op 11-01-2008 15:27 ]

[Sleejuhr]

Denk dat dit verschilt per helpdesk, waar ik gewerkt heb kon ik geen passwords zien van klanten.

Ik kon wel als helpdesk in de mail van klanten kijken mocht ik dat willen, maar dit wist maar een klein deel van de helpdesk. Voordat we een mail in mochten kijken moesten we de klant daar uitdrukkelijk om vragen, aangezien wij de mail ook behandelden onder briefgeheim.

[Grum]

Verwijderd schreef op donderdag 10 januari 2008 @ 19:59:
Even op reageren. Bij XS4ALL kan geen enkele helpdesk medewerker een wachtwoord zien, op geen enkel moment.

En dit is niet omdat het system het niet aan die specifieke medewerker wil/zal laten zien, maar simpelweg omdat het systeem het niet weet. Er zijn geen plaintext passwords bekend.

batsma schreef op donderdag 10 januari 2008 @ 14:35:
Prutsers hiermee bedoel je goedkopere ISP's neem ik aan.

Neehoor, prutsers is onafhankelijk van de prijs en slaat puur op het niet bewust omgaan met privacy gevoelige gegevens. Als iemand op watvoor manier toegang krijgt tot het system wil je gewoon per definitie niet dat daar om wat voor reden dan ook plaintext wachtwoorden in staan.

Hoeveel mensen gebruiken niet dezelfde wachtwoorden voor login/email/tweakers/hotmail/whatever .. meer dan teveel, het is privacy gevoelige info en zou zo ook behandeld moeten worden.

[Verwijderd]

kalizec schreef op vrijdag 11 januari 2008 @ 14:45:
Als voormalig technisch medewerker bij een ISP kan ik bevestigen dat het redelijk normaal is dat medewerkers wachtwoorden in kunnen zien van klanten. Ook het vragen erom is normaal, immers het wachtwoord is de afgesproken code waarmee de klant zichzelf identificeerd aan de provider. Als een klant die code telefonisch doorgeeft aan de helpdesk bevestigd hij/zij daar eigenlijk mee dat hij 'echt' die persoon is. Of dat wachtwoord nu onversleuteld over internet heen gaat of onversleuteld over de telefoon gaat maakt in deze niet uit.

Nu aangaande de e-mailbox. Voor het oplossen van sommige problemen heb je nu eenmaal toegang tot de mailbox nodig. Bijvoorbeeld de klant stelt dat eea niet werkt, dan kun je alleen het tegendeel bewijzen door het uit te proberen en te zien dat het werkt. Om dat te controleren moet je dus wel toegang tot de mailbox verkrijgen.

Vervolgens is het inderdaad netjes om slechts naar de headers te kijken. Maar soms is ook dat niet te voorkomen. Stel dat een klant in het buitenland zit en er een mailtje in zijn mailbox zit die de boel echt blokkeert, dan heb je eigenlijk geen andere keus dan om met de klant te overleggen of het mailtje verwijderd mag worden. In dergelijk geval controleer je dus het wachtwoord van de klant en vervolgens zul je met de klant kunnen overleggen of bepaalde mailtjes van bepaalde afzenders weg mogen. Het alternatief is namelijk dat je alles weggooid en dat is pas echt klantonvriendelijk.

De manier waarop het initiele voorbeeld echter om gaat met de mailbox is inderdaad niet helemaal netjes, maar qua privacy gaat er niets mis. Let wel, medewerkers van ISP's moeten vrijwel altijd geheimhoudingsverklaringen tekenen. In mijn eigen geval heb ik toen ook een verklaring voor enkele tienduizenden (toen nog) guldens getekend. En ja, je ziet vreemde dingen voorbij komen, maar daar houd je gewoon je mond over.

Wel ben ik het met de TS eens dat de tekst uit het voorbeeld alles behalve klantvriendelijk handelen is vanuit de kant van de medewerker. Toch denk ik dat er geen echte schade is aangericht. Er is geen informatie uit de mailbox bij derden terecht gekomen noch blijkt uit iets dat de medewerker op eigen houtje de mailbox is gaan lezen. Inloggen om een wachtwoord te controleren en of de mailbox werkt is eigenlijk slechts een poging om te controleren of eea echt werkt, daarmee help je een klant. Dus eigenlijk is het service-gericht bedoeld.

Jups, de meeste mensen die gebruik maken van provider e-mail zullen denk ik ook vooral mensen zijn met niet al teveel technische computer kennis om problemen etc zelf op te lossen (correct me if I am wrong)

Er zullen niet willekeurige mensen achter de helpdesk en met deze toegang achter de computer zitten, dit zijn mensen die het bedrijf heeft gescreened en die een contract hebben ondertekend met gevolgen bij overtreding. Vertrouw je het bedrijf of het personeel niet moet je imho maar een andere ISP zoeken waar je je wel fijn bij voelt...

[ninjazx9r98]

Wat me opvalt in de discussie dat er gedaan wordt alsof je bij mailservers te maken hebt met 'rocket science'
Er wordt moeilijk gereageerd op tooling, alleen inloggen geeft de juiste informatie enz enz.
Het is net alsof mensen een mailserver als een of ander bijzonder/mysterieus apparaat zien.

Als we er voor het gemak van uitgaan dat de gemiddelde provider een Linux danwel Unix variant draait is het allemaal niet zo spannend.
Voor het gemak even op een kleine Debian mailserver :

server:~# ll /var/mail/klant
-rw-rw---- 1 klant mail 140417 2008-01-11 06:26 /var/mail/klant

Deze klant ontvangt zowieso mail en de laatste mail is van 11 januari om 06:26

server:~# grep klant /var/log/mail.log
Jan 11 18:08:12 server in.qpopper[12726]: (v4.0.5) POP login by user "klant" at (192.168.1.100) 192.168.1.100 [pop_log.c:244]

Deze klant logt met succes in op de mailserver.

server:~# grep klant /var/log/mail.log
Jan 11 18:11:13 server in.qpopper[12753]: [AUTH] Failed attempted login to klant from host (192.168.1.100) 192.168.1.100 [pop_pass.c:1383]

Voor een diagnose ben je nu in principe al een heel eind op weg op een hele simpele manier die ook nog eens heel eenvoudig in te passen is in tooling die voor het gemak webbased zou kunnen zijn.
Dat klanten niet tevreden reageren op de informatie uit dergelijke tooling lijkt me eerder een kwestie van hoe je het brengt cq uitlegt dan dat men er echt ontevreden mee is danwel kan zijn.

Met een sudo oplossing kun je bepaalde mensen toegang geven tot het passwd commando zodat ook niet beheerders wachtwoorden kunnen resetten.

En natuurlijk is bovenstaande allemaal heel simpel gezegd maar het gaat om het principe.

Tevens wordt corrupte email genoemd maar eerlijk gezegd kan ik me niet herinneren wanneer ik dat voor het laatst gezien/gehoord heb.
Wat natuurlijk niet betekent dat het niet bestaat maar het lijkt me dat dat in verhouding zo weinig voorkomt dat je dat soort gevallen zou kunnen escaleren naar de volgende lijn of richting systeembeheer.

Daarnaast zag ik nog iemand refereren aan de Telecommunicatiewet II
Kijk ook eens naar de wet computercriminaliteit waar een en ander vrij duidelijk in genoemd wordt.
Kijken in de mailbox van iemand anders is gewoon strafbaar.
Ik zal nog eens herhalen wat ik al eerder gepost heb :

Artikel 193c
Met gevangenisstraf van ten hoogste een jaar of geldboete van de vierde categorie wordt gestraft
hij die opzettelijk en wederrechtelijk met een technisch hulpmiddel gegevens aftapt of opneemt die
niet voor hem bestemd zijn en die worden verwerkt of overgedragen door middel van
telecommunicatie of door middel van een geautomatiseerd werk.

Artikel 273d
1. Met gevangenisstraf van ten hoogste een jaar en zes maanden of geldboete van de vierde categorie wordt gestraft de persoon werkzaam bij een aanbieder van een openbaar telecommunicatienetwerk of een openbare telecommunicatiedienst:

a. die opzettelijk en wederrechtelijk van gegevens kennisneemt die door tussenkomst van zodanig netwerk of zodanige dienst zijn opgeslagen, worden verwerkt of overgedragen en die niet voor hem zijn bestemd, zodanige gegevens voor zichzelf of een ander overneemt, aftapt of opneemt;

b. die de beschikking heeft over een voorwerp waaraan, naar hij weet of redelijkerwijs moet vermoeden, een gegeven kan worden ontleend, dat door wederrechtelijk overnemen, aftappen of opnemen van zodanige gegevens is verkregen;

c. die opzettelijk en wederrechtelijk de inhoud van zodanige gegevens aan een ander bekendmaakt;

d. die opzettelijk en wederrechtelijk een voorwerp waaraan een gegeven omtrent de inhoud van zodanige gegevens kan worden ontleend, ter beschikking stelt van een ander.


2. Het eerste lid is van overeenkomstige toepassing op de persoon werkzaam bij een aanbieder van een niet-openbaar telecommunicatienetwerk of een niet-openbare telecommunicatiedienst.

Overigens hadden we het vandaag toevallig op het werk over deze hele discussie waarbij een collega nog met een ander argument aankwam.
Er is redelijk wat software te koop waarbij je na betaling een licentiecode per email toegestuurd krijgt.
Ook dat soort gegevens liggen bij wijze van spreken op straat als een 'willekeurig' iemand zomaar een mailbox binnen kan wandelen.

[Verwijderd]

Er is redelijk wat software te koop waarbij je na betaling een licentiecode per email toegestuurd krijgt.
Ook dat soort gegevens liggen bij wijze van spreken op straat als een 'willekeurig' iemand zomaar een mailbox binnen kan wandelen.

Zeker, maar wat is 'willekeurig'
-> je partner?
-> je vriendin? een collega?
-> je buurvrouw?
-> iemand die in een ander dorp woont en niks geen band met je heeft?
-> iemand die bij de helpdesk van je internetprovider werkt?
-> de topbaas van de internetprovider?

[ Voor 3% gewijzigd door Verwijderd op 11-01-2008 18:47 ]

[ninjazx9r98]

Verwijderd schreef op vrijdag 11 januari 2008 @ 17:56:
[...]

Jups, de meeste mensen die gebruik maken van provider e-mail zullen denk ik ook vooral mensen zijn met niet al teveel technische computer kennis om problemen etc zelf op te lossen (correct me if I am wrong)

Heb je ook nog een redenatie waarom dat zo zou zijn ?
Ga je er bijvoorbeeld zondermeer vanuit dat iedereen met computerkennis een eigen domein heeft, eigen mailserver of iets in die richting ?
Ik werk op een afdeling met 40 techneuten die gespecialiseerd zijn in een van de volgende : Unix, Windows, AS400, Novell, Datacom.
Ik geloof dat er naast mij nog 2 zijn met een eigen domein en/of mailserver.
De rest gebruikt gewoon de email van de provider.

Er zullen niet willekeurige mensen achter de helpdesk en met deze toegang achter de computer zitten, dit zijn mensen die het bedrijf heeft gescreened en die een contract hebben ondertekend met gevolgen bij overtreding. Vertrouw je het bedrijf of het personeel niet moet je imho maar een andere ISP zoeken waar je je wel fijn bij voelt...

Dat zou je inderdaad mogen hopen.
In een aantal reacties in deze discussie kun je echter lezen dat dat kennelijk niet vanzelfsprekend is.
Tenzij de mensen die roepen dat ze 'overal' bij kunnen vreselijk aan het opscheppen zijn.

Wat het veranderen van ISP betreft, ik lees dit ondertussen al meerdere keren maar wie kan mij aangeven per ISP hoe het daar in de praktijk geregeld is qua privacy ??
Tot ik namelijk begon met het lezen van deze discussie had ik er nooit aan gedacht dat er uberhaupt providers zouden zijn waar men plaintext passworden ter beschikking had en waar men zondermeer in mailboxen kon kijken.
Mijn veronderstelling was tot nu toe dat je mailbox bij iedere provider 'heilig' en veilig was, dat je wachtwoord encrypted in een password file cq database stond en dat alleen de beheerders van de mailserver zelf in een mailbox zouden kunnen kijken.

[alt-92]

ninjazx9r98 schreef op vrijdag 11 januari 2008 @ 18:51:
Mijn veronderstelling was tot nu toe dat je mailbox bij iedere provider 'heilig' en veilig was, dat je wachtwoord encrypted in een password file cq database stond en dat alleen de beheerders van de mailserver zelf in een mailbox zouden kunnen kijken.

*kuch* GoogleMail *kuch*
Hoeveel accounts hebben die inmiddels wel niet?

[ninjazx9r98]

alt-92 schreef op vrijdag 11 januari 2008 @ 18:58:
[...]


*kuch* GoogleMail *kuch*
Hoeveel accounts hebben die inmiddels wel niet?

Verklaar je nader.
Met andere woorden, wat doet dat af aan mijn gedachte of beter gezegd veronderstelling ?

[kalizec]

ninjazx9r98 schreef op vrijdag 11 januari 2008 @ 18:43:
Voor het gemak even op een kleine Debian mailserver :

Ware het niet dat mailservers bij een ISP met honderdduizenden mailboxen zich niet leent voor inloggen op een machine om even een mailbestand te controleren op datum. Kortom even kijken naar een datum en tijd helpt niet. Zelf beheer ik ook meerdere kleine mailservers en ik kan je vertellen dat dat echt andere koek is dan een cluster van mailservers met allerhande andere 3d-party software.

ninjazx9r98 schreef op vrijdag 11 januari 2008 @ 18:43:

Daarnaast zag ik nog iemand refereren aan de Telecommunicatiewet II
Kijk ook eens naar de wet computercriminaliteit waar een en ander vrij duidelijk in genoemd wordt.
Kijken in de mailbox van iemand anders is gewoon strafbaar.

Sorry maar die interpretatie is botweg incorrect.

Artikel 273d.1a
Er zijn hier twee stukjes cruciaal. Het eerste is het woord "wederrechtelijk". Daar is hier geen sprake van immers voor goed functioneren van een e-mailsysteem is het normaal dat de gegevens op de server staan, het aanwezig en voorhanden zijn van die gegevens an sich is dus normaal en zeker niet wederrechtelijk.

Het tweede stukje "overneemt, aftapt of opneemt" van deze drie is geen van allen sprake. Inzien is wat anders dan overnemen, aftappen of opnemen. Overnemen impliceert kopieren en daar is geen sprake van. Aftappen impliceert onderscheppen en daar is ook geen sprake van en tot slot opnemen impliceert weer kopieren en daar is geen sprake van bij inzien.

Artikel 273d.1b
Gaat geheel over de middelen nodig voor Artikel 273d.1a en dus niet van toepassing.

Artikel 273d.1c
Gaat over doorgeven van die gegevens naar het inzien. Is ook geen sprake van. En mocht hij de inhoud van de box doorgeven aan de klant is het niet wederrechtelijk.

Artikel 273d.1d
Gaat weer geheel over de middelen nodig voor Artikel 273d.1c.

Kortom het door een medewerker van een ISP inzien van een mailbox van een klant aldaar wordt niet verboden door de telecom wet. Tevens wil ik er op wijzen dat de telecomwet niet gelijk staat aan briefgeheim en dat het doel ook niet hetzelfde is.

edit:


Om nog even toe te lichten wat dan wel het doel van de telecomwet is.
Het doel is om wederrechtelijk overnemen, aftappen of opnemen van telecomverkeer tegen te gaan.
Het betreffende onderwerp van de TS heeft meer met privacy-wetgeving te maken dan met telecom-wetgeving.

Tot slot, ninjazx9r98, kan ik je aanraden juridische teksten te leren lezen en mocht je het met het bovenstaande niet eens zijn, dat je dan even aangeeft waarom niet en op basis van welke ervaring en scholing je meent dat deze artikelen anders geinterpreteerd dienen te worden.

[ Voor 5% gewijzigd door kalizec op 11-01-2008 20:20 ]

[Gomez12]

ninjazx9r98 schreef op vrijdag 11 januari 2008 @ 18:43:
Wat me opvalt in de discussie dat er gedaan wordt alsof je bij mailservers te maken hebt met 'rocket science'
Er wordt moeilijk gereageerd op tooling, alleen inloggen geeft de juiste informatie enz enz.
Het is net alsof mensen een mailserver als een of ander bijzonder/mysterieus apparaat zien.

Nee hoor, maar ik werk graag in een professionele omgeving en geen hobby bob omgeving.

server:~# ll /var/mail/klant
-rw-rw---- 1 klant mail 140417 2008-01-11 06:26 /var/mail/klant
Deze klant ontvangt zowieso mail en de laatste mail is van 11 januari om 06:26

Eigenlijk is er gewoon iets toegevoegd aan dit bestand / het is gekopieerd, of dit mail is of een superuser die dit bestand getouched heeft weet je niet.

server:~# grep klant /var/log/mail.log
Jan 11 18:08:12 server in.qpopper[12726]: (v4.0.5) POP login by user "klant" at (192.168.1.100) 192.168.1.100 [pop_log.c:244]
Deze klant logt met succes in op de mailserver.

Hmm, om de een of andere reden gok ik dat dit soort logfiles bij een grotere provider niet zo maar even te greppen zijn of de logfiles worden gearchived waardoor het niet zo 1-2-3 te voorspellen valt in welk bestand je moet greppen. Maar inderdaad gooi maar elke keer een grep over 5Gb aan logbestanden, dat kost niets etc.

Voor een diagnose ben je nu in principe al een heel eind op weg op een hele simpele manier die ook nog eens heel eenvoudig in te passen is in tooling die voor het gemak webbased zou kunnen zijn.
Dat klanten niet tevreden reageren op de informatie uit dergelijke tooling lijkt me eerder een kwestie van hoe je het brengt cq uitlegt dan dat men er echt ontevreden mee is danwel kan zijn.

Want wat weet je nu eigenlijk? Als de klant zegt geen mail binnen te krijgen dan kan jij nog zo mooi vertellen dat het volgens jou zou moeten werken, als hij blijft volhouden dat het niet werkt heb jij een lang gesprek te gaan. Dit is heel simpel op te lossen door de 2 vragen : Mag ik even in uw mailbox kijken? En kent u persoon x/y?

Met een sudo oplossing kun je bepaalde mensen toegang geven tot het passwd commando zodat ook niet beheerders wachtwoorden kunnen resetten.

Ehm, helpdesk medewerkers op de een of andere manier via sudo superuser laten worden is toch echt een nogo.

Overigens hadden we het vandaag toevallig op het werk over deze hele discussie waarbij een collega nog met een ander argument aankwam.
Er is redelijk wat software te koop waarbij je na betaling een licentiecode per email toegestuurd krijgt.
Ook dat soort gegevens liggen bij wijze van spreken op straat als een 'willekeurig' iemand zomaar een mailbox binnen kan wandelen.

A : Het is geen willekeurig iemand ( wel bijna als ik sommige helpdesken zie ) ,
B : Ik vind het een non-argument. Je hebt privacy of geen privacy en dan vind ik een licentie code wel een van de minder belangrijke dingen. Ik kan me stukken ergere dingen bedenken dan 1 licentie codetje.

IDEE

Maar alternatief gedrags / beleids voorstel wat ik even bedenk uit hier genoemde voorbeelden :
1 : De helpdesk medewerker moet indien nodig aan de klant vragen of de klant zijn wachtwoord wil geven.
2 : Als de klant het niet wil einde verhaal.
3 : Als de klant het geeft dan kan de helpdesk medewerker inloggen
4 : Als de klant het niet weet ( staat standaard in outlook opgeslagen, dat weet ik toch niet etc. ) dan kan de helpdesker op een knopje drukken waarna hij de vraag krijgt of hij het aan de klant gevraagd heeft ja/nee ( dit wordt gelogd ) indien ja dan kan hij in de mailbox van de klant.

Door altijd deze irri popup ertussen te douwen weet iedereen weer dat hij het eerst moet gaan vragen en valt deze logging ook bij te houden ( als iedereen max 2x per dag op dit knopje drukt en pietje drukt 100x per dag op dit knopje dan heeft pietje wat uit te leggen, en niet weten / vooruit willen werken is niet meer van toepassing )
Op deze manier is er geen plaintext password nodig ( is ook nooit nodig, reset is voldoende maarja ). Iemand die even vooruit wil lopen op zijn klant heeft een probleem, want hij doet dit meer dan zijn collega's en negeert dus de policyvraag waar hij ja op moet antwoorden.

Op zich lijkt me dat iedereen het hier mee eens zou kunnen zijn? Want imho heeft de helpdesk wel de mogelijkheid nodig, en is het alleen maar een beleidsprobleem als er misbruik van wordt gemaakt.

Of heeft er iemand iets aan te merken op dit idee?

[kalizec]

Gomez12 schreef op vrijdag 11 januari 2008 @ 21:36:
Of heeft er iemand iets aan te merken op dit idee?

Ja, daar is wel iets op aan te merken. Soms komen klanten en hun problemen via e-mail of brief binnen. Daar kun je niet 123 toestemming vragen. Nog afgezien van dat de opdracht om het probleem op te lossen echt als toestemming tot een fatsoenlijke troubleshoot procedure geinterpreteerd mag worden. Inclusief toegang tot de betreffende mailbox.

Ik heb zelf meermalen mee gemaakt dat een klant mailde dat zijn mailbox niet werkte en zijn afzendadres het 'niet' werkende mailadres was. Dan heb je vaak geen andere keus dan het probleem gewoon oplossen, want per e-mail bereiken gaat dan dus niet.

edit:

Maar voor eerste-lijn helpdesk personeel aan de telefoon kan het inderdaad een oplossing zijn

[ Voor 6% gewijzigd door kalizec op 11-01-2008 23:00 ]

[Verwijderd]

freedzed6 schreef op woensdag 09 januari 2008 @ 22:21:
Je ben paranoia en je moet eens weten wat mogelijk is! IEDERE ISP kan in hun klanten mailboxen kijken en ja ook helpdesk medewerkers. Je zou zelfs zijn telefoon (voip) kunnen afluisteren zonder dat de telefoon gaat! WAKE UP dus en stel je niet aan! Indien je slechte bedoeldingen hebt moet je de boel maar coderen oid.

Er staan overigens hele forse boetes op als je hiermee buiten je functie opeens mee gaat zitten kloten. Dit is precies als met artsen die geheimen weten van patienten.

Gast waar heb je het over. Ik heb 2 jaar bij XS4ALL helpdesk gewerkt en 1 jaar bij Multikabel helpdesk. XS4ALL helpdeskers kunnen GEEN wachtwoorden zien, en alleen resetten als de klant belt vanaf zijn ADSL lijn (alvorens over de telefoon een nieuw ww te mogen geven). Helpdesk medewerkers hebben GEEN toegang tot mailboxen van de klant, immers heb je daar het ww voor nodig. Je kunt alleen zien of er berichten binnenkomen. Bij Multikabel was het (ondertussen 6 jaar gelden ) zo dat je alleen een ww kon resetten die dan per brief zou arriveren.

Ik vind het een ZEER slecht iets als ISP hun medewerkers toegang geven tot zulke prive gegevens van hun klanten. Ik snap ook niet dat sommige mensen er hier zo gemakkelijk over doen; kennelijk hebben ze nooit bij organisaties gelet hoe mensen om kunnen gaan met zulke klantgegevens

[Verwijderd]

kalizec schreef op vrijdag 11 januari 2008 @ 14:45:
Als voormalig technisch medewerker bij een ISP kan ik bevestigen dat het redelijk normaal is dat medewerkers wachtwoorden in kunnen zien van klanten. Ook het vragen erom is normaal, immers het wachtwoord is de afgesproken code waarmee de klant zichzelf identificeerd aan de provider. Als een klant die code telefonisch doorgeeft aan de helpdesk bevestigd hij/zij daar eigenlijk mee dat hij 'echt' die persoon is. Of dat wachtwoord nu onversleuteld over internet heen gaat of onversleuteld over de telefoon gaat maakt in deze niet uit.

Kennelijk is het *normaal* bij *die ISP waar jij hebt gewerkt*. Maar niet bij die 2 waar *ik* heb gewerkt. Slechte slechte zaak dit. Wat nou als een bedrijf 100 helpdeskers heeft? Wat nou als ze een externe callcenter inhuren? Vertrouw jij al deze mensen? Er zitten *altijd* rotte appels bij.

Ben er een beetje sprakeloos van eerlijk gezegd. Goed het zal de invloed van XS4ALL op mij wel zijn

[kalizec]

Verwijderd schreef op vrijdag 11 januari 2008 @ 23:03:
Ik vind het een ZEER slecht iets als ISP hun medewerkers toegang geven tot zulke prive gegevens van hun klanten. Ik snap ook niet dat sommige mensen er hier zo gemakkelijk over doen; kennelijk hebben die nooit bij dergelijke organisaties gewerkt.

Zulke prive gegevens zijn het nu ook weer niet. Mag ik je er op wijzen dat bij kabel het notabene een shared medium is... een andere config in het modem laden en je kunt alle verkeer van de hele wijk zien mocht het nodig zijn.

Verder zijn wachtwoorden niet prive informatie. Als een wachtwoord prive was, dan was het niet onderling afgesproken. Wat jij bedoelt is de feitelijke inhoud van een e-mailbox, en ook dat gaat gewoon unencrypted over het internet heen. Tevens betwijfel ik ten zeerste of die situatie bij XS4All en Multikabel voor al het helpdesk-personeel geldt, kennelijk vereisen XS4All en Multikabel geen verklaring van al hun personeel en moeten ze het daarom beveiligen...

[Verwijderd]

kalizec schreef op vrijdag 11 januari 2008 @ 23:12:
[...]
Zulke prive gegevens zijn het nu ook weer niet. Mag ik je er op wijzen dat bij kabel het notabene een shared medium is... een andere config in het modem laden en je kunt alle verkeer van de hele wijk zien mocht het nodig zijn.

Zo diep zit ik niet in de kabel technologie, maar ik had gehoopt dat dit met invoering van DOCSIS al die jaren geleden niet meer mogelijk zou zijn... Nog meer redenen om op DSL te blijven

Verder zijn wachtwoorden niet prive informatie. Als een wachtwoord prive was, dan was het niet onderling afgesproken. Wat jij bedoelt is de feitelijke inhoud van een e-mailbox, en ook dat gaat gewoon unencrypted over het internet heen.

Niet mee eens. Wachtwoorden geen prive informatie? Zo zeg dat maar eens tegen klanten van ISP's...!

Tevens betwijfel ik ten zeerste of die situatie bij XS4All en Multikabel voor al het helpdesk-personeel geldt

En toch is het echt zo.

[ninjazx9r98]

kalizec schreef op vrijdag 11 januari 2008 @ 20:03:
[...]

Ware het niet dat mailservers bij een ISP met honderdduizenden mailboxen zich niet leent voor inloggen op een machine om even een mailbestand te controleren op datum. Kortom even kijken naar een datum en tijd helpt niet. Zelf beheer ik ook meerdere kleine mailservers en ik kan je vertellen dat dat echt andere koek is dan een cluster van mailservers met allerhande andere 3d-party software.

Inloggen ??
Waarom zou je in hemelsnaam willen inloggen om dergelijke informatie tevoorschijn te halen ?
Dergelijke informatie kun je heel eenvoudig met een webbased form oplepelen uit een logfile.
Ook honderdduizenden mailboxen zegt helemaal niets, een beetje server draait daar z'n hand niet voor om een grep oid in wat files te doen.
Zoals ik al zie, het verbaast me om te zien dat mensen net doen of het 'rocket science' is en ontzettend spannend.

[...]

Sorry maar die interpretatie is botweg incorrect.

Laat ik nu hetzelfde willen zeggen over jouw interpretatie.

Artikel 273d.1a
Er zijn hier twee stukjes cruciaal. Het eerste is het woord "wederrechtelijk". Daar is hier geen sprake van immers voor goed functioneren van een e-mailsysteem is het normaal dat de gegevens op de server staan, het aanwezig en voorhanden zijn van die gegevens an sich is dus normaal en zeker niet wederrechtelijk.

Over incorrect gesproken.
Volgens mij zie je twee zaken over het hoofd.
1) Wie is de eigenaar van de email, cq aan wie is het gericht.
2) De betekenis van wederrechtelijk.
Als de gegevens niet voor jou bestemd zijn, maw email gericht aan de klant is het gewoon wederrechtelijk als je die mailbox opent.

edit:


Om nog even toe te lichten wat dan wel het doel van de telecomwet is.
Het doel is om wederrechtelijk overnemen, aftappen of opnemen van telecomverkeer tegen te gaan.
Het betreffende onderwerp van de TS heeft meer met privacy-wetgeving te maken dan met telecom-wetgeving.

Er is ook nog een wet op de computer criminaliteit...

Tot slot, ninjazx9r98, kan ik je aanraden juridische teksten te leren lezen en mocht je het met het bovenstaande niet eens zijn, dat je dan even aangeeft waarom niet en op basis van welke ervaring en scholing je meent dat deze artikelen anders geinterpreteerd dienen te worden.

Hear hear
Ik zou zeggen ga eens wat lezen op http://www.iusmentis.com/
Misschien steek je er nog wat van op.

PS
Als je zo prat gaat op je eigen zogenaamde kennis van het lezen van juridische teksten zou het je sieren om aan te geven op basis van welke ervaring en scholing je dat zelf doet voor je dat van een ander verlangt.

[ninjazx9r98]

Gomez12 schreef op vrijdag 11 januari 2008 @ 21:36:
[...]

Nee hoor, maar ik werk graag in een professionele omgeving en geen hobby bob omgeving.

En in een professionele omgeving kijken mensen in mailboxen maar in een hobby bob omgeving heeft men tooling ?

[...]

Eigenlijk is er gewoon iets toegevoegd aan dit bestand / het is gekopieerd, of dit mail is of een superuser die dit bestand getouched heeft weet je niet.

Ach ja, het is natuurlijk ook doodnormaal dat er zomaar iets toegevoegd wordt aan een dergelijke file, zucht.
En het is natuurlijk ook doodnormaal dat een superuser zomaar een file touched, zucht.
Op een fatsoenlijk beheerd systeem geeft dat gewoon aan wat het laatste tijdstip is waarop mail is toegevoegd aan die file.
Als je dat soort dingen in twijfel gaat trekken ben je echt spijkers op laag water aan het zoeken.

[...]

Hmm, om de een of andere reden gok ik dat dit soort logfiles bij een grotere provider niet zo maar even te greppen zijn of de logfiles worden gearchived waardoor het niet zo 1-2-3 te voorspellen valt in welk bestand je moet greppen. Maar inderdaad gooi maar elke keer een grep over 5Gb aan logbestanden, dat kost niets etc.

Misschien heeft men inderdaad wel logrotate en gzippen de logfiles.
Maken we er toch gewoon zgrep van in plaats van grep ?
En waarom zouden beheerders niet weten in welke files je moet greppen of niet kunnen aangeven aan de mensen die tooling maken welke files het betreft ?
Je doet nu net alsof er een stel digibeten dat soort servers inrichten en beheren.
En goh wat zal het toch moeilijk zijn om een grep oid uit te voeren op een bestand van 5GB (een grootte die zomaar uit de lucht komt vallen)
Niemand is verbaasd dat Google een seconde na een muisklik met vele duizenden resultaten komt voor een willekeurige zoekactie maar lokaal binnn het eigen netwerk op zoek gaan naar een beetje data is ineens weer 'rocket science'
Wat ik aangaf is een simpel voorbeeld en geen maatstaf voor hoe het er in de praktijk daadwerkelijk uit zal zien.
Simpele feit is gewoon dat logfiles precies doen wat de naam al zegt, loggen.
En dat loggen is bedoelt om diagnoses te stellen.

[...]

Want wat weet je nu eigenlijk? Als de klant zegt geen mail binnen te krijgen dan kan jij nog zo mooi vertellen dat het volgens jou zou moeten werken, als hij blijft volhouden dat het niet werkt heb jij een lang gesprek te gaan. Dit is heel simpel op te lossen door de 2 vragen : Mag ik even in uw mailbox kijken? En kent u persoon x/y?

Dan zeg je tegen de klant dat je op de server kan zien dat er weldegelijk mail binnen komt en noem je datum en tijdstip waarop die bewuste mailfile voor het laatst aangepast is.
Vervolgens geef je aan dat je op het systeem kan zien op welk tijdstip men heeft geprobeerd om in te loggen en wat er toen gebeurde.
Zie je de naam niet voorkomen in de log dan zijn er instellingen fout.
Zie je de naam en een password melding geef je aan dat het wachtwoord niet klopt.
Zie je de naam en een succesvolle login geef je aan dat hij binnenkomt op de mailserver.
Wat is daar nu zo vreselijk ingewikkeld aan ?

[...]

Ehm, helpdesk medewerkers op de een of andere manier via sudo superuser laten worden is toch echt een nogo.

Tsjah....
Volgens mij ben je in de war met su en/of weet je niet wat sudo precies is.

[...]

A : Het is geen willekeurig iemand ( wel bijna als ik sommige helpdesken zie ) ,
B : Ik vind het een non-argument. Je hebt privacy of geen privacy en dan vind ik een licentie code wel een van de minder belangrijke dingen. Ik kan me stukken ergere dingen bedenken dan 1 licentie codetje.

A : Willekeurig stond tussen quootjes, die stonden daar niet zomaar
B : Klopt maar het is wel een sprekend voorbeeld van iets wat zomaar ineens op straat zou kunnen liggen en zegt misschien wat meer dan 'privacy' want kennelijk zijn er maar weinig die beseffen wat dat inhoudt.

[Quacka]

Wat is in het algemeen het nut van het openen van mailboxes door helpdeskmedewerkers?

Men zou bij providers tools moeten hebben om bepaalde zaken te kunnen testen, zonder dat er noodzaak is om echt de mailbox te kunnen bezoeken.
Om te weten of een bepaalde login-naam nog bestaat moeten andere testwijze makkelijk mogelijk zijn. Zeker bij providers. Klant geeft login-naam op. Medewerker zoekt login-naam op in zijn systeem. Controleert of de juiste klant bij deze login-naam hoort.
Wanneer je als helpdeskmedewerker de mailbox nodig hebt om een loginnaam te controleren, dan heeft de provider zijn systemen niet op orde.

Wanneer de klant zijn wachtwoord is kwijtgeraakt, dan moet een helpdeksmedewerker natuurlijk wel mogelijkheid hebben om het wachtwoord te resetten. Dan heb je 2 mogelijkheden: Ultra-veilig: Wachtwoord wordt gereset en daarna opgestuurd naar klant. Dit duurt een tijd en is irritant voor klant. Een alternatief kan zijn om het wachtwoord telefonisch te resetten, waarna er automatisch een mail wordt gestuurd met daarin een link naar een pagina waar de klant heel makkelijk zijn wachtwoord weer kan resetten. Zo moeilijk is dit niet, volgens mij.
Voor de veiligheid kan een provider er ook voor kiezen om bij een telefonische wijziging voor de zekerheid ook een brief op te sturen met de melding dat wegens een telefonisch verzoek door klant het wachtwoord is gereset. (normaal gesproken weet een klant hier al van, maar in het geval van misbruik kan de klant ingrijpen, al is het dan al te laat)

Wat ik dus wil zeggen is dat providers hun systemen best kunnen aanpassen zodat privacy wel beschermd wordt, maar helpdeskmedewerkers toch snel klanten kunnen helpen. Providers dienen alleen dan wel hun systemen te wijzigen en moeten zorgen voor voldoende tools voor hun medewerkers.

Ik hoop dat tweakers.net dit probleem eens aan de aandacht wil brengen via een nieuwsbericht. Het is blijkbaar nodig. Nodig om de privacy van nederlanders te verbeteren.
En tweakers heeft een echt eigen nieuwsbericht. De meeste nieuwsberichten worden immers van andere sites over genomen / van persberichten overgenomen.

[Gomez12]

kalizec schreef op vrijdag 11 januari 2008 @ 23:00:
[...]

Ja, daar is wel iets op aan te merken. Soms komen klanten en hun problemen via e-mail of brief binnen. Daar kun je niet 123 toestemming vragen. Nog afgezien van dat de opdracht om het probleem op te lossen echt als toestemming tot een fatsoenlijke troubleshoot procedure geinterpreteerd mag worden. Inclusief toegang tot de betreffende mailbox.

Het gaat hier om een 1e lijns procedure, te lang niet in de helpdesk sector gewerkt, maar je zou toch een klant kunnen terugbellen ter verificatie?

Btw, vroeger kwam gewoon 97% van de vragen of telefonisch of per email binnen en als het per email binnenkomt heb je per definitie al niets in de klant zijn emailbox te zoeken, want dan werkt die...

ninjazx9r98 schreef op zaterdag 12 januari 2008 @ 00:15:
[...]
En in een professionele omgeving kijken mensen in mailboxen maar in een hobby bob omgeving heeft men tooling ?

Nee, maar in een professionele omgeving is professionele tooling aanwezig en dat kost geld en dat zullen de meeste isps er niet voor over hebben.
En dan kun je kiezen voor een simpele effectieve werkwijze die elke vakantiekracht kan begrijpen ( want die heeft waarschijnlijk ooit wel eens webmail gezien ) of je kan kiezen voor hobby-bob tooling die als je niet oppast stukgaat op de meest simpele logging wijzigingen / pad veranderingen in nieuwe versies etc. En als het stuk is dan is er opeens niemand meer aanwezig die er meer iets vanaf weet, want pietje die het geschreven heeft werkt er al 1/2 jaar niet meer. Oftewel helpdesk kan voor een x tijd niets meer nakijken.
Er is een reden waarom bedrijven voornamelijk support contracten afsluiten en huiverig zijn voor hobbybob oplossingen die misschien wel specifiek voor hun bedrijf gemaakt zijn...

Ach ja, het is natuurlijk ook doodnormaal dat er zomaar iets toegevoegd wordt aan een dergelijke file, zucht.
En het is natuurlijk ook doodnormaal dat een superuser zomaar een file touched, zucht.
Op een fatsoenlijk beheerd systeem geeft dat gewoon aan wat het laatste tijdstip is waarop mail is toegevoegd aan die file.

Nee, alleen het laatste tijdstip waarop een file is veranderd. Met jouw methode geeft een helpdesk per definitie foute info als er ergens anders in de organisatie een beheerder een foutje maakt.
Jouw methode is gewoon bij lange na niet waterdicht en zeker niet voor een klant.

Misschien heeft men inderdaad wel logrotate en gzippen de logfiles.
Maken we er toch gewoon zgrep van in plaats van grep ?

Ok, processor belasting stijgt met een x percentage door het gebruik van zgrep ipv grep...

En waarom zouden beheerders niet weten in welke files je moet greppen of niet kunnen aangeven aan de mensen die tooling maken welke files het betreft ?
Je doet nu net alsof er een stel digibeten dat soort servers inrichten en beheren.

Niet inrichten, maar jij wilt dus echt een compleet systeem gaan bouwen wat beheer echt moet gaan onderhouden ( want dit soort maatregelen gaat even iets verder dan de eerder genoemde scripts ).
En een mail server was toch geen rocket science, alleen moet je blijkbaar wel kundige beheerders hebben of het zelfs uitbesteden? Btw rocket science is het niet, maar om het op grote schaal goed te regelen gaat toch echt wel iets verder dan wat simpele scriptjes.

En goh wat zal het toch moeilijk zijn om een grep oid uit te voeren op een bestand van 5GB (een grootte die zomaar uit de lucht komt vallen)

Ooit wel eens logfiles gezien van een mailserver van een provider met enkele 10.000 en mailboxen? En dan willen ze dat nog over een bepaalde tijd bewaard hebben...

Niemand is verbaasd dat Google een seconde na een muisklik met vele duizenden resultaten komt voor een willekeurige zoekactie maar lokaal binnn het eigen netwerk op zoek gaan naar een beetje data is ineens weer 'rocket science'

Ja, google is ook gewoon iets wat jij natuurlijk binnen een week nabouwt... Google wordt ook echt gemaakt en onderhouden door 3 man die gewoon 40 werken?
En voor google is zoeken core-business, dit ontwikkelen mag geld kosten, ze verdienen het wel weer terug. Voor een ISP is een helpdesk gewoon een kostenpost die noodzakelijk is.
Beetje ander perspectief misschien?

Simpele feit is gewoon dat logfiles precies doen wat de naam al zegt, loggen.
En dat loggen is bedoelt om diagnoses te stellen.

Klopt, alleen niet voor 1e lijns helpdesk medewerkers en niet omdat truus belt dat ze haar wachtwoord vergeten is wat in haar aanmeldings brief staat die zij niet meer kan terugvinden...

Dan zeg je tegen de klant dat je op de server kan zien dat er weldegelijk mail binnen komt en noem je datum en tijdstip waarop die bewuste mailfile voor het laatst aangepast is.
Vervolgens geef je aan dat je op het systeem kan zien op welk tijdstip men heeft geprobeerd om in te loggen en wat er toen gebeurde.
Zie je de naam niet voorkomen in de log dan zijn er instellingen fout.
Zie je de naam en een password melding geef je aan dat het wachtwoord niet klopt.
Zie je de naam en een succesvolle login geef je aan dat hij binnenkomt op de mailserver.
Wat is daar nu zo vreselijk ingewikkeld aan ?

Simpel voorbeeld, de nas / san vliegt eruit en dus geeft de grep geen respons. Jij geeft dan dus rustig verkeerde info aan de klant.
Of jij ziet in de log staan dat er een uur geleden nog succesvol is ingelogd op die account, klant weet 100% zeker dat dit niet zo is, alleen heeft zijn vrouw thuis nog even de mail gecontroleerd. Dan zeg jij rustig dat hij binnenkomt op de server terwijl de instellingen niet goed gaan.
Jouw methodiek is gewoon niet waterdicht, en om het wel waterdicht te krijgen moet je een gehele applicatie gaan laten bouwen die nog een heleboel extra dingen checkt. En dat kost weer geld...
Het is niet zo simpel als jij het voorstelt, de simpele controles zijn inderdaad makkelijk uit te voeren, maar om het waterdicht te krijgen moet je opeens met heel veel dingen rekening gaan houden en waarom zou je dat doen als je al een methodiek hebt waarmee je de omgeving van de klant voor 90% kunt nabootsen?

[...]
Tsjah....
Volgens mij ben je in de war met su en/of weet je niet wat sudo precies is.

Ok, inderdaad mijn fout. Ik ken sudo alleen als root-tool, maar je kan dus ook gewoon als een andere user een programma uitvoeren.

Quacka schreef op zaterdag 12 januari 2008 @ 00:18:
Wanneer je als helpdeskmedewerker de mailbox nodig hebt om een loginnaam te controleren, dan heeft de provider zijn systemen niet op orde.

Loginnaam testen heeft vziw niemand hier genoemd.

Een alternatief kan zijn om het wachtwoord telefonisch te resetten, waarna er automatisch een mail wordt gestuurd met daarin een link naar een pagina waar de klant heel makkelijk zijn wachtwoord weer kan resetten. Zo moeilijk is dit niet, volgens mij.

Nee, maar wachtwoord resetten is ook niet het probleem, het komen tot de diagnose of het aan het wachtwoord ligt of dat er iets anders aan de hand is daarvoor moet of een tool geschreven worden of je kan gewoon de helpdesk medewerker het recht geven om in te loggen als gebruiker en het dan in je procedures te regelen dat dit goed zou moeten gaan.

Wat ik dus wil zeggen is dat providers hun systemen best kunnen aanpassen zodat privacy wel beschermd wordt, maar helpdeskmedewerkers toch snel klanten kunnen helpen. Providers dienen alleen dan wel hun systemen te wijzigen en moeten zorgen voor voldoende tools voor hun medewerkers.

En naast de tools moet er ook nog eens training komen voor de medewerkers, de tools moeten beheerd worden. Iemand had hier al eens eerder een simpel driehoekje getoond, wat niet altijd opgaat maar voor een verliesdraaiende / service afdeling als een helpdesk gaat het dat wel op.

[JvS]

Ik zou het wel eens interessant vinden te onderzoeken welke ISP's je wachtwoord als plain tekst opslaan en welke als een hash . Misschien daar eens een los topic over openen .

[ninjazx9r98]

Gomez12 schreef op zaterdag 12 januari 2008 @ 02:05:

[...]
Nee, maar in een professionele omgeving is professionele tooling aanwezig en dat kost geld en dat zullen de meeste isps er niet voor over hebben.
En dan kun je kiezen voor een simpele effectieve werkwijze die elke vakantiekracht kan begrijpen ( want die heeft waarschijnlijk ooit wel eens webmail gezien ) of je kan kiezen voor hobby-bob tooling die als je niet oppast stukgaat op de meest simpele logging wijzigingen / pad veranderingen in nieuwe versies etc. En als het stuk is dan is er opeens niemand meer aanwezig die er meer iets vanaf weet, want pietje die het geschreven heeft werkt er al 1/2 jaar niet meer. Oftewel helpdesk kan voor een x tijd niets meer nakijken.
Er is een reden waarom bedrijven voornamelijk support contracten afsluiten en huiverig zijn voor hobbybob oplossingen die misschien wel specifiek voor hun bedrijf gemaakt zijn...

Volgens mij heb jij echt het idee dat ISP's hoogstaande technische omgevingen hebben die echt vreselijk bijzonder zijn en waar hele spannende moeilijke dingen gebeuren.
Ik heb nieuws voor je, het is allemaal niet zo spannend.
Alleen al de benaming van hobby-bob tooling voor scripts ed die op bijv een Linux/Unix omgeving draaien en aanwezig zijn geeft aan dat je maar wat roept zonder echt te weten waar je het over hebt.

Ik kom dagelijks in aanraking met Unix systemen waar vele terabytes aan kostbare klant informatie op staat en het aanwezig zijn van (zelfgemaakte) scripts die allerlei taken automatiseren is de normaalste zaak van de wereld op dergelijke systemen.
Het gebruiken van scripts om allerlei routine handelingen uit te voeren is niets bijzonders in de Linux/Unix wereld.
Om een of andere vage reden probeer jij dat er echter wel van te maken.
Misschien gebrek aan kennis van hoe het er in een echte beheeromgeving aan toe gaat ?

[...]

Nee, alleen het laatste tijdstip waarop een file is veranderd. Met jouw methode geeft een helpdesk per definitie foute info als er ergens anders in de organisatie een beheerder een foutje maakt.
Jouw methode is gewoon bij lange na niet waterdicht en zeker niet voor een klant.

Schei toch uit zeg.
'ergens in de organisatie een beheerder'
Natuurlijk, er lopen allerlei beheerders overal en nergens in een organisatie die allemaal op die mailserver kunnen inloggen en die zitten ook regelmatig in die mailboxen te wrotten waar ze stomme fouten maken.
De kans dat dit daadwerkelijk aan de hand is is dusdanig klein dat je dit gewoon spijkers op laag water zoeken kunt noemen.
Je bent nu werkelijk zoekende naar argumenten.

[...]

Niet inrichten, maar jij wilt dus echt een compleet systeem gaan bouwen wat beheer echt moet gaan onderhouden ( want dit soort maatregelen gaat even iets verder dan de eerder genoemde scripts ).

Wat denk je dan dat tot de taken van een beheerder hoort ??
Tapes wisselen ??
Is het dan werkelijk zo'n vreemd idee dat een systeemBEHEERDER weet in welke logfiles welke informatie te vinden is ??
Sorry maar dan heb je echt geen flauw idee wat het allemaal inhoudt.

En een mail server was toch geen rocket science, alleen moet je blijkbaar wel kundige beheerders hebben of het zelfs uitbesteden? Btw rocket science is het niet, maar om het op grote schaal goed te regelen gaat toch echt wel iets verder dan wat simpele scriptjes.

Mag ik je vragen wat jij denkt wat een systeembeheerder is en doet ?
Ik heb namelijk het idee dat jij daar heel anders over denkt dan ik.
Overigens lijkt het me niet meer dan logisch dat systeembeheerders kundig zijn tenzij jij er natuurlijk een hele andere definitie van systeembeheer op na houdt.
En nogmaals, ik werk dagelijks met grote systemen en ook op grote schaal is het helemaal niet spannend om scripts te gebruiken.

[...]

Ja, google is ook gewoon iets wat jij natuurlijk binnen een week nabouwt... Google wordt ook echt gemaakt en onderhouden door 3 man die gewoon 40 werken?
En voor google is zoeken core-business, dit ontwikkelen mag geld kosten, ze verdienen het wel weer terug. Voor een ISP is een helpdesk gewoon een kostenpost die noodzakelijk is.
Beetje ander perspectief misschien?

Wakeup call, het gaat om het principe !!
Het principe is dat het mogelijk is om redelijke tot hele grote hoeveelheden aan data binnen een zeer korte tijd te doorzoeken en tot nu toe doe jij net of dat heel ingewikkeld is.

[...]

Klopt, alleen niet voor 1e lijns helpdesk medewerkers en niet omdat truus belt dat ze haar wachtwoord vergeten is wat in haar aanmeldings brief staat die zij niet meer kan terugvinden...

Dus geef je die 1e lijns helpdesk de beschikking over een tool die eea in hapklare brokken voorschotelt.
Het is allemaal niet zo spannend.

[...]

Simpel voorbeeld, de nas / san vliegt eruit en dus geeft de grep geen respons. Jij geeft dan dus rustig verkeerde info aan de klant.

Lol.
En natuurlijk is er helemaal nergens een of ander monitoring systeem wat dat in de gaten krijgt en aan beheer plus helpdesk doorgeeft dat er stront aan de knikker is en dat eea tijdelijk niet in de lucht is.
Nee stel je voor zeg als het nas/san eruit ligt dat je die info verspreidt naar oa de helpdesk zodat ze fatsoenlijk vragen kunnen beantwoorden die er ongetwijfeld binnen notime komen als zoiets plat ligt.
Wat overigens als de helpdesk ineens niet meer die mailbox kan binnenwandelen vanwege nas/san problemen ?
Dan zeg je gewoon tegen de klant "Inderdaad, hier werkt het ook niet"
Je bent echt zoekende naar bijzondere situaties om je gelijk te halen.

Of jij ziet in de log staan dat er een uur geleden nog succesvol is ingelogd op die account, klant weet 100% zeker dat dit niet zo is, alleen heeft zijn vrouw thuis nog even de mail gecontroleerd. Dan zeg jij rustig dat hij binnenkomt op de server terwijl de instellingen niet goed gaan.

Dan zeg je gewoon dat hij een uur geleden nog wel email kon ophalen en stel je de vraag of er in het laatste uur nog iets gebeurt is.
Mijn God zeg, is het allemaal dan werkelijk zo vreselijk moeilijk ?

Jouw methodiek is gewoon niet waterdicht, en om het wel waterdicht te krijgen moet je een gehele applicatie gaan laten bouwen die nog een heleboel extra dingen checkt. En dat kost weer geld...
Het is niet zo simpel als jij het voorstelt, de simpele controles zijn inderdaad makkelijk uit te voeren, maar om het waterdicht te krijgen moet je opeens met heel veel dingen rekening gaan houden en waarom zou je dat doen als je al een methodiek hebt waarmee je de omgeving van de klant voor 90% kunt nabootsen?

Dat doe je omdat de mailbox plus inhoud van de klant is en derden daar in principe niets te zoeken hebben.
Veel moeilijker dan dat is het niet.

[...]

Ok, inderdaad mijn fout. Ik ken sudo alleen als root-tool, maar je kan dus ook gewoon als een andere user een programma uitvoeren.

Eigenlijk is dit wel grappig, je blaast heel hoog van de toren over hoe moeilijk het allemaal wel niet is en over scripting wat hobby-bob niveau zou zijn maar een veelgebruikt stukje tooling wat juist in dit soort settings veelvuldig wordt gebruikt weet je niet wat het nu eigenlijk is en doet.

Ik heb te maken met beheerders van Linux/Unix systemen waarbij de een er 1 in beheer heeft en de andere 20 of meer.
Het scripten en dus automatiseren van allerlei taken is de kracht van een goede systeembeheerder en maakt het beheer en leven vele malen makkelijker.
Als iemand dan scripten gaat vergelijken met hobby-bob niveau en dat niet professioneel noemt vraag ik me werkelijk af wat je eigen ervaring is of in wat voor soort omgeving je zelf werkt.
Scripting en een professionele omgeving gaan uitstekend samen.
Sterker nog, je zou kunnen zeggen dat professionele omgevingen waar niet gescript wordt niet bestaan.

[Verwijderd]

Ik heb voor een zeer korte periode op de helpdesk van Tiscali (en van Telfort, Speedlinq etc..) gewerkt, en inderdaad de medewerkers van de helpdesk kunnen jouw wachtwoorden zien, en kunnen wanneer 'nodig' inloggen in je mailbox.

Ik vindt dit inderdaad ook niet kloppen, want zoals veel providers altijd zeggen: "Onze medewerkers zullen u nooit vragen om uw wachtwoord". Bij Tiscali is dat dus ook niet nodig, want die hebben ze al!

[ninjazx9r98]

kalizec schreef op vrijdag 11 januari 2008 @ 23:12:
[...]


Zulke prive gegevens zijn het nu ook weer niet. Mag ik je er op wijzen dat bij kabel het notabene een shared medium is... een andere config in het modem laden en je kunt alle verkeer van de hele wijk zien mocht het nodig zijn.

Pardon ???
Email die gericht is aan mijn persoon is niet prive ???

Verder zijn wachtwoorden niet prive informatie. Als een wachtwoord prive was, dan was het niet onderling afgesproken. Wat jij bedoelt is de feitelijke inhoud van een e-mailbox, en ook dat gaat gewoon unencrypted over het internet heen. Tevens betwijfel ik ten zeerste of die situatie bij XS4All en Multikabel voor al het helpdesk-personeel geldt, kennelijk vereisen XS4All en Multikabel geen verklaring van al hun personeel en moeten ze het daarom beveiligen...

Met wie heb ik dan een wachtwoord afgesproken ??
Ik heb een wachtwoord ingegeven bij een geautomatiseerd systeem.
Nergens is er een of andere vorm van overleg geweest met een persoon waarbij we samen afspraken welk wachtwoord ik zou gaan gebruiken.

Jouw redenatie doortrekkend is zeker mijn pincode ook niet prive ?
Die is tenslotte volgens jouw manier van redeneren ook onderling afgesproken.
Zelfde geldt voor m'n huissleutel, autosleutel en noem het allemaal maar op.
Allemaal onderling met elkaar afgesproken.

[kalizec]

ninjazx9r98 schreef op vrijdag 11 januari 2008 @ 23:40:
Waarom zou je in hemelsnaam willen inloggen om dergelijke informatie tevoorschijn te halen ?

Omdat als je ook maar enig benul had van goed troubleshooten dan had je geweten dat je om iets te testen je het uit moet proberen. Neem maar eens een gemiddelde FAQ van Harde Waren door op troubleshooting. Je zult zien dat het allemaal uitproberen is. Er zijn legio voorbeelden mogelijk waarbij de datum van het betreffende mailbox-bestand wel wijzigt en er toch geen enkel mailtje binnenkomt of dat er niet ingelogd kan worden.

ninjazx9r98 schreef op vrijdag 11 januari 2008 @ 23:40:
Over incorrect gesproken.
Volgens mij zie je twee zaken over het hoofd.
1) Wie is de eigenaar van de email, cq aan wie is het gericht.
2) De betekenis van wederrechtelijk.
Als de gegevens niet voor jou bestemd zijn, maw email gericht aan de klant is het gewoon wederrechtelijk als je die mailbox opent.

Leer eerst eens onderscheid te maken tussen een mailbox en de inhoud van e-mail en dan kunnen we verder praten. Verder heeft het door jou aangedragen stuk telecomwet in zijn geheel slechts met aftappen, overnemen, etc te maken. Wat wel en niet wederrechtelijk in dat op zicht is doet er niet toe als het niet over aftappen, overnemen, etc gaat.

ninjazx9r98 schreef op vrijdag 11 januari 2008 @ 23:40:
Er is ook nog een wet op de computer criminaliteit...

En er is ook nog een wegenverkeerswet. Punt is dat je de telecomwet als argument gebruikt terwijl die in dit geval kant nog wal raakt.

ninjazx9r98 schreef op vrijdag 11 januari 2008 @ 23:40:
Ik zou zeggen ga eens wat lezen op http://www.iusmentis.com/
Misschien steek je er nog wat van op.

Grappig, laat ik daar nou net de oprichter van kennen en niet alleen van naam. Kennen wij elkaar dat je daar naar refereert? Of lees je die website alleen maar?

ninjazx9r98 schreef op vrijdag 11 januari 2008 @ 23:40:
Als je zo prat gaat op je eigen zogenaamde kennis van het lezen van juridische teksten zou het je sieren om aan te geven op basis van welke ervaring en scholing je dat zelf doet voor je dat van een ander verlangt.

Jij haalt er wetsteksten bij, dan mag ik verwachtten dat je ze op zijn minst goed kunt lezen. Dat blijkt duidelijk niet het geval, want de artikelen die je erbij haalt hebben met het voorbeeld van de TS niets van doen.

ninjazx9r98 schreef op vrijdag 11 januari 2008 @ 23:40:
En in een professionele omgeving kijken mensen in mailboxen maar in een hobby bob omgeving heeft men tooling ?

Blijf bij het voorbeeld in de TS. Het ging over het inloggen op mailbox, nergens blijkt dat die persoon ook maar een enkele mailheader of mailbody gezien heeft.

ninjazx9r98 schreef op vrijdag 11 januari 2008 @ 23:40:
Op een fatsoenlijk beheerd systeem geeft dat gewoon aan wat het laatste tijdstip is waarop mail is toegevoegd aan die file.

Een correct werkend systeem geeft gewoon het laatste tijdstip aan waarop er iets is gewijzigd aan dat bestand. Of dat betekent dat er iets is toegevoegd hoeft dus niet. Als de gebruiker inlogt en een mailtje uit zijn inbox verwijderd wordt het bestand gewijzigd, maar wil dat nog niet zeggen dat er ook mail bezorgd kan worden.

ninjazx9r98 schreef op zaterdag 12 januari 2008 @ 00:15:
Niemand is verbaasd dat Google een seconde na een muisklik met vele duizenden resultaten komt voor een willekeurige zoekactie maar lokaal binnn het eigen netwerk op zoek gaan naar een beetje data is ineens weer 'rocket science'.

ninjazx9r98 schreef op zaterdag 12 januari 2008 @ 10:22:
Het principe is dat het mogelijk is om redelijke tot hele grote hoeveelheden aan data binnen een zeer korte tijd te doorzoeken en tot nu toe doe jij net of dat heel ingewikkeld is.

Het grote verschil is dat Google zoekt in een database die voorzien is van een index. Die index wordt echt niet ter plekke gegenereerd, maar tijdens het crawlen. Kortom, dat is echt andere koek dan het ter plekke doorzoeken van een logfile en verwachtten dat het even snel gaat.

Voor de duidelijkheid een 'fictief' voorbeeldje.
- 30GB logfiles per dag
- Een schijfsysteem dat 500MB data per seconde in kan lezen. (Is geen kattepis)
- Een enkele niet niet-concurrente zoekactie duurt dan minimaal 60 seconden.

En dan hebben we eventjes niet gekeken naar het feit dat er meerdere concurrente zoekacties zullen lopen. Ook kan ik je vertellen dat een minuut moeten wachtten op het antwoord of inloggen op een mailbox mogelijk is, niet acceptabel is.

ninjazx9r98 schreef op zaterdag 12 januari 2008 @ 00:15:
Simpele feit is gewoon dat logfiles precies doen wat de naam al zegt, loggen.
En dat loggen is bedoelt om diagnoses te stellen.

Logbestanden zijn bedoelt om het mogelijk te maken dat er teruggezocht kan worden wat er gebeurt is. Logbestanden zijn daarmee nog niet per definitie geschikt om vast te stellen of iets op dit moment werkt of niet.

ninjazx9r98 schreef op zaterdag 12 januari 2008 @ 00:15:
Dan zeg je tegen de klant dat je op de server kan zien dat er weldegelijk mail binnen komt en noem je datum en tijdstip waarop die bewuste mailfile voor het laatst aangepast is.

En daarmee trek je de wijzigingsdatum van het mailbox bestand gelijk aan de datum waarop er voor het laatste e-mail is binnengekomen en dat is botweg onjuist. Als iemand een mailtje verwijderd uit diezelfde mailbox veranderd de datum ook en weet je nog steeds niet of er e-mail binnenkomt of niet.

ninjazx9r98 schreef op zaterdag 12 januari 2008 @ 00:15:
Vervolgens geef je aan dat je op het systeem kan zien op welk tijdstip men heeft geprobeerd om in te loggen en wat er toen gebeurde.

En als er na het inloggen iets mis gaat en de klant krijgt geen e-mail binnen dan werkt het nog steeds niet. En ja er zijn meerdere dingen die mis kunnen gaan tussen het inloggen op een mailbox en het verschijnen van e-mail in een programma als Outlook Express. En al die zaken kun jij vrolijk niet afleiden uit de datum van het mailbox bestand en of inloggen gelukt is.

Om je een enkel voorbeeldje te geven.
- Wist jij dat Outlook Express over zijn nek gaat van bepaalde strings in de subject header?
- Wist jij dat dit dezelfde foutmelding oplevert aan de gebruikerskant als een willekeurige andere timeout.
- Wist jij dat je om een dergelijk mailtje te herkennen (en ja er zijn zelfs spam-rondes mee geweest) je echt naar de mailheaders moet kijken.

Quacka schreef op zaterdag 12 januari 2008 @ 00:18:
Wat is in het algemeen het nut van het openen van mailboxes door helpdeskmedewerkers?

Men zou bij providers tools moeten hebben om bepaalde zaken te kunnen testen, zonder dat er noodzaak is om echt de mailbox te kunnen bezoeken.

Ware het niet dat er legio mogelijkheden zijn waarbij je iets alleen kunt testen door de praktijk uit te proberen.
Zie bovenstaande voorbeeld.

Gomez12 schreef op zaterdag 12 januari 2008 @ 02:05:
Het gaat hier om een 1e lijns procedure, te lang niet in de helpdesk sector gewerkt, maar je zou toch een klant kunnen terugbellen ter verificatie?

Terug bellen bij een klant die geen telefoonlijn heeft? (Er bestaan dedicated lijnen)
Terug bellen bij een klant die vrijwel nooit thuis is? (En dan komt het vaak ook nog niet uit.)

Gomez12 schreef op zaterdag 12 januari 2008 @ 02:05:en als het per email binnenkomt heb je per definitie al niets in de klant zijn emailbox te zoeken, want dan werkt die...

Dat hoeft dus echt niet waar te zijn. Als de klant wel nog kan versturen via zijn e-mailprogramma (SMTP) dan hoeft zijn mailbox nog niet te werken.

ninjazx9r98 schreef op zaterdag 12 januari 2008 @ 10:22:
De kans dat dit daadwerkelijk aan de hand is is dusdanig klein dat je dit gewoon spijkers op laag water zoeken kunt noemen.

En daar heb je het dus mis. De kans dat er iets anders met de mailbox aan de hand is dan gewoon een probleem met het mailbox klopt gewoon niet. Al was het maar omdat er zaken zijn als forward-loops, spamfilters, etc. Tot slot wil ik je er op wijzen dat mailboxen niet persé POP3 zijn en dat een deel van de problemen niet eens in de normale maillog voorbij zal komen. Misschien vind je dat een aantal mensen hier te moeilijk denken over een mailserver. Maar jij denkt te makkelijk aan een standaard-install POP3-server. Het feit dat je het over een enkele server hebt betekent als dat je er naast zit. Providers met een enkele mailserver voor inkomende mail hebben geen honderdduizenden klanten of in ieder geval niet lang.

ninjazx9r98 schreef op zaterdag 12 januari 2008 @ 10:22:
Is het dan werkelijk zo'n vreemd idee dat een systeemBEHEERDER weet in welke logfiles welke informatie te vinden is ??

We hadden het over een helpdeskmedewerker, waarschijnlijk zelfs eerste lijn. Dat is iemand die 0,0 opleiding aangaande *nix-systemen gehad zal hebben aangezien de helft uitzendkracht zal zijn en de andere helft student in een willekeurig niet-aanverwante studie. Dat is niet het soort mensen dat je even een prompt wilt gaan geven op een machine met de verwachting dat ze er mee over weg kunnen laat staan dat je zo iemand met een week of twee training zover kunt krijgen dat hij/zij log-files zal kunnen lezen. Jij denkt duidelijk te simpel over de binnenkant van een helpdesk.

ninjazx9r98 schreef op zaterdag 12 januari 2008 @ 10:22:
En natuurlijk is er helemaal nergens een of ander monitoring systeem wat dat in de gaten krijgt en aan beheer plus helpdesk doorgeeft dat er stront aan de knikker is en dat eea tijdelijk niet in de lucht is.

Beheertools geven door aan beheerders. Je kunt van standaard helpdesk personeel niet verwachten dat ze 123 in kunnen schatten wat het effect is van het uitvallen van de verbinding tussen servers X en Y. Nog afgezien van dat beheerders die dat wel in kunnen schatten op zondagochtend om 10:15 en masse aanwezig zullen zijn om het daar aan de helpdesk uit te leggen.

ninjazx9r98 schreef op zaterdag 12 januari 2008 @ 10:22:
Dan zeg je gewoon dat hij een uur geleden nog wel email kon ophalen en stel je de vraag of er in het laatste uur nog iets gebeurt is.
Mijn God zeg, is het allemaal dan werkelijk zo vreselijk moeilijk ?

En dan heb je de klant zijn/haar probleem dus niet opgelost en dat is dus niet acceptabel.

ninjazx9r98 schreef op zaterdag 12 januari 2008 @ 10:22:
Dat doe je omdat de mailbox plus inhoud van de klant is en derden daar in principe niets te zoeken hebben. Veel moeilijker dan dat is het niet.

Fout, de mailbox (software/hardware) is van de provider en wordt als dienst geleverd aan de klant. De inhoud van de mailbox valt onder te verdelen in mailheaders (buitenkant van de envelop) en mailbody (binnenkant van de envelop) waarbij die laatste inderdaad privé is.

Let wel we hebben het hier over een helpdeskmedewerker die inlogt op een mailbox. Er staat nergens gemeld dat hij de emailheaders doorneemt, laat staan dat hij de inhoud van berichten gaat zitten lezen. En als iemand zich zo druk maakt over inhoud van zijn e-mail dan zijn er altijd nog opties als PGP.

ninjazx9r98 schreef op zaterdag 12 januari 2008 @ 10:22:
Scripting en een professionele omgeving gaan uitstekend samen.

Scripting en eerste-lijns helpdeskmedewerkers gaat niet samen. Daar zul je echt meer moeten doen dan een paar scripts maken.

ninjazx9r98 schreef op zaterdag 12 januari 2008 @ 10:22:
Sterker nog, je zou kunnen zeggen dat professionele omgevingen waar niet gescript wordt niet bestaan.

Right, dus een omgeving waar geen enkele dag/handeling hetzelfde is en scripting dus volkomen bullshit is, is volgens jou dus niet professioneel.

ninjazx9r98 schreef op zaterdag 12 januari 2008 @ 10:30:
Pardon ???
Email die gericht is aan mijn persoon is niet prive ???

We hebben het over een wachtwoord dat afgesproken is tussen provider en klant, niet over de inhoud van een e-mailbericht. Verder was het voorbeeld om aan te geven dat er onderweg nog legio meer mogelijkheden zijn om de boel voorbij te zien komen.

ninjazx9r98 schreef op zaterdag 12 januari 2008 @ 10:30:
Met wie heb ik dan een wachtwoord afgesproken ??
Ik heb een wachtwoord ingegeven bij een geautomatiseerd systeem.
Nergens is er een of andere vorm van overleg geweest met een persoon waarbij we samen afspraken welk wachtwoord ik zou gaan gebruiken.

Alsof een automatisch systeem geen onderdeel is van diezelfde provider als die helpdeskmedewerker. Kortom, door dat wachtwoord in te voeren in dat automatische systeem (of andersom, je ontvangt een wachtwoordbrief), spreek je met die provider dat wachtwoord af. Die afspraak is tussen jou en die provider. Niet tussen jou en die computer.

ninjazx9r98 schreef op zaterdag 12 januari 2008 @ 10:30:
Jouw redenatie doortrekkend is zeker mijn pincode ook niet prive ?

Die pincode is inderdaad niet privé voor jou alleen. Het banksysteem zal die code ook moeten kennen anders werkt het niet. Dat een bank er voor kiest om die code ontoegankelijk te maken voor bankmedewerkers is in principe alleen maar wenselijk, maar het is niet de regel, laat staan de wet. Als tegenvoorbeeld kun je de expiry-datum op een creditcard gebruiken. Dat is een voorbeeld van een toegangscode die zo vaak rond gaat langs zoveel handen... En toch blijft dat de afgesproken code tussen twee partijen ter verificatie van een identiteit van een der partijen. Die informatie moet uiteraard ook bekend zijn bij de andere der partijen anders kun je er niet mee verificeren.

Tot slot vraag ik me af wat voor gebrek aan vertrouwen jij wel niet hebt richting personeel dat daar werkt. Alsof Pietje Puk ook maar enig belang heeft bij het doorsnuffelen van je mailbox. Die zit daar ook alleen maar omdat hij betaalt wordt om je te helpen. Dat hij denkt dat hij je een dienst doet, door te controleren of eea. inderdaad nog goed en naar behoren werkt, maakt alleen maar duidelijk dat hij een klant wil helpen.

En als je zo gebeten bent op de veiligheid van de informatie in de body van je e-mail dan moet je vooral je e-mail ophalen via SSL of SSH. Vooral ook de inhoud van het bericht versleutelen met PGP en als het even kan ook vooral je eigen mailserver in gaan richten en zelf daar het beheer over nemen.

[Steephh]

kalizec schreef op zaterdag 12 januari 2008 @ 12:59:
[...]

Omdat als je ook maar enig benul had van goed troubleshooten dan had je geweten dat je om iets te testen je het uit moet proberen. Neem maar eens een gemiddelde FAQ van Harde Waren door op troubleshooting. Je zult zien dat het allemaal uitproberen is. Er zijn legio voorbeelden mogelijk waarbij de datum van het betreffende mailbox-bestand wel wijzigt en er toch geen enkel mailtje binnenkomt of dat er niet ingelogd kan worden.

Testen kan ook op andere manieren dan de medewerker te laten inloggen en de mails te laten bekijken... Daar hoef je echt niet die medewerker alles handmatig te laten doen..

[...]


Leer eerst eens onderscheid te maken tussen een mailbox en de inhoud van e-mail en dan kunnen we verder praten. Verder heeft het door jou aangedragen stuk telecomwet in zijn geheel slechts met aftappen, overnemen, etc te maken. Wat wel en niet wederrechtelijk in dat op zicht is doet er niet toe als het niet over aftappen, overnemen, etc gaat.

De helpdeskers kunnen toch in de mail? Dat is het probleem. Dat is nergens voor nodig.. Als ze in de mail kunnen kunnen ze ook de inhoud lezen en dat is nergens voor nodig...

[...]

En er is ook nog een wegenverkeerswet. Punt is dat je de telecomwet als argument gebruikt terwijl die in dit geval kant nog wal raakt.

En jij gebruikt de wegenverkeerswet wat hier totaal NIETS maar dan ook NIETS mee te maken heeft.. Ik wil best een discussie voeren maar kom dan met zinnige en niet van die onzinnige argumenten aan..

[...]

Grappig, laat ik daar nou net de oprichter van kennen en niet alleen van naam. Kennen wij elkaar dat je daar naar refereert? Of lees je die website alleen maar?

Leuk dat je de oprichter kent. Wat een argument zeg.. Halleluja we geloven nu alles wat jij zegt.. Besef je nu eigenlijk wel dat je niet echt argumenten meer aan het aan voeren bent maar je geljik nu via een omweg probeert te behalen?

[...]

Jij haalt er wetsteksten bij, dan mag ik verwachtten dat je ze op zijn minst goed kunt lezen. Dat blijkt duidelijk niet het geval, want de artikelen die je erbij haalt hebben met het voorbeeld van de TS niets van doen.

Haal eens een voorbeeld erbij in van alleen maar te roepen.

[...]

Blijf bij het voorbeeld in de TS. Het ging over het inloggen op mailbox, nergens blijkt dat die persoon ook maar een enkele mailheader of mailbody gezien heeft.

Maar hef feit dat hij erin kan en dit zomaar doet zegt al genoeg. Als hij zomaar in logt op de mailbox zonder toestemming, wie zegt dan dat hij de mail ook niet daadwerkelijk leest?

[...]

Een correct werkend systeem geeft gewoon het laatste tijdstip aan waarop er iets is gewijzigd aan dat bestand. Of dat betekent dat er iets is toegevoegd hoeft dus niet. Als de gebruiker inlogt en een mailtje uit zijn inbox verwijderd wordt het bestand gewijzigd, maar wil dat nog niet zeggen dat er ook mail bezorgd kan worden.

Nu heb je het puur over de mailbox alleen.. Dus wie zegt dat het probleem dan nog bij de klant dan wel provider ligt? Misschien heeft de verzender zijn instellingen wel niet goed staan en daarna de klant opgebeld om te vragen of zijn mail is aangekomen..

[...]


[...]

Het grote verschil is dat Google zoekt in een database die voorzien is van een index. Die index wordt echt niet ter plekke gegenereerd, maar tijdens het crawlen. Kortom, dat is echt andere koek dan het ter plekke doorzoeken van een logfile en verwachtten dat het even snel gaat.

Voor de duidelijkheid een 'fictief' voorbeeldje.
- 30GB logfiles per dag
- Een schijfsysteem dat 500MB data per seconde in kan lezen. (Is geen kattepis)
- Een enkele niet niet-concurrente zoekactie duurt dan minimaal 60 seconden.

En dan hebben we eventjes niet gekeken naar het feit dat er meerdere concurrente zoekacties zullen lopen. Ook kan ik je vertellen dat een minuut moeten wachtten op het antwoord of inloggen op een mailbox mogelijk is, niet acceptabel is.

Je leest niet, je draaft door..

Wakeup call, het gaat om het principe !!
Het principe is dat het mogelijk is om redelijke tot hele grote hoeveelheden aan data binnen een zeer korte tijd te doorzoeken en tot nu toe doe jij net of dat heel ingewikkeld is.

Dan nog.. Zie jij 1 enkele gebruiker die een logfile van 30GB maakt? Ik niet hoor..

[...]

Logbestanden zijn bedoelt om het mogelijk te maken dat er teruggezocht kan worden wat er gebeurt is. Logbestanden zijn daarmee nog niet per definitie geschikt om vast te stellen of iets op dit moment werkt of niet.

Dat kan de klant toch? Als er intern iets fout gaat is dat altijd terug te vinden.. Tenzij er een ander probleem is met de servers maar dan is dat geen klant specifiek probleem maar van de provider zelf. Voor het controleren of iets werkt of niet is een interface te bouwen en nee dat kost geen miljoenen en duurt ook geen jaren om te maken. Verder huren ze daar ook geen Pietje voor in die dat maakt maar wordt dat uitbesteed.....

[...]

En daarmee trek je de wijzigingsdatum van het mailbox bestand gelijk aan de datum waarop er voor het laatste e-mail is binnengekomen en dat is botweg onjuist. Als iemand een mailtje verwijderd uit diezelfde mailbox veranderd de datum ook en weet je nog steeds niet of er e-mail binnenkomt of niet.

Hij kan wel iets wissen maar niets ontvangen.. Dan ligt het probleem al niet meer bij de klant en zal de helpdesker het ook niet meer op kunnen lossen.. Dan is er zeer waarschijnlijk een probleem waarvoor de hulp van de systeembeheerder zal moeten worden ingeroepen..

[...]

En als er na het inloggen iets mis gaat en de klant krijgt geen e-mail binnen dan werkt het nog steeds niet. En ja er zijn meerdere dingen die mis kunnen gaan tussen het inloggen op een mailbox en het verschijnen van e-mail in een programma als Outlook Express. En al die zaken kun jij vrolijk niet afleiden uit de datum van het mailbox bestand en of inloggen gelukt is.

Om je een enkel voorbeeldje te geven.
- Wist jij dat Outlook Express over zijn nek gaat van bepaalde strings in de subject header?
- Wist jij dat dit dezelfde foutmelding oplevert aan de gebruikerskant als een willekeurige andere timeout.
- Wist jij dat je om een dergelijk mailtje te herkennen (en ja er zijn zelfs spam-rondes mee geweest) je echt naar de mailheaders moet kijken.

Wist je dat je de klant ook zelf kan laten inloggen op de webmail? Ohnee.. niet aan gedacht...

[...]

Ware het niet dat er legio mogelijkheden zijn waarbij je iets alleen kunt testen door de praktijk uit te proberen.
Zie bovenstaande voorbeeld.

Dat kan de klant ook..

[...]


Terug bellen bij een klant die geen telefoonlijn heeft? (Er bestaan dedicated lijnen)
Terug bellen bij een klant die vrijwel nooit thuis is? (En dan komt het vaak ook nog niet uit.)


[...]


Dat hoeft dus echt niet waar te zijn. Als de klant wel nog kan versturen via zijn e-mailprogramma (SMTP) dan hoeft zijn mailbox nog niet te werken.

Denk je dan echt dat de klant verwacht dat het aankomt? En hoe moet hij dan die mail ontvangen.. Ik denk dat de meeste klanten dan wel zouden bellen..

[...]

En daar heb je het dus mis. De kans dat er iets anders met de mailbox aan de hand is dan gewoon een probleem met het mailbox klopt gewoon niet. Al was het maar omdat er zaken zijn als forward-loops, spamfilters, etc. Tot slot wil ik je er op wijzen dat mailboxen niet persé POP3 zijn en dat een deel van de problemen niet eens in de normale maillog voorbij zal komen. Misschien vind je dat een aantal mensen hier te moeilijk denken over een mailserver. Maar jij denkt te makkelijk aan een standaard-install POP3-server. Het feit dat je het over een enkele server hebt betekent als dat je er naast zit. Providers met een enkele mailserver voor inkomende mail hebben geen honderdduizenden klanten of in ieder geval niet lang.

Vind het knap dat jij op alle servers tegelijk inlogd... Je kan toch maar op 1 server tegelijkertijd inloggen, diegene die je waarschijnlijk wordt toegewezen door een server die aan loadbalancing doet.. En dat zal steeds dezelfde zijn, denk maar niet dat je mail over 20 servers verspreid is.. Laten we dan maar voortaan het woord 'serverpark' gebruiken.. De klant kan zelf toch in de webmail kijken als het nodig is.. Wat kan de helpdesker als hij erin kijkt? Ja hij ziet dat er mailtjes zijn, maar verder niets. Eventuele foutmeldingen zouden geregenereerd kunnen worden door een interface voor de helpdesker waar alleen eventuele foutmeldingen worden getoond en geen mailtjes zelf.. Dat vind ik persoonlijk nog dezelfde oplossing.

[...]

We hadden het over een helpdeskmedewerker, waarschijnlijk zelfs eerste lijn. Dat is iemand die 0,0 opleiding aangaande *nix-systemen gehad zal hebben aangezien de helft uitzendkracht zal zijn en de andere helft student in een willekeurig niet-aanverwante studie. Dat is niet het soort mensen dat je even een prompt wilt gaan geven op een machine met de verwachting dat ze er mee over weg kunnen laat staan dat je zo iemand met een week of twee training zover kunt krijgen dat hij/zij log-files zal kunnen lezen. Jij denkt duidelijk te simpel over de binnenkant van een helpdesk.

En jij denkt dat ze door op de (web)mail in te kunnen loggen METEEN (want een minuut duurde te lang) kunnen zien wat het probleem is.. Als het probleem werkelijk zo diepliggend is kan de helpdesker er toch niets mee en zal hij een systeembeheerder aan zijn jas moeten trekken.

[...]


Beheertools geven door aan beheerders. Je kunt van standaard helpdesk personeel niet verwachten dat ze 123 in kunnen schatten wat het effect is van het uitvallen van de verbinding tussen servers X en Y. Nog afgezien van dat beheerders die dat wel in kunnen schatten op zondagochtend om 10:15 en masse aanwezig zullen zijn om het daar aan de helpdesk uit te leggen.

Wat al eerder gezegd is dat je te moeilijk denkt.. Stel server 1 en 8 liggen uit de lucht.. Het systeembeheer meldt aan de helpdesk dat ze denken dat het rond 15 uur is opgelost en een klant belt die niet kan inloggen en ook niet op de webmail dan kan de helpdesker mededelen aan de klant dat de servers er naar verwachting helaas tot 15 uur uitliggen. En een interface bouwen die automatisch controleerd of er nog ingelogd kan worden is echt niet zo moeilijk te bouwen...

[...]

En dan heb je de klant zijn/haar probleem dus niet opgelost en dat is dus niet acceptabel.

Dat heb je ook niet door te zeggen 'ja.. hier werkt ie wel hoor.. je hebt mail van jan en ook van henk.. owja en ook nog van tatjana.. die heb je gisteren binnen gekregen om 23 uur...'. Dan denkt de klant 'wtf' en is zijn probleem nog niet opgelost...

[...]


Fout, de mailbox (software/hardware) is van de provider en wordt als dienst geleverd aan de klant. De inhoud van de mailbox valt onder te verdelen in mailheaders (buitenkant van de envelop) en mailbody (binnenkant van de envelop) waarbij die laatste inderdaad privé is.

Let wel we hebben het hier over een helpdeskmedewerker die inlogt op een mailbox. Er staat nergens gemeld dat hij de emailheaders doorneemt, laat staan dat hij de inhoud van berichten gaat zitten lezen. En als iemand zich zo druk maakt over inhoud van zijn e-mail dan zijn er altijd nog opties als PGP.


[...]

Scripting en eerste-lijns helpdeskmedewerkers gaat niet samen. Daar zul je echt meer moeten doen dan een paar scripts maken.

Wie heeft er gezegd dat de helpdeskers deze maken? .. Er worden scripts gebouwd waarvan de helpdeskers vervolgens gebruik maken..

[...]

Right, dus een omgeving waar geen enkele dag/handeling hetzelfde is en scripting dus volkomen bullshit is, is volgens jou dus niet professioneel.

Dat zegt hij niet.. Hij zegt alleen dat die vrijwel niet bestaan.. LEZEN!!!

[...]

We hebben het over een wachtwoord dat afgesproken is tussen provider en klant, niet over de inhoud van een e-mailbericht. Verder was het voorbeeld om aan te geven dat er onderweg nog legio meer mogelijkheden zijn om de boel voorbij te zien komen.

Het wachtwoord is niet afgesproken maar toegewezen. Als de klant daarna zijn wachtwoord wijzigd in een makkelijker te onthouden wachtwoord wat hij op meerdere plekken gebruikt.. Dan heeft een helpdeskmedewerker hier inderdaad niets meer mee te maken.

[...]

Alsof een automatisch systeem geen onderdeel is van diezelfde provider als die helpdeskmedewerker. Kortom, door dat wachtwoord in te voeren in dat automatische systeem (of andersom, je ontvangt een wachtwoordbrief), spreek je met die provider dat wachtwoord af. Die afspraak is tussen jou en die provider. Niet tussen jou en die computer.

En wat heeft die helpdeskmedewerker hier vervolgens mee te maken? Waarvoor heeft hij het daadwerkelijk nodig? Nergens voor en waarom zou hij daadwerkelijk met een wachtwoord moeten inloggen als er scripts voor worden geschreven, desnoods geimplementeerd op een intranet die controleren of mailboxen oid nog werken.. Dat automatisch systeem heeft inderdaad niets met die helpdeskmedewerker te maken..

[...]

Die pincode is inderdaad niet privé voor jou alleen. Het banksysteem zal die code ook moeten kennen anders werkt het niet. Dat een bank er voor kiest om die code ontoegankelijk te maken voor bankmedewerkers is in principe alleen maar wenselijk, maar het is niet de regel, laat staan de wet. Als tegenvoorbeeld kun je de expiry-datum op een creditcard gebruiken. Dat is een voorbeeld van een toegangscode die zo vaak rond gaat langs zoveel handen... En toch blijft dat de afgesproken code tussen twee partijen ter verificatie van een identiteit van een der partijen. Die informatie moet uiteraard ook bekend zijn bij de andere der partijen anders kun je er niet mee verificeren.

Nu zeg je het zelf. Het banksysteem moet het kennen.. En het is gecodeerd, niet zonder reden. Maar de medewerker heeft het nergens voor nodig. Als er iets mis is met je pinpas, gaat de bankmedewerkster dan ook vragen 'mag ik uw pincode even?'? Natuurlijk niet, als een pas getest zou moeten worden (wat overigens volgens mij niet gebeurd) dan heeft men daar een systeem voor ontworpen.. En ik denk persoonlijk dat die systemen wel iets duurder zijn dan een interface voor de helpdeskmedewerker.

Tot slot vraag ik me af wat voor gebrek aan vertrouwen jij wel niet hebt richting personeel dat daar werkt. Alsof Pietje Puk ook maar enig belang heeft bij het doorsnuffelen van je mailbox. Die zit daar ook alleen maar omdat hij betaalt wordt om je te helpen. Dat hij denkt dat hij je een dienst doet, door te controleren of eea. inderdaad nog goed en naar behoren werkt, maakt alleen maar duidelijk dat hij een klant wil helpen.

Misschien heeft hij een slechte dag.. Het is geen robot die dag in dag uit zin heeft om iemand te helpen. En inderdaad, ik vertrouw niet alle helpdeskmedewerkers.. Als het een interne helpdesk van de provider is zou het nog anders liggen maar dan nog steeds, niemand hoeft mijn mail te lezen en niemand mijn wachtwoord te bekijken. Mensen zijn nieuwschierige wezens en als ik iemand persoonlijk ken zou het anders liggen. Maar goed, voor wat ik wil doen heb ik genoeg kennis van zaken dus dat is niet nodig.

En als je zo gebeten bent op de veiligheid van de informatie in de body van je e-mail dan moet je vooral je e-mail ophalen via SSL of SSH. Vooral ook de inhoud van het bericht versleutelen met PGP en als het even kan ook vooral je eigen mailserver in gaan richten en zelf daar het beheer over nemen.

Dus een klant die op privacy gesteld is maar geen verstand heeft van van SSL/SSH/PGP moet vervolgens maar zijn eigen mailserver opzetten?

[alt-92]

Quacka schreef op zaterdag 12 januari 2008 @ 00:18:
Wat is in het algemeen het nut van het openen van mailboxes door helpdeskmedewerkers?

Om die klant die de helpdesk belt te kunnen helpen? Er is een reden dat die klant belt namelijk.

Wanneer je als helpdeskmedewerker de mailbox nodig hebt om een loginnaam te controleren, dan heeft de provider zijn systemen niet op orde.

Er is nergens gezegd dat dat gebeurt.

[... password reset...]
Een alternatief kan zijn om het wachtwoord telefonisch te resetten, waarna er automatisch een mail wordt gestuurd met daarin een link naar een pagina waar de klant heel makkelijk zijn wachtwoord weer kan resetten. Zo moeilijk is dit niet, volgens mij.

Een mail naar de mailbox waar die klant nou net niet in kan, de reden waarvoor hij/zij belt?

Er zijn trouwens genoeg selfhelp systemen waar $klant online zijn password kan veranderen - tenzij $klant ook dat password niet weet, dan kom je ook niet verder.

Wat ik dus wil zeggen is dat providers hun systemen best kunnen aanpassen zodat privacy wel beschermd wordt, maar helpdeskmedewerkers toch snel klanten kunnen helpen. Providers dienen alleen dan wel hun systemen te wijzigen en moeten zorgen voor voldoende tools voor hun medewerkers.

Daar zit een kostenplaatje aan vast, wat doorberekend gaat worden naar $klant.

Of diegenen die het zo goed weten hier maken dat gratis beschikbaar voor elke ISP - en ook geschikt voor alle verschillende ISP systemen, en ook nog eens zodanig dat elke eventualiteit ermee ondervangen kan worden.
Natuurlijk betekent dat dat de standaard Challenge response password systemen dan ook dusdanig omgebouwd dienen te worden dat die tooling dat transparant kan gebruiken (want passwords tonen mag niet).

Misschien een leuk OSS projectje?

Ik hoop dat tweakers.net dit probleem eens aan de aandacht wil brengen via een nieuwsbericht. Het is blijkbaar nodig. Nodig om de privacy van nederlanders te verbeteren.

De gemiddelde nederlander interesseert dat niet - die wil gewoon binnen 5 minuten dat probleem met z'n niet werkende mail opgelost hebben.

[ninjazx9r98]

kalizec schreef op zaterdag 12 januari 2008 @ 12:59:
[...]

Omdat als je ook maar enig benul had van goed troubleshooten dan had je geweten dat je om iets te testen je het uit moet proberen. Neem maar eens een gemiddelde FAQ van Harde Waren door op troubleshooting. Je zult zien dat het allemaal uitproberen is. Er zijn legio voorbeelden mogelijk waarbij de datum van het betreffende mailbox-bestand wel wijzigt en er toch geen enkel mailtje binnenkomt of dat er niet ingelogd kan worden.

Legio voorbeelden zoals ??
De klant gooit mail weg, de datum wijzigt.
Conclusie : de klant kan inloggen dus dat deel werkt.
Nu nog wat andere voorbeelden ?

Dat er niet ingelogd kan worden staat in de logfiles.
Of er daadwerkelijk mail binnenkomt op een adres staat in de logfiles.

Over benul van troubleshooten gesproken.

[...]

Leer eerst eens onderscheid te maken tussen een mailbox en de inhoud van e-mail en dan kunnen we verder praten. Verder heeft het door jou aangedragen stuk telecomwet in zijn geheel slechts met aftappen, overnemen, etc te maken. Wat wel en niet wederrechtelijk in dat op zicht is doet er niet toe als het niet over aftappen, overnemen, etc gaat.

En het verschil tussen de mailbox en de inhoud is ?
Simpel uitgaande van een Unix achtig systeem is de mailbox en de inhoud in feite hetzelfde.
Een plat stuk tekst.
Veel moeilijker is het echt niet.
Op het moment dat je een mailbox bekijkt wordt er data overgenomen naar jouw systeem.
Wederrechtelijk is hier dus gewoon aan de orde.

[...]

En er is ook nog een wegenverkeerswet. Punt is dat je de telecomwet als argument gebruikt terwijl die in dit geval kant nog wal raakt.

Dat is jouw mening en niet meer dan dat.

[...]

Grappig, laat ik daar nou net de oprichter van kennen en niet alleen van naam. Kennen wij elkaar dat je daar naar refereert? Of lees je die website alleen maar?

Grappig, als je iemand kent dan staat dat gelijk aan kennis van een bepaald niveau/onderwerp ?
Maar goed, als je die persoon kent is het misschien eens tijd om een gesprekje aan te knopen over dit onderwerp en hem onder de neus te wrijven dat hij geen wetteksten kan lezen.
Zijn interpretatie op de website strookt namelijk totaal niet met die van jou.
http://www.iusmentis.com/maatschappij/juridisch/briefgeheim/
Op grond van de Wet Computercriminaliteit is schending van deze geheimhouding door medewerkers van een ISP strafbaar gesteld. Er staat een jaar cel op het opzettelijk en wederrechtelijk met een technisch hulpmiddel aftappen of opnemen van gegevens uit een telecommunicatiewerk of computer, als die gegevens niet voor de tapper bestemd zijn (art. 139c Wetboek van Strafrecht).

Verderop, in artikel 273d, wordt nog eens expliciet vastgelegd dat een medewerker van een telecombedrijf (inclusief Internet-providers) die opzettelijk en wederrechtelijk van gegevens kennisneemt van klanten, daarvoor maximaal anderhalf jaar cel kan krijgen. Dit geldt ook voor niet-openbare netwerken zoals bedrijfsnetwerken. En wie "opzettelijk toelaat" dat dit gebeurt, kan dezelfde maximumstraf krijgen.
Laat je het even weten als je de schrijver hebt uitgelegd dat hij geen wetteksten kan lezen ?

[...]

Jij haalt er wetsteksten bij, dan mag ik verwachtten dat je ze op zijn minst goed kunt lezen. Dat blijkt duidelijk niet het geval, want de artikelen die je erbij haalt hebben met het voorbeeld van de TS niets van doen.

Vooralsnog kom je niet veel verder dan roepen dat je de schrijver van een website kent.
Een website die overigens zaken aangeeft die lijnrecht tegenover jouw interpretatie staan.

[...]

Blijf bij het voorbeeld in de TS. Het ging over het inloggen op mailbox, nergens blijkt dat die persoon ook maar een enkele mailheader of mailbody gezien heeft.

Ben heel benieuwd wat jij dan wel verstaat onder inloggen op een mailbox.
En als die persoon geen header of body heeft gezien wat is dan de meerwaarde van dat inloggen ?
Aantonen dat er uberhaupt al ingelogd kan worden ?
Dat kan ook al vrij eenvoudig worden aangetoond met behulp van logfiles.

[...]

Een correct werkend systeem geeft gewoon het laatste tijdstip aan waarop er iets is gewijzigd aan dat bestand. Of dat betekent dat er iets is toegevoegd hoeft dus niet. Als de gebruiker inlogt en een mailtje uit zijn inbox verwijderd wordt het bestand gewijzigd, maar wil dat nog niet zeggen dat er ook mail bezorgd kan worden.

En jij roept iets over het begrijpen van troubleshooten ?
Als je gaat troubleshooten verzamel je relevantie informatie die je op weg helpt.
Me dunkt dat het wel of niet kunnen inloggen relevantie informatie is.

[...]

Het grote verschil is dat Google zoekt in een database die voorzien is van een index. Die index wordt echt niet ter plekke gegenereerd, maar tijdens het crawlen. Kortom, dat is echt andere koek dan het ter plekke doorzoeken van een logfile en verwachtten dat het even snel gaat.

Lees je uberhaupt wel wat iemand schrijft of neem je altijd alles letterlijk als dat beter in je straatje past ?
Het gaat om het PRINCIPE !!
Naast Google zijn er vele vele andere voorbeelden te verzinnen van enorme bakken met gegevens waar je binnen zeer korte tijd informatie uit kunt halen.

Voor de duidelijkheid een 'fictief' voorbeeldje.
- 30GB logfiles per dag
- Een schijfsysteem dat 500MB data per seconde in kan lezen. (Is geen kattepis)
- Een enkele niet niet-concurrente zoekactie duurt dan minimaal 60 seconden.

30GB logfiles per dag ?
Is dat nog op enige realiteit gebaseerd of kwam dat gewoon mooi uit in je rekenvoorbeeld ?
Maar goed, stel dat het echt 30GB per dag is dan roteer je gewoon de logfile eens in de X uur zodat je beter en sneller verwerkbare files over houdt.
Vervolgens vraag je aan de klant of men ongeveer weet wanneer het probleem zich voordeed en kun je tijdsafhankelijk zoeken in de juiste logfile.

En dan hebben we eventjes niet gekeken naar het feit dat er meerdere concurrente zoekacties zullen lopen. Ook kan ik je vertellen dat een minuut moeten wachtten op het antwoord of inloggen op een mailbox mogelijk is, niet acceptabel is.

En er lopen meerdere concurrente zoekacties omdat ?
Omdat de helpdesk de godganse dag bezig is met alleen maar klanten die hun mailproblemen hebben ?

[...]

Logbestanden zijn bedoelt om het mogelijk te maken dat er teruggezocht kan worden wat er gebeurt is. Logbestanden zijn daarmee nog niet per definitie geschikt om vast te stellen of iets op dit moment werkt of niet.

Logbestanden kunnen daar uitermate geschikt voor zijn.
Een tail -f op een logfile kan zeer verhelderend zijn.
Ligt alleen aan de situatie.

[...]

En daarmee trek je de wijzigingsdatum van het mailbox bestand gelijk aan de datum waarop er voor het laatste e-mail is binnengekomen en dat is botweg onjuist. Als iemand een mailtje verwijderd uit diezelfde mailbox veranderd de datum ook en weet je nog steeds niet of er e-mail binnenkomt of niet.

Nogmaals, je weet dan dat de klant toegang heeft tot zijn/haar mailbox wat relevantie informatie is of kan zijn.
Daarnaast geeft een logfile keurig info over binnenkomende mail en hoef je je dus echt niet alleen op de datum van die mailbox te richten.
Hoe zat het ook alweer met troubleshooten ?

[...]

Ware het niet dat er legio mogelijkheden zijn waarbij je iets alleen kunt testen door de praktijk uit te proberen.
Zie bovenstaande voorbeeld.

Je voorbeeld raakt kan noch wal.
De zaken die ik aangeef moet je zien als eerste hulpmiddel om snel een diagnose te stellen.
Als dat vervolgens niet toereikend is heb je meer tooling nodig of escaleert de 1e lijns helpdeskmedewerker naar de volgende lijn.
Helpdesken hebben niet voor niets meerdere lijnen.

[...]

En daar heb je het dus mis. De kans dat er iets anders met de mailbox aan de hand is dan gewoon een probleem met het mailbox klopt gewoon niet. Al was het maar omdat er zaken zijn als forward-loops, spamfilters, etc. Tot slot wil ik je er op wijzen dat mailboxen niet persé POP3 zijn en dat een deel van de problemen niet eens in de normale maillog voorbij zal komen. Misschien vind je dat een aantal mensen hier te moeilijk denken over een mailserver. Maar jij denkt te makkelijk aan een standaard-install POP3-server. Het feit dat je het over een enkele server hebt betekent als dat je er naast zit. Providers met een enkele mailserver voor inkomende mail hebben geen honderdduizenden klanten of in ieder geval niet lang.

Wat ik aangeef is een voorbeeld om het principe te verduidelijken.
Niets meer niets minder.
Nergens heb ik aangegeven dat er alleen maar POP3 mailboxen zouden bestaan net zo goed als ik nergens heb aangegeven dat ik slechts aan een enkele server denk.
Het principe verandert namelijk niet radicaal als er geen POP3 is en/of als er meerdere mailservers zijn.
Ook als je meerdere servers hebt heb je nog steeds logging op servers.
Wel grappig overigens je redenatie.
De klant stelt een enkele smtp en pop server in voor z'n account en krijgt gewoon zijn/har mail omdat die meerdere mailservers nu eenmaal transparant en je als klant niet op zoek hoeft naar het systeem met jouw mail.
Maar owee als de systeembeheerder iets wil weten dan ineens is het een groot probleem dat er meerdere mailservers zijn en kun je ineens van alles niet meer opzoeken.

[...]

We hadden het over een helpdeskmedewerker, waarschijnlijk zelfs eerste lijn. Dat is iemand die 0,0 opleiding aangaande *nix-systemen gehad zal hebben aangezien de helft uitzendkracht zal zijn en de andere helft student in een willekeurig niet-aanverwante studie. Dat is niet het soort mensen dat je even een prompt wilt gaan geven op een machine met de verwachting dat ze er mee over weg kunnen laat staan dat je zo iemand met een week of twee training zover kunt krijgen dat hij/zij log-files zal kunnen lezen. Jij denkt duidelijk te simpel over de binnenkant van een helpdesk.

Wie zegt dat ik mensen een prompt wil geven ?
Ben heel benieuwd naar de quote waarin je mij dat hebt zien zeggen.
Ik heb het gehad over tooling die bepaalde commando's op bepaalde logfiles uitvoert zodat de helpdeskmedewerker hapklare brokken voorgeschoteld krijgt.
Ik zou zeggen, kom maar op die quote.

[...]

Beheertools geven door aan beheerders. Je kunt van standaard helpdesk personeel niet verwachten dat ze 123 in kunnen schatten wat het effect is van het uitvallen van de verbinding tussen servers X en Y. Nog afgezien van dat beheerders die dat wel in kunnen schatten op zondagochtend om 10:15 en masse aanwezig zullen zijn om het daar aan de helpdesk uit te leggen.

Dat is een kwestie van informatie op de juiste manier aan de juiste personen doorgeven.
Je maakt mij niet wijs dat als er ergens het een en ander plat ligt wat directe invloed heeft op de klanten die op dat moment op internet bezig zijn dat je de helpdesk niet voorziet van informatie.
Normaal gesproken zal dus een beheerder informatie krijgen van een of andere tool en zal die informatie in een aangepaste vorm bij de helpdesk komen zodat men dit kan door geven aan bellende klanten en eventueel komt het nog op een storingspagina als men die heeft.

[...]

En dan heb je de klant zijn/haar probleem dus niet opgelost en dat is dus niet acceptabel.

Maar als die 1e lijns helpdeskmedewerker inlogt op die mailbox is het probleem meteen opgelost ?

[...]

Scripting en eerste-lijns helpdeskmedewerkers gaat niet samen. Daar zul je echt meer moeten doen dan een paar scripts maken.

Heb je ook nog argumenten waarom dat niet zo gaan ?
Een webbased interface is prima in staat om op de achtergrond een script af te trappen en de persoon achter de browser van informatie gezien.
Ik blijf erbij, het is allemaal geen rocket science.

[...]

Right, dus een omgeving waar geen enkele dag/handeling hetzelfde is en scripting dus volkomen bullshit is, is volgens jou dus niet professioneel.

Noem mij een omgeving waar helemaal niets elke dag hetzelfde is.
Iedere omgeving heeft een aantal zaken die je uit beheersoogpunt gezien zou willen/moeten monitoren.
Scripting is uitermate geschikt om die zaken te verzamelen zodat je eens in de X uur netjes hapklare brokken krijgt.

[...]

We hebben het over een wachtwoord dat afgesproken is tussen provider en klant, niet over de inhoud van een e-mailbericht. Verder was het voorbeeld om aan te geven dat er onderweg nog legio meer mogelijkheden zijn om de boel voorbij te zien komen.

Nogmaals, met WIE spreek ik dan een wachtwoord af en wie is de provider in dit verhaal ?
Normaal gesproken kies ik een wachtwoord, klop dat ergens in en het wordt geautomatiseerd opgeslagen.
Dat noem ik geen afspraak.

[...]

Alsof een automatisch systeem geen onderdeel is van diezelfde provider als die helpdeskmedewerker. Kortom, door dat wachtwoord in te voeren in dat automatische systeem (of andersom, je ontvangt een wachtwoordbrief), spreek je met die provider dat wachtwoord af. Die afspraak is tussen jou en die provider. Niet tussen jou en die computer.

Dan denken we daar dus fundamenteel anders over.

[...]

Tot slot vraag ik me af wat voor gebrek aan vertrouwen jij wel niet hebt richting personeel dat daar werkt. Alsof Pietje Puk ook maar enig belang heeft bij het doorsnuffelen van je mailbox. Die zit daar ook alleen maar omdat hij betaalt wordt om je te helpen. Dat hij denkt dat hij je een dienst doet, door te controleren of eea. inderdaad nog goed en naar behoren werkt, maakt alleen maar duidelijk dat hij een klant wil helpen.

Eerder in de thread kwam al naar voren dat iemand ergens werkte waar het standaard was om mail van BNers door te lezen.
Ook zijn er zat sites op het internet waar men dolgraag allerlei privezaken van mensen openbaar maakt omdat dat kennelijk zo leuk is.
Voor mij is het dus gewoon een principe kwestie.
Het is een mailbox waar mail binnenkomt geadresseerd aan mijn persoon en niet aan iemand anders.
De mail is dus bestemd voor mijn ogen en niet die van anderen ongeacht of men nu wel of niet belang heeft bij het doorsnuffelen heeft men daar NIETS maar dan ook helemaal NIETS te zoeken.

En als je zo gebeten bent op de veiligheid van de informatie in de body van je e-mail dan moet je vooral je e-mail ophalen via SSL of SSH. Vooral ook de inhoud van het bericht versleutelen met PGP en als het even kan ook vooral je eigen mailserver in gaan richten en zelf daar het beheer over nemen.

Die eigen mailserver staat hier maar dat doet niets af aan het principe en het is en blijft een zwaktebod om je er op deze manier vanaf te maken.

[andreas2005]

Het lijkt mij dat de gemiddelde nederlander zelf mag beslissen of zijn privacy nog iets waard is. Dat hoeft hier niet voor hem beslist te worden. Daarom is dit volgens mij een nieuwswaardig feit, dat best geplaatst kan worden. Dan kan iedere Nederlander (en niet alleen de gemiddelde) zelf beslissen wat hij of zij er mee wil doen.
Een pincode lijkt mij in ieder geval het ultieme voorbeeld van een code die je geheim wilt houden, maar het is wat mij betreft schokkend dat dat al gebruikt moet worden om het recht op privacy te verdedigen. En zelfs dat is hier voor sommigen al niet meer duidelijk genoeg.
De discussie hier ontspoort behoorlijk. Eén: Tiscali geeft zelf in zijn voorwaarden aan dat medewerkers niet in de mail mogen kijken.
Twee: TS geeft aan dat een medewerker dat desondanks heeft gedaan.
Drie: Diverse posters melden dat er helpdesks zijn waar ze ook zonder wachtwoord van de klant kunnen werken, en zonder dat de klant boos wordt. Anders zou bv XS4ALL al niet meer bestaan.

Mijn conclusie is dat die hele discussie hier waar gezegd wordt dat het noodzakelijk is om te kunnen inloggen in de mailbox van de klant volkomen flauwekul is. Het is een typisch voorbeeeld van functionaliteit die, als je het aanbiedt, ook gebruikt wordt maar die niet nodig is om het werk te kunnen doen. Bij XS4ALl én multikabel lukt het zonder die mogelijkheid.

Omdat hier kennelijk de mening van iemand er alleen toe doet als je er professioneel mee te maken hebt, ik ben bussiness analist en ontwerp de processen waarmee onder andere het werk van helpdesks wordt ingericht. Dus ja, ik weet wel degelijk waar ik het over heb.

Zoals het bij Tiscali is ingericht, met plain text wachtwoorden die voor iedereen zijn in te zien, is helemaal geen goedkope oplossing. Het lijkt alleen maar goedkoop. Juist door in een ontwerp de slechte onderdelen weg te laten krijg je én meer veiligheid, én betere onderhoudbaarheid door een simpel ontwerp, én minder functionaliteit waar iedereen mee om moet gaan. Less is écht more bij een goed basisontwerp.

[we_are_borg]

Quacka schreef op zaterdag 12 januari 2008 @ 00:18:

[...]

Ik hoop dat tweakers.net dit probleem eens aan de aandacht wil brengen via een nieuwsbericht. Het is blijkbaar nodig. Nodig om de privacy van nederlanders te verbeteren.
En tweakers heeft een echt eigen nieuwsbericht. De meeste nieuwsberichten worden immers van andere sites over genomen / van persberichten overgenomen.

alt-92 schreef op zaterdag 12 januari 2008 @ 14:29

[...]


De gemiddelde nederlander interesseert dat niet - die wil gewoon binnen 5 minuten dat probleem met z'n niet werkende mail opgelost hebben.

Dus in de tijd dat privacy een zeer gevoelig onderwerp is en er veel geprotesteert wordt als er weer een stukje privacy ontnomen wordt is de gemiddelde Nederlander dus niet geintresseert in z'n onderwerp waar de privacy zo gemakkelijk opzij geschoven wordt.
Maar ik denk ook niet dat hier een gemiddelde Nederlander zomaar komt, Een nieuws topic kan zelfs een discussie starten die misschien wel eens wat op kan leveren.

Tuurlijk wil iedereen binnen 5 minuten geholpen worden en zijn probleem opgelost zijn maar dat kan nu niet altijd, een klant heeft ook de verantwoordelijkheid om zijn papieren goed te bewaren waarop informatie staat. Daarbij heb ik in een eerdere post al het volgende gezegt en ik qoute me zelf even

Hoe had die helpdeskmedewerker kunnen reageren als inloggen noodzakelijk geweest was. Meneer/Mevrouw ik vermoed dat er iets met uw email box aan de hand is. U kunt proberen om het zelf op te lossen en ik probeer u te helpen. Ik kan als u toesteming geeft inloggen op uw mail box en kijken of het werkt en ik zie alleen maar de onderwerpen en kijk in het test mailtje wat ik naar uw mail box stuurt. Ik kan de mail box resetten maar dan bent u alles kwijt wat hier in staat.
Door deze drie keuzes te geven verkomt een ISP een hoop gezeik zowel aan de kant van het bedrijf als aan de kant van de klant. Men kiest zelf en weet wat de consecenties zijn van die keuzes.
De klant heeft nu een keuze die hij eerst niet heeft gehad en kan zelf kiezen hoe belangrijk de inhoud en ze eigen privacy is.

Dan heeft de klant de keus i.p.v. dat een helpdeskmedewerker even zomaar gaat kijken. Het is gewoon een fatsoens norm.

[kalizec]

Steephh schreef op zaterdag 12 januari 2008 @ 13:56:
Testen kan ook op andere manieren dan de medewerker te laten inloggen en de mails te laten bekijken... Daar hoef je echt niet die medewerker alles handmatig te laten doen..

Maar het is wel de meeste betrouwbare manier om iets te controleren. Want de enige 100% betrouwbare manier is een accurate simulatie van wat de klant doet.

En daar gaan we weer. De TS stelt niet dat de helpdesker naar de e-mails heeft gekeken. Wat er staat is dat er ingelogd is om te kijken of inloggen werkte. Dat zijn twee verschillende dingen.

Steephh schreef op zaterdag 12 januari 2008 @ 13:56:
De helpdeskers kunnen toch in de mail? Dat is het probleem. Dat is nergens voor nodig.. Als ze in de mail kunnen kunnen ze ook de inhoud lezen en dat is nergens voor nodig...

Om te controleren of iets werkt is de enige betrouwbare manier dat uitproberen. Als er iets mis kan zijn met die mailbox dan is dat nodig. Dat ze hierbij de inhoud zouden kunnen lezen is niet persé noodzakelijk, maar er zijn problemen bekend dat ze in ieder geval de mailheader moeten kunnen zien om het probleem te kunnen identificeren en oplossen

Steephh schreef op zaterdag 12 januari 2008 @ 13:56:
En jij gebruikt de wegenverkeerswet wat hier totaal NIETS maar dan ook NIETS mee te maken heeft.. Ik wil best een discussie voeren maar kom dan met zinnige en niet van die onzinnige argumenten aan..

Sarcasme is jou zeker onbekend?

ninjazx9r98 haalt er eerst een artikel bij dat alles met onderscheppen en aftappen te maken heeft, maar niets met de TS. Vervolgens haalt hij er de wet op computer criminaliteit bij, die weer niets met deze situatie te maken heeft. Als dat zo door gaat kun je net zo goed nog een wet erbij halen die er niets mee te maken, dus bijvoorbeeld de wegenverkeerswet (sarcastisch bedoeld).

Steephh schreef op zaterdag 12 januari 2008 @ 13:56:
Haal eens een voorbeeld erbij in van alleen maar te roepen.

Het voorbeeld staat in de TS. Dat hoef ik er niet bij te halen, die stond er al voordat ik reageerde. En dat voorbeeld heeft niets met aftappen, overnemen of onderscheppen te maken en dus niet met die genoemde artikelen.

Mocht je van het tegendeel overtuigd zijn, kom dan eens met een argument waarom het wel van toepassing zou zijn in plaats van alleen maar te roepen. Ik kom in ieder geval met argumenten waarom ik van mening ben dat ze niet van toepassing zijn, dus ik ben niet alleen maar aan het roepen zoals je aan het suggereren bent.

Steephh schreef op zaterdag 12 januari 2008 @ 13:56:
Maar hef feit dat hij erin kan en dit zomaar doet zegt al genoeg. Als hij zomaar in logt op de mailbox zonder toestemming, wie zegt dan dat hij de mail ook niet daadwerkelijk leest?

Wat een hopeloze argumentatie. Kennelijk zou jij een slotenmaker achter slot en grendel zetten omdat hij zomaar een slot van een voordeur kan openen? Wie zegt dat hij dat ook niet daadwerkelijk gedaan heeft?

Steephh schreef op zaterdag 12 januari 2008 @ 13:56:
Nu heb je het puur over de mailbox alleen.. Dus wie zegt dat het probleem dan nog bij de klant dan wel provider ligt? Misschien heeft de verzender zijn instellingen wel niet goed staan en daarna de klant opgebeld om te vragen of zijn mail is aangekomen.

In plaats van dit soort vragen te stellen kun je gewoon de TS lezen en zien wat er zich, schijnbaar, voorgedaan heeft. Als je mijn posts op de vorige pagina gelezen had, had je geweten dat ik de manier waarop het gegaan is allang afgekeurd heb. Maar het principe dat een helpdeskmedewerker het wachtwoord van een klant van die helpdesk kan zien en kan controleren of een dienst die aan de klant geleverd wordt nog steeds werkt keur ik zeer zeker niet af.

Steephh schreef op zaterdag 12 januari 2008 @ 13:56:
Wakeup call, het gaat om het principe !!

ninjazx9r98 stelt dat het makkelijk technisch mogelijk is, ik stel dat dat niet zo makkelijk is. Dat iets principieel mogelijk is boeit niet. Principieel is het technisch mogelijk dat we over 12 maanden iemand op Mars hebben staan. Dat wil nog niet zeggen dat het redelijk is om dat ook te verwachten.

Steephh schreef op zaterdag 12 januari 2008 @ 13:56:
Het principe is dat het mogelijk is om redelijke tot hele grote hoeveelheden aan data binnen een zeer korte tijd te doorzoeken en tot nu toe doe jij net of dat heel ingewikkeld is.

En dat klopt in principe alleen voor geindexeerde data. En logbestanden zijn niet geindexeerd. Kortom, het door jou aangedragen principe gaat hier niet op.

Steephh schreef op zaterdag 12 januari 2008 @ 13:56:
Dan nog.. Zie jij 1 enkele gebruiker die een logfile van 30GB maakt? Ik niet hoor..

Jij wou een aparte logfile voor iedere mailbox aanmaken? Ben je gek of zo? We hebben het hier over een logfile voor alle mailboxen. ninjazx9r98 had het ook over de maillogs.

Steephh schreef op zaterdag 12 januari 2008 @ 13:56:
Dat kan de klant toch?

De gemiddelde klant is een huis-tuin-computeraar. Daarvan kun je echt niet verwachten dat hij/zij een logfile kan lezen.

Steephh schreef op zaterdag 12 januari 2008 @ 13:56:
Voor het controleren of iets werkt of niet is een interface te bouwen

Ieder stukje logica kan alleen maar problemen identificeren waar deze van tevoren voor ontworpen is. Zaken waar tijdens ontwerp geen rekening mee gehouden is, kunnen niet gedetecteerd worden en er zijn altijd zaken waar tijdens ontwerp geen rekening mee gehouden is. Of wou je beweren dat alle software bugvrij is?

Steephh schreef op zaterdag 12 januari 2008 @ 13:56:
Hij kan wel iets wissen maar niets ontvangen.. Dan ligt het probleem al niet meer bij de klant

Onjuist, ik zal je een voorbeeld geven van een situatie waarbij de klant wel iets kan wissen, maar niet kan ontvangen.

Klant start Outlook Express, Outlook Express controleert op nieuwe berichten en geeft weer dat er geen nieuwe berichten zijn. Klant besluit een oud mailtje te verwijderen. Outlook Express verwijderd het oude mailtje van de server.

Wat de klant niet weet is dat zijn installatie van Outlook Express corrupt is geraakt en dat de account-instellingen niet correct opgeslagen worden. Gevolg is dat Outlook Express niet meer goed bij houdt welke berichten al van de server gedownload zijn en nieuwe berichten niet meer herkent als zijnde nieuw. de index waar reeds opgehaalde berichten in staan is namelijk corrupt. De account-instellingen voor het inloggen worden echter op een andere plaats bewaard en zodoende kan OE nog wel inloggen.

Bovenstaand voorbeeld is een van de vele manieren waarop het programma OE beschadigd kan raken tijdens het vastlopen of niet goed afsluiten van Windows. Het vervelende eraan is dat de klant alleen merkt dat hij geen nieuwe berichten binnen krijgt, of alle oude berichten nog een keer. De enige oplossing voor dit probleem is alle accountinstellingen van die account weggooien en die account opnieuw aanmaken.

Dus dan ligt het probleem wel bij de klant en de klant kan geen nieuwe berichten ontvangen, maar wel dingen verwijderen. Als je vervolgens naar de wijzigingsdatum van de mailbox gaat kijken weet je nog steeds niet.

Hedendaagse software is vaak zo complex dat er echt geen sprake meer is van zwart-wit. Alles is grijs.

Steephh schreef op zaterdag 12 januari 2008 @ 13:56:
Wist je dat je de klant ook zelf kan laten inloggen op de webmail? Ohnee.. niet aan gedacht...

Wist jij dat sommige klanten niet weten hoe dat moet en het ook niet willen leren/weten. Wist jij dat sommige klanten in paniek raken als je ze gaat vertellen dat ze op zoek moeten gaan naar een mailtje van precies 'xyz' bytes groot? De gemiddelde klant is echt niet van het kaliber van de gemiddelde tweaker. Ook is de gemiddelde klant van XS4All/HCCnet niet hetzelfde als de gemiddelde klant van Tiscali/Telfort/Het Net/KPN etc.

Steephh schreef op zaterdag 12 januari 2008 @ 13:56:
Dat kan de klant ook..

Als de klant dat ook kon, dan belde hij niet. En als je ermee bedoeld dat de klant zelf kan proberen of het werkt. Stel dat het niet werkt? Wat weet je dan? Niets, behalve dat het niet werkt. Want foutmeldingen lezen is niet iets dat de klant kan.

Steephh schreef op zaterdag 12 januari 2008 @ 13:56:
Denk je dan echt dat de klant verwacht dat het aankomt?

Ja, dit heb ik enkele tientallen keren mee gemaakt. Dus ik WEET dat de klant een helpdesk kan mailen met de melding dat zijn e-mail het niet doet.

Steephh schreef op zaterdag 12 januari 2008 @ 13:56:
Denk je dan echt dat de klant verwacht dat het aankomt?

En dat zal steeds dezelfde zijn, denk maar niet dat je mail over 20 servers verspreid is.[/quote]
Het feit dat er meerdere load-balanced pop3-servers zijn wil niet zeggen dat je e-mail maar op 1 van die servers staat. Sterker nog die staat vaak geeneens op die servers. (Dus dat denk ik niet).

Verder moet je je beeld van de gemiddelde helpdeskcall maar eens aanpassen, want de gemiddelde klant en "even webmail" is echt niet zo vanzelfsprekend.

Steephh schreef op zaterdag 12 januari 2008 @ 13:56:
En jij denkt dat ze door op de (web)mail in te kunnen loggen METEEN (want een minuut duurde te lang) kunnen zien wat het probleem is.

Niet wat het probleem is. Dat er een probleem is of niet. En ja, daarna mag hij het probleem gaan escaleren. Maar dan heeft hij in ieder geval niet zijn tijd hoeven te verdoen met zoeken in de logs.

En dan nog ga je er van uit dat hetgeen je zoekt ook daadwerkelijk gelogd wordt.

Steephh schreef op zaterdag 12 januari 2008 @ 13:56:
Als het probleem werkelijk zo diepliggend is kan de helpdesker er toch niets mee en zal hij een systeembeheerder aan zijn jas moeten trekken.

Dan zijn we het er dus over eens dat een helpdesker zich bij de praktijk moet houden en problemen dient te constateren. Het oplossen mag hij aan anderen overlaten. En dan zijn we het er dus ook over eens dat een helpdesker door in te loggen op de (web)mail kan constateren dat er een probleem is of niet, waarbij het bij de logs minstens een minuut zal duren.

Steephh schreef op zaterdag 12 januari 2008 @ 13:56:
Stel server 1 en 8 liggen uit de lucht.. Het systeembeheer meldt aan de helpdesk dat ze denken dat het rond 15 uur is opgelost en een klant belt die niet kan inloggen en ook niet op de webmail dan kan de helpdesker mededelen aan de klant dat de servers er naar verwachting helaas tot 15 uur uitliggen.

Tegenvoorbeeld
Zondagochtend, server 1 doet raar, is niet down, maar werkt ook niet naar behoren.

Klant A belt naar de helpdesk (gebeurt meestal nog geen minuut nadat er een storing optreedt).

Helpdesker B krijgt Klant A aan de lijn.

Klant A legt uit dat hij niet in kan loggen op zijn mailbox.

Helpdesker B controleert of de mailbox werkt door er op in te loggen.

Helpdesker B constateert dat inloggen inderdaad niet mogelijk blijkt.

Helpdesker B maakt een ticket 2 aan.

Vervolgens:

Tweede Lijner C ziet ticket 2 en besluit contact op te nemen met systeembeheer.

Systeembeheerder Q weet Tweede Lijner C te vertellen dat hij geen SMS gehad heeft. Als Tweede Lijner C wilt dat hij gaat kijken zal Systeembeheerder Q voorbeelden nodig hebben met wat er wanneer en waar niet lukt.

Tweede Lijner C gaat op zoek naar voorbeelden door dingen uit te proberen en foutmeldingen te noteren.

Systeembeheerder Q meldt 30 minuten later terug dat het probleem gevonden en opgelost is.

Alternatief:

Systeembeheerder Q weet Tweede Lijner C te vertellen dat hij net een SMS gehad heeft en onderweg is naar huis om in te kunnen loggen op het netwerk om te kijken wat er mis is.

Systeembeheerder Q meldt 15 minuten later terug dat het probleem gevonden en opgelost is.

In beide gevallen is het gesprek met de klant al lang voorbij.

Steephh schreef op zaterdag 12 januari 2008 @ 13:56:
Dat heb je ook niet door te zeggen 'ja.. hier werkt ie wel hoor.. je hebt mail van jan en ook van henk.. owja en ook nog van tatjana.. die heb je gisteren binnen gekregen om 23 uur...'. Dan denkt de klant 'wtf' en is zijn probleem nog niet opgelost...

Maar als het niet gewerkt had, had hij kunnen melden "Klopt, meneer ik zie dat het hier ook niet werkt".
Of als de betreffende medewerker constateert dat het werkt "Meneer, ik heb zojuist gecontroleert of het werkt en dat doet het".

Nogmaals, ik verdedig hier noodzaak tot praktisch uitproberen door in te loggen en dat het niet wettelijk verboden is.
Ik probeer hiet niet te verdedigen dat de medewerker het op dergelijke wijze als in de TS richting de klant communiceert.

Steephh schreef op zaterdag 12 januari 2008 @ 13:56:
Wie heeft er gezegd dat de helpdeskers deze maken? .. Er worden scripts gebouwd waarvan de helpdeskers vervolgens gebruik maken..

Dat zei ik ook niet. Ik zei dat het gebruik van scripts en eerste-lijnshelpdesk medewerkers al vaak niet samen gaat.

ninjazx9r98 schreef op zaterdag 12 januari 2008 @ 10:22:
Sterker nog, je zou kunnen zeggen dat professionele omgevingen waar niet gescript wordt niet bestaan.

Steephh schreef op zaterdag 12 januari 2008 @ 13:56:
Dat zegt hij niet.. Hij zegt alleen dat die vrijwel niet bestaan.. LEZEN!!!

Het woord "vrijwel" komt er toch echt niet in voor. Leer zelf lezen. Het staat er echt alsof het in alle denkbare gevallen waar is.

Steephh schreef op zaterdag 12 januari 2008 @ 13:56:
Het wachtwoord is niet afgesproken maar toegewezen. Als de klant daarna zijn wachtwoord wijzigd in een makkelijker te onthouden wachtwoord wat hij op meerdere plekken gebruikt..
Dan heeft een helpdeskmedewerker hier inderdaad niets meer mee te maken.

Als een wachtwoord wordt toegewezen is dat ook een vorm van 'afspreken'.
Als hij zijn wachtwoord op meerdere plekken gebruikt is dat zijn keuze.

Om een wachtwoord te wijzigen dient hij het nieuwe wachtwoord door te geven aan de ISP. En of hij dat nu doet via een administratief computersysteem of via een helpdesk medewerker. Het blijft in beide gevallen dezelfde rechtspersoon. Je kunt vinden dat die helpdeskmedewerker er hierna niets meer mee te maken heeft, maar die helpdeskmedewerker vertegenwoordig wel dezelfde rechtspersoon als dat administratieve systeem.

Steephh schreef op zaterdag 12 januari 2008 @ 13:56:
En wat heeft die helpdeskmedewerker hier vervolgens mee te maken? Waarvoor heeft hij het daadwerkelijk nodig? Nergens voor en waarom zou hij daadwerkelijk met een wachtwoord moeten inloggen als er scripts voor worden geschreven, desnoods geimplementeerd op een intranet die controleren of mailboxen oid nog werken.

Nogmaals, scripts kunnen geen probleem voorzien of interpreteren die niet bedacht zijn door de maker van die scripts. Ook ga je er klakkeloos van uit dat er voor iedere denkbare situatie scripts voor handen zijn of anders gemaakt kunnen worden. Droom lekker verder, maar dat is niet zo. Bij een ISP kunnen dingen zo vaak veranderen dat vrijwel ieder script van meer dan een half tot een heel jaar oud niet meer goed zal functioneren.

Steephh schreef op zaterdag 12 januari 2008 @ 13:56:
En ik denk persoonlijk dat die systemen wel iets duurder zijn dan een interface voor de helpdeskmedewerker.

En ik weet het wel zeker. Maar dan nog, het tegenvoorbeeld van die credit-card geeft aan dat er ook financiele organisaties zijn die toch zonder codes en versleuteling kunnen werken.
Versleuteling en codering van wachtwoorden is dus niet persé een regel en dat was het doel achter dit argument. Verder ben ik wel blij dat we het eens zijn dat het wenselijk is dat banken hun pincodes bij hun medewerkers weg houden.

Steephh schreef op zaterdag 12 januari 2008 @ 13:56:
Misschien heeft hij een slechte dag.. Het is geen robot die dag in dag uit zin heeft om iemand te helpen. En inderdaad, ik vertrouw niet alle helpdeskmedewerkers.. Als het een interne helpdesk van de provider is zou het nog anders liggen maar dan nog steeds, niemand hoeft mijn mail te lezen en niemand mijn wachtwoord te bekijken. Mensen zijn nieuwschierige wezens en als ik iemand persoonlijk ken zou het anders liggen. Maar goed, voor wat ik wil doen heb ik genoeg kennis van zaken dus dat is niet nodig.

Maar in tegenstelling tot die bankmedewerker heeft hij geen aantoonbaar gewin bij het inzien van dat wachtwoord. Als het een pincode was had hij die kunnen gebruiken om geld te pinnen. Met een e-mailwachtwoord bij een ISP kun je al een stuk minder.

Steephh schreef op zaterdag 12 januari 2008 @ 13:56:
Dus een klant die op privacy gesteld is maar geen verstand heeft van van SSL/SSH/PGP moet vervolgens maar zijn eigen mailserver opzetten?

Nee, maar voor ninjazx9r98 zou het een serieuze optie moeten zijn als hij dat al niet gedaan heeft. Een klant die op zijn privacy gesteld is, moet gewoon naar een ISP toestappen die hij/zij vertrouwd. Vertrouwd hij zijn huidige ISP of de medewerkers aldaar niet (meer) dan kan hij beter van ISP wisselen. Persoonlijk heb ik er geen moeite mee dat iemand van een ISP-helpdesk mijn wachtwoorden in kan zien en in zou kunnen loggen op mijn mailbox. Ik vertrouw die ISP en de medewerkers aldaar dat ze er geen misbruik van zouden maken.

ninjazx9r98 schreef op zaterdag 12 januari 2008 @ 15:39:
Laat je het even weten als je de schrijver hebt uitgelegd dat hij geen wetteksten kan lezen?

Wat de schrijver er neergezet klopt als een bus. Het heeft alleen niets met het onderwerp in de TS te maken en JIJ interpreteert wat daar staat verkeerd.

Tot slot

Onderstaande ben ik het volledig mee eens en daarbij ga ik het laten, want het topic wordt er zo ook niet leesbaarder door. Ik denk dat het een kwestie van vertrouwen is tussen klant en bedrijf en verder ben ik van mening dat de medewerker in de TS het netter had kunnen en moeten doen, maar dat er feitelijk niets illegaals heeft plaatsgevonden.

alt-92 schreef op zaterdag 12 januari 2008 @ 14:29:
De gemiddelde nederlander interesseert dat niet - die wil gewoon binnen 5 minuten dat probleem met z'n niet werkende mail opgelost hebben.

[alt-92]

ninjazx9r98 schreef op zaterdag 12 januari 2008 @ 15:39:
[
En het verschil tussen de mailbox en de inhoud is ?
Simpel uitgaande van een Unix achtig systeem is de mailbox en de inhoud in feite hetzelfde.
Een plat stuk tekst.
Veel moeilijker is het echt niet.
Op het moment dat je een mailbox bekijkt wordt er data overgenomen naar jouw systeem.
Wederrechtelijk is hier dus gewoon aan de orde.

De meerderheid van MTA's in ISP land zijn maildir-based oplossingen.
Geen single mbox file, maar een container waar elk bericht afzonderlijk in staat.

De toegang tot de maildir van de users staat daarbij niet gelijk aan het daadwerkelijk en wederrechtelijk (en wanneer is het wederrechtelijk als je als klant naar een helpdesk toe stapt?) toegang verschaffen tot de INHOUD van de mail.


En om maar even uit datzelfde artikel waar je zelf naar verwijst te quoten:

quote: http://www.iusmentis.com/maatschappij/juridisch/briefgeheim/

Goede werking van netwerk

Er is wel een uitzondering: als het aftappen of opnemen gebeurt "ten behoeve van de goede werking van een openbaar telecommunicatienetwerk" of in opdracht van politie of justitie, dan is het niet strafbaar. Een systeembeheerder mag dus in de uitgaande mail van een klant kijken als deze zo veel mails stuurt dat het systeem instabiel wordt, om een voorbeeld te noemen.
Ook kan de provider natuurlijk afspraken maken met de klant over wanneer zij in de mail (of andere communicatie) van de klant mogen kijken. Zo kan een provider een automatische virusscan uitvoeren op uitgaande e-mail of binnenkomende ongewenste reclame of spam tegenhouden.

[ Voor 32% gewijzigd door alt-92 op 12-01-2008 16:27 ]

[Gomez12]

ninjazx9r98 schreef op zaterdag 12 januari 2008 @ 10:22:
[...]
Volgens mij heb jij echt het idee dat ISP's hoogstaande technische omgevingen hebben die echt vreselijk bijzonder zijn en waar hele spannende moeilijke dingen gebeuren.
Ik heb nieuws voor je, het is allemaal niet zo spannend.
Alleen al de benaming van hobby-bob tooling voor scripts ed die op bijv een Linux/Unix omgeving draaien en aanwezig zijn geeft aan dat je maar wat roept zonder echt te weten waar je het over hebt.

Ok, nog 1 poging dan :
- Je hebt beheerdersscripts die worden onderhouden en zijn in gebruik door beheerders, layout vd uitvoer te veel info geven etc is over het algemeen van secundair belang, omdat het toch alleen maar door beheerders gebruikt wordt. Dit zijn dus geen hobby-bob scripts en de standaard scripts waar jij op doelt.
- Je hebt een programma / tool voor de helpdesk. Hier moeten meerdere ondeskundige mensen gelijk mee kunnen werken, dit mag niet uitvallen want dan kan je de helpdesk bijna dichtgooien. Dit mag nooit en te nimmer te veel info geven omdat het dan de privacy van de klant raakt. Als een beheerder dit "even" gaat zitten scripten dan noem ik het inderdaad een hobby-bob script. De beheerder weet over het algemeen niet de preciese wetten en regels etc. Hij kent de gebruikers over het algemeen ook niet ( hoeveel ISP's hebben hun helpdesk niet gewoon bij een callcenter zitten ). Dus deze scripts moeten 100% waterdicht zijn, 100% duidelijk zijn voor de helpdesker, en 100% uptime hebben. Dat zie ik 99% van de beheerders nog niet bouwen, die zijn goed in het technisch bouwen, maar als het even niet werkt dan verandert een beheerder even het script en dat kan dus niet.

Btw kan jij eens een grove uren indicatie opgeven hoeveel tijd het zou kosten om deze scriptjes te gaan bouwen. Want als ik jouw verhaal zo zie is dit toch makkelijk binnen 1 dag te bouwen...

Ik kom dagelijks in aanraking met Unix systemen waar vele terabytes aan kostbare klant informatie op staat en het aanwezig zijn van (zelfgemaakte) scripts die allerlei taken automatiseren is de normaalste zaak van de wereld op dergelijke systemen.

Yep, dit zijn dus de beheerdersscript. Waar dus maar een select personeel gebruik van maakt wat ook nog eens de kennis heeft om de scripts aan te passen als de output niet volstaat, helpdeskers maken hier dus geen gebruik van.

Schei toch uit zeg.
'ergens in de organisatie een beheerder'
Natuurlijk, er lopen allerlei beheerders overal en nergens in een organisatie die allemaal op die mailserver kunnen inloggen en die zitten ook regelmatig in die mailboxen te wrotten waar ze stomme fouten maken.

Ging meer om het principe, zoals iemand hierboven al zei, verwijderen van een mailtje touched het bestand ook al. Het geeft gewoon alleen maar aan wanneer er iets met het bestand gebeurt is, het zegt niets over wanneer de laatste email binnengekomen is.

[...]
Mag ik je vragen wat jij denkt wat een systeembeheerder is en doet ?
Ik heb namelijk het idee dat jij daar heel anders over denkt dan ik.
Overigens lijkt het me niet meer dan logisch dat systeembeheerders kundig zijn tenzij jij er natuurlijk een hele andere definitie van systeembeheer op na houdt.

Ik denk inderdaad dat beheerders kundig zijn, en ze mogen / moeten ook scripts schrijven om het beheer makkelijker te maken, maar dat zijn wel beheersscripts.

[...]
Dus geef je die 1e lijns helpdesk de beschikking over een tool die eea in hapklare brokken voorschotelt.
Het is allemaal niet zo spannend.

En dan is het dus geen simpel script meer, wat even kijkt wat de laatste wijzigingsdatum van een bestand is, nee er moet gelijk een layout overheen etc., het moet op te roepen zijn vanaf iets anders dan de shell, in een serverpark waarbij gebruikers a/h op server 1 staan, en gebruikers i/z op server 2 moet het script dit ook gelijk goeddoen. Ook als er een server bijkomt.
Terwijl een beheerder alleen maar even hoeft te weten wat de gebruikersnaam is, hij weet uit zijn hoofd / documentatie welke server het is, en draait daar even een scriptje, klopt de documentatie niet meer, niet erg. De beheerder logt gewoon wel even in op de juiste machine, 5 sec extra werk. Met een scripts betekent het gelijk dat de helpdesker er niet meer bij kan, hij moet een call aanmaken naar systeembeheer, en krijgt de volgende dag de melding dat het opgelost is...

Lol.
En natuurlijk is er helemaal nergens een of ander monitoring systeem wat dat in de gaten krijgt en aan beheer plus helpdesk doorgeeft dat er stront aan de knikker is en dat eea tijdelijk niet in de lucht is.

Nou, laat ik het zo zeggen, ik heb het nog nooit gezien dat een monitoring systeem automatisch een melding doorgeeft aan de helpdesk. Beheerders krijgen een melding waar zij iets mee kunnen, en zij geven dit door aan de helpdesk in termen waar de helpdesk iets mee kan.
Dat server15 eruit ligt heeft de helpdesk niets aan, dat alle gebruikers met inlognaam x/y niet meer bij hun mail kunnen daar heeft de helpdesk wel iets aan. Of jij zet dit soort info allemaal in je monitoring systeem?

Dan zeg je gewoon tegen de klant "Inderdaad, hier werkt het ook niet"

Yep, en op dat moment kan er gelijk 2e lijns / 3e lijns gecontacteerd worden en kan er tegen de klant gezegd worden dat het uitgezocht wordt en dat hij teruggebeld wordt. Dan weet je namelijk 100% zeker dat het aan jullie kant ligt.

Dan zeg je gewoon dat hij een uur geleden nog wel email kon ophalen en stel je de vraag of er in het laatste uur nog iets gebeurt is.
Mijn God zeg, is het allemaal dan werkelijk zo vreselijk moeilijk ?

Ooit wel eens op een consumenten helpdesk gezeten? 15 jaar terug toen ik dat deed toen veranderde er nooit iets bij de klant, en vorige week deed hij het nog wel. Oh, dat de klant de router heeft uitgeschakeld dat vermeld hij niet, hij zegt alleen dat zijn internet het niet doet. En dat er niets veranderd is.

Eigenlijk is dit wel grappig, je blaast heel hoog van de toren over hoe moeilijk het allemaal wel niet is en over scripting wat hobby-bob niveau zou zijn maar een veelgebruikt stukje tooling wat juist in dit soort settings veelvuldig wordt gebruikt weet je niet wat het nu eigenlijk is en doet.

He, ik geef tenminste toe dat ik een interpretatie fout maakte.

Ik heb te maken met beheerders van Linux/Unix systemen waarbij de een er 1 in beheer heeft en de andere 20 of meer.
Het scripten en dus automatiseren van allerlei taken is de kracht van een goede systeembeheerder en maakt het beheer en leven vele malen makkelijker.
Als iemand dan scripten gaat vergelijken met hobby-bob niveau en dat niet professioneel noemt vraag ik me werkelijk af wat je eigen ervaring is of in wat voor soort omgeving je zelf werkt.
Scripting en een professionele omgeving gaan uitstekend samen.
Sterker nog, je zou kunnen zeggen dat professionele omgevingen waar niet gescript wordt niet bestaan.

Beheerdersscripts daar klopt dit stukje volledig voor, daar ben ik het ook wel mee eens, maar het gaat hier niet om beheerdersscripts. Het gaat hier om een tool voor de helpdeskers die 0,0 verstand hebben ( moet je van uitgaan ).
Als een beheerdersscript een inhoud van een mailbox toont door een foutje denk ik niet dat iemand er een probleem van maakt, maar als de helpdeskers hetzelfde onder ogen krijgen dan zit je weer op het beginpunt van dit topic.

kalizec schreef op zaterdag 12 januari 2008 @ 12:59:
[...]
Het grote verschil is dat Google zoekt in een database die voorzien is van een index. Die index wordt echt niet ter plekke gegenereerd, maar tijdens het crawlen. Kortom, dat is echt andere koek dan het ter plekke doorzoeken van een logfile en verwachtten dat het even snel gaat.

Voor de duidelijkheid een 'fictief' voorbeeldje.
- 30GB logfiles per dag
- Een schijfsysteem dat 500MB data per seconde in kan lezen. (Is geen kattepis)
- Een enkele niet niet-concurrente zoekactie duurt dan minimaal 60 seconden.

En dan hebben we eventjes niet gekeken naar het feit dat er meerdere concurrente zoekacties zullen lopen. Ook kan ik je vertellen dat een minuut moeten wachtten op het antwoord of inloggen op een mailbox mogelijk is, niet acceptabel is.

Maar de scripts kunnen toch ook indexen aanmaken, heck man, je kan gewoon eventjes een logparser schrijven die de geschikte output naar een db gooit. Waarna het door indexen goed te doorzoeken is. Oh, is dit geen simpel scriptje meer?

Om je een enkel voorbeeldje te geven.
- Wist jij dat Outlook Express over zijn nek gaat van bepaalde strings in de subject header?
- Wist jij dat dit dezelfde foutmelding oplevert aan de gebruikerskant als een willekeurige andere timeout.
- Wist jij dat je om een dergelijk mailtje te herkennen (en ja er zijn zelfs spam-rondes mee geweest) je echt naar de mailheaders moet kijken.

OE foutmeldingen ondervang je niet door in te loggen en op webmail te kijken. En een helpdesker hoeft echt niet naar mailheaders te kijken, hooguit moet er een interne mail zijn geweest dat mailtjes met als onderwerp x OE foutmeldingen geven.
Mailheaders kijken is imho echt geen 1e lijns werk meer.

[...]
Terug bellen bij een klant die geen telefoonlijn heeft? (Er bestaan dedicated lijnen)
Terug bellen bij een klant die vrijwel nooit thuis is? (En dan komt het vaak ook nog niet uit.)

In de klantgegevens staat gewoon een telnr van de klant neem ik aan. En mensen die echt geen telefoon meer hebben maar wel inet zijn volgens mij zo zeldzaam dat je hier geen rekening mee hoeft te houden, heeft een klant geen vaste lijn dan heeft hij waarschijnlijk wel mobiel.
En als de klant niet thuis is, dan gewoon 3x proberen te bellen ( op redelijke tijdstippen ) en als je dan nog niet de klant te pakken hebt gehad dan kan de klant zelf terugbellen na 2 dagen ( wel even naar je klanten communiceren dat je zo werkt )

[...]
Let wel we hebben het hier over een helpdeskmedewerker die inlogt op een mailbox. Er staat nergens gemeld dat hij de emailheaders doorneemt, laat staan dat hij de inhoud van berichten gaat zitten lezen. En als iemand zich zo druk maakt over inhoud van zijn e-mail dan zijn er altijd nog opties als PGP.

Ik denk dat men er meer over valt dat de helpdeskmedewerker met 1 klik dan de inhoud kan lezen, of het gemeld wordt of niet dat is een 2e.
Maar imho is dit een niet te voorkomen probleem zonder dat er echt veel geld tegenaan gegooid wordt.

[...]
Right, dus een omgeving waar geen enkele dag/handeling hetzelfde is en scripting dus volkomen bullshit is, is volgens jou dus niet professioneel.

Geef eens een voorbeeld van zo'n omgeving? Ik kan me geen omgeving voorstellen die niet dezelfde handelingen vereist? Te veel dingen die elke dag weer moeten gebeuren ( backup bijv. ) die prima te scripten zijn.
Ik zou als beheerder gek worden als ik al mijn script eruit zou moeten gooien en alles handmatig zou moeten doen, dan heb ik 80-urige dagen nodig.

[...]
Tot slot vraag ik me af wat voor gebrek aan vertrouwen jij wel niet hebt richting personeel dat daar werkt. Alsof Pietje Puk ook maar enig belang heeft bij het doorsnuffelen van je mailbox. Die zit daar ook alleen maar omdat hij betaalt wordt om je te helpen. Dat hij denkt dat hij je een dienst doet, door te controleren of eea. inderdaad nog goed en naar behoren werkt, maakt alleen maar duidelijk dat hij een klant wil helpen.

Nou, al te veel vertrouwen in de helpdesk van een ISP heb ik ook niet. Meeste 1e lijns helpdesks worden gewoon doorgeschoven richting callcenters etc.
Ik verwacht alleen wel dat een ISP interne richtlijnen opgesteld heeft wat voorkomt dat elke helpdesker het doet. En die ene rotte appel die het toch die ziet mij niet omdat er te veel mailboxen op het systeem staan die veel interessanter zijn.

Btw, andere mogelijkheid die denk ik wel heel erg simpel uit te voeren is :
Zet een proxy neer tussen helpdesk en de webmail waar helpdeskers op kunnen inloggen op de webmail van een klant.
De proxy laat alleen maar enkele pagina's zien, de mailinhoud pagina is dus gewoon denied. Dan kan een helpdesk wel zien of de mailbox werkt, hij kan wel de headers zien, hij kan wel de afzenders zien, hij kan niet de inhoud zien.
Omdat het een proxy betreft werkt hij altijd ongeacht welke wijziging aan webmail ( url-wijzigingen uitgezonderd )

Voor de mensen die vrijwillig hun wachtwoord geven daar kan de medewerker alsnog op de echte webmail inloggen in hier ook de inhoud lezen. Maar dan heeft de klant zelf het wachtwoord gegeven.

[kamerplant]

Ik krijg mijn wachtwoord van Solcon via een medewerker zelfs via MSN, terwijl ik er niet eens naar vroeg. Lekker veilig ook
Ik zit nu niet bij Solcon trouwens, maar dat heeft een andere reden.

[ Voor 10% gewijzigd door kamerplant op 12-01-2008 17:00 ]

[Gomez12]

Datafeest schreef op zaterdag 12 januari 2008 @ 17:00:
Ik krijg mijn wachtwoord van Solcon via een medewerker zelfs via MSN, terwijl ik er niet eens naar vroeg. Lekker veilig ook
Ik zit nu niet bij Solcon trouwens, maar dat heeft een andere reden.

Paar vraagjes, want dit is volgens mij een speciale situatie. En voordat iedereen hier weer op gaat springen.

1 : Ik gok niet dat jij dat MSN adres vanuit het niets hebt getoverd, dus je kent de medewerker al?
2 : Was het een initieel/gereset wachtwoord, of gewoon je huidige?
3 : Is volgens jou MSN onveiliger dan email? Volgens mij namelijk niet, gaat allebei unencrypted over het net.
4 : Is het de normale werkwijze van solcon dat hun helpdesk via MSN werkt?

[ninjazx9r98]

alt-92 schreef op zaterdag 12 januari 2008 @ 16:05:
[...]

De meerderheid van MTA's in ISP land zijn maildir-based oplossingen.
Geen single mbox file, maar een container waar elk bericht afzonderlijk in staat.

Een directory met daarin losse emails in de vorm van tekstfiles met als benaming een unieke naam.
De container is dan in feite een directory met daarin subdirectories voor nieuwe mail, mail gezien door de mailclient en binnenkomende mail.

De toegang tot de maildir van de users staat daarbij niet gelijk aan het daadwerkelijk en wederrechtelijk (en wanneer is het wederrechtelijk als je als klant naar een helpdesk toe stapt?) toegang verschaffen tot de INHOUD van de mail.

Die maildir heeft een owner zijnde de klant.
In principe heeft dus de klant plus de systeembeheerder toegang tot die maildir.
Zodra je op de een of andere manier inlogt op die maildir en daar ziet van wie die klant mail heeft gekregen (eerder in de discussie wordt zelfs geroepen : kent u die persoon, die persoon en die persoon ? als een test/bewijs om aan te geven dat er mail is) heb je je wat mij betreft toegang verschaft tot de email.
Na het daadwerkelijk inloggen is toegang tot inhoud van email slechts een klein stapje verder.
Wat het wederrechtelijk betreft, zolang je niet expliciet toestemming vraagt aan die klant is het wat mij betreft wederrechtelijk.
Als ik een huurhuis zou hebben met een defecte cv ketel en morgen bel naar de verhuurder om die te laten repareren verwacht ik niet bij thuiskomst een monteur in huis te hebben zonder dat ik de deur heb open gedaan.
Naar mijn idee is het dan ook onzin om te veronderstellen dat een telefoontje naar de helpdesk per direct inhoudt dat men daar direct in mijn email ed zou kunnen/mogen graaien.
Mocht dat al uberhaupt noodzakelijk zijn verwacht ik op z'n minst een vraag om toestemming.

En om maar even uit datzelfde artikel waar je zelf naar verwijst te quoten:

Ik vroeg me al af wanneer de eerste met dat stukje zou komen wat ik bewust heb weggelaten.
Het is je hopelijk toch wel opgevallen dat daar systeembeheerder staat ?
En dat het voorbeeld ook spreekt over uitgaande mail met als gevolg een instabiel systeem ?

[RemcoDelft]

Dubieus topic! En erg arrogant van die medewerker.
In gebruikt trouwens NOOIT provider-mail, om de simpele reden dat ik graag wil kunnen "switchen" zonder gegijzeld te worden qua emailadres. Gmail vind ik erg fijn, en natuurlijk gewoon eigen domeinnaam + mailforward...

[Steephh]

kalizec schreef op zaterdag 12 januari 2008 @ 15:58:
[...]

Maar het is wel de meeste betrouwbare manier om iets te controleren. Want de enige 100% betrouwbare manier is een accurate simulatie van wat de klant doet.

En daar gaan we weer. De TS stelt niet dat de helpdesker naar de e-mails heeft gekeken. Wat er staat is dat er ingelogd is om te kijken of inloggen werkte. Dat zijn twee verschillende dingen.

Blijkbaar roep je maar wat.. Want dat is dus niet waar. Stel de klant heeft cookies aanstaan, wat voor de webmail die de provider gebruikt van belang is. Hierdoor kan de klant niet inloggen.. Op de helpdesks staan cookies wel aan.. Wat zei je ook alweer van 100% betrouwbaar? En inderdaad, er staat ook niet dat er naar is gekeken, maar wel dat hij erin zit.. Dat het kan is al niet goed.

[...]

Om te controleren of iets werkt is de enige betrouwbare manier dat uitproberen. Als er iets mis kan zijn met die mailbox dan is dat nodig. Dat ze hierbij de inhoud zouden kunnen lezen is niet persé noodzakelijk, maar er zijn problemen bekend dat ze in ieder geval de mailheader moeten kunnen zien om het probleem te kunnen identificeren en oplossen

Dat klopt, maar er is geen controle op wat de helpdesker doet. Maar noem dan eens een probleem in plaats van het globaal te noemen.

[...]

Sarcasme is jou zeker onbekend?

ninjazx9r98 haalt er eerst een artikel bij dat alles met onderscheppen en aftappen te maken heeft, maar niets met de TS. Vervolgens haalt hij er de wet op computer criminaliteit bij, die weer niets met deze situatie te maken heeft. Als dat zo door gaat kun je net zo goed nog een wet erbij halen die er niets mee te maken, dus bijvoorbeeld de wegenverkeerswet (sarcastisch bedoeld).

Computer criminaliteit heeft nog altijd meer hiermee te maken dan de wegenverkeerswet...

[...]

Het voorbeeld staat in de TS. Dat hoef ik er niet bij te halen, die stond er al voordat ik reageerde. En dat voorbeeld heeft niets met aftappen, overnemen of onderscheppen te maken en dus niet met die genoemde artikelen.

Mocht je van het tegendeel overtuigd zijn, kom dan eens met een argument waarom het wel van toepassing zou zijn in plaats van alleen maar te roepen. Ik kom in ieder geval met argumenten waarom ik van mening ben dat ze niet van toepassing zijn, dus ik ben niet alleen maar aan het roepen zoals je aan het suggereren bent.

Van mening bent ja.. Geef dan eens een voorbeeld waarom het NIET zo is (twas niet zo duidelijk in mijn post, sorry), jij kent die jongen van die site blijkbaar zo goed.. Dan zal je het er wel veel met hem over gehad hebben en kan je dus ook zeggen waarom ze niet van toepassing bent..

[...]

Wat een hopeloze argumentatie. Kennelijk zou jij een slotenmaker achter slot en grendel zetten omdat hij zomaar een slot van een voordeur kan openen? Wie zegt dat hij dat ook niet daadwerkelijk gedaan heeft?

Nee, JIJ hebt een hopeloze argumentatie.. Ik heb toch niet gezegd dat de helpdeskers bij voorbaat al achter slot en grendel moeten zetten? Maar je moet ze ook niet de rechten geven als ze daarover niet over hoeven te beschikken en dit de privacy van de klant tegoede komt.

[...]

In plaats van dit soort vragen te stellen kun je gewoon de TS lezen en zien wat er zich, schijnbaar, voorgedaan heeft. Als je mijn posts op de vorige pagina gelezen had, had je geweten dat ik de manier waarop het gegaan is allang afgekeurd heb. Maar het principe dat een helpdeskmedewerker het wachtwoord van een klant van die helpdesk kan zien en kan controleren of een dienst die aan de klant geleverd wordt nog steeds werkt keur ik zeer zeker niet af.

Een helpdesker heeft het nergens voor nodig.. Zelfs al zou je de helpdesker in de mail willen laten kijken, dat kan ook op andere manieren zonder er een wachtwoord voor te gebruiken..

[...]

ninjazx9r98 stelt dat het makkelijk technisch mogelijk is, ik stel dat dat niet zo makkelijk is. Dat iets principieel mogelijk is boeit niet. Principieel is het technisch mogelijk dat we over 12 maanden iemand op Mars hebben staan. Dat wil nog niet zeggen dat het redelijk is om dat ook te verwachten.

Ah meneer de NASA medewerker.. Ik denk dat ninjazx9r98 toch wel iets meer ervaring op zijn vakgebied heeft dan een roeping die jij zomaar doet...

[...]

En dat klopt in principe alleen voor geindexeerde data. En logbestanden zijn niet geindexeerd. Kortom, het door jou aangedragen principe gaat hier niet op.

Genoeg voorbeelden van mensen in dit topic die aangeven dat dit niet zo is.. En logbestanden zijn makkelijk te indexeren, of denk jij dat er één logbestand op een raid array van 1200gb staat waarin wordt gezocht? Sorteren per klant en op datum en daarvan verschillende logbestanden maken (per week bijvoorbeeld) is niet zo moeilijk..

[...]

Jij wou een aparte logfile voor iedere mailbox aanmaken? Ben je gek of zo? We hebben het hier over een logfile voor alle mailboxen. ninjazx9r98 had het ook over de maillogs.

Hoezo ben je gek? Dat kan ik beter aan jou vragen..Wilde je soms 200.000 klanten in een file proppen?

[...]

De gemiddelde klant is een huis-tuin-computeraar. Daarvan kun je echt niet verwachten dat hij/zij een logfile kan lezen.

De webmail lezen

[...]

Ieder stukje logica kan alleen maar problemen identificeren waar deze van tevoren voor ontworpen is. Zaken waar tijdens ontwerp geen rekening mee gehouden is, kunnen niet gedetecteerd worden en er zijn altijd zaken waar tijdens ontwerp geen rekening mee gehouden is. Of wou je beweren dat alle software bugvrij is?

Nee, helemaal niet. Je denkt er veel te moeilijk over.. Welke foutmelding zie je in de webmail staan die zogenaamd zo moeilijk na te bootsen is in een aparte interface..

[...]

Onjuist, ik zal je een voorbeeld geven van een situatie waarbij de klant wel iets kan wissen, maar niet kan ontvangen.

Klant start Outlook Express, Outlook Express controleert op nieuwe berichten en geeft weer dat er geen nieuwe berichten zijn. Klant besluit een oud mailtje te verwijderen. Outlook Express verwijderd het oude mailtje van de server.

Wat de klant niet weet is dat zijn installatie van Outlook Express corrupt is geraakt en dat de account-instellingen niet correct opgeslagen worden. Gevolg is dat Outlook Express niet meer goed bij houdt welke berichten al van de server gedownload zijn en nieuwe berichten niet meer herkent als zijnde nieuw. de index waar reeds opgehaalde berichten in staan is namelijk corrupt. De account-instellingen voor het inloggen worden echter op een andere plaats bewaard en zodoende kan OE nog wel inloggen.

Bovenstaand voorbeeld is een van de vele manieren waarop het programma OE beschadigd kan raken tijdens het vastlopen of niet goed afsluiten van Windows. Het vervelende eraan is dat de klant alleen merkt dat hij geen nieuwe berichten binnen krijgt, of alle oude berichten nog een keer. De enige oplossing voor dit probleem is alle accountinstellingen van die account weggooien en die account opnieuw aanmaken.

Dus dan ligt het probleem wel bij de klant en de klant kan geen nieuwe berichten ontvangen, maar wel dingen verwijderen. Als je vervolgens naar de wijzigingsdatum van de mailbox gaat kijken weet je nog steeds niet.

Hedendaagse software is vaak zo complex dat er echt geen sprake meer is van zwart-wit. Alles is grijs.

Laat de klant inloggen op de webmail, et voila! Klant ziet dat het daar niet aan ligt en daarvoor hoeft de helpdesk geen namen uit de mailbox voor te lezen.

[...]

Wist jij dat sommige klanten niet weten hoe dat moet en het ook niet willen leren/weten. Wist jij dat sommige klanten in paniek raken als je ze gaat vertellen dat ze op zoek moeten gaan naar een mailtje van precies 'xyz' bytes groot? De gemiddelde klant is echt niet van het kaliber van de gemiddelde tweaker. Ook is de gemiddelde klant van XS4All/HCCnet niet hetzelfde als de gemiddelde klant van Tiscali/Telfort/Het Net/KPN etc.

Dan vraag ik me toch af wat die mensen achter een computer doen.. Wist je dat veel rekeningen alleen nog maar via internet te zien zijn.. Daarvoor moet de klant ook inloggen en dat gaat op dezelfde manier... En over de gemiddelde klant van XS4ALL slaat ook nergens op.. Genoeg mensen die ik ken die XS4ALL hebben gekozen omdat ze daar goede verhalen over hebben gehoord, maar zelf amper iets over computers weten en alleen een beetje kunnen Word'en, mailen en internetten. Ik weet wel zeker dat de gemiddelde klant echt niet iemand hoeft te zijn die qua kennis boven het gemiddelde van de bevolking zit..

[...]

Als de klant dat ook kon, dan belde hij niet. En als je ermee bedoeld dat de klant zelf kan proberen of het werkt. Stel dat het niet werkt? Wat weet je dan? Niets, behalve dat het niet werkt. Want foutmeldingen lezen is niet iets dat de klant kan.

Dan kan je hem toch ook niet helpen..

Klant: mail doet het niet
Helpdesk: kunt u iets preciezer zijn, wat werkt er niet?
Klant: mijn mail
Helpdesk: welke mailclient gebruikt u?
Klant: wat?
Helpdesk: Gebruikt u Outlook Express?
Klant: ja volgens mij wel ja
Helpdesk: wat voor foutmelding krijgt u wanneer u uw mail op wilt halen?
Klant: foutmelding? die kan ik niet lezen..

Stel je je het zo voor? En hij belde niet als hij het wel kon.. Dus als hij een foutmelding wel kan lezen dan kan hij het wel even oplossen (ook al is het een provider gerelateerd probleem).. Juist ja.. Een foutmelding voorlezen die OE geeft is niet zo moeilijk..

Men zei eerder in dit topic dat men inloggen op de webmail vaak gebruikt werd om de klant te laten zien dat het een client gerelateerd probleem is en dat er daarvoor enkele onderwerpen werden voorgelezen.. Als de klant dat zelf kan dan is dat niet nodig.

[...]

Ja, dit heb ik enkele tientallen keren mee gemaakt. Dus ik WEET dat de klant een helpdesk kan mailen met de melding dat zijn e-mail het niet doet.

Ja hoor, dat is hetzelfde als opbellen naar KPN dat je telefoon niet meer werkt en dan hopen dat iemand het heeft gehoord ook al wordt er niet opgenomen.. Of een brief sturen naar de TPG zonder je eigen adres erin te zetten...

[...]

En dat zal steeds dezelfde zijn, denk maar niet dat je mail over 20 servers verspreid is.[/quote]
Het feit dat er meerdere load-balanced pop3-servers zijn wil niet zeggen dat je e-mail maar op 1 van die servers staat. Sterker nog die staat vaak geeneens op die servers. (Dus dat denk ik niet).

Verder moet je je beeld van de gemiddelde helpdeskcall maar eens aanpassen, want de gemiddelde klant en "even webmail" is echt niet zo vanzelfsprekend.

Ik bedoel dat de klanten verspreid zijn over de server.. Ik heb ook helemaal niet gezegd dat deze over 20 verschillende servers verspreid is..

Stap voor stap begeleiden? Als een klant echt niet weet hoe hij in de mail moet?

http://webmail.provider.nl
gebruikersnaam intoetsen
wachtwoord intoetsen
<enter>
et voila..

Moeilijk... Tuurlijk, half Nederland weet niet hoe dat moet..

[...]

Niet wat het probleem is. Dat er een probleem is of niet. En ja, daarna mag hij het probleem gaan escaleren. Maar dan heeft hij in ieder geval niet zijn tijd hoeven te verdoen met zoeken in de logs.

En dan nog ga je er van uit dat het geen je zoekt ook daadwerkelijk gelogd wordt.

Maar als je in de webmail kijkt zie je het natuurlijk meteen, of niet?

[...]

Dan zijn we het er dus over eens dat een helpdesker zich bij de praktijk moet houden en problemen dient te constateren. Het oplossen mag hij aan anderen overlaten. En dan zijn we het er dus ook over eens dat een helpdesker door in te loggen op de (web)mail kan constateren dat er een probleem is of niet, waarbij het bij de logs minstens een minuut zal duren.

Dat valt te automatiseren dmv. een script en een interface... Inloggen is dan nergens meer voor nodig.. En logs duren geen minuut.. Webmail toch ook niet??

[...]


[i]Tegenvoorbeeld
Zondagochtend, server 1 doet raar, is niet down, maar werkt ook niet naar behoren.

Klant A belt naar de helpdesk (gebeurt meestal nog geen minuut nadat er een storing optreedt).

Helpdesker B krijgt Klant A aan de lijn.

Klant A legt uit dat hij niet in kan loggen op zijn mailbox.

Helpdesker B controleert of de mailbox werkt door er op in te loggen.

Valt te automatiseren....

Helpdesker B constateert dat inloggen inderdaad niet mogelijk blijkt.

Helpdesker B maakt een ticket 2 aan.

Vervolgens:

Tweede Lijner C ziet ticket 2 en besluit contact op te nemen met systeembeheer.

Systeembeheerder Q weet Tweede Lijner C te vertellen dat hij geen SMS gehad heeft. Als Tweede Lijner C wilt dat hij gaat kijken zal Systeembeheerder Q voorbeelden nodig hebben met wat er wanneer en waar niet lukt.

Denk je nou echt dat dit zo ingewikkeld ligt? Denk je nu echt dat de systeembeheerder op zijn lamme reet gaat liggen en zelf niet gaat testen? En waarom heeft Systeembeheerder Q geen sms gehad?

Tweede Lijner C gaat op zoek naar voorbeelden door dingen uit te proberen en foutmeldingen te noteren.

Allemaal op de mailbox van de klant? Nou, lekker.

Systeembeheerder Q meldt 30 minuten later terug dat het probleem gevonden en opgelost is.

Alternatief:

Systeembeheerder Q weet Tweede Lijner C te vertellen dat hij net een SMS gehad heeft en onderweg is naar huis om in te kunnen loggen op het netwerk om te kijken wat er mis is.

Systeembeheerder Q meldt 15 minuten later terug dat het probleem gevonden en opgelost is.

In beide gevallen is het gesprek met de klant al lang voorbij.[/i]

Moet de klant soms blijven wachten totdat er een oplossing is? En precies wanneer de klant belt werkt het netwerk niet meer net wanneer de Systeembeheerder naar huis ging.. Kies je de scenario's juist zo uit of lijkt dat maar zo?

[...]

Maar als het niet gewerkt had, had hij kunnen melden "Klopt, meneer ik zie dat het hier ook niet werkt".
Of als de betreffende medewerker constateert dat het werkt "Meneer, ik heb zojuist gecontroleert of het werkt en dat doet het".

Controleren of iets werkt kan ook door middel van een simpele interface..

Nogmaals, ik verdedig hier noodzaak tot praktisch uitproberen door in te loggen en dat het niet wettelijk verboden is.
Ik probeer hiet niet te verdedigen dat de medewerker het op dergelijke wijze als in de TS richting de klant communiceert.

Dat begrijp ik, maar het is niet nodig..

[...]

Dat zei ik ook niet. Ik zei dat het gebruik van scripts en eerste-lijnshelpdesk medewerkers al vaak niet samen gaat.


[...]


[...]

Het woord "vrijwel" komt er toch echt niet in voor. Leer zelf lezen. Het staat er echt alsof het in alle denkbare gevallen waar is.

En weer val je over één woordje!! Ik zeg vrijwel erbij omdat het natuurlijk nooit in alle gevallen kan zijn...

[...]

Als een wachtwoord wordt toegewezen is dat ook een vorm van 'afspreken'.
Als hij zijn wachtwoord op meerdere plekken gebruikt is dat zijn keuze.

Dat is jouw mening.. Dus alle werknemers van de ISP mogen het zomaar weten?

Om een wachtwoord te wijzigen dient hij het nieuwe wachtwoord door te geven aan de ISP. En of hij dat nu doet via een administratief computersysteem of via een helpdesk medewerker. Het blijft in beide gevallen dezelfde rechtspersoon. Je kunt vinden dat die helpdeskmedewerker er hierna niets meer mee te maken heeft, maar die helpdeskmedewerker vertegenwoordig wel dezelfde rechtspersoon als dat administratieve systeem.

Alleen die helpdeskmedewerker zal eerder kwade bedoelingen hebben dan dat administratief systeem.

[...]

Nogmaals, scripts kunnen geen probleem voorzien of interpreteren die niet bedacht zijn door de maker van die scripts. Ook ga je er klakkeloos van uit dat er voor iedere denkbare situatie scripts voor handen zijn of anders gemaakt kunnen worden. Droom lekker verder, maar dat is niet zo. Bij een ISP kunnen dingen zo vaak veranderen dat vrijwel ieder script van meer dan een half tot een heel jaar oud niet meer goed zal functioneren.

'de maker'... Denk je echt dat die dingen worden bedacht en gebouwd door 1 script.. En denk je ook echt dat de manier van inloggen elk half jaar veranderd.. Ik dacht het niet, volgens mij is inloggen op mailservers de laatste tijd niet zo drastisch veranderd hoor..

[...]

En ik weet het wel zeker. Maar dan nog, het tegenvoorbeeld van die credit-card geeft aan dat er ook financiele organisaties zijn die toch zonder codes en versleuteling kunnen werken.
Versleuteling en codering van wachtwoorden is dus niet persé een regel en dat was het doel achter dit argument. Verder ben ik wel blij dat we het eens zijn dat het wenselijk is dat banken hun pincodes bij hun medewerkers weg houden.

Dus als ik in de sloot spring doe jij het ook?

[...]

Maar in tegenstelling tot die bankmedewerker heeft hij geen aantoonbaar gewin bij het inzien van dat wachtwoord. Als het een pincode was had hij die kunnen gebruiken om geld te pinnen. Met een e-mailwachtwoord bij een ISP kun je al een stuk minder.

Het gaat om het principe, niet of het iets minder belangrijk is.. Veel mensen hechten net zoveel waarde aan hun wachtwoord als aan hun pincode, wat in mijn geval zo is.. Daarnaast, aan alleen een pincode heb je bar weinig.. Terwijl je met een wachtwoord meteen een hoop meer kan.

[...]

Nee, maar voor ninjazx9r98 zou het een serieuze optie moeten zijn als hij dat al niet gedaan heeft. Een klant die op zijn privacy gesteld is, moet gewoon naar een ISP toestappen die hij/zij vertrouwd. Vertrouwd hij zijn huidige ISP of de medewerkers aldaar niet (meer) dan kan hij beter van ISP wisselen. Persoonlijk heb ik er geen moeite mee dat iemand van een ISP-helpdesk mijn wachtwoorden in kan zien en in zou kunnen loggen op mijn mailbox. Ik vertrouw die ISP en de medewerkers aldaar dat ze er geen misbruik van zouden maken.

Als het niet nodig is, moet men dat ook niet doen..

[...]

Wat de schrijver er neergezet klopt als een bus. Het heeft alleen niets met het onderwerp in de TS te maken en JIJ interpreteert wat daar staat verkeerd.

Tot slot

Onderstaande ben ik het volledig mee eens en daarbij ga ik het laten, want het topic wordt er zo ook niet leesbaarder door. Ik denk dat het een kwestie van vertrouwen is tussen klant en bedrijf en verder ben ik van mening dat de medewerker in de TS het netter had kunnen en moeten doen, maar dat er feitelijk niets illegaals heeft plaatsgevonden.


[...]

En als de mailserver eruit ligt gaat dat niet.. Dan kan de helpdesk nog zo vaak proberen in te loggen op je webmail en namen voor gaan lezen, eerder gaat het toch niet werken.

Ik moet wel zeggen, ik heb flink gelachen om sommige reacties van je, bedankt hiervoor.

offtopic:
Wat een lange post

[alt-92]

ninjazx9r98 schreef op zaterdag 12 januari 2008 @ 17:28:
Die maildir heeft een owner zijnde de klant.

Nee.

Juridisch gezien is de ISP owner, de klant is slechts gebruiker daarvan (huurder, for the lack of a better term).
De maildir maakt onderdeel uit van de technische infrastructuur - zonder maildir is er geen plaats om de losse berichten te kunnen opslaan.
Losse berichten waar op de inhoud voornoemde rechten (auteursrecht) op zit.

Na het daadwerkelijk inloggen is toegang tot inhoud van email slechts een klein stapje verder.

Waarvan je in dit geval dient te bewijzen dat die kleine extra stap genomen is.
Je uit hier de beschuldiging dat toegang tot een mailbox direct inhoudt dat medewerkers zich toegang verschaffen tot de INHOUD van afzonderlijke mailbestanden.

Ik vroeg me al af wanneer de eerste met dat stukje zou komen wat ik bewust heb weggelaten.

Graag gedaan.

Het is je hopelijk toch wel opgevallen dat daar systeembeheerder staat ?
En dat het voorbeeld ook spreekt over uitgaande mail met als gevolg een instabiel systeem ?

Het is je ook opgevallen dat dat een voorbeeld was?

Of ben jij van mening dat de afdeling Juridische Zaken bij KPN een stelletje incompetente know-nots zijn dat ze dat niet afdekken in contracten, richtlijnen, en AV?

[ Voor 17% gewijzigd door alt-92 op 12-01-2008 18:01 ]

[JvS]

Steephh schreef op zaterdag 12 januari 2008 @ 17:47:
[...]


Stap voor stap begeleiden? Als een klant echt niet weet hoe hij in de mail moet?

http://webmail.provider.nl
gebruikersnaam intoetsen
wachtwoord intoetsen
<enter>
et voila..

Moeilijk... Tuurlijk, half Nederland weet niet hoe dat moet..

Ik weet niet of je weleens op een helpdesk gezeten hebt. Maar het zou je verbazen hoeveel mensen daar moeite mee hebben. Triviale zaken als een internetadres in de adresbalk tikken (De wat?), mensen die overal www voorzetten. Op die pagina vervolgens de u/p invulplek vinden, vervolgens die foutloos intikken aan de telefoon (dat is eng) en dan nog de foutmelding " gebruikersnaam is onjuist" geloven. (Nee hij doet het niet!!!! roepen en niet lezen wat er staat).

Ja, dat "kunt u even via uw webmail kijken of het uberhaupt nog werkt" is een hele leuke vraag, maar het getuigt niet echt van realiteitszin om te verwachten dat alle bellers dat kunnen .

[ninjazx9r98]

Gomez12 schreef op zaterdag 12 januari 2008 @ 16:34:
[...]

Ok, nog 1 poging dan :
- Je hebt beheerdersscripts die worden onderhouden en zijn in gebruik door beheerders, layout vd uitvoer te veel info geven etc is over het algemeen van secundair belang, omdat het toch alleen maar door beheerders gebruikt wordt. Dit zijn dus geen hobby-bob scripts en de standaard scripts waar jij op doelt.

Kun je mij even quoten waar ik het heb over standaard scripts ?
Ik heb een en ander bewust ruim omschreven juist omdat er zo veel mogelijk is met scripts.

- Je hebt een programma / tool voor de helpdesk. Hier moeten meerdere ondeskundige mensen gelijk mee kunnen werken, dit mag niet uitvallen want dan kan je de helpdesk bijna dichtgooien. Dit mag nooit en te nimmer te veel info geven omdat het dan de privacy van de klant raakt. Als een beheerder dit "even" gaat zitten scripten dan noem ik het inderdaad een hobby-bob script. De beheerder weet over het algemeen niet de preciese wetten en regels etc.

Mijn god, de hele discussie gaat over privacy en helpdeskmedewerkers die zomaar mailboxen binnen (kunnen) wandelen en dan begin jij over teveel informatie uit een tool die de privacy van de klant raakt ??
En dan maak je je ook nog druk om beheerders die geen wetten en regels kennen terwijl men het bij de helpdesk doodnormaal vindt om iemands mailbox binnen te gaan waarna er dus van privacy totaal geen sprake meer is ??
Als het je bedoeling was om verwarring te scheppen ben je daar nu iig goed in geslaagd.

Juist tooling/scripting kent bijna oneindig veel mogelijkheden om precies datgene te laten zien wat je wilt laten zien.
En als je bezorgd bent over het teveel aan info draait de tooling eerst op een test omgeving voor het live gaat.

Hij kent de gebruikers over het algemeen ook niet ( hoeveel ISP's hebben hun helpdesk niet gewoon bij een callcenter zitten ). Dus deze scripts moeten 100% waterdicht zijn, 100% duidelijk zijn voor de helpdesker, en 100% uptime hebben. Dat zie ik 99% van de beheerders nog niet bouwen, die zijn goed in het technisch bouwen, maar als het even niet werkt dan verandert een beheerder even het script en dat kan dus niet.

Geen idee met wat voor beheerders jij ervaring hebt, het zijn kennelijk alleen hele andere mensen dan daar waar ik ervaring mee heb.
Waarom zou een script overigens even niet werken ?
De logfile heeft ineens een heel ander formaat of staat op een andere plek ?
Lijkt me sterk maar de beheerder is de aangewezen persoon die nu juist zou moeten weten of er iets dergelijks aan de hand is.
Daarnaast is er in principe niets mis met het aanpassen van een script, dat is normaal onderhoud omdat je iets beter/slimmer wilt doen, omdat er een verzoek is gekomen om iets aan te passen enz enz.
Dat is gewoon normaal onderhoud net als het patchen/updaten van een systeem.

Btw kan jij eens een grove uren indicatie opgeven hoeveel tijd het zou kosten om deze scriptjes te gaan bouwen. Want als ik jouw verhaal zo zie is dit toch makkelijk binnen 1 dag te bouwen...

Ik mag toch hopen dat je zelf wel inziet dat deze vraag niet met enig goed fatsoen zomaar te beantwoorden is ?
Maar goed, basis informatie uit standaard logfiles halen, een en ander filteren, output naar een website.
Dat is inderdaad makkelijk binnen 1 dag te bouwen.
Probleem is natuurlijk alleen dat er totaal geen randvoorwaarden zijn, geen info over de omgeving waar dit zou moeten werken enz enz enz.
Met andere woorden een vraag die niet zomaar te beantwoorden is en iets zegt me dat ik dus bovenstaand antwoord weer op de een of andere manier om m'n oren krijg.

[...]

Yep, dit zijn dus de beheerdersscript. Waar dus maar een select personeel gebruik van maakt wat ook nog eens de kennis heeft om de scripts aan te passen als de output niet volstaat, helpdeskers maken hier dus geen gebruik van.

Spijtig maar je gaat niet door voor de magnetron.
Daar zitten namelijk ook gewoon scripts tussen waarvan de output naar een helpdesk oid gaat.
Wel grappig dat jij denkt te weten met wat voor scripts ik in aanraking kom.

[...]

Ging meer om het principe, zoals iemand hierboven al zei, verwijderen van een mailtje touched het bestand ook al. Het geeft gewoon alleen maar aan wanneer er iets met het bestand gebeurt is, het zegt niets over wanneer de laatste email binnengekomen is.

En dat is dus het hele probleem met voorbeelden als men zelf weigert na te denken maar in plaats daarvan alles letterlijk neemt en daar op verder gaat borduren.
Waar het om ging was het principe dat het vrij eenvoudig is om relevante informatie tevoorschijn te halen uit logfiles ed.
Het is alleen ondoenlijk om een voorbeeld te geven inclusief tig randvoorwaarden om te voorkomen dat iemand het volledig letterlijk neemt en daarmee aan de haal gaat.
Verwijderen van een mail zou het bestand touchen als iemand leave mail op server had aanstaan of andere voorwaarden.
Bij standaard poppen van email wordt het bestand 0 bytes.
Maar jij je zin :
server:/# grep From /var/mail/klant
Even een filtertje er overheen en je hebt alle datums plus tijdstippen van binnengekomen mail.

En ongetwijfeld zal er nu wel weer iemand komen met een opmerking waarom dat niet werkt in bepaalde gevallen.
Dus nog even voor de duidelijkheid, het is een voorbeeld en meer niet.

[...]

Ik denk inderdaad dat beheerders kundig zijn, en ze mogen / moeten ook scripts schrijven om het beheer makkelijker te maken, maar dat zijn wel beheersscripts.

En waarom dan ?
Waarom zou er geen script mogen bestaan dat afgetrapt wordt vanaf een webinterface en wat bepaalde informatie terug geeft aan bijvoorbeeld een helpdesk ?
Wat is daar nu fundamenteel mis mee ?

[...]

En dan is het dus geen simpel script meer, wat even kijkt wat de laatste wijzigingsdatum van een bestand is, nee er moet gelijk een layout overheen etc., het moet op te roepen zijn vanaf iets anders dan de shell, in een serverpark waarbij gebruikers a/h op server 1 staan, en gebruikers i/z op server 2 moet het script dit ook gelijk goeddoen. Ook als er een server bijkomt.
Terwijl een beheerder alleen maar even hoeft te weten wat de gebruikersnaam is, hij weet uit zijn hoofd / documentatie welke server het is, en draait daar even een scriptje, klopt de documentatie niet meer, niet erg. De beheerder logt gewoon wel even in op de juiste machine, 5 sec extra werk. Met een scripts betekent het gelijk dat de helpdesker er niet meer bij kan, hij moet een call aanmaken naar systeembeheer, en krijgt de volgende dag de melding dat het opgelost is...

Hoe moeilijk denk je dat het is om bijv een if then structuur op te nemen in een script ?
Denk je nu echt dat het heel spannend is om de eerste letter van de klantnaam die een helpdesker inklopt en submit op een website te controleren en aan de hand daarvan de juiste server te selecteren ?
En als er een server bijkomt zal die beheerder dat niet weten en ook niet weten dat het van invloed kan zijn op scripts ed ?
Enige wat je steeds lijkt te insinueren is dat systeembeheers een stelletje dombo's zijn die maar wat aan lopen te rommelen en dus eigenlijk niet weten waar ze mee bezig zijn.
Als dat je ervaring is met systeembeheerders vindt ik dat oprecht spijtig voor je.

[...]

Nou, laat ik het zo zeggen, ik heb het nog nooit gezien dat een monitoring systeem automatisch een melding doorgeeft aan de helpdesk. Beheerders krijgen een melding waar zij iets mee kunnen, en zij geven dit door aan de helpdesk in termen waar de helpdesk iets mee kan.
Dat server15 eruit ligt heeft de helpdesk niets aan, dat alle gebruikers met inlognaam x/y niet meer bij hun mail kunnen daar heeft de helpdesk wel iets aan. Of jij zet dit soort info allemaal in je monitoring systeem?

Ik kan je verklappen dat er systemen zijn die monitoring doen van hardware, software, services en op allerlei mogelijke manieren allerlei mensen kunnen inlichten.
Dat inlichten kan gaan met vantevoren ingestelde teksten inclusief mogelijke oplossingen.
Openview Operations is bijvoorbeeld een product wat dat kan.
Kost overigens wel een paar centen maar dan heb je ook wat.
Heb geen idee of er providers zijn die dit specifieke product gebruiken maar het is dan ook meer om aan te geven dat het allemaal gewoon mogelijk is.

[...]

Ooit wel eens op een consumenten helpdesk gezeten? 15 jaar terug toen ik dat deed toen veranderde er nooit iets bij de klant, en vorige week deed hij het nog wel. Oh, dat de klant de router heeft uitgeschakeld dat vermeld hij niet, hij zegt alleen dat zijn internet het niet doet. En dat er niets veranderd is.

En wat verandert er aan dat feit als je als helpdesker die mailbox in kan ?
Het binnengaan van die mailbox heeft bij bovenstaande net zo veel/weinig toegevoegde waarde als het via scripting kunnen aantonen dat er mail binnenkomt en dat er een uur eerder mail opgehaald is.
Toegang tot de mailbox heeft dus totaal geen toegevoegde waarde op dat moment en lost ook het probleem niet op.

[...]

Beheerdersscripts daar klopt dit stukje volledig voor, daar ben ik het ook wel mee eens, maar het gaat hier niet om beheerdersscripts. Het gaat hier om een tool voor de helpdeskers die 0,0 verstand hebben ( moet je van uitgaan ).
Als een beheerdersscript een inhoud van een mailbox toont door een foutje denk ik niet dat iemand er een probleem van maakt, maar als de helpdeskers hetzelfde onder ogen krijgen dan zit je weer op het beginpunt van dit topic.

Scripts en zelf ontwikkelde tooling test je eerst in een ontwikkelomgeving.
Als je het goed doet gaat het daarna naar een acceptatieomgeving en als laatste naar productie.
Acceptatieomgeving realiseer ik me van dat dat maar weinigen gegeven is maar test is niet zo heel bijzonder.
Daarnaast zie ik een wezenlijk verschil tussen een fout script wat een mailbox toont en vervolgens (mag ik aannemen tenminste) gerepareerd wordt en een helpdesk die per definitie inlogt op een mailbox bij problemen.

[...]

Maar de scripts kunnen toch ook indexen aanmaken, heck man, je kan gewoon eventjes een logparser schrijven die de geschikte output naar een db gooit. Waarna het door indexen goed te doorzoeken is. Oh, is dit geen simpel scriptje meer?

Laten we het er maar op houden dat je het met Unix achtigen zo gek kunt maken als je zelf wilt.
En of iets een simpel scriptje is ligt aan de kennis van de beheerder.
Met php, perl, mysql ed kun je in ieder geval een heel eind komen.
Overigens heb ik het idee dat er juist bij ISP's heel veel capabele mensen rondlopen en er ook heel wat afgescript wordt.
Juist de omgeving van een ISP is daar uitermate geschikt voor.

[...]

Ik denk dat men er meer over valt dat de helpdeskmedewerker met 1 klik dan de inhoud kan lezen, of het gemeld wordt of niet dat is een 2e.
Maar imho is dit een niet te voorkomen probleem zonder dat er echt veel geld tegenaan gegooid wordt.

Volgens mij moet je er juist geld tegenaan gooien als je die medewerkers plaintext wachtwoorden wilt laten zien en toegang wilt geven tot mailboxen.
Ik kan in ieder geval niet zomaar een systeem opnoemen met plaintext wachtwoorden en dat default bepaalde gebruikers toegang geeft tot alle mailboxen.
Bij een gemiddeld systeem zul je op z'n minst moeite moeten doen om tot zo'n configuratie te komen.

[Gomez12]

Steephh schreef op zaterdag 12 januari 2008 @ 17:47:
[...]

Genoeg voorbeelden van mensen in dit topic die aangeven dat dit niet zo is.. En logbestanden zijn makkelijk te indexeren, of denk jij dat er één logbestand op een raid array van 1200gb staat waarin wordt gezocht? Sorteren per klant en op datum en daarvan verschillende logbestanden maken (per week bijvoorbeeld) is niet zo moeilijk..

Niet zo moeilijk, maar op dit moment niet aanwezig dus een aanpassing.
Je lijkt wel mijn ex-collega die zegt dat alles niet moeilijk is, een webpagina een pagerank toekennen is niet moeilijk, een webpagina doorzoeken op keywords is niet moeilijk , een zoekalgoritme opstellen is niet moeilijk / bestaan er al genoeg freeware van dus google is niet moeilijk na te bouwen.

[...]
Hoezo ben je gek? Dat kan ik beter aan jou vragen..Wilde je soms 200.000 klanten in een file proppen?

Yep, standaard gebeurt dit wel. Een beheerder wenst geen 200.000 losse bestandjes te doorzoeken om een algemeen probleem te signaleren, hij wenst 1 bestand.
Een beheerder wil een logging hebben die iets zegt over het totale systeem, als er 1 mailbox van die 200.000 problemen geeft is dit voor de beheerder niet boeiend zolang de klant er geen melding van maakt, als dit er 50.000 zijn dan is het voor de beheerder wel boeiend.

Oh, laat me raden. Een beheerder kan zo een script schrijven wat 200.000 losse bestandjes samenvoegt voor zijn eigen gemak.

Nee, helemaal niet. Je denkt er veel te moeilijk over.. Welke foutmelding zie je in de webmail staan die zogenaamd zo moeilijk na te bootsen is in een aparte interface..

Eigenlijk elke foutmelding die bij een nieuwe webmail interface erin gestopt wordt. Of denk jij serieus dat elke provider zijn eigen webmail inplementatie schrijft, dit zijn gewoon standaard scripts / pakketjes waar een template overheen gegooid wordt. Dus een nieuw webmail pakket kan best foutmeldingen hebben die nog niet in de aparte interface staat.
Oh,nee natuurlijk een nieuw webmail pakket wordt eerst door de beheerders van top tot teen doorgelopen om alle foutmeldingen te kopieren en te plakken in de aparte interface.
Het idee dat een nieuwe webmail interface eerst getest wordt en daarna online gegooid is natuurlijk waanzin, elke isp loopt eerst alle regels code door om alles te ondervangen... Ik weet echt niet waar jij de tijd vandaan haalt.

Dan vraag ik me toch af wat die mensen achter een computer doen..

Dat kan jij je afvragen, maar zolang die mensen betalen zal een isp zich dat echt niet afvragen en er alleen maar rekening mee moeten houden.

[...]
Dan kan je hem toch ook niet helpen..
Klant: mail doet het niet
Helpdesk: kunt u iets preciezer zijn, wat werkt er niet?
Klant: mijn mail
Helpdesk: welke mailclient gebruikt u?
Klant: wat?
Helpdesk: Gebruikt u Outlook Express?
Klant: ja volgens mij wel ja
Helpdesk: wat voor foutmelding krijgt u wanneer u uw mail op wilt halen?
Klant: foutmelding? die kan ik niet lezen..

Stel je je het zo voor?
...
Een foutmelding voorlezen die OE geeft is niet zo moeilijk..

Dat was in mijn tijd wel het standaard niveau van de gebruiker ja. En vroeger belden er genoeg mensen vanaf de zaak omdat ze thuis een probleem hadden, geen foutmeldingen opgeschreven, eigenlijk helemaal niets gedaan. En als je ze dan vraagt om zelf webmail te gaan controleren dan kunnen ze dat niet live checken, dus eerst alles letterlijk voorlezen zodat zij het kunnen opschrijven, dan gaat de klant het thuis proberen, en de volgende dag belt de klant met dat het hiermee ook niet lukt, ohja ze zijn de foutmelding wederom vergeten op te schrijven.

Denk je nou echt dat dit zo ingewikkeld ligt? Denk je nu echt dat de systeembeheerder op zijn lamme reet gaat liggen en zelf niet gaat testen?

Denk jij nou echt dat een systeembeheerder met 200.000 mailboxen zelf 1 mailbox gaat testen om te zien wat de foutmeldingen zijn, daar heeft hij een dagtaak aan. Systeembeheerder krijgt een foutmelding en kan in ongeveer 90% van de tijd een standaardmailtje terugsturen naar de helpdesker omdat de foutmelding uitvoerig beschreven staat in de interne faq / intranet die de helpdesker niet goed gelezen heeft.

[...]
Allemaal op de mailbox van de klant? Nou, lekker.

Daar zit het probleem toch? Als het een algemeen probleem is dan is het ( als het goed is ) wel bekend, of zeg jij gewoon tegen een klant die zegt dat hij niet kan inloggen dat het bij jouw test-mailbox wel goed gaat dus dat de klant iets fout doet.

[...]
Controleren of iets werkt kan ook door middel van een simpele interface..

Maar die interface is niet zo simpel om te bouwen, en de huidige webmail oplossing heeft hier al een redelijk mechanisme voor, waarom geld en moeite doen terwijl je al een middel hebt ( webmail ) , het gaat dan alleen nog maar om het gebruik van het middel en het misbruik wat er mee kan gebeuren.

[...]
'de maker'... Denk je echt dat die dingen worden bedacht en gebouwd door 1 script..

Ik zal ook wel vallen over 1 woord, maar het simpele script is dus niet 1 script het wordt niet onderhouden door 1 systeembeheerder. Hmmm, lijkt erop alsof je toch begint toe te geven dat het misschien toch iets uitgebreider moet zijn dan 1 simpel script...

[ninjazx9r98]

alt-92 schreef op zaterdag 12 januari 2008 @ 17:51:
[...]

Nee.

Juridisch gezien is de ISP owner, de klant is slechts gebruiker daarvan (huurder, for the lack of a better term).
De maildir maakt onderdeel uit van de technische infrastructuur - zonder maildir is er geen plaats om de losse berichten te kunnen opslaan.
Losse berichten waar op de inhoud voornoemde rechten (auteursrecht) op zit.

Technische owner zijnde het account van de klant inclusief wachtwoord waarmee de klant zich bekend maakt aan het systeem.
De hardware is uiteraard eigendom van de provider.
De mailbox plus inhoud is van de klant of huurder zoals je het net noemt.

[...]

Waarvan je in dit geval dient te bewijzen dat die kleine extra stap genomen is.
Je uit hier de beschuldiging dat toegang tot een mailbox direct inhoudt dat medewerkers zich toegang verschaffen tot de INHOUD van afzonderlijke mailbestanden.

Waar uit ik die beschuldiging ?
Men heeft toegang tot de maildir en dus automatisch ook tot de inhoud.
Nergens zie je mij zeggen dat ze zich daadwerkelijk toegang verschaffen tot die berichten.
Men is binnengedrongen in het domein van iemand anders zonder daar rechten toe te hebben.
Om maar even terug te komen op de huurder die je eerder noemde, een huurhuis is geen eigendom van de huurder en toch heeft de eigenaar daarbinnen niets te zoeken ook al zou hij niets mee nemen en slechts een rondje lopen in dat huis.

[Steephh]

JvS schreef op zaterdag 12 januari 2008 @ 18:10:
[...]
Ik weet niet of je weleens op een helpdesk gezeten hebt. Maar het zou je verbazen hoeveel mensen daar moeite mee hebben. Triviale zaken als een internetadres in de adresbalk tikken (De wat?), mensen die overal www voorzetten. Op die pagina vervolgens de u/p invulplek vinden, vervolgens die foutloos intikken aan de telefoon (dat is eng) en dan nog de foutmelding " gebruikersnaam is onjuist" geloven. (Nee hij doet het niet!!!! roepen en niet lezen wat er staat).

Ja, dat "kunt u even via uw webmail kijken of het uberhaupt nog werkt" is een hele leuke vraag, maar het getuigt niet echt van realiteitszin om te verwachten dat alle bellers dat kunnen .

Ik neem aan dat dat wel de uitzonderingen zijn. Maar dan nog, als de helpdesk zegt dat ze nog gewoon kunnen inloggen, dat is toch voldoende. Waarom moet er perse een naam/emailadres en datum worden genoemd?

[Steephh]

Gomez12 schreef op zaterdag 12 januari 2008 @ 18:28:
[...]

Niet zo moeilijk, maar op dit moment niet aanwezig dus een aanpassing.
Je lijkt wel mijn ex-collega die zegt dat alles niet moeilijk is, een webpagina een pagerank toekennen is niet moeilijk, een webpagina doorzoeken op keywords is niet moeilijk , een zoekalgoritme opstellen is niet moeilijk / bestaan er al genoeg freeware van dus google is niet moeilijk na te bouwen.

Het is niet zo moeilijk als jij je voorsteld. Google heeft te maken met veel en veel en veeeeel grotere datastromen en hen lukt het ook. Voorbeelden genoeg in dit topic hoe dit gemakkelijk gaat en zo lang duurt dit echt niet!

[...]

Yep, standaard gebeurt dit wel. Een beheerder wenst geen 200.000 losse bestandjes te doorzoeken om een algemeen probleem te signaleren, hij wenst 1 bestand.
Een beheerder wil een logging hebben die iets zegt over het totale systeem, als er 1 mailbox van die 200.000 problemen geeft is dit voor de beheerder niet boeiend zolang de klant er geen melding van maakt, als dit er 50.000 zijn dan is het voor de beheerder wel boeiend.

Oh, laat me raden. Een beheerder kan zo een script schrijven wat 200.000 losse bestandjes samenvoegt voor zijn eigen gemak.

Je gooit het echt door elkaar of niet? Het ging toch om een klant specifiek probleem waarvoor de log files geanalyseerd moeten worden? Dan heb je ook niets aan een bestand voor een algemeen probleem.. En als het probleem algemeen is dan zou het probleem in elke logfile voor moeten komen..

[...]

Eigenlijk elke foutmelding die bij een nieuwe webmail interface erin gestopt wordt. Of denk jij serieus dat elke provider zijn eigen webmail inplementatie schrijft, dit zijn gewoon standaard scripts / pakketjes waar een template overheen gegooid wordt. Dus een nieuw webmail pakket kan best foutmeldingen hebben die nog niet in de aparte interface staat.
Oh,nee natuurlijk een nieuw webmail pakket wordt eerst door de beheerders van top tot teen doorgelopen om alle foutmeldingen te kopieren en te plakken in de aparte interface.
Het idee dat een nieuwe webmail interface eerst getest wordt en daarna online gegooid is natuurlijk waanzin, elke isp loopt eerst alle regels code door om alles te ondervangen... Ik weet echt niet waar jij de tijd vandaan haalt.

LOL

Denk je nu echt dat die provider even een webmail online gooit in 10 minuten zonder er verder naar te kijken.. Dat ten eerste

Ten tweede gaat men niet alle foutmeldingen kopieren en in een aparte interface zetten. Jij praat erover of het 1000'en foutmeldingen zijn.. De interface hoeft in principe maar enkele foutmeldingen te geven waaraan de helpdesker kan zien wat het probleem is..

[...]

Dat kan jij je afvragen, maar zolang die mensen betalen zal een isp zich dat echt niet afvragen en er alleen maar rekening mee moeten houden.

[...]

Dat was in mijn tijd wel het standaard niveau van de gebruiker ja. En vroeger belden er genoeg mensen vanaf de zaak omdat ze thuis een probleem hadden, geen foutmeldingen opgeschreven, eigenlijk helemaal niets gedaan. En als je ze dan vraagt om zelf webmail te gaan controleren dan kunnen ze dat niet live checken, dus eerst alles letterlijk voorlezen zodat zij het kunnen opschrijven, dan gaat de klant het thuis proberen, en de volgende dag belt de klant met dat het hiermee ook niet lukt, ohja ze zijn de foutmelding wederom vergeten op te schrijven.

Dan nog, dat de internetprovider dan zo gemakszuchtig is om de wachtwoorden in plaintext op te slaan wat nergens voor nodig is en de helpdeskmedewerkers toegang te geven tot de webmail.. Dat is nergens voor nodig.

[...]

Denk jij nou echt dat een systeembeheerder met 200.000 mailboxen zelf 1 mailbox gaat testen om te zien wat de foutmeldingen zijn, daar heeft hij een dagtaak aan. Systeembeheerder krijgt een foutmelding en kan in ongeveer 90% van de tijd een standaardmailtje terugsturen naar de helpdesker omdat de foutmelding uitvoerig beschreven staat in de interne faq / intranet die de helpdesker niet goed gelezen heeft.

In jouw voorbeeld loste de systeembeheerder het op.. Als de helpdesker het zelf niet kan oplossen, wat in veel van de technische gevallen wel het probleem zal zijn moet hij sowieso naar de systeembeheerder toestappen.. Hij toch bijna geen kennis?

[...]

Daar zit het probleem toch? Als het een algemeen probleem is dan is het ( als het goed is ) wel bekend, of zeg jij gewoon tegen een klant die zegt dat hij niet kan inloggen dat het bij jouw test-mailbox wel goed gaat dus dat de klant iets fout doet.

In jouw voorbeeld was de server niet goed werkende, er kon niet op worden ingelogd.. Die ene klant is dan echt niet de enige die er last van heeft, dus hoeft men niet in die mailbox te gaan wriemelen.. Ben benieuwd wat je daar sowieso moet doen als men niet kan inloggen.

[...]

Maar die interface is niet zo simpel om te bouwen, en de huidige webmail oplossing heeft hier al een redelijk mechanisme voor, waarom geld en moeite doen terwijl je al een middel hebt ( webmail ) , het gaat dan alleen nog maar om het gebruik van het middel en het misbruik wat er mee kan gebeuren.

Omdat dat ten koste gaat van de privacy.. Waarom moet het altijd via de gemakkelijkste weg? Het gaat er uiteindelijk om wat het praktische is EN!!!! wat de grootste veiligheid biedt.. Een interface die controleerd of je bijvoorbeeld nog kan inloggen is echt niet zo moeilijk.. Je praat erover alsof het maanden duurt om zoiets te schrijven.. Ik denk overigens dat de webmail die de meeste providers gebruiken lang niet zo uitgebreid is.

[...]

Ik zal ook wel vallen over 1 woord, maar het simpele script is dus niet 1 script het wordt niet onderhouden door 1 systeembeheerder. Hmmm, lijkt erop alsof je toch begint toe te geven dat het misschien toch iets uitgebreider moet zijn dan 1 simpel script...

Heb ik gezegd dat het maar één script is? Ik heb het steeds gehad over een interface, niet over een script... Natuurlijk, voor specifieke toepassingen gebruik je maar 1 script ja, dat is logisch..

[Gomez12]

ninjazx9r98 schreef op zaterdag 12 januari 2008 @ 18:22:
[...]
Kun je mij even quoten waar ik het heb over standaard scripts ?
Ik heb een en ander bewust ruim omschreven juist omdat er zo veel mogelijk is met scripts.

Jij hebt het er niet over gehad. Maar simpele scripts voor een heldesk bestaan bijna niet juist door alle randvoorwaarden die veel minder gelden voor beheerdersscripts.

[...]

Mijn god, de hele discussie gaat over privacy en helpdeskmedewerkers die zomaar mailboxen binnen (kunnen) wandelen en dan begin jij over teveel informatie uit een tool die de privacy van de klant raakt ??

Dus jij wilt scripts gaan maken die niet waterdicht zijn, waardoor je iemand laat scripten terwijl het risico blijft bestaan???
En btw uit logfiles kan ik echt wel iets meer privacy gegevens halen dan uit een webmail. Omdat ik dan opeens alle verkeersgegevens onder mijn handen heb. Het gevaar is dan imho iets groter dan met een webmail interface.
Als er message logging aanstaat dan krijg ik feitelijk de gegevens die in de webmail staan ++.

Waarom zou een script overigens even niet werken ?

Ehhm, omdat het script niet overal 100% rekening mee houdt???

De logfile heeft ineens een heel ander formaat of staat op een andere plek ?
Lijkt me sterk maar de beheerder is de aangewezen persoon die nu juist zou moeten weten of er iets dergelijks aan de hand is.

Jawel, maar is de helpdesk zo belangrijk dat er bij de overgang naar een nieuwe mailserver rekening gehouden moet worden met dit helpdesk script?

Daarnaast is er in principe niets mis met het aanpassen van een script, dat is normaal onderhoud omdat je iets beter/slimmer wilt doen, omdat er een verzoek is gekomen om iets aan te passen enz enz.
Dat is gewoon normaal onderhoud net als het patchen/updaten van een systeem.

Hallo, blijf je wel in het oog houden waar het hier over gaat, een script wat helpdeskers andere informatie toont dan ze nu krijgen.
Het is echt geen core-business script ofzo hoor.

[...]
Ik mag toch hopen dat je zelf wel inziet dat deze vraag niet met enig goed fatsoen zomaar te beantwoorden is ?

Nou, als ik lees dat standaard webmail nu voldoende info geeft voor de helpdeskers en je hebt een aantal mensen die zeggen dat het teveel info geeft lijkt het me toch dat het redelijk te beantwoorden zou moeten zijn. Alle randvoorwaarden zitten in de webmail, alleen moet er iets minder info getoond worden.

Probleem is natuurlijk alleen dat er totaal geen randvoorwaarden zijn, geen info over de omgeving waar dit zou moeten werken enz enz enz.
Met andere woorden een vraag die niet zomaar te beantwoorden is en iets zegt me dat ik dus bovenstaand antwoord weer op de een of andere manier om m'n oren krijg.

Niet lullig bedoeld, maar iets als squirrelmail draait bij veel providers, onafhankelijk van omgeving etc. En volgens mij zoeken jullie eigenlijk iets wat dit ook doet, alleen moet het iets minder info tonen, dus volgens mij zijn de randvoorwaarden redelijk bekend. Info over de omgeving is ook niet nodig, het zijn toch allemaal mailservers?
Of wil jij een specifiek script hebben wat alleen werkt voor provider x met mailserver y?

Waar het om ging was het principe dat het vrij eenvoudig is om relevante informatie tevoorschijn te halen uit logfiles ed.
Het is alleen ondoenlijk om een voorbeeld te geven inclusief tig randvoorwaarden om te voorkomen dat iemand het volledig letterlijk neemt en daarmee aan de haal gaat.

Nee, waar het over ging is of dat helpdeskers webmail toegang moeten hebben of dat dit ook makkelijk via scripts te regelen is, omdat squirrelmail (= implementatie webmail ) redelijk systeemonafhankelijk is denk ik dat je zelf al het antwoord geeft door te zeggen dat je voor de scripts al randvoorwaarden nodig hebt etc.

En waarom dan ?
Waarom zou er geen script mogen bestaan dat afgetrapt wordt vanaf een webinterface en wat bepaalde informatie terug geeft aan bijvoorbeeld een helpdesk ?
Wat is daar nu fundamenteel mis mee ?

Ho even, over wat voor scripts hebben we het nu? Hebben we het nu over een script wat 3 regels is en een simpel grep commando uitvoert of over een script wat allemaal dingen controleert, output format volgens bestaande regels en dan doorzet naar een database?
Want ik heb het over het 3-regelige grep script wat hier eerder genoemd als vervanger voor webmail werd en wat iedereen kan schrijven, dit gaat nooit werken vanaf helpdeskers. Dit is gewoon een nogo.
Maak je een uitgebreider script met controles etc dan kan het best afgetrapt worden vanaf een webinterface en outputten naar helpdesk maar dan heb je heb je het niet meer over een simpel script wat iedereen even in elkaar zet, dan ga je eerder praten over een programma dan een simpel script.

Hoe moeilijk denk je dat het is om bijv een if then structuur op te nemen in een script ?
Denk je nu echt dat het heel spannend is om de eerste letter van de klantnaam die een helpdesker inklopt en submit op een website te controleren en aan de hand daarvan de juiste server te selecteren ?
En als er een server bijkomt zal die beheerder dat niet weten en ook niet weten dat het van invloed kan zijn op scripts ed ?
Enige wat je steeds lijkt te insinueren is dat systeembeheers een stelletje dombo's zijn die maar wat aan lopen te rommelen en dus eigenlijk niet weten waar ze mee bezig zijn.

Dat probeer ik niet te insinueren, alleen het begon ermee dat het via simpele scripts die iedereen kon schrijven ook op hetzelfde niveau te controleren was als met webmail.
Nu ga jij meer en meer naar een uitgebreider script toe, waarbij je een ontwikkelomgeving wilt hebben, je wilt een acceptatie omgeving hebben, je wilt onderhouds tijd hebben voor dit script, je betrekt er zijdelings even openview bij. Bedenk wel dat dit allemaal nog niet bestaat, en dat de helpdeskers op dit moment deze gegevens ook al hebben.

Akkoord het is te scripten, maar ik bedoelde ook nooit te zeggen dat het theoretisch niet te scripten valt, maar ik zie geen enkele ISP dit op zo'n manier oppakken.
Jij hebt het over een professionele oplossing die wel te bouwen is via scripten maar die veel, heel veel geld kost, ik heb het over de eerdergenoemde simpele scripts die wel eventjes webmail gaan vervangen. Dit kan imho dus niet voor het geld wat een ISP bereid is uit te geven voor een helpdesk.

Ik kan je verklappen dat er systemen zijn die monitoring doen van hardware, software, services en op allerlei mogelijke manieren allerlei mensen kunnen inlichten.
Dat inlichten kan gaan met vantevoren ingestelde teksten inclusief mogelijke oplossingen.
Openview Operations is bijvoorbeeld een product wat dat kan.
Kost overigens wel een paar centen maar dan heb je ook wat.
Heb geen idee of er providers zijn die dit specifieke product gebruiken maar het is dan ook meer om aan te geven dat het allemaal gewoon mogelijk is.

Ik kan je wel vertellen ( met 99% zekerheid ) dat er geen providers zijn die openview rechtstreeks meldingen laten versturen naar 1e lijns helpdeskmedewerkers.
Ik ken wel enkele ( welgeteld 2 )providers met openview, maar geen enkele haalt het in zijn hoofd om de meldingen door te sturen naar 1e lijns helpdeskers.
Puur vanwege het feit dat deze helpdesk uitbesteed is aan een callcenter, te veel verloop dus. openview geeft een melding aan beheer / 2e lijns. beheer / 2e lijns maakt zelf een mailtje naar 1e lijns met een niet technische vertaling.
Ja, het kan wel, maar vanwege verloop + algemene technische kennis 1e lijns helpdeskers is dit niet zinvol.

en lost ook het probleem niet op.

1e lijns moet ook geen technische isp-problemen oplossen, ze moeten ze signaleren en doorgeven.
1e lijns moet alleen de client-side problemen oplossen. Server-side hebben zij niets mee te maken, daar moeten zij de klant fatsoenlijk kunnen afwimpelen.

Overigens heb ik het idee dat er juist bij ISP's heel veel capabele mensen rondlopen en er ook heel wat afgescript wordt.

Op de backend weet ik dat er bij isp's heel veel capabele mensen rondlopen, maar op de 1e lijns ( sorry voor de mensen die daar werken ) zitten deze niet, als je fulltime 1e lijns bent en je bent capabel schuif je al heel snel door in de organisatie, 1e lijns is imho toch echt de vakantie werkers / parttimers / callcenters waar je beleefd de telefoon moet kunnen oppakken en de klant op een beleefde manier het standaard callscript moet laten doorlopen. Door technische kennis is menig 1e lijns medewerker niet gehinderd imho.
En nu is het gewoon wachten op de mensen die dit een flame vinden, zo is het niet bedoeld, maar simpel voorbeeldje als ik naar mijn isp bel dan vraag ik altijd naar persoon x, want de rest wil eerst het hele call-script aflopen of alle instellingen wel goed staan. Terwijl persoon x gewoon weet dat mijn instellingen 99% goed staan en dat het of een probleem aan hun kant is of er staat bij mij een obscure instelling fout.

[ninjazx9r98]

Steephh schreef op zaterdag 12 januari 2008 @ 17:47:
[...]

Genoeg voorbeelden van mensen in dit topic die aangeven dat dit niet zo is.. En logbestanden zijn makkelijk te indexeren, of denk jij dat er één logbestand op een raid array van 1200gb staat waarin wordt gezocht? Sorteren per klant en op datum en daarvan verschillende logbestanden maken (per week bijvoorbeeld) is niet zo moeilijk..

Dat Google een index gebruikt is niet meer dan logisch maar denk er gewoon eens wat verder over na.
Hoe groot Google is is niet bekend, volgens schattingen heeft men 450.000 servers wereldwijd.
Hoe groot de index is (totaal aantal items) is lastig te vinden, enkele sites noemen 24 miljard items ergens richting eind 2005.
Je zult je al snel beseffen dat ook bij het gebruik van indexering de hoeveelheid data die doorgespit moet worden enorm is en dat dit razendsnel gebeurt.
Natuurlijk is het niet 1 op 1 terug te voeren op logfiles waar we het over hadden maar het geeft aan dat je grote hoeveelheden data best snel kunt verwerken.
En uiteraard heeft men allerlei slimme algoritmes ed maar het gaat om het principe van het zogenaamd niet snel kunnen verwerken van grote hoeveelheden data.

[Gomez12]

Steephh schreef op zaterdag 12 januari 2008 @ 19:23:
[...]


Het is niet zo moeilijk als jij je voorsteld. Google heeft te maken met veel en veel en veeeeel grotere datastromen en hen lukt het ook. Voorbeelden genoeg in dit topic hoe dit gemakkelijk gaat en zo lang duurt dit echt niet!

Hmmm, dus over 2 weken zien we een concurrent van Google van jouw hand?

[...]
Je gooit het echt door elkaar of niet? Het ging toch om een klant specifiek probleem waarvoor de log files geanalyseerd moeten worden? Dan heb je ook niets aan een bestand voor een algemeen probleem.. En als het probleem algemeen is dan zou het probleem in elke logfile voor moeten komen..

Hmm, ik dacht dat het over algemeen 1e lijns indicatie ging, en dat ik vond dat die juist geen log-info nodig had. Dat een webmail juist volstaat. En dat als je een log gaat interpreteren dat je dan imho vele problemen gaat tegenkomen.
Dat iemand dan komt met een totaal onrealistisch beeld als dat er een log per gebruiker dat probeer ik te stoppen.

[...]
Denk je nu echt dat die provider even een webmail online gooit in 10 minuten zonder er verder naar te kijken.. Dat ten eerste

Ten tweede gaat men niet alle foutmeldingen kopieren en in een aparte interface zetten. Jij praat erover of het 1000'en foutmeldingen zijn.. De interface hoeft in principe maar enkele foutmeldingen te geven waaraan de helpdesker kan zien wat het probleem is..

Ter simplificatie : Ja, ik denk inderdaad dat een provider een standaard script pakt om het zo snel mogelijk en zo generiek mogelijk geregeld te hebben. Als hij elke code regel wou napluizen had hij beter zelf een webmail client kunnen schrijven, dit is toch niet zo moeilijk?

Dan nog, dat de internetprovider dan zo gemakszuchtig is om de wachtwoorden in plaintext op te slaan wat nergens voor nodig is en de helpdeskmedewerkers toegang te geven tot de webmail.. Dat is nergens voor nodig.

Plaintext opslaan keur ik vziw ook nergens goed, dit is gewoon fout.
Webmail toegang kan ik wel bedenken wat het nut is, dat er misbruik van gemaakt kan worden zie ik wel, maar dit is te ondervangen door goede procedures en naleving hiervan...
Een een compleet uitgebreid script gaan schrijven met een test acceptatie omgeving dat zie ik geen enkele isp gaan opzetten, het kan wel, maar ik zie het niet gebeuren.

[...]
In jouw voorbeeld was de server niet goed werkende, er kon niet op worden ingelogd.. Die ene klant is dan echt niet de enige die er last van heeft, dus hoeft men niet in die mailbox te gaan wriemelen.. Ben benieuwd wat je daar sowieso moet doen als men niet kan inloggen.

Maar de logging was toch per klant ( Dus sysbeheer heeft geen eigen log )? Of is er volgens jou een logging per klant, een logging per domein, een logging per server, een logging per serverpark. Zoals jij zelfs ( volgens mij ) al eens zei : Een mailserver is niet zo ingewikkeld. En gaat zeker niet zoveel log-files bijhouden.
Dus of het is per klant en dan heeft de beheerder geen inzicht in het feit dat 5000 mensen niet kunnen inloggen op hun webmail want de server draait technisch goed, alleen per klant gaat er iets fout. Of het is 1 algemene logging waardoor het per klant niet meer zo snel te traceren valt.

Omdat dat ten koste gaat van de privacy.. Waarom moet het altijd via de gemakkelijkste weg? Het gaat er uiteindelijk om wat het praktische is EN!!!! wat de grootste veiligheid biedt.. Een interface die controleerd of je bijvoorbeeld nog kan inloggen is echt niet zo moeilijk..

Laten we het wel een beetje realistisch houden aub. de grootste veiligheid is een grot in de bergen van afghanistan. Daar vind zelfs de VS je niet.
De gemiddelde consument wil de grootste veiligheid wat betreft zijn email adres, want hij wil geen spam. Maar toch wil hij dat truus die 30 jaar geleden bij hem op school zat hem wel kan vinden, hier vult hij schoolbank.nl voor in.
En de interface is niet moeilijk, maar het totaalplaatje maakt het best ingewikkeld.

[...]
Heb ik gezegd dat het maar één script is? Ik heb het steeds gehad over een interface, niet over een script... Natuurlijk, voor specifieke toepassingen gebruik je maar 1 script ja, dat is logisch..

Dus oftewel, jij verwacht dat een isp een interface gaat schrijven die 90% van de webmail functionaliteit gaat nabootsen. Als een isp hiertoe besluit dan kan die laatste 10% van mailtjes / headers tonen er ook nog wel bij en hoeft de isp geen algemeen webmail script meer te gebruiken...

[Gomez12]

ninjazx9r98 schreef op zaterdag 12 januari 2008 @ 19:55:
[...]


Dat Google een index gebruikt is niet meer dan logisch maar denk er gewoon eens wat verder over na.
Hoe groot Google is is niet bekend, volgens schattingen heeft men 450.000 servers wereldwijd.
Hoe groot de index is (totaal aantal items) is lastig te vinden, enkele sites noemen 24 miljard items ergens richting eind 2005.
Je zult je al snel beseffen dat ook bij het gebruik van indexering de hoeveelheid data die doorgespit moet worden enorm is en dat dit razendsnel gebeurt.
Natuurlijk is het niet 1 op 1 terug te voeren op logfiles waar we het over hadden maar het geeft aan dat je grote hoeveelheden data best snel kunt verwerken.
En uiteraard heeft men allerlei slimme algoritmes ed maar het gaat om het principe van het zogenaamd niet snel kunnen verwerken van grote hoeveelheden data.

Grote data is supersnel te verwerken met goede algoritmes als dit je core-business is. Dat is het van google. Niet van een script voor een helpdesk-isp.
Als google een nieuw algoritme bedenkt wat 10% sneller is en wat ook 10% meer servers nodig heeft dan is het voor google misschien acceptabel, maar voor een isp zeker niet.

Maar ik ga gewoon niet meer reageren op google verwijzingen, want die zijn zo offtopic.
Google!=helpdesk script
Google zoek budget!=ISP helpdesk budget
Google business concept!=ISP business concept

[alt-92]

ninjazx9r98 schreef op zaterdag 12 januari 2008 @ 18:38:
Technische owner zijnde het account van de klant inclusief wachtwoord waarmee de klant zich bekend maakt aan het systeem.

Als je zo prat gaat op artikelen uit de telecommunicatiewet en de Wet Computercriminaliteit, wees dan ook zo consequent om dan niet opeens puur technisch te gaan kijken.

Waar uit ik die beschuldiging ?
Men heeft toegang tot de maildir en dus automatisch ook tot de inhoud.

Merk op dat zelfs Arnout in het artikel wat je aanhoudt aangeeft dat hier verschil zit tussen de mailbox en de inhoud van de mails.

quote: http://www.iusmentis.com/maatschappij/juridisch/briefgeheim/

Een Internet provider beheert onder andere de mailserver waar alle e-mails van zijn klanten op worden opgeslagen. E-mail bestemd voor een bepaalde klant wordt op deze server ontvangen en bewaard totdat deze klant online komt. Totdat de klant met een e-mail programma zijn berichten naar zijn eigen computer overhaalt, kan de provider al deze mail in theorie lezen.

De klant kan ook met een webmail applicatie zijn e-mail lezen, of gebruikmaken van een protocol als IMAP. Hierbij blijven alle e-mails op de server van de provider staan. De beheerder van deze server is technisch altijd in staat om alle berichten die op de server zijn opgeslagen, in te zien.

Let op dat stuk "berichten inzien".

Nergens zie je mij zeggen dat ze zich daadwerkelijk toegang verschaffen tot die berichten.
Men is binnengedrongen in het domein van iemand anders zonder daar rechten toe te hebben.

Nu zeg je weer iets anders als wat je hierboven in jezelfde post over precies datzelfde zegt.

[Gomez12]

alt-92 schreef op zaterdag 12 januari 2008 @ 17:51:
[...]

Waarvan je in dit geval dient te bewijzen dat die kleine extra stap genomen is.
Je uit hier de beschuldiging dat toegang tot een mailbox direct inhoudt dat medewerkers zich toegang verschaffen tot de INHOUD van afzonderlijke mailbestanden.

INHOUD valt ook headers onder?
Want headers vallen wel onder de inhoud van de mailbox imho.

Alleen is het punt dat als je 100% afspreekt dat een helpdesker geen headers / mailinhoud / afzenders moet kunnen zien dat het niets meer met die mailbox te maken heeft, het gaat op dat moment alleen nog maar over of de klant kan inloggen, of de mailtjes corrupt zijn, of de klant mail heeft gekregen van persoon x, of de klant corrupte mail-headers heeft staan dat is allemaal afhankelijk van de inhoud van de mailbox.

Het kunnen controleren van het mail-wachtwoord dat valt met 99,99999% zekerheid ook wel te controleren door gewoon het account proberen in te loggen. De kans dat de mailserver authenticatie niet werkt is te verwaarlozen voor 1 klant.

Of ben jij van mening dat de afdeling Juridische Zaken bij KPN een stelletje incompetente know-nots zijn dat ze dat niet afdekken in contracten, richtlijnen, en AV?

Door ervaring wijs geworden : Ja. Alleen hebben consumenten niet de juridische middelen om dat te bestrijden.
Vb : Als bedrijf een heel mooi specifiek contract laten opstellen wat preciese voorwaarden had ( 99,99% uptime ) . Toen het puntje bij het paaltje kwam verwees KPN opeens terug op regeltjes in een ander algemener contract ( huurlijn die verplicht bij dit contract genomen moest worden en wat maar 98% uptime bood ). Is uitgelopen op een rechter die besliste dat KPN de keus had, of alle contracten ontbinden omdat ze tegenstrijdig waren, of de boeteclausule betalen die inging als KPN onder de 99,9% uptime zou zitten.
Laat ik het er maar op houden dat de boeteclausule goedkoper was dan de ontbinding

[alt-92]

Gomez12 schreef op zaterdag 12 januari 2008 @ 21:33:
[...]
INHOUD valt ook headers onder?

Headers zijn het equivalent van de envelop bij fysieke post.
Er staat de afzender, geaddresseerde, de route van de mail (stempel) in.
Die vallen met normale post niet onder het briefgeheim, en ook niet bij het electronische equivalent.

Want headers vallen wel onder de inhoud van de mailbox imho.

Ja duh. Het staat in de mailbox.

Kijk, daarom probeerde ik al eerder een heel duidelijk verschil aan te geven tussen 'toegang tot de mail' en toegang tot de mailbox.
Vooral als het om dit soort discussies gaat zul je heel duidelijk moeten aangeven wat je precies bedoelt met 'mail'.

[Gomez12]

alt-92 schreef op zaterdag 12 januari 2008 @ 21:43:
[...]

Headers zijn het equivalent van de envelop bij fysieke post.
Er staat de afzender, geaddresseerde, de route van de mail (stempel) in.
Die vallen met normale post niet onder het briefgeheim, en ook niet bij het electronische equivalent.

En met electronische post vallen ze wel onder hetzelfde bestand. ( bij meeste mailservers )
En een subject kennen we nog niet eens onder het briefgeheim, is dit buiten of binnen de INHOUD?

En afzender die niet onder het briefgeheim valt, dat is imho zeer discutabel als je het over electronische post hebt. Want bij brieven is het niet verplicht, bij electronische post is het wel verplicht ( uit mijn hoofd zelfs strafbaar om dit te frauderen ).
Dus imho valt het bij brieven niet onder het briefgeheim omdat het niet verplicht is ( wil je niet dat de postbode het ziet dan zet je het er niet op ) maar bij email heb je de keuze niet ( dus oftewel je kan de in/uitgaande emails van katja schuurrmans in de gaten houden en als jij genoeg headers ziet kan jij ook wel voorspellen met wie zij een nieuw kindje gaat krijgen , zonder inhoud )

Een maandje bijhouden wie aan wie een mailtje stuurt met de onderwerpen + tijdstippen kan veelzeggend zijn, bij brieven zegt dit bijna niets meer ( iemand uit postcode 3500 heeft een brief gestuurd aan persoon y, de brief is uit postbus x gehaald om 18:00 zegt toch iets anders als : persoon x met mailadres x heeft een email gestuurd aan persoon y met mailadres y over : gefeliciteerd met de kleine, dit mailbericht is gestuurd om 16:44 vanaf server z )

[ Voor 16% gewijzigd door Gomez12 op 12-01-2008 22:21 ]

[alt-92]

Gomez12 schreef op zaterdag 12 januari 2008 @ 22:14:
[...]
En met electronische post vallen ze wel onder hetzelfde bestand. ( bij meeste mailservers )

Dan nog moet je het bestand eerst openen om de auteursrechtelijk beschermde inhoud te kunnen lezen.
Mijn mailclient kan de headers weergeven zonder dat de inhoud van de mail ook daadwerkelijk wordt getoond.

En een subject kennen we nog niet eens onder het briefgeheim, is dit buiten of binnen de INHOUD?

En afzender die niet onder het briefgeheim valt, dat is imho zeer discutabel als je het over electronische post hebt. Want bij brieven is het niet verplicht, bij electronische post is het wel verplicht ( uit mijn hoofd zelfs strafbaar om dit te frauderen ).

Met welk oogmerk?

Dus imho valt het bij brieven niet onder het briefgeheim omdat het niet verplicht is ( wil je niet dat de postbode het ziet dan zet je het er niet op ) maar bij email heb je de keuze niet

Technische limieten aan de mogelijkheden.

( dus oftewel je kan de in/uitgaande emails van katja schuurrmans in de gaten houden en als jij genoeg headers ziet kan jij ook wel voorspellen met wie zij een nieuw kindje gaat krijgen , zonder inhoud )

Maar dan ga je logging of monitoring van verkeersgegevens doornemen, en daarmee begeef je je al op het terrein van de daarvoor aangestelde en bevoegde opsporingsorganen.
Dat valt ook niet onder de bevoegdheden van $ISP om andere redenen dan de verplichting die ze wettelijk hebben deze verkeersgegevens te bewaren in het kader van dataretentie.

[ Voor 3% gewijzigd door alt-92 op 12-01-2008 23:54 ]

[Gomez12]

alt-92 schreef op zaterdag 12 januari 2008 @ 23:52:
[...]

Dan nog moet je het bestand eerst openen om de auteursrechtelijk beschermde inhoud te kunnen lezen.
Mijn mailclient kan de headers weergeven zonder dat de inhoud van de mail ook daadwerkelijk wordt getoond.

En dat is nu net het probleem, je mailclient ziet de inhoud wel, anders weet hij niet waar de headers ophouden / beginnen ( technisch probleem van het in 1 bestand opslaan van alles ). Dat hij ze niet toont is imho niet relevant. Een postsorteer machine / postbode ziet gewoon niets meer dan alleen de adressering omdat de rest niet zichtbaar is.

Technische limieten aan de mogelijkheden.

Van de post of van de email? Ik snap hem niet helemaal.

Maar dan ga je logging of monitoring van verkeersgegevens doornemen, en daarmee begeef je je al op het terrein van de daarvoor aangestelde en bevoegde opsporingsorganen.
Dat valt ook niet onder de bevoegdheden van $ISP om andere redenen dan de verplichting die ze wettelijk hebben deze verkeersgegevens te bewaren in het kader van dataretentie.

Dus als ik als isp helpdesker wel headers mag zien dan mag ik daar toch weer geen datamining op loslaten? Hmmm, ik snap hem wel en ken hem ook wel, maar ben eigenlijk wel benieuwd hoe dit in de wet omschreven staat, want de dbase heb ik al, het recht om hem te bekijken heb ik al, ik kijk er alleen maar op een andere manier tegenaan...

[Verwijderd]

GVD kunnen jullie iets minder gaan quoten SVP? Goddamnnnnnnnnnnnnn

[Steephh]

Gomez12 schreef op zaterdag 12 januari 2008 @ 19:29:
[...]

Jij hebt het er niet over gehad. Maar simpele scripts voor een heldesk bestaan bijna niet juist door alle randvoorwaarden die veel minder gelden voor beheerdersscripts.

Begint ie weer.. Je bouwt er toch een interface door waardoor de helpdesk de scripts niet direct uitvoert maar door middel van bijvoorbeeld een webinterface?

[...]

Dus jij wilt scripts gaan maken die niet waterdicht zijn, waardoor je iemand laat scripten terwijl het risico blijft bestaan???
En btw uit logfiles kan ik echt wel iets meer privacy gegevens halen dan uit een webmail. Omdat ik dan opeens alle verkeersgegevens onder mijn handen heb. Het gevaar is dan imho iets groter dan met een webmail interface.
Als er message logging aanstaat dan krijg ik feitelijk de gegevens die in de webmail staan ++.

Nee een standaard webmail zonder er iets aan te veranderen, dat is slim om te gebruiken... Ik mag toch hopen dat de provider dit een beetje fatsoenlijk implementeert.. Nu probeer je dus eigenlijk te zeggen dat het eigen systeembeheer niet te vertrouwen is.. Nou, ik denk zelfs dat die nog wel iets meer te vertrouwen zijn dan de helpdeskers die toevallig van een of ander callcenter ingehuurd zijn..

[...]

Ehhm, omdat het script niet overal 100% rekening mee houdt???

Doet de webmail dat wel dan? En dan een of andere webmail ergens geplukt van het internet? Dan ben je wel dom om DAT als provider te gebruiken. Nee de webmail is allerheiligst en laat ALLES zien.. Webmaaaail

[...]

Jawel, maar is de helpdesk zo belangrijk dat er bij de overgang naar een nieuwe mailserver rekening gehouden moet worden met dit helpdesk script?

Ja wat denk je nou zelf.. Dat de helpdesk er voor de lol zit?

[...]

Hallo, blijf je wel in het oog houden waar het hier over gaat, een script wat helpdeskers andere informatie toont dan ze nu krijgen.
Het is echt geen core-business script ofzo hoor.

Oh, dus als het niet meer bij de main-activity hoort moet het in een keer maar achterop gesteld worden en nooit geupdated worden. Denk je dat de webmail ook nooit geupdated wordt, alleen maar omdat 'dat niet de main priority' is... Immers, een provider biedt internet aan en emailadressen krijg je daar als extra dienst bij...

[...]

Nou, als ik lees dat standaard webmail nu voldoende info geeft voor de helpdeskers en je hebt een aantal mensen die zeggen dat het teveel info geeft lijkt het me toch dat het redelijk te beantwoorden zou moeten zijn. Alle randvoorwaarden zitten in de webmail, alleen moet er iets minder info getoond worden.


[...]

Niet lullig bedoeld, maar iets als squirrelmail draait bij veel providers, onafhankelijk van omgeving etc. En volgens mij zoeken jullie eigenlijk iets wat dit ook doet, alleen moet het iets minder info tonen, dus volgens mij zijn de randvoorwaarden redelijk bekend. Info over de omgeving is ook niet nodig, het zijn toch allemaal mailservers?
Of wil jij een specifiek script hebben wat alleen werkt voor provider x met mailserver y?

Zoiets lijkt mij wel handig ja. Daar kan de helpdesker mee zien wat hij moet zien (inloggen, dmv een script een aantal acties controleren (mail checken e.d.), waarna het script een output geeft wat er wel en eventueel niet werkt.

[...]

Nee, waar het over ging is of dat helpdeskers webmail toegang moeten hebben of dat dit ook makkelijk via scripts te regelen is, omdat squirrelmail (= implementatie webmail ) redelijk systeemonafhankelijk is denk ik dat je zelf al het antwoord geeft door te zeggen dat je voor de scripts al randvoorwaarden nodig hebt etc.


[...]

Ho even, over wat voor scripts hebben we het nu? Hebben we het nu over een script wat 3 regels is en een simpel grep commando uitvoert of over een script wat allemaal dingen controleert, output format volgens bestaande regels en dan doorzet naar een database?
Want ik heb het over het 3-regelige grep script wat hier eerder genoemd als vervanger voor webmail werd en wat iedereen kan schrijven, dit gaat nooit werken vanaf helpdeskers. Dit is gewoon een nogo.
Maak je een uitgebreider script met controles etc dan kan het best afgetrapt worden vanaf een webinterface en outputten naar helpdesk maar dan heb je heb je het niet meer over een simpel script wat iedereen even in elkaar zet, dan ga je eerder praten over een programma dan een simpel script.


[...]

Dat probeer ik niet te insinueren, alleen het begon ermee dat het via simpele scripts die iedereen kon schrijven ook op hetzelfde niveau te controleren was als met webmail.
Nu ga jij meer en meer naar een uitgebreider script toe, waarbij je een ontwikkelomgeving wilt hebben, je wilt een acceptatie omgeving hebben, je wilt onderhouds tijd hebben voor dit script, je betrekt er zijdelings even openview bij. Bedenk wel dat dit allemaal nog niet bestaat, en dat de helpdeskers op dit moment deze gegevens ook al hebben.

Akkoord het is te scripten, maar ik bedoelde ook nooit te zeggen dat het theoretisch niet te scripten valt, maar ik zie geen enkele ISP dit op zo'n manier oppakken.
Jij hebt het over een professionele oplossing die wel te bouwen is via scripten maar die veel, heel veel geld kost, ik heb het over de eerdergenoemde simpele scripts die wel eventjes webmail gaan vervangen. Dit kan imho dus niet voor het geld wat een ISP bereid is uit te geven voor een helpdesk.


[...]

Ik kan je wel vertellen ( met 99% zekerheid ) dat er geen providers zijn die openview rechtstreeks meldingen laten versturen naar 1e lijns helpdeskmedewerkers.
Ik ken wel enkele ( welgeteld 2 )providers met openview, maar geen enkele haalt het in zijn hoofd om de meldingen door te sturen naar 1e lijns helpdeskers.
Puur vanwege het feit dat deze helpdesk uitbesteed is aan een callcenter, te veel verloop dus. openview geeft een melding aan beheer / 2e lijns. beheer / 2e lijns maakt zelf een mailtje naar 1e lijns met een niet technische vertaling.
Ja, het kan wel, maar vanwege verloop + algemene technische kennis 1e lijns helpdeskers is dit niet zinvol.


[...]

1e lijns moet ook geen technische isp-problemen oplossen, ze moeten ze signaleren en doorgeven.
1e lijns moet alleen de client-side problemen oplossen. Server-side hebben zij niets mee te maken, daar moeten zij de klant fatsoenlijk kunnen afwimpelen.


[...]

Op de backend weet ik dat er bij isp's heel veel capabele mensen rondlopen, maar op de 1e lijns ( sorry voor de mensen die daar werken ) zitten deze niet, als je fulltime 1e lijns bent en je bent capabel schuif je al heel snel door in de organisatie, 1e lijns is imho toch echt de vakantie werkers / parttimers / callcenters waar je beleefd de telefoon moet kunnen oppakken en de klant op een beleefde manier het standaard callscript moet laten doorlopen. Door technische kennis is menig 1e lijns medewerker niet gehinderd imho.
En nu is het gewoon wachten op de mensen die dit een flame vinden, zo is het niet bedoeld, maar simpel voorbeeldje als ik naar mijn isp bel dan vraag ik altijd naar persoon x, want de rest wil eerst het hele call-script aflopen of alle instellingen wel goed staan. Terwijl persoon x gewoon weet dat mijn instellingen 99% goed staan en dat het of een probleem aan hun kant is of er staat bij mij een obscure instelling fout.

Gomez12 schreef op zaterdag 12 januari 2008 @ 20:01:
[...]

Hmmm, dus over 2 weken zien we een concurrent van Google van jouw hand?

Ter indicatie.. Je neemt alles veeeeel te letterlijk... Je bind je vast op elk woordje om je gelijk te krijgen..

[...]

Hmm, ik dacht dat het over algemeen 1e lijns indicatie ging, en dat ik vond dat die juist geen log-info nodig had. Dat een webmail juist volstaat. En dat als je een log gaat interpreteren dat je dan imho vele problemen gaat tegenkomen.
Dat iemand dan komt met een totaal onrealistisch beeld als dat er een log per gebruiker dat probeer ik te stoppen.

De helpdesker krijgt toch niet de directe log te zien?

[...]

Ter simplificatie : Ja, ik denk inderdaad dat een provider een standaard script pakt om het zo snel mogelijk en zo generiek mogelijk geregeld te hebben. Als hij elke code regel wou napluizen had hij beter zelf een webmail client kunnen schrijven, dit is toch niet zo moeilijk?

Ik heb het toch niet over elke regel..

[...]

Plaintext opslaan keur ik vziw ook nergens goed, dit is gewoon fout.
Webmail toegang kan ik wel bedenken wat het nut is, dat er misbruik van gemaakt kan worden zie ik wel, maar dit is te ondervangen door goede procedures en naleving hiervan...
Een een compleet uitgebreid script gaan schrijven met een test acceptatie omgeving dat zie ik geen enkele isp gaan opzetten, het kan wel, maar ik zie het niet gebeuren.

Het zijn maar een paar basisfucntionaliteiten die dit script moet kennen dus enorm groot zal het niet worden.

[...]

Maar de logging was toch per klant ( Dus sysbeheer heeft geen eigen log )? Of is er volgens jou een logging per klant, een logging per domein, een logging per server, een logging per serverpark. Zoals jij zelfs ( volgens mij ) al eens zei : Een mailserver is niet zo ingewikkeld. En gaat zeker niet zoveel log-files bijhouden.
Dus of het is per klant en dan heeft de beheerder geen inzicht in het feit dat 5000 mensen niet kunnen inloggen op hun webmail want de server draait technisch goed, alleen per klant gaat er iets fout. Of het is 1 algemene logging waardoor het per klant niet meer zo snel te traceren valt.

Logging per klant lijkt mij het logischt, want wat heb je nou aan 1 algemene logfile? Daarnaast zou je ook nog 1 algemene logging kunnen draaien puur voor de foutmeldingen alleen maar dan wel in 1 logfile.

[...]

Laten we het wel een beetje realistisch houden aub. de grootste veiligheid is een grot in de bergen van afghanistan. Daar vind zelfs de VS je niet.
De gemiddelde consument wil de grootste veiligheid wat betreft zijn email adres, want hij wil geen spam. Maar toch wil hij dat truus die 30 jaar geleden bij hem op school zat hem wel kan vinden, hier vult hij schoolbank.nl voor in.
En de interface is niet moeilijk, maar het totaalplaatje maakt het best ingewikkeld.

Je moet de zaken niet overdrijven, ik heb niet gezegd dat de klant de maximum veiligheid wil maar wel zo veilig mogelijk, neem ik aan..

[...]

Dus oftewel, jij verwacht dat een isp een interface gaat schrijven die 90% van de webmail functionaliteit gaat nabootsen. Als een isp hiertoe besluit dan kan die laatste 10% van mailtjes / headers tonen er ook nog wel bij en hoeft de isp geen algemeen webmail script meer te gebruiken...

Ik heb helemaal niet gezegd hoeveel er moet worden nageboots, maar dat is zeker geen 90%....

Verwijderd schreef op zondag 13 januari 2008 @ 02:02:
GVD kunnen jullie iets minder gaan quoten SVP? Goddamnnnnnnnnnnnnn

Sorryy...

Nou ga ik slapen want ik ben moe..

[ninjazx9r98]

alt-92 schreef op zaterdag 12 januari 2008 @ 20:34:
[...]

Als je zo prat gaat op artikelen uit de telecommunicatiewet en de Wet Computercriminaliteit, wees dan ook zo consequent om dan niet opeens puur technisch te gaan kijken.

Is het dan echt zo moeilijk om te begrijpen ??
Technische owner alszijnde de persoon die technisch dmv zijn/haar wachtwoord als enige (plus systeembeheer) toegang heeft tot de inhoud die alleen voor hem/haar bestemd is.
De mailbox plus inhoud is gehuurd, het wachtwoord is de sleutel en de klant is de enige persoon die toegang heeft tot die mailbox (plus systeembeheerder)
Mensen waar de data niet voor bestemd is en binnengaan in die mailbox verschaffen zich dus wederrechtelijk toegang.

[...]

Merk op dat zelfs Arnout in het artikel wat je aanhoudt aangeeft dat hier verschil zit tussen de mailbox en de inhoud van de mails.


[...]

Let op dat stuk "berichten inzien".

http://www.vandale.nl
in·zien2 (overgankelijk werkwoord; zag in, heeft ingezien)
1 inkijken, vluchtig lezen of bekijken
2 zich realiseren
3 op de genoemde wijze beoordelen

Verder zie ik daar totaal geen verschil gemaakt worden tussen een mailbox en de inhoud van email.
[...]

Nu zeg je weer iets anders als wat je hierboven in jezelfde post over precies datzelfde zegt.

Ik zeg helemaal niks anders.
Ik bestrijdt nog steeds wat jij eerder beweerde.
Namelijk dat ik gezegd zou hebben dat medewerkers zich toegang verschaffen tot de inhoud van berichten.
IK heb gezegd dat het een kleine stap is als je eenmaal in die mailbox zit, jij bent degene die daar van maakt dat ik gezegd heb dat men zich toegang verschaft tot de inhoud.

[alt-92]

ninjazx9r98 schreef op zondag 13 januari 2008 @ 10:09:
Mensen waar de data niet voor bestemd is en binnengaan in die mailbox verschaffen zich dus wederrechtelijk toegang.

Niet als dat gedaan wordt ter ondersteuning van de dienstverlening als de klant contact opneemt met de Servicedesk.
Daarmee kom je op het uitzonderingsdeel uit wat in het artikel wordt aangehaald.

Verder zie ik daar totaal geen verschil gemaakt worden tussen een mailbox en de inhoud van email.

Er wordt doorlopend gesproken over de inhoud van berichten.
Niet over de mailbox.

Ik zeg helemaal niks anders.
Ik bestrijdt nog steeds wat jij eerder beweerde.
Namelijk dat ik gezegd zou hebben dat medewerkers zich toegang verschaffen tot de inhoud van berichten.
IK heb gezegd dat het een kleine stap is als je eenmaal in die mailbox zit, jij bent degene die daar van maakt dat ik gezegd heb dat men zich toegang verschaft tot de inhoud.

Je stelt hier dat dat hetzelfde is.

En het verschil tussen de mailbox en de inhoud is ?
Simpel uitgaande van een Unix achtig systeem is de mailbox en de inhoud in feite hetzelfde.
Een plat stuk tekst.
Veel moeilijker is het echt niet.
Op het moment dat je een mailbox bekijkt wordt er data overgenomen naar jouw systeem.
Wederrechtelijk is hier dus gewoon aan de orde.

.

En ik heb je al verteld dat het maildir formaat wordt gebruikt.
Naast prestatietechnische redenen (zoals filelocks) geeft dat ook een ander voordeel: namelijk dat je dus nooit direct de inhoud van een mail kan zien bij het openen van een maildir-mailbox waar dat wél het geval is bij een mbox.
Daarmee scherm je je juridisch al gelijk af tegen het direct lezen van de inhoud van de mailberichten.

[ninjazx9r98]

alt-92 schreef op zondag 13 januari 2008 @ 13:59:
[...]

Niet als dat gedaan wordt ter ondersteuning van de dienstverlening als de klant contact opneemt met de Servicedesk.
Daarmee kom je op het uitzonderingsdeel uit wat in het artikel wordt aangehaald.

Ik zie dat dus fundamenteel anders.
Ten eerste zie ik daarin een onderscheid tussen systeembeheer en helpdesk.
Ten tweede ben ik persoonlijk nog steeds van mening dat contact opnemen met een servicedesk niet per definitie inhoudt dat men in mijn mail/mailbox kan en mag kijken.
Mocht dat om wat voor reden dan ook nodig zijn dient men daar tenminste om te vragen.

[...]

Er wordt doorlopend gesproken over de inhoud van berichten.
Niet over de mailbox.

En ik zie dat nog steeds als 1.
Dat er technisch verschil zit tussen mbox en maildir doet niets af aan de mogelijkheid tot inzien van de inhoud van mailberichten die eigendom zijn van een ander.
Als ik toegang heb tot /var/mail/klant of tot /home/klant/Maildir heb ik gewoon toegang tot de inhoud van email.

[...]

Je stelt hier dat dat hetzelfde is.

Dat is nog steeds iets anders dan beweren dat mensen de inhoud van email lezen en dat is waar ik op doel.

[...]
.

En ik heb je al verteld dat het maildir formaat wordt gebruikt.
Naast prestatietechnische redenen (zoals filelocks) geeft dat ook een ander voordeel: namelijk dat je dus nooit direct de inhoud van een mail kan zien bij het openen van een maildir-mailbox waar dat wél het geval is bij een mbox.
Daarmee scherm je je juridisch al gelijk af tegen het direct lezen van de inhoud van de mailberichten.

Definieer het openen van een mailbox, misschien dat we elkaar dan beter begrijpen.
Als het openen is in de zin van inloggen met een mailclient danwel webmail maakt het niet uit of het formaat mbox of maildir is.
Als het gaat om het daadwerkelijk openen van de inhoud van mail dan is er naar mijn mening weinig verschil als je de juiste rechten hebt om bij de locatie van de mailbox te komen.
Of je nu toegang hebt tot /var/mail/klant of tot /home/klant/Maildir maakt weinig uit, in beide gevallen heb je toegang tot de inhoud van email.
Enige is dat je bij maildir wat dieper moet gaan vanwege de directorystructuur maar de email is nog steeds beschikbaar als platte tekst.
Ik zie dat voordeel dus niet, toegang tot de locatie van de mailbox staat in beide gevallen gelijk aan de mogelijkheid om daadwerkelijk de inhoud van emails te zien.

Maar mischien dat jij dat totaal anders ziet.

[Matrix]

Mooie discussie over de achterliggende techniek en de wetgeving maar wat jullie keihard uit het oog verliezen is het soort mensen dat een ISP helpdesk belt met mailproblemen. Dat zijn voornamelijk mensen die de boel hebben laten aansluiten door een handige neef/buurjongen of een installatiemonteur (buiten dan wanneer er een storing is bij die ISP) en verder er nooit naar om hebben gekeken. Mensen die letterlijk moeite hebben met het vinden van de spatiebalk op het toetsenbord.

Wanneer je met die mensen aan de lijn ze via webmail moet laten inloggen omte kijken of daar alles goed gaat, met een case sensitive password ben je vaak de eerst komen eeuw nog niet klaar met die persoon. Men wil gewoon dat het werkt en hoe het werkt maakt bijna niemand wat uit. Voor die mensen is het gewoon veel makkelijker om als helpdesk medewerker gelijk even zelf in de mailbox te kijken om te zien wat daar gebeurd.

En tuurlijk heb je op principieele gronden gelijk, zou het eigenlijk niet moeten mogen of misschien mag het zelfs wel niet. Maar daarmee is het gros van de klanten niet geholpen. Dus principieel hebben mensen gelijk door te zeggen dat het niet kan/mag. Maar in de praktijk is dat een redelijk onwerkbare situatie.


Edit: @hieronder: daar heb je weer helemaal gelijk in, het zou inderdaad gewoon duidelijk vermeld moeten worden in de algemene voorwaarden.

[ Voor 5% gewijzigd door Matrix op 14-01-2008 14:35 ]

[Tukk]

Matrix schreef op maandag 14 januari 2008 @ 13:26:
Mooie discussie over de achterliggende techniek en de wetgeving maar wat jullie keihard uit het oog verliezen is het soort mensen dat een ISP helpdesk belt met mailproblemen. Dat zijn voornamelijk mensen die de boel hebben laten aansluiten door een handige neef/buurjongen of een installatiemonteur (buiten dan wanneer er een storing is bij die ISP) en verder er nooit naar om hebben gekeken. Mensen die letterlijk moeite hebben met het vinden van de spatiebalk op het toetsenbord.

<KNIP>

Ok, heb je gelijk in. Maar.. zet dan dat in je algemene voorwaarden, ontken de situatie dan niet. Vind ik ook best. Geef mij bijvoorbeeld de keuze om mijn passworden niet te geven aan een helpdesk, met een opt-out/in. Nu heb ikzelf geen keuze.

[ Voor 30% gewijzigd door Tukk op 14-01-2008 13:51 ]

[andreas2005]

Matrix schreef op maandag 14 januari 2008 @ 13:26:
Mooie discussie over de achterliggende techniek en de wetgeving maar wat jullie keihard uit het oog verliezen is het soort mensen dat een ISP helpdesk belt met mailproblemen. Dat zijn voornamelijk mensen die de boel hebben laten aansluiten door een handige neef/buurjongen of een installatiemonteur (buiten dan wanneer er een storing is bij die ISP) en verder er nooit naar om hebben gekeken. Mensen die letterlijk moeite hebben met het vinden van de spatiebalk op het toetsenbord.
<KNIP>
En tuurlijk heb je op principieele gronden gelijk, zou het eigenlijk niet moeten mogen of misschien mag het zelfs wel niet. Maar daarmee is het gros van de klanten niet geholpen. Dus principieel hebben mensen gelijk door te zeggen dat het niet kan/mag. Maar in de praktijk is dat een redelijk onwerkbare situatie.

Dan blijft het raar dat XS4ALL, dat bekend staat om zijn deskundige helpdesk, de klanten WEL kan helpen zonder het wachtwoord te kennen. die klanten van XS4ALL zijn echt niet zo bijzonder, die zijn niet slimmer dan alle andere klanten. Het is niet voor niks dat ook zij een installatie aanbieden zonder dat je zelf een vinger hoeft uit te steken.
Het gebruiken van het wachtwoord van de klant is volledig onnodig voor de helpdesk, al vraagt het misschien wel een andere werkwijze. Voor de klanttevredenheid maakt het echter niet uit, want de klanten van XS4ALL zijn ook heel tevreden.

Conclusie: Tiscali hoeft mijn wachtwoord niet te verstrekken aan haar helpdesk, en de voorwaarden van Tiscali geven ook aan dat de helpdesk er helemaal niet mee mag werken. Als medewerkers van de helpdesk menen het toch nodig te hebben, dan moeten de werkinstructies zodanig worden aangepast dat de klant geholpen wordt zonder dat het wachtwoord gebruikt wordt.

[batsma]

andreas2005 schreef op maandag 14 januari 2008 @ 14:47:
[...]

Dan blijft het raar dat XS4ALL, dat bekend staat om zijn deskundige helpdesk, de klanten WEL kan helpen zonder het wachtwoord te kennen. die klanten van XS4ALL zijn echt niet zo bijzonder, die zijn niet slimmer dan alle andere klanten. Het is niet voor niks dat ook zij een installatie aanbieden zonder dat je zelf een vinger hoeft uit te steken.
Het gebruiken van het wachtwoord van de klant is volledig onnodig voor de helpdesk, al vraagt het misschien wel een andere werkwijze. Voor de klanttevredenheid maakt het echter niet uit, want de klanten van XS4ALL zijn ook heel tevreden.

Conclusie: Tiscali hoeft mijn wachtwoord niet te verstrekken aan haar helpdesk, en de voorwaarden van Tiscali geven ook aan dat de helpdesk er helemaal niet mee mag werken. Als medewerkers van de helpdesk menen het toch nodig te hebben, dan moeten de werkinstructies zodanig worden aangepast dat de klant geholpen wordt zonder dat het wachtwoord gebruikt wordt.

Nee xs4all is niet bijzonder, de mensen die er werken zijn ook niet speciaal, ze kosten alleen wel 3 keer meer dan andere providers, rara waarvoor zal dit nodig zijn? alleen de marge? of misschien toch om al die extra privacy/trainingen whatever van agents te bekostigen? Of misschien is het zo dat bij xs4all de calls gemiddeld 3 keer zo lang mogen duren?

ninjazx9r98 schreef op zaterdag 12 januari 2008 @ 15:39:
[...]

En het verschil tussen de mailbox en de inhoud is ?
Simpel uitgaande van een Unix achtig systeem is de mailbox en de inhoud in feite hetzelfde.
Een plat stuk tekst.¹
Veel moeilijker is het echt niet.
Op het moment dat je een mailbox bekijkt wordt er data overgenomen naar jouw systeem.
Wederrechtelijk is hier dus gewoon aan de orde.²

1OMG OMG OMG!!! platte tekst op een mailserver?!?!?!?!!?!? GIEF MD5 HASHES NOW!!!! ik wil encryptie, de hele wereld kan nu die server hacken en mijn platte tekst(zonder opmaak dat dan weer wel) lezen!!!!oneoneoneeleven

2 Euh ja want als jij op een website kijkt met copyright ben je ook strafbaar omdat dan alle afbeeldingen en text etc naar je browser cache worden gecopieert

[ Voor 54% gewijzigd door batsma op 14-01-2008 16:30 ]

[Jasper Janssen]

Let wel, ik spreek hier als privepersoon:

Wat ik zou verwachten is dat je bij een mailprobleem even telnet naar poort 110 van de popserver en dan de user/pass C/Pt en zonodig een list uitvoert. Webmail inloggen doe je normaal pas na toestemming van de klant te vragen, maar aan de andere kant kan ik me goed voorstellen dat dat niet altijd en overal 100% goed gaat.

Dit gaat dan dus puur over het inloggen-op-webmail issue.

Het andere punt, inzage tot plaintext password gegevens, is iets dat inderdaad vreemd overkomt als je alleen ervaring hebt met security setups van corporate accounts etc. Bij consumenten ISPs (en xs4all is gezien de prijs geen consumenten ISP (meer)) is dat (klaarblijkelijk) heel normaal, en ik denk dat het wel ontzettend veel problemen voorkomt/oplost/sneller helpt op te lossen.

[ Voor 5% gewijzigd door Jasper Janssen op 15-01-2008 14:34 ]

[FunkyTrip]

LuCarD schreef op dinsdag 08 januari 2008 @ 13:15:
[...]

Yeah right......

Ik werk bij een betrekkelijk kleine bank, en ik heb geen toegang tot live klanten gegevens.

Een collega van mij heeft wel toegang tot de gegevens, maar elke dag word er overzichten gemaakt wie welke klant heeft bekeken. ( maar ik heb geen idee wat er met die gegevens worden gedaan )

Me vriendin werkt bij de postbank, en die heeft ook geen toegang tot enige klant gegevens.

Wellicht offtopic, maar de laatste tijd heb ik wat af moeten bellen met de Amro bank en alle medewerkers die mij te woord stonden konden al mijn transacties lezen nadat ik mijn rekeningnummer opgegeven had. Ze noemden de bedrijven,data en bedragen.

[Matrix]

andreas2005 schreef op maandag 14 januari 2008 @ 14:47:
[...]


Dan blijft het raar dat XS4ALL, dat bekend staat om zijn deskundige helpdesk, de klanten WEL kan helpen zonder het wachtwoord te kennen. die klanten van XS4ALL zijn echt niet zo bijzonder, die zijn niet slimmer dan alle andere klanten. Het is niet voor niks dat ook zij een installatie aanbieden zonder dat je zelf een vinger hoeft uit te steken.
Het gebruiken van het wachtwoord van de klant is volledig onnodig voor de helpdesk, al vraagt het misschien wel een andere werkwijze. Voor de klanttevredenheid maakt het echter niet uit, want de klanten van XS4ALL zijn ook heel tevreden.

Conclusie: Tiscali hoeft mijn wachtwoord niet te verstrekken aan haar helpdesk, en de voorwaarden van Tiscali geven ook aan dat de helpdesk er helemaal niet mee mag werken. Als medewerkers van de helpdesk menen het toch nodig te hebben, dan moeten de werkinstructies zodanig worden aangepast dat de klant geholpen wordt zonder dat het wachtwoord gebruikt wordt.

Ik kan ook prima klanten helpen zonder wachtwoord, geen enkel probleem duurt alleen wel 5 x zolang, tja en mensen bellen wel een 0900 nummer en dan moet alles snel snel snel. Dus XS4all maakt wel degelijk verschil, zij hebben gewoon een normaal nummer voor de helpdesk en bovendien gaat het vaak om klanten die zich van te voren goed hebben ingelezen en met opzet een XS4ALL abonnement hebben genomen voor de goede service (wat al impliceerd dat ze er over na hebben gedacht, genoeg geld hebben (anders neem je niet zo'n duur abonnement) waar je met enige welwillendheid de conclusie uit zou kunnen trekken dat het intelligentie niveau iets hoger ligt dan gemiddeld. (net zoals je dat zou doen bij bv NRC lezers tov. Telegraaf lezers) Het gaat dus bepaald niet om Tante Truus van drie hoog achter die het goedkoopste internet abonnementje heeft gekozen dat ze voorbij zag komen. Wat je bij goedkopere providers vaak wel ziet.

[Verwijderd]

iedereen heeft het zo over email inzien enzo, maar stel dat de medewerker gewoon een telnetsessie geopend heeft op de mailbox, die tot en met het pass commando gaat, of wellicht een tooltje heeft die niets meer doet dan dat? Daarmee valt te verifiëren of het inloggen werkt, maar zie je verder niet wat er aan mail staat. Overigens, als een medewerker een mail zou openen staat ie ook als gelezen gemarkeert in de webmail, net getest, en die kun je niet meer op ongelezen zetten

[alt-92]

ninjazx9r98 schreef op zondag 13 januari 2008 @ 16:04:
En ik zie dat nog steeds als 1.
Dat er technisch verschil zit tussen mbox en maildir doet niets af aan de mogelijkheid tot inzien van de inhoud van mailberichten die eigendom zijn van een ander.
Als ik toegang heb tot /var/mail/klant of tot /home/klant/Maildir heb ik gewoon toegang tot de inhoud van email.

Definieer het openen van een mailbox, misschien dat we elkaar dan beter begrijpen.

Jij belt naar mij als slotenmaker dat je een probleem hebt met je voordeur - het lijkt erop dat je je huis niet in kan.
Ik maak voor jou de deur open (want je hebt mij er tenslotte bijgehaald omdat je een probleem hebt, weet je nog?).
Ik kijk alleen door de open voordeur, maar ik loop je huis niet binnen.

Ben ik nou wederrechtelijk bezig of niet?
Ook even denken aan de jurisprudentie bij dit geval, niet puur naar de letter van de wet kijken. Doet een rechter ook niet, die houdt ook rekening met wat in het maatschappelijk verkeer als algemeen aanvaard wordt beschouwd.

Enige is dat je bij maildir wat dieper moet gaan vanwege de directorystructuur maar de email is nog steeds beschikbaar als platte tekst.
[...]
Maar mischien dat jij dat totaal anders ziet.

Het is een folder op het filesystem met daarin files.
Ik kan de folder 'listen' - daarmee open ik nog steeds geen files (en kijk dus NIET in de INHOUD).

[Jasper Janssen]

Verwijderd schreef op maandag 14 januari 2008 @ 17:19:
iedereen heeft het zo over email inzien enzo, maar stel dat de medewerker gewoon een telnetsessie geopend heeft op de mailbox, die tot en met het pass commando gaat, of wellicht een tooltje heeft die niets meer doet dan dat? Daarmee valt te verifiëren of het inloggen werkt, maar zie je verder niet wat er aan mail staat. Overigens, als een medewerker een mail zou openen staat ie ook als gelezen gemarkeert in de webmail, net getest, en die kun je niet meer op ongelezen zetten

Dat is idd de betere actie, maar het hangt er wel van af waar de klant mee belt. Heeft hij een probleem met OutlookE[1], dan is een telnetsessietje (cq popcheck) de geeikte manier. Is er iets met de webmail, of er is bijv een corrupte dan wel te grote mail, dan is de webmail vele malen handiger, oa omdat je er meteen bij ziet staan hoe groot de mail is.

[ Voor 5% gewijzigd door Jasper Janssen op 15-01-2008 14:27 ]

[Jasper Janssen]

Ik kan ook prima klanten helpen zonder wachtwoord, geen enkel probleem duurt alleen wel 5 x zolang, tja en mensen bellen wel een 0900 nummer en dan moet alles snel snel snel. Dus XS4all maakt wel degelijk verschil, zij hebben gewoon een normaal nummer voor de helpdesk en bovendien gaat het vaak om klanten die zich van te voren goed hebben ingelezen en met opzet een XS4ALL abonnement hebben genomen voor de goede service (wat al impliceerd dat ze er over na hebben gedacht, genoeg geld hebben (anders neem je niet zo'n duur abonnement) waar je met enige welwillendheid de conclusie uit zou kunnen trekken dat het intelligentie niveau iets hoger ligt dan gemiddeld. (net zoals je dat zou doen bij bv NRC lezers tov. Telegraaf lezers) Het gaat dus bepaald niet om Tante Truus van drie hoog achter die het goedkoopste internet abonnementje heeft gekozen dat ze voorbij zag komen. Wat je bij goedkopere providers vaak wel ziet.

Dat is inderdaad exact het verschil tussen xs4all klanten en klanten van een goedkope ISP, dat merk je wel degelijk.

[ Voor 12% gewijzigd door Jasper Janssen op 15-01-2008 14:27 ]

[we_are_borg]

Misschien leuk Compleet klantbestand in mijn bezit en het interesseert niem Planet gaat dus ook niet goed om met privacy gevoelige informatie. Het is niet vergelijkbaar maar privacy zegt momenteel dus niets meer.

[alt-92]

Mja. De Britse belastingdienst ook niet.

[Jasper Janssen]

Wat heet momenteel, de werknemers van je lokale bankfiliaal konden in 1900 ook je komplete bankrekening inzien. Gewoon op papier.

[Mayonaise]

Jammer genoeg kan Telfort hier niks aan doen. Ze weten zelfs niet eens wie dat persoon was waar je mee spreekte.

Het engiste wat ze voor jou kunnen doen is je e-mail adres terug in leven brengen.

[World Citizen]

Gister ben ik door een van onze Tweaker admins in contact gebracht met de radio zender TROSS Radio Online. Zij hebben hoogte gekregen van dit verhaal, en willen er een item aan besteden.

Ik heb gisteren telefonisch contact gehad met een van presentators, en die vertelde mij dat Telfort/Tiscali een standpunt aan het formuleren zijn..... Helaas hebben ze mij hier zelf niet van op de hoogte gebracht.

Vanavond tussen 8 en 9 uur zij we in de lucht (mits alles doorgaat) en dan word ik in contact gebracht met Telfort/Tiscali. Ik mag dan mijn verhaal uitleggen en zij zullen erop reageren. tevens zal ik ook aandragen dat ik het administrator@ adres in handen heb , en dat hier nog admin gerelateerde mail binnen komt.

Er werd gevraagd of ik naar de studio kom. ivm met mijn werk is dit moeilijk maar ik ben nog iets aan het proberen te regelen. Anders doen we het door de telefoon.

Ik hoop dat het een verduidelijkend gesprek word.

[LuNaTiC]

Mooi ik ga zeker luisteren, ben wel erg benieuwd naar het standpunt van Telfort.

[World Citizen]

LuNaTiC schreef op dinsdag 15 januari 2008 @ 09:27:
Mooi ik ga zeker luisteren, ben wel erg benieuwd naar het standpunt van Telfort.

Ja het mag nogal wat wezen naar een week formuleren.....


Typisch dat een andere tweakers.net bezoeker een zelfde soort verhaal heeft (zip bestand incident) Hij geeft ook al aan dat er niet op word gereageerd door de provider.....

Ik loop al een half jaar te verkondigen dat ik het administrator adres heb en dat er mail op binnenkomt..... Ondertussen schreeuw ik het bijna van de daken en nog geen enkele reactie.....

[Cloud]

LuNaTiC schreef op dinsdag 15 januari 2008 @ 09:27:
Mooi ik ga zeker luisteren, ben wel erg benieuwd naar het standpunt van Telfort.

Is dit ook live online te beluisteren? Ik kan er geen wijs uit worden op de website van de tros namelijk. Ik zie alleen maar oude uitzendingen staan. Of als een handige tweaker het even op kan nemen, zou ook prachtig zijn

Ik ben ook zeer benieuwd naar de uitkomst hiervan.

edit:
hartstikke bedankt heren

[ Voor 4% gewijzigd door Cloud op 15-01-2008 10:38 ]

[World Citizen]

http://www.radio-online.nl/

Ze hebben een archief dus daar zal het bij komen te staan.

[ydegart]

via radio1.nl kun je gewoon live luisteren.

[andreas2005]

Ik ben benieuwd wat Tiscali aan het formuleren is. Precies een week geleden (heb ik een mail hierover gestuurd aan Tiscali, pas vandaag kreeg ik een leesbevestiging van mijn mail (ik stuur mijn mail standaard met de optie van het ontvangen van een leesbevestiging). Is het mogelijk dat ze pas zeer kort geleden wakker zijn geworden? Op het forum bij Tiscali zelf wordt er steen en been over geklaagd dat er totaal niet meer gereageerd wordt op mail.

[LuNaTiC]

Kreeg net een mailtje dat de uitzondering van vanavond niet doorgaat ivm KNVB bekervoetbal... Volgende week willen ze er alsnog aandacht aan besteden, maar vanavond wordt het dus niets helaas.

[World Citizen]

LuNaTiC schreef op dinsdag 15 januari 2008 @ 12:24:
Kreeg net een mailtje dat de uitzondering van vanavond niet doorgaat ivm KNVB bekervoetbal... Volgende week willen ze er alsnog aandacht aan besteden, maar vanavond wordt het dus niets helaas.

Ja ik kreeg hem ook. Jammer. Vooral dat Telfort niet wil reageren op de radio vind ik tegenvallen.

[Ccc]

Ik heb niet elke reactie gelezen in dit topic. Mijn vraag is, heeft die medewerker ook daadwerkelijk jouw email berichten gelezen? Of heeft hij alleen getest of het werkte? En is hij ook daadwerkelijk in je mailbox geweest?

Ik werkook bij een helpdesk en wij kunnen de wachtwoorden van klanten niet zien, alleen wijzigen.

Even een beetje offtopic vraag, maar je koop je wel eens iets via het internet? Bijvoorbeeld via een web-shop ofzo?

[Gomez12]

Ccc schreef op dinsdag 15 januari 2008 @ 19:50:
Even een beetje offtopic vraag, maar je koop je wel eens iets via het internet? Bijvoorbeeld via een web-shop ofzo?

En ken je toevallig persoon x of y, niet dat ik even in je mailbox zit, maar ik ben gewoon telepatisch begaafd

Dames en heren, ik denk dat we de telfort medewerker gevonden hebben

[Verwijderd]

Ik vroeg mij af of de uitzending nog door is gegaan. Graag zou ik hem na willen luisteren. Heeft iemand een linkje?

[Cloud]

Verwijderd schreef op woensdag 16 januari 2008 @ 09:17:
Ik vroeg mij af of de uitzending nog door is gegaan. Graag zou ik hem na willen luisteren. Heeft iemand een linkje?

zie

LuNaTiC schreef op dinsdag 15 januari 2008 @ 12:24:
Kreeg net een mailtje dat de uitzondering van vanavond niet doorgaat ivm KNVB bekervoetbal... Volgende week willen ze er alsnog aandacht aan besteden, maar vanavond wordt het dus niets helaas.

[andreas2005]

Inmiddels heb ik antwoord van Telfort (slechts 1 week en twee uur na het stellen van de vraag ).
Nu zou ik dolgraag het alles verklarende en vooral zeer geruststellende antwoord hier willen posten, maar ik heb nu twee problemen:
1. Het antwoord bevat de volgende clausule:

-----------------------------------------

DISCLAIMER

De informatie verzonden met dit e-mail bericht is uitsluitend bestemd voor de geadresseerde. Gebruik van deze informatie door anderen dan de geadresseerde is verboden. Openbaarmaking, vermenigvuldiging, verspreiding en/of verstrekking van deze informatie aan derden is niet toegestaan.

-----------------------------------------

Ik ga er gemakshalve maar even van uit dat de disclaimer niet onder de verboden valt.

2. er is geen alles verklarend en vooral zeer geruststellend antwoord

Wat is de strekking van een drie alinea's aan tekst (het mocht kennelijk wat kosten)? De medewerker mag niet in de mail kijken, en dús is de privacy gewaarborgd . De medewerker mag bovendien pas in de mailbox als de klant daadwerkelijk toestemming heeft verleend, en nooit in de mail zelf.
Ten slotte is het dubbel veilig, want: er wordt nooit misbruik van gemaakt van de technische mogelijkheid die de medewerkers hebben om in de mailbox van de klant te komen.

Geen woord over maatregelen die ze hebben genomen om misbruik te voorkomen, maar dat hoeft dus ook niet want zij hebben als enige bedrijf in Nederland alleen rechtschapen mensen in dienst.

O ja, en ze geloven ook in kabouters.

[Dolan]

andreas2005 schreef op woensdag 16 januari 2008 @ 09:31:
Inmiddels heb ik antwoord van Telfort (slechts 1 week en twee uur na het stellen van de vraag ).
Nu zou ik dolgraag het alles verklarende en vooral zeer geruststellende antwoord hier willen posten, maar ik heb nu twee problemen:
1. Het antwoord bevat de volgende clausule:

[...]

Ik ga er gemakshalve maar even van uit dat de disclaimer niet onder de verboden valt.

2. er is geen alles verklarend en vooral zeer geruststellend antwoord

Wat is de strekking van een drie alinea's aan tekst (het mocht kennelijk wat kosten)? De medewerker mag niet in de mail kijken, en dús is de privacy gewaarborgd . De medewerker mag bovendien pas in de mailbox als de klant daadwerkelijk toestemming heeft verleend, en nooit in de mail zelf.
Ten slotte is het dubbel veilig, want: er wordt nooit misbruik van gemaakt van de technische mogelijkheid die de medewerkers hebben om in de mailbox van de klant te komen.

Geen woord over maatregelen die ze hebben genomen om misbruik te voorkomen, maar dat hoeft dus ook niet want zij hebben als enige bedrijf in Nederland alleen rechtschapen mensen in dienst.

O ja, en ze geloven ook in kabouters.

Zullen we anders even ophouden met ISP bashen en serieus verder gaan? Dank u.

Op dit moment is het dus het woord van Telfort tegen die van jou. Telfort zegt dat de e-mail niet gelezen is en jij zegt van wel. Jij basseert dat op een post in dit forum (de TS). Je hebt de medewerker niet zelf aan de telefoon gehad.

Wat voor antwoord had je graag gehad?

[Cloud]

trolleystad schreef op woensdag 16 januari 2008 @ 09:46:
Wat voor antwoord had je graag gehad?

Ik denk dat hij graag had willen horen dat de functionaliteit van de helpdesk om gebruikerswachtwoorden te lezen, uitgeschakeld is. Onder andere. Dat zou ik tenminste wel willen horen.

[andreas2005]

Wat voor antwoord had je graag gehad?

Heel simpel: Ik had gevraagd naar het bestaan van procedures waarmee ze zorgen dat er geen misbruik van wordt gemaakt. Dáár wou ik van weten dat ze bestaan. Het antwoord van Telfort / Tiscali gaat daar helemaal niet over, en is daarom niet meer dan een kluit in een hele hoop riet .
Welk antwoord had mij tevreden gesteld:

De mededeling dat elke toegang tot de mailbox van een klant door een medewerker van tiscali wordt gelogd, en steekproefsgewijs wordt gecontroleerd. Bijvoorbeeld aan de hand van aangemaakte calls / problems of hoe ze ook heten bij Tiscali. Toegang tot de mailbox, maar geen call / ticketnummer? Dan heeft de betreffende medewerker het een en ander uit te leggen.
Dit is ook niet waterdicht, maar had mij het gevoel gegeven dat de privacy / beveiliging serieus wordt genomen.
En misschien is er ook wel een dergelijk mechanisme, maar daar is in het geheel niks over gezegd door ze, en dat terwijl ik er toch echt naar vroeg!

Overigens, je beschuldigt mij van bashen, en ik geloof dat je je persoonlijk aangesproken voelt. Het is absoluut niet mijn bedoeling om te bashen, en poog feitelijk weer te geven wat er gebeurt. Dat ik teleurgesteld ben in zowel de reactiesnelheid als de kwaliteit van het antwoord komt inderdaad wel luid en duidelijk over. Maar dat ben ik dan ook!
En dat komt dan weer omdat ik tot nog toe altijd heel snel én volledig ben geholpen door Tiscali. Tot deze keer vond ik de service en de geleverde diensten werkelijk uitstekend. En ik zou nog steeds een tevreden klant kunnen zijn als de beveiliging van mijn gegevens serieus wordt genomen. Dat geldt nog steeds, ik weet nu namelijk niet of die beveiliging wel of niet afdoende is.
Maar beveiliging gebaseerd op de mooie blauwe ogen van de individuele medewerker is geen beveiliging. Net zo min als bveiliging van de chipkaart die gebaseerd is op de aanname dat fraude strafbaar is en dus niet vóórkomt.

Wat natuurlijk helemaal mooi zou zijn is dat de wachtwoorden voortaan niet meer toegankelijk zijn voor de medewerkers. Maar wat mij betreft hoeft dat niet, een fatsoenlijk controlemechanisme waarmee op ongeoorloofde toegang wordt gecontroleerd is mij al goed genoeg.

[World Citizen]

ik heb ook een brief gehad, ik reageer vanavond.

(ik moet even mij standpunt formuleren)

[Dolan]

andreas2005 schreef op woensdag 16 januari 2008 @ 10:50:
[...]
Heel simpel: Ik had gevraagd naar het bestaan van procedures waarmee ze zorgen dat er geen misbruik van wordt gemaakt. Dáár wou ik van weten dat ze bestaan. Het antwoord van Telfort / Tiscali gaat daar helemaal niet over, en is daarom niet meer dan een kluit in een hele hoop riet .
Welk antwoord had mij tevreden gesteld:

De mededeling dat elke toegang tot de mailbox van een klant door een medewerker van tiscali wordt gelogd, en steekproefsgewijs wordt gecontroleerd. Bijvoorbeeld aan de hand van aangemaakte calls / problems of hoe ze ook heten bij Tiscali. Toegang tot de mailbox, maar geen call / ticketnummer? Dan heeft de betreffende medewerker het een en ander uit te leggen.
Dit is ook niet waterdicht, maar had mij het gevoel gegeven dat de privacy / beveiliging serieus wordt genomen.

Daarmee ben ik het eens.

andreas2005 schreef op woensdag 16 januari 2008 @ 10:50:
En misschien is er ook wel een dergelijk mechanisme, maar daar is in het geheel niks over gezegd door ze, en dat terwijl ik er toch echt naar vroeg!

Tja, probeer het nog een keer. Ik kan me vanuit beide posities (jou en de ISP) voorstellen dat er zo gereageerd wordt. Jij wilt graag alles weten en de ISP wilt niet teveel prijs geven over het beleid die ze voeren om reacties van heel Nederland (want wij weten toch altijd alles beter ) te voorkomen.

andreas2005 schreef op woensdag 16 januari 2008 @ 10:50:
Overigens, je beschuldigt mij van bashen, en ik geloof dat je je persoonlijk aangesproken voelt.

Allerminst. Ik werk niet bij Telfort of een andere ISP. Ik heb alleen genoeg ervaring met een aantal bedrijven dat ik heb geleerd in dit soort situaties objectief te blijven. Het gaat hier om één incident die misschien nog lichtelijk overdreven is door de TS (let op, geen beschuldiging, alleen een mogelijkheid) of verkeerd geïnterpreteerd is. Ik weet dat het leuk is om er gelijk sensatie van te maken, maar veel schiet je er niet mee op.

andreas2005 schreef op woensdag 16 januari 2008 @ 10:50:
Het is absoluut niet mijn bedoeling om te bashen, en poog feitelijk weer te geven wat er gebeurt. Dat ik teleurgesteld ben in zowel de reactiesnelheid als de kwaliteit van het antwoord komt inderdaad wel luid en duidelijk over. Maar dat ben ik dan ook!

Ook daar ben ik het mee eens. Houd er alleen wel rekening mee dat bij dergelijke grote bedrijven vaak mensen naar elkaar wijzen. Wie moet de brief schrijven in zo'n geval? Klantenservice omdat het over een klant gaat of de persvoorlichter omdat de radio ook al om opheldering vraagt?

Ik zeg niet dat dit gebeurt is, misschien zijn ze wel gewoon lui daar, maar dit is dus ook een mogelijkheid.

andreas2005 schreef op woensdag 16 januari 2008 @ 10:50:
En dat komt dan weer omdat ik tot nog toe altijd heel snel én volledig ben geholpen door Tiscali. Tot deze keer vond ik de service en de geleverde diensten werkelijk uitstekend. En ik zou nog steeds een tevreden klant kunnen zijn als de beveiliging van mijn gegevens serieus wordt genomen. Dat geldt nog steeds, ik weet nu namelijk niet of die beveiliging wel of niet afdoende is.
Maar beveiliging gebaseerd op de mooie blauwe ogen van de individuele medewerker is geen beveiliging. Net zo min als bveiliging van de chipkaart die gebaseerd is op de aanname dat fraude strafbaar is en dus niet vóórkomt.

Klopt. Iedereen wilt dat het goed beveiligd is.

andreas2005 schreef op woensdag 16 januari 2008 @ 10:50:
Wat natuurlijk helemaal mooi zou zijn is dat de wachtwoorden voortaan niet meer toegankelijk zijn voor de medewerkers. Maar wat mij betreft hoeft dat niet, een fatsoenlijk controlemechanisme waarmee op ongeoorloofde toegang wordt gecontroleerd is mij al goed genoeg.

Tja, zoals al eerder aangegeven is in dit topic zijn wachtwoorden vaak nodig voor de 'gemiddelde' gebruiker die alles gewoon snel opgelost wilt hebben. Dat blijft een discussiepunt. Sommige mensen zijn voor, sommige mensen zijn tegen.

[andreas2005]

Mijn vervolgvraag aan Telfort is inmiddels verzonden. Is er een controlemechanisme op misbruik? Ben benieuwd of ze durven antwoorden.

[kamerplant]

Ik denk dat je beter een aanvraag bij Xs4all kunt indienen. Xsx4all heeft de processen wat betreft security en privacy erg goed in elkaar zitten, het gevolg is wel dat je 60 euro meer voor een 20Mbps verbinding betaald vergeleken Telfort, maar dat lijkt mij een logisch gevolg.

[Dolan]

andreas2005 schreef op woensdag 16 januari 2008 @ 15:49:
Mijn vervolgvraag aan Telfort is inmiddels verzonden. Is er een controlemechanisme op misbruik? Ben benieuwd of ze durven antwoorden.

Ben eigenlijk benieuwd wat je gaat doen als ze antwoorden en ze zeggen "Nee".