Weblog entry #57 for Steve
See all weblog entries made by Steve.
Unless you are my partner, my family, or my boss I utterly refuse to "click here to confirm your email address".
Challenge / Response anti-spam software sucks. Yes I'm talking about you www.spamarrest.com!
I've half a mind to mailbomb somebody every single time I encounter it.
Comments on this Entry
[ Send Message | View todsah's Scratchpad ]
What exactly are your objections against a challenge/response system?
[ Parent | Reply to this comment ]
[ Send Message | View Steve's Scratchpad | View Weblogs ]
Here is just one list of objections.
I can see that they are very seductive and appealing to the user who implements them - but they almost always have something wrong with them when it comes to mailing lists, sending messages to the wrong person, etc.
Google has more lists, and critiques and they are mostly phrased better than I could manage.
I've nothing against whitelisting on your side, but the automatic bounced messages with links to click on? Bad.
[ Parent | Reply to this comment ]
I experimented with C/R once, but I have to agree with its opponents, it is very good at stopping spam, but you'd be surprised how many people won't respond to the challenge. and you have to make exceptions for automated systems. Fiddly and messy.
The primary objection is it sends email (perhaps not a lot) to people who didn't ask for it, and who didn't send you any, because their address was forged. Chances are they are going to be deluged, and it isn't nice to contribute to this unnecessarily. (C/R also makes email more complex to use - this is perhaps arguably worse than the spurious challenges.)
The way to avoid this is to kill unwanted email during the SMTP transaction, as most blacklisting systems, and greylisting do, and as other spam filters can (if implemented at the appropriate point in the system).
The earlier you kill email in the SMTP process the less resource that is expended on it as well. Some of the big email site recommend queuing and then post processing, as this allows handling higher peaks of email throughput, but for most organisations (upto 10,000's of mail boxes) this simply isn't required with modern hardware.
Filtering spam after you've completed the SMTP transaction is bordering on the foolish if you ask me, you have no good choice what to do with the suspected spam.
a) emailing the purported sender is abusive because it is probably faked.
b) sending it to its destination doesn't save anything.
c) leaving it in a spam folder (or deleting it) just means any false positives will be lost to the world.
C/R is just a variation of (a).
Obviously the smart email admin will try and avoid this situation arising in the first place.
[ Parent | Reply to this comment ]