I wrote earlier this week on the discovery that people were blacklisting sites with email autoresponders. More thought and debate on the issue has led to a number of thoughts over how to solve the issues around autoresponders, in particular the concern that they will respond to messages with forged From addresses.

These thoughts have been laid out in this essay on practices for autoresponders which starts off by pointing to RFC3834, and goes further in a world where people might want to blacklist sites just for autoresponding.

The RFC specfies a way for an autoreponse to be reliabily identified as such. Those who are blacklisting or filtering autoresponders can use this so that if they are going to go about blacklisting a site for running an autoresponder (as is required in the SMTP spec) that they only blacklist further autoresponses, and not ordinary mail from the same server. While some blacklisters, unfortunately, have a capricious disregard for the consequences of their actions, most of them agree that they should wish to block as little legitimate, desired mail as possible, ideally zero, so techniques which can make this happen deserve their attention.

There are many other techniques outlined in my essay on challenge-response best practices which are still not followed (admittedly in a few cases even by my own code, since I never put it into public distribution.) These techniques make C/R not only workable, but I believe a must in any good anti-spam system. If somebody’s anti-spam system is going to block my mail, I want the ability to know about it and reverse that decision by proving I’m not a robot. While it is annoying to have to respond to a challenge, if the alternative is not having your mail read, most people would take the challenge — if it was really necessary. C/R systems allow systems to have no false positives, at least for non-anonymous mailers, and that should be the goal for everybody.