<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body>
<p>Hi!</p>
<p><br>
</p>
<p>Maybe, but no one here is in the position to make such a project
work instantly. <br>
</p>
<p><br>
</p>
<p>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.</p>
<p><br>
</p>
<p>Matthias<br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">Am 26.04.20 um 19:20 schrieb Elad
Cohen:<br>
</div>
<blockquote type="cite"
cite="mid:DB7PR10MB2154F47422F78BA4152B1F92D6AE0@DB7PR10MB2154.EURPRD10.PROD.OUTLOOK.COM">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
Jetten,</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
This is not up to you to decide.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
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.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
Respectfully,</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
Elad<br>
</div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font style="font-size:11pt"
face="Calibri, sans-serif" color="#000000"><b>From:</b>
members-discuss <a class="moz-txt-link-rfc2396E" href="mailto:members-discuss-bounces@ripe.net"><members-discuss-bounces@ripe.net></a> on
behalf of Jetten Raymond <a class="moz-txt-link-rfc2396E" href="mailto:raymond.jetten@elisa.fi"><raymond.jetten@elisa.fi></a><br>
<b>Sent:</b> Sunday, April 26, 2020 8:04 PM<br>
<b>To:</b> <a class="moz-txt-link-abbreviated" href="mailto:members-discuss@ripe.net">members-discuss@ripe.net</a>
<a class="moz-txt-link-rfc2396E" href="mailto:members-discuss@ripe.net"><members-discuss@ripe.net></a>; Matthias Brumm
<a class="moz-txt-link-rfc2396E" href="mailto:matthias@brumm.net"><matthias@brumm.net></a><br>
<b>Subject:</b> Re: [members-discuss] Technical Solution to
resolve the global "Email Spam" problem</font>
<div> </div>
</div>
<div>
<div dir="auto" style="direction:ltr; margin:0; padding:0;
font-family:sans-serif; font-size:11pt; color:black">
This list is NOT for technical related posts, it is for
MEMBERSHIP related issues. Please move the discussion
elsewhere.<br>
<br>
</div>
<div dir="auto" style="direction:ltr; margin:0; padding:0;
font-family:sans-serif; font-size:11pt; color:black">
<span id="x_OutlookSignature">
<div dir="auto" style="direction:ltr; margin:0; padding:0;
font-family:sans-serif; font-size:11pt; color:black">
Lähetetty <a href="https://aka.ms/blhgte"
moz-do-not-send="true">Outlook Mobilesta</a></div>
</span><br>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font style="font-size:11pt"
face="Calibri, sans-serif" color="#000000"><b>From:</b>
members-discuss <a class="moz-txt-link-rfc2396E" href="mailto:members-discuss-bounces@ripe.net"><members-discuss-bounces@ripe.net></a> on
behalf of Matthias Brumm <a class="moz-txt-link-rfc2396E" href="mailto:matthias@brumm.net"><matthias@brumm.net></a><br>
<b>Sent:</b> Sunday, April 26, 2020 7:50:23 PM<br>
<b>To:</b> <a class="moz-txt-link-abbreviated" href="mailto:members-discuss@ripe.net">members-discuss@ripe.net</a>
<a class="moz-txt-link-rfc2396E" href="mailto:members-discuss@ripe.net"><members-discuss@ripe.net></a><br>
<b>Subject:</b> Re: [members-discuss] Technical Solution to
resolve the global "Email Spam" problem</font>
<div> </div>
</div>
<div>
<p>Hi!</p>
<p><br>
</p>
<p>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?</p>
<p><br>
</p>
<p>Matthias<br>
</p>
<p><br>
</p>
<div class="x_x_moz-cite-prefix">Am 26.04.20 um 18:05 schrieb
Elad Cohen:<br>
</div>
<blockquote type="cite">
<style type="text/css" style="display:none">
<!--
p
{margin-top:0;
margin-bottom:0}
-->
</style>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12pt; color:rgb(0,0,0)">
<span>Hello Everyone,<br>
</span>
<div><br>
</div>
<div>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).<br>
</div>
<div><br>
</div>
<div>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".<br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>The presentation that the illegal anonymous
organization "The Spamhaus Project" wrote on themselves:<br>
</div>
<div><a class="x_x_moz-txt-link-freetext"
href="https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Violation"
moz-do-not-send="true">https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Violation</a><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>The Implementation:<br>
</div>
<div><br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
<div>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).<br>
</div>
<div><br>
</div>
<div>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).<br>
</div>
<div><br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
<div>The domain owner will need to create a callback file
in his website, for example in the path:
"/nospam-notification-callback" (<a
class="x_x_moz-txt-link-freetext"
href="http://example.com/nospam-notification-callback"
moz-do-not-send="true">http://example.com/nospam-notification-callback</a>)
- 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).<br>
</div>
<div><br>
</div>
<div>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).<br>
</div>
<div><br>
</div>
<div>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).<br>
</div>
<div><br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>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):<br>
</div>
<div><br>
</div>
<div>- 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.<br>
</div>
<div><br>
</div>
<div>- 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.<br>
</div>
<div><br>
</div>
<div>- 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).<br>
</div>
<div><br>
</div>
<div>- 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).<br>
</div>
<div><br>
</div>
<div>- 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.<br>
</div>
<div><br>
</div>
<div>- 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.<br>
</div>
<div><br>
</div>
<div>- 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:<br>
</div>
<div><br>
</div>
<div>- 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.<br>
</div>
<div><br>
</div>
<div>- 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.<br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>Whitelist Handshake:<br>
</div>
<div><br>
</div>
<div>- 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.<br>
</div>
<div><br>
</div>
<div>- 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<br>
</div>
<div><br>
</div>
<div>- 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).<br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>Notification of spam emails:<br>
</div>
<div><br>
</div>
<div>- 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').<br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>Email Spoofing:<br>
</div>
<div><br>
</div>
<div>- 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.<br>
</div>
<div><br>
</div>
<div>- 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.<br>
</div>
<div><br>
</div>
<div>- 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.<br>
</div>
<div><br>
</div>
<div>- 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.<br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>Security Aspects:<br>
</div>
<div><br>
</div>
<div>- All stored data in NoSpam.org Backend
infrastructure is hashed.<br>
</div>
<div><br>
</div>
<div>- 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.<br>
</div>
<div><br>
</div>
<div>- 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.<br>
</div>
<div><br>
</div>
<div>- 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).<br>
</div>
<div><br>
</div>
<div>- 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.<br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>To make it short:<br>
</div>
<div><br>
</div>
<div>- 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).<br>
</div>
<div><br>
</div>
<div>- Any email message from an email address or domain
in whitelist - will reach the inbox.<br>
</div>
<div><br>
</div>
<div>- Whitelist Handshake process is easy to use and
being implemented with clicks of a button, nothing to
type.<br>
</div>
<div><br>
</div>
<div>- 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.<br>
</div>
<div><br>
</div>
<div>- Any email message without links/images/plain-url's
(plain email messages, like electronic email was) - will
reach the inbox.<br>
</div>
<div><br>
</div>
<div>- 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.<br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>Respectfully,<br>
</div>
<div>Elad<br>
</div>
<span></span><br>
</div>
<br>
<fieldset class="x_x_mimeAttachmentHeader"></fieldset>
<pre class="x_x_moz-quote-pre">_______________________________________________
members-discuss mailing list
<a class="x_x_moz-txt-link-abbreviated" href="mailto:members-discuss@ripe.net" moz-do-not-send="true">members-discuss@ripe.net</a>
<a class="x_x_moz-txt-link-freetext" href="https://mailman.ripe.net/" moz-do-not-send="true">https://mailman.ripe.net/</a>
Unsubscribe: <a class="x_x_moz-txt-link-freetext" href="https://lists.ripe.net/mailman/options/members-discuss/matthias%40brumm.net" moz-do-not-send="true">https://lists.ripe.net/mailman/options/members-discuss/matthias%40brumm.net</a>
</pre>
</blockquote>
<pre class="x_x_moz-signature" cols="72">--
Unser Familien-Blog: <a class="x_x_moz-txt-link-freetext" href="https://brumm.family" moz-do-not-send="true">https://brumm.family</a></pre>
</div>
</div>
</blockquote>
<pre class="moz-signature" cols="72">--
Unser Familien-Blog: <a class="moz-txt-link-freetext" href="https://brumm.family">https://brumm.family</a></pre>
</body>
</html>