Onderwerp: smtp.xs4all.nl

> Demon mag binnenkort toch ook bij het lijstje bofkonten aanschuiven, als
> ik BM goed begrepen heb? ;-)

Ik kan contractueel nu vlot opzeggen bij demon en heb dan 3 providers op het
oog, maar die zijn allen duurder dan demon. Daarnaast schijnt demon nog niet
erg mee te werken aan ISP-ISP-migratie op een vlotte manier.
Ik heb er dus in ruil voor een lagere prijs voor gekozen om vooralsnog de
punten waarover ik bij demon niet tevreden ben voor lief te nemen.

Ik vraag me wel af wat Riemer met zijn opmerking "Bofkonten" bedoelt. Als
dat moet inhouden dat die andere providers maar boffen dat ze mij niet als
klant hebben omdat ik zoveel zeik is dat, ondanks dat die opmerking op
persoonlijke titel is gemaakt, ook niet erg verantwoord omdat bekend is dat
hij voor Demon werkt. In dat geval blijf ik denk ik 'voor straf' nog maar
even bij Demon hangen zodat 'ie nog even van m'n aanwezigheid kan genieten.

Voorlopig ga ik er maar even vanuit dat Riemer dit niet bedoelde.

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

> A more right-wing xs4all might decapitate someone
> responsible for missing mails (which might prevent such issues)

So a serverroom full of decapitated Cor Bosmans will prevent mail getting
lost? Your mad. A stark raving lunatic.

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

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

>> Er zijn geen absolute zekerheden met email. Erger: er zijn geen absolute
>> zekerheden. Zelfs aangetekende post van TPG verdwijnt.
> Ik ben dat absoluut met je oneens. Een goede mailserver geeft pas een OK
> voor ontvangst als ie het opgeslagen heeft op non-volatile storage (harddisk
> bv) en die kan je met i-SCSI of weet ik weel zo redundant maken als je wil.

En dan nog steeds geldt: er zijn geen absolute zekerheden.

> Tenzij er meerdere servers zijn gestolen tijdens een inbraak of een heel
> gebouw door een aarbeving is ingestort is het heel goed mogelijk om 100 %
> zekere mailomgeving op te zetten, indien je intresse hebt hoor ik het wel,
> lol.

Jij weet dus niet wat 100% betekent, "lol".

--
Jurjen Oskam

"Avoid putting a paging file on a fault-tolerant drive, such as a mirrored
volume or a RAID-5 volume. Paging files do not need fault-tolerance."-MS Q308417

On 2004-08-18, Jurjen Oskam <joskam@quadpro.stupendous.org> wrote:
> Jij weet dus niet wat 100% betekent, "lol".

Met z'n allen even wat producten bij hem afnemen met 100% uptime SLA?

--
Riemer Palstra
riemer@palstra.com

Onno wrote:
> Ipv te flamen raad ik je aan www.google.com te gebruiken en
> eerst wat artikelen hierover door te nemen.


Denk dat je Ruben een beetje onderschat


--
Alain

spamsux.nl

> So a serverroom full of decapitated Cor Bosmans will prevent mail getting
> lost? Your mad. A stark raving lunatic.

No just one for prevention ;-)

I do agree with the latter statements though...but it's become a lot less
since I stopped using acid.

> Natuurlijk heb ik ook de helpdesk gemailed maar zoveel geduld heb ik niet,
> als ik een antwoord krijg zal ik het hier even updaten. Ik gok dat het een
> buffer probleem is, maar als ik de enige ben die het heeft ga ik het toch
in
> de virussen zoeken (want providers sturen meestal geen mail terug als ze
je
> virusmail killen en dat is nu een keer minder handig).

Ik heb inmiddels van Cor een stukje logfile gezien waaruit je kan zien dat
xs4all smtp de juiste MX server had gevonden qua IP en ook (aldus de log)
een verbinding had en de mail dropte. Nu weet ik dus niet of daar een
transparante firewall tussen zit die de virussen nog scanned ofzo en er toch
nog iets tussen zat.

In mijn logfiles (ook van virusscanner) niet gevonden, ik heb daar amavisd
en clamd voor draaien met postfix en kan daar geen fout ontdekken. Ook heb
ik niets gereload, gekilled, of whatever alleen gekeken, gewone mail kwam
wel aan en later werkte attachments ook (weer).

Omdat vooral niemand anders hier meld dat er een punt van herkenning is
behalve de ellende overal met al die scanners en zooi die het hele mail
protocol verkloten vanwege spammers en viruskiddies en dat is het
belangrijkste om hier te concluderen, door al die zooi neemt het aantal
schakels voor het bezorgen van mail toe en de kans op storingen dus ook.

Vooral bijna nooit voorkomende storingen zijn moeilijk, dus ik wil Cor
bedanken voor de (inhoudelijke) feedback en ook voor de tip om eens
mimedefang te kijken. Cor vond mijn post niet zo leuk en ook te snel
conclusies trekken. Hoewel ik onderin de OP het zeker niet uitsluit dat er
iets buiten xs4all mis is, is schijnbaar voor Cor de strekking al negatief
en dat was niet de bedoeling, ik wilde pas negatief zijn als bleek dat veel
mensen die avond mails kwijt waren die via xs4all waren gelopen....

Maargoed, Cor, zoals ik ook tegen Badmuts zei vind ik xs4all qua prijzen
e.d. de minst slechte access provider op dit moment, maar er zijn dingen die
beter kunnen. Als ik dan mensjes hoor die naar planet willen overstappen
voor die 5 euro minder per maand denk ik, vind je het gek dat ze allemaal
onbereikbaar zijn e.d. en ik hoop dat jullie ipv groot ooit goed gaan
denken...en breken met dat K-U-T product nederland...voordat het te laat is.

Mocht ik het idee geschetst te hebben dat ik zeker wist/weet dat er xs4all
iets te verwijten valt qua probleem in de OP, dan bevestig ik hierbij
nogmaals dat dat niet het geval was/is en niet mijn intentie was/is, ik
vermoede het alleen en dat mag na eerdere issues waar ik verder niet op in
wil gaan (na de server verhuizingen) waar ze zelfs nog een std. brief over
verstuurden...

>> Natuurlijk heb ik ook de helpdesk gemailed maar zoveel geduld heb ik niet,
>> als ik een antwoord krijg zal ik het hier even updaten. Ik gok dat het een
>> buffer probleem is, maar als ik de enige ben die het heeft ga ik het toch
>in
>> de virussen zoeken (want providers sturen meestal geen mail terug als ze
>je
>> virusmail killen en dat is nu een keer minder handig).

>Ik heb inmiddels van Cor een stukje logfile gezien waaruit je kan zien dat
>xs4all smtp de juiste MX server had gevonden qua IP en ook (aldus de log)
>een verbinding had en de mail dropte. Nu weet ik dus niet of daar een
>transparante firewall tussen zit die de virussen nog scanned ofzo en er toch
>nog iets tussen zat.

Ik neem aan dat je niet bedoelt dat wij die transparante firewall zouden
runnen?

>Mocht ik het idee geschetst te hebben dat ik zeker wist/weet dat er xs4all
>iets te verwijten valt qua probleem in de OP, dan bevestig ik hierbij
>nogmaals dat dat niet het geval was/is en niet mijn intentie was/is, ik
>vermoede het alleen en dat mag na eerdere issues waar ik verder niet op in
>wil gaan (na de server verhuizingen) waar ze zelfs nog een std. brief over
>verstuurden...

Ik ben blij dat we jouw problemen hebben kunnen vinden en ik hoop dat je nog
kan opsporen waarom jouw mailserver de emails besloot weg te gooien.

Mocht je nou weer eens problemen hebben, mail me gerust.

groeten,

cor

In article <41239f1b$0$37789$e4fe514c@news.xs4all.nl>,
Onno <oag@_xs4all.nl> wrote:
>Omdat vooral niemand anders hier meld dat er een punt van herkenning is
>behalve de ellende overal met al die scanners en zooi die het hele mail
>protocol verkloten vanwege spammers en viruskiddies en dat is het
>belangrijkste om hier te concluderen, door al die zooi neemt het aantal
>schakels voor het bezorgen van mail toe en de kans op storingen dus ook.

Hmm, ik heb mijn xs4all adres net even als test een paar virussen gestuurd
en die zijn niet aangekomen. Een test mailtje kwam er zo doorheen.

Volgens het service centre heb ik geen virus scanners actief. Merkwaardig.


--
The Electronic Monk was a labor-saving device, like a dishwasher or a video
recorder. [...] Video recorders watched tedious television for you, thus saving
you the bother of looking at it yourself; Electronic Monks believed things for
you, [...] -- Douglas Adams in Dirk Gently's Holistic Detective Agency

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

>> Er zijn geen absolute zekerheden met email. Erger: er zijn geen absolute
>> zekerheden. Zelfs aangetekende post van TPG verdwijnt.

> Ik ben dat absoluut met je oneens. Een goede mailserver geeft pas een OK
> voor ontvangst als ie het opgeslagen heeft op non-volatile storage (harddisk
> bv) en die kan je met i-SCSI of weet ik weel zo redundant maken als je wil.

En dan is het 100% zeker? Of 99.999%? Wat inhoudt dat grof 1 op de 100.000
mailtjes weg zou kunnen raken. 100% is een heleboel. 99.999% is al een hele
boel. Kijk maar eens naar de prijsverschillen tussen 99.9% en 99.999%. Niet
gek opkijken als het zomaar 20 tot 100 maal scheelt, in de prijs,
afhankelijk van hoe hard je de garantie op vijf maal negen wilt hebben.

> is het heel goed mogelijk om 100 % zekere mailomgeving op te zetten,
> indien je intresse hebt hoor ik het wel, lol.

Doe maar. Zet maar op. Loop maar binnen. In plaats van hier de bende te
flamen. Maar vraag je vooraf af waarom je de eerste zou zijn die dat durft
te beloven.


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

Ruben van der Leij <ruben-news@nutz.nl> writes:

>>> Er zijn geen absolute zekerheden met email. Erger: er zijn geen absolute
>>> zekerheden. Zelfs aangetekende post van TPG verdwijnt.

>> Ik ben dat absoluut met je oneens. Een goede mailserver geeft pas een OK
>> voor ontvangst als ie het opgeslagen heeft op non-volatile storage (harddisk
>> bv) en die kan je met i-SCSI of weet ik weel zo redundant maken als je wil.

>En dan is het 100% zeker? Of 99.999%? Wat inhoudt dat grof 1 op de 100.000
>mailtjes weg zou kunnen raken. 100% is een heleboel. 99.999% is al een hele
>boel. Kijk maar eens naar de prijsverschillen tussen 99.9% en 99.999%. Niet
>gek opkijken als het zomaar 20 tot 100 maal scheelt, in de prijs,
>afhankelijk van hoe hard je de garantie op vijf maal negen wilt hebben.

Het is sowieso niet 100%, gezien het verhaal van Onno dat zijn server de mail
aannam met OK en daarna de mail toch verdween. Had je al uitgevonden waar die
mail gebleven is Onno? Ik gok dat amavisd ze heeft opgeslokt..

Cor

On Wed, 18 Aug 2004 15:09:12 +0200, Badmuts
<AntwoordInDeNieuwsgroep@ReplyInNewsgroup.invali d> wrote:

> Ik vraag me wel af wat Riemer met zijn opmerking "Bofkonten" bedoelt.
> Als dat moet inhouden dat die andere providers maar boffen dat ze mij
> niet als klant hebben omdat ik zoveel zeik is dat, ondanks dat die
> opmerking op persoonlijke titel is gemaakt, ook niet erg verantwoord
> omdat bekend is dat hij voor Demon werkt. In dat geval blijf ik denk
> ik 'voor straf' nog maar even bij Demon hangen zodat 'ie nog even van
> m'n aanwezigheid kan genieten.
>
> Voorlopig ga ik er maar even vanuit dat Riemer dit niet bedoelde.

Nou, daar boffen ze weer mee bij Demon ! Hadden ze bijna langer met je
opgescheept gezeten !

Maarten
--
Chew on this: http://download.tepaske.net/chew_on_this.mpg
Vote Nader: http://www.votenader.org/

> Tjee en je dacht er niet aan om ook een mail zonder attachment in deze
> 'test' mee te sturen ter controle ????

Jawel, dat heb ik gedaan en die kwam direct aan, dat had ik ook al gepost.

> Met z'n allen even wat producten bij hem afnemen met 100% uptime SLA?

Wij doen nooit SLA's, ik leg dan de klant uit dat dat onzin is en dat in de
praktijk bijna nooit de contractuele schadevergoeding wordt betaald vanwege
de relatie e.d. Maar ik blijf erbij en echte programmeurs die ook assembler
en hardware I/O e.d. kunnen tot en met java weten dat het kan. Het smtp
protocol is zo gemaakt dat je 100 % zekerheid kunt garanderen als je wil.

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.

Ik ga er verder geen welles nietes van maken, maar durf er wel 10.000 euro
op te verwedden dat ik een mailomgeving kan opzetten die mail of niet
accepteerd of zo opslaat dat het niet verdwijnt en dus bezorgd kan worden of
gebounced wordt als dat niet lukt. Doe me maar een netapp storage (heb ik
veel ervaring mee) en 2 1u servers. Uiteraard kan een server crashen, maar
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.

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.

> En dan is het 100% zeker? Of 99.999%? Wat inhoudt dat grof 1 op de 100.000
> mailtjes weg zou kunnen raken. 100% is een heleboel. 99.999% is al een
hele
> boel. Kijk maar eens naar de prijsverschillen tussen 99.9% en 99.999%.
Niet
> gek opkijken als het zomaar 20 tot 100 maal scheelt, in de prijs,
> afhankelijk van hoe hard je de garantie op vijf maal negen wilt hebben.

100 % zeker dat ik ze opgeslagen heb voordat ik OK zeg.

Dus nogmaals, je leest het goed, 100 % zeker dat het opgeslagen is op
meerdere fysieke storage voordat ik OK ga roepen en ik (beheerder) dus geen
mail verlies als ik het aanneem. 100 % zeker.....dus niet 99.9999%

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 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 je geen verify kan
doen om wat voor reden dan ook of al eerder eruit klapt krijgt de verzender
geen OK, die krijgt dan een error of wacht tot ie het zat is.

Nu niet roepen, kan niet, blabla. Geef mij een voorbeeld scenario als je
bovenstaande implementeerd (is niet zo heel complex dus na goed debuggen kan
dat stuk niet meer misgaan). Dan moet je wel met virussen komen die de
firmware van mijn raid controller(s) heeft aangepast zodat deze net doet
alsof het bestanden opslaat en dan ook nog bij verify de data onthouden
heeft, lol (en die kan je niet maken tenzij je me er eentje laat zien, lol).

Tenzij een extreme hacker heel veel tijd erin stopt, de sources heeft van de
gebruikte software en firmwares e.d., de server hacked en dan onderdelen van
die omgeving kapot maakt werkt dit. En die hacker die dat heeft bestaat
niet, je kan er genoeg obstakels voor leggen (een firewall die alleen
toegestane smtp protocol onderdelen doorlaat met gecontroleerde buffersizes
zodat onverwachte commando's er niet door komen en dus ook geen virussen,
dan kan je die nog hacken, jajajaja).