<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html;
      charset=windows-1252">
  </head>
  <body>
    <p>a centralized solution ... Yikes!</p>
    <p>Next step permits for email, only to be approved by government
      officials? For spam review purposes all emails must be stored
      centrally? Certainly no abuse will ever happen.</p>
    <br>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 4/26/20 7:50 PM, Matthias Brumm
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:1ec3588d-3fa2-2093-0711-88a950d5db57@brumm.net">
      <meta http-equiv="Content-Type" content="text/html;
        charset=windows-1252">
      <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="moz-cite-prefix">Am 26.04.20 um 18:05 schrieb Elad
        Cohen:<br>
      </div>
      <blockquote type="cite"
cite="mid:DB7PR10MB2154F130B8C28D4FA11F035CD6AE0@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);"> <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="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="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="mimeAttachmentHeader"></fieldset>
        <pre class="moz-quote-pre" wrap="">_______________________________________________
members-discuss mailing list
<a class="moz-txt-link-abbreviated" href="mailto:members-discuss@ripe.net" moz-do-not-send="true">members-discuss@ripe.net</a>
<a class="moz-txt-link-freetext" href="https://mailman.ripe.net/" moz-do-not-send="true">https://mailman.ripe.net/</a>
Unsubscribe: <a class="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="moz-signature" cols="72">-- 
Unser Familien-Blog: <a class="moz-txt-link-freetext" href="https://brumm.family" moz-do-not-send="true">https://brumm.family</a></pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
members-discuss mailing list
<a class="moz-txt-link-abbreviated" href="mailto:members-discuss@ripe.net">members-discuss@ripe.net</a>
<a class="moz-txt-link-freetext" href="https://mailman.ripe.net/">https://mailman.ripe.net/</a>
Unsubscribe: <a class="moz-txt-link-freetext" href="https://lists.ripe.net/mailman/options/members-discuss/aleksi%40magnacapax.fi">https://lists.ripe.net/mailman/options/members-discuss/aleksi%40magnacapax.fi</a>
</pre>
    </blockquote>
  </body>
</html>