[members-discuss] Technical Solution to resolve the global "Email Spam" problem
- Previous message (by thread): [members-discuss] Technical Solution to resolve the global "Email Spam" problem
- Next message (by thread): [members-discuss] Technical Solution to resolve the global "Email Spam" problem
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Matthias Brumm
matthias at brumm.net
Sun Apr 26 18:50:23 CEST 2020
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://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/matthias%40brumm.net -- Unser Familien-Blog: https://brumm.family -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.ripe.net/ripe/mail/archives/members-discuss/attachments/20200426/f07100b7/attachment.html>
- Previous message (by thread): [members-discuss] Technical Solution to resolve the global "Email Spam" problem
- Next message (by thread): [members-discuss] Technical Solution to resolve the global "Email Spam" problem
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]