Oversigt
Denne artikel beskriver, hvad vi hos Data & More har brug for fra vores miljø for at kunne indlæse arkiverede e-mails fra MailStore og for at kunne slette individuelle beskeder fra arkivet som led i politikhåndhævelse.
Indlæsning og sletning anvender to forskellige MailStore-grænseflader med separate adgangskrav. Du kan tildele adgang til indlæsning først og adgang til sletning senere – men sletning kan ikke fungere uden begge dele.
1. Produktforudsætning
Krav | Årsag |
|---|---|
MailStore Server (ikke MailStore Service Provider Edition) | SPE Management API har ingen |
Produkt og præcis version meddelt til os | Sletteadfærd verificeres pr. version. Valideret hidtil mod MailStore Server 26.1. |
Anvender du SPE? Indlæsning fungerer stadig (se afsnit 2), men håndhævelse af sletning er ikke inden for scope – meddel os dette, og vi konfigurerer rapport-only-tilstand.
2. Indlæsning – integreret IMAP-server
Vi læser arkiverede beskeder via MailStores indbyggede IMAP-server. Den er skrivebeskyttet by design – intet, vi foretager os over denne forbindelse, kan ændre eller slette arkivindhold.
Krav | Detalje |
|---|---|
Integreret IMAP-server aktiveret | Aktiveres i MailStore Service Configuration |
Netværksadgang | TCP 993 (IMAPS) fra vores deployment-vært(er) til MailStore-serveren |
En MailStore-bruger til os | Med rettigheden IMAP-adgang samt læseadgang til alle arkiver, der er omfattet af compliance-behandling |
TLS-certifikat | Et certifikat, som vores vært kan verificere – enten offentligt betroet eller din interne CA-kæde leveret til os |
De arkiver, denne bruger har adgang til, definerer, hvad vi kan behandle: beskeder i arkiver uden for brugerens adgang er usynlige for indlæsning og dermed også for håndhævelse.
3. Sletning – Administration API
Sletning af beskeder er ikke mulig via IMAP (MailStore dokumenterer dette eksplicit, uanset brugerrettigheder). Det sker i stedet via MailStores Administration API.
Krav | Detalje |
|---|---|
Administration API aktiveret | Deaktiveret som standard; aktiveres i MailStore Service Configuration |
Netværksadgang | TCP 8463 (HTTPS) på samme vært som IMAP-serveren i afsnit 2, tilgængelig fra vores deployment-vært(er). MailStore anbefaler at begrænse denne port til interne maskiner – en firewallregel afgrænset til vores vært(er) er tilstrækkelig og foretrukken |
Administratorrettigheder på kontoen fra afsnit 2 | Vores aktuelle integration anvender én enkelt konto til begge grænseflader: brugeren fra afsnit 2 skal desuden være MailStore-administrator med rettigheder til at liste mapper/beskeder ( |
App-adgangskode hvis MFA er aktiveret | MailStore-administratorer med multifaktorgodkendelse skal anvende en app-adgangskode til API-adgang |
Compliance-indstillinger skal tillade sletning | Opbevaringsperioder, juridisk hold eller adgangsbegrænsende compliance-indstillinger for arkiver kan blokere sletning selv for administratorer. Hvis en besked under et aktivt hold ikke må slettes, er dette korrekt adfærd – men meddel os, hvilke arkiver der er berørt, så håndhævelsesrapporteringen er præcis |
TLS-certifikat | Samme som afsnit 2 – verificerbart af vores vært |
Hvad sletning gør på din side
Enhver sletning er uigenkaldelig og skrives til MailStores egen revisionslog sammen med en årsagsstreng, som vi leverer, og som identificerer den politik og det dokument, der udløste den.
Vi løser beskeden umiddelbart inden sletning og verificerer efterfølgende, at den er fjernet; vi registrerer aldrig en sletning, som MailStore ikke har bekræftet.
Sletning køres kun, når en slettepolitik er eksplicit håndhævet, og kun for beskeder, der har gennemgået review-flowet: berørte brugere adviseres på forhånd via platformen, og alt, der er markeret som falsk positiv, ekskluderes, inden håndhævelse køres.
4. Valideringsmiljø
Inden sletning aktiveres mod produktionsarkiver, har vi brug for ét af følgende:
en ikke-produktions-MailStore-instans, eller
et engangstestarkiv / -postkasse på produktionsinstansen
med et antal udgiftelige testbeskeder, så den fulde løs–slet–verificer-cyklus kan demonstreres i dit miljø. Én kort session; vi kan levere testbeskederne.
5. Overdragelse af legitimationsoplysninger
Lever legitimationsoplysninger via en sikker kanal (deling via adgangskodeadministrator eller tilsvarende – ikke e-mail).
Meddel os dette, inden du roterer adgangskoden på nogen af kontiene eller ændrer deres rettigheder; håndhævelsen fejler sikkert (intet slettes, alarmer udløses), men behandling stopper, indtil legitimationsoplysningerne er opdateret.