Swiped from the 'BitTorrent complaint' thread over on relays...

If an exit relay then drops that connection silently, Tor (and the user) cannot know it needs to select a different exit. The connections simply fail. ... What you do with that iptables rule (or similar rules) is block a bunch of URLs.

There may be room to take and work this capability further...

Instead of populating the directory with the actual exit policies, offload this into a client poll of a set of live exits the client wishes to queuing up for rotation into for common ports, or even ports it's recently seen in use. Plus a general random poll to ensure N number of exits are held that will be able to service the full matrix of 65536 ports M-times redundantly, sortof like tor_exitlist.py function. Then like Tor transparent proxy to the host's packet filter, there can be a way the exit can read, API, or be fed the host's current rules to then be polled for it by the client. Plus an expected ruleset lite/timeout value. Users of custom policies would need to use separate rule tables, interfaces, or be smart about about any sensitive rule data if they care. Directories would still carry all exits. But only predefined policies efficiently marked by an 8 bit label. 0) non-exit 1) fully open 2) pollme 3) reduced 4) std set A 5) std set B, etc. Client releases hold the policy label map, including revoked and reserved label definitions. Or the map can be held in realtime dht or alikes.