121–130 of 188 posts
That is reasonable, but do you think you can go into more detail about your main product? What is it about, exactly?
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,
Stavros
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!
That is reasonable, but do you think you can go into more detail about your main product? What is it about, exactly?
Hello my beloved friend, 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, Stavros
*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?
Earlier quoted context omitted.
1) Yeah, there's support for multiple domains, but I have no domains right now :) If anyone wants to donate one, please open an issue! 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.
I have a few domains you could borrow? I can at the least offer you 5 domains for half a year, shoot me an email if you're interested.
https://spa.mnesty.com/ = server not found. Anyone else seeing this?
Earlier quoted context omitted.
The problem with hashcash for email is that there's no way for the sender and receiver to negotiate the amount of work to be proved, so they must correctly guess how much to perform/require. The most sensible requirement to guess is zero, since all existing email is sent without any proof of work, and the value of interoperability is higher than blocking spam. After all, if you're willing to lose interoperability, yo…
Instead of hashcash why haven't we solved the problem by just attaching real money to every email? The convention would be that you "accept" the payment only if it is spam. $1 gets you into the inbox. If it isn't spam then after 48 hours the token just expires and the sender keeps their dollar. 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.
There is one major problem : the answers are sent immediatly after receiving the email. 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!
I encourage you to file an issue at their source repo: https://gitlab.com/stavros/Spamnesty/issues
There is one major problem : the answers are sent immediatly after receiving the email. 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.
Earlier quoted context omitted.
The problem with hashcash for email is that there's no way for the sender and receiver to negotiate the amount of work to be proved, so they must correctly guess how much to perform/require. The most sensible requirement to guess is zero, since all existing email is sent without any proof of work, and the value of interoperability is higher than blocking spam. After all, if you're willing to lose interoperability, yo…
Could the work requirement be advertised as part of the destination's MX record or something? I know that in theory you're supposed to be able to send the message to your upstream server and let it worry about how to deliver, but in practice it seems like these days you can count on being able to look up the target's DNS info. Another problem is finding a quantity of work which is high enough to stop spam, but low en…
- 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.