Show HN: Spamnesty: Waste spammers' time

Have recommended before and recommend again the book 'Getting to Yes', and Harvard's very open research and sharing in this area: http://www.pon.harvard.edu/

Getting too serious? Not at all. Harvard's role-plays that can be purchased very cheaply ($1-3 per copy) are great teamwork activities.

They tend to focus on numerical amounts denominated in dollars, but these financial numbers can be easily substituted for time, number of people, anything that's a number. Practicing new concepts with things you're immediately familiar with tends to lead to remembered solutions. Instead save the comparison and application to the postmortem.

EDIT: Added.

It doesn't have to be deliberate. It probably evolved. If worse spelling and grammar work better than correct spelling and grammar, then even if no spammer ever consciously says "Ah, I need to make this crappier", the spams will evolve to be crappy.

Moreover, while our brains in this discussion are taking cognitive shortcuts and putting spams on a "correct <-> crappy" single dimensional continuum, the reality is probably even more complicated, and it's actually specific crappiness that works better than others. For instance, I could hypothesize that it's not just typos, but typos that the recipient plausibly believe are the result of a non-native speaker from the relevant country. (I say "plausibly believe" rather than whether the non-native English is truly representative of the relevant country, because that's what matters.) That's an obvious possibility; more subtle things are possible and probably even likely. And again, the spams will evolve into those more subtle possibilities and exploit them even if no individual participant is sitting there and trying to deliberately figure out the best spams to send... which is, obviously, almost certainly untrue as well. And whoever is sitting down to write The Perfect Spam is probably doing so with a lot more data and a lot less scruples than you or I would apply to the problem.

I've often thought one of our best anti-spam defenses is the sheer mailbox stuffing quantity of them. Even the best crafted spam about how I won the lottery I never entered looks a lot less plausible the thousandth time I receive it.

EDIT: Opened https://gitlab.com/stavros/Spamnesty/issues/7 to track this.

Make it count how many times they've attempted. Every-time clear random fields and randomise fields to make auto-filling neigh-on impossible.

EDIT: Or even just the PDF, really, I can host it on the server.

EDIT : oh, I also removed the private key from url param before posting it here.

EDIT 2 : typo in my initial message: by "followed", I meant "forwarded" (in french, we say "faire suivre", which translates word by word to "make follow")

The stereotypical 419 scam, however, has some "plausible" reason why the main transfer has to wait on a smaller transfer in the other direction.

Wait, you want me to type in my username and password into your computer, and then you can take any amount of money from my account, and all everyone needs to do is trust each other?

A lot of those "make $$$ working from home!" things are scams like this. They'll offer you, say, $1,000 for a small amount of work. On payday, they'll send you a $1,500 check, along with some excuse for why it's too high, and ask you to send them the extra $500. A couple of weeks later their check bounces, and you're screwed.

Another technique is to just ask you for help transferring money. They might send you $4,000, tell you to keep $500 to compensate for your time, and send $3,500 to their friend/partner/subsidiary outside the country. Then the $4,000 evaporates. This one is especially clever since the original scheme was probably some form of money laundering or other financial crime, so the victim will usually be reluctant to go to the authorities afterwards.

- Give a 402 reponse if hashcash isn't included or isn't enough, with a link to a price URL

- GETting a price URL may return different values depending on identifying information like IP address, user agent, etc.

- Prices can be adjusted based on server load, whether we recognise this agent as malicious or benevolent, etc.

- Different types of request can have different prices, e.g. GETting a specific resource could be cheaper than searching or performing some expensive computation.

There would also need to be a mechanism to avoid replays, which would make things slightly less RESTful. I haven't thought of anything more useful here than an increasing request ID.

The frustrating part is that only the good guys would follow such a scheme. As long as there's a fallback available, no matter how deprecated, spammers will use it to avoid such payment schemes.

I suppose it could be used as a strong signal for spam filters, in addition to other security/authentication schemes which have been adopted.

> Another problem is finding a quantity of work which is high enough to stop spam, but low enough not to stop legitimate traffic.

Yes, this is another problem which negotiation could alleviate. These days there would also be the option of offloading the actual email sending to a service (either run on your own server, or "in the cloud"). Of course this just shifts the problem, but at least such services can provide arbitrary APIs, and hence can restrict their hashcash power to authenticated users, or require users to provide proof of work in a way which can be negotiated down, e.g. by building up a reputation over time.

Not sure how botsnets can be tackled, but raising the amount of effort even a small amount would hopefully make a lot of spam-based scams unprofitable. I'm sure the problem would just shift then, e.g. to using the botnets for more DDoS attacks or other more lucrative schemes.

This is exactly the same problem faced by hashcash, just wrapped up in more layers of complication. If emails require a $1 attachment to get into your inbox, you will receive no emails, since nobody is currently sending any emails with $1 attached. Just rewrite my above comment, but replace "hashcash" with "dollars".

> I assume the money transfer can be solved today using Bitcoin, and it wouldn't be a terribly complicated protocol.

You do realise that Bitcoin itself is a complicated protocol built on top of hashcash, right? Keypairs, blockchains, mining, etc. is just adding unnecessary complexity to this problem; not to mention your choice of the US dollar as the denomination, which requires an exchange rate, etc.