Adding anti-SPAM and abuse protection to the Phantom Remailer is the focus of my most recent commits. I created the Phantom Remailer for personal use, but when you release a piece of software to a wider audience it becomes your responsibility to ensure it is secure and robust.
The Phantom Remailer uses the Reply-To header to encode necessary meta information about the sender — while this information was encoded it was not authenticated. The design of the Phantom Remailer does not rely on storing any information about the sender or recipient on the server running the remailer so it was vulnerable to attack by crafting compatible To headers in messages addressed to the remailer.
The To header was encoded as:
box+anonymize.<encoded to>.<encoded from>@domain
This permitted anyone to forged messages through the remailer if they created an appropriately formatted To header.
The fix for this flaw is to use SHA+HMAC to sign the Reply-To header and then validate the To header in messages processed by the remailer.
The new format of the To header is:
box+anonymize.<encoded from>.<signature> @domain
The signature is generated by hashing the from address with a secret key that is defined in the configuration file. This makes the signature repeatable and therefore you can compare the signatures that are embedded in the To header with signatures that are generated within the remailer. Then the 2 signatures are compared to check if the from address is authentic.
This approach avoids encryption and does not require storing any information about the sender or recipient on the server running the remailer, but it is a secure way of assuring authenticity.
The next challenge to solve is allowing anonymous users to send outgoing emails through the remailer, rather than replying to messages which originated from the remailer. My solution is to add a secret token that senders can use to effectively relay messages through the remailer without requiring some form of login and password.
To originate messages through the remailer the To address should look like this:
box+<token>.box_at_domain@domain
The recipient address is encoded in one of 2 ways: URL encoding to replace @ with %40 or by replacing @ with _at_ in the phonetic manner you see in various places on the Internet.
The <token> is a shared secret that only users know, such as a word like automobile. This model can be expanded to have a unique token for each address associated with the remailer by expanding the record format in the address alias database. For now I plan to just implement a static token defined in the configuration file, the per-user token could be added later.
These changes to the Phantom Remailer should make it much more robust to attack and abuse.
