IMAP‑postkasser hos webhoteller: sikring og serverlogs

Forside › E-mail forensics · Gennemgået oktober 2026 · Af John Nielsen

Mange mindre virksomheder har mail hos et webhotel og ikke i Microsoft 365 eller Google Workspace. Her findes ingen samlet auditlog, ingen eDiscovery og ingen litigation hold. Postkassen sikres i praksis på to måder: en kopi hentet via IMAP med virksomhedens egen adgang, eller en kopi af mailmapperne direkte fra serveren, som kun hostingleverandøren kan lave. Serverens logs over logins og leveringer skal bestilles særskilt og hurtigt, fordi de typisk roterer efter få uger.

Haster det? Webhotellets logs over logins og leveringer forsvinder typisk efter få uger, og mails markeret til sletning kan blive fjernet ved næste oprydning. Se akut forensisk sikring; hastesager koster ekstra.

Generelt om hostingleverandørens logs og hvad der kan bestilles, se Hostingleverandørens logs. Denne artikel går i dybden med selve postkassen.

Hvordan en IMAP-postkasse er bygget

På serveren ligger mail typisk i Maildir, hvor hver mail er én fil, eller i et databaselignende format, som mailserveren selv styrer. Klienten ser kun det, IMAP-protokollen viser: mapper, mails med flag og en række attributter.

To attributter er centrale for en undersøgelse:

INTERNALDATE er tidspunktet, serveren modtog mailen. For mail leveret via SMTP er det leveringstidspunktet. For mail lagt ind med kommandoen APPEND, fx ved flytning fra en anden konto eller import, er det det tidspunkt, klienten oplyste. INTERNALDATE er altså ikke altid et uafhængigt servertidspunkt.
UID er et fortløbende id pr. mappe. Sammen med mappens UIDVALIDITY identificerer det en bestemt mail. Huller i UID-rækken kan pege på slettede mails, men kan også skyldes flytninger mellem mapper.

Flag som Seen, Answered og Deleted fortæller, om mailen er læst, besvaret eller markeret til sletning. De er nemme at ændre og siger intet om, hvem der satte dem.

Sikring via IMAP

En IMAP-kopi kræver legitim adgang til postkassen: virksomhedens egen konto, en administratoradgang hos webhotellet eller den berørte persons samtykke. Adgangskoder til andres konti må ikke skaffes uden om ejeren. Hvad virksomheden må gennemgå i en medarbejders postkasse, er en juridisk vurdering; se Må vi læse en medarbejders mail?.

Teknisk bør kopien laves med et værktøj, der:

åbner mapperne skrivebeskyttet (EXAMINE i stedet for SELECT), så Seen-flag ikke sættes ved hentning,
henter hver mail som rå RFC 5322-data uden konvertering,
gemmer INTERNALDATE, UID, UIDVALIDITY og flag pr. mail i en separat fil eller i containerformatet,
logger mapper, antal mails og eventuelle fejl,
beregner hashværdi pr. mail og for den samlede kopi.

Almindelige mailklienter er dårlige sikringsværktøjer. De sætter Seen-flag, kan konvertere tegnsæt og gemmer i egne formater. Valg af outputformat er gennemgået i Mailformater i forensics.

Brug ikke POP3. POP henter kun indbakken, og afhængigt af klientens indstilling kan mails blive slettet fra serveren efter hentning.

Sikring på serversiden

Hostingleverandøren kan kopiere postkassens filer direkte fra serveren. Fordelen er, at mail markeret til sletning, men endnu ikke fjernet, kommer med, og at filernes tidsstempler på serveren bevares. Ulempen er, at leverandøren skal udføre arbejdet og dokumentere det.

Bed om:

en kopi af hele postkassens mappestruktur i oprindeligt format, pakket uden komprimering, der ændrer tidsstempler,
hashværdi beregnet af leverandøren ved udleveringen,
en kort beskrivelse af, hvordan kopien er lavet, af hvem og hvornår,
serverens tidszone og om uret synkroniseres.

På et delt webhotel får kunden sjældent adgang til serverens filsystem. På en VPS med eget kontrolpanel kan virksomheden ofte selv sikre mailmapperne og logfilerne.

Serverens logs

Mailserveren skriver typisk tre slags spor, som kunden normalt ikke selv kan se:

Login-log for IMAP, POP og webmail · Konto, tidspunkt, IP-adresse, protokol, succes eller fejl
SMTP-log · Afsendte og modtagne mails med afsender, modtager, message-id og status
Postkasselog · Handlinger som sletning, flytning og kopiering, hvis funktionen er slået til

Den sidste er ikke standard. En udbredt IMAP-server har et plugin, der kan logge sletning, flytning og kopiering med UID og message-id, men både hændelser og felter er tomme i standardopsætningen, så pluginet skal være konfigureret, før hændelsen skete. Om et webhotel har gjort det, varierer og må afklares med udbyderen.

Webmail kører som en webapplikation, og dens adgangslog giver et ekstra spor med IP-adresse og user agent. Viderestillinger og autosvar oprettes ofte i kontrolpanelet eller via Sieve-filtre på serveren og skal sikres derfra, fordi de ikke er synlige som mails i postkassen.

Hvor længe et webhotel gemmer logs, fastsætter udbyderen selv, og perioden kan være kort. Bestil derfor logs skriftligt med præcis periode, konti og ønsket format, så snart sagen opstår, og bed om, at de bevares, indtil udleveringen er sket.

Typiske scenarier

Overtaget konto og fakturasvindel: Login-loggen viser IP-adresser og protokoller. Fremmede IMAP-logins fra udlandet kombineret med en ny viderestilling er et klassisk mønster.
Slettede mails før fratræden: En serverkopi kan indeholde mails markeret til sletning. Postkasseloggen kan vise sletningen, hvis den var slået til.
Skift af webhotel: Ved flytning bliver mails ofte kopieret med APPEND, så INTERNALDATE afspejler flytningen eller den oprindelige dato, afhængigt af værktøjet. Det skal afklares, før datoer tolkes.

Fejlkilder

INTERNALDATE efter en flytning viser ikke nødvendigvis modtagelsestidspunktet hos den oprindelige udbyder.
En mails Date-header er sat af afsenderens klient og kan være forkert eller manipuleret. Modtagelsestidspunktet vurderes ud fra Received-headerne, se Analyse af mail-headere.
Login-logs viser ofte den IP-adresse, der ramte serveren. Står en webmail eller proxy imellem, er det dens adresse.
Klienter på telefoner holder forbindelsen åben og logger ind igen med jævne mellemrum, så mange logins er ikke mange handlinger.

Kontrol af fuldstændighed

En IMAP-kopi er kun så god som kontrollen af, at alt kom med. Sammenlign antallet af mails pr. mappe i kopien med det antal, serveren oplyser via STATUS-kommandoen, og notér den samlede størrelse, hvis serveren understøtter kvoteoplysninger. Afvigelser skal forklares, før kopien bruges. Typiske årsager er mails, der ankom under sikringen, mapper, der ikke var abonneret på og derfor ikke blev vist, og meget store mails, som værktøjet sprang over.

Delte mapper og mapper fra andre konti kan være synlige via IMAP-navnerum. De hører ikke nødvendigvis til den postkasse, sagen handler om, og bør kun sikres, hvis der er grundlag for det.

Dokumentation

Rapporten bør angive server, port og krypteringsform, hvilken konto der blev brugt og med hvilket grundlag, værktøj og version, tidspunkt for start og slut i UTC, liste over mapper med UIDVALIDITY og antal mails, samt hashværdier. For serverkopier og logs fra leverandøren angives, hvem hos leverandøren der leverede dem, hvornår, og hvordan de blev overført.

Hvad sikringen kan og ikke kan bevise

En IMAP-kopi viser postkassens indhold og attributter på sikringstidspunktet. En serverkopi kan vise mere, herunder mails markeret til sletning. Ingen af dem viser, hvem der læste eller slettede, medmindre serverens logs gør det. Konklusioner om handlinger bygger derfor på kombinationen af postkasse og logs, og huller i logningen skal fremgå af rapporten.

Kilder og versioner

Funktioner og logopbevaring varierer mellem webhoteller og serverversioner.

Senest gennemgået: oktober 2026.

Næste skridt

Del af: E-mail forensics

Læs også: Exchange Server lokalt og hybrid: logkilder · Beviser en mail, at den er modtaget?

→ E-mail forensics · For IT-afdelingen · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT

Skrevet af John Nielsen, IT‑sagkyndig og indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Har været IT‑sagkyndig i danske retskredse og ved Den Fælles Europæiske Patentdomstol (UPC). Om John Nielsen · LinkedIn · Redaktionel politik