Archive and journaling

Capturing mail before anyone can touch it

Exchange Online journaling (the primary path)

A journal rule, configured in the Exchange Online admin center by the customer’s own administrator, tells Exchange to send a copy of matching mail (a journal report) to an address Restow controls, before the recipient’s mailbox can be read, changed or deleted from. The rule can be scoped to everyone in the tenant or to selected recipients or groups, the same way Restow’s own protection rules work.

Each tenant has its own journal address, journal+<token>@<journal host>, with a random per-tenant token so a report cannot land in the wrong tenant’s archive by guessing the address. Setup steps are on Exchange journaling.
Exchange requires an undeliverable-journal-report mailbox to be configured before journaling works at all. An administrator will set this once as part of turning journaling on.
A journal report is an envelope around the original message: Restow is planned to parse the envelope (sender, recipients, message id, including BCC recipients, which are only visible in the envelope, never in the message itself) and to store the original byte-exact (message/rfc822) alongside the envelope as structured data.
A report that cannot be parsed (a missing attachment, a malformed envelope) is planned to be archived anyway and flagged as incomplete: Restow is designed not to silently drop what it cannot fully understand.

Graph sync (a supplement, not a substitute)

Journaling only sees mail from the moment the rule is active. A Graph-based sync fills in what already existed in a mailbox before that point, plus calendar and contact items journaling does not cover at all. Anything captured this way is marked “captured after the fact”: the hash-chain protection below only starts once Restow actually has the item, so an item captured late cannot claim to have been captured at the moment it arrived.

IMAP archiving: what it is designed to capture, and what it cannot guarantee

For mail providers without a journaling equivalent, Restow plans a continuous IMAP sync (IDLE where the server supports it, polling otherwise) as the best available approximation:

What it is designed to capture: anything still in the mailbox the next time Restow syncs.
What it cannot guarantee: completeness. A message read, moved or deleted by the user or a mail rule between arrival and the next sync is never seen, unlike journaling, which captures before any of that is possible. Restow documents this plainly as an approximation, never as equivalent to journaling.
Where the provider supports it, Restow recommends adding a server-side copy rule (a Sieve rule, or a BCC-to-journal-address rule) so a copy reaches the archive independently of the mailbox’s own state. The interface is designed to show, per IMAP account, which capture path is actually active.

Mail imported from files

Mail from a legacy mailbox that no longer exists (EML, MSG, MBOX, ZIP or a MailStore export) can be imported into Restow and, optionally, archived at the same time, with the capture route file_import (Mail file import and export). Like a Graph sync it is captured after the fact: the retention period starts at the import, not at the date on the mail, so an old mail imported today is unalterable from today and counted from today. The mail’s own sending date is kept and preferred in search and display. A message that is already archived for the same mailbox is not archived twice.

Keeping it unalterable: hash chain and WORM

Every archived item is planned to get a chained hash: chain_hash = SHA-256(previous_chain_hash || item_hash || received_at). A daily anchor records the date, the chain’s current value and the item count; the anchor is planned to be emailed to the operator and, optionally, sent to an external RFC 3161 timestamp authority (for example freetsa.org) so the anchor’s own timestamp is independently verifiable. Anyone with write access to the database could recompute the chain itself, so the chain alone does not prove anything. Altering or deleting an archived item is designed to make that alteration detectable specifically when the chain is checked against the daily anchors held outside Restow (the emailed copy, or the external timestamp), which is why those anchors, not the chain by itself, are what makes tampering detectable.

Preventing it at the storage layer, not just detecting it, is what object lock (WORM) adds:

The default archive storage target is planned to be S3-compatible object storage with Object Lock in COMPLIANCE mode: every archive object written with a retain-until date matching the end of its retention period, with legal hold using the storage’s own object-level legal hold in addition to Restow’s own.
A filesystem target (a local path, NFS or SMB share) has no hardware WORM. Using one for the archive is planned to require an explicit, audited provider-admin opt-out (“application-level immutability only”), and both the interface and every evidence report generated from that point on are designed to say so in those words: “storage target without hardware WORM.” Application-level immutability means what it says: no code path to modify or delete an archived item before its retention ends, plus the hash chain to detect tampering if someone bypassed Restow entirely. That is a real protection, but not the same guarantee a storage-enforced write lock gives.

See Regulations for whether the law actually requires WORM specifically, or accepts other measures.

Retention and legal hold

A retention policy per tenant, with a suggested default of 10 years and 6, 8, 10 years or unlimited selectable (matching the German commercial and tax retention periods, see Regulations), and, planned as an option, a separate policy per mailbox group.
The statutory calculation under § 147(4) AO (and § 257(5) HGB) starts the retention clock at the end of the calendar year in which a record was received or sent, not at its exact capture date, and it applies broadly, to everything covered by § 147(1) AO, not only accounting vouchers. Restow’s retention policy is planned to offer that end-of-calendar-year start as well as a simpler capture-date start for the same number of years; starting at the capture date ends retention earlier than the statutory calculation, by up to about a year, so the end-of-calendar-year option is the one that matches the statutory minimum.
Legal hold is planned to be applicable at the level of a tenant, a mailbox, or a saved search result, with a required reason, who applied it and when. A hold is designed to block deletion outright and to itself be audited like any other action that touches archived data.
A daily deletion run is planned to remove only objects that are both expired and not held, and to write what it deleted (count, period covered, and the hashes of the deleted objects) into the same hash chain used for integrity, so even legitimate deletion after retention ends stays traceable.
Retention does not necessarily end at the fixed 6/8/10-year mark: under § 147(3) AO, a record must be kept longer while it still matters for a tax assessment that is not yet final. A deletion run that always deletes at the fixed period without checking this could delete too early. Applying that check, or extending a policy manually, is your organization’s own decision, not something Restow automates.

Choosing per mailbox: back up only, or back up and archive

Not every mailbox needs the same treatment. A shared mailbox like bestellung@ or noreply@ may be worth backing up, so it can be recovered if something breaks, without needing the same permanent, unalterable archival that regular staff correspondence gets for evidentiary reasons. Restow is planned to let you choose per mailbox, through the same rule mechanism the backup scope already uses (everyone, a group, an exclusion list, individual overrides), whether an object is backed up only, or backed up and archived, shown side by side as separate Backup and Archive columns in Protected objects.

Once archiving ships, the planned default is that every mailbox is archived; excluding one is a deliberate, explicit, audited choice, not a quiet default. A journal report naming recipients outside the archive scope is planned to simply not be stored for them, unless another recipient of the same message is in scope, in which case the message is archived once, for the in-scope recipients. Every change to what is in or out of scope is designed to be audited and to appear in the evidence report, and the documentation is planned to explain how to scope the underlying Exchange journal rule itself (by recipient or group). Excluding a mailbox that actually carries business-relevant correspondence from the archive remains your organization’s own decision under GoBD, not something Restow decides on your behalf.

Search, export and evidence

Full-text search (available in 0.1.0) over subject, body and attachment content (PDF, DOCX, XLSX, TXT), sender, recipient, date, mailbox and size.
Roles (in development): a tenant admin will be able to search across the whole tenant (itself audited); an end user will only ever be able to search their own mailbox; a provider admin will need an explicit, tenant-granted, four-eyes release before searching a customer’s archive at all.
Export (partly available): archived mail can already be exported as EML files in a ZIP with the original folder structure, a MANIFEST.csv and a SHA256SUMS file, or as MBOX; see Mail file import and export. The export for handing to an auditor, which also carries a CHAIN.txt of the relevant chain values and is readable by any mail client without Restow running, is still in development.
Evidence report (PDF, in development): tenant, period covered, item count, storage target, its object-lock status, chain-verification result, the retention policy in force, deletion-run logs, and a signature over the report itself.

Where to read more

Archiving: the administrator-facing summary and current status.
Regulations: which requirements this design targets, and whether WORM storage is actually required.
GoBD and evidence: the German legal detail behind “unalterable” and “timely”.
Backup vs. archive: why these are separate systems in the first place.