<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html;
      charset=windows-1252">
  </head>
  <body>
    <p>Hi,</p>
    <p><br>
    </p>
    <p> You clearly misunderstand what "centralized" is. Your local
      government is a good example of a centralized service with
      multiple points of service. Single organization, where decisions
      for all of the multiple service points is made from same place.</p>
    <p><br>
    </p>
    <p>UPS and DHL too, they are single organizations with many many
      service points all over the world. Certainly their service is
      decentralized physically and has to be by nature, but they are
      single organization and decisions made by single body concerning
      all of those service points. Only a few executives making all the
      decisions. That is a centralized service.</p>
    <p><br>
    </p>
    <p>A mailing list does not concern most of the world population.</p>
    <p><br>
    </p>
    <p>No amount of sugar coating will make your proposal anything but
      draconian and potentially orwellian.</p>
    <p><br>
    </p>
    <p>Besides, there are easier ways to solve the spam problem -- using
      blockchain you can, spamassassin plugins etc. you can make e-mail
      system in a way where sending email costs just enough to make
      spamming not as financially viable. (Have made proposals to
      blockchain groups in the past, bottomline is we would need to
      develop our own proof of concept to gain any traction)</p>
    <p><br>
    </p>
    <p>-Aleksi<br>
    </p>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 4/26/20 9:28 PM, Elad Cohen wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:DB7PR10MB21541A3EA1EE5A51424CA53DD6AE0@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);">
        It is not centralized because there are many servers with bgp
        anycast spread all over the world.</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);">
        All the data in NoSpam.org backend infrastructure is hashed.</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);">
        All the data which is sent between an email client to NoSpam.org
        backend infrastructure is hashed.</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);">
        Queries that the email client send to NoSpam.org backend are not
        logged and are not saved in any way.</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);">
        Currently - when you register to an online mailing list or to a
        newsletter - it is also centralized - and in cleartext (not
        hashed), so this is exactly the same - just much bigger
        infrastructure  spread over many locations in the world with bgp
        anycast.<br>
      </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 Aleksi <a class="moz-txt-link-rfc2396E" href="mailto:aleksi@magnacapax.fi"><aleksi@magnacapax.fi></a><br>
          <b>Sent:</b> Sunday, April 26, 2020 9: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><br>
          <b>Subject:</b> Re: [members-discuss] Technical Solution to
          resolve the global "Email Spam" problem</font>
        <div> </div>
      </div>
      <div>
        <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="x_moz-cite-prefix">On 4/26/20 7:50 PM, Matthias
          Brumm wrote:<br>
        </div>
        <blockquote type="cite">
          <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_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_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_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_mimeAttachmentHeader"></fieldset>
            <pre class="x_moz-quote-pre">_______________________________________________
members-discuss mailing list
<a class="x_moz-txt-link-abbreviated" href="mailto:members-discuss@ripe.net" moz-do-not-send="true">members-discuss@ripe.net</a>
<a class="x_moz-txt-link-freetext" href="https://mailman.ripe.net/" moz-do-not-send="true">https://mailman.ripe.net/</a>
Unsubscribe: <a class="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_moz-signature" cols="72">-- 
Unser Familien-Blog: <a class="x_moz-txt-link-freetext" href="https://brumm.family" moz-do-not-send="true">https://brumm.family</a></pre>
          <br>
          <fieldset class="x_mimeAttachmentHeader"></fieldset>
          <pre class="x_moz-quote-pre">_______________________________________________
members-discuss mailing list
<a class="x_moz-txt-link-abbreviated" href="mailto:members-discuss@ripe.net" moz-do-not-send="true">members-discuss@ripe.net</a>
<a class="x_moz-txt-link-freetext" href="https://mailman.ripe.net/" moz-do-not-send="true">https://mailman.ripe.net/</a>
Unsubscribe: <a class="x_moz-txt-link-freetext" href="https://lists.ripe.net/mailman/options/members-discuss/aleksi%40magnacapax.fi" moz-do-not-send="true">https://lists.ripe.net/mailman/options/members-discuss/aleksi%40magnacapax.fi</a>
</pre>
        </blockquote>
      </div>
    </blockquote>
  </body>
</html>