smtp.xs4all.nl

On 2004-08-25, Onno <oag@_xs4all.nl> wrote:

> argumenten klopt gewoon niet. Vertel mij inhoudelijk (en niet, door spam en
> virussen) waarom je geen 100 % garantie kan geven dat (en lees goed):
>
> MAIL OF NIET GEACCEPTEERD WORDT OF IS OPGESLAGEN OP NON VOLATILE STORAGE DIE
> REDUNDANT IS

Redundant != 100%.

> gebounced wordt als dat niet lukt. Doe me maar een netapp storage (heb ik
> veel ervaring mee)

Heeft xs4all ook veel ervaring mee. Dat gaat vrijwel altijd goed, tot opeens
op een dag de NetApp er niet zo'n zin meer in had.

> dat is nogmaals niet de issue, mij gaat het om het protocol voor e-mail, als
> je received gaat zitten zenden voordat je hem hebt opgeslagen/gelogged en 1
> ms later de stroom uitvalt of je cpu doorbrandt is de mail pleite.

Ja, en als je mail op hebt geslagen, "OK" aan de verzendende partij hebt
gestuurd, en je filesystem wordt vernaggeld door 1 of andere kernelbug ofzo,
is je mail pleite, zonder bounce. En dan maakt het niet uit hoeveel keer je
de storage redundant hebt uitgevoerd.

100% haal je *nooit*, je komt er hooguit steeds dichter bij in de buurt.

--
Jurjen Oskam
"I often reflect that if "privileges" had been called "responsibilities" or
"duties", I would have saved thousands of hours explaining to people why
they were only gonna get them over my dead body." - Lee K. Gleason, VMS sysadmin

On 2004-08-25, Onno <oag@_xs4all.nl> wrote:

> If smtp mailfrom->
> Try(store)
> {
> catch disk_full:
> ERR
> catch no_more_cpu
> time out
> etc.
> Sync cache
> Verify store
> Log mail
> Send OK
> End if

Je gaat uit van de incorrecte aanname dat als het "opslaan" gelukt is
(eventueel met zoveel controleslagen als je wil), het daarna onmogelijk is
om hetgeen wat opgeslagen is nog te verliezen. Die aanname is, zoals gezegd,
incorrect.

> Je moet dus de code zo maken dat bepaalde dingen niet KUNNEN. Een verify
> betekent dat je de mail van de disk probeert te lezen die je hebt
> opgeslagen, als die er goed opstaat kan je OK geven.

Als de verify lukt betekent dat dat het lezen *die ene keer* goed is gelukt.
Het betekent *niet* dat het lezen *de volgende keer* ook nog zal lukken.

--
Jurjen Oskam
"I often reflect that if "privileges" had been called "responsibilities" or
"duties", I would have saved thousands of hours explaining to people why
they were only gonna get them over my dead body." - Lee K. Gleason, VMS sysadmin

"Onno" <oag@_xs4all.nl> schreef ...

<>

> Gelukkig moeten we binnenkort geloof ik alle mail gaan bewaren, dus
dan
> kunnen we bij alle servers ertussen nog een kopietje opvragen ;-) De
> providers dienen alle e-mail voortaan te forwarden naar
info@overheid.nl,
> dus ook spam en virussen.


Waar kan ik dit nalezen? Je gebruikt 'geloof ik', maar het gerucht zal
toch wel ergens vandaan komen?

Douwe

On 2004-08-25, Douwe <douwe_in_nl@yahoo.com> wrote:
> Waar kan ik dit nalezen? Je gebruikt 'geloof ik', maar het gerucht zal
> toch wel ergens vandaan komen?

Oh jazeker hoor, mensen die onbekend zijn met het begrip 'begrijpend
lezen' en die tevens niet weten hoe aftappen technisch werkt, die gaan
dat soort dingen roepen.

--
Riemer Palstra
riemer@palstra.com

>Zoals ik ergens anders aangeef, het negeren (nietes) van mijn keiharde
>argumenten klopt gewoon niet. Vertel mij inhoudelijk (en niet, door spam en
>virussen) waarom je geen 100 % garantie kan geven dat (en lees goed):

>MAIL OF NIET GEACCEPTEERD WORDT OF IS OPGESLAGEN OP NON VOLATILE STORAGE DIE
>REDUNDANT IS

>En dan niet komen met kernbommen oid, das flauw. Ik zeg dus niet dat de
>mailomgeving altijd mail correct kan ontvangen, maar wel dat ie dan ook de
>verzendende mailserver geen OK moet geven zoals het procotol toelaat. En de
>verzendende mailserver kan het dan later nogmaals proberen of een
>foutrapport mailen naar de verstuurder. Mail komt OF aan OF je krijgt een
>foutmelding.

Hoe kan het dan dat die mail waar jij over klaagde was verdwenen op jouw
mailserver? Blijkbaar had jouw server de mail gewoon geaccepteerd en is
ie toen verdwenen?

Cor

Jurjen Oskam <joskam@quadpro.stupendous.org> wrote:
>On 2004-08-25, Onno <oag@_xs4all.nl> wrote:
>
>> Je moet dus de code zo maken dat bepaalde dingen niet KUNNEN. Een verify
>> betekent dat je de mail van de disk probeert te lezen die je hebt
>> opgeslagen, als die er goed opstaat kan je OK geven.
>
>Als de verify lukt betekent dat dat het lezen *die ene keer* goed is gelukt.
>Het betekent *niet* dat het lezen *de volgende keer* ook nog zal lukken.

Ik ben ook wel benieuwd wat voor 'n impact een dergelijke "100%"
controle zal hebben op de throughput van het mailsysteem. Dit is leuk
als je 10 mailtjes per minuut ontvangt, met 10 of meer per seconde wordt
het al interessanter.


Ik vind het al zo mooi dat data lezen vanaf een disk zo vaak goed gaat.
Je moet eens voor de gein disk specs nalezen:

Nonrecoverable read errors 1 per 10^14 bits read

(van een willekeurige seagate SATA)

100GB is 10^11 bytes, zeg maar 10^12 bits (incl. overhead). Dus een
200GB disk 50 x lezen levert gemiddeld 1 fout op. Da's dus 99,heleboelx9
procent, ook geen 100%.


Paul Slootman

In article <cgidp8$o5k$1@news.cistron.nl>, Paul Slootman wrote:
> [ ... ]
> Ik vind het al zo mooi dat data lezen vanaf een disk zo vaak goed gaat.
> Je moet eens voor de gein disk specs nalezen:
>
> Nonrecoverable read errors 1 per 10^14 bits read
>
> (van een willekeurige seagate SATA)
>
> 100GB is 10^11 bytes, zeg maar 10^12 bits (incl. overhead). Dus een
> 200GB disk 50 x lezen levert gemiddeld 1 fout op. Da's dus 99,heleboelx9
> procent, ook geen 100%.

Daarom ondervang je dat soort risico's dan ook vaak met zaken als RAID...
(wat zaken als FS corruptie natuurlijk nog niet doet verdwijnen... )

> Paul Slootman

Groetjes,
JP Velders

On 2004-08-25, JP Velders <jpv@news.veldersjes.net> wrote:

> Daarom ondervang je dat soort risico's dan ook vaak met zaken als RAID...

Als de kans op een single failure (van 1 disk) ongelijk nul is, is de kans
van een double failure ook niet nul. Bij een double failure op RAID5 sta je
alsnog met een bek vol tanden en een RAID zonder data.

FS-corruptie, natuurlijk. Maar rm -rf? Fouten in NFS? Locking-problemen? Een
worker-thread in OnTap die wel 'OK' roept maar doodgaat bij het flushen van
de queue? Rotte sector onder de kop?

Onno lijkt, juist vanwege z'n volhardend volhouden dat 100.00000000000000%
te doen is erg onbekend met de faalbaarheid van hardware, software en de
optelsom daarvan.

Laat een wiskunde alle faalfrequenties van alle onderdelen van je systeem
narekenen en hij toont je aan dat booten onmogelijk is.

ER ZIJN GEEN ABSOLUTE ZEKERHEDEN IN HET LEVEN. (En zelfs dat is niet zeker,
hooguit behoorlijk waarschijnlijk.)

Onno mag beginnen met definieren wat een acceptabele foutfrequentie voor z'n
eigen mailserver is. Dan rekenen we even voor hoeveel het 'm gaat kosten om
die te halen.

--
Ruben
"Conversation would be vastly improved by the constant use of four
simple words: I don't know." André Maurois

> Hoe kan het dan dat die mail waar jij over klaagde was verdwenen op jouw
> mailserver? Blijkbaar had jouw server de mail gewoon geaccepteerd en is
> ie toen verdwenen?

Cor, ik kan niet bewijzen dat jullie de mail niet bezorgden, andersom lijkt
het me ook sterk. Maar een goed voorbeeld xs4all ellende:

www.kroonkameleon.nl

Als ik die intype in mijn browser via xs4all doet deze domeinnaam het niet.
Dit is een grote klant, wij hebben brieven gestuurd, gemailed, etc. Ooit was
dat domein bij xs4all geregistreerd en later naar mij verhuisd. Jullie
weigeren het te deleten uit dns en mailservers.

Heel vaak hebben we dit gehad met andere klanten, meestal dat de DNS wel
gedelete was maar de mail via xs4all niet aankwam. Ik heb alleen geen zin om
te melden wat er allemaal niet goed gaat bij xs4all maar deze is denk ik al
voldoende om eens te kijken naar hoeveel dingen fout KUNNEN gaan bij jullie.

Wat deze site betreft hebben we het maar opgegeven, een deel van jullie DNS
doet alleen dns via rootservers, een deel van jullie DNS doet ook de door
jullie gehoste zaken. Deze DNS is enorm vervuild met vele domeinen die
helemaal niet meer bij jullie staan. Ga dat maar oplossen ipv bijdehand te
doen...dit domein is al een jaar geleden naar mij verhuisd, jullie zouden me
terug bellen, LOL

De DNS die ik gebruik:

194.109.9.99
194.109.6.66

Als je de 194.109.104.104 gebruikt gaat het wel goed geloof ik maar de 2
bovenstaande gebruiken veel mensen waaronder ik. Er is geen enkel excuus
voor, xs4all is een slechte provider die na tig keer bellen nog steeds dit
niet heeft kunnen oplossen.

Ik weet ook dat het beleid is om concullega providers te saboteren bij het
verhuizen van domeinen e.d. dus wees trots op je werkgever...geen excuus
ervoor dat dit nog steeds in jullie DNS staat. Je kan een ontheffing krijgen
bij de SIDN en dan periodiek alle domeinen eruit flikkeren die niet meer
gekoppeld zijn aan je DNS (of ze nu wel of niet als registrar bij jullie of
jullie CNO reseller staan).

Ipv te trollen op usenet zou je eerst dit fundamentele probleem eens moeten
oplossen.

Vandaar Cor dat als er iets mis is ik aan xs4all denk, want dat bedrijf
functioneerd niet altijd even goed zoals ik je nu onweerlegbaar heb
aangetoond. Kroonkameleon is van kroon leverworst in samenwerking met de
kameleon boekenreeks, er is een hele campagne naar lagere scholen gestuurd
met verzamelplaatjes en de xs4all klanten konden deels niet
meedoen......lang leve Cor met een plaat voor zijn kop want je kunt nu
eenmaal niet alle klanten netjes behandelen????

> Als de verify lukt betekent dat dat het lezen *die ene keer* goed is
gelukt.
> Het betekent *niet* dat het lezen *de volgende keer* ook nog zal lukken.

www.google.com

Reliable storage device. Of zoek eens op raid, lol. iscsi etc. Er zijn wel
degelijk transactie systemen die storage gebruiken die na verify dus echt
wel (gemirrored) is opgeslagen. Desnoods sla je het op op een linux en bsd
server, I don't care. Maar ik snap het al, wordt een welles nietes
verhaal...want als aliens je server hacken kan de mail toch verdwijnen,
VOOODOOO

Als jij niet te overtuigen bent van non volatile storage die dankzij
mirroring gegarandeert de data zo opslaat dat ie terug te lezen is houd het
op...

> Onno lijkt, juist vanwege z'n volhardend volhouden dat 100.00000000000000%
> te doen is erg onbekend met de faalbaarheid van hardware, software en de
> optelsom daarvan.

Als je voldoende backups maakt kan je heel wat nullen achter de komma
krijgen ja. En je kan het dupliceren op verschillende filesystems, etc.
Hoeveel nullen achter de komma je wil hangt af van je budget lijkt mij, maar
het kan zo ver als je wil...

EOT

Onno <oag@_xs4all.nl> wrote:
>
>> Onno lijkt, juist vanwege z'n volhardend volhouden dat 100.00000000000000%
>> te doen is erg onbekend met de faalbaarheid van hardware, software en de
>> optelsom daarvan.
>
>Als je voldoende backups maakt kan je heel wat nullen achter de komma
>krijgen ja. En je kan het dupliceren op verschillende filesystems, etc.
>Hoeveel nullen achter de komma je wil hangt af van je budget lijkt mij, maar
>het kan zo ver als je wil...

Volgens mij mis je hier juist een essentiele punt:
het aantal nullen achter de komma maakt niks uit :-)
Het is dus 99, met achter de komma een heleboel 9's; hoe meer hoe beter.
Het kan de 100 wel benaderen, maar zal het nooit worden.


Paul Slootman

>Cor, ik kan niet bewijzen dat jullie de mail niet bezorgden, andersom lijkt
>het me ook sterk. Maar een goed voorbeeld xs4all ellende:

Sorry hoor Onno, maar de krampachtigheid waarmee je vasthoud aan je theorie
dat wij die email niet bezorgd hebben is een beetje ver gezocht.
Die mail is gewoon bezorgd, punt. Ik zeg dat niet omdat ik zou proberen
de dans te ontspringen ofzo, maar omdat het gewoon feitelijk zo is.
Ik heb je mail IDs gegeven waarmee jij dat moet kunnen opzoeken. Onze
mailserver verzint die mailids echt niet. Die geef jij ons, als het goed
is nadat jouw mailserver 100% zeker is dat de mail op de harddisk staat.

>www.kroonkameleon.nl

>Als ik die intype in mijn browser via xs4all doet deze domeinnaam het niet.
>Dit is een grote klant, wij hebben brieven gestuurd, gemailed, etc. Ooit was
>dat domein bij xs4all geregistreerd en later naar mij verhuisd. Jullie
>weigeren het te deleten uit dns en mailservers.

Laat dit eens zien met wat output van dns tools ofzo. Ik kan het niet
direkt reproduceren.

>Heel vaak hebben we dit gehad met andere klanten, meestal dat de DNS wel
>gedelete was maar de mail via xs4all niet aankwam. Ik heb alleen geen zin om
>te melden wat er allemaal niet goed gaat bij xs4all maar deze is denk ik al
>voldoende om eens te kijken naar hoeveel dingen fout KUNNEN gaan bij jullie.

Ik ben er niet van overtuigd dat dit een probleem van ons is, net zoals ik
er niet van overtuigd was dat je email die niet aankwam een probleem van ons
was. Wat achteraf dus inderdaad gewoon bij jou lag.

Om te beginnen, doe je wat raars met je DNS.

dig @ns.nic.nl ns kroonkameleon.nl.
kroonkameleon.nl. 1D IN NS ns0.selious.com.
kroonkameleon.nl. 1D IN NS ns2.selious.com.

dig @ns0.selious.com. ns kroonkameleon.nl.
kroonkameleon.nl. 1H IN NS ns3.selious.com.
kroonkameleon.nl. 1H IN NS ns4.selious.com.

Het zou handig zijn als je nameservers consistent zouden zijn in wie
authorative is voor kroonkameleon.nl. Ik weet niet of dit deels je
probleem van verklaren, gok van niet, maar onhandig is het wel.

>helemaal niet meer bij jullie staan. Ga dat maar oplossen ipv bijdehand te
>doen...dit domein is al een jaar geleden naar mij verhuisd, jullie zouden me
>terug bellen, LOL

Jouw redenatie is dus als volgt:

"Help XS4ALL verliest mijn email, wat een kut provider"
"Het ligt aan jezelf Onno, kijk maar.. <bewijs geleverd>"
"Oh ja, nou.. je hebt ook dit (mogelijke) probleem, dus ga nou niet
bijehand doen".

Snap ik dat goed?

>Vandaar Cor dat als er iets mis is ik aan xs4all denk, want dat bedrijf
>functioneerd niet altijd even goed zoals ik je nu onweerlegbaar heb
>aangetoond. Kroonkameleon is van kroon leverworst in samenwerking met de

Net zo onweerlegbaar als jouw email probleem zeker? Ik heb weinig zin om
nu een reeks mogelijke problemen te gaan uitzoeken. Deze thread ging over
email die je kwijt raakte. Je weet nu waarom, tijd om je mailserver te
fixen.

Groeten,

Cor

Onno wrote:
> Maar een goed voorbeeld xs4all ellende:
> www.kroonkameleon.nl
> Als ik die intype in mijn browser via xs4all doet deze domeinnaam het niet.

Daarbuiten ook niet:

#dig www.kroonkameleon.nl. a
....
;; connection timed out; no servers could be reached

Of, met een andere dig versie:
....
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 58657
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

> Dit is een grote klant, wij hebben brieven gestuurd, gemailed, etc.
> Ooit was dat domein bij xs4all geregistreerd en later naar mij verhuisd.

Dat is dan niet zo'n succes.

> Kroonkameleon is van kroon leverworst in samenwerking met de kameleon
> boekenreeks

Ach zo. De 'whois' vertelt een heel ander verhaal:
Registrant: Bokma Reklame-Adviesburo B.V.

-p

Piet Beertema wrote:
> Onno wrote:
>> Maar een goed voorbeeld xs4all ellende:
>> www.kroonkameleon.nl
>> Als ik die intype in mijn browser via xs4all doet deze domeinnaam
>> het niet.
>
> Daarbuiten ook niet:

Nou via tiscali kom ik meteen op de www.kroonkameleon.nl/totziens.html
pagina terecht hoor. Tot de volgende keer staat daar. Nou dat dacht ik dus
niet ;-)