Existing software, reconnected
Run your mail server. Reach it from Thunderbird through Daemonet.
This lab keeps mailbox access and message submission on an authenticated Daemonet path, while ordinary Internet mail still enters and leaves through an explicit public SMTP edge. Thunderbird is the client—not the server—and 1Man is never the mailbox or message path.
Email is a public federation. Daemonet can keep client access, administration, and the origin path private; it cannot make messages sent through ordinary SMTP anonymous, end-to-end encrypted, or invisible to the servers that receive and deliver them. Use OpenPGP or S/MIME separately when message-level end-to-end encryption is required.
Architecture
Keep public mail transfer and private mailbox access as different planes.
Use one Ubuntu server first. Expose only Postfix TCP 25 to the Internet. Bind IMAPS 993 and authenticated submission 587 to the Daemonet/WireGuard side. After the workflow is proven, move the public SMTP role to a small edge node without moving the mailbox.
Prerequisites
Prepare the parts email cannot pretend away.
A test domain or subdomain
Start away from your primary address. You need authority to publish MX, SPF, DKIM, DMARC, and later MTA-STS records.
A stable public IP
Your provider must permit inbound and outbound TCP 25 and allow reverse DNS. Many consumer and cloud networks block mail.
An owner profile
The server and every Thunderbird device must be current approved members with a working direct WireGuard path.
Separate TLS identities
Use public WebPKI for the public SMTP name and a profile-issued certificate for each exact private .daemonet service name.
Queues, abuse, and monitoring
Plan rate limits, spam and malware handling, blocklists, alerting, disk limits, log retention, and an incident contact.
A restore you have tested
Back up mailboxes, configuration, DKIM keys, TLS material, account data, and queue policy. A backup is not evidence until restored cleanly.
Mail reputation and delivery failures are slow to unwind. Prove the complete send, receive, queue, revoke, outage, and restore lifecycle on a disposable test domain first.
Ubuntu mail host
Install the ordinary mail stack, then narrow its listeners.
This lab uses Postfix for SMTP and Dovecot for IMAP. Their official documentation remains authoritative for account storage, SASL, delivery, TLS syntax, and distro-version differences; Daemonet changes reachability and authorization around them, not their protocols.
# Ubuntu Server: install the minimum starter components
sudo apt update
sudo apt install postfix dovecot-imapd
# Inspect every TCP listener before changing firewall policy
sudo ss -lntp
# Validate native configuration before a restart
sudo postfix check
sudo doveconf -n25/tcp SMTP transferPublic interfaceReceive for owned domains only; queue safely; never authenticate end-user submission here.993/tcp IMAPSDaemonet/WireGuard address onlyImmediate TLS; valid private service certificate; Dovecot account authentication.587/tcp submissionDaemonet/WireGuard address onlyRequire STARTTLS and SASL authentication; allow relay only after successful authentication.- Set the exact mail hostname and owned destination domains.
- Reject unauthenticated relay to non-owned domains.
- Separate port 25 transfer from authenticated port 587 submission.
- Set queue limits, recipient validation, rate limits, and abuse handling.
- Choose Maildir or another deliberately backed-up mailbox format.
- Require TLS and disable unencrypted remote authentication.
- Bind the IMAPS listener to the exact Daemonet address.
- Keep the mailbox password or client certificate separate from Daemonet identity.
- Do not reuse the public edge key as the Daemonet service identity by accident.
- Commit the exact private service SPKI in the signed service manifest.
- Keep private keys root-readable only where the mail daemon requires them.
- Fail on a name, chain, or key mismatch; do not click through exceptions.
Daemonet membership proves an authorized transport peer. It does not log that peer into Dovecot and does not authorize Postfix to relay mail. Keep TLS plus IMAP/SMTP application authentication enabled.
Daemonet services
Publish two private services—not one broad network exception.
Complete Daemonet setup and invite the mail host and Thunderbird device into the same owner-approved profile. Verify the direct tunnel first. Then use the local manager’s profile service workflow for each exact listener.
mailbox.home.daemonet
- Protocol
- TCP
- Port
- 993
- Host
- mail server member
- TLS
- profile leaf + committed SPKI
- Purpose
- Thunderbird IMAPS
submission.home.daemonet
- Protocol
- TCP
- Port
- 587
- Host
- mail server member
- TLS
- profile leaf + committed SPKI
- Purpose
- authenticated outbound submission
- Approve the host and client
Use separate fresh passkey ceremonies. A transport handshake alone does not grant service access.
- Create exact source egress and destination ingress
The Thunderbird device grants only TCP 993 and 587 to the mail host; the host exports only those ports to that current member.
- Generate the TLS key on the mail host
Create a P-256 key and CSR for the exact service name. Commit its SPKI in the service manifest before installing a leaf certificate.
- Approve and publish each private service
The owner signs name, host, WireGuard address, port, SPKI, and access mode. DNS discovery still does not grant network access.
- Install trust manually in this alpha lab
The repository has owner-side profile CA issuance, but automated remote CSR delivery, rotation, and desktop trust-store enrollment remain future work. Move only the CSR and issued certificate through an already authenticated local channel, and import the profile CA deliberately.
network_policy for the first Thunderbird lab.An identity_pass can hide DNS and the service port until a short destination-issued pass exists, but Thunderbird cannot request that pass itself. Use it later for bounded admin or gated access unless the Daemonet manager is intentionally maintaining the current pass.
Public mail DNS
Publish only what Internet mail delivery actually needs.
Private .daemonet records are for authorized clients. Public senders do not use them. Public DNS must point the domain’s mail flow at the deliberately exposed SMTP edge.
example.com. MX 10 mail.example.com.Names the public SMTP edge. Never point MX at a private .daemonet name.
mail.example.com. A 203.0.113.20Maps the public edge to its stable public address.
203.0.113.20 → mail.example.com.Set reverse DNS with the IP provider and keep forward/reverse identity coherent.
example.com. TXT "v=spf1 mx -all"Authorize actual outbound sources. This is an example, not a value to copy if other senders exist.
selector._domainkey.example.com. TXT "v=DKIM1; …"Publish the public key matching the mail server’s protected signing key.
_dmarc.example.com. TXT "v=DMARC1; p=none; …"Begin in monitored mode, inspect current reports and alignment, then tighten deliberately.
SPF must include every legitimate sender; DKIM requires real key generation and rotation; current DMARC policy and reporting behavior must be reviewed; MTA-STS needs a valid public certificate and HTTPS policy host. A typo can reject legitimate mail.
Thunderbird
Point the client at the private names and keep offline custody enabled.
On an already authorized Daemonet device, open Thunderbird’s account setup from the application menu and add an existing email account. Automatic discovery will not know these private names, so choose manual configuration.
mailbox.home.daemonetsubmission.home.daemonet993587- Verify Daemonet first
Resolve both private names and confirm the exact source egress and destination ingress grants are active.
- Install the profile CA before account creation
Confirm its fingerprint out of band. Do not accept a one-off certificate exception for the mail server.
- Choose manual configuration
Use the exact table above, then run Thunderbird’s re-test and inspect the resolved settings before selecting Done.
- Enable offline synchronization intentionally
Thunderbird can retain local IMAP copies for offline use. Protect the device with full-disk encryption and include the profile in backup policy.
- Send to yourself before sending outward
Prove local delivery, Sent-folder behavior, IMAP resync, and submission authentication before testing Internet reputation.
WireGuard authenticates the approved peer path. TLS authenticates the exact mail service. Thunderbird should reject a certificate for a different host or a leaf whose key no longer matches the service manifest.
Acceptance and failure tests
Prove the mail still works—and prove revoked access dies.
# From an authorized Daemonet client
openssl s_client \
-connect mailbox.home.daemonet:993 \
-servername mailbox.home.daemonet \
-verify_return_error
openssl s_client -starttls smtp \
-connect submission.home.daemonet:587 \
-servername submission.home.daemonet \
-verify_return_errorMail flow
- Local account → local account
- External sender → owned domain
- Owned domain → external recipient
- Temporary remote failure → queue → eventual delivery
Private service
- Authorized client resolves both names
- Unauthorized device gets no route or answer
- Wrong TLS key fails closed
- Wrong mailbox credentials fail
Hostile workflows
- Ethernet ↔ Wi-Fi
- Hotspot and network change
- Suspend and resume
- Router, Tor, and daemon restart
Removal
- Revoke client service grant
- Prove DNS and ports disappear
- Revoke profile member
- Prove existing sessions terminate
Portal independence
- Stop the UI/control portal
- Keep established direct mail access
- Record visible coordination failures
- Never fall back to public IMAP
Clean restore
- Restore mailbox and indexes
- Restore DKIM/TLS/config safely
- Rejoin an authorized client
- Verify old revoked keys remain dead
Thunderbird sends and receives over the exact private route; port 25 alone remains public; the portal is outside established message traffic; a revoked device loses resolution and service reachability; and a clean restore preserves mail without reviving removed authority.
Advanced topology
Move public SMTP to a tiny edge without moving the mailbox.
After the one-host lab is reliable, place Postfix’s Internet-facing transfer role on a stable public node. Keep Dovecot, mailbox storage, submission, administrative services, search, and backups on the owner-controlled private host.
The edge validates recipients, applies abuse controls, queues safely, and relays only for owned domains over an authenticated Daemonet path.
The private submission service authenticates the user. The edge accepts only the exact authenticated internal relay and signs outbound mail as configured.
- Stable IP, port 25, PTR, public TLS, DKIM policy, queues, rate limits, and monitored disk.
- A narrowly scoped Daemonet identity and exact path to the private delivery service.
- No IMAP, mailbox storage, private admin UI, or broad profile access.
- Accept edge delivery only from the exact current edge member and port.
- Keep Thunderbird IMAPS and submission available only to authorized clients.
- Retain the authoritative mailbox, backups, and restore procedure.
- The public edge necessarily observes SMTP envelope metadata.
- If it terminates SMTP TLS, it can process message plaintext at that endpoint.
- Daemonet protects the edge-to-host path; it does not make ordinary SMTP zero knowledge.
A minimal queueing gateway and a full always-on mail node have different custody, spam, storage, recovery, and support duties. Daemon Mail remains an application research track until that operational boundary is chosen and proven.
Implementation truth
What this lab can use now—and what remains manual or future.
Primary references
Use current upstream documentation for the mail stack.
This guide defines the Daemonet composition. These primary sources define the current client, server, and Internet mail behavior.
The pattern is the product insight
Keep the open application. Replace the connective captivity.
The same approach can wrap file platforms, media servers, source forges, document tools, and business applications: the software remains open, its host remains yours, and Daemonet supplies a bounded relationship between authorized devices and services.