Wanneer is een bericht per contactformulier aangekomen?

mail-to-cc-bccEen lezer vroeg me:

Op 20 juni stuurde ik een opzegbericht via het contactformulier bij een betaalwebsite. Pas drie dagen later kreeg ik een reactie, waarbij ze meteen meldden dat ik te laat was. Maar 20 juni was de laatste dag, dus ik was wél op tijd. Ik kan met een screenshot bewijzen dat ik het formulier heb ingevuld en dat de site daarop meldde dat het bericht is ontvangen. Is dat genoeg bewijslast?

De wet zegt dat wie een bericht verstuurt, moet bewijzen dat het aangekomen is bij de beoogde ontvanger. Bewijzen dat het verzonden is, is daarbij niet genoeg. Zelfs niet bij aangetekende post.

Bij e-mail is bewijs van ontvangst best ingewikkeld. Ik ken eigenlijk maar één manier en dat is dat de ontvanger terugmailt dat hij het heeft gehad. Ja, of je moet met portalen gaan werken waar een derde logt of en zo ja hoe laat het bericht is ingezien door de ontvanger.

Bij een contactformulier is de regel hetzelfde. Maar het bewijs is volgens mij iets makkelijker: vrijwel elk formulier zegt na insturen iets van “Dank u, uw bericht is ontvangen en wij reageren binnen X werkdagen”. Daaruit mag je concluderen dat het bericht ook echt binnengenkomen is. Natuurlijk gaat het bericht vervolgens per mail naar de persoon die er wat mee moet, en die mail kan net zo hard kwijtraken als jouw mail naar info@, maar dat doet er dan niet meer toe. Vanaf ontvangst door het bedrijf is alle vervolgdoorzending hun risico.

Lastig is dan weer wel bewijzen wát er is ontvangen. Want (grote ergernis) je kunt zelden tot nooit vragen om een kopietje naar je eigen mailbox, en “Uw bericht zoals ontvangen staat hieronder” zie je ook vrijwel nooit. Je kunt dan eigenlijk alleen screenshotten (of een filmpje maken) wat je invult en wat het bevestigingsscherm was, en dan moet je maar hopen dat de wederpartij niet gaat roepen dat je die vervalst hebt. Oh, en het filmpje ergens online neerzetten zodat er een onafhankelijke datering is van de inhoud.

Dat gezegd hebbende vind ik het altijd wel heel verstandig om bij zo’n late opzegging er zelf extra bovenop te gaan zitten. Even namailen, drie keer dat formulier insturen of bellen. Want het gedoe om het achteraf recht te trekken is altijd meer dan het gedoe van dat ene telefoontje.

(Terzijde: bewijslast gaat over wie bewijs moet leveren, niet de hoeveelheid bewijs die nodig is.)

Arnoud

21 reacties

  1. Technisch gezien (juridisch zal het wel weer anders liggen) vind ik dat je kunt zeggen dat het bericht is aangekomen bij hun webserver. Je hebt immers het contactformulier opgestuurd, en daarna werd je doorgestuurd naar een andere pagina. Dat is alleen mogelijk wanneer het bericht aangekomen is bij de server. Aangezien de webserver niet mijn verantwoordelijkheid is, maar die van de ontvanger, heb ik dan alles in mijn macht gedaan om te zorgen dat het bericht bij de ontvanger aankomt.

    Met e-mail is het wat lastiger; dan stuur je de mail namelijk naar je eigen provider, die ‘m vervolgens doorstuurt naar de eigenlijke ontvanger. Dus dan kun je niet zo makkelijk zeggen “hij kwam aan bij de server dus niet mijn probleem”, want wat als jouw eigen provider de mail kwijtraakte? Gelukkig zijn hier technische oplossingen voor; je kunt de ontvangende partij (via technische wegen) verzoeken een ontvangstbevestiging te sturen. Zo’n bevestiging ziet eruit als een bounce-mail, behalve dat er “Successful Mail Delivery Report” in de subject staat. Als je zo’n automatische bevestiging hebt sta je mijn inziens sterk.

    1. Als het via je eigen server gaat kun je in de logs zien op welk moment een door de ontvanger opgegeven systeem de mail heeft ontvangen. Bij een goede service gerichte provider kun je die informatie krijgen door het op te vragen.

    2. Daar doe ik (en een heleboel anderen) nooit aan mee. Leesbevestigingen van emails gaan me net te ver en vind ik net te arrogant. Evenzo onzichtbare pixels in mails, die ik nooit laat laden door mn client. En als links in de mail een hash bevatten, google ik liever naar de beoogde pagina dan dat ik de link gebruik (dit laatste werkt niet altijd en moet ik kiezen of ik de pagina bezoeken belangrijk genoeg vind).

      Sorry, maar als een anders iets wil weten over wat ik wel al iets heb gelezen, zal dat waarschijnlijk toch niet in mijn voordeel zijn. Dus waarom zou ik.

      1. Jij bedoelt de leesbevestiging, die wordt verstuurd wanneer een ontvanger de mail opent in z’n mailclient (en “Ja” antwoordt op de vraag of er wel een leesbevestiging verstuurd mag worden). Maar ik hoef niet te weten wanneer jij mijn mail leest, ik wil weten wanneer mijn mail bij jou aangekomen is.

        Dit is dus iets anders, Delivery Status Notification (RFC3461, section 4.1) geeft de mogelijkheid om een notificatie te sturen wanneer de mail afgeleverd is. Het kan zijn dat de mail is afgeleverd in een mailbox die nooit gelezen wordt, of rechtstreeks naar /dev/null gaat, maar ik heb op die manier in ieder geval bevestiging dat mijn mail in de server van de ontvangende partij is aangekomen. Of jij mijn mail te zien krijgt danwel leest is een andere zaak, maar ik heb mijn bewijs dat de mail aangekomen is.

      2. Dus als u zegt “Ik ga vanavond het journaal kijken” en ik kom morgen bij u langs om te praten over het journaal en vraag: “Hebt u het journaal nog gekeken gisteravond?” dan negeert u mij gewoon omdat ik dan een bevestiging vraag? Dat is namelijk exact hetzelfde als het versturen van een leesbevestiging via e-mail.

        1. Hoe kun je een koetjes- en kalfjesgesprek waarbij ik rustig kan liegen als ik wil exact hetzelfde noemen als het bewijs moeten leveren dat ik iets dat jij wil heb gedaan?! Als jij een dossier wil opbouwen tegen mij heb je lekker pech als je in bewijsnood verkeert. En dan ga ik echt niet zomaar meewerken aan mijn eigen ‘veroordeling’.

  2. Terzijde: bewijslast gaat over wie bewijs moet leveren, niet de hoeveelheid bewijs die nodig is.

    Hear hear! Ik erger mij een kriek aan al dat foute gebruik van het woord bewijslast. (Net zoals aan het niet kennen van het verschil tussen mits en tenzij. Of het gebruik van gesanctioneerd in de betekenis van bestraft. Kortom: gebruik geen dure woorden als je niet weet wat ze betekenen.)

  3. Lastig als je computer-wizard bent die screenshots, e-mails en ander (niet-cryptografisch) digitaal bewijsmateriaal met het grootste gemak kan vervalsen. Dan wordt bewijs dat je aanlevert niet overtuigender dan “mijn woord tegen het zijne”.

    Bewijsmateriaal lijkt me overtuigender als er een onafhankelijke derde partij is die als getuige fungeert, of een hele groep onafhankelijke derden (denk “block chain”). Je bent er alleen wel van afhankelijk dat het medium waarover je communiceert zich daar voor leent. Waarom ligt de bewijslast trouwens niet bij de partij die het communicatiemedium afdwingt (“je moet opzeggen via dit webformulier doen”)?

      1. Het gaat er niet zozeer om, denk ik, dat het werkt, maar dat degene die de ander een communicatieplatform kan opleggen zelf de verantwoordelijkheid draagt dat het werkt. Nu heb je de situatie: Goliath zegt tegen David: loop jij maar lekker door de kooi met de tijger om bij het loket te komen waar je kunt opzeggen. En dóet David dat, dan ligt ook nog eens de last bij hem om te bewijzen dát hij dat gedaan heeft. Daar zit een enorme scheefheid.

        Als je de marktmacht hebt om een medium op te leggen, dan heb je ook de macht een medium te kiezen dat altijd werkt.

        1. Terecht punt. Maar dan neig ik er meer naar om te zeggen, je mág dat platform niet bij uitsluiting van andere voorschrijven. (Wat de Wet Van Dam ook doet bij abonnementen). Want je komt hier niet uit denk ik. Als beheerder van het platform kan ik niet bewijzen dat jij niet het formulier hebt ingezonden. Ook niet met mijn logs; ik zie het verschil niet tussen geen formulier en een inzending die per abuis niet gelogd werd.

          1. Nee, dat klopt niet! Je kunt aan de server logs in veel gevallen wel zien dat een bezoeker op de knop inzenden heeft geklikt!

            Dit kan, omdat de browser dan een nieuwe request doet richting de server, en deze request komt ook in het log terecht. Ook al wordt alles via AJAX/JQuery gedaan dan is het nog een nieuwe HTTP(S) request en de server houdt dat netjes bij. Ten minste, als je een server log hebt aanstaan, want dit kan uitgeschakeld worden.

            Wat je niet kunt zien aan het log is of de inzending wel of niet is geslaagd. Dat zou weer in de web applicatie bijgehouden moeten worden.

            Maar in deze kwestie is het niet de vraag of het formulier wel of niet is aangekomen. Er wordt immers gezegd dat het formulier te laat was verzonden! Dus het is verzonden maar het gaat nu om het aantonen van het tijdstip waarop deze was verzonden. De klant zegt de 20e. Bedrijf zegt dat het later was…

            Hoe kan het dat het bedrijf de afmelding later heeft ontvangen? Vermoedelijk is het formulier dusdanig opgezet dat iedere afmelding niet meteen de database in gaat maar gewoon vertaald wordt naar een email met daarin de NAW gegevens van de klant en dan richting Klantenservice. Daardoor kan er een verschil in tijd ontstaan tussen het moment dat de klant het formulier inzendt en het moment dat deze email wordt verzonden. Immers, er kunnen op dat moment problemen zijn met de mail server of de web applicatie is ingesteld om maar om de 6 uur emails te verzenden. Maar dat is een probleem voor het bedrijf zelf want dan maakt hun systeem het mogelijk dat afmeldingen verdwijnen of te laat worden ontvangen.

      2. Als jij geen bewijs hebt, en die ander zegt dat ‘ie op tijd heeft opgezegd, dan krijgt die ander gelijk.

        Het is dan natuurlijk aan jou om er voor te zorgen dat je wel bewijs hebt, zodat je zelf niet in de problemen raakt. Bewijs van niet bestaan is inderdaad lastig (bewijs maar eens dat marsmannetjes niet bestaan). Misschien zijn er wel processen te bedenken waarbij een onafhankelijke partij elke opzegging kan waarnemen (eventueel encrypted / gehasht voor privacy) en het online zijn van je opzeg-systeem kan controleren.

        Probleem is wel: als jij een derde partij inhuurt, is die derde partij dan nog wel onafhankelijk? Het zelfde probleem geldt in omgekeerde richting als die ander een derde partij kan uitkiezen.

        Afgezien van “officieel betrouwbare” derde partijen (zoals notarissen) is mijn idee (andere reactie) om de block chain toe te passen misschien zo gek nog niet. Als je een gestandaardiseerde manier hebt op afzeggingen in een block chain te registreren, dan kan je naast aanwezigheid ook afwezigheid van opzeggingen controleren. Daarnaast is een block chain altijd online: er is geen server downtime. Probleem is wel dat dit nog geen “standaard techniek” is die beschikbaar is voor de gemiddelde consument, in tegenstelling tot web services. Wellicht wel een leuk idee voor een start-up, om zo’n service te beginnen.

  4. Ik heb nog wel een geeky oplossing:

    maak een screenshot van je ingevulde formulier (met klok van je computer zichtbaar), verstuur het formulier, maak nog een screenshot (met klok zichtbaar) die laat zien dat het formulier verstuurd is, maak een verklaring (“ik, …, heb dit formulier op dit en dat tijdstip ingevuld en opgestuurd, enz.”), maak een secure hash van de combinatie van de documenten (bijv. sha256(zip(screenshots, verklaring))), en leg die secure hash vast in de Bitcoin block chain, voordat de deadline verstrijkt. Bewaar voldoende gegevens (de zip file en eventueel een kopie van (een deel van) de block chain) om als cryptografische trace naar je data te dienen.

    Aangezien de Bitcoin block chain een betrouwbare timestamping service is, heb je daarmee in ieder geval krachtig bewijs geleverd dat de screenshots en je verklaring op het moment van vastleggen al bestonden. Zolang je voorafgaande aan de deadline geen motief kunt hebben gehad om de gegevens te vervalsen, lijkt het me overtuigend bewijs dat je het formulier ook daadwerkelijk hebt verstuurd. De screenshot van de webpagina die zegt dat het formulier is ontvangen lijkt me ook redelijk bewijs dat het ook is aangekomen op hun server. Wat er daarna met het formulier gebeurt is niet jouw verantwoordelijkheid.

    Het wordt misschien nog mooier als je, in plaats van screenshots, opgeslagen websites vastlegt, met bijbehorende TLS informatie; ik geloof dat daar wel browser plug-ins voor zijn. De TLS informatie bevat een digitale handtekening van de server-kant; dan is het dus helemaal onmogelijk voor mij om de gegevens te vervalsen, ook al zou ik daarvoor een motief hebben. Dat zou alleen kunnen als ik zou inbreken op hun server of bij een certificate authority (beide onwaarschijnlijk, dus bewijslast ligt bij andere partij).

  5. Wat mij altijd opvalt is dat de bedrijven die zeuren dat de opzegging te laat is of via een of andere exotische route moet worden ingediend nooit moeite hebben met aanmeldingen. Die zijn altijd op tijd, bindend en overtuigend gegeven, Het zou mooi zijn om bij het aanvechten van zo’n opzegging het gedrag bij aanmelden ook mee te kunnen nemen.

  6. Persoonlijk vraag ik mij af waarom iemand op de 20e opzegt, de laatste datum van een deadline, in plaats van een dag ervoor of nog eerder. Het uitstellen tot het laatste moment om op te zeggen is niet erg verstandig, vind ik. Maar goed, het moet wel kunnen.

    Overigens lijkt de bewijslast mij duidelijk. Er is een screenshot dat het formulier was ingevuld en men heeft een bericht ontvangen, dus is het aannemelijk dat het gewoon op tijd verzonden is. Maar dan sta ik ook even stil aan tijdzones. Want het is de 20e hier in Nederland maar in b.v. Japan kan het al de 21e zijn en in de USA is het misschien net de 19e. Dus als een deadline op de 20e valt, volgens welke tijdzone moet er dan gerekend worden? De tijdzone van de klant of the tijdzone van het bedrijf? 😀

    Ja, ik kom weer eens met een leuk scenario…

    1. Want het is de 20e hier in Nederland maar in b.v. Japan kan het al de 21e zijn en in de USA is het misschien net de 19e.

      Dat gaat je niet lukken 🙂 Het eerste wel: de 21e in Japan en de 20e in NL; het tweede ook: de 20e in NL en de 19e in de US. Maar een verschil van twee dagen (de 21e in Japan en de 19e in US) zit er niet in.

      1. De meest extreme tijdzones zijn UTC+14 (Kiribati) en UTC-12, met een verschil van meer dan 24 uur. UTC-12 is onbewoond, maar UTC-11 bevat Amerikaans Samoa. Er zijn daardoor wel degelijk plaatsen in de wereld die soms twee dagen van elkaar verschillen. Dat zijn alleen niet de VS en Japan.

Geef een reactie

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren, <UL>/<OL> voor lijsten, en <em> en <strong> voor italics en vet.