Tor Exit Policy Configuration - Balancing Contribution and Abuse Management

Tor's default exit policy (accept *:*) forwards traffic to any destination and any port. This maximizes network usefulness but generates the broadest range of abuse complaints. The Tor Project's recommended reduced exit policy accepts most common web and application ports while blocking ports most commonly associated with abuse:

ExitPolicy accept *:80,*:443,*:110,*:143,*:993,*:995,*:6660-6667,*:6697,*:8080,*:8443
ExitPolicy reject *:*

This policy allows HTTP, HTTPS, email (POP3, IMAP, SMTPS, IMAPS), IRC, and alternative web ports while blocking ports most associated with spam (port 25 SMTP), malware C2 (many high ports), and other abuse-generating traffic. The vast majority of legitimate Tor usage does not require ports outside this list.

The most impactful single policy decision is whether to allow port 25 (SMTP). Allowing port 25 generates massive spam complaints because spammers actively seek exit nodes with SMTP access. Blocking port 25 alone reduces abuse complaint volume by 70 to 90% with minimal impact on legitimate users, who use authenticated submission ports (465, 587) through their email provider's infrastructure rather than sending directly on port 25.

Setting up reverse DNS that identifies the IP as a Tor exit proactively reduces abuse complaint handling. Webmasters, security tools, and abuse desks that see traffic from an IP with rDNS like tor-exit-1.yourdomain.example know immediately that they are seeing Tor exit traffic. Many automated abuse systems route Tor-identified IPs to a separate handling queue or simply drop complaints entirely.

Configure rDNS through the AnubizHost control panel or by opening a support ticket. The recommended format is tor-exit-N.your-domain.tld where N is a number and your-domain.tld is a domain you control that provides a contact page with information about your Tor exit operation. This contact page is the standard recommended by the EFF and Tor Project for exit operators.

Register the ContactInfo in your torrc with a meaningful contact address. Many abuse desks send complaints to the ContactInfo email before escalating to the hosting provider. An operator who responds promptly to abuse mail with a polite explanation of Tor exit traffic typically resolves complaints without provider involvement. Responsiveness to legitimate abuse is the key to long-term exit relay operation.

Maintaining a good relationship with your hosting provider is essential for long-term exit relay operation. Before deploying an exit relay, contact the provider's abuse team proactively and explain what a Tor exit relay is, what kinds of abuse complaints they may receive, and how you will respond to them. This advance communication prevents surprised and reactive account suspensions.

AnubizHost is familiar with Tor exit relay operations and has handled exit relay customers. When running an exit relay on AnubizHost, include a note in your account records that the VPS is a Tor exit relay and provide a brief explanation of Tor for reference by support staff who may see abuse complaints. This context prevents well-intentioned but uninformed support staff from taking immediate action on complaints.

Maintain a polite, prepared abuse response template. Responding to each complaint with a copy-paste explanation of Tor's nature and the EFF Tor Legal FAQ reference demonstrates good faith and typically satisfies complainants who did not understand they were contacting a Tor operator. Track complaints by type to identify patterns - a sudden spike in specific complaint types may indicate a misconfiguration in your exit policy.