The parts nobody sees.

Accepting mail from strangers

The roster to calendar sync accepts a roster sent as an ordinary email. The message is handled at the network edge as it arrives, the sender is authenticated, the shifts are imported, and the sender gets a reply listing exactly what was read. Because it runs on the mail path itself rather than as a mailbox something polls, there is no inbox in the middle for a roster to sit in and no scheduled job that can quietly stop.

Authentication runs before every other check. A message that fails it is refused without a reply, so the service cannot be turned into a way of bouncing mail at an address somebody else forged. The only authentication result trusted is the one stamped by the receiving mail infrastructure, identified by which server wrote it rather than by where it sits in the message, so a sender who types a convincing header of their own gains nothing. When no recognised stamp is present the check fails closed and the message is refused, and the refusal records every stamp it did see, so a genuine change in the mail infrastructure is diagnosable rather than a silent outage.

Authentication vouches for the address written in the message header, not for the address the sending server declares, so the two are additionally required to agree. That closes a real path in which an outsider authenticates perfectly well on a domain they control while naming somebody else's work address as the sender. Only once the sender is established does eligibility get checked: the address has to be on the one domain the service accepts, and it has to belong to an account that is active with that address verified. Being on the right domain is not enough on its own.

Nobody is turned away in silence. A sender outside the accepted domain, and a sender with no account, each get a written explanation of why the roster was not imported and what to do instead. Every reply attempt is wrapped, because on the success path the shifts are already imported and a reply that cannot be delivered must not fail the message it is answering. Failures are sorted into permanent and temporary: a roster that cannot be read is answered with a rejection that stops redelivery, while an outage on our own side is deliberately allowed to fail so the mail platform retries it later.

The intake cannot write to anybody's data on its own authority. It hands the parsed shifts to a single authenticated endpoint on the application server, which independently re-checks the domain rule and the account before storing anything. Every outcome that is not an import, including a suspected forgery, an ineligible sender, an unregistered address and an unreadable roster, is written into the application's shared audit log, so refusals are reviewable rather than invisible. Writing that record is best effort and never throws, on the principle that failing to log an outcome must not change the outcome.

Copies that are actually copies

Backups run on a schedule on the machine that serves the application, and produce a single archive holding both of its data stores, so a restore is one extraction and cannot pair one day's records with another day's database.

The two stores are captured by different means on purpose. The document tree is safe to archive directly because every write to it is atomic: written to a temporary file, flushed, then renamed, so any file read mid-backup is whole. The database is copied through the database engine's own online backup interface rather than as a file, because in write-ahead mode a plain file copy silently omits every commit since the last checkpoint. That failure has the nastiest possible shape: the copy passes an integrity check, because what it holds is internally consistent, it is just missing the most recent rows. The database is backed up at all because two of its tables exist nowhere else, the only record of who did what and the credentials that let integrations in. Everything else in it is rebuilt from the document tree on startup.

Every snapshot is proved before it is kept. It is reopened, integrity checked, and its row counts compared against the live database, and a shortfall in either irreplaceable table fails the run outright rather than quietly keeping a thin copy. The comparison allows the snapshot to be exactly one row behind on the append-only table, since a row can legitimately land while the copy is running, but never ahead of the original and never further behind.

Archives are compressed in process rather than by shelling out, because the usual tool stamps the current time into its output, which would make two archives of byte-identical content differ on every single run and defeat the comparison entirely. A run that finds nothing has changed keeps no new archive, and the comparison is made by hashing the contents before the outer archive exists, so it measures what the backup holds rather than when it ran. That is deliberate wear control: the storage this runs on fails by being written to, and the surest way to lose the data is to exhaust the card the backups also sit on. An unchanged run is still recorded as a successful run, which is what stops the staleness alarm firing at somebody whose data simply has not changed.

The outcome of every run is written down whether it worked or not, because a backup nobody can see the state of is indistinguishable from one that stopped weeks ago. A failed run alerts immediately and exits with an error, so a failure is pushed rather than waited for. The failure that matters more is a backup that simply stops, because that says nothing at all, so the running application reads the recorded state hourly and raises an alert once no run has happened for longer than it should. Those alerts are throttled to one a day per condition, which is what makes them survivable enough to leave switched on.

Copies are pulled off the machine by separate storage on the same network rather than pushed to it, so the machine holding the data holds no credentials for the place the copies go. Whether that collection actually happened is read from the operating system's own record of the collecting account signing in, not from file timestamps and not from anything the far side is trusted to write. The health readout then describes precisely what that proves and no more: the far side connected and authenticated inside the window, which is not proof the transfer finished, so it reports the copy as collected rather than verified. A collection that stops is alerted separately from a backup that stops, and that alert says plainly that copies are still being made locally, so the two problems are never confused for each other. Being unable to answer is reported as exactly that, never as healthy.

Two independent clocks are watched, because two different things can quietly stop: the backup itself, and the collection of it. Backup health is read from disk rather than held in memory, because the application does not run the backup and restarting the application must not reset what is known about it. Neither the application code nor the operating system is included: the code lives in version control and the system has its own separate clone, so the archive holds only what nothing else can reproduce. Credentials are excluded from it too and captured in their own bundle, so a data archive can be handled without also being a bundle of secrets.

A contact form worth having

This site publishes no email address anywhere, and the relay behind the contact form exists so that it never has to. A message passes through two separate processes: the site's own server validates it and writes it to durable storage, and a second service composes the mail and sends it.

The second service does not trust the first. It re-validates every field from scratch against the same bounds, on the reasoning that the shared secret could leak or the two halves could drift apart in a later change. That secret is compared in constant time, because a plain equality check returns as soon as it finds a difference, and that timing alone is enough to recover a secret one byte at a time. A request that arrives carrying a browser's origin is refused outright, because the server-to-server call that is supposed to make it never carries one. Oversized requests are refused twice, once on the declared size before a single byte is read and again on the true encoded byte count afterwards, because the declared size can lie or be absent.

Anything a visitor types is neutralised before it reaches an inbox: control characters are stripped from every value that becomes a mail header, since a line break there lets a submitter add headers of their own. The mail binding is pinned to one already-verified destination, so a bug anywhere in the payload handling cannot turn it into an open relay. The message is sent from an identity on a domain we hold, with the reply address set to the person who filled in the form, so replying from the inbox answers them directly.

Email is treated as the convenient notification and not as the system of record. Every submission is written to storage before the relay is called, and the relay call is best effort, so a delivery failure loses a notification rather than a message. A relay that is not configured says so at startup and again on every submission, because a misconfigured deploy would otherwise be indistinguishable from a working one: messages saved, visitors thanked, nothing arriving. Failing to write a submission to storage is the one failure a visitor is deliberately allowed to see, because it is better they retry than believe a message was received that nobody will ever read.

The checks that keep automated submissions out are ordered cheapest first, so anything obviously mechanical is turned away before reaching the one check that costs an outbound request. Two silent traps, a decoy field and a minimum time to fill the form, answer in exactly the same way a successful send does, because telling an automated submitter which trap it tripped is free tuition on getting past it. The timing trap convicts only on elapsed time that is not negative, because a device whose clock runs ahead is evidence of clock skew rather than of a bot, and treating it as one silently discarded real messages.

Rate limiting separates checking from spending, so somebody who fumbles a validation error twice does not burn their allowance on messages that were never accepted. The human verification step carries a limit of its own, spent whether or not the check passes, because it is the only check that makes an outbound request and it fails closed. That limit is per visitor with no sitewide counterpart on purpose, since a single shared counter would hand a distributed attacker a cheaper version of the outage the limit exists to prevent. Verification failing closed means that when the verification service cannot be reached the submission is refused and the visitor is asked to try again shortly, because accepting everything during an outage turns any outage into an open door. The whole mechanism is optional and each half fails independently, so the site runs correctly with none of it configured, and every wrong combination of keys is announced out loud at startup, because one key on its own either verifies nothing or rejects everything and neither state is ever intentional.

A rejected submission is answered with a readable page explaining which check it did not pass, rather than a wall of machine punctuation, so a visitor browsing without scripting still gets a reason and a way onward. An accepted one answers with a redirect rather than in place, so refreshing the thank-you page cannot resubmit the message and the back button does not offer to.

Serving the site itself

The site is served by a small server with no dependencies, because the process that serves the bytes is the only thing that can guarantee the security headers are on every response. Every response carries a fixed set of them, including a content policy that permits no inline or evaluated script anywhere and forbids framing the site outright. Exactly one third-party origin appears in that policy, and only for the two things the human verification widget cannot work without. Outbound connections from the page stay same-origin.

File serving works from an allow list rather than a block list: a file is served only when its extension is one the site actually publishes, so anything sensitive that lands in the tree is private by default instead of public by default. A second, explicit block list covers what an extension cannot, since the server's own source, the stored messages, the version control data and the relay's source all share extensions with things the site does publish. Directory traversal is neutralised by normalising the requested path before anything else touches it and then confirming the result still sits inside the published tree, so plain and encoded traversal both collapse to the same rejection, and decoding happens inside the error handling so a malformed escape sequence returns a not-found instead of taking the process down.

The server listens only on the machine's own loopback interface and is reachable from outside solely through a tunnel. That is what makes a visitor's address trustworthy: the address is read only when the connection came through the tunnel, and the more commonly used forwarding header is deliberately never consulted, because the edge appends to it rather than replacing it, which leaves its first entry chosen by the client even on legitimate traffic.

The only thing the server ever injects into a page is a public key and one fixed sentence of its own. Every other file, HTML included, is served as untouched bytes and is never read as text or scanned for anything. Even that key is validated against the shape a real key has before it is used, so a mistyped configuration value cannot smuggle markup into a served page.

Getting a change onto the machine

There is one released line of history and one place where edits are made. The machine that serves an application pulls and deploys; it is not a place to change code. The deploy script refuses to run from any branch other than the released one, so a stray checkout on the serving machine cannot quietly ship the wrong thing.

A release is gated on a validation step that checks syntax and catches any drift between the version number and the changelog entry meant to describe it, and the deploy refuses any version that is not strictly greater than the one already live, so a bad deploy cannot silently regress a feature. It then rebuilds the front end, restarts the service, and polls the running application until it confirms the new version is actually serving, so a deploy that did not take is caught rather than assumed.

The publicly readable version endpoint reports the version number alone. The build identity sits behind the administrator gate, because a commit reference tells an anonymous caller exactly which known issues are present. Configuration secrets are excluded from version control by design, which means a deploy never delivers a key by itself and a change that depends on one has to have it put in place first.