Open Source

Where to take an issue

All issues and discussions go to one place:

github.com/serverlessinbox/serverlessinbox

That is the front-door repository, and it is the single tracker for every component. You should never have to work out which repository a problem belongs to before you can report it — a failing install, a JMAP client that cannot connect, a rendering bug in the admin UI, a documentation error: they all go there.

• Bugs and install problems — the issue tracker in that repository.
• Questions, ideas, show-and-tell — Discussions in that repository.
• Security issues — reported privately, never as a public issue. The process is described in the security policy.

What is open and what is not

Open, under Apache-2.0:

• the CDK constructs and the CloudFormation templates,
• the IDL and the SDKs generated from it,
• the admin UI,
• the JMAP server library for Go,
• this documentation.

Not open:

• the Go Lambda implementations — the entire mail data plane — which ship as pre-compiled, signed binaries,
• the webmail UI, closed for now.

The part worth noticing

The obvious reading of that split is that the interesting code is closed and the packaging is open. It is the other way around, in the way that matters for trust.

The Lambdas holding the most privileged IAM roles in a deployment are the open ones. The control-plane TypeScript Lambdas — the parts that can change infrastructure, deploy stacks, manage users, touch DNS, delete resources — ship as readable source precisely so that they can be audited. Code that can do anything an administrator can do should be code you are able to read.

The closed binaries are the mail engine. And the open CDK surrounding them is what defines, in full, what that engine is permitted to touch: every role, every policy, every table and queue and bucket it can reach. You do not have to read the engine’s source to know its blast radius, because the boundary around it is in code you can read.

For why the closed parts are signed and what that signature actually buys you, see Trust & Code Integrity.

The repositories

All under https://github.com/serverlessinbox/:

• serverlessinbox — the front door, and the tracker for all issues and discussions.
• mailbox-cdk — the CDK constructs: the infrastructure.
• mailbox-apps — ready-to-deploy apps and the CloudFormation templates.
• mailbox-idl — the JMAP JSON schemas and the admin API protobuf; the source the generated SDKs come from.
• jmap-server-go — the JMAP server library for Go.
• admin-ui — the admin frontend.
• artifact-registry — release artifact resolution.

More repositories are being opened; that work is in progress. If you follow a link above and find a repository private, that is expected and temporary, not a mistake.