Spam protection

[Revertron]

The yggmail is a great implementation of distributed E-mail, but with great abilities comes great responsibility.
Especially, how can we defend our mail inboxes from any malicious agent (spammer) that is able to generate a new identity every 10 milliseconds and spam a lot of messages to every known address?

This issue is more about discussion to find a decent solution to that problem.

[neilalexander]

This is indeed something I’ve been trying to think my way around and, due to the simplicity of generating new keys, I am not sure how many measures will be effective.

An obvious solution is to add allow/deny lists of remote senders, so you can either block someone who spams you from the same address or only allow mails from people you trust. The latter somewhat defeats the point of open mailing though.

Another angle here is that we don’t want remote spammers to be able to exhaust all of your available inbox/disk space, so we need to ensure we implement quotas too. Should make a separate issue for that.

[zander]

There are some older and newer ideas in that area.
Here is an older one that will likely still work (but may need updating to modern tech) https://en.wikipedia.org/wiki/Hashcash

Newer ideas are that people pay a tiny amount of money (say, half a cent) to send you a message using some crypto. Personally don't really like that one.

Another idea is that multiple yggmail instances talk to each other and sign messages every now and then to show proof-of-life and in return create some score with other yggmail nodes based on how long they have been online.
When I get an incoming connection from a peer I either look in my own DB or ask a known nearby yggmain peer (that has a good score) for a reputation statement, signed by their pubkey.
Lack of a reputation may end up your yggmail replying "you are graylisted, please try again in 15 minutes minimum".

The latter idea still is not perfect as someone can just spin up 1000 nodes in containers, so not sure if there is a full solution possible.

[Revertron]

Pardon me, please, I've worked too much with blockchain, but there is a solution. I wonder, why I didn't propose it in the first place :)
We can make a miner to mine keypairs with some number of zeroes in the start of the public key.
Then, when getting the needed key is somewhat hard, and banning that address is relatively simple, spammers will not bother to send spam :)

Even more! The number of zeroes can be some sort of spam-score. More zeroes - less the spam-score. That score is added to headers of the mail, there are a bunch of formats, we can choose one.

[errhammr]

The hash cash idea seems more flexible to me than the number of zeroes at the start of the pubkey.

The pubkey is something a genuine yggmail user does not want to change after initial setup while spammers probably want to invest some ressources in trustworthy looking keys that change once in a blue moon. So the number of zeroes at the start of the pubkey isn't adjustable at all for genuine users. This would give an advantage to spammers and a disadvantage to genuine users. Also, a spammer with a moderately beefy server can probably get "good" keys relatively easily while my Raspberry Pi will struggle to generate a "medium quality" key. Also, this only works on a per yggmail address basis, not per message.

The hashcash solution is way more flexible, while also having similar issues. At least genuine users don't have to generate a new yggmail address if spam gets out of hand. But it would be easier to adjust the difficulty for the trustworthiness score. Also, it would be on a per message basis so a user that sends a dozen messages per week wouldn't notice much of a difference while spammers sending 1000s of messages per second would probably feel an impact.

In general, imho, we should focus on a per message penalty rather than a per yggmail address penalty because the addresses are something genuine users don't want to change very often.

[Revertron]

In general, imho, we should focus on a per message penalty rather than a per yggmail address penalty

Some users want to use yggmail as a platform for Delta Chat, so they will send big amount of messages to each other every day. So, the "per message penalty" will have a big impact on those users also :(

[GRbit]

In general, imho, we should focus on a per message penalty rather than a per yggmail address penalty

Some users want to use yggmail as a platform for Delta Chat, so they will send big amount of messages to each other every day. So, the "per message penalty" will have a big impact on those users also :(

If we will make this parameter configurable, we can run mail servers for delta chat without this limit, or with an increased limit.

[Revertron]

If we will make this parameter configurable, we can run mail servers for delta chat without this limit, or with an increased limit.

So, If you are using Delta Chat, you will rise limits on your server, and rise amount of spam messages that your server receives :))