[members-discuss] Technical Solution to resolve the global "Email Spam" problem

a centralized solution ... Yikes!

Next step permits for email, only to be approved by government 
officials? For spam review purposes all emails must be stored centrally? 
Certainly no abuse will ever happen.



On 4/26/20 7:50 PM, Matthias Brumm wrote:
>
> Hi!
>
>
> To understand correctly. You want to enforce, that every subscribe 
> operation / e-mail client operation (get new email from server) in the 
> world will make a bidirectional communication with a central server? 
> Do you have an ellaborated guess, how much computing power that would 
> need?
>
>
> Matthias
>
>
> Am 26.04.20 um 18:05 schrieb Elad Cohen:
>> Hello Everyone,
>>
>> I want to share with you my technical solution to resolve the global 
>> world "Email Spam" problem and in addition it will also resolve the 
>> spreading of illegal links (phishing/malware/etc , once the sites are 
>> known) through electronic mail and will stop email spoofing (that 
>> part using current technologies).
>>
>> Email spam problem was not being able to be defeated since the 
>> beginning of electronic mail, as long as email spam will be 
>> profitable to email spammers - it will exist, email spam caused the 
>> illegal anonymous organization "The Spamhaus Project" to exist, "The 
>> Spamhaus Project" is hurting and damaging many businesses worldwide 
>> in their way to fight email spam, "The Spamhaus Project" is an 
>> illegal anonymous organization according to the following 
>> presentation that they wrote on themselves, they are violating laws 
>> in their way to fight email spam and still they don't win in the 
>> battle against email spam. "The Spamhaus Project" is keeping their 
>> anonymity because they are afriad of justified lawsuits due to their 
>> criminal actions in their way to fight email spam. The following 
>> technical solution will resolve the world email spam problem without 
>> to hurt and to damage many businesses worldwide that have nothing to 
>> do with email spam like "The Spamhaus Project" does, the following 
>> implementation can remove the need for an illegal anonymous 
>> organization such as "The Spamhaus Project".
>>
>>
>> The presentation that the illegal anonymous organization "The 
>> Spamhaus Project" wrote on themselves:
>> https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Violation
>>
>>
>>
>> The Implementation:
>>
>> There will be a site (lets call it NoSpam.org) - the site will be 
>> owned by the 5 RIRs, the site will use bgp anycast and will be 
>> deployed in each of the 5 RIRs (the site will also be able to be 
>> deployed by the ccTLD registries in each country), the site in all 
>> the locations will be synced automatically.
>>
>> Each domain owner will be able to register at the site (an email 
>> message will be sent to the domain owner email address in the domain 
>> name WHOIS details in order to verify that the domain owner is the 
>> one registering).
>>
>> After being logged in, a domain owner will be able to add his email 
>> addresses (of the specific domain name) that will be used to send 
>> newsletters / mailing lists / one-to-many email messages, lets call 
>> these kind of email addresses as 'mailing list' email addresses. The 
>> domain owner will not be able to see the list of 'mailing list' email 
>> addresses that he added - because when he added each 'mailing list' 
>> email address it will be saved with hash in the NoSpam.org backend 
>> infrastructure (due to privacy and security reasons) - hence only if 
>> the domain owner will manually type the 'mailing list' email address 
>> he will be able to enter it in order to manage it (to see the total 
>> number of subscribers email addresses, to see the subscribers email 
>> addresses but only with their hashes due to security and privacy 
>> reasons, to remove a subscriber from the list, to add a sub-user with 
>> permissions to manage that specific 'mailing list' email address).
>>
>> In his site, the domain owner will be able to integrate an iframe 
>> from NoSpam.org (or to connect to NoSpam.org with ajax) regarding a 
>> subscriber registration form to his specific 'mailing list' email 
>> address, the subscriber will receive an email message with a link to 
>> confirm his subscription.
>>
>> The domain owner will need to create a callback file in his website, 
>> for example in the path: "/nospam-notification-callback" 
>> (http://example.com/nospam-notification-callback) - that url will 
>> receive encrypted post notifications (encryption key will be provided 
>> by the domain owner in his NoSpam.org logged in account) from 
>> NoSpam.org regarding any new end-user that will subscribe or that 
>> will unsubscribe from a 'mailing address' email address which is 
>> related to the domain of the domain owner (unsubscribe functionality 
>> by the user later below).
>>
>> The subscriber email address and that 'mailing list' email address 
>> (that was subscribed to) will be sent by NoSpam.org to 
>> "/nospam-notification-callback" not in the hashed format but in 
>> cleartext (so the domain owner will be able to save it in his system 
>> for future email messages from the specific 'mailing list' email 
>> address to the specific subscriber email address).
>>
>> The domain owner will also have an API to NoSpam.org backend 
>> infrastructure in order to remove a specific subscriber email address 
>> from a specific 'mailing list' email address (the domains owner will 
>> send the values through the API - hashed).
>>
>> The domain owner will also provide a web interface in his site for 
>> the end-user to remove himself from the specific 'mailing list' email 
>> address.
>>
>>
>>
>> The above is the backend implementation (no upgrade is needed to any 
>> email server in the internet), the following is the upgrade that will 
>> needed for any email client (that upgrade is not mandatory, without 
>> the following upgrade the email client will work exactly as it is now 
>> without the added no-spam features, electronic mail will not break if 
>> some email users will upgrade their email clients and some will not):
>>
>> - There will not be 'mark as spam' button, that kind of functionality 
>> will stop to exist because spam is not a boolean value, 'spam' to one 
>> person is valuable to another 'person', specially when the internet 
>> is global and different people from different countries will consider 
>> spam content differently. One user can consider an email message as 
>> spam and another user can consider the same message as not spam, 
>> 'Spam' is subjective and any kind of 'mark as spam' functionality is 
>> useless in the battle against email spam.
>>
>> - There will be blacklists and whitelists (just like there are now, 
>> but they will be more prominent): blacklist email addresses , 
>> blacklist domains , whitelist email addresses , whitelist domains.
>>
>> - The end-user should be able to easily enter each email message to 
>> whitelist or to blacklist (meaning the 'from' email address of the 
>> email message), and will be able to search in the 'Spam' folder 
>> easily for an email address (these features can exist today, but they 
>> should be given more visibility, so end-users will use them more).
>>
>> - The end-user will be able to import/export his whitelists and 
>> blacklists using an xml format to any other upgraded email client, 
>> the blacklists and whitelists will be local (end-user will be able to 
>> pass the local whitelists and blacklists to another email client of 
>> his with the click of a button in the upgraded email client - the 
>> upgraded email client will just send them to itself - without to 
>> download them from the email server so the end-user will be able to 
>> download it with another upgraded email client - or the end-user will 
>> be able to send the whitelists and blacklists to another email 
>> address of him, the usage will not be like sending regular email 
>> message with attachments - the upgraded email clients will take care 
>> to sending and receiving of the blacklists and whitelits - in the 
>> background, these are custom formatted email messages that the two 
>> upgraded email clients will know how to act upon them).
>>
>> - The email client will be able to display with GUI with buttons any 
>> 'mailing-list registration confirmation email' in a specific section 
>> related to registration to new 'mailing list' email addresses for the 
>> end-user to choose with buttons if he accept or refuse to register to 
>> a specific 'mailing list' email address.
>>
>> - For any email message that was received: in case a received 'from' 
>> email address was found in the whitelist email addresses or in the 
>> whitelist domains - then it will be moved to the 'Inbox' folder, in 
>> case the 'from' email address of the email message was found in the 
>> blacklist email addresses or in the blacklist domains - then the 
>> email message will be moved to the 'Trash' folder.
>>
>> - In case the 'from' email address or domain was not found in the 
>> whitelists and in the blacklists, then the upgraded email client will 
>> send the 'from' email address and the 'from' domain and the current 
>> user email address and the external links that exist in the email 
>> message (but all of these data will be sent in a hashed way, and not 
>> in cleartext) with a query to NoSpam.org backend infrastructure, 
>> NoSpam.org will perform the following algorithem after it:
>>
>> - If the hashed 'from' domain (or any other 'hashed' domain from the 
>> external links) exist in a list of criminals hashed domains (of 
>> phishing/malware/viruses/etc) then NoSpam.org will respond to the 
>> email client to delete the email message, otherwise the hashed 'from' 
>> email address will be checked against a list of hashed 'mailing list' 
>> email addresses - if found then the sender is a 'mailing list' email 
>> address and there will be a check by NoSpam.org backend 
>> infrastructure if the hashed 'receiver' email address is a subscriber 
>> of that specific 'mailing list' email address , if the hashed 
>> 'receiver' was found then NoSpam.org will send a response to the 
>> email client that the email message can be displayed in the 'Inbox' 
>> folder and in the response NoSpam.org will also include an 
>> unsubscribe key - the email client will be able to display an 
>> unsubscribe button to the email client and if clicked the email 
>> client will send an https request to NoSpam.org with the specific 
>> unsubscribe key, NoSpam.org backend infrastructure will remove the 
>> end-user email address from the 'mailing list' email address and will 
>> notify the domain owner at the domain owner callback url 
>> "/nospam-notification-callback" that the specific user unsubscribed. 
>> In case the hashed 'receiver' wasn't found then NoSpam.org will 
>> respond to the email client to delete the email message and 
>> NoSpam.org will also notify the callback url of the related domain 
>> owner that he shouldn't send email messages from the specific 
>> 'mailing  list' email address to the specific subscriber email address.
>>
>> - In case when NoSpam.org backend infrastructure searched the hashed 
>> 'from' email address and it wasn't found in the list of all hashed 
>> 'mailing list' email addresses, it mean that the email address was 
>> sent from a 'personal' email address and NoSpam.org backend 
>> infrastructure will notify the email client that the email message is 
>> from a 'personal' email address - the email client in that stage will 
>> need to decide if to move the email message to the 'Inbox' folder or 
>> to the 'Spam' folder based on the following - the email client will 
>> check if the email message include links/images/plain-url's - and if 
>> yes then the email message will be moved to the 'Spam' folder, 
>> otherwise it will be moved to the 'Inbox' folder.
>>
>>
>>
>>
>> Whitelist Handshake:
>>
>> - In order to facilitate the adding of new email address to the local 
>> whitelist, a process of 'Whitelist Handshake' exist , a 'Whitelist 
>> Handshake' is a GUI representation in two email clients regarding 
>> background email messages between them (that the two end-users don't 
>> see), "end-user A" with a click of a button will be able to send 'add 
>> me to whitelist' request to "end-user B" which will be able to accept 
>> or deny and if accepted then "end-user B" will be able to 
>> automatically send the same "add me to whitelist" request to 
>> "end-user A" , all of this communication will be done behind the 
>> scenes, these special email messages will not be visible to the 
>> end-users, end-users will see popups with GUI that email address X is 
>> asking to be added to whitelist. In order for spammers not to abuse 
>> this option - the email client will keep only one 'whitelist request' 
>> from each requester email address (there will be a 'whitelist 
>> requests' section in the upgraded email client). A repeated 
>> 'whitelist request' that came from a specific email address can never 
>> be raised in the list (unless the end-user will specifically search 
>> for it) even when the sender will send more and more 'add me to 
>> whitelist' requests - no priority will given to them, and once an 
>> end-user refused an 'add me to whitelist' request - no new 'add me to 
>> whitelist' request will be shown from the specific sender email 
>> address in the specific email client.
>>
>> - There can be a case that an upgraded email client will send 'add me 
>> to whitelist' request to a not-upgraded email client and then the 
>> receiver will see the request as it is - as an email message in the 
>> inbox folder - due to it the content of that message will be in the 
>> language of the domain TLD of the receiver email address and the 
>> content in the email message will explain what is NoSpam.org and how 
>> to upgrade the email client and supported upgraded email clients, etc
>>
>> - In the 'whitelist requests section' in the upgraded email client - 
>> the whitelist requests will appear in a list - there should be 
>> preference so some requests will appear upper and other lower (so 
>> requests from spammers will appear lower) - whitelist requests from 
>> email addresses of domains which are older (according to their WHOIS 
>> details) will appear upper than whitelist requests from email 
>> addresses of domains which are newer. Whitelist requests from a list 
>> of a more-trusted-domains (domains of known webmails service, 
>> universities, governments, etc) will have preference over other 
>> domains, specific TLDs that not anyone can purchase will also have 
>> preference over other TLDs that anyone can purchase (upgraded email 
>> clients will retrieve the list of trusted TLD's and Domains each day 
>> from NoSpam.org backend infrastructure).
>>
>>
>> Notification of spam emails:
>>
>> - An additional feature in the upgraded email client is that whenever 
>> an email message will reach the 'Spam' folder - the email client will 
>> send in the background a known-format email message to the sender and 
>> will notify him about it, if the sender is using an upgraded email 
>> client then it will be able to automatically send a 'add me to 
>> whitelist' request to the receiver in the background (once an email 
>> address is whitelisted - all the email messages from it will move 
>> from 'Spam' to 'Inbox').
>>
>>
>>
>> Email Spoofing:
>>
>> - In an upgraded email client, email messages from 'personal' email 
>> addresses cannot arrive from email relay server, in case it happen 
>> the message will be deleted and the email client will send an 
>> automatic email message in the background to the sender with the text 
>> (in the language of the sender domain TLD) that email messages from 
>> 'email relay servers' cannot be received from him.
>>
>> - In an upgraded email client, email messages from 'mailing list' 
>> email addresses can arrive from email relay servers - but they must 
>> be encrypted with DKIM.
>>
>> - In an upgraded email client, the email client should check the SPF 
>> txt dns record of the sender domain, and will drop the email message 
>> if it is a spoofed email message.
>>
>> - DNS servers developers will need to make the SPF txt dns record to 
>> be a mandatory field for every domain, in order for email spoofing to 
>> be annihilated.
>>
>>
>>
>> Security Aspects:
>>
>> - All stored data in NoSpam.org Backend infrastructure is hashed.
>>
>> - The criminals domains list in NoSpam.org Backend Infrastructure 
>> will be managed only by regulated supervised Law Enforcement Agency 
>> (for example: Interpol) and not by an internet organization such as 
>> the RIRs or ccTLD registries.
>>
>> - Domains owners will have 'forgot password' functionality to their 
>> NoSpam.org account, the password reset link will be sent to the email 
>> address of the owner of the domain according to the domain WHOIS details.
>>
>> - Communication between email clients to NoSpam.org backend 
>> infrastructure will be over https, there will only be an handshake 
>> process in the beginning over electronic mail between email client 
>> and NoSpam.org backend infrastructure - the email client will send an 
>> email message with a chosen key to an email address of @nospam.org 
>> (that key will be used in further communication between the email 
>> client and the NoSpam.org backend infrastructure over https, it will 
>> be used for NoSpam.org backend infrastructure to identify the 
>> specific email address over https, so anyone will not be able to 
>> query NoSpam.org backend infrastructure to know which hashed email 
>> address belongs to which hashed 'mailing list' email address, besides 
>> the email client user with the right key to query NoSpam.org Backend 
>> infrastructure only on himself).
>>
>> - Any email client will download once per day 'spam-rules' file from 
>> NoSpam.org backend infrastructure, 'spam-rules' file will be an xml 
>> formatted file that include rules of when to move an email message 
>> that was received from 'personal' email address which is not 
>> whitelisted to the 'Spam' folder (for example, when email have at 
>> least 1/2/3 links, when email format is rich text or html and not 
>> plaintext, etc), in case future adjustments will be needed to win the 
>> battle against email spam - email clients will not need to be 
>> upgraded, the new 'spam-rules' will be updated in this daily file.
>>
>>
>> To make it short:
>>
>> - Any email message from a subscribed mailing list / newsletter / etc 
>> - will reach to the inbox (that kind of email messages can contain 
>> any kind of content without any restrictions, because the user 
>> subscribed to it and the user can unsubscribe from it at anytime).
>>
>> - Any email message from an email address or domain in whitelist - 
>> will reach the inbox.
>>
>> - Whitelist Handshake process is easy to use and being implemented 
>> with clicks of a button, nothing to type.
>>
>> - In case an email message will the 'Spam' folder - an automatic 
>> email message will be sent from the receiver to sender and sender can 
>> automatically ask to be added to the receiver's whitelist.
>>
>> - Any email message without links/images/plain-url's (plain email 
>> messages, like electronic email was) - will reach the inbox.
>>
>> - Any other email will reach the 'Spam' folder - if needed the user 
>> will be able to easily whitelist the email message in the 'Spam' folder.
>>
>>
>>
>> Spammers need links in their email messages for monetization, above 
>> solution blocks it and also block criminal domains links in email 
>> message and implement email spoofing blocking at client-side. We will 
>> all stop to receive more than 100 spam email messages per day with 
>> the above solution.
>>
>>
>> Respectfully,
>> Elad
>>
>>
>> _______________________________________________
>> members-discuss mailing list
>> members-discuss at ripe.net
>> https://mailman.ripe.net/
>> Unsubscribe:https://lists.ripe.net/mailman/options/members-discuss/matthias%40brumm.net
> -- 
> Unser Familien-Blog:https://brumm.family
>
> _______________________________________________
> members-discuss mailing list
> members-discuss at ripe.net
> https://mailman.ripe.net/
> Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/aleksi%40magnacapax.fi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.ripe.net/ripe/mail/archives/members-discuss/attachments/20200426/0b69bf64/attachment.html>