Timestamp anchoring is the Enterprise answer to a hard question: how do you prove an email existed at a point in time, even against an attacker who controls the whole server?

The internal audit hash chain is "self-sealed" — whoever controls the server could rewrite both the data and the chain. Anchoring submits the archive's fingerprints to an external, third-party notary (an RFC 3161 Time-Stamping Authority), so backdating is detectable: the old anchor no longer matches.

How it worksCopy Anchor Link

1. Bichon maintains a Merkle tree over every archived email's content hash (leaf = SHA-256 of envelope_id | content_hash | ingest_at [+ deleted_at for tombstones]). Leaves are append-only — deleted emails keep a tombstone leaf, so deletion cannot silently remove history.
2. Periodically (default every 24 hours), the tree root is submitted to a TSA as an RFC 3161 timestamp request.
3. The returned TSA token is stored in timestamp/anchor.db with status verified (a pinned TSA certificate validated the token), stored (the TSA returned a token but no pinned certificate was configured, or validation failed), or local (no TSA configured, so only the root hash is recorded).

Per-email proofsCopy Anchor Link

POST /api/v1/timestamps/verify-email/{envelope_id} returns a proof bundle: the email's leaf hash, its Merkle path, the anchored root hash, and the TSA token. A third party can then verify — offline, with only openssl ts -verify, without Bichon — that this exact email existed, with this exact content, at the anchored time.

ConfigurationCopy Anchor Link

APICopy Anchor Link

All endpoints require the timestamp:manage permission and an Enterprise license.