Anonymous Email Server as Tor Hidden Service: Setup and Operations

A hidden service email system routes email access (IMAP/POP3 and SMTP submission) through Tor onion addresses. Users access their email using email clients configured with Tor SOCKS5 proxy, connecting to the .onion IMAP and SMTP endpoints. The email server itself handles delivery - outbound email to clearnet recipients routes through the server's clearnet IP (or through a clearnet SMTP relay), so the email itself carries the server's information rather than the user's real IP. Inbound email from clearnet arrives at the server's clearnet MX address. The anonymization protects user access to the mailbox, not the delivery path of emails to clearnet recipients.

Install Postfix (MTA for sending/receiving) and Dovecot (IMAP/POP3 server for client access). Configure Postfix's main.cf for your mail domain. Configure Dovecot with IMAPS (port 993) and SMTPS submission (port 587) listening on localhost. In torrc, configure HiddenService entries pointing to localhost:993 and localhost:587. Generate a Let's Encrypt certificate for the email domain (even though access is over .onion, TLS encrypts communication between Tor and the mail server processes). Client configuration: mail client IMAP settings point to the .onion address with SOCKS5 proxy to Tor. This setup requires a clearnet-accessible domain for email delivery (MX records) but hides user access metadata.

The weakest point in an anonymous email system is account creation. If account registration requires verification that links to real identity (phone number, credit card), anonymization of access is irrelevant. Design registration to require no identifying information: username and password only (no phone, no recovery email, no real name). CAPTCHA on registration prevents automated account creation without requiring identity. Issue accounts with clear terms (abuse results in account suspension, no appeals process needed for obvious abuse). Some providers make registration invite-only (existing users invite new users) to control growth and maintain quality without requiring identity.

Outbound emails to clearnet recipients carry the server's IP address in mail headers. The sending server's IP appears in Received: headers, identifying the email as originating from your server. This is a known limitation - hiding the server's IP from email headers requires additional techniques (routing through Tor itself, which some clearnet mail servers reject) or accepting that the server IP is visible in sent mail headers. For internal email (from one user of the hidden service to another), all email stays within the hidden service and no clearnet IPs are involved. For external email, advise users that outbound email headers identify the sending server location.

Operating an anonymous email service creates responsibility for abuse prevention. Anonymous email is attractive to spammers. Implement: IP reputation checking for inbound email (reject from known spam sources), rate limiting of outbound email per account (prevent individual accounts from sending high volumes), content filtering for obvious spam patterns, and clear abuse reporting mechanisms. Outbound email from anonymous servers may face deliverability challenges (recipient mail servers may reject or filter based on reputation). Using established outbound email relay services while maintaining anonymous inbound access provides better deliverability at the cost of letting the relay service see outbound email content.