VaultSandbox is my attempt at fixing that. It's a self-hosted SMTP gateway (AGPLv3) that validates SPF, DKIM, DMARC, and rDNS on every incoming message. You keep your production email provider (Postmark, SendGrid, SES) in tests and you just change the recipient domain. No mocking, no config changes. There are client SDKs (Node, Python, Go, Java, .NET), plus a Web UI and a CLI for manual testing.
Some technical details:
Deterministic Tests Instead of polling or sleep loops, the SDKs use Server-Sent Events (SSE) so test assertions trigger the moment the mail hits the gateway.
Minimal infrastructure footprint Built with NestJS and Angular, with no external database dependency to keep the container footprint small and easier to reason about.
Post-Quantum Encryption I use ML-KEM-768 for the encryption layer. Incoming mail is encrypted immediately using a client-generated public key and the plaintext is discarded. The server only ever stores encrypted message data and cannot decrypt it. I chose PQ because I wanted to build something I wouldn't have to revisit in five years. If it handles large PQ keys reliably, everything else is easy.
Quick start: https://vaultsandbox.dev/getting-started/quickstart/
Site: https://vaultsandbox.com
I'd love feedback, especially on whether AGPLv3 would be a blocker for something you'd self-host in dev.
dspillett•1mo ago
AGPL3 shouldn't be a blocker for use with this sort of tool unless:
▪ someone is very paranoid about GPL infection (that is to say that they, or their bosses, have been taken in by some of the fear-mongering over the years)
▪ or they are intending to make the feature available as part of the their product/service (if it is a mail related/adjacent tool and they want to use this as a built-in self-test module) rather than just using it internally, in which case they might be subject to the full terms of the licence due to effectively directly linking the code.
To alay the concerns of that first group, perhaps include in you documentation a paragraph explaining that simply using it in a dev environment, with no redistribution, does not constitute linking.
If someone tells you "no one will use it commercially if you use GPL"¹, you always have the option (assuming all the code is yoursor contributors have signed over their relevant rights) of dual licencing GPL and commercial.
--------
[1] this usually means "I want to sell this with my service but don't want to pay or otherwise give back, please use a more permissive license so I can do that"
vaultsandbox•1mo ago
For now I am focusing on phase 1, which is to make it rock solid. Only after that will I start doing that part. In this phase, I wanted to listen to the community to add missing features, but apparently it will not be easy :D
Thanks for your reply.
Edit: One crucial detail I should have mentioned: while the gateway engine is AGPLv3, all the native SDKs (Node, Python, Go, Java, .NET), Frontend and CLI are MIT licensed. This ensures a clean legal boundary; your application code only ever interacts with the MIT-licensed client, which talks to the gateway over the network. This should eliminate any 'GPL infection' concerns for standard CI/CD use cases.
dspillett•4w ago
Despite there not being an issue, there are many companies, including some very significant ones, that have restrictive rules about the use of GPL software just-in-case. Some flat out have a blanket “no GPL code at all” for the libraries and such that they use. I don't know if it still stands, but Android development at Google had a “no GPL in userspace” edict. If your service becomes big, you will get people asking you to change the licence so that they can use it.
vaultsandbox•4w ago
dspillett•4w ago
I wasn't advocating for change in my previous comments, just pointing out that a fair number of people will ask for that, and why they would. IMO "we can't use it under this license because of company policy" is a them problem, not a you problem!
vaultsandbox•4w ago
I got some upvotes, but almost no feedback, negative or positive.