CMOS batterij en verzenddatum email

[Astie]

Ik ben ICTer bij de overheid en kreeg een vraag waar ons ICTteam geen goed antwoord op kon geven. We waren erg verdeeld en hopen via Tweakers een goed sntwoord te krijgen.

Als iemand van huis uit via pop3 een email stuurt op maandagochtend 9:00 uur maar de verzenddatum van de email is de zaterdagavond ervoor om 19:30 hoe komt dit dan? Wij beweren dat de email vertraagt is verzonden. De verzenden beweert dat zijn CMOS batterij bijna leeg is en daarom zijn computerklok achter loopt. Is de stelling van de verzender de juiste?

Wij hebben al getest dat als je een email vertraagt verzend dat de verzenddatum van de email toch de datum en tijd is dat je op de verzend knop drukt. De headers geven aan dat de email voor het eerst bij een server komt op de vertraagde tijd. Dit is echter alleen bij pop3 email. Bij elke andere vorm imap, exchange en webmail geven de tijd van de server aan.
Als je CMOS batterij bijna leeg is heeft dit toch niet het effect van een analoge klok die achtef gaat lopen? Hij werkt of hij werkt niet. Hij reset de datum en tijd op je moederbord naar de fabrieksinstellingen op het moment dat je batterij leeg is.

Kan iemand hier een helder licht over laten schijnen?

[NiGeLaToR]

Interessante kwestie, had er een beetje een sceptisch gevoel bij maar vond toch een site waar men aangeeft dat achterlopende tijd veroorzaakt kan worden door een bijna lege batterij:
http://www.statelandrecords.com/19992308.html
En nog meer:
http://www.tomshardware.c...0/windows-clock-sync.html

Blijkbaar kan dat toch, ondanks dat ik ook zou verwachten dat ie op een gegeven moment gewoon leeg is.

Als dit een gevalletje 'wordt er nu gejokt of niet?' Is dan kun je ook nog type computer opvragen. Cmos batterij is zelden leeg binnen 3 jaar na productie en vaak pas na 5 jaar.

Tenslotte zie je aan de header inderdaad het tijd van aanbieden bij de mailserver, dus die tijd zou je als verzendtijd kunnen aanhouden.
Pop3 insinueert dat dit prive email was?

Edit: 1 ding verbaast me wel, windows checkt zelf de tijd ook via de time service, dus dat moet dan ook net misgelopen zijn

[ Voor 13% gewijzigd door NiGeLaToR op 03-08-2016 08:00 ]

[jeroen3]

Een RTC loopt niet langzamer bij een lagere spanning.
Ze werken vaak tot onder de 2 Volt, en dan is die batterij al lang helemaal op. Kom je zo laag dat de RTC ermee stopt, dan zit ineens in Januari 1970.
Sterker nog, de RTC makers specificeren niet eens een accuracy drift per voltage. Alleen per temperatuur. En dan maximaal 10ppm. En dan duurt het wel even voordat je 14 36 uur achter loopt.
Zelfs met 100 ppm is het slechts een uur per jaar.

http://data.energizer.com/PDFs/cr2032.pdf

http://time.is/

Klant zijn RTC werkt helemaal niet, of het kristal is defect?

[Verwijderd]

jeroen3 schreef op woensdag 03 augustus 2016 @ 08:46:

Klant zijn RTC werkt helemaal niet, of het kristal is defect?

Of heeft de klok handmatig terug gezet omdat hij daar belang bij heeft.

[jeroen3]

Wat is eigenlijk de maximale time skew voor certificaatvalidatie / ssl?
14 uur is toch hopelijk wel teveel?

[Astie]

Om de stelling van wat meer informatie te voorzien:
de betreffende zaterdag is er ook om 15:00 uur een email verzonden die om 15:01 dezelfde dag aangekomen is. Is zijn klok in 4,5 uur tijd zo ver achter gaan lopen?

Verwijderd schreef op woensdag 03 augustus 2016 @ 08:56:
[...]

Of heeft de klok handmatig terug gezet omdat hij daar belang bij heeft.

Juist het vooruit zetten van de klok, daar zou deze persoon belang bij hebben, niet het terugzetten. :

NiGeLaToR schreef op woensdag 03 augustus 2016 @ 07:47:
Interessante kwestie, had er een beetje een sceptisch gevoel bij maar vond toch een site waar men aangeeft dat achterlopende tijd veroorzaakt kan worden door een bijna lege batterij:
http://www.statelandrecords.com/19992308.html
En nog meer:
http://www.tomshardware.c...0/windows-clock-sync.html

Blijkbaar kan dat toch, ondanks dat ik ook zou verwachten dat ie op een gegeven moment gewoon leeg is.

Als dit een gevalletje 'wordt er nu gejokt of niet?' Is dan kun je ook nog type computer opvragen. Cmos batterij is zelden leeg binnen 3 jaar na productie en vaak pas na 5 jaar.

Tenslotte zie je aan de header inderdaad het tijd van aanbieden bij de mailserver, dus die tijd zou je als verzendtijd kunnen aanhouden.
Pop3 insinueert dat dit prive email was?

Edit: 1 ding verbaast me wel, windows checkt zelf de tijd ook via de time service, dus dat moet dan ook net misgelopen zijn

de time service kan je handmatig uitzetten.

[Astie]

jeroen3 schreef op woensdag 03 augustus 2016 @ 09:05:
Wat is eigenlijk de maximale time skew voor certificaatvalidatie / ssl?
14 uur is toch hopelijk wel teveel?

Ik heb zelf de klok van mijn pc 2 dagen achteruit gezet en ik kreeg de email terug van de server met de mededeling dat de tijd te ver in het verleden lag.

[NiGeLaToR]

Astie schreef op woensdag 03 augustus 2016 @ 09:07:
[...]


Ik heb zelf de klok van mijn pc 2 dagen achteruit gezet en ik kreeg de email terug van de server met de mededeling dat de tijd te ver in het verleden lag.

Gebruikte je pop3?


Vwbt RTC afwijking: lees zelf de diverse draadjes hierover die ik postte en die je zelf kunt vinden. Er zijn veel mensen die klagen over een achter lopende klok en dit oplossen met een nieuwe cmos batterij. Lijkt me niet helemaal uitgesloten dus.

En time service uitzetten kan, maar als de andere partij onschuldig is was dit niet gebeurd en was de tijd vanzelf bijgewerkt.

[Astie]

NiGeLaToR schreef op woensdag 03 augustus 2016 @ 09:57:
[...]


Gebruikte je pop3?


Vwbt RTC afwijking: lees zelf de diverse draadjes hierover die ik postte en die je zelf kunt vinden. Er zijn veel mensen die klagen over een achter lopende klok en dit oplossen met een nieuwe cmos batterij. Lijkt me niet helemaal uitgesloten dus.

En time service uitzetten kan, maar als de andere partij onschuldig is was dit niet gebeurd en was de tijd vanzelf bijgewerkt.

Ja ik gebruikte pop3.

De vraag is alleen hoe lang doet het RTC erover om +/- 36 uur achter te lopen. Is in de tussentijd de batterij dan niet helemaal leeg?

[Tens]

Door een slechte batterij gaat de klok achterlopen, bij elke herstart van de pc wordt in principe gesynchroniseerd met de internettijd. Als je de computer aan laat staan gebeurt dit standaard één keer per week. Dit kan je uitzetten natuurlijk.

in de mail-header staat toch ook de tijd dat de mailserver de mail ontvangen heeft?

[Astie]

Tens schreef op woensdag 03 augustus 2016 @ 10:18:
Door een slechte batterij gaat de klok achterlopen, bij elke herstart van de pc wordt in principe gesynchroniseerd met de internettijd. Als je de computer aan laat staan gebeurt dit standaard één keer per week. Dit kan je uitzetten natuurlijk.

in de mail-header staat toch ook de tijd dat de mailserver de mail ontvangen heeft?

Ja, dat staat in de headers. Dit hebben wij ook nagekeken. In de headers staat 09:00 maandagochtend. En niet zaterdag.
Daarom gaan wij nog steeds er van uit dat de email vertraagt is verstuurd. Hierin heeft de persoon geen rekening gehouden met het feit dat de verzenddatum (ook al verstuur je vertraagt) altijd de tijd en datum is van het moment dat je de verzend knop in drukt en niet de tijd waarop je hem vertraagt laat versturen.

Echter het verhaal van de persoon is dus dat de datum van verzending komt door een bijna lege CMOS batterij.

de persoon heeft op de zaterdagmiddag ook een email gestuurd naar ons die binnen een minuut aankwam waar de verzenddatum wel goed van was.

[ Voor 7% gewijzigd door Astie op 03-08-2016 10:26 ]

[Tens]

Cmos batterij scenario lijkt me zeer onwaarschijnlijk (aanvulling: het is natuurlijk onmogelijk voor een klok om binnen een paar uur een dag achter te lopen), ik denk niet dat je mailtjes verstuurd krijgt met zo'n afwijkende tijd.
Een ander scenario zou kunnen(dit gaat gepaard met diverse meldingen die je moet negeren):

ik druk op zaterdag op verzend, en sluit de pc meteen af, mailprogramma heeft niet de kans gekregen om het mailtje te versturen.
Ik zet maandag dag de pc aan; zo gauw mailprogramma actief is wordt het mailtje verstuurd.

Ik ga er vanuit dat de time stamp dan maandag is.

[ Voor 9% gewijzigd door Tens op 03-08-2016 10:44 ]

[NiGeLaToR]

Outbox-scenario is plausibel, al is dan de verzendtijd de tijd die de e-mail de client verliet en niet de tijd dat ie in de outbox geplaatst werd.

CMOS verhaal met zoveel achterstand vind ik ook niet heel plausibel, al valt ie zonder de situatie te reproduceren niet 100% uit te sluiten.

Helemaal in combinatie met de aanvulling dat een andere op zaterdag verzonden mail wel direct en met de juiste timestamp aankwam.

Verder even de tijdlijn schetsende:

• Mr X stuurt zaterdag een e-mail, komt direct aan.
• Mr X claimt zaterdag maandag nog een e-mail verzonden te hebben, maar die heeft als verzenddatum zaterdag. Als oorzaak wordt gegeven, verlate verzending door achterlopende klok.
• Astie constateert echter dat de mail maandag is aangeboden bij de e-mailserver.

Als de klok van Mr X achter liep dan had het er heel anders uit gezien. Stel op zaterdag stuurt hij een e-mail vanaf een klok die achter loopt en je mailclient neemt de verzenddatum voor binnenkomst. Dan krijg je hem alsnog direct maar mogelijk onder oudere e-mails. Sorteer je je e-mail echter op moment van binnenkomst dan staat ie alsnog, direct bovenaan. In de header staat dan bijvoorbeeld (fictieve, achterlopende tijd) verzenddatum donderdag en aankomst datum zaterdag.

Ik snap even niet wat Mr X wil bewijzen - dat hij zaterdag die e-mail verzonden heeft, maar dat ie maandag (ik gok na een verstreken deadline?) pas aankomt? E-mails blijven ook niet zonder NDR achtige melding van vertraging in een queue hangen, zelfs als je op een grey-list komt duurt het niet zo lang.

Wat ik op school wel eens heb gedaan is de tijd op mijn pc terug gezet naar het moment dat de deadline nog niet verstreken was en dan verzenden, zodat in de inbox van de docent deze inderdaad nog 'op tijd' binnen kwam. Gelukkig keken die docenten toen niet in de e-mailheaders en/of sorteerden ze e-mail niet op ontvangst in de mailserver, maar verzenddatum.

Hypothese is dus: Mr X stuurt maandag een e-mail, maar wil doen lijken dat hij hem zaterdag heeft verzonden. Ontvangende mailserver boeit het niet dat er een verzendtijdstip in het verleden ligt en neemt de e-mail netjes aan en plakt er 'ontvangen op maandag' op. Linksom of rechtsom kan een achterlopende klok, als hij gewoon op zaterdag die e-mail had gestuurd, geen probleem geweest.

Ik vul nu wel iets meer aan dan ik weet, want ik begrijp nog niet helemaal wat Mr X nu wilt bewijzen met het CMOS verhaal.

Edit: verhaal bijgewerkt nav feedback TS.

[Astie]

NiGeLaToR schreef op woensdag 03 augustus 2016 @ 10:56:
Outbox-scenario is plausibel, al is dan de verzendtijd de tijd die de e-mail de client verliet en niet de tijd dat ie in de outbox geplaatst werd.

CMOS verhaal met zoveel achterstand vind ik ook niet heel plausibel, al valt ie zonder de situatie te reproduceren niet 100% uit te sluiten.

Helemaal in combinatie met de aanvulling dat een andere op zaterdag verzonden mail wel direct en met de juiste timestamp aankwam.

Verder even de tijdlijn schetsende:

• Mr X stuurt zaterdag een e-mail, komt direct aan.
• Mr X claimt zaterdag nog een e-mail verzonden te hebben, maar die komt pas maandag aan. Als oorzaak wordt gegeven, verlate verzending door achterlopende klok.
• Astie constateert echter dat de mail pas maandag is aangeboden bij de e-mailserver.

Als de klok van Mr X achter liep dan had het er heel anders uit gezien. Stel op zaterdag stuurt hij een e-mail vanaf een klok die achter loopt en je mailclient neemt de verzenddatum voor binnenkomst. Dan krijg je hem alsnog direct maar mogelijk onder oudere e-mails. Sorteer je je e-mail echter op moment van binnenkomst dan staat ie alsnog, direct bovenaan. In de header staat dan bijvoorbeeld (fictieve, achterlopende tijd) verzenddatum donderdag en aankomst datum zaterdag.

Ik snap even niet wat Mr X wil bewijzen - dat hij zaterdag die e-mail verzonden heeft, maar dat ie maandag (ik gok na een verstreken deadline?) pas aankomt? E-mails blijven ook niet zonder NDR achtige melding van vertraging in een queue hangen, zelfs als je op een grey-list komt duurt het niet zo lang.

Wat ik op school wel eens heb gedaan is de tijd op mijn pc terug gezet naar het moment dat de deadline nog niet verstreken was en dan verzenden, zodat in de inbox van de docent deze inderdaad nog 'op tijd' binnen kwam. Gelukkig keken die docenten toen niet in de e-mailheaders en/of sorteerden ze e-mail niet op ontvangst in de mailserver, maar verzenddatum.

Hypothese is dus: Mr X stuurt maandag een e-mail, maar wil doen lijken dat hij hem zaterdag heeft verzonden. Ontvangende mailserver boeit het niet dat er een verzendtijdstip in het verleden ligt en neemt de e-mail netjes aan en plakt er 'ontvangen op maandag' op. Linksom of rechtsom kan een achterlopende klok, als hij gewoon op zaterdag die e-mail had gestuurd, geen probleem geweest.

Ik vul nu wel iets meer aan dan ik weet, want ik begrijp nog niet helemaal wat Mr X nu wilt bewijzen met het CMOS verhaal.

Goede samenvatting maar er zit één fout in.

Mr. X wil niet bewijzen dat hij op zaterdag een email heeft verzonden maar wil bewijzen dat hij op maandag de email heeft verzonden. En dat de verzenddatum op zaterdag ligt vanwege zijn CMOS batterij.

[Afvalzak]

Even puur hypothetisch, Mr. X sluit op zaterdag zijn PC af, start hem maandagochtend opnieuw op,
tijd staat nog op die van zaterdag door de kapotte batterij, vervolgens wordt dat door de mailserver etc overgenomen.
Dan zou zijn verhaal dus kloppen?

Wat heeft hij eraan om te bewijzen dat hij de mail maandag ipv zaterdag, dus juist later, gemaild heeft? (andersom kan ik me nog voorstellen)

[NiGeLaToR]

Astie schreef op woensdag 03 augustus 2016 @ 11:01:
[...]


Goede samenvatting maar er zit één fout in.

Mr. X wil niet bewijzen dat hij op zaterdag een email heeft verzonden maar wil bewijzen dat hij op maandag de email heeft verzonden. En dat de verzenddatum op zaterdag ligt vanwege zijn CMOS batterij.

Volgens mij kan die onmogelijk kloppen dan

Poging 2 (aangepast nav aanvulling hieronder):

• MrX stuurt zaterdag 15:00 e-mail die komt om 15:01 aan
• MrX stuurt een e-mail die maandag om 09:00 aankomt en claimt dat ie het dan ook verzonden heeft, maar de verzenddatum is zaterdag 19:30 (4,5 uur later dan 15:00).
• MrX beweert dat doordat zijn klok achter loopt het lijkt alsof die zaterdag is gestuurd, terwijl die maandag is gestuurd.

Klok verhaal kan de prullenbak in lijkt mij, want het klopt gewoon niet met de tijdlijn. Enige wat al genoemd is wat wellicht kan zijn gebeurd is dat zaterdag om 19:30 in de outbox gezet en pas maandag om 09:00 verzonden, al zal het me verbazen als dat de verzend-tijd op zaterdag zet. Heb in het verleden vaak e-mails klaargezet met een verzendtijdstip in m'n outbox en die krijgt dan gewoon het geplande verzendtijdstipje mee.

Afvalzak schreef op woensdag 03 augustus 2016 @ 11:09:
Even puur hypothetisch, Mr. X sluit op zaterdag zijn PC af, start hem maandagochtend opnieuw op,
tijd staat nog op die van zaterdag door de kapotte batterij, vervolgens wordt dat door de mailserver etc overgenomen.
Dan zou zijn verhaal dus kloppen?

Wat heeft hij eraan om te bewijzen dat hij de mail maandag ipv zaterdag, dus juist later, gemaild heeft? (andersom kan ik me nog voorstellen)

Vind het een goede hypothese, alleen heb ik er een paar vragen bij:
- CMOS batterij leeg = factory reset van de tijd
- CMOS batterij bijna leeg = mogelijk traag lopende klok.
Scenario wat je schetst van een stilstaande tijd heb ik nog niet kunnen vinden.

Daarbij blijft bij een ATX mobo de boel op netstroom als je de pc uit zet maar de stekker in het stopcontact doet. Dan moet je al net als ik doe de stekker uit het stopcontact halen. Bij een laptop voorkomt een volle accu ook een CMOS-batterij probleem.

[ Voor 31% gewijzigd door NiGeLaToR op 03-08-2016 11:15 ]

[Astie]

NiGeLaToR schreef op woensdag 03 augustus 2016 @ 11:09:
[...]


Volgens mij kan die onmogelijk kloppen dan

Poging 2:

• MrX stuurt zaterdag 15:00 e-mail die komt om 15:01 aan
• MrX stuurt een e-mail die maandag om 09:00 aankomt, maar claimt(?) dat deze zaterdag 19:30 (4,5 uur later dan 15:00) is verzonden.
• MrX beweert dat doordat zijn klok achter loopt het lijkt alsof die zaterdag is gestuurd, terwijl die maandag is gestuurd.

Klok verhaal kan de prullenbak in lijkt mij, want het klopt gewoon niet met de tijdlijn. Enige wat al genoemd is wat wellicht kan zijn gebeurd is dat zaterdag om 19:30 in de outbox gezet en pas maandag om 09:00 verzonden, al zal het me verbazen als dat de verzend-tijd op zaterdag zet. Heb in het verleden vaak e-mails klaargezet met een verzendtijdstip in m'n outbox en die krijgt dan gewoon het geplande verzendtijdstipje mee.

Mr. X claimt juist dat de email op maandagochtend om 9 uur is verzonden maar dat de verzenddatum op zaterdag staat door zijn falende CMOS batterij. De aankomst in de mailbox en bij de verzendservers is maandagochtend 9 uur.

Lastig verhaal en ik mag verder geen achtergronden geven over het waarom.

[muppet99]

Ik zou zeggen, raad deze meneer aan om een andere baan te gaan zoeken:

Als je je als persoon hier druk over moet maken, heeft deze verder geen uitdagingen in zijn baan. Moet je eens kijken wat deze ongein al gekost heeft. Wanneer het afleveren van email een dusdanig hoge druk heeft, zou de betreffende persoon zelf wel checken of de mail aangekomen was.

Om nog even een scenario te noemen.

Persoon X opent zaterdag zijn outlook. Verzend mail. Sluit vervolgens zijn outlook. Bedenkt na een half uurtje dat hij nog ene word document moet versturen. Persoon rechterklikt op het word document en doet sent to. Dus een outlook venster opent. Meneer vult alles in en drukt op send. Echter zolang meneer outlook zelf niet opstart wordt de mail niet verstuurd. Dus maandag ochtend wil meneer zijn email lezen en start daarvoor outlook op en vervolgens wordt dus ook pas de mail verstuurd.

Ergo, meneer had zelf even moeten checken in de outlook client of alles goed was gegaan.

[NiGeLaToR]

Astie schreef op woensdag 03 augustus 2016 @ 11:12:
[...]


Mr. X claimt juist dat de email op maandagochtend om 9 uur is verzonden maar dat de verzenddatum op zaterdag staat door zijn falende CMOS batterij. De aankomst in de mailbox en bij de verzendservers is maandagochtend 9 uur.

Lastig verhaal en ik mag verder geen achtergronden geven over het waarom.

Snap ik en hoeft denk ik ook niet - blijft een beetje speculeren wat er gebeurt is dan. Oorzaak falende CMOS batterij blijft twijfelachtig gezien de tijdlijn, maar wellicht niet helemaal onmogelijk.

De afwijking is ook te groot voor een tijdzone-issue, die kom ik ook nog wel eens tegen voor e-mails die in ene in het verleden verzonden lijken te zijn/worden.

muppet99 schreef op woensdag 03 augustus 2016 @ 11:19:


Ergo, meneer had zelf even moeten checken in de outlook client of alles goed was gegaan.

Meneer claimt pas maandag de e-mail te hebben gestuurd en moet nu uitleggen waarom de e-mail zelf is ontvangen op maandag maar als verzenddatum zaterdag er voor heeft. Dat wordt met jouw scenario niet verklaard toch?

[ Voor 21% gewijzigd door NiGeLaToR op 03-08-2016 11:21 ]

[Astie]

muppet99 schreef op woensdag 03 augustus 2016 @ 11:19:
Ik zou zeggen, raad deze meneer aan om een andere baan te gaan zoeken:

Als je je als persoon hier druk over moet maken, heeft deze verder geen uitdagingen in zijn baan. Moet je eens kijken wat deze ongein al gekost heeft. Wanneer het afleveren van email een dusdanig hoge druk heeft, zou de betreffende persoon zelf wel checken of de mail aangekomen was.

Om nog even een scenario te noemen.

Persoon X opent zaterdag zijn outlook. Verzend mail. Sluit vervolgens zijn outlook. Bedenkt na een half uurtje dat hij nog ene word document moet versturen. Persoon rechterklikt op het word document en doet sent to. Dus een outlook venster opent. Meneer vult alles in en drukt op send. Echter zolang meneer outlook zelf niet opstart wordt de mail niet verstuurd. Dus maandag ochtend wil meneer zijn email lezen en start daarvoor outlook op en vervolgens wordt dus ook pas de mail verstuurd.

Ergo, meneer had zelf even moeten checken in de outlook client of alles goed was gegaan.

Hij claimt dat het aan zijn CMOS batterij ligt en daarwerkelijk op maandagochtend op verzend heeft geklikt.

Over de inhoud van het verhaal kan ik geen uitspraken doen vanwege een lopend onderzoek. Het verschil tussen op zaterdag of maandag verzenden is van vitaal belang in dit onderzoek. Vandaar dat er aan ons is gevraagd om uitsluitsel tegen over het verhaal van Mr X.
Echter konden wij allerlei scenario's verzinnen waarin meneer gelijk heeft maar dit zijn allemaal onwaarschijnlijke scenario's.

Dat de email in de outbox bleef staan is niet aan de orde omdat meneer claimt maandagochtend op verzenden geklikt te hebben

[ Voor 3% gewijzigd door Astie op 03-08-2016 11:24 ]

[muppet99]

Meneer claimt pas maandag de e-mail te hebben gestuurd en moet nu uitleggen waarom de e-mail zelf is ontvangen op maandag maar als verzenddatum zaterdag er voor heeft. Dat wordt met jouw scenario niet verklaard toch?

Zeker wel. Ik heb net nog even een test gedaan. Om 11.23 outlook afgesloten en een txt bestand naar mijzelf gemaild via de send to. Deze staat dus in postvak uit met timestamp 11.23. Vervolgens na 5 minuten mijn mail weer geopend. bestand wordt verstuurd. In verzonden items staat ook verstuur tijd 11:23. Ook als ontvanger zie ik dat hij om 11:23 verstuurd is.

Wat mij wel opviel is dat de mail bleef hangen in mijn postvak uit en pas verstuurd werd nadat ik heb geklikt op Alles verzenden/ontvangen. En toch staat de tijd op 11:23.....

[ Voor 12% gewijzigd door muppet99 op 03-08-2016 11:34 ]

[jeroen3]

Astie schreef op woensdag 03 augustus 2016 @ 06:55:
Ik ben ICTer bij de overheid

Ik neem aan dat mails dan via een versleutelde verbinding gaan. Kun je die versleutelde verbinding maken als je tijd fout staat?

[Astie]

jeroen3 schreef op woensdag 03 augustus 2016 @ 11:33:
[...]

Ik neem aan dat mails dan via een versleutelde verbinding gaan. Kun je die versleutelde verbinding maken als je tijd fout staat?

Nee, dit gaat om prive mail naar werk email. Dus van Pop3 naar Exchange.

[NiGeLaToR]

muppet99 schreef op woensdag 03 augustus 2016 @ 11:32:
[...]


Zeker wel. Ik heb net nog even een test gedaan. Om 11.23 outlook afgesloten en een txt bestand naar mijzelf gemaild via de send to. Deze staat dus in postvak uit met timestamp 11.23. Vervolgens na 5 minuten mijn mail weer geopend. bestand wordt verstuurd. In verzonden items staat ook verstuur tijd 11:23. Ook als ontvanger zie ik dat hij om 11:23 verstuurd is.

Wat mij wel opviel is dat de mail bleef hangen in mijn postvak uit en pas verstuurd werd nadat ik heb geklikt op Alles verzenden/ontvangen. En toch staat de tijd op 11:23.....

Dan staat deze optie bij mij bovenaan als plausibel. Maar das dan alsnog niet wat Mr X claimt natuurlijk.
Top dat je het even gecheckt hebt

[jeroen3]

Het hele verhaal van de RTC die op de batterij loopt gaat helemaal niet op als meneer de stekker nooit uit de pc haalt. Dan draait de klok op 5V stanbdy.

En bij laptops gaat het verhaal ook niet op, want dan moet eerst de master accu dood zijn voordat de RTC alleen op het knoopcelletje draait.

[Astie]

muppet99 schreef op woensdag 03 augustus 2016 @ 11:32:
[...]


Zeker wel. Ik heb net nog even een test gedaan. Om 11.23 outlook afgesloten en een txt bestand naar mijzelf gemaild via de send to. Deze staat dus in postvak uit met timestamp 11.23. Vervolgens na 5 minuten mijn mail weer geopend. bestand wordt verstuurd. In verzonden items staat ook verstuur tijd 11:23. Ook als ontvanger zie ik dat hij om 11:23 verstuurd is.

Wat mij wel opviel is dat de mail bleef hangen in mijn postvak uit en pas verstuurd werd nadat ik heb geklikt op Alles verzenden/ontvangen. En toch staat de tijd op 11:23.....

Dit is bijna hetgene wat wij zelf vermoeden. Wij vermoeden dat mr. X op zaterdagavond de email geschreven heeft en via de optie "Bezorging uitstellen" de email verzonden heeft. Echter had mr X niet in de gaten dat de verzenddatum dan op zaterdag avond staat en niet op de uitgestelde datum. Hierna heeft mr X het verhaal met de CMOS batterij verzonnen om zichzelf in te dekken.

[Astie]

jeroen3 schreef op woensdag 03 augustus 2016 @ 11:42:
Het hele verhaal van de RTC die op de batterij loopt gaat helemaal niet op als meneer de stekker nooit uit de pc haalt. Dan draait de klok op 5V stanbdy.

En bij laptops gaat het verhaal ook niet op, want dan moet eerst de master accu dood zijn voordat de RTC alleen op het knoopcelletje draait.

Zoals ik lees is dit niet het geval. De RTC wordt alleen via de knoopbatterij gevoed. Dus zit de RTC niet aangesloten op de accu of voeding van het systeem.

[NiGeLaToR]

Astie schreef op woensdag 03 augustus 2016 @ 11:42:
[...]


Dit is bijna hetgene wat wij zelf vermoeden. Wij vermoeden dat mr. X op zaterdagavond de email geschreven heeft en via de optie "Bezorging uitstellen" de email verzonden heeft. Echter had mr X niet in de gaten dat de verzenddatum dan op zaterdag avond staat en niet op de uitgestelde datum. Hierna heeft mr X het verhaal met de CMOS batterij verzonnen om zichzelf in te dekken.

I concur. Zeker omdat er opzet in het spel lijkt omdat het maandag ochtend verzonden zou moeten zijn. Foutje, bedankt

jeroen3 schreef op woensdag 03 augustus 2016 @ 11:42:
Het hele verhaal van de RTC die op de batterij loopt gaat helemaal niet op als meneer de stekker nooit uit de pc haalt. Dan draait de klok op 5V stanbdy.

En bij laptops gaat het verhaal ook niet op, want dan moet eerst de master accu dood zijn voordat de RTC alleen op het knoopcelletje draait.

Had ik hierboven ook geschetst inderdaad, verhaal van de CMOS batterij is voor 90% busted. Zowel technisch als in de tijdlijn zo onwaarschijnlijk.

[Felicia]

Ik kan me in 18 jaar helpdesk (en delen daarvan ook TD) niet 1x heugen dat ik een PC terug heb gekregen waar de klok van bleef hangen omdat de batterij bijna leeg was. Deze oorzaak lijkt me echter makkelijk uit te sluiten door de batterij op te vragen en de spanning te meten.

Daarnaast lijkt het me van belang toegang te vragen tot de eventlogs van de betreffende PC. Als de datum gemuteerd is zou je dat in het eventlog terug moeten zien (link, link2).

[noguru]

Felicia schreef op woensdag 03 augustus 2016 @ 12:30:
Ik kan me in 18 jaar helpdesk (en delen daarvan ook TD) niet 1x heugen dat ik een PC terug heb gekregen waar de klok van bleef hangen omdat de batterij bijna leeg was. Deze oorzaak lijkt me echter makkelijk uit te sluiten door de batterij op te vragen en de spanning te meten.

Daarnaast lijkt het me van belang toegang te vragen tot de eventlogs van de betreffende PC. Als de datum gemuteerd is zou je dat in het eventlog terug moeten zien (link, link2).

Ik ook niet. Als de batterij leeg is wordt de klok gereset en gaat dan terug naar een vaste datum ergens ver in verleden. Als je dan boot in Windows zal die de juiste tijd instellen, niet gaan achterlopen. Het hele "mijn klok liep achter" verhaal rammelt.

[evilution]

NiGeLaToR schreef op woensdag 03 augustus 2016 @ 11:45:
[...] voor 90% busted.

Zolang dat niet 100% is blijft het verhaal dus plausibel. Onwaarschijnlijk maar niet onmogelijk

[garriej]

Astie schreef op woensdag 03 augustus 2016 @ 11:42:
[...]


Dit is bijna hetgene wat wij zelf vermoeden. Wij vermoeden dat mr. X op zaterdagavond de email geschreven heeft en via de optie "Bezorging uitstellen" de email verzonden heeft. Echter had mr X niet in de gaten dat de verzenddatum dan op zaterdag avond staat en niet op de uitgestelde datum. Hierna heeft mr X het verhaal met de CMOS batterij verzonnen om zichzelf in te dekken.

Zou goed kunnen natuurlijk. Zeker als hij zaterdag alvast de mail stuurt omdat ie maandag ziek is

[Martin.Air]

Uit ervaring kan ik zeggen dat Windows soms zijn tijd niet aanpast na standby/hibernate. Dan staat de systeemtijd nog op de tijd waarbij het systeem in slaapstand ging.

Mocht er in de tijd (tot Windows daarna synct met de systeemklok ofwel NTP) een mail verstuurd worden zou het natuurlijk kunnen dat de header aangeeft dat het om een ander tijdstip is verzonden.

[Astie]

Martin.Air schreef op woensdag 03 augustus 2016 @ 14:42:
Uit ervaring kan ik zeggen dat Windows soms zijn tijd niet aanpast na standby/hibernate. Dan staat de systeemtijd nog op de tijd waarbij het systeem in slaapstand ging.

Mocht er in de tijd (tot Windows daarna synct met de systeemklok ofwel NTP) een mail verstuurd worden zou het natuurlijk kunnen dat de header aangeeft dat het om een ander tijdstip is verzonden.

Dat is een mogelijkheid maar alle tijden in de header staan op maandagochtend.

[Martin.Air]

Astie schreef op woensdag 03 augustus 2016 @ 15:31:
[...]


Dat is een mogelijkheid maar alle tijden in de header staan op maandagochtend.

O dat had ik even gemist, ik dacht dat juist daar ook nog een tijd wel op zaterdag stond. Dan moet ik zeggen dat ik het eens ben met de conclusie dat bezorging uitstel functie is gebruikt. Dit klikt het meest plausibel, alle overige opties zouden ook in de headers moeten tonen aangezien de sender client dan echt overtuigd is dat het zaterdag is.

Dit is natuurlijk te reproduceren, wat ik gok dat je eigenlijk al mee bezig bent/hebt gedaan, als de vraag vanuit management er is als dit om zoiets als ziekteverzuim gaat (om dat voorbeeld maar even te gebruiken).