|
The Spam WarsRBLs & C/R (Challenge/Response systems)Contents:
SORBS is out of controlSORBS (the RBL) has become overzealous in RBLing (blocking) many legitimate IPs.
Their algorithm takes no account of the content (by their own claim) and apparently takes little of the frequency. They demand $50 to even examine an RBLd IP, but offer no guarantee of not simply blacklisting someone they do not like immediately again, no matter how innocent the triggering messages. This amounts to hardly more than extortion. SORBS response is that registration requests, vacation messages, etc. are spam. While automated emailers can send unwanted messages to innocent third parties, the net volume of such mail is much lower than the amount of incoming spam deflected because most (80-90% in my experience) spam from: addresses are completely bogus and no email to them ever reaches a real person. Thus, while the pain is transferred to someone else, the net pain to the whole internet community is reduced. Meanwhile, RBLs are weak filters. They have a high false negative rate (spam let thru) more or less by design because their unit of resolution is only an IP address. Even were spam and ham never to come from the same IP address, spammers move around their IP addresses, and RBLs are always playing catchup. Worse still, RBLs have a substantial false positive rate (ham which is blocked) for some of these reasons:
The irony is that SORBS objects to C/R systems because they are less than perfect, preferring the full assault, but they themselves are far leakier than the system they object to. Rebuttal to "Challenge-Response Anti-Spam Systems Considered Harmful"SORBS points to this website by Karsten M. Self for the rationale behind their policy. If this is SORBS rationale for RBLs, it is weak. Mr. Self's points break down as follows: 1) Some C/R systems have flawsTrue, but this is argument for fixing bad implementations, not getting rid of C/R systems. Claim 4 -'Local whitelisting is good, while C/R is bad'. This just means the C/R system should be aware of the local whitelist. EWL is. Claim 7 - 'Some C/R systems deadlock'. Yes, this is a bug in really bad implementations, but not real world ones. EWL has an explicit ringing detector. Claim 10 - 'Some C/R systems respond badly to mailing lists'. Yes, C/R systems must be conscious of mailing lists and long cc lists. 2) Bad comparison to filter systemsThese objections are of the form 'C/R systems have problems', but the same objection is even worse for filtering systems. Claim 0 - 'Spammers can easily bypass C/R system'. Not so, the chance of a spammer hitting an email address of a registered friend is quite low. In running my C/R system this never happened. Sometimes spammers will register though. Claim 1, 5 - 'C/R systems have high false positive rates'. Their false positive rate on registered senders is 0, better than filters. The C/R false positive rate on unregistered senders is the rate of friends not registering. In my experience this is very low, but regardless it is neither clearly less nor greater than the filtering false positive rate. It's likely lower than the RBL false positive rate. Also, see below on how good C/R systems minimize this failure to register rate. Claim 3 - 'C/R violates privacy by letting your ISP know you get email from' If my ISP handles my email, it already knows who I send email to and receive from. And, if instead I run my own server (as I do), then my C/R runs there and ISP stills knows nothing (short of sniffing TCP conversations, which C/R still doesn't change). 3) C/R systems fail to punish the spammersClaim 2, 11 - Yes, but so do filtering and RBL systems. This is not an objection to C/R per se. 4) Registration requests are spam tooClaim 2, 6, 9 - They all say the same thing, registration requests are spam, and C/R users should be punished for trying to use them. This is a valid objection, but not a complete one. See below 5) Theoretical problemsClaim 6 - 'C/R systems could be used for a DNS attack'. Seems like a rare thing and fairly weak attack. Claim 8 - 'C/R systems could be used as spam confirmers.' This is true only if people choose to register themselves with a spammer. If you got a registration request from someone you never sent an email to in the first place, would you register? I think not. This claim is unlikely to matter much in practice.
In defense of Challenge/Response SystemsC/R systems have high resolution. They cut the false negative (spam let thru) rate to near zero since spammers almost never register. The false positive rate (friendly email recognized as spam) for friends is also cut to near zero since the only lost email is for friends who refuse to register. See below for the problem of handling legitimate business email. The only serious criticism of C/R systems is that innocent 3rd parties are burdened with registration requests. Most (80-90% in my experience) of the return addresses that spammers use are completely bogus. Email sent to them is dead at the SMTP conversation level. Some additional percentage of those which do go thru are headed to /dev/null. Thus, even though an unwanted registration request is unwanted email, C/R systems reduce the net amount of unwanted email ever seen by a person by some large factor (maybe 5 to 1). This is a net win. RBLs are making it impossible to extract this 10 to 1 win. That is a real loss. Also, a registration request is less annoying, at least to me, than a spam. It's easier to recognize and less offensive just on its own merits. C/R systems should not be used as the only filter for incoming email. Rather they should be used as a lost resort after other techniques fail. There is a trade-off here because false positives of other filtering systems running first versus keeping registration requests low. As a practical matter, I set my spamassassin score to 10 (which is relatively high) and challenged all unregistered emails under that. That kept false positives to 0 and registration requests to a sensible fraction. Mr. Self's criticism that C/R systems are less accurate than filtering is doubly mistaken when they are used in exactly the place where other filtering systems have already failed. A good C/R system:
Auto registrationThe last two points merit some explanation. Businesses will often send from email addresses that no one ever reads, and thus they will not respond to registration requests. The deal with these cases, one approach is to such a businesses an email address of yours that auto-registers the first time you see an email to it. When that address leaks out, that alias no longer auto registers, or accepts unregistered email. For instance:
Ringing, as a featureMr. Self lists ringing as bug of C/R systems. Properly implemented, it is a feature. First, it can detected without content analysis and is thus reliable. If Alice sends Bob a registration request and Bob replies with a registration request in turn to Alice. Alice's C/R system simply notes that Bob failed to register when a registration request was expected. Alice's C/R system can now either a) just drop Bob's registration request and ignore the whole matter, b) pass it to Alice herself for consideration, or c) hold it for a few days and see if Bob ever registers. The feature part is that if a spammer injects a message to Alice from innocent third party Bob, then the two C/R systems ultimately just drop everything and no human is every bothered. If Bob had really sent Alice an email, then Bob's C/R system would already have whitelisted Alice and never have sent her a registration request. SPF + C/RThough SPF is dead for now, it is a good companion for a C/R system. The main problem with the C/R system is that innocent third parties get unwanted registration requests. SPF solves that problem. An SPF sender is either a valid correspondent or a spammer with their own SPF domain. Sending a registration request to the latter is irrelevant. Sending it to the former does not burden a third party. This should avoid spamtraps as well. One problem with this is that for people who publish an email address
publicly (e.g. a discussion forum) and invite replies (e.g. asking for help)
should not expect all who try to help to register just to reach them. EWLI wrote EWL as my own personal C/R whitelisting system. It implements all of the features listed above (the source comments in main.cpp list many others). I ran it for several years, successfully reducing a spam load of thousands per week to about 10. As of May 2006, I have surrendered the use of it because SORBS has blacklisted me. I installed the latest versions of the following Postfix recipient rules + sqlgrey + spamassassin and tuned them all, leaving me at about 100 spams per week, definitely worse than under C/R. The problems involved in running it were:
My Current Email ConfigCurrently, it is postfix + sqlgrey + spamassassin 3.1 + me own whitelister, EWL, running in a purely local mode (no registration requests are actually sent as I have surrendered to SORBS). The local whitelisting overrides any false positives from spamassassin. The registration problem is minimal because any time I email a new person they are registered. Therefore I need to manually whitelist only those incoming addresses to whom I never reply. The whitelist override guarantees that everything in inbox is from a whitelisted sender and any whitelisted sender will be seen no matter the spamassassin score. I check inbox frequently. spamlite gets checked weekly for possible new correspondents. That amount of spam which sneaks past sqlgrey and spamassassin is ignored at this time. The point is that I never tolerate spam clogging my inbox until I am ready to address it, at the cost of new correspondents possibly getting a delayed response. Current problems:
Neither sqlgrey nor spamassassin installed in any direct way on Fedora Core 4 (Red Hat) linux. I include my install notes here. Sqlgrey 1.6 config on Fedora Core 4 linux
Spamassassin 3.1.1 daemon config on Fedora Core 4 linux
|