I've often thought that it would be nice to come up with something which submitted plausibible but fake information to the forms on spammers' websites. This would be done slowly so as not to DoS the server, but the steady trickle of nonsense replies would hopefully mean that the spammer couldn't tell the real ones from the fakes.
This is only effective where the spammer is offering to send something by surface mail: if they're just taking things to the next stage via email, they can presumably weed out the fakes that way at little cost to themselves.
MX records tell you which machines receive mail for a domain. They tell you nothing about who may send mail from that domain. It's perfectly legitimate to have different machines for these functions, and many large senders of mail do so.
Much of the concern about the increasing number of cameras in the UK is because they enable Them (the government, law enforcement) to watch Us (ordinary folk). Cheap and ubiquitous cameras in the hands of ordinary citizens are a good thing, or at least, as David Brin argues, they are better than the other alternative.
The author would have been better off hanging out on
news.admin.net-abuse.email for a bit before going public with this. Here
are some problems I spotted on a quick scan through:
RBL is a trademark of MAPS. The generic term is DNSBL.
It looks like his entire netblock is blacklisted because it blocks
relay tests by null routing the osirusoft.com tester. Given the
controversy over relay testing, it is reasonable for him or his ISP to
block such tests. It is also reasonable for an open relay blacklist to
list for it.
The article fails to clearly distinguish between open relay/proxy
blacklists (which are largely automatic) and blacklists and blacklists
based on harbouring spammers (which will always have a human in the loop
somewhere). It seems the author himself is confused about this.
I doubt it's true that most admins who use RBLs "assume they are
blocking only spam". Any use of filtering by a large organisation should
only be done after examination of the consequences.
The section headed "Network Effects and the Unscalable Nature of
RBLs" has nothing to do with scalability as I understand the term. A
DNSBL scales as well as the DNS itself. The increased use of DNSBLs
could be argued to increase their effectiveness, since it puts pressure
on irresponsible admins to fix their problems.
My understanding of the more reasonable blacklists (the SBL, and to
some extent, SPEWS) is that they only widen a listing to include
"collateral damage" after the ISP has failed to respond to complaints.
It is the responsibility of the ISP to have a working abuse@ address and
to read what is send to it. For open relay lists, there is no
"collateral damage" since the IP listed is an open relay, exactly as
claimed by the list operator.
The "geopolitical" section is just nonsense. The blackholes.us
operators provide lists of IPs by country so that people who know they
do not expect legitimate email from a particular place can block that
place. They do not advocate that the entire Internet shuns Korea,
say. An business with Korean customers clearly would not use that list.
The example banner on the open relay can only form a contract if the
spammer sees it and agrees to it. The Sherman Antitrust Act is of no
consequence to the ORDB operators in Denmark, to SPEWS in Irkutsk, nor
to me in the UK.
The section on Distributed Notification Systems should probably
mention the Distributed Checksum Clearinghouse, since that, to my mind,
does away with some of the problems of Razor.
Neither. A contract requires consideration (something of value exchanged) and the intention to form a contract on both sides. I'm not a lawyer, but both your banners rely on the person connecting actually seeing the banner. The odds are that they won't.
Well - adding negotiation to the current infrastructure will exacerbate what is in my opinion the worst aspect of spam: the amount of bandwidth it consumes
The point of a hashcash scheme is that it is easy for the recipient to check that the cash is good, but hard for the sender to form cash. The bandwidth required for such a check is minute compared to the amount currently consumed by spam.
IM2000 does have an impact on spam filtering: it is more reliable for an ISP to prevent its users spamming by scanning its hard drives, than it is to intercept their outgoing traffic (especially if the spammer does not use the ISP's SMTP server).
You assume that the spammer uses their ISP's mailserver. There's nothing stopping the spammers sending notifications from their own machines and making the messages available for collection from there. You're also assuming that the ISP cares. Some don't.
Perhaps even some chain system for trusted servers could be set up so that your mail client would tell you if some waiting mail was from an unauthorised source.
I've suggested something like this in the past (in the context of spam reporting, but I see your idea as the opposite: not-spam reporting, if you like). I was rightly put in my place: Vernon Schryver wrote that:
My claim is that [the web of trust idea] makes sense only while there are very few trusted people. For a large number of people reporting spam, it confounds the cryptographic notion of "trust" with the non-technical notion. Remember the words in the PGP FAQ or documentation
about the web of trust saying absolutely nothing about whether the owner of a key is trustworthy.
The rest of the thread is a useful read: Vernon is a clever chap.
The folks over at Camram (the hashcash people) are trying to work out how to bodge hashcash negotiation onto the existing mail system. It sounds like it's a pain to get right.
If we had a new, shiny, protocol designed so that there was some negotiation before the message was collected by the receiver, the hashcash payment could go in at that stage. People who don't pay don't get their messages collected.
Sending emails back to spammers is for brainless cretins - it serves only to clutter up your mail queue and risks offending innocent impersonated senders or having your email address confirmed as valid for spam.
Not just that: recently there's been a situation where someone decided to "test" their TMDA-like filter using postings to news.admin.net-abuse.sightings (in this case, the thing sends back an email containing a link which you must visit to release the mail). Unfortunately, the confirmation email concerned went back to a spamtrap address owned by me, and hence the text of confirmation email is now marked as spam by both the DCC and Razor (that's a fuzzy match, too, so this so-called spam protection system is now useless for reaching people protected by either Razor or the DCC until the listing decays). As long as spammers keep forging From addresses to one of the addresses on their list, by using something like TMDA you risk sending mail back to an address which will promptly blacklist either your IP or the message body.
Some people are stupid enough to buy stuff advertised in spam. With such a low cost to sending email, it only takes a few. Especially when what you're "selling" is something like a Nigerian 419 scam, where you'll be taking the idiots for thousands of $currency.
Cloudmark is the commercial end of Vipul's Razor, which you can get working on Unix.
For various reasons, I prefer the Distributed Checksum Clearinghouse (DCC) over Razor: I've written a HOWTO on getting the DCC working on a home Debian system (Exim/fetchmail). It catches a lot of spam.
If I put "newarchitectmag spam" into Google groups, I find this thread, where the article is demolished by various people who know vastly more about open relays than the author of the article (or, for that matter, Slashdot editors).
There's no excuse for failing to do even the most basic research before posting an article. Still, nice work if you can get it, I suppose.
Most people will still be faster with any sort of keyboard.
It's not intended as a competitor to a keyboard, though. On the web page I read that "Dasher is a competitive text-entry system wherever a full-size keyboard cannot be used".
There are faster search algorithms than the obvious linear search. The creator of nilsimsa suggested one, and I implemented it to see how fast it was. I found it would be workable for a DCC-like system holding on to 2 million digest codes at a time, handling about 3 million messages a day. The server would need about half a gig of physical memory to retain the entire database in memory. Since a Razor system only holds spam digests rather than the digests of all mail, I imagine it'd be OK for that, too.
I BSD-ified my example code so if anyone wants to use it, feel free.
I've seen that too. I think they're doing this to break up the phrases SpamAssasin uses, rather than as a hashbuster. It'd be easy to strip out HTML before doing the comparison, although I'm not aware of any system which does that at present.
The web page says there's some sort of trust system built into it. Vipul said on the Razor list a while back that they were going closed source on the server side code to prevent people from working out how to defeat the trust system. The web page goes on about how you score for reporting real spam, but does not go into detail about how the system decides what is real spam.
It would be interesting to see how the system coped with:
Multiple IPs all reporting popular mailing lists as spam (open proxies would be good for this, the spammers already know where to find them).
Someone getting very trusted and then reporting popular mailing lists as spam. It's easy to get trusted: just post to one of those MLM webboards and report everything you get on your posting address as spam. How long will it take your reputation to decay when you mess up?
Some mailing lists are badly run. They don't confirm requests to join the list. So some people will be getting spam from these lists. But some people will be getting mail they requested.
I'm sceptical that the trust system could resist a determined assault.
I make the same point to Vernon Schryver, who wrote the DCC, which is also based on distributing message digests. His reply was that the DCC has been around for ages and not one spammer has had the brains to do this (and that people who believe that what they are doing is not spam will not do it, since it is a tacit admission that they're attempting to evade filters). Maybe the DCC just isn't popular enough either.
I've seen mention of systems which use "ephemeral signatures", that is, they change which part of the message they use for the signature from time to time. This makes it hard to write spamware which defeats the system. That would be an option if mutating the message became popular.
The latest stuff I'm seeing from the Camram (Campaign for Real Mail) website suggests that a hash would be necessary for initial contact, but that after that people would verify each other by using keys exchanged in the initial contact.
This means that if you're running a mailing list, the initial signup procedure (where you confirm that the address you've been given really did want to sign up, by sending them back an email) will do the key exchange, so after that you're only doing some crypto rather than a hashcash calculation. Still more expensive than conventional email, but not deliberately expensive.
For an example of a cryptosystem which works in this way, see Herbivore
Guess what? I'm not SPEWS either. None of us are. Move along now...
My customer is told that he has to talk to his ISP about getting rid of spammers (which should be SPEWS job, IMHO) or move his network.
It is believed that SPEWS sends complaints about the spam it receives, just as anyone else would. So the ISP is told about the spammers. They just don't know who is telling them. Think of SPEWS as the Egon Ronay guide to mailservers.
What SPEWS is not interested in doing is saying "hey, we're SPEWS, kick your spammer off". I surmise that they are doing this becuase an ISP ought to be listening to ordinary complaints, and because they have no wish to get sued.
I'd like someone to put together a nice enviroment for beginning programmers. Base it on Python and gtk, so
it's portable between Windows and Unix. Use Glade so people can start off drawing what they want their
program to look like, then write bits of Python to make it work. Throw in a really good canvas widget, so it's
easy to start drawing things and get things moving on the screen without worrying about expose events and
redraws. Then write the book "Learn to program with Python", that takes beginners who've only ever used
computers before by the hand and leads them through the delights of making them do your bidding.
We've done something a bit like this. It's based on Tk rather than gtk, but other than that it's more or less what you want: a simple canvas to draw on and a bunch of worksheets for beginners to programming. It was done for LiveWires, a Christian computer camp. You can get our old (1999) stuff here. We did some extra things for the 2000 holiday this summer which we've not released yet. They'll be released under a BSD-ish licence soon: I'm in the middle of writing a mail to our webmaster to get him to put them up. Keep watching the LiveWires site or mail me if you can't wait for us to sort it out.
Slashdot Mirror
I've often thought that it would be nice to come up with something which submitted plausibible but fake information to the forms on spammers' websites. This would be done slowly so as not to DoS the server, but the steady trickle of nonsense replies would hopefully mean that the spammer couldn't tell the real ones from the fakes.
This is only effective where the spammer is offering to send something by surface mail: if they're just taking things to the next stage via email, they can presumably weed out the fakes that way at little cost to themselves.
MX records tell you which machines receive mail for a domain. They tell you nothing about who may send mail from that domain. It's perfectly legitimate to have different machines for these functions, and many large senders of mail do so.
Much of the concern about the increasing number of cameras in the UK is because they enable Them (the government, law enforcement) to watch Us (ordinary folk). Cheap and ubiquitous cameras in the hands of ordinary citizens are a good thing, or at least, as David Brin argues, they are better than the other alternative.
Neither. A contract requires consideration (something of value exchanged) and the intention to form a contract on both sides. I'm not a lawyer, but both your banners rely on the person connecting actually seeing the banner. The odds are that they won't.
The point of a hashcash scheme is that it is easy for the recipient to check that the cash is good, but hard for the sender to form cash. The bandwidth required for such a check is minute compared to the amount currently consumed by spam.
IM2000 does have an impact on spam filtering: it is more reliable for an ISP to prevent its users spamming by scanning its hard drives, than it is to intercept their outgoing traffic (especially if the spammer does not use the ISP's SMTP server).
You assume that the spammer uses their ISP's mailserver. There's nothing stopping the spammers sending notifications from their own machines and making the messages available for collection from there. You're also assuming that the ISP cares. Some don't.
Perhaps even some chain system for trusted servers could be set up so that your mail client would tell you if some waiting mail was from an unauthorised source.
I've suggested something like this in the past (in the context of spam reporting, but I see your idea as the opposite: not-spam reporting, if you like). I was rightly put in my place: Vernon Schryver wrote that:
The rest of the thread is a useful read: Vernon is a clever chap.
The folks over at Camram (the hashcash people) are trying to work out how to bodge hashcash negotiation onto the existing mail system. It sounds like it's a pain to get right.
If we had a new, shiny, protocol designed so that there was some negotiation before the message was collected by the receiver, the hashcash payment could go in at that stage. People who don't pay don't get their messages collected.
It's been done. You want the Distributed Checksum Clearinghouse.
Sending emails back to spammers is for brainless cretins - it serves only to clutter up your mail queue and risks offending innocent impersonated senders or having your email address confirmed as valid for spam.
Not just that: recently there's been a situation where someone decided to "test" their TMDA-like filter using postings to news.admin.net-abuse.sightings (in this case, the thing sends back an email containing a link which you must visit to release the mail). Unfortunately, the confirmation email concerned went back to a spamtrap address owned by me, and hence the text of confirmation email is now marked as spam by both the DCC and Razor (that's a fuzzy match, too, so this so-called spam protection system is now useless for reaching people protected by either Razor or the DCC until the listing decays). As long as spammers keep forging From addresses to one of the addresses on their list, by using something like TMDA you risk sending mail back to an address which will promptly blacklist either your IP or the message body.
Google has the story of this occurrence.
Some people are stupid enough to buy stuff advertised in spam. With such a low cost to sending email, it only takes a few. Especially when what you're "selling" is something like a Nigerian 419 scam, where you'll be taking the idiots for thousands of $currency.
Cloudmark is the commercial end of Vipul's Razor, which you can get working on Unix.
For various reasons, I prefer the Distributed Checksum Clearinghouse (DCC) over Razor: I've written a HOWTO on getting the DCC working on a home Debian system (Exim/fetchmail). It catches a lot of spam.
There's no excuse for failing to do even the most basic research before posting an article. Still, nice work if you can get it, I suppose.
The original poster clearly referred to full size keyboards. Since he's been using them for 15 years it's doubtful he meant to refer to PDAs.
It's not intended as a competitor to a keyboard, though. On the web page I read that "Dasher is a competitive text-entry system wherever a full-size keyboard cannot be used".
I BSD-ified my example code so if anyone wants to use it, feel free.
SpamPal
I've seen that too. I think they're doing this to break up the phrases SpamAssasin uses, rather than as a hashbuster. It'd be easy to strip out HTML before doing the comparison, although I'm not aware of any system which does that at present.
It would be interesting to see how the system coped with:
I'm sceptical that the trust system could resist a determined assault.
I make the same point to Vernon Schryver, who wrote the DCC, which is also based on distributing message digests. His reply was that the DCC has been around for ages and not one spammer has had the brains to do this (and that people who believe that what they are doing is not spam will not do it, since it is a tacit admission that they're attempting to evade filters). Maybe the DCC just isn't popular enough either.
I've seen mention of systems which use "ephemeral signatures", that is, they change which part of the message they use for the signature from time to time. This makes it hard to write spamware which defeats the system. That would be an option if mutating the message became popular.
This means that if you're running a mailing list, the initial signup procedure (where you confirm that the address you've been given really did want to sign up, by sending them back an email) will do the key exchange, so after that you're only doing some crypto rather than a hashcash calculation. Still more expensive than conventional email, but not deliberately expensive.
For an example of a cryptosystem which works in this way, see Herbivore
My customer is told that he has to talk to his ISP about getting rid of spammers (which should be SPEWS job, IMHO) or move his network.
It is believed that SPEWS sends complaints about the spam it receives, just as anyone else would. So the ISP is told about the spammers. They just don't know who is telling them. Think of SPEWS as the Egon Ronay guide to mailservers.
What SPEWS is not interested in doing is saying "hey, we're SPEWS, kick your spammer off". I surmise that they are doing this becuase an ISP ought to be listening to ordinary complaints, and because they have no wish to get sued.
I don't know about Somalia, but it seems the US is still ignoring the Geneva Convention when it suits it to do so. At least a few are speaking out.
I get loads of spam from China, or advertising Chinese websites.
Looks like sending the postmaster a note congratulating him on joining the Falun Gong might work well.
Spam is Free Speaaech (A Troll)
No more government regulation (aynrand666) All problems have a technical solution. Just hit delete.I know more than you do (karmawhore23) I am cleverer than you.
We've done something a bit like this. It's based on Tk rather than gtk, but other than that it's more or less what you want: a simple canvas to draw on and a bunch of worksheets for beginners to programming. It was done for LiveWires, a Christian computer camp. You can get our old (1999) stuff here. We did some extra things for the 2000 holiday this summer which we've not released yet. They'll be released under a BSD-ish licence soon: I'm in the middle of writing a mail to our webmaster to get him to put them up. Keep watching the LiveWires site or mail me if you can't wait for us to sort it out.