On Thu, Nov 29, 2012 at 06:14:23PM +0000, Julian Yon wrote:
(3) Don't bother trying to ascertain the full exit policy, but rather maintain a simple table of exit/IP/port combinations that have been rejected and consult it when building/using circuits. This requires no protocol changes (win!) at the cost of no longer blacklisting dishonest exits entirely. Some mechanism for expiring entries would probably be a good idea, and/or maybe hold it in a circular list so that there's a maximum number.
I had this same thought while rereading my earlier message: just prepend a reject rule for this ip:port to our local version of the relay's exit policy.
It does let the exit "tag" you with an IP:port combo that you'll never come back to it with. But that seems a small risk compared to the risk of an exit relay with a complex enough policy that it causes clients to spend two circuits for fetching each component of web pages.
--Roger