I wrote a CR filter for my OS/2 mail server in 2002. It was increadibly effective but I took it offline to prevent the challanges from being classed as spam.

But I do want to explain some of the reailty of C/R as a spam threat. First off most forged spam e-mails we get are non-existing e-mails. They do not go to a single user. Secondly my (and I assume other) C/R programs will only send one C/R to any email address a week. Since spam addressed are 99% repeated that cuts C/R responces down way farther (even for us getting tens of thousands of spam a day). This does not include a whitelist (auto built from your users SMTP sending)and bayesian filter wich catches most spam before it even hits CR.

The problem is if you have a huge comercial spammer (debatable) who can hit enough C/Rs they can flood an account with a lot of C/R responces. Thus the argument by blacklists is all C/R's should be treated as so better than the original spammer.

Here is the thing. Pulling back from the knee jerk reaction for easy management. If a huge spammer is spamming THAT many addresses with a forged e-mail the forged users account is going to get flooded to beyond belief with flames and angery responces anyways making C/R the least of that account's problems.

Solution: If it was possible for this idea to come forward (without being blacklisted for even suggesting it). I think one solution would be to "standardize" for what is concidered a acceptable C/R responce. Example:

C/R: should start the subject line.
The message must be text and be no larger than 512 bytes. Only one link mail or e-mail in the message and it must go to the same domain as the sending SMTP mail server.

Reasoning: The C/R subject would allow mailers (just as bayesian preforms test emails now) to flag for testing C/R emails (even limit # recieved in X time). This format would work and be too restrictive for most spammers. However it would require the adoption of standards .

Another idea I have been kicking around (which would be easier to implement into existing systems) would be to set up a volunteer C/R server (similar in idea to the blacklists). Only legit registered servers could relay C/R through our server. Our server would then apply the "tests above" to each C/R. No more than 5 C/R's would ever be sent to one e-mail address in an hour. A delay to a ISP's message queue (time to delay queue after so many C/Rs sent at once) based on ISP size to prevent a hacked ISP from spamming (before being caught).

This server model could be distributed via a server farm or participating servers (DNS (round robin) and MX).

I feel this method would give ISP's a "safe source to whitelist" for C/Rs, prevent any abusive volume of mail from C/Rs, and safe guard spammers from abusing the system.