Quote by WannabeWordsmith
That's certainly one avenue that has been considered.
Looking around the web at various ways sites have tackled this kind of thing, the common thread is that spam always finds a way, and all we can do is slow it down or make it more annoying so they go elsewhere.
If we say you can't create groups for N weeks, they'll create an account and wait N weeks then come back.
If we say you need to make X posts before being allowed to create groups, they'll just create X one-word posts.
If we say you can't post links, they will make links like h ttps://spamsite.com which will still automatically get made into actual links (like that) or at the very least get the domain name posted in many places to attract link juice/SERPS.
If we say you must post a story, they'll scrape one off another site and push it here.
Everything quantity-based that we would try to implement would backfire in some way or piss off members who want to create an account and start sharing legit content quickly.
It'll probably come down to implementing some sensible limits - like a bunch of hurdles - but quite what they would be and how we would use them to differentiate real users Vs people who just want to spam others is difficult to gauge.
I agree on those probabilities. They can be persistent. This may be a coincidence, mostly hypothetical. Not to deter paid and potentially paying members. However, I noticed that after my paid subscription expired, I was never added again to any group messages while others still kept getting them. I was thinking that they are targetting those with an active paid subscription. I could be wrong.
As a solution, how about adding a message subfolder for 'Message Requests'? All messages from any member whom the recipient user has never interacted through Lushmail and not in the Friends and Following (excluding Followers) list will be routed there. This is how most social media and messaging platforms are currently set.
There will only be one message request notification from that sender regardless of how many messages are exchanged within that group, including succeeding one-on-one messages, until the recipient does an action, either to accept, decline or report.
You can put 'Accept', 'Decline', 'Report', 'Decline and Delete' 'Decline and Leave' and 'Decline and Block' options for the recipient. Or add checkbox suboptions for 'Delete', 'Leave', and 'Block' if the recipient declines.
If the recipient selects the 'Decline' option with no further actions, that message will stay in the 'Message Requests' folder as a read message for a maximum of two months (or less) until it autodeletes. Any option that is not 'Accept' will stop new notifications to the recipient.
In the case of massive requests, you can add an option for multiple decline and/or deletion. A checkbox before the group message sender's name will be accessible for a single, as well as an easy 'Decline/Delete All' option.
This may help to prevent if not mitigate the burden to recipients getting unwanted messages, too. More control on privacy for members, higher satisfaction.
