Tor Exit Relay Policy Optimization: Utility vs Abuse Management

The ExitPolicy directive in torrc controls which destinations exit traffic can reach. Default exit policy: ExitPolicy reject *:25 (block SMTP to prevent spam), ExitPolicy reject *:119 (NNTP), ExitPolicy reject *:135-139 (Windows NetBIOS), ExitPolicy reject private:* (block connections to RFC 1918 private addresses), ExitPolicy accept *:* (allow everything else). Each rule is evaluated top-down - first match wins. You can add additional reject rules before the final accept to restrict specific destinations. ExitPolicy reject *:* at the end makes the relay non-exit (relay only, no exit function). Most abuse comes from specific ports - rejecting those ports while allowing the rest maintains utility while reducing abuse vectors.

Operators who cannot accept a full exit policy but want to contribute exit capacity can use a reduced exit policy. Tor Project recommends the 'reduced exit policy' which allows common ports (80, 443, IMAP, POP, SMTP port 587, SSH, DNS) while rejecting abuse-prone ports. torrc for reduced exit: ExitPolicy accept *:80,ExitPolicy accept *:443,ExitPolicy accept *:587,ExitPolicy accept *:993,ExitPolicy accept *:995,ExitPolicy accept *:22,ExitPolicy accept *:53,ExitPolicy reject *:*. This allows web browsing (80/443), email submission (587), IMAP/POP over SSL (993/995), SSH (22), and DNS (53). This reduced policy serves the majority of legitimate Tor use cases while rejecting the ports most commonly abused for spam and scanning.

Exit relay operators receive abuse complaints because their exit IP appears in server logs for all traffic that exits through them. Handling procedure: maintain a template response explaining that the IP is a Tor exit relay, you have no logs of which user's traffic caused the complaint, and you operate under the Tor Project's exit relay guidelines. The Tor Project provides template DMCA and abuse responses on their website. Post a standard abuse response in your server's WHOIS record (set the abuse email in your ARIN/RIPE/APNIC record to an automated response or a dedicated contact). Use the Tor Project's ExitRelay WHOIS information practice - register your relay in the Tor Exit Relay Registry so abuse handlers can verify your exit status.

Exit relay IPs appear on DNS blocklists (DNSBLs) because spam and attacks exit through them. This causes collateral blocking: legitimate services may refuse connections from exit IPs. The Tor Project maintains a DNSBL (exitlist.torproject.org) for Tor exit IPs used by operators who want to block Tor exits. Many email servers, gaming platforms, and anti-fraud services block known exit IPs. As an exit operator: use dedicated IPs for your exit relay that are not used for other services you operate. Reputation management is difficult - IPs that have been exit relays acquire DNSBL entries quickly. If switching an IP from exit to non-exit (or vice versa), allow time for DNSBL records to expire.

The legal environment for exit relay operators varies by jurisdiction. US: Computer Fraud and Abuse Act (CFAA) does not criminalize running an exit relay per current interpretations. Multiple US courts and legal opinions have supported exit relay operation as a legitimate activity. EU: varies by member state. Germany has a complex legal history with exit operators (some operators have faced legal actions that were ultimately resolved, and Germany has significant relay infrastructure). Iceland: strong press freedom and limited legal risk for relay operators. Switzerland: strong privacy laws. The EFF's Legal FAQ for Tor Relay Operators is a valuable resource regardless of jurisdiction. Consulting local counsel before operating a high-bandwidth exit in jurisdictions with unclear legal status is advisable.