[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 19:27:46 CEST 2020
Hi! Maybe, but no one here is in the position to make such a project work instantly. To get it rolling, this may be easier than IPv4+. Present a working proof-of-concept with nospan.org and a Thunderbird-Plug-In. Then try to get the E-Mail-Clients on board. As long as the nospam.org servers are scalable, you can grow very fast. Matthias Am 26.04.20 um 19:20 schrieb Elad Cohen: > Jetten, > > This is not up to you to decide. > > This is a membership discuss mailing list, I'm a member just like you > are, please don't shut conversations and tell what we can or cannot > talk about, Spam is a problem that is related to all Ripe LIR members > including you. > > Respectfully, > Elad > ------------------------------------------------------------------------ > *From:* members-discuss <members-discuss-bounces at ripe.net> on behalf > of Jetten Raymond <raymond.jetten at elisa.fi> > *Sent:* Sunday, April 26, 2020 8:04 PM > *To:* members-discuss at ripe.net <members-discuss at ripe.net>; Matthias > Brumm <matthias at brumm.net> > *Subject:* Re: [members-discuss] Technical Solution to resolve the > global "Email Spam" problem > This list is NOT for technical related posts, it is for MEMBERSHIP > related issues. Please move the discussion elsewhere. > > Lähetetty Outlook Mobilesta <https://aka.ms/blhgte> > > ------------------------------------------------------------------------ > *From:* members-discuss <members-discuss-bounces at ripe.net> on behalf > of Matthias Brumm <matthias at brumm.net> > *Sent:* Sunday, April 26, 2020 7:50:23 PM > *To:* members-discuss at ripe.net <members-discuss at ripe.net> > *Subject:* Re: [members-discuss] Technical Solution to resolve the > global "Email Spam" problem > > 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 <mailto: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 -- 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/e4a42d65/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 ]