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

Spam... Plus the fact that this guy appears to have some link in BGP
Hijacking cases... (sources :
https://mybroadband.co.za/news/internet/318205-the-big-south-african-ip-address-heist-how-millions-are-made-on-the-grey-market.html)


On 4/26/20 8:13 PM, Franco Tauceri wrote:
> In the meanwhile we're waiting for next Elad's idea to save the
> planet, I suggest a little move that will contribute to a little
> reduction of spam: is it kindly possible to remove him from this list
> (that, it's clear, he as no understood the goal of this list...) ?
>
> Regards
>
> -- 
> 	
> Franco Tauceri
> *DomainRegister*
> m: 	39.3483064202
> w:
> https://DomainRegister.international  e: [email protected]
> <mailto:franco.tauceri at domainregister.it>
>
>
> On 26/04/2020 07:31 PM, Elad Cohen wrote:
>
>>>  
>>> Hello,
>>>  
>>> Ripe have 30 millions euros of expenses each year that are hidden
>>> and now shown to where exactly they are paid, instead of that
>>> corruption - a small part of the money can be used also for the
>>> deployment of IPv4+ and also for NoSpam.org and also for the next
>>> solution that I will present regarding how to dramatically lower
>>> ddos attacks, a simple and elegant solution that will help each and
>>> every ASN in the world.
>>>  
>>> Respectfully,
>>> Elad
>>>  
>>> ------------------------------------------------------------------------
>>> *From:* Matthias Brumm <matthias at brumm.net>
>>> *Sent:* Sunday, April 26, 2020 8:27 PM
>>> *To:* Elad Cohen <elad at netstyle.io>; Jetten Raymond
>>> <raymond.jetten at elisa.fi>; members-discuss at ripe.net
>>> <members-discuss at ripe.net>
>>> *Subject:* Re: [members-discuss] Technical Solution to resolve the
>>> global "Email Spam" problem
>>>  
>>>
>>> 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>
>>>> <mailto:members-discuss-bounces at ripe.net> on behalf of Jetten
>>>> Raymond <raymond.jetten at elisa.fi> <mailto:raymond.jetten at elisa.fi>
>>>> *Sent:* Sunday, April 26, 2020 8:04 PM
>>>> *To:* members-discuss at ripe.net <mailto:members-discuss at ripe.net>
>>>> <members-discuss at ripe.net> <mailto:members-discuss at ripe.net>;
>>>> Matthias Brumm <matthias at brumm.net> <mailto: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>
>>>> <mailto:members-discuss-bounces at ripe.net> on behalf of Matthias
>>>> Brumm <matthias at brumm.net> <mailto:matthias at brumm.net>
>>>> *Sent:* Sunday, April 26, 2020 7:50:23 PM
>>>> *To:* members-discuss at ripe.net <mailto:members-discuss at ripe.net>
>>>> <members-discuss at ripe.net> <mailto: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
>>
>> _______________________________________________
>> 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/franco.tauceri%40domainregister.it
>
> _______________________________________________
> 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/arnold.dech%40adct.be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ripe.net/ripe/mail/archives/members-discuss/attachments/20200426/9d9110e4/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: photo_2020-04-26_20-26-31.jpg
Type: image/jpeg
Size: 89008 bytes
Desc: not available
URL: <https://lists.ripe.net/ripe/mail/archives/members-discuss/attachments/20200426/9d9110e4/attachment.jpg>