Overview
This article describes what Data & More needs from your environment to ingest archived email from MailStore and to delete individual messages from the archive as part of policy enforcement.
Ingestion and deletion use two different MailStore interfaces with separate access requirements. You can grant ingestion access first and deletion access later — but deletion cannot work without both.
1. Product prerequisite
Requirement | Why |
|---|---|
MailStore Server (not MailStore Service Provider Edition) | The SPE Management API has no |
Product and exact version communicated to us | Deletion behaviour is verified per version. Validated so far against MailStore Server 26.1. |
On SPE? Ingestion still works (see section 2), but delete enforcement is out of scope — tell us and we will configure report-only mode.
2. Ingestion – integrated IMAP server
We read archived messages through MailStore's built-in IMAP server. It is read-only by design; nothing we do over this connection can modify or delete archive content.
Requirement | Detail |
|---|---|
Integrated IMAP server enabled | Enabled in MailStore Service Configuration |
Network access | TCP 993 (IMAPS) from our deployment host(s) to the MailStore server |
A MailStore user for us | With the IMAP access privilege and read access to every archive in scope for compliance processing |
TLS certificate | A certificate our host can verify — publicly trusted, or your internal CA chain provided to us |
The archives this user can see define what we can process: messages in archives outside its access are invisible to ingestion and therefore also to enforcement.
3. Deletion – Administration API
Message deletion is not possible over IMAP (MailStore documents this explicitly, regardless of user privileges). It goes through MailStore's Administration API instead.
Requirement | Detail |
|---|---|
Administration API enabled | Off by default; enabled in MailStore Service Configuration |
Network access | TCP 8463 (HTTPS) on the same host as the IMAP server in section 2, reachable from our deployment host(s). MailStore recommends restricting this port to internal machines — a firewall rule scoped to our host(s) is sufficient and preferred |
Administrator rights on the account from section 2 | Our current integration uses a single account for both interfaces: the user from section 2 must additionally be a MailStore administrator with rights to list folders/messages ( |
App password if MFA is enabled | MailStore administrators with multi-factor authentication must use an app password for API access |
Compliance settings must permit deletion | Retention periods, legal hold, or archive-access compliance settings can block deletion even for administrators. If a message under an active hold must not be deleted, that is correct behaviour — but tell us which archives are affected so enforcement reporting is accurate |
TLS certificate | Same as section 2 — verifiable by our host |
What deletion does on your side
Every deletion is irreversible and is written to MailStore's own audit log together with a reason string we supply, identifying the policy and document that triggered it.
We resolve the message immediately before deleting and verify afterwards that it is gone; we never record a deletion that MailStore did not confirm.
Deletion runs only when a deletion policy is explicitly enforced, and only for messages that have passed the review flow: affected users are notified in advance through the platform, and anything flagged as a false positive is excluded before enforcement runs.
4. Validation environment
Before deletion is enabled against production archives, we need one of:
a non-production MailStore instance, or
a disposable test archive / mailbox on the production instance
with a handful of expendable messages, so the full resolve–delete–verify cycle can be demonstrated in your environment. One short session; we can supply the test messages.
5. Credential handover
Deliver credentials over a secure channel (password manager share or equivalent — not email).
Tell us before rotating either account's password or changing its privileges; enforcement fails safe (nothing is deleted, alerts are raised) but processing stops until credentials are updated.