Nortix Mail: A Disposable Mail Server That Skips TLS by Default

The spam problem Nortix Mail is built to absorb

Every signup form that asks for an email address creates a record you do not control. The README states the concern directly: addresses get stored, sometimes sold to advertisers, and a breach can expose your primary inbox. Nortix Mail's answer is to hand out disposable addresses instead. You run the server, you generate addresses, and you use them for sites that require verification. The intended user is someone technical enough to run Node or Docker but who does not want to administer Postfix, Dovecot and a certificate chain just to receive a few confirmation emails. The README frames the project as "like running your own Gmail server," which overstates the scope. There is no mention of sending mail, mailbox search, or multi-user accounts. What the material describes is an inbound server for temporary addresses, and that narrower framing is the honest one.

What the repository actually shows about the architecture

The stack is split in two. A Svelte frontend lives in the front directory and is compiled with npm run build. A Node process, started with node main.js, serves the built frontend and handles mail. Persistence is a data folder: the README says moving to another server means copying that folder, and configuration lives at data/config.json. Certificates, when used, are also dropped into data. That is the whole visible data flow. Mail arrives on port 25, the Node process stores it, the Svelte interface reads it back, and the refresh interval and page size are configurable. There is no database service, no message queue, and no separate worker described. For a small deployment this keeps the moving parts low, but it also means the storage layer is whatever the project implements over the filesystem, and the README does not describe its format, indexing, or concurrency behaviour.

Running it: the two documented paths

The non-Docker route is a sequence of commands. Install Node and npm, run npm install at the root, then cd front, npm install, npm run build, cd .., and finally node main.js. The README also gives a combined one-liner: npm install && cd front && npm install && npm run build && cd .. && node main.js. The HTTP server listens on port 80, and the README notes that port 25 must be reachable to receive mail. The Docker route is shorter: clone the repository and run docker compose up -d. The compose file maps 25:25 by default, and the README recommends leaving that mapping alone when a reverse proxy sits in front, because some proxies cannot forward SMTP packets. Configuration is limited to data/config.json, which the README says controls the mail refresh interval and the number of emails shown per page. Those are the only two settings named in the material. Anyone expecting relay rules, domain allowlists, or retention policies will not find them documented.

TLS is optional, and that is the central design decision

The README is unusually candid here. It says the mail transfer protocol is old and does not require TLS by default, so a server sending mail to your instance can be read by anyone positioned to intercept it, though it notes that this capability mostly sits with ISPs and hosting providers. Setting up TLS is recommended rather than required. The setup is file-based: copy a certificate and private key into data, and Nortix Mail detects which file is which, with the README stating that the file name and extension do not matter. The same automatic detection covers domain changes, so switching domains needs no extra configuration. This is the project's main convenience claim, and it is a real one for people who have fought certificate paths in mail software. The cost is that a misdetected or expired certificate is not surfaced through any documented mechanism. There is no described health check, log format, or startup validation. You would be trusting that the server picked the right file and that clients negotiate TLS, and the README gives no way to confirm either.

Where Nortix Mail is the wrong tool

Delivery is the obvious failure mode. Mail servers are judged partly on reputation, and a freshly deployed instance on a residential or cheap VPS IP will be rejected or throttled by major providers regardless of how the software is written. The README does not discuss deliverability, SPF, DKIM, DMARC, or PTR records, and none of those are optional in practice for a domain that sends or receives real mail. Port 25 is also blocked outbound by many hosting providers and ISPs, which the README does not address; it simply says the port must be accessible. Then there is the licence. The repository reports NOASSERTION, meaning no standard licence could be identified from the files. That is a genuine blocker for commercial use, for redistribution, or for anyone whose legal team needs a known licence before deployment. Finally, the project accepts no pull requests. Issues are welcome for features, bugs, and questions, but the codebase is not open to contribution, so a fix you need has to come from the maintainer or from your own fork.

How it differs from a general-purpose mail stack

The natural comparison is a conventional self-hosted stack such as Postfix with Dovecot, or a turnkey mail suite like Mailcow. Those tools are built around permanent mailboxes, outbound delivery, spam filtering, and multi-user administration. Nortix Mail inverts the priorities. It assumes addresses are temporary, that storage can be a copied folder, and that TLS is a nice-to-have rather than a baseline. The difference in approach shows up in the failure cases too: Mailcow and similar suites ship opinionated configuration for DNS records, certificates, and spam handling, while Nortix Mail ships one config file with two documented keys. If your goal is a durable inbox you will check daily, the conventional stack is the right shape. If your goal is a rotating set of addresses that receive a confirmation link and nothing else, the lighter model is defensible, provided you accept the transport risks the README itself lists.

Maintenance, upgrades, and what the licence silence costs you

There are no releases in the retrieved metadata, so upgrade paths are whatever the main branch happens to be at clone time. The README does not describe a migration process, a version scheme, or a changelog. The only stated portability mechanism is copying the data folder, which doubles as the backup story. That is convenient and fragile at once: if the storage format changes between commits, a copied folder may or may not still load, and nothing in the material says which. Because the licence cannot be determined, you also cannot assume you may modify and redistribute the code, bundle it into a product, or even rely on a warranty disclaimer. Treat the licence question as unresolved until you read the repository's own licence files directly. The maintenance burden is otherwise low by design: one Node process, one frontend build, one data directory, and a compose file. That low surface area is the project's strongest argument, and its weakest guarantee.

Editorial conclusion

Nortix Mail suits engineers who want a throwaway inbox for signups and are comfortable running a mail server without TLS on port 25. It is not for anyone who needs guaranteed delivery, encrypted transport, or a supported project with a release history. Before adopting it, verify the licence terms (the repository reports NOASSERTION), confirm port 25 is reachable from your host, and check whether the automatic certificate detection in the data folder behaves as the README describes on your setup.

Official sources

1. Issues
2. README
3. Zhoros/NortixMail on GitHub