The NNCPNET email network

Running a modern mail server is a complicated business. In part, this complication is caused by the series of incrementally developed practices designed to combat the huge flood of spam that dominates modern email communication. An unfortunate side effect is that it prevents people from running their own mail servers, concentrating people on a few big providers. NNCPNET is a suite of software written by John Goerzen based on the node-to-node copy (NNCP) protocol that aims to make running one's own mail servers as easy as it once was. While the default configurations communicates only with other NNCPNET servers, there is a public relay that connects the system to the broader internet mail ecosystem.

NNCP

NNCP is a spiritual successor to the unix-to-unix copy protocol (UUCP) in the same way that SSH is a spiritual successor to rsh. Sergey Matveev created the project to be an easier to use, more secure replacement for UUCP. Like its predecessor, NNCP is both a (relatively simple) protocol, and a suite of reusable single-purpose command-line tools. The project's code is licensed under the GPLv3.

As with early computer networks, routing in NNCP is manual. In order to contact a host, the user needs to explicitly tell NNCP what routes are available to connect to it. In modern parlance, that makes it a friend-to-friend network, where each computer connects only to computers that the owner knows about and trusts. This makes it impossible to tell exactly how many people are using NNCP, because there's no network-wide consensus on membership. Routes may also be indirect: if two servers aren't directly connected, but they both know how to reach some third server, they can be configured to talk to each other via the third server. This avoids the need for explicit bang paths in each email, but is still a form of manual routing. In practice, many users likely have a connection to the quux.org server operated by Goerzen for this purpose.

That server publishes a list of all of the nodes that it knows about (by making the file available via NNCP file requests). Being added to the list is a manual process that requires sending Goerzen an email. This is reflective of the back-to-basics ethos of the NNCP network: the tools focus only on the core job of sending data where they're told, leaving decisions about the network's structure and policies up to the human administrators.

Messages in NNCP take the form of encrypted packets that can be exchanged via the internet, shared storage, or pretty much any other kind of connection. The tools have built-in support for exchanging data at specified times, so that bulk traffic can be sent when a network is not otherwise being used. NNCP is a store-and-forward network, so it directly supports nodes with intermittent connections, such as an air-gapped computer that uses a removable storage device to send messages to other computers. When a message needs to be sent via another node as a relay, the payload is wrapped in layered encryption, so that each node along the configured route removes a layer. This makes it harder for an outside observer to tell the difference between a message destined for a specific server, and one that is merely being relayed through it.

In addition to the at-rest encryption used on messages awaiting delivery, connections between nodes that operate over the internet are also encrypted, to further disguise message metadata. Two separate keypairs, one for the at-rest encryption and one for the in-transit encryption, are generated when the node is initialized using the nncp-cfgnew command. The public part of these keypairs needs to be communicated to every other server that it will communicate with. Keys aren't expired or rotated automatically — users wishing to rotate their keys will need to do so by hand.

NNCP's flexibility is both a blessing and a curse; on the one hand, it follows the Unix philosophy of letting the user compose their own special-purpose tools to do things that the developers didn't anticipate. On the other hand, it makes setting up a node to participate in the network a manual (and potentially error-prone) process. Goerzen wrote NNCPNET as an automated way to set up an NNCP node for the common case of handling email, and as a way to introduce people to NNCP.

NNCPNET

When I asked Goerzen about his motivation for working on NNCPNET, he said: "I want people today to be able to enjoy networking and the Internet the way I did in 1998". Goerzen started running his own mail server around that time:

For 24 years since 1995, I ran my own mail server for complete.org, on various hosted VPSs and even once a dedicated box at the house of a friend with fast Internet. In 2019, I gave it up, because it was just too difficult. SPF, DKIM, DMARC, TLS, getting blacklisted by email providers due to issues outside my control, etc.

When he stopped, he needed some way for his various servers to send him basic cron emails — he couldn't even use SMTP because of provider restrictions. Luckily, email was once transported via UUCP, and support for that mode of operation still exists in a lot of mail servers. So, he realized that all that was really needed was to write some supporting software to let mail servers connect via NNCP as well; that effort became NNCPNET.

NNCPNET takes the form of a docker container with NNCP, Exim, Dovecot, and a handful of other utilities installed. Setup is mostly automated, with a few things left for the user to do that are described in the documentation. The container has a cron job that is responsible for periodically downloading the list of nodes that quux.org is aware of and adding NNCP routes for them that go via quux, for example, but getting registered on the list is still manual. Configuring everything without docker is definitely possible, since all the individual pieces of software are packaged separately, but Goerzen has not written instructions for that.

Once set up and running, NNCPNET acts as a normal email server for normal email clients. Unlike email running over the internet, however, NNCPNET uses the fact that NNCP messages are end-to-end encrypted and signed in order to validate the sender of each message. That, plus the friend-to-friend nature of the network, is supposed to strongly discourage spam. There is also a public relay that can optionally be used to connect NNCPNET addresses to the open internet, which Goerzen politely asks people not to abuse.

Emails within NNCPNET all end in ".nncpnet.org"; for example, the test robot that can be used to validate one's email setup is "testrobot@mail.quux.nncpnet.org". Generally, the local part of the email ("testrobot") is completely up to the user; the domain part will start with their chosen NNCP node name, which is ultimately limited by whatever they can get other people to put in their configuration files. Sending an email from one NNCPNET address to another NNCPNET address works like this:

1. The user's mail client submits mail to Exim running in the NNCPNET container (locally or via SMTP).
2. An Exim script extracts the NNCP name of the destination host (e.g. "mail.quux") and passes the email off to the appropriate NNCP command.
3. NNCP prepares a message with the email in it, possibly with several layers of encryption of the packet needs to be relayed through multiple hops.
4. That message sits in the NNCP spool directory until something sends it to the next hop in some way — via scheduled connection, sneakernet, or otherwise.
5. Any intermediate hops receive the message, strip a layer of encryption off of it, and sort it into the appropriate outgoing spool.
6. Eventually, the destination NNCPNET server receives the message, decrypts it, and checks that the sending address has the same host as the NNCP signature.
7. Then it ingests the email as normal, and the recipient eventually fetches it with their mail client.

Sending email between the open internet and NNCPNET is fairly similar, except that the destination host on the NNCP side is Goerzen's bridge. He does have plans to remove that single point of failure: "NNCP itself is decentralized and I would like NNCPNET to be as well. I have put some thought to that already." The bottleneck is "more interested contributors". The project doesn't take much day-to-day attention, Goerzen said, but his time is still limited.

Overall, NNCPNET is not really in a state for non-technical users, but typical LWN readers should not have a problem setting it up, perhaps as a weekend project. The documentation is fairly thorough, but I did run into two problems in getting my setup working: a problem with systemd inside the docker container expecting to have access to the host system's control-group hierarchy, and needing to fiddle with the NNCP configuration in order to do local testing with multiple nodes. That said, setting up an email server with NNCPNET is definitely possible. I asked Goerzen what he wanted people to take away from trying out the project. He replied:

You can run your own mail server again. A real one, not a toy. You can build email networks. They can be limited to NNCP only, or full participants on the Internet. Your phone can be a mail server and run a mailing list. You don't need an email provider for everything: just run it yourself. Your scanner with its "scan to email" function can work and do just that, without having to have a complex workaround because many modern email accounts require OAUTH and such.

NNCPNET is, at the moment, fairly small. The quux nodelist contains 16 entries — two of which are for quux itself, one of which is for Goerzen's personal email host, and one of which I set up for testing. So the number of people actively using the network is likely to be somewhere around a dozen. Whether NNCPNET eventually picks up more users, or remains a niche alternative remains to be seen.