Webmail: mails onterecht in spambox, verplaatsen naar inbox lukt niet
Marjolein Katsma
naar de webmail kijken. Wat layout foutjes (zoek formulier staat over
"ingelogd als" heen zodat dat niet te lezen is), maar het ziet er wel
aardig uit.
Jammer alleen dat de "zoekgeraakte" mails die ik inderdaad in the
spambox aantrof (waar ze geheel ten onrechte zitten!) NIET naar de inbox
verlpaats kunnen worden. Wat ik ook probeer (een voor een of beide
tegelijk, handmatig selecteren of met (de)Selecteer alles), er komt
niets in de inbox (ook geen kopie), en ze blijven staan in de spambox.
Dat is uiteraard niet de bedoeling van de functie "Verplaats
geselecteerde naar: ".
Doorsturen lukt wel (na het een voor een openen van de mails) maar is
geen echte oplossing - ze horen gewoon in de inbox en ik moet ze
vandaaruit normaal kunnen poppen. (Mijn enige reden om de webmail te
gebruiken is dus in de spambox kijken en eventueel eruit halen wat er
niet in hoort!)
Ook nogal irritant dat ik bij switchen van spambox naar inbox en vice
versa telkens weer opnieuw moet inloggen (ik zie een heleboel cookies,
maar ze zijn maar voor een mailbox - waarom niet een voor elke mailbox
zolang er ingelogd is?).
Jawel, cookies worden geaccepteerd and JavaScript staat aan.
Mozilla 1.7 op Win2K SP4.
Om misverstanden to voorkomen:
- niet kunnen verplaatsen vanuit spambox: dit betreft dus een (ernstige)
BUG.
- niet telkens opnieuw moeten inloggen bij wisselen mailbox: FEATURE
REQUEST
- layout (zoek formulier over "ingelogd als" heen): eveneens een BUG
Ziet eruit als een beta versie, dus....
--
Marjolein Katsma
*Help with HomeSite/Studio: http://hshelp.com/
*Travel blog: http://blog.iamback.com/
*Spam reporting addresses: http://banspam.javawoman.com/report3.html
Nelis
switchen tussen spam en inbox kan gewoon
inloggen op je gebruikersnaam en vandaaruit klikken op spambox,vandaaruit
kan je ook weer terug naar je inbox. en v.v. Werkt prima
Denk overigens dat het niet duidelijk kunnen zien van de pagina meer een
instelling van je browser/pc is, bij mij staat alles namelijk gewoon prima,
geen teksten over elkaar enzo.
wat betreft het verplaatsen vanuit spambox naar inbox zal ermee te maken
hebben dat het een andere pop-box betreft. wat is er mis met het gewoon
doorsturen daarvan. Overigens is XS reeds bezig met het maken van een white
list, zodat dat niet meer voor hoeft te komen
succes
--
Nelis
Er leiden meer wegen naar Rome, maar er is er maar 1 de juiste.
Frank Lekens
> Verwachte mail kwam niet aan in mijn mail client, dus ging ik maar eens
> naar de webmail kijken. Wat layout foutjes (zoek formulier staat over
> "ingelogd als" heen zodat dat niet te lezen is), maar het ziet er wel
> aardig uit.
>
> Jammer alleen dat de "zoekgeraakte" mails die ik inderdaad in the
> spambox aantrof (waar ze geheel ten onrechte zitten!) NIET naar de inbox
> verlpaats kunnen worden. Wat ik ook probeer (een voor een of beide
> tegelijk, handmatig selecteren of met (de)Selecteer alles), er komt
> niets in de inbox (ook geen kopie), en ze blijven staan in de spambox.
> Dat is uiteraard niet de bedoeling van de functie "Verplaats
> geselecteerde naar: ".
>
> Doorsturen lukt wel (na het een voor een openen van de mails) maar is
> geen echte oplossing - ze horen gewoon in de inbox en ik moet ze
> vandaaruit normaal kunnen poppen. (Mijn enige reden om de webmail te
> gebruiken is dus in de spambox kijken en eventueel eruit halen wat er
> niet in hoort!)
Wat wel kan, is je spambox POP-en. Natuurlijk eerst even snel in de webmail
de echte spam verwijderen, en dan poppen maar. Krijg je die mailtjes gewoon
binnen in je e-mailprogramma, volgens mij. En kun je ze beantwoorden met
een andere account.
> Ook nogal irritant dat ik bij switchen van spambox naar inbox en vice
> versa telkens weer opnieuw moet inloggen (ik zie een heleboel cookies,
> maar ze zijn maar voor een mailbox - waarom niet een voor elke mailbox
> zolang er ingelogd is?).
>
> Jawel, cookies worden geaccepteerd and JavaScript staat aan.
> Mozilla 1.7 op Win2K SP4.
>
> Om misverstanden to voorkomen:
> - niet kunnen verplaatsen vanuit spambox: dit betreft dus een (ernstige)
> BUG.
Mwah. Lijkt me een feature. Het zijn nu eenmaal aparte POP-boxen.
Waar ze wel over denken als nieuwe feature, is een whitelist. Dat lijkt me
een stuk nuttiger, als dat eenmaal werkt denk ik niet dat ik nog veel false
positives zal krijgen.
> - niet telkens opnieuw moeten inloggen bij wisselen mailbox: FEATURE
> REQUEST
Ahum... ik denk dat dit in gezinnen waarin verschillende gezinsleden elk
een aparte POP-box hebben, met eigen wachtwoord en een redelijke mate van
privacy, niet echt op prijs zou worden gesteld.
En tussen mail- en spambox kun je nu wel switchen zonder opnieuw inloggen.
Dwz als je op webmail inlogt onder je accountnaam, kun je zonder opnieuw in
te loggen doorklikken naar de spambox.
> - layout (zoek formulier over "ingelogd als" heen): eveneens een BUG
Het werkt nu allemaal even niet, dus ik kan niet kijken wat je bedoelt.
Maar ik kan me geen layout-problemen herinneren, en ik gebruik webmail elke
dag. Misschien iets te maken met de opties in je webmail? Daarin is wel een
en ander aan weergave in te stellen.
> Ziet eruit als een beta versie, dus....
Dat vind ik helemaal niet. Maar goed, ieder z'n meug.
Succes ermee.
--
Frank
(xs4all dot nl is where it's really @)
Nico Bartels
wrote:
>Jammer alleen dat de "zoekgeraakte" mails die ik inderdaad in the
>spambox aantrof (waar ze geheel ten onrechte zitten!)
Ze volgen de regels en blacklists die JIJ wil, dus zitten ze er niet
geheel ten onrechte. Hooguit kun je vinden dat de verzenders ten
onrechte in blacklists zitten, maar dat is dan aan die verzenders om de
beheerders van die blacklists te overtuigen met valide argumenten..
Zelf kun je natuurlijk de keus maken om blacklists waar jij het niet mee
eens bent niet te gebruiken. Lijkt mij dan een logische keus.
--
|\ |
| \|ico
Panic now and avoid the rush!
Marjolein Katsma
news:43a71870$0$24781$e4fe...@dreader32.news.xs4all.nl:
> switchen tussen spam en inbox kan gewoon
> inloggen op je gebruikersnaam en vandaaruit klikken op
> spambox,vandaaruit kan je ook weer terug naar je inbox. en v.v.
Jawel, dat kan wel, maar bij elke switch moet ik weer opnieuw inloggen.
> Denk overigens dat het niet duidelijk kunnen zien van de pagina meer
> een instelling van je browser/pc is, bij mij staat alles namelijk
> gewoon prima, geen teksten over elkaar enzo.
Gebruik je soms IE?
> wat betreft het verplaatsen vanuit spambox naar inbox zal ermee te
> maken hebben dat het een andere pop-box betreft.
Maar er is een prompt, een dropdown om een box te kiezen (INBOX) als
enige mogelijkheid) en een button om het verplaatsen uit te voeren.
Als dat niet zou moeten werken zou die user interface er niet moeten
zijn. Als de user interface er wel is is het logisch dat het ook zou
_moeten_ werken (maar dat doet het niet).
> wat is er mis met het gewoon doorsturen daarvan.
Niks gewoon - in de eerste plaats staan de betreffende mails al in de
verkeerde box (mail van dezelfde afzenders is altijd *gewoon*
binnengekomen). En als ik de mails doorstuur krijgen ze een andere
afzender en gaan de sorteerfilters niet werken. Als ik ze in de inbox
kan zetten zouden ze dezelfde afzender houden en hebben de filters ook
het gewenste effect.
> Overigens is XS reeds bezig met het maken van een white
> list, zodat dat niet meer voor hoeft te komen
Waarom gebeurt het plaatsen van deze mails in de spambox nu dan ineens
wel? Van reguliere afzenders waarvan mail altijd gewoon is ontvangen?
Daar zou ik toch geen white list voor nodig hebben?
Marjolein Katsma
news:kid7604rkild$.d...@coconino.nl:
>> - niet kunnen verplaatsen vanuit spambox: dit betreft dus een
>> (ernstige) BUG.
>
> Mwah. Lijkt me een feature. Het zijn nu eenmaal aparte POP-boxen.
Met een prompt, een dropdown en een button om te verplaatsen. DAT lijkt
me een feature. Dat die op zich zeer heldere en overduidelijk aanwezige
user interface dan niet werkt is dus een bug.
> Waar ze wel over denken als nieuwe feature, is een whitelist. Dat
> lijkt me een stuk nuttiger, als dat eenmaal werkt denk ik niet dat ik
> nog veel false positives zal krijgen.
Lijkt me helemaal niet nuttig voor mails van afzenders die gewoon moet
binnenkomen en tot nu toe ook altijd is binnengekomen.
> En tussen mail- en spambox kun je nu wel switchen zonder opnieuw
> inloggen. Dwz als je op webmail inlogt onder je accountnaam, kun je
> zonder opnieuw in te loggen doorklikken naar de spambox.
NIET dus: Een keer inloggen voor elk is redelijk; maar daarna wel
ingelogd blijven totdat je expliciet uitlogt - waarvoor dus TWEE sets
cookies moeten worden bijgehouden (en niet zoals nu maar een). Vandaar
de melding.
>> - layout (zoek formulier over "ingelogd als" heen): eveneens een BUG
>
> Het werkt nu allemaal even niet, dus ik kan niet kijken wat je
> bedoelt. Maar ik kan me geen layout-problemen herinneren, en ik
> gebruik webmail elke dag. Misschien iets te maken met de opties in je
> webmail? Daarin is wel een en ander aan weergave in te stellen.
Niks ingesteld - ik zie deze nieuwe webmail voor het eerst. Dan zou het
dus goed moeten worden weergegeven in elke fatsoenlijke browser
(waaronder ik zeker Mozilla reken). Lijkt me meer een CSS foutje maar ik
heb nog niet naar de CSS code gekeken maar toe ik twee half-verscholen
lettertjes zag kon ik er alleen achter komen wat er stond door naar de
HTML source te kijken.
>> Ziet eruit als een beta versie, dus....
>
> Dat vind ik helemaal niet. Maar goed, ieder z'n meug.
Ik kan me niet herinneren me als betatester te hebben aangemeld (en voor
de driemaal per jaar dat ik de webmail nodig heb is dat ook
onwaarschijnlijk) - maar ik vergeet wel eens vaker wat. ;)
Frank Lekens
> Frank Lekens (kraz...@goedlezen.invalid) wrote in
> news:kid7604rkild$.d...@coconino.nl:
>
>>> - niet kunnen verplaatsen vanuit spambox: dit betreft dus een
>>> (ernstige) BUG.
>>
>> Mwah. Lijkt me een feature. Het zijn nu eenmaal aparte POP-boxen.
>
> Met een prompt, een dropdown en een button om te verplaatsen. DAT lijkt
> me een feature. Dat die op zich zeer heldere en overduidelijk aanwezige
> user interface dan niet werkt is dus een bug.
Helder en overduidelijk aanwezig? En toch begrijp je die interface
verkeerd, volgens mij.
Met die inbox wordt niet de inbox van je POP-account bedoeld (hoe zou de
spam-account moeten weten naar wélke van de andere 4 pop-boxen het
verplaatst moet worden?). In dat dropdown-lijstje staan gewoon de mappen
van de op dat moment actieve POP-account, in dit geval: de spambox-account.
Wat je hooguit zou kunnen zeggen, is dat het verwarrend is dat die
dropdown-box ook in de Spambox te zien is -- want in de Spambox kún je
helemaal geen mappen aanmaken, laat staan berichten van map naar map
verplaatsen. (Of misschien kan het technisch of op shell-niveau of i.d.
wel, maar niet in de webmail-interface.)
>> Waar ze wel over denken als nieuwe feature, is een whitelist. Dat
>> lijkt me een stuk nuttiger, als dat eenmaal werkt denk ik niet dat ik
>> nog veel false positives zal krijgen.
>
> Lijkt me helemaal niet nuttig voor mails van afzenders die gewoon moet
> binnenkomen en tot nu toe ook altijd is binnengekomen.
Een whitelist lijkt mij gewoon *altijd* nuttig. Heb je die eenmaal goed
ingesteld, dan kunnen alleen nieuwe klanten of klanten die ineens hun adres
veranderen nog per ongeluk in je Spambox belanden.
En probeer eens uit te zoeken waarom die mail nu ineens in de Spambox
terechtgekomen is. Het is allicht vervelend -- maar wellicht ook heel goed
verklaarbaar.
>> En tussen mail- en spambox kun je nu wel switchen zonder opnieuw
>> inloggen. Dwz als je op webmail inlogt onder je accountnaam, kun je
>> zonder opnieuw in te loggen doorklikken naar de spambox.
>
> NIET dus: Een keer inloggen voor elk is redelijk; maar daarna wel
> ingelogd blijven totdat je expliciet uitlogt - waarvoor dus TWEE sets
> cookies moeten worden bijgehouden (en niet zoals nu maar een). Vandaar
> de melding.
Dat is dan een probleem dat zich ergens bij jou voordoet -- misschien in je
cookiebeheer? Ik heb er thuis (Firefox) nog op mijn werk (IE) last van.
Hoef nooit tweemaal in te loggen.
Wietse Muizelaar
> Op 19 Dec 2005 21:11:31 GMT schreef Marjolein Katsma:
>
>> Frank Lekens (kraz...@goedlezen.invalid) wrote in
>> news:kid7604rkild$.d...@coconino.nl:
[knip allemaal webmail-dingen]
>>> En tussen mail- en spambox kun je nu wel switchen zonder opnieuw
>>> inloggen. Dwz als je op webmail inlogt onder je accountnaam, kun je
>>> zonder opnieuw in te loggen doorklikken naar de spambox.
>>
>> NIET dus: Een keer inloggen voor elk is redelijk; maar daarna wel
>> ingelogd blijven totdat je expliciet uitlogt - waarvoor dus TWEE sets
>> cookies moeten worden bijgehouden (en niet zoals nu maar een). Vandaar
>> de melding.
>
> Dat is dan een probleem dat zich ergens bij jou voordoet -- misschien in je
> cookiebeheer? Ik heb er thuis (Firefox) nog op mijn werk (IE) last van.
> Hoef nooit tweemaal in te loggen.
Volgens mij was de extra eis om zonder inlog-actie te kunnen wisselen
van spam- en gewone inbox, dat de passwords van beide gelijk moesten zijn.
Althans, zoiets staat me bij.
--
Met vriendelijke groeten,
Wietse Muizelaar
Frank Lekens
O ja, dat klopt. Dat is wel zo, dat was ik vergeten.
En dat is dus makkelijk genoeg aan te passen.
Frank Lekens
Correctie, dat is natuurlijk *niet* in alle gevallen makkelijk aan te
passen (bijv. in gezin met verschillende pop-gebruikers met verschillende
wachtwoorden). Nou ja...
Dr.Ruud
> Een whitelist lijkt mij gewoon *altijd* nuttig. Heb je die eenmaal
> goed ingesteld, dan kunnen alleen nieuwe klanten of klanten die
> ineens hun adres veranderen nog per ongeluk in je Spambox belanden.
Maar vergeet de berichten met vervalste afzender(s!) niet, die kunnen
via whitelists weer ver komen.
--
Affijn, Ruud
"Gewoon is een tijger."
Dr.Ruud
> Waarom gebeurt het plaatsen van deze mails in de spambox nu dan ineens
> wel?
Kijk even in de X-XS4ALL- header fields van het bericht, want daar staat
in uitgespeld waarom.
> Van reguliere afzenders waarvan mail altijd gewoon is ontvangen?
Het hoeft helemaal niets met de afzender te maken te hebben. Het is
verder afhankelijk van welk spamfilter je hebt ingesteld.
Marjolein Katsma
@news.isolution.nl:
>> Van reguliere afzenders waarvan mail altijd gewoon is ontvangen?
>
> Het hoeft helemaal niets met de afzender te maken te hebben. Het is
> verder afhankelijk van welk spamfilter je hebt ingesteld.
Niks anders dan ik altijd heb gehad.
Het enige dat er veranderd is is de webmail.
Marjolein Katsma
news:slrndqeb84.u3l....@boudams.xs4all.nl:
> Volgens mij was de extra eis om zonder inlog-actie te kunnen wisselen
> van spam- en gewone inbox, dat de passwords van beide gelijk moesten
> zijn. Althans, zoiets staat me bij.
Dat zijn ze dus niet. (Natuurlijk niet!)
Ik kan me zoiets niet herinneren, maar ik mis wel eens wat als ik na een
lange reis terugkom.
Wat niet wegneemt dat er technisch geen enkele reden is om hetzelfde
password te vereisen: zoals gezegd, TWEE sets cookies in plaats van een is
voldoende. Kwestie van scriptje even aanpassen - maar dat doen ze met SM
toch al bij Xs4all.
Marjolein Katsma
>> O ja, dat klopt. Dat is wel zo, dat was ik vergeten.
>> En dat is dus makkelijk genoeg aan te passen.
>
> Correctie, dat is natuurlijk *niet* in alle gevallen makkelijk aan te
> passen (bijv. in gezin met verschillende pop-gebruikers met
> verschillende wachtwoorden). Nou ja...
Al is het gemakkelijk - ik prakkizeer er niet over om verschillende
boxen van hetzelfde password te voorzien. Een password is beveiliging,
en die werkt alleen maar als je het maar een keer gebruikt.
Marjolein Katsma
@news.isolution.nl:
>> Een whitelist lijkt mij gewoon *altijd* nuttig. Heb je die eenmaal
>> goed ingesteld, dan kunnen alleen nieuwe klanten of klanten die
>> ineens hun adres veranderen nog per ongeluk in je Spambox belanden.
>
> Maar vergeet de berichten met vervalste afzender(s!) niet, die kunnen
> via whitelists weer ver komen.
Ook al weer waar, al vind ik inderdaad dat een whitelist nuttig kan zijn.
De mate van nuttigheid hangt wel een beetje af van de implementatie
(alleen op "From:" header zou wel een tikje primitief zijn; op verzendend
IP adres of range al een stuk nuttiger).
Marjolein Katsma
news:hc7eq15esdr3ed1mm...@nbartels.net:
>>Jammer alleen dat de "zoekgeraakte" mails die ik inderdaad in the
>>spambox aantrof (waar ze geheel ten onrechte zitten!)
>
> Ze volgen de regels en blacklists die JIJ wil, dus zitten ze er niet
> geheel ten onrechte.
Ik heb HELEMAAL NIETS aan mijn regels veranderd, dus zouden zeker mails
die regelmatig gewoon binnenkomen dat nog steeds moeten doen.
Deze mails in mijn spambox is absoluut NIET iets dat ik wil en niet waar
ik om gevraagd heb.
Of de afzenders ten onrechte in een blacklist zitten (ik gebruik er maar
een paar) is inderdaad een mogelijkheid...
-
Wat blijft is dat ik van mening ben dat mails die ten onrechte in de
spambox gezet zijn gewoon daaruit verplaatst moeten kunnen worden. Bij
andere webmail systemen die ik ken is dat ook mogelijk - en een
alleszins logische mogelijkheid.
Afgezien van de interface die het wel mogelijk lijkt te maken (maar
niets doet): Er is niets waardoor dat technisch niet mogelijk zou zijn.
Kwestie van programmeren (en eventueel om een password vragen van de
mailbox waarnaar verplaatst moet worden als dat anders is dan dat van de
spambox). 't Is gewoon PHP en IMAP mailboxen zijn ook gewoon maar
bestandjes of directories met bestanden (afhankelijk van implementatie)
- als Xs4all hier hulp bij nodig heeft bied ik me graag aan. :)
En zolang het NIET kan graag even die domme userinterface verwijderen
die suggereert dat het wel kan - en zelfs geen foutmelding geeft als de
actie niet lukt!
Marjolein Katsma
> Met die inbox wordt niet de inbox van je POP-account bedoeld (hoe zou
> de spam-account moeten weten naar w‚lke van de andere 4 pop-boxen het
> verplaatst moet worden?). In dat dropdown-lijstje staan gewoon de
> mappen van de op dat moment actieve POP-account, in dit geval: de
> spambox-account.
Er staat dus een box in de dropdown, genaamd INBOX.
> Wat je hooguit zou kunnen zeggen, is dat het verwarrend is dat die
> dropdown-box ook in de Spambox te zien is -- want in de Spambox kún je
> helemaal geen mappen aanmaken, laat staan berichten van map naar map
> verplaatsen. (Of misschien kan het technisch of op shell-niveau of
> i.d. wel, maar niet in de webmail-interface.)
Als er geen INBOX is voor dat account zour helemaal geen userinterface
moeten zijn om iets te veplaatsen naar een niet-bestaande box. Dat is
dus niet alleen "verwarrend" maar een doodgewone bug. Slecht ontwerp,
verkeerde specificaties of verkeerd geimlementeerd, maar een bug is het
zeker.
>>> Waar ze wel over denken als nieuwe feature, is een whitelist. Dat
>>> lijkt me een stuk nuttiger, als dat eenmaal werkt denk ik niet dat
>>> ik nog veel false positives zal krijgen.
>>
>> Lijkt me helemaal niet nuttig voor mails van afzenders die gewoon
>> moet binnenkomen en tot nu toe ook altijd is binnengekomen.
>
> Een whitelist lijkt mij gewoon *altijd* nuttig. Heb je die eenmaal
> goed ingesteld, dan kunnen alleen nieuwe klanten of klanten die ineens
> hun adres veranderen nog per ongeluk in je Spambox belanden.
Ik ben met je eens dat in zijn algemeenheid een whitelist nuttig zou
zijn.
Met het onderhavige geval heeft het echter weinig te maken.
> En probeer eens uit te zoeken waarom die mail nu ineens in de Spambox
> terechtgekomen is. Het is allicht vervelend -- maar wellicht ook heel
> goed verklaarbaar.
Ja, ik ga eens spitten of uit de headers iets zinnigs valt af te leiden.
IK heb in elk geval niets veranderd aan welke instelling dan ook.
>> NIET dus: Een keer inloggen voor elk is redelijk; maar daarna wel
>> ingelogd blijven totdat je expliciet uitlogt - waarvoor dus TWEE
>> sets cookies moeten worden bijgehouden (en niet zoals nu maar een).
>> Vanndaar de melding.
>
> Dat is dan een probleem dat zich ergens bij jou voordoet -- misschien
> in je cookiebeheer? Ik heb er thuis (Firefox) nog op mijn werk (IE)
> last van. Hoef nooit tweemaal in te loggen.
Niks abnormaals mijn mijn cookeiesbeheer - ze worden gewoon
geacccepteerd, in dit geval niet eens voor alleen een sessie; ik kan ze
ook lezen (wat verklaart dat ik kan melden dat er maar een set - voor de
box waarnaar ik kijk - aanwezig is)
Marjolein Katsma
@news.isolution.nl:
>> Waarom gebeurt het plaatsen van deze mails in de spambox nu dan
>> ineens wel?
>
> Kijk even in de X-XS4ALL- header fields van het bericht, want daar
> staat in uitgespeld waarom.
"Sending machine is listed in bl.spamcop.net"
Jammer, want duidelijk onterecht in dit geval. De blacklist van SpamCop
is een van de meest betrouwbare (daarom gebruik ik die OOK op mijn eigen
server!) maar aangezien die wel grotendeels afhankelijk is van meldingen
van gebruikers komt er soms een onterechte listing in.
In dit geval niet meer dan een doorgeefluik voor mails waarvan de
gebruikers (van dat doorgeeflijk) juist spam willen voorkomen door
"weggooi" email adressen aan te maken.
SpamCop meldt (http://www.spamcop.net/w3m?action=checkblock&ip=
209.190.47.10):
~~~
Causes of listing
* System has sent mail to SpamCop spam traps in the past week (spam
traps are secret, no reports or evidence are provided by SpamCop)
* It appears this listing is caused by misdirected bounces. We have
a FAQ which covers this topic: Why auto-responses are bad (Misdirected
bounces). Please read this FAQ and heed the advice contained in it.
~~~
Hmm...
Scenario:
- spammer of virus gebruikt een "weggooi" adres bij deze dienst als
afzender (normale zaak)
- ontvangend mailsysteem "bouncet" de virus of spam mail naar de
vermeende afzender (adres bij de dienst) - iets wat nog steeds VEEL te
veel voorkomt - ... die het dan weer naar de eigenaar van het weggooi
adres doorstuurt.
- "eigenaar" van dat adres is een spamtrap
Iets anders kan ik niet bedenken... en ik zie niet in hoe de dienst zou
kunnen weten dat het adres gekoppeld aan een adres van hen een spamtrap
adres is.
De echte boosdoener is de server die de virus/spam mail bouncet.
Jan H
>En zolang het NIET kan graag even die domme userinterface verwijderen
>die suggereert dat het wel kan - en zelfs geen foutmelding geeft als de
>actie niet lukt!
Helemaal mee eens! Gebruikers met IE zien in het voortgangsbalkje dat
er kennelijk iets gebeurt, maar er gebeurt dus nada. Heel verwarrend!
Jan
Han Willemsen
> Een password is beveiliging, en die werkt alleen maar als je het maar
> een keer gebruikt.
Dat is een interessante stelling.
]-[an.
--
==================================================
= Han Willemsen - <will...@xs4all.nl> =
= Via IPv6 - Utrecht - Netherlands =
==================================================
A r d
enkels onderste boven, getergd erkende xij:
> Dr.Ruud (rvtol...@isolution.nl) wrote in news:do7gds.1cs.1
> @news.isolution.nl:
>
> > Kijk even in de X-XS4ALL- header fields van het bericht, want daar
> > staat in uitgespeld waarom.
>
> "Sending machine is listed in bl.spamcop.net"
Je tart elke logica:
1. De blacklist-setup van XS lijkt mij dusdanig
getest/doorontwikkeld dat de mail welke op basis van een blacklist
getagt wordt, daadwerkelijk op die blacklist voorkomt/voorkwam bij
binnenkomst. Ergo, TERECHT in je spambox komt (dan wel gereject
wordt).
> Jammer, want duidelijk onterecht in dit geval. De blacklist van SpamCop
> is een van de meest betrouwbare (daarom gebruik ik die OOK op mijn eigen
> server!) maar aangezien die wel grotendeels afhankelijk is van meldingen
> van gebruikers komt er soms een onterechte listing in.
2. Dit maakt dat SpamCop per definitie e1n van de minst betrouwbare
blacklists is.
--
Grtx, Ard ( @ @ ) drA ,xtrG
------------------------o00o--(. .)--o00o-------------------------
Your mileage may vary.
Burg
> Ook al weer waar, al vind ik inderdaad dat een whitelist nuttig kan zijn.
> De mate van nuttigheid hangt wel een beetje af van de implementatie
> (alleen op "From:" header zou wel een tikje primitief zijn; op verzendend
> IP adres of range al een stuk nuttiger).
Theoretisch geneuzel. Ik heb zo'n "primitieve" whitelist al meer dan 2 jaar
draaien, er is misschien 1 doorheen gekomen.
--
Burg in Thailand [1966-03-18]
Slrn 0.9.8.0 [2003-08-25]
SuSE Linux 9.1 (i586) [2.6.5-7.201-default quite stable]
Zoeken in ncol [http://www.xs4all.nl/~burgie/linux/search_ncol.html]
Timo
> Wat niet wegneemt dat er technisch geen enkele reden is om hetzelfde
> password te vereisen: zoals gezegd, TWEE sets cookies in plaats van een is
> voldoende. Kwestie van scriptje even aanpassen - maar dat doen ze met SM
> toch al bij Xs4all.
Twee sets cookies heeft geen zin zolang je browser maar 1 sessie ziet.
De cookie hoort bij die sessie, en de enige manier om (in Mozilla,
Firefox, IE en veel meer) een andere sessie te beginnen, is om de bestaande
te sluiten (ofwel, uitloggen).
Dat is ook de reden waarom het bij sites als yahoo, hotmail, gmail etc.
net zo werkt.
--
Timo
Eric Bus
> Al is het gemakkelijk - ik prakkizeer er niet over om verschillende
> boxen van hetzelfde password te voorzien. Een password is beveiliging,
> en die werkt alleen maar als je het maar een keer gebruikt.
Ben ik toch benieuwd: heb je zo weinig accounts of heb je zo'n
ijzersterk geheugen? :)
--
Eric
Dr.Ruud
> Dr.Ruud:
>> [attributie hersteld] Marjolein Katsma:
(je was ook nog vergeten de "(was:.*)" uit het Subject header field te
verwijderen)
>>> Waarom gebeurt het plaatsen van deze mails in de spambox nu dan
>>> ineens wel?
>>
>> Kijk even in de X-XS4ALL- header fields van het bericht, want daar
>> staat in uitgespeld waarom.
>
> "Sending machine is listed in bl.spamcop.net"
En de X-XS4ALL-SpamScore header?
> Jammer, want duidelijk onterecht in dit geval.
Ik weet niet wat jij onder "onterecht" verstaat, maar heb je enig idee
op welke manier een mailserver in die blacklist terecht komt? Het is te
vinden op www.spamcop.net
> De blacklist van
> SpamCop is een van de meest betrouwbare (daarom gebruik ik die OOK op
> mijn eigen server!) maar aangezien die wel grotendeels afhankelijk is
> van meldingen van gebruikers komt er soms een onterechte listing in.
Ik weet niet wat jij onder "betrouwbaar" verstaat, maar de blacklist van
SpamCop is niet "hard".
In het Service Center kun je bijvoorbeeld zien dat het xs4all-advies bij
"bl.spamcop.net" is: "niet gebruiken".
Die "bl.spamcop.net" staat in het default xs4all-spamfilter op "niet
gebruiken". Heb je misschien zelf een spamfilter aangemaakt en daarin
die lijst op Doorsturen gezet? Zo niet, dan betekent de "listed in
bl.spamcop.net" niet meer dan wat er letterlijk staat, dus zal de mail
niet (alleen) om die reden in je spambox terecht gekomen zijn. Wat was
de X-XS4ALL-SpamScore, en welke codes stonden erbij?
> De echte boosdoener is de server die de virus/spam mail bouncet.
Dat hoeft geen server te zijn. Het IP-nummer van de afleverende
mailserver komt in de SpamCop-blacklist. Als die bouncer dus bij
dezelfde club zit als degene van wie jij mail krijgt, en die bouncer
dezelfde mailserver(s) gebruikt om zijn bounces mee te verspreiden, dan
komt die mailserver in de black list.
Ik gebruik de mailbox van mijn hoofdaccount als xs4all-spambox (met een
zelf samengesteld spamfilter), en laat alleen mail blokkeren via de
blocklists (de blacklists met het "Spam blokkeren"-advies).
De weinige spam die dan nog doorkomt, zet ik vervolgens met
xs4all-procmail in een eigen spam-mailbox (en meld ik aan bij SpamCop).
Ik heb dus geen aparte spam-popbox, vind ik veel makkelijker.
Dr.Ruud
> Marjolein Katsma:
>> Ook al weer waar, al vind ik inderdaad dat een whitelist nuttig kan
>> zijn. De mate van nuttigheid hangt wel een beetje af van de
>> implementatie (alleen op "From:" header zou wel een tikje primitief
>> zijn; op verzendend IP adres of range al een stuk nuttiger).
>
> Theoretisch geneuzel. Ik heb zo'n "primitieve" whitelist al meer dan
> 2 jaar draaien, er is misschien 1 doorheen gekomen.
Projectie. Je eigen praktijk is niet werelddekkend.
Marjolein Katsma
(arosink@abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijk
.com) wrote in news:MPG.1e12362c7...@news.cistron.nl:
>> "Sending machine is listed in bl.spamcop.net"
>
> Je tart elke logica:
>
> 1. De blacklist-setup van XS lijkt mij dusdanig
> getest/doorontwikkeld dat de mail welke op basis van een blacklist
> getagt wordt, daadwerkelijk op die blacklist voorkomt/voorkwam bij
> binnenkomst. Ergo, TERECHT in je spambox komt (dan wel gereject
> wordt).
Ik tart helemaal geen logica. TERECHT zou inhouden dat de betreffende
sender ook TERECHT in the blacklist staat - wat in dit geval niet het
geval is.
>> Jammer, want duidelijk onterecht in dit geval. De blacklist van
>> SpamCop is een van de meest betrouwbare (daarom gebruik ik die OOK op
>> mijn eigen server!) maar aangezien die wel grotendeels afhankelijk is
>> van meldingen van gebruikers komt er soms een onterechte listing in.
>
> 2. Dit maakt dat SpamCop per definitie e1n van de minst betrouwbare
> blacklists is.
Ik weet niet wat voor "definitie" jij hanteert, maar ik ben het daar
niet mee eens. Kijk maar eens hoe andere blacklists "gevoed" worden. 0%
false positives is niet mogelijk maar de blacklist van SpamCop heeft wel
een van de laagste rates van false positives (overigens wel iets
vergroot toen de "spamtraps" werden toegevoegd, die juist vaak tot
onterechte listsings leiden, zoals ook in dit geval).
Marjolein Katsma
@news.isolution.nl:
> Ik weet niet wat jij onder "onterecht" verstaat, maar heb je enig idee
> op welke manier een mailserver in die blacklist terecht komt
Ja. En veel meer dan "enig".
Marjolein Katsma
@news.isolution.nl:
>> De blacklist van SpamCop is een van de meest betrouwbare (daarom
>> gebruik ik die OOK op mijn eigen server!) maar aangezien die wel
>> grotendeels afhankelijk is van meldingen van gebruikers komt er soms
>> een onterechte listing in.
>
> Ik weet niet wat jij onder "betrouwbaar" verstaat, maar de blacklist
> van SpamCop is niet "hard".
> In het Service Center kun je bijvoorbeeld zien dat het xs4all-advies
> bij "bl.spamcop.net" is: "niet gebruiken".
In mijn ervaring is de blacklist van SpamCop nog altijd zeer
betrouwbaar. Daarom gebruik ik die, op mijn eigen server en dus ook bij
Xs4all. "Betrouwbaar" betekent voor mij zo weinig mogelijk (kans op)
false positives.
> Heb je misschien zelf een spamfilter aangemaakt
Uiteraard - zie onder. :)
> en daarin die lijst op Doorsturen gezet?
Inderdaad, bl.spamcop.net staat op "doorsturen naar spambox". Blokkeren
doe ik bij Xs4all niet omdat ik nu en dan wil kunnen controleren wat de
resultaten zijn, en ik hier al meer blacklists gebruik dan op mijn eigen
server. Een aantal blacklists die deel uitmaken van het Xs4all
spamfilter gebruik ik echter juist niet omdat ik ze veel te
onbetrouwbaar vind gezien de wijze waarop ze gevoed (en geschoond, of
niet) worden.
Waarom de afleverende server in bl.spamcop.net staat heb ik al
aangegeven - lees de URL die ik citeerde er maar even op na.
Geen enkele blacklist is vrij van false positives, maar bij SpamCop ligt
het percentage laag. Toevallig loop ik er nu tegen een aan.
>> De echte boosdoener is de server die de virus/spam mail bouncet.
>
> Dat hoeft geen server te zijn. Het IP-nummer van de afleverende
> mailserver komt in de SpamCop-blacklist.
Maar het IS wel een server. Zie URL.
Marjolein Katsma
$e4fe...@news.xs4all.nl:
> Ben ik toch benieuwd: heb je zo weinig accounts of heb je zo'n
> ijzersterk geheugen? :)
Een ijzersterk (met wachtwoord beveiligd) geheugen. ;-) Ik hoef maar een
password te onthouden om er honderden te kunnen gebruiken. (Nou ja, twee -
ook nog eentje als ik onderweg ben en mijn eigen Squirrelmail gebruik om
mijn travel blog bij te werken - maar dan heb al die andere weer niet
nodig.)
Marjolein Katsma
news:43a8266a$0$11064$e4fe...@news.xs4all.nl:
> Twee sets cookies heeft geen zin zolang je browser maar 1 sessie ziet.
> De cookie hoort bij die sessie, en de enige manier om (in Mozilla,
> Firefox, IE en veel meer) een andere sessie te beginnen, is om de
> bestaande te sluiten (ofwel, uitloggen).
Een sessie kan best meerdere logins bijhouden - het is maar wat je in een
sessie opslaat.
Burg
> Projectie. Je eigen praktijk is niet werelddekkend.
Ik projecteer helemaal niks. Ik vertel alleen mijn eigen ervaring. Dat
jullie het in "Jullie wereld" nog niet voor elkaar krijgen om spam uit je
inbox te weren is weer een heel ander verhaal.
En wat bedoel je precies met werelddekkend?
Dr.Ruud
> Inderdaad, bl.spamcop.net staat op "doorsturen naar spambox". [...]
> Geen enkele blacklist is vrij van false positives, maar bij SpamCop
> ligt het percentage laag. Toevallig loop ik er nu tegen een aan.
Waarmee de berichten dus terecht in je spambox zijn terecht gekomen.
Begrijp je?
Dr.Ruud
> Inderdaad, bl.spamcop.net staat op "doorsturen naar spambox".
> Blokkeren doe ik bij Xs4all niet
Je vergeet de keuze Markeren.
> Een aantal blacklists die deel
> uitmaken van het Xs4all spamfilter gebruik ik echter juist niet omdat
> ik ze veel te onbetrouwbaar vind gezien de wijze waarop ze gevoed (en
> geschoond, of niet) worden.
Bekijk dan nog eens de blacklists waar het xs4all-advies "Blokkeren" bij
staat (ofwel de blocklists), en geef aan waar jij dat advies onterecht
vindt. Ik ben het tot nu toe eens met het aangegeven advies.
> Waarom de afleverende server in bl.spamcop.net staat heb ik al
> aangegeven - lees de URL die ik citeerde er maar even op na.
Nergens staat dat de geliste server ook de bouncer is, dus ik denk dat
je nog steeds het e.e.a. door elkaar gooit.
Een mailserver doet bij weigering i.h.a. een SMTP-reject, dus creëert
geen Non-Delivery Report (zie RFC 2821). De bounces die dit soort
ellende veroorzaken, komen meestal (met de frequente uitzondering van
Qmail-servers) van systemen voorbij de geliste mailserver.
Timo
> news:43a8266a$0$11064$e4fe...@news.xs4all.nl:
>
>> Twee sets cookies heeft geen zin zolang je browser maar 1 sessie ziet.
>> De cookie hoort bij die sessie, en de enige manier om (in Mozilla,
>> Firefox, IE en veel meer) een andere sessie te beginnen, is om de
>> bestaande te sluiten (ofwel, uitloggen).
>
> Een sessie kan best meerdere logins bijhouden - het is maar wat je in een
> sessie opslaat.
Nee, dat kan niet. Je zou in die cookie wel een andere login kunnen opnemen,
maar daar daar heb je niks aan, als jij 2 windows (= 1 session) open hebt
met webmail dan krijgt je browser van de server voor beide windows hetzelfde
cookie, en je browser doet niets anders dan braaf dat cookie terug sturen ter
identificatie van de session. Dus kan je browser nooit het verschil zien
tussen die 2 windows.
Als je dit wil omzeilen heb je een browser nodig die meerdere sessions aan
kan, of je moet 2 verschillende browsers naast elkaar gebruiken.
--
Timo
Dr.Ruud
> Dr.Ruud:
>> Ik weet niet wat jij onder "onterecht" verstaat, maar heb je enig
>> idee op welke manier een mailserver in die blacklist terecht komt
>
> Ja. En veel meer dan "enig".
Waarom kom je dan met een frase als "onterecht in spambox"? Je hebt
helemaal zelf ingesteld dat berichten die aan xs4all worden aangereikt
door een server die in de SpamCop-blacklist staat, naar je spambox
moeten worden doorgestuurd.
Frank Lekens
>>> Jammer, want duidelijk onterecht in dit geval. De blacklist van
>>> SpamCop is een van de meest betrouwbare (daarom gebruik ik die OOK op
>>> mijn eigen server!) maar aangezien die wel grotendeels afhankelijk is
>>> van meldingen van gebruikers komt er soms een onterechte listing in.
>>
>> 2. Dit maakt dat SpamCop per definitie e1n van de minst betrouwbare
>> blacklists is.
>
> Ik weet niet wat voor "definitie" jij hanteert, maar ik ben het daar
> niet mee eens. Kijk maar eens hoe andere blacklists "gevoed" worden. 0%
> false positives is niet mogelijk maar de blacklist van SpamCop heeft wel
> een van de laagste rates van false positives (overigens wel iets
> vergroot toen de "spamtraps" werden toegevoegd, die juist vaak tot
> onterechte listsings leiden, zoals ook in dit geval).
Huh? Als er één lijst is die bij mij vaak mailtjes onterecht in de Spambox
deed belanden, was het Spamcop wel. Die lijst heb ik in mijn filter al
heel lang op 'markeren' ipv 'doorsturen naar spambox' gezet.
xs4all adviseert voor die lijst zelf ook 'niet gebruiken' (maar goed, dat
doen ze voor wel heel veel lijsten).
Xs4all zelf heeft ook eens een tijdje onterecht op Spamcops blacklist
gestaan, geloof ik (het hele domein).
In ieder geval ligt de fout dus blijkbaar bij Spamcop, niet bij het
spamfilter an sich.
--
Frank
(xs4all dot nl is where it's really @)
Dr.Ruud
> Dr.Ruud:
>> Burg:
>>> [nut van whitelist hangt af van implementatie]
>>> Theoretisch geneuzel.
>>
>> Projectie. Je eigen praktijk is niet werelddekkend.
>
> Ik projecteer helemaal niks. Ik vertel alleen mijn eigen ervaring.
Welnee, je komt met "Theoretisch geneuzel."
> Dat
> jullie het in "Jullie wereld" nog niet voor elkaar krijgen om spam
> uit je inbox te weren is weer een heel ander verhaal.
Ik krijg precies de spam door die ik wil hebben, namelijk van de servers
die niet in een aantal bekende blocklists staan en die nog niet bij
SpamCop bekend zijn. Dat zijn de berichten waarvoor ik het de moeite
waard vind om ze aan te melden.
Ik heb daartoe ook spamtrap-adressen, dus adressen waar in een
wereld-zonder-spam geen mail op zou binnenkomen. Het gaat nu per dag om
zo'n 30 berichten.
J.B.
> Dr.Ruud (rvtol...@isolution.nl) wrote in news:do9ect.148.1
> @news.isolution.nl:
>
> >> De blacklist van SpamCop is een van de meest betrouwbare (daarom
> >> gebruik ik die OOK op mijn eigen server!) maar aangezien die wel
> >> grotendeels afhankelijk is van meldingen van gebruikers komt er soms
> >> een onterechte listing in.
> >
> > Ik weet niet wat jij onder "betrouwbaar" verstaat, maar de blacklist
> > van SpamCop is niet "hard".
> > In het Service Center kun je bijvoorbeeld zien dat het xs4all-advies
> > bij "bl.spamcop.net" is: "niet gebruiken".
>
> In mijn ervaring is de blacklist van SpamCop nog altijd zeer
> betrouwbaar. Daarom gebruik ik die, op mijn eigen server en dus ook bij
> Xs4all. "Betrouwbaar" betekent voor mij zo weinig mogelijk (kans op)
> false positives.
Ik heb spamcop zojuist verwijderd uit al mijn blacklist using systems,
vanwege hun blacklisting van een vrij grote smtp die nog nooit iets
verkeerds aan mij heeft verzonden, waar ik de admins van ken,
en van weet dat ze nooit schuldig kunnen zijn geweest aan spam.
Na informeren blijkt dat hun dispute regeling een conflict
(meningsverschil) opleverde tussen de betrokken admins,
en dat ze daardoor het IP niet wilde unlisten. Sois, sorry
voor spamcop, maar ik vertrouw er per heden niet meer op.
Dit staat geheel los van deze draad, overigens, maar ik
vertel het even om aan te geven dat dit geen op zichzelf
staand gebeuren is.
Nico Bartels
<kraz...@goedlezen.invalid> wrote:
>Huh? Als er één lijst is die bij mij vaak mailtjes onterecht in de Spambox
>deed belanden, was het Spamcop wel. Die lijst heb ik in mijn filter al
>heel lang op 'markeren' ipv 'doorsturen naar spambox' gezet.
Heb ik hier ook, Het gaat alhier nog wel naar een aparte 'effe checken'
folder, maar dus niet naar mijn spambox. Het gebeurt te vaak dat
legitieme mailinglist mail door een enthousiaste ontvanger gezien wordt
als spam en gerapporteerd wordt en derhalve mail van die list dankzij
die spamcop listing (m.i. onterecht) als spam wordt gemarkeerd.
Blokkeren op basis van Spamcop is dus helemaal uit den boze.
--
|\ |
| \|ico
Panic now and avoid the rush!
Marjolein Katsma
news:43a85fdf$0$11076$e4fe...@news.xs4all.nl:
>> Een sessie kan best meerdere logins bijhouden - het is maar wat je in
>> een sessie opslaat.
>
> Nee, dat kan niet. Je zou in die cookie wel een andere login kunnen
> opnemen, maar daar daar heb je niks aan, als jij 2 windows (= 1
> session) open hebt met webmail dan krijgt je browser van de server
> voor beide windows hetzelfde cookie, en je browser doet niets anders
> dan braaf dat cookie terug sturen ter identificatie van de session.
> Dus kan je browser nooit het verschil zien tussen die 2 windows.
Even afgezien van specifiek webmail:
Voor een site is slechts een cookie nodig om de sessie in stand te
houden. Binnen een sessie kunnen alle willekeurige gegevens worden
opgeslagen (en die gegevens kunnen indien gewenst) ook aan een URL
worden gekoppeld. DAT er een login geweest is voor UID1 kan dus worden
vastgehouden, en DAT er een login geweest is voor UID2 kan eveneens
worden vastgehouden. Of een login met UID2 wordt geinterpreteerd als
loguit voor UID1 is een kwestie van implementatie; al voor verschillende
UIDs verschillende inhouden moeten worden getoond kan dat door de
gegevens aan een URL te koppelen. Op die manier wordt het wel degelijk
mogelijk meerdere logins bij te houden in een en dezelfde sessie.
> Als je dit wil omzeilen heb je een browser nodig die meerdere sessions
> aan kan, of je moet 2 verschillende browsers naast elkaar gebruiken.
Het bijhouden van een sessie en alles wat daarbij wordt opgeslagen is
het werk van de server; een enkele cookie is van de kant van de browser
alles wat nodig is om aan te geven dat de sessie nog bestaat.
Door gebruik te maken van verschillende cookies kan het geheel nog
verfijnd worden (bijvoorbeeld een cookie per login, naast een session
cookie); de browser stuurt braaf *alle* cookies voor dezelfde server
terug dus kan de server gemakkelijk zien welke logins (nog) aktief zijn.
Dat het in het huidige webmail niet zo werkt is duidelijk - maar dat wil
niet zeggen dat het bijhouden van twee logins binnen een (browser)
sessie niet mogelijk is.
Miquel van Smoorenburg
Marjolein Katsma <nob...@example.net> wrote:
>Dat het in het huidige webmail niet zo werkt is duidelijk - maar dat wil
>niet zeggen dat het bijhouden van twee logins binnen een (browser)
>sessie niet mogelijk is.
Kan alleen als je verschillende URLs gebruikt voor de 2 sessies,
bv https://webmail.xs4all.nl/user/timo en ..../user/marjolein.
Of een redirect naar webmailsessie12345.webmail.xs4all.nl per
login, dat zou ook werken.
Zo werkt de xs webmail op dit moment niet. Geen idee hoe ingewikkeld
het is om te maken - de huidige webmail is een project van Cor,
althans de ontwikkeling niet het onderhoud, als-ie weer terug is
van vakantie kom er dan nog eens op terug zou ik zeggen.
Mike.
Robert
> Het bijhouden van een sessie en alles wat daarbij wordt opgeslagen is
> het werk van de server; een enkele cookie is van de kant van de browser
> alles wat nodig is om aan te geven dat de sessie nog bestaat.
Stop eens met het denken vanuit de server-kant, en probeer je eens te
verplaatsen naar de belevingswereld van een domme browser. Dan doe je
namelijk het volgende: a) elk cookie voor variabele X overschrijft het
vorige cookie voor die variabele en b) als je een cookie heb voor een
bepaalde server (en path), stuur je dat met *elk* volgende request mee.
En c) een request in een nieuw window ziet er exact hetzelfde uit als
een request in een bestaand window.
Combineer dat en de server heeft geen enkele mogelijkheid om verschil
te maken tussen beide windows. Wat jij ziet als 2 verschillende sessies,
ziet de server als een stroom requests die allemaal hetzelfde cookie
meesturen.
> Dat het in het huidige webmail niet zo werkt is duidelijk - maar dat wil
> niet zeggen dat het bijhouden van twee logins binnen een (browser)
> sessie niet mogelijk is.
Dat wordt pas mogelijk als webmail verschillende adressen maakt voor
verschillende logins, bijv. webmail.xs4all.nl/login1/,
webmail.xs4all.nl/login2/, webmail.xs4all.nl/login3/, etc. en die
informatie gebruikt in het path-veld van de cookies.
Groetjes,
Robert
JoopG
> Nico Bartels (nbar...@xs4all.nl) wrote in
> news:hc7eq15esdr3ed1mm...@nbartels.net:
>
>
>>>Jammer alleen dat de "zoekgeraakte" mails die ik inderdaad in the
>>>spambox aantrof (waar ze geheel ten onrechte zitten!)
>>
>>Ze volgen de regels en blacklists die JIJ wil, dus zitten ze er niet
>>geheel ten onrechte.
>
>
> Ik heb HELEMAAL NIETS aan mijn regels veranderd, dus zouden zeker mails
> die regelmatig gewoon binnenkomen dat nog steeds moeten doen.
>
> Deze mails in mijn spambox is absoluut NIET iets dat ik wil en niet waar
> ik om gevraagd heb.
>
> Of de afzenders ten onrechte in een blacklist zitten (ik gebruik er maar
> een paar) is inderdaad een mogelijkheid...
>
> -
>
> Wat blijft is dat ik van mening ben dat mails die ten onrechte in de
> spambox gezet zijn gewoon daaruit verplaatst moeten kunnen worden. Bij
> andere webmail systemen die ik ken is dat ook mogelijk - en een
> alleszins logische mogelijkheid.
>
> Afgezien van de interface die het wel mogelijk lijkt te maken (maar
> niets doet): Er is niets waardoor dat technisch niet mogelijk zou zijn.
> Kwestie van programmeren (en eventueel om een password vragen van de
> mailbox waarnaar verplaatst moet worden als dat anders is dan dat van de
> spambox). 't Is gewoon PHP en IMAP mailboxen zijn ook gewoon maar
> bestandjes of directories met bestanden (afhankelijk van implementatie)
> - als Xs4all hier hulp bij nodig heeft bied ik me graag aan. :)
>
Dit draadje lijkt me een heel slechte referentie voor je...
Joop
Marcel de Groot
>A r d
>(arosink@abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijk
>.com) wrote in news:MPG.1e12362c7...@news.cistron.nl:
>
>>> "Sending machine is listed in bl.spamcop.net"
>>
>> Je tart elke logica:
>>
>> 1. De blacklist-setup van XS lijkt mij dusdanig
>> getest/doorontwikkeld dat de mail welke op basis van een blacklist
>> getagt wordt, daadwerkelijk op die blacklist voorkomt/voorkwam bij
>> binnenkomst. Ergo, TERECHT in je spambox komt (dan wel gereject
>> wordt).
>
>Ik tart helemaal geen logica. TERECHT zou inhouden dat de betreffende
>sender ook TERECHT in the blacklist staat - wat in dit geval niet het
>geval is.
En hoe weet jij dat dat niet zo is?? Jij weet precies wat er allemaal
via die machine/mail server van de isp verzonden is?
>
>>> Jammer, want duidelijk onterecht in dit geval. De blacklist van
>>> SpamCop is een van de meest betrouwbare (daarom gebruik ik die OOK op
>>> mijn eigen server!) maar aangezien die wel grotendeels afhankelijk is
>>> van meldingen van gebruikers komt er soms een onterechte listing in.
>>
>> 2. Dit maakt dat SpamCop per definitie e1n van de minst betrouwbare
>> blacklists is.
>
>Ik weet niet wat voor "definitie" jij hanteert, maar ik ben het daar
>niet mee eens. Kijk maar eens hoe andere blacklists "gevoed" worden. 0%
>false positives is niet mogelijk maar de blacklist van SpamCop heeft wel
>een van de laagste rates van false positives (overigens wel iets
>vergroot toen de "spamtraps" werden toegevoegd, die juist vaak tot
>onterechte listsings leiden, zoals ook in dit geval).
Toch apart dan, dat XS4ALL adviseert om de spamcop blacklist niet te
gebruiken.. En deze iig bij mij ook de meeste false-positives geeft
juist omdat jan-en-alleman 'm kan gebruiken (of is dat misbruiken) om
spam mee aan te melden. Ik persoonlijk zou absoluut nooit blocken op
spamcop, juist omdat er zoveel false - positives in zitten.
Marcel
Peter Moone
>
> Ook nogal irritant dat ik bij switchen van spambox naar inbox en vice
> versa telkens weer opnieuw moet inloggen (ik zie een heleboel cookies,
> maar ze zijn maar voor een mailbox - waarom niet een voor elke mailbox
> zolang er ingelogd is?).
>
Als beide wachtwoorden gelijk zijn, schakel je naadloos over, maar dat
is al een keer of tachtig aan de orde geweest ;-)
--
Peter
Marjolein Katsma
news:6o1jq1ld9jkvne7rt...@4ax.com:
>>Ik tart helemaal geen logica. TERECHT zou inhouden dat de betreffende
>>sender ook TERECHT in the blacklist staat - wat in dit geval niet het
>>geval is.
>
> En hoe weet jij dat dat niet zo is?? Jij weet precies wat er allemaal
> via die machine/mail server van de isp verzonden is?
Dat weet ik inderdaad niet. Maar - zie scenario. Het is op z'n minst
uiterst onwaarschijnlijk gezien de aard van de dienst die als zendende
mail server optreedt.
>>Ik weet niet wat voor "definitie" jij hanteert, maar ik ben het daar
>>niet mee eens. Kijk maar eens hoe andere blacklists "gevoed" worden.
>>0% false positives is niet mogelijk maar de blacklist van SpamCop
>>heeft wel een van de laagste rates van false positives (overigens wel
>>iets vergroot toen de "spamtraps" werden toegevoegd, die juist vaak
>>tot onterechte listsings leiden, zoals ook in dit geval).
>
>
> Toch apart dan, dat XS4ALL adviseert om de spamcop blacklist niet te
> gebruiken.. En deze iig bij mij ook de meeste false-positives geeft
> juist omdat jan-en-alleman 'm kan gebruiken (of is dat misbruiken) om
> spam mee aan te melden. Ik persoonlijk zou absoluut nooit blocken op
> spamcop, juist omdat er zoveel false - positives in zitten.
Een advies is niet meer dan dat; en de adviezen die Xs4all bij de spam
filters geeft zijn denk ik vooral gericht op diegenen die niet zelf
onderzoek gaan doen over hoe de betreffende blacklists gevuld/geschoond
worden en op basis van hun bevindingen een afweging gaan maken.
Ik heb zo'n onderzoek wel gedaan en kom tot andere conclusies dan
Xs4all, dat is alles.
Wat hier voor mij geldt, geldt bovendien niet voor mij overal, of voor
iedereen; het is een kwestie van afwegen van voor- en nadelen en ook het
type spam dat (naar verwacht mag worden) wordt ontvangen. Mijn regels
voor het spamfilter bij Xs4all zien er dan ook anders uit dan die op
mijn eigen mail server - omdat het gebruik van de betreffende
emailadressen geheel verschillend is.
Marjolein Katsma
news:doa374$mv5$2...@news.cistron.nl:
>>Dat het in het huidige webmail niet zo werkt is duidelijk - maar dat
>>wil niet zeggen dat het bijhouden van twee logins binnen een (browser)
>>sessie niet mogelijk is.
>
> Kan alleen als je verschillende URLs gebruikt voor de 2 sessies,
> bv https://webmail.xs4all.nl/user/timo en ..../user/marjolein.
Inderdaad, dat zei ik ook:
"Of een login met UID2 wordt geinterpreteerd als loguit voor UID1 is een
kwestie van implementatie; al[s] voor verschillende UIDs verschillende
inhouden moeten worden getoond kan dat door de gegevens aan een URL te
koppelen."
> Zo werkt de xs webmail op dit moment niet. Geen idee hoe ingewikkeld
> het is om te maken - de huidige webmail is een project van Cor,
> althans de ontwikkeling niet het onderhoud, als-ie weer terug is
> van vakantie kom er dan nog eens op terug zou ik zeggen.
Ja, ik heb ook niet recentelijk in de code van Squirrelmail gespit, dus
hoe ingewikkeld het is voor deze specifieke software kan ik niet direckt
beoordelen (en al helemaal niet voor de Xs4all-variant - ik wil toch
aannemen dat Xs4all deze Open Source Software heeft gekozen *omdat* het
aangepast kan, en mag, worden).
Ik heb alleen willen aangeven dat het technisch wel degelijk mogelijk is
om binnen een (browser)sessie gegevens voor meerdere logins vast te
houden. Hoe moeilijk of gemakkelijk dat in de betreffende software te
realiseren is hangt uiteraard sterk af van de structuur van die
software. :)
Marjolein Katsma
news:slrndqh4...@wiet.xs4all.nl:
>> Het bijhouden van een sessie en alles wat daarbij wordt opgeslagen is
>> het werk van de server; een enkele cookie is van de kant van de
>> browser alles wat nodig is om aan te geven dat de sessie nog bestaat.
>
> Stop eens met het denken vanuit de server-kant, en probeer je eens te
> verplaatsen naar de belevingswereld van een domme browser. Dan doe je
> namelijk het volgende: a) elk cookie voor variabele X overschrijft het
> vorige cookie voor die variabele en b) als je een cookie heb voor een
> bepaalde server (en path), stuur je dat met *elk* volgende request
> mee. En c) een request in een nieuw window ziet er exact hetzelfde uit
> als een request in een bestaand window.
Dit berust op een misverstand: de *browser* houdt geen sessie bij, maar
schrijft, update of verwijdert alleen een cookie. WAT er die cookie
staat is de zaak van de server die hem aanmaakt en aan de browser
verzoekt hem op te slaan.
Een sessie onderhouden en bij de sessie behorende gegevens vastleggen is
de zaak van de server - en die gegevens hoeven helemaal niet in een
cookie te staan. Goed beschouwd heb je maar *een* cookie nodig, namelijk
die die de sessie *identificeert*. Met behulp van die indentificatie kan
de server opslaan wat hij maar wil - op de server.
De "domme browser" hoeft niet meer te doen dan (als haar baasje dit
toestaat) een cookie te onthouden of vast te leggen en terug te sturen
naar de eigenaar van de cookie (de server).
Een sessie = een cookie is voldoende. Zoals ik al heb uitgelegd, om
verschillende inhouden voor verschillende logins vast te houden kan
gebruik gemaakt worden van verschillende URLs die worden gekoppeld aan
verschillende *gegevens* (voor dezelfde sessie) op de server. De "domme
browser" hoeft nog steeds niet meer te doen dan een cookie voor die ne
server te onthouden.
> Combineer dat en de server heeft geen enkele mogelijkheid om verschil
> te maken tussen beide windows. Wat jij ziet als 2 verschillende
> sessies, ziet de server als een stroom requests die allemaal hetzelfde
> cookie meesturen.
Nee, ik heb het niet over twee verschillende sesies: ik heb het over EEN
sessie waarin gegevens voor verschillende logins (met bijbehorende
verschillende URLs) worden vastgehouden. En die ene sessie heeft nog
steeds maar EEN cookie nodig.
De *server* heeft gegevens nodig om de verschillende logins binnen *een*
sessie van elkaar te onderscheiden en dat kan door na inloggen naar
verschillende URLs te sturen en de (op de server) vast te legfen
gegevens aan die URL te koppelen.
>> Dat het in het huidige webmail niet zo werkt is duidelijk - maar dat
>> wil niet zeggen dat het bijhouden van twee logins binnen een
>> (browser) sessie niet mogelijk is.
>
> Dat wordt pas mogelijk als webmail verschillende adressen maakt voor
> verschillende logins, bijv. webmail.xs4all.nl/log> in1/,
> webmail.xs4all.nl/login2/, webmail.xs4all.nl/login3/, etc. en die
> informatie gebruikt in het path-veld van de cookies.
Ik heb inderdaad al aangegeven in de post waar jij op reageert dat je
binnen een sessie gegevens voor verschillende logins kunt bijhouden
*als* je gebruik maakt van verschillende URLs (zie mijn post en mijn
antwoord aan Mike!). Of je dat implementeert via de path-info van de
cookies is optioneel, je kunt de URL-gegevens (datgene wat ze
verschillend maakt) ook in de sessie zelf vastleggen (op de server dus).
Met "domme browsers" heeft dit alles niets te maken - wel met het
ontwerp van de software die op de server draait.
Marjolein Katsma
$e4fe...@news.xs4all.nl:
> Als beide wachtwoorden gelijk zijn, schakel je naadloos over, maar dat
> is al een keer of tachtig aan de orde geweest ;-)
Precies - evenals de redenen om de wachtwoorden NIET gelij aan elkaar te
houden. :)
Nico Bartels
wrote:
>Ik heb zo'n onderzoek wel gedaan en kom tot andere conclusies dan
>Xs4all, dat is alles.
Ja, jouw ene conclusie is dat het een prima blacklist is, terwijl je
tegelijkertijd tot de conclusie bent gekomen dat het juist niet zo'n
goeie blacklist is omdat het zorgt dat er gewenste mail in je spambox
komt. Make up your mind.. :-)
Robert
> Een sessie = een cookie is voldoende. Zoals ik al heb uitgelegd, om
> verschillende inhouden voor verschillende logins vast te houden kan
> gebruik gemaakt worden van verschillende URLs die worden gekoppeld aan
> verschillende *gegevens* (voor dezelfde sessie) op de server. De "domme
> browser" hoeft nog steeds niet meer te doen dan een cookie voor die ne
> server te onthouden.
Dan zijn we het eens. Ik wil wel benadrukken dat het gebruik van
verschillende URLs *noodzakelijk* is om dit werkend te krijgen.
> Met "domme browsers" heeft dit alles niets te maken - wel met het
> ontwerp van de software die op de server draait.
Je blijft als server denken, he? Leg mij eens stap-voor-stap uit, als ik
als domme browser het volgende doe, wat ik stuur en wat de server
terugstuurt in de volgende situatie:
1. Ik open een nieuw browser-venster. Noem het venster A.
2. In A ga ik naar webmail.xs4all.nl en log in als user aap. Een gevulde
mailbox verschijnt.
3. Ik open een nieuw browser-venster. Noem het venster B.
4. In B ga ik naar webmail.xs4all.nl en log in als user beer.
5. In A klik ik een mail aan.
Hoe wil je voor elkaar krijgen dat ik bij 5 de juiste mail zie?
Ga ervan uit dat ik vóór 2 nog geen cookie heb.
Groetjes,
Robert
Peter Moone
> Precies - evenals de redenen om de wachtwoorden NIET gelij aan elkaar te
> houden. :)
>
>
Klopt, daar schreef ik ook niets over.
--
Peter
Marjolein Katsma
> Ja, jouw ene conclusie is dat het een prima blacklist is, terwijl je
> tegelijkertijd tot de conclusie bent gekomen dat het juist niet zo'n
> goeie blacklist is omdat het zorgt dat er gewenste mail in je spambox
> komt. Make up your mind.. :-)
Dat heb ik al gedaan en ik heb ook gemeld dat GEEN blacklist 0% false
positives heeft.
Bovendien is zowel de wijze waarop een blacklist gevoed wordt als de wijze
waarop die *geschoond* wordt belangrijk. Die conmbinatie betekent voor mij
dat SpamCop een goede keus is - maar net als alle andere niet 100%
foutvrij, omdat dat nu eenmaal niet kan.
Marjolein Katsma
news:slrndqmk...@wiet.xs4all.nl:
> Je blijft als server denken, he?
Ja, want browsers hebben geen idee wat een server voor een sessi enodig
heeft. Als browser denken is dus zinloos - het enige dat telt is hoe
sessies op de server zijn geinmplementeerd.
> Leg mij eens stap-voor-stap uit, als
> ik als domme browser het volgende doe, wat ik stuur en wat de server
> terugstuurt in de volgende situatie:
>
> 1. Ik open een nieuw browser-venster. Noem het venster A.
> 2. In A ga ik naar webmail.xs4all.nl en log in als user aap. Een
> gevulde mailbox verschijnt.
> 3. Ik open een nieuw browser-venster. Noem het venster B.
> 4. In B ga ik naar webmail.xs4all.nl en log in als user beer.
> 5. In A klik ik een mail aan.
>
> Hoe wil je voor elkaar krijgen dat ik bij 5 de juiste mail zie?
> Ga ervan uit dat ik v형형r 2 nog geen cookie heb.
1. De server zorgt ervoor dat de gebruiker voor user A een andere URL te
zien krijgt dan voor user B.
2. De server legt voor de ene sessie (met in jouw voorbeeld toevallig
twee windows, maar het kan ook twee tabs zijn) gegevens vast voor zowel
user A (URL1) als user B (URL2).
De gedachten van de browser spelen hierbij totaal geen rol, alleen
implementatie op de server. De gedachten van de gebruiker achter de
browser spelen wel een rol, want er zal tenminste een sessie-cookie
moeten worden geaccepteerd.
Implementatie-technisch kan het eventueel handig zijn van meerdere
cookies gebruik te maken, maar een enkel session cookie per sessie is
voldoende om dit mogelijk te maken. De domme browser stuurt steeds het
ene sessie cookie terug naar de server die de eigenaar ervan is.
Robert
>> Ga ervan uit dat ik v형형r 2 nog geen cookie heb.
Je newsreader is stuque. Hij snapt mime-types en charsets niet.
> 1. De server zorgt ervoor dat de gebruiker voor user A een andere URL te
> zien krijgt dan voor user B.
> 2. De server legt voor de ene sessie (met in jouw voorbeeld toevallig
> twee windows, maar het kan ook twee tabs zijn) gegevens vast voor zowel
> user A (URL1) als user B (URL2).
Da's te summier. Ik bedoelde stap-voor-stap:
1. -
2.a. browser vraagt van webmail.xs4all.nl op, zonder cookie mee te sturen
b. server stuurt inlogscherm
c. browser stuurt username/password
d. server stuurt een cookie met de volgende sessiedata: a,b,c
3. -
4.a. browser vraagt webmail.xs4all.nl op en stuurt het cookie van 2d mee.
Etcetera. Ik betwijfel of het mogelijk is om veilig bij 5 te komen.
> Implementatie-technisch kan het eventueel handig zijn van meerdere
> cookies gebruik te maken, maar een enkel session cookie per sessie is
> voldoende om dit mogelijk te maken. De domme browser stuurt steeds het
> ene sessie cookie terug naar de server die de eigenaar ervan is.
Mijn vraag is dus of je een implementatie kunt laten zien, die werkt.
Groetjes,
Robert
Marjolein Katsma
news:slrndqtp...@wiet.xs4all.nl:
> Da's te summier. Ik bedoelde stap-voor-stap:
> 1. -
Gebruiker plaatst de URL van het inlog scherm in de bowser ;-)
> 2.a. browser vraagt van webmail.xs4all.nl op, zonder cookie mee te
> sturen
Allicht: er is nog geen (sessie) cookie
> b. server stuurt inlogscherm
MET cookie - op dit moment is het aan de gebruiker (of de gebruikers
instellingen van de browser) om het cookie te accepteren.
> c. browser stuurt username/password
MET cookie - indien het werd geaccepteerd.
> d. server stuurt een cookie met de volgende sessiedata: a,b,c
Nee - de server ONTVANGT de sessiecookie van de browser en kan op dit
moment een sessie creeren. De sessieDATA (specifiek voor de inlog)
worden op de server zelf vastgelegd (aannemende een correcte login
natuurlijk.
> 3. -
INDIEN de server het cookie heeft ontvangen en een sessie heeft kunnen
creeren stuurt hij de browser een redirect naar een inlog-specifieke URL
waarop de inbox voor DIE login kan worden getoond); ZONIET (cookie was
dus niet geaccepteerd) stuurt hij de browser een redirect naar een
foutmelding dat zonder het accepteren van een sessie-cookie een sessie
niet kan worden gecreeerd en het niet mogelijk is de webmail te
benaderen.
> 4.a. browser vraagt webmail.xs4all.nl op en stuurt het cookie van 2d
> mee.
Nee hoor, allang gedaan! :)
De server vraagt de login-specifieke URL op waarnaar de server had
geredirect om de bij de login behorende inbox te tonen; de sessiecookie
wordt opnieuw meegestuurd.
> Etcetera. Ik betwijfel of het mogelijk is om veilig bij 5 te komen.
Zie boven. Het *inlogscherm* stuurt al de sessiecookie mee naar de
browser, bij de submit van het inlogscherm wordt deze door de browser
teruggestuurd.
> Mijn vraag is dus of je een implementatie kunt laten zien, die werkt.
Zie boven - dat is het algoritme. Als dat nog niet genoeg is en je echt
een *implementatie* wilt zien, zal ik wat in m'n eigen Squirrelmail
moeten sleutelen, natuurlijk, want die werkt op dit moment maar voor een
login. Of iets anders in elkaar knutselen. Het algoritme blijft
hetzelfde. ;-)
J.B.
> MET cookie - op dit moment is het aan de gebruiker (of de gebruikers
> instellingen van de browser) om het cookie te accepteren.
De cookie.
Robert
> Zie boven - dat is het algoritme. Als dat nog niet genoeg is en je echt
> een *implementatie* wilt zien, zal ik wat in m'n eigen Squirrelmail
> moeten sleutelen, natuurlijk, want die werkt op dit moment maar voor een
> login. Of iets anders in elkaar knutselen. Het algoritme blijft
> hetzelfde. ;-)
Als je het werkend krijgt, stuur dan gelijk je patches op naar Squirrelmail.
Wij doen geen source-patches meer, want dat kost teveel onderhoud op de
lange termijn.
Groetjes,
Robert