Archive and journaling

The archive ships with 0.1.0. Five ways fill it in 0.4.7: Exchange Online journal receipt over SMTP, Graph capture of Microsoft 365 mailboxes, forwarded copies from a mail provider, IMAP archiving of IMAP and Google Workspace accounts (all four need a Business or Service Provider license, and the last three since 0.4.4), and mail import with the option to archive at the same time (every edition, Community included). It is an append-only store with a SHA-256 hash chain and an archive check (every link, the daily anchors sealed every night and, on request, a sample of the stored messages), searchable by subject, addresses and (for imported mail) body text, with a fixed retention of 8 years, export as EML or MBOX and a JSON evidence report through the integration API in every edition. Enforced retention and legal hold need Business or Service Provider. Planned (no dates; the roadmap orders them): external daily anchors, Object Lock that follows the archive’s own retention, a retention policy per tenant, search in attachments, self-service and role-scoped search, an auditor export, a signed PDF evidence report, a choice per mailbox and a procedural documentation generator. See Archiving for the exact status list and Backup vs. archive for why backup and archive are deliberately different systems.

Capture ways

Five ways feed the archive.

Way	Mail source	Capture	Status
Exchange Online journaling	Microsoft 365	At transport: in transport, before delivery	Available since 0.1.0 (Business, Service Provider)
Graph capture	Microsoft 365	Near-time: from the mailbox, shortly after delivery	Available since 0.4.4 (Business, Service Provider)
Forwarding to the journal address	IMAP providers with a server-side copy (BCC or forwarding rule), Google Workspace (routing rule)	At transport: in the provider’s transport	Available since 0.4.4 (Business, Service Provider)
IMAP archiving	Any IMAP account, Google Workspace included	Near-time: from the mailbox, continuously	Available since 0.4.4 (Business, Service Provider)
File import with “archive at the same time”	EML, MSG, MBOX, ZIP, MailStore export	After the fact: at the import	Available since 0.1.0 (every edition)

The four ways that capture from a mailbox or at a provider’s transport are part of the Business and Service Provider editions; the Community build keeps the capture service idle and only imports files.

Every archive item carries its capture way in the field source. Search, the item detail, the export and the evidence report name it, and a mail that was imported or captured near-time never appears as journaled. The field has five values: journal, file_import, graph_sync, imap_sync and, since 0.4.4, smtp_forward for forwarded copies. In the interface a forwarded copy reads Forwarded.

Journaled or near-time capture

The product calls the two kinds At transport and Near-time (in the job editor, in search and on the archive page).

Journaled capture (an Exchange journal rule, forwarding at the provider) makes the copy in transport, before the mail lies in any mailbox. No user, no mailbox rule and no client can step in beforehand. The envelope of a journal report names all recipients, BCC and expanded distribution lists included, and even mail that never reaches a mailbox, or is deleted at once, is captured. That is the strongest proof of “complete and captured before any change”. The price: Restow has to accept mail from outside (port 25, a host name of its own with TLS), and if Restow is unreachable for a long time, the sending system eventually gives up delivering. A forwarded copy has no such envelope: the recipients stand only in its headers, and BCC recipients are not visible at all unless the provider writes them into a header.

Near-time capture (Graph, IMAP) fetches the mail from the mailbox shortly after delivery. It is not complete. In that gap a mail can be moved or deleted. A hold in the Microsoft 365 tenant largely closes the gap for deleted mail; for IMAP there is nothing comparable. Restow sees BCC recipients only on the sender’s side, and mail that an application sends without a copy in Sent Items is missing.

In short: journaling proves every mail as it passed through the server; near-time capture delivers every mail as it lay in the mailbox shortly afterwards. Restow labels both, and it claims no completeness for near-time capture.

Exchange Online journaling (Business and Service Provider)

A journal rule, configured in the Exchange 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. Setup, status and troubleshooting are on Exchange journaling; this section is what the way does.

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. The receiver needs a TLS certificate of your own and does not start without one.
Exchange requires an undeliverable-journal-report mailbox before journaling works at all. An administrator sets it once when turning journaling on. Since 0.4.4 Restow writes the Exchange Online PowerShell commands for the connector, that mailbox and the journal rule, ready to copy, and waits for the first report.
A journal report is an envelope around the original message. Restow reads the envelope (sender, recipients, message id, including the BCC recipients, which only the envelope shows) and stores the original byte-exact (message/rfc822) and the envelope as structured data.
A report that cannot be read in full is archived anyway and flagged (report-unparseable, report-parse-timeout, report-parse-memory-limit): Restow does not silently drop what it cannot fully understand. Reports are read in separate parser processes with time and memory limits, never in the api process; see How journal reports are read.
Since 0.3.1 each archived report is assigned, in the same transaction, to every protected mailbox of the tenant whose address its envelope names: as recipient, as sender (sent mail), as the mailbox a delegate sent for, or as the mailbox that forwarded. Addresses are compared in lower case against the primary address, the user principal name and every SMTP alias that the directory sync stores; an IMAP account is matched by its login. A report that names no mailbox of the tenant is archived all the same and belongs to the tenant only: nothing is dropped. Search, export and a legal hold on a mailbox take assigned reports into account. Reports received before 0.3.1 have no assignment.
One SMTP transaction delivers into one tenant’s archive: a recipient of a second tenant is answered 452 and delivered by the sender separately.
The receiver does not verify the sender yet (SPF, Microsoft address ranges). It accepts only known journal and archive addresses, limits the rate per sender IP address and per address (since 0.4.4: 600 connections and 300 deliveries per minute by default) and refuses reports above JOURNAL_MAX_SIZE_MB (150 MB by default).
Journaling only sees mail from the moment the rule is on. Mail that was already in a mailbox before then is not captured this way; Graph capture takes it over once.

Graph capture (Microsoft 365, since 0.4.4)

Restow subscribes to Microsoft Graph change notifications of new mail for each archived mailbox and fetches every new mail shortly after delivery. It needs only the app consent that backup already uses (Mail.ReadWrite, application permission): no new permission, no port 25, no mail host name, no journal rule. Details and the network side are on Connecting sources.

One subscription per archived mailbox, created and renewed in $batch (at most 20 per request and one request per second and Microsoft tenant), renewed with less than a day left, reauthorized when Microsoft asks, created again after a removal or an expiry and when the Entra app changes (a subscription belongs to the app that made it).
A notification carries no mail. It only tells Restow that a mail exists; the worker fetches the mail from Graph with its own token, within minutes. Drafts are skipped (a sent mail arrives as its own message in Sent Items). Immutable message ids keep a moved mail from being captured twice.
A regular catch-up fetches what a lost notification missed: a delta over every folder, hidden ones included, and the recoverable deletions, every 6 hours (ARCHIVE_GRAPH_CATCHUP_MINUTES, 360) and at once after a missed notification.
Without a public HTTPS URL Microsoft cannot send notifications, and every mailbox is checked every 15 minutes (ARCHIVE_GRAPH_POLL_MINUTES). The archive page says why.
Deleted mail. Restow reads the deletions folder of the Recoverable Items. What a user deletes for good before Restow has fetched it (seconds to minutes with notifications) can be missing, and only journaling captures before delivery. So that quickly deleted mail is captured too, the tenant should have a retention policy or a litigation hold active. Graph v1.0 cannot tell Restow, so an administrator confirms it on the archive page, with the Exchange Online PowerShell commands that check it.
Limits. Graph cannot export a mail over about 150 MB: such a mail is logged and not archived.

Forwarding to the journal address (IMAP providers, Google Workspace; since 0.4.4)

For providers without Exchange journaling, the provider sends a copy of every incoming and outgoing mail to Restow on the server side: a BCC rule in Postfix, mailcow or at the hoster, a Sieve redirect :copy, or the routing rule “Add more recipients” in Google Workspace. The receiver takes such copies besides Exchange journal reports. The copy arises in the provider’s transport, so, as with journaling, before any access by the user.

Two kinds of address. Every IMAP account can have its own archive address, archive+<token>@<journal host>: a copy to it belongs to exactly that account. A copy to the tenant’s journal address is assigned by its headers (From, To, Cc, Delivered-To and others) and by MAIL FROM; that is how a domain-wide rule or the Google Workspace routing rule works.
What a copy lacks. There is no envelope like a journal report’s. BCC recipients are visible only if the provider writes them into a header, and MAIL FROM is often an SRS address of the forwarder. The address of a single account therefore assigns safely, the tenant address only as far as the headers go.
The receiver is the one for journaling: port 25, a host name of its own, a TLS certificate, and STARTTLS is mandatory. The operator sets it up once for both. See Forwarding copies from the mail provider.
Sieve forwards incoming mail only; outgoing mail comes in through IMAP archiving.

IMAP archiving (IMAP and Google Workspace accounts, since 0.4.4)

A continuous sync of the mailbox that captures a mail as soon as it lies in the mailbox. For providers without forwarding it is the best available approximation and is labelled as such.

On activation Restow records where every folder stands (UIDVALIDITY and UIDNEXT). Mail up to there is taken over once; after that every pass reads only what is new: STATUS per folder, the metadata first, the source only of mail the archive does not hold for this account yet. A moved mail or an already forwarded copy is not downloaded again. A changed UIDVALIDITY reads the folder again without archiving anything twice.
All folders but Drafts. On Gmail and Google Workspace only All Mail, Spam and Trash are read, which hold every mail exactly once.
IDLE where the server offers it. Each worker process watches up to ARCHIVE_IMAP_IDLE_MAX accounts (300) with one open connection each, so new mail is noticed within moments; a STATUS round over the other folders runs every ARCHIVE_IMAP_POLL_MINUTES (5). Other accounts are checked by a login every ARCHIVE_IMAP_LOGIN_POLL_MINUTES (10). Providers with a tight connection limit: the source’s setting Check at intervals only.
IMAP accounts on a Microsoft host are archived like any other, but a Microsoft 365 source with Graph or journaling captures such mailboxes more completely.

The one-time takeover of existing mail (since 0.4.4)

When a way for a mailbox is switched on, a background job takes over the mail that is already there, once. It continues where it stopped, stops cleanly for an update or a shutdown and waits while a tenant’s storage switches targets. What it brings in is marked Captured afterwards (flag captured-late): the mail lay in the mailbox before capture began, so the archive can show when Restow got it, not that nobody changed it earlier. The archive page shows the progress.

One item per mail across ways (since 0.4.4)

Restow recognizes the same mail from several ways by its normalized Message-ID together with the exact bytes or a hash of the body (a journal copy and the mailbox copy differ in their headers, not in the body), and keeps one item. A capture that is not stronger than the one held becomes a capture row on that item, outside the chain, plus an assignment to the mailbox. A stronger capture (at transport beats from the mailbox beats import) becomes a new item that names the weaker one it replaces; the weaker item stays unchanged, because the archive is append-only. The same Message-ID with another body is kept twice and flagged message-id-conflict. Journal reports and imported mail are stored as items of their own. Search shows the stronger capture and lists the others on request (Show replaced captures, includeSuperseded=true on GET /api/v1/archive/search); see Archiving.

Mail imported from files (every edition)

Mail from a legacy mailbox that no longer exists (EML, MSG, MBOX, ZIP or a MailStore export) can be imported into Restow and archived at the same time, with the capture way file_import (Mail file import and export). This works in every edition, Community included. It is captured after the fact: the retention period starts at the import, not at the date on the mail, and the archive’s protection (append-only storage, hash chain) starts when Restow captures the item. An old mail imported today is counted from today. The mail’s own sending date is kept (in sent_at) and preferred in search and display. A message that is already archived for the same mailbox is not archived twice.

The job editor and the capture ways

The editor of a mail job (Backup jobs) recognizes the kind of each mailbox in the job (Microsoft 365, IMAP, Google Workspace over IMAP, IMAP on a Microsoft host) and offers only the ways that fit: Graph and Exchange journaling for Microsoft 365, IMAP archiving and forwarding for IMAP and Google Workspace. Each is labelled At transport or Near-time, locked with its edition, and at least one per kind is required. The defaults of a new job are Graph and IMAP archiving. A journal address is created only while Exchange journaling is chosen for Microsoft 365 mailboxes, and archive addresses for forwarding only on request. A job from before 0.4.4 keeps what it did: Exchange journaling for Microsoft 365, and no way yet for IMAP and Google Workspace until an administrator chooses one.

What the archive page shows (Business, since 0.4.4)

On the Archive page a tenant administrator sees the state of the ways: a notice, which can be hidden, that names the mail jobs where Graph or IMAP archiving could be switched on; the capture from the mailboxes with its streams, how mail is noticed (notified, or checked at intervals with the reason), counts and the takeover progress, and a table per mailbox with Catch up; the confirmation of the hold for deleted mail per Microsoft 365 source, with the read-only PowerShell commands that check it; the Exchange journaling commands and the wait for the first report; and the forwarding addresses per IMAP account with the configuration for Postfix, mailcow, Sieve and Google Workspace. Alerts say when capture stops: a mailbox in error for over an hour, forwarded copies or journal reports silent for 24 hours (the event archive.failed). All of it is described on Archiving.

Keeping it tamper-evident: the hash chain

Every archived item gets a chained hash: chain_hash = SHA-256(previous_chain_hash || item_hash || received_at). The Verify chain button on the Archive page (and GET /api/v1/archive/chain/verify in the API) runs three separate checks since 0.3.1 and names in its result what each one covered:

Links. Every entry’s chain hash is recomputed from its predecessor. This catches a changed hash and an entry removed or reordered anywhere but at the very end. It checks the checksums stored in the database; the first break is reported with its position (counted from 1) and the item.
Daily anchors. After each UTC day, a nightly run of the worker seals an anchor for every tenant whose archive grew that day: the date, the chain value of the last entry of the day and the number of entries the chain had by then. Anchors are append-only, and each one is also written to the worker log. The check compares the chain with every anchor: it must still reach it, with the same value at the same position. That exposes entries cut off the end of the chain, which the links alone cannot, because nothing is left to disagree. Entries newer than the last anchor are not covered yet, and the result says how many there are.
Content sample, on request. Verify chain and a sample of the content reads up to 100 randomly chosen messages back from the repository and compares each with the size and SHA-256 recorded at capture. Links and anchors are about database rows; only this check looks at the stored messages themselves, and only at the sample. A message archived before its repository was recorded cannot be compared, and the result says so.

Every check is written to the audit log (archive.chain.verified). That is what tamper-evident means here: a change is detectable, not impossible. Anyone with write access to the database could recompute the whole chain and the anchors with it, so on its own the chain does not prove who is honest. In 0.4.7 the check runs synchronously inside one request; a background run with progress is not built.

One shared append path (since 0.4.4). Every writer (journal receiver, file import, Graph capture, IMAP archiving, forwarded copies) appends through one shared path: the original is uploaded before the tenant’s chain lock is taken, so a large report no longer holds up the other deliveries of the tenant, and under the lock an item is stamped strictly later than the last one in the order the chain check walks (time, then id). Before that, two writers of one tenant with the same time could fork the chain.

Planned, not in 0.4.7: external daily anchors. The anchors above stay inside Restow, in its database and its worker log. Planned is a record of the date, the chain’s current value and the item count, 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. Checked against a value held outside Restow, a recomputed chain could be caught. The audit log has its own chain with daily anchors.

What the storage target enforces

Archive objects go into the chunk store like backup objects: the original byte-exact and encrypted. In addition, each object gets a sealed record, one JSON file per item at tenants/<tid>/archive/<year>/<month>/<archive_item_id>.json. The archive is protected on two layers. The application has no code path to change or delete an archived item before its retention ends: the only deletion is the retention run after expiry, for items without a legal hold (Business and above). The storage target can add a second layer, and what it adds depends on the target. The default archive target is the local volume of the installation.

With Object Lock on S3. The sealed record carries an Object Lock retention (compliance mode) to the end of the archive retention. The message content lives in packs of the chunk store, next to backup data. Since 0.4.0 an administrator can turn on immutable backups for a repository, and then those packs are locked as well, so the content of archived mail too: for the period set there (1 to 3650 days), renewed every 6 days while the packs are in use. That period is a setting of the repository, not the archive’s retention. Object Lock that follows the archive’s own retention is planned.
Without Object Lock (local storage, NFS, S3 without a lock, or a repository without immutable backups). Restow enforces immutability at application level only: no deletion or change path in the code, and the chain check. Whoever has access to the files or the server can change or delete them, and packs carry no retention. The Repositories page labels such targets “No hardware WORM” or “Object Lock not enabled”, the Archive page says how the storage protects archived mail, and the job editor says so when a job archives. Object Lock is not a precondition for archiving; it is what you add if you want the storage itself to refuse changes.
Dedupe. Identical content lies in the chunk store once per tenant. Since 0.4.4 the archive also recognizes the same mail from several capture ways (by Message-ID and content) and keeps one item, with a capture row and an assignment to the mailbox for each further capture; see One item per mail across ways. Journal reports and imported mail still become items of their own.
The field object_lock. The field object_lock of an archive item, and the counter objectLocked in the archive status and the evidence report, mean “has a retention end date”. They do not mean “lies under Object Lock”.

What that means in practice:

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. That is a real protection against anything that goes through Restow, but not the same guarantee a storage-enforced write lock gives.
On the Repositories page (Tenant settings → Repositories), a successful test of an S3 repository shows whether the bucket enforces Object Lock. Whether backup data and archived content are locked is a separate setting on the repository’s card, Immutable backups, off until an administrator turns it on.
With it on, the storage itself refuses to delete or overwrite the packs, committed manifests and wrapped keys before their date, also for someone who holds Restow’s storage key. If someone who controls Restow stops the renewal, what is locked runs out after the period you set. A directory gets only a deletion delay that Restow keeps, which is not immutability, and the installation’s default repository cannot be made immutable in 0.4.7.
Backups are a separate system (see Backup vs. archive). Their lock is a setting of each repository and does not show by itself that an archive or a procedure meets GoBD.

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

Retention and legal hold

Retention in 0.4.7 is a fixed default for every tenant: archived items are kept for 8 years, and the period ends on 31 December of the year of receipt plus 8 years (mail received in 2026 is kept to 31 December 2034). The Archive settings show it (GET /api/v1/archive/retention); no screen and no API sets another one. That covers the 6 years for business letters and the 8 years for accounting vouchers, but not the 10 years for books and annual financial statements; see GoBD and evidence.
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 default starts the clock at the end of the calendar year, which matches the statutory minimum. Starting it at the capture date instead would end retention earlier than the statutory calculation, by up to about a year.
Legal hold (Business and above) can be placed and released on the Archive page for a whole tenant or for a single mailbox. It has a reason, the person who created it and a date, and it is audited like any other action that touches archived data. A hold blocks deletion outright, including the scheduled retention run. Releasing a hold needs a reason in the interface, and the audit log records it (archive.legal_hold.released); the API accepts a release without a reason for clients of the first version, then the audit entry has none. A hold that was already released is not released a second time (409). A hold on a search result is not available in 0.4.7. A mailbox hold protects the archive items that belong to a mailbox: mail archived at import, journal reports assigned to that mailbox (since 0.3.1) and, since 0.4.4, the mail captured from that mailbox and the copies forwarded for it. Reports without an assignment, which includes every report received before 0.3.1, are protected only by a tenant-wide hold.
A daily deletion run (Business and above; the task retention, scheduled by default at 04:30) removes only items that are both expired and not held, and writes each deletion, with the item’s hashes, to the hash-chained audit log (archive.item.deleted), so even legitimate deletion after retention ends stays traceable. Without the Business capability, nothing is ever deleted from the archive.
Retention does not necessarily end at the fixed 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, and Restow’s run does not check it. Applying that check, for example with a legal hold, is your organization’s own decision, not something Restow automates.
Planned: a retention policy per tenant (6, 8, 10 years or unlimited), optionally per mailbox group, with the clock starting at the capture date or, as § 147(4) AO counts, at the end of the calendar year; and a deletion log (number, period, hashes of the deleted objects) as an entry of its own in the chain. A separate retention policy per mailbox group is planned as well.

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

Planned, not in 0.4.7. 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 archival that regular staff correspondence gets for evidentiary reasons. Restow is meant 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 on the Protection tab.

In 0.4.7 there is no such switch per mailbox in Restow. The question What should this job do? on a mail job (see Backup jobs) switches the archive on for all the job’s mailboxes, and the capture ways are chosen per kind of mailbox, not per mailbox. What reaches the archive through journaling is decided by the journal rule you set in Exchange Online (everyone, or selected recipients or groups), what Graph, IMAP archiving and forwarding capture by the mailboxes of the jobs that archive and the rules at the provider, and mail import archives what you choose to import with the archive option. 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.

Journaling and mailbox backup

Journaling does not replace the mailbox backup, and the backup does not replace journaling. They run independently: the archive changes no backup run, skips none and deduplicates none; they share only the tenant’s chunk store.

Journaling captures what Exchange Online sees in transport, at the moment the mail passes through:

incoming and outgoing mail, internal and external, BCC recipients through the envelope, as far as the journal rule covers these messages (the type All messages for all senders and recipients, see Exchange journaling). A rule only for external mail, or only for certain users, does not capture internal mail or the other mailboxes;
the state at sending: what a user changes, moves or deletes afterwards does not change the copy in the archive.

Journaling does not capture:

calendars, contacts, tasks and notes, and no meeting responses as mailbox objects (an invitation that travels as mail lies in the archive as mail);
drafts and everything that was never sent;
the folder structure, the folder of a mail, read and flag status, categories and later moves;
later changes and deletions: the archive shows the state in transport, not the current state of the mailbox, and it cannot put a mailbox back into an earlier state (a restore into the original folders);
mail that lay in the mailbox before journaling was turned on (existing mail, see Limits);
mail that does not pass through the Exchange Online transport: imported into the mailbox directly (PST import, migration, Graph or IMAP), or rejected or quarantined by the transport before the journal rule acts;
reports that do not reach Restow (connector, firewall, certificate): Exchange Online sends them to the mailbox for undeliverable journal reports, not to the archive.

Graph capture and IMAP archiving capture from the mailbox, so they see a mail only after it was delivered, in the state it has then. They do not replace the backup either: they capture neither calendars and contacts nor the folder structure, and a restore into the original folders stays a job of the backup. What the backup and the archive each keep is the same question as for journaling, only with a gap between delivery and capture.

The mailbox backup captures mail, calendar and contacts with folders and status at the time of the run, and restores them. It does not see what arrives and is deleted between two runs, and it is not tamper-evident: restore points expire under their retention policy.

When to use which:

To be able to restore (a deleted mail, whole folders, calendars, a mailbox after an error or an attack): the mailbox backup. It is always needed.
To be able to prove (GoBD, retention periods, legal hold, the mail before any change by users): the archive, in addition to the backup. Journaling or forwarding at transport is the strongest way; Graph and IMAP archiving capture from the mailbox and are not complete.
While journaling is active for a tenant, new mail is in the archive from its arrival (with Graph or IMAP archiving: from shortly after it). A less frequent backup (for example every 8 hours or daily instead of hourly) then only shrinks the window in which calendar, folders and status can be lost, not the capture of the mail, and it puts less load on Microsoft 365. Restow does not change the frequency by itself: the editor of a mail job suggests Back up every 8 hours and applies it only when you click, see Backup jobs.

Search, export and evidence

Search (every edition, on the Archive page for tenant administrators): full-text search over the subject, the addresses (sender and recipients) and, for imported mail, mail captured from the mailbox and forwarded copies, the body text (the first 200,000 characters; very long bodies can be cut), with paging and filters by sender, date, mailbox and “has attachment”. Attachment content is not searched (no PDF, DOCX or XLSX extraction), and the body text of journal reports is not indexed in 0.4.7, so journaled mail is found by subject and addresses, and a report archived without its details is not found at all. It uses PostgreSQL full-text search with the simple configuration: no stemming, no language analysis. Only tenant administrators search. A hit names its capture way and, since 0.4.4, the other ways that captured the same mail again and whether it was captured afterwards; a capture that a stronger one replaced is hidden unless you choose Show replaced captures. An archived message can be read in Restow and downloaded as .eml (since 0.3.1). Searches, every item you read and every download are recorded in the audit log.
Roles (planned): a tenant admin will be able to search across the whole tenant with role-scoped rules (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. In 0.4.7 the archive is for tenant administrators.
Export (every edition): archived mail can be exported as EML files in a ZIP with the original folder structure, a MANIFEST.csv and a SHA256SUMS file, or as MBOX. A worker job builds the file, it can be downloaded for 24 hours, and every request and download is written to the audit log. Exporting the current search leaves out replaced captures, as the search does, so the export holds what the search counted. The export can be read without Restow. See Mail file import and export. The export for handing to an auditor, which also carries a CHAIN.txt of the relevant chain values, is planned.
Evidence report (every edition, as JSON through the integration API): GET /api/v1/archive/report (scope archive:read, at most 366 days, 30 days by default, with from and to) returns the tenant, the period, the number and size of the items, the items per capture way, the daily anchors of the period, the retention policies stored for the tenant and the legal holds in the period. GET /api/v1/archive/status returns the current counts per capture way, the chain anchors, the retention policies and the active legal holds. Two things to know: the chain state in both reads not_verified in 0.4.7, because neither call runs the chain check (use the archive check, see above), and the built-in default of 8 years is not stored as a policy, so a tenant on the default may show no policy there (GET /api/v1/archive/retention shows the period that applies). Reading the report is audited. The contract stays at 1.5.0: forwarded copies count in the totals but are not listed as a channel of their own, and graphSync and imapSync report the new ways. There is no PDF report and no screen for it yet.
Planned: search in attachments (PDF, DOCX, XLSX, TXT) and by size; self-service search for end users in their own mailbox; the provider-admin release described above; CHAIN.txt in the export; the evidence report as a signed PDF in the interface (tenant, period covered, item count, storage target, chain-check result, retention policy, deletion-run logs and a signature over the report itself).

Known issues of the capture ways (since 0.4.4)

The capture ways were tested against simulated services (a simulated Graph API, a simulated IMAP server and the Dovecot of the release smoke, the receiver itself for forwarding), not against a real Microsoft 365 or Google Workspace tenant, Postfix, mailcow or hoster. Holds in a Microsoft 365 tenant are not detected, and only the deletions folder of the Recoverable Items is read, so mail purged before Restow fetched it can be missing. Graph cannot export mail over about 150 MB. The receiver does not check the sender, and its limits count per api process. IMAP sources with OAuth2 cannot be created yet. Forwarded copies count in the totals of the integration API but are not a channel of their own. The list is on Archiving.

Procedural documentation (planned)

The procedural documentation (Verfahrensdokumentation) is planned; Restow 0.4.7 does not generate it. The intention: a document per tenant, generated from the configuration and a template, with the system description, the capture ways, the storage location, encryption, access rights, retention, the deletion procedure, the controls (archive check, scrub), the responsible people and the change history. It would come as Markdown and PDF, versioned and dated. It is part of being audit-ready, not an extra. The full document, including your organizational processes, stays your organization’s own responsibility.

Where to read more

Archiving: the administrator-facing summary and current status.
Exchange journaling: the setup, step by step.
Connecting sources: what Graph capture, IMAP archiving and forwarded copies need from Microsoft 365, the mail provider and your network.
Regulations: which requirements this design targets, and whether WORM storage is actually required.
GoBD and evidence: the German legal detail behind the GoBD requirements “unalterable” and “timely”, and what Restow does not claim.
Backup vs. archive: why these are separate systems in the first place.
Immutable backups: S3 Object Lock and the deletion delay for the backup data of a repository.