kellan - the problem with SpamCop's resolution system is that it's targetted at ensuring people like you - actually running a legit list - can get a problem resolved.

If you check the requirements for resolving a "wasn't a spam" complaint, they expect you to show that you have a legitimate opt-in trail. But in Felten's case, he wasn't running a list, nor did he claim to run a list, nor did he even accidentally run a list. As a result, he doesn't have - nor should he be expected to have - the needed documentation.

SpamCops approach reminds me of "papers please?" "Hmm" "Your papers are not in order...". Or,
more to the point, guilty until proven innocent.

Interestingly, SpamCops own guidelines on the the DNS blacklist (what I assume we are discussing here) state
"This blocking list is somewhat experimental and should not be used in a production environment where legitimate email must be delivered." They further indicate that a "tag only"
mode is preferable. That suggests that a remote ISP may
be partly at fault for using SpamCop in a way that wasn't intended.

The other part of the problem here isn't really SpamCop -
it's Felten's ISP who implemented take down without actually
receiving a reasonable notice.

I use SpamAssassin, and find that there will always be some
legitimate email that gets tarred this way. Erik is on target when he points out that economics are the root of the problem - and we may end up paying by packet just to make the problem go away. or - better yet - how about paying by port 25 open attempts, with the first 500 free?