"Vi4Gra PIllz for cheap caNAda Donald Trump's secret affair."
"Bank statement credit check cashed QUICK FREE!!!"
"You may hav virus. i help fix click here"
"running pharmasy slow now shipping Mexico"
And this script that plays what sounds like an old man losing his memory: https://www.reddit.com/r/itslenny/
These is how to use it:
Transfer, conference, or forward your telemarketing calls to 1-347-514-7296
Can't wait to try this out.
Without being able to make that distinction, it's nearly impossible to force phone software makers to write rules preventing "illegal" phone use in situations where it is illegal.
Instead, they punish using verifiable methods such as direct observation (cop sees you doing it).
The situation may be similar for recording calls (I'm not familiar with exact laws in this area), but I'm assuming there are also privacy restrictions in calling which lead to the software restrictions.
I remember once using something called HearSayApp, but it disappeared off the face of the internet without a trace. It used HTML5 to place a call, somehow. And the audio was crystal clear.
It's probably got something to do with some kind of regulations. Voice changers are fun, but not when calling 911, for example. Maybe it's a requirement that the sound goes directly to the baseband or something?
They could get around it the same way Toyota limits their liability from me using the touch screen while I drive - pop up a message saying when and how the feature should be used.
For call recording, the phone maker is potentially facilitating a felony. It's really complex. Does the phone stop recording when you cross state lines? Does it allow covert recording?
If I'm from California recording a call in DC on vacation and accidentally enter Maryland and get arrested, I'm suing the company.
Likewise, if you are in California, you can't send a text while driving, but you can enter an address into the GPS app (probably).
All Apple and Google would have to do is warn you that recording calls may be illegal.
Radio Shack sold phone recorders in every state and AFAIK, nobody ever sued them.
I have Google Voice and Google lets me record calls on that. I'm not sure what the big difference is for when the call is over Android.
Edit: There have been cell phones that had call recorders built in, just none that run Android or iOS (AFAIK). I know a lot of Motorola phones included the functionality.
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.
El cheapo bots have pretty basic English skills which can help them fit naturally into the spam target patterns.
The same logic that favours using an opening gambit that scares off all but the most unworldly of people works against using bots for the followup conversation. You don't want to finally find someone that genuinely believes that a random central African stranger might want to split $138,400,000 with them and has funds ready to send only for your bot to fail the Turing test by misunderstanding their question about how to pay the deposit.
Also, anyone smart and knowledgeable enough to be able to write bots capable of persuading exceptionally gullible people to part with their money is probably capable of moving to the next level and going after the slightly-less gullible, who are more numerous and richer.
It's also probably a bit flattering to the average scammer to assume the flaws in their patter are a deliberate filter pattern though. They're just as likely to open with a highly plausible (probably copied) offer of high value second hand goods on a listings website that probably attracts dozens or replies and then respond to each of those genuine expressions of interest from people willing and able to pay with badly-written response(s) that conflict with the detail of the original ad, not to mention totally forgetting that little old Scottish ladies don't have email addresses registered in the name of Nigerian men.
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.
I'm also little inclined towards scepticism there's much evolutionary optimization going on when the standard email scam format hasn't even adapted to get around now unbiquitous standard webmail spam filters, which are essentially orthogonal to the gullibility of the account owner.
Besides, wouldn't an evolutionary process that wasn't a conscious attempt to avoid generating false positives (or slavish copying by people that don't really analyse in much depth) tend to optimise for reusing the emails that generated more responses rather than less?
I'm acquinted with someone who does spamming for a living, mostly in the online casino segment. He does very well, and surprisingly polite company cares more about the money he has, than the way he makes it.
I hope you and your family are healthy and happy. As I have detailed in my previous correspondence, my offering to you is a way to waste spammers' time by making them reply to emails. I am sure your esteemed self would have great use for such a service. Please wire $1500 to my account for attorney's fees.
Thank you and God Bless,
*In all seriousness though (lol): You could have different types of personalities, depending on the email address of the person who doesn't want the spam. Like someone pretending mnesty.com is their work address but is still treating it like a personal message. That way the spammer will disregard the fact that the reply email isn't the same as the original.
EDIT: Nevermind, I see you said you did that already... I think. ... Help?
"Hey, I'm switching to my work email. Refresh me on the details again."
"I'll have to get back with you. Can you repost a summary?"
"I'm sorry, but your emails are hard to read. Could you format them alittle nicer. Thanks!"
"Gee, I'd love to help. It's hard to think of how, though."
It would also avoid problems with canned responses failing the Turing test.
However, you raise an interesting point: blacklists could reasonably be put into place. I'll make a merge request to use Spintax.
Someone should organize a competition to see who can create the longest running conversation (or the funniest one).
Yeah, that's an interesting aspect of it for me. I'll have to clean up the code a bit, because it's very "weekend project" quality, but it's an interesting way forward.
I always thought it interesting that no one seriously tried to replicate a tool so good at its job that spammers were actually scared.
EDIT: Cloudflare has been enabled!
If you are using the free plan, note that you aren't really getting DDoS protection. They offer "I'm under attack" mode which can be bypassed easily and it does not protect against l3 and l4 attacks.
Another idea is to send two spammers responses to each other.
Everything, even spam, is based on ROI.
Perhaps, "Hi there, I thought we were really making progress, but I haven't heard from you for a week. Is there still a chance I could get in on this great opportunity?"
1) If lots of people start using this, spammers might learn to avoid wasting time with Mnesty's CEO. Having a few more fake companies would help.
2) The bot could probably be made a lot smarter with some natural language processing. But it seems to fill its purpose pretty well already. I think this just shows how desperate for leads spammers are.
'[country] rules mean we need you fill out the attached pdf. Please complete and upload to [... IP logging website]'
EDIT: Or even just the PDF, really, I can host it on the server.
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 Also re-order the form locations, placeholders so it's nearly impossible to script automation for the page!
> - we want to give you $10,500,000.00 !!!
> - thanks, but it's out of our budget. Can you make an effort?
I can only imagine the spammer reaction :D "Wait... wat?"
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")
2) Exactly, they're so desperate for leads that they will spend lots of time chasing someone who doesn't appear to make lots of sense.
Edit: just noticed I get a chance to edit the conversation. That's pretty cool, although of course it would be even better if I didn't have to :-D
EDIT: Opened https://gitlab.com/stavros/Spamnesty/issues/7 to track this.
I have wired the funds you asked for. Could we please proceed to the next stage?
CEO, MNesty, LLC
Is that a canned response? This happens later on in the thread (does it recognise that the topic of the conversation is "funds" rather than say "product")
Each category comes with its own set of responses, but you can see where the category changed because the bot will start talking about a product and then switch to talking about funds.
The code is here if you want to see:
What surprises me is that a mail with viruses is in my mailbox (my spambox, granted). I guess it was not know it was a virus when it was received.
So it passed the Turing test?
Anyone else seeing this?
Funny thing is that most of the people who downloaded it came from Nigeria and seemed to think that it was a tool that allowed them to scam people. It was quite funny when they put their own contributions and then one of them was talking to a real scammer trying to scam him.
Had to delete the thread cause it didn't make much sense though.
Most appear to be "Web Developers". Ex: See this Conversation: http://www.mlooper.com/conversations/2912/
Is this common? Do a lot of you get spammed with Indian companies / individuals claiming to do web development? I have received a few, and the funny thing is, NONE of the ones I received even had a Web Site?! How does that work?!!
EDIT: Can you add an issue to the tracker with the forward header verbatim so I don't forget?
This is obviously suspicious, considering most of the mails require at least a few minutes of reading + time to write the mail.
I guess adding a delay would improve the bot's credibility by a lot!
And effectiveness in stealing spammers' time. If the bot immediately auto-responds to each subsequent (presumably human-initiated at this point) email, then the spammer may more easily follow the thread.
On the other hand, if the bot waits 30-90 minutes, the spammer likely has gone on to other things. There's an additional (albeit minor) cognitive load here if they want to engage with a potential sucker.
With it, you just schedule asynchronous tasks in the future ... you don't have to manage the event queue.
I encourage you to file an issue at their source repo: https://gitlab.com/stavros/Spamnesty/issues
8:46 AM - initial receipt email
The conversations linked in the subsequent receipt emails lack the spammer's email. They only contain the response from the Spamnesty bot.
Can you post the IDs of the emails you received so I can look into the issue?
In amongst the scripts to waste their time have a few to freak them out.
And thanks so much for sharing the source on GitLab to reproduce it.
Really great work!
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.
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?
Note that it may be possible to have servers negotiate an amount of work to perform, but having someone else (the server) perform the work defeats the point of the system. The client must be told to do the work, but it's a core feature of email that it's not realtime: messages can be composed offline, and queued up by servers, so by the time a "needs more work" response is received, there's no way for the server to send a message back to the client.
Another problem is finding a quantity of work which is high enough to stop spam, but low enough not to stop legitimate traffic. You want people to be able to send email from their RPiZero or original iPhone, but stop spammers who may have massive botnets, or at least decent PCs.
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.
- 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 way I did it is:
- When the user focuses in a comment field, the page makes a request to the server asking for initial parameters.
- The server returns the number of leading zeroes required, the number of distinct hashes it needs, and a salt to use. (This is just a constant in my code right now, but could be varied based on client specifics.)
- The page then crunches on the work as the user types their comment. The submit button is disabled until it's complete.
- The proof of work is submitted to the server along with the comment. The server then checks to see if it's good and accepts or rejects. A properly working client should never be rejected (since it fetches the required parameters in advance) so the rejection doesn't have to be too fancy.
- Replays are prevented by storing the salts in a database, and deleting them once they're used for a comment.
I changed the standard hashcash technique a bit by requiring the client to submit multiple distinct hashes. Requiring only one hash works fine, but results in a lot of variance in how long it takes to compute the proof of work. You might tune it for an average of 30 seconds, but a decent percentage of clients will get it in 1 second, or will take 60 seconds. By, for example, requiring 7 fewer leading zeroes but requiring 128 distinct hashes, you get the same average but with a lot less variance. You can also display a semi-accurate progress indicator this way. The downside, of course, is that you have to send more data and the server has to do some extra work to verify.
If you'd like to see it anyway, I pulled out the relevant parts here:
The comment-inline.js file is directly embedded in the HTML for the comments area, and is the glue code between the actual UI and the hashcash computation code. The hashcash.js file is where all the client-side work happens, and it handles the actual hashing, making multiple attempts, checking to see if an attempt produced a good result, and such. Then commentsubmit.py handles the server side by returning hashcash parameters when requested, and checking the provided hashcash for validity when submitting.
I have a brief blog post about it here, which you can also use to see the system in action:
If you have any questions, comments, or criticisms, please feel free to get in touch.
I assume the money transfer can be solved today using Bitcoin, and it wouldn't be a terribly complicated protocol.
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.
> You do realise that Bitcoin itself is a complicated protocol built on top of hashcash, right?
Of course, but it already exists.
> 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.
Yes, but assume there are people sending bulk email legitimately who have delivery issues. All you need is one major provider to accept it and then there is a benefit for senders. DKIM and SPF prove that the deployment problem can be overcome, even for relatively weak attacks on the spam problem.